AutoPower: Automated Power Control & Modeling

• AutoPower is a term for domain-specific automation paradigms that estimate, allocate, or conserve energy across varied applications such as robotics, CPU design, HPC, wireless transfer, and IoT systems.
• Systems under AutoPower exploit latent structures—like recent power history in robots or decoupled power groups in CPUs—to achieve high prediction accuracy (R² ~0.90–0.97) and significant energy savings.
• AutoPower extends beyond prediction to prescriptive controls, as seen in offline RL for CPU power-capping and occupancy-driven IoT automation, bridging component-level control with overall energy efficiency.

“AutoPower” denotes a set of domain-specific automation paradigms for power prediction, power modeling, power control, and power conservation rather than a single canonical method. In the literature considered here, the name is used most explicitly for a lightweight autoregressive power predictor for GTernal robots in the Georgia Tech Robotarium (Abdelmeguid et al., 14 Mar 2026), a fully automated few-shot architecture-level CPU power modeling framework (Zhang et al., 17 Aug 2025), and an offline reinforcement-learning controller that selects CPU power caps on HPC nodes (Raj et al., 16 Jan 2026). Related usages also include an omnidirectional wireless power transfer scheme with automatic power flow control (Jayathurathnage et al., 2019) and an occupancy-driven IoT room-automation system (Sanaboina et al., 2023). This suggests that the term is best understood as a recurring label for systems that automate the estimation, allocation, or conservation of power in a domain-specific way.

1. Terminological scope and major usages

The shared motif across AutoPower systems is automation of a power-related decision that would otherwise be approximated manually, tuned analytically, or delegated to static rules. In robotics, the automated object is instantaneous power prediction from recent telemetry. In CPU design, it is architecture-level power estimation from a very small number of known configurations. In HPC runtime management, it is online power-cap selection from an offline-trained policy. In wireless power transfer, it is automatic redistribution of transmitter power across orthogonal channels. In room automation, it is occupancy-driven switching of electrical loads (Abdelmeguid et al., 14 Mar 2026, Zhang et al., 17 Aug 2025, Raj et al., 16 Jan 2026, Jayathurathnage et al., 2019, Sanaboina et al., 2023).

Domain	AutoPower form	Core mechanism
Multi-robot systems	Instantaneous power predictor	Autoregressive MLP with recent power history
Early-stage CPU design	Architecture-level power model	Power group decoupling
HPC runtime control	Autonomous CPU power controller	Offline RL over discrete power caps
Wireless power transfer	Automatic power flow control	Three orthogonal Tx–Rp–Rx channels
Room automation	Occupancy-based conservation	Two IR sensors, relays, cloud, Android app

A common misconception is that “AutoPower” names one standardized framework. The literature instead presents several technically distinct systems that share an automation objective but differ in signal model, control loop, hardware substrate, and evaluation metric.

2. Autoregressive robot power prediction

In “Data-Driven Autoregressive Power Prediction for GTernal Robots in the Robotarium” (Abdelmeguid et al., 14 Mar 2026), AutoPower is a lightweight data-driven autoregressive power predictor for the GTernal mobile robot platform in the Georgia Tech Robotarium. Its stated goal is to provide multi-robot planners and learning systems with accurate estimates of instantaneous power draw and ultimately energy usage, so that energy-aware decisions can be made in simulation and on physical robots. The paper argues that traditional kinematic models are too simplistic because they miss motor thermal effects, transient startup or acceleration behavior, sensor and communication overhead, and other latent hardware states.

The empirical basis is a dataset of 48,000 samples collected over 26.5 minutes from one robot across six motion trials, with power ranging from about 3,000 to 8,450 mW and mean 3,652 mW. The GTernal platform is described as a differential-drive robot with footprint 11 cm × 9.5 cm, max linear speed about 26 cm/s, INA260 power monitor, power precision 10 mW, 30 Hz velocity commands, a 100 Hz PID loop, and power telemetry synchronized to the 30 Hz command rate. The core observation is strong lag-1 autocorrelation in power consumption, with $\rho_1 \approx 0.95$, more specifically roughly 0.942 to 0.956 across the six trials and mean 0.949. The paper relates this to an AR(1)-style ceiling $R^2 = \rho_1^2$, implying $R^2 \approx 0.90$ when $\rho_1 = 0.95$. In controlled comparison, velocity-only features gave $R^2 = 0.16$, while adding one lag of power history increased performance to $R^2 = 0.90$ (Abdelmeguid et al., 14 Mar 2026).

The predictor conditions on 11 input features: $v$, $\omega$, $\dot{v}$, $\dot{\omega}$, $R^2 = \rho_1^2$0, $R^2 = \rho_1^2$1, and the five-lag power history $R^2 = \rho_1^2$2, and predicts current power $R^2 = \rho_1^2$3. The model is a multi-layer perceptron with hidden layers $R^2 = \rho_1^2$4, GELU activations, dropout 0.1, and 7,041 parameters. Inputs are z-normalized, output is denormalized to milliwatts, and training uses Adam with learning rate $R^2 = \rho_1^2$5, batch size 256, 100 epochs, early stopping with patience 10, and a split of trials 1–4 for training, trial 5 for validation, and trial 6 for test.

On the held-out steady-state trial, the paper reports $R^2 = \rho_1^2$6, MAE = 31.5 mW, and MAPE = 0.86\%. Across all six trials, mean $R^2 = \rho_1^2$7, with per-trial $R^2 = \rho_1^2$8 from 0.89 to 0.92. Residuals were approximately Gaussian, with mean residual 1.3 mW and 90\% of errors within $R^2 = \rho_1^2$9 mW. Physical validation on seven unseen GTernal robots in a collision avoidance scenario using control barrier functions yielded mean $R^2 \approx 0.90$0, standard deviation $R^2 \approx 0.90$1, mean MAE = 70.7 mW, cumulative energy prediction error below 2.3\% for all robots, and cumulative error under 0.1\% for four robots. Inference takes 224 $R^2 \approx 0.90$2s per step, or 4,500 Hz, approximately 150$R^2 \approx 0.90$3 the 30 Hz command rate. Deployment is provided both as a PyTorch checkpoint and as a NumPy-compatible model; in simulation it can run autoregressively from its own past predictions, while on physical robots it can be corrected each timestep by measured power to avoid drift (Abdelmeguid et al., 14 Mar 2026).

The main significance of this AutoPower instance is methodological: it makes temporal persistence, rather than instantaneous kinematics, the dominant explanatory variable for robot power consumption. A plausible implication is that energy-aware multi-robot algorithms on real hardware should treat recent power history as a first-class state variable.

3. Few-shot architecture-level CPU power modeling

In “AutoPower: Automated Few-Shot Architecture-Level Power Modeling by Power Group Decoupling” (Zhang et al., 17 Aug 2025), AutoPower is a fully automated, few-shot architecture-level CPU power modeling framework for early-stage CPU design. The target problem is fast yet accurate power evaluation during architecture exploration, when repeated RTL implementation, synthesis, and signoff analysis across many design points would otherwise take weeks. The paper positions traditional analytical models such as McPAT and Wattch as fast but often inaccurate, and prior ML-based architecture-level power models as data-hungry.

The framework rests on two observations: clock and SRAM dominate processor power, and clock and SRAM power correlate with structural information available at the architecture level. On that basis, AutoPower introduces a two-level decoupling strategy. First, total CPU power is split into clock power, SRAM power, and logic power. Second, each group is decomposed into submodels tied to structural drivers. For clock power, the decomposition is

$R^2 \approx 0.90$4

with

$R^2 \approx 0.90$5

The paper then defines an effective active rate

$R^2 \approx 0.90$6

so that final clock power is written as

$R^2 \approx 0.90$7

This yields submodels $R^2 \approx 0.90$8, $R^2 \approx 0.90$9, and $\rho_1 = 0.95$0, where $\rho_1 = 0.95$1 denotes hardware parameters and $\rho_1 = 0.95$2 event parameters (Zhang et al., 17 Aug 2025).

SRAM power is modeled top-down as Component $\rho_1 = 0.95$3 SRAM Position $\rho_1 = 0.95$4 SRAM Block $\rho_1 = 0.95$5 SRAM Macro. The hardware model estimates block width, depth, and count from architecture-level hardware parameters using scaling-pattern-based relationships, while activity is predicted from hardware parameters, event parameters, and program-level features. Macro activity is related to block activity through

$\rho_1 = 0.95$6

and SRAM power is then written as

$\rho_1 = 0.95$7

Logic power is split into register power, $\rho_1 = 0.95$8, and combinational logic power, $\rho_1 = 0.95$9. The paper uses linear models with L2 normalization for register count and gating rate, and XGBoost for workload-sensitive submodels such as $R^2 = 0.16$0, SRAM activity, and combinational variation (Zhang et al., 17 Aug 2025).

The evaluation uses Chipyard v1.8.1, RISC-V BOOM, 15 configurations, 8 workloads, Synopsys VCS, Synopsys Design Compiler, PrimePower, gem5, and a TSMC 40nm standard cell library plus memory compiler. With only two known configurations for training, AutoPower achieves MAPE = 4.36\% and $R^2 = 0.16$1, compared with McPAT-Calib at MAPE = 9.29\% and $R^2 = 0.16$2. With three known configurations, it reports MAPE = 3.64\% and $R^2 = 0.16$3. Subgroup results include clock power MAPE = 11.37\% with $R^2 = 0.16$4, SRAM power MAPE = 7.60\% with $R^2 = 0.16$5, and about 6.93\% MAPE on average for the register-count and gating-rate submodels (Zhang et al., 17 Aug 2025).

This AutoPower variant is notable for reframing power modeling as structured decomposition rather than direct regression on total power. The paper’s central claim is that physically meaningful decoupling makes few-shot learning practical at the architecture level.

4. Runtime power control and adjacent power-aware computing

In “Offline Reinforcement-Learning-Based Power Control for Application-Agnostic Energy Efficiency” (Raj et al., 16 Jan 2026), AutoPower is an offline RL controller for HPC CPU nodes. The controller observes

$R^2 = 0.16$6

chooses a CPU power cap

$R^2 = 0.16$7

and applies it through Intel Running Average Power Limit via GEOPM at a 1 Hz control interval. The power-cap range is discretized into 16 uniformly spaced actions between 78 W and 165 W. The reward is

$R^2 = 0.16$8

and is normalized per application into $R^2 = 0.16$9. Training uses Conservative Q-Learning on a dataset of 1,291 transitions collected under a random power-cap policy, with one Q-network of input dimension 5 and output dimension 16, two hidden layers with 10 neurons each, 10,000 iterations, $R^2 = 0.90$0, $R^2 = 0.90$1, and buffer size 128. On a bare-metal Intel Cascade Lake node, the method reports 20.34\% average energy savings, 7.40\% average execution-time degradation, and lower $R^2 = 0.90$2 than the compared baselines; the abstract and conclusion summarize this as about 20\% average energy reduction at about 7.4–7.5\% average performance loss (Raj et al., 16 Jan 2026).

A common misconception is that automated power systems must lower instantaneous wattage. Adjacent computing literature instead emphasizes energy or combined time-power objectives. In “Power Reduction of Automatic Heterogeneous Device Offloading” (Yamato, 2021), automatic GPU offloading on the Himeno benchmark increased power from about 27 W to about 109 W, but reduced energy from 4080 Watt*seconds to 2070 Watt*seconds through a runtime reduction from 153 seconds to 19 seconds. In “Power Saving Evaluation with Automatic Offloading” (Yamato, 2021), automatic FPGA offloading on MRI-Q reduced energy from 1,690 Watt·seconds to 223 Watt·seconds while reducing runtime from about 14 seconds to about 2 seconds and reducing server power from about 122 W to about 111 W. Both papers use the combined fitness

$R^2 = 0.90$3

which encodes the same principle: automatic power optimization can prefer higher instantaneous power if total energy falls (Yamato, 2021, Yamato, 2021).

An adjacent infrastructural strand is “SmartWatts: Self-Calibrating Software-Defined Power Meter for Containers” (Fieni et al., 2020), which does not use the AutoPower name but addresses a prerequisite for many automated power-control systems: fine-grained measurement. SmartWatts models host power as

$R^2 = 0.90$4

learns frequency-aware linear models for dynamic power from hardware performance counters, and triggers online recalibration when the error

$R^2 = 0.90$5

exceeds a threshold. Reported accuracy is PKG error < 4 W on average and DRAM error < 0.5 W on average at 2 Hz, with calibration taking only a couple of milliseconds (Fieni et al., 2020). This suggests that runtime AutoPower control and automated power attribution are tightly coupled research directions.

5. Physical power-flow control and occupancy-driven conservation

In “Omnidirectional Wireless Power Transfer with Automatic Power Flow Control” (Jayathurathnage et al., 2019), the AutoPower idea is realized as automatic redistribution of transmitter power in a wireless power transfer system with three orthogonal Tx–Rp–Rx channels. The architecture uses three orthogonal transmitter coils and three repeater coils, arranged so that cross coupling between channels is negligible. Under the derived circuit model, the current in each transmitter is proportional to the corresponding coupling term, so the power drawn from each transmitter automatically adjusts depending on the mutual inductance between the receiver and the Tx–Rp pair. Negative mutual inductance is handled by transmitter-side polarity reversal, effectively replacing $R^2 = 0.90$6 with $R^2 = 0.90$7. The prototype operates at 593 kHz, is tested with the receiver moving on a circle of radius 200 mm, and reports DC-to-DC efficiency close to 90\% over the full angular range (Jayathurathnage et al., 2019).

In “An Automated Power Conservation System (APCS) using Particle Photon and Smartphone” (Sanaboina et al., 2023), APCS is described as a low-cost IoT-based “AutoPower” solution for room-scale energy conservation. The system uses a Particle Photon microcontroller, two IR obstacle sensors, a two-channel relay module, ThingSpeak, and an Android app. Occupancy is inferred from the order of two sensor activations at a doorway: if IR1 detects first and IR2 follows within a 15-second window, the system increments a person-count variable; if IR2 detects first and IR1 follows, it decrements the count. When count is greater than zero, lights and fans are turned ON; when count reaches zero, they are turned OFF. The Android app supports monitoring and remote manual override. The paper reports successful operation in both automatic and manual modes and claims that APCS can save almost 15\% of power per month (Sanaboina et al., 2023).

These two systems illustrate a prescriptive form of AutoPower: the objective is not prediction of power as a latent variable, but direct automatic reallocation or suppression of power flow in a physical environment. The technical commonality lies in event-driven actuation: mutual inductance changes in the WPT case, and occupancy-count transitions in the APCS case.

6. Broader significance, adjacent vehicle-control research, and recurring misconceptions

Across the literature, AutoPower systems differ most sharply in whether they are predictive or prescriptive. Predictive instances estimate power from telemetry or structural variables, as in Robotarium autoregression and architecture-level CPU modeling (Abdelmeguid et al., 14 Mar 2026, Zhang et al., 17 Aug 2025). Prescriptive instances directly choose a power allocation or power-cap action, as in offline RL for HPC nodes, wireless power redistribution, and occupancy-triggered switching (Raj et al., 16 Jan 2026, Jayathurathnage et al., 2019, Sanaboina et al., 2023). A plausible implication is that the term is increasingly attached to automation around power-related decision loops, not to any single model class.

A second misconception is that automated power methods are necessarily detached from task-level behavior. Adjacent vehicle and powertrain literature shows the opposite. “Optimization of Power Control for Autonomous Hybrid Electric Vehicles with Flexible Power Demand” (Kargar et al., 2023) defines an AutoPower setting in which the lower-level controller is allowed to choose a flexible driveline torque $R^2 = 0.90$8 and reports a 14.1\% fuel economy improvement from flexible-demand AutoPower relative to fixed demand. “Optimal Vehicle Dynamics and Powertrain Control for Connected and Automated Vehicles” (Zhao et al., 2019) uses a two-level architecture in which a vehicle-dynamics controller shapes the speed trajectory and a powertrain controller optimizes engine–motor torque split. “A stochastic power management strategy with skid avoidance for improving energy efficiency of in-wheel motor electric vehicles” (Jalalmaab et al., 2017) reports about 22\% reduction in power consumption relative to equal distribution in the NYCC-on-slippery-road case and about 3\% average energy consumption reduction across tested scenarios. “Comprehensive Energy Footprint Benchmarking Algorithm for Electrified Powertrains” (Anwar et al., 2021) and “Real-Time Dynamic Optimal Power Flow in Electric Vehicles Considering the Lifetime of the Components in the E-Powertrain” (Mohagheghi et al., 2020) extend the same principle to mixed-integer powertrain optimization, eco-driving, thermal dynamics, and lifetime-aware optimal power flow. This suggests that AutoPower-type automation increasingly sits at the interface between energy objectives and system-level behavior rather than purely within a component-level controller.

The central technical lesson across domains is that successful AutoPower systems exploit latent structure that simple heuristics ignore. In Robotarium, recent power history dominates kinematics. In architecture-level CPU modeling, power-group decoupling makes few-shot learning viable. In offline RL power control, application progress and hardware counters provide a gray-box state for energy-efficient actuation. In WPT, orthogonal channels and polarity switching turn mutual inductance variation into self-adjusting power flow. In IoT room automation, doorway event ordering becomes a sufficient statistic for occupancy-triggered load control. The diversity of these mechanisms is precisely why “AutoPower” remains a productive but non-unified term in current research.