Why actions for long-running tasks in ROS - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a ROS action client that sends a goal.

ROS

client = actionlib.SimpleActionClient('move', [1])
client.wait_for_server()

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

AMoveAction

BMoveGoal

CMoveResult

DMoveFeedback

Attempts:

3 left

💡 Hint

Common Mistakes

Using MoveGoal instead of MoveAction causes errors because the client expects the full action type.

Confusing feedback or result types with the action type.

The client needs the action type, which is MoveAction, to communicate properly with the server.

2fill in blank

medium

Complete the code to send a goal and wait for the result.

ROS

goal = [1]()
goal.target_pose = pose
client.send_goal(goal)
client.wait_for_result()

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

AMoveGoal

BMoveAction

CMoveFeedback

DMoveResult

Attempts:

3 left

💡 Hint

Common Mistakes

Using MoveAction instead of MoveGoal when sending a goal.

Trying to send feedback or result objects as goals.

To send a goal, you create an instance of MoveGoal and fill its fields.

3fill in blank

hard

Fix the error in the server callback to handle preemption properly.

ROS

def execute_cb(self, goal):
    if self.server.is_preempt_requested():
        self.server.[1]()
        return
    # perform long task

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

Aset_aborted

Bset_succeeded

Cset_preempted

Dset_result

Attempts:

3 left

💡 Hint

Common Mistakes

Calling set_succeeded or set_aborted instead of set_preempted on preemption.

Not returning after handling preemption.

When a preempt request is detected, the server must call set_preempted() to stop the goal cleanly.

4fill in blank

hard

Fill both blanks to publish feedback and set the result after task completion.

ROS

feedback = [1]()
feedback.progress = 50
self.server.publish_feedback(feedback)
result = [2]()
result.success = True
self.server.set_succeeded(result)

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

AMoveFeedback

BMoveResult

CMoveGoal

DMoveAction

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up feedback and result message types.

Using goal or action types instead of feedback or result.

Feedback uses MoveFeedback and the final result uses MoveResult.

5fill in blank

hard

Fill all three blanks to create a ROS action server with proper initialization and start.

ROS

self.server = actionlib.SimpleActionServer('[1]', [2], execute_cb=self.execute_cb, auto_start=[3])
self.server.start()

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

Amove

BMoveAction

CFalse

DTrue

Attempts:

3 left

💡 Hint

Common Mistakes

Using True for auto_start causes the server to start before setup.

Confusing action name with action type.

Omitting the execute callback.

The server needs the action name 'move', the action type MoveAction, and auto_start=False to initialize properly before starting.

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