Understand how capture, training and validation fit together, and what a learned robot policy still needs before deployment.
Each path has its own starting point and sequence.
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. View full reading pathWhy a strong model is only the beginning: capture evidence, operating envelopes, runtime monitoring and the commissioning boundary.
Start with What a Robot Model Still Leaves to the Plant View full reading path3 pieces not currently in a reading path.
I would design MES around shared operational state, physical context and decision services. The test is whether another manufacturing function can reuse an assessment and remain consistent when the operation changes.
Two ramp scenes pass the selected NVIDIA USD physics-configuration rules, but only one keeps its block within a 10 mm limit. A press-cell demo passed 24 general rules while its PhysX run missed a 10 mm tracking requirement. The walkthrough shows the inputs, traces, solver sensitivity and the friction that stayed assumed.
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.
A refinery valve operation shows why robot capture should begin with the task: preserve the motion, contact, timing and measurements the policy will need.
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?
I choose hardware by the work it runs, the memory it needs and what has to move between devices. A SplatStage run shows why the GPU model alone was a poor guide to sizing the machine.
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.
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.
A pretrained robot policy can supply useful action skills. An automotive parts-kitting cell still needs a way to adapt those skills, verify each kit and respond when parts or conditions change. That is the pipeline I would build now.
A request to scope a robot training center became a five-stage working model. I use one task to explain the handoffs, the tool choices and what still needs testing before pipeline reuse becomes a business or deployment claim.