CHAPTER 1

Introduction to Robot Operating System 2

Introduction

This chapter will begin by introducing the challenges of robot programming that have led software developers to use Robot Operating System 2 (ROS 2). ROS 2 is a programming framework designed to empower roboticists and developers to design, build, and simulate advanced robotics applications. The basic concepts of ROS 2, its architecture, and its set of functionalities will be introduced in this chapter, along with a brief overview of its development history. At the end of the chapter, we will learn how to install ROS 2 on our computer running the Linux operating system. The information presented in this chapter will be put into practice in the next chapter.

Structure

In this chapter, we will discuss the following topics:

Robot Programming

Benefits of Using ROS 2

ROS 2 Concepts

ROS 2 Nodes

Communication Models

Nodes Discovery

Packages and Workspace

ROS 2 Distributions and Licensing

ROS 2 Internal Architecture

Data Distribution Service (DDS)

ROS 2 Installation

Installing ROS 2 using Dockers

Testing ROS 2 Installation

Robot Programming

Robotics is in its golden age. New robotic systems capable of performing autonomously different tasks appear every day on the market. From industrial automation to healthcare, from inspection of hazardous environments to household chores, robots have permeated almost every aspect of human life and work, reshaping industries and redefining human-machine interactions. However, the process of creating effective autonomous machines that work robustly is still an open challenge. Among the different aspects behind robotics, a crucial role is represented by robot programming, which is essential to developing smart applications to allow autonomous systems to accomplish advanced operations.

Even though robots can be programmed with classical techniques and languages, programming robots differs from classical programming in several aspects. First, robots must interact with the real world, introducing additional challenges such as sensor integration, elaboration and processing, motor actuation, and quick response to unexpected situations. Robot programming can be sketched into three looping phases:

Sense: Robot programs heavily rely on sensors to perceive their environment and make decisions. This requires programming algorithms for sensor data processing, fusion, and interpretation, which are essential for tasks such as navigation, object recognition, and manipulation.

Plan: Robots need to operate in complex and dynamic environments, accomplishing manipulation or navigation tasks. Programming robot motion involves algorithms for path planning, trajectory generation, and closed-loop control, which must account for factors such as kinematics, dynamics, and collision avoidance.

Act: Robots can move thanks to their actuators. Robotic software must control them to precisely accomplish the desired motion, even in the case of a chain of actuators with multiple motors connected, such as the classical robotic manipulators.

Apart from the implementation of these three levels, which is depicted in Figure 1.1, robots operate in dynamic and unpredictable environments. This means that their programs must be robust, fault-tolerant, and safe. Unlike traditional software failures, errors in robotic systems can have physical consequences, making reliability a critical concern.

Figure 1.1: Sense-Plan-Act architecture

Two additional concepts augment the complexity of designing and building programs for robots. These systems present a tight coupling between hardware and software components. This requires a deep understanding of both the physical hardware and the software architecture to effectively integrate and control the entire system. In addition, robots can be used in various domains, and each of them requires a different and unique knowledge. For example, programming a mobile robot for navigation involves different techniques compared to programming an industrial robot arm for manipulation tasks. In fact, in the first case, the developers should implement software layers to control the wheels of the robot, controlling their velocity and retrieving the performed rotation. In the second case, instead, a number of motors (one for each robotic joint) should be interfaced to be controlled in parallel, avoiding self-collision or similar dangerous situations. Robotic programming requires domain-specific knowledge and expertise to address these challenges effectively.

To summarize, programming robots means not only facing traditional software development problems but also specialized knowledge in robotics, including sensor processing, planning, and system integration, making it a truly heterogeneous process. In this context, a huge help to the robotics community is provided by the Robot Operating System (ROS) framework, as discussed further in the book.

Benefits of Using ROS 2

As discussed in the previous section, designing and building applications for robots means putting together heterogeneous knowledge about programming, domain-specific problems, and sensor and hardware integration. Sometimes a single software developer or a small team is not able to address all these problems due to lack of time, resources, or knowledge. This issue has been addressed by different robotics researchers and developers, giving birth to ROS and, consequently, ROS 2.

If these motivations are strong enough, the original aim of the ROS developers was to share and speed up the development process of the software modules used in robotics, creating a standardization of the libraries and data types used from the robotics applications.

ROS 2 (without space between the acronym ROS and its "version") stands for Robot Operating System 2 and represents a programming framework suitable to design, build, handle, and simulate robotics applications. The general term to which ROS 2 is referred is middleware. This means that ROS 2 is a software layer that fits between the Operating System and the applications built by the developers. In this view, ROS 2 provides a set of tools to develop, maintain, and monitor robotics software. A set of libraries is already set up to solve several key problems of robotics using state-of-the-art techniques.

In a single statement, the definition of ROS 2 is a set of software libraries and tools for building robot applications, ranging from driver interfaces to advanced algorithms and powerful tools for developers.

Let us try to understand the meaning of the ROS 2 definition with a practical example. Imagine that for an academic project or a business demonstration, you need to develop a program for a mobile robot that must surveil an environment and detect possible intruders. A camera sensor can be used to detect intruders. The robot must navigate through the initially unknown environment, avoiding eventual obstacles. The navigation modules can use a 2D lidar. To achieve this task, a set of modules should be implemented, representing the classical pieces of software needed to achieve similar tasks. These are briefly introduced here but will be described in detail in the rest of the book. A sketch of the software architecture is depicted in Figure 1.2 and consists of three levels.

Low-Level: The layer that directly communicates with the robot actuators.

High-Level: The layer consisting of programs in charge of more complex calculations.

Application-Level: The layer that interacts with the user and uses sensor data to solve domain-specific problems.

To be fully autonomous, the following software modules must be implemented:

Motor Control: This module sends control input to the robot’s actuators. Typically, in mobile robotics, this is represented by a velocity command.

Odometry Calculation: This is used to roughly estimate the robot’s position, considering the encoder of the wheels.

Path Planner: This is needed to generate an obstacle-free path considering the status of the environment.

Localization and Mapping: This is needed to refine the initial estimation of the position of the robot so that it can have a more precise and reliable position.

User Interface: This module is used by the user to interact with the robot.

Image Elaboration: This exploits camera data to achieve a specific task, such as detecting intruders.

Figure 1.2: Classical software architecture to accomplish domain-specific tasks with mobile robots

Let us imagine you are interested only in implementing the Image Elaboration module (indicated with dashed borders in Figure 1.2). To have a complete system, you must implement all the other modules as well. Additionally, for the robot to move and gather information from sensors, you need to integrate the hardware with the other modules through software. Therefore, even adding a small feature to the project, such as intruder detection, requires a significant amount of work, and it may not be straightforward. ROS 2 can help solve these and many other challenges with its numerous features. Here are two of those features:

Communication Models: ROS 2 software modules (literally called nodes) can exchange data using a set of interfaces containing the description of typical data types used in robotics (that is, the position of the robot, a velocity control command, a stream of camera images).

Tools and Libraries for Robotics: ROS 2 already implements different drivers for robotic sensors and algorithms, solving complex problems that are configurable and adaptable to different robotic systems.

Returning to the case of the software architecture depicted in Figure 1.2, the developer should only connect the different pieces of code based on the robot configuration. For example, path planner and localization and mapping algorithms can be easily retrieved from the ROS 2 software suite and installed on the robot. Then, using the appropriate interfaces, the robot can move by connecting its output to the low-level control modules.

These features help developers to create modular source code. Imagine that the developer wants to upgrade the robot hardware to improve the performance of the localization software and decides to change the Lidar sensor. Using ROS 2, this can be done just by replacing the hardware component and installing and running the ROS 2 driver for the lidar. The localization algorithm will receive the new data using the same interface as the old one.

Note: Modularity allows developers to build complex robotic systems by breaking them down into smaller, manageable components. Each module, or node, encapsulates specific functionality, such as sensor data processing, motion planning, or actuator control, making it easier to understand, test, and maintain.

Now that the importance of using ROS 2 to build robot software has been introduced, let us discuss in depth all its functionalities.

ROS 2 Concepts

In this section, the main concepts to learn about ROS 2 before starting to program it are detailed.

ROS 2 Nodes

One of the basic concepts of ROS 2 is related to the nodes. In principle, nodes are the programs written by the developer (or downloaded from software repositories) that perform specific calculations. Of course, the number of nodes of a specific application and the number of operations able to perform from that node are defined by the software developer. Typically, each node is devoted to the execution of single and specific tasks, such as sensor data processing, control, or communication. Nodes share data with each other by the ROS 2 interface, enabling modular and distributed system architectures.

In ROS 2, each node can run independently and can be written in various programming languages, facilitating interoperability. In this book, we mainly consider nodes written in Python. If desired, multiple nodes can be created within a process, and these nodes can communicate independently with other nodes. All nodes in the system can be run on a single computer or distributed across multiple computers.

Let us consider for the last time the example made in the previous section. Referring to the architecture represented in Figure 1.2, each ellipse can be developed as a separate node. For example, let us consider the path planner module, which has the objective of generating an obstacle-free geometry path for a mobile robot. It can be represented as a ROS 2 node receiving the initial position of the robot, the destination to reach, and the current environment map, while the output could be the list of waypoints to navigate in order to bring the robot from the start position to the goal position.

In this book, a node is nothing more than a Python script. Moreover, ROS 2 allows the definition of multiple nodes in a single script. This allows you to encapsulate multiple functionalities or components within a single file while still benefiting from the modularity and communication features of ROS 2. Each node would typically handle a specific task or functionality within your robotic system.

Communication Models

As already stated, one of the core functionalities of ROS 2 is represented by the communication models that enable interoperability among several nodes, also developed in different programming languages. These models are made to work with generic or custom interfaces (that can be considered as a set of messages) that connect different parts of the robotic software.

Mainly, three kinds of models are implemented in ROS 2, and each of them has its own ideal usage conditions. In the following, these interfaces are described.

Figure 1.3: Publish-subscribe communication models

Publish-subscribe: This is the most famous and probably used communication model of ROS 2. The basic concept of the publish-subscribe interface is that sometimes information must be streamed as a continuous data flow by just one node and consumed (or received) from one or more nodes. In this setup, the system has one publisher and zero or more subscribers. To share the data using this model, the publisher writes data to a topic that represents the communication channel for sending and receiving data between nodes. Topics can be imagined as a blackboard on which the publisher writes the information to share while the subscriber nodes read from it. In this sense, this communication model is asynchronous since the publisher sends data through the topic independently from the subscribers and the publisher is not blocked during the communication process. Each topic is associated with a unique name and a message type. The type can be seen as the language in which the message is written on the blackboard. A schema of the publish-subscribe model is depicted in Figure 1.3.

Note:If no subscribers for a given topic are detected in the ROS 2 network, data is not streamed, avoiding congestion in the internal network of the computer.

As a practical example, this model is perfectly suitable for the nodes implementing drivers of sensors, such as the driver of a camera sensor. This driver continuously retrieves image frames from the hardware and publishes them on a proper ROS 2 topic. In this example, it is not important if the subscriber nodes lose one or more frames of the streamed messages or read them with a few milliseconds of delay.

Services: This is a synchronous communication model based on the call-and-response paradigm and suitable for operations that require a specific response within a reasonable duration. It is ideal for tasks where the request-response cycle is relatively quick and predictable. Unlike the publish-subscribe, the service request reaches the appropriate service provider, and the response is returned to the correct requester. This process is implemented between two nodes. The service client, which requests specific data, and the service server that generates and provides the requested data. In this context, the server can be seen as the provider of a specific service that is made available to all the ROS 2 nodes of the system. The communication interface, in this case, is a file specifically created based on the service being implemented that is called service, consisting of two fields, a request and a response. The client fills in the request part of the message, sending it to the server. The server calculates the response by putting it into the same message and sending it back to the client. This model should be used to implement remote procedure calls. However, since this is a blocking model, the execution cycle of the client node will be blocked until it receives a reply from the server. Therefore, this model must be used only if the server is able to provide fast responses. Differently, our robot will not be able to react to unexpected situations since it is waiting for a response from the server node.

Like the topic case, a service is identified by a name and an interface type. Note that, if the set of messages of ROS 2 to implement the publish-subscribe model is generic and it is easy to find the message you need to share information among the ROS 2 nodes (such as a sensor message or the position of the robot in a specific frame), services are typically user-defined. Therefore, implementing this model also means to generate the service interface. A schema of the service model is depicted in Figure 1.4.

Tip:The sense-plan-act paradigm discussed in the previous section (Figure 1.1) is implemented as a continuous loop. The robot must be able to check all its input (sensors) and react quickly to any kind of unexpected situation: an obstacle on the path, a new command from the user, and similar. The main loop controlling the robot should never be stopped.

Figure 1.4: Service communication model

As a practical example, the service communication model should be applied when a function must be used from different nodes. Let us imagine that we want to implement a service calculating the cartesian position of the end-effector of a robotic arm (the direct kinematic), and let us make it usable from different nodes. The service accepts the configuration of the robotic arm (that is, the position of the robot joint) as input, returning the position and the orientation of the manipulator. This is a fast calculation that can be solved in a few milliseconds, and different nodes can exploit it without reimplementing the procedure to calculate the direct kinematic.

Actions: Sometimes, we need to implement the remote procedure called executing long-running tasks. In these situations, we can use the actions communication model that helps developers implement a Movement. In this case, the message used by the client to request the execution of a remote function is an action file and consists of three fields: goal, feedback, and result. Similarly to the service model, the client fills in the goal to request the execution of a given action. The server, after receiving the goal, starts the execution, providing feedback to inform the client about the task status and, finally, sending a result. As a result, with this model, we do not block the client’s loop code while waiting for the server response. Instead, the client is constantly informed about the status of the task (using feedback). What if some unexpected situations happen during the server execution? In this case, the server can be preempted by requesting a new goal for the same action, or it can be directly canceled.

As a matter of fact, implementing the actions model is trickier than the publish-subscribe and services, since it is necessary to implement the mechanism to handle preemption and cancellation procedures.

Figure 1.5: Action communication model schema

The communication model established via the ROS 2 action is represented in Figure 1.5. In this schema, it is clear that the action model is built on top of the topic and services. This is transparent to the developer, who just uses action calls to share the goal and the result. However, the goal is implemented as a service. The client fills the request field of the goal service, which is transmitted to the action server. If this goal is accepted, it adds a positive response to the service client. During the execution of the task, the feedback is published from the server continuously. Finally, when the task ends, with a success or failure, the result can be retrieved using the result service.

The client-server communication model is already used by several ROS 2 software modules, and to use them, we need only to implement the client part. This is the example of one of the most famous elements of ROS 2, the navigation stack, in which the server acts as a path and motion planner that receives as a goal the destination where to move the robot, provides feedback on the distance between the current position of the robot and the target, and finally, provides the success of the task if the robot reaches the goal or the failure otherwise. Another condition in which we could use the client-server model could be the motion of the robotic arm. In fact, this is a long-running task (the execution could also last several minutes) and can also fail. For example, if the arm finds obstacles during its motion or cannot reach the specified destination point. In this context, the client will pass the cartesian position to reach the server, which will transform it into a set of joint values that can be actuated consequently. At each iteration, the server could provide the distance of the arm to the goal, or an estimation of the completion time of the task, while the result is also, in this case, a success or a failure.

Nodes Discovery

Now that we have covered the concept of node and intranode communication using services and topics, let us discuss a new feature of ROS 2 nodes: node discovery. Thanks to the node discovery feature, the nodes can be run on remote computers, allowing them to share data among themselves using ROS 2 communication models in a reliable and transparent way for the user. This feature is useful in various operating conditions. For example, imagine your robot is equipped with a camera used to perform a certain inspection task (that is, inspect an environment not accessible for humans or hazardous), or you can use that camera to teleoperate the robot from a ground station computer using ROS 2. Through node discovery, camera data streamed on a topic from the sensor driver can be read from the ground station, as well as teleoperation data streamed from the ground station to the robot. Node discovery is a fundamental aspect of ROS 2’s communication infrastructure, enabling nodes to dynamically discover and establish connections with other nodes on the network. The main features of node discovery are:

Dynamic Configuration: Node discovery allows nodes to dynamically configure and adapt to changes in the network environment. They can join or leave the network, and new nodes can be added or removed without manual intervention.

Decentralized Communication: Nodes communicate directly with each other without relying on a central server or coordinator. Node discovery enables nodes to find and establish direct communication links with other nodes, facilitating efficient peer-to-peer communication across the network.

Scalability: Node discovery enables scalable communication in large-scale robotic systems with hundreds or thousands of nodes. Nodes can discover and connect to each other dynamically, allowing the system to scale gracefully as the number of nodes and the complexity of the system grow. This scalability is essential for deploying ROS 2 in complex robotic applications, such as multi-robot systems or distributed sensor networks.

Interoperability: Node discovery enables interoperability between ROS 2 nodes running on different hardware platforms, operating systems, or communication models. Nodes can discover and communicate with each other regardless of their underlying implementation details, allowing for heterogeneous deployments and seamless integration of components from different vendors or development teams. This feature is also useful to improve the power computation unit of your robotic application. You can easily add a different computer to elaborate weight data (such as images) while maintaining other computers to manage the actuation part.

Figure 1.6: Example of the distributed robotic system

Node discovery is also useful for implementing a multi-robot system, as shown in Figure 1.6. Imagine that a developer must develop a system in which a mobile manipulator (a mobile robot equipped with an arm) brings objects to a fixed industrial arm. As already discussed, this is a typical application that can be implemented using ROS 2 actions. The task to perform is a long-term task that could also fail. By exploiting the node discovery, it is enough to put the two robots in the same network under the same domain id. At this point, the two robots share the action visibility.

We will delve deeper into the topic of node discovery in the upcoming chapters of this book. However, to have an idea of how this feature is automatic and easy to establish, it can be summarized as follows:

Upon startup, a node broadcasts its presence to other nodes within the network that share the same ROS domain, which is determined by a proper environment variable. The other nodes reply to this advertisement with personal information.

Each node periodically advertises its presence so that connections can be made with new nodes of the network even after the initial discovery period.

Nodes advertise to other nodes when they are going to disconnect.

Packages and Workspace

ROS 2 has a structured way to organize source code and it is strictly related to the concept of workspaces. However, to better understand the concept of the workspace, what a package is should be defined.

A package is a container of source code developed in ROS 2. A package can be directly created, downloaded from some repositories, or installed in the system using the operating system package manager. At the same time, the package organization allows us to easily share developed source code with other members of a developer team or the ROS 2 community. In this view, it is possible to define ROS 2 packages as modular units of software containing nodes, libraries, and configuration files, facilitating modularity and reusability in Robot Operating System 2. ROS 2 mainly supports two kinds of packages: C++ and Python packages. However, members of the ROS 2 community have created additional client libraries such as Android, C# Rust, and similar.

Note: This book will be considered only for the creation of Python packages.

A package can contain multiple nodes, organized in different source files. Again, multiple nodes can be bundled within a single ROS 2 package, allowing for modular and distributed development of robotic applications. A package is created using ROS 2 command-line tools, as discussed in Chapter 2, Hands-on ROS 2 Programming using Python, of this book. In addition, a package can contain both mandatory and optional files or directories inside.

The simplest structure of a ROS 2 package created to contain Python nodes is as follows:

ROS2_package/

setup.py

package.xml

resource/ROS2_package

These files are mandatory to identify a ROS 2 package, and their content is used to:

package.xml: A file containing meta-information about the package, such as package information, maintainers and authors, licenses, and dependencies.

setup.py: It contains instructions for how to install the package.

setup.cfg: It is required when a package has executables, so ROS 2 can find them.

resource/: A directory with the same name as your package, used by ROS 2 tools to find the package in the system.

However, creating a package with only those files is useless since there are no configuration or executable files. Apart from previous files, a ROS 2 package can contain the following key elements:

Nodes: Individual processes that perform specific tasks within the robotic system. These are represented by implementation files (for example, mainly written in C++, Python) defining the functionality of nodes and other components.

Launch Files: Configuration files are used to start multiple nodes and set their parameters.

Configuration Files: Files defining parameters, settings, or other configurations used by nodes.

Dependencies: External libraries or packages required for the package to function properly.

Documentation: Descriptions, instructions, and usage guidelines for the package and its components.

Tests: Unit tests, integration tests, or other testing scripts to ensure the correctness and reliability of the package.

While implementing the aforementioned communication models, a ROS 2 package can contain all the necessary files to implement the communication interfaces:

Messages files (.msg): It defines the structure of data exchanged between nodes. Messages can represent sensor readings, control commands, or any other type of data passed between components of the robotic system.

Services files (.srv): It defines a request-response communication pattern between nodes. Services allow nodes to offer functionality that can be called by other nodes, enabling synchronous communication.

Actions files (.action): It defines a more complex communication pattern than services, allowing for asynchronous, goal-oriented behavior.

Now that the concept of package has been described, let us define what a ROS 2 workspace is. A workspace is nothing more than a directory in which all the ROS 2 packages are located. This directory will also contain the files generated during the installation and compilation of new software. In this context, from the workspace, ROS 2 packages are built, installed, and managed. Of course, a ROS 2 workspace can contain several ROS 2 packages, even written in different programming languages. Also, in this case, the files and subdirectories contained in a workspace are not strictly defined. The common structure and main files of a workspace are reported as follows:

ROS2_worskapce/

build/

install/

setup.bash

log/

src/

pkg1/

pkg2/

pkg3/

CmakeLists.txt

The meaning of each directory and file is presented as follows:

build: The directory containing build artifacts generated during the compilation process.

install: Directory where built packages are installed. It contains the executable binaries, libraries, launch files, and other resources necessary to run the ROS 2 packages.

log: Directory where log files generated during the build and runtime are stored.

src: Source directory for ROS 2 packages. Each subdirectory corresponds to a ROS 2 package, containing source code files, configuration files, and other package-specific resources.

CMakeLists.txt: Top-level CMake build script that configures the build process for the entire workspace and specifies dependencies between packages.

setup.bash: Script used to set up environment variables for the ROS 2 workspace. It is typically sourced before working with ROS 2 commands and tools.

However, we will learn how to use and generate these files in the next chapter. In any case, before starting to execute ROS 2 nodes, the workspace in which the package containing the node must be properly sourced (activated) to inform the operating system about its availability. The workspace is not unique. Multiple workspaces can survive together in the same system. This also helps the developer to better organize his work. To allow the coexistence of different workspaces in the same system, the concept of overlay must be introduced.

Overlaying a ROS 2 workspace means that you can have multiple workspace directories and their corresponding packages coexist and be used together. This allows you to extend or modify the functionality of existing packages without directly modifying their source code. Here is how overlaying works in a ROS 2 workspace:

Multiple Workspaces: You can have multiple ROS 2 workspaces on your system. Each workspace is a directory structure containing ROS 2 packages.

Priority order: When you build or run ROS 2 commands, the packages in the currently active workspace take priority. If a package with the same name exists in multiple workspaces, the one in the currently active workspace will be used.

Overlaying: You can overlay one workspace on top of another. This means packages from the overlay workspace are used with packages from the underlying workspace. If a package exists in both the overlay and underlying workspace, the package from the overlay workspace takes precedence.

Overlaying workspaces provides flexibility and modularity in ROS 2 development. For example, it can be used to:

Extend the functionality of existing packages by adding new packages or modifying existing ones without directly modifying the original source code.

Experiment with different versions or variations of packages without affecting the core functionality of the system.

Manage dependencies between packages more effectively by isolating changes or additions in separate workspaces.

In any case, after installing ROS 2, a workspace is already set and ready to be used to execute a set of nodes that comes with its basic installation. In the next chapter, we will see how to create a workspace owned by the user to create or download new packages.

ROS 2 Distributions and Licensing

In this section, let us briefly retrace the history of ROS 2 from its predecessor ROS, explaining also its development cycle and commercial license. ROS 2 is the second version of ROS. The developers of the ROS started the project to address several key challenges and opportunities in the field of robotics research and development:

Lack of Standardization: Before ROS, there was a lack of standardization in robotic software development. Each research lab or organization developed its own proprietary software stack, making it difficult to collaborate, share code, and reproduce experiments across different institutions.

Code Reuse and Collaboration: Robotics researchers and developers recognized the need for a common framework that would facilitate code reuse and collaboration. By sharing libraries, algorithms, and tools within a standardized platform, developers could build upon each other’s work and accelerate progress in the field.

Complexity of Robotic Systems: Robotics applications are inherently complex, involving multiple sensors, actuators, and algorithms working together to perform tasks in real-world environments. ROS aimed to provide a modular, distributed architecture to simplify the development and integration of these components.

Rapid Prototyping and Experimentation: Researchers needed a platform that would enable rapid prototyping and experimentation, allowing them to test algorithms, simulate scenarios, and iterate designs quickly and efficiently. ROS provided tools for simulation, visualization, and debugging, facilitating this iterative development process.

Openness and Community Engagement: The developers of ROS believed in the power of open-source collaboration and community engagement. By making the framework open-source and inviting contributions from researchers, developers, and enthusiasts worldwide, they aimed to create a vibrant ecosystem of tools, libraries, and resources for robotic software development.

ROS has become a widely adopted platform in academia, industry, and hobbyist communities, driving innovation and advancement in robotics research and development. It officially supports only Linux distributions, ensuring compatibility with Ubuntu Linux.

Development started in 2007 at the Stanford Artificial Intelligence Laboratory, when the basic functionalities of ROS were implemented, such as message passing, visualization, and simulation for robotic systems. ROS quickly gained popularity within the robotics community due to its open-source nature, modular design, and rich ecosystem of packages and tools. The development of ROS 1.x continued with multiple releases introducing new features, improvements, and libraries to the framework, becoming the standard-de-facto of robot programming. Unofficial releases of ROS also began to support other operating systems, embedded devices, and programming languages.

Despite its success, ROS 1.x faced certain limitations and challenges, particularly in terms of real-time performance, scalability, and compatibility with emerging hardware platforms and middleware technologies. These limitations prompted discussions within the community about the need for a new version of ROS to address these issues. For this reason, in 2016, the ROS community officially launched the ROS 2 initiative aimed at designing and developing a next-generation version of ROS that would address the shortcomings of ROS 1.x and meet the evolving needs of robotics research and development. The ROS 2 initiative was driven by Open Robotics in collaboration with a diverse group of contributors from academia, industry, and the open-source community. The development of ROS 2 has been ongoing since the launch of the initiative, with a focus on addressing key requirements such as real-time capabilities, better support for different hardware architectures, improved performance and reliability, and enhanced interoperability with existing middleware and communication protocols. ROS 2 has gone through several alpha, beta, and release candidate versions, with each iteration incorporating feedback and contributions from the community. Overall, the birth of ROS 2 was driven by the need to overcome the limitations of ROS 1.x and to provide a more capable, flexible, and scalable framework for robotics software development. ROS 2 builds upon the success of its predecessor while introducing new features and improvements to support the growing complexity and diversity of robotic applications.

But who is the maintainer and the developer of ROS 2? ROS 2 is primarily developed and maintained by the Open Robotics organization, formerly known as the Open-Source Robotics Foundation (OSRF), a non-profit organization dedicated to the development and promotion of open-source software for robotics research, development, and education. However, the development of ROS 2 also involves contributions from a wide range of individuals and organizations within the robotics community. This includes researchers, engineers, hobbyists, and companies from both academia and industry who contribute code, documentation, bug fixes, and other resources to the project. The development process for ROS 2 is collaborative and transparent, with contributions being made through GitHub repositories, mailing lists, forums, and community events. Open Robotics provides leadership and coordination for the project, but the success and growth of ROS 2 rely on the active participation and engagement of the broader robotics community. As for the ROS 2 core source, its development cycle involves the release of periodic versions, known as distributions, which include new features, improvements, and bug fixes. The development and release process is managed by the Open Robotics organization, with input and contributions from the ROS community.

The development cycle of ROS 2 typically follows a series of periodic releases (called distributions). Each distribution includes a new or upgraded core package, libraries, and tools. Distributions are named alphabetically and typically follow a two-year release cycle, with a new distribution released approximately every year (this development cycle is like the one of Ubuntu). Each distribution introduces new features, improvements, and compatibility enhancements based on feedback from users and developers.

Choosing the correct distribution for starting a new project is fundamental to avoiding compatibility issues with the operating system in use and to avoid using deprecated ROS 2 packages. To give you an idea, Table 1.1 reports the latest ROS 2 distributions with their release and end-of-support dates.

Table 1.1: List of ROS 2 releases from 2019 to 2023

As shown in Table 1.1, multiple distributions are supported and developed at the same time or have a supporting period longer than others. In fact, every third ROS 2 distribution is designated as a Long-Term Support (LTS) release, which receives extended maintenance and support for a longer period compared to non-LTS releases. LTS releases are intended to provide stability and reliability for users who require long-term support for their robotic applications. For this reason, if a developer starts a project that is expected to be longer than 2 years, relying on an LTS release is fundamental to ensure that their software remains supported and maintained until the end of the project.

Note: In this book, we will use ROS 2 humble, the last release LTS at the time of writing.

Regarding the ROS 2 releasing license, ROS 2 is primarily distributed under the Apache 2.0 license. This license is an open-source license that permits users to use, modify, distribute, and sublicense the software, whether for commercial or non-commercial purposes, as long as it includes the original copyright notice and the terms of the license in any distribution. The Apache 2.0 license is known for being permissive, allowing for the creation of proprietary derivative works based on the original code. It also provides certain protections for both contributors and users of the software. However, it is important to note that while ROS 2 itself is distributed under the Apache 2.0 license, individual packages and dependencies within the ROS ecosystem may be distributed under different licenses. It is always advisable to check the license of each package or component you use within your ROS 2 projects to ensure compliance with their respective licensing terms.

ROS 2 Internal Architecture

The internally designed architecture of ROS 2, as depicted in Figure 1.7, is shaped as a multiple-layer architecture in which each layer provides a specific functionality or Application Programming Interface (API).

Figure 1.7: ROS 2 software architecture design

At a higher level of abstraction, there is the user source code