Coincidentally or not, after 10 years of ROS 1, the Open Source Robotics Foundation has launched a new version called ROS 2. ROS 2 (the code name “Ardent Apalone” – Apalone is a genus of turtles in the family Trionychidae) was officially released at the end of 2017. The release of the new ROS has gone a little unobserved by the usual ROS users, and it is understandable since there are few articles in online about this release.
So in this article, I will try to describe why Ardent Apalone appeared and what gaps left by ROS 1 will be covered by the new ROS 2 version.
Before going into the subject, I will remind that ROS (The Robot Operating System) is not an operating system as we know. ROS (or ROS 1) is a solution designed to be hosted by an operating system like Linux. Or, as the majority calls it, this is a meta-operating system. And of course, it’s designed for robots.
Like ROS 1, the ROS 2 is the network of nodes that allows communication/exchange of information between the components used in the robot. So far, nothing new. Everything is the same as we know it today.
One of the reasons behind the launch of a completely new version (ROS 2) and not the improvement of ROS 1 is the significant changes to the framework. The team that developed ROS 2 has chosen to implement the new changes safely in the new framework. So, they did not want to alter the ROS 1 variant to not affect the performance and stability of the current versions of ROS. From my point of view, it’s a wise decision. Especially because there is a plan to implement the ROS 1 nodes to work with the ROS 2 nodes together on the same robot. So there will not be significant changes to the systems that will work with both ROS variants.
Below I made a list of the new features of ROS 2.
1. Three compatible operating systems
One of the news is that besides Linux, ROS 2 is compatible with Windows 10 and Mac OS X 10.12 (Sierra). If the support of OS X is not new (officially ROS 1 were compatible with OS X as an experimental part), the support for Windows is something new for ROS.
2. Real-time support
ROS 1 has not been designed for real-time applications. The goal of ROS 1 was to create a simple system that can be re-used on various platforms. In other words, the use of ROS has led to a significant reduction in the development of a robot.A real-time system must update periodically to meet deadlines. The tolerance to errors is very low for these systems.
The example below is used by the ROS team to describe a situation when a system needs real-time support.
In other words, the real-time support is more about computation delivered at the correct time and not performance. If a system fails to send a response is as bad as giving a wrong response. This new feature is very useful in safety- and mission-critical applications such as autonomous robots and space systems.
3. Distributed discovery
This new feature facilitates, in some way, the communication between nodes. In other words, the nodes in ROS 2 do not need the master node to change messages between them. If you run a C ++ written node and another in Python (a talker and a listener), the nodes will identify each other and start communicating automatically. You may be wondering how to identify the nodes if there is no master node to allow authentication. In ROS 2, the role of the master node was taken over by the ROS_DOMAIN_ID environment variable. When a ROS 2 node is launched, it makes its presence known in the network to other nodes that share the same ROS domain.
4. Node lifecycle management
The most important thing is that a managed node presents a known interface and is executed according to a known life cycle machine. This means that the developer can choose how to manage the life cycle functionality.
ROS 1 had no security issues because it did not exist. With ROS 2 we can talk about security. It integrates the transport layer of ROS 1 with an industry standard transport layer that includes security. The layer is called Data Distribution Service (DDS).