Robotics is moving quickly.
At Actuate 2026, that was hard to miss. Foxglove brought more than 1,000 robotics developers together at Fort Mason in San Francisco on August 18–19, with sessions from NVIDIA, Wayve, Aurora, Physical Intelligence, Zipline, Shield AI, Google DeepMind, and others.
There were two conferences happening in that building.
The one on stage was about AI. World models, generative models, reinforcement learning, simulation, and data. Generalist announced GEN-1.5 on day two, a model that learns a new task from a three to twelve second demonstration with no gradient updates, and people were still talking about it in the hallways that afternoon. NVIDIA's physical AI session was legitimately excellent. The work on that stage is genuinely impressive.
The one at the booths was about something else entirely.
We spent two days talking with dozens of companies that have robots deployed in the field right now. Almost none of those conversations were about models. They were about how to reliably get software onto real hardware and keep it working.
That's the gap I left with. The industry's attention is on the model. The industry's pain is three layers underneath it.
Here's what we heard.👇
I asked nearly every team at our booth how they build and ship their robot software. The answers were remarkably consistent.
Start with Ubuntu. Harden the base image. Find some way to get your application onto it.
From there the paths diverge slightly, but not much. Some teams pull down containers and load them. Some run elaborate Ansible scripts. The more sophisticated teams slim down the base image, mirror their own package repositories, and pull only from their own hosted feeds so they can control what lands on a device.
That last one is worth sitting with. Teams are spending real engineering years, and by the look of it millions of dollars, to make a general-purpose desktop distribution behave like a product runtime.
And everyone is using Docker. Frankly, almost nobody I spoke with likes using Docker. It's the industry default rather than anyone's preference.
Here's what that architecture produces in practice, in the words of the people running it:
Ansible scripts stall mid-installation. Now you're recovering from a partially-configured device, which means starting again from a known state that was never all that known to begin with.
OTA updates take minutes to hours. Without clean image-based isolation, they're unreliable in a way that generates both customer frustration and engineering frustration.
Rollback isn't guaranteed. One founder told me he wants a big green button on the wall that always rolls the fleet back to a working state. He came from a hardware and electrical engineering background and knows what good embedded practice looks like. I told him, only half joking, that he's never going to get that on a mutable runtime. It doesn't exist there.
Nobody can reproduce anybody else's work. Engineers hack on their own device, install their own packages, and within weeks no one can say what version of what is running where. Every machine becomes a development snowflake.
What struck me most: there was almost no mention of tools built to solve this. Teams just keep doubling down on a mutable foundation and accruing technical debt against it.
The only organizations genuinely building this layer in-house are the largest in the world. Tesla and Optimus. Probably Figure and 1X. Everyone else deploying live robots today is on Ubuntu, and struggling with the same short list of problems.
If you look up our company, you'll find a lot of material about the 100-device wall. I spent two days being gently corrected on that.
Almost nobody at that show is anywhere near a hundred devices. But they are struggling badly, and much earlier than our messaging assumes. Reproducibility starts breaking down at roughly three robots and three engineers.
That's the point where two people can no longer reliably reproduce each other's builds. Where you can't say with confidence which packages are on which machine. Where rolling back a package is a research project rather than a command.
The seed-stage founder who wants the green button isn't running a fleet. He has three software engineers building robots, and his instinct that this will not scale is correct. It's going to take his team weeks to build a mediocre version of something that should be a property of the runtime.
Software reproducibility is not a production-scale problem that arrives later. It's a team-of-three problem that compounds quietly until someone asks how the fleet gets managed, and the honest answer is that nobody knows.
Here's the part that surprised me. Of every problem we discussed at that booth, an immutable, image-based runtime addresses roughly 90% of them.
Not incrementally. Structurally.
When the image is immutable and signed, reproducibility isn't a discipline your team has to maintain. It's a property of the system. Every device runs the identical, verified image. Rollback is atomic, because there's a known-good image to return to. Updates are A/B, so a failure is recoverable rather than catastrophic. Version drift can't accumulate, because there's nothing mutable for it to accumulate in.
The green button is achievable. Just not on a mutable base.
What made this a genuinely interesting two days is that most people I explained it to had never encountered the idea. They were describing the symptoms precisely and had no name for the cure. There's real education to do here before the industry can even ask for the right thing.
The apprehension I heard was never "that wouldn't work." It was sunk cost, existing technical debt, and a reasonable question about what migration actually looks like. Those are fair concerns, and worth a longer answer than this post can give.
But the technical objection didn't come up once.
Our CTO, Justin, took a different approach in his Actuate session, So You Decided To Ship A Robot. It starts with a familiar problem: your PM tells you the robot is occasionally missing something, and asks you to figure it out before Thursday.
You investigate. It's a timing bug. A camera driver is timestamping frames incorrectly, so you patch the driver yourself. Reasonable.
Then the patched driver needs newer middleware. The middleware needs a newer userspace. Your board image is pinned to an older kernel.
By Q3, those reasonable decisions have led somewhere unexpected: you're building a custom Linux image, maintaining build infrastructure, signing kernel modules, managing multiple system versions, and figuring out rollback.
You're no longer just building a robot. You're maintaining an operating system.
This is the engineering version of yak shaving. Every individual decision makes sense. The cumulative path takes you further from the thing you set out to build.
And the root cause is the same one from every booth conversation. When your foundation is mutable, you have to build the guarantees yourself. Reproducibility, rollback, and version control all become your engineering problem, one patch at a time, until you've accidentally become a distro maintainer.
At our booth, we showed GOAT Racer One, an autonomous race car running on an NVIDIA Jetson Orin Nano, with RealSense depth, LiDAR, and Isaac ROS. The demo showed a complete sim-to-real workflow: Simulate → Export → Deploy → Update
The policy is trained in NVIDIA Isaac Sim and Isaac Lab, exported as portable ONNX, and deployed to the physical car without rebuilding the system. The same runtime runs in simulation and on the vehicle.
Then comes the part that's easy to leave out of a robotics demo: update it.
Field data feeds back into the development loop, and new policies can be delivered as extensions without rebooting the system. Atomic A/B updates provide automatic rollback if something goes wrong.
The most convincing thing about the demo wasn't on the slides. Over two days on conference Wi-Fi, with the network access you'd expect at a packed venue, we shipped roughly 70 over-the-air updates to the car from our platform.
That's the whole argument, honestly. Not that OTA is a feature we have, but that it's routine enough to do seventy times from a folding table in Fort Mason without anyone holding their breath.
For robotics teams, OTA isn't a nice-to-have. Once a machine is deployed, physically touching every device to install a new version stops being a development workflow and becomes an operational problem.
📄 Read the GOAT Racer One sim-to-real reference design →
We're also opening up part of the workflow as an Avocado OS reference, so Jetson teams can run the same loop themselves. It isn't live yet. Send us a note and we'll send it the day it lands.
Foxglove announced 3.0 shipped on the first day of the conference, and it points to where robotics tooling is heading. The release added an agent that builds layouts and answers questions about your data, semantic search across image and video, and comparison mode for putting multiple recordings on a single timeline.
The specific features matter, but the direction matters more. Robotics developers are moving from looking at data toward interrogating the systems that produced it.
That's a sign of a maturing ecosystem. The tooling isn't just helping teams build a prototype. It's helping them understand, debug, and operate real systems.
I did not have a single conversation at Actuate with a team doing anything interesting on non-NVIDIA silicon. Not one. They're training on NVIDIA and deploying on NVIDIA. Sometimes that's Jetson, sometimes it's RTX, but it was never anyone else.
That dominance is earned. Cosmos 3, an omnimodal world foundation model spanning physical reasoning, world generation, and action generation, connects synthetic data, model development, evaluation, and real-time deployment on Jetson Thor across one stack. Sim-to-real only becomes useful when the pieces connect, and NVIDIA is the only company that has connected them.
Our GOAT Racer One demo runs on that ecosystem end to end, from Isaac Sim and Isaac Lab through to Jetson hardware. We're not trying to build an isolated robotics stack. We want to make the path from AI development to production hardware easier for teams already building on NVIDIA.
One example of where that path is shifting: JetPack 7.2 made Yocto an officially supported option, which sharpened a choice Jetson teams have lived with for years. Fast bring-up and easy evaluation, or reproducible source-driven builds with a minimal attack surface. Teams used to pick one.
And the more capable that compute becomes, the more the surrounding software infrastructure matters. More compute doesn't eliminate the deployment problem, it raises the stakes on solving it.
After two days of conversations with robotics engineers, builders, and companies working across the physical AI stack, five things feel particularly clear:
Every team I spoke with begins with a general-purpose distribution and spends significant engineering effort hardening it into something shippable. It's the universal starting point, and it's the source of most of the pain that follows.
The hundred-device wall gets the attention. The real wall shows up as soon as a few engineers are contributing to the same machine and nobody can reliably reproduce anyone else's work.
An immutable, image-based runtime solves most of what teams described to us at the booth. Most had never considered it. OTA is the visible tip of that iceberg, not the point of it.
Teams with slow, unreliable updates don't have an update problem. They have a reproducibility problem that becomes visible at update time.
This isn't about teams becoming more cross-disciplinary. It's that robotics teams are categorically not investing in the infrastructure that embedded engineering figured out years ago. Applying what already exists would meaningfully accelerate how fast these teams can build.
The robots are impressive. The models are impressive. The compute is impressive. But the interesting engineering problems increasingly live in the space between "it works" and "we can ship it."
The questions we heard over and over at Actuate weren't abstract:
Every one of those has the same root cause. And every one of them has the same answer.
Peridio builds the software infrastructure that helps robotics teams move from development to production without taking on an entire embedded infrastructure stack themselves. Avocado OS provides the immutable runtime. Peridio Core provides the fleet infrastructure.
Your engineers should be doing robotics. Nobody should maintain a distro by accident.
We're continuing the GOAT Racer One work in an upcoming technical live session with NVIDIA, hosted by our friends at ipXchange, walking through the full workflow live: Isaac Sim training, ONNX export, provisioning a Jetson straight out of the box, and delivering an OTA update with rollback.
Whether you're building your first physical AI application or preparing to scale beyond a single prototype, you'll leave with a practical understanding of what it takes to move physical AI from simulation to the edge, and from a single working prototype to a repeatable, maintainable deployment.
🎥 Register for the live session on Sept. 15th @ 12pm EST here →