PAPER DEEP DIVE
FADA: Few-Shot Domain Adaptation via Dynamics Alignment for Humanoid Control
High-precision humanoid control is limited by target-domain dynamics mismatch, where the same control objective can induce different realized motions under changes in terrain, payload, or actuator response. Existing methods either pursue zero-shot transfer through domain randomization or in-context adaptation without target-domain specialization, or require heavy adaptation pipelines that leverage target-domain data, such as model calibration, residual learning, or policy retraining. In this paper, we present FADA (Few-Shot Domain Adaptation via Dynamics Alignment), a three-stage Planner-Inverse Dynamics Model (Planner-IDM) framework for few-shot adaptation in humanoid control. FADA first trains an oracle policy with privileged information and then distills the oracle behavior into a deployable Planner-IDM student through DAgger. At deployment, FADA freezes the planner and finetunes only the IDM using approximately 2 minutes of target-domain rollouts with standard supervised learning. Rather than requiring optimal demonstrations or rewards, FADA uses the paired actions and observations that are observed during these rollouts as supervision, aligning the IDM's action generation with target-domain dynamics. Experiments show that FADA outperforms both in-context and end-to-end adaptation baselines, improving task performance under dynamics shifts and enabling real humanoid robots to execute diverse high-precision whole-body tasks. Implementation details and qualitative hardware rollout videos are available at https://lecar-lab.github.io/FADA-humanoid/.
One-line summary
FADA factorizes a humanoid controller into a planner that emits six-step proprioceptive intent and an inverse dynamics model that turns that intent into actions. After deployment, the planner is frozen and only a low-rank update to the IDM is learned from about two minutes of ordinary target rollouts. On Unitree G1 and Booster T1, this raises slope and basket-pulling success from 20% to 80–100% without target rewards, demonstrations, motion capture, or simulator recalibration.
Why the transfer failure is a plan-to-action failure
Humanoid policies are usually made robust before deployment: domain randomization covers friction, mass, actuator response, delays, and observation noise; privileged-to-student distillation removes simulator-only state; IsaacSim supplies a safe place to fail. These methods answer a source-distribution question. A deployment environment asks a different one: when the realized transition dynamics move outside that distribution, does the same command still cause the same intended motion?
The answer breaks down in coupled whole-body dynamics. A small change in terrain stiffness changes contact timing. Contact timing changes support. Support changes the torque that the next action must generate. A one-kilogram asymmetric payload is not just added mass; it changes the posture, gait, and contact sequence used to realize a velocity command. On deformable mats or under a persistent pulling force, the failure mode becomes even clearer: the robot may start the correct skill, but its previously learned action map cannot maintain the intended body motion.
The paper organizes prior work by what is updated at target time. Zero-shot methods randomize the source distribution or infer a deployment-time context without changing weights. Target-data methods perform system identification, learn residual dynamics, or finetune a policy. The first class remains conservative; the second usually needs a simulator to fit, expert demonstrations, or a computable target reward. FADA asks whether none of those ingredients is necessary if the target rollouts themselves contain a usable supervision signal.
They do. A robot executing a zero-shot policy for two minutes produces paired proprioceptive observations and executed actions. The trajectories are suboptimal, but each realized future is causally paired with actions that actually produced it. FADA uses that pairing to recalibrate the inverse dynamics side of the controller. This is a deliberately narrow update: it preserves the command interface and task semantics, while adapting the component most affected by physical shift.
The code release reinforces the claim. The repository covers oracle PPO training, Planner-IDM DAgger distillation, checkpoint evaluation, ONNX export, MuJoCo and hardware data collection, IDM LoRA finetuning, and matched pre/post rollouts. The README states that the hardware H5 dataset feeds the same finetuning entry point as the simulator dataset.
Problem setup
For a fixed task $\mathcal{T}$ and deployment condition $\xi$, FADA considers the MDP
$$\mathcal{M}_{\mathcal{T},\xi}=(\mathcal{S},\mathcal{O},\mathcal{A},p_{\xi},r_{\mathcal{T}}).$$
Here $s_t\in\mathcal{S}$ is privileged state, $o_t\in\mathcal{O}$ is deployable proprioception, $a_t\in\mathcal{A}$ is action, and $c_t\in\mathcal{C}$ is a velocity command or motion reference. Domain shift lives in $p_{\xi}$; the target reward $r_{\mathcal{T}}$ is unavailable. Source training has a privileged oracle $\pi^{o}(s_t,c_t)\mapsto a_t^{\star}$, while the student sees histories $\mathcal{O}_t^H$, $\mathcal{A}_t^H$, and command $c_t$:
$$\pi^{s}(\mathcal{O}_{t}^{H},\mathcal{A}_{t}^{H},c_{t})\mapsto a_{t},\quad\mathcal{O}_{t}^{H}=(o_{t-H+1},\ldots,o_{t}),\quad\mathcal{A}_{t}^{H}=(a_{t-H},\ldots,a_{t-1}).$$
The target dataset contains only ordinary executed rollouts,
$$\mathcal{D}_{\mathrm{tgt}}=\{\tau_{i}\}_{i=1}^{N_{\mathrm{roll}}},\qquad\tau_{i}=\{(o_{t},c_{t},a_{t})\}_{t=0}^{T_{i}}.$$
These equations define the access model. Adaptation may read paired observations, commands, and executed actions. It may not read privileged contact forces, terrain height, actuator parameters, rewards, or expert labels. In the experiments, the history length is $H=30$ and the prediction horizon is $K=6$.
Planner-IDM factorization
The central structural claim is that target-domain shift changes how an intent must be executed more often than it changes the intent itself. FADA therefore writes the deployable student as $\pi^{s}=(P_{\phi},I)$. The planner predicts a $K$-step proprioceptive future $\hat{Y}_{t}^{K}$ from history and command. The IDM maps history, action history, and this future to an action chunk. Only the first action is deployed:
$$\hat{Y}_{t}^{K}=P_{\phi}(\mathcal{O}_{t}^{H},c_{t}),\qquad\hat{U}_{t}^{K}=I(\mathcal{O}_{t}^{H},\mathcal{A}_{t}^{H},\hat{Y}_{t}^{K}),\qquad\hat{a}_{t}=\Pi_{1}(\hat{U}_{t}^{K}).$$
The operator $\Pi_1$ is a contract, not merely an array index. The IDM may emit a six-step action chunk, but both training and deployment score the first action. This avoids a common mismatch in which a sequence model learns a full-window behavior while a receding-horizon robot executes only its first step.
Source IDM objective
For source rollout windows $(\mathcal{O}_{t}^{H},\mathcal{A}_{t}^{H},Y_{t,\mathrm{exec}}^{K},U_{t,\mathrm{exec}}^{K})$, $U_{t,\mathrm{exec}}^{K}$ contains the actions executed by the student, not privileged oracle actions. The IDM is trained with
$$\mathcal{L}_{I}(\psi)=\mathbb{E}_{(\mathcal{O}_{t}^{H},\mathcal{A}_{t}^{H},Y_{t,\mathrm{exec}}^{K},U_{t,\mathrm{exec}}^{K})\sim\mathcal{D}_{I}^{\mathrm{src}}}\left[\left\|\Pi_{1}\!\left(I(\mathcal{O}_{t}^{H},\mathcal{A}_{t}^{H},Y_{t,\mathrm{exec}}^{K})\right)-\Pi_{1}(U_{t,\mathrm{exec}}^{K})\right\|_{2}^{2}\right].$$
This objective survives imperfect data because DAgger already includes teacher-guided and weaker student trajectories. The IDM learns the action that actually belongs to a physically realized future. A target-domain rollout is still a valid realized future, even if it is not optimal.
Actionable planner futures
A planner trained to regress oracle future observations can look plausible while producing futures that are useless to the IDM. FADA instead evaluates the planner through the current IDM. With a stop-gradient through the IDM, denoted $I_{\bar{\psi}}$, the planner minimizes the error against the privileged first oracle action:
$$\mathcal{L}_{P}(\phi)=\mathbb{E}_{(\mathcal{O}_{t}^{H},\mathcal{A}_{t}^{H},c_{t},a_{t}^{\star})\sim\mathcal{D}_{P}^{\mathrm{src}}}\left[\left\|\Pi_{1}\!\left(I_{\bar{\psi}}(\mathcal{O}_{t}^{H},\mathcal{A}_{t}^{H},P_{\phi}(\mathcal{O}_{t}^{H},c_{t}))\right)-a_{t}^{\star}\right\|_{2}^{2}\right].$$
The future is therefore judged by its downstream action consistency. Appendix B gives the planner residual form $\hat{Y}_{t}^{K}=o_t+\Delta\hat{Y}_{t}^{K}$, so the network predicts a delta from the latest observation. In code, `fada/planner_idm/model.py` and `common/backbone.py` implement the transformer modules, while `trainer_batching.py` handles future-observation masking, noise, and loss branches.
Oracle relabeling on student states
Oracle labels are obtained by snapshot relabeling. The system saves a simulator snapshot at each visited student state, restores it after the rollout, and rolls the privileged oracle forward for $K$ steps under the same command. That produces the oracle-shadow pair $(Y_{\mathrm{orac}}^{K},U_{\mathrm{orac}}^{K})$, whose first action supplies $a_t^\star$. For trajectory-source batches, the IDM instead uses the realized pair $(Y_{\mathrm{traj}}^{K},U_{\mathrm{traj}}^{K})$:
$$(Y_{I}^{K},U_{I}^{K})=\begin{cases}(Y_{\mathrm{traj}}^{K},U_{\mathrm{traj}}^{K}),&\text{for trajectory-source batches},\\ (Y_{\mathrm{orac}}^{K},U_{\mathrm{orac}}^{K}),&\text{for oracle-source batches}.\end{cases}$$
This matters because the oracle-shadow pair is physically rolled out; its observations and actions are causally consistent. It is not a synthetic future invented after the fact. `fada/planner_idm/trainer_rollout.py` implements the snapshot restore, oracle forward pass, and oracle-shadow chunk assembly.
Few-shot LoRA adaptation
At target deployment, FADA-zs runs for approximately 6000 control steps. For locomotion this is about two minutes at 50 Hz; for whole-body tracking it is six repetitions of an approximately 20-second reference motion. The collected windows form
$$\mathcal{W}_{\mathrm{tgt}}=\left\{\left(\mathcal{O}_{t}^{H},\mathcal{A}_{t}^{H},Y_{t,\mathrm{exec}}^{K},U_{t,\mathrm{exec}}^{K}\right)\right\}.$$
The planner parameters $\phi$ and the pretrained IDM parameters $\psi$ are frozen. Only the low-rank update $\Delta\psi$ is optimized:
$$\ell_{\mathrm{adapt}}(\Delta\psi)=\mathbb{E}_{(\mathcal{O}_{t}^{H},\mathcal{A}_{t}^{H},Y_{t,\mathrm{exec}}^{K},U_{t,\mathrm{exec}}^{K})\sim\mathcal{W}_{\mathrm{tgt}}}\left[\left\|\Pi_{1}\!\left(I_{\psi+\Delta\psi}(\mathcal{O}_{t}^{H},\mathcal{A}_{t}^{H},Y_{t,\mathrm{exec}}^{K})\right)-\Pi_{1}(U_{t,\mathrm{exec}}^{K})\right\|_{2}^{2}\right].$$
The deployed controller becomes $\pi^{\mathrm{ft}}=(P_{\phi},I_{\psi+\Delta\psi})$. LoRA is not only a memory optimization. Full IDM finetuning can overfit two minutes of data, while a low-rank residual constrains the executable correction. In the official implementation, `fada/common/lora_utils.py` wraps linear layers and packed QKV attention with `LoRALinear` and `LoRAMultiheadAttention`, keeps the base weights frozen, and `finetune_idm_lora.py` performs the target update.
Why the planner stays frozen
The target dataset was generated under the old intent interface. If the planner changed, new intents could point into regions without supervision. Keeping it frozen also makes matched pre/post comparisons possible: the same command sequence can be replayed against the two ONNX files. The controlled arm study in Section 5.6 supports the separation. Across 0, 2.5, and 5.0 kg wrist loads, the planner RMSE changes only from 0.049 to 0.052 radians, while IDM adaptation reduces the consistency gap and end-effector error.
flowchart TB
subgraph SRC["Source training"]
ORC[Privileged oracle] --> DAS[DAgger rollouts]
DAS --> YU[Realized future Y and executed U]
YU --> IDM1[IDM first-action loss]
DAS --> REL[Oracle relabel snapshots]
REL --> PLAN[Planner through frozen IDM]
PLAN --> STUDENT[Planner-IDM student]
end
STUDENT --> ZS[Zero-shot FADA-zs]
ZS --> COL[Collect about 2 min target rollouts]
COL --> WIN[Extract paired windows]
WIN --> LORA[LoRA update on IDM only]
LORA --> FT[Adapted policy]
FT --> RUN[Execute first action]
RUN --> VERIFY[Same command pre/post test]
Experiments
The systems are Unitree G1 with 29 DoF and Booster T1 with 23 DoF. Students are trained in IsaacSim with $H=30$ and $K=6$. Hardware tasks include two 15-degree ramps about 0.8 meters wide, approximately 3 kg asymmetric groceries, Kungfu tracking on deformable mats, a 1 kg asymmetric arm payload, and pulling an approximately 6 kg laundry basket. Hardware results average five trials, main sim-to-sim results average twenty, and every adaptation budget is matched to about 6000 steps.
Real-hardware results
| Method | G1 slope success | G1 payload velocity error | G1 soft-terrain MPJPE | T1 payload velocity error | T1 basket success |
|---|---|---|---|---|---|
| TF-DAgger | 0% | 1.000±0.203 | 1.00±0.091 | 1.000±0.132 | 0% |
| FADA-zs | 20% | 1.289±0.711 | 1.18±0.103 | 1.043±0.025 | 20% |
| FADA | 80% | 0.797±0.018 | 0.86±0.084 | 0.866±0.040 | 100% |
Normalized errors use TF-DAgger as 1.0, so lower is better. The two completion tasks improve from a 20% average to 90%, while TF-DAgger fails both. Across the three continuous-error tasks, FADA lowers error by 27.4% relative to FADA-zs and 15.9% relative to TF-DAgger. The IDM loss also drops on all five tasks, evaluated on windows collected by each policy. That is the quantitative signature of dynamics alignment: the plan-to-action map, not one lucky trajectory, becomes better matched to the target.
The qualitative failures match the architecture. Terrain and contact shifts cause accumulated foot-placement and posture error; payload and dragging shifts leave the plan reasonable but break action realization. The same LoRA update addresses both because it recalibrates the shared execution mapping. The soft-mat Kungfu task is especially notable because deformable contact lies outside the source randomization distribution.
Sim-to-sim transfer
| Method | G1 slope | G1 Kungfu | T1 payload | T1 slope | T1 Falcon |
|---|---|---|---|---|---|
| TF-DAgger | 1.000±0.439 | 1.000±0.052 | 1.000±0.143 | 1.000±0.252 | 1.000±0.086 |
| TF-CoPred-zs | 0.973±0.387 | 1.031±0.068 | 1.029±0.142 | 1.080±0.224 | 0.943±0.133 |
| TF-CoPred-ft | 1.611±0.488 | 1.421±0.198 | 1.737±0.387 | 1.193±0.246 | 1.054±0.162 |
| FADA-zs | 0.946±0.358 | 0.961±0.055 | 1.042±0.147 | 1.034±0.334 | 0.880±0.094 |
| FADA | 0.800±0.236 | 0.714±0.048 | 0.885±0.135 | 0.914±0.193 | 0.347±0.043 |
Across IsaacSim-to-MuJoCo tasks, FADA reduces normalized error by 24.7% relative to FADA-zs and 26.8% relative to TF-DAgger. The largest gain is T1 Falcon, where the robot must compensate a persistent external pulling force while tracking velocity. The negative control is equally informative: TF-CoPred-ft improves future-observation prediction but makes every task worse. Better prediction alone does not fix the action map.
Ablations
| Design | Key numbers | Conclusion |
|---|---|---|
| Prediction horizon | $K=1$ gives 1.000; $K=6$ gives 0.830 and 0.813; $K=10/15$ do not improve | A six-step future supplies about 18% of the gain; longer windows saturate |
| Training contract | Without first-action supervision, success drops from 10/10 to 4/10; without planner-through-IDM, to 7/10; without both, to 1/10 | Training must match receding-horizon execution |
| LoRA vs full finetuning | G1 slope 0.8463 vs 1.1000; T1 payload 0.8489 vs 1.1163; T1 slope 0.8846 vs 1.2918 | Full IDM updates overfit the two-minute budget |
| Data budget | 6000 steps gives 0.758; 10k, 20k, and 30k give 0.793, 0.794, and 0.777 | The main budget reaches the plateau |
| Role separation | Planner RMSE 0.049 to 0.052 rad from 0 to 5 kg; consistency gap drops about 54%; end-effector error drops about 24% | Intent remains stable while execution adapts |
Limitations
The authors identify three boundaries. First, FADA requires non-trivial zero-shot performance: catastrophic initial failures cannot collect useful observation-action pairs and may need recovery controllers or assisted collection. Second, the IDM is intended to capture execution dynamics, but it is still trained within a task distribution and may encode task-specific structure. Third, the current instantiation uses only proprioception and executed actions; it does not explicitly represent terrain geometry or payload distribution, so primarily exteroceptive shifts may require richer inputs.
A further engineering caution is warranted. The 6000-step plateau is evidence for the tested slopes, payloads, soft terrain, and pulling force, not a universal convergence law. If the robot falls repeatedly during collection, the data distribution is truncated. If the shift involves high-frequency contact timing, the 50 Hz proprioceptive window may need redesign. LoRA provides a strong safeguard, but the safety envelope should still be measured per task.
Conclusion
FADA turns post-deployment adaptation into a narrow, supervised update. The planner preserves what the robot is trying to do; the IDM learns how to do it under the measured physics. Because the adaptation objective is exactly the first-action execution objective, two minutes of ordinary rollouts are enough to produce a targeted correction. The result is a practical recipe for humanoids: keep the command interface stable, collect a short trajectory, and update only the execution seam.
Many humanoid transfer failures are not failures of understanding the task; they are failures of the old action table under new physics. FADA rewrites only the action table.
