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

asked 2022-09-01 02:55:10 -0500

Zeckurbo
105 ●9 ●15 ●22

updated 2022-09-01 08:06:56 -0500

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?

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2022-09-02 09:25:26 -0500

Olivier Kermorgant

280 ●9 ●24 ●20 http://pagesperso.ls2n...

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.

edit flag offensive delete link

Comments

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 :/

Zeckurbo ( 2022-09-02 10:19:39 -0500 )edit

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.

Olivier Kermorgant ( 2022-09-02 11:44:19 -0500 )edit

add a comment

answered 2023-01-26 06:38:45 -0500

sherlockshome221
46 ●1 ●4 ●4

updated 2023-01-26 06:56:00 -0500

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:

A remapping is used to drop the leading / from the /tf and /tf_static topics.
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.
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.
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.

edit flag offensive delete link

add a comment

answered 2022-09-02 06:22:24 -0500

pmuthu2s

224 ●16 ●35 ●30

The way I prefer is to use both namespaces and prefix. You have /robot1/tf and /robot2/tf topics published by the robot publisher, which then could be relayed onto the /tf topic. By that way, you can just use a single RViz to visualize both the robot, provided you have a common localization that provides you with the transforms from map to robot1/odom and /map to robot2/odom.

Of course, you have to figure out a way for sending goals from RViz and also you need to take care of handling of the prefix for the odom frame and the base_link frame by either having a xacro or using 2 different URDF's.

As said early, there could be just different ways.

edit flag offensive delete link

Comments

Thank you for your answer. I just want to use libraries, like nav2 and slam toolbox, so I would like to keep everything as simple as possible, but your suggestion would make sense for a self made project.

Zeckurbo ( 2022-09-02 10:22:19 -0500 )edit

add a comment

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

3 Answers

Comments

Comments

Question Tools

Stats

Related questions

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

3 Answers

Comments

Comments

Question Tools

Stats

Related questions

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