ROS Kinetic has come to EOL. We have discussed the impact of EOL in the past, but with its final sync out on May 12th, ROS Kinetic is no longer supported. Together with Ubuntu Xenial, both distributions will no longer receive security updates or bug fixes.
ROS second LTS release became the largest rosdistro with 1,233 repositories over the last 5 years. We want to join our partner, Open Robotics, in thanking all of you who contributed to making ROS Kinetic a milestone in robotics history.
But for all of us still working with Kinetic, in our deployed robots, labs or universities, two questions arise: where do I migrate to and what are the challenges?
To answer these questions, we asked our community what they think. So throughout April, we conducted 2 small polls on LinkedIn and Twitter. Two main questions were asked.
What is your ROS migration plan?
The first question was straightforward, where are you moving? Four options were given as seen in the figure below.
With 269 votes, ROS 2 Foxy stood up as the main option for our ROS community with 37% of responses.
ROS 2 represents a no legacy carryover approach; all the design criteria have been revisited to get the best possible experience. Take for example communications, in ROS 2 we no longer have a hub/spoke design. Instead, ROS 2 has essentially a peer-to-peer design by default, where each component can discover peers and talk directly to them. ROS 2 includes pluggable middleware, DDS, with different vendors offering different capabilities, to handle the inter-robot communications. This new middleware enables on-the-wire security, such as including authentication before joining the ROS graph or enforcing permissions. Undoubtedly, ROS 2 comes with a learning curve. Here you can find a complete migration guide for ROS 2 Foxy.
With a combined 46,6%, ROS 1 is still a desirable option for the community. The migration to Melodic is easier, as it still supports Python 2. For those of you still working with Kinetic who wish to upgrade to a newer version of ROS 1, you can find guides for Melodic and Noetic on the ROS 1 wiki.
However, staying in Kinetic is still an option for our voters. With a significant 16,4%, we see that people want to remain in this EOL distribution. Let’s explore why.
What is your ROS Kinetic migration challenge?
The second question aims to explore the main challenges for migrating. Like before, four options were given as seen in the figure below, with 179 people in this poll. Software availability/compatibility were acknowledged as the main challenge for developers with 35,4% of responses.
One of the challenges when moving to different distributions is software availability. In ROS, some of the ROS packages that you used in one distribution (e.g. Kinetic) might not be supported in newer distributions of ROS (e.g. Foxy). In the same way, some APIs from your current ROS environment might depend on specific versions of the applications and libraries of Ubuntu Xenial. For example, Python 2.7 is no longer supported in ROS 1 Noetic nor ROS 2 Foxy.
Other technical challenges (such as Ubuntu migration) and the challenges of migrating remotely also contributed to the difficulty of the task. Take for instance those deploying ROS robots in the field. Their users are already employing the robots, perhaps in critical operations. Collecting all the deployed units represents a challenge for companies. It requires planning internally and with their end user. Migration also brings additional expenses, including for the users due to robots’ downtime operation.
Finally, 24,2% voted to stay in Kinetic. Let’s discuss the implications next.
Unsupported, your robot is at risk.
Working with an EOL distribution is not safe. Have a look at our latest webinar about the risk of staying on ROS Kinetic. In a nutshell, you are putting your device and user at risk by not receiving security updates for your OS and ROS environment. As with any system, robotic security is not just about the platform itself, but the weakest link in the digital ecosystem where the robot resides. Therefore, robotics companies need to develop security mechanisms for securing their products from malicious actors and understand the risk that they bring and are exposed to in any network.
Software updates for security maintenance represent the minimum requirement for reducing vulnerabilities. If a robot software in a manufacturing line or retail is not maintained, sooner or later attackers may gain a foothold on it and possibly use it to gain access to the device itself, and potentially to other corporate assets. Therefore, security maintenance is included in all cybersecurity frameworks such as the Center for Internet Security (CIS) top 20 or National Institute of Standards and Technology (NIST) Cybersecurity Framework, and its application in robotics is as equally valid as any other computational system.
ROS ESM
Ultimately, we recommend companies migrate to a supported ROS distribution. But we understand the challenges of migration and conducting and maintaining a security maintenance infrastructure for robotic companies.
Therefore, to support the deployment and security of ROS robots deployed on the field, Canonical designed the Robot Operating System Extended Security Maintenance (ROS ESM) as the foundation for security compliance in different industries.
Delivered in partnership with Open Robotics, ROS ESM provides enterprise support for ROS and the Ubuntu OS. Through ROS ESM robots will receive backported security updates that have been tested and curated guaranteeing system stability. We aim to help ROS developers deploy more secure devices by easing security maintenance with ROS ESM.
Get ROS ESM