Action client with feedback in ROS - Deep Dive

Overview - Action client with feedback

What is it?

An action client in ROS is a program that sends a goal to an action server and waits for the result. It can also receive ongoing feedback from the server while the goal is being processed. This feedback helps the client know the progress or status of the task before it finishes.

Why it matters

Without action clients and feedback, programs would have to wait blindly for long tasks to finish, making them unresponsive or inefficient. Feedback allows real-time updates, improving user experience and enabling smarter decision-making during task execution.

Where it fits

Before learning action clients with feedback, you should understand ROS nodes, topics, and services basics. After this, you can explore advanced action patterns, server-side implementations, and integrating actions with complex robot behaviors.

Mental Model

Core Idea

An action client sends a goal to a server and listens for progress updates until the task completes.

Think of it like...

It's like ordering a pizza and getting live updates from the restaurant about your pizza being prepared, baked, and out for delivery.

┌───────────────┐       send goal       ┌───────────────┐
│ Action Client │──────────────────────▶│ Action Server │
└───────────────┘                        └───────────────┘
       ▲                                      │
       │          receive feedback             │
       │◀─────────────────────────────────────┤
       │                                      │
       │          receive result               │
       │◀─────────────────────────────────────┤

Build-Up - 6 Steps

1

Foundation

Understanding ROS Actions Basics

Concept: Learn what ROS actions are and how they differ from topics and services.

ROS actions allow asynchronous communication where a client sends a goal to a server and can receive feedback and a final result. Unlike topics (continuous streams) or services (instant request-response), actions handle long-running tasks with progress updates.

Result

You understand that actions are designed for tasks that take time and need feedback.

Knowing the unique role of actions helps you choose the right communication method in ROS.

2

Foundation

Setting Up a Simple Action Client

Concept: Create a basic action client that sends a goal and waits for the result.

Write a ROS node that initializes an action client, sends a goal to the server, and blocks until the result arrives. This shows the basic request-response flow without feedback.

Result

The client successfully sends a goal and receives the final result from the server.

Understanding the basic client-server interaction is essential before adding feedback handling.

3

Intermediate

Adding Feedback Handling to Client

🤔Before reading on: do you think feedback is received automatically or requires explicit setup? Commit to your answer.

Concept: Learn how to receive and process feedback messages from the action server during goal execution.

Modify the action client to register a feedback callback function. This function runs whenever the server sends feedback, allowing the client to react or display progress updates.

Result

The client prints or processes feedback messages while waiting for the final result.

Knowing that feedback requires explicit callbacks helps you design responsive clients that stay informed.

4

Intermediate

Handling Goal States and Cancellations

🤔Before reading on: do you think the client can cancel a goal anytime or only before sending it? Commit to your answer.

Concept: Explore how the client can monitor goal states and cancel goals if needed.

Use the action client's state monitoring methods to check if the goal is active, succeeded, or aborted. Implement a cancellation request to stop the goal mid-execution.

Result

The client can stop a running goal and handle different goal states gracefully.

Understanding goal lifecycle and cancellation improves robustness and control in real applications.

5

Advanced

Managing Multiple Goals and Feedback

🤔Before reading on: do you think an action client can handle multiple goals simultaneously? Commit to your answer.

Concept: Learn how to handle sending multiple goals and processing their feedback independently.

Implement logic to send new goals before previous ones finish, track each goal's feedback and result separately, and manage concurrency or preemption.

Result

The client can manage several goals and their feedback streams without confusion.

Knowing how to handle multiple goals is key for complex robot tasks requiring multitasking.

6

Expert

Optimizing Feedback for Real-Time Systems

🤔Before reading on: do you think sending feedback too frequently is always better? Commit to your answer.

Concept: Understand the trade-offs in feedback frequency and how to optimize it for performance and usability.

Analyze how excessive feedback can overload communication channels or processing. Implement throttling or filtering strategies to send meaningful feedback at appropriate intervals.

Result

The system remains responsive without unnecessary overhead or delays.

Balancing feedback frequency is crucial for real-time robotic systems to maintain efficiency and clarity.

Under the Hood

The action client uses ROS communication protocols to send a goal message to the action server. The server processes the goal asynchronously and sends feedback messages periodically over a dedicated feedback topic. The client subscribes to this feedback topic and invokes callback functions when feedback arrives. When the server finishes, it sends a result message that the client receives to complete the action.

Why designed this way?

Actions were designed to handle long-running tasks that cannot be completed instantly. Unlike services, which block until done, actions allow continuous feedback and cancellation. This design improves responsiveness and control in robotic systems where tasks may take unpredictable time.

┌───────────────┐          ┌───────────────┐
│ Action Client │          │ Action Server │
├───────────────┤          ├───────────────┤
│ send goal ────┼─────────▶│               │
│               │          │ process goal  │
│ feedback ◀────┤─────────▶│ send feedback │
│               │          │               │
│ result ◀──────┤─────────▶│ send result   │
└───────────────┘          └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the action client automatically receive feedback without any setup? Commit to yes or no.

Common Belief: The client automatically gets feedback without extra code once the goal is sent.

Reality: The client must explicitly register a feedback callback to receive and handle feedback messages.

Why it matters: Without setting up feedback callbacks, the client misses progress updates, losing valuable real-time information.

Quick: Can an action client send multiple goals at the same time by default? Commit to yes or no.

Common Belief: Action clients can handle multiple goals simultaneously without extra management.

Reality: By default, action clients handle one goal at a time; managing multiple goals requires custom logic.

Why it matters: Assuming multiple goals work out-of-the-box can cause unexpected behavior or lost goals in complex systems.

Quick: Is sending feedback as often as possible always better? Commit to yes or no.

Common Belief: More frequent feedback always improves client responsiveness and user experience.

Reality: Too frequent feedback can overload communication channels and processing, causing delays or dropped messages.

Why it matters: Ignoring feedback frequency can degrade system performance and make feedback less useful.

Quick: Does cancelling a goal guarantee immediate stop of the server task? Commit to yes or no.

Common Belief: Cancelling a goal instantly stops the server's task execution.

Reality: Cancellation requests are cooperative; the server decides when and how to stop the task.

Why it matters: Expecting immediate cancellation can lead to incorrect assumptions about task state and client behavior.

Expert Zone

1

Feedback callbacks run asynchronously and must be thread-safe to avoid race conditions in the client.

2

The action client internally uses a state machine to track goal status, which can be queried for advanced control.

3

Preemption and goal replacement require careful synchronization to avoid conflicts between old and new goals.

When NOT to use

Avoid using action clients for very short or instantaneous tasks; services or topics are simpler and more efficient. For extremely high-frequency feedback, consider custom communication channels or shared memory to reduce overhead.

Production Patterns

In real robots, action clients often integrate with user interfaces to show progress bars, with safety monitors to cancel dangerous goals, and with behavior trees to sequence complex tasks using feedback to decide next steps.

Connections

Observer Pattern (Software Design)

Action client feedback callbacks implement an observer pattern where the client observes server progress.

Understanding observer pattern clarifies how feedback updates are pushed asynchronously to clients.

Event-Driven Programming

Action clients react to feedback events via callbacks, fitting the event-driven model.

Knowing event-driven concepts helps design responsive clients that handle asynchronous updates smoothly.

Project Management Progress Tracking

Receiving feedback during action execution is like tracking project milestones before completion.

This connection shows how incremental progress updates improve decision-making and resource allocation.

Common Pitfalls

#1 Not registering a feedback callback, so no progress updates are received.

Wrong approach:

client.send_goal(goal)
# No feedback callback registered
client.wait_for_result()

Correct approach:

client.send_goal(goal, feedback_cb=feedback_callback)
client.wait_for_result()

Root cause:

Misunderstanding that feedback requires explicit callback registration.

#2 Assuming goal cancellation immediately stops the server task.

Wrong approach:

client.cancel_goal()
# Assume task stops instantly without checking server state

Correct approach:

client.cancel_goal()
# Monitor server state to confirm cancellation completion

Root cause:

Not realizing cancellation is cooperative and server-dependent.

#3 Sending feedback too frequently, causing communication overload.

Wrong approach:

while task_running:
server.publish_feedback(progress)
# No delay or throttling

Correct approach:

while task_running:
if time_since_last_feedback > threshold:
server.publish_feedback(progress)
reset_timer()

Root cause:

Ignoring communication bandwidth and processing limits.

Key Takeaways

ROS action clients enable asynchronous task requests with real-time feedback and final results.

Feedback requires explicit callback setup to receive progress updates during task execution.

Clients can monitor goal states and cancel goals, but cancellation depends on server cooperation.

Managing multiple goals and feedback streams requires careful design to avoid conflicts.

Optimizing feedback frequency balances responsiveness with system performance in real-time robotics.

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