Skip to main content

Chapter 2: ROS 2 Architecture

Chapter Info

Module: The Robotic Nervous System | Duration: 3 hours | Difficulty: Beginner

Learning Objectives​

After completing this chapter, you'll be able to:

  1. Explain ROS 2's fundamental architectural elements: nodes, topics, services, and actions.
  2. Utilize essential ROS 2 command-line utilities for system inspection and troubleshooting.
  3. Understand the publish-subscribe pattern and its role in distributed robotics.
  4. Launch and coordinate multiple ROS 2 nodes effectively.

Prerequisites​

  • Completion of Chapter 1: Introduction to Physical AI, with a functional ROS 2 development workspace.
  • Basic terminal command proficiency.

What You'll Build​

This chapter guides you through creating a simple ROS 2 system with communicating nodes, including:

  • A fundamental ROS 2 publisher node.
  • A corresponding ROS 2 subscriber node.
  • A ROS 2 launch file for node orchestration.

Introduction: Coordinating Robotic Intelligence​

Human bodies rely on nervous systems to coordinate movements, process sensations, and enable cognition. Similarly, sophisticated robots require robust architectures to manage their diverse components. Enter the Robot Operating System 2 (ROS 2)—not an operating system in the conventional sense, but rather a comprehensive framework for developing robot software. ROS 2 provides tools, libraries, and conventions that streamline the creation of complex, reliable robotic applications.

Developed to overcome ROS 1's limitations, ROS 2 introduces substantial improvements in real-time communication, multi-robot coordination, and security—making it suitable for broader industrial and research applications. It abstracts low-level communication and hardware interfacing, enabling roboticists to concentrate on high-level behavioral logic.

Picture a humanoid robot: it possesses cameras for vision, motors for locomotion, an IMU for balance, and numerous other sensors. Each component needs to communicate, exchange data, and receive commands. ROS 2 provides the infrastructure for this inter-component communication, transforming disparate hardware and software modules into a cohesive, intelligent system.

This chapter dissects ROS 2's core architectural principles. We'll examine how individual software modules called nodes communicate using topics, services, and actions. You'll gain hands-on experience with fundamental ROS 2 command-line tools for inspecting, debugging, and understanding information flow within running systems. By chapter's end, you'll possess a clear mental model of how ROS 2 functions as the "nervous system" coordinating intelligent robotic behaviors.

Core Concepts: ROS 2 Fundamental Components​

ROS 2's architecture centers on a distributed communication graph where independent processes (nodes) exchange information. This modularity represents a key strength, allowing different software components to be developed, tested, and executed independently.

1. Nodes: Computational Building Blocks​

A Node represents an executable process performing specific computations. In typical robot systems, you might encounter:

  • A node controlling motor operations.
  • A node reading LiDAR sensor data.
  • A node processing camera images for object detection.
  • A node planning robot trajectories.

Each ROS 2 node is designed to be compact, modular, and focused on a specific task. This approach promotes code reusability and simplifies debugging by isolating issues to individual nodes. Nodes communicate to achieve complex behaviors.

2. Topics: Asynchronous Data Streams​

Topics represent the primary mechanism for nodes to exchange real-time data asynchronously. This employs a publish-subscribe (pub/sub) communication pattern:

  • A node generating data (e.g., a camera node producing image frames) publishes messages to a named topic.
  • One or more nodes consuming this data (e.g., an object detection node or visualization node) subscribe to that topic.

Topic characteristics:

  • Asynchronous Operation: Publishers don't wait for subscriber acknowledgment.
  • One-to-Many Communication: Single publishers can have multiple subscribers; multiple publishers can publish to the same topic (though less common for data streams).
  • Message Types: Each topic uses a predefined message type (e.g., sensor_msgs/msg/Image for camera data, std_msgs/msg/String for text). Message types define data structure.
  • Middleware Foundation: ROS 2 utilizes Data Distribution Service (DDS) as its communication middleware, enabling efficient, real-time, secure communication across platforms.

3. Services: Synchronous Request-Response​

Services facilitate synchronous, request-response communication between nodes. When a client node requires specific computation or action from a server node, it sends a request and awaits a response.

  • Client: The requesting node.
  • Server: The node providing the service and returning a response.

Services are ideal for:

  • Triggering actions (e.g., "Capture an image").
  • Querying information (e.g., "What's the robot's current position?").
  • Executing one-time calculations.

Unlike topics, services typically involve one-to-one communication. Each service has a defined service type specifying both request and response message structures.

4. Actions: Long-Duration Asynchronous Operations​

Actions are designed for long-running tasks providing periodic feedback and supporting preemption (cancellation). They combine aspects of topics and services:

  • Goal: The request initiating a long-running task (similar to service requests).
  • Feedback: Periodic progress updates (similar to topics).
  • Result: The final task outcome (similar to service responses).

Actions excel for tasks like:

  • Navigating a robot to a target location.
  • Executing complex manipulation sequences (pick-and-place operations).
  • Performing environmental scans.

A node acts as an Action Client to send goals and receive feedback/results, while another node acts as an Action Server to process goals, provide feedback, and deliver final results.

5. Parameters: Runtime Configuration​

Parameters are dynamic configuration values that nodes expose. They enable behavior modification without code recompilation.

  • Dynamic Nature: Parameters can be read and modified at runtime.
  • Centralized Management: The ROS 2 parameter server allows other nodes and command-line tools to interact with node parameters.

Parameters are useful for:

  • Setting robot maximum speed.
  • Configuring sensor thresholds.
  • Switching between algorithms within a node.

ROS 2 Graph and Lifecycle Management​

These components (nodes, topics, services, actions, parameters) form the ROS 2 graph, representing active communication and computation in the system.

ROS 2 also introduces Lifecycle Nodes, providing standardized state transition management (unconfigured, inactive, active, finalized). This is particularly important for robust, fault-tolerant systems, especially in industrial applications where predictability and safety are paramount.

Hands-On Tutorial: Exploring the ROS 2 Ecosystem​

In Chapter 1, you established your ROS 2 development environment. Now, let's use fundamental ROS 2 command-line tools to explore an existing system. We'll use the hello_physical_ai package you created previously, consisting of a publisher (talker) and subscriber (listener).

First, ensure your ROS 2 environment is sourced. If you've closed your terminal, re-source:

source /opt/ros/humble/setup.bash
source ~/ros2_ws/install/setup.bash # Assuming workspace is ~/ros2_ws

Step 1: Launch the hello_physical_ai Example​

Use the launch file to start both publisher and subscriber nodes. Open a terminal and execute:

ros2 launch hello_physical_ai talker_listener.launch.py

You should observe output indicating sim_talker is publishing messages and sim_listener is receiving them.

Step 2: Inspecting Active Nodes​

With talker_listener running, open a new terminal and ensure your ROS 2 environment is sourced.

List all active ROS 2 nodes:

ros2 node list

Expected output includes:

/sim_listener
/sim_talker

These are the node names defined in our launch file.

Retrieve detailed information about a specific node:

ros2 node info /sim_talker

This displays which topics it publishes/subscribes to, services it provides/uses, and its parameters.

Step 3: Inspecting Active Topics​

List all active topics in the ROS 2 graph:

ros2 topic list

You should see /topic, /parameter_events, and /rosout.

  • /topic: Our custom topic where sim_talker publishes messages.
  • /parameter_events: System topic for parameter change notifications.
  • /rosout: System topic for logging messages.

Retrieve detailed topic information, including type and connected nodes:

ros2 topic info /topic

Expected output:

Type: std_msgs/msg/String
Publishers:
    /sim_talker
Subscribers:
    /sim_listener

This confirms sim_talker publishes std_msgs/msg/String messages to /topic, and sim_listener subscribes to it.

View messages being published on a topic in real-time:

ros2 topic echo /topic

You should see "Hello ROS 2 World" messages printed as they're published.

Step 4: Inspecting Available Services​

While our hello_physical_ai example doesn't explicitly use services, system nodes provide them. List all active services:

ros2 service list

You'll see numerous services, mostly related to parameter management and node lifecycle. Retrieve information about a specific service:

ros2 service info /sim_talker/set_parameters

This displays the service type and which node provides it.

Step 5: Inspecting Node Parameters​

List all parameters available on a specific node (e.g., sim_talker):

ros2 param list /sim_talker

You'll see parameters like use_sim_time.

Retrieve or modify a parameter:

ros2 param get /sim_talker use_sim_time
ros2 param set /sim_talker use_sim_time true

(Note: Setting use_sim_time to true is often necessary when running nodes in simulation environments like Gazebo, covered in later modules.)

Step 6: Shutting Down​

To stop the launch file and all its nodes, press Ctrl+C in the terminal where you executed ros2 launch.

Deep Dive: ROS 2 vs. ROS 1 Evolution​

ROS 2 was developed to address several critical limitations of ROS 1, making it more suitable for modern robotics challenges, particularly in industrial and safety-critical applications.

Key ROS 2 improvements:

  1. DDS (Data Distribution Service) Integration: ROS 2 employs DDS as its communication middleware, replacing ROS 1's custom TCP/IP-based ros_comm. DDS is an open international standard for real-time systems, providing:

    • Quality of Service (QoS) Policies: Fine-grained control over communication reliability, durability, and latency—essential for critical systems.
    • Decentralized Architecture: Eliminates single points of failure (like ROS 1's roscore).
    • Real-time Communication: Enhanced support for deterministic communication.
    • Security: Built-in authentication, authorization, and encryption mechanisms.

  2. Multi-Robot Systems: Designed from inception to support multiple robots communicating in shared environments and seamlessly handle communication across network segments.

  3. Cross-Platform Support: ROS 1 was primarily Linux-centric. ROS 2 expands support to Windows, macOS, and various real-time operating systems (RTOS), broadening applicability.

  4. Lifecycle Management: Introduction of standard lifecycle states for nodes (unconfigured, inactive, active), enabling more robust and predictable system startup and shutdown.

  5. Enhanced Build System: ament build system (used with colcon) provides superior cross-platform support and modularity compared to ROS 1's catkin.

  6. Improved Parameter System: Enhanced parameter management with cleaner API and dynamic parameter updates.

  7. Advanced Actions: More sophisticated API for long-running, goal-oriented tasks with feedback and preemption capabilities, improving upon ROS 1's simple actions.

These advancements make ROS 2 a more powerful, flexible, and robust framework for developing next-generation intelligent robotic systems.

Troubleshooting: Common ROS 2 Architecture Issues​

  1. Issue: ros2: command not found
    • Cause: ROS 2 environment not sourced.
    • Solution: Execute source /opt/ros/humble/setup.bash and source ~/ros2_ws/install/setup.bash (if applicable) in each new terminal. Add these to ~/.bashrc for persistence.
  2. Issue: Nodes cannot discover topics or each other.
    • Cause: ROS 2 ROS_DOMAIN_ID mismatch or network connectivity issues.
    • Solution: Ensure export ROS_DOMAIN_ID=<ID> is set to the same value in all terminals. Verify network connectivity.
  3. Issue: ros2 launch fails to locate package or launch file.
    • Cause: Package not built, not sourced, or incorrect path in launch file.
    • Solution: Execute colcon build --packages-select <your_package_name> from workspace root, then source install/setup.bash. Verify package and launch file names.
  4. Issue: Messages not appearing with ros2 topic echo.
    • Cause: Publisher not running, topic name mismatch, or message type mismatch.
    • Solution: Verify publisher node is running (ros2 node list). Check topic name (ros2 topic list) and message type (ros2 topic info).
  5. Issue: ros2 run command fails with executable not found.
    • Cause: Executable not correctly defined in setup.py (Python packages) or CMakeLists.txt (C++ packages).
    • Solution: Ensure entry_points in setup.py (Python) or install directives in CMakeLists.txt (C++) correctly register the executable. Rebuild and re-source.

Practice Exercises​

  1. ROS 2 System Introspection:
    • Launch talker_listener.launch.py again.
    • In a separate terminal, use ros2 topic list -t to list topics with their types.
    • Use ros2 node info /sim_talker and ros2 node info /sim_listener to understand their connections.
    • Experiment with ros2 param set /sim_talker use_sim_time true and observe any changes (though not directly visible in this simple example).
  2. Modify Communication Content:
    • Modify publisher_member_function.py to publish a different message (e.g., "Physical AI is transforming robotics!").
    • Rebuild the package (colcon build --packages-select hello_physical_ai) and re-source.
    • Relaunch the nodes and verify the new message is received by the listener.
  3. Add a Third Node:
    • Create a new Python file in hello_physical_ai/hello_physical_ai called minimal_timer.py that publishes the current time (using std_msgs.msg.String or builtin_interfaces.msg.Time) on a new topic /time_topic every 1 second.
    • Update setup.py to register this new executable.
    • Modify talker_listener.launch.py to also launch this new node.
    • Rebuild, re-source, and launch the system to verify the new timer node is working.

Summary​

This chapter provided fundamental understanding of ROS 2's architecture, covering:

  • The roles of nodes, topics, services, actions, and parameters.
  • How to use key ROS 2 command-line tools for system introspection.
  • The advantages of ROS 2 over its predecessor, ROS 1.

You built upon your Chapter 1 development environment by launching and inspecting a basic ROS 2 publisher-subscriber system.

Next Steps​

The next chapter, "ROS 2 Python Development," deepens your programming skills by teaching you to create custom nodes, handle messages, and implement more complex robotic behaviors using Python.

➡️ Continue to Chapter 3: ROS 2 Python Development

Additional Resources​