ROS 2

The Executor is the processing engine within a node that schedules the execution of callbacks from timers, subscriptions, services, and action servers. It manages the flow of data from the DDS layer to user code. ROS 2 provides several executor types:

• SingleThreadedExecutor: Processes all callbacks sequentially in one thread.
• MultiThreadedExecutor: Uses a thread pool to process callbacks concurrently, improving responsiveness.
• StaticSingleThreadedExecutor: An optimized variant for known, fixed callback groups. Proper executor configuration is critical for meeting real-time deadlines and avoiding callback starvation.

ROS 2 Quality of Service (QoS) policies are a foundational architectural feature, allowing fine-grained control over communication reliability and resource usage. Policies are set per publisher/subscriber or client/server pair. Key policies include:

• Reliability: RELIABLE (guaranteed delivery) vs. BEST_EFFORT.
• Durability: TRANSIENT_LOCAL (late-joining subscribers get last message) vs. VOLATILE.
• Deadline: The maximum expected time between messages.
• Liveliness: How a node signals it is still alive. This allows tuning from loss-tolerant sensor data to critical real-time control commands.

ROS 2 remains a cornerstone in academic and industrial research for developing next-generation embodied intelligence.

• Simulation Integration: Seamlessly interfaces with high-fidelity physics-based simulators like Gazebo and Ignition for Sim-to-Real Transfer Learning.
• Algorithm Development: Provides a standardized framework for implementing and testing Reinforcement Learning for Robotics, Imitation Learning, and advanced Model Predictive Control (MPC) algorithms.
• Modularity: The component-based architecture allows researchers to rapidly swap out perception, planning, or control modules for experimental comparison.

ROS 2 enables the development of sophisticated surgical and rehabilitation robots where precision and safety are paramount.

• Real-time Control Loops: Guarantees low-latency execution for haptic feedback and sub-millimeter precision in surgical manipulators.
• Human-Robot Interaction (HRI): Supports safe collaboration through force/torque sensing and compliant control modes.
• Regulatory Compliance: The auditability of the ROS 2 communication graph and configurable security features assist in meeting stringent medical device regulations.

ROS 2 Quality of Service (QoS) is a set of configurable policies that govern the behavior of communication between nodes, replacing ROS 1's fixed reliability model. Developers select profiles to match their system's requirements.

Key policies include:

• Reliability: RELIABLE (guaranteed delivery) vs. BEST_EFFORT.
• Durability: VOLATILE (late-joining subscribers miss data) vs. TRANSIENT_LOCAL (server retains data for new subscribers).
• Deadline: The maximum expected time between message publications.
• Liveliness: How a node signals it is still active.
• History: How many messages to keep if the subscriber cannot keep up. This fine-grained control allows a single ROS 2 graph to support mixed criticality, from best-effort logging to hard real-time sensor data for control.

A ROS 2 Lifecycle Node is a managed node that follows a strict, finite state machine, enabling systematic startup, error recovery, and shutdown of complex system components. This is critical for safety and determinism in production systems.

The defined states are:

• Unconfigured: The node is constructed but has not read parameters.
• Inactive: Configured, with resources allocated, but not performing its primary function.
• Active: Fully operational, processing data and executing its main task.
• Finalized: Cleanly shut down, ready for destruction. Transitions between states (e.g., configure, activate, deactivate, cleanup) are explicit and can be managed by a lifecycle manager. This prevents nodes from interacting before they are fully initialized and allows for graceful system reconfiguration.

ROS 2 Navigation2 is the official navigation framework successor to ROS 1's move_base. It provides a complete system for mobile robot autonomy, built on a behavior tree architecture for improved modularity and recovery logic.

Key components and improvements:

• Behavior Tree Engine: Replaces the finite state machine, allowing complex, reusable recovery behaviors (e.g., "spin in place, then re-plan").
• Planner/Controller Servers: Modular plugins for global path planning (e.g., A*, RRT*) and local trajectory following (e.g., DWB, MPC).
• Costmap2D Layer System: Dynamic, layered maps for obstacles, inflation, and other costs.
• Lifecycle Managed: All major servers are lifecycle nodes for controlled startup.
• Smac Planners: Includes state-of-the-art search-based planners (State Lattice, Hybrid-A*) for smoother, kinematically feasible paths. Navigation2 is the standard stack for deploying autonomous mobile robots (AMRs) in warehouses, hospitals, and other dynamic environments.

ROS 2 Control is a framework for abstracting and managing robot hardware interfaces and controllers in a real-time control loop. It provides a unified layer between high-level planning (e.g., MoveIt2, Navigation2) and low-level motor drivers.

Core concepts:

• Hardware Interface: A C++ class that abstracts specific hardware (e.g., a joint motor, an IMU). Types include PositionJointInterface, VelocityJointInterface.
• Controller: An algorithm that computes commands for hardware interfaces (e.g., a joint_trajectory_controller for following planned paths).
• Controller Manager: Loads, unloads, and switches between controllers at runtime.
• Resource Manager: Handles claiming and conflict resolution of hardware resources between controllers.
• Real-time Capable: Designed for integration with real-time operating systems or Linux with the PREEMPT_RT patch. This separation allows robot descriptions (URDF) and high-level motion commands to remain hardware-agnostic, simplifying integration and testing.