Transforms and namespace usage

[carlsondc-ceva]

I noticed when I set the Create's namespace through the web UI that in addition to the sensor and odometry topics, the /tf and /tf_static outputs picked up the prefix, becoming /some_prefix/tf and /some_prefix/tf_static.

Is the expectation that when there are multiple sources of transforms (e.g. multiple robots or alternate navigation stack), it will be up to the user to combine the various publishers onto a single topic? e.g. something like topic_tools transform to add a prefix to the frame_id and child_frame_id fields and republish to the global /tf topic?

[alsora]

Hi @carlsondc-ceva, thank you for the question!

While developing the Create 3 we made the intentional choice of handling tf and ROS namespaces as you described.
There isn't yet a standard way to handle this problem in the ROS 2 community, although this seems to be the preferred approach.
See here some discussions:

• add option for setting namespace as tf_prefix automatically ros/robot_state_publisher#30
• tf2: Standardize a convention to replace the tf_prefix API ros/geometry2#32

The main driver for our decision has been that this is the same approach adopted by the navigation2 stack (see https://github.com/ros-planning/navigation2/blob/galactic/nav2_bringup/bringup/launch/tb3_simulation_launch.py#L51-L58).
If we followed a different convention, then Create 3 users wouldn't be able to use the navigation2 stack out of the box.

If users want to visualize multiple robots in the same transformations tree, I agree that the best solution is to create a new ROS 2 node that subscribes to all the namespaced tf trees and then combines them into a single one.
Unfortunately, as far as I know, there isn't a ROS 2 open-source package that does that out of the box.