Robot Operating Systems: ROS 2 Architecture Explained from Hardware to Applications

The Limitations of ROS 1

Created in 2007 at Willow Garage, ROS 1 revolutionized academic robotics research. However, it had architectural limitations that prevented deployment in commercial, mission-critical robots:

1. 1
   Centralized Master (roscore): A single master process held the address book of all nodes. If roscore crashed or experienced network dropouts, the entire robot halted.
2. 2
   No Real-Time Determinism: The Linux TCP/IP transport had unpredictable scheduling jitter, making it unsuitable for direct brushless motor control loops.
3. 3
   Weak Wireless Networking: Wi-Fi dropouts caused master disconnects and broken socket states.
4. 4
   No Native Multi-Robot Support: Deploying a fleet of 50 warehouse robots required complex network tunneling hacks.

The ROS 2 DDS Revolution

ROS 2 replaces the proprietary network layer with DDS (Data Distribution Service)—an international military- and aerospace-grade standard (OMG DDS) used in air traffic control, nuclear reactors, and warships.

DDS introduces:

• Brokerless Peer-to-Peer Discovery: Nodes broadcast UDP multicasts to discover each other dynamically. There is zero master node.
• Configurable Quality of Service (QoS): Developers can configure packet delivery behavior per-topic (e.g., allow dropping old sensor frames vs guarantee delivery of emergency stop commands).
• Security (SROS 2): Native TLS authentication, access control policies, and hardware-accelerated encryption.

A production-ready ROS 2 robot organizes software into a modular 7-tier pipeline:

1. 1
   Hardware Tier: Physical brushless actuators, encoders, IMUs, 2D/3D LiDARs, depth cameras, and battery systems.
2. 2
   Micro-ROS & Embedded Tier: Microcontrollers (ESP32, STM32) running FreeRTOS with micro-ROS clients, executing hard real-time PID loops and publishing raw tick counts.
3. 3
   Hardware Driver Nodes: Linux processes communicating over USB/Ethernet/CAN (e.g., sllidar_ros2, realsense2_camera) converting hardware bytes into standardized ROS 2 messages.
4. 4
   Coordinate Transformation (TF2): Real-time spatial tracking of all robot links and sensor mounting positions.
5. 5
   Localization & Mapping (SLAM): Sensor fusion nodes (robot_localization, slam_toolbox) creating global maps and computing robot pose.
6. 6
   Motion Planning & Navigation (Nav2 / MoveIt 2): High-level path generation, dynamic obstacle avoidance, and trajectory tracking.
7. 7
   Application Logic & Behavior Trees: Mission controllers (e.g., "drive to Table 4, pick up pallet, return to charging station").

Nodes

A Node is a single, focused process responsible for one discrete task (e.g., one node reads the camera, another detects faces, another drives the motors). Dividing software into hundreds of small nodes ensures that if a camera driver crashes, the safety stop and motor nodes remain fully alive.

Managed Lifecycle Nodes

In safety-critical robots, you cannot allow a motor controller to start spinning wheels while the LiDAR node is still booting up. ROS 2 provides Lifecycle Nodes with explicit finite state machines:

• Unconfigured: The node is instantiated but has not allocated memory or claimed hardware.
• Inactive: Configuration parameters are loaded, memory buffers are pre-allocated, but callbacks are paused.
• Active: Full execution mode, publishing and processing data.
• Finalized: Cleanly shut down with all hardware safely depowered.

ROS 2 provides three distinct communication patterns for nodes:

1. Topics (Publish-Subscribe)

• Pattern: Asynchronous, many-to-many, non-blocking data streaming.
• Analogy: Radio broadcasting. The publisher broadcasts data regardless of whether anyone is listening.
• Use Case: High-rate sensor telemetry (e.g., /scan for 30Hz LiDAR scans, /odom for 100Hz odometry, /cmd_vel for wheel speed commands).

2. Services (Request-Response)

• Pattern: Synchronous, one-to-one, blocking or callback-based transaction.
• Analogy: Making a telephone call. The client sends a question and waits for the server to reply.
• Use Case: Quick, momentary operations (e.g., /reset_trip_distance, /calibrate_gyro, /set_camera_exposure).

3. Actions (Goal - Feedback - Result)

• Pattern: Asynchronous, client-server, long-running, preemptible goal execution.
• Analogy: Ordering a taxi. You submit a goal destination; the taxi driver continuously reports progress (distance remaining, ETA); you can cancel the ride midway; upon arrival, you receive a final completion receipt.
• Use Case: Multi-second or multi-minute operations (e.g., /navigate_to_pose, /execute_trajectory, /dock_to_charger).

In ROS 1, all communication defaulted to reliable TCP. In wireless robotics, if a single 30 FPS camera packet is lost, TCP pauses the entire stream to retransmit the lost packet, resulting in buffering lag. By the time the video recovers, the frames are 2 seconds old—causing the robot to drive off a cliff.

ROS 2 solves this by introducing QoS Profiles:

• Reliability:
• *Best Effort:* Drops packets if network is congested. (Essential for high-rate sensor streams like LiDAR and video).
• *Reliable:* Guarantees packet arrival with retransmissions. (Mandatory for motor commands and safety stops).
• Durability:
• *Volatile:* Only nodes currently online receive messages.
• *Transient Local:* The publisher retains the latest message in memory and automatically delivers it to any new subscriber that comes online 10 minutes later (ideal for static maps on /map).
• History & Depth:
• *Keep Last (Depth N):* Retains only the $N$ most recent samples in memory.

A robot has many physical parts: wheels, chassis, a mast, and sensors. When a LiDAR mounted on top of a 50cm mast detects an obstacle 2 meters ahead, how does the chassis navigation planner know where that obstacle is relative to its wheels?

TF2 (Transform Library) solves this by maintaining a directed acyclic tree of coordinate frames:

• map: Global fixed world frame. Has long-term drift correction from SLAM. (Discontinuous jumps during loop closure).
• odom: Continuous, smooth world-fixed frame derived from wheel encoders and IMU. Never jumps, but slowly drifts over distance.
• base_link: Rigidly attached to the center of rotation of the robot chassis.
• laser_frame / camera_link: Attached to sensor mounting points.

TF2 automatically interpolates between coordinate frames across time, allowing any node to ask: *"Where was the laser beam relative to the global map 80 milliseconds ago?"*

ros2_control: The Hardware Bridge

Writing custom motor driver code for every robot creates massive technical debt. ros2_control standardizes actuation:

• Hardware Interface: A C++ plugin that talks to your specific motor driver (via CAN, UART, or SPI). It exposes standardized Command Interfaces (e.g., target velocity, target torque) and State Interfaces (actual position, actual velocity).
• Controllers: Ready-to-use real-time controller plugins (e.g., diff_drive_controller, joint_trajectory_controller) that read /cmd_vel and command hardware interfaces without knowing the underlying motor chip.

Nav2: The Autonomous Navigation System

Nav2 is the state-of-the-art navigation stack for mobile robots. It includes:

• Global Planner: Finds the optimal collision-free path from current pose to goal on a static map (A* or Dijkstra).
• Costmaps (Global & Local): 2D occupancy grids that inflate obstacles based on the robot's physical footprint.
• Controller (Local Planner): Generates smooth /cmd_vel commands that track the global path while dynamically steering around moving obstacles (DWB, TEB Local Planner, MPPI).
• Behavior Trees: Orchestrates complex navigation sequences with automated recovery actions (spinning in place to clear sensor costmaps, reversing out of dead-ends).