Embodied AI: Why Having a Body Changes the Problem

Physical AI and embodied AI get used interchangeably, including by people who should be precise about it. The overlap is real. But there is a distinction worth keeping, and it is not academic.

Physical AI describes what a system does: it senses and acts on the physical world. Embodied AI describes where the intelligence comes from: the claim that having a body, with specific sensors and specific actuators, shapes what a system can learn and how it must be built.

Put differently, physical AI is a deployment category. Embodied AI is a claim about the nature of the problem. This post is about the second one, because it is the part that changes engineering decisions.

The body is not a peripheral

The conventional pipeline treats the machine as an accessory: collect a dataset, train a model, deploy it behind an API, attach it to hardware. It works for classification. It breaks for control, for a specific reason.

In a closed loop, the system's own actions determine the data it sees next. A policy that drifts slightly left sees a left-drifting world and trains on it. The independent, identically distributed assumption underneath most of supervised learning simply does not hold once the model is steering. This is why a perception model with excellent offline metrics can be unusable on a robot, and why teams keep rediscovering it.

The consequences are concrete:

• Proprioception is a first-class input. Joint angles, motor currents, IMU data and contact forces are often more informative than the camera, and always cheaper.
• The morphology encodes competence. A leg's compliance solves part of the balance problem in mechanics rather than in software. Good hardware makes the learning problem smaller.
• Failure is physical. You cannot roll back an actuator. Exploration in the real world has a repair bill.

Case study: learned control that actually shipped

Boston Dynamics is the useful case here because they publish engineering detail rather than demo reels, and because they arrived at learned control from a classical-controls tradition that had already worked.

Their published work on reinforcement learning for Spot describes training and deploying a fully learned control policy on production hardware, including an explicit procedure for quantifying the sim-to-real gap using only onboard sensing, and then optimizing simulation parameters against that measurement. That last step is the whole discipline in one sentence: they did not assume the simulator was right, they measured how wrong it was and closed the gap deliberately.

On the humanoid side, Atlas learns manipulation tasks by practicing across many simulated variations, and carries three onboard computers handling control, perception and estimation. Everything runs on the machine.

Two lessons transfer to any embodied program. First, sim-to-real is a measurement problem before it is a training problem. Second, learned policies work best layered over a controls stack that already handles the physics, not instead of one.

Case study: when the body is a planet away

The Perseverance rover is the extreme case of embodiment, because the round trip to a human operator is measured in minutes and the vehicle is unrecoverable. JPL's autonomy work splits navigation into perception, localization, and planning and control, and continues to push more of that stack onboard: Drive-By Science and Energy-Optimal AutoNav both aim to let the vehicle decide more for itself, with EOA explicitly optimizing driving distance against available energy.

An energy-optimal navigation stack is the clearest statement of the embodied position we know. The route is not chosen by what is shortest or safest in the abstract. It is chosen by what this body, with this battery, on this terrain, can afford. Intelligence and physiology are not separable there.

What this means for how you build

If you accept the embodied framing, several standard practices change:

1. Instrument the body before you train anything. Log proprioception, currents and temperatures from day one. Most teams have cameras and no idea what the joints were doing.
2. Budget for a sim-to-real measurement, not just a simulator. The deliverable is a number describing how far off simulation is, and it should be tracked like a test metric.
3. Keep a deterministic layer under the learned one. Envelope protection, geofences, force limits. This is also what makes the system accreditable.
4. Treat energy as a control input. If your planner does not know the state of charge, it is planning in a world your robot does not live in.
5. Design where the boundary sits. Which decisions may the machine take alone, and which require a verified human? Enforce that in the system rather than in a policy document, the same principle behind the Human Exclusion Zones in our own verification work.

The energy argument, again

Embodiment and power efficiency are the same conversation. A body that must carry its own compute cannot carry a data center's worth of it.

Event-driven processors are a good match for embodied sensing specifically because embodied sensing is sparse. Most of the time, nothing has changed. A conventional processor pays full price for that nothing, every clock cycle. A spiking network pays almost nothing until something moves. On sensory and pattern-recognition workloads, that architectural difference is commonly measured at 100x to 1,000x lower energy per inference, and in our own lab it was the difference between 9 watts and 120 watts at matched accuracy.

That is not a marginal saving. It is the difference between a perception system that runs for a shift and one that runs for an hour, which is to say the difference between a product and a demonstration. The longer argument is in why neuromorphic computing matters.

An honest limit

Embodied AI is genuinely harder than the current discourse suggests, and the humanoid form factor is the most oversold part of it. A body is expensive, fragile and slow to iterate on. Where the mission allows a simpler morphology, a simpler morphology will get there sooner and cost less to keep running.

The teams making real progress are unglamorous about this. They constrain the environment, pick hardware whose mechanics do some of the thinking, measure the sim-to-real gap instead of assuming it away, and keep a deterministic floor under everything learned. That is not a limitation of the field. It is the field.