Diving into the Functioning of Robotics Operating Systems (ROS)

Digging towards more technical aspects of new-age technologies like Artificial Intelligence, Machine Learning, and Data Science, we come across various platforms, tools, and libraries that support the algorithms of these innovative approaches. But when it comes to robotics, all we can think of is mechanical parts and a mere intelligent software that helps operate it.

Little did we know about Robotics Operating Systems (ROS), which is also a great part of Robotics mechanisms.

As noted by the Tech Republic, "ROS" stands for robot operating system, though it's not really an operating system; instead, it's a set of software libraries and tools that help developers build robot applications. While ROS (1.0) started off as more of an academic, hobbyist tool, a new version was released in 2017 (2.0) that has a more enterprise flavor, with support for real-time, multiple robots working together, production environments, and more. Though it sounds like a cool upgrade on a venerable (non) operating system, ROS 2 broke many of the APIs that ROS developers depend on."

Moreover, in an interview with IEEE Spectrum, Brian Gerkey, CEO of Open Robotics, the foundation behind ROS development said, "but it's still worth it to make the jump to ROS 2. The future of robotics depends on it."

What Changed from ROS 1 to ROS 2?

Each change is described as briefly as possible from ROS1 to ROS 2.

Platforms

ROS 1 is only being CI tested on Ubuntu. It is actively supported by the community on other Linux flavors as well as OS X.

ROS 2 is currently being CI tested and supported on Ubuntu Xenial, OS X El Capitan as well as Windows 10 (see ci.ros2.org).

Languages

C++ standard

The core of ROS 1 is targeting C++03 and doesn't make use of C++11 features in its API. ROS 2 uses C++11 extensively and uses some parts from C++14. In the future ROS 2 might start using C++17 as long as it is supported on all major platforms.

Python

ROS 1 is targeting Python 2. ROS 2 requires at least Python version 3.5.

Reusing existing middleware

ROS 1 uses a custom serialization format, a custom transport protocol as well as a custom central discovery mechanism. ROS 2 has an abstract middleware interface, through which serialization, transport, and discovery is being provided. Currently, all implementations of this interface are based on the DDS standard. This enables ROS 2 to provide various Quality of Service policies that improve communication over different networks.

Build system

For more information about the build system please see the ament article.

Support other build systems beside CMake

Every ROS package is a CMake project. In ROS 2 other build systems can be easily supported. For now, the build tool supports plain Python packages beside CMake.

Python packages

In ROS 1 a package with Python code can only use a small subset of the features available in setup.py files since the setup.py file is being processed by custom logic from within CMake. In ROS 2 a Python package can use anything in setup.py files, e.g. entry points since they are being invoked with python3 setup.py install.

Environment setup

In ROS 1 the build tool generates scripts that must be sourced in order to set up the environment before being able to use the built ROS packages. This approach only works when the ROS packages are being built with ROS specific build tool.

In ROS 2 the environment setup is separated into package-specific scripts and workspace-specific scripts. Each package provides the necessary scripts to make itself usable after being built. The build tool only invokes the workspace-specific scripts which then call the package-specific scripts.