Turtlebot4 Navigation Issues (2D Pose Estimate does nothing, Issues in SLAM console)

[antebellumcerebellum]

Edit 11/13/24: This question was made in user error trying to run SLAM and Navigation2 at once. SLAM is meant to map out the area, and localization nodes are necessary for nav2 to be active.

I have been attempting to follow the navigation tutorials provided on the Turtlebot4 User Manual. However, RViz doesn't seem to work as shown: namely, the 2D Pose Estimate never resolves or produces any result. The console that produced RViz logs the starting position and orientation, but that's it.

In addition, there are a number of other INFO, ERRORS and Warnings I recieve on the SLAM console which may be of interest, such as:

[sync_slam_toolbox_node-1] [ERROR] [#timestap] [slam_toolbox]: Transform from base_link to odom failed: Lookup would require extrapolation into the past. Requested time #timestamp but he earliest data is at time #timestamp when looking up transform from frame [base_link] to frame [odom]

• sometimes past is replaced with future
• Looking up other solutions with respect to this error lead to the idea that there may be a bottleneck somewhere, but I have observed the resources of both robot and computer using htop and not found that they are overencumbered on CPU or RAM.

[sync_slam_toolbox_node-1] [WARN] [#timestap] [slam_toolbox]: Queue size has grown to: #N. Recommend stopping until message is gone if online mapping.

• This #N number continues to grow even if the robot is doing nothing.

[sync_slam_toolbox_node-1] [INFO] [#timestap] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time: #timestamp for reason 'the timestamp on the message is earlier than all the data in the transform cache'

[sync_slam_toolbox_node-1] [INFO] [#timestap] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time: #timestamp for reason 'discarding message because the queue is full'

Any suggestions for dealing with any of these issues? Of primary interest is getting 2D Pose estimate to work, but I have listed my other issues in case they share a cause or help in diagnosing the problem.

Edit (11/12/2024): After messing around and looking at the topics and how they change w.r.t to Rviz, I believe I have found at least one issue. Rviz doesn't seem to correctly publish to the /initial_pose topic. No matter how many times I apply the 2D Pose Estimate tool, the /initial_pose topic remains unpublished. I am not sure how to fix this, so advice is still appreciated.

The topic name for 2D estimate is initialpose, not initial_pose. I assume that there is a similar issue with nav2, but I can't edit it from RViz and I'm not sure how to edit it in the code.

in /opt/ros/humble/share/slam_toolbox/config under Tools: under Class: rviz_default_plugins/SetInitialPose under Topic under Value, the value is /initialpose instead of /initial_pose, which is the topic the robot produces. I assume there is something similar in Nav2 but I have not found it yet.

[hilary-luo]

@antebellumcerebellum It is not clear to me what exactly you are trying to do. You mention using slam but you also mention trying to set an initial pose. I will address these two items separately and perhaps that can either clear up some confusion or allow you to clarify to me what you are doing.

SLAM - timestamp error: When operating any ROS system it is important to make sure all computers in the system are time synced together. Generally in the context of the turtlebot4 all devices sync to the ubuntu ntp servers and therefore this is taken care of. This error can also show up with excessively bogged down networks / systems if the messages take too long to arrive. By looking more carefully at the exact time stamps you can get clues to what is causing this. You mention that you checked CPU and RAM but I would suggest that you look more closely at your network. At minimum make sure that you are using a 5 GHz WiFi network, latest software and if on humble try using discovery server to reduce traffic.

SLAM - queue size warning: By default in Humble the slam minimum travel distance is set to 0 which means that even if you stop moving it will continue to attempt to map. This is only a problem when mapping particularly large environments or if you take a very long time to map an environment. If you are running into this issue while mapping then I would suggest making a copy of the SLAM config in the turtlebot4 repo and modifying the minimum travel distance / angle to a non-zero value. Launching slam with this custom config will allow you to pause mapping by stopping the robot and allow the system to catch up.

For most use cases, SLAM should only be active when you do initial mapping of the environment and then you save your map and move on to using nav2 + localization nodes. SLAM and localization should not be active at the same time. Using SLAM does not involve manually setting an initial pose.

Localization - Set initial pose: When you are using localization you always have to set your initial pose. You mention that Rviz is publishing to /initialpose. That is the topic that I expect the system to be using and that localization consumes. The robot does not publish an initial pose while using localization.

To summarize the 3 different launch options:

1. SLAM = simultaneous localization and mapping - creates a map and keeps track of where the robot is in said map, used to create a map file to feed into localization
2. Localization - keeps track of where the robot is in a map given a map and an initial pose
3. Nav2 - can navigate the robot to a new position, requires localization from either the SLAM or Localization node

Let me know if this does not answer your question and provide a step by step of what you are doing / trying to do.

[antebellumcerebellum]

This exactly answered my question! Unfortunately, I just figured the SLAM -> local + nav2 order by myself first by about 30 minutes earlier. Still, I appreciate taking the time to write this all out clearly. I will mark in my original question the source of the user error. Thank you for your time!

[antebellumcerebellum]

Also, in response to the other notes:
SLAM - timestamp error

• I'm running network traffic over a 2.4 GHz (since that is what the Turtlebot4 tutorials recommend for simpleDDS)
• Are there any tools (command line preferred) I could use to track the networking?

SLAM - queue size warning

• Thanks for pointing this out!

[hilary-luo]

Can you point me to where the tutorials suggest 2.4 GHz? There is a limitation that the create3 can only be connected on 2.4 GHz but the recommendation is that the pi be connected on 5 GHz (the two networks must be bridged on the router). I generally recommend using discovery server so that the create3 is not connected to wifi and therefore the system only needs the 5GHz network. If there is something in the documentation that lead you to believe that the 2.4 GHz is recommended then I definitely want to fix this.

There are a couple of different options of tools depending on what you are trying to do. If you are just looking at excessive latency between the robot and the offboard computer then the ros2 topic delay cli command can be pretty useful. Do note that the accuracy of this tool is limited by how good your time sync is between the two computers. If you are trying to qualify how much bandwidth you have on a network you can use the iperf3 tool. Do note that for most accurate results you should match the protocol, in the case of ROS 2 that is UDP packets. If you are trying to dig in further to the number of packets being transmitted or what is in them etc you can use wireshark, in particular I like leveraging the I/O Graphs (under statistics) to visualize the data. If you are just wanting to monitor bandwidth on the command line then bmon is a good tool. This is a pretty broad list so which is the best tool will depend on exactly what you are trying to do.

[antebellumcerebellum]

I have a router which I split into a 5 GHz and 2 GHz ip so I could connect to both if necessary. I remembered there being an issue where I couldn't get ros2 topics to show up when connected to 5GHz but I just checked it with ros2 topic list and by passing the dock and undock actions and they worked just fine. Not sure what was going wrong originally but I'll use the 5GHz from now on.

There's nothing in the documentation per se that recommends 2.4 GHz overwhelmingly, just that simpleDiscovery is noted as the default for ROS2 and the tutorial page for simpleDiscovery is significantly shorter and less involved. On https://turtlebot.github.io/turtlebot4-user-manual/setup/networking.html under Choosing a Network Configuration it states that simpleDiscovery is better for 1-2 robots, which is my situation. Granted, it does recommend navigation on Discovery, but I didn't think I would need that much more overhead since I'm only planning on adding one custom node with intermittent traffic. Now that I have a handle on how everything works, I understand and agree the Discovery server has an overwhelming performance advantage after the hassle of setup.

finally, thanks for all the network tools. I'll check those out throughout the week.