Research and buying guidance
Humanoid robot battery life: runtime versus working hours
Interpret runtime claims, charging and battery changes without confusing powered-on time with useful output.
CompareMyRobot.com · Last reviewed · Published
The short answer
A battery-life figure is a screening input, not a promise of productive hours. Ask for the proposed task, charge conditions and every interruption, then measure accepted work across the full observation period.
Three clocks: runtime, availability and productive time
Manufacturer-stated runtime describes operating duration under stated—or undisclosed—conditions. Availability concerns whether the robot can be dispatched. Productive time concerns execution of accepted work. A robot can be powered on but waiting for an upstream item; it can also be unavailable while charging or being recovered. These categories answer different buying questions.
Agility’s March 2025 announcement describes both battery capability and autonomous docking. Those separate statements illustrate why duration and charging logistics need separate evidence. Neither statement establishes the accepted output of your workflow.
Read the conditions behind “about” and “up to”
The inspected G1 specification uses “About 2h” and labels its battery “Quick Release”. Agility’s dated announcement uses “up to four hours”. These are examples of different manufacturer wording, not a matched comparison. Do not infer that one robot produces twice the useful work of the other.
Request hardware edition, software version, carried object, route, motion pattern, starting charge and stopping rule. If the supplier cannot disclose the conditions, keep the claim qualified rather than substituting your most favourable assumptions.
Evidence: Unitree G1 configuration specifications; Agility: Digit product innovations, 31 March 2025
Capacity is not a duration
Ampere-hours measure electrical charge, not hours of operation. Comparing stored energy requires voltage as well as capacity; estimating runtime additionally requires usable energy and average demand over the workload. Dividing unlike quantities does not produce a reliable operating-time forecast.
Do not use a charger’s output voltage as an undocumented battery-pack voltage, or treat a peak motor-power label as average system consumption. Without the required inputs, request a workload test rather than printing a calculated runtime.
Evidence: Unitree G1 configuration specifications
Charging, quick release and hot swapping
Autonomous docking describes reaching a charging arrangement. A quick-release pack describes removal. Neither alone establishes uninterrupted operation. Ask whether shutdown, restart, cooling or manual handling is required, and follow the approved battery procedure.
Spare packs can introduce separate charging-space, inventory and staffing requirements. Record those practical dependencies in the operating plan instead of assuming that an extra pack removes all downtime.
| Question | Request | If missing |
|---|---|---|
| One charge covers the work block? | Runtime on the actual task and stated stop rule | Use the headline only for screening |
| Charging fits the workflow? | Docking, charge duration and dispatch policy | Do not promise continuous coverage |
| Pack changes avoid interruption? | Approved swap and restart procedure | Do not infer hot swapping |
| Output is sufficient? | Accepted tasks per elapsed observation hour | Do not substitute powered-on hours |
Evidence: Unitree G1 configuration specifications; Agility: Digit product innovations, 31 March 2025
Build a shift ledger
Use mutually exclusive categories: productive execution, ready but waiting, charging or swapping, recovery or intervention, and maintenance. The categories should sum to the observation period. This is an editorial reporting framework, not a universal availability standard.
Report accepted tasks divided by total elapsed trial time, with quality rules declared first. Also report active-time output separately. If retries eventually complete a task, preserve their time and assistance in the log; do not retrospectively erase unsuccessful attempts.
A battery acceptance test you can reproduce
Agree the task envelope and safe test procedure with the supplier. Record configuration, software, battery condition, load, route, environment, initial and final charge, accepted output and interventions. Repeat representative cycles and show variation, not only the longest run.
The next decision is whether the documented combination of task runtime, charging and recovery covers your work block. If it does not, narrow the task or revise the operating plan before treating the robot as shift-ready.
Evidence: Unitree G1 configuration specifications; Agility: Digit product innovations, 31 March 2025
Sources and editorial method
We distinguish source-backed technical explanations from our practical evaluation frameworks. Manufacturer documentation describes its stated configurations; it is not independent testing. The examples and checklists here are editorial guidance, not measured robot performance or safety certification.
- Unitree G1 configuration specifications
Manufacturer table inspected on 24 October 2026. Exact-edition labels matter; undisclosed workload conditions prevent a performance ranking. No catalogue values were changed.
- Agility: Digit product innovations, 31 March 2025
Dated manufacturer announcement separates battery duration from autonomous docking. It does not establish productive shift output under a matched workload.
Scope and limitations
- No firsthand robot testing was performed. Proposed evaluation methods are editorial frameworks, not standards or certified procedures.
- Search demand and keyword volumes have not been verified.
- The dated examples do not verify current shipped battery performance or comparable task conditions.