Request for Comments: static_transform_mux

Hello ROS (1) developers. Recently, I was facing some issues due to the fact that I had more than one /tf_static publisher in my system. I think that’s not completely unusual, since I’ve seen several people trying to do the same.

The problem is the following: the /tf_static topic should have all publishers latched, which is good for latecomers online, but not sufficient when replaying a bag - then you will only get the transforms from the last publisher that published to /tf_static. What I (and more people) would expect is to get all the static transforms. That is not accomplishable through latching.

I tackled the problem by creating the static_transform_mux node that sits there all the time, remembers everything it saw on /tf_static, and tries to always be the last publisher on the topic publishing all the transforms it saw.

What do you think about this approach? Do you think it’s worth trying to publish it as an official ROS package? Or should I instead send a PR to tf2_ros or rosbag?

Thank you very much for your opinions!

1 Like

If you want, I’d be willing to merge it into static_tf if tf2_ros doesn’t want it. Right now, all that repo (which there are binaries for) has is my simple script for publishing static tfs without needing 9 arguments.

I have struggled with this before as well… Would be great to have it merged in some existing ROS packages and tf2_ros seems reasonable or maybe tf2_tools, which seems to contain scripts / nodes instead of API.

See also my comment at https://github.com/ros/ros_comm/issues/146#issuecomment-417615663 about how this might be solved in rosbag itself, but it sounds to me like the mux should address the problem well enough and it is ready to be used.