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 https://github.com/ros-drivers/ros2_ouster_drivers/blob/d3cd586e2548f9989b68ebc33b03a5d99b816ea8/ros2_ouster/include/ros2_ouster/conversions.hpp#L230 ... 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:
In attempting to combine the
ouster_driverwith a SLAM algorithm, it came to my attention that, in the/scantopic, there may be a mismatch between:msg.angle_minmsg.angle_maxmsg.angle_incrementmsg.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 https://github.com/ros-drivers/ros2_ouster_drivers/blob/d3cd586e2548f9989b68ebc33b03a5d99b816ea8/ros2_ouster/include/ros2_ouster/conversions.hpp#L230 ... in the driver the "number of data points" is used to compute the angle increment, and the lines above are equivalent tomsg.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),msg.rangescould be extended with an additional data point (repeating the first one).