Planning future ROS 1 distribution(s)

tl;dr: Open Robotics intends to create a ROS 1 distribution in May 2020 targeting Python 3, but we’ll need your help to make it successful.

In the recent past ROS 1 distributions have been created by Open Robotics (OR) once every year in May. On even numbered years a ROS distribution came with 5 years of support (long-term support, or LTS), while in odd years with only 2 years of support (non-LTS). Since the non-LTS ROS distributions are not being used much by the community OR decided earlier this year to not proceed with non-LTS releases but only release an LTS ROS distro every two years.

In light of ROS 2 gaining more traction the question recently came up what this means for ROS 1 releases. The discussion includes both perspectives (this is just a brief description of the two major directions):

  • On one hand the majority of effort and funding is being spent on ROS 2. So instead of splitting the attention no future ROS 1 distros after the already released Melodic should be made.

  • On the other hand there is a large community using ROS 1 with no (immediate) plans to migrate to ROS 2 and ROS 2 is not as feature rich and complete as ROS 1 at this moment.

We need to carefully balance the pros and cons for future ROS 1 distributions. On the one hand we want both ROS versions to coexist for as long as feasible to allow a migration over time, but on the other hand we are bound by resource constraints. Here we mean not just OR but all ROS 1 package maintainers, wherever they work. As has been pointed out by @Pyo, each new ROS 1 distro creates an initial development and subsequent maintenance burden for anyone who releases their packages for that new distro. As @gerkey said, OR doesn’t receive funding directed at this kind of work, and I would guess that the same is true at other organizations.

Looking at the current state of ROS 2 it has certainly gained a lot of features in the core and many porting efforts of important capabilities (like navigation, moveit, image pipeline) are on the way. That being said there is still some way to go to before it can match up with ROS 1 in various areas, just to mention one area: documentation and tutorials.

Looking at the current support timeline of ROS 1 the latest distribution Melodic was released in 2018 and will be supported until 2023. While that gives us a timeline of 4.5 years in principle, there are two factors which limit the effective support horizon:

  • At some point in the future ROS 2 will target a newer version of Ubuntu (namely 20.04). Commonly for ROS distributions that happens for the next ROS distro released after the Ubuntu LTS becomes available. While the concrete point in time is up for discussion, at some point that move will happen - very likely before 2023. Then not having a new ROS 1 distro targeting a newer version of Ubuntu would leave us in a “split” situation: the latest versions of ROS 1 and ROS 2 would not be supported on the same Ubuntu distribution which would make using a heterogeneous system much more challenging. As such this split would also make any gradual migration effort more difficult. This aspect shrinks the supported time window to the overlap between ROS 1 and ROS 2 distros on a common platform which is less than 4.5 years - more like 2-3 years (also noted by @mikeferguson).

  • The second aspect limiting the effective support window of ROS 1 Melodic is the EOL of Python 2 in the beginning of 2020. While existing distributions and packages will continue to exist, the unavailability of security patches moving forward will likely significantly hinder the ability to continue using Python 2 software. So the effective time window becomes even shorter - more realistically something around 1.5-2 years.

Based on these considerations OR has decided to commit some resources to creating a ROS 1 release, code-named Noetic Ninjemys (Noetic) in ~ May 2020 which will target Python 3 (instead of Python 2). The availability of that ROS 1 distribution will address both limitations described above and effectively ensure a coexistence of ROS 1 and ROS 2 until at least 2025. While in 2022 new ROS 2 distributions will likely target newer Ubuntu distros (which are not supported by ROS 1 Noetic) that is less of a problem for the coexistence / migration since by then we certainly expect the ROS 2 release from 2020 / 2021 to be a viable platform users can stick to. (At the moment that is much less the case while significant features are still being worked on and previous releases are not necessarily in a viable state to be used.)

That being said the transition from Python 2 to Python 3 in ROS 1 is certainly a significant one. While OR will contribute to create a Noetic release in 2020 the scope of work is much higher. It requires the whole community to contribute to the effort - otherwise Noetic would just contain a fraction of packages of previous ROS 1 releases or if not tested extensively the quality might be subpar.

In the context of a ROS 1 Noetic release and ROS 2 porting effort you can see the Python 3 transition as a benefit to both worlds. Either a package is first being made compatible with Python 3 for Noetic and then ported to ROS 2, or a package is first ported to ROS 2 (which involves making it work with Python 3) and then the Python 3 specific changes can be ported for the Noetic release. Either way the step to Python 3 is necessary.

As with any ROS distribution, it’ll be up to package maintainers to decide whether and when to release their packages into Noetic. And as always, all community members will be welcome to step up and help to get package(s) released. If you see something missing from any supported ROS distro, consider volunteering your time to help with the release. If it’s a package that you deeply care about, consider volunteering to become a co-maintainer or even to take on sole maintainership. You’re very likely to get a positive response from package maintainers. And given the extra effort because of the Python 3 transition, we expect that we’ll need much more such community assistance than we’ve had in the past for Noetic to become a complete distro.

What does that mean for ROS 1 beyond Noetic? At the moment OR can’t commit to continue investing resources into future ROS 1 releases past Noetic. So OR does not intend to spend effort on a O-turtle ROS 1 release. If there is significant interest from the community this should by no means imply that there can’t be more ROS 1 releases. All the infrastructure is open and if one or multiple entities would like to take on the responsibility for rolling future ROS 1 distributions OR will be more than happy to help them getting started with that effort.

We hope this provides a clear direction for ROS 1 for the foreseeable future and some level of certainty what to expect from OR.

Your ROS team @ Open Robotics

18 Likes

@dirk-thomas thanks for this detailed roadmap and high-level outline on how people need to contribute. Has anyone already built a table of Python3-compliant ROS packages?

I do think that the Python 2-3 migration challenge is just an extreme case of a more general characteristic of ROS package distribution and organization. While ROS-based systems are supposed to be loosely-coupled (i.e. all you need are matching message MD5 hashes), the way that ROS binaries are distributed creates very tight coupling through system dependencies. Namely, all released ROS packages must link against the same system library binary versions, even though this is only really necessary for packages that are linked at compile- or run-time.

Do you know if anyone in the community has developed a robust toolchain for running subsets of ROS packages in isolated environments? I’ve seen some examples with Python virtualenv, chroot, snaps, and Docker, but there’s nothing that I know of others using in practice. This might east not only the Python 2-3 migration, but also running heterogeneous ROS/ros2 systems.


As an aside, I really have a hard time reading “OR” as anything but a logical disjunction…

I expect that ROS 2 enabled packages will be registered for the upcoming ROS Crystal release. At that point they will be browsable on ROS Packages

1 Like

Thanks for this, @dirk-thomas.

Do you have any suggestions for how one might find projects that could use help in this?

At some point there will be a buildfarm for ROS 1 Noetic which automates the testing with Python 3 and indicated which packages have failing test.

Until then you need to build any set of ROS packages using Python 3. Then you can run the unit tests and fix any Python 3 related problems and (since the tests will no cover each and every case) use the built workspace to check if anything else needs fixing.

It feels like we need a spreadsheet of what needs to be ported in order to consider a release possible, and what the status of efforts are. Maybe form a working group of some kind.

2 Likes

Once Noetic is on the build farm, you should be able to use a page similar to this: http://repositories.ros.org/status_page/blocked_releases_melodic.html?q=label%3D"UNBLOCKED_BLOCKING"&s=2&r=1

(which covers everything, not just Python)

1 Like

Given https://devguide.python.org/#status-of-python-branches what will be the minimum version of Python 3 supported? 3.5 will EOL 6 months after ROS on Python 3 debuts. Better async support and f"strings" of Python 3.6 might make a better starting point than 3.5.

Ultimately the REP 3 will specify it for ROS Noetic. Commonly we use the lowest common denominator from the set of targeted platforms. Usually that will be between Debian and Ubuntu. The latest Debian distro Buster ships with 3.7. For Ubuntu 20.04 that hasn’t been determined yet but since 19.10 also has 3.7. So I think it is safe to assume that it will be at least Python 3.7 in Noetic.

Is there discussion on the REP at the moment?
I am surprised to see Noetic is not listed yet and it’s late March already.

36 days and counting

5 Likes

ros-infrastructure/rep#202

You might want to double check that counter. The planned release date is world turtle day which is this year on May 23rd.

3 Likes

In places where the release was only specified by the month, I put the first. I’ve updated the clock.