[ros-users] Best option for communication over an unreliable link?

Cedric Pradalier cedric.pradalier at gmail.com
Mon Feb 14 09:32:14 UTC 2011


As an additional input, we have developed a generic message transport plugin
architecture [1]. This allows to implement your own kind of transport for
any type. For instance, we've implemented a udp multicast and a shared mem
This could be a framework to implement your link, although it is a single
master approach.

[1] http://www.ros.org/wiki/ethzasl_message_transport


On Feb 14, 2011 10:15 AM, "Raymond Sheh" <rsheh at cse.unsw.edu.au> wrote:
 Hi Stefan,

Thank you for your information!

I did follow a few of the multi-robot topics in the archives and they're
certainly related but I guess the emphasis of what I'm trying to
accomplish here relates more to allowing the various nodes on each end
of the comms link to manage the unreliability of the link in their own
way (and thus having the relay mechanism expose these details - which I
understand is in a somewhat different direction to the approaches that
try to abstract the link away as much as possible).

For example, a node that deals with formatting data for a remote teleop
video feed (with a codec that can handle packet loss) will need to
specify that its data should always be dropped if it can't be sent,
rather than buffered. Ideally, it should also have a medium to high
priority on the link and should be notified if delays go up or bandwidth
begins to drop so we can do thing like increase compression. In
contrast, a remote logging node would be low priority and buffer rather
than drop when the link drops out. Also, nodes that handle control and
realtime teleop should be actively informed by the relay system when the
link has dropped out (rather than relying on a timeout).

Of course, having a wishlist like this is one thing, figuring out what's
worth implementing and how to go about it is another! ;-) In our
previous work we used completely different systems for the different
data and while it kinda worked, I'm trying to see if there's a viable
way of doing this all under the one infrastructure.


- Raymond

On 14/02/2011 5:01 PM, Stefan Kohlbrecher wrote:
> Hi,
> one of your team area neighbors from Sin...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110214/d4a7ef75/attachment-0003.html>

More information about the ros-users mailing list