A few weeks ago someone asked me a simple-sounding question: if you wanted to stand up a training center for industrial robots from scratch, how would you do it? Not buy a robot for one job, the way the industry used to sell them, but build the place where a capable, general-purpose robot gets trained into the specific thing you need, again and again. My first reaction wasn’t a plan. It was a small wave of panic. Start listing what such a place touches, capturing how people do the work, building simulations, generating data, adapting large models, proving the results are safe, running them on real robots, and it stops looking like a project. It looks like ten projects, each with its own stack, its own experts, and its own way of failing. I couldn’t fit them into a sentence that held together, let alone a sequence.
It’s worth asking why that question comes up now, because a few years ago it wouldn’t have. Industrial robotics grew up on a waterfall model. A robot was designed and built for one purpose, arrived pre-programmed for it, and did exactly that until it was retired. Picture a KUKA arm bolted to an automotive paint line, taught once to spray the same panel or weld the same seam, then repeating that motion for years, precise, reliable, and fixed to its one job. The intelligence was baked in at the factory. What’s shifting, and shifting fast, is that the hardware is going generic. Perception and motion are increasingly built to be general-purpose, and the specialization, the part that makes a robot useful for your task, moves downstream to whoever trains it. You can watch the business model split along that seam. Fauna Robotics ships Sprout, a capable and deliberately approachable humanoid, as a developer platform, and lets others, from universities to companies, build the applications on top. That was compelling enough that Amazon acquired the company. The buyer is part of the signal. Amazon runs one of the largest special-purpose robot fleets in the world, machines each built for a narrow warehouse job, and it still paid to own a general-purpose humanoid platform. When the company that arguably perfected the dedicated-robot model buys into the general-purpose one, I read that as a loud vote for where this is heading. Physical Intelligence is building, in its own words, foundation models to “control any robot to perform any task,” selling the brain rather than the body. Different layers, same bet: build the general capability broadly, and let the user train it for the outcome. Jensen Huang points the same way, that the “ChatGPT moment for general robotics” is around the corner, and that most developers won’t have the resources to train these models from scratch.
That last point is why the question exists at all. If the hardware is generic and the training is where the value and the difficulty now sit, then the training itself is the opportunity rather than a cost you pay once and forget. The pipeline that carries one task from a human demonstration to a working skill is largely the same pipeline for the next task, so the infrastructure pays for itself across a whole catalog of jobs. The parallel I keep coming back to is fine-tuning an LLM: one capable base model and one reusable post-training pipeline turn into a hundred specialized assistants, and the value sits in the platform rather than any single fine-tune. Robot training looks the same. It’s a real business, but an ecosystem-level one rather than a standalone product, because it only pays off by serving many customers who each want a highly capable, general-purpose robot to do their own specialized job well. Someone has to build the place where that training happens repeatably. That place is the training center, and that’s where the original ask, and my panic, came from.
So I did the sensible thing and took it as an action item. Go read, talk to people who have built pieces of this, and come back with a way to think about it that isn’t a shopping list. This piece is where I’ve gotten so far. It’s a work in progress, not a finished map, and I’m sharing it at this stage on purpose. Writing it down is how I find the holes, and if you’re on the same road, I’d rather compare notes than have each of us redraw the map alone.
What finally untangled it for me was small and a little embarrassing. I’d been treating it as a catalog of technologies when it’s one loop. A training center isn’t a pile of tools you assemble. It’s a single cycle that turns real work into robot skills and then feeds what happens back in. Real work goes in one end, trained and tested skills come out the other, and every deployment becomes fuel for the next round of learning. Once I saw the loop, the ten projects collapsed into five stages of one thing, and the technology stopped being a list to memorize and became a set of choices at known points on a cycle. That reframe is the point of the piece. What follows is just walking the loop once, slowly, from where I sit, which is inside NVIDIA and therefore closer to some of these tools than others. So one fair warning before we start. My go-to at each stage leans NVIDIA, and not because I ran a bake-off and it won. It’s because that’s the stack I have hands-on, and it’s what I know best so far. Read the open alternatives I list beside each pick as equally valid places to start, and discount my defaults for the bias they carry. A fair version of this map needs both, and I’d rather name my slant than pretend I don’t have one.
Capture is where real work becomes data a robot can learn from. It sounds like the dull part and is quietly one of the hardest. You take a person’s demonstration of a task, picking a part, seating it, handling a tote, and turn it into structured signal: poses, motion, moments of contact, and, crucially, what to do when it goes wrong. The open world has moved fast here, and it’s worth knowing even if you never touch it. Stanford’s Mobile ALOHA showed you can teleoperate a low-cost bimanual rig and, with as few as 50 demonstrations per task plus co-training, push success on hard mobile-manipulation jobs up to around 90%. Hugging Face’s LeRobot has become a common language for this kind of data, and projects like the Universal Manipulation Interface let you collect usable demonstrations with a handheld gripper and a GoPro, no robot required. This has now spilled out of the lab into a real gig economy in just the last few months. Companies pay ordinary people to strap on a head-mounted camera and record themselves doing everyday chores, folding laundry, chopping vegetables, washing dishes, so the footage can feed training pipelines. DoorDash launched an app in March 2026 that pays its Dashers up to $25 an hour to film their own housework. A startup called Micro1 has recruited thousands of contributors across more than 50 countries doing the same, and data firms like Scale AI and Encord are assembling their own recording crews, with people earning roughly $80 for a couple of hours of usable video. It amazed me that “record your own chores for pocket money” has become a global business almost overnight. One distinction is worth keeping straight, though. A teleoperated demonstration like ALOHA comes with the robot’s actions attached, while a video of someone folding laundry does not. Human video is cheaper and far more plentiful, but you have to lift it into actions, retargeting the motion onto the robot, before a policy can learn from it. The two aren’t interchangeable, and a good chunk of current research is about closing that gap. From my seat I’d reach for NVIDIA’s teleoperation and Isaac tooling to feed the rest of the stack. But the lesson from the open work is the one that sticks: the bottleneck isn’t the capture gadget, it’s getting enough varied, honest demonstrations of the messy real task, failures included.
Simulate and synthesize is where a little real data becomes a lot. It’s two moves inside one stage. First you build the digital twin: take your industrial 3D and CAD and make it physically real, with collisions, contact, grasp points, and safety zones, so a robot can act in it. That’s what NVIDIA’s Omniverse, built on OpenUSD, is for from where I sit, with Isaac Sim and Isaac Lab running the physics on top. The open world reaches instead for simulators like DeepMind’s MuJoCo, the long-standing standard for contact-rich physics, the newer Genesis project chasing far faster generation, or UC San Diego’s ManiSkill/SAPIEN, built specifically for manipulation. Then comes the synthesize half, and this is where the synthetic data generator lives. You stretch a small pile of captured demonstrations into a large, varied one by manufacturing the cases you’d never capture enough of by hand, the rare ones and the failures especially, either through domain randomization inside the simulator or generative world models like NVIDIA’s Cosmos. This is the stage where I think the payoff is highest and the least appreciated. I’m not neutral here. I find the Omniverse and Cosmos side of this compelling, and you should read that knowing where I sit. The point underneath holds up on its own, though. Synthetic data doesn’t only add more examples, it can produce new behavior. NVIDIA’s own GR00T N1.5 report puts a number on it, a synthetic-generation pipeline lifting success on a set of novel tasks from 13% to 38%. That figure is first-party, so weight it accordingly. But the general pattern is old news: domain randomization has been showing since 2017 that the variety you can only manufacture in simulation is often what makes a policy survive contact with the real world. The generator in the middle of this stage is what does that job.
Train is where a capable starting model becomes your skills. What reframed this for me is that almost nobody serious starts from scratch anymore. You take a pretrained model, more and more often a “vision-language-action” model that already carries a lot of general world knowledge, post-train it toward your tasks, and compose the basic skills into fuller workflows. The open evidence here is worth citing precisely because it cuts against the “you must train your own giant model” instinct. Stanford’s OpenVLA, a 7-billion-parameter open model, beat a 55-billion-parameter closed one by about 16 points of task success with roughly seven times fewer parameters. Physical Intelligence’s π0 and Google’s RT-2 line pushed the generalist-policy idea further still. From inside NVIDIA I reach for the GR00T foundation models and Isaac Lab as the post-training ground, and I do think the head start is real. But the signal I’d want a reader to leave with is that the winning move is adaptation over invention. (I’ve written separately about why teams reach for fine-tuning too early. The same reflex shows up here, and I suspect the same discipline applies.)
Validate is where you find out whether a skill is good, and safe, before a real robot moves. You run the trained skill back in simulation, replay its failures to see where it breaks, benchmark it consistently so you can compare across robots and models, and hold it against a real safety and compliance bar. This is the stage I’m least settled on, and I’d rather say so than fake confidence. A good score in simulation does not guarantee good behavior on hardware. The sim-to-real gap is real, and only partly closed by tricks like domain randomization. The most useful thing I found is Berkeley’s SIMPLER, which showed you can make simulated evaluation line up closely with real-world performance, but only after explicitly attacking the visual and control disparities. Benchmarks like LIBERO and CALVIN give you shared yardsticks. What none of them give you yet is a trustworthy way to prove a skill is production-safe, which is why this stage deserves more attention than it gets.
Deploy and improve is where skills go onto real robots and the loop closes. You put the skill on on-robot compute, run it in the real environment on standard middleware like ROS 2, with Isaac ROS as the accelerated flavor I use, and then feed what happens back into the data pipeline so the next round is better. This is also where the model you were proud of meets a wall. A billion-parameter policy has to close its loop in milliseconds on whatever compute rides on the robot, and “runs great in the notebook” and “runs at control rate on the arm” are very different sentences. Latency, action chunking, and a safe fallback for when the policy hesitates are the real work here, and they get harder as the model gets bigger. That last arrow, from production back to Capture, is the one people draw as a dotted line and never build. It’s also the part that makes this a training center rather than a one-time integration. Underneath all five stages sits a question I left off the map to keep it readable, but that’s always in the room: where each workload runs, across the robot, the edge, the cloud, and your own data center. I kept it out of the picture on purpose. It belongs in the conversation from day one.
Here’s the loop on one page: what each stage really is, the part that’s hard, and, in the last column, my own first reach next to the open alternatives I’d weigh against it. Read that column as opinionated defaults rather than a catalog. The point isn’t the tool names, it’s that every stage is a real decision, and the “hard part” column is what I’m trying to get past when I pick one. And yes, the left side of that column leans NVIDIA the whole way down, for the reason I already owned up to. Weight it accordingly.
| Stage | What it really is | The hard part | My first reach (and alternatives) |
|---|---|---|---|
| Capture | Turn human demonstrations into robot-ready data | Enough varied, honest demos, including failures | Isaac teleop / ALOHA, LeRobot, UMI |
| Simulate & synthesize | Build the twin, then generate synthetic variety on top | Manufacturing the rare cases, not just more of the same | Omniverse + Isaac Sim, Cosmos (synthetic data) / MuJoCo, Genesis, ManiSkill |
| Train | Post-train a foundation model into skills | Adapting, not reinventing; the right data mix | GR00T, Isaac Lab / OpenVLA, π0, RT-2 |
| Validate | Prove skills in sim and against a safety bar | Sim-to-real gap; no trusted safety proof yet | Isaac Lab-Arena / SIMPLER, LIBERO, CALVIN |
| Deploy & improve | Run on real robots, feed results back | Actually building the return arrow | Isaac ROS, Jetson / ROS 2 |
One thing the table makes visible, which took me a while to value: each stage is a slot rather than a fixed choice. There’s more than one credible technology at every step, and a center is better off treating each stage as something it can swap or mix, choosing the base model or the simulator that fits the task in front of it, than committing the whole place to a single stack end to end. That flexibility is more than procurement hygiene. It feeds generalization directly. The more variety you allow at each stage, in the demonstrations, the simulators, the synthetic data, the less a trained skill overfits to one pipeline’s quirks, and the better it holds up when the real line doesn’t match the lab. The loop gives you the structure. Keeping each node flexible is what stops that structure from hardening into another purpose-built machine, which is the thing the whole shift was meant to get us away from.
None of this makes the loop easy to stand up. Building all five stages and wiring them into one working cycle is a serious undertaking, and I don’t think a center should try to own every stage equally. Earlier I said the pipeline pays for itself across jobs. Let me be more precise, because that reuse isn’t spread evenly. The part that generalizes is the middle, stages 2 through 4: simulate-and-synthesize, train, and validate. That’s the task-agnostic machinery, the twin, the synthetic-data generator, the post-training and evaluation pipeline, that looks broadly the same whatever job you’re teaching. Capture and Deploy are where the per-customer, per-site specifics live: this factory’s demonstrations, that plant’s robots, this site’s safety rules. So if I were building a business around a training center, I’d invest first and deepest in that middle three and treat it as the core worth owning, while leaning on the open ecosystem and specialist vendors for the capture rigs and the deployment edges. The obvious objection is that I’ve got it backwards. If data is the scarce thing, then Capture is the real moat, the proprietary demonstrations plus the return arrow that keeps refilling them, and the middle is exactly what open models and simulators are commoditizing fastest. That’s the strongest case against my bet, and I’m not sure I’m on the right side of it. Where I land for now is a distinction: the capture rig I’d rent, the captured data I’d guard. Those are different things, and blurring them is probably the softest spot in my own argument. So call it a bet, not a proof, and the kind of thing I’d want to argue out with someone who has actually run it.
Step back from the stages and the thing that surprised me is simple. The hard part of a robot training center is not the robots, and not even the models. It’s data and proof. Robot learning is data-starved in a way large language models never were, because there’s no internet of physical demonstrations to scrape. The whole scramble around shared datasets like Open X-Embodiment, a million-plus trajectories pooled from 22 robot types across 34 labs that then transferred better than robot-specific data, exists because everyone is fighting the same scarcity. And proving a learned skill is safe enough to run on a real line is not a solved problem yet. So if I had to compress what I’ve learned into one stance: don’t start by shopping for technology. Start by drawing the loop and picking one real task to carry all the way around it. The tech choices get obvious, and defensible, only once you know which stage you’re standing in and what its hard part is. The urge to open a catalog and start picking tools is the same urge that made this look like ten projects in the first place.
That’s as far as I’ve gotten. I still have open questions I can’t answer cleanly, most of them clustered in Validate, where I think the real unsolved work is. I’m going to keep pulling on this, and probably take a single toy task all the way around the loop myself, to replace some of this hand-waving with something I’ve actually run. (Update: I did — I built the loop and carried two tasks around it. Part 1 is what actually ran; Part 2 is what it changed my mind about, and what I still can’t prove.) If you’re building in this space, or you’ve been burned by one of these stages and know something I don’t, I’d like to compare notes. Reach out, and let’s learn in the open and leave the map a little better than we found it.
Disclaimer: The views and opinions expressed in this account are those of my own and do not represent those of my employer, NVIDIA. This is a work in progress and I’ve almost certainly gotten something wrong or missed a detail, so I’m always happy to be corrected.