ROS2 Foundations and Setup
ROS2 Introduction
What is ROS 2
ROS 2 (Robot Operating System 2) is an open-source robotics middleware and tooling ecosystem. It is not an operating system by itself. Instead, it provides communication libraries, developer tools, and runtime conventions that help you build distributed robotic applications.
Definition of ROS 2
ROS 2 provides the infrastructure needed for robotics software, including:
- Inter-process communication
- Hardware abstraction through drivers
- Package and dependency management
- Distributed execution across multiple machines
In practice, ROS 2 lets developers connect sensors, algorithms, and actuators into modular systems.
Design objectives for ROS 2
ROS 2 was designed for modern robotic systems with stronger production requirements:
| Objective | Why it matters |
|---|---|
| Real-time friendliness | Better support for low-latency workloads |
| Distributed deployment | Nodes can run across processes and machines |
| Reliability and maintainability | Better fit for production than ROS 1-era assumptions |
| Security | Supports encryption, authentication, and access control |
| Cross-platform support | Runs on Linux, Windows, macOS, and embedded targets |
ROS 2 Core values
- Modular design: software is split into reusable packages.
- Distributed communication: supports multi-process and multi-machine systems.
- Rich ecosystem: many community-maintained packages and tools.
- Active community: broad contribution from developers and companies.
ROS 2 Core concept
Node (Nodes)
A node is the smallest computational unit in ROS 2. Each node is a process that uses ROS 2 APIs to communicate with other nodes.
Node design principles:
- Single responsibility: one node should focus on one function.
- Low coupling: nodes communicate through interfaces instead of tight dependencies.
- Composability: complex systems are built by combining many nodes.
Topics (Topics)
A topic is an asynchronous publish/subscribe channel between nodes.
Topic communication features:
| Feature | Description |
|---|---|
| Asynchronous | Publishers and subscribers do not block each other |
| One-to-many | Multiple subscribers can consume the same topic |
| Loosely coupled | Nodes only need to agree on topic name and message type |
| Streaming friendly | Good for sensor streams and continuous control |
Typical topics:
| Topic Name | Message Type | Purpose |
|---|---|---|
/cmd_vel | geometry_msgs/msg/Twist | Velocity command |
/odom | nav_msgs/msg/Odometry | Odometry data |
/scan | sensor_msgs/msg/LaserScan | Lidar scan data |
/camera/image_raw | sensor_msgs/msg/Image | Raw image stream |
Services (Services)
Services provide synchronous request/response communication.
Service communication characteristics:
| Feature | Description |
|---|---|
| Request/response | Client sends a request and waits for a response |
| Synchronous pattern | Useful when completion status is required |
| One-to-one interaction | Typically one client and one service endpoint |
| Best for short tasks | Not suitable for long-running jobs |
Typical services:
| Service Name | Service Type | Purpose |
|---|---|---|
/spawn | turtlesim/srv/Spawn | Spawn a new turtle |
/teleport_absolute | turtlesim/srv/TeleportAbsolute | Move turtle to a target pose |
/reset | std_srvs/srv/Empty | Reset simulation state |
Actions
Actions are used for long-running tasks that need progress feedback and cancellation.
Three streams in an action interface:
| Stream | Purpose |
|---|---|
| Goal | Defines the requested task |
| Feedback | Reports progress during execution |
| Result | Returns the final outcome |
Typical actions:
| Action Name | Action Type | Purpose |
|---|---|---|
/navigate_to_pose | nav2_msgs/action/NavigateToPose | Navigate to target pose |
/spin | turtlesim/action/RotateAbsolute | Rotate by target angle |
Parameters (Parameters)
Parameters are node configuration values. They can be set at startup and updated at runtime.
Example:
ros2 param set /camera_node exposure_mode manualCommon parameter types:
| Type | Description | Example |
|---|---|---|
bool | Boolean | true |
int | Integer | 42 |
double | Floating-point number | 3.14 |
string | Text | "camera_link" |
byte[] | Byte array | [0x01, 0x02] |
bool[] | Boolean array | [true, false] |
int[] | Integer array | [1, 2, 3] |
double[] | Floating-point array | [0.1, 0.2] |
string[] | String array | ["a", "b"] |
ROS 2 Structure
Layer structure
ROS 2 uses a layered architecture from OS to application:
Typical layers:
- Operating system layer (Linux/Windows/macOS/RTOS)
- DDS implementation layer
- RMW abstraction layer
- Client library layer (
rclcpp,rclpy, etc.) - Application layer (your robot nodes)
Client Library (Client Libraries)
ROS 2 supports multiple client libraries:
| Library | Language | Typical use |
|---|---|---|
rclcpp | C++ | High-performance production nodes |
rclpy | Python | Fast prototyping and scripting |
rclc | C | Micro-ROS and constrained devices |
rcljava | Java | JVM ecosystem integration |
rclnodejs | JavaScript / Node.js | Web and tooling integration |
RMW and DDS
RMW (ROS Middleware interface) decouples ROS 2 APIs from specific DDS vendors.
Benefits:
- Swap DDS implementations with minimal application changes.
- Reuse the same ROS 2 code across different middleware backends.
- Leverage DDS features such as discovery and QoS.
Common DDS backends:
| RMW implementation | DDS backend | License model | Notes |
|---|---|---|---|
rmw_cyclonedds_cpp | Cyclone DDS | Open source | Common default choice |
rmw_fastrtps_cpp | Fast DDS | Open source | Widely used and feature-rich |
rmw_connextdds | RTI Connext DDS | Commercial | Industrial-grade option |
Core DDS capabilities used by ROS 2:
- Automatic discovery
- QoS policy control
- Efficient transport and serialization
- Strong type contracts for message exchange
Major differences between ROS 1 and ROS 2
Structure comparison
ROS 1 depends on a centralized ROS Master for discovery, while ROS 2 uses DDS-based decentralized discovery.
Detailed comparative tables
| Dimension | ROS 1 | ROS 2 |
|---|---|---|
| Middleware | Custom TCPROS/UDPROS | DDS-based standard middleware |
| Discovery | ROS Master (centralized) | DDS discovery (decentralized) |
| Build system | Catkin | Colcon + Ament |
| Python support | Python 2/3 (Noetic era transition) | Python 3 |
| OS support | Primarily Linux | Linux, Windows, macOS, RTOS |
| Real-time support | Limited | Improved real-time support |
| Multi-robot support | Extra setup required | Better native isolation (ROS_DOMAIN_ID) |
| Security | Minimal built-in security | SROS2 security framework |
| Release line | Noetic is final ROS 1 release | Active releases (Humble, Iron, Jazzy, etc.) |
Detailed information on key improvements
- Decentralization
- ROS 1: depends on ROS Master for discovery.
- ROS 2: DDS discovery removes single-point dependence.
- Real-time capability
- ROS 1: not designed for strict real-time workloads.
- ROS 2: improved determinism through DDS QoS and executor design.
- Multi-robot collaboration
- ROS 1: requires additional engineering to isolate robots.
- ROS 2:
ROS_DOMAIN_IDsimplifies logical separation.
- Cross-platform support
- ROS 1: Linux-focused.
- ROS 2: stronger support across Linux, Windows, macOS, and embedded targets.
ROS 2 Release
Version history
ROS 2 uses named releases. Common milestones include:
- Ardent
- Bouncy
- Crystal
- Dashing
- Eloquent
- Foxy
- Galactic
- Humble
- Iron
- Jazzy
Humble is a long-term support (LTS) release and is widely adopted in education and production entry projects.