[ros-users] ROS & DDS

Wed Feb 12 19:51:20 UTC 2014

This is an important topic, but I don't personally have any DDS experience.
Instead, I'm forwarding comments from our DDS guy... who also has experience
with ROS and many other middlewares.

Thanks,
-Nick

-----Original Message-----
From: Daniel Herring [mailto:dherring at ll.mit.edu] 
Sent: Wednesday, February 12, 2014 1:16 PM
To: Armstrong-Crews, Nicholas - 1002 - MITLL
Subject: Re: FW: [ros-users] ROS & DDS

On Wed, 12 Feb 2014, Armstrong-Crews, Nicholas - 1002 - MITLL wrote:

> Any comments for the gods of ROS?

Hi Nick,

Its a no-brainer.  Go for it.  The strength of ROS is in its body of modules
and the messages connecting them, not its middleware.  DDS is gaining
momentum for good technical reasons.

RTI and PrismTech both have good, freely available implementations for MSWin
and Linux.  Establish ROS as an "infrastructure community" with RTI. 
Just download the LGPL packages from PrismTech.  Many other players from IBM
to Twin Oaks have commercial DDS implementations.  OCI DDS was a build
nightmare and nearly unusable when the "first usable release" came out
roughly 7 years ago; I've heard it has improved since then but is still
feature poor.

http://www.rti.com/products/licensing/infrastructure-community.html

http://www.prismtech.com/opensplice/products/opensplice-community

Other communications middlewares like JMS or {Active,Zero,*}MQ have
proponents but really aren't appreciably better than DDS.  DDS is king
because of the range of QoS options it supports, a long history of users and
standards documents refining rough edges, and a growing body of industry
support.  I expect the opensource community will eventually stop toying with
these ideas and start writing DDS implementations.

(As an analogy, I view these other middlewares as being like GNU Hurd or
Plan 9 and view DDS as being like Unix/Linux.  The other OSes have some good
features, but Linux has a complete, proven package.  DDS is one of the few
middlewares to have a proper standard, with independent implementations.
Most just have a single reference implementation, with some documentation on
how it works.  The difference in design maturity is
considerable.)

Regarding the DDS API:  Nobody likes the full API.  Most companies (LL
included) start by writing a library that insulates the user from all the
factory and QoS boilerplate.  There is a new C++ DDS API that should be much
simpler.  The vendors also have added (vendor specific) config files that
can replace all the tedious QoS API calls.  ROS should be able to hide all
this behind a few simple API calls, possibly with some DDS-specific config
files.

Regarding IDL:  Meh, it works but is not very special unless you need OMG
CORBA legacy support.  They recently added support for dynamically
extensible data types -- not widely available or used yet.

Switching existing ROS messages to IDL would be a big breaking change with
little benefit.  It is probably easier to put the ROS-encoded message in a
"sequence<octet,MAX_LENGTH>" IDL message packet.  Putting an integer key
before this sequence value allows sending multiple data types over a single
topic (DDS enforces 1:1).  The opaque encoding does defeat some DDS
features; but these can be supported by adding/copying a few fields out of
the sequence and into the IDL.  Overhead for this approach should be
comparable to a memcpy of the sequence length (i.e. negligible in most
cases).

Whether new ROS messages should use IDL or the current ROS approach is a
separate but related question.  There are benefits to separating the
encoding from the transport.  For example, it makes it easier to save
messages to disk and maintains compatibility with existing ROS message
inspection tools.  DDS only exposes unpacked data structures.  The separate
encoding may also simplify support for languages that DDS doesn't support;
do the serialization in the niche language and just pass byte arrays to the
foreign function interface.

Later,
Daniel

> -----Original Message-----
> From: ros-users-bounces at lists.ros.org
> [mailto:ros-users-bounces at lists.ros.org] On Behalf Of Brian Gerkey
> Sent: Wednesday, February 12, 2014 11:57 AM
> To: User discussions
> Subject: [ros-users] ROS & DDS
>
> hi,
>
> As we work on improving the communications middleware within ROS, one 
> of the approaches that has come up repeatedly is DDS (Data 
> Distribution Service; http://portals.omg.org/dds/).  There are lots of 
> positive aspects of DDS as a middleware, and of course some tradeoffs 
> (e.g., in exchange for lots of features in the message transport, the 
> API is incredibly verbose; while there are open source 
> implementations, there's not the feeling of an active community doing
development on them).
>
> We'd like to understand what the level of interest is within the ROS 
> community for DDS support.
>
> 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?
>
> thanks,
> brian.
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5446 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140212/dc3409a4/attachment.bin>