Revision history [back]

Looking at the tf wiki page, section static_transform_publisher, we see this:

static_transform_publisher x y z yaw pitch roll frame_id child_frame_id period_in_ms

Publish a static coordinate transform to tf using an x/y/z offset in meters and yaw/pitch/roll in radians. (yaw is rotation about Z, pitch is rotation about Y, and roll is rotation about X). The period, in milliseconds, specifies how often to send a transform. 100ms (10hz) is a good value.

Assuming you are referring to this specific part of this specific page: in tf (so not tf2), there was actually no real concept of "static TFs", neither was there support in the infrastructure. A static transform there is just a transform which doesn't change any of its values during the runtime of the application.

This means that in order for each listener to not consider the "static frame" (note again: nothing special, just a regular frame with unchanging values) stale after some time, you'll have to make sure to republish it. That's what that last sentence is about.

With tf2, this changed, and static transform is actually supported now. From wiki/tf2: Adding static transform support:

The goal of static transforms was to remove the need for recommunicating things that don't change. The ability to update the values was implemented in case they are subject to uncertainty and might be re-estimated later with improved values. But importantly those updated values are expected to be true at all times.

Technically, tf2 broadcasts regular transforms over the regular topic (ie: /tf) with normal Publishers, while static transforms are published using a latched Publisher on a special topic (ie: /tf_static) and only once (or very infrequently).

So tf2 would seem to correspond to what you imply: "never" changing data should not need to be republished.

Looking at the tf wiki page, section static_transform_publisher, we see this:

static_transform_publisher x y z yaw pitch roll frame_id child_frame_id period_in_ms

Publish a static coordinate transform to tf using an x/y/z offset in meters and yaw/pitch/roll in radians. (yaw is rotation about Z, pitch is rotation about Y, and roll is rotation about X). The period, in milliseconds, specifies how often to send a transform. 100ms (10hz) is a good value.

Assuming you are referring to this specific part of this specific page: in tf (so not tf2), there was actually no real concept of "static TFs", neither was there support in the infrastructure. A static transform there is just a transform which doesn't change any of its values during the runtime of the application.

This means that in order for each listener to not consider the "static frame" (note again: nothing special, just a regular frame with unchanging values) stale after some time, you'll have to make sure to republish it. That's what that last sentence is about.

With tf2, this changed, and static transform is actually supported now. From wiki/tf2: Adding static transform support:

The goal of static transforms was to remove the need for recommunicating things that don't change. The ability to update the values was implemented in case they are subject to uncertainty and might be re-estimated later with improved values. But importantly those updated values are expected to be true at all times.

Technically, tf2 broadcasts regular transforms over the regular topic (ie: /tf) with normal Publishers, while static transforms are published using a latched Publisher on a special topic (ie: /tf_static) and only once (or very infrequently).

So tf2 would seem to correspond to what you imply: "never" changing data should not need to be republished.