[ros-users] ROS 2.0 Strategy review

[Valerio De Carolis]

Hi Brian,

first of all thanks for the detailed reply. I think most of the people 
interest in this topics are familiar with the design documents and, by 
the way, thanks for developing things such in the open. :)

I've just a couple of points that for me, having experience with 
different message-oriented middleware architectures (AMPQ, ActiveMQ, 
0MQ, etc), and ESBs, are not clear in such evaluations.

On 28/09/15 22:08, Brian Gerkey via ros-users wrote:
> While you might consider zmq a "known thing," and indeed it is widely
> used in a number of distributed systems, it's insufficient to say, "use
> zmq."  zmq specifies only the transport part of the system (how sockets
> are handled), saying nothing about discovery (how participants find each
> other) or serialization (how data is encoded on the wire).

The nice thing about ZMQ is the C4.1 community process, where group of 
interests (like the robotics community) can propose and endorse any 
change or standard to be build on top of the existing technology. This 
can help in creating even more consensus around the ROS middleware.

Using the same community process discovery protocols are being build on 
top of the existing infrastructure. For instance ZRE (ZeroMQ Realtime 
Exchange Protocol) [1] along with its reference implementations [2], [3] 
in C/C++ and Python can be used for exactly that purpose.

Serialization is generally left to the user in many of the existing 
message-oriented middlewares. If one wants to rely on existing open 
standards the new IETF CBOR [4] specification can be a good starting point.

> zmq doesn't support  unreliable transport, so you'd also need to add your own solution there
> (e.g., managing UDP sockets manually).

Yes it does. It can be used it over UDP with Pragmatic General Multicast 
(PGM), both in its raw and encapsulated versions. The use of PGM is 
standardized by IETF in RFC3208 [5].

> At OSRF, we looked carefully at this issue, considered a wide variety of
> options, and came to the conclusion that while we could build on things
> like zmq, we would really be defining and building another custom
> middleware.  And things would just get more custom as we want to add
> features like quality-of-service (QoS).  Do you want to support
> store-and-forward of messages?  Priority among messages?
> Limited-duration delivery retry?  Well, you have to invent your own
> rules for handling those cases, in addition to writing (and testing and
> debugging) the code to implement them.

Nice thing to note is that ZeroMQ makes exactly one guarantee: all 
messages are complete - you will never receive partial messages. It 
makes no guarantee of reliability. This guarantee is the true difference 
respect other enterprise message queues and it has been motivated by 
specific reasons [6]. One of which is that developing store and forward 
message systems is heavily dependant on the application use case and 
"one-size-fits-all" is more the holy-grail of software engineering than 
a reality.

So while all the above concern are true I'm still wondering why such 
guarantees should be enforced as default, while not all of the robotics 
use cases require so (think of sensors data streams rather than high 
level concepts), and not left as an optional transport where the user 
needs to fully understand the limitations of the use case and hopefully 
control those. Think about assessing how much information can be 
buffered before breaking the system and hopefully control such 
behaviour. In this case neither "fire-and-forget" and "retry-forever" 
are viable options cause they sit at the extreme edges of the spectrum.

> By contrast, DDS (and its underlying wire protocol, RTPS) is an open,
> end-to-end middleware specification that is relied upon for serious
> applications in labs and industries around the world.  And the
> specification includes extensive QoS settings that give you essentially
> any kind of behavior between UDP fire-and-forget and TCP retry-forever.
> That's exactly what we need for robotics applications.  And there are
> multiple well-tested implementations of the specification.

Open specification true but concerns over IP and patents can make the 
same users turn in the other direction especially if looking for 
commercial applications built on top of ROS.

That said it is a pleasure to see the ROS 2.0 topic being discussed in 
the open. :)

Cheers,
Valerio

[1]: http://rfc.zeromq.org/spec:36
[2]: https://github.com/zeromq/zyre
[3]: https://github.com/zeromq/pyre
[4]: http://cbor.io/
[5]: http://tools.ietf.org/rfcmarkup?doc=3208
[6]: http://zeromq.org/area:whitepapers


----- 
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.