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

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use ROS actions instead of services for long tasks?

In ROS, why are actions preferred over services for tasks that take a long time to complete?

A Actions allow feedback and can be preempted, while services block until completion without feedback.

B Services provide feedback during execution, but actions do not support preemption.

C Actions are synchronous calls that block the client, while services run asynchronously.

D Services are designed for long-running tasks with progress updates, actions are for quick commands.

💡 Hint

Think about how you would want to know progress or stop a task that takes a long time.

Actions in ROS are designed for long-running tasks because they allow the client to receive feedback during execution and can be preempted (stopped) if needed. Services, on the other hand, are blocking calls that wait until the task finishes and do not provide feedback or allow interruption.

❓ component_behavior

intermediate

What happens if a ROS service is called for a long task?

If a ROS service is called to perform a task that takes several minutes, what will the client experience?

A The client will block and wait until the service finishes, with no updates during execution.

B The client will receive continuous feedback messages about progress.

C The client can cancel the service call anytime during execution.

D The client will run asynchronously and continue without waiting.

💡 Hint

Think about how services handle requests and responses.

ROS services are synchronous and blocking. When a client calls a service, it waits until the service completes and returns a response. There is no built-in way to get progress updates or cancel the call.

❓ lifecycle

advanced

How does ROS action server handle preemption during a long task?

During a long-running action in ROS, what happens when the client requests preemption (cancellation)?

A The action server crashes because preemption is not supported.

B The action server ignores the preemption request and continues until completion.

C The action server restarts the task from the beginning automatically.

D The action server stops the task and sends a result indicating it was preempted.

💡 Hint

Consider how actions allow clients to stop tasks cleanly.

ROS action servers support preemption, allowing clients to cancel ongoing tasks. When preempted, the server stops the task and sends a result message indicating the task was preempted.

📝 Syntax

advanced

Identify the correct ROS action client usage for feedback handling

Which code snippet correctly sets up a ROS action client to receive feedback during a long task?

A client.call_service(goal, feedback=feedback_callback)

B client.send_goal(goal, feedback=feedback_callback)

C client.send_goal(goal, feedback_cb=feedback_callback)

D client.call_action(goal, feedback_cb=feedback_callback)

💡 Hint

Look for the correct method name and parameter for feedback callback.

In ROS, the action client uses send_goal method with a feedback_cb parameter to register a feedback callback function. Other options use incorrect method names or parameter names.

🔧 Debug

expert

Why does a ROS action client never receive feedback?

A ROS action client sends a goal to the server but never receives feedback updates during the task. What is the most likely cause?

A The feedback callback function is defined but never registered with send_goal.

B The action server does not publish feedback messages during execution.

C The client did not call send_goal and is waiting on a service instead.

D The action client is using a service client instead of an action client.

💡 Hint

Check if the server is sending feedback messages properly.

If the action server does not publish feedback messages during the task, the client will not receive any feedback even if the callback is set up correctly. Other options describe client-side mistakes that would cause different symptoms.

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