leroyworld's profile - activity

Done. Thank you again, gvdhoorn.

This post has been answered by @gvdhoorn in the comments under the main question.

Thank you @gvdhoonr, you've already given us plenty of useful information to start working with. I consider all your comments made more than a full answer so I'll add an answer redirecting to these comments. Regards.

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?

"Raw images" i know... They only sent us one bag for testing. I guess they will compress the video in the near future.

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.

->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)

->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

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.

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

Hi everyone,

[Kinetic 1.12.6, Ubuntu 16.04 kernel 4.4.062-generic]

We've got the following system topology:

The radio platforms act like a HUB so endpoint nodes see each other like if they were directly connected by an ethernet cable. Our radio platforms are embedded devices that don't understand TCPROS protocol, they are just configured in promiscous mode to move traffic from ethernet interface to RF interface and viceversa.

Now here comes the problem: we have ~75 topics and we want our radio platforms to be able to filter TCPROS traffic by TOPIC, so we can define high or low priority topics.

How can we differentiate which packet corresponds to each topic? As far as I understand, client-master negotiate what port they are going to use for each topic and then the datastream from each topic is sent to its assigned port. In other words, my only way to filter data stream from one topic would be to keep a track of assigned ports (when topics are published) and then check every "destination port" field within TCP header? Does this make sense? or is there any easier way?

Regards,

-Leroy