ROS 2 Control (ros2_control)

The Resource Manager is the central authority that owns and arbitrates access to all Hardware Components and their State & Command Interfaces. It enforces strict rules to prevent multiple controllers from writing to the same command interface.

• Core Responsibility: Maintains a global map of all available control interfaces (e.g., /joint1/position, /wheel_left/velocity).
• Lifecycle: Initializes all hardware components, prepares them for communication, and handles their cleanup.
• Interaction: The Controller Manager requests interface access from the Resource Manager when activating a controller.

A Control Interface is a named, typed channel for data exchange between a Controller and a Hardware Interface. They are the fundamental "wires" over which control signals flow.

• Command Interface: A write-only channel from a controller to hardware (e.g., to set a joint's target position).
• State Interface: A read-only channel from hardware to the system (e.g., to read a joint's actual position or motor current).
• Standard Types: position, velocity, acceleration, effort (force/torque).
• Naming Convention: Follows the pattern /<component_name>/<interface_type> (e.g., /arm_joint_3/position).

A Hardware Component is a concrete implementation of a Hardware Interface that represents a specific piece of physical hardware. It is the leaf node in the abstraction tree, containing the actual driver logic.

• Examples:
  • A GenericSystem component for simulating simple joints.
  • A MockSensor component for testing.
  • A custom EtherCATDrive component for a specific motor controller.
• Declaration: Defined in a robot's URDF file using <ros2_control> tags, specifying its type, parameters, and the control interfaces it provides.
• Lifecycle: Configured and activated by the Resource Manager on startup.

ROS 2 Control's core function is to provide a hardware abstraction layer (HAL). It defines a standard interface (hardware_interface) for communicating with diverse physical hardware—motors, sensors, grippers—through a common API. This decouples high-level controllers from the specifics of motor drivers or communication buses (e.g., CAN, EtherCAT).

• System Components: A RobotHW class (or System/Sensor/Actuator in ros2_control) manages the low-level read/write cycle.
• Real-World Example: A robot arm with Dynamixel servos and a force-torque sensor uses a single System to read joint positions and the sensor state, then write new position commands, all through the standardized interface.

The framework manages the lifecycle and execution of various controllers—software modules that compute commands (e.g., torque, velocity) for the hardware. The controller_manager is the central orchestrator.

• Controller Types: It can load, start, stop, and switch between controllers like joint_trajectory_controller for following planned paths, diff_drive_controller for mobile bases, or force_controllers for compliant manipulation.

• Dynamic Reconfiguration: Controllers can be hot-swapped at runtime. For example, switching from a position controller for precise movement to an impedance controller for safe human interaction.

• Real-Time Execution: The manager ensures controllers are updated at a deterministic, high-frequency rate (e.g., 1 kHz) critical for stable control.

ROS 2 Control is essential for hardware-in-the-loop (HIL) and pure simulation workflows. The ros2_control Gazebo plugin creates a simulated hardware interface, allowing the same controllers and control stack to run identically in simulation and on real hardware.

• Sim-to-Real Consistency: Developers can design and test complex controller behaviors in a safe, simulated environment using Gazebo or Ignition before deploying to physical robots.

• Workflow: The plugin bridges the simulation physics engine (providing simulated joint states) and the ROS 2 Control framework, which runs the actual controller_manager and controllers. This validates the entire software pipeline.

It enables the design of deterministic, real-time control systems. By separating the non-real-time ROS 2 communication layer from the real-time control loop, it ensures low-latency, jitter-free execution.

• Dual-Loop Architecture: High-level planning nodes (non-real-time) send goals via actions/topics. The controller_manager and its loaded controllers (often in a real-time thread or process) execute the tight control loop.

• Use Case: A mobile manipulator uses this architecture. A non-real-time navigation planner sends a base trajectory, while a real-time controller manages wheel velocities and arm joint torques simultaneously, ensuring stable and responsive physical behavior.

ROS 2 Control extends the URDF robot model with control-specific tags (<ros2_control>) to declaratively define hardware interfaces and transmissions.

• Transmission Modeling: It mathematically maps actuator space (e.g., motor rotation) to joint space (e.g., linear motion of a prismatic joint) using gear ratios and mechanical linkages. A <transmission> tag in the URDF defines this relationship.

• Declarative Configuration: This allows the system to auto-configure itself from the robot description, reducing boilerplate code. For instance, defining a four-bar linkage or a differential drive transmission here automatically handles the command conversions for the controllers.

The framework supports complex, modular robotic systems, from single arms to heterogeneous fleets.

• Component-Based Design: Each logical hardware component (e.g., a mobile base, a manipulator arm, a sensor pan-tilt unit) can be modeled as its own System within ros2_control, managed by a single or distributed controller_manager.

• Fleet Orchestration: In a warehouse, multiple Autonomous Mobile Robots (AMRs) each run their own ROS 2 Control stack. A fleet management system sends high-level goals, while each robot's local control stack handles precise motor control and safety. This separation of concerns is enabled by the abstraction ros2_control provides.

A Hardware Interface is the software abstraction layer that provides a standardized API for reading from and writing to physical robot hardware components. It acts as the bridge between the generic control commands from ROS 2 controllers and the specific, often proprietary, drivers for motors, sensors, and actuators.

• Types: Common interfaces include PositionJointInterface, VelocityJointInterface, and EffortJointInterface for actuated joints, as well as interfaces for sensors like JointStateInterface and ImuSensorInterface.
• Implementation: Developers implement these interfaces for their specific hardware, handling the low-level protocol translation (e.g., CAN bus, EtherCAT, PWM signals).
• Role in ros2_control: The hardware resource manager uses these interfaces to claim and command hardware resources, ensuring exclusive access and thread-safe operation for real-time control loops.

The Controller Manager is the central runtime service in ros2_control responsible for loading, configuring, starting, stopping, and switching between different controllers. It manages the lifecycle of all controllers within the system.

• Dynamic Loading: Controllers are typically loaded as plugins at runtime, allowing for flexible system composition without recompilation.
• Resource Arbitration: It ensures that multiple controllers do not conflict by attempting to command the same hardware interface simultaneously. A controller must 'claim' a hardware resource before it can write to it.
• Real-Time Execution: The manager orchestrates the update loops of loaded controllers, calling their update() methods at a fixed frequency (e.g., 1 kHz) to compute and forward commands to the hardware interfaces.

A Joint Trajectory Controller is a specific type of ROS 2 controller that executes smooth, time-parameterized motion paths (trajectories) for a set of robot joints. It is one of the most commonly used controllers for robotic arms and other multi-joint systems.

• Input: It subscribes to a trajectory_msgs/msg/JointTrajectory topic, which specifies a sequence of target positions, velocities, and accelerations for each joint over time.
• Function: The controller uses internal interpolation (e.g., splines) and feedback (from a JointStateInterface) to compute the instantaneous command (position, velocity, or effort) needed to follow the desired trajectory.
• Use Case: Essential for tasks like pick-and-place, where the arm must move through a series of predefined waypoints smoothly and accurately. It abstracts the complex low-level motion generation from the higher-level planning stack.

URDF (Unified Robot Description Format) and SRDF (Semantic Robot Description Format) are XML file formats used to describe a robot's physical and semantic properties, which are foundational for ros2_control configuration.

• URDF: Defines the robot's kinematic tree: links (rigid bodies), joints (connections between links with type, limits, and dynamics), and visual/collision geometry. ros2_control uses URDF to understand the robot's structure and to parse <ros2_control> tags that declare hardware interfaces and transmission types.
• SRDF: Adds semantic information not in the URDF, such as default robot poses, end-effector groups, and most critically for control, virtual joints and passive joints. It helps distinguish between joints controlled by ros2_control and those that are fixed or mimic other joints.
• Integration: Together, they provide a complete static description that the ros2_control system uses to auto-generate much of its configuration and understand resource naming.

A Transmission in ros2_control defines the kinematic relationship between an actuator (e.g., a motor) and a joint in the robot model. It maps actuator state/command space (e.g., motor revolutions) to joint space (e.g., radians) and vice-versa.

• Purpose: Abstracts mechanical reductions, non-linear couplings, or complex linkages (e.g., four-bar linkages). It allows controllers to command in intuitive joint space while the hardware interface handles the actuator-specific commands.
• Types: The most common is the SimpleTransmission, which defines a linear gear ratio. More complex types can be implemented for systems like differential drives or robotic hands with tendon-driven fingers.
• Configuration: Defined within the <ros2_control> tag in the URDF file, linking a specific hardware interface (actuator) to a specific joint.

Real-Time Code refers to software whose execution timing must be deterministic and guaranteed to meet strict deadlines, a critical requirement for low-level robot control. rclcpp is the ROS 2 Client Library for C++, which must be used carefully in real-time contexts.

• Challenge: Standard ROS 2 communication (via rclcpp::Node) and memory allocation (e.g., std::vector resizing) are non-deterministic and can cause deadline misses, leading to jerky or unstable robot motion.
• Best Practices:
  • Use the RealtimeNode class from realtime_tools as a base, which provides real-time-safe publishers.
  • Pre-allocate all memory (messages, vectors) during initialization.
  • Avoid dynamic memory allocation in the control loop.
  • Use a real-time priority scheduler (e.g., SCHED_FIFO on Linux) for the control thread.
• ros2_control Design: The framework is built to facilitate this by isolating the real-time critical update loop (in controllers and hardware interfaces) from non-real-time management tasks (in the controller manager).