witcheer/microduck-walk-slope

walk-slope

Walk on gentle hills with +-1 deg of gear play in every servo: walk-flat v2 plus 3,000 iterations (7,000 to 10,000) on a floor of pyramid hills, slope 0.05 to 0.15 rise per run (our one-change fork Mjlab-Velocity-Flat-Backlash-Slope-MicroDuck), 4096 envs, about 128 min on one RTX 5090. Trained in simulation only. On a 0.15 hill, walking straight ahead at 0.3 m/s, it stayed on its feet for 20 s in 23 of 30 takes against 12 of 30 for walk-flat v2 (one-sided Fisher p 0.0041): 14 of 15 against 8 of 15 without shoves, 9 of 15 against 4 of 15 with shoves every 0.5-1 s. On the flat control both held 10 of 15. Only the 0.15 hill was tested, every take starting on a hilltop and walking off it. Not yet tested on a real Microduck.

A perpetual policy for the microduck (61-D observation, 14 actions, 50 Hz). Runs until told otherwise — a gait for the walk slot.

Run it on a robot

sudo robotctl policy load walk witcheer/microduck-walk-slope

The observation normalizer is baked into policy.onnx; feed raw observations. manifest.json follows schema 2 of the microduck policy manifest (docs/policy-manifest.md in the daemon repo).

Training

• repo: pollen-robotics/microduck_rl
• branch: develop
• commit: 53b8971b6
• exported from a checkout with uncommitted changes

Results in simulation (v1, 2026-10-22)

Simulation only. Not yet tested on a real Microduck.

Headline first, on the read we fixed before training: pooled over the two hill conditions, walk-slope stayed on its feet for the whole 20 s in 23 of 30 takes against 12 of 30 for walk-flat v2 (one-sided Fisher exact p = 0.0041). On the flat control both held 10 of 15, so there is no sign of a loss on level ground. The cleaner of the two hill conditions is the one without shoves (14 of 15 against 8 of 15); with shoves the gap alone is only a hint (9 of 15 against 4 of 15, one-sided p = 0.070).

What changed: one thing, the floor. Pollen's Mjlab-Velocity-Flat-Backlash-MicroDuck trains on a flat plane. Our fork Mjlab-Velocity-Flat-Backlash-Slope-MicroDuck (task file witcheer_velocity_slope_env_cfg.py) replaces it with a 10 by 10 grid of 4 m tiles, one gentle pyramid hill per tile (mjlab's HfPyramidSlopedTerrainCfg, the generator Pollen's rough grid uses for slopes), with the slope drawn per tile between 0.05 and 0.15 rise per run. At 0.15 the flat top sits 127 mm above the floor and the slope runs about 1 m down to the tile edge. Rewards, terminations, shoves, the gear-play robot, the curricula and the observations are the maker's; the policy has no terrain scan and meets the hill blind. The checkout also carries our local patch that measures height terms from the ground under the feet instead of the tile origin (ground_height_patch.py): on a hill that patch is what lets the height terms see the slope. Those, the import line that registers the fork in tasks/__init__.py and the Hub card metadata patch are why the manifest says the checkout had uncommitted changes.

Training: warm start from walk-flat v2 (model_7000), 3,000 more iterations (7,000 to 10,000), 4096 envs, about 128 min on one RTX 5090 (2.55 s per iteration; the heightfield floor costs about twice the flat task per iteration). The run stopped after 1,200 iterations on the first day and resumed from that checkpoint the next. Over 100-iteration windows, mean reward went 80.1, 101.3 and 101.5 at 7,100, 8,000 and 8,200 (the last full window before the stop), then 105.8 and 106.1 at 9,000 and 10,000: flat over the last 1,000. fell_over went 0.757, 0.570, 0.480, 0.473 at 7,100, 8,000, 9,000 and 10,000, and the velocity tracking error went from 0.351 to 0.449. These are on hills, so they do not compare with walk-flat v2's own training numbers on the flat.

Proof takes with headless_play in the slope task, walk-slope against walk-flat v2 under identical settings: 20 s each, standing start on a hilltop, walking command fixed straight ahead at 0.3 m/s, samples every 0.1 s, 15 takes per policy per condition, every tile forced to the same slope. A take counts as held when it has no tilt fall and no mid-episode reset (the task's fell_over termination fires at 70 degrees of tilt). The slope setting was checked in the play env before any take (every hilltop at 127.0 mm at 0.15, 1.0 mm at the control setting), and the takes drop mjlab's out-of-terrain-bounds timeout, which on a generated floor otherwise ends a take that starts in an edge tile after a metre or two of walking with the duck still upright.

• 0.15 hill, no shoves: 14 of 15 held against 8 of 15 (one-sided p = 0.018). Takes with a fall event on the slope band: 1 against 5.
• 0.15 hill with the maker's play shoves (up to ±0.3 m/s every 0.5 to 1 s): 9 of 15 against 4 of 15 (one-sided p = 0.070, a hint on its own). Takes with a fall event on the slope band: 5 against 6; walk-flat v2 also lost 5 takes first on the hilltop, to the shoves.
• Both hill conditions pooled (the read fixed in advance): 23 of 30 against 12 of 30 (one-sided p = 0.0041).
• Flat control, same layout with 1 mm hills, with shoves: 10 of 15 against 10 of 15 (two-sided p = 1.0). No loss.

No take in any condition ended in a mid-episode reset with the duck upright, so no count here depends on that timeout fix. Walk-flat v2's videos for the shove condition were lost to a temp-folder clash between two batches running in parallel; its take logs are complete and the counts above come from them.

Not tested: any slope but 0.15 and the 1 mm control, uphill walking on its own (every take starts on a hilltop and walks off it; most go past the bottom of the slope where the next hill begins, but uphill is not scored separately), slopes steeper than 0.15, any command other than straight ahead at 0.3 m/s, more than 20 s, a second simulator, and a real robot. Not yet tested on a real Microduck.

Run log: the microduck-skill-tree dataset (folder level-01g-walk-slope) carries the reward curve, the queue item, the fork file and every take log. Sibling policies: witcheer/microduck-*. walk-flat stays the default walk; walk-slope is the variant trained on hills.

Simulation only.