Robotics foundation models are moving from demos to controlled work
Vision-language-action models can transfer skills across tasks and robot bodies, but dependable physical work still comes from calibrated hardware, bounded jobs, deterministic safety controls and intervention-aware testing.
What is happening?
A robotics foundation model is meant to give a robot a reusable starting point instead of programming every object and movement separately. The model can connect a spoken instruction and camera view to a plan or physical action. That is useful, but it is not a finished robot employee. The machine still needs the right gripper, accurate calibration, fast local control, hard safety limits, a clear definition of success and a person who can recover it when the world does something unexpected.
Why this trend is moving
- 01Vision-language-action models now connect web-scale visual and language knowledge with robot actions.
- 02Cross-embodiment datasets let one policy learn from demonstrations collected on many robot types.
- 03Open models such as OpenVLA, Octo and GR00T make adaptation and reproduction more accessible.
- 04Simulation, synthetic data and world models are expanding the number of scenarios available for training and testing.
- 05Industrial safety standards were updated in 2025 while NIST is developing practical test methods for physical AI.
- 06Current benchmarks and real-robot studies are exposing a large gap between polished demonstrations, simulation scores and intervention-free deployment.
What this means in practice
- The correct production unit is the complete robot system and one bounded job, not the model checkpoint alone.
- Edited demonstration videos should be separated from repeated trials with stated intervention and failure rules.
- Cross-robot training data requires explicit action frames, calibration, timing and embodiment metadata.
- Simulation and synthetic data broaden coverage but cannot certify real-world contact, wear, people or recovery behavior.
- Learned planning and control should remain inside deterministic speed, force, workspace and emergency-stop limits.
- Long-horizon reliability depends heavily on success detection, recovery and human handoff between ordinary skills.
- The business case should use complete cost per successful task, including integration, supervision, resets, downtime and maintenance.
What the headline leaves out
This is the practical technical view: how the system is put together, where it can fail, and what a real deployment asks from the team running it.
How it is built
A production robotics-foundation-model system begins with a bounded task, environment and hazard analysis. Sensors, coordinate frames, joints and end effectors are calibrated before demonstrations and simulated experience are normalized into a consistent observation-and-action schema. A pretrained vision-language-action model is adapted to the target embodiment. At runtime, perception and high-level planning produce actions or short action chunks, while conventional controllers enforce motion and safety limits. Independent state checks determine whether each physical step succeeded, and bounded recovery or human intervention handles uncertainty. Every model, controller, hardware and data change is logged, replayed, qualified and reversible.
How inference behaves
Vision-language-action models map images, language and robot state to actions. Some tokenize position, rotation and gripper commands; others predict continuous trajectories, diffusion policies or action chunks. Cross-embodiment pretraining can transfer visual and semantic knowledge, but every robot has different cameras, kinematics, control rates and action semantics. Hierarchical systems separate embodied reasoning from fast motor control, while end-to-end systems learn more of the stack together. Neither architecture removes the need for calibrated feedback, deterministic limits and physical verification.
What the tests can miss
A credible evaluation reports trial counts, confidence intervals, intervention-free completion, long-horizon transitions, changed objects and layouts, perturbation recovery, success-detection accuracy, latency and jitter, protective-stop events, cycle time, sim-to-real gap and complete cost. The model must be frozen before final trials, and training, debugging and evaluation data must remain separate. A simulation leaderboard or a few successful videos cannot establish physical reliability.
What deployment involves
Begin with perception support or a fenced adaptive manipulation cell. Use the simplest embodiment that can perform the job, preserve a conventional safety layer and keep a fast safe state local. Add mobile manipulation, cross-task learning or humanoid form only when the workflow requires it. New models should enter through simulation, replay, shadow runs, low-speed physical canaries and immediate rollback. Scaling should follow repeatable operation across shifts, ordinary environmental variation and clearly measured human intervention.
Where the risks sit
A learned robot adds cameras, microphones, wireless links, model artifacts, remote update channels and tool interfaces to the traditional machine-security boundary. Model or visual prompt injection must not authorize physical actions. Signed software, protected calibration, least-privilege tools, network segmentation, local stopping, tamper detection and controlled teleoperation are required. Logs and video can contain workers, homes or confidential facilities and need purpose, access and retention limits.
What it really costs
Robotics economics combine hardware, fixtures, safety integration, demonstrations, simulation, accelerators, cloud services, technicians, maintenance, charging, spare parts, damaged items, downtime and human recovery. A flexible policy may reduce task-specific programming, but early systems can shift work into data collection and exception handling. The useful denominator is successful tasks delivered at the required quality and cycle time, not robot purchase price, model size or an isolated inference cost.
What the evidence supports
The direction is technically credible. RT-2, Open X-Embodiment, Octo and OpenVLA established reusable policies trained across web and robot data. Gemini Robotics, Gemini Robotics-ER, GR00T, Helix and pi0.5 report stronger dexterity, cross-embodiment transfer, planning and new-environment behavior under their test conditions. On-device models reduce latency and network dependence, while RoboCasa365 and synthetic-data systems increase evaluation and training scale. At the same time, NIST describes a continuing gap between embodied-AI research and feasible manufacturing deployment, ISO treats robot and application safety as system-level work, and current benchmark audits and real-robot studies show that action semantics, setup, shortcuts and interventions can dominate model scores. The evidence supports controlled, task-specific deployment—not autonomous general labor.
How it works in practice
A robotics foundation model can make a robot easier to teach, but it does not turn a machine into a dependable general worker. Production value comes from the entire closed-loop system: embodiment-specific data, calibrated sensors, deterministic control, safety-rated limits, task verification, human intervention and disciplined change management.
How the parts work together
The headline technology is only one part of the product. Reliability, security and cost are usually decided by the handoffs around it.
- 01
Task, environment and hazard definition
The deployment begins with a bounded job, allowed workspace, objects, people, failure consequences and measurable completion criteria. A broad instruction such as “help in the warehouse” is not an engineering specification.
- 02
Embodiment and sensor calibration
Cameras, force sensors, joints, grippers, mobile bases and coordinate frames are calibrated. The same action vector means different motion on different robots, so embodiment metadata and controller conventions must remain explicit.
- 03
Data and action-schema preparation
Human demonstrations, teleoperation, autonomous trials, simulation and synthetic data are normalized into observations, language, robot state and actions. Bad timestamps, inconsistent frames or weak coverage become learned control errors.
- 04
Pretraining and task adaptation
A vision-language-action model learns from diverse robot and web data, then is fine-tuned or conditioned for the target robot and job. Adaptation must preserve safety constraints and be evaluated on held-out environments.
- 05
Perception, planning and action generation
At runtime, the system interprets the scene, chooses a subtask and produces an action or short action chunk. High-level reasoning and low-level motion may be separate models with different frequencies and failure modes.
- 06
Deterministic control and safety envelope
A conventional controller translates the requested motion into motor commands while enforcing speed, force, workspace, collision and emergency-stop limits. Learned policy output is treated as a proposal, not unrestricted authority.
- 07
Verification, recovery and human intervention
The robot checks whether the intended state was achieved, detects slips or blocked motion, retries within limits, asks for help or enters a safe state. Long tasks require explicit progress and failure detection.
- 08
Telemetry, replay and controlled improvement
Every run records model, data, controller, environment, interventions and outcomes. Failures become reviewed training or test cases, and updates move through simulation, shadow, canary and rollback gates.
Estimate the limits before the demo
These equations are planning tools rather than substitutes for testing. They help expose a design that is unlikely to fit its hardware, budget, reliability or risk limits.
Long tasks multiply small weaknesses
task success ≈ Π(step successᵢ) The approximation assumes step outcomes are independent, which real robot failures often are not. It still shows why a policy that succeeds 95% of the time on one step can perform poorly on a twenty-step task: 0.95²⁰ is only about 36%.
- A kitchen-cleaning demonstration can hide many pick, place, open, navigate and verification steps.
- One unreliable drawer-opening skill can dominate the whole mission.
- Recovery logic can improve task success without changing the base model.
Closed-loop latency must fit the physical process
control delay = sensing + preprocessing + inference + communication + actuation The acceptable delay depends on speed, payload, compliance and the environment. Average latency is not enough; jitter and occasional long pauses can destabilize control or make human interaction unsafe.
- A slow high-level planner can be acceptable when a fast local controller maintains stability.
- Cloud inference may work for deliberate manipulation but not for reflex-like collision response.
- Action chunking reduces model calls but increases open-loop exposure when the scene changes.
Economics belong to the successful cycle
cost per successful task = total robot, integration, compute, supervision, maintenance and downtime cost ÷ successful completed tasks Hardware price or inference cost alone cannot establish a business case. Interventions, resets, damaged items, idle time and integration work often dominate early deployments.
- A lower-cost robot can be expensive when a technician must reset it frequently.
- A model upgrade that reduces interventions may matter more than a small benchmark gain.
- Simulation saves data-collection cost only when transfer to the real cell is measured.
A generalist policy is not a general-purpose robot
Vision-language-action models extend the language-model idea into physical control: an image, instruction and robot state are mapped to actions. RT-2 represented actions as tokens; OpenVLA, Octo, Gemini Robotics, GR00T and newer systems use different architectures, data mixtures and action representations. The shared goal is transfer: teach new tasks without rebuilding the entire policy from zero.
That is meaningful progress, but the model does not supply accurate calibration, a safe gripper, collision limits, a maintained battery, a reliable network or a clear job definition. The same checkpoint can succeed on one embodiment and fail on another because camera placement, control frequency, coordinate conventions and action normalization changed.
The correct production unit is therefore the robot system and its bounded task. Model capability is evidence inside that system, not proof that the machine is generally competent.
- Name the exact robot, sensors, controller and task version in every result.
- Separate model generalization from integration quality.
- Treat impressive videos as demonstrations, not reliability studies.
- Require a safe state when the learned policy is unavailable or uncertain.
The action representation decides what the model can control
A VLA model must convert semantic intent into numbers that move hardware. Some systems discretize position, rotation and gripper commands into tokens. Others predict continuous actions, diffusion trajectories or chunks of several future actions. High-level models may instead produce plans or tool calls for a separate controller.
Each design creates a tradeoff. Tokenized actions reuse language-model machinery but can lose precision. Continuous outputs fit control more naturally but require specialized heads and training. Action chunks improve throughput yet reduce the chance to react between steps. Hierarchical designs make planning easier to inspect, while errors can appear at the boundary between planner and controller.
Evaluation should therefore identify the action horizon, frequency, coordinate frame and feedback loop. “The robot followed the instruction” hides the mechanism that determines whether it can recover when the object slips or a person moves into the scene.
- Declare action units, frames and normalization.
- Measure latency and jitter at the executed control rate.
- Test disturbances during an action chunk.
- Verify that termination and success signals are calibrated.
A million trajectories do not automatically form one coherent experience
Open X-Embodiment pooled data across many robot types, and projects such as Octo and OpenVLA use that diversity to improve transfer. The premise is powerful: one robot can benefit from tasks demonstrated on another. Yet the combined dataset contains different cameras, grippers, control rates, operators, action spaces and collection policies.
Cross-embodiment learning works only after those differences are represented rather than erased. A seven-dimensional end-effector action is not interchangeable across coordinate frames. Demonstrations can also encode one operator’s preferred path, incomplete failure recovery or inconsistent language. More data can amplify those patterns.
Dataset governance should track origin, license, robot, sensor calibration, action schema, task definition, success label and known defects. Teams need coverage maps showing where the target deployment differs from the training mixture.
- Keep dataset and embodiment lineage.
- Audit timestamp, frame and normalization consistency.
- Include failed and recovered trials, not only successful demonstrations.
- Measure target-task coverage before deciding how much fine-tuning is enough.
Simulation expands coverage but cannot certify the physical system
Real robot data is slow, expensive and potentially hazardous to collect. Simulation frameworks, digital twins and world models can generate variations in lighting, object placement, camera views and motion. NVIDIA’s Cosmos and GR00T data tools, RoboCasa365 and classical simulators make broader training and repeatable evaluation possible.
The limitation is the sim-to-real gap. Contact, friction, deformable objects, wear, sensor noise and human behavior are difficult to reproduce. A policy can overfit the simulator’s visual style or exploit a shortcut that does not exist on the factory floor. Synthetic data can also multiply a faulty assumption at enormous scale.
Use simulation to find failures, compare policies and rehearse rare cases. Final claims about physical reliability must come from controlled real-world trials on the target embodiment and environment.
- Version simulator, assets and physics settings.
- Randomize factors that truly vary in deployment.
- Track real-to-sim and sim-to-real performance separately.
- Promote synthetic scenarios into real regression tests where feasible.
Long-horizon work fails at the transitions between ordinary skills
A robot may know how to pick up a cup and still fail to clear a table. Long tasks require ordering subtasks, preserving state, deciding whether a step succeeded and recovering when the world differs from the plan. Gemini Robotics-ER separates embodied reasoning from lower-level action, while other systems combine planning and control more tightly.
The hardest moments are often transitions: the object was placed but not released, a drawer opened halfway, the gripper now blocks the camera, or the robot must navigate before manipulating again. A language explanation does not prove that the physical state changed.
Progress should be verified through sensor evidence and explicit state checks. Retries need limits, and intervention should be recorded as part of the outcome rather than hidden from the success rate.
- Define observable completion for every subtask.
- Measure intervention-free completion, not only final success after resets.
- Test reordered, missing and partially completed states.
- Preserve a safe human handoff and resume procedure.
A prompt is not a safety mechanism
Robotics safety depends on the complete machine and application. ISO 10218 separates requirements for industrial robots from the integration of robot applications and cells. Learned models add new uncertainty, but they do not replace established risk assessment, guarding, speed and separation controls, force limits, emergency stops or validated safety functions.
Google DeepMind’s AutoRT work illustrates the layered principle: an LLM-based task filter was combined with classical force limits, human line-of-sight supervision and a physical deactivation switch. The model could help choose tasks, but safety did not depend on the model consistently remembering a rule.
The learned policy should operate within an independently enforced envelope. High-consequence actions require deterministic checks, and model output should never disable or reinterpret a safety-rated control.
- Perform application-specific hazard analysis before model trials.
- Keep emergency stop and protective functions independent of AI inference.
- Limit speed, force, workspace and payload at the controller level.
- Validate foreseeable misuse, sensor failure and communication loss.
Success rate means little without trials, conditions and intervention rules
Robot evaluations are unusually sensitive to setup. Object position, reset procedure, camera exposure, operator assistance and the definition of success can materially change the result. Simulation leaderboards are useful for controlled comparison, but recent benchmark audits show that shortcuts, overfitting and weak statistical power can exaggerate progress.
A credible report states the number of trials, confidence interval, target and unseen conditions, resets, interventions and failure taxonomy. It includes latency, task time and safety events, not only binary completion. Videos should include ordinary failures and continuous runs rather than edited successes.
The decisive test is a prospective deployment trial with frozen model and controller versions. Evaluation data collected after tuning must remain separate from the training and debugging set.
- Predeclare success and intervention rules.
- Use enough trials to estimate uncertainty.
- Report seen, unseen and disturbed conditions separately.
- Preserve raw event logs and representative failure video.
Integration, maintenance and exception handling decide the business case
A flexible model can reduce the programming required for each object or task, but deployment still needs fixtures, safety design, workflow integration, charging, spare parts, cleaning, calibration, updates and staff training. Humanoid form can fit human spaces, yet it adds joints, balance and maintenance complexity that a fixed arm or mobile manipulator may avoid.
The correct comparison is not robot versus an abstract labor hour. It is the complete automated process against the current process, including throughput, quality, downtime, supervision and the work created by exceptions. A narrow cell with known objects may create value sooner than a visually impressive general-purpose pilot.
Scale only after the system demonstrates repeatable operation across shifts and ordinary environmental variation. Model upgrades should be treated like machine changes: qualified, canaried and reversible.
- Choose the simplest embodiment that can perform the job.
- Track interventions, mean time to recovery and maintenance burden.
- Include integration and downtime in return calculations.
- Freeze and qualify every model-controller-hardware combination.
What a benchmark worth believing should report
A performance number means little unless the workload, system configuration and quality bar are fixed. This is the minimum record a team should keep.
| Metric | How to measure it | Why it matters |
|---|---|---|
| Intervention-free task success | Count completed trials without teleoperation, manual resets or unplanned human assistance. | Final completion can hide substantial hidden labor. |
| Long-horizon mission completion | Report full missions and each subtask transition rather than averaging isolated skills. | Small step errors compound across realistic work. |
| Generalization slices | Test new objects, layouts, lighting, instructions, operators and environments separately. | One aggregate score hides where transfer actually works. |
| Perturbation recovery | Move objects, introduce slips, occlusions and partial completion during execution. | Real environments change after the plan begins. |
| Success-detection accuracy | Compare the robot’s own completion and failure judgments with independently labeled outcomes. | A robot cannot recover reliably when it misreads its state. |
| Action latency and jitter | Report sensing-to-command p50, p95 and p99 at each control layer. | Occasional delays can destabilize physical behavior. |
| Safety-limit activations | Count emergency stops, protective stops, force-limit events, workspace violations and near misses. | A task success rate should not conceal unsafe trajectories. |
| Human intervention burden | Record minutes, reasons and skill level required for supervision, recovery and reset. | Intervention is a real operating cost and reliability signal. |
| Cycle time and throughput | Measure successful tasks per operating hour including resets and charging. | A capable robot may still miss the production requirement. |
| Sim-to-real gap | Run matched scenarios in simulation and on the physical system and compare failure types. | Synthetic performance cannot be assumed to transfer. |
| Data-efficiency curve | Plot target success against demonstrations, autonomous trials and synthetic data added. | This shows whether adaptation is economically practical. |
| Embodiment-transfer loss | Compare performance before and after adaptation across robot bodies and action schemas. | Cross-robot claims need a measurable denominator. |
| Change regression | Replay held-out and physical safety suites after model, data, controller, sensor or hardware changes. | The system can change without an obvious application-code edit. |
| Complete cost per successful task | Include hardware, integration, compute, supervision, maintenance, consumables, downtime and damage. | Purchase price and token cost understate deployment economics. |
Four sensible deployment patterns
Perception and planning assistant
- Where it fits
- The model identifies objects, proposes plans or checks progress while a human or conventional system executes.
- What you take on
- Lowest physical risk and easiest evidence collection, but limited labor substitution.
Fenced adaptive manipulation cell
- Where it fits
- Known work area with variable objects, deterministic safety controls and a learned manipulation policy.
- What you take on
- Strongest near-term production fit; flexibility remains bounded by the cell and validated task set.
Supervised mobile manipulator
- Where it fits
- Warehouses, labs or facilities where navigation and manipulation occur under geofencing and remote assistance.
- What you take on
- Broader utility, with higher mapping, interaction, connectivity and recovery complexity.
Humanoid or general-purpose pilot
- Where it fits
- Research and controlled trials where human-form access or cross-task learning is the main hypothesis.
- What you take on
- Highest option value and highest integration, safety, maintenance and evidence burden.
Where projects usually go wrong
A demonstration is treated as a reliability result
What you see: Only edited successful runs are shown and trial counts are absent.
What to do: Require prospective repeated trials, failure video, confidence intervals and intervention records.
Action frames or normalization are wrong
What you see: Offline predictions look plausible while the real robot moves unpredictably or drifts.
What to do: Validate coordinate frames, units, timing and action conversion with low-speed hardware tests.
The policy overfits one camera or workspace
What you see: Small changes in lighting, viewpoint or background sharply reduce success.
What to do: Use generalization slices, calibrated augmentation and target-environment data.
Long action chunks ignore a changed scene
What you see: The robot continues toward an object after it moved or a person entered the path.
What to do: Shorten open-loop horizon, add fast local monitoring and interruptible controllers.
Simulation shortcuts do not exist in reality
What you see: Leaderboard gains disappear on hardware.
What to do: Audit policies for shortcuts and maintain matched sim-to-real trials.
Success detection is overconfident
What you see: The robot advances after a failed grasp or incomplete placement.
What to do: Use independent state checks, calibrated confidence and bounded retry logic.
A language safety rule is bypassed
What you see: The planner proposes a hazardous task after unusual wording or scene content.
What to do: Enforce hazards, workspace and actuation limits outside the model.
Cross-embodiment data hides incompatible controls
What you see: Transfer learning degrades because robot state and action semantics were mixed.
What to do: Preserve embodiment metadata and use explicit adapters with per-robot qualification.
Intervention labor is omitted
What you see: The pilot appears autonomous while technicians constantly reset, label or teleoperate it.
What to do: Count every intervention and include it in cost and success metrics.
A model update changes physical behavior silently
What you see: Cycle time, path or force profile changes after a checkpoint or serving update.
What to do: Pin versions, shadow updates, run physical regressions and support immediate rollback.
Cloud loss disables safe operation
What you see: The robot freezes, repeats or enters an undefined state when connectivity fails.
What to do: Keep stabilization, stopping and safe-state behavior local and deterministic.
The embodiment is more complex than the task
What you see: A humanoid pilot creates maintenance and balance problems for work a simpler machine could do.
What to do: Compare against fixed-arm, mobile-manipulator and conventional automation baselines.
A checklist you can actually use
- Define one bounded job and its measurable completed state.
- Document people, objects, spaces and foreseeable misuse around the robot.
- Choose the simplest embodiment that can meet the requirement.
- Specify cameras, sensors, control rates, coordinate frames and action units.
- Create a versioned robot, controller and model compatibility record.
- Map training-data coverage against the target deployment.
- Track dataset source, license, calibration, task and success labels.
- Include failed, interrupted and recovered demonstrations.
- Separate training, tuning, debugging and final evaluation trials.
- Define deterministic speed, force, workspace and payload limits.
- Keep emergency stop and protective functions independent of AI.
- Define observable success and failure for every subtask.
- Set retry, timeout, intervention and safe-state rules.
- Test changed objects, layouts, lighting, instructions and operators.
- Inject slips, occlusions, blocked paths and partial completion.
- Measure p50, p95 and p99 control latency and jitter.
- Record all human intervention and reset time.
- Report safety-limit events and near misses with task outcomes.
- Compare simulation and physical performance on matched cases.
- Calculate complete cost per successful task.
- Shadow and canary every model, data or controller update.
- Preserve physical regression cases and representative failure video.
- Scale only after repeatable operation across ordinary shifts and environmental variation.
Terms worth knowing
- Embodied AI
- AI that perceives and acts through a physical body in an environment.
- Vision-language-action model
- A model that maps visual observations and language instructions to robot actions or action plans.
- Embodiment
- The particular robot body, sensors, joints, gripper, controller and physical capabilities.
- Robot policy
- A function that selects actions from observations, state and goals.
- Action token
- A discrete symbol representing part of a robot command so actions can be predicted like language tokens.
- Action chunk
- A sequence of future robot actions predicted and executed together.
- Teleoperation
- Human remote control used to operate a robot or collect demonstrations.
- Cross-embodiment transfer
- Using experience from one robot type to improve a policy for another.
- Sim-to-real gap
- The performance difference between simulation and the physical system.
- Domain randomization
- Varying simulated appearance or physics to reduce overfitting to one virtual environment.
- Closed-loop control
- Repeatedly sensing the current state and correcting actions from feedback.
- Safety envelope
- Independently enforced limits on motion, force, workspace and operating conditions.
- Intervention
- Unplanned human assistance, reset or teleoperation needed to continue a task.
- Success detector
- A mechanism that judges whether a physical step or task reached its intended state.
- Physical regression test
- A repeatable hardware trial used to confirm that a system change did not break established behavior.
Primary references and technical starting points
These sources support the architecture, runtime, benchmark and security claims. Vendor capabilities can change, so the article records the distinction between established evidence, measured product behavior and editorial interpretation.
- 01 Google DeepMind: Gemini Roboticsdeepmind.google
- 02 Google DeepMind: Gemini Robotics On-Devicedeepmind.google
- 03 Google DeepMind: Gemini Robotics 1.5deepmind.google
- 04 Google DeepMind: Gemini Robotics-ER 1.6deepmind.google
- 05 NVIDIA: Isaac GR00T N1research.nvidia.com
- 06 NVIDIA Research: GR00T N1.6research.nvidia.com
- 07 NVIDIA: Cosmos physical-AI data toolsnvidianews.nvidia.com
- 08 Figure: Helix vision-language-action modelfigure.ai
- 09 Physical Intelligence: pi0.5 open-world generalizationarxiv.org
- 10 Google DeepMind: RT-2deepmind.google
- 11 Google DeepMind: Open X-Embodiment and RT-Xdeepmind.google
- 12 Open X-Embodiment repositorygithub.com
- 13 OpenVLA projectopenvla.github.io
- 14 OpenVLA repository and evaluation guidancegithub.com
- 15 Octo generalist robot policyroboticsproceedings.org
- 16 DROID distributed robot interaction datasetgithub.com
- 17 Google DeepMind: AutoRT large-scale robot data collectiondeepmind.google
- 18 Google DeepMind: RoboCat self-improving robot agentdeepmind.google
- 19 RoboCasa365 simulation and benchmarkrobocasa.ai
- 20 RoboCasa365 leaderboardrobocasa.ai
- 21 Robot manipulation benchmark auditarxiv.org
- 22 Real-world VLA deployment study on a UR5 platformarxiv.org
- 23 NIST: Physical AI and Data Generation for Roboticsnist.gov
- 24 ISO 10218-1:2025 industrial robot safetyiso.org
- 25 ISO 10218-2:2025 robot applications and cellsiso.org
- 26 NIST AI Risk Management Frameworknist.gov
- 27 NIST AI 600-1 Generative AI Profilenist.gov
- 28 Open X-Embodiment paperarxiv.org
- 29 OpenVLA paperarxiv.org