[ros-users] ROS & DDS

Thu Feb 13 12:22:20 UTC 2014

Hi Brian, hi all,

thank you very much for initiating and pursuing this discussion on the
mailing list. I, as a ROS user, appreciate being in the loop, at least
initially, of such design discussions!

I have two questions:
(1) For a researcher using ROS to run experiments on a single robot +
local LAN, what is the __single__ most important advantage of a
middleware switch to, for instance, DDS?

(2) For a maintainer of a client language of ROS (not cpp or python),
what is the overhead of the discussed switch?

Thanks for any response, and keep up the interesting discussion.

Cheers,
Georg.

On 02/13/2014 12:38 PM, Nikolai Ensslen wrote:
> Hi Brian,
> 
> 
> 
> as you know from our recent conversations, at Synapticon we're absolutely
> in favour of putting ROS onto any of the mature middleware options
> available and DDS is the most promising candidate. Christian and Daniel
> (forwarded by Nick) gave great summaries to which we can't add much. We
> think making ROS supporting or using DDS would finally enable ROS to gain
> the traction it deserves in industrial/product applications.
> 
> 
> 
> However we also think it makes sense not to replace the traditional ROS
> middleware but to just add DDS spec to it, maybe replacing some elements
> that make sense after some time. Backwards compatibility is important and
> there are some things ROS middleware is obviously good at that DDS can't
> provide, e.g. messaging or streaming larger amounts of data.
> 
> 
> 
> We'd be happy to contribute to the efforts of adding DDS as a middleware
> choice to ROS.
> 
> 
> 
> Best,
> 
> Nik
> 
> 
> 
> *Von:* ros-users-bounces at lists.ros.org [mailto:
> ros-users-bounces at lists.ros.org] *Im Auftrag von *Daniele Calisi
> *Gesendet:* Donnerstag, 13. Februar 2014 11:26
> *An:* User discussions
> *Betreff:* Re: [ros-users] ROS & DDS
> 
> 
> 
> I agree with Christian Schlegel on the following points:
> 
> - Configuring DDS is very complex and the effort makes sense only for big
> projects. I personally have an experience with DDS used in robotics and it
> has often be a pain to configure everything in such a way that it works as
> expected. If you are not a DDS expert, you can easily have configurations
> that perform worse than using whatever middleware.
> 
> - Let's write an abstraction layer, this is the best solution, because we
> are not sure how ROS middleware can perform with respect to DDS for
> specific robotic applications (and I see using ROS middleware much more
> simple for those who are just beginning with robotics, e.g., students).
> Moreover, we are not sure about what the future has to offer, what if we
> discover that a new-born middleware is better than everything for robotics
> and embedded systems? I personally did this for our framework OpenRDK (
> http://openrdk.sf.net), and, although the abstraction was not complete and
> sometimes requires some hacks, I was able to use OpenRDK own middleware,
> ROS middleware, DDS or even KDE D-Bus or HTTP, depending on the application.
> 
> 
> 
> On Thu, Feb 13, 2014 at 10:14 AM, Christian Schlegel <schlegel at hs-ulm.de>
> wrote:
> 
> Dear Brian,
> 
>    - DDS definitely is a very interesting candidate. If it comes to QoS, it
>    is the most standardized and most advanced approach. In particular, due to
>    the high degree of standardization, different implementations of the DDS
>    standard can smoothly interact.
> 
> Let me give some more hints:
> 
>    - I have been wondering for a long time why robotics more or less
>    ignored so far existing middleware standards and often comes up with
>    solutions ignoring the achievements in the scientific community of
>    distributed / middleware systems. That is in particular interesting since
>    in robotics, we need the most advanced middleware systems (scalability
>    across different H/W and OS platforms ranging from embedded to full-scale
>    systems, QoS, partly even realtime etc.). The DDS standard deals with many
>    of these things!
>    - "freedom from choice" instead of "freedom of choice":
> 
> 
>    - it will be decisive not just to migrate to DDS (or any other
>       middleware) and then present the complexity of DDS ("freedom of
> choice") to
>       the robotics user (configuring DDS is complex  but that is because DDS is
>       powerful). We need to have an abstraction layer (execution
> container) that
>       comprises "robotics communication patterns" ("freedom from choice") like
>       query (request / response) and push (publish / subscribe). These provide
>       stable interfaces to the robotics experts but can be mapped onto whatever
>       middleware that is appropriate. Going beyond state-of-the-art would
>       introduce QoS attributes with such communication patterns and
> mapping them
>       with QoS will most likely consider DDS a very good candidate.
>       - this way, you separate the "robotics communication patterns" from
>       the middleware and ignoring that separation unfortunately has a long
>       tradition in robotics: for very good reasons, you should not expose the
>       complexity of CORBA, zeroMQ, ACE, ACE/TAO, DDS to the robotics user but
>       should have framework experts that once do these mappings
> 
> 
>    - If you are interested in such communication patterns (and how they can
>    be mapped onto different middleware systems, but right now still without
>    QoS), you might want have a look at the "SmartSoft communication patterns"
> 
> http://www.intechopen.com/books/robotic-systems-applications-control-and-programming/robotic-software-systems-from-code-driven-to-model-driven-software-development
> 
> Christian
> 
> 
> 
> 
> Am 12.02.2014 17:56, schrieb Brian Gerkey:
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
> 