I’ve been thinking about the lack of a convenient way to handle namespace-dependent topic names in configuration files.
Many ROS 2 frameworks (like Nav2 and MoveIt2) rely heavily on parameters to define which topics to subscribe to and which frames to use. However, there’s currently no built-in support for dynamically referencing the node’s namespace (e.g., using something like ${ns} or __ns) within the value of a parameter.
My idea is to extend the parameter parsing logic so it automatically replaces a shorthand like ${ns} with the actual namespace of the node. This would make configurations more reusable and namespace-aware without needing to manually rewrite parameter values per deployment.
I’m ready to start working on this implementation, but before doing so, I’d like to ask:
Is this a feature the community would find useful?
What should the shorthand syntax be? ${ns}, $(namespace), or something else?
@peci1 Thanks for the information. I actually didn’t know that the ros2 topic subscribe would substitute the namespace if you start the topic name with ~.
I think this is documented rather poorly. I will start adding a section to the ROS 2 docs and make a pull request, especially since it does replace the ~ with the entire node name (i.e., namespace + node_name), and if you just want the namespace, you need to use substitution with {namespace}.
But this only solves half the issue. The transform names are still an issue. But since we already have namespace shorthand for the topic, the best way to move forward would probably be to open an issue in the geometry2 package and implement it there.
Interesting, I haven’t known about the {node} and similar substitutions. Thanks for digging it out!
It is currently documented here: Topic and Service name mapping to DDS . I agree this is not the best place and an update of the normal tutorials would be beneficial.
Regarding TF prefixes, the concept you are talking about is called tf_prefix. If you google it, you’ll find a lot of references and discussions about it. It was part of ROS 1 for a long time, but later it started to get evicted from various tools because its workings were a bit more unexpected than topic namespaces and people got quickly confused.
I know Rviz2 has support for TF prefix, so it can e.g. only show a robot model composed of TFs with a common prefix. robot_state_publisher has frame_prefix parameter.
@peci1 If I remember correctly, ROS1 encouraged users to keep a common TF topic and namespace the frames themselves.
We used to follow the same approach in ROS2 for a multi-robot navigation setup. This allowed us to do convenient lookups in a single TF tree — for example, calculating distances between robots. However, we encountered more networking issues than it solved, so we decided to switch to separate TF topics (as Nav2 suggests).
That said, in non-mobile robotics setups — where the network is stable — it still makes a lot of sense to merge TF trees and namespace only the frames.
Therefore, I still feel the need for a proper way to namespace TF frames. I would suggest achieving feature parity between topic names and frame IDs, by adding substitutions and namespaces to tf_buffer and tf_broadcaster.