Robot-in-the-Loop vs Human-in-the-Loop Capture

There are, at heart, only two ways to capture manipulation data. One puts a robot in the loop: a person drives a robot arm, the robot does the task, the robot's sensors record the trajectory. The other puts the human in the loop directly: the person wears sensors, does the task themselves with their own hands, and the sensors record what happened.

Every serious data pipeline in physical AI is one, the other, or a coordinated combination of both. Understanding the tradeoff cleanly is the fastest way to decide which one belongs where in your program.

Trajectories are natively in the target robot's action space. There is no retargeting between capture and deployment. The dynamics the policy learns are the dynamics it will face. For a team shipping a specific bimanual platform, this is the shortest possible path from a demonstration to a policy that runs on the hardware you own.

Failure modes are honest. If the arm slips, the data shows the slip. If the gripper fumbles, the data shows the fumble. The demonstrator experiences the same latency, dexterity limits, and force ceiling the deployed robot will experience, and the resulting policy inherits realistic priors about what is easy and what is not.

The floor cost is high, arms, cells, floor space, on-site operators. The throughput scales linearly with capex. The embodiment is fixed at the moment the cell is built; changing it is a capital project. And critically, the skill ceiling of the demonstrations is bounded by the dexterity of the specific robot in the cell. If the robot cannot do fine sushi work, no operator, however skilled, can produce a fine-sushi demonstration in that cell.

Capture happens wherever the operator already works, a kitchen, a workshop, a factory floor, a lab bench. No cells, no floor plan, no shipping robots to skilled workers. The skill ceiling is the operator's own skill, not the robot's. Force and tactile signals are recorded directly at the fingertip, not inferred from motor currents on a follower arm. And the same session, captured as raw human motion plus force, can be retargeted to many different robot embodiments after the fact.

There is a retargeting layer between the captured trajectory and the robot policy. That layer is real work, and if the target embodiment is very different from a human hand it can introduce error. Some deployment platforms do not have a clean human analogue at all, for those, robot-in-the-loop capture will always be the right tool.

The teams that are furthest along are running both. Wearable capture for volume, embodiment diversity, skill ceiling, and any task that lives outside a cell. Robot-in-the-loop capture for platform-specific tuning, hard-to-retarget morphologies, and the last-mile fit to the exact robot being shipped. Choosing one exclusively is a strategic error at the scale the frontier labs are now operating at.