Action server implementation in ROS - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to import the ROS action server library.

ROS

from actionlib import [1]

Drag options to blanks, or click blank then click option'

AActionClient

BSimpleActionServer

CPublisher

DSubscriber

Attempts:

3 left

💡 Hint

Common Mistakes

Using ActionClient instead of SimpleActionServer

Importing Publisher or Subscriber which are unrelated

The SimpleActionServer class is used to create an action server in ROS.

2fill in blank

medium

Complete the code to initialize the ROS node for the action server.

ROS

import rospy
rospy.[1]('my_action_server')

Drag options to blanks, or click blank then click option'

Ainit_node

BPublisher

CSubscriber

Dspin

Attempts:

3 left

💡 Hint

Common Mistakes

Using spin instead of init_node

Trying to use Publisher or Subscriber here

The init_node function initializes a ROS node with the given name.

3fill in blank

hard

Fix the error in the action server callback function definition.

ROS

def execute_cb([1]):
    rospy.loginfo('Executing action')

Drag options to blanks, or click blank then click option'

Aself

Bmsg

Cdata

Dgoal

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'self' which is for class methods

Using 'msg' or 'data' which are generic names

The callback function for the action server receives the goal as its argument.

4fill in blank

hard

Fill both blanks to create the action server instance and start it.

ROS

server = SimpleActionServer('[1]', MyAction, execute_cb=[2], auto_start=False)
server.start()

Drag options to blanks, or click blank then click option'

Amy_action

Bexecute_cb

Cstart_cb

Dgoal_cb

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong callback function names like 'start_cb' or 'goal_cb'

Using incorrect action name strings

The first blank is the action name string. The second blank is the callback function name.

5fill in blank

hard

Fill all three blanks to send a success result from the action server.

ROS

result = MyActionResult()
result.[1] = True
server.[2](result)
rospy.loginfo('[3]')

Drag options to blanks, or click blank then click option'

Asuccess

Bset_succeeded

CAction succeeded

Dset_aborted

Attempts:

3 left

💡 Hint

Common Mistakes

Using set_aborted instead of set_succeeded

Not setting the success field

Logging incorrect messages

The result's success field is set to True, then set_succeeded sends the result, and a log message confirms success.

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