If reverse_data = true (see here), the driver reverses the order of individual point measurements in a scan.
The result is that the output scan does not follow the ROS laser scan massage definition, which says:
# in frame frame_id, angles are measured around
# the positive Z axis (counterclockwise, if Z is up)
# with zero angle being forward along the x axis
What happens is that a consumer of this wrong scan massage thinks that the individual point measurements were recorded in the opposite temporal order - which causes problems if you try to correct for motion distortion (eg, Cartographer does this).
Conclusion: reversing the data should never happen in the driver, this is a bug.
Until this bug is fixed in the driver, you can use this rplidar_inverted.launch file as workaround:
If
reverse_data = true
(see here), the driver reverses the order of individual point measurements in a scan.The result is that the output scan does not follow the ROS laser scan massage definition, which says:
What happens is that a consumer of this wrong scan massage thinks that the individual point measurements were recorded in the opposite temporal order - which causes problems if you try to correct for motion distortion (eg, Cartographer does this).
Conclusion: reversing the data should never happen in the driver, this is a bug.
Until this bug is fixed in the driver, you can use this
rplidar_inverted.launch
file as workaround:It ensures that
reverse_data = false
and inverts the frame so that the rotation direction is correct (see https://github.com/Slamtec/rplidar_ros/issues/31).