[ros-users] ROS & DDS

[Geoffrey Biggs]

On 13 February 2014 01:56, Brian Gerkey <gerkey at osrfoundation.org> wrote:

> So, for those of you who already know something about DDS (especially
> if you have experience using it), here are some questions to start a
> discussion.  Don't feel obliged to answer every question, and also
> feel free to answer questions not asked here.  If you prefer, you can
> reply directly to me, and we'll anonymize your comments before
> potentially sharing them.
>
> What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
> why?  If you don't like it, why not?
>
> How would you compare DDS to the ROS middleware?
>
> Do you see others in your field using DDS?  Have you ever wished that
> ROS could "speak DDS"?  Have you already used DDS in combination with
> ROS?
>

We have quite a bit of experience with DDS here, both from using it and
from sitting in some of the meetings where the standards are defined
(although often "argued over" may be a better term).

DDS is the state-of-the-art. The features available make it ideally
suitable for robotics. I cannot think of any good reason not to use DDS
unless you are only dealing with a single computing node, and even then
only if the cost of serialisation is too high and you don't want features
such as QoS, logging and introspection. The QoS features alone make DDS a
must-have in many applications (fun fact: Robonaut talks DDS between the
ISS and the ground - apparently RTI initially couldn't understand the need
to support a one minute latency).

DDS is standardised at both the API level (the C++ API is quite nice to
use, in my opinion) and at the wire level, meaning any conforming
implementation has compatibility with any other. I have seen at least five
independent implementations all talking at once. Although vendors obviously
add their own extensions to the C++ API, we have found that they tend to be
focused on API simplicity over new features.

The parameter tuning is important if the defaults don't do what you need,
but it is nothing new to anyone who's had to tune network performance,
especially in a wifi environment. Specifying QoS parameters in an XML file
is standardised now, so all implementations do or shortly will support it.
This is extremely useful; you can save different profiles for different
links and load them dynamically depending on what sort of deployment you do.

Using DDS instead of a home-grown transport, whether the existing one or a
new one, would mean an instant boost in compatibility with non-ROS systems.

There are some open-source implementations available, such as the actually
open OpenDDS (which uses CORBA, specifically TAO, internally), and
PrismTech's OpenSplice DDS. Then there are the we-pretend-to-be-open ones
such as RTI Connext DDS. Most of our experience is with the RTI one - the
tools they provide are incredibly useful.

RTI has a page listing some of their academic license uses. The number of
them doing robotics is telling, as is the number of those that are field
applications.

http://www.rti.com/resources/university-participants.html

Geoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140213/e92034cf/attachment-0001.html>