Lidar process dying in ros2

[sardanian]

I am running this command after installing everything:
ros2 launch rplidar_ros view_rplidar_a1_launch.py

but this is my output.

[INFO] [launch]: All log files can be found below /home/pariah/.ros/log/2023-10-07-10-19-30-269248-arigato-166787
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [rplidar_node-1]: process started with pid [166788]
[INFO] [rviz2-2]: process started with pid [166790]
[rplidar_node-1] [INFO] [1696695570.347868138] [rplidar_node]: RPLidar running on ROS2 package rplidar_ros. RPLIDAR SDK Version:2.0.0
[rviz2-2] [INFO] [1696695570.762169630] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-2] [INFO] [1696695570.762270111] [rviz2]: OpenGl version: 4.6 (GLSL 4.6)
[rviz2-2] [INFO] [1696695570.850297554] [rviz2]: Stereo is NOT SUPPORTED
[rplidar_node-1] [ERROR] [1696695574.411850622] [rplidar_node]: Error, operation time out. SL_RESULT_OPERATION_TIMEOUT! 
[ERROR] [rplidar_node-1]: process has died [pid 166788, exit code 255, cmd '/home/user/Applications/lidar_temp/install/rplidar_ros/lib/rplidar_ros/rplidar_node --ros-args -r __node:=rplidar_node --params-file /tmp/launch_params_s66gn50h'].

and this is my rviz screen.

I am trying to test the lidar to see if it is working. I had been trying it on the Create 3, but it would not work. So I am trying to just get the lidar working and it seems to not be functioning properly or I have some sort of misconfiguration.

I am running this on my a raspberry PI and my PC.

[grwells]

I have also been working on a Create3 + RPi SLAM project and also experienced my rplidar node dying after a SL_RESULT_OPERATION_TIMEOUT error.

I haven't found any good explanations here or in the Create3 examples repo issues, but I was able to get mine up and running by fiddling with the parameters passed to the node. I realized that after the node crashes, it prints a debug statement like the one below:

[ERROR] [rplidar_composition-2]: process has died [pid 138426, exit code 255, cmd '/opt/ros/humble/lib/rplidar_ros/rplidar_composition --ros-args -r __node:=rplidar_composition -r __ns:=/ --params-file /home/winterrain/Documents/U_of_I/Robotics/create3_examples_ws/install/create3_lidar_slam/share/create3_lidar_slam/config/rplidar_node.yaml'].

In my case, the parameter renaming the node with -r __node:=rplidar_composition was somehow causing the issue. Running the command from the debug statement while renaming the node to rplidar_node allowed it to run without crashing immediately.

Even though I don't have a solid answer I hope that maybe adjusting the launch params could fix your problem. None of the issues in this repo have been replied to in about a year so it is definitely a blind leading the blind scenario.

[sardanian]

Interesting solution How do you run the command from the debug statement? Also, it seems my command is already calling the node rplidar_node. What I did do as a temporary test is I got an A2m12 lidar and it works. So I know its not my setup.

…

On Mon, Oct 9, 2023 at 12:22 PM Garrett Wells ***@***.***> wrote: I have also been working on a Create3 + RPi SLAM project and also experienced my rplidar node dying after a SL_RESULT_OPERATION_TIMEOUT error. I haven't found any good explanations here or in the Create3 examples repo issues, but I was able to get mine up and running by fiddling with the parameters passed to the node. I realized that after the node crashes, it prints a debug statement like the one below: [ERROR] [rplidar_composition-2]: process has died [pid 138426, exit code 255, cmd '/opt/ros/humble/lib/rplidar_ros/rplidar_composition --ros-args -r __node:=rplidar_composition -r __ns:=/ --params-file /home/winterrain/Documents/U_of_I/Robotics/create3_examples_ws/install/create3_lidar_slam/share/create3_lidar_slam/config/rplidar_node.yaml']. In my case, the parameter renaming the node with -r __node:=rplidar_composition was somehow causing the issue. Running the command from the debug statement while renaming the node to rplidar_node allowed it to run without crashing immediately. Even though I don't have a solid answer I hope you can get some mileage out of my hack around it style solution. None of the issues in this repo have been replied to in about a year so it is definitely a blind leading the blind scenario. — Reply to this email directly, view it on GitHub <#138 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMDPYDT2Z2C53YADPZFLG3TX6Q6GDAVCNFSM6AAAAAA5XA2BSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTGQ2TOMJTGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[sardanian]

actually, when I run it in the Create3 code, I do have rplidar_composition. But I am unclear on how to run it in debug statement

…

On Tue, Oct 10, 2023 at 10:43 PM Ronnie Romman ***@***.***> wrote: Interesting solution How do you run the command from the debug statement? Also, it seems my command is already calling the node rplidar_node. What I did do as a temporary test is I got an A2m12 lidar and it works. So I know its not my setup. On Mon, Oct 9, 2023 at 12:22 PM Garrett Wells ***@***.***> wrote: > I have also been working on a Create3 + RPi SLAM project and also > experienced my rplidar node dying after a SL_RESULT_OPERATION_TIMEOUT > error. > > I haven't found any good explanations here or in the Create3 examples > repo issues, but I was able to get mine up and running by fiddling with the > parameters passed to the node. I realized that after the node crashes, it > prints a debug statement like the one below: > > [ERROR] [rplidar_composition-2]: process has died [pid 138426, exit code 255, cmd '/opt/ros/humble/lib/rplidar_ros/rplidar_composition --ros-args -r __node:=rplidar_composition -r __ns:=/ --params-file /home/winterrain/Documents/U_of_I/Robotics/create3_examples_ws/install/create3_lidar_slam/share/create3_lidar_slam/config/rplidar_node.yaml']. > > In my case, the parameter renaming the node with -r > __node:=rplidar_composition was somehow causing the issue. Running the > command from the debug statement while renaming the node to rplidar_node > allowed it to run without crashing immediately. > > Even though I don't have a solid answer I hope you can get some mileage > out of my hack around it style solution. None of the issues in this repo > have been replied to in about a year so it is definitely a blind leading > the blind scenario. > > — > Reply to this email directly, view it on GitHub > <#138 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AMDPYDT2Z2C53YADPZFLG3TX6Q6GDAVCNFSM6AAAAAA5XA2BSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTGQ2TOMJTGY> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[sardanian]

nevermind, I understand what you mean about running the command from the debug. I am able to now get it to run. But now I am getting these errors when I run:

ubuntu@ubuntu:~$ ros2 launch create3_lidar_slam slam_toolbox_launch.py
[INFO] [launch]: All log files can be found below /home/ubuntu/.ros/log/2023-10-11-06-23-39-888033-ubuntu-2551
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [async_slam_toolbox_node-1]: process started with pid [2552]
[async_slam_toolbox_node-1] [INFO] [1697005420.587037004] [slam_toolbox]: Node using stack size 40000000
[async_slam_toolbox_node-1] [INFO] [1697005421.521036568] [slam_toolbox]: Using solver plugin solver_plugins::CeresSolver
[async_slam_toolbox_node-1] [INFO] [1697005421.523307445] [slam_toolbox]: CeresSolver: Using SCHUR_JACOBI preconditioner.
[async_slam_toolbox_node-1] [INFO] [1697005421.723101108] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 1697005421.458 for reason 'discarding message because the queue is full'
[async_slam_toolbox_node-1] [INFO] [1697005421.857685413] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 1697005421.587 for reason 'discarding message because the queue is full'
[async_slam_toolbox_node-1] [INFO] [1697005421.993968437] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 1697005421.723 for reason 'discarding message because the queue is full'
[async_slam_toolbox_node-1] [INFO] [1697005422.129183623] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 1697005421.858 for reason 'discarding message because the queue is full'
[async_slam_toolbox_node-1] [INFO] [1697005422.264361865] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 1697005421.994 for reason 'discarding message because the queue is full'
[async_slam_toolbox_node-1] [INFO] [1697005422.399798955] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 1697005422.129 for reason 'discarding message because the queue is full'
[async_slam_toolbox_node-1] [INFO] [1697005422.545917438] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 1697005422.264 for reason 'discarding message because the queue is full'
[async_slam_toolbox_node-1] [INFO] [1697005422.681299752] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 1697005422.400 for reason 'discarding message because the queue is full'
[async_slam_toolbox_node-1] [INFO] [1697005422.816457364] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 1697005422.546 for reason 'discarding message because the queue is full'

[grwells]

Hmmm, interesting. None of those errors mean anything to me, unfortunately.

I emailed Slamtec support about this problem and their paraphrased suggestion was "to use the latest version". I suppose this refers to the latest hardware (a2m12) but I haven't seen any documentation suggesting that older hardware generations are not supported.

So thanks for mentioning that you got this working with an a2m12. I think I will just be buying a new unit to get around this.

[grwells]

A final note, sllidar_ros2 has more open issues with similar symptoms of failure. My conclusion is that although the support section of these projects say A2 is supported, that doesn't guarantee that RPLiDAR SDK version 2.0 supports your device's firmware.