Revision history [back]

The problem we have is that we want to be able to get the static transforms in a lot of nodes, but we don't want the overhead of distributing the high rate transform to every node, just the small number that need it.

"static transforms" in TF2 are broadcast using a latched publisher, which means they won't be periodically published at all, but rather retrieved once and then stored in clients (ie: buffers).

The problem we have is that we want to be able to get the static transforms in a lot of nodes, but we don't want the overhead of distributing the high rate transform to every node, just the small number that need it.

"static transforms" in TF2 are broadcast using a latched publisher, which means they won't be periodically published at all, but rather retrieved once and then stored in clients (ie: buffers).

A set of static transforms for the robot that define things like the wheel positions and sensor locations. These are fixed but they need to be used in a variety of nodes. The problem we have is that we want to be able to get the static transforms in a lot of nodes, transforms come from URDF mainly but we don't want the overhead of distributing the high rate transform to every node, just the small number that need it. there may be some calculated from parameter input when a node starts or from a launch file.

"static transforms" in TF2 are broadcast using a latched publisher, which means they won't be periodically published at all, but rather retrieved once and then stored in clients (ie: buffers).

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.

[..]

The biggest way that static transforms differ from regular transforms is that they don't keep a time history This primarily saves storage and lookup time, though the publishing overhead is also better.

All fixed joints in URDFs/XACROs are broadcast as static transforms. static_transform_publisher from tf2_ros also only publishes static transforms.

Under the hood, two topics are used:

• /tf: regular TF broadcasts (ie: things that change dynamically)
• /tf_static: all transforms that are static

A set of static transforms for the robot that define things like the wheel positions and sensor locations. These are fixed but they need to be used in a variety of nodes. The transforms come from URDF mainly but there may be some calculated from parameter input when a node starts or from a launch file.

You're probably aware of it, but "static transforms" in TF2 are broadcast using a latched publisher, which means they won't be periodically published at all, but rather retrieved once and then stored in clients (ie: buffers).

From buffers). See 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.

[..]

The biggest way that static transforms differ from regular transforms is that they don't keep a time history This primarily saves storage and lookup time, though the publishing overhead is also better.

All fixed joints in URDFs/XACROs are broadcast as static transforms. static_transform_publisher from tf2_ros also only publishes static transforms.

Under the hood, two topics are used:

• used: /tf: for regular TF broadcasts (ie: things (things that change dynamically)
• dynamically) and /tf_static: all transforms that are static

The problem we have is that we want to be able to get the static transforms in a lot of nodes, but we don't want the overhead of distributing the high rate transform to every node, just the small number that need it.

There are various approaches one could think of, but remapping might be an easy one: instead of broadcasting the transforms with high update rate onto /tf, remap it to some other topic. Then make the "small number that need it" subscribe to that topic, instead of the regular /tf (remapping again). That should prevent uninterested nodes from being spammed by the high-rate broadcasts, while leaving everything else unchanged.

Some tricks with muxing might be needed to make sure that those high-rate nodes would also still get the regular broadcasts on /tf.

A set of static transforms for the robot that define things like the wheel positions and sensor locations. These are fixed but they need to be used in a variety of nodes. The transforms come from URDF mainly but there may be some calculated from parameter input when a node starts or from a launch file.

You're probably aware of it, but "static transforms" in TF2 are broadcast using a latched publisher, which means they won't be periodically published at all, but rather retrieved once and then stored in clients (ie: buffers). See wiki/tf2: Adding static transform support

All fixed joints in URDFs/XACROs are broadcast as static transforms. static_transform_publisher from tf2_ros also only publishes static transforms.

Under the hood, two topics are used: /tf for regular TF broadcasts (things that change dynamically) and /tf_static (transforms that don't).

The problem we have is that we want to be able to get the static transforms in a lot of nodes, but we don't want the overhead of distributing the high rate transform to every node, just the small number that need it.

There are various approaches one could think of, but remapping might be an easy one: instead of broadcasting the transforms with high update rate onto /tf, remap it to some other topic. Then make the "small number that need it" subscribe to that topic, instead of the regular /tf (remapping again). That should prevent uninterested nodes from being spammed by the high-rate broadcasts, while leaving everything else unchanged.

Some tricks with muxing might be needed to make sure that those high-rate nodes would also still get the regular broadcasts on /tf.