Should I use ROS 2 Rolling for my project?
To answer this question you need to understand the state of various ROS releases, how they relate, and the needs of your project.
First of all, there are three basic types of ROS releases. There are Long Term Support (LTS), Stable, and Rolling releases. The latest LTS release of ROS 2 is Foxy. The next one will be Humble. These releases come out every two years with the LTS release from Ubuntu. In the case of Foxy, this was Ubuntu 20.04 and Humble will be on Ubuntu 22.04. The second type is the Stable release, this is the odd year releases. The current one of these is Galactic. It still targets the current LTS of Ubuntu but from the perspective of the authors of ROS will be supported for much less time. Lastly, there is the newest type of release, the Rolling release. The Rolling release allows you to get the latest features and bug fixes from the authors of ROS. The obvious downside of depending on Rolling is it is a moving target.
Background
Now for how they relate. At a point in time, the current state of development of ROS is frozen into a release. Except for Rolling, using ROS releases ensures that the underlying API and most of the behavior will not change on you. This is very important so that you can trust that code you wrote that works now and depends on code in the release will continue to work in the future. This does have a downside though in that if the release contains bugs they are unlikely to be fixed as those bugs are part of the behavior that someone might depend on. The other reason these bugs are unlikely to get fixed and backported is the authors of ROS have limited time and their focus is always on the next version of ROS.
For more context a good example of something that is outright broken in Foxy and will never be backported is ros2 bag, but you can build it from source if you need it. In Foxy there are huge performance issues with the released version of ros2 bag. For most ROS based projects collecting and playing back bag files is a critical feature. In order to deal with this you have three paths, each with different tradeoffs:
| ROS version | Benefits | Drawbacks | Implications |
|---|---|---|---|
| Foxy |
API is stable and will never change
EOL is the furthest out at May 2023
|
Bugfixes are rarely backported
Major performance issues
|
Build upstream packages with fixes from source like MoveIt2, ros2bag, rviz |
| Galactic |
API is stable and will never change
Many bug fixes and performance improvements over Foxy
|
Bugfixes are rarely backported
EOL on November 2022
|
As Galactic ages and you need the latest fixes you’ll do the same as foxy, build patched packages from source |
| Rolling |
The latest bugfixes, features, and performance upgrades
Regular releases of upstream packages like MoveIt, rviz, etc
|
Breaking API changes
Not stable
|
Observe deprecation warnings and adjust downstream packages to API changes. |
Foxy
To make this decision you have to understand the costs to your project of each of these drawbacks and their implications. If you develop on Foxy you will run into performance issues and bugs. If these bugs and performance issues are fixed in later versions, chances are you can build the projects you are depending on from the source to get the latest fixes you need.
However, the further the API diverges from Foxy the less likely newer versions of the projects you are depending on will build on Foxy. That means that to have the latest bug fixes you’ll have to maintain a fork because changes in the API cannot be backported and released in the main repo. When you do this you are on your own and lose many of the benefits of using upstream packages in the same way the rest of the community does. The better approach is when you need a bug fix or feature from a newer version to use that newer version of ROS. That way, when you run into issues, it is much easier for the authors and community to help you.
Rolling
With all these drawbacks to Foxy should you just use Rolling for your project? Rolling will incur a different sort of cost to your project. The API of Rolling is not stable. What builds today might not build tomorrow which would make it hard to deploy a project based on Rolling. Also, because the API is changing it will require a more skilled development team to keep up with the latest changes. This is not as difficult as it sounds though because ROS uses a tick-tock deprecation strategy for the core libraries. This means that before ROS will remove any API they will first add deprecation notices to the code that will print warnings when you compile. In our experience adapting to these warnings is fairly trivial.
Galactic
The natural compromise would seem to be Galactic. Our opinion is that Galactic should currently be the default choice for new projects with the expectation that at some point this might need to change. By using Galactic, you get the benefit of the most recent version of ROS with the latest bug fixes and features while still having a stable version to build against.
Comparisons
Long term, we have found that the best way to develop with ROS 2 in its rapidly evolving state is to expect to upgrade to the latest stable version of ROS as soon as it is possible. ROS 2 is the cutting edge of robotics software and if you are using it, you do want the latest features and bug fixes as soon as your team can tolerate them.
Another critical consideration is the external packages you depend on and what features are critical for your project. There are cases where using ROS 1 Noetic for example is a better choice than any of the ROS 2 releases because you need a feature that has yet to be implemented in ROS 2. In the end, this is a cost-benefit analysis with the goal of your project gaining the most from using the ROS release you choose.
Your Team and Your Project
The size and ability of your team to adapt to upstream changes also play a role. In many cases, people overestimate how much work keeping up with the latest changes is and underestimate how helpful the latest bug fixes can be. The problem comes from comparing something easy to estimate (the extra time needed to use the latest versions) vs. something hard to predict (if you will be impacted by existing bugs in old released versions). There is also the issue that the older APIs are often much better documented so your initial startup costs will be much lower as you’ll be able to rely on existing documentation more. This is especially true if comparing ROS 1 with ROS 2.
The scope and amount of dependencies of your project should also be taken into consideration. If it is a huge project that will be hard to adapt to newer APIs later in the development cycle. This makes the initial choices matter more. If it is a small project with very few external dependencies you can have the best of both worlds. Develop it on a stable version and upgrade later when it is critical to the project or your users.
Another consideration is how much you plan on modifying upstream repositories as part of your project. In many cutting-edge robotics projects, it makes sense to contribute improvements to upstream projects that enable the needs of your project. At first, this may seem like a bad and difficult approach because upstream changes will require you to go through code reviews and make your changes general enough they help other users of those upstream projects. The real win here is that code contributed upstream will continue to be improved by the whole community. This is the key to and one of the largest values you get from using and working with open-source software. The more eyes there are on something the quicker issues get fixed and the more robust the solution becomes. To easily contribute upstream you should be using the latest versions as those are the ones that can accept changes to the API.
Lastly, you should consider how soon you plan on cutting releases of your software and what will serve your users the best. If you are nearing a point where you will cut a release you should bias towards a stable release of your dependencies so that your project can be easily used by others. If on the other hand you are under active development, using the latest features from Rolling and looking to target a future stable release would be a wise move because it can save you time debugging things that have been fixed since the last release and make the API transition to the next stable release gradual.
Conclusion
In summary, what version of ROS you should use and how you should plan on upgrading is nuanced and has to take into account many different factors. We at PickNik are regularly dealing with many versions of ROS across our clients’ projects and there is not a simple answer to the question “What version of ROS should I use for my project?”. If you want a general rule of thumb, ask the question “Is my project on the cutting edge of robotics, do I plan on releasing my software after Humble (May 2022) and do I have a high performance software team?” If the answer is yes to all three, use Rolling. Otherwise, the question could be, “Do the released versions of libraries in Foxy or Galactic contain everything I need for my project?” If so, use one of those versions of ROS.
