Industrial Physical AI
The Model Fills the Room.
Hardware Builds the Room.
What Industrial Physical AI actually requires, and why most robots aren’t ready.
Dexmate Team
June 29, 2026
Physical AI is having a breakout year. We’re watching robot policies fold laundry, clear tables, sort parts, and take instructions in plain language, which would have seemed far-fetched not long ago. Nearly all of that progress traces back to the models getting better: larger vision-language-action networks, better training recipes, cleaner architectures. So the natural assumption is that the road to robots that actually hold up in the real world runs through a still-better model.
We don’t think it does, at least not on its own. We’ve deployed robots on real factory floors, and the thing that separates an impressive demo from a deployment you can depend on is almost never the model. It’s the machine the model runs on.
It’s worth being precise about what a Physical AI system actually is, because it’s tempting to picture a single neural network doing all the work. What you really have is a closed loop.
Every Physical AI robot runs this loop. The model is just one box in it. Schematic after NVIDIA Isaac GR00T.
On every control cycle, the model takes in multi-view camera frames, the language instruction, and the robot’s own joint state, and emits a short chunk of motor commands. (Usually that model is a vision-language-action model, or VLA; sometimes a world-action model, or WAM.) The robot moves, the world changes, fresh observations come back in, and the loop runs again, dozens to hundreds of times a second.
The model is one box in that loop. Almost everything around it is hardware: the sensors that produce the frames, the compute that runs inference, the body that carries out the actions, the safety system that keeps them in check. And that hardware puts a hard limit on what any model in the loop can do. You can have the best policy in the world, but if your cameras drift out of sync, or your compute can’t keep up, or your body can’t last a shift, or your safety system was built for a robot that no longer moves the way this one does, the policy never gets the chance to show what it can do.
The model fills the room; the hardware builds it. This post walks through the four hardware decisions that set the size of that room, and it ends with a short list of questions you can use to size up any robot, ours included.
Data is scarce, and bad sensors waste what little there is
Start with the raw input to all of this: data. The big foundation models are trained on staggering amounts of it. Robotics has almost none by comparison.
The largest robot-manipulation datasets ever assembled, Open X-Embodiment and AgiBot World, come to roughly a million clips between them. A video-generation model like Cosmos or Wan trains on several billion. Robotics is working with one of the smallest datasets anywhere in AI, short of where it needs to be by a factor of a thousand or more.
Robotics is working with one of the smallest datasets in AI, by orders of magnitude.
That gap would be hard enough on its own. The bigger problem is that a lot of the little data we do collect turns out to be unusable, and not because the task failed. The recording itself gets corrupted at capture. A camera stalls or freezes and the stream goes stale. A motor overheats, quietly throttles itself, and changes how the robot behaves halfway through an episode. Frames arrive out of order and scramble the timeline, so the policy ends up learning the wrong cause and effect. Or the camera latency drifts away from the proprioception, and the pixels and the joint angles end up describing two slightly different moments.
In practice we throw out twenty to thirty percent of episodes in quality filtering, including plenty where the task actually succeeded, before we count any outright failures.
And the fix isn’t better software, which is the part that trips people up. The corruption starts down in the hardware, at the camera link. Consumer USB cameras, which most research setups default to, drop frames under load, fall out of sync with one another, run over short cabling that picks up electrical noise, and deliver latency you can’t predict. The automotive world dealt with this years ago using GMSL, a camera link designed for cars stuffed with sensors and electrical noise. It gives you hardware-synchronized capture, long shielded cabling, EMI tolerance, and predictable latency. The gap between the two is large: on the same camera, GMSL holds time-sync to around fifteen microseconds, while USB sits somewhere in the ten-to-fifteen-millisecond range, roughly a thousand times looser.
From there you put every sensor on the same clock. With hardware PTP, the network interface timestamps each packet right at the wire against its own onboard clock, so jitter from the operating system never creeps in, and the cameras, lidars, and IMUs all end up sharing one timeline to within microseconds. It reads like plumbing, but it’s what makes the data trainable in the first place, and it’s the most common quiet reason a policy that worked in the lab falls apart on the floor.
Get capture right and the robot becomes more than a worker. It turns into a data instrument. Every hour it spends deployed produces clean, aligned, reproducible episodes, those episodes feed the next training run, the next policy comes out better, and the robot grows more useful. The effect compounds.
Clean capture turns every deployment into training-grade data, a flywheel that raises the ceiling over time.
That flywheel is how the data ceiling rises over time, but only if the hardware underneath it is producing data worth keeping in the first place.
Compute and power: don’t starve the brain
Clean data gets you a capable policy, trained on a GPU cluster. But none of that pays off unless the policy then runs on the robot itself, every cycle, and that’s a separate hardware problem.
The obvious shortcut is to run the model in the cloud, and on a factory floor it doesn’t hold up. Fast, reliable Wi-Fi is rarely available across an entire working facility, and a control loop that has to round-trip to a datacenter stalls the instant the connection hiccups. There’s also the matter of streaming raw video off-site, which means handing a customer’s operations, their products, their processes, and their people, to someone else’s servers, and most plants simply won’t agree to that. So the policy has to run onboard.
Running a modern VLA onboard, on every cycle, takes real compute. A traditional industrial controller draws ten to twenty-five watts and delivers essentially no AI throughput, because it’s replaying a fixed program rather than perceiving anything. Vega, our robot, carries an onboard NVIDIA Jetson Thor instead. It draws forty to a hundred and thirty watts and delivers around 2,070 AI TFLOPS with 128 GB of memory, which is enough to run a full-size policy at full rate with room to spare. And where a fixed program sips power, the Thor pulls its watts continuously, every cycle the robot is switched on.
That leads to a fact that catches people off guard. In a Physical AI robot, the motors aren’t the only major power draw anymore; the AI compute sits right next to them. The Thor-class module runs inference every cycle and pulls its watts the whole time, while the motors draw hard in bursts and stay light in between. The battery, in other words, has to be sized for the brain as much as the body. Vega’s 4.8 kWh pack gives it about twenty hours of runtime, and still more than sixteen hours with the AI pinned at full load.
Twenty hours on one charge, arm and torso in constant motion — a full shift, not a demo.
That’s what separates a robot that works a full shift from one that only works a demo. Size the battery for the motors alone and forget the compute, and the demo is what you’ll get.
The body has to survive the floor, not just the demo
It helps to see where these machines come from. Industrial robots have arrived in roughly three generations.
Generation
What it has
What it lacks
Built for
Programmed
Brawn — deterministic, fast, precise
Brains — blind; re-engineered for every task
The fixed line
Research
Brains — learns from data, adapts
Brawn — lab bench, single webcam, no safety story
The benchmark
Industrial Physical AI
Both — research-grade adaptability, industrial-grade durability
—
The floor
The first is the programmed robot: deterministic, fast, precise, and blind. Plenty of brawn, no brains, and it has to be re-engineered for every new task. The second is the research robot, which learns from data and adapts but is built for a lab bench rather than a shift, usually with a single webcam, often tethered, and no real safety story to speak of. Brains, but no brawn. The third generation, where Vega sits, has to bring both at once: the adaptability of the research robot and the durability of an industrial one, in a single machine that actually ships.
Adaptable work asks a lot of the body. A policy that can do dozens of jobs is wasted if the body can’t physically reach them. Vega’s arm runs about fifteen centimeters longer than a human arm, so it sweeps a much larger reachable volume, more than two meters of span, without moving its base. The torso folds in three, which lets the robot stow compact for a tight cell and then extend to a vertical reach past two meters, from a part on the floor to the top of a rack. Each arm carries fifteen pounds while staying no thicker than a person’s, so you get the strength without the bulk that heavy payloads usually bring.
A long arm and a three-fold torso reach from the top of a rack down to a part on the floor.
And it holds a dumbbell in each hand — 15 lb per arm, in an arm no thicker than a person’s.
None of it counts for much if the machine can’t keep doing it. The real bar for industrial work isn’t a thirty-second clip. It’s sixteen hours a day, every day, for a year, and almost no humanoid robot clears that bar yet. Designing for it is unglamorous work: thermal headroom, duty cycle, serviceability, the mean time between failures.
It also drove a deliberate choice that separates Vega from most of the humanoid field: a mobile base instead of legs. Wheels keep the robot’s motion bounded and stable and give it a much simpler safety case. They also take whole categories of failure off the table, including the balance computation, the fall risk, and the difficult safety argument that legs demand. For industrial work, that’s a trade worth making.
Safety: the AI drives, but you still own the safety
The last wall is the one the industry has spent the least time on, mostly because it’s so new.
For fifty years an industrial robot did exactly what it was told. Its motion was scripted, bounded, and possible to verify ahead of time, so safety came down to guarding the cell and proving the program correct. That whole assumption is gone now. In a Physical AI system the operator is an AI policy, and before long the supervisor managing it will be an AI agent too. You can’t read the robot’s next move off a script, because there isn’t one. A learned policy can, in principle, output anything at all.
That changes what safety even means. It stops being about writing safe code ahead of time and becomes a matter of watching and bounding an unpredictable operator in real time, while it’s actually in control. Since you can’t make the operator predictable, you build the safety into the body and the system around it instead. Three hardware-level decisions do most of the work.
First, physical safety that assumes a command will eventually surprise you. Every major joint has a brake that freezes its position the moment control is cut, so “stop” means the arm holds where it is rather than collapsing or whipping around. The center of mass sits low and wide, so an unexpected motion turns into a contained wobble instead of a tip-over. And self-collision checking runs in real time on every motion, both arms included during bimanual work, blocking anything that would drive the robot into itself.
Second, a safety gate sitting between the policy and the motors. Because the policy can emit anything, a validation layer in front of the actuators rejects out-of-bounds or nonsensical commands before they reach a joint. Support for action chunks is built in, so the control stays smooth and real-time instead of stuttering; the policy’s output is checked and streamed to the actuators at a steady rate.
Third, channels meant for an AI supervisor, not just a human at a button. A robot that an agent is running has to be readable and stoppable in software, so Vega exposes two of them. The first is a dual-format event log that pairs machine error codes with a plain-language description an agent can actually reason about:
The second is a programmatic e-stop, an endpoint that a supervising agent or a person can call to halt the robot at once, with no physical button needed:
That’s what separates a robot you’d let an AI drive on your floor from one you wouldn’t.
The ceiling, raised
It’s worth noticing that not one of those four decisions was about the model.
The policy lives under what the hardware allows. The ceiling is the lowest wall, not the average.
Clean, synchronized data. An onboard brain with the power to keep it fed. An industrial body that survives the floor. Safety built for an AI operator. Four hardware walls, and they hold up a ceiling. The policy lives underneath that ceiling, and it can only ever rise as high as the hardware lets it.
The corollary matters more than the rule. A ceiling held up by four walls is only ever as high as the lowest wall. A great data pipeline counts for nothing if the robot can’t last a full shift, and the most capable policy in the world counts for nothing if you can’t safely let it drive. You don’t get to average the four. You raise whichever one is lowest.
Four questions to ask any vendor
That gives you a simple, vendor-neutral way to size up any Physical AI robot, one question per wall. Put them to us, and to everyone else in the room.
01
Data. Are your cameras and lidars hardware-synchronized, with latency you can actually control? Ask to see the timestamps.
02
Compute. Can it run a modern VLA or WAM fully onboard, every cycle, and what’s the power budget while it’s running inference?
03
Body. How many hours a day can it run, for how long, and at what pose is the rated payload actually measured?
04
Safety. How do I stop it when an AI is driving, and what happens to the joints when I do? Will the robot fall?
The honest answers to those four questions tell you where a robot’s ceiling actually sits.
Where this goes
The models will keep getting better, and fast. That’s exactly why the hardware matters more rather than less. Every gain in the policy only shows up on your floor if the machine underneath it can keep up. The room has to be built before the model can fill it.
The model fills the room; the hardware builds it. We built Vega to give your AI the highest ceiling we know how to build, and to answer all four of those questions without flinching. ■
Takeaway
Physical AI is racing ahead on the model side, but a deployment is only ever as good as the hardware underneath it allows. Four hardware decisions set the ceiling on what any policy can do on a real floor. You need clean, time-synchronized data so the model can learn. You need an onboard brain, and a battery sized for it, so the model can run every cycle. You need an industrial body that survives sixteen-hour days rather than demos. And you need safety designed for an AI operator you can’t predict. The ceiling is the lowest of those four walls, not the average of them. So before you judge the model, judge the machine, and ask every vendor, ours included, the four questions above.
Dexmate · Industrial Physical AI