ROS 2 Explained: Architecture, DDS, Setup, and Robotics Workflows

Updated on Oct 7, 2026

9 min read

ROS 2 (Robot Operating System 2) is an open-source framework for building robot applications from cooperating programs. It provides communication, tools, and conventions for connecting sensors, controllers, and higher-level behaviors without requiring every component to be one large program. This guide explains its architecture, where it fits, and how to start a small Python node. ROS 2 is middleware and a software ecosystem, not a complete operating system or a substitute for robot safety engineering.

What Is ROS 2?

ROS 2 is a collection of client libraries, command-line tools, build and launch systems, message definitions, and middleware interfaces for robotics. A ROS 2 application is usually a set of nodes: separate processes or composable components that each perform a focused job and exchange typed data.

For example, a mobile robot might run a camera driver, an object detector, a localization component, a planner, and a motor controller. ROS 2 supplies common ways for those parts to discover one another and exchange data. It does not prescribe the robot’s mechanics, algorithms, operating system, or safety certification.

The Problem ROS 2 Solves

Robots combine components with different owners, languages, update rates, and hardware interfaces. Without a shared communication and tooling layer, teams must build custom protocols, tightly couple modules, and repeatedly solve logging, discovery, configuration, and deployment problems.

ROS 2 gives those components standard interfaces and communication patterns. It was designed for distributed robots and production constraints that are difficult to address with a single machine-local coordinator. Compared with ROS 1, ROS 2 uses a middleware abstraction and supports distributed discovery, configurable Quality of Service (QoS), and security capabilities. Compatibility is not automatic: ROS 1 and ROS 2 have different APIs and message-generation workflows, so systems that need both use a separately configured bridge.

How ROS 2 Works: Architecture

A simplified data path is sensor driver node -> typed ROS message -> ROS client library -> RMW middleware implementation -> network or local transport -> subscribing node. The reverse direction carries commands and service or action responses.

Nodes and executors: Nodes own publishers, subscriptions, services, actions, timers, and parameters. An executor schedules their callbacks. The executor and operating-system scheduler affect when work runs; ROS 2 alone does not promise hard real-time deadlines.
Client libraries and interfaces: rclcpp and rclpy expose ROS concepts in C++ and Python. Generated message, service, and action types define the data exchanged between nodes.
RMW and middleware: The ROS Middleware Interface (RMW) lets ROS client libraries use different middleware implementations. DDS-based implementations are common; the chosen implementation and its configuration affect discovery, transport, and performance.
Discovery and domains: Middleware discovery lets participants find publishers, subscribers, and services without a ROS 1-style central master. Domain IDs help isolate groups of ROS 2 participants, but do not replace network segmentation or security controls.
Tools around the graph: Launch files start and configure groups of nodes. The CLI inspects the graph, while rosbag2 records and replays data for debugging and testing.

Communication occurs within a ROS graph, but the graph does not guarantee that every participant can reach every other participant. Firewalls, multicast support, domain IDs, network interfaces, middleware settings, and compatible QoS all matter, especially across subnets or wireless links.

Components and Communication Choices

Use the communication pattern that matches the work rather than putting every exchange on a topic:

Interface	Communication shape	Best suited to	Important behavior
Topic	Publish/subscribe stream	Sensor readings, state updates, and commands	Producers and consumers are loosely coupled; QoS determines delivery and history behavior.
Service	Request and response	Short operations such as reading or changing a setting	A client sends a request and receives a result; do not use it for work that needs ongoing feedback.
Action	Goal, feedback, and result	Longer tasks such as navigation or an arm motion	A client can monitor progress and request cancellation while the server works.

QoS policies let endpoints trade delivery guarantees, latency, and resource use. The profile must be compatible between a publisher and subscriber for them to communicate.

Policy	Typical choice	Trade-off
Reliability	`RELIABLE` for important state; `BEST_EFFORT` for high-rate sensor streams that can tolerate drops	Retransmission can improve delivery but may add work and latency.
History and depth	`KEEP_LAST` with a bounded depth	Bounds queued samples; too shallow a queue loses bursts, while a deep queue uses more memory and can deliver stale data.
Durability	`VOLATILE` for live streams; `TRANSIENT_LOCAL` when late joiners need a publisher’s retained samples	Retained samples are available only while the publisher providing transient-local durability remains available.
Deadline and lifespan	Set only when the application has a meaningful timing requirement	These policies help detect late or expired data; they do not make a callback meet its deadline.

Common building blocks also include parameters for runtime configuration, lifecycle nodes for managed startup and shutdown, and components that can be composed into one process. The available middleware choices and default settings depend on the ROS 2 distribution and platform; consult the distribution’s documentation before changing an RMW implementation.

Real-World Use Cases

Mobile robots: Drivers publish laser scans and odometry, localization estimates the robot pose, navigation plans a route, and controller nodes command the base. Navigation goals are a natural use for actions because they take time and need feedback.
Manipulation: A camera or depth sensor feeds perception nodes; planning components generate trajectories; controller nodes send commands to actuators. Services can handle short configuration requests while actions represent longer motions.
Industrial and research platforms: Common interfaces make it practical to replace a sensor, test a new planner, or record a repeatable experiment without rewriting every connected module.
Simulation and multi-robot prototypes: ROS 2 nodes can exchange simulated and hardware data through similar interfaces. Network discovery, clocks, QoS, and namespaces still need deliberate configuration when systems span machines or robots.

For a system that operates around people or valuable equipment, ROS 2 communication is only one layer. Independent safety mechanisms, fault handling, hardware limits, and validation remain application responsibilities.

Practical ROS 2 Setup and Development

Select a supported distribution

Choose a ROS 2 distribution that supports the operating system and architecture used by the robot, then keep that distribution consistent across development and deployment. The official distribution and platform matrix (REP 2000) lists support and lifecycle information. The Jazzy installation guide is one maintained example; follow the instructions for the exact distribution and platform rather than copying an old repository-key setup.

After configuring the official package source for a supported Ubuntu platform, a desktop installation can be installed with:

sudo apt update
sudo apt install ros-jazzy-desktop python3-colcon-common-extensions
source /opt/ros/jazzy/setup.bash

The package name and setup path above are specific to Jazzy; use the matching names in the chosen distribution’s installation instructions. Open two terminals with the environment sourced and test the built-in demo:

# Terminal 1
ros2 run demo_nodes_cpp talker

# Terminal 2
ros2 run demo_nodes_cpp listener

Create a workspace and a Python package when ready to add your own node:

mkdir -p ~/ros2_ws/src
cd ~/ros2_ws/src
ros2 pkg create --build-type ament_python --dependencies rclpy std_msgs status_publisher
cd ~/ros2_ws
colcon build --symlink-install
source install/setup.bash

The following minimal node publishes a status message with an explicit reliability policy. Save it in a package entry point or adapt it to your package’s normal executable setup:

import rclpy
from rclpy.node import Node
from rclpy.qos import QoSProfile, ReliabilityPolicy
from std_msgs.msg import String


class StatusPublisher(Node):
    def __init__(self):
        super().__init__('status_publisher')
        qos = QoSProfile(depth=10, reliability=ReliabilityPolicy.RELIABLE)
        self.publisher = self.create_publisher(String, 'robot/status', qos)
        self.timer = self.create_timer(1.0, self.publish_status)

    def publish_status(self):
        message = String()
        message.data = 'ready'
        self.publisher.publish(message)


def main():
    rclpy.init()
    node = StatusPublisher()
    try:
        rclpy.spin(node)
    finally:
        node.destroy_node()
        rclpy.shutdown()


if __name__ == '__main__':
    main()

Inspect the running graph with ros2 node list, ros2 topic list, and ros2 topic echo /robot/status. Use ros2 topic info --verbose /robot/status to examine endpoint QoS. Record representative sessions with ros2 bag before changing tuning parameters so comparisons use the same input.

For reliable deployments:

Match QoS intentionally. A reliable subscriber cannot receive from a best-effort publisher when the requested and offered policies are incompatible. Check both endpoint profiles before debugging application code.
Measure timing end to end. Record sensor-to-controller latency and callback duration. If deadlines matter, select a real-time-capable operating system and review executor behavior, memory allocation, drivers, and middleware configuration as one system.
Treat networking as part of the design. Check domain IDs, interfaces, multicast, firewall rules, and bandwidth. Wireless links can be lossy and congested; use bounded queues and test the expected network.
Secure deployments. ROS 2 has security mechanisms, but they require configuration of identities, permissions, and governance. Follow the ROS 2 security guide, limit network exposure, and test the actual deployment.
Choose middleware with evidence. Test the official RMW implementation guidance against the target hardware, message sizes, topology, and QoS needs instead of assuming one implementation is universally fastest.

Common ROS 2 Misconceptions

“ROS 2 is an operating system.” It runs on a host operating system and provides robotics middleware, libraries, and tools.
“DDS makes every deployment real-time.” DDS is a communication layer. Deterministic behavior also depends on the OS, executor, application, hardware, and a measured timing budget.
“There is no central broker, so networking is automatic.” Discovery still depends on reachable interfaces and compatible middleware, domain, and network configuration.
“Reliable QoS guarantees end-to-end success.” It affects transport delivery semantics; it cannot guarantee that a consumer processes data on time or that a physical robot executes a safe command.
“ROS 2 is secure by default.” Security features must be provisioned and enabled appropriately, and network access must still be controlled.
“ROS 1 packages run unchanged in ROS 2.” The APIs and build systems differ. Migration or a configured bridge is needed when integrating ROS 1 systems.