tf aggregator to avoid many-to-many /tf connections?

asked 2021-09-19 11:18:16 -0500

lucasw gravatar image

I'm guessing lower latency is the reason for not pushing all tf messages through an aggregator node by default (though there could be a hybrid system where some nodes that need lower latency still subscribe to /tf, but others like rviz would get aggregated output). I'm curious if anyone has considered or made a /tf_agg that functions like /rosout_agg?

edit retag flag offensive close merge delete

Comments

1

I'm not sure I completely understand what you're describing. Afaik, rosout_agg is a topic where the collective rosout output of all nodes (for that master) is republished. tf by default (as a topic) is bus-like, so already carries all messages.

Having written that: something like tf2_web_republisher?

Additionally, if a node does not need / want to subscribe to tf (via a Listener fi), you could use a tf2_ros::BufferServer, which exposes an Action server interface. Or one of the alternative implementations, such as magazino/tf_service and peci1/tf2_server.

The last one there specifically mentions:

It can be used as a TF concentrator which reduces the usual M:N connection nature of the TF topic to a M:1 and 1:N.

gvdhoorn gravatar image gvdhoorn  ( 2021-09-19 11:46:01 -0500 )edit

Those look interesting, I'll have to to see if any actually publish to a new tf topic (it would be a trivial add except in case of wanting to throttle the aggregate output down- then there is a question of how to filter higher frequency data, just use most recent transform for the update period?). That last quote is exactly what I have in mind.

I think topic aggregation could be made message type generic, that node already exists- just a standard topic tools relay pointed at tf could be all I want- but still curious if anyone else has tried this out.

lucasw gravatar image lucasw  ( 2021-09-19 12:47:48 -0500 )edit
add a comment