[ros-users] ROS & DDS

Brian Gerkey gerkey at osrfoundation.org
Sun Feb 16 18:35:58 UTC 2014

This is a great thread!  I've missed these passionate discussions.
And all it took was asking a seemingly simple question.

Here's my view of the consensus so far (I'm trying not to draw any
conclusions; just restating what's been said):

* Good: Improving the capabilities of the ROS middleware, such as
adding QoS features.  The ROS middleware is nice, but QoS and
reliability in general are notably absent.

* Good: Relying on a high-quality existing middleware, perhaps DDS.
ZeroMQ also came up, but with the caveat that it only does the
socket-handling, so you have to add your own discovery and marshaling,
as well as QoS, if you care about that.

* Bad: Making ROS code harder to write (e.g., by forcing everyone to
use the full DDS API, which is quite verbose).  For the common case,
the code should be as simple as it is now in ROS.

* Bad: Making ROS systems harder to configure (e.g., by forcing
everyone to become an expert in the DDS XML configuration system).
For the common case, everything should just work out of the box.

* Bad: Forcing everyone to make a lot of changes to their existing ROS
code to adapt to updates in ROS, even when they don't care about the
new features brought about by those updates (e.g., roslisp code, which
doesn't care about QoS, should just keep working, no matter what).
Whatever changes are made, the transition path must be easy, including
the option to not make the transition but keep using ROS.

Other proposals have been made, including:
* simplify ROS middleware to speak HTTP; and
* extend ROS middleware by adding transports, as has been done for
images and by Cedric in the ethzasl_message_transport package.

It has been suggested that DDS, like CORBA before it, is overly
(perhaps pointlessly) complex, and the fact that we would need to hide
its complexity from most users should give us pause.  On the other
hand, it's also been suggested that it's good practice to hide the
complexity and details of any middleware, to allow for a separation of


On Sun, Feb 16, 2014 at 8:02 AM, Ingo Lütkebohle <iluetkeb at gmail.com> wrote:
> Hi Christian,
> I general agree with your suggestions. In particular, I think it is
> definitely possible to present a user interface that the ROS community
> will like, or even the same as currently, based on an established
> middleware package. I am *also* positive that doing so won't be easy,
> but it can be done.
> That said, I think there is one other concern that people have: That
> the underlying platform, even if well encapsulated, might still cause
> issues. This is, in my opinion, a serious and well-founded concern
> supported by lots of evidence in that past! If there is a lot of
> complexity beneath that implements all sorts of features, this will
> typically also affect the somple code-paths. If nothing else, more
> code usually means more bugs, and if there is a bug, encapsulation
> usually helps not at all.
> Moreover, I would like to mention one thing that is routinely
> forgotten by people working with high-end middleware: Installation is
> often not trivial at all! Many of the DDS packages mentioned here are
> not available as part of a standard Linux distribution, and supporting
> them through packages might have licensing issues. For example, the
> OpenSplice Community Edition is LGPL, not BSD.
> I'm am sure all of these concerns can be addressed, but only if we
> look at them, instead of focusing on API issues only!
> Cheers,
> On Sun, Feb 16, 2014 at 9:16 AM, Christian Schlegel <schlegel at hs-ulm.de> wrote:
>> Hi,
>> "freedom of choice" is what general purpose tools like CORBA etc. provide. They give no guidance which parts to use in what situation. They require far too much knowledge from standard users but provide all you need for experts (framework builder, all kinds of domains, etc., all kinds of interoperable implementations of the standards).  You never ever should expose these to the domain experts that is the robotics experts.
>> "freedom from choice" is what we provide by a domain-specific presentation of those artefacts along with their proper configuration. We present communication patterns with an agreed semantics and all the mapping onto standard middleware is hidden (including which CORBA, DDS, ACE, zeroMQ etc. concepts are selected and how they are configured). Thus, the abstraction is NOT presenting everything of DDS and/or CORBA in a simplified way but in a domain-specific way: such how robotics people want to have their presentation.
>> Exactly this helped us to seamlessly migrate from CORBA to ACE without exposing anything of that to the robotics user!
>> Christian
>> ---
>> 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.zafh-servicerobotik.de/
>> http://www.youtube.com/user/roboticsathsulm
>> http://smart-robotics.sourceforge.net/
>> http://www.joser.org/
>>> Am 16.02.2014 um 00:19 schrieb "Michael Zillich" <zillich at acin.tuwien.ac.at>:
>>> Hi,
>>> my two cents regarding this discussion come from experiences with
>>> another "industry-standard" middleware, that was somewhat ... complex
>>> internally and thus typically was hidden under layers of convenience
>>> code: the abominable CORBA.
>>> (I ended up writing my own middleware after CORBA nearly killed a project)
>>> I have to admit I know nothing about DDS, so forgive me if I unjustly
>>> critizise it. But reading in some of the ongoing discussions that its
>>> complexity can easily be handled by some abstraction layer .. that rang
>>> an alarm bell.
>>> If something is too complex to use for the intended target audience of
>>> developers, and thus has to be hidden behind another layer (which, trust
>>> me, inevitably leads to the most hilarious bugs you can possibly
>>> imagine) then it is probably the wrong technology for that application
>>> area. (But there are certainly other appliction areas where this
>>> middleware is the perfect choice).
>>> So my personal choice is always a clear and simple solution targeted at
>>> a specific application area (with specific requirements, problems, and
>>> development procedures and cycles) rather than a
>>> solves-all-and-everyones-problems solution developled by large committees.
>>> cheers,
>>> Michael
>>> p.s. For those interested in the CORBA story read the enlightening
>>> article by Michi Henning
>>>   https://queue.acm.org/detail.cfm?id=1142044
>>> who as one of the authors of "Advanced CORBA Programming with C++" is
>>> probably one of the only two persons on the planet, who actually
>>> understood CORBA (the other person being Steve Vinoski, the other author
>>> of the book).
>>> --
>>> Dr. Michael Zillich
>>> ACIN Institute of Automation and Control
>>> Vienna University of Technology
>>> (DVR-Number 0005886)
>>> Gusshausstr 27-29/E376, 1040 Vienna, Austria
>>> zillich at acin.tuwien.ac.at    http://users.acin.tuwien.ac.at/mzillich
>>> Tel: +43 1 58801 376648        Fax: +43 1 58801 37698
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at lists.ros.org
>>> http://lists.ros.org/mailman/listinfo/ros-users
>> _______________________________________________
>> ros-users mailing list
>> ros-users at lists.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
> --
> Ingo Lütkebohle, Dr.-Ing.
> Machine Learning and Robotics Lab, IPVS, Universität Stuttgart
> http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle
> +49-711-685-88350
> PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users

More information about the ros-users mailing list