Thanks, Markus, Nick, and Daniel!
More feedback is most welcome.
On Wed, Feb 12, 2014 at 11:51 AM, Armstrong-Crews, Nicholas - 1002 -
MITLL <
nickarmstrongcrews@ll.mit.edu> 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<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@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
(text/plain)