For standardization in ROS we have tried to standardize how information is represented inside a coordinate frame. Please see REP 103 for conventions on units and coordinate conventions. This REP includes Units, Orientation conventions, Chirality, Rotation Representations, and Covariance Representations.
Transforms are specified in the direction such that they will transform the coordinate frame "frame_id" into "child_frame_id" in tf::StampedTransform and geometry_msgs/TransformStamped. This is the same transform which will take data from "child_frame_id" into "frame_id".
All frame_ids should be resolved when created such that all stored and sent frame_ids are globally unique.
All code should reference the frame name and resolve using the tf_prefix into a frame_id Unless the code is specifically calling to full tf_prefixs possibly between robots.
Coordinate frames in ROS are identified by a string frame_id in the format /[tf_prefix/]frame_name This string has to be unique in the system. All data produced can simply identify it's frame_id to state where it is in the world. All frame_ids sent over the system should be fully resolved using the tf_prefix policy outlined below.
To support multiple "similar" robots tf uses a tf_prefix parameter. Without a tf_prefix parameter the frame name "base_link" will resolve to frame_id "/base_link".
If the tf_prefix parameter is set to "a_tf_prefix" "base_link" will resolve to "/a_tf_prefix/base_link". This is most useful when running two similar robots which otherwise would have name collisions in their frame_ids.
tf_prefix is determined by doing a searchParam, if it is not found a single '/' is prepended to the frame_name.
tf_prefix for data sources
All sources of data should apply the tf_prefix resolution to their frame_id before publishing.
tf_prefix for data processors
All nodes using frame_ids should use fully resolved frame_ids, resolving the tf_prefix from the parameter.
The only exception is nodes which are explicitly designed to work between multiple robots. In which case they should know all fully resolved frame_ids.
Multi Robot Support
tf_prefix is designed for operating multiple similar robots in the same environment. The tf_prefix parameter allows two robots to have base_link frames, for they will become /robot1/base_link and /robot2/base_link if all nodes for robot1 are run in robot1 as their tf_prefix parameter. And likewise for robot2. This means that a node running with parameter tf_prefix="robot1" can lookup "base_link" which will resolve to /robot1/base_link, but if it wants to know where robot2 is it can lookup /robot2/base_link explicitly.
Rules of thumb when developing multi robot safe software
In the single robot case everything should work with any arbitrary tf_prefix set including no tf_prefix set. To do this code should by default be configured using frame names, which are resolved immediately into frame_ids using the tf_prefix parameter.
If that robot is pushed down into a namespace with a unique tf_prefix everything should work the same.
A second copy of the robot should be able to be started in a separate namespace with a different tf_prefix and work completely independently of the first robot as though it was the only one there.
- Specific code for robot interaction can be then added to tell the two robots how to interact. A common case for this would be to point robot2 at robot1's map frame_id so they can share the same map.