Ask Your Question

Tf tree for multiple turtlebots

asked 2021-10-06 04:12:44 -0500

Roshan gravatar image

updated 2021-10-10 08:09:59 -0500

Mike Scheutzow gravatar image

Hello, I am trying to run two turtlebots in a gazebo simulation. I'm wondering about the tf tree for the robots. This is what I get: image description

Sometimes if I refresh this I get: image description

so the wheel_right_link and wheel_left_link switch between tb3_0/robot_state_publisher and tb3_1/robot_state_publisher.

The launch file I am using is an edited version of the gazebo_simulations file found here:

When running the unedited version you get the same tf tree, just that it the wheel links switch between tb3_0/robot_state_publisher, tb3_1/robot_state_publisher and tb3_2/robot_state_publisher. Here is the tf tree for the unedited launch file:

image description

This is the launch file I'm using:

  <arg name="model" default="$(env TURTLEBOT3_MODEL)" doc="model type [burger, waffle, waffle_pi]"/>
  <arg name="first_tb3"  default="tb3_0"/>
  <arg name="second_tb3" default="tb3_1"/>

  <arg name="first_tb3_x_pos" default="0.0"/>
  <arg name="first_tb3_y_pos" default="1.0"/>
  <arg name="first_tb3_z_pos" default=" 0.0"/>
  <arg name="first_tb3_yaw"   default=" 1.57"/>

  <arg name="second_tb3_x_pos" default=" 0.0"/>
  <arg name="second_tb3_y_pos" default="0.0"/>
  <arg name="second_tb3_z_pos" default=" 0.0"/>
  <arg name="second_tb3_yaw"   default=" 1.57"/>

  <include file="$(find gazebo_ros)/launch/empty_world.launch">
    <arg name="world_name" value="$(find turtlebot3_gazebo)/worlds/"/>
    <arg name="paused" value="false"/>
    <arg name="use_sim_time" value="true"/>
    <arg name="gui" value="true"/>
    <arg name="headless" value="false"/>
    <arg name="debug" value="false"/>

    <!-- Start marker detector--> 
  <node name="aruco_detect" pkg="aruco_detect" type="aruco_detect">
    <param name="image_transport" value="compressed" />
    <param name="publish_images" value="true" />
    <param name="fiducial_len" value="0.15" />
    <param name="dictionary" value="0" />
    <param name="do_pose_estimation" value="true" />
    <param name="ignore_fiducials" value="" />
    <param name="fiducial_len_override" value="" />
    <remap from="/camera/compressed" to="/tb3_1/camera/rgb/image_raw/compressed"/>
    <remap from="/camera_info" to="/tb3_1/camera/rgb/camera_info"/>

  <group ns = "$(arg first_tb3)">
    <param name="robot_description" command="$(find xacro)/xacro --inorder $(find turtlebot3_description)/urdf/turtlebot3_$(arg model).urdf.xacro" />

    <node pkg="robot_state_publisher" type="robot_state_publisher" name="robot_state_publisher" output="screen">
      <param name="publish_frequency" type="double" value="50.0" />
      <param name="tf_prefix" value="$(arg first_tb3)" />

    <node name="spawn_urdf" pkg="gazebo_ros" type="spawn_model" args="-urdf -model $(arg first_tb3) -x $(arg first_tb3_x_pos) -y $(arg first_tb3_y_pos) -z $(arg first_tb3_z_pos) -Y $(arg first_tb3_yaw) -param robot_description" />

  <group ns = "$(arg second_tb3)">
    <param name="robot_description" command="$(find xacro)/xacro --inorder $(find turtlebot3_description)/urdf/turtlebot3_$(arg model).urdf.xacro" />

    <node pkg="robot_state_publisher" type="robot_state_publisher" name="robot_state_publisher" output="screen">
      <param name="publish_frequency" type="double" value="50.0" />
      <param name="tf_prefix" value="$(arg second_tb3)" />

    <node name="spawn_urdf" pkg="gazebo_ros" type="spawn_model" args="-urdf -model $(arg second_tb3) -x $(arg second_tb3_x_pos) -y $(arg second_tb3_y_pos) -z $(arg second_tb3_z_pos) -Y $(arg second_tb3_yaw) -param robot_description" />


and this is my world file:

<sdf version='1.6'>
  <world name='default'>
    <!-- A global light source -->
    <include> ...
edit retag flag offensive close merge delete


The launch file looks correct. You've removed references to the 3rd turtlebot and added the aruco detector. My best guess now is that you're launching using an alternative version of the file from the one you're editing or something like that. If you know the original file works. Start with that and incrementally make changes until it stops working to isolate the problem.

tfoote gravatar image tfoote  ( 2021-10-06 05:16:06 -0500 )edit

Does the tf tree look correct for the unedited file? The thing that has me a little worried is if the file I'm working off is also not doing things correctly, and especially the wheel links switching between the different tb3s has me worried. But I will incrementally add changes and see what causes the issue as you said.


I have been making gradual changes to the launch file. I started with the original and worked my way from there. If I use an empty world file I get the warnings, but if I use the turtlebot3_house file I don't get the warnings. In addition, removing the

   <!-- A turtlebot symbol -->

from the house file also gives the warnings. It seems that this model has to be in the world file or else you start getting warnings. More details in ...(more)

Roshan gravatar image Roshan  ( 2021-10-06 05:19:05 -0500 )edit

Related discussions in #360480 seem to suggest that Noetic no longer supports tf_prefix (but since I haven't worked with Noetic much I can't verify). This would not explain why the one world file you mentioned does not give the warning... but would explain why, in most cases, the transforms from each robot are getting published to the same tf frame name.

but as a sanity check, you could consider the somewhat tedious task of either adding a prefix argument to each joint name field in the turtlebot's xacro file (e.g. <joint name="$(arg prefix)*original_joint_name*" .... This would guarantee that the URDF passed to each robot_state_publisher have non-conflicting frame names and should avoid the clashing you're experiencing

shonigmann gravatar image shonigmann  ( 2021-10-06 13:10:31 -0500 )edit

Thank you for your answer, but it seems that the tf_prefix was recently added according to this: So I can understand that the person in the related discussion would have a problem, but it does not explain why the problem is still occurring. But does the tf tree look reasonable to you?

Roshan gravatar image Roshan  ( 2021-10-06 13:20:45 -0500 )edit

As it was just merged 6 days ago, can you confirm that you are indeed using a version of robot_state_publisher that includes the fix (>=1.15.2)?

shonigmann gravatar image shonigmann  ( 2021-10-06 13:25:44 -0500 )edit

Of course, excuse me for sounding like a noob but how would I do that?

Edit: Went into the package.xml of the robot_state_publisher package. It's:

Roshan gravatar image Roshan  ( 2021-10-06 13:26:53 -0500 )edit

Assuming you're using ubuntu and you've installed robot_state_publisher using apt, then you can type apt list ros-noetic-robot-state-publisher in your terminal and it should tell you the version installed. sudo apt update && sudo apt upgrade should bring it up to date with the latest version, which indeed looks like 1.15.2

If you've built robot_state_publisher from source, then running git rev-parse --short HEAD in the package folder would tell you what commit you're currently using, but the simpler approach would be to just make sure you have the noetic-devel branch checked out and git pull

shonigmann gravatar image shonigmann  ( 2021-10-06 13:53:06 -0500 )edit

I did sudo apt update && sudo apt upgrade, but when I do apt list ros-noetic-robot-state-publisher, I get:

apt list ros-noetic-robot-state-publisher
Listing... Done
ros-noetic-robot-state-publisher/focal,now 1.15.0-1focal.20210922.194208 amd64 [installed,automatic]

Meaning that it did not update?

Roshan gravatar image Roshan  ( 2021-10-06 14:11:01 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2021-10-06 15:27:46 -0500

shonigmann gravatar image

For a while, ROS Noetic did not support the tf_prefix parameter so the respective robot_state_publisher nodes are publishing data to the same frame names. PR 169 has added this functionality to Noetic, but, as of writing this question, has not made it into the debian release. You can install the latest source code version of this package with the following:

cd ~/my_workspace/src
git clone -b noetic-devel
cd ~/my_workspace
source devel/setup.bash

Which should resolve the issue until the binary of version 1.15.2 is released

edit flag offensive delete link more



just to make it extra clear:

Which should resolve the issue until the binary of version 1.15.2 is released

Switching back to the released binary version on his system is now the responsibility of @Roshan. This is not done automatically.

If you don't switch back, your version of robot_state_publisher will be "frozen" at whatever commit it was when you git cloned the repository and will never be updated (unless you take action yourself that is).

gvdhoorn gravatar image gvdhoorn  ( 2021-10-07 02:48:00 -0500 )edit

It seems the issue wasn't completely resolved, as when I tested today I started getting the warnings:

Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_footprint at time 284,759000 according to authority /gazebo
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp

But I think the problem here is that there is only one odom topic in the tf tree and it's not connected to any of the robots. It is on its own and connected to base_footprint. This warning did not happen when I tested yesterday, despite the tf tree looking the same as it did yesterday.

The new tf tree will be shown in the original post.

Could this be because I did

cd ~/my_workspace/src
git clone -b noetic-devel

and that there are other directories that might need to have the updated robot_state_publisher too?

Roshan gravatar image Roshan  ( 2021-10-07 03:01:49 -0500 )edit

Two potential thoughts come to mind:

1) you didn't get the issue yesterday because you appropriately sourced the workspace where the source version of robot_state_publisher was written. If you tried again in a new terminal without first running source ~/my_workspace/devel/setup.bash, then the binary install of robot_state_publisher is being used instead. Or maybe

2) I'm not sure if the gazebo diff_drive_controller plugin actually respects the ros namespace / tf prefix you set, so it could be that you would need to modify the plugin parameters for each turtlebot. I've had similar issues with plugins in ROS2, but can't say i've dog too far into it with ROS1

shonigmann gravatar image shonigmann  ( 2021-10-07 11:53:06 -0500 )edit

I think the sourcing is done correctly. I cd into the workspace, do source devel/setup.bash and launch the project through roslaunch. And then I open a new terminal, do source devel/setup.bash and launch rqt, and then get errors.

Not sure how I would do the 2nd option, but do you think the issue will be fixed in the next sync? Or maybe I'll have to go to Melodic instead.

Edit: Sometimes it works, sometimes it does not.

Roshan gravatar image Roshan  ( 2021-10-07 13:08:31 -0500 )edit

because this thread is getting a bit messy, I'd suggest opening a new question for this particular issue. I believe this is because the gazebo_ros_plugins are run by gazebo server and have no notion of the robot namespace specified in your launch file, unless you explicitly add robotNamespace to the part of the URDF that starts the plugin (e.g. in here). Even if you do that, I'm not sure that the plugin will respond correctly. I can't see much in the source code that points to the plugin considering that tf_prefix or robotNamespace.... This is getting out of my area of knowledge though, so probably best starting a new question to prompt help from others

shonigmann gravatar image shonigmann  ( 2021-10-07 16:08:22 -0500 )edit

New question has been opened:

Roshan gravatar image Roshan  ( 2021-10-07 17:00:41 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2021-10-06 04:12:44 -0500

Seen: 125 times

Last updated: Oct 07 '21