ROS2 - Basic concepts
Let's dig into the ROS2 concepts, starting with the basic ones. Wherever used, ROS means in the general context of both ROS1 & ROS2, unless specified.
Client library
The base library of ROS2 is written in C, called ROS client library or rcl, which sits between these other client libraries and the DDS communication interface. Other libraries are built on top of rcl and act as wrappers for other programming languages to implement ROS code. Code written using these different client libraries can share messages with each other because all the client libraries implement the necessary code generators that provide the users with a capability to interact with ROS2 interface files in their respective language. E.g. rclcpp, rclpy. The advantage of this approach is that If any changes are made to the logic/behavior of the functionality in the core rcl library, all client libraries that use the rcl will have these changes reflected in them.
Nodes
Picture courtesy: https://docs.ros.org/en/foxy/_images/Nodes-TopicandService.gif
Normally a ROS2 system revolves around a ROS graph which visualizes the interconnected network of nodes within the system. These nodes can be seen as processes or participants or simply executables that use topics as data channels to communicate messages between them. Nodes can subscribe to a topic or publish to it. All nodes subscribed to the same topic will receive the published data or message on that topic. Nodes can provide configurable parameters to change their behavior during run-time.
Topics & Messages
In the ROS publish - subscribe model, publisher nodes produce the data and subscriber nodes consume the data. The data communication between the nodes happens via topics or topic name which are essentially data channels that allow passage of message information between various nodes. These messages can be discrete data like interrupt information or continuous data stream like robot state, sensor readings etc. All publishers and subscribers that are on the same topic name can directly communicate with each other. Also, when data is published to the topic by any of the publishers, all subscribers in the system will receive the data. Messages contain specific information and may contain one or more datatypes in it.
Services
Apart from just publishing and subscribing to information, nodes can often act as a service client to have another node in the system perform a computation on their behalf. The node that performs this computation for another node is a service server. This is like remote procedure calls where the client (requester) waits for the server (responder) to make a short computation and return a result. To maintain a distributed architecture, each node periodically advertise their presence so that connections can be made with new-found entities, allowing discovery. Hoever, Nodes will only establish connections with other nodes if they have compatible Quality of Service settings.
Actions
Picture courtesy: https://docs.ros.org/en/foxy/_images/Action-SingleActionClient.gif
ROS2 services are expected to compute and return quickly, since the client is generally waiting for the result. If the computation is long-running, actions should be used instead of services. For such long-running computations, a node can act as an action client to have another node perform the computation on their behalf, or as an action server to provide functionality to other nodes. Actions can be considered as long-running remote procedure call with feedback and the ability to cancel or preempt the goal. In ROS2, actions enable one node (the client) to send a request to another node (the action server) to perform a specific action. While the action is being performed, the server will constantly send feedback to the client with details about the progress of the action being performed. Once the action is completed, the server will send a result to the client with the final action outcome. ROS actions are like ROS services, except that the action server sends feedback, while the ROS service would not.
Namespaces
Namespaces provide a method to divide a ROS network into different isolated groups. This is very useful in multi-robot systems and when managing large projects. It creates a unique context for ROS nodes, topics, and services. In other words, namespaces allow the ROS nodes to have the same name but operate in different contexts. For example, when two robots in the same network have nodes and topics with the same name, giving unique namespaces allow them to operate independently.
Parameters
In ROS2, parameters are linked to nodes and are used to configure the nodes at startup or during runtime, without any changes to the code. Parameters can be created and used to control the behavior of the nodes, even during runtime. They act like settings for a node and each node maintains its own parameters. A node can register a callback to be informed when a parameter is changed by user, allowing to tune the node behavior on the fly.
Launch files
For a complex ROS system, there will be multiple nodes and running each of their nodes will present a huge task. Hence ROS allows automation in this scenario using launch systems. The launch system in ROS automates the running of multiple nodes with a single command. It also contains the configuration of the system, nodes to execute, arguments to pass to nodes, etc. Launch files can be written in Python, XML, or YAML.
Command line tools
ROS2 has a plethora of commands that can be used for a variety of tasks. The main command is ros2 followed by a subcommand and arguments. As ROS2 uses this distributed discovery process for nodes to connect to each other, it can take time for ROS nodes to discover all other participants in the ROS graph. Because of this, a long-running daemon is automatically started in the background when the relevant command-line tools are used for the first time. This daemon stores information about the ROS graph to provide faster responses to queries.
