ElevateHead: Decide Once, Then Commit: When the Action Head Matters for Multimodal Imitation
Organizations: National University
Abstract
Robots that learn from people often see several valid ways to do the same task: pass an obstacle on the left or on the right, open the microwave or move the kettle first. A policy that re-decides at every step can waver between these ways mid-task. We ask when the action head (the part of a policy that turns the state into actions) matters, and how it should make this choice. On a controlled task, heads that sample one way succeed far more often than a head that averages the ways when the demonstrations contain several ways and the state gives no hint which to take (+0.72 success with two ways); this trend was not reproduced on the other tasks we ran. We then present ElevateHead, a head that decides once at a learned decision point, commits to that choice for the episode, and exposes the choice as an input a user can set. We designed it by diagnosis: each version was frozen and tested on tasks it had not seen, and the next version changed only what a measured failure pointed to; predictions were registered before each run. The first four versions each fell below BeT on at least one held-out task. The fifth completed all four subtasks of the held-out Franka Kitchen task in 45.2% of episodes against 29.3% for BeT, the strongest baseline across our tasks (+0.160, 95% CI [+0.129, +0.188]); when a mode was forced, the first completed subtask matched it in 95% of successful episodes. Diagnosis also located where commitment breaks: varied start positions (repaired on the controlled task: commitment 0.22 to 0.81, success 0.74 to 0.91) and varied object placement (partly repaired: in an exploratory variant, commitment 0.03 to 0.59 on aligning with no detectable change in success). On held-out block stacking, version 4 was comparable to BeT and did not exceed it. A real-robot test with predictions fixed in advance is planned for a follow-up version of this paper.
Figures & tables
| Question | Answer | Key evidence |
|---|---|---|
| When does the head matter? (§ III ) | With several ways and no hint in the state (controlled task); not reproduced on other tasks | gap at two ways, when the average path works |
| Does deciding once help on an unseen task? (§ VI ) | Yes on Kitchen; not shown on stacking | 0.452 vs. 0.293 for BeT, [+0.129, +0.188] |
| Does the mode input set the behavior? | On Kitchen, mostly (descriptive) | first subtask matches the forced mode in 95.4% of successes |
| Where does commitment break? | Varied starts (repaired on one task), few demonstrations | commitment 1.00 to 0.22; gate ( 1 ) restores 0.81 |
| Varied object placement (toward clutter)? | Partly repaired; success unchanged within uncertainty (exploratory) | commitment 0.03 to 0.59 (aligning), 0.32 to 0.64 (stacking) |
| Which baseline is strongest? (Table III ) | BeT (or tied) on every task, among eight heads | Kitchen : BeT 0.293, flow 0.111, diffusion 0.000 |
| Ver. | Diagnosis (registered experiments) | Change in the next version |
|---|---|---|
| v1 | On sorting-2 the proposal was confident, yet the head committed and timed out; re-selection, its threshold and the mode choice were ruled out as causes | v2: commit only when the proposal is uncertain; train a no-mode branch (mode dropout 0.25) |
| v2 | On pushing the regression loss limited it, not commitment (plain L1 0.10 vs. L2 0.68) | v3: L2 action loss |
| v3 | On aligning the gate never committed (certain proposal), so success rested on an action network that trailed BeT | v4: BeT-style action network |
| v4 | On development tasks: commitment helped on avoiding; re-selecting a mode when the arm “stalls” hurt (turning it off: on pushing); the gate closed as clustering found more modes | v5: no stall re-selection; gate ( 1 ); training unchanged |
| Task | L1 | L2 | MIP | AR | VQ-BeT | Flow | Diff. | BeT | ElevateHead |
|---|---|---|---|---|---|---|---|---|---|
| avoiding | .667 | .000 | .000 | .807 | .610 | .490 | .300 | .813 | .967 † |
| sorting-2 | .667 | .643 | .743 | – | – | – | – | .776 | .619 (v1) |
| sorting-4 | .043 | .034 | .041 | .083 | – | – | – | .166 | .054 (v2) |
| pushing | .102 | .683 | .154 | .602 | – | – | – | .787 | .764 † |
| aligning | .001 | .134 | .020 | .246 | .131 | .247 | .032 | .342 | .402 † |
| stacking a | .140 | .017 | .000 | .107 | .130 | .016 | .000 | .139 | .154 (v4) |
| Id | Task | Test | Value [lo, hi] | Verdict |
| P1 | C-S | slope of on | [+0.134, +0.437] | supported |
| P2 | C-S | [-0.039, -0.025] | inconclusive | |
| P5 | C-S | [+0.363, +0.981] | supported | |
| HM-1 | C-S | falls with start jitter (0, 0.005, 0.02) | supported | |
| HM-3 | C-S | (open loop) (closed loop) , jitter 0.02 | [+0.097, +0.189] | supported |
| HM-4 | C-S | blocked route: deterministic , noise heads | 0.00 vs. 0.42 | supported |
| Task (role for v5) | v5 | BeT | v5 BeT |
|---|---|---|---|
| C-S, (development) | 1.000 | 1.000 | |
| avoiding (development) | 0.967 | 0.813 | [+0.097, +0.217] |
| pushing (development) | 0.764 | 0.787 | [-0.076, +0.029] |
| aligning (development) | 0.402 | 0.342 | [+0.016, +0.104] |
| stacking, 3 boxes (held-out) | 0.044 | 0.043 | – |
| Kitchen (held-out) | 0.452 | 0.293 | [+0.129, +0.188] |
| C-S dataset | commit v4 | commit v5 | succ. v4 | succ. v5 | BeT | steer (seeds) |
|---|---|---|---|---|---|---|
| 1.000 | 1.000 | 1.000 | 1.000 | 1.000 | 1.000 (5/5) | |
| 1.000 | 1.000 | 1.000 | 1.000 | 1.000 | 1.000 (5/5) | |
| 1.000 | 1.000 | 1.000 | 1.000 | 1.000 | 0.989 (5/5) | |
| 0.620 | 1.000 | 1.000 | 1.000 | 1.000 | 0.953 (5/5) | |
| 0.342 | 0.950 | 1.000 | 1.000 | 1.000 | 0.931 (5/5) | |
| 0.216 | 0.812 | 0.744 | 0.912 | 0.740 | 0.921 (5/5) |
| Head (one CPU thread, batch 1) | stacking | aligning |
|---|---|---|
| BeT | 0.495 | 0.524 |
| ElevateHead (v4 networks) | 0.659 | 0.631 |
| VQ-BeT | 2.185 | 1.615 |
| Flow matching (10 steps) | 2.119 | 1.892 |
| Diffusion (10 DDIM steps) | 2.604 | 2.331 |
Robot Policy Learning
Robot policy learning develops controllers that map sensory observations, task goals, and interaction history to actions for embodied robots.
See all 369 papers