The iteration loop is the whole game

A thing I did not expect when building Ronin: the most valuable property is not dexterity or precision or any of the specs. It is that the gap between "I wonder if this would work" and "I know whether it works" is now measured in hours. That gap is the whole game in imitation learning and I do not think enough people are talking about it.

Most of imitation learning follows the same loop. Collect demonstrations. Train a policy. Deploy it. Watch it fail in some unexpected way. Adjust your approach. Repeat. Everyone knows this loop. The bottleneck that actually determines your rate of progress is how many times you can run it in a given week.

On a single arm, the loop is solved

Desktop manipulation with one arm sitting on a desk is a solved iteration problem. You can collect 50 demonstrations in an afternoon, fine-tune overnight, and deploy in the morning. The LeRobot ecosystem, OpenPI, and similar tools have made this workflow accessible to anyone with a capable GPU and a few hundred dollars in hardware.

The hard part is no longer software. It is form factor.

On a bimanual humanoid, it is still a lab project

Jump from a single arm to a bimanual humanoid and everything changes. The data collection rig is expensive. The robot itself costs enough that running an unconfident policy feels like a risk, not a learning opportunity. The setup and teardown time for each experiment eats into the hours you could spend iterating.

Today, maybe four or five organizations in the world can afford to iterate on bimanual humanoid policies at any meaningful pace. That is not a software problem or a model problem. It is a hardware access problem.

Which is why almost nothing interesting happens on bimanual humanoids outside those four or five companies. Not because the ideas are missing, but because the people with the ideas cannot afford to test them.

What a real iteration day looks like on Ronin

Morning: collect 30 bimanual demonstrations using the matched teaching controller. The controller has the same kinematics as Ronin, so the data is clean and the demonstrations feel natural. No motion retargeting. No sim-to-real gap in the demonstration data itself.

Afternoon: fine-tune a policy on the new data. If you are starting from a pretrained checkpoint, this takes a few hours on a single GPU. Overnight if you are training from scratch.

Next morning: deploy the policy. Watch it fail at the hard part. Note exactly where and how it fails. Is it a perception issue? A timing issue? A generalization gap?

Same day: collect 20 more targeted demonstrations that cover the failure mode. Run training again.

The point is not that each individual run succeeds. The point is that you are running the loop twice per day instead of twice per month.

Speed compounds

In a month, a single researcher on Ronin can run 40 or more iteration cycles on a bimanual humanoid task. A large lab with a $100K+ platform might run five in the same period. Not because they are slower or less capable. Because every run carries more risk, requires more coordination, and the hardware is shared across multiple projects.

The researcher who runs more loops learns faster. Not because they are better, but because the loop is the teacher. Each failure tells you something specific. Each adjustment narrows the space of things that could go wrong. The person who can do that 40 times learns things that the person who does it 5 times simply cannot.

This is how it works in every field where iteration speed matters. The team that ships more builds learns more. The chef who cooks more dinners improves faster. The programmer who runs more tests finds more bugs. Imitation learning on humanoids is no different, except that until now the hardware has made the loop unreasonably slow for almost everyone.

The model side is ready

The model side of imitation learning is moving fast. New architectures and fine-tuning approaches land weekly. pi0, pi0.5, pi0.6, OpenPI. Open-weight VLAs you can download and run today. The tooling for collecting, training, and deploying imitation learning policies has never been better.

But the people making real progress are not the ones with the best model. They are the ones who can test, fail, and adjust before lunch. That has always been a hardware problem. Ronin is an attempt to solve it.