"Simulation" is not One Thing in Robotics - From Behaviour to Outcome.

Physical AI in Production - Part III (Article 3 of 3 )

Robotics is bang in the middle of a real acceleration. Robot learning is picking up speed, with larger real-world datasets, better pre-training capabilities, better policy guidance, and simulation frameworks that can run massive numbers of parallel rollouts.

The part that gets swept into the broad word - “simulation” bothers me, though. It’s often brought up as important but as a single capability - mostly about simulating robot behaviour. This is a half-truth. Not because simulation isn’t critical, but that “simulation” bundles together multiple jobs that reduce different kinds of uncertainty.

Robotic simulation success is not automatically deployment success: A robotics simulator answers - can the system execute the task?. Simulation is scalable and safe; it’s a powerful environment for training, benchmarking, and large-scale data generation.

However, in simulation, we use abstractions and approximations, and those gaps can limit how reliably policies transfer from simulation into the real world (Sim2Real Gap)

What uncertainty are we trying to reduce? What kind of simulation reduces it at a cost and speed that matters for day-to-day operations?

---

There has been an increased sharing of starting points - open datasets, pre-trained checkpoints, and open-source stacks make robotic workflows more reproducible, and reduce the time and cost of cold starts.

Open Datasets like Open X‑Embodiment’s community dataset (1M+ n+ real-robot trajectories across multiple robot embodiments to enable cross-embodiment learning and reuse), and DROID (Distributed Robot Interaction Dataset - Open-Source Large-Scale Robot Manipulation Dataset with 76K demonstration trajectories and 350h of interaction data across 564 scenes and 86 tasks globally over a year).

There’s also LeRobot’s end-to-end library - vertically integrated open stack tooling across middleware, dataset handling, training, and inference/deployment. Then GPU-native simulation frameworks like Isaac Lab, are making training and evaluation more scalable, integrating high-fidelity physics and modularly rendering environments

These speed up how fast you can iterate on behaviour learning. But they only tell a part of the story.

---

Behaviour is not the same as Consequence.

Physical AI Simulation needs to include behaviour plus outcomes - throughput, yield, safety, availability, and ability to change the system without breaking it.

A robot can pick and place, insert, tighten, spray, route correctly, or drive - and still create the wrong business result if the consequences of its actions are poorly modeled - unstable contact, material damage, thermal drift, process variation, fluid behaviour, gradual wear that accumulates over weeks, or congestion that has a downstream impact.

The problem is that these are actually different simulation problems.

Robotics simulation (learn behaviour faster): This is what most people are actively discussing in Physical AI simulations today - simulating kinematics and dynamics, contact, sensor streams, and environment interaction - so you can train and test policies at scale. It helps you learn faster, test more variations, and reduces the cost of testing on real hardware.

Physics and multi-physics simulation (understand and predict consequences): Trying to understand what actually happens to the work and the process - how is Stress distributed, how do materials deform, how does temperature change, how does tolerance shift, or how a part’s properties change under load and heat.... We need models that handle thermodynamics, mechanics, and materials engineering to represent these behaviours.

Surrogates and reduced-order models (ROMs) (make physics cost-effective and fast enough to use continuously, increase the exploration over the design-space): High-fidelity simulation is often too slow for everyday decision loops. Surrogate models can provide fast, approximate predictions. And when full multi-physics is too computationally heavy, ROMs can meet real-time requirements. Surrogates help not only in validating designs to discovering better designs through non-intuitive thinking.

This matters because, as in my previous posts, Physical AI is viable when you can change the system at scale safely and efficiently (cheaply) - so if you can model outcomes and validate changes quickly, you can iterate more safely. If you cannot, every change is expensive and slow to re-qualify - different simulation layers reduce different parts of the cost.

---

Let’s take the example from my previous post (where we pilot a general-purpose Robot)

• 6 robots x 16 hours per day x 10 min of human support per robot-hour = 960 minutes of support per day (16 hours/day).

• Labour Cost is £45/hour, which means £720/day of support or £180,000/year (250 working days). If we can improve policy to cut that time in half, we can save about £90,000/year.

What’s causing this need for support time in the first place?

If it’s sequencing, edge cases, or poor policy generalisation, then better robot-learning stacks and better robotics simulation reduce it. If it’s because of contact instability, deformation, changing friction, thermal drift, or tool–material interaction, we need multi-physics models to predict what will happen before you let the robot do it at production scale. And if the physics model is too slow to run frequently, we need a surrogate layer so validation is cheap enough to do so continuously rather than once/ad-hoc.

---

Let’s take another example where small percentages matter:

• A production line outputs 20K units/day. Holds/Misses which could be avoided affect just 0.5% - 100 units/day. Direct handling cost is about £10/unit. That’s £250,000/year over 250 days in direct cost (not including warranty, scrap, brand reputation, etc). In this example, it’s not about robotics simulation but modelling the process outcomes under variability, and doing this fast enough to explore multiple scenarios.

  ---

So when I talk to businesses about simulation-led strategies for autonomy - the question I have is - what kind of uncertainties are we trying to reduce, and which simulation jobs do we need to reduce them?

Usually it’s a combination of all three.

-

Pallavi Chari, Moving Parts | Linkedin

---

• _{Physical AI in Production Part I}

• Physical AI in Production Part II