ROS Action

A ROS Action is fundamentally an asynchronous, goal-oriented communication pattern. A client sends a goal (e.g., 'navigate to pose X, Y') to an action server. The server executes the potentially long-running task without blocking the client, which can continue other operations, preempt the goal, or cancel it. This contrasts with synchronous ROS Services, which block the client for the entire request duration. The protocol is built on three ROS topics: goal, feedback, and result.

A key advantage over services is the built-in feedback mechanism. During goal execution, the action server can publish periodic feedback messages on a dedicated topic. This allows the client to monitor progress in real-time (e.g., '60% complete', 'current position: X, Y'). Feedback is crucial for user interfaces and for higher-level planning nodes that need to make decisions based on the progress of subordinate tasks.

• Example: A navigation action server might stream feedback containing the robot's estimated distance to the goal and current velocity.

ROS Actions are designed to be interruptible. A client can send a new goal to the same server, which will preempt the currently executing goal. The client can also explicitly send a cancel request. The action server must handle these interrupts gracefully, typically stopping the current task, performing any necessary cleanup, and sending a canceled result status. This is essential for reactive robotic systems where priorities can change dynamically (e.g., 'stop moving and return to base').

Upon completion (successful, preempted, aborted, etc.), the action server sends a final result message to the client. This result is distinct from feedback and contains the outcome of the task. The action protocol defines a standard set of terminal states: SUCCEEDED, ABORTED, CANCELED, etc. This structured termination provides deterministic error handling and allows clients to programmatically react to different completion scenarios.

• Result vs. Feedback: Feedback is for interim progress; the result is the final, conclusive output of the action (e.g., the final pose achieved, a list of objects grasped).

An Action is not a primitive communication type but a convention and API layer built atop standard ROS Topics and a Service. The ActionLib library in ROS 1 and the rclpy.action/rclcpp::action client libraries in ROS 2 implement this convention. Internally, it uses:

• A Service for goal submission and cancellation.
• Three Topics: one for the goal, one for feedback, and one for the result. This design leverages the existing, robust ROS communication infrastructure while providing a higher-level abstraction for complex tasks.

ROS Actions are ideal for any robotic task that is non-instantaneous and benefits from monitoring or interruption.

• Autonomous Navigation: MoveBase action for sending navigation goals.
• Manipulation: PickPlace action for complex pick-and-place sequences.
• Perception: ObjectDetection action for a lengthy scan-and-identify routine.
• Human-Robot Interaction: SpeechRecognition action for listening and processing audio. In these cases, the action client (e.g., a task planner) can monitor feedback, handle failures, and send new goals without managing low-level topic communication directly.

Complex perception algorithms like 3D mapping, object recognition in a cluttered scene, or a full system calibration can take seconds. A ROS Action provides the ideal interface: a client requests a scan or analysis, receives periodic feedback (e.g., 'processing scan line 150 of 200', 'percentage of scene segmented'), and gets a final result containing the processed data (e.g., a point cloud map, a list of detected objects).

• Feedback: percent_complete, current_processing_step
• Result: point_cloud, detected_objects_array, calibration_transform
• Client State: The client is not blocked and can perform other computations while waiting for the final result.

Docking a mobile robot with a charging station is a precise, multi-stage process involving approach, alignment, and final connection. A ROS Action manages this sequence: the goal initiates docking, feedback provides status (e.g., 'approaching', 'aligning', 'connected'), and the result confirms success or failure. The action can be preempted if an obstacle blocks the path or if a higher-priority task emerges.

• Sequential States: Feedback clearly communicates which phase of the docking procedure is active.
• Error Handling: The result can specify failure modes like alignment_failed or charger_unavailable.
• Safety: Allows for immediate cancellation if a person enters the docking zone.

ROS Actions can be composed into hierarchical state machines or behavior trees. A high-level task manager acts as an action client to lower-level skill servers. For example, a 'Deliver Item' task might sequentially call: NavigateToKitchenAction, PickUpObjectAction, NavigateToOfficeAction, PlaceObjectAction. Each sub-action provides its own feedback and result, allowing the orchestrator to monitor the overall task's progress and handle failures at the granular skill level.

• Composability: Actions are the natural building block for complex, recoverable behaviors.
• Fault Tolerance: Failure in a sub-action (e.g., object not found) can be reported cleanly to the orchestrator for re-planning.
• Progress Tracking: The orchestrator can aggregate feedback from all sub-actions to estimate total task completion.

Applying a firmware update or running a comprehensive system self-test are long-running operations with distinct progress stages. A management node sends an update or diagnostics goal. The server provides feedback on the current step (downloading, flashing, testing_motors, testing_sensors) and a final result with a detailed log and pass/fail status. This pattern is superior to a service call, which would block the client for the entire, potentially lengthy, duration.

• User Feedback: Critical for providing operational status to a human operator via a UI.
• Interruptibility: Allows an update to be canceled before the irreversible flashing phase.
• Result Data: The final result can contain a full diagnostic report or update verification hash.

A ROS Topic is the primary mechanism for asynchronous, many-to-many data streaming. Nodes publish messages to a named topic, and any number of subscriber nodes can receive them concurrently.

• Communication Model: Publish-Subscribe.
• Data Flow: Unidirectional, streaming.
• Use Case: Continuously publishing sensor data (e.g., camera images, LiDAR scans, odometry).
• Key Difference from Actions: Topics lack a formal goal, feedback, and result structure; they are pure data streams.

A ROS Service provides a synchronous, request-response communication pattern. A client sends a request to a server node and blocks execution until it receives a reply.

• Communication Model: Client-Server (blocking).
• Data Flow: Bidirectional, single exchange.
• Use Case: Performing quick, atomic operations like looking up a transformation, calculating a value, or toggling a setting.
• Key Difference from Actions: Services are designed for short-duration tasks; they do not provide intermediate feedback and block the client for the duration.

The Action Protocol is the underlying specification that defines the structure of a ROS Action. It is implemented using three dedicated topics under a common namespace:

1. Goal Topic: Client sends the goal description.
2. Feedback Topic: Server streams periodic progress updates.
3. Result Topic: Server sends the final outcome upon completion.

This protocol also defines a simple state machine (PENDING, ACTIVE, PREEMPTED, SUCCEEDED, etc.) tracked by an Action Server and monitored by an Action Client.

An Action Server is the node that receives goal requests, executes the corresponding long-running task, and manages the action's lifecycle.

• Responsibilities: Accepts/rejects goals, executes the task logic, streams feedback, and provides a final result or cancellation notice.
• Preemption: A core capability is handling goal preemption, where a newer goal can cancel the currently executing one.
• Implementation: Typically contains a callback (e.g., execute_callback) where the developer writes the task's business logic.

An Action Client is the node that sends a goal to an Action Server and monitors its execution.

• Responsibilities: Sends the goal, can cancel it, and listens for feedback and the final result.
• Non-Blocking: The client can send a goal and continue with other processing, polling for completion or using a callback to be notified of the result.
• Feedback Handling: The client can define a callback function to process incoming feedback messages during task execution.

Behavior Trees are a decision-making architecture often used with ROS Actions, most notably in the ROS 2 Navigation2 (Nav2) stack. They orchestrate complex robotic behaviors by structuring actions, conditions, and logic into a hierarchical tree.

• Integration with Actions: Behavior Tree nodes (called Action Nodes) frequently wrap ROS Action clients. For example, a ComputePathToPose action node sends a goal to the planner's action server.
• Advantages: Provides modularity, reactivity (through preemption), and improved maintainability over monolithic state machines for task sequencing.