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@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 > 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 > > > > > > > > > _______________________________________________ > 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