Chapter 1: Introduction to ROS 2

Welcome to your first chapter in the Robot Operating System 2 (ROS 2)! If you're coming from an AI/ML background, you might be familiar with frameworks like PyTorch or TensorFlow that help you build neural networks. ROS 2 serves a similar purpose for robotics—it's a middleware framework that helps you build distributed robotic systems.

1.1 Why ROS 2? The Evolution from ROS 1

If you research robotics online, you'll encounter both ROS 1 and ROS 2. Understanding why ROS 2 exists will help you appreciate its design decisions.

The ROS 1 Architecture Problem

ROS 1 (released in 2007) relied on a master node architecture:

graph TD
    M[ROS Master] --> N1[Camera Node]
    M --> N2[Perception Node]
    M --> N3[Control Node]
    M --> N4[Motor Node]

    style M fill:#dc3545,stroke:#721c24,color:#fff

Single Point of Failure: If the ROS Master crashes, the entire robotic system stops communicating. This is unacceptable for production robots, especially humanoids operating in unstructured environments.

The ROS 2 Distributed Architecture

ROS 2 eliminated the master node by adopting DDS (Data Distribution Service), a proven middleware standard used in aerospace, defense, and industrial systems.

graph LR
    N1[Camera Node] <--> DDS[DDS Middleware Layer]
    N2[Perception Node] <--> DDS
    N3[Control Node] <--> DDS
    N4[Motor Node] <--> DDS

    style DDS fill:#00aeef,stroke:#005f7f,color:#fff

Key Improvements:

No single point of failure: Nodes discover each other peer-to-peer
Real-time performance: Deterministic communication with configurable QoS
Security: Built-in authentication and encryption (SROS2)
Multi-robot support: Nodes can communicate across networks seamlessly

1.2 Core Concepts: The Computational Graph

ROS 2 represents your robot as a computational graph where:

Nodes are processes that perform computation (vertices in the graph)
Communication channels connect nodes (edges in the graph)

1.2.1 Nodes

Design Philosophy: ROS 2 encourages many small nodes rather than one monolithic program. This provides:

Modularity: Replace or upgrade individual components
Fault isolation: One crashing node doesn't bring down the entire system
Parallel execution: Nodes run on separate CPU cores automatically
Testability: Test individual nodes in isolation

Example Humanoid Robot System:

graph LR
    IMU[IMU Driver] --> FUSION[Sensor Fusion]
    CAM[Camera Driver] --> PERC[Perception]
    PERC --> PLAN[Motion Planner]
    FUSION --> CTRL[Balance Controller]
    PLAN --> CTRL
    CTRL --> MOTOR[Motor Interface]

Each box represents a separate node. This 6-node system is easier to develop, test, and debug than a single 10,000-line program.

Publish-Subscribe Pattern:

sequenceDiagram
    participant Pub as Publisher<br/>(Camera Node)
    participant Topic as /camera/image
    participant Sub1 as Subscriber 1<br/>(Object Detector)
    participant Sub2 as Subscriber 2<br/>(Image Logger)

    Pub->>Topic: publish(Image msg)
    Topic->>Sub1: callback(Image msg)
    Topic->>Sub2: callback(Image msg)
    Note over Pub,Sub2: Asynchronous, non-blocking

When to Use Topics:

✅ Sensor data (camera images, IMU readings, joint states)
✅ Robot state (pose, velocity, battery level)
✅ Command streams (motor velocities, LED colors)
❌ Request-response patterns (use services instead)
❌ Guaranteed delivery requirements (configure QoS)

1.2.3 Services: Request-Response Communication

Service Call Pattern:

sequenceDiagram
    participant Client as Service Client<br/>(Planning Node)
    participant Server as Service Server<br/>(Inverse Kinematics)

    Client->>Server: Request(target_pose)
    Note over Server: Compute joint angles
    Server->>Client: Response(joint_positions)
    Note over Client: Blocks until response

When to Use Services:

✅ Compute intensive operations (inverse kinematics, path planning)
✅ Configuration queries (get/set parameters)
✅ Trigger actions (start/stop motors, reset odometry)
❌ High-frequency data (use topics instead)
❌ Long-running tasks (use actions instead)

1.2.4 Actions: Goal-Oriented Behavior

Action Communication Pattern:

sequenceDiagram
    participant Client as Action Client<br/>(Behavior Node)
    participant Server as Action Server<br/>(Navigation)

    Client->>Server: Goal(target_waypoint)
    Server->>Client: Feedback(distance_remaining: 5.2m)
    Server->>Client: Feedback(distance_remaining: 3.8m)
    Server->>Client: Feedback(distance_remaining: 1.1m)
    Server->>Client: Result(SUCCESS, final_pose)

When to Use Actions:

✅ Navigation to waypoints
✅ Object manipulation sequences
✅ Autonomous behaviors (dance, wave, grasp)
✅ Long computations with progress tracking
❌ Simple on/off commands (use services)
❌ Continuous data streams (use topics)

1.3 ROS 2 Distributions

ROS 2 releases new distributions every 6-12 months, named alphabetically after turtles.

Distribution	Release	EOL	Ubuntu	Python	LTS
Humble Hawksbill	May 2022	May 2027	22.04	3.10+	✅
Iron Irwini	May 2023	Nov 2024	22.04	3.10+	❌
Jazzy Jalisco	May 2024	May 2029	24.04	3.12+	✅

1.4 Setting Up Your ROS 2 Environment

Before diving into code, ensure ROS 2 Humble is installed correctly.

Installation Verification

Open a terminal and run:

# Source ROS 2 environment
source /opt/ros/humble/setup.bash

# Verify installation
ros2 --version

# Expected output:
# ros2 cli version: 0.25.x

# List available commands
ros2 --help

You must source the ROS 2 setup script in every new terminal:

source /opt/ros/humble/setup.bash

Pro tip: Add this line to your ~/.bashrc to automatically source ROS 2 in all terminals:

echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc

Your First ROS 2 Command: Viewing the Computational Graph

Let's explore a live ROS 2 system using the turtlesim demo:

# Terminal 1: Start the turtlesim node
ros2 run turtlesim turtlesim_node

# Terminal 2: Start the keyboard teleop node
ros2 run turtlesim turtle_teleop_key

# Terminal 3: View active nodes
ros2 node list

# Expected output:
# /turtlesim
# /teleop_turtle

# Terminal 3: View active topics
ros2 topic list

# Expected output:
# /turtle1/cmd_vel
# /turtle1/color_sensor
# /turtle1/pose

You just created a 2-node computational graph! The turtle_teleop_key node publishes to /turtle1/cmd_vel, and turtlesim subscribes to it.

Visualizing the Computational Graph

ROS 2 includes rqt_graph, a tool to visualize node connections:

# Terminal 4: Launch rqt_graph
ros2 run rqt_graph rqt_graph

You'll see:

Nodes: Ovals representing processes
Topics: Rectangles representing message buses
Edges: Arrows showing publish/subscribe relationships

1.5 Hands-On Exercise: Exploring a ROS 2 System

Learning Objectives

Launch multiple ROS 2 nodes using ros2 runInspect active topics and their message typesEcho topic data in real-time to understand data flow

Progress: 0% (0 / 3)

Problem Statement

You are analyzing an existing ROS 2 system (turtlesim) to understand how nodes communicate. Your task is to identify:

What message type is used for controlling the turtle's velocity?
What data does the /turtle1/pose topic publish?
How many subscribers are listening to /turtle1/cmd_vel?

Requirements

Launch the turtlesim system (2 nodes: turtlesim_node and turtle_teleop_key)
Inspect topic details using ros2 topic info
View message structure using ros2 interface show
Echo topic data using ros2 topic echo /turtle1/pose (move the turtle and observe output)

Testing

# Verify turtlesim is running
ros2 node list
# Should show: /turtlesim and /teleop_turtle

# Inspect the velocity command topic
ros2 topic info /turtle1/cmd_vel
# Expected: Message type geometry_msgs/msg/Twist

# View message fields
ros2 interface show geometry_msgs/msg/Twist

# Echo pose data (press arrow keys in teleop terminal)
ros2 topic echo /turtle1/pose

Deliverable

Answer these questions:

What are the two main fields in a Twist message? (Hint: linear and angular velocities)
At what frequency (Hz) does /turtle1/pose publish data? (Use ros2 topic hz /turtle1/pose)
What happens when you kill the turtle_teleop_key node? (Does turtlesim still receive commands?)

Key Takeaways

✓ Core Concepts Mastered

ROS 2 uses a distributed, peer-to-peer architecture (no master node) powered by DDS middleware for fault tolerance and scalability
Nodes are independent processes with single responsibilities, allowing modular, testable robotic systems
Topics provide asynchronous publish-subscribe communication for continuous data streams (sensors, state, commands)
Services provide synchronous request-response communication for infrequent, atomic operations (queries, triggers)
Actions extend services with feedback and cancellation for long-running, goal-oriented tasks (navigation, manipulation)
ROS 2 Humble Hawksbill LTS is the recommended distribution for production systems (Ubuntu 22.04, supported until 2027)

What's Next?

In Chapter 2: ROS 2 Nodes and Topics, you'll write your first Python code using rclpy to create publishers and subscribers. You'll learn:

How to create custom ROS 2 packages
Writing publisher nodes that send sensor data
Writing subscriber nodes that process incoming messages
Configuring Quality of Service (QoS) for reliable communication

Prerequisite Check: Before proceeding, ensure you can:

✅ Explain the difference between ROS 1 and ROS 2 architectures
✅ Define nodes, topics, services, and actions
✅ Run ros2 node list and ros2 topic list successfully
✅ Visualize a computational graph using rqt_graph

Next: Chapter 2: ROS 2 Nodes and Topics (coming soon)

1.1 Why ROS 2? The Evolution from ROS 1​

The ROS 1 Architecture Problem​

The ROS 2 Distributed Architecture​

1.2 Core Concepts: The Computational Graph​

1.2.1 Nodes​

1.2.2 Topics: Publish-Subscribe Communication​

1.2.3 Services: Request-Response Communication​

1.2.4 Actions: Goal-Oriented Behavior​

1.3 ROS 2 Distributions​

1.4 Setting Up Your ROS 2 Environment​

Installation Verification​

Your First ROS 2 Command: Viewing the Computational Graph​

Visualizing the Computational Graph​

1.5 Hands-On Exercise: Exploring a ROS 2 System​

Explore the Turtlesim Computational Graph