Microduck policies: install, export and publish ONNX behaviours

How Microduck policies work: the seven shipped moves, ONNX export, Hugging Face publishing, robotctl commands and how to install community moves safely.

Oct 19, 2026

Microduck robot mid-motion with an abstract policy trajectory

Short answer: a Microduck policy is an ONNX file trained in simulation and loaded by the robot at 50 Hz. Slots hold the behaviours the robot runs by default; skills are named one-shots. You can load a gait, add a community skill, reset to the official set, or train, export and publish your own without rebuilding the robot software.

The useful mental model is not “one program per trick”. It is a shared observation contract with interchangeable controllers. Every published policy receives the same 61 values and returns the same 14 joint targets, which is what lets the runtime hand the robot from walking to recovery to a one-shot and back.

Slots, skills and the seven moves

robotctl policy list prints two tables: slots and skills. A slot is what the robot runs by default in a mode, such as the walking network or a standing network. A skill is something the robot runs when asked, such as a kick, a bow or a short trick.

Concept	What it means	Example
Slot	A named default controller the robot returns to	`walk`, `stand`, `sitstand`
Skill	A named behaviour requested for a duration	A four-second bow or a kick
Official set	Policies published and versioned by Pollen Robotics	`pollen-robotics/microduck-policies`
Community policy	A policy published by another Hub user	A search hit under `microduck`

The seven moves you drive are policy behaviours, not a folder of canned animations. The official published set also contains supporting entries for recovery, ground pick and sit/stand, so do not assume the number of .onnx files must equal seven.

The policy contract

Contract item	Current value
Observation	61 values: 48 proprioception values plus twist, head pose and body pose commands
Action	14 joint targets
Control rate	50 Hz on the robot
File format	ONNX
Normalizer	Baked into the ONNX graph during export
Manifest	Schema 2 for a single-policy repo or the official set
Robot check	Wrong width, robot model or daemon API version is refused before load

The contract is deliberately stable. A policy trained for one terrain can be swapped for another without changing the client or the motor bus. The authoritative details are in the policy manifest documentation and the RL repository.

What a manifest tells the robot

A manifest.json is how the robot knows what a file is before it runs it. The fields that matter most are:

Field	Why it matters
`obs_len` and `action_len`	Must match the robot's 61-to-14 contract
`robot.model`	Prevents loading a policy for a different robot
`model_api`	Refuses a policy that needs a newer daemon
`name`	The name a skill answers to
`kind`	`episodic` returns on its own; `perpetual` holds until stopped
`duration_s`	How long an episodic skill runs
`unwind_s`	How a held policy is brought back safely
`slot`	Which default slot a perpetual gait belongs in
`command.encoding`	Whether the daemon feeds a constant twist, a phase or a posture flag

Only a constant-command episodic policy can be installed as a general one-shot. A phase-driven ground pick or a posture-flag sit/stand belongs in the slot the daemon drives, not in the generic skill table. This is enforced by the robot, not by a naming convention.

Install a skill from the Hub

Search first, then add the policy by repository name. The robot downloads it, reads the manifest and creates a named skill:

robotctl policy search microduck
sudo robotctl policy add polite-bow fffiloni/microduck-polite-bow-b1d864
robotctl robot do polite-bow

The robot must be driving for a skill to run. Press Start on the pad first; the deadman can keep the twist at zero while the one-shot runs, so you do not need to hold a stick.

For a policy that holds until told otherwise, give it a duration and the command it expects:

sudo robotctl policy add flamingo RemiFabre/microduck-flamingo-cycle --hold 5 --command 1,1,0

Community policies are not verified by Pollen Robotics. What makes them safe to try is the shape check, the joint clamps and the fall response, not the description on the Hub. Put the robot on a stand for the first run and keep it away from a table edge.

Load a different walking policy

A policy loaded into a slot replaces the default gait and survives a reboot:

sudo robotctl policy load walk /home/microduck/my_walking.onnx
sudo robotctl policy load walk RemiFabre/microduck-flamingo-cycle
robotctl policy reset walk

If the robot is walking when the load begins, it returns to its home pose, swaps the policy and drives again. If it is sitting or standing still, the swap happens without moving the robot. A failed load keeps the policy that was already running.

Use robotctl policy check to see whether the official set has moved, then sudo robotctl policy update to install the newest release. A slot you loaded yourself is left alone because it points somewhere else. The policy section of the robot cheat sheet is the canonical command reference.

Train and export your own policy

The training stack is built on mjlab with MuJoCo Warp and PPO. A CUDA GPU is the practical requirement for local training; Hugging Face Jobs is the alternative for a machine without one. The training repository documents the full recipe, including actuator modelling, domain randomisation and the sim-to-real gap.

git clone https://github.com/pollen-robotics/microduck_rl
cd microduck_rl
uv sync
uv run train Mjlab-Velocity-Flat-MicroDuck --env.scene.num-envs 4096
uv run scripts/export.py Mjlab-Velocity-Flat-MicroDuck --wandb-run-path <entity/project/run>

Always export through scripts/export.py. The exporter bakes the observation normalizer into the ONNX graph; a hand-converted checkpoint can look correct and still send unnormalised observations to the network at runtime.

Before calling a policy finished, run it in the simulator, then in CPU MuJoCo, then on the robot with the duck on a stand. “It scores well” is not the same as “it stands up, recovers and stops safely”.

Publish a policy to the Hub

The RL repository has a publisher that writes a conforming single-policy repository from an ONNX file or a training checkpoint:

uv run publish --onnx output.onnx \
  --repo <your-user>/microduck-polite-bow \
  --kind episodic --duration-s 4.0

uv run publish --onnx walk.onnx \
  --repo <your-user>/microduck-my-walk \
  --kind perpetual --slot walk

An episodic policy runs for its duration and returns itself to a safe pose, so it can become a skill. A perpetual policy holds until told otherwise; a gait needs a slot, while a held pose needs an unwind time when installed. The publisher validates the observation/action shape and runs a smoke check before uploading. A preview video is optional but useful: policy search looks for a clip beside the description.

For the official set, publishing is four steps: upload the ONNX to pollen-robotics/microduck-policies, add an entry to its manifest, tag the revision, then run robotctl policy update on a robot. The official repository, not a blog post, is the formatting authority.

Test, reset and stay safe

Use this order for any new policy:

Read the manifest. Check robot model, shape, API and kind.
Test in the simulator. Try the movement at the edge of its training distribution.
Put the hardware on a stand. No table edge, no pets, no hands inside the legs.
Load or add. Watch robotctl health while the policy is running.
Keep the official policy reachable. robotctl policy reset is the way back.

If a staff member or a community author suggests ignoring the shape gate or writing motor commands outside robotd, treat that as unsafe advice. The architecture deliberately makes one daemon the only process that reaches the motor bus. See Microduck software architecture for why that boundary exists.

Licensing and provenance

The robot software and RL code are Apache-2.0. The simulation STL meshes are separately licensed CC BY-NC-SA 4.0. A policy's ONNX weights can have their own provenance and licence, so check the model repository before commercial use or redistribution. “The code is Apache-2.0” is not a blanket licence for every downloaded behaviour.

Microduck policy FAQ

Do I need to restart Microduck to change a policy? No. The daemon loads or swaps an ONNX policy while the service keeps running. A failed load leaves the previous policy in place.

Can I use a custom Microduck policy commercially? The robot and training code are Apache-2.0, but a policy is a separate published artefact and may carry its own licence or provenance. Check the model repository before using it commercially.

Can I modify an official Microduck policy? Yes, the software stack is open source. Keep the official slot available so you can reset it, export through the official script so the observation normalizer is baked into the ONNX, and test the result in simulation first.

What file shape does the robot accept? The current runtime expects one observation vector of 61 values and one action vector of 14 values, at 50 Hz. A file without that shape is refused before it replaces the running policy.

Where can I find community policies? Search the Hugging Face Hub with robotctl policy search microduck. Community policies are not verified by Pollen Robotics; put the robot on a stand and test away from a table edge.

Where to go next

How to train Microduck - the full sim-to-real workflow
Microduck simulator - run policies without hardware
Microduck Python SDK - connect, read state and command a policy
Microduck software architecture - daemons, IPC and the control loop
Microduck moves - the seven behaviours explained
Documentation - the complete technical index
Microduck RL on GitHub - training code and tasks