Duty cycle

Duty cycle – definition

Duty cycle is the fraction of one repeating signal period during which the signal is active. In mobile robotics, the term usually describes the high-time proportion of a pulse-width modulation (PWM) signal used by a motor controller, LED driver, actuator interface, or sensor trigger circuit. It is expressed as a ratio, percentage, or normalized value between 0.0 and 1.0.

The duty cycle D is calculated from the active time t_on and the full signal period T:

D = t_on / T

Duty cycle [%] = (t_on / T) × 100

For example, a PWM output with a 20 ms period and a 5 ms high state has a duty cycle of 0.25, or 25%. The PWM frequency is the inverse of the period:

f_PWM = 1 / T

IEEE Std 181 defines duty factor as the ratio of pulse duration to pulse period. In a UGV drivetrain, this value is typically generated inside the motor driver or its embedded firmware, not directly by high-level ROS 2 navigation software. The effective motor voltage, torque response, current draw, and thermal load depend on the duty cycle, PWM frequency, supply voltage, load, and motor-controller topology.

Source: IEEE Std 181-2011, IEEE Standard for Transitions, Pulses, and Related Waveforms.

Duty cycle in mobile robot motor control

On a differential-drive UGV, the left and right wheel sides are controlled independently. A motor controller commonly receives a direction command and a PWM duty-cycle command, then switches battery voltage to the DC motors. A higher duty cycle generally increases the average voltage delivered to the motor terminals, but it does not guarantee a proportional vehicle speed.

Motor speed is affected by terrain resistance, wheel slip, battery voltage sag, payload mass, drivetrain friction, motor back electromotive force, and closed-loop feedback. Therefore, duty cycle should be treated as a low-level actuator command rather than a reliable speed unit.

The following distinctions are important when integrating a mobile platform:

Command duty cycle – the requested PWM ratio sent to a motor driver.
Applied duty cycle – the ratio actually generated after controller limits, current protection, ramping, or deadband logic.
Operating duty cycle – the fraction of time a subsystem is active during a longer mission cycle, such as a sensor running for 10 minutes in every hour.
Thermal duty cycle – the on/off profile used to determine average heating of a motor, driver, relay, or power converter.

For motor drivers, the relevant thermal quantity is often RMS current rather than the PWM value alone. Resistive losses in cables, windings, and switching devices increase approximately with the square of current. A robot climbing loose soil can therefore heat a motor driver significantly even when its commanded duty cycle is lower than during unloaded driving.

Duty cycle and ROS 2 control interfaces

ROS 2 does not define a universal duty_cycle topic, message type, or hardware interface. ROS 2 applications usually command a velocity, position, effort, or acceleration target through ros2_control. The hardware interface converts that target into driver-specific commands, which may include PWM duty cycle internally.

For a differential-drive base, the common high-level path is:

Nav2 velocity command
        ↓
geometry_msgs/msg/TwistStamped or Twist
        ↓
diff_drive_controller
        ↓
wheel velocity command
        ↓
hardware interface / motor controller
        ↓
PWM duty cycle and direction signals

The diff_drive_controller in ros2_control accepts body velocity commands and converts them into wheel commands using wheel geometry. Current versions use geometry_msgs/msg/TwistStamped; support for unstamped Twist messages depends on the controller version and configuration. It is not intended to expose raw PWM as the normal navigation interface. This separation allows odometry, velocity limits, acceleration limits, and wheel feedback to remain independent from a specific motor driver.

Sources: ros2_control documentation; diff_drive_controller documentation; geometry_msgs/Twist documentation.

Duty cycle on Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive platform with an onboard Raspberry Pi compute unit and ROS 2 support. Its normal ROS 2 integration should use the documented base-control interface and wheel feedback rather than bypassing the platform controller with direct GPIO PWM. Direct PWM control can bypass safety limits, feedback handling, command timeout logic, and drivetrain calibration implemented by the supported software stack.

Leo Rover is not an autonomous vehicle out of the box. When Nav2, SLAM, or teleoperation software sends a linear and angular velocity command, the platform control layer converts this request into motor-control commands. Depending on the controller configuration, the resulting PWM duty cycle can change continuously because of acceleration limits, controller logic, and, where available, wheel-velocity feedback.

Raph Rover follows the same engineering principle: motor-controller configuration must be appropriate for the platform’s motors, payload, and operating conditions. Duty-cycle testing on either platform should begin in a low-risk test area, followed by verification under representative payload and terrain conditions. Current limits, thermal monitoring, cable sizing, and braking behavior should be verified against the relevant platform and motor-controller documentation.

Source: Leo Rover technical documentation.

Key parameters to document

A reproducible motor-control integration needs more information than a percentage value. The following parameters should be recorded in the platform configuration, driver documentation, and test report.

Parameter	Purpose	Typical unit
PWM duty cycle	Active fraction of one switching period	% or 0.0 to 1.0
PWM frequency	Switching repetition rate	Hz
Deadband	Command range that produces no wheel motion	% or normalized command
Ramp rate	Maximum command change over time	command/s
Current limit	Protection threshold for motor and driver	A
Command timeout	Time before a missing command causes a stop	s

Inspecting the ROS 2 control path

Before introducing a custom duty-cycle interface, inspect the available hardware interfaces and wheel-state topics. The commands below do not modify motor output. They help identify whether the base exposes velocity, position, or effort interfaces.

ros2 control list_hardware_interfaces
ros2 control list_controllers
ros2 topic list
ros2 topic echo /joint_states

If a custom hardware interface exposes a PWM command topic, its message definition, valid range, timeout behaviour, and safety logic must be documented by the integrator. A normalized value of 0.25 should not be assumed to mean 25% duty cycle unless the driver specification explicitly defines that mapping.

Standards and implementation considerations

ROS coordinate frames and physical units should follow REP 103. It specifies SI units for ROS conventions, including seconds, metres, radians, velocity in metres per second, and angular velocity in radians per second. PWM duty cycle itself is dimensionless, but it must not be confused with a ROS velocity command.

For autonomous navigation, use wheel velocity feedback, odometry, IMU data, and appropriate sensor fusion rather than estimating motion from duty cycle. The same PWM value can produce different wheel speeds on carpet, gravel, grass, slopes, or when battery voltage changes.

Source: REP 103 – Standard Units of Measure and Coordinate Conventions.