slam_toolbox giving error: discarding message because the queue is full

[coolinventorr]

How are you connecting to your Create 3?

Wi-Fi (ROS 2)

Computer(s) Model(s) and Operating System(s)

Raspberry Pi 4/ ubuntu 22.04/humble/turtlebot 4 os - VirtualBox ubuntu 22.04 VM/humble

Which version of ROS 2 is installed on your computer?

Humble

Which firmware version is installed on your robot?

H.2.6

Which RMW is your robot running?

FastRTPS

Does your robot have an assigned namespace? If so, please share.

No response

Is the robot connected to a network? If so, what is the network type?

home network

Are there multiple Create 3 robots connected to your network?

None

Is multicast enabled?

None

What is the Adapter Board's USB/BLE Toggle currently switched to?

USB

Describe your question.

I have recently purchased a SLAMTEC RPLIDAR A1, and was hoping to use it with SLAM, and python. Testing the create3 examples with SLAM, I get the repeated error from slam_toolbox: [async_slam_toolbox_node-1] [INFO] [1711769129.930220100] [slam_toolbox]: Message Filter dropping message: frame 'laser_frame' at time 1711769129.807 for reason 'discarding message because the queue is full' [async_slam_toolbox_node-1] [INFO] [1711769129.942137353] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time 1711769129.929 for reason 'discarding message because the queue is full'

I tried this with the create3 examples, and with the turtlebot4 ones; same error on both.

[alsora]

This problem seems to be caused by the tf topic.

You should check whether your transformations tree is complete.
The error message shows that you have both a rplidar_link and a laser_frame frames, I'm not sure if this is expected.

Can you show how are you running slam toolbox and the lidar?

If the transformations are good, another possible cause could be that the timestamps of the robot and the Pi are not synchronized.
You can check that by comparing the timestamp field of tf messages published by the Raspberry Pi.
This scenario can be fixed by setting up an NTP server on the Pi as described here https://iroboteducation.github.io/create3_docs/setup/compute-ntp/

[alsora]

We use base_footprint rather than base_link because the latter can oscillate due to small variations in roll and pitch angles reported by the IMU and this causes some problems to slam_toolbox.

And yes, this should be somehow connected to odom.
@brianabouchard I thought that it should have been "odom" -> "base_link" -> "base_footprint" -> "laser_fram", but your picture is likely correct.
The transformation "odom" -> "base_footprint" should be available regarldess of slam_toolbox.

The lack of map is likely because slam_toolbox hasn't been able to process anything yet, so it hasn't published this frame.

I was going to do some tests on Monday on my Create 3 and report back, as I don't remember much of this out of the top of my head.

[coolinventorr]

Hmm, I tried adding the unicast xml file, and it changed some things; ubuntu@ubuntu:~$ ros2 launch create3_lidar_slam sensors_launch.py [INFO] [launch]: All log files can be found below /home/ubuntu/.ros/log/2024-03-31-18-35-53-739963-ubuntu-2946 [INFO] [launch]: Default logging verbosity is set to INFO [INFO] [static_transform_publisher-1]: process started with pid [2947] [static_transform_publisher-1] [WARN] [1711910154.410235991] []: Old-style arguments are deprecated; see --help for new-style arguments [static_transform_publisher-1] [INFO] [1711910154.476371586] [static_transform_publisher_quPva3VxsABjlTQc]: Spinning until stopped - publishing transform [static_transform_publisher-1] translation: ('-0.012000', '0.000000', '0.144000') [static_transform_publisher-1] rotation: ('0.000000', '0.000000', '0.000000', '1.000000') [static_transform_publisher-1] from 'base_footprint' to 'laser_frame' [INFO] [rplidar_composition-2]: process started with pid [2957] [rplidar_composition-2] [INFO] [1711910156.479086478] [rplidar_node]: RPLIDAR running on ROS 2 package rplidar_ros. SDK Version: '1.12.0' [rplidar_composition-2] [INFO] [1711910158.987768510] [rplidar_node]: RPLIDAR S/N: BE8CED95C4E493CBA5E69EF02F5C4B6F [rplidar_composition-2] [INFO] [1711910158.987981878] [rplidar_node]: Firmware Ver: 1.29 [rplidar_composition-2] [INFO] [1711910158.988144803] [rplidar_node]: Hardware Rev: 7 [rplidar_composition-2] [INFO] [1711910158.989809494] [rplidar_node]: RPLidar health status : '0'

It only goes up to that point now, and the LIDAR stops spinning.

As for slam toolbox, it stays pretty much the same:

ubuntu@ubuntu:~$ ros2 launch create3_lidar_slam slam_toolbox_launch.py [INFO] [launch]: All log files can be found below /home/ubuntu/.ros/log/2024-03-31-18-36-01-673638-ubuntu-2968 [INFO] [launch]: Default logging verbosity is set to INFO [INFO] [async_slam_toolbox_node-1]: process started with pid [2969] [async_slam_toolbox_node-1] [INFO] [1711910162.302568670] [slam_toolbox]: Node using stack size 40000000 [async_slam_toolbox_node-1] [INFO] [1711910162.727194520] [slam_toolbox]: Using solver plugin solver_plugins::CeresSolver [async_slam_toolbox_node-1] [INFO] [1711910162.729349021] [slam_toolbox]: CeresSolver: Using SCHUR_JACOBI preconditioner.

I also tried the custom ntp, but it didn't really work: Mar 31 17:56:01 iRobot-060EB663C12A45E7BC6AE2340FB9830F user.notice ntpd: ntpd: reply from 192.168.186.3: delay 0.006247 is too high, ignoring Mar 31 18:00:32 iRobot-060EB663C12A45E7BC6AE2340FB9830F user.notice ntpd: Script called in periodic mode Mar 31 18:06:50 iRobot-060EB663C12A45E7BC6AE2340FB9830F user.notice ntpd: ntpd: reply from 192.168.186.3: delay 0.003295 is too high, ignoring

I'm going to see if factory resetting my robot, and doing a fresh install of ubuntu could make any difference.

[coolinventorr]

Uhh, this is weird; after a clean install of ubuntu, and a factory reset, it seems to work!

[brianabouchard]

Well yay! I'm glad it is solved, but odd that there wasn't a clear reason.

[coolinventorr]

Sorry to reopen the problem, but upon running rviz again, it gives the same error, and the map doesn't show up. I'm not sure why that one time it worked.