I don’t think anybody is proposing to discard the LaserScan message. That wouldn’t make much sense. But I agree with you that LaserScan3D would be a better name (or, to revive my very old proposal MultiLayerLaserScan, but LaserScan3D is shorter and still precise enough).
3 Likes
I agree that there is a need to reduce the bandwidth when it comes to sending high-resolution LiDAR data.
The bandwidth problem should not be underestimated. There is a case to be made for LiDAR scanners transmitting ROS messages natively (like the SICK picoScan), without the need for a vendor-specific driver. This makes the discussion about bandwidth even more relevant.
Transmitting integral distances with a range multiplier would provide a significant reduction in bandwidth and could help mitigate the issue. A suggestion would be to include a scaling factor and an offset in the LidarChannel type. The offset allows efficient transmission of domains that do not start at zero.
In dynamic scenarios, where the sensor is subject to rotations, e.g. from a host vehicle, and the fire timing sequence is fixed, the deviation in actual measurement angles and “normative” angles can be significant. The resulting error depends in spinning lidars on the scan frequency or resp. the scan cycle time. Sacrificing measurement accuracy for saving bandwidth is a compromise that can only be made with knowledge about the application. To circumvent this problem, the angles or beam time offsets must be transmitted in the LidarScan object depending on which control strategy the sensor implements. As an alternative, a LidarInfo message would have to be sent along with each LidarScan message.
With modern high-resolution LiDARs that use an n × m grid-like scan pattern, sending angle information every time introduces minimal overhead compared to the range data. One could consider adding a LidarInfo field directly to the LidarScan message. This would allow a choice between using a latched LidarInfo topic or embedding the LidarInfo within each LidarScan.
If LidarInfo is really sent very infrequently, why not store angle, timestamp, and related information per beam? This would allow for greater flexibility when accommodating different measurement methods. As an alternative, the proposed specialized LidarInfo messages are very interesting. They would introduce flexibility in scanner designs that we currently cannot anticipate, while still providing a fallback that works for all LiDAR scanners. Tailoring beam information to the LiDAR scanner’s measurement principle enables the most efficient use of bandwidth.