Revision history [back]

Static transforms are transforms that are assumed not to change -- or very infrequently.

Because of that, they don't need to be periodically broadcasted. At the implementation leve, this means static transform broadcasters can make use of topic latching, greatly reducing required message traffic on the TF topics.

For transforms that do change, this is not suitable, so that's where a regular TF broadcaster comes in.

If you look at the two tutorials you mention, you'll see that the static broadcaster essentially calls sendTransform(..) once and then the programs hangs in the ros::spin().

The non-static broadcaster calls sendTransform(..) at the end of the poseCallback(..), which is called for every incoming turtlesim::Pose message. This essentially means that sendTransform(..) will be called at a specific rate, which would make sense as the transform needs to be updated for every new pose.

Finally: regular broadcasters publish to /tf, while static broadcasters publish to /tf_static.

Static transforms are transforms that are assumed not to change -- or very infrequently.

Because of that, they don't need to be periodically broadcasted. At the implementation leve, level, this means static transform broadcasters can make use of topic latching, greatly reducing required message traffic on the TF topics.

For transforms that do change, this is not suitable, so that's where a regular TF broadcaster comes in.

If you look at the two tutorials you mention, you'll see that the static broadcaster essentially calls sendTransform(..) once and then the programs hangs in the ros::spin().

The non-static broadcaster calls sendTransform(..) at the end of the poseCallback(..), which is called for every incoming turtlesim::Pose message. This essentially means that sendTransform(..) will be called at a specific rate, which would make sense as the transform needs to be updated for every new pose.

Finally: regular broadcasters publish to /tf, while static broadcasters publish to /tf_static.