You're reading the documentation for a version of ROS 2 that has reached its EOL (end-of-life), and is no longer officially supported. If you want up-to-date information, please have a look at Iron.
Conceptual overviews provide relatively high-level, general background information about key aspects of ROS 2.
- The ROS_DOMAIN_ID
- About different ROS 2 DDS/RTPS vendors
- About logging and logger configuration
- About Quality of Service settings
- About ROS 2 client libraries
- About ROS 2 interfaces
- About parameters in ROS 2
- Introspection with command line tools
- Overview and usage of RQt
- About Composition
- On the mixing of ament and catkin (catment)
- About Cross-compilation
The Core Stack Developer Concepts are much more detailed conceptual articles intended for developers who plan modify or contribute to the ROS 2 core:
- About the build system
- About internal ROS 2 interfaces
- About ROS 2 middleware implementations
- ROS 2 Client Interfaces (Client Libraries)
Quick overview of ROS 2 Concepts
ROS 2 is a middleware based on an anonymous publish/subscribe mechanism that allows for message passing between different ROS processes.
At the heart of any ROS 2 system is the ROS graph. The ROS graph refers to the network of nodes in a ROS system and the connections between them by which they communicate.
Nodes: A node is an entity that uses ROS to communicate with other nodes.
Messages: ROS data type used when subscribing or publishing to a topic.
Topics: Nodes can publish messages to a topic as well as subscribe to a topic to receive messages.
Discovery: The automatic process through which nodes determine how to talk to each other.
A node is a participant in the ROS graph. ROS nodes use a ROS client library to communicate with other nodes. Nodes can publish or subscribe to Topics. Nodes can also provide or use Services and Actions. There are configurable Parameters associated with a node. Connections between nodes are established through a distributed discovery process. Nodes may be located in the same process, in different processes, or on different machines. These concepts will be described in more detail in the sections that follow.
ROS client libraries allow nodes written in different programming languages to communicate. There is a core ROS client library (RCL) that implements common functionality needed for the ROS APIs of different languages. This makes it so that language-specific client libraries are easier to write and that they have more consistent behavior.
The following client libraries are maintained by the ROS 2 team:
rclcpp = C++ client library
rclpy = Python client library
Additionally, other client libraries have been developed by the ROS community. See the ROS 2 Client Libraries article for more details.
Discovery of nodes happens automatically through the underlying middleware of ROS 2. It can be summarized as follows:
When a node is started, it advertises its presence to other nodes on the network with the same ROS domain (set with the ROS_DOMAIN_ID environment variable). Nodes respond to this advertisement with information about themselves so that the appropriate connections can be made and the nodes can communicate.
Nodes periodically advertise their presence so that connections can be made with new-found entities, even after the initial discovery period.
Nodes advertise to other nodes when they go offline.
Nodes will only establish connections with other nodes if they have compatible Quality of Service settings.
Take the talker-listener demo for example. Running the C++ talker node in one terminal will publish messages on a topic, and the Python listener node running in another terminal will subscribe to messages on the same topic.
You should see that these nodes discover each other automatically, and begin to exchange messages.