[ros-users] Design decisions behind libTF...?

[Herman Bruyninckx]

On Fri, 10 Sep 2010, Ivan Dryanovski wrote:

> I'm sorry that I'm jumping from topic to topic. This post is about a
> related issue we've had with the tf paradigm. From what I can tell, an
> important feature of the tf tree structure is that it does not allow
> over-constrained situations. This is enforced by not allowing two
> parents to publish a transform to the same child
> (http://www.ros.org/wiki/tf/FAQ#Frames_are_missing_in_my_tf_tree._Why.3F).
> In my mind this restriction is too strong. For example, if we have
> frames A, B, C, and D:
>
> a) A -> B -> C -> D
>
> and
>
> b) A -> B <- C -> D
>
> are two tf chains, neither of which expresses an over-constrained
> situation. However, only the a) chain is allowed in the current tf
> model. We have encountered two usage scenarios where model b) would
> fit our application better, and I will outline them here.
>
> SCENARIO 1.
>
> We have a UAV with an GPS sensor. A local pose estimation system tells
> us the pose of the UAV (uav_base) in some local, fixed frame, for
> example, the building (local_map). We also have a static tf telling us
> the position of the GPS sensor on the robot frame:
>
> local_map -> uav_base -> GPS
>
> Now the GPS sensor receives information about the position of the
> robot in some global world frame (global_map):
>
> global_map -> GPS.
>
> How do we chain these together, so we find the pose of the building in
> the world? Ideally, like this:
>
> local_map -> uav_base -> GPS <-global_map
>
> However, we cannot do that, so we have to invert the direction of the
> "global_map - >GPS" tf:
>
> local_map -> uav_base -> GPS -> global_map
>
> Now suppose we have a ground robot, which is localized directly on the
> global map. The resulting chain would then look like this:
>
> local_map -> uav_base -> GPS -> global_map -> ground_robot_base
>
> This looks ugly, since it doesn't follow an intuitive hierarchical
> model - ideally we want the global map being the root, and sensors
> being leafs in the tree. An alternative solution would be to take the
> "global_map - >GPS" transform, and manually compute in our code the
> required "global_map -> local_map" tf, so we can publish this:
>
> global_map -> local_map -> uav_base -> GPS
>
> This looks better, but in order to achieve this, we had to do manually
> work our way back up the tf chain, in order to massage our data so
> that tf accepts it.
>
> SCENARIO 2:
>
> We have a system which tracks makers and publishes their pose with
> respect to the camera (http://www.ros.org/wiki/ar_pose). One usage is
> to have the camera fixed in the room, and locate a moving marker:
>
> local_map -> camera_frame -> marker_frame
>
> Another usage would be to put the marker on a ground_robot, while the
> camera is mounted on a UAV. The pose of the UAV is then determined
> with respect to the ground robot:
>
> local_map -> ground_robot_base -> marker_frame -> camera_frame -> uav_frame.
>
> You notice that we had to invert two things to make the above tf chain
> work: the "camera_frame -> marker_frame" tf direction, as well as the
> "uav_frame -> camera_frame" tf. Similarly to SCENARIO 1, we are forced
> to invert transforms and end up with counter-intuitive tf chains. Not
> only that, but our program has to be told in advance (via a
> "reverse_tf" boolean parameter) which way to publish the camera-marker
> transform.
>
> ***
>
> So in conclusion, the "single parent" restriction has led us into
> situations that aren't easily handled using the current tf model.
> While we can make things work by manually inverting things or setting
> parameters, the solutions are not "clean". If someone has an idea of
> how to better fit the scenarios described about in the "single parent"
> paradigm, please, let us know.
>

Great description! Good use cases!

Possible solution: replace "parent-child" relationship with "sibling"
relationship + "direction" property.

Better solution: let's go for "graphs" and not just "trees"!

Herman