The detail that surprised me most: the duck walks backward across the carpet while wearing larger rectangular pinkish pads instead of its usual small footplates, swaying its weight from side to side and tipping torso and head as it goes. It even appears in two different foot configurations.
Under the shell, the project runs on an Arduino UNO Q, a board that carries two processors at once. A Qualcomm Dragonwing QRB2210 handles Debian Linux, earmarked for policy inference, perception, logging and higher-level behavior. Alongside it, an STM32U585 runs Arduino sketches atop Zephyr and takes the time-sensitive work: sensor and actuator interfaces, command validation and watchdog logic. Training happens off-board in simulation, with the board reserved for deploying the trained policy. The planned flow sends observations up to Linux for inference, passes action targets down to the microcontroller, and from there out to the actuators.
There is a playful target too: the maker wants the duck to kick a small ball one day. A yellow accent band around the head and a neck joint linking head to torso give it plenty of character.
What stands out is the honesty about limits. The processor separation won't by itself crack sim-to-real transfer or ensure steady walking, and latency, observation timestamps, control rates and missed-command behavior all still matter. The split is an intended approach rather than a finished implementation, and whether a given policy runs fast enough on the board still needs benchmarking. The maker is also asking the community where the boundary between the policy runner and the controller should sit, and whether to send joint targets straight over or push more control logic onto the microcontroller.