ROS 2: Robot Operating System

2019. Amazon Scout - the first autonomous delivery robot rolling down the sidewalks of Snohomish County, Washington. 20+ programs running side-by-side: 6 cameras, LIDAR, IMU, GPS, obstacle detection, routing, motors, battery. Data flying around 100 times a second, no failures. The substrate underneath: ROS 2, the de facto standard for robotics software since 2020.

• **NASA**: the Mars rover uses ROS 2 to coordinate cameras, the drill, and the manipulator - each subsystem runs as a separate node communicating via topics
• **Autoware**: the open autonomous driving stack on ROS 2 - dozens of nodes for perception, planning, and control, connected via topics, services, and actions
• **Amazon Robotics**: thousands of Kiva warehouse robots are managed via ROS 2, coordinating navigation through actions and sharing maps via topics

From Willow Garage to Open Robotics

ROS was created in 2007 at Willow Garage - a startup funded by Google co-founder Scott Hassan. The first robot running ROS - PR2 - could fold towels and open refrigerator doors. ROS 1 used a central roscore and had no real-time support. ROS 2, developed by Open Robotics from 2014, rethought the architecture: DDS instead of roscore, managed node lifecycle, native multi-robot support. By 2025 ROS 2 is used by NASA, Boston Dynamics, and Amazon Robotics.

Предварительные знания

• Kinematics: Forward and Inverse

Nodes - computational processes

Amazon Scout, the delivery robot, 2019. Six cameras, LIDAR, IMU, GPS, obstacle detector, route planner, motor controller - all running at once. Cram it all into one 200,000-line monolith? A maintenance horror story. **ROS 2** (Robot Operating System 2) solves the mess through a **node** architecture: independent processes, each owning exactly one job.

**Node** - the smallest unit of computation in ROS 2. Each node is a separate process (or thread) doing one job: reading a camera, driving a motor, planning a path. Nodes talk to each other through three mechanisms: topics, services, and actions.

The headline change from ROS 1: **ROS 2** killed the central server (roscore). Nodes find each other through **DDS** (Data Distribution Service), an industrial middleware standard with automatic discovery built in. One node crashes, the rest keep humming. No roscore, no single point of failure.

Topics - asynchronous messages

Camera at 30 frames/s. LIDAR at 10 point clouds/s. IMU at 200 measurements/s. Three streams, three different consumers. How to deliver all of it without blocking and without welding the source to the receiver? **Topics** in ROS 2 are named pub/sub channels. The publisher has no idea who is subscribed. Fire-and-forget.

**Topic** - a named channel carrying messages of a specific type. A **publisher** node pushes data into a topic; one or more **subscriber** nodes pull it out. The publisher never learns who is listening (if anyone). Total decoupling.

In ROS 2 every message on a topic carries a strict **type** described in IDL (Interface Definition Language). Standard types ship in packages: `std_msgs`, `sensor_msgs`, `geometry_msgs`, `nav_msgs`. Custom types come from `.msg` files.

**QoS (Quality of Service)** is the make-or-break setting in ROS 2. For a camera `BEST_EFFORT` is fine (a dropped frame is no big deal); for control commands use `RELIABLE` (every command has to land). Mismatched QoS between publisher and subscriber - they go silent and never see each other.

Services - synchronous request-response

Topics handle streams. But sometimes a node needs to **ask another node to do one specific thing and wait for the answer**. Flip the camera to night mode. Request the current map. Save configuration. ROS 2 covers that with **services** - a synchronous request/response mechanism.

**Service** - a named 'request-response' channel. The client fires a Request and **blocks** until the Response comes back. The server handles the request and returns the result. Unlike a topic, a service is point-to-point: one server, one or more clients.

Services **block** the calling node until a response lands. If the server hangs or dies, the client hangs with it. For long-running operations (navigation, scanning) reach for **actions**, not services. Rule of thumb: a service should finish **fast** - milliseconds, seconds at the absolute outside.

Actions - long tasks with feedback

'Go to point (3.5, 7.2)' - that's 30 seconds of driving. A service is wrong here: the client hangs for half a minute. A topic is wrong too: a definite result is needed. ROS 2 ships **actions** for exactly this case - a hybrid of service and topic with three channels: goal, feedback, and result.

**Action** - a mechanism for long tasks with three phases: 1. **Goal** - client sends the goal, server accepts or rejects it 2. **Feedback** - server periodically reports progress (distance to goal, % completion) 3. **Result** - server returns the final result (success/failure + data)

The killer feature of actions is **cancellation**. The robot is mid-trip and a new goal arrives (or danger appears) - the client kills the current action via `cancel_goal()`. The server gets the notification and stops cleanly. No panic, no leaked resources.

Under the hood an action is wired from **3 hidden topics and 2 services**: a topic for feedback, a topic for goal status, a service for sending the goal, a service for cancellation. ROS 2 hides all that wiring behind a clean ActionServer/ActionClient API.

Key ideas

• **Node** - the minimum computational unit of ROS 2. One process = one task. Nodes discover each other via DDS without a central server.
• **Topic** - an asynchronous pub/sub channel for streaming data (camera, LIDAR, odometry). One publisher, multiple subscribers. Fire-and-forget.
• **Service** - synchronous request/response for quick one-shot requests (switch mode, request configuration). Blocks the client.
• **Action** - a mechanism for long tasks with feedback and cancellation (navigation, scanning). Combines topics and services under the hood.

Related topics

ROS 2 combines many concepts from software engineering and robotics:

• Kinematics — The MoveIt library in ROS 2 implements FK/IK and motion planning for manipulators via actions
• Parallel Computing — ROS 2 nodes are parallel processes, and DDS uses inter-process communication mechanisms
• Real-Time Systems — ROS 2 supports real-time via DDS QoS, executor priorities, and managed nodes

Вопросы для размышления

• Back to the Amazon Scout delivery robot: which data would be transmitted via topics, which operations via services, and which via actions? Try to distribute all 20+ components.
• Why did ROS 2 abandon the central server (roscore from ROS 1)? What problems does this solve for robots working in a group?
• Designing a control system for a delivery drone - what nodes would be created and how would they be connected via topics, services, and actions?

Связанные уроки

• rob-02 — Manipulator kinematics is implemented via MoveIt actions in ROS 2
• rob-04 — SLAM and Nav2 navigation are built on top of ROS 2 topics/actions
• par-01 — ROS 2 nodes are parallel processes with DDS as the IPC mechanism
• rts-01 — ROS 2 supports real-time via DDS QoS and executor priorities
• ds-01 — Pub/sub in ROS 2 mirrors distributed messaging in microservices
• emb-03 — Physical layer: I2C/SPI sensors feed data into ROS 2 topics
• os-13-ipc