Comments (9)
There's certainly an option to propose one. If you wanted to do so conducting a survey of the sensors available, determining their datatypes and then layout out the necessary coverage elements would be what we'd want to do. As well as collecting all the competing implementations for comparison and contrasting.
A few concerns I would have would be to think about what order scans are measured? Are they simultaneous? Do they go in the same direction? Do they have the same start angles? Do they follow a grid or are they interleaved or offset?
There are also several approaches using existing datatypes that can capture the information fully.
The simplest is to simply publish N LaserScan messages, one for each row of the scan.
As a multi layer laser scanner starts to get to a non-trivial number of layers it starts to look a lot like a depth camera, and as such the DepthImage datatype starts to look like a good way to encode the data for analysis. (Clearly this would be missing some of the potential timing data, but can be processed quickly in many common pipelines). And of course the laser drivers could also just directly publish the point clouds doing all the internal timing and reprojection internally. Again there's a little bit of timing loss compared to the high precision laser scan to point cloud projections without the timing information available.
One benefit of using N of the basic LaserScan messages is that the standard laser scan to point cloud implementations can continue to work. Also if users want classic behavior they can process just one of the scans. Each scan can be run into all the standard navigation algorithms without andy changes. And the aggregate results can moderately easily be aggregated say using the point cloud aggregator just like we did for the tilting hokuyo on the PR2. N scans can be aggregated, transformed with high precision and then converted into the depth map or point cloud.
So in the end I'd suggest encouraging the laser scanner drivers to publish N of the standard Laser Scans for the N rows. Likely they could be put out on the same topic and they would just want to have different frame_ids for each scan to show the different angular positions. And this would work for ones that are not even coaxial or have a single focal point, or exactly the same timings.
from common_msgs.
Thanks for the insights, Tully. I was already thinking about this and many of the problems you pointed out popped up to me, too. But I think it's manageable if it's done proper/thoroughly.
I've two comments now before anyone starts doing the actual job.
-
The idea to publish multiple LaserScan messages won't work for the majority of multi-layer laser scanners, because the scan rings aren't planes but cones. And I think most (if not all) LaserScan processing algorithms only count with planes. Creating separate frame_ids for every ring would not help with this issue. Therefore, I'm strongly against re-using the existing LaserScan type for this kind of non-planar information.
-
The reason why I think a LaserScan-like message is needed, is exactly the timing and reprojection information that can get lost during a transformation to a point cloud. Think about faster mobile robots which can go 1 meter per second or faster. If the scan frequency is 10 Hz, the robot drives around 10 cm during capturing the scan. And you really need to account for this motion during the transformation to a point cloud. Most lidars provide nodes that publish point clouds, but they either use some internal IMU for doing this correction, or they don't do the correction at all... And I feel this is just wrong in case you have some better-grade fast odometry available.
from common_msgs.
32 rings, all lasers pointing in the same direction horizontally, vertically evenly spaced by 4/3° around -10° direction. Firing sequence is irregular in angles, and regular in time offsets (only 1 laser firing at a time, the 32 rings are collected sequentially). The single firing sequence consists of 32 cycles of 1.152μs followed by 8 dead cycles of 1.152μs. Horizontal angle can be interpolated for higher precision given the time offsets and assuming a constant rotational speed of the lidar.
Possible output channels: X, Y, Z, Intensity, Ring. Supports dual output mode (strongest, latest).
from common_msgs.
32 rings, lasers pointing into different directions both vertically and horizontally. Vertical rays have irregular angle offsets. Timing is a little bit unclear - I've only found docs for the 16-beam version. in the 16-beam version, there are 3 us per firing (times 16) plus 2 us recharge time, giving 50 us per firing pattern.
Possible output channels: X, Y, Z, Intensity. Supports dual output mode (strongest, latest).
from common_msgs.
64 rings, lasers pointing to different directions both vertically and horizontally. Vertical rays have regular offsets, horizontal rays have partly-regular periodic offsets. Timing-wise, it should be a solid-state multi-beam lidar in the vertical direction, so all points in a firing sequence should have the same timestamp. Nevertheless, the docs say the minimum length of the firing pattern is 50 us.
What's interesting here is that the 16-beam version publishes a 64-ring pointcloud, where the excess rings are filled with zeros...
Possible output channels: X, Y, Z, ring, intensity, timestamp, reflectivity, noise, range.
from common_msgs.
Hi
Is there a way to filter out those zeros points in the pointcloud (64 layers)? As i am using a OS1-16.
Best,
Samuel
from common_msgs.
@HappySamuel This is not the right place to ask. Please, ask the Ouster lidar support. Generally, a LaserScan message can contain many values, but only those inside its specified range are considered valid.
from common_msgs.
Hi @peci1
Ok, i will ask for the ouster lidar support.
Best,
Samuel
from common_msgs.
Here's a working draft of a package implementing the proposed messages: https://github.com/peci1/multilayer_laser_scan .
from common_msgs.
Related Issues (20)
- add ARROW_LIST to visualization_msgs/Marker HOT 3
- add Jerk message to the geometry_msgs HOT 3
- Add cell_temperature to sensor_msgs/BatteryState
- sensor_msgs/Range lacking variance (error) field HOT 6
- Organizing sensor messages by stamped and unstamped HOT 3
- Array message versions of PoseStamped and TransformStamped HOT 8
- Can not found CameraInfo under sensor_msgs namespace HOT 1
- MultiDOFJointTrajectoryPoint.msg accelerations are declared as Twist instead of Accel
- [BatteryState] Add time to full/empty HOT 1
- Python can't import messages from "sensor_msgs" module HOT 1
- Signal Handler Error while compiling HOT 1
- NavSatStatus quality status HOT 6
- New Releases HOT 5
- point_cloud2 read_message returns 2 values when reading field HOT 2
- visualization_msgs/MarkerArray is provided but visualization_msgs/ImageMarkerArray is not HOT 1
- TransformStamped and tf2 Inconsistency HOT 2
- Pose and Transform messages are redundant HOT 2
- Default Quaternion is invalid HOT 2
- About a constant in visualization_msgs/Marker
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from common_msgs.