ASAP uses real humanoid trajectories to learn a correction for simulation training, then deploys the newly trained policy without that correction model. The distinction is essential: the robot still has to produce real rollouts to reveal the mismatch, but the learned residual is inserted into the simulator during policy fine-tuning rather than added to the final hardware control loop. If you are evaluating this route, trace which data fit the residual, which simulator received it, and which policy was actually tested on the robot.
The ASAP authors’ project page describes four stages: motion-tracking pre-training, real trajectory collection, delta-action learning, and fine-tuning with the frozen delta model inside simulation. Their reported hardware demonstrations involve a Unitree G1 and selected agile whole-body skills. That is evidence about the authors’ setup, not a promise that the same correction transfers to another humanoid or motion library.
What the residual changes
A nominal simulator can produce a plausible kick or jump while the corresponding hardware follows a different trajectory. Motor response, contact and other dynamics may all contribute. ASAP learns an action correction instead of requiring an engineer to attribute the entire discrepancy to one physical parameter. That makes the location of the correction crucial to interpreting a result.
That sequence has a direction. First obtain a pre-trained policy and run it on the real robot under the collection protocol. Then fit the correction using the resulting paired sim/real information. Freeze the correction and fine-tune the motion-tracking policy in the altered simulator. Finally deploy the fine-tuned policy alone. The paper’s post-training method explicitly separates simulator insertion from final deployment. Saying that ASAP “adds a residual controller at runtime” reverses that boundary.
The residual is also narrower than a universal simulator repair. A correction learned from particular motions, states and hardware can be a poor guide outside their coverage. The paper compares transfers among Isaac Gym, Isaac Sim, Genesis and a real G1; those are distinct evaluation settings. Before treating one result as evidence for your machine, name the training engine, the correction’s fitting trajectories, the fine-tuning engine and the target platform.
| Stage | Artifact to retain | What the stage can establish | What it cannot establish |
|---|---|---|---|
| Initial policy and real collection | Policy version, motion IDs, timestamps, observed state and actuator commands | The particular behavior that exposed a gap | Safe exploration of untested skills |
| Residual fitting | Paired-state definition, alignment rule, training split and frozen model | A correction on represented trajectories | A unique diagnosis of every physical cause |
| Corrected-simulator fine-tuning | Simulator build, residual version and new policy checkpoint | Whether training responds to the inserted correction | Hardware success by itself |
| Correction-free deployment | Final policy ID and independent hardware rollouts | Whether that policy works under tested conditions | Generalization to all motions and robots |
This table is an editorial audit framework, not an ASAP experiment. It prevents a common attribution error: using a successful corrected-simulator rollout as if it were the final hardware result.
A proposed diagnostic for one motion
Imagine a lab with a pre-trained sideways-jump policy. In the first hardware trials, the landing state repeatedly differs from the simulated landing state. A proposed local investigation would align the commanded motion and observed states from these trials, reserve some real runs from residual fitting, and compare three policies on matched starts: the original policy, a policy fine-tuned in the unchanged simulator, and one fine-tuned with the frozen correction. The hardware comparison must run the policies themselves, without secretly applying the residual to their output.
That example is hypothetical. No sideways-jump dataset or robot trial was created for this article. It illustrates why both a held-out trajectory set and an uncorrected-simulator comparison matter. If all fitting and evaluation trials share the same landing state, a residual can look persuasive by replaying a narrow pattern. If other training settings also change, an apparent improvement cannot be cleanly attributed to the simulator correction. Keep contact conditions, motion specification and evaluation criteria visible.
For a broader comparison of simulation changes, the domain-randomization guide explains how varying training conditions differs from identifying one measured discrepancy. ASAP’s project contrasts its route with system identification and domain randomization, but the result belongs to its selected skills and baselines. The useful decision is not which label sounds more modern; it is whether your team can collect enough relevant real trajectories and demonstrate that the corrected training stage improves a later independent hardware rollout.
Keep simulator evidence separate from hardware evidence
A simulator corrected with real data remains a simulator. If two candidate policies rank differently after correction, that can guide what to test next, yet it does not itself prove their real ordering. The SIMPLER policy-ranking discussion addresses that separate question of whether simulation comparisons track real outcomes. ASAP instead changes the training dynamics using a learned delta. The two questions can coexist, but their evidence should not be merged into one success claim.
The paper identifies concrete access limits: precise motion capture for real trajectories, actuator overheating and damage during collection, and substantial data demand when fitting all joint corrections. Its reduced ankle-joint correction and full-body correction study should not be treated as equally practical data-collection recipes. A team without reliable trajectory measurements does not yet have the inputs assumed by this workflow.
For deployment review, ask for the exact final checkpoint, a record that the residual model was absent from hardware inference, and outcome traces for motions not used to fit it. Note failures as carefully as successes: a policy may track the original motion yet fail at contact timing, recovery or a changed surface. The author demonstrations do not establish safety or validate an untested platform. No code, simulator or robot was run for this article.