Section 45.5: Energy efficiency; sim-to-real and safety in locomotion

"A locomotion policy that ignores heat and power is outsourcing the hard part to the battery."

A Field Deployment Checklist

A policy that works in simulation but collapses on wet concrete is not a transfer success: it is a transfer claim that was never tested.

Two quadrupeds cross the same 300 m inspection route at the same speed; one returns with 40% battery to spare and the other strands itself halfway, and the only number that separates them is the one most demo reels never report. That number is cost of transport (CoT), \(\mathrm{CoT} = E / (mgd)\), where \(E\) is energy spent over distance \(d\) for mass \(m\). It lets researchers compare controllers across robot size and runtime. The same controller can improve speed while worsening CoT enough to make battery-limited missions impossible.

CoT matters because robots operate under a hard energy budget. A battery pack is finite, and a policy that wastes energy on unnecessary stabilizing torques or inefficient gait phases (a gait cycle is one repeating unit of leg motion, e.g. one full stride; "phases" are the stance and swing sub-steps within it) cuts mission range directly. A CoT increase of 20% on a 48 kg platform running at 1.5 m/s can halve usable range on a standard battery, turning a viable inspection route into a stranded robot mid-deployment.

In practice, \(E\) is measured as the sum of electrical energy delivered to all actuators over the run, sampled from motor current and voltage at each joint. The denominator normalizes by weight and distance so that a heavy robot and a light one are comparable. Computing CoT on hardware requires synchronized joint-level power logging at 100 Hz or finer; a single dropped logging window invalidates the figure for that trial.

Once CoT is measured, the usual levers for lowering it are: penalizing joint torque and jerk directly in the reward so the policy stops "fighting itself" with opposing muscle-like torques, shaping the gait toward lower-impact footfalls that need less corrective stabilization, and reducing unnecessary body-pitch oscillation that wastes energy on repeated acceleration and braking. Each lever trades against speed or robustness, which is why CoT is reported alongside the safety-stop count rather than optimized alone.

From Energy to Transfer

Frame sim-to-real transfer as a residual model problem. The residual \(\delta(x_t, u_t)\) captures the gap between the simulator's prediction and real dynamics: \(x^{\mathrm{real}}_{t+1} = f_{\mathrm{sim}}(x_t, u_t) + \delta(x_t, u_t)\). System identification, randomization, and fine-tuning each shrink that residual or harden the policy against it. Safety logic must operate on the residual-aware closed loop, not on the simulator's output alone. A narrow randomization range compounds badly. A policy that trains for 40,000 episodes on dry surfaces still fails on wet tile. Widen the friction envelope to cover that regime and the same policy generalizes after roughly 3,000 more episodes, because training now includes the residual the policy must tolerate. The stakes are concrete: a policy trained without friction randomization produces zero safety stops across 50 simulation episodes. Deploy it on wet-tile terrain and the same policy triggers 8 stops in the first 10 runs. Expanding the randomization envelope to cover low-friction surfaces brings that count back down to 1 stop in 10.

Figure 45.5.1 lays out this discipline as a closed loop: observe resource and safety state, model the transfer gap, act within the validated envelope, and verify on hardware traces before the cycle repeats.

Theory

A field-ready locomotion controller solves a multi-objective problem. You are trading task time, energy, actuator temperature, contact stress, and safety margins simultaneously. Optimizing one while hiding the others is how impressive lab videos become expensive hardware failures.

One of those hidden objectives, the transfer residual, deserves its own accounting, because a controller that balances the trade-offs in simulation can still misjudge every one of them on hardware. Transfer methods are only comparable when evaluated on the same hardware panel. Domain randomization, actuator modeling, residual learning, and hardware fine-tuning all help, but their value changes with how much of the real residual is actually represented.

Consider a specific case. Boston Dynamics Spot runs a learned trot policy trained entirely in Isaac Lab with domain randomization (training across many randomly varied simulated physics parameters, such as friction or payload, so the policy does not overfit to one exact simulated world) over floor friction (0.4 to 1.2), actuator damping (plus or minus 20%), and payload mass (0 to 5 kg). On polished concrete the velocity tracking error stays below 0.08 m/s. On a wet ramp it spikes to 0.31 m/s and trips the safety supervisor (the layered monitoring logic defined later in this section, under "Algorithm: Transfer-And-Safety Deployment Loop") within two gait cycles. The randomization range covered dry surfaces but not wet-ramp slip dynamics, so training left the residual for that terrain patch unrepresented. This is the canonical pattern: a transfer claim reaches only as broad as the terrain and actuator conditions that entered the randomization envelope.

Because no randomization envelope can anticipate every terrain patch the robot will meet, the controller needs a second line of defense for the residual it was never trained on, and that defense is where safety logic enters. Safety logic should be layered. Fast inner loops prevent immediate falls or torque spikes. Slower supervisory logic can reduce speed, widen gait, trigger re-localization, or stop the robot when the residual leaves the validated envelope.

Worked Example

A small deployment summary can expose whether a faster policy is actually the better field controller once energy and safety are priced in.

energy_j = 18200
mass_kg = 48
distance_m = 320
g = 9.81
safety_stops = 2

cot = energy_j / (mass_kg * g * distance_m)
print(f"cost_of_transport={cot:.3f}")
print({"safety_stops": safety_stops, "deployment_ok": safety_stops <= 1 and cot < 0.14})

Expected output interpretation. The energy figure is acceptable, but the safety-stop count fails the deployment criterion. This is exactly why energy and safety must live in the same artifact rather than in separate dashboards.

Practical Recipe

1. Define deployment thresholds for CoT, thermal excursions, safety stops, and velocity tracking before testing.
2. Replay the same command traces in simulation and on hardware to estimate the residual gap.
3. Evaluate the same scenario panel under nominal and degraded conditions, including battery sag or low-friction patches.
4. Add runtime monitors that can reduce speed or halt before the low-level controller saturates.
5. Store every deployment run as a transferable artifact with telemetry, summary metrics, and intervention labels.

This section is where embodied AI becomes operations engineering. The hardest variables are not abstract control gains but current draw, actuator wear, battery chemistry, and the organizational cost of false safety stops.

It also shows why sim-to-real is never one scalar gap. The transfer residual has structure: delays, friction mismatch, compliance, sensor timing, estimator drift, and operator response. Decomposing that structure is the skill worth teaching.

When field transfer fails, assign blame to the dominant residual first: actuator model, terrain mismatch, sensing delay, estimator drift, or safety supervisor interaction. Otherwise teams waste time tuning the policy around the wrong bottleneck.