[ Evidence and evaluation · no robots operated here ]
Physical AI
Learned models are being asked to act in the physical world, where the system’s own actions decide what it sees next and a mistake has consequences. These pages explain the methods — world models, vision-language-action policies, learning from demonstration, domain randomization, uncertainty and monitoring — and say plainly what each published result establishes.
This section is the learning and modelling companion to robotics evidence and evaluation, which owns the hardware, the evidence records and the safety boundaries. Where a subject belongs to both, robotics keeps the evidence record and these pages link to it rather than publishing a second version.
Start here
- What “physical AI” means, and how it relates to robotics and control
Physical AI is the use of learned models to perceive and act in the physical world under real time, real sensors and real consequences. It is a perspective on robotics, not a replacement for it, and it inherits everything control engineering already knows about feedback.
- The loop is the system: perception, state, action, consequence
A physical AI system is a loop, not a pipeline. Its own actions change what it will observe next, which is why accuracy measured on a fixed dataset does not predict behaviour when the policy is driving.
- Vision-language-action models: what the success rate means
A vision-language-action model maps images and an instruction directly to robot actions, using a pretrained vision-language backbone. Reported success rates describe the tasks, objects and embodiments that were evaluated, and generalise no further on their own.
All 16 explanations
- What “physical AI” means, and how it relates to robotics and control
Physical AI is the use of learned models to perceive and act in the physical world under real time, real sensors and real consequences. It is a perspective on robotics, not a replacement for it, and it inherits everything control engineering already knows about feedback.
- The loop is the system: perception, state, action, consequence
A physical AI system is a loop, not a pipeline. Its own actions change what it will observe next, which is why accuracy measured on a fixed dataset does not predict behaviour when the policy is driving.
- World models, and what an agent does with an imperfect one
A world model is a learned predictor of what happens next. Training a controller inside one is efficient and introduces a specific failure: the controller can learn to exploit the model’s mistakes instead of solving the task.
- Vision-language-action models: what the success rate means
A vision-language-action model maps images and an instruction directly to robot actions, using a pretrained vision-language backbone. Reported success rates describe the tasks, objects and embodiments that were evaluated, and generalise no further on their own.
- Learning from demonstration and teleoperation
Cloning an expert’s actions is the most direct way to get a policy. Its characteristic failure is that the learner must act in states the expert never visited, and small errors take it there.
- Domain randomization: what it varies, and what transfer it buys
Domain randomization trains a model across randomly varied simulated conditions so that reality looks like one more variation. It buys robustness to the parameters that were randomized, and nothing about the ones that were not.
- Planning and feedback control do different jobs
A planner chooses what to do over a horizon; a feedback controller keeps the system on that choice despite disturbance. Learned policies can replace either, and confusing which one was replaced makes a result unreadable.
- Uncertainty estimates and the inputs a model has never seen
A useful uncertainty estimate rises when the input is unlike training data. Reported methods do this on average; none of them is a guaranteed detector, and an average is not an operating point.
- Runtime monitoring, intervention and what the system does when it is wrong
Behaviour on failure is a design choice that should be specified before deployment: what is monitored, what threshold triggers, what the system does next, and who can intervene.
- What a benchmark score is evidence of
A benchmark score is evidence about that benchmark. Its value depends on whether the tasks, objects and scoring resemble the decision you are making.
- Where the demonstrations came from, and what you are allowed to do with them
A robot dataset carries provenance and permission questions that a model card rarely answers: who was recorded, under which licence, and whether people appear in the frames.
- A runnable perception–action fixture, and what it is not
This section ships a small deterministic simulation of a perception–action loop with latency, noise, an uncertainty monitor, intervention and a failure report. It is a teaching fixture: it demonstrates the accounting, not any robot’s capability.
- State estimation: the system acts on an estimate, never on the world
A controller never sees the state it is controlling. It sees measurements, and acts on an estimate built from them. How much that estimate trusts the newest measurement is a parameter someone chose.
- Reward specification: the objective is a proxy, and the system optimises the proxy
A learned system pursues the objective it was given, not the one that was meant. Where those differ, the difference is not a bug the system will correct — it is the direction the system will move in.
- Fine-tuning a foundation model for control: what web pretraining does and does not transfer
Coupling a pretrained vision-language model to robot actions transfers semantic knowledge the robot data never contained. It does not transfer physical competence, and the evidence for each is different.
- The teleoperation interface is part of the dataset
Demonstrations are not neutral recordings of a task. They record what one operator could do through one interface, and the interface leaves its signature in every trajectory a policy learns from.
Run the fixture yourself
A deterministic one-dimensional perception–action loop with observation noise, actuation delay, a monitor and an intervention path. It reports autonomous success, assisted success, failure or abort — and splits monitor firings into those an injected disturbance explains and those it does not.
node --experimental-strip-types scripts/physical-ai-loop.ts run --actuationDelaySteps 3 node --experimental-strip-types scripts/physical-ai-loop.ts counterexamples
It is a simulation with no physics, contact, hardware or people. See what the fixture is not.
Related sections
- Robotics evidence and evaluation — hardware, evidence intake, safety and the 40-page evaluation corpus.
- Neuromorphic and biocomputing — event-driven sensing and in-memory computing for embodied systems.
- Nanotechnology — the same evidence discipline applied to materials claims.
- Mathematics knowledge system — the formal layer under estimation and control.
Sources read for this section
- Ross, Gordon and Bagnell — A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning (DAgger) ↗
Read at: Abstract; §1 Introduction · inspected 2026-09-19
- Tobin et al. — Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World ↗
Read at: §III-A Domain randomization · inspected 2026-09-19
- Ha and Schmidhuber — World Models ↗
Read at: §4.4 Transfer policy to actual environment; surrounding discussion of model imperfections · inspected 2026-09-19
- Kim et al. — OpenVLA: An Open-Source Vision-Language-Action Model ↗
Read at: Abstract; §1 Introduction · inspected 2026-09-19
- Lakshminarayanan, Pritzel and Blundell — Simple and Scalable Predictive Uncertainty Estimation using Deep Ensembles ↗
Read at: Abstract; §1 Introduction · inspected 2026-09-19
- Yu et al. — Meta-World: A Benchmark and Evaluation for Multi-Task and Meta Reinforcement Learning ↗
Read at: Abstract; §1 Introduction · inspected 2026-09-19
- NIST AI Risk Management Framework ↗
Read at: Overview of the AI RMF — the framework’s own purpose statement · inspected 2026-09-20
- Welch and Bishop — An Introduction to the Kalman Filter (UNC-Chapel Hill TR 95-041) ↗
Read at: §1 The Discrete Kalman Filter — “The Computational Origins of the Filter” and the discussion of equation (1.8); the time-update / measurement-update cycle · inspected 2026-09-20
- Amodei, Olah, Steinhardt, Christiano, Schulman and Mané — Concrete Problems in AI Safety ↗
Read at: Abstract; §3 Avoiding Negative Side Effects; §4 Avoiding Reward Hacking · inspected 2026-09-20
- Brohan et al. — RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control ↗
Read at: Abstract; §1 Introduction · inspected 2026-09-20
- Zhao, Kumar, Levine and Finn — Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware (ALOHA / ACT) ↗
Read at: Abstract; project description of the teleoperation setup · inspected 2026-09-20
Every performance figure on these pages is the original authors’ own reported result on their own evaluation, attributed as such. Maha has replicated none of them, operates no robot, and endorses no system or vendor.