[ros-users] ROS & DDS

Jonathan Bohren jonathan.bohren at gmail.com
Fri Feb 14 15:12:20 UTC 2014

As others have said, usability is critical, and the ROS learning curve has
only been getting steeper and steeper.

A lot of people have been saying for a long time that updating the
transport layer would dramatically improve the performance of all ROS
systems. I see a lot of standards that have been explored which would see
the entire transport layer re-implemented, but there are simpler things
that could be done like just adding UDP multicast as has been done in the
ethzasl_message_transport stack [1]. This stack serves as an example of how
to override the normal transport in a case where it needs to be optimized.
In the end, I think whatever "default" settings get used for the ROS
transport need to be as "good enough" for beginners as the current defailts
without having to specify on what kind of network connection your computers
are connected.

Regardless of how the transport layer or APIs get modified, Nicholas makes
a good point:

On Fri, Feb 14, 2014 at 9:14 AM, Armstrong-Crews, Nicholas - 1002 - MITLL <
nickarmstrongcrews at ll.mit.edu> wrote:

> Doing it right will take some work, but I think it'll be worth it to enough
> people, and the advanced features can be spooled out incrementally over
> time.

I'd like to add to this that any significant change in the way ROS is used
(like this) should necessitate a usability study with users who aren't
directly involved in the changes. Most of the ROS core was subject to
Willow's "Milestone 3" push [2] to document and verify the usability of
nearly 200 packages in 2010. Newer core utilities like Catkin haven't
benefited from such a broad push. This lack of a broad usability study has
both the effect of a software tool that is harder to use and necessitates
much more engineering effort from the designers to modify after it has been

[1] http://wiki.ros.org/ethzasl_message_transport


On Fri, Feb 14, 2014 at 9:20 AM, Christian Schlegel <schlegel at hs-ulm.de>wrote:

> Hi,
> Indeed, ease of use is decisive but it should not come with ignoring major
> technical needs (complex robotic systems depend on advanced technologies
> like those from domains like distributed systems and software engineering).
> Again:
> communication patterns provide two views.
> One is a precise interface and semantics exposed to the robotics
> community. Make their live as simple as possible and match their needs.
> The other is the interface to the underlying middleware which is not seen
> by robotics users but just by framework builders and middleware experts.
> They do all the mappings duch that the agreed semantics remains the same
> whatever middleware mapping you prefer. They keep the middleware away from
> the robotics people!
> This way, it is also completely transparent to the robotics community
> which mapping you prefer and how finally messages are transmitted (even in
> "any" types of DDL)
> The way to go is to introduce this separation of concerns: precise
> semantics and stable interfaces for robotics people and internal stable
> interfaces towards middleware used by framework builders, middleware
> experts to map communication patterns but not visible to robotics.
> 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 14.02.2014 um 15:05 schrieb "Ryan Gariepy" <
> rgariepy at clearpathrobotics.com>:
> >
> > Ease of use is *critical*. We're already receiving regular feedback
> > that the usability of ROS is getting worse with each distribution.
> >
> > -Ryan
> >
> >> On Fri, Feb 14, 2014 at 8:43 AM, Ingo Lütkebohle <iluetkeb at gmail.com>
> wrote:
> >>> On Fri, Feb 14, 2014 at 2:27 PM, Edwards, Shaun M. <sedwards at swri.org>
> wrote:
> >>> My main concerns is Geoffrey Biggs' comment below.  Tuning should be a
> dirty
> >>> word in software.  I know it's needed, but successful software just
> works.
> >>> Ease of use should always be our focus.  It is this single issue that
> has
> >>> been the nail in the coffin of every middleware I have used.
> >>
> >> I agree on that.
> >>
> >> One could reasonably argue that the attempt to solve the communication
> >> problem in a relatively application-independent manner is doomed, and
> >> that application-specific protocols are the way to go. Some people may
> >> dismiss that as unrealistic, but I would argue that
> >> application-specific protocols are the IETF approach, and that it has
> >> been fairly successful, so far.
> >>
> >> That said, there is a question of what the basis for such developments
> >> should be, or, in other words, whether the protocols in the DDS family
> >> are a better foundation for robotics applications than base-level
> >> TCP/IP.
> >>
> >> I guess answers to that question will be influenced significantly by
> >> whether you're coming from an enterprise environment, or from an open
> >> systems environment.
> >>
> >> cheers
> >>
> >> --
> >> 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
> > _______________________________________________
> > 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

Jonathan Bohren
Laboratory for Computational Sensing and Robotics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140214/564ce986/attachment.html>

More information about the ros-users mailing list