[ros-users] The future of ROS 2.0 protocol changes

[Jenkins, Odest Chadwicke]

Hi Tully,

I would like this discussion to continue on ros-users and address Aaron's
core question:

"Why would a researcher/developer invest resources into a platform that was
going to completely change nullifying their personal investment in that
platform?"

This is a huge question and source of uncertainty for current ROS users.
 As stated, this decision "can make or break ROS in the future."  Given the
constant changes in ROS from distribution to distribution, it is unclear
whether this change of protocol will lead to greater stability and
interoperability, or become a unwise investment of time and resources.

ROS has been an invaluable contribution to moving robotics forward.  Your
work and the work of OSRF has enabled a large ecosystem of open-source
robotics, which is tremendously appreciated.  Within that ecosystem, many
people have care deeply about ROS.  They have invested themselves in ROS
and its future.

Thus, pushing this discussion off to a SIG list would a disservice to those
of us who are concerned about this core question in possibly transitioning
between ROS and ROS 2.0.

-Chad

Date: Sun, 14 Sep 2014 14:58:29 -0700
From: Tully Foote <tfoote at osrfoundation.org>
To: Aaron Sims <aaron at happyartist.net>, User discussions
        <ros-users at lists.ros.org>
Subject: Re: [ros-users] The future of ROS 2.0 protocol changes
Message-ID:
        <CAM7qi7UwvjVjYtSbnpMrUcAKg1yO=qeAjDhNKN0H_Ldo3+rFZQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Aaron,

Thanks for your input. Would you mind reposting this on the ros-sig-ng-ros
https://groups.google.com/forum/?fromgroups#!forum/ros-sig-ng-ros 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.

And as announced before I encourage anyone who's interested in this topic
to join that SIG.

Tully

On Sun, Sep 14, 2014 at 1:40 PM, Aaron Sims <aaron at happyartist.net> wrote:

> Dear ROS Teams,
> 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.
> 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.
> Many well intended protocol implementations end up at dead ends. Two
examples are: HTTP NG (Next Generation) <
http://www.w3.org/Protocols/HTTP-NG/Activity.html>
http://www.w3.org/Protocols/HTTP-NG/Activity.htmlGnutella 2 <
http://en.wikipedia.org/wiki/Gnutella2>
http://en.wikipedia.org/wiki/Gnutella2
> I'd like to share the approach of the Happy Artist RMDMIA 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.
> 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?
> 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).
> 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.
>
> In the interim here are some ROS 1.0 improvements that could greatly
improve ROS performance with substantial latency decrease, while increasing
data bandwidth:
>
> 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).
>
> *UDP Jumbogram support:* 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.
> *UDP Multicast support:* 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: (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).
> *Maximum Topic Subscribers support:* 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.
> If you have any questions or would like to have further discussion, I
look forward to discussion.
>
> Sincerely,
>
> Aaron
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140915/934df43e/attachment.html>