Calculating your robot’s power requirements means building a complete power budget: listing every component that draws current, estimating its average and peak current consumption, summing these to find total average and peak current, multiplying by operating voltage to determine wattage, and then using runtime requirements to calculate the battery capacity (in mAh or Ah) needed—a systematic process that prevents undersized batteries, overloaded wiring, brownout resets, and unexpectedly short run times before the first wheel ever turns.
There is a particular frustration that visits almost every robotics beginner: the robot is fully assembled, the code is uploaded, and on the very first real test run the motors start, the whole robot stutters, the microcontroller resets, and everything stops. The robot tries again. Same result. What just happened?
The answer, almost always, is a power budget problem. The motors drew a surge of current on startup. That surge caused the battery voltage to sag below the minimum operating voltage of the microcontroller. The microcontroller reset. The robot saw this as a startup condition and immediately tried to drive the motors again. Repeat indefinitely.
This scenario—and many variations of it—is entirely preventable. A power budget calculated before building the robot would have identified that the battery’s internal resistance was too high for the expected motor surge current, or that the wiring was too thin for the peak current, or that a capacitor across the power bus was needed to smooth the surge. Five minutes of arithmetic on paper could have prevented hours of debugging frustration on the bench.
This article gives you the complete, practical process for calculating power requirements for any robot—from a simple two-motor rover to a complex multi-arm platform. By the end, you’ll know exactly how to size a battery, select wire gauges, identify voltage regulation needs, and anticipate the current conditions your robot will encounter in real operation.
Why Power Budget Calculations Matter
A power budget is a complete accounting of where electrical energy goes in your robot—what each component consumes, when it consumes it, and what the total demand means for the battery and wiring. Building this budget before construction serves three critical purposes.
Sizing the battery correctly. Without a power budget, battery selection is guesswork. Too small a battery means short runtime and poor performance near the end of discharge. Too large a battery wastes money and weight—both of which matter in mobile robots. A power budget tells you exactly what capacity you need.
Preventing brownout and reset failures. If peak current demand exceeds the battery’s delivery capability or causes excessive voltage sag, microcontrollers reset, motor drivers fault, and sensors lose their calibration state. A power budget reveals these problems before they occur.
Sizing wiring safely. Every wire has a maximum current rating. Exceeding it means heat generation, potential fire, and damaged insulation. A power budget identifies the maximum current through each section of wiring, enabling correct wire gauge selection throughout the robot.
Planning voltage regulation. Most robots have multiple voltage domains—12V for motors, 5V for microcontrollers, 3.3V for sensors. A power budget shows how much current each domain needs, enabling correct selection of voltage regulators with adequate current ratings.
Step 1: List Every Component That Draws Current
The foundation of a power budget is a comprehensive component inventory. Start with a clean spreadsheet or table and list every single component in the robot that consumes electrical power.
Don’t forget easily overlooked consumers:
- LED status indicators
- Buzzer or speaker
- The microcontroller itself (not just what it controls)
- Voltage regulators (they consume a small amount of current themselves)
- Communication modules (WiFi, Bluetooth, radio receivers)
- Fans for cooling
- Any relay coils
- Display screens or LCD modules
- Any always-on sensor that doesn’t sleep
Component Inventory — Example Differential Drive Robot:
Drive and actuation:
□ Left drive motor + gearbox (Pololu 150:1 with encoder)
□ Right drive motor + gearbox (Pololu 150:1 with encoder)
□ Left motor driver (DRV8833)
□ Right motor driver (DRV8833)
Computing and communication:
□ Arduino Mega 2560
□ Raspberry Pi 4 (2GB)
□ USB hub (powered from RPi)
Sensing:
□ MPU-6050 IMU (I2C)
□ HC-SR04 ultrasonic sensor ×2 (front and rear)
□ RPi Camera Module v2
□ Left wheel encoder (optical, 3.3V)
□ Right wheel encoder (optical, 3.3V)
Power infrastructure:
□ 3S LiPo battery (source, not a consumer)
□ DC-DC buck converter (12V → 5V for RPi + Arduino)
□ 3.3V LDO regulator (for 3.3V sensors)
□ Power switch
Status and indicators:
□ Power LED (red, always on)
□ Status LED ×3 (mode indicators, intermittent)
□ Buzzer (brief startup beep, occasional alerts)This inventory becomes the rows of your power budget table.
Step 2: Find Current Consumption for Each Component
For each component in your inventory, you need two current values: quiescent (idle) current — what it draws when present but not doing heavy work — and operating (active) current — what it draws during typical operation. For some components you also need peak current — the maximum brief draw during worst-case conditions.
Where to Find Current Values
Component datasheets are the primary source. Every electronic component has a datasheet specifying typical current consumption in various operating modes. For microcontrollers, look for “supply current” at the operating frequency. For sensors, look for “operating current” or “active current.” For motors, look for “no-load current,” “rated current,” and “stall current.”
Manufacturer product pages often list power consumption for complete modules like the Raspberry Pi. The Raspberry Pi foundation publishes measured current draw at 5V for each Pi model under various load conditions.
Direct measurement with a multimeter in series (ammeter) or a USB power meter is the most accurate method for complex modules like single-board computers, WiFi adapters, and camera modules, where the datasheet value may be conservative or outdated.
Empirical rules of thumb for when datasheets aren’t available:
N20 DC gearmotor: No-load ~50mA, rated load ~200mA, stall ~500-800mA
TT yellow hobby motor: No-load ~100mA, rated ~300mA, stall ~800-1200mA
Standard servo (SG90): Idle ~5mA, moving unloaded ~100mA, stall ~500-700mA
HC-SR04 ultrasonic: ~15mA during pulse, <2mA standby
Generic LED (3mm, 5mm): ~5-20mA (check resistor value to confirm)
Arduino Uno/Nano: ~20-50mA (5V supply, full speed, no external load)
Arduino Mega: ~80-100mA
Raspberry Pi 4 (2GB): ~600mA idle, ~1200mA under CPU load, ~1800mA peak
ESP8266 WiFi module: ~80mA average, ~350mA during WiFi transmission burst
ESP32: ~80mA average, ~240mA during WiFi+BT activity
NEO-6M GPS module: ~35-50mA during acquisition, ~25mA tracking
HC-05 Bluetooth module: ~35mA paired, ~8mA standbyMotor Current: The Critical and Variable Quantity
Motor current consumption is the most important and most variable part of any mobile robot power budget, and it requires special treatment.
DC motors draw current proportional to the torque they produce. The relationship is approximately linear:
Motor current ≈ Stall_current × (Torque / Stall_torque)
No-load current is the y-intercept (current at zero torque)
For a motor with 1A no-load current and 5A stall current:
At 25% of stall torque: I = 1 + (5-1) × 0.25 = 2A
At 50% of stall torque: I = 1 + (5-1) × 0.50 = 3A
At stall: I = 5AFor power budget purposes, use these motor current estimates:
- Idle (robot stationary, motors powered but not running): No-load current × 2 (for back-EMF and driver quiescent losses)
- Normal driving (flat surface, typical speed): 30–50% of stall current
- Heavy load (climbing a ramp, pushing against obstacle): 70–90% of stall current
- Stall (motor blocked): 100% of stall current — brief, but defines peak wire and fuse rating
The single most important rule for motor power budgeting: always size wiring and fuses for stall current, because that condition can and will occur in real operation (robot hits a wall, gripper closes on a hard object, wheels momentarily stuck). Even though stall is brief, the wiring must survive it.
Building the Current Table
With values in hand, populate the power budget table:
POWER BUDGET — Example 3S LiPo Robot (11.1V nominal)
Component | Voltage | Idle (mA) | Avg Op (mA) | Peak (mA)
---------------------|---------|-----------|-------------|----------
Left drive motor | 11.1V | 100 | 400 | 1200
Right drive motor | 11.1V | 100 | 400 | 1200
Left motor driver | 11.1V | 5 | 10 | 15
Right motor driver | 11.1V | 5 | 10 | 15
Buck converter loss | 11.1V | 50 | 80 | 120
5V DOMAIN (via buck):
Arduino Mega | 5V | 80mA→ | 90mA→ | 100mA→
(referred to 12V: | 11.1V | 36 | 41 | 45)
Raspberry Pi 4 | 5V | 600mA→ | 1000mA→ | 1800mA→
(referred to 12V: | 11.1V | 272 | 450 | 811)
RPi Camera | 5V via | 100mA→ | 200mA→ | 250mA→
(referred to 12V: | 11.1V | 45 | 90 | 113)
3.3V DOMAIN (via LDO):
MPU-6050 IMU | 3.3V | 5mA→ | 5mA→ | 5mA→
(referred to 12V: | 11.1V | 1.5 | 1.5 | 1.5)
HC-SR04 ×2 | 5V | 4mA→ | 30mA→ | 30mA→
(referred to 12V: | 11.1V | 1.8 | 13.6 | 13.6)
Encoders ×2 | 3.3V | 10mA→ | 10mA→ | 10mA→
(referred to 12V: | 11.1V | 3 | 3 | 3)
Power LED | 5V | 15 | 15 | 15
Status LEDs ×3 | 5V | 0 | 15 | 45
Buzzer | 5V | 0 | 5 | 50
---------------------|---------|-----------|-------------|----------
TOTAL (at 11.1V) | | 619 mA | 1,534 mA | 3,647 mA
| | 0.62A | 1.53A | 3.65A
Note: Components on regulated domains are converted to equivalent
current at battery voltage using: I_batt = (V_domain × I_domain) / (V_batt × η_reg)
where η_reg is regulator efficiency (assumed 0.85 here)Step 3: Identify Average and Peak Current
From the completed table, extract the two most important numbers:
Average operating current: This determines battery runtime. For the example robot: 1.53A average.
Peak current: This determines minimum battery C-rating, wire gauge for main power lines, and fuse sizing. For the example robot: 3.65A peak (both motors at stall simultaneously).
Note that peak current is dominated by motors. This is almost always true—mechanical loads produce current surges that dwarf the contributions of electronics.
Step 4: Calculate Required Battery Capacity
With average current known, calculate the minimum battery capacity for the desired runtime:
Required capacity (mAh) = Average current (mA) × Runtime (hours) / Efficiency factor
Efficiency factor accounts for:
- Battery capacity is not 100% usable (reserve ~20% to avoid deep discharge)
- Capacity decreases at higher discharge rates
- Aging degrades capacity over time
Practical efficiency factor: 0.75–0.80 (use 0.75 for conservative sizing)
Example robot, desired runtime 45 minutes (0.75 hours):
Required capacity = 1530mA × 0.75h / 0.75
= 1530 mAh
Select: 2200 mAh (next standard size above minimum, provides comfortable margin)
Or: 3000 mAh (for 60+ minutes of runtime)Verifying the C-Rating
Required C-rating = Peak current / Battery capacity (in Ah)
Peak current: 3.65A
Battery capacity: 2.2Ah (2200mAh)
Minimum C-rating = 3.65A / 2.2Ah = 1.66C
Even a 5C battery comfortably handles 1.66C peak.
Select a 20C+ battery for margin — at 20C × 2.2Ah = 44A capability,
the 3.65A peak is trivially within the battery's delivery capability.The C-rating is rarely the binding constraint for small wheeled robots with modest motors—the peak current is usually well below what even a low-rated LiPo can deliver. C-rating becomes critical for robots with large, high-stall-current motors (robot arms, sumo wrestlers, heavy-load carriers).
Step 5: Size the Wiring
Wire gauge must be selected for the maximum sustained current through each wire segment, not the average. Use the peak current values for each segment, add a 25% safety margin, and select the minimum AWG gauge that handles that current:
Wiring sizing for the example robot:
Segment | Max current | +25% margin | Min AWG
---------------------------|-------------|-------------|--------
Battery to main bus | 3.65A peak | 4.56A | AWG 20
(carries all loads) | (use AWG 18 for margin and future expansion)
Main bus to each motor | 1.2A stall | 1.5A | AWG 22
driver | | |
Motor driver to each motor | 1.2A stall | 1.5A | AWG 22
(motor leads) | | |
Main bus to buck converter | 0.81A peak | 1.0A | AWG 24
(5V domain supply) | | |
Buck converter to RPi | 1.8A peak | 2.25A | AWG 22
(at 5V, not battery V) | | |
Buck converter to Arduino | 0.1A peak | 0.125A | AWG 26+
3.3V domain total | 0.02A peak | 0.025A | AWG 28+This systematic approach ensures every wire is sized correctly without over-engineering (using unnecessarily heavy wire everywhere) or under-engineering (creating hot spots in the harness).
Step 6: Plan Voltage Regulation
Each regulated voltage domain in the robot needs a regulator sized for the current that domain demands. Using the power budget, identify the maximum current for each regulated supply:
5V domain consumers (for the example robot):
- Arduino Mega: 100mA max
- Raspberry Pi 4: 1800mA max (peak)
- RPi Camera: 250mA max
- HC-SR04 ×2: 30mA max
- Status LEDs ×3: 45mA max
- Buzzer: 50mA max
Total 5V max: 2275mA ≈ 2.3A
→ 5V regulator must be rated for at least 2.3A
→ Practical selection: 3A buck converter with at least 3A rating
(e.g., MP1584 module, LM2596, or better: a high-quality 3A synchronous buck)
3.3V domain consumers:
- IMU: 5mA
- Encoders ×2: 10mA
- Additional sensors: 15mA
Total 3.3V max: 30mA
→ 3.3V regulator: even a small LDO like AMS1117-3.3 (800mA rated) is fine
(30mA is well within its capability)A critical mistake: selecting a 5V regulator rated at 1A for a system that can demand 2.3A. The regulator overheats, shuts down thermally, and the Raspberry Pi reboots—exactly the kind of intermittent fault that is maddening to diagnose without a power budget.
Step 7: Account for Startup Surge and Inrush Current
When the robot is first powered on, several components draw much higher current than their operating values as they initialize:
Motors: Even in static startup (not commanding motor movement), motor driver chips charge gate capacitances. When motors first receive a PWM command, back-EMF is zero, so initial current is effectively stall current until the motor spins up. For PWM-controlled motors, the first few hundred milliseconds after a speed command can see currents at or near stall.
Capacitors: Large capacitors (100µF+) on voltage rails appear as short circuits at the moment of power application. This inrush current can trip current-limited supplies or blow under-rated fuses.
Single-board computers: The Raspberry Pi draws a significant inrush current as it charges its onboard capacitors and initializes its power management IC.
Mitigation strategies:
Soft-start motor commands: In code, ramp motor commands from 0 to operating speed over 50–100ms rather than jumping immediately to full power. This is good control practice in any case (reduces jerk and mechanical stress) and eliminates the motor startup surge.
// Soft-start motor ramp — reduces inrush current on startup
void softStartMotors(int targetSpeed) {
int currentSpeed = 0;
int rampSteps = 20; // Number of steps to full speed
int stepDelay = 5; // ms per step — total ramp = 100ms
for (int i = 0; i <= rampSteps; i++) {
currentSpeed = (targetSpeed * i) / rampSteps;
setMotorPWM(currentSpeed);
delay(stepDelay);
}
}NTC inrush limiters: Negative Temperature Coefficient thermistors placed in series with the main power input provide high resistance at startup (limiting inrush) and low resistance during operation (minimal power loss). Inexpensive and require no active control.
Pre-charge resistor: A resistor briefly in series with the main power path during initial capacitor charging, then bypassed by a relay or MOSFET after a short delay. Used in higher-power systems.
Staggered power sequencing: Apply power to electronics first (motors disabled), allow capacitors to charge, then enable motor power. Many motor drivers have an enable pin that can be used for this sequencing.
Step 8: Design the Power Distribution Architecture
With all the data collected, design the physical power distribution architecture—how battery power flows to each consumer.
Common Power Architecture for a Mid-Sized Robot
┌─────────────────────────────────────────┐
│ 3S LiPo Battery │
│ 11.1V nominal (9.0–12.6V) │
└───────────────┬─────────────────────────┘
│ 16 AWG (main leads)
┌───────────────▼─────────────────────────┐
│ Main Power Switch │
└───────────────┬─────────────────────────┘
│ 18 AWG
┌───────────────▼─────────────────────────┐
│ Power Distribution Board │
│ (fused outputs for each load section) │
└──┬──────────┬──────────┬────────────────┘
│22 AWG │18 AWG │22 AWG
┌────────▼───┐ ┌───▼──────┐ ┌▼──────────────┐
│Left Motor │ │Right │ │DC-DC Buck │
│Driver │ │Motor │ │12V→5V, 3A │
└────────────┘ │Driver │ └─────┬──────────┘
└──────────┘ │ 5V, 22 AWG
┌──────▼──────────┐
│ 5V Distribution │
│ (RPi, Arduino, │
│ sensors) │
└──────┬──────────┘
│ 3.3V LDO
┌──────▼──────────┐
│ 3.3V sensors │
│ (IMU, encoders)│
└─────────────────┘This hierarchical architecture has several important properties:
Separate motor and logic power paths from the distribution point. Motor switching noise cannot as easily contaminate the logic supply because the two paths separate at the distribution board.
Fused outputs allow individual circuit sections to be protected independently. A motor short trips only the motor fuse, not the logic power—the microcontroller keeps running and can report the fault.
Centralized switching through a single main power switch that disconnects all power at once in an emergency, with the switch rated for the full peak current.
Worked Example: Complete Power Budget for a 4WD Outdoor Robot
To consolidate all the steps, here is a complete worked power budget for a more complex robot:
Robot: 4-wheel drive outdoor exploration robot, 3 kg Motors: 4× 12V DC gearmotors, rated current 0.8A each, stall 3.5A each Compute: Raspberry Pi 4 + Arduino Nano Sensors: GPS, IMU, 4× ultrasonic sensors, stereo camera Battery target: Run for 30 minutes minimum
POWER BUDGET:
Motor loads (12V):
4× motors normal driving (30% load each): 4 × 0.3A = 1.2A
4× motors heavy load (70% load each): 4 × 0.68A = 2.72A
4× motors stall (all 4 simultaneously): 4 × 3.5A = 14.0A ← wire/fuse limit
Electronics (referred to 12V, η=0.85):
Raspberry Pi 4 (average): 1.0A @ 5V → 0.49A @ 12V
Arduino Nano: 0.02A @ 5V → 0.01A @ 12V
GPS module: 0.05A @ 3.3V → 0.02A @ 12V
IMU (MPU9250): 0.004A @ 3.3V → 0.002A @ 12V
4× HC-SR04: 0.06A @ 5V → 0.03A @ 12V
Stereo camera (USB): 0.5A @ 5V → 0.25A @ 12V
Buck converter loss (~5%): ~0.04A @ 12V
TOTALS:
Average operating current (12V): 1.2A (motors) + 0.84A (electronics) = 2.04A
Heavy load current (12V): 2.72A + 0.84A = 3.56A
Peak stall current (12V): 14.0A + 0.84A = 14.84A (brief)
Battery sizing for 30 minutes = 0.5 hours:
Average capacity needed = 2.04A × 0.5h / 0.75 = 1.36Ah = 1360mAh
→ Select 3S LiPo 3000mAh (generous margin, accounts for heavy terrain)
C-rating check:
Peak 14.84A / 3.0Ah = 4.95C
Select 20C+ battery → 20C × 3.0Ah = 60A capability — handles 14.84A peak easily
Main wire gauge:
Peak 14.84A + 25% margin = 18.55A → AWG 16 main battery leads
Motor wire gauge:
Per motor peak 3.5A + 25% = 4.4A → AWG 20 per motor
All 4 motors from distribution: 14A + 25% = 17.5A → AWG 16
5V regulator sizing:
RPi: 1800mA, camera: 500mA, Arduino: 20mA, sensors: 120mA
Total 5V: ~2440mA → select 3A buck converter minimumThis complete budget, done before ordering parts, would have flagged the need for a minimum 3A 5V regulator, AWG 16 main wiring, and a 20C LiPo—details that, if missed, would cause the robot to fail in the field.
Power Budget Template
Use this template as the starting point for any new robot project:
ROBOT POWER BUDGET TEMPLATE
Robot name: ________________ Date: ________________
Battery: __________________ V nominal, _______ mAh, _______C
COMPONENT | VOLTAGE | IDLE (mA) | AVG OP (mA) | PEAK (mA) | NOTES
----------|---------|-----------|-------------|-----------|------
| | | | |
| | | | |
[... add all components ...]
----------|---------|-----------|-------------|-----------|------
TOTALS | Battery | | | |
SUMMARY:
Average current at battery voltage: _______ mA
Peak current at battery voltage: _______ mA
Required capacity (30 min run): _______ mAh
Required C-rating: _______C
Main wire gauge: AWG _____
5V regulator rating needed: _______ A
3.3V regulator rating needed: _______ AFilling in this template before ordering any components takes less than an hour and prevents the most common power-related failures before the first wire is soldered.
Summary
Calculating power requirements is not optional complexity reserved for advanced robot builders—it is essential groundwork that every robot builder should complete before selecting a battery, ordering wire, or choosing regulators. The process follows eight clear steps: inventory every component, find current values from datasheets or measurement, build a complete current table, identify average and peak current, calculate required battery capacity, size all wiring, plan voltage regulation, and account for startup surge.
The insights this process produces are irreplaceable: it tells you the exact battery capacity needed for your target runtime, the minimum C-rating to handle peak loads, the wire gauge needed to safely carry maximum current in every section, and the regulated supply current ratings needed to prevent thermal shutdowns. Each of these parameters, if wrong, causes a specific class of failure—short runtime, voltage sag brownouts, wire overheating, or regulator thermal shutdown. None of these failures are mysterious; they are all direct, predictable consequences of a missing or incorrect power budget.
The next article covers voltage regulators specifically—the components that take your battery’s varying voltage and convert it to the stable, precise voltage levels that sensitive electronics demand, with guidance on selecting, sizing, and correctly implementing them in robot power systems.
Common Power Budget Mistakes and How to Avoid Them
Even builders who do attempt a power budget often make systematic errors that reduce its value. Understanding the most common mistakes sharpens the accuracy of your estimates.
Mistake 1: Using Only Rated (Nominal) Motor Current
Motor datasheets often list a “rated current” at “rated load”—the operating point of maximum efficiency or the intended continuous operating point. This number is not the stall current, and it is not the worst-case current the motor can draw.
For power budgeting purposes, you need three motor current values:
- No-load current (baseline with the motor spinning freely)
- Operating current (at the expected torque load during typical driving)
- Stall current (the maximum possible current, used for wire and fuse sizing)
Using rated current as if it were the only current figure leads to undersized wiring that heats up when the motors experience unexpected load, and a false sense that the peak current is much lower than it actually is.
Mistake 2: Ignoring Regulator Efficiency
When converting battery voltage to lower regulated voltages, the power conversion is not lossless. A linear regulator (LDO) dissipates the voltage difference as heat: converting 12V to 5V at 1A wastes (12-5)×1 = 7W as heat—a 58% efficiency. A switching (buck) regulator is much better—typically 85–95% efficient—but still not 100%.
When calculating current drawn from the battery to power a regulated domain, you must divide the domain’s power by the regulator efficiency to find the battery current:
Battery current for regulated domain =
(Domain voltage × Domain current) / (Battery voltage × Regulator efficiency)
Example: 5V domain drawing 2A total, 12V battery, 88% efficient buck converter:
Battery current = (5 × 2) / (12 × 0.88) = 10 / 10.56 = 0.95A
Ignoring efficiency: 5 × 2 / 12 = 0.83A (17% underestimate)
Over a 1-hour run, this error underestimates battery capacity need by ~150 mAh.For linear regulators, the efficiency penalty is severe enough that they should not be used to supply significant current loads. A linear regulator supplying 1A at 5V from a 12V battery draws the full 1A from the battery (12V × 1A = 12W in, 5V × 1A = 5W out, 7W wasted as heat)—three times worse efficiency than a good switching regulator.
Mistake 3: Forgetting Quiescent Current of Regulators Themselves
Voltage regulators consume a small amount of current for their own internal operation—the quiescent current (Iq). For some regulator types this is negligible (a few microamps for modern switching regulators), but for others it is significant:
LM7805 linear regulator Iq: 5–8mA (negligible for most uses)
LM2596 switching regulator Iq: ~5mA (negligible)
AMS1117 LDO Iq: 4–6mA (negligible)
Some older regulator ICs: 50–100mA Iq (significant in small robots)For most modern regulators, quiescent current adds at most a few milliamps to the budget. But if you’re using older or lower-quality regulator modules, verify the Iq from the datasheet—some cheap buck converter modules draw 10–30mA themselves even with no output load.
Mistake 4: Treating Peak Current as Rare and Ignorable
A common rationalization: “The motors only stall briefly when they hit an obstacle—I don’t need to design for that.” This reasoning is dangerous because:
- Wires don’t know the current is brief. A 30A surge through an AWG 24 wire (rated 0.5A) will damage or destroy it regardless of how brief it is. Wires are rated for continuous current, not surge current.
- Fuses respond to the surge. A correctly sized fuse should blow during a sustained stall to protect the motor from overheating. An undersized wire before the fuse will heat or fail before the fuse blows.
- Peak conditions happen more often than you think. Wall collisions, debris trapped under wheels, gripper closing on hard objects, loose wheels briefly jammed—these are routine events in robot testing and competition, not rare exceptions.
Design wiring for the peak, design batteries for the average. This is the correct power budget philosophy.
Mistake 5: Not Accounting for Battery Voltage Drop Over Discharge
The battery voltage at the start of a run is different from the voltage at the end. A 3S LiPo starts at 12.6V and ends (at safe cutoff) at 9.0V. This 30% voltage change affects every aspect of the robot:
- Motor speed decreases as voltage falls (motors run on voltage, not just current)
- Voltage regulators must work over the entire input range
- Any component with a minimum operating voltage must stay above that threshold throughout the entire discharge, not just at full charge
When selecting buck converters, verify the input voltage range covers from full charge (12.6V for 3S LiPo) down to cutoff (9.0V). Some cheap modules have a minimum input voltage of 10V—they will fail before the battery is safely depleted.
When calculating motor speed at the end of a run, use the minimum battery voltage:
Motor speed is approximately proportional to voltage:
Full charge (12.6V): motor runs at 12.6/11.1 = 113% of "nominal" speed
At cutoff (9.0V): motor runs at 9.0/11.1 = 81% of "nominal" speed
A robot designed for 0.5 m/s at 11.1V will run at:
0.5 × 1.13 = 0.57 m/s when freshly charged (faster than intended!)
0.5 × 0.81 = 0.41 m/s at low battery (slower than intended)
This speed variation must be handled by the control system (closed-loop speed
control via encoders compensates automatically; open-loop control doesn't).Power Monitoring in the Running Robot
A power budget calculated on paper is a planning tool—but monitoring actual power in the running robot gives you real-time insight into whether the design is performing as expected and catches early signs of problems.
Voltage Monitoring
As covered in the battery article, monitoring battery voltage at regular intervals (every 5 seconds is adequate for most applications) provides state-of-charge estimation and early warning of deep discharge. Connect the battery through a resistive voltage divider to an analog pin and sample periodically.
Current Monitoring
Monitoring current draw requires a current sensor in series with the main power line. The INA219 and INA226 are popular I2C current and voltage sensors in robotics that measure both voltage and current simultaneously, reporting power in real time:
// INA219 power monitoring example
// Measures voltage, current, and power at the main battery bus
// Install: Library Manager → "Adafruit INA219"
#include <Wire.h>
#include <Adafruit_INA219.h>
Adafruit_INA219 ina219;
void setup() {
Serial.begin(115200);
Wire.begin();
if (!ina219.begin()) {
Serial.println("INA219 not found — check wiring!");
while (1);
}
// Configure for up to 32V / 2A (default)
// For higher current: ina219.setCalibration_32V_2A() or use INA226
Serial.println("INA219 power monitor ready");
Serial.println("Voltage(V), Current(mA), Power(mW)");
}
void loop() {
float busVoltage = ina219.getBusVoltage_V();
float shuntVoltage = ina219.getShuntVoltage_mV();
float current_mA = ina219.getCurrent_mA();
float power_mW = ina219.getPower_mW();
Serial.print(busVoltage + shuntVoltage / 1000.0, 3);
Serial.print(", ");
Serial.print(current_mA, 1);
Serial.print(", ");
Serial.println(power_mW, 1);
delay(500); // 2 Hz update rate
}Logging current draw from the INA219 during a test run lets you compare actual consumption against your power budget predictions. Discrepancies between predicted and measured current reveal either modeling errors (your estimates were wrong) or design problems (something is drawing more current than it should—a possible sign of a fault or inefficiency).
Energy Consumed (Coulomb Counting)
For precise state-of-charge tracking and accurate runtime prediction, integrate current over time to track total energy consumed—a technique called coulomb counting:
// Coulomb counting for accurate state-of-charge tracking
float batteryCapacity_mAh = 3000.0; // Rated capacity of your battery
float chargeUsed_mAh = 0.0; // Running total of charge consumed
unsigned long lastUpdateTime = 0;
void updateChargeUsed() {
unsigned long now = millis();
if (lastUpdateTime == 0) {
lastUpdateTime = now;
return;
}
float dt_hours = (now - lastUpdateTime) / 3600000.0; // ms → hours
float current_mA = ina219.getCurrent_mA();
// Accumulate charge used (mA × hours = mAh)
if (current_mA > 0) {
chargeUsed_mAh += current_mA * dt_hours;
}
lastUpdateTime = now;
}
float getStateOfCharge() {
return 100.0 * (1.0 - chargeUsed_mAh / batteryCapacity_mAh);
}
float getEstimatedRuntimeMinutes(float currentDraw_mA) {
float remainingCapacity_mAh = batteryCapacity_mAh - chargeUsed_mAh;
if (currentDraw_mA <= 0) return 9999; // Not discharging
return (remainingCapacity_mAh / currentDraw_mA) * 60.0; // hours to minutes
}Coulomb counting combined with voltage monitoring provides the most accurate state-of-charge estimate: voltage tells you where you are in the discharge curve, and accumulated current tells you how much total energy has been extracted.
Power Budget for a Beginner Robot: Simplified Version
For those building a simple first robot, the full 8-step process above may feel daunting. Here is a simplified 3-step version that catches the most critical issues:
Step A: Estimate total current at the battery. Add up the stall current of all motors (this is the worst case) plus 500mA for all electronics. This gives you your worst-case current draw.
Step B: Calculate battery capacity for your runtime. Multiply your estimated average current (roughly 25–35% of stall current for normal driving) by the hours of runtime you want, then divide by 0.7 to add safety margin.
Step C: Check that your battery C-rating handles the worst-case current. Divide your worst-case current (Step A) by your battery capacity in Ah. If the result is less than the battery’s C-rating, you’re fine.
Simplified example — 2-motor beginner robot:
2× TT motors, stall 1.2A each
Electronics (Arduino + sensors): ~0.3A
Worst case: 2 × 1.2A + 0.3A = 2.7A → size wires for 3A+, AWG 22
Average current (30% of stall + electronics):
2 × 0.4A + 0.3A = 1.1A
For 1 hour runtime:
Capacity = 1.1Ah × 1h / 0.7 = 1.57Ah → use 2000mAh battery
C-rating check:
2.7A / 2.0Ah = 1.35C → any battery with 5C or higher is fineThis simplified version takes under 5 minutes and prevents the three most common power budget failures: undersized battery, undersized wiring, and inadequate C-rating.
