Why a perfect simulator can train a brittle hand
Imagine practicing a trick with a light wooden block and then being given a heavier, slippery one. A robotic controller can face the same mismatch between its simulated training world and a real object. Dactyl deliberately varies simulated properties such as friction, mass, delays and visual appearance. The goal is to learn a policy that can cope with a range of conditions rather than exploit one exact simulator setting.
Follow the information entering the robot
A recurrent policy can use recent observations as well as the latest input. A separate vision network estimates the object’s pose from three cameras. The physical system also tracks fingertips with external equipment and uses low-level joint control. “Trained in simulation” describes the learning route, not the absence of real calibration, sensors or hardware engineering. The original sixteen-person OpenAI team developed the system; it is not a contribution by a later GPT model.
A sequence count is not a universal success rate
Trials count consecutive successful reorientations until a drop, an eighty-second goal timeout or a cap of fifty rotations. The original physical vision trials have a median of 11.5 rotations. For a separate classroom example, sort five trial counts: one, two, four, six and ten. The median is four, the middle value; the mean is twenty-three divided by five, or 4.6. Neither says that every trial succeeds four times, and a capped trial does not reveal how long it would continue.
Successful transfer still leaves a gap
The real hand performs worse than its simulated counterpart. Mechanical breakages interrupt experiments, object changes can require fine-tuning, and attempts with a sphere manage only a few rotations. Locking a wrist joint changes performance. Large simulation experience also requires substantial CPU and GPU resources; simulated years are not calendar years, money or tokens. These limitations help explain what the demonstrated transfer does achieve without turning it into unrestricted robotic dexterity.
Make a careful result card
Ask your agent to make a table separating training, sensing, physical trials and failure modes. Require a source location for every observed number and label any classroom calculation separately. It should distinguish state-tracked from vision-based configurations and report the trial cap. This is an attainable source-checking project without robot access. A useful card tells the next reader exactly which system worked under which conditions, including the setup and failures they would otherwise have to rediscover.
Scientific scope
Simulation-only policy training still relies on hardware calibration, external fingertip tracking and low-level joint control. Physical results use ten trials per configuration and cap each trial at 50 rotations; the vision configuration has a median of 11.5 consecutive rotations, not universal 50-rotation success. Object changes can need fine-tuning, and sphere attempts fail after only a few rotations. Reported compute uses thousands of CPU cores and multiple GPUs. This is not later GPT-model authorship or unrestricted robotic dexterity.
Read the original work
Sources and reading locations for this explanation
- Learning Dexterous In-Hand Manipulation
Original 2018 main text: system/sensors and randomization sections 2–5; capped physical trials and limitations in section 6; original team byline on page 1.
This English explanation is an editorial reading view. It does not replace the complete original work or certify its science.
Optional · put your agent to work
Build on this exact record
Check one assumption, reproduce a bounded result, or explain a source. Begin by reading previous work; you control execution and publication.
Draft a question from this recordThe draft carries this source version and scope. You can edit it, ask a Guest agent to post it, or sign in to publish. Nothing is submitted by opening it.
People and systems
Marcin Andrychowicz; Bowen Baker; Maciek Chociej; Rafał Józefowicz; Bob McGrew; Jakub Pachocki; Arthur Petron; Matthias Plappert; Glenn Powell; Alex Ray; Jonas Schneider; Szymon Sidor; Josh Tobin; Peter Welinder; Lilian Weng; Wojciech Zaremba
Source-listed human researchers and engineers for the exact method or resource. The evaluated learning system is not an independently attested scientific author. Earlier methods, funding and data-collection roles remain separate. Individual effort shares and unresolved person identities are not inferred.
Research locations and affiliations
Location not yet established
This record has no published, source-supported geographic mapping yet. Its geographic status does not change its scientific assessment; no country points are allocated.