ros2_control

ros2_control – definition

ros2_control is the ROS 2 framework for connecting robot hardware to controllers through standard command and state interfaces. It separates low-level hardware communication from higher-level motion control. In a mobile UGV, it commonly connects wheel motors and wheel encoders, while IMUs, batteries, and other devices can be integrated through dedicated ROS 2 drivers or, where appropriate, ros2_control hardware interfaces.

The framework is maintained as part of the ROS 2 ecosystem and is documented by ros2_control documentation. Its central runtime component is controller_manager. The controller manager loads hardware components, activates controllers, exposes ROS 2 services, and performs the control update loop.

For a differential-drive platform such as Leo Rover, ros2_control is typically used to expose left and right wheel interfaces to diff_drive_controller. The controller converts commanded linear and angular velocity into individual wheel commands. It can also calculate wheel odometry from encoder feedback. Raph Rover can use the same architecture, but its hardware plugin may communicate with motor controllers over CAN, serial, Ethernet, or another transport selected by the system integrator.

Core architecture in a mobile robot

ros2_control uses a layered architecture. Each layer has a defined responsibility. This reduces coupling between a hardware driver and navigation, teleoperation, or autonomy software.

Robot description – a URDF file contains a <ros2_control> element describing available hardware interfaces.
Hardware interface plugin – a C++ plugin derived from ros2_control hardware interface classes. It reads sensor data and writes actuator commands.
Resource manager – the internal component that imports hardware interfaces and checks whether controllers can claim them.
Controller manager – loads, configures, activates, deactivates, and updates controllers.
Controllers – ROS 2 plugins such as diff_drive_controller, joint_state_broadcaster, or a custom controller.

The hardware abstraction supports actuator, sensor, and system components. A wheeled UGV normally uses a system component because its motors, encoders, and potentially onboard status signals form one coordinated hardware subsystem. The interface lifecycle includes configuration and activation states, allowing a driver to reject control activation when communication or safety checks fail.

Command and state interfaces

A ros2_control hardware component exports interfaces identified by joint or sensor name and interface type. A command interface accepts a requested value. A state interface reports a measured or estimated value.

Interface	Typical UGV use	Example unit
`velocity` command	Requested wheel angular speed	rad/s
`position` state	Wheel encoder position	rad
`velocity` state	Measured wheel speed	rad/s
`effort` command or state	Motor torque control or feedback, if supported by the motor driver	N·m

Standard joint interfaces use ROS units and conventions, while the supported interfaces, limits, and control behavior are determined by the hardware implementation and controller configuration. A velocity command should not be assumed to be closed-loop wheel-speed control unless the motor controller or hardware plugin implements that behavior. This distinction matters when tuning odometry, traction control, or navigation on uneven terrain.

Differential drive control for Leo Rover

Leo Rover has a four-wheel differential-drive layout and supports ROS 2 on its built-in Raspberry Pi compute unit. It is not autonomous by default. A navigation stack, localization source, safety logic, and suitable sensors must be integrated separately.

The standard controller for this kinematic model is diff_drive_controller. It receives a body velocity command and calculates left and right wheel velocities. For track width b, wheel radius r, linear velocity v, and angular velocity ω, the ideal wheel angular velocities are:

ω_left  = (v - ωb/2) / r
ω_right = (v + ωb/2) / r

The controller can use wheel position feedback to estimate odometry. Its odometry output is only as accurate as encoder resolution, wheel radius calibration, wheel separation, surface traction, and synchronization of feedback data. On a skid-steered or four-wheel rover, slip can create substantial dead-reckoning error. An IMU, LiDAR SLAM system, visual odometry source, or RTK GNSS receiver can provide external correction through an estimator such as robot_localization.

URDF and controller configuration

The following simplified URDF fragment declares velocity commands and position and velocity feedback for two wheel joints. The exact joint names must match the robot model and hardware plugin configuration.

<ros2_control name="RoverSystem" type="system">
  <hardware>
    <plugin>fictionlab_rover_hardware/RoverSystem</plugin>
  </hardware>
  <joint name="left_wheel_joint">
    <command_interface name="velocity"/>
    <state_interface name="position"/>
    <state_interface name="velocity"/>
  </joint>
  <joint name="right_wheel_joint">
    <command_interface name="velocity"/>
    <state_interface name="position"/>
    <state_interface name="velocity"/>
  </joint>
</ros2_control>

A controller YAML file then assigns wheel joints and geometric parameters. These parameters must be measured on the physical platform rather than copied from a generic robot example.

controller_manager:
  ros__parameters:
    update_rate: 50

    diff_drive_base_controller:
      type: diff_drive_controller/DiffDriveController

diff_drive_base_controller:
  ros__parameters:
    left_wheel_names: ["left_wheel_joint"]
    right_wheel_names: ["right_wheel_joint"]
    wheel_separation: 0.30
    wheel_radius: 0.08
    publish_rate: 50.0
    enable_odom_tf: false
    open_loop: false

The values above are configuration examples, not Leo Rover or Raph Rover specifications. The update_rate and publish_rate values must be selected according to motor-controller latency, encoder update rate, CPU load, and the required control response.

ROS 2 interfaces and frame conventions

Current ros2_controllers documentation specifies that diff_drive_controller accepts velocity commands on its ~/cmd_vel input using geometry_msgs/msg/TwistStamped. It publishes odometry as nav_msgs/msg/Odometry and can publish the odom to base_link transform when enabled. Integrators should verify the interface of the installed controller version because ROS 2 distributions and controller releases can differ.

Coordinate frames should follow REP 103 and REP 105. For a ground rover, base_link is fixed to the robot body, while odom provides locally continuous odometry. A localization system may provide the map to odom transform. ros2_control should not publish competing transforms for the same frame pair.

Integration considerations for Raph Rover

Raph Rover is intended for configurations requiring greater payload capacity. Payload hardware that requires ros2_control integration should be modeled using the appropriate actuator, sensor, or system component. Devices such as a LiDAR, RTK GNSS receiver, depth camera, or onboard computer will usually use dedicated ROS 2 drivers rather than ros2_control.

The base drive hardware plugin should implement deterministic read and write behavior. It should validate communication timeouts, reject invalid commands, apply motor-controller limits, and expose diagnostics where available. Hardware-level emergency stop logic must remain effective independently of ROS 2 process state. ros2_control manages software control interfaces; it does not replace electrical safety circuits or manufacturer-defined motor-controller protections.