You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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!
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 ofsensor_msgs/laser_scan.msg
. Each raw data is divided by 1000.0 and then written atscan->ranges[idx]
, so on the ROS side, we can only get data within range [0.0 - 65.535] in theranges
array.This can be confirmed by monitoring the
/scan
ROS topic while executing turtlebot3; scan data does not exceed65.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 exceeding65.535
(the data gets as big asinf
).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 clampsinf
tomsg->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 containinf
(as explained above), and those data that exceed 3500mm will not be clamped under the logic of this drive controller.The text was updated successfully, but these errors were encountered: