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

Stefan Kohlbrecher stefan.kohlbrecher at googlemail.com
Thu Feb 17 11:39:01 UTC 2011


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

I see where you're coming from, my intention was more to show the
related stuff that I am aware of, even if it doesn't fit perfectly.
What you propose would definitely the nicest thing to have, especially
for USAR and similar scenarios. There's quite a lot of ideas that
could be implemented. For example, I could imagine that scaling the
overall available transmission bandwidth could be useful, so all
transmission data needed for teleoperation gets throttled back
gracefully in a best effort way once link quality degrades.

To me, an approach that probably could be realized in a shorter time
frame would involve basically two link classes:
-non-guaranteed: Send and forget, an example would be pose data that
frequently gets resent anyways and has short time of validity. An
example would be the team communication of soccer robots in the
RoboCup Humanoid League. We use such a scheme for team coordination
extensively there (think UDP)
-guaranteed: Mainly used for transmission of large amounts of data who
must not get corrupted. An example would be the exchange of occupancy
grid map data between robots. It might would make sense to be able to
throttle transmission here, so the link doesn't get saturated (think
TCP/IP)

Both link types should be able to cope with temporary communication outages.

That's what I'd consider a good starting point from a pragmatic (e.g.
I'd like to have something useful, even if not perfect) perspective
(ignoring the ROS API, how topics are specified for communication over
wireless link etc.).



More information about the ros-users mailing list