The physical AI stack is a set of connected responsibilities: data, simulated environments, models, robot interfaces, runtime hardware and operations. Map the interfaces and evidence at each layer before assuming that a collection of compatible-looking tools forms a deployable system.
Identity boundary. Original PhysicalAI.best editorial guide. Source links support factual examples; evaluation questions and decision rules are editorial guidance, not upstream endorsements.
Data and provenance
Begin with the observations, actions and outcomes used for training or evaluation. Track collection hardware, operator involvement, scene coverage and dataset terms. DROID documents a shared collection platform, while Open X-Embodiment aggregates constituent datasets. A common storage format does not make every sensor, action convention or license identical. The data contract is an integration artifact as well as a provenance record.
google-deepmind · Publication date not disclosed · Source accessed 2026-09-28
Official README inspected live. Repository code terms do not automatically cover model weights, data, or third-party assets.
Simulation and task environments
Separate the simulator from the benchmark or task definition that runs on it. MuJoCo is a physics engine; Isaac Sim and Isaac Lab serve distinct simulation and learning workflows. Choose the environment around the required sensors, contacts, assets and experiment. Pin versions and record configuration changes, because a simulator upgrade or altered success rule can change what a result means.
isaac-sim · Publication date not disclosed · Source accessed 2026-09-28
Official README inspected live. Repository code terms do not automatically cover model weights, data, or third-party assets.
Models and adaptation tooling
Identify the checkpoint and the tools used to train, adapt or serve it. OpenPI and LeRobot expose software workflows; their presence in a stack does not specify a single universal policy or a complete supported robot. Record observation preprocessing, action normalization, local task data and execution configuration. Keep the software license distinct from the terms for model weights and training datasets.
huggingface · Publication date not disclosed · Source accessed 2026-09-28
Official README inspected live. Repository code terms do not automatically cover model weights, data, or third-party assets.
Robot interfaces and control
Connect the model’s outputs to the actual robot interfaces. ROS 2 provides an ecosystem for components and messages, but a distribution label is not proof that a particular camera, arm or controller is supported. Assign responsibility for drivers, calibration, command limits, state feedback and recovery. Document the tested interface versions rather than relying on a broad compatible-with-ROS statement.
ros2 · Publication date not disclosed · Source accessed 2026-09-28
Official README inspected live. Repository code terms do not automatically cover model weights, data, or third-party assets.
Runtime and compute
Select compute for the actual workload and physical installation. The Jetson AGX Thor Developer Kit is a specific development product, not a guarantee about every robot using the same processor family. Evaluate the chosen model, precision, sensor load, latency, memory and thermal conditions together. If inference depends on remote services, include connectivity, failure handling and data access in the architecture review.
NVIDIA · Publication date not disclosed · Source accessed 2026-09-28
Evaluation and operating feedback
Close the diagram with task evaluation, logs, maintenance and change control. Record which layer produced a failure and which revision was running. A new checkpoint, camera, gripper or software package should trigger the tests that depend on it. Benchmark evidence and customer operation belong in separate records connected to the same system, so an improvement in one layer does not silently become a claim about every deployed workflow.
Related reading is an editorial crosslink. Sourced connections describe relationships reported in the cited material. A link to a versioned profile does not establish compatibility with that version unless the connection note explicitly identifies it.
Record history & verified changes
A research review records when we checked a source. It does not mark a product launch or a new deployment.
Initial reviewed record. No subsequent field change has been recorded.
google-deepmind · Repository · Publication date not disclosed · Source accessed 2026-09-28
License: Apache-2.0 repository software; CC BY 4.0 other repository content; constituent dataset licenses separate. Factual summary and attribution only; no upstream prose, images, weights, or dataset redistributed.
Official README inspected live. Repository code terms do not automatically cover model weights, data, or third-party assets.
Physical-Intelligence · Repository · Publication date not disclosed · Source accessed 2026-09-28
License: Apache-2.0 code; Gemma and other component terms apply separately. Factual summary and attribution only; no upstream prose, images, weights, or dataset redistributed.
Official README inspected live. Repository code terms do not automatically cover model weights, data, or third-party assets.