Instructions to use witcheer/microduck-walk-step with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- Microduck
How to use witcheer/microduck-walk-step with Microduck:
sudo robotctl policy load walk witcheer/microduck-walk-step
- Notebooks
- Google Colab
- Kaggle
walk-step
Walk on flat ground with +-1 deg of gear play in every servo, fine-tuned for single steps: walk-flat v2 plus 3,000 iterations (7,000 to 10,000) on a floor that is flat except for one 1.5 m platform 10-25 mm high per 4 m tile (our one-change fork Mjlab-Velocity-Flat-Backlash-Step-MicroDuck), 4096 envs, 64 min on one RTX 5090. It has no terrain scan and meets the step blind. Trained in simulation only. In 20 s takes walking straight ahead over a 25 mm step with no shoves it stayed on its feet in 11 of 15 takes against at most 5 of 15 for walk-flat v2; on the same layout at 1 mm with shoves 10 of 15 against at most 7 of 15. 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-step
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-14)
What changed: one thing, the floor. Pollen's Mjlab-Velocity-Flat-Backlash-MicroDuck trains on an infinite flat plane. Our fork Mjlab-Velocity-Flat-Backlash-Step-MicroDuck swaps it for a generated floor that is flat except for one raised square per 4 m tile: a 1.5 m platform whose top sits 10 to 25 mm above the floor (drawn per tile), with 2.5 m of flat floor between platforms. Every edge crossing is a single step. Rewards, terminations, pushes, 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 fork is a separate task file registered by one import line in tasks/__init__.py. The maker's own rough-terrain task also softens terrain contacts and raises solver iterations; this fork does not, to keep one variable.
Training: warm start from walk-flat v2 (model_7000), 3,000 more iterations (7,000 to 10,000), 4096 envs, 64 min on one RTX 5090 (about 1.28 s per iteration), one uncut block. Mean reward over 100-iteration windows: 93.5 at 8,000, 93.5 at 9,000, 95.1 at 10,000 (flat from 8,000); fell_over 0.864, 0.850, 0.808 over the same windows. The velocity tracking error rose from 0.340 in the first window after the resume to 0.468 in the last.
Proof takes with headless_play in the step task, walk-step against walk-flat v2 under identical settings: 20 s each, standing start on a platform, the walking command fixed straight ahead at 0.3 m/s (play otherwise samples random commands and a take can miss the edge entirely), samples every 0.1 s, every platform forced to 25 mm. 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).
- 25 mm step, no pushes: 11 of 15 held against at most 5 of 15 for walk-flat v2 (one-sided Fisher exact p = 0.033). walk-flat v2 fell in the edge band (0.65 to 1.15 m from the platform centre) in 9 of the 10 takes it lost.
- 25 mm step with play pushes every 0.5 to 1 s: 5 of 15 against 2 of 15 (p = 0.19, not a result on its own). With pushes this often both policies mostly fall, and walk-step still had an edge-band fall in 6 of 15 takes.
- Both step conditions pooled: 16 of 30 against at most 7 of 30 (one-sided p = 0.016).
- Control, the same layout at 1 mm with pushes: 10 of 15 against at most 7 of 15 (two-sided p = 0.46). No loss without a real step. walk-step holds slightly more here too, not significantly, so part of the gain on the step may be general sturdiness under pushes rather than a step skill.
"At most": on a generated floor the task ends an episode when the robot leaves the tile grid, and a single-env take starts in an edge column, so a few takes ended early with the duck upright. That hit walk-flat v2 only (2 takes in the no-push step case, 3 in the control, none for walk-step). Those takes are counted as held for walk-flat v2, which can only flatter it; the counts above are the conservative ones.
The clean signal is the no-push step: walk-flat v2 falls at the edge, walk-step mostly walks down it.
Not tested: walking up a step (no take of walk-step reached the next platform, 2.5 m away), step heights other than 25 mm and 1 mm, any command other than straight ahead at 0.3 m/s, slopes or stairs, more than 20 s, a second simulator, and a real robot. The higher training tracking error means it may follow speed commands less closely than walk-flat v2; the takes do not measure that. Not yet tested on a real Microduck.
Clip and run log: the microduck-skill-tree dataset (folder level-01e-walk-step) carries the reward curve, the queue item, the fork file, the side-by-side clip and every take log. Sibling policies: witcheer/microduck-*. walk-flat stays the default walk; walk-step is the variant for a floor with a step in it.
Simulation only.
- Downloads last month
- 15