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