Multi robot /tf with namespaces for tf or with frame_prefix? What is the right way to do it? ROS2

Question

Hello,

I want to simulate 2 turtlebots with their own slam and navigation together in the same Gazebo ROS2 Foxy simulation. For that, I want to separate them, so that they do not interfere with each other.

I stumbled across this post, but it is not clear to me, what is the best/right way.

As far as I understand, the tf (or tf2) library uses a global name server, to calculate transformations (But could be only in ROS1). When I have both robots publishing a frame with the name odom to /tf, I would expect, tf can no longer tell, which frame belongs to which robot.

I would expect the same behavior for /robot1/tf because of the global name server. So I thought, that the right way would be 1 tree with a frame prefix per robot.

But nav2 seems to use only the namespace, not the prefix. Also here they answered in the same way.

I also cant find any support for frame prefixes in most libraries, they only offer a namespace argument, so I am not sure how to remap their requests for frames.

Does anybody know, how it should be done? Maybe can even explain, how to use it in an example (e.g. Use namespace and remap for every node etc.)?

Thank you very much

EDIT: I think the name recognition is per tf node? So that if I have two /tf in separate name spaces, they will operate fine, right?

---

Originally posted by Zeckurbo on ROS Answers with karma: 105 on 2022-09-01

Post score: 2

Answer 1

My advise is to use a xacro file with a namespace or prefix argument, that is the same as the topic namespace for this robot. When using Gazebo the description file also lists the plugins to be used, that may include:

• topics to be published or subscribed, that have to be different between robots (namespaces)
• frame names to be written in some messages (e.g. imu frame), that should also be robot-specific (prefixes)

Remapping /tf to /robotX/tf is another issue, that is more about all nav stack nodes sending and receiving many useless transforms on /tf while they are only interested in the transforms that involve the one robot they navigate. To my knowledge, both ways work fine in a local multi-robot simulation. You may not want that for multiple real robots exchanging countless and useless transforms over wifi.

Prefixing the frames may be omitted when using a separate tf topic for each robot, but then you cannot display the whole fleet in e.g. RViz without some kind of complex bridge that would add prefixes on-the-fly in all messages their appear in (tf but also LaserScan or others). This may be a minor problem, or not.

Note that with Ignition Gazebo, there is no publication from the simulation to tf which is normal as tf is about estimations while the simulation is about ground truth. Ignition can publish e.g. the real pose, that you may forward to your favorite tf topic.

---

Originally posted by Olivier Kermorgant with karma: 280 on 2022-09-02

This answer was ACCEPTED on the original site

Post score: 4

---

Original comments

Comment by Zeckurbo on 2022-09-02:
My idea was, that with everything related to one robot in a namespace, I could do the same things n times and it will work every time. For me it is very frustrating, that every example is all the time without namespaces, so one robot in gazebo works out of the box but 2 robots in gazebo do not work.

I thought it would make sense, if I separate robots with namespaces, to do what I would do with only one robot, but just inside the namespace. But so far it seems to be not so easy as I had thought :/

Comment by Olivier Kermorgant on 2022-09-02:
I do agree, that it why I have a whole 4 hours lab about it.

The main difficulties people encounter in practice are not about fine-tuning the nav stack, it is more on using it on a custom (e.g. home-made) robot or fleet of robots. An intro lab on the nav stack is basically a lab on tf, parameter files, launch files and learning about the nav2_common.launch.RewrittenYaml function.

Answer 2

Multi-robot simulation in the same Gazebo environment can be successfully done without the need for tf_prefix and just using namespaces. I think what is "correct" is very dependent on what the purpose is for you to use tf_prefix. In ROS1 to ROS2 migration, the use of tf_prefix was deprecated as mentioned here. However, there was a lot of discussion thereafter because several people who were using tf_prefix had their functionalities broken. So, tf_prefix was reintroduced (Ex: See discussion here and PR here).

But the choice made in nav2 multi robot simulation follows the reasoning mentioned here and partly also due to the limitations from Gazebo plugin not namespacing the tfs as highlighted in the link shared in the OP.

For example, nav2 multi turtlebot simulation achieves the desired multi robot simulation in Gazebo purely using namespaces as follows:

1. A remapping is used to drop the leading / from the /tf and /tf_static topics.
2. This remapping will enable the application of the namespace specified to start robot_state_publisher to the tf topics of each robot. Essentially, you get /<robot_namespace>/tf and /<robot_namespace>/tf_static.
3. Then, using the RewrittenYaml launch substitution, the respective robot namespaces are added to the root level of the parameters used by navigation modules such as amcl, costmap_2d etc. In other words, this enables the creation of parameters that are scoped under the same namespace as the one's used for the robots.
4. As a result, each robot will have it's own namespaced tf, map_server, localization, controller_server and so on.

The scoped /<robot_namespace>/tf topics are basically a robot specific TF tree with a robot specific map frame. As a result, transform lookups will succeed for each robot.

To summarize, using the namespacing approach is reasonable unless there is a strong requirement to have a single TF tree that includes TFs from all robots. For example, if relative positions are needed by a higher layer to make decisions in a multi-robot use case, only those topics or messages can be consumed instead of bloating up a single TF tree. Of course this is just one way of implementation.

Hope this helps.

---

Originally posted by sherlockshome221 with karma: 46 on 2023-01-26

This answer was NOT ACCEPTED on the original site

Post score: 1