Preempting actions in ROS - Step-by-Step Execution

Concept Flow - Preempting actions

Action Client sends goal

↓

Action Server starts processing

↓

Client sends preempt request

↓

Server receives preempt

↓

Server stops current goal

↓

Server sends preempted result

↓

Client receives preempted status

The client sends a goal, then can send a preempt request to stop it. The server stops processing and reports the goal as preempted.

Execution Sample

ROS

client.send_goal(goal)
# After some time
client.cancel_goal()

Client sends a goal to the server, then later cancels it to preempt the action.

Execution Table

Step	Event	Client State	Server State	Action
1	Client sends goal	Goal sent, waiting for result	Goal received, processing started	Server starts working on goal
2	Server processing goal	Waiting for result	Working on goal	Server executing goal
3	Client sends cancel (preempt)	Cancel request sent	Received cancel request	Server prepares to stop goal
4	Server stops goal	Waiting for preempt confirmation	Goal stopped, preempted	Server sends preempted result
5	Client receives preempted	Goal marked preempted	Idle	Client handles preempted status
6	No further action	Idle	Idle	Action cycle complete

💡 Action preempted by client cancel, server stopped goal and sent preempted result

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	Final
client_goal_status	None	Sent	Cancel Requested	Preempted	Preempted
server_goal_status	Idle	Processing	Cancel Received	Preempted	Idle

Key Moments - 2 Insights

Why does the server stop processing after receiving a cancel request?

Because the cancel request signals the client wants to stop the current goal, so the server must preempt and stop work as shown in steps 3 and 4 of the execution_table.

What happens if the client never sends a cancel request?

The server continues processing the goal until completion or failure, never entering the preempted state as seen by the absence of steps 3 and 4 in the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the server state at Step 3?

A Received cancel request

B Processing goal

C Idle

D Goal stopped

💡 Hint

Check the 'Server State' column at Step 3 in the execution_table.

At which step does the client mark the goal as preempted?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look at the 'Client State' column in the execution_table to find when the goal is marked preempted.

If the client never sends a cancel request, which step would be missing?

A Step 1

B Step 3

C Step 5

D Step 6

💡 Hint

Step 3 shows the client sending a cancel request; without it, that step would not occur.

Concept Snapshot

Preempting actions in ROS means stopping a running goal early.
Client sends a goal to the server.
Client can send a cancel request to preempt.
Server stops processing and sends a preempted result.
Client receives preempted status and handles it.
This allows flexible control over long-running tasks.

Full Transcript

In ROS, preempting actions lets a client stop a goal it sent to an action server before completion. The client first sends a goal, and the server starts working on it. If the client decides to stop, it sends a cancel request. The server receives this and stops the current goal, marking it as preempted. Then the server sends a preempted result back to the client. The client receives this and knows the goal was stopped early. This process helps manage tasks that may need to be interrupted or replaced with new goals.

Practice

1.

What does cancel_goal() do in ROS action clients?

easy

A. It requests to stop the currently running action goal.

B. It starts a new action goal immediately.

C. It pauses the action without stopping it.

D. It resets the action server to its initial state.

Solution

1. Step 1: Understand the purpose of cancel_goal()

   This function is used to request the cancellation of the current goal being processed by the action server.

2. Step 2: Differentiate from other actions

   Starting a new goal or pausing are different operations; cancel_goal() specifically requests stopping the current goal.

3. Final Answer:

   It requests to stop the currently running action goal. -> Option A

4. Quick Check:

   cancel_goal() stops current goal [OK]

Hint: Remember: cancel_goal() means stop current action [OK]

Common Mistakes:

• Confusing cancel_goal() with starting a new goal
• Thinking cancel_goal() pauses instead of cancels
• Assuming cancel_goal() resets the server

2.

Which of the following is the correct sequence to preempt an action in ROS?

1. cancel_goal()
2. send_goal(new_goal)

easy

A. Call cancel_goal() first, then send_goal(new_goal).

B. Call send_goal(new_goal) first, then cancel_goal().

C. Call cancel_goal() twice, then send_goal(new_goal).

D. Only call send_goal(new_goal) without canceling.

Solution

1. Step 1: Understand preempting order

   You must first cancel the current goal to stop it before sending a new goal to replace it.

2. Step 2: Confirm correct method calls

   Calling cancel_goal() first ensures the old task stops, then send_goal(new_goal) starts the new task.

3. Final Answer:

   Call cancel_goal() first, then send_goal(new_goal). -> Option A

4. Quick Check:

   Cancel before sending new goal [OK]

Hint: Cancel first, then send new goal to preempt [OK]

Common Mistakes:

• Sending new goal before canceling old one
• Calling cancel_goal() multiple times unnecessarily
• Skipping cancel_goal() and sending new goal directly

3.

Given this ROS action client code snippet, what will be the output behavior?

client.send_goal(goal1)
client.cancel_goal()
client.send_goal(goal2)

What happens to goal1 and goal2?

medium

A. Neither goal runs because cancel_goal() stops all actions.

B. goal1 runs fully; goal2 is ignored.

C. Both goal1 and goal2 run simultaneously.

D. goal1 is canceled; goal2 starts running.

Solution

1. Step 1: Analyze the cancel_goal() effect

   After sending goal1, cancel_goal() requests to stop it immediately.

2. Step 2: Understand sending goal2

   Sending goal2 after canceling goal1 starts the new action goal.

3. Final Answer:

   goal1 is canceled; goal2 starts running. -> Option D

4. Quick Check:

   Cancel old goal, start new goal [OK]

Hint: Cancel stops old goal; new send_goal starts new task [OK]

Common Mistakes:

• Assuming goal1 runs fully despite cancel
• Thinking both goals run at once
• Believing cancel_goal() stops all future goals

4.

Identify the error in this ROS action client code snippet:

client.send_goal(goal1)
client.send_goal(goal2)
client.cancel_goal()

What is wrong with this sequence?

medium

A. The code should call cancel_goal() twice to cancel both goals.

B. You cannot send two goals without canceling the first one first.

C. Calling cancel_goal() after sending two goals does not preempt correctly.

D. There is no error; this sequence is correct.

Solution

1. Step 1: Understand goal handling

   Sending two goals in a row without canceling means the second goal overrides the first immediately.

2. Step 2: Analyze cancel_goal() timing

   Calling cancel_goal() after both sends only cancels the currently active goal, not preempting properly between goals.

3. Final Answer:

   Calling cancel_goal() after sending two goals does not preempt correctly. -> Option C

4. Quick Check:

   Cancel before sending new goal to preempt [OK]

Hint: Cancel before sending next goal, not after [OK]

Common Mistakes:

• Sending multiple goals without canceling first
• Assuming cancel_goal() cancels all previous goals
• Calling cancel_goal() too late to preempt

5.

You want to preempt a running action only if it has been active for more than 5 seconds. Which approach correctly implements this logic?

if client.get_state() == ACTIVE and client.get_time_active() > 5:
    client.cancel_goal()
    client.send_goal(new_goal)

hard

A. You must call cancel_goal() before checking the state.

B. This approach correctly preempts only after 5 seconds of activity.

C. You should send the new goal first, then cancel the old one.

D. ROS actions do not support checking active time for preemption.

Solution

1. Step 1: Check action state and duration

   The code checks if the action is active and has been running longer than 5 seconds.

2. Step 2: Cancel and send new goal conditionally

   Only if both conditions are true, it cancels the current goal and sends a new one, correctly preempting.

3. Final Answer:

   This approach correctly preempts only after 5 seconds of activity. -> Option B

4. Quick Check:

   Check state and time before canceling [OK]

Hint: Check active state and time before canceling [OK]

Common Mistakes:

• Canceling without checking active time
• Sending new goal before canceling old one
• Assuming ROS lacks timing info for actions