Instructions to use witcheer/microduck-walk-mix with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- Microduck
How to use witcheer/microduck-walk-mix with Microduck:
sudo robotctl policy load walk witcheer/microduck-walk-mix
- Notebooks
- Google Colab
- Kaggle
walk-mix
One walk for three conditions at once, with +-1 deg of gear play in every servo: walk-step v1 plus 3,000 iterations (10,000 to 13,000) on a floor with single 10-25 mm steps, foot friction from 0.2 to 1.3 and the training shove doubled to +-0.6 m/s every 3-6 s (our fork Mjlab-Velocity-Flat-Backlash-Mix-MicroDuck), 4096 envs, 64 min on one RTX 5090. Trained in simulation only. With all three at once (25 mm step, friction 0.2, doubled shoves), walking straight ahead at 0.3 m/s, it stayed on its feet for 20 s in 9 of 15 takes against 0 of 15 for walk-flat v2 (one-sided Fisher p 0.0003). Against each single-condition policy on its own condition it showed no measurable loss: step 10 of 15 vs walk-step 13 of 15 (p 0.39), doubled shoves 10 of 15 vs walk-push 9 of 15, slippery floor with shoves 11 of 15 vs walk-slip 3 of 15 (a low draw: walk-slip held 6 to 8 of 15 in three other 15-take sets at that friction and shove, so read it as no loss, not a win). 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-mix
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 condition we picked in advance as the test of this run: with all three conditions at once (a 25 mm step, foot friction 0.2 and doubled shoves every 3 to 6 s), walk-mix stayed on its feet for the whole 20 s in 9 of 15 takes against 0 of 15 for walk-flat v2 (one-sided Fisher exact p = 0.0003). Against each of the three single-condition policies on that policy's own condition, there is no measurable loss. One of those three reads needs a caveat, set out below: walk-slip scored low in this batch.
Why it exists: three of our one-change forks of walk-flat v2 each trained one condition, a single step (walk-step), a slippery floor (walk-slip) and harder shoves (walk-push). A real owner installs one walk policy, so this run asks whether one policy can carry all three without losing any of them.
What changed against Pollen's Mjlab-Velocity-Flat-Backlash-MicroDuck, all three at once, in our fork Mjlab-Velocity-Flat-Backlash-Mix-MicroDuck (task file witcheer_velocity_mix_env_cfg.py, which imports the three single-condition task files rather than copying them):
- floor: one 1.5 m platform per 4 m tile, its top 10 to 25 mm above the floor, so every edge crossing is a single step (
witcheer_velocity_step_env_cfg.py); - foot friction drawn per env between 0.2 and 1.3 instead of 0.7 to 1.3 (
witcheer_velocity_slip_env_cfg.py); - the training shove doubled from ±0.3 to ±0.6 m/s, still every 3 to 6 s (
witcheer_velocity_push_env_cfg.py).
Rewards, terminations, the gear-play robot, the curricula and the observations are the maker's; the policy has no terrain scan and meets the step 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). 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-step v1 (model_10000), 3,000 more iterations (10,000 to 13,000), 4096 envs, 64 min on one RTX 5090 (about 1.29 s per iteration), one uncut block. Over 100-iteration windows, mean reward went 44.8, 49.5 and 50.6 at 11,000, 12,000 and 13,000 (38.1 at 10,100, the resume ramp), fell_over 3.62, 3.00 and 2.93, and the velocity tracking error 0.357, 0.375 and 0.383: nearly flat over the last 1,000. These are under all three conditions at once, so they do not compare with any single-condition policy's training numbers.
Proof takes with headless_play in the mix task, 20 s each, standing start on a platform, 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 step height, both policies of a pair under identical settings. 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 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. The step, friction and shove overrides are the same functions we checked in each single-condition play env.
- All three at once, against walk-flat v2 (the condition picked in advance): 9 of 15 held against 0 of 15 (one-sided p = 0.0003). Mid-episode resets over the 15 takes: 9 against 80.
- 25 mm step, normal grip (friction 1.0), no shoves, against walk-step: 10 of 15 against 13 of 15 (two-sided p = 0.39). No measurable loss; walk-mix trails by three takes, a small-sample hint at most.
- Doubled shoves every 3 to 6 s on a flat floor (the same layout with 1 mm platforms), normal grip, against walk-push: 10 of 15 against 9 of 15 (two-sided p = 1.0). No loss.
- Foot friction 0.2 with the maker's shove (±0.3 m/s every 0.5 to 1 s) on the 1 mm layout, against walk-slip: 11 of 15 against 3 of 15 (two-sided p = 0.0092). No loss. We do not read this as walk-mix beating walk-slip on slippery floors: 3 of 15 is low for walk-slip on the condition it trained for. Same checkpoint, same friction and shove; what differs from walk-slip's own takes (8 of 15 on a plane, random walking commands) is this batch's fixed straight-ahead command and the generated 1 mm floor. We re-ran walk-slip with each change on its own: 7 of 15 on its plane with the fixed command, 6 of 15 on this floor with random commands. So walk-slip shows no regression; the 3 is a low draw on the harder of the setups (against the 21 of 45 it held over the other three sets, two-sided p = 0.079). Against walk-slip's best set, 11 of 15 against 8 of 15 is p = 0.45: no difference we can measure.
The same caution applies to the shove line: walk-push held 14 of 15 at doubled shoves every 3 to 6 s on its own plane, 9 of 15 here. Some rival takes had a mid-episode reset with the duck still upright (10 resets in walk-flat v2's takes in the first condition, one each for walk-slip and walk-push). Counting a take as held when its only events were such resets moves one count, walk-push to at most 10 of 15, still two-sided p = 1.0; walk-mix had none.
Not tested: steps above 25 mm or stepping up onto a platform as a scored event, friction below 0.2, shoves above ±0.6 m/s, slopes or rough ground, 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-01h-walk-mix) carries the reward curve, the queue item, the fork files, every take log and the two walk-slip re-run batches. Sibling policies: witcheer/microduck-*. walk-flat stays the default walk; walk-mix is the one-policy candidate for floors with a step, a slippery patch and the odd shove.
Simulation only.
- Downloads last month
- 5