Skip to main content

Module 1: The Robotic Nervous System (ROS 2)

Welcome to the Robotic Nervous System​

Over the next three weeks, you'll master ROS 2 (Robot Operating System 2)—the middleware that connects every perception, planning, and control component in a robot system. Think of ROS 2 as your robot's nervous system:

  • Sensors (cameras, LiDAR, IMU) send data through ROS 2 topics—like sensory nerves
  • AI and planning modules process that data—like the brain reasoning about perception
  • Motors and actuators receive commands through ROS 2 publishers—like motor nerves controlling muscles
  • Services and actions enable request-response patterns—like reflexes and coordinated behaviors

In Module 0, you learned what Physical AI is and why embodied intelligence matters. In Module 1, you'll learn the how—the practical tools and patterns that let you build distributed, resilient robotic systems.

By the end of this module, you'll have written your first ROS 2 nodes, debugged real distributed systems, and launched multi-component robot software—skills that professionals use every day in robotics companies and research labs worldwide.

Module Structure: What You'll Learn​

This module is organized into three chapters:

Chapter 1.1: ROS 2 Architecture Overview​

What is ROS 2 and how does it work?

  • History: Why ROS 2 is a complete redesign from ROS 1
  • Core concepts: Nodes, topics, services, actions, packages
  • The DDS middleware layer and quality-of-service
  • Message types and type safety
  • Real-world comparison: ROS 1 vs. ROS 2

Time Investment: 90 minutes reading + 20 minutes self-assessment quiz

Chapter 1.2: Nodes and Topics - Pub/Sub Communication​

How do ROS 2 components communicate?

  • Building your first publisher node (sensor simulator)
  • Building your first subscriber node (data consumer)
  • Debugging with ros2 topic CLI tools
  • Choosing message types for your application
  • Best practices: Node naming, topic hierarchies, error handling

Time Investment: 120 minutes reading + 90 minutes hands-on lab

Chapter 1.3: Services and Actions - Advanced Communication​

How do ROS 2 nodes request help from each other?

  • Service-client patterns for synchronous request-response
  • Action servers and clients for asynchronous, long-running tasks
  • When to use services vs. actions vs. topics
  • Implementing fault-tolerant communication
  • Real-world robotics patterns: motion planning, navigation, gripper control

Time Investment: 120 minutes reading + 120 minutes hands-on lab

Learning Outcomes​

By the end of Module 1, you will be able to:

  1. Understand ROS 2 middleware architecture and DDS

    • Explain why ROS 2 uses Data Distribution Service instead of custom middleware
    • Describe the difference between the DDS layer and ROS 2 abstraction layer
    • Configure QoS (Quality of Service) settings for different robotics scenarios
    • Understand how ROS 2 nodes discover each other on a network

  2. Implement publishers and subscribers for robot communication

    • Write a Python ROS 2 node that publishes sensor data to topics
    • Write a Python ROS 2 node that subscribes to topics and processes incoming messages
    • Choose appropriate message types for your data (std_msgs, sensor_msgs, custom types)
    • Debug topic communication using CLI tools (ros2 topic echo, hz, bw)
    • Handle message callbacks and synchronization across multiple subscribers

  3. Create ROS 2 services for request/response patterns

    • Design and implement a service server (provider) in Python
    • Design and implement a service client (requester) in Python
    • Distinguish when services are appropriate vs. topics
    • Handle service timeouts and failure modes
    • Implement service quality-of-service for real-time constraints

  4. Develop ROS 2 actions for asynchronous task execution

    • Understand action state machines (idle → executing → succeeded/aborted)
    • Implement an action server that executes long-running tasks with progress feedback
    • Implement an action client that monitors task execution and handles cancellation
    • Compare actions to services for robot tasks (e.g., motion, navigation)
    • Integrate goal preemption (canceling one task to start another)

  5. Organize code in reusable ROS 2 packages

    • Create and structure ROS 2 packages for Python and C++ projects
    • Understand package.xml and setup.py configuration
    • Organize nodes, message definitions, and launch files
    • Build and test packages using colcon
    • Share and document your robotics code for team collaboration

Why ROS 2? Why Now?​

The Problem with Monolithic Robot Code​

Imagine building a humanoid robot without any middleware. Your code might look like:

# Bad: Tightly coupled, not reusable
while robot_running:
    sensor_data = read_camera()
    lidar_data = read_lidar()
    imu_data = read_imu()

    world_model = process(sensor_data, lidar_data, imu_data)
    path = plan_motion(world_model)
    execute_path(path)

    send_status_to_user()
    log_data()

Problems:

  • If the camera fails, the entire robot stops
  • You can't reuse "process" or "plan_motion" in other projects
  • Adding a new sensor requires rewriting the entire control loop
  • Logging and debugging are scattered throughout
  • If perception gets slow, motion planning stalls waiting for data

The ROS 2 Solution​

ROS 2 decouples these concerns into independent, message-passing components:

┌─────────────┐
│   Camera    │  (publishes camera frames)
└──────┬──────┘
       │
       ▼
┌────────────────────┐
│ World Model Node   │  (subscribes to sensors, publishes world model)
└──────┬─────────────┘
       │
       ▼
┌────────────────────┐
│  Motion Planner    │  (subscribes to world model, publishes paths)
└──────┬─────────────┘
       │
       ▼
┌────────────────────┐
│  Motor Controller  │  (subscribes to paths, sends motor commands)
└────────────────────┘

Advantages:

  • ✅ Modularity: Each component is independent and reusable
  • ✅ Resilience: One node failing doesn't crash the whole system
  • ✅ Flexibility: Add sensors or swap implementations without touching other code
  • ✅ Debugging: Log individual topics or replay recorded data
  • ✅ Team Development: Multiple developers work on different nodes simultaneously

Why ROS 2 (Not ROS 1)?​

ROS 1 (released 2007) was groundbreaking, but it had fundamental limitations:

FeatureROS 1ROS 2
MiddlewareCustom TCP/UDP implementationData Distribution Service (DDS)
Real-Time SupportLimited; not designed for itFull real-time, deterministic control loops
Production MaturityGood for researchEnterprise-grade reliability
Node IsolationSingle master node (single point of failure)Distributed discovery; no master
DDS MiddlewareNot usedIndustry-standard (Bosch, Apex, RTI, Connext)
Type SafetyRuntime errors possibleType-safe at compile time
Network TransparencyTight coupling to ROS ecosystemInteroperates with any DDS system
SecurityMinimal encryptionSROS2—production-grade encryption, authentication
Cross-LanguagePython, C++, Lisp (limited)Python, C++, Java, C# (equal support)
Industry AdoptionAcademic/hobby projectsProduction robots (Boston Dynamics, MIT, Toyota, Tesla)

Key difference: ROS 1 has a master node that all nodes register with. If the master crashes, the robot stops. ROS 2 uses DDS discovery—any node can find any other node without a central authority.

The ROS 2 Stack: Three Layers​

Understanding the layer architecture helps you debug and design systems:

┌─────────────────────────────────────┐
│  Application Layer (Your Code)      │
│  (Nodes in Python/C++/Java)         │
└────────────────┬────────────────────┘
                 │
        ┌────────▼─────────┐
        │  ROS 2 Client    │ (rclpy, rclcpp)
        │  Library         │
        └────────┬─────────┘
                 │
        ┌────────▼─────────────────────┐
        │    DDS Middleware Layer      │
        │  (Data Distribution Service) │
        │  (Fast-RTPS, Connext, etc.)  │
        └────────┬─────────────────────┘
                 │
        ┌────────▼─────────────────────┐
        │  OS Network Stack            │
        │  (UDP, TCP on Ethernet/WiFi) │
        └──────────────────────────────┘

Layer 1: Application Layer (Your Code)

  • Your Python/C++ nodes that solve robotics problems
  • You write publishers, subscribers, services, actions here

Layer 2: ROS 2 Client Libraries

  • rclpy (Python): Creates publishers, subscribers, processes messages
  • rclcpp (C++): Higher performance alternative
  • These libraries abstract away DDS complexity

Layer 3: DDS Middleware

  • Handles discovery: "Hello, I'm a node called /motor_controller"
  • Handles pub/sub: Delivers messages from publishers to subscribers
  • Handles QoS: Ensures reliable delivery when needed, drops old messages when not
  • Multiple implementations available (Fast-RTPS is default)

Why layers matter: If a message isn't being delivered, you can debug at any layer:

  • Layer 3 issue: Network problem (ping test)
  • Layer 2 issue: DDS misconfiguration (ros2 daemon logs)
  • Layer 1 issue: Your code bug (print debugging)

What You'll Build This Module​

Lab 1.1: Your First Publisher and Subscriber (Week 3)​

Scenario: You have a simulated robot with sensors. Build two nodes:

  1. Sensor Publisher: Reads simulated camera data and publishes it to /camera/image topic
  2. Data Logger: Subscribes to /camera/image, receives frames, and logs statistics

Skills Gained: Creating nodes, topics, message handling, debugging

Expected Time: 2 hours (45 min reading + 75 min coding)

Lab 1.2: Service-Based Request/Response (Week 4)​

Scenario: Your robot needs a gripper controller. Build a service:

  1. Gripper Service Server: Waits for grip position requests, controls gripper hardware
  2. Client Caller: Requests gripper actions ("open", "close", "grip at 50% force")

Skills Gained: Service design, synchronous communication, error handling

Expected Time: 2.5 hours (60 min reading + 90 min coding)

Lab 1.3: Action-Based Long-Running Tasks (Week 5)​

Scenario: Your robot needs to navigate to a goal. Build an action:

  1. Navigation Action Server: Accepts goal position, streams progress feedback
  2. Navigation Client: Sends goal, monitors progress, can cancel if blocked

Skills Gained: Asynchronous task management, feedback streams, preemption

Expected Time: 3 hours (75 min reading + 105 min coding)

Capstone Connection​

By the end of Module 1:

  • Your robot will have a communication nervous system (ROS 2)
  • Multiple independent nodes will work together autonomously
  • You'll understand how to debug distributed systems
  • You'll be ready for Module 2 (simulation) and Module 3 (perception)

All your future code—perception pipelines, path planning, LLM integration—will communicate via ROS 2 topics and services.

Prerequisites and Setup​

What You Need to Know​

  • Python 3.8+: Functions, classes, callbacks, async patterns
  • Linux/Terminal: Comfortable with cd, ls, running scripts
  • Basic Networking: Understand IP addresses, ports, packets (at conceptual level)

What You'll Learn (Don't Worry If You Don't Know)​

  • ✅ ROS 2 architecture and DDS
  • ✅ Distributed systems concepts
  • ✅ Message-passing design patterns
  • ✅ Real-time system constraints

System Requirements​

Minimum (Simulator-Only Path)

  • Ubuntu 22.04 LTS (or WSL2 on Windows, macOS with Docker)
  • 4GB RAM, 20GB disk space
  • ROS 2 Humble (free, open-source)
  • Python 3.10+

Recommended (Hardware Path)

  • Same as above, plus:
  • Jetson Orin Nano ($235) or comparable edge device
  • USB interface for robot hardware

Installation Check (you'll do this before Lab 1.1):

ros2 --version  # Should print: ROS 2 Humble
python3 --version  # Should print: Python 3.10+

See Hardware Setup Guide for detailed installation instructions.

How to Use This Module​

Reading Strategy​

Each chapter is structured for active learning:

  1. Read the Introduction (5–10 min): Understand why this concept matters
  2. Learn the Concept (20–40 min): Diagrams, analogies, real-world examples
  3. Study Code Examples (20–30 min): Read, predict outputs, then run them
  4. Do the Hands-On Lab (60–120 min): Build something with your own hands

Hands-On Labs​

  • All lab code is provided in the course GitHub repository
  • Start with the provided skeleton; fill in missing parts
  • Run the code; see it work
  • Modify and experiment—break things intentionally to learn
  • Push your code to your own GitHub repository (for portfolio)

Debugging Strategy​

When your node doesn't work:

  1. Check if the node runs: ros2 run <package> <node>
  2. Check if the topic exists: ros2 topic list
  3. Check if messages are flowing: ros2 topic echo /topic_name
  4. Check the frequency: ros2 topic hz /topic_name (should match expected rate)
  5. Check for errors: ros2 node info /node_name
  6. Check the logs: ros2 launch <launch_file> --log-level debug

Office Hours & Discussion​

  • Post questions in the course forum with tag #module-1
  • Include: Your error message, node code (relevant snippet), OS info
  • Expected response time: 24 hours on weekdays

Key Terminology (Reference)​

We'll define terms in detail as we go, but here's a quick glossary:

TermMeaning
NodeIndependent executable program that publishes/subscribes/serves
TopicNamed data stream that nodes publish to and subscribe from (one-way)
PublisherNode that sends messages to a topic
SubscriberNode that receives messages from a topic
MessageTyped data structure containing fields (e.g., sensor_msgs/Image)
ServiceSynchronous request-response pattern (client waits for answer)
ActionAsynchronous request-response with feedback and cancellation
DDSData Distribution Service—industry-standard pub/sub middleware
QoSQuality of Service—reliability, ordering, deadline settings
PackageDirectory containing nodes, messages, launch files, and docs
Launch FileYAML file that starts multiple nodes with arguments
rclpyROS 2 Python client library
GraphVisualization of nodes and topics; shows data flow

Common Challenges (We'll Address These)​

Challenge 1: "My node runs but nothing is published"​

Root causes: Node fails silently, topic name mismatch, message type error Solution: Use ros2 topic list and ros2 node info to debug

Challenge 2: "My subscriber never receives messages"​

Root causes: Publisher publishes before subscriber subscribes, QoS mismatch Solution: Start subscriber first; use transient-local QoS for late joiners

Challenge 3: "Services are slow; my robot can't react in time"​

Root causes: Service processing takes too long, network latency Solution: Use actions instead; implement predictive control

Challenge 4: "My code works on Linux but crashes on macOS/Windows"​

Root causes: Path differences, ROS 2 package availability Solution: Stick with Ubuntu 22.04 for consistency; use Docker if needed

Learning Path: Choose Your Adventure​

  • Run ROS 2 on your laptop in Docker or native Ubuntu
  • Simulate sensor data with Python publishers
  • Subscribe and process data
  • No hardware required
  • Best for: Learning fundamentals, rapid iteration
  • Time: Full 3 weeks

Path B: Simulation + Real Sensors (Advanced)​

  • ROS 2 on Jetson Orin Nano
  • Connect real camera, microphone, IMU
  • Publish real sensor data to same ROS 2 graph
  • Test algorithms on actual hardware
  • Best for: Portfolio building, understanding sim-to-real gap
  • Time: Full 3 weeks + hardware setup (1 week)

Path C: Skip to Advanced (If You Know ROS 1)​

  • Fast-track through chapters 1.1–1.2
  • Jump directly to actions and launch files (1.3)
  • Spend saved time on Lab 1.3 and experimentation
  • Best for: ROS 1 veterans learning ROS 2 differences
  • Time: 1.5–2 weeks

What's Next?​

You're about to enter the distributed systems world. Let's start by understanding how ROS 2 is architected and why it works the way it does.

Ready? Continue to Chapter 1.1: ROS 2 Architecture Overview.

Module Begins: Week 3 Module Ends: Week 5 (end of chapter 1.3 + all labs) Estimated Total Time: 18–24 hours (reading + hands-on labs) Capstone Relevance: ROS 2 is the backbone of your voice-controlled humanoid; every future module depends on Module 1 mastery

Last Updated: December 2025 Course Version: 1.0 ROS 2 Version: Humble (LTS)

Textbook Assistant

Ask me anything about the textbook...