ROS 2 Executor

The core function of an executor is to spin, which is the process of waiting for and then executing callbacks. It monitors all associated entities (e.g., subscriptions, timers) for readiness. When a timer fires or a message arrives on a subscription, the executor places the corresponding callback into a queue for execution. The spin() or spin_once() methods are called to process this queue, executing callbacks in a controlled, single-threaded loop. This centralizes the flow of control, preventing callback race conditions within a node.

ROS 2 provides several executor implementations, each with distinct concurrency models:

• SingleThreadedExecutor: The default. Processes all callbacks sequentially in a single thread. Simple and deterministic but can lead to callback latency if one callback blocks.
• MultiThreadedExecutor: Uses a thread pool to execute multiple ready callbacks concurrently. Increases throughput but introduces complexity from potential race conditions between callbacks.
• StaticSingleThreadedExecutor: An optimized version of the single-threaded executor with lower overhead, as it discovers all entities once at configuration time. Ideal for performance-critical, static node graphs.

The executor works in tandem with the underlying Data Distribution Service (DDS) middleware. The DDS layer is responsible for the actual network communication: discovery, message queuing, and delivery based on Quality of Service (QoS) policies. The executor's role is to pull these delivered messages from the DDS's local queues and invoke the user-provided callback functions. This separation allows the executor to focus on application-level scheduling while DDS handles reliable, real-time data distribution.

For real-time robotic control, executor behavior must be predictable. Key factors include:

• Callback Priorities: Executors themselves do not implement priorities; priority is managed at the OS thread level using real-time scheduling policies (e.g., SCHED_FIFO).
• Callback Duration: A long-running callback can starve other callbacks, breaking real-time guarantees. Callbacks must be designed to be non-blocking and short.
• Spin Behavior: spin_once() allows explicit control over when callbacks are processed, enabling integration into custom, deterministic control loops.

An executor is not tied to a single node. A key architectural pattern is node composition, where one executor can spin multiple nodes. This is essential for ROS 2 Components, which are node-like objects compiled into shared libraries. A component container loads these libraries and spins them with an executor, allowing multiple functional units to run in a single process. This reduces inter-process communication overhead and is critical for high-performance, embedded systems.

Effective use of executors follows established patterns:

• One Executor Per Process: Typically, a main thread creates and spins one executor for all nodes in that process.
• Separation of Concerns: Use separate executors (and often separate threads/processes) for distinct system parts: a high-frequency control loop on a real-time executor, and a slower planning node on a standard executor.
• Avoiding Blocking Calls: Never call long-running or blocking functions (e.g., network I/O, long sleeps) inside a callback. Use asynchronous operations or delegate work to separate threads.
• Using Timers for Periodic Work: For periodic tasks, use a ROS Timer callback instead of a while loop with sleep, as it integrates cleanly with the executor's scheduling.

A ROS 2 Node is the fundamental executable process that contains the Executor. It is the primary unit of computation in a ROS 2 graph. The Executor's sole purpose is to manage the callbacks (for subscriptions, timers, services, etc.) owned by its node.

• Primary Container: The node provides the callbacks; the executor runs them.
• Single-Threaded Model: A default, single-threaded executor spins within the node's main thread.
• Multi-Node Executors: A MultiThreadedExecutor can be shared across multiple nodes to co-locate their processing.

ROS 2 Quality of Service (QoS) policies govern when and if messages are delivered between nodes. The Executor's scheduling is directly impacted by the QoS profiles of the subscriptions it manages.

• Deadline Policy: Defines the expected maximum period between messages. The executor must schedule callbacks fast enough to meet these deadlines.
• Liveliness Policy: Ensures publishers are active. The executor's responsiveness affects a node's ability to assert its liveliness.
• History & Depth: Determines how many messages are queued for a subscription before the executor processes them, directly affecting memory and latency.

A ROS 2 Callback is a user-defined function that the Executor invokes. It is the atomic unit of work scheduled by the executor. Different callback types have distinct scheduling characteristics.

• Subscription Callback: Triggered when a message arrives on a topic.
• Timer Callback: Triggered at a fixed frequency, independent of other node activity.
• Service Callback: Triggered by an incoming service request.
• Action Server Callbacks: Include goal, cancel, and result callbacks for long-running tasks.
• Callback Groups: Callbacks can be assigned to Mutually Exclusive or Reentrant groups to control executor concurrency.

This broader architectural pillar encompasses the need for deterministic, low-latency execution loops—the core problem the Executor is designed to solve. Designing an effective executor strategy is critical for real-time performance.

• Deterministic Scheduling: Using a Static Single-Threaded Executor provides predictable, fixed-priority callback ordering.
• Latency Chains: The executor is the central scheduler in the perception-planning-actuation loop. Its design (e.g., spin period, callback group assignment) directly impacts end-to-end system latency.
• Integration with Control Loops: High-frequency control often bypasses the executor for hardware-timed interrupts, but the executor manages higher-level task coordination.

A ROS 2 Component is a node packaged as a shared library. A Component Manager uses a specialized MultiThreadedExecutor to dynamically load and run multiple components within a single process.

• Process Composition: The Component Manager's executor allows co-locating multiple nodes (components) to reduce inter-process communication overhead.
• Resource Management: The executor manages the lifecycle and callbacks of all loaded components, providing a unified scheduling context.
• Performance: This model is key for performance-sensitive applications, as it minimizes serialization and context-switching costs.

A Callback Group is an executor-level mechanism to control concurrency among a node's callbacks. It defines whether callbacks can be executed in parallel.

• Mutually Exclusive Group: Callbacks in this group are never executed concurrently by the executor. This is the default and safe for shared data access.
• Reentrant Group: Callbacks in this group can be executed in parallel by a MultiThreadedExecutor, requiring explicit user synchronization (e.g., mutexes).
• Executor Binding: Callback groups are associated with an executor when a node is added to it, defining the thread pool available for those callbacks.