[ros-users] ROS & DDS

Thu Feb 13 10:25:46 UTC 2014

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 listros-users at lists.ros.orghttp://lists.ros.org/mailman/listinfo/ros-users
>
>
>
> --
> Prof. Dr. Christian Schlegel
> Prodekan, Studiendekan Master IS
> Fakultät Informatik
> Hochschule Ulm
>
> Tel.: 0731 / 50-28242
> http://www.hs-ulm.de/schlegelhttp://www.servicerobotik-ulm.de/http://www.zafh-servicerobotik.de/ (Sprecher)http://www.youtube.com/user/roboticsathsulmhttp://smart-robotics.sourceforge.net/http://www.joser.org/
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
>

-- 
Daniele "MadMage" Calisi
*"Your limit is always a bit beyond"*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140213/29108cfc/attachment.html>