Motor controller

Motor controller – definition

A motor controller is an electronic subsystem that regulates electrical power delivered to a drive motor and converts high-level motion commands into controlled torque, speed, or position. In mobile robotics, the term usually refers to the board or embedded unit placed between the compute platform and the traction motors. It accepts command inputs such as target wheel velocity, PWM duty cycle, or current setpoint, and it closes one or more feedback loops using signals from encoders, current sensors, or internal estimators.

On a UGV, a motor controller is part of the drivetrain, not only a power switch. It is responsible for commutation, direction control, acceleration limits, braking behavior, and protection functions such as overcurrent, undervoltage, thermal shutdown, and stall detection. For brushed DC motors, this is typically implemented with an H-bridge and a speed or current control loop. For BLDC motors, the controller also performs phase commutation and may run field-oriented control. In practical ROS 2 systems, the motor controller is the low-level actuator interface below diff_drive_controller, ros2_control, or a custom hardware driver.

For Leo Rover and Raph Rover, the motor controller should be understood in the context of a differential-drive mobile base. It receives left and right wheel commands derived from geometry_msgs/msg/Twist or joint velocity targets, drives the wheel motors, and reports feedback required for odometry. This layer is critical because wheel tracking error, update rate, and controller latency directly affect navigation, localization, and safety.

How a motor controller fits into a UGV architecture

In a research rover, the motor controller sits between the battery bus and the onboard computer. It is usually connected over UART, CAN, USB, RS-485, or GPIO-level PWM and direction lines. The exact interface matters because it determines command frequency, observability, fault reporting, and synchronization with the rest of the robotic stack.

In ROS 2, the typical signal path is short and well defined. A navigation node publishes a commanded body velocity. That command is converted to wheel targets and sent to the hardware interface. The motor controller executes the low-level loop and returns wheel state data used to compute odometry.

Layer	Typical function	Common ROS 2 element
Navigation	Path following, obstacle avoidance	Nav2
Base kinematics	Convert body twist to wheel velocities	`diff_drive_controller`
Hardware interface	Transport to controller, read encoders	`ros2_control` hardware plugin
Motor controller	Current, speed, direction, protections	Vendor firmware or MCU firmware
Motor and gearbox	Generate wheel torque	Physical drivetrain

For differential-drive rovers such as Leo Rover, the body-to-wheel conversion is defined by standard mobile robot kinematics. If v is linear velocity, ω is angular velocity, L is wheel separation, and r is wheel radius, then wheel angular velocities are:

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

The motor controller does not compute global navigation. It executes these wheel-level targets reliably and with bounded error.

Key parameters and metrics

Motor controllers are selected and evaluated using electrical, control, and interface parameters. In UGV work, torque demand during start-up, slope climbing, and obstacle crossing is usually more important than nominal free-run speed. The controller must also match the battery voltage, motor type, encoder interface, and communication method used by the rover.

The following parameters are the most important during integration and verification.

Supported motor type – brushed DC, BLDC, or stepper. UGV traction systems commonly use brushed DC or BLDC.
Input voltage range – must match the platform power bus, for example 2S to 6S battery ranges depending on design.
Continuous and peak current – defines sustained and transient torque capability.
Control mode – open-loop PWM, closed-loop velocity, current, or position.
Feedback interface – quadrature encoder, Hall sensors, absolute encoder, current sense.
Command update rate – often 10 Hz to 100 Hz from ROS 2, while internal control loops may run in the kHz range.
Telemetry rate – encoder counts, RPM, current, temperature, fault flags.
Latency and jitter – directly affect wheel speed tracking and odometry quality.
Protection features – overcurrent, overtemperature, undervoltage, short-circuit, watchdog timeout.

For ROS-based mobile robots, two metrics are operationally important. First, wheel state feedback should be fast enough for stable odometry, commonly tens of hertz or more. Second, the controller should support deterministic stop behavior if command updates stop. A watchdog timeout on the controller side is preferred to relying only on application-level logic.

Motor controllers in ROS 2

ROS 2 does not define a single mandatory message type for motor controllers. In practice, integration follows the control abstraction used by ros2_control. The controller manager communicates with hardware through state and command interfaces such as wheel joint velocity, position, and optionally effort. For a differential-drive base, the standard arrangement is to expose left and right wheel joints and let diff_drive_controller handle kinematics.

The message entering the mobility stack is often geometry_msgs/msg/Twist on /cmd_vel. The motor controller itself usually never sees this message directly. Instead, it receives wheel-level targets through a hardware plugin.

diff_drive_controller:
  ros__parameters:
    left_wheel_names: ["left_front_wheel_joint", "left_rear_wheel_joint"]
    right_wheel_names: ["right_front_wheel_joint", "right_rear_wheel_joint"]
    wheel_separation: 0.38
    wheel_radius: 0.065
    publish_rate: 50.0
    cmd_vel_timeout: 0.5
    use_stamped_vel: false
    open_loop: false

In this setup, publish_rate: 50.0 means odometry and controller state are published at 50 Hz. The actual low-level motor loop usually runs much faster inside the embedded controller firmware. This separation is normal and desirable.

ros2 topic pub /cmd_vel geometry_msgs/msg/Twist \
"{linear: {x: 0.2, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.3}}" -r 10

If the hardware driver reports wheel positions and velocities correctly, ROS 2 can compute odometry on /odom and maintain the transform chain required by REP 105 frame conventions, where odom and base_link are standard mobile platform frames.

Practical context on Leo Rover and Raph Rover

On Leo Rover, the motor controller must be considered part of a compact embedded stack built around a Raspberry Pi compute unit and a four-wheel skid-steer chassis. Although the rover supports ROS 2, autonomous navigation is not provided out of the box. Reliable low-level wheel control is therefore a prerequisite for adding SLAM, Nav2, or custom autonomy functions.

In practice, this means the motor controller should provide stable wheel velocity control, encoder feedback for odometry, and safe stop behavior for indoor and outdoor experiments. Because Leo Rover is often used in education and research, clear interfaces and reproducible control timing matter as much as raw power. A poor controller can introduce wheel asymmetry, deadband, or drift that later appears as localization error.

Raph Rover operates in a different regime. As a larger platform intended for higher payloads, it may carry heavier sensors, edge compute, or custom instrumentation. That increases traction load, inertia, and current demand. Here, controller current limits, thermal design, regenerative behavior, and transport robustness such as CAN-based communication become more important. The core role is the same, but the sizing margins and fault handling requirements are stricter.

Common integration issues and trade-offs

Motor controller problems often appear as navigation problems. Wheel slip, inconsistent encoder scaling, and low-rate telemetry can degrade odometry long before a failure is visible at the hardware level. For that reason, controller verification should include both electrical and ROS 2 tests.

The most common trade-offs are straightforward.

Open-loop PWM vs closed-loop velocity – open-loop control is simpler but less repeatable under changing load.
UART/USB vs CAN – simple serial links are easy to prototype; CAN is usually better for noise immunity and fault isolation on larger platforms.
High gear reduction vs responsiveness – more torque improves terrain capability but reduces speed and can amplify backlash effects in odometry.
Controller-side odometry vs host-side odometry – controller-side computation reduces host load; host-side computation is easier to inspect and modify in ROS 2.

A good validation procedure includes wheel radius calibration, wheel separation calibration, watchdog stop tests, current logging under peak load, and comparison of commanded versus measured wheel velocity.

Normative references and standards

In ROS systems, the most relevant references are the official message and frame conventions rather than a dedicated ROS motor controller standard. geometry_msgs/msg/Twist, nav_msgs/msg/Odometry, and REP 105 are directly relevant to differential-drive integration. If ros2_control is used, the hardware interface must expose command and state interfaces consistent with the controller configuration.

For terminology, engineering usage distinguishes the actuator, the drive electronics, and the control loop. In embedded robotics practice, “motor controller” commonly refers to the drive electronics plus its firmware. Vendor datasheets remain the primary source for current limits, voltage range, switching frequency, encoder support, and protection features. Those values must be taken from the exact hardware revision used in the rover.