tfoote
commented
4 years ago 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.
peci1
HappySamuel
Nowadays, there seem to be lots of multiple-layer lidars on the market. I've noticed there's no datatype that would represent them as laserscans (of course, you can transform them into pointclouds right away, but you can lose some information during the transformation).
The result is that most lidar vendors create their own message types, which are, of course, incompatible. And then, it also means each lidar vendor provides his own version of raw data->pointcloud transformers, although there already is the standard (though single-layer) LaserScanToPointCloud tool provided by ROS.
I think it'd be nice to provide a common defeinition vendors could use to get to the same nice state where single-layered lidars are now in ROS.
However, I'm neither a lidar maker, nor do I feel I could persuade them to switch to a different scan message. Do you see any way to proceed?
E.g. Gazebo has its own multilayered scan definition, although a simplified one which doesn't account for the time it takes to capture the scan: https://bitbucket.org/osrf/gazebo/src/default/gazebo/msgs/laserscan.proto .