[ros-users] The future of ROS 2.0 protocol changes
Mike Purvis
mpurvis at clearpathrobotics.com
Mon Sep 15 15:29:32 UTC 2014
I appreciated the talks from Dirk and William about the DDS decision and
the future of the APIs— I like the look of this future, especially the
effort to unify node/nodelet APIs so that the decision to run nodes in many
processes vs one is made at launch time rather than at authoring time.
I don't feel at all thrown under the bus by DDS/2.0; much as we did with
catkin, Clearpath will continue to use the legacy tools for a period of
time while we evaluate the new hotness, and then gradually switch our
software over, probably beginning with peripheral drivers and generic
components, and finishing with the platform software itself.
That said, some concerns:
- As raised during the Q&A, it is critical that ROS 2.0 reverse the
trend of making each ROS release harder and harder to get into, learn
about, and get started with. Given the state of things presently, it's a
very legitimate concern that a further fracturing of documentation/tutorial
effort could render ROS 2.0 completely inaccessible to anyone who was not
already an expert in ROS 1.x. It'll be important than the majority of
documentation explaining ROS 2.0 is targeted at non-users, not migrating
ROS 1.0 users.
- Along these same lines, the installation
<http://wiki.ros.org/indigo/Installation/Ubuntu> needs to get shorter
and simpler— rosdep, rosinstall, and wstool should be installed
automatically, and the rosdep (xylem?) init/update should be part of its
install, not a separate step. For ROS 2.0's supported platforms, I feel we
should strive to offer a "one step setup", perhaps a homebrew-like python
-e "$(curl -fsSLhttps://ros.org/install)", or a downloadable "install
deb" with an installation walk-through. Power users might still prefer to
do everything their own way, but for the majority, especially those getting
started for the first time, I feel strongly that it should be a one-click
affair.
- I'm unsure if the future of ROS community docs are the wiki or some
version-controlled sphinx-type thing, but either way, having a ROS1/2
switcher like the rosbuild/catkin one isn't enough. There are still
rosbuild-centric tutorial pages on the ROS wiki— how about a warning box
which appears automatically on wiki pages which haven't been thumb-upped in
the last 6 months, perhaps combined with a "hot list" page that shows
warning boxed pages sorted by traffic to them. (This doesn't need to wait
for ROS 2.0; it would be great to have immediately...)
- ROS is more than just a generic publish/subscribe middleware— a lot
more. I'm glad to hear about the intent to fix the parameter service, but
what about issues specific to robotics, like runtime dynamic URDF, or
multimaster? These are tough problems, and it'd be great to see OSRF take a
really active role in solving these, either by spearheading development, or
providing direct counsel-to and endorsement-of other groups working on
these. ROS is long overdue for an officially-blessed "do your multi-robot
system *this* way", where "this way" is a solution which handles
discovery, reasonably propagates namespaced, rate-limited TF data, and is
also not completely different in simulation.
Hope that's helpful. Thanks again for a great ROSCon.
Mike
On 15 September 2014 10:11, Brian Gerkey <gerkey at osrfoundation.org> wrote:
> hi Chad, Ingo,
>
> It works for me to have to this discussion on ros-users at . Folks who
> aren't interested can ignore it.
>
> To Aaron's question:
>
> "Why would a researcher/developer invest resources into a platform that
> was going to completely change nullifying their personal investment in that
> platform?"
>
> My answer is: we're not nullifying anything in our work on ROS 2.0, nor is
> everything completely changing. As Dirk explained in his ROSCon talk on
> Friday: our goal with ROS 2.0 is to address specific shortcomings of ROS
> 1.0, as requested by the community for many years, among them: multi-robot
> systems and single-master in general, real-time communication, quality of
> service, lossy networks, and the robustness/trust/faith required to deploy
> ROS into a production environment. After extensive research and
> consideration (some of which is documented at the ROS 2.0 design site:
> http://design.ros2.org/), we decided that the best technical approach to
> address these shortcomings is to build ROS 2.0 atop DDS. William's talk
> later on Friday got more into the details of how that DDS-based system will
> look and work. (We'll get the videos of talks posted ASAP for everyone to
> see; that might happen this week.)
>
> Now, we're under no illusion that the community will switch wholesale to
> ROS 2.0 next year when it's ready. To the contrary, we committed with the
> release of Indigo as our first LTS distro to support ROS as it exists today
> for 5 years. ROS 2.0 won't replace ROS 1.0, but rather will live alongside
> it, with tools in place to allow the two systems to communicate (through
> bridges and/or library shims), and to assist with porting existing code to
> new APIs.
>
> Rather than nullifying current development efforts, we're laying the
> groundwork for those efforts to have greater impact in the future by, with
> some porting and/or bridging efforts, taking advantage of new core
> capabilities. Of course, if those new capabilities are not important to
> you, you can happily ignore them and continue with your existing ROS 1.0
> system, the behavior of which won't change.
>
> brian.
>
> On Mon, Sep 15, 2014 at 6:07 AM, Ingo Lütkebohle <iluetkeb at gmail.com>
> wrote:
>
>> I think Odeste has a point in requesting that the core question is
>> answered here.
>>
>> That said, my original understanding was that, while new APIs are
>> introduced, there would be backwards compatibility. For example,
>> design.ros2.org site states
>> "But fear not: there will be mechanisms in place to allow ROS 2.0 code to
>> coexist with existing ROS code. At the very least, there will be
>> translation relays that will support run-time interactions between the two
>> systems. And it is possible that there will be library shims that will
>> allow existing ROS code to compile/run against ROS 2.0 libraries, with
>> behavior that is qualitatively similar to what is seen today."
>>
>> If that happens, it seems as if that should be okay for existing ROS
>> users who are for some reason unable or unwilling to migrate to the new
>> APIs.
>>
>> I was not personally at ROSCon this year, but was there anything said
>> that contradicts this statement?
>>
>>
>> On Mon, Sep 15, 2014 at 2:59 PM, Jenkins, Odest Chadwicke <
>> cjenkins at cs.brown.edu> wrote:
>>
>>>
>>> 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
>>> >
>>> >
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at lists.ros.org
>>> http://lists.ros.org/mailman/listinfo/ros-users
>>>
>>>
>>
>>
>> --
>> Ingo Lütkebohle, Dr.-Ing.
>>
>> PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at lists.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> 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/bf3ca8c2/attachment.html>
More information about the ros-users
mailing list