A 25 cm, 800 g robot duck whose movements come from reinforcement learning.
Why everyone is talking about this duck
Recently, a small yellow robot has been showing up across the robotics community. It can walk, kick a ball, pick things up with its beak, recover after a fall and even roller skate.
This is Microduck, a biped robot from Pollen Robotics. Its software stack and reinforcement learning tools are open source. The original robot uses 15 motors and an RK3566 main controller, with learned policies handling its movements.
The official browser sandbox lets anyone try a digital Microduck online. We wanted to take the idea one step closer to real hardware by putting motion control and vision on an actual RDK X5.
What we built
The project combines cloud simulation, edge motion control and BPU vision.
Browser ↔ Cloud GPU server ↔ RDK X5
The browser displays the scene and sends commands. MuJoCo provides the robot model and physical simulation. RDK X5 runs the 50 Hz ONNX locomotion policy and uses its BPU for DOSOD ball detection.
The policy takes IMU and joint observations as input, then outputs motor targets. The vision pipeline processes the duck’s camera feed, finds the ball and lets the board decide how to turn and approach it.
What it can do
The current system can
- walk and run at adjustable speeds
- turn in place
- kick a ball 2.9 metres without falling
- crouch and stand up
- perform a forward roll
- pick up objects with its beak
- recover within about two seconds after being pushed over
- detect and chase a ball automatically with BPU vision
Why the control loop belongs on the board
Our first version sent control across the public internet. A round trip of around 50 ms was enough to make the robot unstable. Dynamic balance does not tolerate that kind of delay.
We also trained a latency tolerant policy on an RTX 5090, randomising actuator delay between 60 and 120 ms. It could walk, though its reactions were noticeably slower.
The better answer was to keep the time critical 50 Hz control loop on RDK X5. The board handles the policy, behaviour and recovery logic locally, while the cloud side focuses on simulation, rendering and visualisation. The same control code can later move to a physical robot by replacing simulated sensor input with data from the motor bus and IMU.
A few engineering lessons
- The observation vector must match training exactly. A single misplaced index can make the robot fall.
- The BPU input path expects an NV12 NumPy array. Passing raw bytes can silently produce meaningless output.
- A yellow duck on a yellow floor is surprisingly hard to see. A cooler background made detection much more reliable.
- Control commands need a heartbeat. Sending only state changes means one dropped packet can leave the robot waiting indefinitely. A 25 Hz heartbeat made delivery much more dependable.
Help us build the next version
The duck can already walk, recover and chase a ball. There is plenty left to explore.
We would love to see developers build on this project with RDK X5. Possible directions include richer BPU perception models, person and gesture recognition, obstacle perception, multi camera vision, new locomotion policies, real servo and IMU integration, mechanical designs and better sim to real workflows.
You do not need to build the whole robot to contribute. A converted model, a servo driver, a printable joint, a new behaviour or a detailed record of a failed experiment can all help the next developer.
Start with the open source projects below, share your progress in the forum and tell us what you would like this duck to learn next.
- Microduck software
- Microduck reinforcement learning tools
- Microduck browser simulator
- RDK X5
- Original Chinese community post
Let’s build the next generation of RDK powered ducks together. 