Foundation Models for Industrial Robotics: State of Production (2026)

Foundation models for industrial robotics 2026 are no longer a research demo. They are a deployable software category with a recognisable shape: a vision-language-action (VLA) backbone in the 2 to 7 billion parameter range, an action head that emits joint or end-effector commands at 10 to 50 Hz, and a real-time controller that runs the closed loop at 200 to 1000 Hz on the robot. The leading model families competing for production cells are Physical Intelligence’s Pi0 and Pi0.5, NVIDIA’s Isaac GR00T N1 / N1.5 / N2, Figure’s Helix, Google DeepMind’s Gemini Robotics and Gemini Robotics-ER, and Skild AI’s Skild Brain — all descended in some way from the RT-2, PaLM-E, and OpenVLA lineage that proved a large pretrained transformer could output usable robot actions. What this post covers: the landscape, the reference architecture, how the data flywheel works, what deployment looks like on a real factory floor, the failure modes nobody puts in the press release, and a pragmatic recommendation if you are choosing a stack in 2026.

Architecture at a glance

Why robot foundation models matter in 2026

For the last thirty years, industrial robotics shipped on a recipe: a CAD model of the workcell, a hand-coded motion plan, a tightly engineered fixture, and a six-week integration job per SKU. That worked for the automotive welding cell because the SKU set was small, the parts were rigid and registered to within 0.1 mm, and the cycle paid back the integration cost over millions of vehicles. It collapses the moment you try to apply it to apparel folding, mixed-case palletising, contract electronics assembly, or any humanoid task where the environment cannot be jigged. Classical robotics had no answer to “pick up the wrinkled shirt and fold it” because the perception, the planning, and the control all required a model of the world that the engineer did not have time to build.

Foundation models change the economics of that build. A pretrained VLA absorbs the common visual and semantic priors from web-scale image-text data, the embodied priors from internet video and simulation, and the manipulation priors from teleoperation logs collected across many robots. Fine-tuning on a new cell now takes hours to days of teleop data instead of weeks of CAD-and-script work, and the same checkpoint can run on a Franka arm in a lab, a UR10e in a contract manufacturer, and a humanoid on a logistics floor with embodiment adapters rather than a rewrite. The economic claim — and it is the only claim that matters at a CFO level — is that the per-task integration cost drops by roughly an order of magnitude once the underlying foundation model is good enough.

In 2026 the model is finally good enough for a meaningful slice of tasks. Pick-place from a bin, kitting, machine tending, light assembly, palletising, and a growing list of bimanual humanoid behaviours are in production or in supervised pilot at named customers. The systems still fail, and the failure modes are exotic — we will get to those — but the curve has crossed the line where a serious operations team can write a business case. That is the bar for “production” in this post: a model is deployed in a real plant, on real product, with a real takt-time constraint, and the line is making money. Research papers without that grounding do not count here.

For an operator team that already runs an Industrial IoT stack and a digital-twin programme, the integration question is the bigger one. A foundation model is just another workload that needs versioning, observability, and a release process. The same MQTT and OPC UA backbone that streams PLC telemetry now also streams robot policy decisions and confidence scores; the same digital twin that hosts the cell’s geometry now also hosts the simulation data that the policy was trained against. The technology stack converges, and the foundation model becomes the highest-leverage component in the cell.

The landscape: Pi0, GR00T, Helix, and Gemini Robotics

The field consolidated in 2024 to 2025 into a handful of serious robot foundation model production efforts. The table below is the cleanest snapshot of where each family sits as of mid-2026. Figures are vendor-reported unless flagged; treat parameter counts and dataset sizes as approximate because vendors keep refining them between point releases.

Model family	Backbone size (approx)	Action head	Training data shape	Embodiments demonstrated	Licence
Physical Intelligence Pi0 / Pi0.5	~3B VLM + flow-matching expert	Continuous, flow-matching	~10k hrs cross-embodiment teleop + web	Franka, UR, ALOHA, mobile manipulators, humanoids	Open Pi0-base under Apache-2.0; Pi0.5 partly closed
NVIDIA Isaac GR00T N1.5 / N2	2B System-2 VLM + ~300M System-1 action expert	Dual-system, diffusion-style	Cosmos synthetic + Ego4D + teleop + neural-trajectories	GR00T humanoid reference, Fourier, 1X, Agility, Sanctuary	Open weights under NVIDIA research-friendly licence
Figure Helix	Dual-system 7B System-2 + ~80M System-1	Continuous, high-rate System-1 at 200 Hz	Figure fleet teleop + internet video	Figure 02 / 03 humanoid only	Proprietary, closed weights
Google DeepMind Gemini Robotics / Gemini Robotics-ER	Scaled from Gemini multimodal	Action decoder + embodied-reasoning chain	Web + ALOHA-class teleop + partner data	ALOHA, Apptronik Apollo, bi-arm platforms	Closed API + partner access
Skild AI Skild Brain	Vendor-undisclosed, “general” scale	Vendor-undisclosed	Web video + sim + teleop, vendor-reported	Multi-embodiment claim; specifics undisclosed	Proprietary

Two architectural patterns dominate. Pi0 and the open Pi0-base popularised the flow-matching action expert attached to a pretrained VLM — a single backbone produces a continuous action chunk through a small dedicated head, and the whole thing is trained end-to-end. GR00T N2 and Helix instead split the work into a slower System-2 reasoning model and a faster System-1 control model: System-2 thinks at a few hertz about the scene and the goal, System-1 emits high-rate motor commands. The split shows up cleanly in the latency budget; we will come back to it in the deployment section.

A useful narrative thread is that this consolidation took roughly three years from RT-2 in 2023 — the Google paper that first showed a web-pretrained VLM could output robot actions. OpenVLA opened the recipe in 2024. Pi0 productised it in late 2024. GR00T N1 shipped with open weights in early 2025 and was iterated through N1.5 and N2 over the following year; the NVIDIA Isaac GR00T N1.5 vs Cosmos robot foundation 2026 comparison goes into the System-1 / System-2 split in detail, and the NVIDIA Isaac GR00T N1.5 vs Cosmos robot foundation model breakdown is a useful primer if you have not read it. Helix landed in 2025 with the dual-system pitch and a hard humanoid focus. Gemini Robotics joined the same year with the embodied-reasoning model that pairs well with the action model. Skild surfaced from stealth with a broad-generalisation claim that the market is still independently verifying.

What does the leaderboard tell you? Honestly, not much. There is no standardised benchmark suite for production robot policies that everyone agrees on. The closed Open-X embodiment evaluation, the ARC-style real-world challenges, and a handful of academic suites (LIBERO, RoboCasa, CALVIN) are all in use, but every vendor cherry-picks. The honest read is that on narrow tasks within the training distribution, all five families succeed more than 80 percent of the time; on out-of-distribution tasks, success rates fall to 30 to 60 percent and vary wildly by category. That last sentence is the single most important thing you will read on this topic.

Reference architecture: how a VLA policy reaches the actuator

Strip away the brand names and the production architecture is the same in every serious deployment. The sensor layer is typically two or three wrist cameras plus a scene camera at 30 frames per second, optional depth, force-torque at the wrist, optional tactile skins on the fingers, and joint encoders streaming proprioception at 1 kHz. The perception layer tokenises images with a vision transformer in the SigLIP or DINO family, tokenises the instruction text, and either concatenates or cross-attends the joint state. The VLA backbone is a decoder-only transformer in the 2 to 7 billion parameter range, frequently initialised from an open VLM (PaliGemma, Llama-3, or a Gemini-class model) and then continued-trained on robot data.

The action head is where the families diverge. Pi0 and Pi0.5 use a flow-matching head that learns a velocity field over a chunk of future actions and integrates it at inference time — typically a 50 ms chunk emitted at 10 to 20 Hz. GR00T N2’s action expert is a separate diffusion-style network conditioned on the System-2 features and the proprioception; the official guidance is that it runs at higher rates than the System-2, with the System-2 refreshing perception and goal context every few hundred milliseconds. Helix’s System-1 emits at 200 Hz, which is what makes its public bimanual demos look continuous rather than chunked.

Underneath the action head sits a controller that the foundation model does not own. On a humanoid it is a whole-body controller that solves an inverse-dynamics optimisation at 200 to 1000 Hz, treating the VLA’s target as a reference and adding balance, contact, and self-collision constraints. On an industrial arm it is the vendor’s real-time motion controller — KUKA KRC, Universal Robots PolyScope, Fanuc R-30iB — fed either via the vendor’s external motion interface or via a thin shim that converts the VLA’s chunk into joint targets. The safety-rated stop and the speed-and-separation monitoring still live in the safety PLC, not in the foundation model, and that boundary is one of the most important pieces of the architecture. The Boston Dynamics Atlas Hyundai deployment is a good illustration of where the line is drawn between the policy and the controller; the Boston Dynamics Atlas Hyundai deployment architecture walkthrough shows the partition cleanly.

The end-to-end latency budget on a competitive production cell as of 2026 is roughly: 30 ms perception, 40 to 80 ms VLA inference on a Jetson Thor or RTX-class edge GPU, 5 to 10 ms action-head sampling, 5 ms transport to the controller, 5 ms controller update. Total: about 100 to 150 ms from camera frame to motor command. That is faster than a human reaction loop but slower than a hard-real-time motion controller, which is why the System-1 / System-2 split exists — high-rate stability is not the foundation model’s job.

Training, fine-tuning, and the data flywheel

The training story is where the field has matured most over the last 18 months. In 2024, “train a VLA” meant pretraining on web image-text, then fine-tuning on whatever teleop data you had. In 2026, the production recipe is more layered. The base VLM is pretrained on a few hundred billion tokens of web image-text. A continued-training phase ingests internet video — Ego4D, Epic-Kitchens, large-scale YouTube how-to corpora — to give the model embodied priors about how humans manipulate the world. A robot-specific co-training phase mixes simulation rollouts, multi-embodiment teleoperation logs, and lab demonstrations in a deliberate ratio. Then per-platform fine-tuning produces an embodiment-specific checkpoint, and per-task fine-tuning produces a deployable model for the cell.

Simulation is doing more of the heavy lifting in 2026 than in 2024 because the photoreal generative world models have matured. NVIDIA Cosmos generates synthetic egocentric robot video from text and scene priors and is now a standard ingredient in the GR00T training mix. Genie-class models from DeepMind play a similar role for Gemini Robotics. The bet is that synthetic-to-real transfer, supported by aggressive domain randomisation in a physics simulator like Isaac Sim, can substitute for a meaningful fraction of teleoperation hours; the Isaac Sim 4.5 domain randomisation tutorial for robot foundation models walks through the randomisation parameters that matter most. The vendors that have been honest about this — Physical Intelligence in particular — say synthetic data helps with coverage and novelty but does not replace real teleop for fine-grained contact-rich tasks.

Teleop is the unsexy moat. Pi0’s training set is reportedly around 10,000 hours of cross-embodiment teleoperation across roughly ten platforms, collected partly internally and partly via partnerships. Figure’s fleet teleop programme runs continuously and is a key reason Helix is competitive despite a smaller backbone than some rivals — they own the data pipeline end-to-end. NVIDIA’s data strategy leans more heavily on synthetic and on partner-contributed teleop because they sell the platform rather than operate the fleet. There is no shortcut to the data; if you are starting a programme in 2026 and you do not have a teleop strategy, you do not have a foundation model strategy.

The flywheel closes when deployed robots stream telemetry back. Every successful manipulation becomes a positive sample; every failure, ideally caught by a safety guard before damage, becomes a labelled failure case. Replay buffers feed back into the next training run, and the model improves on the long tail of edge cases that were not in the original distribution. Closing this loop with the necessary observability, data governance, and labelling pipeline is what separates a serious operator from a pilot that stalls.

A subtle point about the data flywheel: the teleop logs are only useful if they include the same modalities the deployed robot will see. If you train on logs that have wrist RGB but no force-torque, then deploy a robot that has force-torque, you cannot use the contact signal at inference time without retraining. That sounds obvious; it is also a mistake that more than one programme has made. The data schema is a more important architectural decision than the model size.

Deployment patterns on the factory floor

A production deployment of a robot foundation model has four layers that an Industrial IoT and digital-twin practitioner will recognise immediately. The cloud layer trains the model, holds the registry of versioned signed artefacts, and runs the observability lake for fleet telemetry. The plant DMZ runs an edge gateway speaking MQTT and OPC UA, plus an OTA orchestrator that pushes signed model bundles down to the cell. The cell edge runs the inference — Jetson Thor for new humanoid deployments, AGX Orin for older deployments and many industrial arms, with an RTX A-series workstation as the alternative when the cell can afford the power. The robot itself runs the real-time controller and the safety-rated stop.

The split matters because nothing in the foundation model is safety-rated. The model emits a target; the safety PLC enforces the limits. The standards everyone is converging on — ISO 10218-1 for industrial robots, ISO/TS 15066 for collaborative operation, the emerging ISO/PAS 5672 work on humanoid behaviour — all assume that there is a deterministic safety layer below the policy. A SIL-2 watchdog monitors envelope, speed, and contact force; if the policy commands something outside the envelope, the watchdog rejects it and triggers either a speed-scale, a fallback, or a protective stop.

OTA is the unglamorous engineering that decides whether your foundation model deployment scales or not. A serious programme treats every model release like a firmware release: signed artefacts, a software bill of materials, a canary deployment to a small fleet subset, automated rollback triggered by drift detection on telemetry, and an approval gate from the quality team for any model that changes behaviour in a way that affects the validated process. NVIDIA, Physical Intelligence, and Figure all ship their own OTA infrastructure; if you are not using a vendor’s stack, you will build the equivalent with Foundry / Anchore / Sigstore plus a fleet manager.

A pattern worth highlighting is the policy registry as an operational asset. Each cell holds not one model but a small set: the active production policy, a previous-known-good for instant rollback, a canary for shadow inference, and often a small scripted fallback for the cases where the policy’s confidence drops below a threshold. The cell controller chooses among them based on confidence and the safety guard’s verdict. This is the same pattern that mature ML platforms have used in software for years; the novelty in robotics is that the fallback is a physical motion, not a cached response.

Connectivity matters less than people expect once the policy is on the edge. A factory cell does not need a continuous cloud connection to run inference; it needs a connection to push telemetry, pull model updates, and trigger alarms. A 24-hour cloud outage should degrade observability, not stop the line. Designing for that property — call it offline-capable inference — is non-negotiable for any plant that takes uptime seriously.

The integration with the existing PLM and MES stack is where most deployments stall. The PLM holds the product geometry and the bill of materials that the model is operating on; the MES holds the work order, the takt-time target, and the quality results. A serious deployment exposes the policy outputs and confidence scores back to the MES so that operators can see why a cycle failed, and feeds the PLM’s CAD into the model’s prompt context so that the policy knows what it is meant to assemble. This is the bridge between the digital twin and the foundation model, and it is where the industrial IoT discipline pays off.

Trade-offs, gotchas, and what goes wrong

Robot foundation models fail in ways that are different from classical robots, and the failure modes are why production deployments need so much surrounding engineering. The first and most uncomfortable category is hallucination. A VLA is a generative model; it can confidently emit an action sequence for a task it has not actually understood. The classical failure of a scripted robot is “stop, error code 4012”; the foundation-model failure is “smoothly pick up the wrong object and put it in the wrong place.” The latter is more dangerous because nothing in the motion looks abnormal. Mitigating this requires a semantic safety check — typically a separate VLM verifier that confirms the picked object matches the intended SKU before placement — which adds 50 to 100 ms of latency and is now standard in serious deployments.

The second category is the generalisation gap. A model that achieves 95 percent success on its training distribution can drop to 40 percent on a visually similar but semantically different task — a different lighting condition, a different conveyor speed, a different gripper. This is not a bug; it is the standard behaviour of all current VLA models. The implication is that “generalist” is a marketing word in 2026. In production, every cell is fine-tuned on its own data, every change to the cell triggers a re-validation, and the fleet behaves as a federation of specialised models that share a backbone rather than as a single brain.

The third category is the simulation-to-real gap. Synthetic data closes some of the coverage problem but introduces a different one: the model can become very good at the simulation’s quirks. Contact dynamics, soft-body physics, deformable objects, and translucent materials are all places where 2026 simulators still mislead. The honest practice is to treat simulation as a generalisation tool and real data as the ground truth, not the other way around. Vendors that claim sim-only training is sufficient are overselling.

The fourth category is safety certification. There is no current process for certifying a learned policy as safety-rated. The standards bodies are debating it; the regulators in Europe under the Machinery Regulation 2023/1230 are starting to look at it; nobody has a closed answer. The pragmatic position is that the safety case is built on the deterministic layer below the policy — the watchdog, the speed-scale, the safety-rated stop — and the policy is treated as a non-safety component whose failure must be containable by the safety layer. This is unsatisfying to anyone who wanted the foundation model to be the safety system, but it is the only honest engineering posture in 2026.

The fifth category is data poisoning and adversarial perturbation. A VLA inherits the perception layer’s vulnerabilities. A sticker on a conveyor, a printed pattern on a glove, an unusual lighting flicker can all push the policy into a behaviour that the operator did not expect. There are no off-the-shelf certified defences; the practical mitigations are restricted scene access, scene-change detection, and an envelope-based safety layer that does not trust the model’s spatial reasoning.

The sixth category is the long-tail edge case. Every plant has them. A pallet with a torn shrink-wrap, a part that arrived from the supplier with the wrong colour, a lighting fixture that flickered during a thunderstorm. The foundation model will get most of them right; the long tail is what determines whether the line runs or stops. Designing for graceful degradation — confidence-gated fallback, easy human handoff, fast scripted recovery primitives — is what separates a robot that runs lights-out from a robot that needs a babysitter.

A final operational gotcha: software supply chain. The model artefact is the new firmware. Signing, SBOM, provenance, and rotation policy all need to extend to model weights. Several incidents in 2025 — none catastrophic, all instructive — involved poisoned checkpoints flowing through unofficial mirror sites. If your security team does not understand model provenance, they will not catch the next one.

Practical recommendations

If you are choosing a stack for an industrial robotics programme in 2026, the choice is not between five models; it is between a few coherent product architectures. The recommendations below assume you are building for production rather than for a research demo.

Pick the model family that matches your data position and your embodiment. If you operate a fleet of humanoids and you can run continuous teleop, Figure-style closed stacks or Pi0.5 fine-tuned on your data both make sense, with Pi0.5 winning if you want weight portability and Figure winning if you want a tightly integrated turnkey product. If you are buying a humanoid from a partner — Fourier, Agility, 1X, Apptronik — and want a vendor-supported open base, NVIDIA GR00T N2 plus the Isaac platform is the path of least resistance because the entire toolchain from Cosmos to Isaac Sim to Isaac ROS is built to land on it. If your task mix is light industrial arms doing kitting, pick-place, machine tending, and you want a portable open base, Pi0-base or one of the Pi0-derived community fine-tunes will give you the best price-to-capability ratio.

Standardise on Jetson Thor for new humanoid cells and AGX Orin for industrial arms. The compute is the cheap part of the bill. Where teams underspend is on the surrounding observability: video archive, action-log lake, drift detector, and a labelling tool that lets a process engineer annotate failure cases in minutes rather than hours.

Build the data pipeline before you build the model team. The model is a function of the data. A modest model on excellent data outperforms a frontier model on mediocre data every time. Invest in teleoperation rigs, in a structured data schema that captures every modality the deployed robot will see, and in a labelling and triage workflow. If your CFO asks why the spend on the data pipeline is larger than the spend on GPUs, the answer is that the data pipeline is the product.

Treat safety as a first-class subsystem, not as a wrapper. A safety PLC, a SIL-2 watchdog, a speed-and-separation monitor, a deterministic envelope check on every command — these are not optional. The foundation model lives inside that envelope. Anyone who pitches you a “single neural network controls everything including safety” architecture in 2026 is wrong, and the regulators will eventually agree.

Plan for OTA and policy versioning from day one. The pattern of active / canary / previous-known-good is well understood in software; bring it into robotics. Sign every artefact, hold an SBOM, design a rollback that can be executed by a process engineer in the middle of the night without paging the model team.

Invest in the digital twin. The same plant model you use for layout planning and process simulation is the substrate for synthetic data generation, for the verifier that checks policy output against the expected geometry, and for the operator-facing interface that explains what the policy did and why. The investment compounds across the foundation model programme, the IoT programme, and the PLM programme.

Be honest about what is not yet ready. Dexterous in-hand manipulation under occlusion. Long-horizon assembly with many parts. Tasks that require tight force control in unfamiliar materials. High-mix low-volume cells with weekly SKU churn. These are the frontier in 2026; some will move into production within twelve months and some will not. The right posture is to pilot them with a clear exit criterion and not to bet a programme on them.

The summary is that robot foundation models in 2026 are a real industrial software category, with a recognisable architecture, deployable on commodity edge hardware, fail in characteristic ways that experienced teams can engineer around, and pay back the investment when they are deployed against the right tasks. They are not magic. They are the next layer of the robotics stack, and the discipline of running them well is closer to the discipline of running a mature ML platform than it is to the discipline of running a classical robot integrator.

FAQ

What is a robot foundation model?

A robot foundation model is a large pretrained neural network — typically a vision-language-action transformer in the 2 to 7 billion parameter range — that takes images, an instruction, and a robot’s joint state, and outputs motor commands. It is “foundation” in the same sense as a foundation language model: pretrained at scale on broad data and then fine-tuned for specific tasks. The leading 2026 examples are Pi0, Isaac GR00T N2, Helix, and Gemini Robotics. They replace the hand-coded perception and planning of classical robotics with a learned policy.

How is a VLA different from a classical robot controller?

A classical controller solves explicit equations — inverse kinematics, motion planning, trajectory optimisation — using a hand-built model of the world. A VLA learns the mapping from observations to actions from data, without an explicit world model. The classical controller is deterministic, certifiable, and brittle outside its design envelope; the VLA is statistical, harder to certify, and far more flexible. In a production cell in 2026, both coexist: the VLA emits a target action and the deterministic controller executes it under safety constraints.

How much teleoperation data do I need to fine-tune?

For a narrow task in a fixed cell, current practice is roughly 50 to 500 teleoperation episodes — call it one to five hours of demonstrations per task — assuming you start from a strong pretrained checkpoint like Pi0-base or GR00T N2. For broader behaviour or for novel embodiments, you need ten to a hundred times more. The number scales with the visual and dynamic novelty of your environment, not with task complexity in the human sense. Volumetric simple variation is the expensive axis.

Which edge hardware do I need?

Most 2026 production cells run NVIDIA Jetson Thor for new humanoid deployments or AGX Orin for industrial arms and older cells, sometimes paired with an RTX A-series workstation when power and space allow. The VLA inference budget is roughly 40 to 80 ms per step on Thor for the 2 to 7 billion parameter range. Inference is rarely the bottleneck; the perception preprocessing, the safety check, and the controller round-trip together account for most of the latency budget.

Can a foundation model be safety certified for industrial use?

Not today, not as a single artefact. As of 2026 there is no harmonised standard for certifying a learned policy as functional-safety-rated. Production deployments handle this by treating the policy as a non-safety component and building the safety case on the deterministic layer beneath — the safety PLC, the watchdog, the speed-and-separation monitor, ISO 10218-1 envelope checks. Standards bodies and regulators are actively working on it; expect formal guidance over the next two to four years.

How do I compare Pi0, GR00T, Helix, and Gemini Robotics?

Pi0 is open at the base layer and strongest on cross-embodiment generality with a clean fine-tuning recipe. GR00T N2 is the NVIDIA-native choice with the best toolchain integration into Isaac Sim, Cosmos, and the broader NVIDIA stack. Helix is a closed dual-system architecture optimised for Figure’s humanoids with strong continuous control. Gemini Robotics couples a powerful embodied-reasoning model with an action model and is the cleanest path if you already run a Google partner stack. Match the model to the embodiment, the data position, and the platform commitment.

How does the data flywheel actually work in production?

Each deployed robot streams telemetry — video, joint trajectories, force readings, policy decisions, confidence scores — back to the cloud. Successful manipulations are positive samples; failures, ideally caught by the safety guard before damage, are labelled failure cases. A labelling and triage workflow categorises failures (hallucination, slip, occlusion, out-of-distribution) and the replay buffer feeds the next training round. The result is a model that gets better at the long tail of cases the original distribution missed. The flywheel only closes if the observability and labelling discipline is in place.

What tasks are still out of reach for robot foundation models in 2026?

Dexterous in-hand manipulation under heavy occlusion, long-horizon assembly with dozens of parts and tight tolerances, high-precision force-controlled tasks in unfamiliar materials, and unstructured outdoor tasks with severe lighting variability are still hard. The frontier moves quickly, so any list will be out of date within a year, but the honest 2026 read is that these categories should be piloted with clear exit criteria rather than bet on as the core of a production programme.

Further reading

• Physical Intelligence Pi0 paper and Pi0.5 update
• NVIDIA Isaac GR00T project and N1 / N1.5 / N2 model cards on Hugging Face
• Figure Helix announcement and dual-system overview
• Google DeepMind Gemini Robotics and Gemini Robotics-ER announcements
• RT-2: Vision-Language-Action Models — original Google paper that started the lineage
• OpenVLA — open-source VLA reference implementation
• NVIDIA Isaac GR00T N1.5 vs Cosmos robot foundation model deep dive
• Boston Dynamics Atlas Hyundai deployment architecture
• Isaac Sim 4.5 domain randomisation tutorial for VLA training
• ISO 10218-1:2025 — Safety requirements for industrial robots
• ISO/TS 15066 — Collaborative robots safety guidance