LD19 driver bug -- incompatible with ROS2 SLAM

[Chambana]

Describe the bug A clear and concise description of what the bug is. The LD19 driver apparently calculates the number of readings in a scan in a non-conformal way and is out of spec with what the ROS2 SLAM Toolbox expects. The maintainer of SLAM toolbox has asked maintainers of LIDAR drivers to fix the calculation on their end. With the current LD19 driver, the SLAM Toolbox will discard around 70% of scans from the LD19 (see graphic below) and is largely unusable. This LD19 driver needs to be updated to always output the same number of readings in every scan and not repeat 0 degrees and 360 degrees. The output range should be [0,360) not [0,360].

To Reproduce Steps to reproduce the behavior:

• Run this repo's driver on ROS2 Humble

• Run the SLAM toolbox on ROS2 Humble (you'll need a a robot model publisher and source of odom-base_link TF to start the toolbox)

• the LD19's laserscan topic will provide a solid 10Hz output (USB or serial UART doesn't affect this problem)

• the SLAM toolbox discards 60-70% of all scans because the SLAM toolbox is expecting a certain number of readings per scan (which appears to be set at SLAM Toolbox initialization) and the scan length provided by the LD19 driver is consistently off by 1 reading.

• The issue is masked to the user because the scan topic looks great and comes in at 10Hz. Also, the SLAM map does get created (because it's still receiving some scans) but it's hugely inefficient due to the toolbox dropping 70% of scans.

Expected behavior A clear and concise description of what you expected to happen. These warnings in SLAM Toolbox should be pretty rare and only occur when the LIDAR scan speed doesn't hit its timing, but they're currently alerting on 70% of all scans [async_slam_toolbox_node-1] LaserRangeScan contains 452 range readings, expected 451 [async_slam_toolbox_node-1] LaserRangeScan contains 452 range readings, expected 451 [async_slam_toolbox_node-1] LaserRangeScan contains 452 range readings, expected 451 [async_slam_toolbox_node-1] LaserRangeScan contains 452 range readings, expected 451 [async_slam_toolbox_node-1] LaserRangeScan contains 452 range readings, expected 451 [async_slam_toolbox_node-1] LaserRangeScan contains 450 range readings, expected 451 [async_slam_toolbox_node-1] LaserRangeScan contains 452 range readings, expected 451

Screenshots If applicable, add screenshots to help explain your problem. SLAM toolbox discarding 70% of scans

Desktop (please complete the following information):

OS: Ubuntu 22.04 ROS2 version: Humble Device type: x86-64 (SLAM toolbox), ARM (LD19 driver) Additional context Add any other context about the problem here. https://github.com/SteveMacenski/slam_toolbox/issues/293#issuecomment-696296457 https://github.com/SteveMacenski/slam_toolbox/issues/430#issuecomment-905100814 https://github.com/SteveMacenski/slam_toolbox/issues/141#issuecomment-564670621 https://github.com/SteveMacenski/slam_toolbox/issues/426#issuecomment-882782222 https://github.com/SteveMacenski/slam_toolbox/issues/328#issuecomment-779367098 https://github.com/SteveMacenski/slam_toolbox/pull/145

Easiest fix is to probably alter the LD19 driver angle min / max so that it conforms to the SLAM Toolbox's format and triggers the GetIs360Laser() check here: https://github.com/SteveMacenski/slam_toolbox/blob/912703c43b7a640303b1b5fc62f05d53fae9cf57/lib/karto_sdk/include/karto_sdk/Karto.h#L4302C11-L4302C11

[Chambana]

@mingdonghu The best fix would be a launch file boolean that locks the number of readings in each Laserscan message to be the same (could be whatever the first message's scan length is). Also, the angle_min and angle_max and angle increment shouldn't repeat readings for 0 degrees and 360 degrees.

[Chambana]

@mingdonghu bump

[mingdonghu]

@Chambana Sorry this is due to the lidar product itself

[Chambana]

Why was this closed? Why couldn't the driver be modified to truncate the numbers of readings per scan to a fixed number? I understand that the hardware is providing a different number each time, but I'm talking about fixing the length of the output.

[mil0sou]

Hey, did you manage to solve it? I'm currently experiencing the same problem

[Chambana]

Yes. Search the other issues in this repo for more info.

On Wed, Jan 17, 2024, 3:03 AM Milo @.***> wrote:

Hey, did you manage to solve it? I'm currently experiencing the same problem

— Reply to this email directly, view it on GitHub https://github.com/ldrobotSensorTeam/ldlidar_ros2/issues/1#issuecomment-1895476924, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADL233VZAH6SN6XI264ZOH3YO6OWVAVCNFSM6AAAAAA3WH3YHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVGQ3TMOJSGQ . You are receiving this because you were mentioned.Message ID: @.***>