Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Incorrect LiDAR simulation and subsequent logic error in turtlebot3_drive.cpp #178

Open
squizz617 opened this issue Jan 26, 2022 · 1 comment

Comments

@squizz617
Copy link

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
Copy link
Contributor

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!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants