[ros-users] ROS & DDS

Sat Feb 15 14:40:03 UTC 2014

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":
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/schlegel
http://www.servicerobotik-ulm.de/
http://www.zafh-servicerobotik.de/ (Sprecher)
http://www.youtube.com/user/roboticsathsulm
http://smart-robotics.sourceforge.net/
http://www.joser.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140215/347fd696/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/347fd696/attachment.png>