Action server implementation in ROS - Deep Dive

Overview - Action server implementation

What is it?

An action server in ROS is a program that performs long-running tasks and communicates progress and results back to clients. It allows clients to send goals, receive feedback during execution, and get the final result when the task completes. This setup helps manage complex operations that take time and may need to be preempted or canceled.

Why it matters

Without action servers, managing long tasks in robotics would be difficult and inefficient. Clients would have to wait or repeatedly check if a task is done, leading to poor responsiveness and resource use. Action servers enable smooth, asynchronous communication, improving robot control and user experience.

Where it fits

Before learning action servers, you should understand ROS nodes, topics, and services basics. After mastering action servers, you can explore advanced robot behaviors, multi-action coordination, and real-time system integration.

Mental Model

Core Idea

An action server is like a personal assistant that takes your task requests, works on them step-by-step, updates you on progress, and tells you when it's done or if it had to stop.

Think of it like...

Imagine asking a friend to bake a cake. They tell you when they start, update you while mixing and baking, and finally let you know when the cake is ready or if they had to stop because of missing ingredients.

┌───────────────┐       ┌───────────────┐
│   Action      │       │   Action      │
│   Client      │──────▶│   Server      │
│ (Sends Goal)  │       │ (Executes)    │
└───────────────┘       └───────────────┘
       ▲                       │
       │                       ▼
       │               ┌───────────────┐
       │               │ Feedback      │
       │◀──────────────│ (Progress)   │
       │               └───────────────┘
       │                       │
       │                       ▼
       │               ┌───────────────┐
       │               │ Result        │
       └──────────────▶│ (Outcome)     │
                       └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding ROS nodes and communication

Concept: Learn what ROS nodes are and how they communicate using topics and services.

ROS nodes are programs that perform computation. They communicate by sending messages over topics or by calling services for short tasks. Topics are like radio channels where nodes broadcast messages, and services are like phone calls for quick requests and responses.

Result

You can create simple ROS programs that send and receive messages or call services to perform tasks.

Understanding nodes and their communication methods is essential because action servers build on these concepts to handle more complex interactions.

2

Foundation

Basics of ROS services and their limits

Concept: Services allow request-response communication but are not suited for long tasks.

A service in ROS lets a client send a request and wait for a response. This works well for quick tasks but blocks the client while waiting. For longer tasks, this blocking is inefficient and can freeze the system.

Result

You know why services are not ideal for long-running operations and need a better solution.

Recognizing the limits of services motivates the need for action servers to handle asynchronous, long tasks.

3

Intermediate

Introducing action servers and clients

🤔Before reading on: do you think action servers block clients like services or allow asynchronous communication? Commit to your answer.

Concept: Action servers let clients send goals and continue working without waiting, receiving updates and results asynchronously.

An action server runs in its own node and listens for goals from clients. When a goal arrives, it starts processing and sends feedback messages to the client about progress. The client can also cancel the goal if needed. When done, the server sends the final result.

Result

You can see how action servers improve responsiveness by allowing clients to keep working while tasks run.

Understanding asynchronous communication is key to grasping how action servers enable smooth robot control.

4

Intermediate

Structure of an action server in ROS

🤔Before reading on: do you think an action server uses topics, services, or a new communication method? Commit to your answer.

Concept: Action servers use a combination of topics and services under the hood but provide a higher-level interface for goal management.

An action server uses three main communication channels: a goal topic to receive goals, a feedback topic to send progress updates, and a result topic to send the final outcome. It also handles goal preemption and cancellation requests.

Result

You understand the communication flow and how the server manages multiple goals and client interactions.

Knowing the internal channels helps debug and optimize action server behavior.

5

Intermediate

Implementing a simple ROS action server

🤔Before reading on: do you think the server code runs the task synchronously or uses callbacks? Commit to your answer.

Concept: Action servers use callbacks to handle goals and send feedback without blocking the main program.

In ROS, you create an action server by defining a callback function that starts when a goal arrives. Inside this function, you perform the task step-by-step, sending feedback messages periodically. When finished, you set the result and mark the goal as succeeded or aborted.

Result

You can write a working action server that handles goals and communicates progress and results.

Using callbacks allows the server to remain responsive and handle multiple goals efficiently.

6

Advanced

Handling goal preemption and cancellation

🤔Before reading on: do you think an action server automatically stops tasks on cancellation or requires explicit handling? Commit to your answer.

Concept: Action servers must explicitly check for cancellation requests and stop tasks gracefully.

When a client cancels a goal, the server receives a cancellation request. The server's callback should check for this and stop the ongoing task safely, then set the goal state to preempted. This prevents wasted work and keeps the system stable.

Result

You can implement robust action servers that respond correctly to cancellations and preemptions.

Knowing that cancellation is not automatic prevents bugs where tasks continue running despite client requests.

7

Expert

Optimizing action servers for concurrency and reliability

🤔Before reading on: do you think a single-threaded action server can handle multiple goals simultaneously? Commit to your answer.

Concept: Advanced action servers use multi-threading or asynchronous programming to handle multiple goals and improve reliability.

By default, action servers process goals sequentially. To handle multiple goals concurrently, you can use multi-threaded spinning or asynchronous callbacks. Additionally, implementing proper error handling and state management ensures the server remains stable under load and recovers from failures.

Result

You can build production-ready action servers that scale and handle complex robot behaviors.

Understanding concurrency and error management is crucial for deploying action servers in real-world robotics applications.

Under the Hood

An action server internally uses ROS communication primitives: it subscribes to a goal topic to receive new goals, publishes feedback and result messages on separate topics, and uses services to manage goal cancellation and status. The server maintains a goal state machine to track active, succeeded, preempted, or aborted goals. It processes callbacks triggered by incoming messages, allowing asynchronous execution without blocking the main thread.

Why designed this way?

ROS action servers were designed to overcome the limitations of services for long-running tasks. Using topics for streaming feedback and results allows asynchronous, non-blocking communication. The separation of goals, feedback, and results into different channels simplifies client-server interaction and improves scalability. Alternatives like pure services or topics alone lacked this structured goal management and cancellation support.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Client      │──────▶│ Goal Topic    │──────▶│ Action Server │
│ (Sends Goal)  │       │ (Subscribe)   │       │ (Executes)    │
└───────────────┘       └───────────────┘       └───────────────┘
       ▲                       │                       │
       │                       ▼                       │
       │               ┌───────────────┐              │
       │               │ Feedback Topic│◀─────────────┤
       │               │ (Publish)    │              │
       │               └───────────────┘              │
       │                       │                       │
       │                       ▼                       │
       │               ┌───────────────┐              │
       │               │ Result Topic  │◀─────────────┤
       │               │ (Publish)    │              │
       │               └───────────────┘              │
       │                                               │
       │                       ▲                       │
       │                       │                       │
       │               ┌───────────────┐              │
       │               │ Cancel Service│◀─────────────┤
       │               │ (Request)    │              │
       │               └───────────────┘              │
       └───────────────────────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do action servers block the client until the task finishes? Commit to yes or no.

Common Belief: Action servers block the client like services, making the client wait until the task completes.

Reality: Action servers allow clients to continue working asynchronously, receiving feedback and results without blocking.

Why it matters: Believing this causes developers to misuse action servers and lose the benefits of asynchronous control, leading to inefficient robot behavior.

Quick: Does an action server automatically stop a task when the client cancels the goal? Commit to yes or no.

Common Belief: When a client cancels a goal, the action server automatically stops the task immediately.

Reality: The server must explicitly check for cancellation requests and stop the task; it does not happen automatically.

Why it matters: Assuming automatic cancellation leads to tasks running unnecessarily, wasting resources and causing unexpected robot actions.

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

Common Belief: Action servers can process multiple goals concurrently without extra setup.

Reality: By default, action servers handle goals sequentially; concurrency requires additional programming like multi-threading.

Why it matters: Misunderstanding this limits system scalability and causes performance bottlenecks in complex applications.

Quick: Is the action server communication based on a new ROS protocol different from topics and services? Commit to yes or no.

Common Belief: Action servers use a completely new communication protocol separate from topics and services.

Reality: Action servers use existing ROS topics and services under the hood, combining them for goal management.

Why it matters: Thinking otherwise can confuse debugging and integration with other ROS components.

Expert Zone

1

Action servers can be layered to create complex behaviors by chaining goals and feedback between multiple servers.

2

Properly managing goal states and transitions prevents race conditions and inconsistent robot states in multi-goal scenarios.

3

Using action servers with real-time constraints requires careful design to avoid delays in feedback and cancellation handling.

When NOT to use

Avoid action servers for very short or instantaneous tasks where services suffice. For streaming sensor data or continuous control, use topics directly. When tasks require strict real-time guarantees, consider specialized real-time frameworks instead of standard ROS action servers.

Production Patterns

In production, action servers often run alongside state machines or behavior trees to coordinate complex robot tasks. They are used for navigation goals, manipulation sequences, and monitoring long operations like charging or diagnostics. Robust implementations include logging, error recovery, and dynamic reconfiguration.

Connections

Asynchronous programming

Action servers implement asynchronous communication patterns similar to async/await in programming languages.

Understanding asynchronous programming helps grasp how action servers allow non-blocking task execution and feedback.

Client-server architecture

Action servers follow the client-server model where clients request services and servers respond, extended with progress updates and cancellation.

Knowing client-server basics clarifies how action servers manage requests and responses over time.

Project management workflows

Action servers resemble project workflows where tasks have goals, progress reports, and completion statuses.

Seeing action servers as task management systems helps understand goal tracking, feedback, and cancellation in robotics.

Common Pitfalls

#1 Ignoring cancellation requests in the action server code.

Wrong approach:

def execute_cb(goal):
for i in range(100):
# do work
time.sleep(0.1)
server.set_succeeded(result)

Correct approach:

def execute_cb(goal):
for i in range(100):
if server.is_preempt_requested():
server.set_preempted()
return
# do work
time.sleep(0.1)
server.set_succeeded(result)

Root cause:

Not checking for preemption means the server never stops tasks when clients cancel, causing wasted resources.

#2 Blocking the main thread while processing goals.

Wrong approach:

def execute_cb(goal):
long_task() # blocks entire node
server.set_succeeded(result)

Correct approach:

def execute_cb(goal):
for step in task_steps:
# process step
server.publish_feedback(feedback)
if server.is_preempt_requested():
server.set_preempted()
return
server.set_succeeded(result)

Root cause:

Blocking prevents the server from handling new goals or cancellations, reducing responsiveness.

#3 Assuming action servers can handle multiple goals without extra setup.

Wrong approach:

# Single-threaded server code without concurrency
server = ActionServer(...)
server.start()

Correct approach:

# Use multi-threaded spinner or asynchronous callbacks
spinner = MultiThreadedSpinner()
spinner.spin()

Root cause:

Not configuring concurrency leads to sequential goal processing and performance bottlenecks.

Key Takeaways

Action servers in ROS manage long-running tasks by allowing clients to send goals and receive asynchronous feedback and results.

They improve robot responsiveness by avoiding blocking calls and supporting task cancellation and preemption.

Action servers use existing ROS communication tools like topics and services but organize them for goal management.

Proper handling of cancellations and concurrency is essential for robust and scalable action server implementations.

Understanding action servers bridges basic ROS communication and advanced robot behavior coordination.

Practice

1. What is the main role of an action server in ROS?

easy

A. To handle long-running tasks and provide feedback during execution

B. To send simple messages without feedback

C. To only receive goals without processing them

D. To replace the ROS parameter server

Solution

1. Step 1: Understand the purpose of an action server

   An action server is designed to manage tasks that take time and can provide updates while working.

2. Step 2: Compare options with the role

   Only To handle long-running tasks and provide feedback during execution correctly describes handling long tasks and sending feedback, unlike others which describe unrelated roles.

3. Final Answer:

   To handle long-running tasks and provide feedback during execution -> Option A

4. Quick Check:

   Action server = long tasks + feedback [OK]

Hint: Remember: action servers manage long tasks with feedback [OK]

Common Mistakes:

• Confusing action server with simple message publishers
• Thinking action server only receives goals without processing
• Mixing action server with parameter server functionality

2. Which of the following is the correct way to define the execute callback function in a ROS action server using Python?

easy

A. def execute(goal, self):

B. def executeCallback(goal):

C. def callback_execute(goal, self):

D. def execute_callback(self, goal):

Solution

1. Step 1: Recall the standard signature for execute callback

   In ROS Python action servers, the execute callback is a method with 'self' and 'goal' parameters.

2. Step 2: Match options to this signature

   Only def execute_callback(self, goal): correctly uses 'def execute_callback(self, goal):' matching the expected pattern.

3. Final Answer:

   def execute_callback(self, goal): -> Option D

4. Quick Check:

   Method signature = self first, then goal [OK]

Hint: Method callbacks in classes always have self first [OK]

Common Mistakes:

• Omitting 'self' parameter in method definition
• Swapping parameter order incorrectly
• Using camelCase instead of snake_case for method name

3. Given this snippet inside an action server's execute callback:

for i in range(3):
    feedback.percent_complete = (i + 1) * 33
    self._action_server.publish_feedback(feedback)
    rospy.sleep(1)
result.success = True
self._action_server.set_succeeded(result)

What will the client receive?

medium

A. No feedback updates, only success result

B. Three feedback updates at 33%, 66%, and 99%, then success result

C. Only one feedback update at 99%, then success result

D. Feedback updates but the result will be failure

Solution

1. Step 1: Analyze the loop sending feedback

   The loop runs 3 times, each time publishing feedback with percent_complete increasing by 33.

2. Step 2: Check the result setting after loop

   After feedback, the result.success is set to True and the goal is marked succeeded.

3. Final Answer:

   Three feedback updates at 33%, 66%, and 99%, then success result -> Option B

4. Quick Check:

   Loop feedback + success result = Three feedback updates at 33%, 66%, and 99%, then success result [OK]

Hint: Loop sends multiple feedbacks before final success [OK]

Common Mistakes:

• Assuming feedback is sent only once after loop
• Confusing success with failure result
• Ignoring the sleep delay between feedbacks

4. Identify the error in this action server execute callback snippet:

def execute_callback(self, goal):
    if goal.order < 0:
        self._action_server.set_aborted()
    result = Result()
    result.output = goal.order * 2
    self._action_server.set_succeeded(result)

medium

A. set_aborted() is called without a result argument

B. Result() is not imported or defined

C. The goal attribute 'order' does not exist

D. set_succeeded() should be called before set_aborted()

Solution

1. Step 1: Check set_aborted() usage

   set_aborted() requires a result argument to inform the client about failure details.

2. Step 2: Verify other parts

   Result() usage is typical; goal.order is assumed valid; set_succeeded() after set_aborted() is not called sequentially here.

3. Final Answer:

   set_aborted() is called without a result argument -> Option A

4. Quick Check:

   set_aborted needs result argument [OK]

Hint: Always pass a result when aborting goals [OK]

Common Mistakes:

• Calling set_aborted() without result causes runtime error
• Assuming set_aborted() can be called without parameters
• Ignoring the need to inform client on abort

5. You want to implement an action server that cancels the goal if a certain condition is met during execution. Which approach correctly handles goal cancellation in the execute callback?

hard

A. Call set_aborted() immediately when the goal is received without checking cancellation

B. Ignore cancellation requests and always call set_succeeded() at the end

C. Check self._action_server.is_preempt_requested() inside the loop, then call self._action_server.set_preempted() and return

D. Use rospy.sleep() to delay cancellation handling until after completion

Solution

1. Step 1: Understand cancellation handling in action servers

   Cancellation requests are detected by checking is_preempt_requested() during execution.

2. Step 2: Proper response to cancellation

   When cancellation is requested, call set_preempted() to notify client and stop processing.

3. Final Answer:

   Check self._action_server.is_preempt_requested() inside the loop, then call self._action_server.set_preempted() and return -> Option C

4. Quick Check:

   Cancellation check + set_preempted = Check self._action_server.is_preempt_requested() inside the loop, then call self._action_server.set_preempted() and return [OK]

Hint: Use is_preempt_requested() to detect and handle cancellations [OK]

Common Mistakes:

• Ignoring cancellation requests during execution
• Calling set_aborted() instead of set_preempted() on cancel
• Delaying cancellation handling until after task finishes