Discussion:
The future of ROS 2.0 protocol changes
Aaron Sims
2014-09-14 20:40:17 UTC
Permalink
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: HTT
P NG (Next Generation) http://www.w3.org/Protocols/HTTP-NG/Activity.html Gnutella 2 http://en.wikipedia.org/wiki/Gnutella2 I'd like to share the approach of the Happy
Artist RMDMIARCSM (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 c
ommercialized 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 attri
bute 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 suppor
t 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
Tully Foote
2014-09-14 21:58:29 UTC
Permalink
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
Post by Aaron Sims
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.
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
http://lists.ros.org/mailman/listinfo/ros-users
Jenkins, Odest Chadwicke
2014-09-15 12:59:19 UTC
Permalink
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-GsQoM64suCGGJGYlWa3Ukdi2O/***@public.gmane.org>
To: Aaron Sims <aaron-0KzpBRKCo+***@public.gmane.org>, User discussions
<ros-users-g9ZBwUv/***@public.gmane.org>
Subject: Re: [ros-users] The future of ROS 2.0 protocol changes
Message-ID:
<CAM7qi7UwvjVjYtSbnpMrUcAKg1yO=qeAjDhNKN0H_Ldo3+rFZQ-JsoAwUIsXosN+***@public.gmane.org>
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
Post by Aaron Sims
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.
Post by Aaron Sims
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.
Post by Aaron Sims
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
Post by Aaron Sims
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
Post by Aaron Sims
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.
Post by Aaron Sims
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?
Post by Aaron Sims
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).
Post by Aaron Sims
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.
Post by Aaron Sims
In the interim here are some ROS 1.0 improvements that could greatly
improve ROS performance with substantial latency decrease, while increasing
Post by Aaron Sims
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).
Post by Aaron Sims
*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.
Post by Aaron Sims
*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).
Post by Aaron Sims
*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.
Post by Aaron Sims
If you have any questions or would like to have further discussion, I
look forward to discussion.
Post by Aaron Sims
Sincerely,
Aaron
_______________________________________________
ros-users mailing list
http://lists.ros.org/mailman/listinfo/ros-users
Ingo Lütkebohle
2014-09-15 13:07:04 UTC
Permalink
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 <
Post by Jenkins, Odest Chadwicke
Hi Tully,
I would like this discussion to continue on ros-users and address Aaron's
"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
Subject: Re: [ros-users] The future of ROS 2.0 protocol changes
<CAM7qi7UwvjVjYtSbnpMrUcAKg1yO=
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
Post by Aaron Sims
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.
Post by Aaron Sims
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.
Post by Aaron Sims
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
Post by Aaron Sims
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
Post by Aaron Sims
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.
Post by Aaron Sims
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?
Post by Aaron Sims
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).
Post by Aaron Sims
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.
Post by Aaron Sims
In the interim here are some ROS 1.0 improvements that could greatly
improve ROS performance with substantial latency decrease, while increasing
Post by Aaron Sims
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).
Post by Aaron Sims
*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.
Post by Aaron Sims
*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).
Post by Aaron Sims
*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.
Post by Aaron Sims
If you have any questions or would like to have further discussion, I
look forward to discussion.
Post by Aaron Sims
Sincerely,
Aaron
_______________________________________________
ros-users mailing list
http://lists.ros.org/mailman/listinfo/ros-users
_______________________________________________
ros-users mailing list
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
Brian Gerkey
2014-09-15 15:11:44 UTC
Permalink
hi Chad, Ingo,

It works for me to have to this discussion on ros-***@. 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.
Post by Ingo Lütkebohle
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 <
Post by Jenkins, Odest Chadwicke
Hi Tully,
I would like this discussion to continue on ros-users and address Aaron's
"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
Subject: Re: [ros-users] The future of ROS 2.0 protocol changes
<CAM7qi7UwvjVjYtSbnpMrUcAKg1yO=
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
Post by Aaron Sims
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.
Post by Aaron Sims
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.
Post by Aaron Sims
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
Post by Aaron Sims
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
Post by Aaron Sims
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.
Post by Aaron Sims
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?
Post by Aaron Sims
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).
Post by Aaron Sims
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.
Post by Aaron Sims
In the interim here are some ROS 1.0 improvements that could greatly
improve ROS performance with substantial latency decrease, while increasing
Post by Aaron Sims
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).
Post by Aaron Sims
*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.
Post by Aaron Sims
*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).
Post by Aaron Sims
*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.
Post by Aaron Sims
If you have any questions or would like to have further discussion, I
look forward to discussion.
Post by Aaron Sims
Sincerely,
Aaron
_______________________________________________
ros-users mailing list
http://lists.ros.org/mailman/listinfo/ros-users
_______________________________________________
ros-users mailing list
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
http://lists.ros.org/mailman/listinfo/ros-users
Jonathan Bohren
2014-09-15 15:27:54 UTC
Permalink
Post by Brian Gerkey
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.
What I gathered from Aaron's initial post is that an open question is
whether or not ROS 1.x will continue to be enhanced and/or if OSRF has the
bandwidth to organize contributions which enhance it in the ways he
described. Over in ros-sig-ng-ros, I mentioned that there are currently a
bunch of enhancements floating around which either not been fully fleshed
out or have not been integrated into the ROS 1.x core. These include, but
are not limited to UDP Multicast Support [1] and a ZeroMQ-based backend
which improves performance [2].

[1] http://wiki.ros.org/ethzasl_message_transport
[2] https://github.com/esteve/ros_comm/tree/zeromq_thrift

-jon
Brian Gerkey
2014-09-15 15:55:35 UTC
Permalink
Post by Jonathan Bohren
What I gathered from Aaron's initial post is that an open question is
whether or not ROS 1.x will continue to be enhanced and/or if OSRF has the
bandwidth to organize contributions which enhance it in the ways he
described. Over in ros-sig-ng-ros, I mentioned that there are currently a
bunch of enhancements floating around which either not been fully fleshed
out or have not been integrated into the ROS 1.x core. These include, but
are not limited to UDP Multicast Support [1] and a ZeroMQ-based backend
which improves performance [2].
[1] http://wiki.ros.org/ethzasl_message_transport
[2] https://github.com/esteve/ros_comm/tree/zeromq_thrift
OSRF will continue to maintain the ROS 1.x core, but we do not intend to
spend time on new development for them. We will of course entertain
patches to improve the ROS 1.x core, but with the caveat that incorporation
of significant changes (e.g., adding new transport options) will require
significant effort from interested folks outside OSRF. E.g., merging
Cedric's UDP multicast support is not out of the question, but somebody
who's sufficiently motivated to make that happen will need to lead the
charge, including testing and documentation of affected packages.

brian.
Hai Nguyen
2014-09-16 17:43:59 UTC
Permalink
I'm not particularly familiar with DDS, but does it work nicely with
browsers? either through some sort of translation or better yet, natively?
I'm interested as the current ROS to WebSockets bridge is particularly
ugly: the bridge has to subscribe to all the messages that any web client
would need to listen to and then rebroadcast them, which introduces
additional delays making it horribly painful to use for things like teleop
with large messages like images or point clouds.
From my perspective, interest, especially commercially, in getting ROS to
work with the web have only grown over time. There has been push by Bosch
and Brown for a while, and then Willow joined in, right before it closed
shop, to build a complementary web toolkit [1] for ROS. Savioke, from their
job postings, seem to be doing something webby behind the scenes too. And
even for hobby/research projects, it's just so much easier to access robots
over a browser compared to with Ubuntu/RViz. The fact that you get iOS and
Android support, no ROS java [2] needed, almost for free through their
browsers is just fantastic (and I suggest trying this if you haven't
already).

I might have missed it in my superficial lurking, but I haven't seen this
issue of communicating with web clients raised with any seriousness yet. It
would be a big missed opportunity if ROS 2.0 only supports talking to
browsers at the level that it does now. Most projects are moving to the
web. These days even my humble ipython runs a full-fledged web server in
its default installation. Certainly, in the future, I feel like this will
become a much more pressing issue.

[1] http://robotwebtools.org
[2] https://code.google.com/p/rosjava/
On Mon, Sep 15, 2014 at 8:27 AM, Jonathan Bohren <
Post by Jonathan Bohren
What I gathered from Aaron's initial post is that an open question is
whether or not ROS 1.x will continue to be enhanced and/or if OSRF has the
bandwidth to organize contributions which enhance it in the ways he
described. Over in ros-sig-ng-ros, I mentioned that there are currently a
bunch of enhancements floating around which either not been fully fleshed
out or have not been integrated into the ROS 1.x core. These include, but
are not limited to UDP Multicast Support [1] and a ZeroMQ-based backend
which improves performance [2].
[1] http://wiki.ros.org/ethzasl_message_transport
[2] https://github.com/esteve/ros_comm/tree/zeromq_thrift
OSRF will continue to maintain the ROS 1.x core, but we do not intend to
spend time on new development for them. We will of course entertain
patches to improve the ROS 1.x core, but with the caveat that incorporation
of significant changes (e.g., adding new transport options) will require
significant effort from interested folks outside OSRF. E.g., merging
Cedric's UDP multicast support is not out of the question, but somebody
who's sufficiently motivated to make that happen will need to lead the
charge, including testing and documentation of affected packages.
brian.
_______________________________________________
ros-users mailing list
http://lists.ros.org/mailman/listinfo/ros-users
--
Hai Nguyen
http://haidai.tumblr.com
Jonathan Bohren
2014-09-16 18:26:16 UTC
Permalink
Post by Hai Nguyen
I'm not particularly familiar with DDS, but does it work nicely with
browsers? either through some sort of translation or better yet, natively?
I'm interested as the current ROS to WebSockets bridge is particularly
ugly: the bridge has to subscribe to all the messages that any web client
would need to listen to and then rebroadcast them, which introduces
additional delays making it horribly painful to use for things like teleop
with large messages like images or point clouds.
This looks promising:
http://www.prismtech.com/blog/dds-web-programming-dscript

-j
--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren
William Woodall
2014-09-16 18:43:58 UTC
Permalink
Can we please keep topics like supporting communication with browsers on
the ng-sig? I have already asked Hai off channel to repost over to the sig,
which he has and I have since responded there too.

I understand the want to discuss high level concerns about ROS 2.0 on
ros-user's, which is fine, but we should really strive to keep the traffic
here low (we get a lot of complaints about the traffic on this list from
technical discussions and support questions).

Thanks,
Post by Jonathan Bohren
Post by Hai Nguyen
I'm not particularly familiar with DDS, but does it work nicely with
browsers? either through some sort of translation or better yet, natively?
I'm interested as the current ROS to WebSockets bridge is particularly
ugly: the bridge has to subscribe to all the messages that any web client
would need to listen to and then rebroadcast them, which introduces
additional delays making it horribly painful to use for things like teleop
with large messages like images or point clouds.
http://www.prismtech.com/blog/dds-web-programming-dscript
-j
--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren
_______________________________________________
ros-users mailing list
http://lists.ros.org/mailman/listinfo/ros-users
--
William Woodall
ROS Development Team
william-GsQoM64suCGGJGYlWa3Ukdi2O/***@public.gmane.org
http://wjwwood.io/
Valerio De Carolis
2014-09-16 20:31:18 UTC
Permalink
Post by Brian Gerkey
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.
What I gathered from Aaron's initial post is that an open question is
whether or not ROS 1.x will continue to be enhanced and/or if OSRF has
the bandwidth to organize contributions which enhance it in the ways he
described. Over in ros-sig-ng-ros, I mentioned that there are currently
a bunch of enhancements floating around which either not been fully
fleshed out or have not been integrated into the ROS 1.x core. These
include, but are not limited to UDP Multicast Support [1] and a
ZeroMQ-based backend which improves performance [2].
[1] http://wiki.ros.org/ethzasl_message_transport
[2] https://github.com/esteve/ros_comm/tree/zeromq_thrift
The UDP support and the ZeroMQ transport is really a good combination
that we use successfully in our projects. Unfortunately the ROS 2.0
plans seems to diverge on these topics. Hope one can easily plug
different systems like it was possible with the ROS 1.x version.

JSON and msgpack serialization is way more efficient than the 1.x one.
Post by Brian Gerkey
I'm not particularly familiar with DDS, but does it work nicely with browsers? either through some sort of translation or better yet, natively? I'm interested as the current ROS to WebSockets bridge is particularly ugly: the bridge has to subscribe to all the messages that any web client would need to listen to and then rebroadcast them, which introduces additional delays making it horribly painful to use for things like teleop with large messages like images or point clouds.
http://www.prismtech.com/blog/dds-web-programming-dscript
I fear this suffers of the same problem, cause once you want to play
with the browser side JSON format is really a must have as you can pass
your messages without parsing and serializing them twice. There is a
trade-off one has to choose between having checks on static typed
messages or embrace the dynamic nature of the web. ;)
--
Valerio De Carolis - PhD Student
Ocean Systems Laboratory
Heriot-Watt University
EH14 4AS, Edinburgh, UK

tel: +44 (0)131 451 3506
web: http://osl.eps.hw.ac.uk



-----
We invite research leaders and ambitious early career researchers to
join us in leading and driving research in key inter-disciplinary themes.
Please see www.hw.ac.uk/researchleaders for further information and how
to apply.

Heriot-Watt University is a Scottish charity
registered under charity number SC000278.
Mike Purvis
2014-09-15 15:29:32 UTC
Permalink
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
Post by Brian Gerkey
hi Chad, Ingo,
aren't interested can ignore it.
"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
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.
Post by Ingo Lütkebohle
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 <
Post by Jenkins, Odest Chadwicke
Hi Tully,
I would like this discussion to continue on ros-users and address
"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
Subject: Re: [ros-users] The future of ROS 2.0 protocol changes
<CAM7qi7UwvjVjYtSbnpMrUcAKg1yO=
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
Post by Aaron Sims
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.
Post by Aaron Sims
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.
Post by Aaron Sims
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
Post by Aaron Sims
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
Post by Aaron Sims
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.
Post by Aaron Sims
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?
Post by Aaron Sims
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).
Post by Aaron Sims
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.
Post by Aaron Sims
In the interim here are some ROS 1.0 improvements that could greatly
improve ROS performance with substantial latency decrease, while increasing
Post by Aaron Sims
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).
Post by Aaron Sims
*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.
Post by Aaron Sims
*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).
Post by Aaron Sims
*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.
Post by Aaron Sims
If you have any questions or would like to have further discussion, I
look forward to discussion.
Post by Aaron Sims
Sincerely,
Aaron
_______________________________________________
ros-users mailing list
http://lists.ros.org/mailman/listinfo/ros-users
_______________________________________________
ros-users mailing list
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
http://lists.ros.org/mailman/listinfo/ros-users
_______________________________________________
ros-users mailing list
http://lists.ros.org/mailman/listinfo/ros-users
Jenkins, Odest Chadwicke
2014-09-17 15:12:58 UTC
Permalink
William,

I respectfully disagree with pushing discussions on high-level issues (like
this) to a sig.

Hai's question pertains directly to core changes in the ROS protocols. He
makes a clear argument for why interoperability with the web should be part
of the core scope of ROS, and not treated as an disconnected component.

Usability is a high-level concern for ROS and ROS 2.0, especially for
front-end development, broader accessibility (e.g., outside of a LAN,
without requiring super user privileges), and cross-platform performance.
Towards this, Hai makes a very good points about ROS front-ends being
limited to Ubuntu/rViz and ROS/rosbridge having room for improvement, and
whether DDS addresses these limitations. Given the magnitude of the ROS
2.0 transition, these points should be addressed among the larger
community, as was done with ros-users at the beginnings of ROS over five
years ago.

Thus, I would ask again that discussions related to ROS-ROS2.0 transitions
remain on ros-users until there is some larger consensus. While this
requires some people to bear through some additional messages, engaging the
larger community in this discussion will be better for everyone in the long
run such that we do not "throw the current ROS users under the bus."

-Chad

Date: Tue, 16 Sep 2014 13:43:58 -0500
Post by Jenkins, Odest Chadwicke
Subject: Re: [ros-users] The future of ROS 2.0 protocol changes
<CAFe2DWgKj=
Content-Type: text/plain; charset="utf-8"
Can we please keep topics like supporting communication with browsers on
the ng-sig? I have already asked Hai off channel to repost over to the sig,
which he has and I have since responded there too.
I understand the want to discuss high level concerns about ROS 2.0 on
ros-user's, which is fine, but we should really strive to keep the traffic
here low (we get a lot of complaints about the traffic on this list from
technical discussions and support questions).
Thanks,
On Tue, Sep 16, 2014 at 1:26 PM, Jonathan Bohren <
Post by Jonathan Bohren
Post by Hai Nguyen
I'm not particularly familiar with DDS, but does it work nicely with
browsers? either through some sort of translation or better yet,
natively?
Post by Jonathan Bohren
Post by Hai Nguyen
I'm interested as the current ROS to WebSockets bridge is particularly
ugly: the bridge has to subscribe to all the messages that any web
client
Post by Jonathan Bohren
Post by Hai Nguyen
would need to listen to and then rebroadcast them, which introduces
additional delays making it horribly painful to use for things like
teleop
Post by Jonathan Bohren
Post by Hai Nguyen
with large messages like images or point clouds.
http://www.prismtech.com/blog/dds-web-programming-dscript
-j
--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren
_______________________________________________
ros-users mailing list
http://lists.ros.org/mailman/listinfo/ros-users
--
William Woodall
ROS Development Team
http://wjwwood.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.ros.org/pipermail/ros-users/attachments/20140916/d731436e/attachment-0001.html
Ingo Lütkebohle
2014-09-18 07:01:46 UTC
Permalink
First of all, thanks to Brian for confirming again that the bridge/compat
to 1.0 still holds. I know from experience that such things can turn out
much harder than expected, and it is no small commitment on the OSRF's
behalf to pledge that.

Regarding the other half of the discussion, while I sympathize with Chad's
sentiments, and agree on many points, it appears to me that the ROS 2.0
*core* is largely an endeavour of the OSRF, similarly to how the ROS 1.0
core was largely an endeavour of Willow Garage. I mean this in the sense
that, while it is Open Source, they bear the brunt of the development, and
the rest here are largely *users*. Of couse "use" in this case means
development of software based on it. This other software makes up much of
what is ROS, so we probably don't like to think of us as regular users, but
in relation to the core, I think we mostly are (the exact history
unfortunately appears to be lost in the move to github, so please correct
me if I'm wrong).

I'm mentioning this to make a case that people who are interested enough
should not find it too much of a burden to join a special interest group,
if that makes the whole job easier for the "core" developers. The split
between "users" and "developers" is common for many projects, and there are
usually quite a few people on the "developers" list who aren't contributing
code but mostly other input. I'm personally a bit annoyed that the SIG is
on google groups instead of a regular mailing list, but well, I can live
with that ;-)

That said, I also think that OSRF would be well advised to *actively* pull
people into the SIG, and maybe not just those that speak up here, because
it could provide not just interesting input, but also the potential for
work sharing. Greater community involvement will certainly ease migration.
Also, otherwise, people might be scared away by the "special interest"
description.

cheers,
Ingo

Loading...