A ROS action handles long-running goals — navigate somewhere, execute a trajectory — with live progress feedback and the ability to cancel, filling the gap between fire-and-forget topics and quick request-response services.
A ROS action is for tasks that take a while, like "drive to the kitchen." You send a goal, get progress updates along the way, and can cancel it if you change your mind — unlike a quick service call that just returns once.
"Navigate to the kitchen" isn't a quick question — it takes time, you want progress updates, and you might change your mind halfway. A service can't do that, and a topic has no notion of a goal. The ROS action is built exactly for this.
What it is
An action is an asynchronous, goal-oriented interaction with three parts:
Goal — the client requests something ("go to (x, y)").
Feedback — the server streams progress while it works ("2.3 m remaining").
Result — the final outcome when done ("arrived" or "failed").
And critically, the client can cancel the goal mid-execution. Under the hood, an action is composed of topics and services, but it presents this richer lifecycle as one unit.
A goal with progress and an off-switch
Unlike a service's single reply, an action keeps you informed while it runs and lets you abort — the model for any task that takes real time.
When to use it
The three ROS interaction types map to three timescales:
Topic — continuous streams.
Service — instant request/response.
Action — anything long-running where you need progress or cancellation.
If a client would be stuck waiting a long time for a service, it should be an action instead.
Where you'll see it
Actions are everywhere a robot does something that takes a while:
Nav2 exposes navigation as an action (NavigateToPose) — send a destination, watch progress, cancel if needed.
Gripper open/close, docking, and inspection routines are commonly actions.
Why it matters
Actions give ROS a clean way to command long tasks — the everyday reality of robotics, where navigating, manipulating, and inspecting all take time and can go wrong partway. They're essential to how high-level robot behaviors are commanded and monitored.
