Incorrect LiDAR simulation and subsequent logic error in `turtlebot3_drive.cpp`

[squizz617]

Hi, I want to report a discrepancy between the simulated turtlebot and the physical one that runs LDS-01 sensor.

Physical robot

Based on the sensor specification, two bytes are used to store each scan distance data (unit: mm), meaning that the valid range of raw scan data is 0x00 - 0xFFFF (65535).

Then, in the LDS sensor driver, the stored raw data is read to populate the float32[] ranges array of sensor_msgs/laser_scan.msg. Each raw data is divided by 1000.0 and then written at scan->ranges[idx], so on the ROS side, we can only get data within range [0.0 - 65.535] in the ranges array.

This can be confirmed by monitoring the /scan ROS topic while executing turtlebot3; scan data does not exceed 65.535.

Simulation

However, the simulator relies on gazebo plugin libgazebo_ros_ray_sensor, which does not respect the specification of LDS-01 sensor. The scan data published by the plugin is never constrained to the valid range in any of the simulated nodes, thus on the ROS side, the scan data contains values exceeding 65.535 (the data gets as big as inf).

Such discrepancy can be problematic if the development process relies on the simulated environment and makes incorrect assumptions. Please see below for details.

Additional issue

Turtlebot3 manual introduces an autonomous collision avoidance node here (at the bottom of the foxy tab), which utilizes the LDS scan result to control turtlebot3 in a way that it does not get close to nearby objects.

When processing the received scan data, the code does not properly constrain the data to range_max parameter, because it only clamps inf to msg->range_max. Any "non-inf" value is used as is, even though they can be invalid (according to LDS-01 specification, maximum valid distance is 3500mm). When operating the physical robot, scan data can never contain inf (as explained above), and those data that exceed 3500mm will not be clamped under the logic of this drive controller.

[ROBOTIS-Will]

Hi @squizz617

Thank you for reporting the issue. I'll update the LDS driver so that any range values that exceed the range_max could be represented as inf. Please allow us a few weeks until we can get onto this. Thanks!