[ros-users] ROS 2.0 Strategy review

Johan Fabry jfabry at dcc.uchile.cl
Tue Sep 29 22:32:56 UTC 2015


> On Sep 29, 2015, at 18:17, Mike Purvis via ros-users <ros-users at lists.ros.org> wrote:
> 
> Note here that all the goals that OSRF presents are perfectly achievable
> using a different strategy: ROS1.5. ROS1.5 means building nodes that talk
> via the ROS1 protocol, but are built using ROS2 infrastructure and libraries.
> 
> Another view of "ROS1.5" would be where APIs (especially the C++ API) are maintained even as the underlying transport and serialization is changed around, an improved node/nodelet/launch scheme is developed, etc.
> 
> I support the DDS direction, but it does seem to be an all-or-nothing affair, and that's one of the biggest bummers about it.

I agree with Mike.

Changing the API and asking the community to migrate is a very high requirement for community members. Personally I think it is too high. I’m motivated by for example, the PR2 community survey (march ’15) where over 70% of the users were 1 or 2 ROS distributions behind. Non-portability of current work was a big motivation in that (52.9%). And this just *between* ROS versions, which is nowhere near to what is being proposed in ROS2. 

So at least maintain the existing APIs. Incrementally improve ROS and add new APIs for new features, as you see fit. Swap out custom technologies for tried and tested newer/better/… Much of this is possible without breaking existing stuff, and moreover it can bring improvements to the existing ecosystem ‘for free’.

Have a migration plan with automatized migration tools. (Semi-)automatic source code rewriting is no black magic and it will be a big help e.g. in those cases where an API change is needed. Google does this with Go and it seems to work out well for them (see 'Mechanical source transformation’ in http://blog.golang.org/go-fmt-your-code <http://blog.golang.org/go-fmt-your-code>).

To repeat myself: big bang releases are very risky and very costly. Gradual improvements like above avoid this risk, and may even allow the community to use new features sooner and/or profit from the improvements in the back-end.

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of Chile

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20150929/19e98986/attachment.html>


More information about the ros-users mailing list