Standing still is not the same as doing nothing

The machine looks idle. The power meter disagrees. A humanoid can stand motionless at a workstation while joint controllers stabilize posture, sensors watch the environment, processors maintain world models, networks exchange traffic, cooling carries residual heat away and the battery-management system watches every cell. Nothing visible is happening, yet the robot is still spending energy to remain ready.

Fraunhofer IPA's 2026 benchmark of a Unitree G1 EDU-4 makes the point unusually concrete. Under the institute's test conditions, the robot averaged about 154 W while standing, about 272 W while walking on level ground and about 283 W on a 10 percent incline. Its defined one-hour standard scenario averaged about 239 W. Those values are platform- and test-specific, not generic humanoid constants, but the standing result is strategically important: a machine can consume more than half of its measured level-walking power while producing no translational work. Fraunhofer also reports a maximum operating time of 2 h 49 min while standing and 1 h 49 min in a mixed standing-and-walking scenario. [1]

The implication is easy to miss if efficiency is measured only during motion. A robot that saves ten percent during a demanding walking sequence can give much of that advantage back by remaining fully awake through long pauses. Industrial work is full of them: a conveyor stops, an interlock remains closed, a human handover slips, a quality decision is delayed, a tool is missing, a network response arrives late. Availability and productivity are not the same operating state.

The useful question is no longer only, “How efficient is the robot while moving?” It becomes, “How much energy does the robot consume across the full mission, including the minutes in which almost nothing appears to happen?” The measured contrast between standing and walking makes that hidden load visible below.

Idle is not one state

Calling all nonproductive time “idle” hides the engineering decision. Five seconds of waiting at a workstation and thirty minutes on a docking station may both look inactive to a production scheduler, but they demand different levels of readiness.

During a brief pause, the robot may still need balance control, obstacle detection, authenticated network reception and immediate resumption of a manipulation sequence. Shutting down central perception, collapsing network links and relaxing actuator control could reduce instantaneous power while increasing transition cost and response delay. The machine is not inactive. It is attentive.

During a much longer pause, the physical problem can change completely. Docking, sitting or external support can remove the need for continuous balancing. High-performance compute can potentially suspend, cameras and lidars can enter lower-power modes, large actuator domains can be isolated, thermal systems can slow, and only a small supervisory domain may remain energized. The robot remains part of the factory system, but the capability it must deliver immediately has changed.

This distinction already exists inside modern electronics. Operating systems and silicon platforms use multiple idle, suspend, retention and off states because there is no single best answer to the trade-off between power and resume latency. Linux runtime power management explicitly notes that changing device power state costs both time and energy and recommends delaying runtime suspend until a device is likely to remain unused for a meaningful interval. [5] Robotics needs the same logic at machine scale.

The key architectural move is to stop treating “awake” and “off” as the only robot-level states. A humanoid needs a readiness hierarchy that can degrade capability intentionally, safely and reversibly.

A five-state readiness hierarchy

A useful starting framework is five robot-wide states: Full Active, Task Active, Attentive Idle, Safe Standby and Deep Sleep. These names are proposed system-level terminology. They are not an industry standard and should not be confused with the power-mode labels used by a particular MCU, processor or SoC.

Full Active is the peak-capability condition: locomotion, manipulation, perception, communication and compute resources are available according to the current operating envelope. It may be needed for dynamic whole-body motion, complex manipulation or rapidly changing scenes.

Task Active keeps the capabilities required by the current job but allows unused subsystems to scale down. A stationary manipulation task may not need full locomotion capability. A logistics walk may not need dexterous hand compute at maximum performance. This is where workload-aware frequency scaling, core management, sensor duty cycling and local power domains can reduce energy without changing the task.

Attentive Idle is the state of short waiting. The robot remains safe, context-aware and quickly responsive, but expensive activity is reduced. High-rate perception may fall back to low-rate monitoring; compute clocks may scale down; unused joints may enter lower-power holding strategies where mechanically permitted; and cooling can follow the new thermal load.

Safe Standby assumes a more stable physical condition: docked, seated, mechanically supported or otherwise protected against uncontrolled motion. Large actuator and compute domains can be switched off or suspended. A trusted supervisory domain remains active to monitor battery, selected safety signals, wake sources, timing, communications and the orderly restoration of the machine.

Deep Sleep is the lowest-energy planned state short of complete shutdown. Most functional domains are off. Retained information is deliberately limited. Wake is slower and may require substantial requalification before the robot is permitted to move. Deep Sleep should be understood as a mission-management choice, not as an instruction to force every component into its deepest silicon state.

The important property is monotonic loss of immediate capability as energy falls. Lower power should correspond to a clearly defined reduction in what the robot can safely promise. The proposed hierarchy below makes that exchange explicit: energy and immediate capability fall together, while the burden of waking increases.

Every power state needs four contracts

A state name is not enough. “Standby” becomes dangerous when different engineering teams interpret it differently. The mechanical team may assume brakes are engaged. The compute team may assume localization remains valid. The communications team may assume wake-on-network is active. The safety team may assume a watchdog remains independent. All four can be internally consistent and collectively wrong.

The ambiguity disappears only when each robot-level state carries four explicit contracts.

The energy contract defines what may consume power and the expected power envelope. It is not only a watt target. It identifies powered domains, allowable peaks, thermal consequences and transition energy. If the cooling loop must remain active to protect a recently stressed actuator, that obligation belongs in the state definition.

The readiness contract defines which capabilities remain immediately available. Can the robot maintain balance? Can it detect a person approaching? Can it receive a production command? Can it hold a payload? Can it execute an emergency stop path? Readiness must be expressed in functional terms, not merely in electrical rail status.

The wake contract defines what may restore capability and how quickly. A timer, authenticated Ethernet packet, proximity sensor, battery event, safety input, touch signal or human command may all be valid wake sources in different states. The contract also defines whether the trigger wakes the whole machine or only the next supervisory layer.

The state-integrity contract defines which information is still trustworthy after time spent in the state. This is the least familiar and possibly the most important. Retained RAM can preserve bytes perfectly while the physical world changes around the robot. Joint references, object locations, maps, network sessions, safety assumptions and thermal limits age at different rates. A valid resume therefore requires a policy for what can be reused, what must be checked and what must be reconstructed.

Together, the four contracts turn power management from an optimization hint into an executable system architecture. The four-contract model below shows why a watt target alone is insufficient: every energy decision is tied to capability, wake behavior and the validity of retained state.

The silicon already knows how to sleep

The component mechanisms are already familiar. Modern embedded processors and microcontrollers provide the primitives needed for a hierarchy: dynamic voltage and frequency scaling, clock gating, power gating, retained memory, low-power timers, wake pins, watchdogs, RTC alarms, autonomous peripherals and hardware-managed power domains.

NVIDIA's Jetson Orin software stack, for example, exposes CPU idle, wake-from-idle, wake-from-sleep, DVFS, CPU/GPU frequency governors, power monitoring, thermal management and configurable power profiles. NVIDIA's nvpmodel framework can constrain online CPU cores and maximum frequencies for CPU, GPU and other engines, illustrating the distinction between reducing active-state power and entering a true suspended state. [6][7]

At the supervisory end of the spectrum, automotive and industrial MCUs show a different pattern. Infineon's AURIX TC3xx power-management architecture supports multiple standby power domains, wake events from RTC, timer and pin sources, and standby RAM. Its Standby Controller is a small controller that continues running while the main SoC is in standby, with watchdog, timers, RTC, serial interfaces and local memory. [3][4] That architecture is close to what a humanoid needs conceptually: a low-power trusted island capable of observing selected conditions while the expensive processing fabric is asleep.

The engineering challenge appears when these mechanisms are distributed across dozens of controllers, smart sensors, network switches, motor inverters and high-performance compute devices. Each component has its own transition graph and assumptions. A camera may resume before its clock is synchronized. A network switch may need link training. A drive may boot into a torque-disabled state. A central computer may retain DRAM but lose external sensor continuity. The robot-level state machine must orchestrate these local behaviors into one coherent capability transition.

Component sleep modes solve local electrical problems. A humanoid needs something stricter: a power-state supervisor that understands dependencies and can prove that a local transition still produces a valid robot-level state.

The robot still needs a nervous system at 3 a.m.

Standby design starts with an uncomfortable question: what is the smallest part of the robot that cannot be allowed to disappear? The answer should be small, but it cannot be zero.

The always-on domain is the minimum trustworthy nervous system that remains available while major compute, sensing and actuation domains are suspended. Its exact composition depends on the robot and its safety concept, but a plausible design includes battery supervision, selected voltage and temperature monitoring, timekeeping, watchdogs, a secure wake controller, limited authenticated communications, power-sequencing control and the ability to observe a small set of wake-capable sensors.

This domain should be architecturally distinct from the high-performance computer it supervises. If the main AI computer must be awake in order to decide whether the main AI computer can sleep, the design has already lost most of the opportunity. Likewise, a wake-on-network path that depends on a large switch fabric, multiple PHYs and a general-purpose OS may cost far more than a deliberately narrow low-power command channel.

The AURIX standby-controller pattern demonstrates that a physically separate low-power execution island can continue to run watchdog, timer, RTC and communication functions while the main processing domains are in standby. [4] The exact silicon choice is not the point. The architectural principle is.

Security belongs here as well. A sleeping robot remains an asset connected to a factory and capable of motion after wake. Wake sources therefore need authentication and rate limiting where appropriate. A nuisance packet should not be able to wake hundreds of watts of compute and actuators repeatedly. A malicious actor should not be able to convert power-state transitions into a denial-of-service mechanism. Fraunhofer's benchmark explicitly includes cybersecurity and system behavior under failures alongside energy, a useful reminder that low-power design cannot be separated from trust. [1]

The always-on domain is therefore not merely a low-power island. It is the root of authority for bringing the physical machine back to life. The architecture below separates that supervisory island from the much larger switched domains it controls.

Waking is a system event, not a voltage event

Voltage can return before capability does. That gap is where unsafe assumptions accumulate.

A typical wake sequence may start with the supervisory controller validating the wake source and battery condition, then enabling intermediate rails, clocks and network islands. Local controllers boot or resume. Communication links establish. Time synchronization converges. Sensors begin producing data. The central computer resumes applications. Motor drives execute self-checks. Mechanical brakes may remain engaged until control authority has been re-established. Only after required state has been requalified should torque and motion permissions propagate.

The order is not an implementation detail. Actuators should not be energized before trustworthy command paths exist. Perception should not be treated as current before timestamps and sensor health are coherent. A brake should not release because a processor has booted; it should release only when the required system preconditions are satisfied.

Wake latency is therefore layered. There is electrical wake latency, compute-resume latency, network-ready latency, perception-ready latency, localization-ready latency, actuator-ready latency and finally mission-ready latency. A datasheet value for MCU wake time describes only one small part of this chain.

This is why the readiness hierarchy should use externally meaningful metrics. An Attentive Idle state may promise continuous obstacle monitoring and rapid restoration of task motion; a Safe Standby state may promise authenticated command reception while accepting a longer, explicitly measured path back to controlled motion. The thresholds belong to the machine and mission profile, not to a processor datasheet.

The distinction between warm and cold restart also becomes architectural. Retained memory can shorten resume, but the more state that is retained, the more state must be validated. A cold restart discards context and costs time; a warm restart preserves context and creates a trust problem. Neither is inherently superior.

For a humanoid, sleep is physical

A server can suspend while sitting in a rack. A humanoid may be carrying a box at shoulder height on two legs.

Gravity makes robot sleep state-dependent on posture and contact. Removing actuator torque from a gravity-loaded joint can create motion even when the control command is zero. Industrial motion-safety practice treats suspended or vertical loads accordingly: safe brake control is used to engage mechanical holding brakes when an axis is at standstill, and risk assessment must address unintended movement if power disappears or a brake fails. [9]

For a humanoid, the same principle expands to the whole body. Can the robot enter Safe Standby while standing freely? Perhaps on a machine with mechanically locking joints, reliable brakes and a validated static posture. Perhaps not on a machine that requires continuous motor torque to maintain balance. The answer is design-specific.

A robust architecture should make low-power states conditional on mechanical support. Docking is therefore more than charging. A docking station can become an energy-management device: it can support body weight, constrain motion, provide a known reference pose, engage mechanical interfaces and remove the need for continuous balancing. Sitting can serve a similar function. A fixture at a workstation can allow an arm to unload a payload before the power state changes.

Stored energy must also be considered. Springs, counterbalances, elastic transmissions, lifted payloads, pressurized systems and hot actuators do not become harmless because a processor sleeps. The state machine must know where physical energy remains and which monitoring functions are still required.

This is where the familiar “PC sleep” analogy breaks. Humanoid sleep is an electromechanical state, and the safe electrical configuration depends on posture, contact and stored physical energy. The three cases below show why free-standing, seated and mechanically supported robots can justify very different power decisions.

The whole robot should not share one power state

A humanoid is already a distributed machine. Forcing that distributed body into one monolithic power state wastes the very modularity built into it.

Consider a stationary inspection task. The legs may only need posture and safety capability. One arm may be manipulating. The other arm may be parked. Head perception may be active. High-performance vision compute may be needed, while dexterous-hand processing on the parked side is not. A single global “active” state forces all of these subsystems toward the capability level of the busiest one.

Zonal power management allows local states to differ under a robot-wide policy. Arms, legs, hands, perception modules, central compute, communication infrastructure and cooling can each have local power states, provided dependencies are explicit. The robot-wide state becomes a constraint set rather than a single voltage switch.

The dependency graph is the difficult part. A sleeping camera may remove a safety function. A powered-down arm controller may also remove a network bridge used by another device. Disabling a compute accelerator may reduce heat enough to stop a fan, but restarting the fan late can violate thermal limits during wake. Powering down a leg domain may be illegal while the body is unsupported. A sensor rail may be shared by both a mission sensor and a wake sensor.

Good architecture therefore separates three concerns: functional zoning, electrical zoning and communication zoning. They should align where practical but must not be assumed to be identical. The shutdown graph should be machine-readable, version-controlled and testable, with explicit prerequisites and rollback behavior.

That creates a distinct systems-engineering object: the robot's power dependency model. It should be as deliberate as the network topology or safety concept, because local power savings are valid only when shared dependencies remain satisfied. The zonal example below shows how several local states can coexist inside one robot without becoming independent of one another.

Retained bits are not necessarily retained truth

A robot wakes into a world that may have continued without it. That is exactly the wrong moment to trust retained memory blindly.

Suppose the central computer retained a localization estimate during standby. While it slept, a human moved the robot half a meter on its dock. The bytes are intact. The estimate is false. Or consider a grasped object that was removed, a pallet that advanced, a door that closed, a map segment that changed, a battery that cooled, a thermal limit that tightened, a security credential that expired or a network master that restarted.

Power-state architecture therefore needs state aging. Every retained object should have a validity rule based on elapsed time, observation continuity, physical constraints or explicit re-verification. Some state can remain authoritative: cryptographic counters in protected retention, for example, may be deliberately preserved. Some can remain provisional: a map may still be useful but require alignment. Some must be discarded: obstacle tracks based on stale sensor frames should not survive as if nothing happened.

This creates a requalification pipeline. On wake, the robot checks time integrity, communication identity, battery and thermal envelopes, mechanical pose, joint references, sensor health and environmental consistency. Localization may need relocalization. Cameras may need exposure stabilization. IMUs may need bias handling. Safety channels may need self-tests. Drives may need state confirmation before torque enable.

The process should be risk-weighted. Deep Sleep has a larger requalification burden than Attentive Idle because more observation continuity has been lost. That burden is part of the wake contract and part of the energy calculation. A state that saves power but requires expensive repeated reconstruction can be operationally inferior.

The distinction is fundamental: memory retention is an electrical property; truth retention is a systems property.

The lowest-power state is not always the lowest-energy choice

Every transition has a price. The robot may consume extra energy to save context, shut down rails, park joints, engage brakes, restart processors, spin cooling, re-establish links and requalify state. It also loses productive time while waking.

Linux runtime power-management guidance makes the same point at device scale: state changes cost time and energy, so suspend should be delayed unless the device is expected to remain idle long enough. [5] At robot scale, the break-even interval can be expressed simply.

If an attentive state consumes power P_A, a deeper state consumes P_S, and the combined entry-plus-exit transition costs energy E_T, then the energy-only break-even time is approximately:

t_BE = E_T / (P_A - P_S)

That is only the first layer. A production robot also pays for wake latency. If an interruption arrives during Deep Sleep, the lost cycle time can be worth more than the electrical energy saved. The optimal policy therefore depends on the probability distribution of the next task arrival, not simply the expected pause duration.

A practical controller could choose states using four inputs: predicted idle duration, transition energy, required response time and confidence in the prediction. High confidence in a long pause favors deeper sleep. Low confidence or a strict response-time requirement favors Attentive Idle. If docking mechanically enables much lower power, the planner may decide that a short relocation to the dock is worthwhile only beyond a second break-even threshold.

Prediction can improve the policy, but the core problem does not require speculative intelligence. Classical scheduling, state machines and measured transition models are enough to capture substantial value once the robot exposes explicit states and transition costs. The break-even construction below shows why the lowest-power state can still be the wrong choice for a short interruption.

Measure the mission, not the moment

Once power states are explicit, energy efficiency becomes an operational quantity rather than a laboratory curiosity.

The primary metric should remain mission energy: total electrical energy consumed to complete a defined mission at the required safety, quality and timing. It can then be normalized as energy per productive hour, per completed cycle, per transported kilogram, per pick or per unit of useful work, depending on the application.

Several secondary metrics expose where the energy goes. State occupancy shows the share of mission time spent in Full Active, Task Active, Attentive Idle, Safe Standby and Deep Sleep. Nonproductive-energy share shows how much battery energy is consumed while no useful task output is being produced. Wake latency should be measured from accepted wake event to mission-ready capability, not merely to processor execution. False-wake rate reveals whether sensors or communications are repeatedly pulling the robot into expensive states. Transition success rate captures reliability. Requalification frequency indicates how often retained context fails validation and forces a more expensive recovery.

Fraunhofer IPA's benchmark is useful because it already measures standing, walking, incline and mixed scenarios rather than quoting only a battery capacity or peak power number. [1] A next step for the industry would be to add explicit state occupancy and transition measurements to mission profiles. The objective is not to replace capability benchmarks but to connect capability with operational energy.

For engineering teams, a useful commissioning artifact would be a state-transition matrix containing measured steady-state power, entry energy, exit energy, entry time, mission-ready wake time, allowed wake sources, physical prerequisites and required requalification checks. That table can be validated on every software release and across battery temperature, payload and aging conditions.

At fleet level, the questions become direct: how many productive minutes does a battery deliver, how much charging infrastructure is required, and how much nominal robot capacity is being lost to machines that are waiting while electrically fully awake?

Physical AI must learn how much of itself to keep awake

Humanoid battery-life discussions usually converge on better cells, more efficient motors, regeneration, lighter structures and faster AI accelerators. All matter. Yet mission energy also leaks through a less visible path: capability that remains powered simply because the robot is available.

The solution is not aggressive shutdown. A robot that saves energy by giving up required balance, safety observation or response time has not become more efficient; it has simply violated the mission. The correct objective is minimum mission energy at the required readiness.

A five-state hierarchy—Full Active, Task Active, Attentive Idle, Safe Standby and Deep Sleep—provides one workable architecture. Its value comes from the four contracts underneath it: energy, readiness, wake and state integrity. Those contracts force electrical design, mechanics, compute, networking, software and safety to agree on what the robot can promise in each state.

The semiconductor mechanisms are already available. Modern compute platforms can scale activity and suspend domains; embedded controllers can retain selected memory, keep RTCs and watchdogs alive, react to wake events and supervise power sequencing. [3][4][6] The harder work is robot-level orchestration, especially when gravity, stale world state and distributed dependencies turn “sleep” into a physical systems problem.

A mature humanoid should not consume maximum resources merely because it is available. It should know when full capability is necessary, when attention is enough, when mechanical support makes deeper sleep safe and when a wake event requires the world to be learned again before motion resumes.

Physical AI is usually defined by its ability to perceive, decide and act. A mature machine must make one more decision before any of those: how much of itself needs to be awake to act safely.