FYI: the master is not involved in datastreams for topics after two nodes have negotiated their connections (see wiki/Master fi). This doesn't necessarily change your problem, but your 'diagram' is only valid for the initial negotiation phase. wiki/ROS/Technical Overview is also a good link with info on how the master and nodes interact.
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.
Originally posted by gvdhoorn with karma: 86574 on 2017-02-14
This answer was ACCEPTED on the original site
Post score: 1
Original comments
Comment by leroyworld on 2017-02-14:
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
Comment by leroyworld on 2017-02-14:
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.
Comment by leroyworld on 2017-02-14:
->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
Comment by leroyworld on 2017-02-14:
->About ROS graph sections: not sure what that is,I'll check it out. Nevertheless it sounds like it has to do with endpoints (it's a base station and an UAV), for which we don't have access. Not all ~75 topics are actually needed, only those with high priority (probably UAV command and control data)
Comment by leroyworld on 2017-02-14:
Well, I do really appreciate your helpful "non-answers" ;)
-> 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.
Comment by leroyworld on 2017-02-14:
"Raw images" i know... They only sent us one bag for testing. I guess they will compress the video in the near future.
Comment by leroyworld on 2017-02-14:
Ok, I'll try to talk them into ROS2. Appreciate your help, @gdvhoorn.
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?
