Rviz2 not showing tf for real Turtlebot

For my ROS2 Navigation Rosject with the real Turtlebot, rviz2 is not showing all the tf for the real Turtlebot.

However, when I echo the tf topic, I get the expected base_link (wheel_right_link and wheel_left_link) and base_footprint info, so I’m not sure how rviz2 isn’t detecting it. I am using the same rviz config that works for the Gazebo sim.

I established the ros1-bridge using the following code, according to this discussion:

source ~/catkin_ws/devel/setup.bash
source /opt/ros/foxy/setup.bash
ros2 run ros1_bridge dynamic_bridge --bridge-all-topics

Screenshot 2023-08-30 171848

Then when I launch path planning, I get an error that says: " Timed out waiting for transform from base_link to map to become available, tf error: Invalid frame ID “map” passed to canTransform argument target_frame - frame does not exist".
So maybe the tf topic is just too slow, as the tf topic echoes much faster for the Gazebo sim.

Does anyone know how to fix this? Thanks


One check woudl be to see if in ROS1 those TFs are there, to discard that is something to do with a misconfiguration of the bridge?

Have you launched the map_server and the amcl nodes?

You need both running to have the transform between map->odom->base_link.

So before launching the path planning, you need to have those two nodes working properly. This means, the yellow messages in your image should not appear. You need to concentrate on solving that first, once solved, you can try the path planner.

How to solve it?

  1. Launch the map server and the localization server
  2. Use rviz to provide an initial localization
    At that point, if everything is working properly, you should not see the yellow error messages.
    If you still see those errors, then
  3. Make a plot of the tf showing all the tfs available and their connections in different branches (as explained in the course). Post it here so we can see where the problem is

Here’s the real robot tf tree with no nodes launched:

Here’s the real robot tf tree with the map_server and amcl nodes launched, and an initial localization provided in rviz:

As shown in the image from my original post, I still get the rviz tf errors when the map_server and amcl nodes are launched and an initial localization is provided.

Hi @anaam.mostafiz ,

If you substitute base_link with base_footprint in all your configuration files, your problem will be resolved. You need to make changes in amcl, planner, controller, recoveries and bt_navigator yaml files.

This should fix your problem. Let us know if you still have issues after these changes.

EDIT: Also, don’t use dynamic_bridge. Use parameter_bridge instead - this way you will bridge only the required topics like cmd_vel, scan, imu, odom, tf, tf_static, clock.


All my yaml files already had base_footprint. I tried changing them to base_link just to see what would happen, and I still get the same errors.

And I have to use dynamic_bridge. As explained in the discussion linked in my original post, parameter_bridge does not work, and dynamic_bridge is the solution.

@girishkumar.kannan @rtellez @duckfrost2 I am still stuck. I don’t even get tf to show up properly in rviz2 after establishing the ros1_bridge and launching the cartographer.

I also get this warning: [cartographer_node-1] [WARN] [1693981460.197128385] [cartographer_ros]: W0906 06:24:20.000000 6445 tf_bridge.cc:67] Lookup would require extrapolation into the past. Requested time 1693981459.655794 but the earliest data is at time 1693981459.782910, when looking up transform from frame [odom] to frame [base_footprint].

I’m really suspecting the dynamic_bridge is too slow because it bridges all topics, but I just cannot get parameter_bridge working.

Maybe there’s something wrong with my parameter_bridge files:


<?xml version="1.0"?>
    <rosparam file="/home/user/catkin_ws/src/load_params/params/topics_turtlebot.yaml" command="load"/>


topics: [{topic: /tf, type: tf2_msgs/msg/TFMessage, queue_size: 500}, {topic: /tf_static, type: tf2_msgs/msg/TFMessage, queue_size: 500}, {topic: /scan, type: sensor_msgs/msg/LaserScan, queue_size: 100}, {topic: /odom, type: nav_msgs/msg/Odometry, queue_size: 100}, {topic: /clock, type: rosgraph_msgs/msg/Clock, queue_size: 100}, {topic: cmd_vel, type: geometry_msgs/msg/Twist, queue_size: 100}] 

I understand that you can try to run the parameter_bridge without entering roslaunch load_params load_params.launch first, but that doesn’t work for me either.

For the possibility that there’s something wrong with my cartographer code, here it is:


include "map_builder.lua"
include "trajectory_builder.lua"

options = {
  map_builder = MAP_BUILDER,
  trajectory_builder = TRAJECTORY_BUILDER,
  map_frame = "map",
  tracking_frame = "base_footprint",
  published_frame = "odom",
  odom_frame = "odom",
  provide_odom_frame = false,
  publish_frame_projected_to_2d = true,
  use_odometry = true,
  use_nav_sat = false,
  use_landmarks = false,
  num_laser_scans = 1,
  num_multi_echo_laser_scans = 0,
  num_subdivisions_per_laser_scan = 1,
  num_point_clouds = 0,
  lookup_transform_timeout_sec = 0.2,
  submap_publish_period_sec = 0.3,
  pose_publish_period_sec = 5e-3,
  trajectory_publish_period_sec = 30e-3,
  rangefinder_sampling_ratio = 1.,
  odometry_sampling_ratio = 1.,
  fixed_frame_pose_sampling_ratio = 1.,
  imu_sampling_ratio = 1.,
  landmarks_sampling_ratio = 1.,

MAP_BUILDER.use_trajectory_builder_2d = true

TRAJECTORY_BUILDER_2D.min_range = 0.12
TRAJECTORY_BUILDER_2D.max_range = 3.5
TRAJECTORY_BUILDER_2D.missing_data_ray_length = 3.0
TRAJECTORY_BUILDER_2D.use_imu_data = false
TRAJECTORY_BUILDER_2D.use_online_correlative_scan_matching = true 
TRAJECTORY_BUILDER_2D.motion_filter.max_angle_radians = math.rad(0.1)

POSE_GRAPH.constraint_builder.min_score = 0.65
POSE_GRAPH.constraint_builder.global_localization_min_score = 0.7

-- POSE_GRAPH.optimize_every_n_nodes = 0

return options


import os
from launch import LaunchDescription
from ament_index_python.packages import get_package_share_directory
from launch_ros.actions import Node

def generate_launch_description():

    cartographer_config_dir = os.path.join(get_package_share_directory('project_mapping'), 'config')
    configuration_basename = 'cartographer.lua'

    return LaunchDescription([
            parameters=[{'use_sim_time': True}],
            arguments=['-configuration_directory', cartographer_config_dir,
                       '-configuration_basename', configuration_basename]),

            parameters=[{'use_sim_time': True}],
            arguments=['-resolution', '0.05', '-publish_period_sec', '1.0']

Can anyone try to replicate my errors with the real Turtlebot, please?

I used your code with the real robot in the following way (proper order):

  1. Connected to the real robot
  2. Launched the dynamic bridge. Wait here until the topics are bridged (messages shown)
  3. Launched your localization launch file
  4. Launched Rviz2 with your config file for rviz
  5. Provided an initial location

Then everything set into place. All the transforms where properly setand I could see the tfs, the particles, everything properly.

You are right that the dynamic bridge is too slow because it is bridging everything. I don’t know yet why the parameter doesn’t work. But in any case, when you have an error and you don’t know from where it is, you need to go to the basics, to remove sources of errors. So the dynamic bridge is the way in this case. Even if slow, it is the only way to make sure everything is working. So you need to wait until things are bridged.

About the Cartographer problem, I reviewed your code and found that the only two things you did not have properly to see the TFs and the map in the real robot are:

  1. In your launch file, you need to specify use_sim_time to False because now you are using the real robot, not the simulation
  2. The map display in Rviz2 must be configured as reliable and Transient Local

You can see the results here in this image which contains all the important points I mentioned above:

Let me know if that works for you

Thanks for testing my code with the real robot!

I tried the steps you listed but I’m still having the same problem. I screen-recorded it here so you can see exactly what I’m doing.

I also tried setting use_sim_time to False in the cartographer launch file, and tf started working, but then kept dropping in and out, as shown in the beginning of this screen recording. It works for like 5 seconds at a time then drops out for another 30ish seconds. My Rviz2 maps are already configured as reliable and Transient local.
In the rest of that video, I tried to see if setting use_sim_time to False in the localization launch file could get tf to start working a little too, but it couldn’t.

@rtellez any ideas as to what’s going wrong in the above videos?

Hi Anaam, I see you are getting the robot localized. I don’t understand why you have the orange warning messages about transforms in rviz, but it looks like the localization is working.

After localizing the robot with an initial location, please try the following:

  • On another terminal, launch the teleop
  • Then move the robot with the keys around the environment
  • If everything is working, the localization particles should be concentrating in a single point, indicating that the localization is taking place properly

Let me know if that works or not. If not, we may need to have a personal meeting so you can show me live.

It is true that the cloud computer is slow but even with that slowness, everything should work. Even with warning messages, it should work

@rtellez Hi Ricardo, I tried what you suggested and it seems that localization doesn’t work. Below are screenshots in chronological order showing the particles over time. As you can see, the particles spread out instead of concentrating to a single point, and the pose becomes inaccurate. Also, it takes a long time for rviz to update while I’m operating the robot.

Meanwhile, the localization particles converge in the simulation, as shown below.

Can we please have a personal meeting to discuss this?

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.

We finally discovered that the problem is in using the dynamic bridge to transfer all the topics over the internet. That is a lot of information being transferred and the system is not able to manage.

We had to go back to launching the parameter bridge indicating only the proper topics to bridge (only the ones necessary for navigation). Doing that it works.

In order to launch the parameter bridge, you need to launch the following commands:

source ~/catkin_ws/devel/setup.bash
roslaunch load_params load_params.launch
source /opt/ros/foxy/setup.bash
ros2 run ros1_bridge parameter_bridge
1 Like