tf namespace resolution
In my tf tree, I accidentally forgot the root forward slash in a single link inside the tree. For example, in the tree in the view_frames output here, the following link:
/map -> /ens1/map
was accidentally being transmitted by a python node as:
map -> ens1/map
Now, view_frames clearly ignored this error and formed up everything as a single tree (a full tree was formed - as shown in image above). Similarly tf_echo successfully produced the following transformation:
rosrun tf tf_echo /segbot1/base_footprint /segbot1/ens1/map
Output:
At time 459.605
- Translation: [-5.000, -5.000, 0.001]
- Rotation: in Quaternion [0.000, 0.000, -0.000, 1.000]
in RPY [0.000, 0.000, -0.000]
At time 460.600
- Translation: [-5.000, -5.000, 0.001]
- Rotation: in Quaternion [0.000, 0.000, -0.000, 1.000]
in RPY [0.000, 0.000, -0.000]
However the navigation stack kept complaining (correctly?) about there being 2 separate trees:
Waiting on transform from /segbot1/base_footprint to /segbot1/ens1/map to become available before running costmap, tf error: Could not find a connection between '/segbot1/ens1/map' and '/segbot1/base_footprint' because they are not part of the same tree.Tf has two or more unconnected trees.
After (quite) a bit of debugging, I found that the tf information was being interpreted as 2 different trees by the move_base node (i.e. Costmap2DRos) in the navigation stack, but as a single tree by view_frames and tf_echo. Although the error has been fixed:
- Did this happen because because the move_base node was launched in the /segbot1 namespace and/or /segbot1/tf_prefix was set. The TransformListener applied standard name resolution rules and resolved the tf link as /segbot1/map -> /segbot1/ens1/map
- If 1 did indeed happen, does it make sense for the TransformListener to do this sort of name resolution, as essentially nodes in different namespace see different trees.