ROS 2 Component

Unlike a standard ROS 2 node, which is a standalone executable, a Component is a shared library (e.g., a .so or .dll file). It is loaded on-demand into a Component Container process. This allows multiple components to be composed into a single operating system process, drastically reducing inter-process communication (IPC) overhead and memory footprint compared to running each as a separate node. This is essential for performance-critical systems on resource-constrained hardware.

A component does not have its own main() function. Its lifecycle is managed by the container it runs inside. The container is responsible for:

• Loading the component's shared library.
• Instantiating the component class.
• Spinning the component's executor to process callbacks.
• Providing access to the node's context and interfaces. Common container types include rclcpp_components::ComponentManager for manual composition or ComposableNodeContainer for launch file composition. This abstraction separates business logic from process management.

A component must explicitly register its ROS interfaces upon construction. This is done using macros or base class constructors that declare:

• Subscriptions and Publishers (for topic communication).
• Service Servers and Clients (for request-response).
• Action Servers and Clients (for long-running tasks).
• Parameters (for configuration). This registration makes the component's API self-documenting and allows the container to properly wire it into the ROS graph. The component's class inherits from rclcpp::Node but is constructed with a pre-existing node instance provided by the container.

Component-based design enables sophisticated fault containment strategies. Since multiple components run in a single process, a failure in one component can potentially crash the entire container process. This sounds negative but is a feature: it allows system designers to group tightly-coupled, trusted components together in one container for performance, while isolating less stable or third-party components in separate containers. This creates a "fault barrier," preventing a buggy component from taking down unrelated parts of the system, and allows for monitored restarts of individual containers.

The same component code can be deployed in multiple configurations without recompilation:

• Monolithic Process: Multiple components composed into one container for minimal latency.
• Distributed Processes: Each component in its own container, deployed across a network, for modularity and isolation.
• Mixed Strategy: Critical perception/control loops in a fast monolithic container, with higher-level planning components in separate containers. This is controlled at launch time via ROS 2 Launch Files using the ComposableNode description, making it a powerful tool for system integration and testing.

Use Cases:

• High-frequency control loops where IPC latency is prohibitive.
• Complex systems (e.g., autonomous vehicles) with many nodes, to reduce process sprawl.
• Systems requiring dynamic reconfiguration (loading/unloading functionality).
• Embedded systems with limited RAM/CPU.

Key Benefits:

• Reduced Overhead: Eliminates serialization/deserialization and TCP/UDP transport for intra-container communication.
• Lower Latency: Direct C++/Python method calls between components in the same process.
• Better Cache Utilization: Code and data reside in a single process space.
• Cleaner System Architecture: Enforces strong boundaries and explicit dependencies between modules.

The primary use case for a ROS 2 Component is process composition, where multiple component nodes are compiled into shared libraries and loaded into a single OS process via a component container. This eliminates the overhead of inter-process communication (IPC) for messages passed between composed nodes, drastically reducing latency and CPU usage. For example, a perception pipeline with separate nodes for image rectification, object detection, and tracking can be composed into one process, enabling high-frequency, low-latency data flow critical for real-time control loops.

Components enable a clean, modular software architecture. Different teams can develop independent, reusable components (e.g., a LIDAR driver, a SLAM module, a navigation planner) that are packaged as standalone libraries. A system integrator can then assemble these pre-built components into a complete application using launch files, without modifying source code. This mirrors plugin architectures in other software domains, promoting code reuse and simplifying the integration of third-party or proprietary algorithms into a larger ROS 2 system.

When combined with ROS 2 Lifecycle Nodes, components enable sophisticated runtime management. A system manager can dynamically load, configure, activate, deactivate, and unload components based on system state or operational mode. For instance, a mobile robot could:

• Load and activate a high-precision mapping component when in an unexplored area.
• Deactivate it and load a lightweight localization component for routine navigation to conserve CPU.
• Unload all navigation components and load a manipulation planning component when the arm is engaged. This allows for optimal resource utilization and graceful error recovery.

Components are ideal for deployment on embedded systems or edge devices with limited memory and CPU cores. By composing multiple nodes into one process, you reduce the total number of processes, minimizing memory overhead from duplicated libraries and runtime environments. This is crucial for deploying complex autonomy stacks on single-board computers (e.g., NVIDIA Jetson, Raspberry Pi) common in mobile robots and drones. The component model allows these systems to run more functionality within strict resource budgets.

A concrete example is a camera processing pipeline built with four components:

1. Camera Driver Component: Publishes raw images from hardware.
2. Image Rectification Component: Subscribes to raw images, corrects lens distortion.
3. Object Detection Component: Subscribes to rectified images, runs a neural network, publishes bounding boxes.
4. Visualization Component: Subscribes to images and boxes, overlays results. All four components are loaded into a single-threaded executor within one container. The rectified image message is passed from Component 2 to Component 3 via a pointer, without serialization or network traversal, resulting in sub-millisecond latency. This entire pipeline is defined and launched from a single Python launch file.

The component model simplifies unit and integration testing. Because a component is a class with well-defined interfaces, it can be instantiated and tested in isolation without a running ROS graph, using standard testing frameworks like GTest or Pytest. For integration testing, a component can be loaded into a minimal test container with mocked or recorded data (e.g., from a ROS Bag). This also benefits simulation: high-fidelity physics simulators like Ignition Gazebo or NVIDIA Isaac Sim often interface with ROS via plugin components that are composed directly into the simulation process for maximum performance.

A ROS 2 Executor is the processing engine within a node that manages the execution of callbacks from subscriptions, timers, services, and action servers. It is critical for component performance.

• Single-Threaded Executor: Processes callbacks sequentially in a single thread. Simple but can lead to latency if one callback blocks.
• Multi-Threaded Executor: Uses a thread pool to process callbacks concurrently, improving responsiveness for components with heavy or parallelizable workloads.
• Component Container Role: The container that hosts one or more components provides the executor(s). Component developers implement callbacks; the executor schedules them.

Process Composition is the architectural pattern enabled by ROS 2 Components, where multiple node-like entities (the components) are compiled into shared libraries and dynamically loaded into a single OS process called a container.

• Performance Benefit: Eliminates inter-process communication (IPC) overhead for messages passed between components in the same container, reducing latency and CPU usage.
• Resource Management: Allows fine-grained control over system resources by colocating related functionality. For example, all perception nodes for a single sensor can be composed into one process.
• Trade-off: A fault in one component can potentially crash the entire container process, unlike fault-isolated standalone nodes.

A Component Container is a generic process that provides the runtime environment for one or more loaded components. It manages the node lifecycle, provides the executor, and handles the component's integration into the ROS graph.

• ComponentManager: The ROS 2 node (e.g., rclcpp_components::ComponentManager) that acts as the container, offering services to load and unload component libraries.
• Dynamic Loading: Uses system utilities (e.g., dlopen on Linux) to load component libraries (*.so files) at runtime without restarting the process.
• Common Patterns: A system may run multiple containers—one for high-priority control components (with a real-time executor) and another for best-effort planning components.