[ros-users] ROS & DDS

Sat Feb 15 14:58:27 UTC 2014

I don't think it's a matter of *if* the complexity can be hidden, it's that
there are ways to design this such that the complexity is hidden, and there
are ways to design this such that the complexity is necessary to face for
people to even write a node. I believe the common thread here is that we
need to push to keep the basic interface (in whatever form it may take) at
the current level of simplicity or simpler.

There was a comment early on about areas where DDS is unsuitable for
robotics applications. Could someone expand on that?

On Sat, Feb 15, 2014 at 9:40 AM, Christian Schlegel <schlegel at hs-ulm.de>wrote:

>  Hi,
>
> really interesting to me that ease of use, user experience, make it simple
> for robotics people is seen (partly) in conflict with using more advanced
> middleware systems.
>
> "separation of concerns" exactly allows to hide compexity because robotics
> people should not be bothered with middleware complexity. That does not
> mean that you can only have simple middleware systems beneath the
> presentation to the robotics user. It also does not mean that you have to
> think about QoS all the time. If you do not give any parameters with
> respect to QoS, you just experience a best effort behavior. If you prefer
> to have all components on a single microcontroller (no need for
> networking), you can even have your communication patterns mapped onto
> something with very small footprint.
>
> What is the approach of "communication patterns"?
>
>    - look here for a short explanation:
>    http://www.servicerobotik-ulm.de/drupal/?q=node/39
>    - look then at "send", "query", "push newest", "push timed", "event",
>    "wiring", "state"
>
> The example of the "query pattern":
> [image: Figure: Query Pattern]
>  The "client" shows what you see as a robotics expert at the client side
> of a service that is composed out of a "query client". You can invoke a
> query either synchronously or asynchronously by just calling these methods.
>
> The "server" shows what you see as a robotics expert at the server side of
> a service that is composed out of a "query server". Each incoming query is
> forwarded to a handler, you can do any processing, even forward it to a
> processing pipeline, since the answer is finally provided by calling
> "answer".
>
> That is all. The messages / the protocol behind that interaction
> ("system") is not visible to you. That protocol is exactly what is mapped
> onto whatever middleware system. This abstraction does not polute your
> robotics user view with any kind of middleware specifics. Thus, the very
> same semantics, the very same interfaces to these patterns are maintained
> whatever mapping you prefer.
>
> Of course, you can come up with ideas of mapping that hidden protocol onto
> DDS, onto CORBA, onto sockets or even onto global variables / shared
> memory.  You can even think about interoperability of the messages used
> within the protocol between different middleware systems. Again, no effect
> at the user interface visible to robotics experts.
>
> Of course, I should say more about the marshalling (also hidden and
> transparent) but please have a look at SmartSoft Communication Patterns,
> they are in operation on various robots, on different platforms, on
> different middleware systems. Supporting them by a MDSD approach even makes
> it much easier to use them:
>
> http://youtu.be/04SqzrS6Udw
>
> Of course, the above user interfaces do not yet comprise QoS attributes
> but that is work in progress. How to map the QoS attributes onto DDS
> configurations is done by framework experts and NOT by the robotics user.
> This is the same as a robotics user should not play around with socket
> properties, buffer capacities etc. (polute his code or his deployment and
> modify the semantics of the communication patterns)
>
> Christian
>
>
> Am 15.02.2014 06:48, schrieb Benjamin Johnston:
>
> 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
>
>
>
>  --
> Prof. Dr. Christian Schlegel
> Prodekan, Studiendekan Master IS
> Fakultät Informatik
> Hochschule Ulm
>
> Tel.: 0731 / 50-28242
> http://www.hs-ulm.de/schlegelhttp://www.servicerobotik-ulm.de/http://www.zafh-servicerobotik.de/ (Sprecher)
> http://www.youtube.com/user/roboticsathsulmhttp://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140215/00f83b71/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: query.png
Type: image/png
Size: 15765 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140215/00f83b71/attachment.png>