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@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" 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@lists.ros.org > [mailto:ros-users-bounces@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@lists.ros.org > http://lists.ros.org/mailman/listinfo/ros-users >