Why actions for long-running tasks in ROS - See It in Action

Why Actions for Long-Running Tasks in ROS

📖 Scenario: You are building a robot that needs to perform tasks that take time, like moving to a location or picking up an object. These tasks can take several seconds or more, and you want your robot to stay responsive during these tasks.

🎯 Goal: Learn why ROS uses actions for long-running tasks and how to set up a simple action client to handle such tasks efficiently.

📋 What You'll Learn

Create a simple action definition for a long-running task

Set up a variable to hold the action goal timeout

Write the core logic to send a goal and handle feedback

Complete the action client setup with proper callbacks

💡 Why This Matters

🌍 Real World

Robots often need to do tasks like moving or picking objects that take time. Using actions lets them keep working on other things while waiting.

💼 Career

Understanding ROS actions is important for robotics developers to build efficient and responsive robot software.

1

Create an action definition for a long-running task

Create a file named MoveRobot.action with these exact lines:
float32 target_x
float32 target_y
---
bool success
---
float32 current_x
float32 current_y

ROS

# Create the MoveRobot.action file with the exact content
# Your code here

Hint

This file defines the goal, result, and feedback parts of the action.

2

Set a timeout variable for the action goal

In your action client code, create a variable called goal_timeout and set it to rospy.Duration(5.0).

ROS

goal_timeout = rospy.Duration(5.0)
# Your code here

Hint

This timeout helps the client know when to stop waiting for the action to finish.

3

Send a goal and handle feedback in the action client

Write code to send a goal with target_x = 10.0 and target_y = 5.0 using the action client variable client. Use a callback function named feedback_cb to handle feedback.

ROS

# Send goal with target_x=10.0 and target_y=5.0 using client
# Use feedback_cb as feedback callback
# Your code here

Hint

Use the send_goal method with the goal and feedback callback.

4

Complete the action client with done callback and wait for result

Add a done callback function named done_cb to handle the action result. Then call client.wait_for_result(timeout=goal_timeout) to wait for the action to finish.

ROS

# Add done_cb callback and wait for result with timeout
# Your code here

Hint

This ensures the client knows when the action is done and can handle the result properly.

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