It’s a little more than a year since the first official release of ROS 2 has been released.
It’s a little more than a year since the first official release of ROS 2 has been released. While the new version of the Robotic Operating System was promising, many features were still under development.
With the release of ROS 2 Crystal Clemmys in December 2018, ROS 2 has gained a lot of maturity and we felt it was time to add support in ROS 2 for the ZED and its 3D computer vision software stack.
One year after Crystal, in December 2019, ROS 2 Eloquent Elusor has been released with many changes and improvements on stability.
ROS 2 introduces a lot of changes with respect to the ten-year-old ROS. The official ROS 2 design post presents these changes in detail.
The biggest step forward is in the development languages. ROS 2 supports Python v3.5, C++11, C++14 and C++17. The “Boost” library is not a dependency anymore.
Also, while ROS was created with the PR2 robot in mind, ROS 2’s design targets every kind of robot, with an emphasis on robot security, real-time control, and distributed control.
In ROS, you can write your code either as a ROS node or as a ROS nodelet. ROS nodes are being compiled into executables. ROS nodelets on the other hand are being compiled into a shared library which is then being loaded at runtime by a container process.
In ROS 2 the concepts of node and nodelet have been unified and each not is now a Component, very similar to the nodelet in ROS. In ROS 2 a single process can execute more than one node, using Composition, exploiting the intra-process communication feature.
ROS communication infrastructure is based on a custom serialization format, a custom transport protocol and a custom central discovery mechanism. ROS needs a “master node” running on one of the machines of the robot infrastructure to relay all messages between the different nodes..This means that that if the communication with the “master” node fails, the whole system collapses.
ROS 2 has an abstract middleware interface that provides serialization, transport, and discovery. Currently, all implementations of this interface are based on the DDS standard. This enables ROS 2 to provide various Quality of Service policies (QoS) that improve communication over different networks. Playing with QoS parameters gives direct control over the reliability, latency and lifespan of each published message. You can reduce the latency of a sensor message that does not need reliability, but guarantee that a message will remain available until it does not reach its destination.
Yuya Maruyama’s “Exploring the Performance of ROS 2” provides an excellent analysis of the communication improvements in ROS 2.
In ROS, most nodes have their own main functions. In ROS 2, components can be subclassed from a life cycle component. The life cycle can be used by tools like roslaunch to start a system composed of many components in a deterministic way, knowing the real state of each node in every moment of its “life”.
ROS launch files are based on XML tags with very limited capabilities. In ROS 2, the launch files are written in Python, which enables more complex logic like conditionals. The Python launch system gives complete control over life cycle components. Users can start each node when a well-defined situation occurs. For example, the file could start the motor control node only when all the sensor nodes are ready to provide information.
In ROS, a single global server takes care of all the parameters available in the whole system. Users must instantiate a node-specific dynamic reconfigure server for each node in order to handle real-time changes.
ROS 2 eliminates the concept of global parameters. Each node has its own parameter set. When a parameter changes, it notifies the node about the event, which can handle the new value.
Users can’t define the parameters in the launch file like in ROS. But as they need to provide one or more YAML files, parameter management is still simple and organized.
ROS does not support writing real-time code, instead relying on external frameworks like Orocos. In ROS 2, it will eventually be possible to write real-time nodes when using a proper RTOS.
The ZED wrapper for ROS 2 exploits many of the new functionalities offered by ROS 2. The primary features include:
Point clouds, RGB and depth streams, stereo sync stream, objects bounding boxes and skeletons… everything available in Rviz2.
The wrapper comes with a complete guide describing all available features, plus C++ tutorials and examples about how to retrieve the main information from a ZED camera connected to the ROS 2 network.
A dedicated GitHub repository is available with many tutorials and examples:
Colored point cloud and RGB stream in RVIZ2
The current version of the ZED ROS 2 Wrapper only supports ROS 2 Eloquent Elusor running on Ubuntu 18 machines.
To get started with the ZED in ROS 2, download the new ROS 2 wrapper and read the online documentation. If you test it, please let us know what you think by submitting issues and suggestions on GitHub.
