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"?
The example of the "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