Action client with feedback in ROS - Performance & Optimization

Performance: Action client with feedback

MEDIUM IMPACT

This concept affects the responsiveness and smoothness of user interactions by managing how feedback messages are processed and rendered during action execution.

Handling feedback messages in a ROS action client

ROS

import threading

def feedback_cb(feedback):
    threading.Thread(target=process_feedback, args=(feedback,)).start()

client.send_goal(goal, feedback_cb=feedback_cb)

# Feedback callback quickly delegates work to a separate thread

Delegating heavy processing off the main feedback callback keeps feedback handling fast and responsive.

📈 Performance GainNon-blocking feedback processing improves interaction responsiveness (INP)

Handling feedback messages in a ROS action client

ROS

def feedback_cb(feedback):
    print(f"Feedback received: {feedback.progress}")

client.send_goal(goal, feedback_cb=feedback_cb)

# Feedback callback does heavy processing or blocking operations

Performing heavy or blocking operations inside the feedback callback delays processing of subsequent feedback and user interactions.

📉 Performance CostBlocks feedback processing causing input lag and delayed UI updates

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Blocking feedback callback	N/A	N/A	Delays UI update	[X] Bad
Non-blocking feedback callback with threading	N/A	N/A	Smooth UI update	[OK] Good

Rendering Pipeline

Feedback messages trigger callbacks that update UI or logs. If these callbacks block, they delay the event loop and UI updates, causing slower interaction response.

→Event Handling

→UI Update

→Callback Execution

⚠️ BottleneckCallback Execution when heavy processing blocks event loop

Core Web Vital Affected

INP

This concept affects the responsiveness and smoothness of user interactions by managing how feedback messages are processed and rendered during action execution.

Optimization Tips

1Keep feedback callbacks lightweight to avoid blocking event handling.

2Use threads or async methods to process feedback without delaying UI updates.

3Monitor feedback handling performance to maintain smooth user interactions.

Performance Quiz - 3 Questions

What is the main performance risk of doing heavy processing directly inside a ROS action client's feedback callback?

A It blocks feedback processing and delays UI responsiveness

B It increases network bandwidth usage

C It causes memory leaks

D It improves feedback accuracy

DevTools: Performance

How to check: Record a performance profile while the action client receives feedback. Look for long tasks or blocking callbacks in the timeline.

What to look for: Check for gaps or delays in event handling and UI updates indicating blocking feedback processing.

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