All,
I’d like to start a discussion on the ROS to ROS2 transition plan. I know there are many users of ROS today, and that ROS2 is not yet fully featured, but I believe we need a plan to get the community to transition on to ROS2 as soon as possible. I believe that ROS2 can and will be better than ROS in the long run, and the sooner we get the community support in getting it ready the better.
Python 2.7 is going to EOL in 2020, and there are ROS dependencies on Python 2 that would need to be resolved in order to do a 2020 release on Ubuntu 20.04 and other OS’s. That could be a lot of work, that in my opinion, would be better spent on improving ROS2 and porting more packages to ROS2.
Given that ROS Melodic was just released, and that OSRF is committed to supporting it for 5 years, until June of 2023, it seems we have 4.5 years to move to ROS2, even if another ROS release doesn’t happen in 2020.
I also realize that there is a planned 2019 release - ‘Noetic’. Since that isn’t on a Ubuntu LTS, I’m not sure how many in the community will move to that, but that could be discussed also.
So, I’d like to know other users thoughts. Is 2023 enough time to move fully to ROS2? Do we need a LTS release in 2020? My proposal is to forgo a ROS release in 2020 and put the effort in to ROS2 instead.
We would need to work together as a community to improve ROS2 to the point that it is ready. I believe we can make that happen soon.
I’m also in favour of forgoing the 2020 release and putting the effort into ROS2. However, there are certain projects that must be available on ROS2 for it to be viable to consider moving for many people. Not least of which are navigation (which the OP @mkhansen is working on), MoveIt, OpenCV and PCL (or equivalent).
Jumping ship and burning bridges has never been a great recipe when you are dragging a lot of weight (community) with you.
I’d prefer ROS releases transitioning towards ROS2 which of course assumes stable apis/concepts on that end. ROS2 IMHO is potentially facing the challenge of having fragmented communities along the lines of OS-s.
ROS’s biggest asset has always been, and will always will be the community. Keep that in mind and don’t break it.
There has been a lot of discussion about this in the past, and the sort-of consensus was (or at least the decision by OSRF) that from a development and maintenance perspective and a fear of breaking ROS1 for ppl currently using it, the only option was a clean slate (see also the end of Why ROS 2.0?).
Perhaps at a high level we could seek conceptual re-use / transitioning and a shim could help, but not sure whether what you’re suggesting is practical (personally I’d like it too though).
I’d like to start a discussion on the ROS to ROS2 transition plan. I know there are many users of ROS today, and that ROS2 is not yet fully featured, but I believe we need a plan to get the community to transition on to ROS2 as soon as possible. I believe that ROS2 can and will be better than ROS in the long run, and the sooner we get the community support in getting it ready the better.
One alternative is for the ROS1 community to jointly refuse to migrate to ROS2, keeping current businesses and projects alive and well, with only the Python2 → Python3 migration costs to pay. Instead of porting any package to ROS2, efforts could be spend on reducing the differences between ROS1 and ROS2 from both ends, to reduce the impact of the community split, and all costs of eventual full migration.
The longer ROS2 remains in it’s unfinished ‘non-beta’ release, the more time remains to reduce the migration barrier without splitting the community. So ‘the sooner, the better’ is not necessarily economically true for the community.
We should be thinking about this in terms of net new projects. I realize that libraries need to migrate or be redesigned to support new Robotics applications on ROS2 however we shouldn’t be discussing porting Robotics applications from ROS1 to ROS2 generally. Some may choose to do it where it makes sense but I’m guessing its not going to happen broadly.
If you already have an inflight or working ROS1 application it can, and probably should stay on ROS1 until that application has exhausted its useful lifecycle. Any new or next generation of that application should be targeted to be built on ROS2 and getting the libraries there to support it.
If we agree on that as the approach then the question would be: is 2023 enough time to have LTS support on your current robotics project/application and can the community start to move forward with building bridges, tools and porting libraries as you described?
In my personal opinion, I think it’s time to concentrate on ROS2 rather than managing both ROS1 and ROS2 with fewer resources. I manage over 150 packages of ROS1 Kinetic, but I think it is too hard to manage both ROS1 and ROS2. From the perspective of a company that sells platforms that support ROS, if ROS1 is further supported after Melodic version, it must be mandatory to support ROS1 packages for customer’s request. I agree with the opinion of @mkhansen, I also hope that Melodic version is the last version of ROS1. I think that ROS1 maintainer should give them time to migrate to ROS2 rather than maintain the existing packages for ROS1. If ROS1 is finished with the Melodic version, many maintainers are likely to start working on ROS2.
I believe it’s way too early to start talking about stopping support for ROS1. ROS2 does not yet even have feature parity with ROS1 (actionlib, navigation, you name it). Switching off the lights on ROS1 should be considered after 99% of developers have made the switch, not 5%.
2023 sounds like a long time, but that doesn’t mean we can afford not to have any releases after melodic. We should continue the usual release cycle until that time at least, because we need new releases to upgrade to new versions of libraries, avoid introducing breaking API changes within a release and so on. Making melodic the last ROS1 release kills ROS now, not in 2023.
Alienating ROS1 users won’t magically turn them into ROS2 users. A monolithic company can simply allocate people to work on project B instead of project A. In an open source community, you have to win people over instead of trying to force them. The latter will simply lead to forks and probably a lot of chaos, confusion and pain for everyone.
I anticipate a loooong transition period from ROS1 to ROS2. This is why interoperability is key, e.g. it should be made as easy as possible to maintain packages for both in a single repo, with patches being backported between the versions.
At this point, splitting the community will only harm ROS2. It hasn’t reached a critical mass yet.
Declaring Melodic the last ROS1 LTS allows Open Robotics to focus their very limited resources on getting ROS2 to feature complete (Actions, etc) and production quality over the next few releases rather than splitting those resources across projects. Making Melodic the last ROS1 release doesn’t kill ROS now, it kills it in 2023
As a new robotics company entering the ROS world, having clarity on this sort of point is very important to us. We’ve decided to go “all in” on ROS 2 only. Anything that we need from ROS 1 that is not being actively ported already is something that we will look at helping with going forward (time and budgets allowing.)
BTW, we are targeting our first “ROS” enabled release for the second half of 2019.
(I’d like to prefix this by saying I haven’t looked into the ROS bridge recently as we’ve been focused on ROS1 on Windows bring up. If my comments are invalid or otherwise cringeworthy, please disregard.)
One of the lessons from surviving multiple API transitions in Windows - you will fragment your developer ecosystem if the API set differences are too large. The best API transitions I’ve been through, are the ones where the API transition is gradual. (Ship of Theseus comes to mind)
Is there opposition to making changes to ROS1 to make it ROS2 aware, in order to make the transition gradual?
(Admittedly trivial) Examples of these changes:
Making it so a single workspace can host both ROS1 & ROS2 could help ease the pain. What is the feasibility of making Catkin “Ament aware”, and ament “Catkin aware”, so that you can drop a ros2 node into a catkin build and have it Just Work™?
Would it be feasible to make roslaunch auto-start the ros bridge when launching a ROS2 node?
Well, maybe not now, but in 2019/2020 (when the next normal release / LTS release is due). We need to continue with the regular release schedule past that point for the reasons I outlined in my previous post.
I fully agree with @ooeygui’s suggestion to make the API transition gradual in order not to split the developer base. Not out of charity for ROS1, but to give ROS2 a shot at survival; I don’t think it’s a foregone conclusion that ROS2 would win if the developer base is split at this point.
I’ve used ROS since 2010, and I’ve seen many examples of new APIs being introduced (rosbuild to catkin, tf to tf2, C++98 to C++11, …), and it always took many years until the majority of packages was updated. For example, tf2 was available since at least 2013, and navigation switched to tf2 only last month. Since ROS1 to ROS2 is a much larger step than any of those examples, I’m afraid it will take much longer than that for the majority of packages to migrate to ROS2.
I fully agree with @ooeygui’s suggestion to make the API transition gradual in order not to
split the developer base. Not out of charity for ROS1, but to give ROS2 a shot at survival;
OSRF can just going to stop the buildfarm for Melodic, then how will the ROS1 community survive? There would have to be a thrid alternative to an OSRF supported ROS1 and an OSRF supported ROS2.
I fully agree with @ooeygui’s suggestion to make the API transition gradual in order not to
split the developer base.
And one reaction was this statement at ROSCOn 2015: ROSCon 2015 Hamburg: Day 1 - Dirk Thomas: State of ROS 2 - demos and the technology behind on Vimeo, starting minute 46, Brian Gerkey took the mike:
“I’ll just add that one of the things that […] we talked about is what we colloquially refer to as a library shim. So this is something that you can imagine in any language […]. It would present a ROS1 API, but under the hood it would call into the ROS2 libraries. […] There are going to be different migration paths for different use-cases. We’re not a gang of super-villains out to give you a really bad day. We want to make this as useful as possible and make it as easy as possible to migrate.”
Then at ROSCon 2016, we got this talk: ROSCon 2016 Seoul Day 1: ROS 2 Update on Vimeo (Minute 29:46) with William basically saying they could not get design a shim that works beyond simple cases. Also talks about experiments to unify the buildsystem (minute 32).
I don’t think there has been any encouraging development since. Given the TSC committee notes (ROS 2 TSC Meeting Minutes: September 6th, 2018): “When will ROS1 be EOL’d? […] It would be good to have a tentative plan for migration. The longer people can use ROS1 the less motivated they will be to move to ROS2.”, it seems that instead of providing a smooth migration path, just scaring the ROS1 community into all trashing their existing work and investing in rewriting their systems for ROS2.0 is favoured by OSRF and the TSC. Basically make the community pay for OSRFs decision to create ROS2 fast and backwards-incompatible, and worry about migration later.
So not sure if Brian today would repeat his above joke “We’re not a gang of super-villains out to give you a really bad day.” in light of all the talk of making Melodic the last release.
If OSRF were to do that, there would be a fork. All those companies and research labs deeply invested in ROS wouldn’t just say “well, it’s been fun, I guess we’re just going to do something else now”. Everything necessary to run one’s own build farm is open source, so it’s not like OSRF have a kill switch for ROS in their hands that they can push at any time. But probably there wouldn’t be just one, but multiple forks; also, without a source of funding, it’s unclear to me how the fork would be able to keep up the quality of support that OSRF is providing at the moment. Thus the “chaos, confusion and pain” I mentioned in my earlier post.
That said, I have confidence in OSRF to do The Right Thing™ (i.e., not trying to actively kill ROS), and I really believe Brian when he’s saying they’re not a gang of super villains.
Your points about the shim are very good. I get the same vibe that it’s not going to happen, but I still believe we would really need one for the reasons that @ooeygui listed.
In the absence of a shim (I don’t know whether that is possible or not, but for the sake of this question assume it isn’t), what about a migration tool or script to do 80+% of the migration effort? Would that help ease the transition?
I agree with Martin. As a company building solutions based on ROS 1, porting all of our code base to a new middleware would be a major effort. Our robots perform mobile picking in warehouses, where performance and reliability demands require a well-understood system. Exchanging the foundation of this very complex system and getting to a similar performance level again will not be an easy step.
And even if there was a script for doing many of the basic steps, the real work begins afterwards when you discover and fix all the bugs related to a different communication model, bugs in the still fresh and mildly tested libraries, in core components etc that often only appear after long-term operation (cf. some of the bugs in roscore my colleagues have reported and fixed)
Since many of the new features of ROS 2 are not really required for our use case, we would have to decide whether it makes more sense for us to migrate, or to fork and build, in addition to our own packages, also the required ROS core packages. The latter would definitely not be my preferred outcome, and I hope that we can find either a good migration path or ways for maintaining both versions for a longer time.
I’m coming late to the discussion here, but it seems like there are a couple points that are being conflated. I totally agree with @Martin_Guenther that ROS API changes are hard things to live through. I’ve been using ROS since before Mango Tango, and I shudder when I think of some of the transitions we’ve had to go through. However, I also agree with @mkhansen that not releasing another LTS after Melodic doesn’t kill ROS next year. Much of my lab is still on Indigo because some of our robots are locked to particular ROS version, and the pain of upgrading outweighs the lack of recency of our version. If there were no more releases after Indigo, I wouldn’t have cared. Of course, everyone’s use cases are different, but I don’t think it’s accurate to say that ROS1 is over if there’s no N-Turtle. If does, however, start the clock ticking.
I guess that, for me, it breaks down to the question of “Are the improvements in ROS2 worth the pain of migrating all of my code?”. We’ve got a lot of code, and that would be a significant pain. Personally, I think that ROS2 will be better (for me and my students) than ROS1 is, once we get some features in place (looking at you actions and the new nav stack). Given that we have to upgrade from Indigo next April in any case, I might just bite to bullet and move to ROS2.
In the end, I think that the question of limited resources might be the most powerful one. If Open Robotics has N hours to work on ROS, how many should they spend on ROS1 and how many on ROS2. If we need M hours of work to make ROS2 viable, then the math is simple; more time on ROS1 means a longer time until ROS2 is ready.
The worst thing we can do is fork. If this happens (and it’s a non-zero probability event, for the reasons the @Martin_Guenther lists), that’s bad for everyone.
I think that the issue of emergent bugs that @moritz mentions is the thing that worries me most about the transition, since this sort of thing is inevitable. However, my hunch is that there are going to be fewer of them, since we’re moving to a more robust communication system, and because Real Companies ™ with Real Software Engineers ™ are now starting to contribute to ROS (hat tip to @mkhansen and his crew, among others). How many of the emergent bugs in ROS1 were because of code written by grad students that wasn’t properly tested?
The big question, of course, is whether the new (hopefully) more mature and better-developed parts of ROS2 will dominate the inevitable emergent bugs. I have no idea, but I’m at least a little optimistic.
True, a number of components seem better designed, and software engineering practices are used more from the beginning. A problem when porting a complex system built on top is just that the application code, often silently, relies on properties of the communication layers (think for example about when exactly to ask tf for transforms and what to consider beforehand). If such behavior changes (even if it changes to the better), problems will appear.
That’s probably the crux of it; how many of these implicit assumptions will surface, and how long will they take to find and fix. I guess that’s an argument for both never moving to ROS2 (so we don’t have to deal with it) and moving to ROS2 immediately (so we don’t write any more code that relies on ROS1 idiosyncrasies). :-/
