Introduction to Robot Operating System 2 (ROS 2)
The ROS 2 ecosystem consists of these four pivotal elements:
Data Distribution Service (DDS): ROS 2 facilitates communication between nodes via ROS Middleware Interface (RMW), which uses Data Distribution Service (DDS) as its middleware. DDS uses the Quality of Service (QoS) profile to provide real-time communication, scalability, performance enhancement, and security benefits to ensure efficient and reliable data exchange in a decentralized manner.
Tools: ROS 2 offers a suite of developer tools, which cover a wide range of functionalities and accelerate application development. The tools include launch, introspection, debugging, visualization, plotting, logging, and playback.
Capabilities: ROS 2 provides advanced features such as node lifecycle management, which allows developers to have fine-grained control over the states and transitions of nodes, enhancing system reliability and robustness. It also includes built-in security measures, such as authentication, encryption, and access control, ensuring secure communication between nodes. Additionally, ROS 2 supports real-time computing, making it suitable for applications that require precise timing and low-latency communication, essential for time-critical robotic operations.
Ecosystem: The ROS 2 ecosystem is supported by a vibrant community of developers, researchers, and industry professionals who contribute to a rich repository of open-source packages and libraries, enhancing the platform's functionality. This community-driven effort ensures continuous improvement and innovation. Adoption of ROS 2 across various industries, including automotive, aerospace, and healthcare, demonstrates its versatility and reliability.
This topic explains a ROS 2 computation graph in detail.
ROS Domain ID
Every ROS 2 network has a domain ID. The domain ID distinguishes different ROS 2 networks
that may be running on the same physical network. Nodes within the same domain ID can
freely discover and send messages to each other, while nodes on different domain IDs
cannot. By default, all ROS 2 nodes use domain ID 0. You can modify the domain ID using
the ROS_DOMAIN_ID
environment variable.
Nodes
Nodes are the basic building blocks of ROS applications, that are responsible for all the computations. They are independent processes that communicate with each other by sending and receiving messages. Nodes can publish or subscribe to topics, act as service clients or servers, and act as action client or servers. Nodes also have configurable parameters associated with them. Nodes establish connections with each other through a discovery process.
Discovery
Discovery of nodes is the process of automatically finding and connecting to other nodes on the ROS 2 network. Discovery happens on the network with the same ROS domain, identified with the domain ID. Nodes advertise their presence to other nodes in the following scenarios.
Starting of the nodes.
Connection establishment with newer entities, periodically.
Shutting down of the nodes.
Nodes communicate with other nodes using one of the three communication interfaces: topics, services, and actions.
Topics
The individual communication channels that nodes use to communicate with other nodes are called topics. A topic can have several nodes publishing to it, and several nodes subscribing to it.
Publisher –– Publishers are nodes that produce data. A node can publish a specific type of message over a topic and make it available for other nodes.
Subscriber –– Subscribers are nodes that consume data. A node can subscribe to messages or information published on a topic.
Topics are used to publish and subscribe to data that is continuously updated, including sensor data and robot state.
Messages
Messages are the data units exchanged between nodes. They are described in a
.msg
file and have two parts, namely fields and constants. Nodes
can publish to a topic to send messages to other nodes or subscribe to a topic to
receive messages from other nodes. Messages can contain any type of data, such as sensor
readings, actuator commands, images, and so on.
Services
Nodes also communicate with each other using services. Services are used for quick tasks
where a node, known as the service client, requests a service from another node, known
as the service server, which returns the result as a response. A service message is
described in a .srv
file and comprises of two parts, a request and a
response.
Client –– A service client is the node which requests to perform a computation on its behalf. The client creates the request part of the service message.
Server –– A service server is the node which accepts the service request and performs the required computation. The server then fills up the response part of the service message.
Services are used for remote procedure calls that are typically short-lived, such as querying the state of a node, performing calculations or conversions, and so on.
Actions
Action is another communication mechanism for long-running tasks. A node, known as the
action client, sends a goal to another node, known as the action server, which provides
feedback on the goal's progress and sends a result message upon completion. An action
message is defined in an .action
file and comprises of three parts: a
goal, feedback and a response.
Client –– An action client is the node which requests a goal to be completed. It can track the execution status of the goal and cancel goals if necessary.
Server –– An action server is the node which accepts the goal and handles the execution of actions requested by the action client. It sends out feedback as the action progresses and returns a result when the goal is achieved.
Actions are used for tasks that involve multiple steps with feedback, such as navigation (reaching a specific location), manipulation (picking up an object), and so on.
Packages
Packages in ROS 2 serve as modular units for organizing and sharing code. Packages comprise
of source code, configuration files, and documentation, promoting code reuse and
maintainability. To manage and build these packages effectively, ROS 2 employs
colcon
, a build tool specifically crafted for ROS 2
projects.
A workspace is a directory containing ROS 2 packages. Workspaces provide a structured hierarchy, ensuring that packages are organized effectively. A single workspace can contain several packages, each in their own folder.
Parameters
You can configure nodes using parameters. Each node has a set of parameters associated with it in a ROS 2 system. You can use parameters to store and access data from different nodes. Each parameter has three parts: a key, a value, and a descriptor. The key, which is a string, names the parameter, while the value can be of various types, such as integers, floats, booleans, strings, or lists (arrays). Initially, all descriptors are empty, but they can include parameter descriptions, value ranges, type details, and other constraints.
ROS Middleware (RMW)
DDS is a middleware protocol that enables real-time, high-throughput, and low-latency communication between distributed systems. DDS is a key component of ROS 2. By using DDS as its underlying middleware, ROS 2 provides a reliable, efficient, and scalable platform for developing robot applications.
The ROS middleware interface acts as an abstraction layer between ROS 2 applications and the underlying DDS implementation. It provides a unified interface that simplifies the development process and allows seamless switching between different DDS implementations without code changes.
Quality of Services (QoS)
Quality of Service (QoS) in ROS 2 is a set of policies that define how nodes communicate data between themselves. These policies allow developers to fine-tune the behavior of ROS 2 communication to meet the specific needs of their applications. For instance, you can use QoS policies to ensure that nodes deliver data reliably, even under network disruptions or node failures.
QoS policies address various aspects of data communication, including history, depth, reliability, durability, deadline, lifespan, liveliness, and lease duration.
History –– Defines the number of past data samples that a subscriber can access.
Depth –– Refers to the maximum number of messages that can be queued for a particular topic.
Reliability –– Ensures that data samples are delivered reliably and in the correct order.
Durability –– Determines how long data samples are stores to ensure data persistence for late-joining subscribers.
Deadline –– Defines the maximum amount of time allowed between messages.
Lifespan –– Defines the maximum amount of time the network considers a message valid.
Liveliness –– Determines how entities report that they are still alive.
Lease Duration –– Defines the maximum amount of time a publisher has to indicate that is it alive before the system considers it to have lost liveliness.
For more information on how to manage QoS policies, see Manage Quality of Service Policies in ROS 2.
Transformations (tf2)
ROS 2 uses transformations to express an object’s position and orientation in relation to another object. It uses a coordinate frame to define the position and orientation of an object in space. You can use the tf2 transform library in ROS 2 to represent and manage transformations between different coordinate frames.
For more information on how to receive, send, verify, and apply ROS 2 transformations, see
ros2tf
.
ROS 2 Integration in MATLAB and Simulink
This image provides a high-level overview of how ROS 2 is implemented and integrated within MATLAB® and Simulink® environments. It breaks down the integration into three layers: application layer, middleware layer, and communication layer.
Application layer –– MATLAB and Simulink offer APIs and blocksets for integration with ROS 2, enabling users to incorporate their custom code and models into MATLAB scripts and Simulink models. The APIs and blocksets facilitate the utilization of ROS 2 capabilities within these environments.
Middleware layer –– The middleware layer, based on DDS for ROS 2, acts as a bridge between the application layer (MATLAB® and Simulink®) and the communication layer. It includes client libraries and APIs that facilitate communication and interaction with the ROS 2 system.
Communication layer –– The underlying communication protocol for ROS 2 is DDS, which handles the actual data exchange between nodes in a distributed system.