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

Raymond Sheh rsheh at cse.unsw.edu.au
Sat Feb 12 00:40:55 UTC 2011


  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.

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?

Cheers!

- Raymond Sheh



More information about the ros-users mailing list