Why actions for long-running tasks in ROS - Performance Evidence

Performance: Why actions for long-running tasks

HIGH IMPACT

This concept affects the responsiveness and smoothness of robot control interfaces during long-running operations.

Handling a long-running robot task without freezing the interface

ROS

import actionlib
from your_package.msg import LongTaskAction, LongTaskGoal

def execute_long_task_action():
    client = actionlib.SimpleActionClient('long_task', LongTaskAction)
    client.wait_for_server()
    goal = LongTaskGoal()
    client.send_goal(goal)
    # Non-blocking, can handle feedback and preemption
    client.wait_for_result()
    return client.get_result()

Uses ROS actions to run task asynchronously, keeping UI responsive and allowing feedback.

📈 Performance GainNo blocking of main thread; input responsiveness maintained; better user experience.

Handling a long-running robot task without freezing the interface

ROS

def execute_long_task():
    # Blocking call
    result = do_heavy_computation()
    return result

# Called directly in main thread
execute_long_task()

This blocks the main thread, freezing the interface until the task finishes.

📉 Performance CostBlocks rendering and input handling for entire task duration, causing poor INP.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Blocking long task in main thread	N/A	Blocks input events	Blocks UI updates	[X] Bad
Using ROS actions for long tasks	N/A	No blocking	Smooth UI updates	[OK] Good

Rendering Pipeline

Long-running tasks block the main thread, delaying input processing and UI updates. Using actions delegates work to separate threads or nodes, allowing the main thread to continue rendering and responding.

→Input Handling

→Task Execution

→UI Update

⚠️ BottleneckMain thread blocking during task execution

Core Web Vital Affected

INP

This concept affects the responsiveness and smoothness of robot control interfaces during long-running operations.

Optimization Tips

1Never run long tasks directly in the main thread to avoid freezing the UI.

2Use ROS actions to run long tasks asynchronously with feedback support.

3Keep the main thread free to maintain good input responsiveness (INP).

Performance Quiz - 3 Questions

What is the main performance problem when running long tasks directly in the main thread?

A It increases bundle size significantly.

B It blocks input handling and UI updates, causing poor responsiveness.

C It causes layout shifts on the page.

D It reduces network bandwidth.

DevTools: Performance

How to check: Record a performance profile while triggering the long task. Look for long tasks blocking the main thread and delayed input events.

What to look for: Long tasks over 50ms blocking main thread indicate poor responsiveness; absence means good async handling.

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