PWM (Pulse-Width Modulation)
PWM (Pulse-Width Modulation) – definition
Pulse-Width Modulation (PWM) is a method of representing a control value with a periodic digital signal whose active-state duration changes while its repetition frequency is normally kept constant. In mobile robotics, PWM is commonly used at the low-level actuator interface: between a microcontroller or single-board computer and a motor driver, electronic speed controller, servo controller, or auxiliary device.
A PWM waveform has two primary timing parameters: period T and pulse width ton. Its frequency and duty cycle are defined as:
f = 1 / T
D = t_on / T × 100%For a DC motor driver, the duty cycle can control the average voltage applied to the motor terminals when the driver switches the supply through a power stage. The effective motor torque and speed are not determined by duty cycle alone. They also depend on supply voltage, driver topology, current limits, motor back-EMF, load, friction, and the closed-loop control method.
In a UGV, PWM is not an autonomy interface. It is an electrical or timing-level interface below ROS 2 navigation, velocity control, odometry, and safety logic. A ROS 2 node usually converts a high-level velocity command into actuator-specific PWM outputs through a motor-controller protocol or a microcontroller firmware layer.
PWM modes used in mobile robots
The term PWM is used for several different interfaces. These interfaces should not be treated as interchangeable because they use different signal semantics, voltage levels, timing constraints, and safety behavior.
| Interface type | Control variable | Typical UGV use | Integration note |
|---|---|---|---|
| DC motor PWM | Duty cycle | Motor drive command | Usually combined with direction pins, an H-bridge, or signed command logic. |
| RC-style pulse command | Pulse width within a repeating frame | Servo actuators, some ESCs, steering modules | This is a timed pulse protocol, not simply duty-cycle control. |
| Motor-controller PWM input | Vendor-defined PWM range | Legacy motor controllers and embedded control boards | The controller datasheet defines neutral, direction, fault, and input-loss behavior. |
| Power PWM | Duty cycle at a switching stage | Fans, LEDs, heaters, power regulation | Requires electrical design appropriate for voltage, current, EMI, and thermal load. |
A motor driver must switch motor current, not merely expose a logic-level PWM pin. Raspberry Pi GPIO pins are logic interfaces and must not be connected directly to a traction motor. GPIO electrical limits and logic levels must be verified against the Raspberry Pi documentation and the selected driver specification.
PWM in ROS 2 control architectures
ROS 2 does not define a universal pwm topic, standard PWM message, or mandatory duty-cycle range. ROS 2 nodes exchange semantic commands such as linear velocity, angular velocity, steering angle, or actuator setpoint. The hardware interface converts those values into PWM only when PWM is the required device-level protocol.
For a differential-drive UGV, the control path commonly contains the following stages:
- A navigation or teleoperation node publishes a velocity command.
- A kinematic controller converts body velocity into left and right wheel targets.
- A motor-control layer applies limits, ramping, direction control, and optional closed-loop PID control.
- The hardware layer outputs PWM, serial commands, CAN frames, or another controller-specific interface.
- Encoders provide wheel feedback for odometry and velocity regulation.
ROS coordinate conventions are defined by REP 103. For ground vehicles, the conventional robot body frame uses x forward, y left, and z up. A PWM mapping must preserve these sign conventions so that a positive linear.x command produces forward motion and positive angular.z produces counter-clockwise yaw.
# Example ROS 2 body-velocity command.
# The hardware bridge or ros2_control hardware interface performs PWM conversion.
ros2 topic pub --once /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.0}}"The exact command topic and message type are deployment-specific. Some systems use geometry_msgs/msg/Twist; others use stamped messages or controller-specific command interfaces. The interface definition should be checked with ros2 topic info, ros2 interface show, and the documentation of the deployed ROS 2 controller.
Key PWM parameters and safety constraints
PWM settings must be selected from the motor driver, ESC, or actuator datasheet. A higher switching frequency can reduce audible noise and current ripple, but it can also increase switching losses and electromagnetic interference. A lower frequency can increase torque ripple or produce audible operation. There is no safe universal frequency or duty-cycle range for UGV motor control.
Before enabling PWM on a mobile platform, verify the following parameters at the hardware boundary:
- Logic voltage compatibility between the controller output and driver input.
- Required PWM polarity, frequency, timing range, and neutral-state behavior.
- Maximum motor current, peak current, thermal dissipation, and power supply limits.
- Direction-change handling, including any dead time required by the driver.
- Watchdog behavior when ROS 2 communication, the compute unit, or the command stream fails.
- Encoder feedback availability for closed-loop wheel-speed control and odometry.
A robust implementation also clamps commands, applies acceleration limits, and forces PWM to a documented safe state on timeout. These functions should be implemented independently of Nav2 or any higher-level autonomy stack.
PWM on Leo Rover and Raph Rover
Leo Rover is a four-wheel differential-drive UGV that can use a Raspberry Pi as its onboard computer and supports ROS-based software integrations. In this context, PWM is relevant when extending the platform with custom motor electronics, auxiliary actuators, payload control boards, or a dedicated microcontroller. It is not a replacement for the rover’s documented motor-control interface.
For Leo Rover, a practical design separates high-level ROS 2 processes from real-time signal generation. A microcontroller can receive a bounded command through serial, CAN, or another supported interface, generate PWM with deterministic timers, read encoders, and apply watchdog logic. This reduces sensitivity to Linux scheduling jitter on the Raspberry Pi.
Raph Rover provides a UGV platform for higher-payload integrations. Custom payloads may require PWM-controlled sensors, lighting, pump modules, steering components, or motor subsystems. The payload power budget, connector pinout, grounding, fuse protection, and electromagnetic compatibility must be verified for the specific Raph Rover configuration before connecting a PWM-controlled device.
Normative references and technical sources
The following sources define the ROS conventions and hardware-level context relevant to PWM integration:
- ROS REP 103 – Standard Units of Measure and Coordinate Conventions.
- ROS 2 documentation – interfaces and message types.
- ros2_control documentation, including hardware interfaces and controller integration.
- Raspberry Pi documentation, including GPIO and electrical-interface guidance.
- Leo Rover technical documentation.