[ros-users] ROS & DDS

Benjamin Johnston Benjamin.Johnston at uts.edu.au
Sat Feb 15 05:48:07 UTC 2014


The recent discussions have been very interesting. Thanks!

I've not used DDS in practice so I'm only responding based on my [superficial] reading of the DDS specifications.

I would suggest the *opposite* to DDL. I would suggest that ROS could be simplified. A simplified ROS could be used on local networks. Keeping things very simple would ensure low barriers of entry for students and hobbyists. More sophisticated middleware could talk to the simple ROS nodes, connecting ROS sites over low-latency or low-bandwidth links and within large swarms of robots.

How could ROS be simplified? For example, subscribing to /tf could be achieved by a simple HTTP GET http://master/tf. The master can redirect to the slave, and the slave redirect to the TCPROS endpoint, using HTTP 303 redirects. The TCPROS endpoint could serve its headers as ordinary HTTP headers and then serve the message stream using an encoding that has widespread language support (perhaps IDL, protobuf, XMLRPC or JSON). This would allow a new ROS user to inspect a topic using just a web-browser and also vastly simplify the process of connecting to ROS from other languages. Not to mention the possibility of using Apache/Nginx or arbitrary websites as ROS nodes out-of-the-box!

Solutions to the problem of site-to-site and low-bandwidth communications could then be provided by many competing ROS packages rather than as a core part of ROS itself. Where control of buffering, deadline, durability and liveliness is desired, then DDS might serve as the technology to bridge/proxy between sites. Another package might, instead, offer 1-in-n message sampling or even image resampling to more predictably throttle image streams over slow links. The installation and (complex) configuration of these packages would only be needed for sites that choose to go down this path. Furthermore, by having a simplified ROS on the local sites, it would be easier for middleware developers to integrate their middleware technologies as a site-to-site bridging/proxy transport for ROS.

As for DDS itself. It is a rather complex protocol and my reading of the specification is that it has a quite different philosophy to that of ROS. To switch to DDS "properly" would involve major rewrites and significant rethinking of the idioms in ROS development. For example, my understanding is that DDS lacks synchronous services and it also seems that DDS is based on distributing and updating data *objects* over message passing rather than being purely about message passing. These would not be insurmountable but I would fear that switching to DDL would basically mean either misusing DDS or starting a new ROS competitor and hoping that users follow rather than smoothly enhancing what already exists through a straightforward upgrade path.

What I love about ROS is that it has so far been focused on the software experience rather than the hardware. It almost seems like a contradiction to be worrying about QoS when much of your code is Python scripts and other higher-level languages (instead of C) running on Ubuntu (instead of a RTOS). I'm certainly not saying that QoS is unimportant -- it would be very nice to have -- but I would place simplicity as a higher priority. Maybe ROS Industrial would be a better place for DDS or baked-in QoS?

-Ben

________________________________________
From: ros-users-bounces at lists.ros.org [ros-users-bounces at lists.ros.org] On Behalf Of Brian Gerkey [gerkey at osrfoundation.org]
Sent: Thursday, February 13, 2014 3:56 AM
To: User discussions
Subject: [ros-users] ROS & DDS

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

UTS CRICOS Provider Code: 00099F
DISCLAIMER: This email message and any accompanying attachments may contain confidential information.
If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or
attachments. If you have received this message in error, please notify the sender immediately and delete
this message. Any views expressed in this message are those of the individual sender, except where the
sender expressly, and with authority, states them to be the views of the University of Technology Sydney.
Before opening any attachments, please check them for viruses and defects.

Think. Green. Do.

Please consider the environment before printing this email.


More information about the ros-users mailing list