Why actions for long-running tasks in ROS - Why It Works This Way

Overview - Why actions for long-running tasks

What is it?

In ROS (Robot Operating System), actions are a way to handle tasks that take a long time to complete. Unlike simple commands that finish quickly, long-running tasks need a way to report progress and allow interruption. Actions provide a communication pattern where a client can send a goal, receive feedback during execution, and get a final result when done.

Why it matters

Without actions, managing long tasks would be clumsy or unreliable. For example, if a robot is asked to move to a distant point, it might take several seconds or minutes. Without a way to track progress or cancel the task, the system could become unresponsive or stuck. Actions solve this by enabling smooth control and monitoring of ongoing tasks, improving robot reliability and user experience.

Where it fits

Before learning about actions, you should understand ROS topics and services, which handle simple messaging and quick requests. After mastering actions, you can explore advanced task coordination, such as action servers with multiple goals or integrating actions with state machines for complex robot behaviors.

Mental Model

Core Idea

Actions let a program start a long task, watch its progress, and stop it if needed, all while staying responsive.

Think of it like...

Imagine ordering a pizza delivery. You place your order (send a goal), get updates like 'your pizza is being prepared' or 'out for delivery' (feedback), and finally receive the pizza (result). You can also cancel the order if needed. Actions work the same way for long tasks in robots.

Client ──> [Send Goal] ──> Action Server
          <── [Feedback Updates] <──
          <── [Result When Done] <──
          <── [Cancel Request] <──

Build-Up - 6 Steps

1

Foundation

Understanding ROS communication basics

Concept: Learn how ROS nodes talk using topics and services.

ROS nodes communicate by sending messages over topics for continuous data streams or by calling services for quick request-response interactions. Topics are like radio broadcasts, and services are like phone calls.

Result

You can send and receive simple messages and make quick requests between nodes.

Knowing topics and services sets the stage to understand why they are not enough for long tasks.

2

Foundation

Limitations of services for long tasks

Concept: Services block the caller until the task finishes, which is bad for long tasks.

When a node calls a service, it waits until the service completes and returns a response. If the task takes a long time, the caller is stuck waiting and cannot do anything else. This makes the system unresponsive.

Result

Long tasks cause delays and block other operations when using services.

Recognizing this problem explains why a new communication pattern is needed.

3

Intermediate

Introducing actions for asynchronous tasks

Concept: Actions allow starting a task and continuing other work while waiting.

An action client sends a goal to an action server and immediately continues running. The server works on the task and sends feedback messages to update progress. When done, it sends a result message. The client can also cancel the task anytime.

Result

The system stays responsive and informed during long tasks.

Understanding asynchronous communication is key to handling real-world robot tasks smoothly.

4

Intermediate

Action feedback and cancellation

🤔Before reading on: do you think feedback is optional or required in ROS actions? Commit to your answer.

Concept: Actions provide feedback during execution and support cancellation requests.

Feedback messages let the client know how the task is progressing, like percentage done or current status. Cancellation allows stopping the task if conditions change or the user wants to abort.

Result

Clients can monitor and control tasks dynamically, improving flexibility.

Knowing feedback and cancellation makes actions powerful for interactive robot control.

5

Advanced

Action server states and transitions

🤔Before reading on: do you think an action server can handle multiple goals at once or only one? Commit to your answer.

Concept: Action servers manage goals with states like pending, active, succeeded, or aborted.

When a goal arrives, the server marks it pending, then active when processing. It can succeed, abort, or be canceled. Servers can queue or reject multiple goals based on implementation. This state management ensures clear task lifecycle handling.

Result

Tasks have well-defined progress and outcomes, enabling robust robot behavior.

Understanding states prevents bugs like lost goals or unclear task status.

6

Expert

Why actions use separate communication channels

🤔Before reading on: do you think actions use the same topic for goals, feedback, and results or separate ones? Commit to your answer.

Concept: Actions use different topics for goals, feedback, and results to keep communication clear and efficient.

ROS actions create three separate channels: one for sending goals, one for feedback, and one for results. This separation allows clients and servers to handle messages independently and avoid blocking or mixing data.

Result

Communication is more reliable and scalable for complex tasks.

Knowing this design helps understand how actions maintain responsiveness and clarity under the hood.

Under the Hood

ROS actions are implemented as a combination of topics and services under the hood. When a client sends a goal, it publishes on a goal topic. The server listens and accepts or rejects goals. Feedback and results are published on separate topics. Internally, the action server tracks each goal's state and uses callbacks to update progress or handle cancellations. This design allows asynchronous, non-blocking communication with clear separation of concerns.

Why designed this way?

Actions were designed to overcome the blocking nature of services and the one-way nature of topics. By combining multiple communication channels and a goal management protocol, actions provide a flexible, robust way to handle long-running tasks. Alternatives like using only topics or services were insufficient because they either lacked feedback or blocked the caller. The chosen design balances complexity and usability.

┌───────────────┐       ┌───────────────┐
│ Action Client │──────▶│ Action Server │
│               │       │               │
│  Send Goal    │       │  Receive Goal │
│◀────Feedback──│       │───Send Feedback│
│◀────Result────│       │───Send Result  │
│  Cancel Goal  │──────▶│  Handle Cancel│
└───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think ROS actions block the client until the task finishes? Commit to yes or no.

Common Belief: Actions work like services and block the client until the task completes.

Reality: Actions are asynchronous; the client sends a goal and continues without waiting for completion.

Why it matters: Believing actions block leads to poor system design and unresponsive robot behavior.

Quick: Do you think feedback messages are optional in ROS actions? Commit to yes or no.

Common Belief: Feedback is optional and rarely used in actions.

Reality: Feedback is a core feature of actions, enabling clients to monitor progress in real time.

Why it matters: Ignoring feedback misses opportunities for dynamic control and better user experience.

Quick: Do you think an action server can handle multiple goals simultaneously? Commit to yes or no.

Common Belief: Action servers always process only one goal at a time.

Reality: Action servers can be designed to queue, reject, or handle multiple goals depending on implementation.

Why it matters: Assuming single-goal handling limits system scalability and flexibility.

Quick: Do you think actions use a single communication channel for all messages? Commit to yes or no.

Common Belief: Actions send goals, feedback, and results over the same topic.

Reality: Actions use separate topics for goals, feedback, and results to avoid message conflicts and blocking.

Why it matters: Misunderstanding this can cause confusion when debugging communication issues.

Expert Zone

1

Action clients can track multiple goals simultaneously by using unique goal IDs, enabling complex task coordination.

2

The action protocol supports preemption, allowing higher-priority goals to cancel lower-priority ones gracefully.

3

Feedback frequency and content should be carefully designed to balance network load and responsiveness.

When NOT to use

Actions are not suitable for very short or instantaneous tasks where services or topics suffice. For simple commands without feedback or cancellation needs, services are simpler and more efficient. Also, for continuous data streams without discrete goals, topics are better.

Production Patterns

In real robots, actions are used for navigation goals, manipulation tasks, or sensor calibration. Developers often combine actions with state machines or behavior trees to manage complex sequences. Monitoring feedback allows adaptive behaviors, like stopping a robot if an obstacle is detected.

Connections

Asynchronous programming

Actions implement asynchronous communication patterns similar to async/await in programming languages.

Understanding asynchronous programming helps grasp how actions keep systems responsive during long tasks.

Client-server architecture

Actions extend the client-server model by adding feedback and cancellation channels.

Knowing client-server basics clarifies how actions manage requests and responses over multiple channels.

Project management workflows

Actions resemble task tracking in project management, with goals, progress updates, and completion reports.

Seeing actions as task management helps understand their role in coordinating complex robot behaviors.

Common Pitfalls

#1 Blocking the client by waiting for action result synchronously.

Wrong approach:

result = action_client.send_goal_and_wait(goal)
# This blocks until the task finishes

Correct approach:

action_client.send_goal(goal)
# Continue running and handle feedback and result asynchronously

Root cause:

Misunderstanding that actions are asynchronous and can be used without blocking.

#2 Ignoring feedback messages and assuming task is done only when result arrives.

Wrong approach:

action_client.send_goal(goal)
# No feedback callback registered

Correct approach:

action_client.send_goal(goal, feedback_cb=handle_feedback)
# Feedback updates keep client informed

Root cause:

Not realizing feedback is essential for monitoring long tasks.

#3 Trying to send multiple goals without managing goal IDs or states.

Wrong approach:

action_client.send_goal(goal1)
action_client.send_goal(goal2)
# No handling of multiple goals

Correct approach:

goal_handle1 = action_client.send_goal(goal1)
goal_handle2 = action_client.send_goal(goal2)
# Manage each goal separately

Root cause:

Lack of understanding of goal management and unique identifiers.

Key Takeaways

ROS actions provide a structured way to handle long-running tasks without blocking the system.

They allow sending goals, receiving progress feedback, and getting results asynchronously.

Actions support cancellation, making robot control flexible and responsive.

Using separate communication channels for goals, feedback, and results ensures clear and efficient messaging.

Understanding actions is essential for building robust, interactive robot applications that handle complex tasks smoothly.

Practice

1. Why are actions used in ROS for long-running tasks instead of simple service calls?

easy

A. Because actions do not require a goal to be set

B. Because actions are faster than service calls

C. Because actions only run once and then stop automatically

D. Because actions provide feedback and allow preemption during the task

Solution

1. Step 1: Understand the difference between service calls and actions

   Service calls in ROS are blocking and do not provide feedback during execution, making them unsuitable for long tasks.

2. Step 2: Identify the benefits of actions for long tasks

   Actions allow sending a goal, receiving continuous feedback, and can be preempted or canceled, which is essential for long-running tasks.

3. Final Answer:

   Because actions provide feedback and allow preemption during the task -> Option D

4. Quick Check:

   Actions give feedback and control = C [OK]

Hint: Actions = feedback + control for long tasks [OK]

Common Mistakes:

• Thinking actions are faster than services
• Believing actions don't need goals
• Assuming actions run only once without control

2. Which of the following is the correct ROS action message structure for a long-running task?

easy

A. Goal, Feedback, Result

B. Request, Response

C. Publisher, Subscriber

D. Service, Client

Solution

1. Step 1: Recall the components of a ROS action

   A ROS action consists of three parts: Goal (what to do), Feedback (progress updates), and Result (final outcome).

2. Step 2: Compare with other ROS communication types

   Request/Response is for services, Publisher/Subscriber is for topics, and Service/Client is a pair for services, not actions.

3. Final Answer:

   Goal, Feedback, Result -> Option A

4. Quick Check:

   Action message parts = Goal, Feedback, Result = A [OK]

Hint: Actions = Goal + Feedback + Result [OK]

Common Mistakes:

• Confusing actions with services
• Mixing up topics and actions
• Ignoring the feedback part

3. Consider this ROS action client code snippet:

client.send_goal(goal_msg)
while not client.wait_for_result(timeout=1.0):
    print('Working...')
result = client.get_result()
print(result)

What will this code do during the long-running task?

medium

A. Raise an error because wait_for_result does not accept timeout

B. Block immediately until the task finishes, then print the result

C. Print 'Working...' repeatedly until the task finishes, then print the result

D. Print 'Working...' once and then stop without printing the result

Solution

1. Step 1: Analyze the wait_for_result call with timeout

   The method waits up to 1 second for the result; if not ready, it returns False, so the loop continues printing 'Working...'.

2. Step 2: Understand the loop behavior

   The loop keeps printing 'Working...' every second until the action finishes, then it exits and prints the final result.

3. Final Answer:

   Print 'Working...' repeatedly until the task finishes, then print the result -> Option C

4. Quick Check:

   wait_for_result with timeout loops = D [OK]

Hint: wait_for_result(timeout) loops until done [OK]

Common Mistakes:

• Assuming wait_for_result blocks fully without timeout
• Expecting only one 'Working...' print
• Thinking wait_for_result with timeout causes error

4. You wrote this ROS action client code but it never prints the result:

client.send_goal(goal_msg)
client.wait_for_result()
print('Result:', client.get_result())

What is a likely reason for this behavior?

medium

A. The client must call send_goal repeatedly

B. The action server is not running or not responding

C. wait_for_result() requires a timeout argument

D. get_result() must be called before wait_for_result()

Solution

1. Step 1: Understand wait_for_result behavior

   wait_for_result() blocks until the server sends a result or the server is unavailable.

2. Step 2: Identify why it never prints

   If the action server is not running or not responding, wait_for_result() blocks forever, so print never executes.

3. Final Answer:

   The action server is not running or not responding -> Option B

4. Quick Check:

   Server missing causes wait block = B [OK]

Hint: No server = wait_for_result blocks forever [OK]

Common Mistakes:

• Thinking send_goal needs repeating
• Believing wait_for_result needs timeout
• Calling get_result too early

5. You want to implement a ROS action for a robot that cleans a room. The cleaning can be paused or stopped anytime, and you want to show progress updates. Which approach best uses ROS actions for this long-running task?

hard

A. Define an action with a goal to start cleaning, send periodic feedback with percent done, and allow preemption to pause or stop

B. Use a service call that blocks until cleaning finishes, then returns success

C. Publish a topic with cleaning commands and ignore feedback

D. Use a timer to run cleaning steps without feedback or control

Solution

1. Step 1: Identify requirements for the cleaning task

   The task is long-running, needs progress updates, and must support pause/stop (preemption).

2. Step 2: Match ROS communication types to requirements

   Actions support goals, feedback, and preemption, making them ideal for this use case. Services block and lack feedback, topics alone don't handle goals or preemption well.

3. Final Answer:

   Define an action with a goal to start cleaning, send periodic feedback with percent done, and allow preemption to pause or stop -> Option A

4. Quick Check:

   Actions fit long tasks with feedback and control = A [OK]

Hint: Use actions for control, feedback, and preemption [OK]

Common Mistakes:

• Using services for long tasks needing feedback
• Ignoring feedback and control with topics
• Not supporting preemption in design