Revision history [back]

Also: this sounds a bit like an xy-problem. What is the real issue that you are trying to solve? Is it lowering traffic on your radio-link, or do you want all traffic, but want to be able to prioritise?

Edit:

My TCPROS jargon wasn't accurate enough. I edited the question accordingly.

I have the same example, camera and viewer, and roscore is running in the same host as the viewer is. Once connections are negotiated, topic datastreams are flowing through the RF link, and I'd like to apply topic filtering

When the RF link is saturated (bottleneck) we need to lower the traffic, dropping packets from low priority topics. Ideally TCP would try to resend this packets and our RF link should be able to send them eventually. Anyway, simply put: Yes, we want to lower the traffic on our radio-link.

I would look into the things the teams in the DRC did: they had to work with low-bw, high-latency and lossy links all the time. I remember some of them implementing custom gateways (nodes) that used UDP to 'bridge' over the wireless links.

(related thought: ROS2 / DDS should actually make this much simpler: proper QoS settings should make this easier)

I would also look into separation of ROS graph sections, the way multi-master setups allow you to. That should make it possible to completely control which topics do get tranmitted over your wireless link. Do all 71 topics actually need to be transmitted?

What you are asking is probably possible (you could probably use the master to track IP:PORT combos for pub/subs, etc), but it might be easier to achieve your goal in a different way, hence my suggestions. I also purposefully used comments, to not answer your question with non-answers.

Edit2:

ROS2/DDS: I forgot to mention we don't have access to the endpoints, as they belong to another company and ROS version is fixed. We are only in charge of the radio platforms and RF link. To inform us which topics are high priority they appended a prefix to each topic, like: /high/flir/imageraw

pfew. Raw images over a radio link. There are lossless compression options (compressed_image_transport with PNG fi) that save quite some bandwidth. Irrespective of what you end up doing I would look into that.

About the UDP Bridge: that's mainly what our radio platforms do. I'll try to check DRC projects.

About tracking IP:PORT: I guess that's our only choice to implement within the radio platform. But it doesn't seem too straight forward.

yes, that is probably not straightforward, and it'll probably be brittle as well. It would probably really help if you could get some influence over the endpoints. ROS(1) was designed for a 'perfect network' (high-bw, low-latency, no/very little loss). It seems unreasonable to expect that assumption to hold here with your wireless system in between.

Ok, I'll try to talk them into ROS2

covering my *ss here: that is not really what I meant. My comment was more like "hm, this sounds like something where the QoS support in DDS might come in handy". It was not a direct advice to move to ROS2.

Just to see if I understood correctly. Once the topics are negotiated, the only way to differentiate one data stream from one topic to another one is to check the TCP ports, is this right?

I would expect so, but I've never done anything like that. The master keeps a record of all nodes and advertised topics & svcs, together with ip:port info. I could imagine using that to feed a 'proxy' with priorities for different ip:port combos. See if the Master API and/or Slave API help here.

You could also look into the various multi-master implementations that exist. Instead of transparently bridging two networks over your wireless link (at layer 2 or 3) it'd be more like a configurable proxy where you explicitly configure which topics should be bridged.