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_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
|
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).
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 inros2_ouster_drivers/ros2_ouster/include/ros2_ouster/conversions.hpp
Line 230 in d3cd586
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),msg.rangescould be extended with an additional data point (repeating the first one).