[ros-users] ROS & DDS
Nikolai Ensslen
nensslen at synapticon.com
Thu Feb 13 11:38:11 UTC 2014
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
--
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 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/51e030e4/attachment.html>
More information about the ros-users
mailing list