Action server implementation in ROS - Step-by-Step Execution

Concept Flow - Action server implementation

Start Action Server

↓

Wait for Goal

↓

Receive Goal

↓

Process Goal

↓

Publish Feedback

↓

Check if Goal Complete

↓

Set Result

↓

Send Result

↓

Wait for Next Goal

The action server waits for a goal, processes it while sending feedback, then sends the result and waits for the next goal.

Execution Sample

ROS

def execute_callback(goal):
    goal_complete = False
    while not goal_complete:
        publish_feedback()
        # process goal here and update goal_complete accordingly
    set_result()
    send_result()

This code runs the action server callback, sending feedback repeatedly until the goal is done, then sends the final result.

Execution Table

Step	Action	Goal State	Feedback Sent	Result Sent
1	Start Action Server	Waiting	No	No
2	Receive Goal	Processing	No	No
3	Publish Feedback	Processing	Yes	No
4	Publish Feedback	Processing	Yes	No
5	Check if Goal Complete	Processing	Yes	No
6	Goal Complete Detected	Complete	Yes	No
7	Set Result	Complete	Yes	No
8	Send Result	Complete	Yes	Yes
9	Wait for Next Goal	Waiting	No	No

💡 Goal completed and result sent, server waits for next goal.

Variable Tracker

Variable	Start	After Step 2	After Step 6	After Step 8	Final
goal_state	Waiting	Processing	Complete	Complete	Waiting
feedback_sent	No	No	Yes	Yes	No
result_sent	No	No	No	Yes	No

Key Moments - 3 Insights

Why does the server send feedback multiple times before sending the result?

Because the goal is still being processed (see steps 3,4,5 in execution_table), feedback updates keep the client informed until completion.

What happens if the goal never completes?

The server keeps publishing feedback and does not send a result, staying in the processing state (refer to steps 3-5).

When does the server become ready for a new goal?

After sending the result (step 8), the server resets to waiting state (step 9) to accept new goals.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the goal state set to 'Complete'?

A Step 2

B Step 4

C Step 6

D Step 9

💡 Hint

Check the 'Goal State' column in the execution_table rows.

At which step does the server send the final result to the client?

A Step 8

B Step 3

C Step 5

D Step 2

💡 Hint

Look at the 'Result Sent' column in the execution_table.

If the server never detects goal completion, what happens to 'result_sent' in variable_tracker?

A It changes to 'Yes' immediately

B It stays 'No' forever

C It toggles between 'Yes' and 'No'

D It becomes 'Yes' after feedback

💡 Hint

Refer to variable_tracker and key_moments about goal completion.

Concept Snapshot

Action Server Implementation:
- Start server and wait for goals
- On goal receive, process and send feedback repeatedly
- When goal completes, set and send result
- Return to waiting for next goal
- Keeps client informed during processing with feedback

Full Transcript

An action server in ROS starts by waiting for a goal from a client. When a goal arrives, it processes the goal and sends feedback messages repeatedly to keep the client updated. Once the goal is complete, the server sets the result and sends it back to the client. After sending the result, the server waits for the next goal. This cycle repeats for every new goal. Feedback is sent multiple times during processing to inform the client about progress. The server only sends the final result after the goal is complete, then resets to accept new goals.

Practice

1. What is the main role of an action server in ROS?

easy

A. To handle long-running tasks and provide feedback during execution

B. To send simple messages without feedback

C. To only receive goals without processing them

D. To replace the ROS parameter server

Solution

1. Step 1: Understand the purpose of an action server

   An action server is designed to manage tasks that take time and can provide updates while working.

2. Step 2: Compare options with the role

   Only To handle long-running tasks and provide feedback during execution correctly describes handling long tasks and sending feedback, unlike others which describe unrelated roles.

3. Final Answer:

   To handle long-running tasks and provide feedback during execution -> Option A

4. Quick Check:

   Action server = long tasks + feedback [OK]

Hint: Remember: action servers manage long tasks with feedback [OK]

Common Mistakes:

• Confusing action server with simple message publishers
• Thinking action server only receives goals without processing
• Mixing action server with parameter server functionality

2. Which of the following is the correct way to define the execute callback function in a ROS action server using Python?

easy

A. def execute(goal, self):

B. def executeCallback(goal):

C. def callback_execute(goal, self):

D. def execute_callback(self, goal):

Solution

1. Step 1: Recall the standard signature for execute callback

   In ROS Python action servers, the execute callback is a method with 'self' and 'goal' parameters.

2. Step 2: Match options to this signature

   Only def execute_callback(self, goal): correctly uses 'def execute_callback(self, goal):' matching the expected pattern.

3. Final Answer:

   def execute_callback(self, goal): -> Option D

4. Quick Check:

   Method signature = self first, then goal [OK]

Hint: Method callbacks in classes always have self first [OK]

Common Mistakes:

• Omitting 'self' parameter in method definition
• Swapping parameter order incorrectly
• Using camelCase instead of snake_case for method name

3. Given this snippet inside an action server's execute callback:

for i in range(3):
    feedback.percent_complete = (i + 1) * 33
    self._action_server.publish_feedback(feedback)
    rospy.sleep(1)
result.success = True
self._action_server.set_succeeded(result)

What will the client receive?

medium

A. No feedback updates, only success result

B. Three feedback updates at 33%, 66%, and 99%, then success result

C. Only one feedback update at 99%, then success result

D. Feedback updates but the result will be failure

Solution

1. Step 1: Analyze the loop sending feedback

   The loop runs 3 times, each time publishing feedback with percent_complete increasing by 33.

2. Step 2: Check the result setting after loop

   After feedback, the result.success is set to True and the goal is marked succeeded.

3. Final Answer:

   Three feedback updates at 33%, 66%, and 99%, then success result -> Option B

4. Quick Check:

   Loop feedback + success result = Three feedback updates at 33%, 66%, and 99%, then success result [OK]

Hint: Loop sends multiple feedbacks before final success [OK]

Common Mistakes:

• Assuming feedback is sent only once after loop
• Confusing success with failure result
• Ignoring the sleep delay between feedbacks

4. Identify the error in this action server execute callback snippet:

def execute_callback(self, goal):
    if goal.order < 0:
        self._action_server.set_aborted()
    result = Result()
    result.output = goal.order * 2
    self._action_server.set_succeeded(result)

medium

A. set_aborted() is called without a result argument

B. Result() is not imported or defined

C. The goal attribute 'order' does not exist

D. set_succeeded() should be called before set_aborted()

Solution

1. Step 1: Check set_aborted() usage

   set_aborted() requires a result argument to inform the client about failure details.

2. Step 2: Verify other parts

   Result() usage is typical; goal.order is assumed valid; set_succeeded() after set_aborted() is not called sequentially here.

3. Final Answer:

   set_aborted() is called without a result argument -> Option A

4. Quick Check:

   set_aborted needs result argument [OK]

Hint: Always pass a result when aborting goals [OK]

Common Mistakes:

• Calling set_aborted() without result causes runtime error
• Assuming set_aborted() can be called without parameters
• Ignoring the need to inform client on abort

5. You want to implement an action server that cancels the goal if a certain condition is met during execution. Which approach correctly handles goal cancellation in the execute callback?

hard

A. Call set_aborted() immediately when the goal is received without checking cancellation

B. Ignore cancellation requests and always call set_succeeded() at the end

C. Check self._action_server.is_preempt_requested() inside the loop, then call self._action_server.set_preempted() and return

D. Use rospy.sleep() to delay cancellation handling until after completion

Solution

1. Step 1: Understand cancellation handling in action servers

   Cancellation requests are detected by checking is_preempt_requested() during execution.

2. Step 2: Proper response to cancellation

   When cancellation is requested, call set_preempted() to notify client and stop processing.

3. Final Answer:

   Check self._action_server.is_preempt_requested() inside the loop, then call self._action_server.set_preempted() and return -> Option C

4. Quick Check:

   Cancellation check + set_preempted = Check self._action_server.is_preempt_requested() inside the loop, then call self._action_server.set_preempted() and return [OK]

Hint: Use is_preempt_requested() to detect and handle cancellations [OK]

Common Mistakes:

• Ignoring cancellation requests during execution
• Calling set_aborted() instead of set_preempted() on cancel
• Delaying cancellation handling until after task finishes