Actuator

Actuator – definition

An actuator is a device that converts supplied energy into physical motion or force. In mobile robotics, the term usually refers to the hardware that moves the robot or changes the state of a subsystem. On a UGV, this most often means wheel drive motors, steering elements, braking devices, linear drives, or mechanisms used to position sensors and payloads. The input energy can be electrical, hydraulic, or pneumatic, but in research and educational UGV platforms the dominant class is the electric actuator.

In ROS and ROS 2 practice, an actuator is not only a mechanical component. It is part of a control chain that includes power electronics, feedback sensing, low-level firmware, and high-level software interfaces. A mobile robot does not command torque or speed directly from a navigation node to bare hardware. Instead, the command is translated through controllers, motor drivers, and feedback loops. For example, a differential-drive UGV receives a velocity command, often on /cmd_vel using geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped, and converts that command into left and right wheel actuator setpoints.

For Leo Rover and Raph Rover, the actuator concept should be understood in the context of ground locomotion. The core actuators are the traction motors that generate wheel torque. Their behavior determines acceleration, climb capability, turning response, odometry quality, power draw, thermal load, and overall navigation performance.

How actuators are used in mobile UGVs

On a mobile platform, an actuator is part of the plant controlled by the robot software stack. The actuator receives a target value such as angular velocity, duty cycle, current, or torque, and the low-level controller attempts to track it. In a UGV, the most important distinction is between actuator type and control mode.

Typical actuator roles in mobile robotics include the following:

propulsion – rotating wheels or tracks to move the platform
steering – changing the wheel angle on Ackermann or articulated platforms
sensor positioning – moving a mast, tilt unit, or pan-tilt camera
auxiliary mechanisms – opening covers, releasing samples, adjusting tools

For a differential-drive robot such as Leo Rover, propulsion and steering are coupled. The robot turns by changing the relative speeds of the left and right wheel actuators. This differs from an Ackermann vehicle, where one actuator group provides traction and another controls steering geometry.

The kinematic relation for differential drive is standard:

v = (v_r + v_l) / 2
ω = (v_r - v_l) / b

where v is linear velocity, ω is angular velocity, v_r and v_l are right and left wheel linear velocities, and b is wheel separation. In practice, actuator accuracy directly affects how well the robot tracks these commanded values.

Actuators in ROS 2 control stacks

In ROS 2, actuators are usually exposed through hardware interfaces and controllers rather than through direct device-specific calls in user applications. The common software architecture is based on ros2_control. It separates the robot hardware layer from the controller layer and supports command interfaces such as position, velocity, and effort.

This matters because the same navigation stack can work with different actuators if the hardware interface is implemented correctly. A UGV application sends body-level motion commands, while the low-level control layer maps them to actuator commands.

Relevant ROS 2 components include:

geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped – body velocity command, often published on /cmd_vel
sensor_msgs/msg/JointState – actuator and wheel feedback such as velocity or position
ros2_control – hardware abstraction and controller framework
diff_drive_controller – standard controller for differential-drive robots
nav_msgs/msg/Odometry – estimated motion, indirectly dependent on actuator feedback

A minimal controller configuration for wheel actuators on a differential-drive rover can look like this:

controller_manager:
  ros__parameters:
    update_rate: 50

    joint_state_broadcaster:
      type: joint_state_broadcaster/JointStateBroadcaster

    diff_drive_controller:
      type: diff_drive_controller/DiffDriveController

diff_drive_controller:
  ros__parameters:
    left_wheel_names: ["front_left_wheel_joint", "rear_left_wheel_joint"]
    right_wheel_names: ["front_right_wheel_joint", "rear_right_wheel_joint"]
    wheel_separation: 0.38
    wheel_radius: 0.065
    publish_rate: 50.0
    use_stamped_vel: false

In this model, the actuator hardware may be DC motors with encoders, but the controller treats them through standardized interfaces. This is a common pattern in ROS 2.

Key actuator parameters and metrics

Actuators are selected and evaluated through measurable parameters. For UGV integration, these values are not optional details. They define whether the platform can move as intended, whether odometry remains stable, and whether the power system is correctly sized.

Parameter	Why it matters in a UGV
Rated voltage	Must match the battery and motor driver design
Continuous torque	Determines sustained traction under load
Peak torque	Important for startup, obstacle crossing, and slope entry
Rated speed or speed constant	Sets achievable wheel speed after gear reduction
Gear ratio	Trades speed for torque and affects backdrivability
Encoder resolution	Impacts velocity estimation and odometry precision
Control mode	Position, velocity, current, or torque control changes system behavior
Current draw	Affects power budget, thermal constraints, and battery runtime
Update rate	Low-level loops commonly run faster than ROS topics, often in the tens to thousands of hertz depending on hardware
Ingress protection	Relevant for outdoor UGVs exposed to dust and splashes

In field robotics, actuator selection must also consider wheel radius, vehicle mass, expected payload, rolling resistance, terrain type, and slope. A larger rover such as Raph Rover typically requires higher continuous torque and a more robust thermal and electrical design than a lighter educational platform.

Practical context on Leo Rover and Raph Rover

On Leo Rover, actuators are typically considered as part of a compact four-wheel-drive system controlled from an onboard Raspberry Pi-based compute unit. Leo Rover supports ROS 2, but autonomous navigation is not provided out of the box. The actuator layer must therefore be integrated with the selected navigation and control stack.

In practice, actuator-related engineering work on Leo Rover often includes:

mapping /cmd_vel to wheel speed commands
reading wheel encoder feedback for odometry
tuning velocity control to reduce slip-induced drift
limiting acceleration to avoid wheel spin on loose terrain
verifying current and thermal margins for added payload

Raph Rover uses the same actuator concept, but the integration constraints are different. A higher payload platform usually carries heavier sensors, larger batteries, and more demanding compute hardware. This increases inertia and changes drivetrain requirements. The actuator design must then support higher load, stronger traction, and stable low-speed control for inspection or research tasks.

Limitations and trade-offs

No actuator is ideal. In mobile robotics, the major trade-offs are between torque, speed, efficiency, controllability, cost, and environmental robustness. A high gear ratio improves climbing ability but reduces top speed and can worsen control smoothness. A low-cost motor driver may be sufficient for teleoperation but may not provide the feedback quality needed for precise odometry.

Common actuator-related failure modes on UGVs include:

encoder noise or missed counts
motor saturation under load
thermal derating during long missions
insufficient current capability in the driver or battery
wheel slip causing divergence between commanded and actual motion

For this reason, actuator feedback should not be treated as ground truth. In autonomous navigation, wheel-based estimates are usually fused with IMU, visual odometry, LiDAR odometry, or GNSS using state estimation nodes such as robot_localization.

Normative references and standards

The ROS message and frame conventions relevant to actuator integration are defined in official ROS documentation and REPs. For mobile robots, the most useful references are the ROS 2 documentation for ros2_control, the standard message definitions, and REP-103 for units and coordinate conventions. REP-105 defines the common mobile robot frame structure such as base_link, odom, and map, which is essential when actuator feedback contributes to odometry.

Source references commonly used for verification include:

ROS 2 documentation – ros2_control, controller interfaces, and message definitions
REP-103 – Standard Units of Measure and Coordinate Conventions
REP-105 – Coordinate Frames for Mobile Platforms
hardware datasheets from motor, encoder, and driver manufacturers
platform documentation at docs.fictionlab.pl/leo-rover