<div dir="ltr">Hi Aaron, <div><br></div><div>Thanks for your input. Would you mind reposting this on the ros-sig-ng-ros <a href="https://groups.google.com/forum/?fromgroups#!forum/ros-sig-ng-ros">https://groups.google.com/forum/?fromgroups#!forum/ros-sig-ng-ros</a> that's the best location for discussing the ROS 2.0 efforts. We'd like to keep the ROS 2.0 discussions together so we can have a cohesive archive of the discussions. </div><div><br></div><div>And as announced before I encourage anyone who's interested in this topic to join that SIG. </div><div><br></div><div>Tully</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 14, 2014 at 1:40 PM, Aaron Sims <span dir="ltr"><<a href="mailto:aaron@happyartist.net" target="_blank">aaron@happyartist.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:8pt"><div>
</div><pre><font face="Arial, sans-serif"><font size="3">Dear ROS Teams,</font></font>
<font face="Arial, sans-serif"><font size="3">Thanks for an informative time at ROSCon 2014. I had to leave about an hour and a half early to catch a flight, and I was left with my head spinning about the the decision to change protocols in ROS 2.0. This is an important decision, and I will share my concerns, as well as my thoughts on a direction I personally would of taken with ROS 2.0, and the protocol directions. This topic seems better fit for a blog, however, an open discussion is important. </font></font>
<font face="Arial, sans-serif"><font size="3">First let me say the direction of ROS 2.0 makes sense, the complete shift to ROS DDS protocol does not seem wise. There are many good reasons to implement DDS in ROS, however, the way it is implemented can make or break ROS in the future. </font></font>
<font face="Arial, sans-serif"><font size="3">Many well intended protocol implementations end up at dead ends. Two examples are: </font></font>
<font face="Arial, sans-serif"><font size="3"><a href="http://www.w3.org/Protocols/HTTP-NG/Activity.html" target="_blank">HTTP NG (Next Generation)</a> </font></font>
<font face="Arial, sans-serif"><font size="3"><a href="http://www.w3.org/Protocols/HTTP-NG/Activity.html" target="_blank">http://www.w3.org/Protocols/HTTP-NG/Activity.html</a></font></font>
<font face="Arial, sans-serif"><font size="3"><a href="http://en.wikipedia.org/wiki/Gnutella2" target="_blank">Gnutella 2</a></font></font>
<a href="http://en.wikipedia.org/wiki/Gnutella2" target="_blank"><font face="Arial, sans-serif"><font size="3">http://en.wikipedia.org/wiki/Gnutella2</font></font></a>
<font face="Arial, sans-serif"><font size="3">I'd like to share the approach of the Happy Artist RMDMIA <font color="#000000">RCSM (Robot Control System Messenger) API. The RCSM implements a plugin architecture that allows multiple robot operating system clients to be registered/accessed, run simultaneously, and inter operate together, or simply to plugin a single client such as the Happy Artist ROS Client for TCPROS/UDPROS. As a ROS user this allows any protocol to plugin, and work from any 3rd party vendor DDS implementation, TCPROS/UDPROS, or any other protocol. In the Happy Artist RMDMIA implementation the RCSM component serves as an interface to the rest of the system so that protocols can change, while code written for autonomous/user control follows the same pattern, allowing interchangeability, and forward/backward compatibility between other aspects of the system. If ROS were to approach 2.0
like this, libraries like MoveIt (an example of a library name (no idea if it is tied to TCPROS/UDPROS protocols in ROS 1.0 implementation), could run on any communication protocol without ever needing to know anything about the protocols it was operating on. This approach needs to be applied to all areas of the system so that a user of any component can interchange their libraries to ROS 2.0 for 100% forward, and backward compatibility.</font></font></font>
<font face="Arial, sans-serif"><font size="3"><font color="#000000">I am personally concerned that researchers may find themselves using ROS alternatives due to the time/money that will be lost while they wait for a viable ROS 2.0 solution. Why would a researcher/developer invest resources into a platform that was going to completely change nullifying their personal investment in that platform?</font></font></font>
<font face="Arial, sans-serif"><font size="3"><font color="#000000">It is evident ROS 2.0 needs support similar to ACID transactions for autonomous robotics that the DDS implementation will support (primarily for people safety, and system stability of commercialized autonomous systems). </font></font></font>
<font face="Arial, sans-serif"><font size="3"><font color="#000000">It is a bad, bad idea to throw the current ROS users under the bus in the interim. The implementation architecture direction for ROS 2.0 I am suggesting alleviates this scenario, and allows ROS to backtrack a little with its users to continue improving ROS 1.0 functionality in TCPROS, and UDPROS.</font></font></font></pre><pre><font face="Arial, sans-serif"><font size="3"><font color="#000000">In the interim here are some ROS 1.0 improvements that could greatly improve ROS performance with substantial latency decrease, while increasing data bandwidth:</font></font></font></pre><pre><font face="Arial, sans-serif"><font size="3"><font color="#000000">Add support for UDPROS on every ROS supported client, and server with a few minor enhancements. (Some of these suggestions came out of the BOF at ROSCon discussion on latency and performance, and some I have been attempting to subtly hint at with multiple questions on ROS Answers over the last year).</font></font></font>
<font face="Arial, sans-serif"><font size="3"><font color="#000000"><b>UDP Jumbogram support:</b></font><font color="#000000"> This is a very simple enhancement. Allow unbounded UDP Datagram sizes, and during protocol handshake (XMLRPC negotiation in UDPROS), and add a flag to the publisher configuration that says allow UDP jumbogram support, or specify the maximum datagram size. ROS currently puts their datagram size limit around 1500 bytes. If the system hardware supports jumbograms, the only change is supporting a configurable maximum datagram size. </font></font></font>
<font face="Arial, sans-serif"><font size="3"><font color="#000000"><b>UDP Multicast support:</b></font><font color="#000000"> Adding a header attribute called multicast could allow a topic or service (not aware service is currently supported for UDPROS, but it should be) to configure the associated Publisher to perform a broadcast (A concern of multiple subscribers to a topic causing a major problem with system performance can be alleviated with a feature request by a person in the BOF get together for specifying the numeric limit to subscribers of a particular topic). Note: </font><font color="#000000">(Based on my personal UDPROS implementation experience, adding Multicast support would be fairly simple to add into the Happy Artist Java client, so I assume the same might apply on other platforms that have UDPROS support). </font></font></font>
<font face="Arial, sans-serif"><font size="3"><font color="#000000"><b>Maximum Topic Subscribers support:</b></font><font color="#000000"> Allow the the system designer to specify the maximum number of subscribers on any given topic. The use case given was a high bandwidth topic that multiple users subscribe to and cause the system to hang. The user wanted to implement a UDPROS topic with Multicast support for a single subscriber. Note: Based on my personal knowledge of the CPP client (somewhat limited), the client uses low level arrays rather than Data Collection Objects, therefore the incremental nature of arrays in CPP code should make this task fairly straight forward to implement.</font></font></font>
<font face="Arial, sans-serif"><font size="3"><font color="#000000">If you have any questions or would like to have further discussion, I look forward to discussion.<br><br>Sincerely,<br><br>Aaron</font></font></font></pre><div><br></div></div></div><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>