What makes the duck move?

One interface, different behaviors.

Walking reads a velocity command. Posture and phase-driven skills use some of the same slots for different meanings. A matching observation layout does not make policies interchangeable across physics models: roller policies need passive wheels. The published catalog includes the command recipe, source revision and matching morphology for each network.

These networks do not receive images or object labels. The player lines up with objects; the app supplies task logic and bounded named requests. The policy controls the motion.

Inspect the network you just tried.

Download the script above and run it in a new folder. It checks the policy against this Space’s release manifest and saves its pinned source and license record alongside the ONNX file.

python quickstart.py --policy walk --output ./microduck-policy

# Optional: verify the network interface with ONNX Runtime
python -m pip install onnxruntime
python quickstart.py --policy rough-walk-e --output ./rough-walk

The optional check uses an all-zero synthetic observation to verify shape and finite output. It does not drive a robot, emulate a task or prove policy quality. Do not replay its output as motor commands.

The observations are normalized inside the exported ONNX. Applying an extra normalizer changes what the network sees. The official runtime also owns action scaling, joint order, command encoding, timing and handoffs; inspecting a network is only one part of using it correctly.

Compare what you observe.

1. Pick a world and drive a short route with Alpha walk.
2. Use “Sample 10 simulated seconds” and download the practice note.
3. Try Rough walk, return to the same scene and repeat a similar route.
4. Compare observed policies, mean speed and approximate path length. Record falls and task outcomes yourself if those matter to your question.

The Space integrates sampled speed over simulated time. Pauses stop that clock; a model or world switch, invalid reading or long sampling gap cancels the sample. Human inputs, starting pose and contacts can differ across runs, so this is an exploratory practice note rather than a controlled benchmark. Your note remains in the tab until you download it.

From your ONNX export to a duck you can drive.

1. Export a MicroDuck legs walking policy with the repository’s scripts/export.py path. It bakes observation normalization into the ONNX. Preserve the shared 61-observation / 14-action layout, command block, joint order, 50 Hz timing and unfiltered actions.
2. Return to the Space’s Build your policy loadout button. In the scene’s terminal, choose the file, name it, add a semantic version and training source, and confirm embedded normalization.
3. Choose Validate + equip. A compatible file is saved in this browser and wrapped in an equipped brain with the supplied skills enabled. An invalid file is refused before a new brain is selected.
4. Under Your policy keys, assign your new brain to a key from 1–9, and bind other keys to supplied skills. Close the terminal and press a key or tap its hotbar button. Use Legs, start a run and confirm your policy’s name in the live Controller reading. Click inside the scene and drive with WASD, arrows, touch or a gamepad.
5. Try sitting or kicking, then return to walking. Those skills have their own supplied controllers; your uploaded network drives walking. Reopen the terminal and choose Equip the factory walker to restore the default brain.

Accepted files have one float32 input obs [1, 61] and one action output actions [1, 14], at most 16 MiB. Initialization has a 12-second budget, followed by warm-up and a finite zero-observation inference within 50 ms. Dimensions alone do not establish that a controller has the right morphology or command semantics. A roller or episodic trick export cannot be used as a walker merely because its shapes match.

The file stays in browser storage for the Space’s origin and is never sent through the workbench’s message bridge. It is not published to the public Space or asset Bucket. Reloading can restore the selected brain; clearing site data removes it. The full app has a separate browser library. To use the policy there or keep a private account copy, import the same ONNX in Trainer HQ.

A finite rehearsal checks basic runtime compatibility, not task quality or hardware readiness. Watch actual simulated rollouts and retain measured evaluation evidence before promotion.

Build a brain, then train a candidate.

Trainer HQ combines policies into a brain and provides account-based private imports and demonstration records. The native repository supplies MJLab environments, PPO training, ONNX export and CPU deployment rehearsal. Hosted GPU Jobs depend on the app’s live capability flag and explicit cost approval.

# In a clone of github.com/reachjalil/nottyduck:
uv sync
uv run list-envs

# After checking GPU availability, smoke-test before a long run:
uv run train Mjlab-Velocity-Flat-MicroDuck \
  --env.scene.num-envs 64 --agent.max_iterations 5

# Export your trained run using the repository’s normalizer-aware path:
uv run scripts/export.py Mjlab-Velocity-Flat-MicroDuck \
  --wandb-run-path <entity/project/run_id>

# Rehearse your walking export in CPU MuJoCo:
uv run scripts/infer_policy.py --walking <exported-policy.onnx>

Read the repository’s training guide and task registry before running a job. The smoke test requires a supported GPU setup and consumes compute; this page does not start it. Evaluate actual rollouts before promotion. Simulator evidence and physical robot validation are separate records.

From solo practice to Duck Lounge.

Join Duck Lounge on the full app to play as MicroDuck alongside other visitors. Multiplayer runs on nottyduck.com and may require sign-in. The public Space is your solo first taste and policy workbench; it links into the same product.