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@lists.ros.org [mailto:ros-users-bounces@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@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@lists.ros.org
http://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/schlegel
http://www.servicerobotik-ulm.de/
http://www.zafh-servicerobotik.de/ (Sprecher)
http://www.youtube.com/user/roboticsathsulm
http://smart-robotics.sourceforge.net/
http://www.joser.org/

_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users

--

Daniele "MadMage" Calisi
"Your limit is always a bit beyond"