[ros-users] ros-users Digest, Vol 48, Issue 9

[Wrede, Sebastian]

Dear Brian, dear All,

2014-02-17 13:00 GMT+01:00 <ros-users-request at lists.ros.org>:
> * Good: Improving the capabilities of the ROS middleware...
> * Good: Relying on a high-quality existing middleware...
> * Bad: Making ROS code harder to write...
> * Bad: Making ROS systems harder to configure...
> * Bad: Forcing everyone to make a lot of changes...
+1 for this summary and the interesting discussion. From my perspective,
many of the (bad) things mentioned can be compensated for in an
architecture that treats the selection of a specific transport
implementation as a deployment decision based on non-functional
requirements of the system architecture.

Following this idea, we realized in our approach [1] dedicated extension
points for transport and serialization. On that basis, communication
patterns (similar to what Christian mentioned) are implemented with the
effect that the user (code) does not need to know about the details of the
configuration of the underlying transport. Required aspects such as QoS are
exposed to the patterns level but without a dependency to a specific
implementation underneath. Hence, the required configuration for "getting
started" scenarios is kept as simple as possible, while complex setups
allow and require complex configuration for the selected transports.

> * extend ROS middleware by adding transports, as has been done for
> images and by Cedric in the ethzasl_message_transport package.
The mentioned ideas are almost certainly related to what Cedric did but I
suppose that the required abstraction layer for integrating different
transports needs to go beyond pure protocol-level aspects, e.g. it requires
dealing with different wire formats and serialization strategies [2]. This
could probably also provide an avenue for maintaining backward
compatibility with deprecated ROS versions and allows integration with
non-DDS middleware, e.g. from the automation domain. Furthermore, these
extensions would probably require integration with the overall ROS
architecture and would need to be implemented also in other client
languages. Actually, I don't know if this has been done for the
ethzasl_message_transport package.

In any case, it would be great if ROS could provide similar extension
points with clearly defined interfaces and protocols at various levels to
allow collaboration / competition on implementations. Binding ROS to an OMG
standard is one option to achieve this at the transport level, but I wonder
if the IETF inspired process (that Ingo referenced) wouldn't be a better
approach for the specification of a common ecosystem. One could still take
the core DDS functionality as a reference and model the abstract interfaces
accordingly.

More directly geared towards the use of DDS, a couple of further questions
might be:

 * How will services / RPC be implemented with DDS? Is there already an
accepted standard protocol for doing RPC over DDS?
 * What is the status of the open source DDS implementations in terms of
(language bindings x operating system x quality)?
 * Are there any complete implementations of the DDS standard for Python 3?

Best,

Sebastian

[1] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6147617
[2] http://link.springer.com/chapter/10.1007/978-3-642-34327-8_30


---
Dr. Sebastian Wrede                                 phone +49-521-106-5148
Research Institute for Cognition and Robotics (CoR-Lab),
Cognitive Systems Engineering,
Bielefeld University                   http://www.cor-lab.de/users/swrede
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140217/e10cae5a/attachment.html>