ROS 2 Architecture: Nodes, Topics, Services

🟢Beginner

Loading personalization panel...

In this section, we'll dive deep into the three fundamental communication patterns in ROS 2: nodes, topics, and services. Understanding these concepts is crucial for building any robotic system, especially humanoid robots that require coordination between many different subsystems.

Nodes: The Building Blocks

A node is a process that performs computation. In ROS 2, nodes are the fundamental building blocks of any robot application. Each node should have a single, specific purpose.

Creating a Node

A node in ROS 2 is typically implemented as a class that inherits from rclpy.Node. Here's the basic structure:

import rclpy
from rclpy.node import Node

class MinimalNode(Node):
    def __init__(self):
        super().__init__('minimal_node')
        self.get_logger().info('Minimal node created')

def main(args=None):
    rclpy.init(args=args)
    node = MinimalNode()

    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        rclpy.shutdown()

if __name__ == '__main__':
    main()

Node Naming and Uniqueness

Each node must have a unique name within the ROS 2 domain. If two nodes try to use the same name, one will fail to start. This ensures that there's no confusion about which node is which in a distributed system.

Topics: Publish/Subscribe Communication

Topics enable asynchronous communication between nodes using a publish/subscribe pattern. A node publishes messages to a topic, and other nodes subscribe to that topic to receive the messages.

Topic Characteristics

Asynchronous: Publishers don't wait for subscribers to receive messages
Many-to-many: Multiple publishers can send to the same topic, and multiple subscribers can receive from the same topic
Data-driven: Communication is triggered by data availability, not by requests

Topic Example: Robot Sensor Data

In a humanoid robot, topics are perfect for sensor data distribution:

Joint position sensors publish to /joint_states
Camera nodes publish images to /camera/image_raw
IMU sensors publish to /imu/data

Multiple nodes can subscribe to these topics simultaneously - a controller node might read joint states, while a monitoring node displays them.

Quality of Service (QoS)

ROS 2 provides Quality of Service settings that allow you to tune communication behavior:

Reliability: Best effort vs. reliable delivery
Durability: Volatile vs. transient local (for late-joining subscribers)
History: Keep all messages vs. keep last N messages

Services: Request/Response Communication

Services provide synchronous request/response communication. A client sends a request to a service, and the service sends back a response. This is useful for operations that need to complete before the client can continue.

Service Characteristics

Synchronous: The client waits for the response
One-to-one: One client communicates with one service server
Action-oriented: Good for operations with a clear beginning and end

Service Example: Robot Control

Services are ideal for operations that must complete successfully:

/move_to_pose: Move robot to a specific pose
/get_robot_state: Get current robot state
/calibrate_sensors: Calibrate sensors

Actions: Goal-Oriented Communication

Actions are used for long-running tasks that have feedback and can be canceled. They combine the benefits of both topics and services, providing goal-oriented communication with progress feedback.

Action Characteristics

Long-running: For tasks that take significant time
Cancellable: Clients can cancel goals in progress
Feedback: Servers provide ongoing feedback about progress
Preemption: New goals can preempt current goals

Actions are perfect for navigation tasks:

/navigate_to_pose: Navigate to a pose with feedback on progress
/move_group: Plan and execute complex manipulator motions

Practical Example: Node Communication

Let's consider how these patterns work together in a humanoid robot:

Sensor Node: Publishes joint states to /joint_states topic
Controller Node: Subscribes to /joint_states, calculates control commands, publishes to /joint_commands topic
Safety Node: Subscribes to both topics, monitors for dangerous conditions, provides /emergency_stop service
High-level Planner: Uses /navigate_to_pose action to move the robot

ROS 2 Communication Patterns Summary

Pattern	Type	Use Case	Example
Topic	Publish/Subscribe	Sensor data, continuous streams	`/joint_states`, `/camera/image`
Service	Request/Response	Action with completion	`/get_state`, `/set_pose`
Action	Goal-Oriented	Long-running tasks	`/navigate`, `/manipulate`

Best Practices for Communication Design

1. Choose the Right Pattern

Use topics for continuous data streams
Use services for discrete operations that must complete
Use actions for long-running operations with feedback

2. Topic Naming Conventions

Use descriptive names that indicate content
Group related topics with common prefixes
Example: /arm/joint_states, /arm/end_effector_pose

3. Message Types

Use standard message types when possible
Create custom message types for domain-specific data
Keep messages lightweight but complete

4. Error Handling

Implement proper error handling for all communication patterns
Use appropriate QoS settings for your application
Plan for network interruptions and node failures

Communication Patterns Lab

Objectives

Understand the differences between topics, services, and actions
Identify appropriate use cases for each pattern
Analyze a humanoid robot's communication architecture

Prerequisites

Understanding of ROS 2 basics
Basic Python knowledge

Steps

Identify 3 different sensor streams on a humanoid robot that would use topics
List 3 operations that would be better implemented as services than topics
Describe a scenario where an action would be more appropriate than a service
Sketch a simple communication diagram showing how these patterns work together in a walking humanoid robot

Expected Outcome

You should be able to distinguish between the different communication patterns and identify appropriate use cases for each

Troubleshooting Tips

Remember that topics are for continuous data streams
Services are for operations that must complete before the client continues
Actions are for long-running operations that provide feedback

Summary

In this section, we've explored the three fundamental communication patterns in ROS 2:

Nodes are the basic computational units
Topics enable asynchronous publish/subscribe communication
Services provide synchronous request/response communication
Actions support long-running goal-oriented tasks

Understanding these patterns is essential for designing effective robotic systems, particularly for humanoid robots where many different subsystems must coordinate seamlessly.

Next Steps

In the next section, we'll put these concepts into practice with a hands-on lab where you'll create your first ROS 2 publisher and subscriber nodes.

Nodes: The Building Blocks​

Creating a Node​

Node Naming and Uniqueness​

Topics: Publish/Subscribe Communication​

Topic Characteristics​

Topic Example: Robot Sensor Data​

Quality of Service (QoS)​

Services: Request/Response Communication​

Service Characteristics​

Service Example: Robot Control​

Actions: Goal-Oriented Communication​

Action Characteristics​

Action Example: Navigation​

Practical Example: Node Communication​

ROS 2 Communication Patterns Summary​

Best Practices for Communication Design​

1. Choose the Right Pattern​

2. Topic Naming Conventions​

3. Message Types​

4. Error Handling​