Why Action client with feedback in ROS? - Purpose & Use Cases

The Big Idea

What if you could watch your robot's progress live instead of guessing?

The Scenario

Imagine you send a robot a command to move to a location, but you have no idea if it's making progress or stuck somewhere.

The Problem

Without feedback, you can't tell if the robot is working or frozen. You might wait forever or send conflicting commands, causing confusion and errors.

The Solution

Using an action client with feedback lets you receive updates from the robot as it works, so you know exactly what's happening in real time.

Before vs After

✗ Before

send_goal(goal)
# no updates, just wait

✓ After

send_goal(goal, feedback_cb=show_progress)
# get live progress updates

What It Enables

This lets you build smart systems that react to progress, handle delays gracefully, and improve user trust with live status.

Real Life Example

Think of a delivery robot that tells you it's halfway to your door, so you can be ready to receive the package.

Key Takeaways

Manual commands give no progress info, causing uncertainty.

Action clients with feedback provide live updates during tasks.

This improves control, reliability, and user experience.

Practice

1. What is the main purpose of an action client in ROS when using feedback?

easy

A. To directly control robot hardware without feedback

B. To send goals to an action server and receive progress updates

C. To replace service calls with simpler requests

D. To only receive the final result without intermediate updates

Solution

1. Step 1: Understand the role of an action client

   An action client sends goals to an action server and can receive feedback during execution.

2. Step 2: Identify feedback purpose

   Feedback callbacks provide real-time progress updates while the task runs.

3. Final Answer:

   To send goals to an action server and receive progress updates -> Option B

4. Quick Check:

   Action client = send goals + get feedback [OK]

Hint: Action clients send goals and get feedback updates [OK]

Common Mistakes:

• Thinking action clients only get final results
• Confusing action clients with service clients
• Ignoring feedback callbacks

2. Which of the following is the correct way to create an action client with feedback in ROS Python?

easy

A. client = actionlib.SimpleActionClient('move', MoveAction, feedback_cb=feedback_cb)

B. client = actionlib.ActionClient('move', MoveAction, feedback_cb=feedback_cb)

C. client = actionlib.SimpleActionClient('move', MoveAction)

D. client = actionlib.ActionClient('move', MoveAction)

Solution

1. Step 1: Recall ROS Python action client syntax

   The standard way is to use SimpleActionClient with server name and action type.

2. Step 2: Feedback callback is set separately

   Feedback callbacks are registered when sending goals, not in constructor.

3. Final Answer:

   client = actionlib.SimpleActionClient('move', MoveAction) -> Option C

4. Quick Check:

   SimpleActionClient + feedback_cb separate [OK]

Hint: Feedback callback is passed when sending goal, not client creation [OK]

Common Mistakes:

• Passing feedback_cb in constructor (wrong)
• Using ActionClient instead of SimpleActionClient
• Missing action type argument

3. Given this ROS Python snippet, what will be printed if the feedback callback receives progress=50?

def feedback_cb(feedback):
    print(f"Progress: {feedback.progress}%")

client = actionlib.SimpleActionClient('task', TaskAction)
client.wait_for_server()
goal = TaskGoal()
client.send_goal(goal, feedback_cb=feedback_cb)

medium

A. Progress: 50%

B. Progress: feedback.progress%

C. Progress: None%

D. No output because feedback_cb is not called

Solution

1. Step 1: Understand feedback callback behavior

   The feedback_cb prints the progress attribute from feedback with formatting.

2. Step 2: Substitute progress value

   If feedback.progress is 50, the print outputs "Progress: 50%" exactly.

3. Final Answer:

   Progress: 50% -> Option A

4. Quick Check:

   Formatted string with feedback.progress = output [OK]

Hint: Feedback callback prints formatted progress value [OK]

Common Mistakes:

• Printing variable name instead of value
• Assuming feedback_cb is not called
• Ignoring string formatting

4. What is wrong with this ROS Python action client code snippet?

client = actionlib.SimpleActionClient('task', TaskAction)
client.send_goal(TaskGoal(), feedback_cb=feedback_cb)
client.wait_for_server()

medium

A. wait_for_server() should be called before send_goal()

B. feedback_cb cannot be passed to send_goal()

C. TaskGoal() must be assigned to a variable before sending

D. SimpleActionClient requires a third argument for feedback

Solution

1. Step 1: Check action client usage order

   wait_for_server() must be called before sending a goal to ensure server is ready.

2. Step 2: Identify error in code order

   Here, send_goal() is called before wait_for_server(), which is incorrect.

3. Final Answer:

   wait_for_server() should be called before send_goal() -> Option A

4. Quick Check:

   wait_for_server() before send_goal() [OK]

Hint: Always wait for server before sending goal [OK]

Common Mistakes:

• Calling send_goal before wait_for_server
• Misunderstanding feedback_cb usage
• Assuming feedback_cb is constructor argument

5. You want to implement an action client that sends multiple goals sequentially and prints feedback for each. Which approach correctly handles feedback for each goal without mixing updates?

hard

A. Ignore feedback and only wait for final results of each goal

B. Use a single global feedback callback for all goals without distinguishing them

C. Send all goals at once without waiting and use one feedback callback

D. Create a new feedback callback function for each goal that captures its goal ID

Solution

1. Step 1: Understand feedback handling for multiple goals

   Each goal's feedback should be handled separately to avoid mixing progress updates.

2. Step 2: Use closures or separate callbacks

   Creating a unique feedback callback per goal that captures its ID ensures correct feedback association.

3. Final Answer:

   Create a new feedback callback function for each goal that captures its goal ID -> Option D

4. Quick Check:

   Separate feedback callbacks per goal prevent mix-up [OK]

Hint: Use unique feedback callbacks per goal to track progress separately [OK]

Common Mistakes:

• Using one callback for all goals causing mixed feedback
• Sending all goals simultaneously without control
• Ignoring feedback defeats purpose of action client