Chapter 1.1: Introduction to ROS 2 Architecture
Introduction​
Welcome to ROS 2 (Robot Operating System 2), the standard middleware for robotics development. In this chapter, we'll explore what problems ROS 2 solves, why robots need middleware, and how ROS 2 architecture enables complex robotic systems to work together seamlessly.
What Problem ROS 2 Solves​
Building complex robotic systems presents several challenges:
Component Integration Challenge​
Without middleware like ROS 2, integrating different components of a robot would require:
- Direct communication between every pair of components
- Custom communication protocols for each connection
- Complex, hard-to-maintain code that's difficult to modify
- Difficulty in testing individual components separately
The Need for Standardized Communication​
Robotic systems typically include many different components:
- Perception systems (cameras, LiDAR, IMUs)
- Planning systems (path planning, task planning)
- Control systems (motor control, trajectory generation)
- User interfaces (command interfaces, visualization tools)
These components need to communicate with each other, but they may:
- Be developed by different teams
- Use different programming languages
- Run on different computers
- Have different update rates and timing requirements
Why Robots Need Middleware​
Middleware is software that sits between different applications and enables them to communicate. Robots need middleware for several key reasons:
Decoupling Components​
Middleware allows components to:
- Develop independently without tight dependencies
- Be replaced or upgraded without affecting other components
- Be tested in isolation
- Be reused across different robotic platforms
Language and Platform Independence​
ROS 2 enables:
- Components written in different programming languages (C++, Python, etc.) to communicate
- Components running on different operating systems to work together
- Components on different physical computers to interact seamlessly
Standardized Interfaces​
Middleware provides:
- Common message formats that all components understand
- Standard ways to publish and subscribe to information
- Consistent tools for debugging and monitoring
Core ROS 2 Concepts​
Nodes​
Nodes are the basic execution units of a ROS 2 system. Think of them as individual programs or processes that perform specific functions:
- Purpose: Each node typically performs one specific task or set of related tasks
- Example nodes: Camera driver, path planner, motor controller, user interface
- Independence: Nodes can run on the same or different computers
- Communication: Nodes communicate with each other through topics, services, and actions
Topics​
Topics are named channels through which nodes publish and subscribe to messages:
- Publish-Subscribe Pattern: One node publishes data, multiple nodes can subscribe to receive it
- Asynchronous: Publishers and subscribers don't need to run simultaneously
- Data Flow: Information flows from publishers to subscribers
- Example: Camera node publishes images to a "camera/image" topic, multiple nodes can subscribe to process the images
Services​
Services provide request-response communication between nodes:
- Synchronous: The client waits for a response from the server
- Request-Response: Client sends a request, server processes it and sends a response
- Use Case: When you need to get specific information or perform a specific action on demand
- Example: Requesting the robot's current position or asking for a path to a destination
Actions​
Actions handle long-running tasks with feedback:
- Goal-Result-Feedback: Clients send goals, receive feedback during execution, and get results when complete
- Cancel Capability: Actions can be canceled during execution
- Use Case: Tasks that take significant time and need status updates
- Example: Moving the robot to a distant location with periodic progress updates
ROS 2 in Humanoid Robotics​
In humanoid robotics, ROS 2 architecture becomes even more critical because of the complexity of these systems:
Multiple Subsystems​
Humanoid robots typically have:
- Locomotion systems: Leg control, balance, walking algorithms
- Manipulation systems: Arm control, hand coordination, grasping
- Perception systems: Vision, spatial awareness, object recognition
- Cognitive systems: Task planning, decision making, human interaction
- Safety systems: Emergency stops, collision avoidance, stability monitoring
Coordination Requirements​
These subsystems need to coordinate effectively:
- Perception data must inform planning decisions
- Planning outputs must be executed by control systems
- Safety systems must override other systems when necessary
- Human interaction systems must coordinate with all other systems
Distributed Architecture​
Humanoid robots often use distributed computing:
- High-level planning on powerful computers
- Real-time control on specialized hardware
- Sensor processing on embedded systems
- ROS 2 enables these distributed components to work together
Learning Summary​
In this chapter, we've covered:
- ROS 2 solves the component integration challenge in complex robotic systems
- Robots need middleware for decoupling, language independence, and standardized interfaces
- Core ROS 2 concepts include nodes, topics, services, and actions
- Each concept serves different communication patterns and use cases
- In humanoid robotics, ROS 2 enables coordination of multiple complex subsystems
- ROS 2 supports distributed architectures that are common in humanoid robots
Self-Assessment Questions​
- What is the main problem that ROS 2 solves in robotics development?
- Explain the difference between nodes, topics, services, and actions in ROS 2.
- Why is language independence important in ROS 2?
- What are the key subsystems in a humanoid robot that would use ROS 2?
- How does ROS 2 enable distributed computing in robotics?