What Is Microduck?
Microduck is a tiny biped robot duck, about 25 cm tall and 800 g, built by Pollen Robotics, the robotics team at Hugging Face. The repository is, in the project's own words, the duck's brain: everything needed to run a Microduck, from the control loop to the update machinery that gets new software onto the robot without bricking it.
What it does reads like a toy list and a robotics demo at the same time. Pick up a gamepad and drive it around. Put wheels on and it rolls in roller mode. It picks things up with its beak, kicks a ball, sits down, and quacks in a voice that is its own. Knock it over and it stands itself back up. That last trick is the one that tells you this is not a remote-controlled toy with a duck shell on it. Getting back up is a learned skill, not a scripted animation.
The numbers explain the attention. The repo passed 10,000 GitHub stars within months of its July 2026 debut, with over 1,300 forks, and it is Apache 2.0 licensed, so anyone can use, modify and build on it. If you want the physical duck, the project points you to its own page. If you want the brain, it is all here.
It Taught Itself to Walk
Microduck did not learn to walk by being programmed step by step. It learned in simulation, using reinforcement learning, and the training lives in a sibling repository called microduck_rl. There, policies are trained with MuJoCo and PPO, with domain randomization to close the gap between simulation and the real world, and then exported to ONNX, the format this repo loads and runs.
That division of labor is the whole design. One repo trains the policies. This repo runs them. On the robot, a 50 Hz control loop drives fifteen servos from those neural policies, alongside the radios, the camera and the update system. Roller mode works the same way: ask for it and the duck loads the other brain, the one trained for wheels instead of feet.
Training in simulation first is also why a duck this small can be this capable. A real robot that falls over thousands of times while learning would break. A simulated one just resets. By the time a policy reaches the hardware, it has already fallen over, gotten up and tried again more times than any physical duck ever could.
Under the Hood: Rust Daemons on a Rockchip
The robot runs on a Rockchip RK3566, and the software is Rust with no framework, one workspace, a handful of daemons that each own one job. robotd owns the control loop and the motor bus. updaterd installs signed releases and rolls them back when a robot comes up unhealthy. configd owns wifi and identity. btd is the Bluetooth path a phone uses. padd reads the gamepad. mediad streams the camera over WebRTC. tofd serves the depth sensor.
They all talk over one JSON-RPC contract on Unix sockets, and every client sends exactly the same calls: the app, the console, the gamepad, your script. That uniformity is a deliberate choice. It means there is no special privileged path into the robot. If you can drive it from the app, you can drive it from a script with the same calls.
Updates get the same care as movement. Every update is verified, health-gated and reversible: install, roll back, pin. A bad release does not brick a duck, it gets rolled back. The project writes its interesting decisions down in its design docs, and its project docs record what has gone wrong and what would close it, which is the kind of honesty that makes an open-source hardware project worth building on.
What It Can Do on Your Desk
Start with the obvious: walking. Pair a gamepad, drive the duck around, and it walks. Then the party tricks, which are really capability demos. Roller mode swaps the walking brain for the rolling one. The beak picks things up off the floor on one button press. It kicks a ball. It sits. And when you knock it over, it gets back up by itself, which never stops being satisfying to watch.
The owner's cheat sheet covers every robotctl command: drive, configure, voice, chorale, theremin, wifi, updates and logs. Yes, chorale and theremin are on that list. A robot duck that can sing in a choir and play a theremin is exactly the kind of detail that tells you the team building this is having fun, and that the platform is flexible enough to allow it.
Control is not limited to the gamepad. duckctl drives the robot from a laptop over Bluetooth, with no network and no ssh. And if you do not have a duck yet, the simulation runs the real daemons against a body in MuJoCo, one duck in a window or four as machines you log into, so you can develop against the same software the hardware runs.
Get One, or Build on It
If you want the physical robot, the project page is the place to go. If you already have one, the docs are organized by what you are trying to do: the cheat sheet for everyday commands, the gamepad guide for pairing a pad and its full button mapping, duckctl for laptop control, and the updates guide for installing, rolling back and pinning releases.
If you want to build on it, the doors are all open. The training repo has the MuJoCo and PPO setup, the sim2real recipe and the ONNX export. The architecture doc puts the whole system on one page, the daemons, the bus, how an update reaches a robot, and then goes a page per part. The dev board guide takes you from a blank board to a robot running branch builds, and the dev cheat sheet covers branch builds, release candidates, driving from a laptop and the restart traps after an update. Push your branch over ssh and it installs in about a minute.
The honest summary is the README's own: no duck was harmed in the making of this robot. Several were consulted. What you get is a small, real, open-source biped that learned to move the modern way, with software you can read, run and change.
