myzhar / ldrobot-lidar-ros2 Goto Github PK

I am using ldlidar
for cartographer slam ros2 humble. The ldlidar published scan data on topic /ldlidar_node/scan but the cartographer node expects scan data on /scan topic. I remap the topic name from /ldlidar_node/scan to /scan following launch file remap but no data was published on /scan
here is my launch file

import os
from ament_index_python.packages import get_package_share_directory
from launch import LaunchDescription
from launch.actions import DeclareLaunchArgument
from launch.substitutions import LaunchConfiguration
from launch_ros.actions import Node, LifecycleNode


def generate_launch_description():
    
    node_name = LaunchConfiguration('node_name')

    # Lidar node configuration file
    lidar_config_path = os.path.join(
        get_package_share_directory('ldlidar_node'),
        'params',
        'ldlidar.yaml'
    )

    # Launch arguments
    declare_node_name_cmd = DeclareLaunchArgument(
        'node_name',
        default_value='ldlidar_node',
        description='Name of the node'
    )

    # LDLidar lifecycle node
    ldlidar_node = LifecycleNode(
        package='ldlidar_node',
        executable='ldlidar_node',
        name=node_name,
        namespace='',
        output='screen',
        parameters=[
            # YAML files
            lidar_config_path  # Parameters
        ],
        remappings=[('/ld_scan', '/scan')]
    )

    # URDF path
    urdf_file_name = 'ldlidar_descr.urdf.xml'
    urdf = os.path.join(
        get_package_share_directory('ldlidar_node'),
        'urdf',
        urdf_file_name)
    with open(urdf, 'r') as infp:
        robot_desc = infp.read()

    # Robot State Publisher node
    rsp_node = Node(
        package='robot_state_publisher',
        executable='robot_state_publisher',
        name='ldlidar_state_publisher',
        output='screen',
        parameters=[{'robot_description': robot_desc}],
        arguments=[urdf]
    )

    # Define LaunchDescription variable
    ld = LaunchDescription()

    # Launch arguments
    ld.add_action(declare_node_name_cmd)

    # Launch Nav2 Lifecycle Manager
    ld.add_action(rsp_node)

    # LDLidar Lifecycle node
    ld.add_action(ldlidar_node)

    return ld

Hi @Myzhar,

Just curious if it's possible to integrate this node with hector_slam? They are still on ROS1 (and I'm not really sure if they'd migrate in the nearest future). I guess there's a difference between topics/frames used by ldlidar for publishing and what hector_slam expects while subscribing. Do you have any thoughts regarding the common steps required for such integration? Note that it seems like hector_slam can work w/o odometry, just by using lidar data.

Thanks,
Sergey

In this part of the install tutorial, the path shouldn't include the /src at the end. The next command in the tutorial assumes you're in ros2_ws not ros_ws/src

Build the packages:

cd ~/ros2_ws/src/

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.

To Reproduce
Steps to reproduce the behavior:

1. Run this repo's driver on ROS2 Humble
2. 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)
3. the LD19's laserscan topic will provide a solid 10Hz output (USB or serial UART doesn't affect this problem)
4. 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.
5. 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

Scans coming in at 10Hz
Screencast from 08-18-2023 12:00:52 PM.webm

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.
SteveMacenski/slam_toolbox#293 (comment)
SteveMacenski/slam_toolbox#430 (comment)
SteveMacenski/slam_toolbox#141 (comment)
SteveMacenski/slam_toolbox#426 (comment)
SteveMacenski/slam_toolbox#328 (comment)
SteveMacenski/slam_toolbox#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

Hello
I'm new to the ROS2 system. I would like to ask a question. I recently purchased the LIDAR LD19. I managed to configure it and it is working OK, presenting the data in the RVIZ (LaserScan).

My question is: I would like to make a SLAM process and for that I am using the slam_toolbox framework. I configured the slam_toolbox following a tutorial and apparently managed to subscribe to the /ldlidar_node/scan topic. I opened the RVIZ2, activated the map. I added the map topic, however I can't generate the map (SLAM) at all. The funny thing is that apparently ldlidar_node is being processed by slam_toolbox (you can see it in the terminal). But the map is not generated.

Could you let me know if the LD-19 Lidar is compatible with the ROS2 slam_toolbox? Is there any other framework, compatible, that I could generate the SLAM?

Thanks.

Describe the bug
Installed ROS2 following
https://docs.ros.org/en/humble/Installation/Ubuntu-Install-Debians.html
(Desktop install)

Then following https://github.com/Myzhar/ldrobot-lidar-ros2#install-the-node

Getting error on command
colcon build --symlink-install --cmake-args=-DCMAKE_BUILD_TYPE=Release

root@ROS:/opt/ros/humble# colcon build --symlink-install --cmake-args=-DCMAKE_BUILD_TYPE=Release
Starting >>> ament_package
Starting >>> ament_lint                       
Starting >>> gtest_vendor
Starting >>> gtest                                                                
[7.607s] WARNING:colcon.colcon_ros.task.ament_python.build:Package 'ament_package' doesn't explicitly install a marker in the package index (colcon-ros currently does it implicitly but that fallback will be removed in the future)
[7.608s] WARNING:colcon.colcon_ros.task.ament_python.build:Package 'ament_package' doesn't explicitly install the 'package.xml' file (colcon-ros currently does it implicitly but that fallback will be removed in the future)
[7.650s] WARNING:colcon.colcon_ros.task.ament_python.build:Package 'ament_lint' doesn't explicitly install a marker in the package index (colcon-ros currently does it implicitly but that fallback will be removed in the future)
[7.651s] WARNING:colcon.colcon_ros.task.ament_python.build:Package 'ament_lint' doesn't explicitly install the 'package.xml' file (colcon-ros currently does it implicitly but that fallback will be removed in the future)
--- stderr: gtest_vendor
CMake Error: The source directory "/opt/ros/humble/share/gtest_vendor" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/colcon_core/executor/__init__.py", line 91, in __call__
    rc = await self.task(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/colcon_core/task/__init__.py", line 93, in __call__
    return await task_method(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/colcon_ros/task/cmake/build.py", line 34, in build
    rc = await extension.build(
  File "/usr/lib/python3/dist-packages/colcon_cmake/task/cmake/build.py", line 87, in build
    rc = await self._reconfigure(args, env)
  File "/usr/lib/python3/dist-packages/colcon_cmake/task/cmake/build.py", line 182, in _reconfigure
    buildfile = get_buildfile(cmake_cache)
  File "/usr/lib/python3/dist-packages/colcon_cmake/task/cmake/__init__.py", line 114, in get_buildfile
    if 'Visual Studio' in generator:
TypeError: argument of type 'NoneType' is not iterable
---
Failed   <<< gtest_vendor [0.21s, exited with code 1]
Aborted  <<< ament_package [0.34s]
Aborted  <<< ament_lint [0.28s]
Aborted  <<< gtest [0.25s]                             

Summary: 0 packages finished [7.17s]
  1 package failed: gtest_vendor
  3 packages aborted: ament_lint ament_package gtest
  1 package had stderr output: gtest_vendor
  277 packages not processed
argument of type 'NoneType' is not iterable

Desktop (please complete the following information):

• OS: Ubuntu 22.04
• ROS2 version: Humble desktop
• Device type: VirtualBox

On Nvidia Orin Nano, ldlidar node uses 100% of one core. This seems high for me since it's just parsing out serial input and publishing. Comparatively, nav2 uses less. Is there any way to reduce it? Lower publish rate or something? Maybe we should try to use static memory or maybe some external library like CUDA or something to speed it up?

• OS: Ubuntu 22.04
• ROS2 version: humble (nvidia docker image)
• Jetson Orin Nano

I'm just using the stock launch file and parameters.

Describe the bug
I was trying to get into ROS2 for a bit and had an LDLidar LD19 lying around, trying to make it work in ROS2 Iron.
I chose Iron as that was what the website suggested to use, as other versions are officially marked as EOL.

On compiling I got the following error:

ubuntu@raspi-ROS2:~/ros2_ws$ colcon build --symlink-install --cmake-args=-DCMAKE_BUILD_TYPE=Release

Starting >>> ldlidar_component
--- stderr: ldlidar_component
CMake Error at CMakeLists.txt:71 (message):
  ROS2 iron is not officially supported by this package.  Correct working is
  not guarantee.


---
Failed   <<< ldlidar_component [2.66s, exited with code 1]

Summary: 0 packages finished [4.14s]
  1 package failed: ldlidar_component
  1 package had stderr output: ldlidar_component
  2 packages not processed

Desktop (please complete the following information):

• OS: Ubuntu
• ROS2 version: Iron
• Device type: Rpi3B+

Is there a workaround method to get the code to compile anyway? Afaik the data coming out of the Lidar is a stream of bytes being piped in through a USB/TTY interface.

Hi @Myzhar,

I want to use this code with LD06 lidar. Tried to follow the instructions from README but had initially failed to locate ZED (googled it and installed the latest ZED SDK). Now I'm failing to locate zed_interfaces:

Starting >>> zed_components
--- stderr: zed_components                         
CMake Warning at CMakeLists.txt:69 (find_package):
  By not providing "Findzed_interfaces.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "zed_interfaces", but CMake did not find one.

  Could not find a package configuration file provided by "zed_interfaces"
  with any of the following names:

    zed_interfacesConfig.cmake
    zed_interfaces-config.cmake

  Add the installation prefix of "zed_interfaces" to CMAKE_PREFIX_PATH or set
  "zed_interfaces_DIR" to a directory containing one of the above files.  If
  "zed_interfaces" provides a separate development package or SDK, be sure it
  has been installed.


CMake Error at /opt/ros/foxy/share/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake:77 (message):
  ament_target_dependencies() the passed package name 'zed_interfaces' was
  not found before
Call Stack (most recent call first):
  CMakeLists.txt:143 (ament_target_dependencies)

I'm a bit confused here. Could you please elaborate, why do we need ZED to control LiDAR? And if it's a must-have framework / set of libs, what else I'm missing here? As there are no requirements in README that mention ZED.

P.S. I'm on Ubuntu 20, ROS2 foxy. And failure occurs on the following step:

colcon build --symlink-install --cmake-args=-DCMAKE_BUILD_TYPE=Release

Thanks,
Sergey