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

edit

Some related Q&As first:

• #q270403 (what is tf)
• #q10285 (How does tf do interpolation?)
• #q210572 (what is a frame?)
• #q272400 (what does the word "transform" mean in tf?)

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)