You're reading the documentation for a development version. For the latest released version, 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
- About topic statistics
- Introspection with command line tools
- Overview and usage of RQt
- About Composition
- On the mixing of ament and catkin (catment)
- About Cross-compilation
- About ROS 2 Security
- About tf2
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
- About ROS 2 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.
ROS 2 includes the ability to secure communications among nodes within the ROS 2 computational graph. Similar to discovery, security happens through the underlying ROS 2 middleware (provided it has support for the corresponding security plugins). No additional software installation is needed to enable security; however, the middleware requires configuration files for each ROS graph participant. These files enable encryption and authentication, and define policies both for individual nodes and for the overall ROS graph. ROS 2 also adds a master “on/off” switch to control security behavior.
ROS utilities can create the authoritative trust anchor for a ROS application, or an external certificate authority can be used.
See the ROS 2 Security article for additional details or ROS security features.