I am trying to simulate a robot with a namespace using slam-toolbox but I can't get it to publish a map and I keep getting the message "[async_slam_toolbox_node-6] [INFO] [1710771843.519004315] [rover1.slam_toolbox]: Message Filter dropping message: frame 'rover1/base_link/lidar' at time 62.640 for reason 'discarding message because the queue is full'" .

Could someone help me with what am I doing wrong/missing in the setup?

I am using ROS2 Humble and Gazebo Fortress.

This is my tf-tree: enter image description here The output from ros2 topic list:


The output from ros2 node list:


How the slam-toolbox is launched (I tried to remap every topic I could think of, thinking that maybe it would solve the problem but no luck.):

    slam_toolbox_node = launch_ros.actions.Node(
        parameters=[{'use_sim_time': launch.substitutions.LaunchConfiguration('use_sim_time')}],
        remappings=[('/odom', 'odom'), 
                    ('/map_metadata', 'map_metadata'), 
                    ('/slam_toolbox/scan_visualization', 'slam_toolbox/scan_visualization'),
                    ('/slam_toolbox/graph_visualization', 'slam_toolbox/graph_visualization'), 
                    ('/tf', 'tf'), 
                    ('/tf_static', 'tf_static'), 

And finally the output of ros2 node info /rover1/slam-toolbox:

    /clock: rosgraph_msgs/msg/Clock
    /parameter_events: rcl_interfaces/msg/ParameterEvent
    /rover1/map: nav_msgs/msg/OccupancyGrid
    /rover1/scan: sensor_msgs/msg/LaserScan
    /rover1/slam_toolbox/feedback: visualization_msgs/msg/InteractiveMarkerFeedback
    /parameter_events: rcl_interfaces/msg/ParameterEvent
    /rosout: rcl_interfaces/msg/Log
    /rover1/map: nav_msgs/msg/OccupancyGrid
    /rover1/map_metadata: nav_msgs/msg/MapMetaData
    /rover1/pose: geometry_msgs/msg/PoseWithCovarianceStamped
    /rover1/slam_toolbox/graph_visualization: visualization_msgs/msg/MarkerArray
    /rover1/slam_toolbox/scan_visualization: sensor_msgs/msg/LaserScan
    /rover1/slam_toolbox/update: visualization_msgs/msg/InteractiveMarkerUpdate
    /rover1/tf: tf2_msgs/msg/TFMessage
  Service Servers:
    /rover1/slam_toolbox/clear_changes: slam_toolbox/srv/Clear
    /rover1/slam_toolbox/describe_parameters: rcl_interfaces/srv/DescribeParameters
    /rover1/slam_toolbox/deserialize_map: slam_toolbox/srv/DeserializePoseGraph
    /rover1/slam_toolbox/dynamic_map: nav_msgs/srv/GetMap
    /rover1/slam_toolbox/get_interactive_markers: visualization_msgs/srv/GetInteractiveMarkers
    /rover1/slam_toolbox/get_parameter_types: rcl_interfaces/srv/GetParameterTypes
    /rover1/slam_toolbox/get_parameters: rcl_interfaces/srv/GetParameters
    /rover1/slam_toolbox/list_parameters: rcl_interfaces/srv/ListParameters
    /rover1/slam_toolbox/manual_loop_closure: slam_toolbox/srv/LoopClosure
    /rover1/slam_toolbox/pause_new_measurements: slam_toolbox/srv/Pause
    /rover1/slam_toolbox/save_map: slam_toolbox/srv/SaveMap
    /rover1/slam_toolbox/serialize_map: slam_toolbox/srv/SerializePoseGraph
    /rover1/slam_toolbox/set_parameters: rcl_interfaces/srv/SetParameters
    /rover1/slam_toolbox/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically
    /rover1/slam_toolbox/toggle_interactive_mode: slam_toolbox/srv/ToggleInteractive
  Service Clients:

  Action Servers:

  Action Clients:

Lidar data does get published to the /rover1/scan topic.


2 Answers 2


I suppose the warning you are receiving is being generated because the lidar data is being stored but not processed, and that's why it is prompting that the queue is full.

It's been a while since I coded in ROS2 (I must return to it early on). I have seen a remapping from /odom to odom but in your tf_tree the odom frame is being called /rover1/odom. Are you sure you have remapped the typical frames such as base_link, odom, etc. to match your namespace? Also, why is your rqt publishing "default_authority" for the broadcaster of the frames?

  • $\begingroup$ Thank you for answering! The odom and the tf topics do have the frame prefix of the name of the rover for every frame. The only topic I found where the frame_id was missing was the joint_states one. Here I don't know how to transfer this information from the ignition simulation to the ros2 topic through the bridge. Do you think this might cause the problem? RViz does not seem to have a problem with it, when I move the rover with a simple teleop command the model keeps together in RViz and the frames rotate normally with the wheels. $\endgroup$
    – Veronika
    Commented Mar 22 at 10:17
  • $\begingroup$ You could check if the node from slam_toolbox is connected succesfully to the topics that it should and also make sure that it knows perfectly the namespaces you are using. RVIZ gets the information from the tf and tf_static topics, while packages normally allow a parameter to set the name of important frames such as odom, and map. $\endgroup$
    – ÁngeLoGa
    Commented Mar 29 at 18:59

I had similar errors

queue full

Because TF from various sources had different timestamps (I used real robot). So TF, odometry (which came from robot) had different (older) time stamps than lidar (from PC). Since slamtoolbox needs to match data from various sources (TF, odom, lidar) it needs to have accurate time stamps.

That's why you have queue full, it thinks the data is older (or newer) and waits for corresponding data...and queue fills up.

On my real robot I solved it by setting up chrony and syncing time.

On your simulated robot and Gazebo, search for use_sim_time variable, maybe you need to set it up for every node: using a simulation? Set use_sim_time to true for all nodes you start

Anyways, check if you have time set up properly, you can also check time with:

ros2 topic echo /scan --field header

  • $\begingroup$ Thanks for the answer! I set the use_sim_time to true for every node I launch and checked the timestamps of the scan, the tf and the odom topics: they seem to match with each other and the clock. One thing I noticed is that the tf_static is published only once, with timestamp 0. According to what I read this should not cause problems, but it might be different in this case - do you think it might help if I set up a continuous publisher for it? $\endgroup$
    – Veronika
    Commented Mar 22 at 10:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.