<div dir="ltr">Dear Brian, dear All,<br><br>2014-02-17 13:00 GMT+01:00 <<a href="mailto:ros-users-request@lists.ros.org">ros-users-request@lists.ros.org</a>>:<br>> * Good: Improving the capabilities of the ROS middleware...<br>
> * Good: Relying on a high-quality existing middleware...<br>> * Bad: Making ROS code harder to write...<br>> * Bad: Making ROS systems harder to configure... <br>> * Bad: Forcing everyone to make a lot of changes...<br>
+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. <br>
<br>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. <br>
<br>> * extend ROS middleware by adding transports, as has been done for<br>> images and by Cedric in the ethzasl_message_transport package. <br>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.<br>
<br>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.<br>
<br>More directly geared towards the use of DDS, a couple of further questions might be:<br><br> * How will services / RPC be implemented with DDS? Is there already an accepted standard protocol for doing RPC over DDS? <br>
* What is the status of the open source DDS implementations in terms of (language bindings x operating system x quality)?<br> * Are there any complete implementations of the DDS standard for Python 3?<br><br>Best,<br><br>
Sebastian<br><br>[1] <a href="http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6147617">http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6147617</a><br>[2] <a href="http://link.springer.com/chapter/10.1007/978-3-642-34327-8_30">http://link.springer.com/chapter/10.1007/978-3-642-34327-8_30</a><br>
<br><br><div>---</div><div><span style="font-family:arial,sans-serif;font-size:13px">Dr. Sebastian Wrede phone +49-521-106-5148</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">Research Institute for Cognition and Robotics (CoR-Lab),</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">Cognitive Systems Engineering,</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">Bielefeld University </span><a href="http://www.cor-lab.de/users/swrede" target="_blank" style="font-family:arial,sans-serif;font-size:13px">http://www.cor-lab.de/users/swrede</a><br>
</div><div><br></div></div>