# Why publish a static tf every 100ms?

I have a multi-lidar, multi-camera system with several static tf transforms (no sensors will ever move), I note that the tf wiki page recommends publishing static transforms at 10Hz - I wondered what the rationale for this is? Why not publish, for example every 5 seconds? or even less often? How much of a performance cost is there here? Is the benefit just so that nodes which die and are reborn can quickly get the tf?

EDIT: i'm using tf, not tf2 - would the situation be different if i was using tf2?

edit retag close merge delete

Please be precise: tf or tf2?

( 2020-03-13 07:33:12 -0500 )edit

have clarified

( 2020-03-13 07:35:30 -0500 )edit

Sort by » oldest newest most voted

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.

Edit:

EDIT: i'm using tf, not tf2 - would the situation be different if i was usiung tf2?

while you may be using functions, classes et al. from tf, you're actually already using tf2:

Migration: Since ROS Hydro, tf has been "deprecated" in favor of tf2. tf2 is an iteration on tf providing generally the same feature set more efficiently. As well as adding a few new features. As tf2 is a major change the tf API has been maintained in its current form. Since tf2 has a superset of the tf features with a subset of the dependencies the tf implementation has been removed and replaced with calls to tf2 under the hood.

more

1

If you specifically call the tf static_transform_publisher executable it maintains the original behavior. You can simply switch to the tf2 static_transform_publisher it will leverage the static transform primitives and not have to rebroadcast.

( 2020-03-13 13:16:24 -0500 )edit

When updating the static transform publisher in your launch files to use tf2 rather than tf, you have to make two changes: 1) update the pkg from tf to tf2_ros 2) delete the period_in_ms argument at the very end of the command.

See section 5 of this page for proper syntax for publishing static transforms.

( 2020-09-25 14:30:27 -0500 )edit