# Is the tf 'tree' persistent in any way or derived from the flow of tf topics?

I am trying to get a level deeper in understanding tf. Yes there are tutorials but I have yet to find a good conceptual explanation, tied to the api, so I am just experimenting and reading bits and pieces from all over the place. A few questions:

• in a robot such as a turtlebot3 (but this is probably a general question) who is responsible for publishing tf topics? Is it an assumed by product of the logic that computes the odometry?

• is there actually a stored tf 'tree' or is it derived from the passing flow of tf topic publications?

(Sorry of these are dumb questions, I am still learning.)

edit retag close merge delete

Sort by » oldest newest most voted

Some related Q&As first:

And a link to the design sketch of tf2 and the tf: The transform library paper.

As to your questions:

• in a robot such as a turtlebot3 (but this is probably a general question) who is responsible for publishing tf topics? Is it an assumed by product of the logic that computes the odometry?

I'm not entirely familiar with the TB3 specifically, but in general for a mobile robot there can be a nr of publishers of TF frames. How many and what frames they publish depends on the specific setup.

Note that "tf publishers" are typically called broadcasters, but it's essentially the same thing.

An odometry publisher may also publish an odom frame, but it could also publish just a nav_msgs/Odometry message and leave the TF frame for some other node to publish. An example of such a node could be robot_localization, but it could really be any node.

Many of the other frames (those that make up the kinematic structure of the robot itself) are typically published by either the robot_state_publisher (based on the urdf and the sensor_msgs/JointState messages) and/or (a) custom node(s) when there are transforms that cannot be easily calculated based on the FK that the robot_state_publisher does (kinematic structures with cycles in them fi).

A third example of TF publishers would be external localisation or tracking systems. Those would include motion capture or optical trackers. They could publish transforms from anything to anything, but generally provide a pose of the tracked object (ie: marker) relative to the coordinate system origin of the tracking system.

All of this feeds the "tf system".

is there actually a stored tf 'tree' or is it derived from the passing flow of tf topic publications?

The answer to this would actually be: "yes". I know you phrased this as an or-question, but there is a tree and it's stored. It just happens to be stored in each-and-every TF client (ie: listener) and it's based on whatever TF messages that particular client has received.

So it's perfectly possible for instance for two clients to have a different (incomplete) view of the same TF tree: it just means that one client has received broadcasts that the other hasn't. Or hasn't yet.

This would also be the cause of those "annoying" and "mysterious" lookup errors, and we have three categories (note: all of the "before" and "after" are local to the specific client/listener):

1. straight errors: client just hasn't seen transform at all yet
2. interpolation into the past: client has seen it, but you're asking for the transform at a timepoint before the first message was received
3. interpolation into the future: client has seen it, but you're asking for the transform at a timepoint after the last message was received

As ...

more

fantastic answers, thanks! I wonder if there is documentation that explains this that I overlooked? I have looked at all the doc and books I can find and did not have this good an explanation!

( 2019-06-25 07:46:54 -0500 )edit

I guess the assumption is that TF implements such a commonly used concept from robotics (ie: coordinate systems and transformations between those with a temporal dimension) that truly extensive documentation would not be needed. In the end it's all linear algebra hidden behind a bunch of methods on classes.

( 2019-06-25 07:54:21 -0500 )edit

Yes, linear algebra is just additions and multiplications, so that's not so important either. And after all the tf library is just a bunch of classes and objects, so that doesn't need any either. Really?

( 2019-06-25 09:09:37 -0500 )edit

Nowhere in my comment did I judge anyone for wanting more documentation or explanation. Nowhere in my comment did I excuse the lack of documentation by claiming that it is not needed.

You seem to have taken this personal.

I merely suggested a possible rationale for why the current state of things is as it is.

Your question ("is there documentation that explains this that I overlooked?") seemed to focus on the conceptual aspects of TF. That is what I was referring to.

( 2019-06-25 09:12:13 -0500 )edit

Yes, sorry, I was a little rude. And you've always been super helpful on this forum so I apologize. I do think your and @peteblackerthe3d together would form a great document or FAQ on tf that at least I would have found super clarifying.

( 2019-06-25 09:35:10 -0500 )edit

To answer your first question, no single node is ever expected to be the sole publisher of tf messages. Instead each node which either senses or calculates a particular tf transform would be expected to publish it.

For example if you had a revolute arm in a workcell with a depth camera on the end of the arm being used to identify the location of objects. In this case a node using the robots URDF file would listen to the joint take topic and calculate the relationships between each link of the arm. The end effector mounted camera would also be part of the URDF so it's location relative to the base link of the robot is also defined. Next you would use a static transform publisher to define the position of the arm base link in the world frame of the workcell. Finally your object detection node would detect and publish the position of objects relative to the cameras optical frame.

In this case you have three nodes which are each publishing part of the TF tree. The combined tree can be used to find the location of the detected objects in the world frame of the workcell.

To answer your second question. No there is no internal TF tree state. Each new node that starts a TF listener starts listening to the tf and tf_static topics. It then builds up a buffer of frame relationships which it uses to resolve TF queries. So each node will only be aware of transforms which have be published since that node started.

Hope this helps clear this up for you.

more

fantastic answers, thanks! I wonder if there is documentation that explains this that I overlooked? I have looked at all the doc and books I can find and did not have this good an explanation!

( 2019-06-25 07:46:59 -0500 )edit