Lidar time out error
scottcandy34 opened this issue · comments
I have an iRobot Create3 running firmware G.3.1. Using a Raspberry PI 4 B with Ubuntu Server 20.04 on 8GB SD and ros2 galactic installed (from your guides) (the desktop version). I am using Slamtec lidar A1M8 R5. I have followed the directions to download and build the packages. It all builds fine.
When trying to run the code for the first time I get errors for the port access...
[rplidar_composition-2] [INFO] [1675195758.244521824] [rplidar_node]: RPLIDAR running on ROS 2 package rplidar_ros. SDK Version: '1.12.0'
[rplidar_composition-2] [ERROR] [1675195758.244987564] [rplidar_node]: Error, cannot bind to the specified serial port '/dev/ttyUSB0'.
I give access by sudo chmod 777 /dev/ttyUSB0 or 666. After I have fixed the first error I get this error every time I try to run it.
[rplidar_composition-2] [ERROR] [1675256952.394627028] [rplidar_node]: Error, operation time out. RESULT_OPERATION_TIMEOUT!
This is where I'm stuck now. I have tried reboots and leaving it off for a while. I have tried all 4 ports. I have tried redownloading the packages and building it again. I have tried a different baud rate, which is pointless since it was correct for the device I'm using. I have switched the USB cable to the lidar even. I have even tried Slamtec example to run the lidar which I get the same error.
ros2 run rplidar_ros rplidar_composition --ros-args -p serial_port:=/dev/ttyUSB0 -p serial_baudrate:=115200
I have only gotten it to work once when I switched the USB controller board. And I get
[INFO] [launch]: All log files can be found below /home/ubuntu/.ros/log/2023-01-27-19-57-33-073544-ubuntu-1391
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [static_transform_publisher-1]: process started with pid [1393]
[INFO] [rplidar_composition-2]: process started with pid [1395]
[rplidar_composition-2] [INFO] [1674849453.708146769] [rplidar_node]: RPLIDAR running on ROS 2 package rplidar_ros. SDK Version: '1.12.0'
[static_transform_publisher-1] [INFO] [1674849453.710432322] [static_transform_publisher_7VwpYAbc65MxPrhg]: Spinning until killed publishing transform from 'base_footprint' to 'laser_frame'
[rplidar_composition-2] [INFO] [1674849456.224702197] [rplidar_node]: RPLIDAR S/N: FB939DF1C3E39AC4C3E698F90B44340D
[rplidar_composition-2] [INFO] [1674849456.224960787] [rplidar_node]: Firmware Ver: 1.25
[rplidar_composition-2] [INFO] [1674849456.225071527] [rplidar_node]: Hardware Rev: 5
[rplidar_composition-2] [INFO] [1674849456.226865788] [rplidar_node]: RPLidar health status : '0'
[rplidar_composition-2] [INFO] [1674849456.227065601] [rplidar_node]: Start
[rplidar_composition-2] [INFO] [1674849456.776160315] [rplidar_node]: current scan mode: Express, max_distance: 12.0 m, Point number: 4.0K , angle_compensate: 1, flip_x_axis 0
Running the other code and starting rviz2 I was able to get it to display graphicly. But this didn't last and I got an error saying something like the que is full. After restarting the lidar server I got the same error again. This has been very long and confusing as to why its not working.
I have also tried a R6 USB board with an adapter cable and still get the same error.
The last thing I have done is on an 128GB SD installed ubuntu desktop 22.04 and ros2 humble (from your guides) (the desktop version). And installed H.0.0 firmware to the iRobot. I downloaded and built the humble version on GitHub. I added myself to the group for the USB access sudo usermod -a -G dialout $USER and still end up with the same error. I'm out of ideas at this point besides trying with an external power supply; which I don't have the tools for.
I can see you are frustrated; there is a lot to unpack, here, and we will try to help. Changing ROS 2 versions or LIDAR SKUs is not going to help you; it's just going to add more variables to the set of simultaneous equations, so let's keep things stable and try to systematically solve this problem.
The first half of this is something wrong with your LIDAR -- something that has nothing to do with the Create 3 robot or this example. When you say "switched the USB controller board," are you talking about the one that comes with your LIDAR? Looks like you root-caused your problem -- somehow, that board was bad, and it seems that data was not coming back from the LIDAR into your computer (single board or otherwise). Robotics is hard, and often things break down when systems are integrated together.
The second half of this sounds like something is wrong with your transformation tree. Get everything on Galactic, and start from a known state, fresh from boot, with a known working LIDAR assembly. Then, try the directions from https://github.com/iRobotEducation/create3_examples/tree/galactic/create3_lidar#sbc-setup . Please attach the logs from these three terminal windows, after running for ~30 seconds. Having the exact error messages will help us to help you. Please also be sure your robot is running the same middleware as your single board computer, and that its namespace and domain IDs are the default ones.
Could you also please send a picture or draw a diagram of how everything is plugged together? I'm not sure why you're referring to an external power supply. Where would that go, if you had one?
I simply changed versions to rule out the possibility that it was not something with the versions. I have thought about the USB device being bad but I tried a new one and got the same error (I'll try another with another LIDAR). A total of 3 devices interchanged so far. I even changed the PI (but for different unrelated reasons). I know at this point it is nothing to do with the create 3. Yes I left everything basic and default.
I am trying a fresh state now with 20.04 server. Will take me some time.
The setup is the same as what's in this documentation exactly. Also when I was doing some research on this problem some people said about inefficient power to the lidar can cause this issue. And some of their solutions where to use a different power source. They didn't go into exact details on how they accomplished this but I deemed it a possibility since inefficient power could cause a USB device to act strangely. But I deemed it unnecessary since this documentation demonstrates a working version.
I've been working on a similar setup and hitting similar issues.
+1 to @shamlian 's note about verifying your transforms are set up. One issue that I ran into was having my create3 running in a non-root namespace-- leave it at root until you have a good reason to put it in a namespace. When you're in this state, you will see "discarding message because the queue is full" at a very fast rate, and you won't get any output on e.g. slam_toolbox's /map topic.
Once this was resolved, I still saw the "discarding message" error from slam_toolbox, but at a slower rate (maybe a few times a second), and I started getting output on e.g. /map. When I recorded a bag file ros2 bag record -a and then replayed it with rviz running, I saw lots of transform errors associated with the laser scans, generally of the form "lookup would require extrapolation into the future," where the delta between the requested/available time was on the order of 10s of ms.
Similarly, when I had a case where the create3 and SBC had totally different timestamps due to NTP synch, I got the first case (no output, slam_toolbox spams error messages). So to me, if the transform tree is otherwise OK, it looks like this problem can arise when you have discrepancies between the odom<->base_link transform (published by create3) and the timestamps associated with the laser scans and map<-> odom transform (published by the SBC).
I had some decent success yesterday by following all of the directions here AND taking the create3 off of WiFi: in this case, the only time source available to the create3 is the NTP service provided by the SBC over its USB connection. I'm still validating this approach, per discussion here.
One other aside on the hardware-- I've had issues with the strain relief on RPLidar cables before, so making sure that all the pins in the LIDAR side of the adapter are properly seated is worth doing.
I'm confused. It sounded like you were able to get your LIDAR to communicate. There should not be a reason to swap that device. You can verify your LIDAR is working using the frame grabber in their SDK: https://github.com/Slamtec/rplidar_sdk/releases . I'd recommend doing that, just to make sure everything is working as you'd expect, without adding ROS 2 to the mix.
As far as the power supply -- if you're using the Create 3 adapter board and the setup is the same as the example, and your cables are sized for the appropriate currents, there should be more than enough headroom for things to be stable.
As far as @carlsondc-ceva 's note about time sync -- that's a good point. The SLAM solver is really sensitive to synchronized clocks.
Yes I did get the lidar to communicate after I switched USB devices (was to test if the device was bad, and the only reason I would switch the device) it worked, I got excited and then it stopped working not long after and will not work anymore.
Yes I thought the same thing before and have tried the frame grabber but I can not get that to work either, and always get Cannot bind to the specified port
I'll check out the NTP, but did not do that initially because it said its not required when the create3 and PI are connected to the Wi-Fi as well. Thanks @carlsondc-ceva
Also @carlsondc-ceva I would like to know what your setup is and what you did to get yours to work. Its highly possible that I missed something somewhere, be it small.
Thanks @shamlian for the help.
A full reinstall with 20.04 seems to of worked for now. With ros2 run rplidar_ros rplidar_composition --ros-args -p serial_port:=/dev/ttyUSB0 -p serial_baudrate:=115200 to test the connection before introducing iRobot. But I used a different lidar, I put the old one back in and it did not work. It seems as like @carlsondc-ceva mentioned bad connection I'll have to verify it on the lidar that doesn't work. This makes sense since it worked that one time and then stopped working (the socket is bad).
Now I am just having the queue is full message