HUMANOID
QUADRUPED
PHYSICAL AI
5 Mins
|
21 SEPT 2026
Summary: Physical AI is intelligence that has to work through a body: actuators and controllers that obey gravity, contact and time. Here's what that takes, with real numbers: the embodiment under the model, the architecture that turns understanding into motion, and the runtime that closes the loop safely, every millisecond.
A robot can work perfectly in a lab and turn unreliable the moment it runs on a real floor. That gap is where physical AI projects get decided. A lab has none of what a real site has: dust, temperature swings, uneven floors, and shifts that run for hours with nobody watching. Everything below is about why a system survives the second one.
Key Components of Physical AI
Embodiment comes first: actuators, gearing and thermal design set the ceiling on what any model can command.
VLA models turn vision plus a text instruction into task understanding; a smaller action head turns that into continuous motion at tens of hertz.
World models let a robot predict an action's outcome before taking it, so it needs fewer real-world attempts to learn.
A safety layer between model and motor is non-negotiable: joint limits, torque limits and fallback controllers.
Training happens on GPU clusters; deployment happens on watt-constrained edge compute, and low-level control never leaves the robot.
1. Intelligence needs a body first
A robot with underpowered actuators fails at dynamic movement no matter how good its software is. A robot with a poorly designed thermal or wiring layout can work fine on a bench and then turn unreliable the moment it runs continuously on a real floor.
This is where actuation does the quiet, unglamorous work everything above it depends on. PMSM actuators, field-oriented-control drivers, quasi-direct-drive systems, and planetary or harmonic gears aren't background specifications; they set the actual space of motion a robot can execute: how fast, how hard and how precisely it can move.
Addverb's own robots make the point concretely. Trakr, our quadruped, and Elixis, our humanoid, share the same underlying AI principles and still need very different intelligence, because each is built for a different body, load and terrain.
Spec | Trakr (quadruped) | Elixis (humanoid) |
Actuators / DoF | 12 actuators | 41 degrees of freedom |
Sensing | 4 stereo cameras | — |
Payload | Up to 20 kg total | 5 kg per hand |
Speed | Slope- and uneven-terrain capable | 1 m/s bipedal walking |
Runtime | 90 minutes | 2 hours |
Trakr's spec sheet exists because a robot built for site inspection and security patrols has to climb slopes and absorb uneven terrain unsupervised. Elixis's torque-to-weight ratio is one a wheeled or fixed-base robot never has to solve for.
2. Where does the training data actually come from?
None of this works without training data, and how that data gets collected, annotated and curated is a large enough problem on its own. If you want the full picture of how teleoperation, human demonstrations and annotation pipelines turn raw robot recordings into usable training data, that's covered in our piece, Why Is Data Annotation Important for Robotics?
3. How do VLA models turn vision and language into action?
The architecture most associated with today's physical AI wave is the Visual-Language-Action (VLA) model: the layer connecting what a robot sees, what a person says, and what it does. A VLA pipeline turns camera images, a text instruction and robot state into a shared token space, then passes that through a language-model backbone that gives the robot task-level understanding: what "pick the red box" means in context.
The scale here is real and public. OpenVLA, one of the best-known open VLA models, pairs a 600-million-parameter vision encoder with a 7-billion-parameter language backbone, trained on roughly 970,000 real robot demonstrations. Despite being an order of magnitude smaller, it beat Google's earlier 55-billion-parameter RT-2-X model by 16.5 percentage points in absolute task success rate across 29 tasks: data diversity and architecture often matter more than raw parameter count.
Understanding isn't a physically usable action on its own. A smaller action generator sits downstream, converting it into something continuous and safe, often through flow matching or action chunking, methods that output a smooth run of movement rather than one decision at a time.
4. World models: teaching a robot to anticipate
VLA gives a robot task-conditioned action. World models give it something different: the ability to ask "what will happen if I do this?" before doing it, the way a child learns gravity, not from an equation, but from watching things fall and stop, over and over.
This isn't theoretical. NVIDIA's Cosmos Predict world model, trained on roughly 200 million video clips, generates coherent predicted futures up to 30 seconds ahead. On NVIDIA's Cosmos Policy kitchen-manipulation benchmark, a Cosmos-based policy matched the strongest prior method using 50 real-world demonstrations instead of 300: six times less data for the same result, and exactly the pattern that makes a world model worth the added complexity.
5. The safety layer that closes the control loop
None of this matters if it can't run fast enough on the robot itself. In a real runtime, a large model interprets the scene and task, a smaller action generator produces candidate actions, and a lower-level controller converts them into joint targets or torque commands, while state estimators keep the robot honest about where its body actually is.
The frequency mismatch is real: an industrial robot arm's native controller often runs at 125 Hz, while a VLA policy above it might produce a fresh action chunk at only 25 Hz. The gap gets bridged by interpolating each predicted step into smaller, evenly spaced sub-steps, so the low-level controller still sees smooth motion at its native rate.
A model that works beautifully offline is worthless if it can't hit the frequency the robot needs in the field. Because high-level AI outputs can be uncertain, this loop always needs a layer digital AI never requires: a safety layer between the model and the motor, with joint limits, torque limits and fallback controllers, so an uncertain output never directly commands an actuator unchecked.
6. Why training happens on servers but running happens on the edge?
Physical AI systems are trained in one place and run in another, and those places pull in opposite directions. Training happens on large GPU clusters, where the constraint is data and scale, because latency doesn't matter yet. Deployment happens on the robot's own edge compute, where power, thermal headroom and determinism now matter more than raw model size.
The edge hardware class has grown fast. NVIDIA's Jetson Orin family, now widely used across humanoid and mobile robotics platforms, spans roughly 40 TOPS at 7 to 15 watts on the smallest module, up to 275 TOPS on the largest, configurable between 15 and 60 watts.
That's the ceiling robotics engineers design against: a large "teacher" model trained on servers gets distilled into a lighter "student" model that fits that envelope, running onboard the robot in real time. Cloud inference can still help where a delay is tolerable, but low-level control stays on the robot: network latency can never be trusted for anything safety-critical.
The throughline
A general model can understand what to do. The actuators, embodiment and controller underneath still have to be tuned to how this particular robot's body lets it do that. That's the real work of physical AI: intelligence and embodiment working as one system, under conditions no training run can fully anticipate.
If you're evaluating a physical AI platform, ask what it was actually tuned on: a demo rig, or a body built for your load, terrain and duty cycle. That answer tells you more than the model's parameter count ever will.
Frequently Asked
What is physical AI?
What is a Visual-Language-Action (VLA) model?
Why do robots need world models?
Why does physical AI run on edge compute instead of the cloud?
