Why actions for long-running tasks in ROS - Visual Breakdown

Concept Flow - Why actions for long-running tasks

Start long task request

↓

Send goal to action server

↓

Action server processes task

↓

Periodically send feedback

↓

Client receives feedback

↓

Task completes

↓

Action server sends result

↓

Client receives result and finishes

This flow shows how ROS actions handle long tasks by sending goals, providing feedback during processing, and returning results when done.

Execution Sample

ROS

goal_handle = action_client.send_goal(goal)
while not goal_handle.is_done():
    feedback = goal_handle.get_feedback()
    print(feedback)
result = goal_handle.get_result()

This code sends a goal to an action server, receives feedback while the task runs, and gets the final result when done.

Execution Table

Step	Action	Client State	Server State	Output/Feedback
1	Send goal to server	Goal sent, waiting	Goal received, processing started	No feedback yet
2	Server processes task	Waiting for feedback	Task running	No feedback yet
3	Server sends feedback	Feedback received	Task running	Progress 10%
4	Client processes feedback	Waiting for completion	Task running	Progress 10% displayed
5	Server sends feedback	Feedback received	Task running	Progress 50%
6	Client processes feedback	Waiting for completion	Task running	Progress 50% displayed
7	Server completes task	Waiting for result	Task done	No new feedback
8	Server sends result	Result received	Idle	Result data received
9	Client processes result	Task finished	Idle	Final result output

💡 Task completes and client receives final result, ending the action.

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	After Step 8	Final
goal_handle.state	None	Goal sent	Feedback received	Feedback received	Result received	Task finished
feedback.progress	None	None	10%	50%	None	None
result	None	None	None	None	Result data	Result data

Key Moments - 3 Insights

Why does the client receive feedback before the task finishes?

Because the action server sends periodic feedback during the long task (see steps 3 and 5 in execution_table), so the client knows the task is progressing.

What happens if the client waits only for the final result without feedback?

The client would appear unresponsive during the long task since it wouldn't get updates until the end, making feedback important for user experience (refer to execution_table steps 3 and 5).

Why can't we use simple service calls for long-running tasks?

Service calls block until completion and don't provide feedback, so actions are better because they allow feedback and can be preempted (see overall concept_flow).

Visual Quiz - 3 Questions

Look at the execution_table, what is the client state at step 5?

A Waiting for completion

B Goal sent, waiting

C Task finished

D Result received

💡 Hint

Check the 'Client State' column at step 5 in the execution_table.

At which step does the server complete the task?

A Step 3

B Step 7

C Step 5

D Step 9

💡 Hint

Look for 'Task done' in the 'Server State' column in execution_table.

If the server never sends feedback, how would the client state change at step 3?

A Client would receive feedback anyway

B Client would be 'Task finished'

C Client would be 'Goal sent, waiting'

D Client would still be 'Waiting for feedback'

💡 Hint

Refer to variable_tracker and execution_table feedback steps to see client state changes.

Concept Snapshot

ROS actions handle long tasks by sending a goal to an action server.
The server processes the task and sends periodic feedback.
The client receives feedback to stay informed.
When done, the server sends the final result.
This avoids blocking and improves responsiveness.

Full Transcript

In ROS, long-running tasks use actions to avoid blocking the client. The client sends a goal to the action server, which starts processing. While working, the server sends feedback messages to update the client on progress. The client can display this feedback to users, so they know the task is ongoing. When the task finishes, the server sends a result message. This flow keeps the client responsive and informed, unlike simple service calls that block until done. The execution table shows each step: sending the goal, receiving feedback, and finally getting the result. Variables like goal_handle.state and feedback.progress change over time to reflect the current status. Understanding this flow helps beginners see why actions are essential for long tasks in ROS.

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