Skip to main content

Actions: Long-Running Tasks

Learning Objectives

After completing this chapter, you will be able to:

  • Create custom action definitions for complex robotic tasks
  • Implement action servers that handle long-running operations
  • Build action clients that monitor and control ongoing tasks
  • Design action-based workflows for humanoid robot navigation and manipulation

Introduction

Actions in ROS 2 are designed for long-running tasks that require feedback during execution and the ability to cancel operations. This makes them ideal for humanoid robotics applications such as navigation, manipulation, complex trajectory following, or any task that takes a significant amount of time to complete and requires monitoring.

Unlike services, which are synchronous and block until completion, actions are asynchronous and provide continuous feedback to clients. This allows the robot system to continue operating while a task is in progress, providing updates on progress and allowing for intervention if needed. Actions also support cancellation, which is crucial for safety in robotic systems.

Core Concepts

ROS 2 actions extend the request-response pattern of services by adding continuous feedback and the ability to cancel operations. Each action interface includes three message types: goal (request), result (response), and feedback (status updates during execution).

Action Definition

Action definitions are specified in .action files that define the goal, result, and feedback message structures. The goal contains parameters for the action, the result contains the outcome, and the feedback provides periodic updates during execution.

Action Server

An action server manages the execution of long-running tasks. It receives goals from clients, executes them, provides feedback during execution, and returns results when complete. Action servers can also handle cancellation requests.

Action Client

An action client sends goals to an action server and can monitor progress, receive feedback, and cancel goals if needed. This allows for more complex interactions than simple services.

Use Cases

Actions are appropriate for operations that:

  • Take a long time to complete
  • Require monitoring of progress
  • Need the ability to cancel during execution
  • Benefit from feedback during execution
  • Are goal-oriented rather than request-response oriented

Hands-on Examples

Let's implement custom actions for humanoid robot navigation and manipulation:

# Action file: NavigateToPose.action
# Save as action/NavigateToPose.action

# Define the goal
geometry_msgs/Pose target_pose
float32 tolerance

---
# Define the result
bool success
string message
float32 distance_traveled

---
# Define the feedback
string status
float32 distance_to_goal
float32 progress_percentage
geometry_msgs/Pose current_pose

Expected Output:

[INFO] [1678882844.123456789] [navigate_to_pose_action_server]: Navigation action server initialized
[INFO] [1678882844.123456789] [navigate_to_pose_action_client]: Navigation action client initialized
[INFO] [1678882844.123456789] [navigate_to_pose_action_client]: Waiting for action server...
[INFO] [1678882844.123456789] [navigate_to_pose_action_client]: Sending navigation goal to (2.0, 1.5)
[INFO] [1678882844.123456789] [navigate_to_pose_action_server]: Received goal request to navigate to position: (2.0, 1.5)
[INFO] [1678882844.123456789] [navigate_to_pose_action_server]: Executing goal...
[INFO] [1678882844.323456789] [navigate_to_pose_action_client]: Navigation feedback: 10.0% complete, 2.21m to goal
[INFO] [1678882844.523456789] [navigate_to_pose_action_client]: Navigation feedback: 20.0% complete, 1.98m to goal
...
[INFO] [1678882854.123456789] [navigate_to_pose_action_server]: Result: Reached target position within 0.2m tolerance
[INFO] [1678882854.123456789] [navigate_to_pose_action_client]: Result: Reached target position within 0.2m tolerance
[INFO] [1678882854.123456789] [navigate_to_pose_action_client]: Distance traveled: 2.55m

Exercises

Complete the following exercises to reinforce your understanding:

  1. Manipulation Action: Create an action for controlling humanoid arm movements

    • Define an action interface for arm manipulation tasks
    • Implement an action server that controls the robot's arms
    • Create a client that sends manipulation goals
    • Add progress feedback for multi-step manipulation sequences
  2. Action Cancellation: Implement robust cancellation handling

    • Add cancel callbacks that properly stop ongoing operations
    • Test cancellation under various timing conditions
    • Implement cleanup procedures that run on cancellation
    • Create a user interface for requesting action cancellations

Common Pitfalls and Solutions

  • Pitfall 1: Not handling cancellation properly - Actions continuing to execute after cancellation
    • Solution: Always check goal_handle.is_cancel_requested in execution loops
  • Pitfall 2: Blocking execution - Action callbacks blocking the executor
    • Solution: Use async/await patterns and avoid long blocking operations
  • Pitfall 3: Resource cleanup - Not properly cleaning up resources when actions complete
    • Solution: Use try/finally blocks to ensure cleanup happens
  • Pitfall 4: Feedback frequency - Sending feedback too frequently or infrequently
    • Solution: Balance feedback frequency with performance requirements

Summary

  • Actions are designed for long-running tasks requiring feedback and cancellation
  • Action interfaces define goal, result, and feedback message structures
  • Action servers execute tasks and provide continuous feedback
  • Action clients can monitor progress and cancel operations
  • Actions are essential for navigation, manipulation, and complex task execution

Further Reading