What You Actually Build and Train Physical AI On: The Full Stack From Simulation to Edge Compute

If you strip away the marketing, a physical AI stack is a fairly small number of layers stacked on top of each other: simulated worlds where a robot practices billions of times before it ever moves in real life, teleoperated or human demonstration data that teaches it what “correct” looks like, a foundation model that turns perception into action, a middleware layer that routes messages between sensors, actuators and planners in real time, and an edge compute board bolted to the robot that runs all of it locally, in milliseconds, with no cloud round-trip. Every commercially serious humanoid, warehouse robot or robotic arm shipping in 2026 is built on some version of this stack, and the specific pieces — NVIDIA’s Jetson Thor boards, Isaac Sim, GR00T foundation models, ROS 2 middleware — show up again and again because they’ve become the default rather than because there is no alternative.

This article walks the stack top to bottom: what gets trained where, what gets deployed on which hardware, and why the layers are arranged the way they are.

What is the physical AI stack, exactly?

The physical AI stack is the set of software and hardware layers a team needs to take a robot from “can perceive its environment” to “can act correctly and safely in the physical world, on its own compute, in real time.” In practice it decomposes into five layers that map cleanly onto a development pipeline:

1. Simulation and world models — where a robot’s policy gets its first million (or billion) attempts at a task, in a physics-accurate virtual replica of its environment, before risking real hardware.
2. Data collection: teleoperation and demonstration — human-in-the-loop control sessions, VR teleoperation rigs and motion-capture setups that generate the labeled trajectories a model imitates or fine-tunes on.
3. Foundation models for action — vision-language-action (VLA) models such as NVIDIA’s Isaac GR00T family that take camera and sensor input and output motor commands, typically pretrained on internet-scale and synthetic data, then fine-tuned per robot embodiment.
4. Middleware and orchestration — a real-time messaging and node framework, almost always some version of ROS 2 today, that wires together perception nodes, planners, controllers and safety systems on the robot.
5. Edge compute hardware — the onboard system-on-module, increasingly NVIDIA’s Jetson family, that has to run perception, the action model’s inference pass, and control loops within a power and thermal budget that fits inside a robot chassis rather than a data center rack.

None of these layers is optional in a production system. A model trained purely in simulation without any real demonstration data typically fails to transfer (“sim-to-real gap”); a model with no simulation stage is prohibitively expensive and dangerous to train through real-world trial and error alone; and no model, however good, is useful without middleware and edge silicon capable of running it under a robot’s actual power and latency constraints. The rest of this piece goes layer by layer, with the specific tools and numbers that define each one as of mid-2026.

Why can’t you just train a robot in the real world?

Because real-world trial-and-error is slow, expensive and occasionally destructive, and a modern learned policy needs millions of attempts to converge — a volume of practice no real-world process can supply safely, quickly or cheaply enough. A simulator lets a team run a task attempt in a fraction of a second, in parallel across thousands of simulated instances on a GPU cluster, with no risk to hardware and no need for a human supervisor in the loop. This is why simulation sits at the base of essentially every serious physical AI training pipeline rather than being treated as a nice-to-have.

The trade-off is the “sim-to-real gap”: a policy trained purely on simulated physics and rendering can pick up on shortcuts and visual artifacts that don’t exist in the real world, and then fail when it’s deployed onto an actual robot. Modern pipelines close this gap in two ways: domain randomization (varying lighting, textures, friction and mass in simulation so the policy can’t overfit to a single simulated appearance of the world) and synthetic-data generation pipelines that produce photorealistic, physically-grounded training episodes at a scale real-world data collection can’t match. NVIDIA’s own research on its GR00T N1.5 model is a useful, concrete illustration of how much synthetic data can move the needle: on a set of 12 tasks introduced specifically to test generalization on DreamGen-generated synthetic data, GR00T N1.5 hit a 38.3% success rate versus 13.1% for the earlier GR00T N1 — nearly a threefold improvement attributable largely to better synthetic-data training, not new hardware. That’s the kind of gain simulation and synthetic data make possible — a gain real-world-only data collection realistically can’t match, given how much slower and more constrained physical trials are.

Simulation and digital twins are a large enough discipline in their own right — physics engines, sensor simulation fidelity, domain randomization tooling — to warrant a dedicated deep dive into simulation and digital twins as its own layer of the stack.

Where does the data that trains these models actually come from?

Simulation solves scale, but it doesn’t solve the “what does correct behavior actually look like” problem for tasks with a lot of nuance — delicate manipulation, ambiguous multi-step tasks, anything where the reward signal is hard to define programmatically. That’s where teleoperation and human demonstration come in. A human operator, often wearing a VR headset or using a haptic controller rig, pilots the robot (or a simulated proxy of it) through a task, and every joint angle, camera frame and control input gets logged as a labeled trajectory. Foundation models are then trained to imitate these trajectories directly, or fine-tuned on them after an initial simulation-heavy pretraining stage.

This is a genuinely distinct engineering discipline from either simulation or model training: it involves latency-sensitive teleoperation hardware, data pipelines for cleaning and labeling demonstration sessions, and increasingly its own tooling for scaling data collection across many robots and operators simultaneously rather than one robot at a time. Teams building this part of the stack in isolation from the rest of the pipeline tend to underinvest in it, which is a mistake — a foundation model is only as good as the demonstrations it’s shown, and current industry practice treats teleoperation and data collection as its own pipeline stage with its own tooling and headcount, not a one-off exercise before “real” model training starts.

What is the foundation model layer, and what does it actually do?

The foundation model layer is where perception becomes action. A vision-language-action (VLA) model takes in camera frames (and sometimes language instructions, proprioceptive sensor data, or both) and outputs a sequence of motor commands — joint torques, end-effector positions, gripper states. NVIDIA’s Isaac GR00T family is the most visible example of this category as of 2026: a foundation model pretrained across a mix of internet-scale video/language data, simulated robot trajectories, and real teleoperated demonstrations, then fine-tuned per robot embodiment and task set.

It’s worth being precise about where the GR00T line actually stands as of this writing, because coverage is inconsistent. GR00T N1.5 is a documented, benchmarked release from NVIDIA Research, with published numbers (the 38.3%-vs-13.1% synthetic-task result cited above). Beyond that, some industry roundups describe a newer GR00T N1.7 as a General Availability release with full production support guarantees, while NVIDIA’s own developer forum posts and Hugging Face’s coverage describe it as an Early Access release rather than GA. Those two characterizations are not reconcilable from public information as of this writing, so treat GR00T N1.7’s production-readiness status as unsettled rather than confirmed — a genuinely useful thing to know before you commit to a production timeline for it.

What is confirmed, and probably more important for a team scoping a build, is the scale of the ecosystem around this model family. NVIDIA announced at GTC 2026 that its robotics stack — spanning Jetson edge hardware, the Isaac simulation and development platform, and GR00T foundation models — now has more than 2 million developers building on it, and NVIDIA and Hugging Face announced plans to unite that community with Hugging Face’s roughly 13 million AI builders. That scale matters practically: it’s the difference between adopting a platform with a thin, unstable ecosystem and one with a large enough base of tooling, tutorials, pretrained checkpoints, and hireable talent that the platform risk is comparatively low. Whether a competing foundation model beats GR00T on any single benchmark matters far less than the depth of its ecosystem, which is why the two are worth weighing separately. A dedicated look at how Isaac and GR00T fit together as a platform — not just as a model — is worth reading before you bet your roadmap on it.

What software runs on the robot itself, and why is it almost always ROS 2?

Underneath the foundation model, a robot needs a real-time framework that wires together its sensors, its planners, its safety interlocks and its actuators, passes messages between them with predictable latency, and gives every one of those components a common way to talk to every other one regardless of which team or vendor wrote it. This is the job of middleware, and in 2026 that middleware is, for the vast majority of new commercial and research robots, some distribution of ROS 2 (Robot Operating System 2), the open-source successor to the original ROS, built to handle real production concerns — real-time performance, multi-robot support, and a DDS-based communication layer — that ROS 1 was never designed for.

ROS 2 ships as a series of named distributions on a predictable release cadence, and the two relevant to anyone starting a build today are:

Distribution	Type	Released	Supported until
ROS 2 Jazzy Jalisco	Long-Term Support (LTS)	May 2024	May 2029
ROS 2 Kilted Kaiju	Standard release	May 2025	November 2026

The practical implication of this table is straightforward: a team building something meant to stay in production for years without a forced mid-life migration should default to the LTS release (Jazzy Jalisco, supported into 2029) rather than a standard release with an eighteen-month support window. Standard releases like Kilted Kaiju are the place to track newer features and faster-moving APIs, but they are not the release you want underneath a fleet of robots you don’t plan to re-flash next year.

It’s worth noting that some market-research aggregators publish adoption figures for ROS 2 versus the original ROS 1 — figures like a specific market-share percentage, or a count of new ROS-based robot models released this year with a stated ROS 2 proportion. Those figures could not be verified against a second independent primary source for this piece, so they’re left out here rather than repeated as fact. What is verifiable and worth acting on is simpler: ROS 2 is the active development target, ROS 1 is not receiving new distributions, and the LTS-versus-standard-release trade-off above is the concrete decision a new project actually has to make.

Running ROS 2 well in a fleet — rather than on a single robot on a bench — is its own discipline: managing node lifecycles across many machines, handling network partitions between robots, versioning message schemas without breaking every robot in the field at once. That operational layer is covered in more depth in a piece on running ROS 2 in production robotics environments, which is worth reading once the single-robot prototype stage is behind you.

What hardware do you actually deploy this stack onto?

Everything above — the foundation model, the ROS 2 graph, the perception pipeline — eventually has to run inside a robot chassis, on a compute module with a real power budget, real thermal limits, and no guaranteed network connection to a data center. This is the edge compute layer, and NVIDIA’s Jetson line is the dominant reference platform for it in 2026, most notably the Jetson AGX Thor.

The specs are worth stating precisely because they define what’s actually feasible to run onboard versus what still has to be offloaded to a nearby server or the cloud:

Spec	Jetson AGX Thor (T5000 module)
AI compute	Up to 2,070 FP4 TFLOPS / 1,035 FP8 TFLOPS
GPU	Blackwell architecture, 2,560 CUDA cores, 96 Tensor Cores
CPU	14-core Arm Neoverse
Memory	128GB LPDDR5x
Performance vs. Jetson AGX Orin (previous generation)	~7.5x AI performance, ~3.5x energy efficiency
Developer kit price	$3,499 USD

Two things stand out in that table. First, the generational jump over the previous Jetson AGX Orin — roughly 7.5x the AI performance at roughly 3.5x better energy efficiency — is a large enough leap that it changes what’s architecturally sane to run onboard versus what needs a network round-trip; a foundation model inference pass that previously had to be split across edge and server compute can plausibly run entirely on-device now. Second, the $3,499 developer kit price point is a genuinely accessible number for a board with this much onboard AI compute, which is part of why it’s become a default reference platform for teams prototyping physical AI systems rather than a niche high-end option reserved for well-funded labs.

The practical takeaway for anyone scoping a build: the edge compute question is no longer “can we fit any useful model on the robot” — with 128GB of memory and over 2,000 FP4 TFLOPS available, the answer to that is comfortably yes for current-generation VLA models. The real question is thermal and power budget inside a specific chassis, and how much of that generous compute envelope gets consumed by perception and safety systems before the action model even gets its turn.

How does the stack change between a research prototype and a production robot fleet?

A research prototype typically runs a heavier, less optimized version of every layer: a full-fidelity simulator with no need for real-time performance, a foundation model run largely unquantized for maximum accuracy, and a ROS 2 graph running on a single robot with no fleet-management concerns. Moving to a production fleet changes the requirements at every layer simultaneously, not just at the edge-hardware layer:

• Simulation shifts from “get one policy working” to “regression-test every policy change against the same simulated scenario suite before it ships to the fleet,” closer to a CI pipeline than a research notebook.
• Data collection shifts from ad hoc teleoperation sessions to a standing pipeline that continuously ingests new demonstrations, including corrections logged from real deployed robots (a form of active learning some teams call “failure mining”).
• The foundation model typically gets quantized, distilled, or otherwise optimized for the specific edge hardware budget rather than run in its research configuration.
• Middleware has to handle fleet-wide concerns — rolling software updates without taking every robot offline at once, telemetry aggregation, and safety monitoring across dozens or thousands of units rather than one.
• Edge hardware selection becomes a real cost line item multiplied across a fleet, not a one-off dev kit purchase, which is why the price and efficiency numbers above matter more at fleet scale than they do for a single prototype.

This transition — from single-robot prototype to fleet-operated production system — is a big enough discipline shift that it’s really its own topic rather than a footnote to the stack itself; running and monitoring a live robot fleet touches on deployment pipelines, remote monitoring, and incident response in ways a training stack alone doesn’t cover, and is treated separately as its own operational layer above the stack described here.

Who is actually building on this stack today, and does the money back it up?

It’s worth grounding the “this is the dominant stack” claim in observable capital allocation rather than just tooling popularity, because funding decisions are one of the few signals that are both public and hard to fake.

Amazon is the clearest large-scale production example: the company has deployed more than 1 million robots across its global fulfillment network as of mid-2025, spanning systems like Sequoia, Hercules, Pegasus and Proteus, and has continued expanding that fleet through 2026 alongside releasing its own generative AI foundation model for warehouse robotics — a direct, at-scale instance of the simulation-to-edge-compute stack described above being run in a live commercial environment rather than a lab.

On the venture side, two funding rounds from 2025–2026 illustrate how much capital is backing full-stack physical AI companies specifically (as opposed to component vendors). Figure AI closed a Series C exceeding $1 billion at a $39 billion post-money valuation in September 2025, led by Parkway Venture Capital. More recently, German full-stack robotics maker Neura Robotics raised a Series C of up to $1.4 billion — reported as the largest funding round ever for a full-stack robotics company — led by Tether, with participation from NVIDIA, Amazon, Qualcomm, Bosch, Schaeffler and the European Investment Bank, taking its valuation to $7 billion. Notably, that investor list includes a chipmaker (NVIDIA), a hyperscaler with its own robotics fleet (Amazon), and established industrial manufacturers (Bosch, Schaeffler) — a cross-section that reflects how many different parts of the value chain now have a direct stake in the same stack succeeding.

Beyond these two verified rounds, there are widely circulated aggregate figures for total 2026 robotics/humanoid venture funding — figures in the tens of billions, cited differently across sources with no clear shared methodology. Those aggregate totals varied enough across otherwise-credible sources, without a reconcilable methodology, that they’re deliberately left out here rather than reported as a single settled number.

What does a reference physical AI stack look like end to end?

Putting the layers together into a single reference architecture, roughly in the order data and control actually flow:

Layer	What it does	Representative tooling (2026)
Simulation & synthetic data	Physics-accurate training environment, domain randomization, synthetic trajectory generation	NVIDIA Isaac Sim, DreamGen-style synthetic pipelines
Data collection	Human teleoperation and demonstration capture, VR/haptic piloting rigs	Teleoperation rigs feeding labeled trajectory datasets
Foundation model (VLA)	Perception + language → action policy, pretrained then fine-tuned per embodiment	NVIDIA Isaac GR00T family
Middleware / orchestration	Real-time node graph: perception, planning, control, safety	ROS 2 (Jazzy Jalisco LTS or Kilted Kaiju standard release)
Edge compute	Onboard inference and control within the robot’s power/thermal envelope	NVIDIA Jetson AGX Thor (T5000 module)

Reading this table top to bottom is effectively reading a robot’s development timeline: a policy is born in simulation, refined against human demonstration data, packaged into a foundation model, wired into a ROS 2 graph, and finally deployed to run inference on a Jetson-class board bolted into the chassis. Skipping a layer doesn’t remove the underlying problem — it just means the problem shows up later and more expensively, usually as a robot that works in the lab and fails in the field.

For a broader map of how this layer of the stack connects to the rest of the physical AI landscape — foundational concepts, humanoid hardware, applied use cases and market dynamics — the Physical AI Stack hub is the place to see how this piece fits alongside the rest of the cluster. And for precise definitions of terms used throughout this piece — VLA, sim-to-real, domain randomization and the rest — the site glossary is worth bookmarking rather than re-deriving definitions from context every time.

These four layers are also where the discipline of engineering an agent actually lands once that agent has a body: harness, memory, evaluation and human oversight all have direct, physical-world analogues here rather than staying abstract. Agentic engineering for physical AI walks through exactly how that mapping works, and why the loop closes differently than it does for a software-only agent.

Frequently asked questions

What’s the difference between the physical AI stack and a “robotics software stack”? In practice the terms overlap heavily, but “robotics software stack” is often used more narrowly to mean the on-robot software — middleware like ROS 2, drivers, planners and controllers — while “physical AI stack” more commonly includes the full training pipeline behind that software: the simulation environment, the data collection process, and the foundation model, none of which necessarily run on the robot itself. If someone says “robotics software stack,” it’s worth clarifying whether they mean just the runtime layer or the whole pipeline described in this article.

Do I need NVIDIA hardware specifically to build a physical AI system? No, but as of 2026 NVIDIA’s combination of Jetson edge hardware, Isaac simulation tooling and GR00T foundation models has become the default reference stack for a large share of the industry, reflected in the more than 2 million developers NVIDIA reports building on its robotics platform. Alternative simulators, edge boards and foundation models exist, but choosing NVIDIA’s stack currently means inheriting the largest ecosystem of tutorials, pretrained checkpoints, and hireable talent, which is a real practical advantage independent of any single benchmark comparison.

Is GR00T N1.7 production-ready? This is genuinely unsettled in public reporting as of this writing. Some industry coverage describes it as a General Availability release with full support guarantees; NVIDIA’s own developer forum posts and Hugging Face’s coverage describe it as Early Access, not GA. Teams evaluating it for a production timeline should treat its readiness status as unconfirmed rather than assume either characterization, and verify directly with NVIDIA’s current documentation before committing to a launch date for it.

Should I start with ROS 2 Jazzy Jalisco or Kilted Kaiju? For anything meant to stay in production for more than a year or two, Jazzy Jalisco is the safer default: it’s the current Long-Term Support release, supported until May 2029, versus Kilted Kaiju’s standard-release window running only into November 2026. Kilted Kaiju is worth tracking for newer features, but not as the base a fleet gets built on if you don’t want a forced migration within eighteen months.

How much does it actually cost to get started with a Jetson-class edge board? The NVIDIA Jetson AGX Thor Developer Kit lists at $3,499 USD, which buys a Blackwell-architecture GPU with 2,560 CUDA cores and 96 Tensor Cores, a 14-core Arm Neoverse CPU, and 128GB of LPDDR5x memory, delivering up to 2,070 FP4 TFLOPS of AI compute. That’s roughly 7.5 times the AI performance and 3.5 times the energy efficiency of the previous-generation Jetson AGX Orin, at a price point accessible to teams well below hyperscaler budgets.

Why can’t a robot just be trained entirely in simulation, without any real-world data? Because simulated physics and rendering never perfectly match the real world — a gap known as the sim-to-real gap — and a policy trained purely in simulation can learn to exploit quirks of the simulator that don’t exist in reality, then fail when deployed onto an actual robot. Techniques like domain randomization and photorealistic synthetic-data generation narrow this gap substantially (NVIDIA’s own benchmarks show GR00T N1.5 nearly tripling task success versus GR00T N1 on synthetic-data test tasks), but they don’t eliminate the need for at least some real demonstration data and real-world validation before deployment.

What’s the single biggest bottleneck in building a physical AI system today: hardware, models, or data? Most teams that have actually shipped a system point to data — specifically, the volume and quality of real demonstration and teleoperation data — as the tightest constraint, more than raw compute or model architecture. Edge hardware like Jetson AGX Thor now offers enough onboard compute that it’s rarely the limiting factor for current-generation models, and foundation models like the GR00T family are broadly available to fine-tune; what’s harder to obtain at scale is well-labeled, embodiment-specific demonstration data, which is why teleoperation and data collection pipelines have become a standalone discipline rather than an afterthought.

Does a robotics software stack always mean ROS 2 today? It’s the default for new commercial and research robots as of 2026, given its active development, the size of its ecosystem, and the two currently supported distributions (Jazzy Jalisco LTS and Kilted Kaiju standard release). It is not, however, universal — some production systems, especially at the largest fleet operators, run custom or proprietary middleware built before ROS 2 matured, or layered on top of it. Adoption-percentage figures circulating in market reports could not be independently verified for this piece, so treat specific market-share numbers for ROS 2 with some skepticism until you can trace them to a primary source.