ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Finer control of messages forwarded using ros1_bridge

Suppose I want to not forward some topic ro ROS2. For exampe /tf. How would I do that? Is the best way to add an argument to dynamic_bridge that takes a list fo topics not to forward.

And suppose I want to reduce the data. Suppose I have a GeoPose in 10 Hz in ROS1 but only need it in 1 Hz in ROS2. How would I do that?

I kind of need this functionality and will try to implement something and contribute it back. But if there are some prefered way to do these kind of things it could be good to know.

There is currently no way (that I am aware of) to avoid forwarding topics across the bridge. I guess the situation you’re describing is that you have publishers and subscribers on the topic /tf, for example, on both the ROS 1 and ROS 2 sides but you don’t want them to talk? If you only had /tf publishers and subscribers on the ROS 1 side, then even though it would “bridge” that topic, there would be no one listening or contributing from the ROS 2 side anyways. If this is a feature you need, then I’d ask you to open an issue about it on the ros1_bridge’s issue tracker:

As for the message rate throttling, we could implement that into the bridge, but it could also be implemented on the ROS 1 side with some of the topic tools:

It is clearer, in my opinion, to separate the bridging and throttling code unless there is a compelling reason to combine them.

We’re always happy to have contributions, it sounds like the “blacklist” of topics on the bridge would be a useful one.

Can you provide a little bit more information about your goal of “not forwarding” topics. If they don’t have a matched subscriber on the other side they won’t get forwarded.

You can relatively easily remap any topic to a non-matching topic and it won’t get forwarded.

For your example of throttling a topic there’s already tools for that like throttle you’ll end up publishing the data at a slower rate on a different topic and remap that to connect to your ROS2 system.

In general I do not believe that we want to support blacklisting topics for the bridge. If every other topic passes through but one topic doesn’t, if you didn’t configure the blacklist yourself it would be very surprising behavior and break everyone’s assumptions about connectivity.

Your use case is more general than just the bridge which is having tools to selectively expose lower datarate representations of robot data externally. There’s been lots of though experiments and we plan to attack this sort of tool in the future as the new QoS features will help it a lot too. This tool can be written to run on either side of the bridge. But we expect that the introspection and orchestration APIs in ROS2 will help with this tooling a lot.

I want to use the bridge to forward messages to different robots that runs on different cores.

So there are messages for example /diagnostics or internal messages that are on a topic that does not have a namespace to indicate that it belongs to a specific robot. And these messages should not be forwarded but they are subscribed to on each platform so if I just use dynamic_bridge they will be forwarded and mess up things.

The messages that are forwarde either have a prefix or are messages that are global to the whole system of robots.

On the other hand, when our ROS1 implementation is converted to ROS2 then what is needed is something else. What that is I do not know. Maybe a way to group node together and automatically add a prefix to topics from that group.

You could also compile a custom static bridge that specifies the exact messages that need to be converted. That would be a whitelist. Each message type and topic name would have to be specified in the static bridge. I don’t think it is capable of passing through groups of messages.