ROS 2 Foxy tf2 static transform publisher and Humble subscriber QoS durability interoperability question

Answer first

No. Do not force VOLATILE on /tf_static to get Foxy-Humble interoperability. The correct universal setting is TRANSIENT_LOCAL and it is already the default for the tf2 static transform broadcaster in both ROS 2 Foxy and ROS 2 Humble. A single default QoS profile works on both distros without modifying library source. tf2 does not provide a runtime API to detect or adapt to a peer QoS mismatch; incompatibility is surfaced by the DDS layer as a requested/offered incompatible event and as warnings in node logs.

Confirmed facts

• The tf2_ros StaticTransformBroadcaster creates the /tf_static publisher with TRANSIENT_LOCAL durability. This design predates the Foxy and Humble releases and mirrors ROS 1 latched behavior for static transforms.
• DDS QoS compatibility: a subscriber requesting TRANSIENT_LOCAL is incompatible with a publisher offering only VOLATILE. A VOLATILE subscriber can receive from a TRANSIENT_LOCAL publisher. Therefore a VOLATILE publisher is the breaking direction, not a TRANSIENT_LOCAL one.
• Forcing VOLATILE on /tf_static breaks late-joining subscribers because they will never receive transforms published before they started. That creates the incompatibility you are trying to avoid.

Likely explanation for the premise

The Foxy VOLATILE vs Humble TRANSIENT_LOCAL claim is likely incorrect. Both distros ship tf2_ros with TRANSIENT_LOCAL for /tf_static. If you are seeing a QoS mismatch warning, it is more probable that the publisher is being overridden to VOLATILE by custom code, a different node publishing to /tf_static, or an RMW/discovery issue rather than a distro default change.

Verification steps for this case

1. Check the live QoS on both sides:

   ros2 topic info /tf_static --verbose

   Compare the Durability field for each publisher and subscription endpoint on the Foxy node and the Humble node.
2. Verify the installed source: Inspect the tf2_ros static_transform_broadcaster source on each distro for the QoS used when creating the /tf_static publisher. The default construction uses TRANSIENT_LOCAL.
3. Test latching behavior: Start the Foxy static broadcaster first, then start a fresh Humble tf2 listener. If the transform arrives immediately, TRANSIENT_LOCAL latching is working and no durability mismatch exists.
4. Confirm RMW parity: Check both sides use the same RMW implementation via ros2 doctor --report or the RMW_IMPLEMENTATION environment variable. Mixed Fast DDS vs Cyclone DDS can cause discovery or delivery issues independent of tf2 QoS.

Assumptions and uncertainty: Exact defaults are version-sensitive and can be affected by distro-specific backports. Foxy is end-of-life, so behavior may differ from a pristine install. Verify against the installed tf2_ros source rather than documentation alone.

One diagnostic detail that changes the recommendation: Are you using a custom StaticTransformBroadcaster with an explicit rclcpp::QoS passed in, or is another node publishing to /tf_static with VOLATILE durability? If a custom QoS override exists, that is the source of the mismatch, not the distro defaults.