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

Stefan Kohlbrecher stefan.kohlbrecher at googlemail.com
Mon Feb 14 09:01:10 UTC 2011


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:

Discussion here:

Discussion: http://ros-users.122217.n3.nabble.com/multi-robot-co-coperation-relaying-ros-namespaces-td747773.html

Another topic dealing with the issue:

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


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

More information about the ros-users mailing list