[ros-users] ROS 2.0 Strategy review

Tue Sep 29 17:52:07 UTC 2015

Johan, 

I think you are spot on.

> Am 29.09.2015 um 16:35 schrieb Johan Fabry <jfabry at dcc.uchile.cl>:
> 
> Hi all,
> 
> I second many of Michael’s concerns, especially the part of his mail quoted below.
> 
> Frankly, the strategy review document reads almost like a horror story to me. There are so many things that can go wrong in such a long development process, without intermediate parts that will be immediately useful to the community, and so many assumptions that the community can/will follow. I have read many stories of failed software development efforts (I have a software engineering background) and this strategy document very strongly reminds me of these documents. 

In fact, I'd urge everybody to pull out Fred Brooks's "Mythical Man Month" and read up on the second-system effect. I am convinced this applies here.

> FWIW, I advocate a more gradual path, where as much as possible of the planned technologies are integrated step by step. This so that the community can follow and moreover benefit from the positive aspects of these technologies *immediately*, instead of having to wait for a long time for these technologies to arrive in a big-bang release (which typically also is an affair with a much higher chance of failure). I found that the image included in the original message (https://i.imgflip.com/rl3g1.jpg) was not funny at all BTW. Added benefit of such an approach is that support for these technologies is then outsourced, which frees up time.

While I see a lot of arguments about changes, compatibility, migration and other technicalities in the strategy review, I failed to find an answer to a simple business question I pose myself:

How do you actually argue a nuclear middleware change based on the merits to be reaped?  What will you be able to do post-change at all, or better, than you can do or not do now? And given that delta, is the change warranted in terms of cost and impact?

for the record: I am not advocating here to remain with the ROS1 status quo. Eventually everybody including me graduates from using raw sockets, serial ports and homegrown serialisation methods including the eternal JSON escape hatch.

But setting sail with a wholesale API breakage for starters, but without a migration path and not showing the money is not going to convince many this is actually worthwhile, even if it happens to arrive in a relevant timeframe.

The API's _are_ a project's fundamental contract. You can evolve API's over time. But the social price for API breakage is very high. For API breakage without obvious upside it's super high: it's the farm at stake.

> For example, why not migrate to protocol buffers as a start, to outsource that part of ROS? Migration for the community should be easy, it’s relatively trivial to write a tool that can convert .yaml files to .proto files and this tool could be included in ROS.

I think slicing the problem into manageable and largely disjoint topics would be a good start.

For instance, along the lines of your suggestion, into: serialisation, transport, rendezvous & discovery (which might be optional or statically configured in some scenarios). Come to a clear understanding what actually requires hard deadline guarantees, and what not (most of middleware does not). Confine and localize the impact of the 'hard deadlines needed' part, as opposed to infesting the whole stack with useless requirements.*)

While at it, I think it is prudent to give up on the panacea idea - all this has to come from a single source - the issues are largely unrelated anyway and some are optional, and then an evidence-driven mix-and-match strategy will result in a resilient architecture with a very high software reuse factor. By evidence I mean for instance timing measurements.

As for your concrete suggestion on protobuf: I concur this is doable compile-time and fully automatic, as most serialisation methods are highly isomorphic. That said - given some creative use of protobuf introspection, I think even automatic runtime translation of messages is conceivable (by automatic I mean: exclusively driven by IDL descriptors, not manifest field-fiddling code). 

That would open a natural migration path which I currently do not see, at least for message contents.

- Michael

*) it is my experience from the the precursor of the machinekit project, and I hear the same story from commercial users of realtime stacks: time and again way too much code is done in hard realtime environments - usually for a lack of understanding of the actual requirements, "playing it safe" and erring on the costly side, and sometimes it comes down to very human factors like job security.

> 
>> On Sep 29, 2015, at 08:09, Michael Haberler via ros-users <ros-users at lists.ros.org> wrote:
>> 
>> I think looking at a spec sheet alone for such a decision runs the danger of disregarding a key aspect of open source social dynamics: you might miss the buy-in of a key constituency and - given the lack of interoperability - in essence bifurcate the project, with a good chance of sinking the whole ship while at it:
>> 
>> - a open-source-only variant which remains with ROS1 as DDS adoption is unlikely to happen
>> - a ROS2/DDS flavor used by folks which face institutional pressures to adopt DDS
>> 
>> If the hope for this project is 'Open Source Robotics', rather than 'a DDS sales channel', I think the decision is ill advised and flawed technically as well as socially. Changing middleware without a migration path is risky enough. While at it, going to a place where you stand a strong chance of loosing users along the way is extra divisive.
>> 
>> 
>> I strongly recommend to revisit the ROS2/DDS decision:
>> 
>> - put ROS-on-DDS on hold as just one option of several possibilities
>> - proceed in parallel exploring alternatives based on actual use cases, actual measurements, and a more rigorous separation of concerns than shown so far
>> - evaluate the cost of each one along several dimensions: fulfilling actual, proven-to-must-have requirements, integration effort, migration path, considering the upside of existing communities and their support contributions, and keep the factors for community buy-in in eyesight.
>> 
>> - Michael
> 
> 
> ---> Save our in-boxes! http://emailcharter.org <---
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of Chile