ROS 2 Architecture Overview

Below is a high-level diagram of the ROS 2 architecture.

Data Distribution Service (DDS) Architecture Overview

ROS 2 uses DDS as its middleware. DDS reduces coupling, increases scalability, and improves performance, reliability, security, and flexibility. It is for this reason why it is common to see the DDS communication protocol used in the defense industry. 

Below is a high-level diagram of the DDS publish-subscribe communication protocol using an example robotics application.

ROS 2 has three main ways nodes (i.e. the individual C++ or Python programs that make up the robotics system you’re building) can communicate with each other.

• Topics
• Services
• Actions

Below I will detail the circumstances when you should use each of these communication methods.

Use Topics for Continuous Data Streams

Use topics when you have continuous data streams (e.g. sensor data, robot state, etc.). 

An example of a continuous data stream is laser scan data generated by LIDAR. Data will be continuously published on the topic as long as the robot is up and running.

The data types used in topic-based communication are known as messages. Nodes publish messages via topics, and nodes subscribe to messages via topics.

You can use standard ROS 2 message data types, or you can create your own custom message data types.

Use Services for Quick Request/Response Communication

Services should be used for fast request/response communication. A Service Client node sends a request (typically for some data) to a Service Server node. The Service Server node then replies to that request with a response.

An example of a service is in this post where I call a service to load a new map once a robot has reached a new floor of a building.

Use Actions for Long-Running Tasks That Have a Clear Beginning and End

Actions should be used for long running processes that have a clear beginning and end. An action is made up of a goal, interim feedback (to keep you updated on the progress being made to reach the goal), and a result.

An Action Client node sends a request (i.e. a Goal) to an ActionServer. The goal might be, for example, for the robot to move to a particular location in the environment.

The Action Server node gives the Action Client feedback on the progress it is making towards the execution of that goal (e.g. the robot’s most recent position along the path towards the goal location).

When the Action Server completes the goal, it sends a result message to the ActionClient.

That’s it! Keep building!

In a ROS 2 project, code is organized into packages. A package is just a directory that contains files and folders. Each package might contain a mixture of code (e.g. ROS 2 nodes), data, libraries, images, documentation, etc. Every program you write in ROS 2 will need to be inside a package.

Suppose we have a ROS 2 package named my_robot_package. The file tree below shows a possible structure for a ROS 2 package. This structure is aligned with best practice for a ROS 2 package. I made a few tweaks (e.g. added rviz and maps folders). Note: You do not need to create all these folders in every ROS 2 package.

my_robot_package/

├── README (Describes the package*. Example)

├── CHANGELOG.rst (REP-0132 compliant changelog. Example.)

├── CONTRIBUTING (Describes the contribution guidelines. Example.)

├── LICENSE (A copy of the license or licenses for this package. Usually Apache 2.0. Example.)

├── setup.py (Where to install the Python modules. Python-only packages. Example.)

├── CMakeLists.txt (How to build the code and where to install. Packages with C++ code. Example.)

├── package.xml (Defines the package properties as defined by this convention. Example.)

├── action (Holds custom action definitions. Example.)

├── config (Holds configuration files … i.e. yaml. Example.)

├── doc (Holds all the documentation. Example.)

├── launch (Holds launch files. Example.)

├── maps (Holds map files. Example.)

├── models (Holds SDF model files. Example.)

├── msg (Holds custom message definitions. Example.)

├── rviz (Holds RViz configuration files. Example.)

├── srv (Holds custom service definitions. Example.)

├── test (All system (btw packages), integration (btw code), and/or unit (w/n code) test data. Example.)

├── urdf (Contains URDF files. Example.)

├── worlds (Contains Gazebo world files. Example.)

├── my_robot_package (Holds Python files that can be imported into other Python files. Example.)

│     ├── __init__.py

│     └── python_module_to_import.py

├── scripts (Holds Python code.**. Example.)

│     └── py_node.py

├── include (Holds C++ header files and libraries we want to use inside this package. Example.)

│     └── my_robot_package

│               └── cpp_header.hpp

└── src (Holds C++ source code.***. Example.)

        └── cpp_node.cpp

* All packages should have these documentation elements present in their README or linked to from their README:

• Description and purpose
• Definition and description of the public API
• Examples
• How to build and install (should reference external tools/workflows)
• How to build and run tests
• How to build documentation
• How to develop (useful for describing things like python setup.py develop)
• License and copyright statements

** Check this page for best practices on code style and language versions for C++, Python, and README files.

*** Each source file must have a license and copyright statement, checked with an automated linter.