Possible mismatch in angle_min, angle_max, angle_increment and number of data points in LaserScan message

[nielsvd]

In attempting to combine the ouster_driver with a SLAM algorithm, it came to my attention that, in the /scan topic, there may be a mismatch between:

• msg.angle_min
• msg.angle_max
• msg.angle_increment
• msg.ranges.size() or equivalently, msg.intensities.size()

The SLAM algorithm in question asserts the following condition (up to floating-point precision):
msg.angle_max == msg.angle_min + msg.angle_increment * (msg.ranges.size() - 1)
I.e., by (msg.ranges.size() - 1) the number of "gaps" between data points determines the angle increment, and not the number of data points itself. I suppose that makes sense, in particular if you would generalize to non-360 degree scans. As can be seen in

ros2_ouster_drivers/ros2_ouster/include/ros2_ouster/conversions.hpp

Line 230 in d3cd586

msg.angle_increment = 2 * M_PI / ouster::sensor::n_cols_of_lidar_mode(mdata.mode);

... in the driver the "number of data points" is used to compute the angle increment, and the lines above are equivalent to msg.angle_increment = (msg.angle_max - msg.angle_min) / msg.ranges.size().

Say there is indeed a mismatch, there could be an error in at least three of the data fields mentioned above. Currently, I'm not familiar enough with the device and the driver to determine which one should be fixed:

• msg.angle_min = -M_PI + msg.angle_increment,
• msg.angle_max = M_PI - msg.angle_increment,
• msg.angle_increment = 2 * M_PI / (ouster::sensor::n_cols_of_lidar_mode(mdata.mode) - 1),
• technically, msg.ranges could be extended with an additional data point (repeating the first one).