<div dir="ltr">I agree with Christian Schlegel on the following points:<div>- 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.</div>
<div>- 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 (<a href="http://openrdk.sf.net">http://openrdk.sf.net</a>), 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.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 10:14 AM, Christian Schlegel <span dir="ltr"><<a href="mailto:schlegel@hs-ulm.de" target="_blank">schlegel@hs-ulm.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Dear Brian,<br>
<ul>
<li>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.</li>
</ul>
<p>Let me give some more hints:<br>
</p>
<ul>
<li>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!</li>
<li>"freedom from choice" instead of "freedom of choice":<br>
</li>
<ul>
<li>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.</li>
<li>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<br>
</li>
</ul>
<li>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"<br>
</li>
</ul>
<a href="http://www.intechopen.com/books/robotic-systems-applications-control-and-programming/robotic-software-systems-from-code-driven-to-model-driven-software-development" target="_blank">http://www.intechopen.com/books/robotic-systems-applications-control-and-programming/robotic-software-systems-from-code-driven-to-model-driven-software-development</a><br>
<br>
Christian<div class=""><br>
<br>
<br>
Am 12.02.2014 17:56, schrieb Brian Gerkey:<br>
</div></div>
<blockquote type="cite">
<pre>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; <a href="http://portals.omg.org/dds/" target="_blank">http://portals.omg.org/dds/</a>). 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
<a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72">--
Prof. Dr. Christian Schlegel
Prodekan, Studiendekan Master IS
Fakultät Informatik
Hochschule Ulm
Tel.: 0731 / 50-28242
<a href="http://www.hs-ulm.de/schlegel" target="_blank">http://www.hs-ulm.de/schlegel</a>
<a href="http://www.servicerobotik-ulm.de/" target="_blank">http://www.servicerobotik-ulm.de/</a>
<a href="http://www.zafh-servicerobotik.de/" target="_blank">http://www.zafh-servicerobotik.de/</a> (Sprecher)
<a href="http://www.youtube.com/user/roboticsathsulm" target="_blank">http://www.youtube.com/user/roboticsathsulm</a>
<a href="http://smart-robotics.sourceforge.net/" target="_blank">http://smart-robotics.sourceforge.net/</a>
<a href="http://www.joser.org/" target="_blank">http://www.joser.org/</a></pre>
</div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Daniele "MadMage" Calisi<br><i>"Your limit is always a bit beyond"</i></div>
</div>