Odd QOS for Diff Drive TF Publication

[DLu]

Describe the bug
Is there a particular reason why the TF is published directly using a publisher rather than TF Broadcaster? Publishing it with a custom publisher / custom QOS settings does not play nicely with other systems.

To Reproduce

1. ros2 launch gazebo_ros2_control_demos diff_drive.launch.py
2. Attempt to visualize TF in rviz2

Expected behavior
Full transform from /odom to all other links.

Actual behavior
Full transforms not published, most frequently failing to publish odom -> base_link/chassis (See ros-controls/gazebo_ros2_control#224)

Environment (please complete the following information):

• OS: Ubuntu 20.04
• Version Foxy

[bmagyar]

I believe when this was ported, the broadcaster wasn't a thing yet.
Please feel free to submit a PR

[DLu]

Okay, so the real issue is that raw publisher is passed to the realtime_tools::RealtimePublisher, and I don't think there's a RealtimeTFBroadcaster. Should the QOS just get fixed, or is there something else todo with realtime?

[christophfroehlich]

Maybe it's worth it to implement a RealtimeTFBroadcaster based on the realtime_publisher?

[bmagyar]

Afaik the broadcaster/listener are tfbuffer+publisher/subscriber. We could also just grab the publisher from inside the broadcaster class if that's a possibility in API