Learning, deployment and commissioning
Two paths through the robot-training loop and the harder work around model capability: capture, validation and commissioning.
Choose a reading path
Each path has its own starting point and sequence.
The robot-training loop · 4 pieces
The five-stage mental model, the pipeline I ran on one GPU, and what capture and learning method change inside the same loop.
Start with A Robot Training Center Looks Like Ten Projects. It's One Loop.From model capability to deployment · 4 pieces
Why a strong model is only the beginning: capture evidence, operating envelopes, runtime monitoring and the commissioning boundary.
Start with Physical AI's bottleneck isn't the model anymoreMore in Physical AI
1 piece not currently in a reading path.
Most Robot Policies Don't Need Tactile Input. The Test Is Whether Vision Can See What Decides the Task.
Years of MES work taught me where automation stops: at tasks whose decisive state cannot be written down or seen. Tactile input earns its place when it reveals that missing state; contact alone is not enough.
What Industrial Maintenance Demands From Robot Capture
A refinery valve operation shows why robot capture should begin with the task: preserve the motion, contact, timing and measurements the policy will need.
A VLA Benchmark Is Not a Commissioning Package
Robot foundation models are getting better at handling situations they were not shown. That makes the old commissioning questions more important: where is the model valid, how do I know it has left that range, and what happens next?
NVIDIA's Hardware Line Looks Like a Catalog. It's One Architecture in Many Boxes.
People keep asking me a version of the same question: what NVIDIA hardware should I be thinking about for a digital twin, from a developer build at my desk all the way to production? I always had an answer but no clean model behind it, just a pile of product names, three of which are confusingly all called DGX. So I built the model I wanted: NVIDIA develops one architecture family a year and expresses it across many kinds of computer, from a gaming card to a liquid-cooled rack. These are my rough notes, in case you're coming at it from the software side and asking the same thing.
Testing the Robot Training Loop I Drew
A month ago I drew a five-stage loop for a robot training center and admitted most of it was an educated guess I hadn't tested. So I built the loop as a real, orchestrated pipeline on one GPU and carried two tasks around it — a pole that balances by trial and error, and a Franka arm that learns to stack cubes by copying demonstrations. This is the environment, the stack, the architecture, and what actually ran. Part 1 of two.
What Testing the Robot Training Loop Taught Me
Running the training loop for real surfaced one concept the diagram doesn't capture: the same five stages take two different shapes depending on how the robot learns — by trial and error (reinforcement learning) or by copying demonstrations (imitation). This part is the mechanism behind that fork, grounded in the two tasks I ran, plus the open questions the build left unproven. Part 2 of two.
Physical AI's bottleneck isn't the model anymore
We finally have models that can watch the physical world, reason about it, and predict what happens next. Walk a real automotive parts-kitting task through what they actually solve, and the thing still standing between a demo and a working line isn't a smarter model: it's the policy you have to train for your machine, and the system that keeps it trained.
A Robot Training Center Looks Like Ten Projects. It's One Loop.
Someone asked me how you'd build a training center for industrial robots from scratch, and my first reaction was that it isn't one project, it's ten. What untangled it was seeing that they aren't ten separate things at all. They're five stages of one loop that turns real work into robot skills and feeds what happens back in. This is where I've gotten so far, still learning, sharing it in case you're walking the same road.