Open-Loop vs Closed-Loop Control: Feedback Wins
Feedback is the line between open loop and closed loop control. Here is how it reshapes what you capture, how a policy trains, and where each one fails.
Think of an open-loop robot as a thrown dart. It aims once, commits to a fixed sequence of motions, and hopes the world stays exactly where it expected. Bolt down every object, remove every disturbance, and this works beautifully. Let a part shift two millimeters and the whole motion sails past its target.
A closed-loop robot watches while it moves. It compares what it senses against what it intended, and corrects continuously. That single difference, whether the policy reacts to feedback or not, changes almost everything upstream: the control rate you need, the sensors you must read, and, most of all, the data you have to capture to train it.
The gap matters because most robot learning quietly assumes closed-loop behavior while collecting data that only supports open-loop execution. That mismatch is where a lot of promising policies die on contact with reality.
What the two words actually mean
In open-loop control, the policy produces a plan and executes it blind. Feedback, if there is any, is used before motion starts, not during. It is fast and simple, and it is brittle in exactly the way you would expect. Any error between the model and the world compounds, because nothing is watching to catch it.
Open-loop is not a mistake or a relic. In a structured, repeatable setting it can be the right call. A pick-and-place cell where every part arrives in a fixture, jigged to a known pose, runs open-loop happily and fast, because there is no uncertainty for feedback to resolve. The trouble starts the moment the world stops cooperating, which, outside a fixture, is most of the time.
Closed-loop control puts perception inside the action loop. The policy observes, acts, observes again, and adjusts, many times per second. Modern visuomotor policies are closed-loop almost by definition: a network like the ones behind NVIDIA Isaac GR00T maps the latest camera frame and joint state to the next action, then repeats. Feedback is not a feature bolted on. It is the architecture.
Why feedback changes what you must capture
Here is the part that catches teams off guard. Training a closed-loop policy needs more than a clean recording of the ideal trajectory. It needs to see how an expert reacts when things go slightly wrong, because that reaction is the behavior you are actually trying to learn.
Think about what a demonstrator does when a grasp slips. They feel it, adjust grip, reposition, and recover, all without conscious thought. An open-loop dataset throws that away, keeping only the smooth successful path. A closed-loop dataset has to capture the corrections: the small reactive adjustments that exist only because the human was sensing feedback in real time. This is one reason teleoperated datasets like DROID, recorded with a human in the control loop, carry signal that scripted or replayed trajectories simply do not.
Why perfect demonstrations are not enough
There is a well-known trap here. Train only on an expert's flawless runs and the policy never sees the states its own small mistakes will lead it into. The first error takes it somewhere the training data never went, and from there it has no idea what to do. The classic fix is to collect data on the states the policy actually visits, including the awkward ones an expert would never reach on their own. That is expensive, and it is precisely the data an open-loop capture setup fails to record.
It also raises the bar on synchronization and rate. If the corrective reaction happens in 50 milliseconds, but your capture logs vision and force on different clocks, the very signal that teaches recovery is smeared out. Work from the Berkeley BAIR blog on reactive manipulation keeps returning to this point: the value is in the fast feedback, and fast feedback is unforgiving about timing.
Counting the difference
The two control regimes make genuinely different demands, on the robot and on the dataset behind it.
| Dimension | Open-loop | Closed-loop |
|---|---|---|
| Sensing during motion | None used | Continuous |
| Typical control rate | Plan once, execute | 10 to 200-plus Hz |
| Robustness to disturbance | Low | High |
| Data requirement | Ideal trajectories | Reactions, corrections, recovery |
| Dominant failure mode | Compounding drift | Latency, bad timing |
Read down the last two rows and the lesson is plain. A dataset of only perfect runs is an open-loop dataset, whatever architecture you later train on it.
Action chunking, the pragmatic middle
Pure per-step closed-loop control has a cost: predicting one action at a time can make motion jittery and expensive to run. So a popular compromise has emerged. Predict a short chunk of future actions, execute part of it, then re-plan with fresh observations. It is closed-loop at the chunk boundary, open-loop within the chunk.
This is the pattern behind several recent policies, including work described on the Physical Intelligence blog. It buys smoother motion and lower compute without giving up feedback entirely. For capture, it means the chunk length is a parameter you have to respect: your data has to support re-planning at whatever rate the policy will actually run.
Latency is the failure mode people underestimate. A closed-loop policy that reacts too slowly is, in effect, open-loop again: by the time it responds, the moment it needed to correct has already passed. This is why control rate and end-to-end latency deserve to be treated as first-class properties of a dataset, not afterthoughts. A demonstration recorded at a rate the target robot cannot match teaches reactions the robot can never execute.
A dataset of only perfect trajectories teaches a robot how to succeed, never how to recover. Deployment needs both.
Capture for the loop you will run
Open-loop and closed-loop are not rival philosophies to pick between. Almost every capable robot is closed-loop where it counts, and the interesting decisions are about rate, sensing, and what the data has to contain. The trap is subtle. You can build a closed-loop architecture, train it on open-loop data, and never understand why it fails the moment the world pushes back. Capture the corrections, respect the timing, and match the data to the loop the robot will actually close. That is the difference between a policy that demos well and one that survives a real shift.