Thanks, Markus, Nick, and Daniel! More feedback is most welcome. On Wed, Feb 12, 2014 at 11:51 AM, Armstrong-Crews, Nicholas - 1002 - MITLL wrote: > 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 >> > > _______________________________________________ > ros-users mailing list > ros-users@lists.ros.org > http://lists.ros.org/mailman/listinfo/ros-users > _______________________________________________ ros-users mailing list ros-users@lists.ros.org http://lists.ros.org/mailman/listinfo/ros-users