Glossary

Fictionlab > Glossary > Power budget

Power budget

Power budget – definition

A power budget is a documented calculation of the electrical power and energy required by a mobile robot during a defined operating mission. For an unmanned ground vehicle (UGV), it compares available battery capacity and power-delivery capability with the demand of propulsion, onboard computing, sensors, communication devices, and auxiliary loads.

The power budget must cover both continuous consumption and short-duration peak loads. A robot can have sufficient battery energy for a planned mission while still failing if its battery, power distribution board, wiring, connectors, or DC-DC converters cannot supply the required current during acceleration, climbing, or simultaneous sensor startup.

For Leo Rover and Raph Rover integrations, the power budget is part of system engineering and should be prepared before adding payloads such as a LiDAR, depth camera, GNSS/RTK receiver, NVIDIA Jetson computer, radio modem, or environmental sensor enclosure. The native Raspberry Pi compute unit on Leo Rover also has to be included in the calculation, together with the power required by any external USB devices.

Power, energy, and current in a UGV

Power describes the instantaneous rate of energy consumption. Energy describes how much work can be supplied over time. Both quantities are necessary when estimating whether a mobile platform can complete a route without voltage drop, battery protection shutdown, or an unexpected reboot of the compute unit.

The basic electrical relationships are shown below. In practice, values should be measured at the battery input and at relevant regulated rails, rather than inferred only from nominal device ratings.

P [W] = V [V] × I [A]

E [Wh] = average P [W] × t [h]

Estimated runtime [h] =
usable battery energy [Wh] / average system power [W]

Battery nameplate capacity alone is not enough. A battery rated in ampere-hours must be interpreted together with its nominal voltage to estimate watt-hours. Usable energy can be lower than nominal energy because of battery-management limits, temperature, aging, discharge rate, converter losses, and the configured low-voltage cutoff.

Loads that belong in a mobile robot power budget

A complete budget separates loads by electrical rail and operating state. This makes it possible to identify which device causes a peak current event and whether a regulated supply has enough margin.

  • Propulsion: drive motors, motor drivers, encoders, steering components where applicable, and braking or holding current.
  • Compute: Raspberry Pi on Leo Rover, external x86 computer, NVIDIA Jetson, SSD, USB hub, and cooling fan.
  • Perception: 2D or 3D LiDAR, RGB-D camera, stereo camera, IMU, GNSS/RTK receiver, and illumination.
  • Networking: Wi-Fi, Ethernet switch, LTE or 5G modem, radio bridge, and access point.
  • Auxiliary hardware: payload controllers, relays, indicators, actuators, heaters, and environmental sensors.

Each load should be recorded in a power-budget table using the manufacturer datasheet and an instrumented measurement. Datasheet values define an engineering baseline, while measurements reveal real behaviour under the intended ROS 2 workload.

Parameter Purpose Recommended source
Input voltage range Verifies compatibility with the battery and DC-DC rail. Device manufacturer specification
Typical and maximum power Separates average runtime demand from worst-case sizing. Device datasheet and measurement
Startup or inrush current Prevents brownouts during boot or sensor connection. Manufacturer documentation and oscilloscope measurement
Duty cycle Models intermittent loads such as fans or radios. Mission profile and recorded telemetry
Converter efficiency Accounts for losses between battery and payload rail. DC-DC converter datasheet

Peak power and voltage drop

Motor current is often a dominant variable load on a differential-drive UGV. It changes with terrain, payload mass, wheel slip, acceleration, turning resistance, and slope. A budget based only on stationary motor current is therefore not valid for field navigation.

Voltage drop must also be evaluated across battery leads, fuses, connectors, power switches, and distribution wiring. The simplified relationship is:

V_drop [V] = I [A] × R [Ω]

If the voltage seen by a compute rail falls below the converter input requirement, a Raspberry Pi, LiDAR, USB hub, or network device may reset even when the battery still contains energy. Separating motor power from sensitive compute and sensor rails, while retaining a common electrical safety design, is a common UGV integration practice.

Power monitoring in ROS 2

ROS 2 does not define one mandatory power-budget subsystem. A robot application can publish battery telemetry using sensor_msgs/msg/BatteryState, which includes voltage, current, charge, capacity, percentage, power-supply status, and health fields. The message definition is maintained in the ROS 2 common interfaces documentation.

Power telemetry should be time-stamped and recorded during representative missions. This supports correlation between power events and navigation failures, CPU load, LiDAR activation, or motor commands. ROS 2 distributions follow the release model documented by REP 2000; Leo Rover integrations should use ROS 2 Humble or another distribution supported by the platform software environment.

ros2 topic echo /battery_state
ros2 topic hz /battery_state
ros2 bag record /battery_state /cmd_vel /odom

The command sequence verifies that battery telemetry is available, measures its publication frequency, and stores it with motion data for later analysis. The required topic frequency depends on the battery monitor, mission dynamics, and fault-detection requirements; it should be specified by the system integrator rather than assumed from ROS 2.

Power budgeting for Leo Rover and Raph Rover

On Leo Rover, power planning is particularly important when USB-powered perception hardware and external compute modules are added. The platform supports ROS 2 natively, but autonomous navigation is not provided by default. A navigation stack, sensor suite, and additional compute hardware can materially change the electrical load compared with a basic teleoperation configuration.

Raph Rover is intended for larger payloads and therefore requires the same method at a larger system scale. The budget should include payload power, payload-specific regulators, sensor mounting cables, and the expected terrain profile. A larger platform does not remove the need to verify peak current, thermal conditions, cable losses, or emergency-stop behaviour.

Normative and technical references

The following primary documentation is relevant when implementing power telemetry and ROS 2 software interfaces. Electrical limits must always be checked against the current documentation for the specific battery, motor controller, converter, and sensor used in the robot.

See also