ROS 2 is the second generation of the Robot Operating System, an open-source middleware and software framework that lets the many programs of a robot exchange data, share configuration and run controllers in a common, modular way. Despite its name it is not an operating system: it runs on Linux, Windows, macOS and real-time platforms and provides communication, tooling and libraries on top of them.
In robot control systems, ROS 2 matters because it hosts the layer where feedback control meets hardware. Through the ros2_control framework, controllers such as PID position loops or trajectory followers read sensor states, compute commands and write them to motors in a deterministic update loop, while the rest of the robot software communicates through standard interfaces.
How ROS 2 is organized
A ROS 2 system is a graph of nodes, each a process or component responsible for one function such as reading a LiDAR, estimating pose or commanding a gripper. Nodes communicate through a few well-defined patterns, each suited to a different kind of interaction.
| Pattern | Interaction style | Typical control-related use |
|---|---|---|
| Topic | Anonymous publish and subscribe stream | Joint states, sensor data, velocity commands |
| Service | Request and single response | Switching controllers, triggering calibration |
| Action | Long-running goal with feedback and cancel | Following a joint trajectory, navigating to a pose |
| Parameter | Named configuration value per node | Controller gains, limits, update rates |
Underneath, ROS 2 uses the Data Distribution Service (DDS) standard through a middleware abstraction layer called RMW. DDS provides automatic discovery of nodes on the network and configurable Quality of Service (QoS) policies, which removes the single central master that the first ROS generation required and allows multi-robot and embedded deployments.
Quality of service and timing
QoS policies decide how messages behave when networks or processes are imperfect. For control data the right choice is often counterintuitive: a lost sensor sample should be dropped rather than retransmitted late, because stale data is worse than no data in a feedback loop.
| Setting | Options | Effect on control data |
|---|---|---|
| Reliability | Reliable or best effort | Best effort avoids latency spikes from retransmission |
| History and depth | Keep last N or keep all | Keep last 1 delivers only the newest state |
| Durability | Volatile or transient local | Transient local lets late joiners get the last value |
| Deadline | Maximum period between messages | Flags a sensor or command stream that stopped |
| Liveliness | Automatic or manual assertion | Detects a crashed publisher |
ROS 2 itself is not hard real-time by default. Deterministic loops in the kilohertz range require a real-time kernel such as PREEMPT_RT, memory preallocation, careful executor design and avoidance of dynamic allocation inside the control path. Many robots therefore run the fastest current or torque loops in motor drives or microcontrollers and use ROS 2 for position, trajectory and supervisory control.
Control with ros2_control
ros2_control is the standard framework for closing control loops inside ROS 2. A controller manager runs a periodic read, update, write cycle, commonly at 100 Hz to 1 kHz: hardware interfaces read encoder and sensor states, controllers compute commands, and the hardware interfaces write those commands to the actuators.
The framework separates hardware abstraction from control logic. A hardware interface plugin exposes state interfaces, such as position and velocity, and command interfaces, such as effort or velocity setpoints. Controllers bind to these interfaces by name, so the same joint trajectory controller can drive a simulated arm and a real one without code changes.
| Controller | Input | Typical application |
|---|---|---|
| Joint trajectory controller | Time-stamped joint waypoints | Robot arms executing planned motion |
| Diff drive controller | Linear and angular velocity | Two-wheeled mobile bases with odometry |
| Forward command controller | Direct position, velocity or effort | Simple actuators, testing |
| PID controller | Reference and measured value | Closing loops on any exposed interface |
| Joint state broadcaster | Hardware state interfaces | Publishing joint states for other nodes |
Controllers and hardware components follow a managed lifecycle with unconfigured, inactive and active states. This allows a supervisor to load, configure and activate controllers in a defined order, switch between position and effort control at runtime, and bring hardware into a safe inactive state before shutdown or after a fault.
ROS 2 compared with neighboring control concepts
ROS 2 is infrastructure, not a control law. PID, feedback control and model predictive control are algorithms that decide what command to send; ROS 2 provides the plumbing, scheduling and interfaces through which those algorithms receive measurements and deliver commands. A model predictive controller for a mobile base, for example, can run as a ROS 2 node that consumes odometry and publishes velocity commands.
Compared with the first ROS generation, ROS 2 adds DDS-based discovery, QoS, managed lifecycle nodes, security through SROS 2 and better support for real-time and embedded systems via micro-ROS on microcontrollers. Compared with a PLC or a vendor robot controller, ROS 2 offers far more flexibility and ecosystem but does not by itself provide certified functional safety, which still requires dedicated safety controllers.
Practical pitfalls
Teams moving from prototypes to products meet a recurring set of problems, most of which concern timing, configuration and versions rather than algorithms.
- QoS mismatch: a reliable subscriber cannot receive from a best-effort publisher, so topics appear silent without an obvious error.
- Executor starvation: long callbacks in a single-threaded executor delay control callbacks and cause jitter.
- Discovery traffic: large graphs on shared Wi-Fi networks can flood the link, which often calls for a discovery server or domain separation.
- Distribution drift: mixing packages from different ROS 2 distributions breaks message compatibility, so teams usually pin one long-term support release.
- Unclear safety boundary: emergency stops and protective limits belong in hardware and safety-rated controllers, not only in ROS 2 nodes.
In everyday language
ROS 2 is like the shared language and wiring system inside a robot. The camera program, the motor program and the planning program each do their own job, and ROS 2 lets them pass messages to one another reliably.
For control, it provides a steady heartbeat: many times per second, it reads where the motors are, lets the control program decide what to do, and sends the new commands. Engineers can swap parts without rebuilding everything.
Seen in the real world
A small manufacturer builds a six-axis arm for laboratory automation. The motor drives handle current control internally, and a Linux computer with a PREEMPT_RT kernel runs ros2_control at 500 Hz, using a custom hardware interface that exchanges positions and velocity commands with the drives over EtherCAT.
A motion planner sends trajectories to the joint trajectory controller through a ROS 2 action, and a separate node publishes diagnostics with best-effort QoS. During development the same controllers ran against a simulator, which let the team tune gains before touching hardware. In production, a dedicated safety relay handles the emergency stop, while ROS 2 handles motion, monitoring and integration with the lab scheduling software.