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

Raymond Sheh rsheh at cse.unsw.edu.au
Mon Feb 14 09:15:45 UTC 2011

  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 Singapore here. I have that
> feeling that we have a very similar scenario we're working on,
> involving USAR scenarios, RoboCup and all that ;) .
> We're also working on having multiple robots in the Rescue arena and
> face the same challenges. I did some quick searching around for
> multi-robot stuff in ROS and came up with the following:
> http://www.ros.org/wiki/wifi_comm
> Discussion here:
> http://ros-users.122217.n3.nabble.com/Multi-robot-communication-td929343.html
> http://github.com/jonfink/multimaster-ros-pkg
> Discussion: http://ros-users.122217.n3.nabble.com/multi-robot-co-coperation-relaying-ros-namespaces-td747773.html
> Another topic dealing with the issue:
> http://ros-users.122217.n3.nabble.com/Multi-Robot-System-td131485.html
> http://ros-users.122217.n3.nabble.com/Re-ros-users-Multi-Robot-System-td134490.html
> So without going into detail, there have been approaches from
> different people for different systems, but a standard approach
> obviously did not emerge so far. The part of the Building Manager
> project dealing with multi-robot applications sounds very good:
> http://www.ros.org/wiki/Projects/Building%20Manager/Overview . Ken,
> can you specify a (even if very) approximate time frame of realization
> the multi-robot comms portion?
> Multi-robot communication is a major part of many projects (a working
> solution would evaluation of ROS on our Humanoid KidSize robots
> feasible for example) and it would be great to see it gaining
> momentum.
> regards,
> Stefan
> 2011/2/14 Raymond Sheh<rsheh at cse.unsw.edu.au>:
>>   On 13/02/2011 5:15 AM, Ken Conley wrote:
>>> On Fri, Feb 11, 2011 at 4:40 PM, Raymond Sheh<rsheh at cse.unsw.edu.au>    wrote:
>>>>    Hi all!
>>>> We are looking at using ROS on a set of robots, which run autonomously
>>>> and independently but at times require some collaboration,
>>>> teleoperation, remote logging and monitoring over a link that is
>>>> unreliable. I understand that ROS's network communications stack
>>>> natively assumes reliable, complete connectivity so we'd need to somehow
>>>> supplement its capabilities.
>>> roscpp implements a UDP transport as well, so you can do roscpp-roscpp
>>> unreliable.
>>>> Ideally, as the link degrades we'd like the ability to, depending on the
>>>> data, selectively drop or buffer and detect (from both ends) what kinds
>>>> of delays may be present and when the link has dropped completely so
>>>> that they can react accordingly. We'd also need to have some form of QoS
>>>> mechanism.
>>>> Does anyone have any suggestions as to the best way of going about doing
>>>> this with ROS? If there's already a quasi-standard way of doing this
>>>> kind of thing within ROS we'd prefer to avoid reinventing the wheel! :-)
>>>> I'm still getting up to speed with ROS (I've just come from an
>>>> environment based mainly around Player, Ice and some custom
>>>> error-tolerant "stuff"). My current thinking is to have each robot run
>>>> completely separate ROS "clusters" (what's the collective noun for a
>>>> group of computers/nodes that all talk ROS to each other?) each with an
>>>> independent master. We'd then develop a node that acts as a
>>>> communications relay with the ability to provide this kind of graceful
>>>> degradation and QoS. The "clusters" will talk to each other via these
>>>> relay nodes. One obvious downside would be that we'd lose the ability to
>>>> transparently move nodes from one robot to another although given the
>>>> control we need over what happens on the link I'd assume there isn't
>>>> really a sensible way of keeping this completely transparent whatever we
>>>> do.
>>>> I notice some discussion mid last year about using foreign_relay to do a
>>>> vaguely similar thing but would I be correct to conclude that the goal
>>>> of foreign_relay is more to handle the unreliable link in a way that is
>>>> largely transparent to the nodes involved? Would an alternative be to
>>>> somehow extend foreign_relay to include the capabilities that we need?
>>> foreign_relay is a relay node implemented on top of roscpp's UDP
>>> transport mechanism.  At the very least, it's a good starting point
>>> for you might relay between different clusters.
>>> As part of our "Building Manager" project [1], we hope to investigate
>>> other mean of maintaining communication between different robots over
>>> wifi links, but we haven't started that particular feature
>>> investigation yet and would appreciate any insight you have.
>>> Hope this helps,
>>> Ken
>>> [1]: www.ros.org/wiki/Projects/Building Manager
>> Thanks for your info! I'll have another look at the UDP transport and
>> foreign_relay and I'll keep an eye on the building manager project.
>> I'm still at the stage of getting to know what ROS can do and how it
>> fits in with what we'd like to do overall - it'll be another couple of
>> months at least before we're in a position to seriously implement
>> something.
>> As for insights, I've got some ideas for what to do (and not to do!)
>> based on our previous experience but I am also looking around at how
>> other projects have handled unreliable links and QoS issues. I'd
>> appreciate any pointers that you (or anyone else for that matter) could
>> offer to other projects that are worth looking at for ideas! :-)
>> Cheers!
>> - Raymond
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users

More information about the ros-users mailing list