# XGO-Duck, a 3D-printable biped duck and what the hardware files do and do not cover > The xgoduck_hardware repository holds the mechanical models, PCB sources, bill of materials and assembly guide for a 15 servo biped duck built around an Arduino UNO Q. It is explicitly a learning and testing revision, and the README carries a board correction that affects anyone who already owns one. **LuwuDynamics/xgoduck_hardware** — Build your own robot duck. XGO-Duck is a 3D-printable biped powered by Arduino UNO Q and 15 servos, adapted from Pollen Robotics' Microduck. Includes mechanical models, PCB designs, a BOM, and an assembly guide. Build it, explore its motion, and make it your own. - Repository: https://github.com/LuwuDynamics/xgoduck_hardware - Website: https://www.xgorobot.com - Stars: 1,279 · Forks: 164 - Language: Unknown - License: not declared - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/luwudynamics-xgoduck-hardware ## What the hardware repository actually contains XGO-Duck is a duck shaped biped robot adapted by Luwu Dynamics from Pollen Robotics' Microduck. The hardware repository is the physical starting point: print the parts, prepare the electronics, assemble the robot. The README is explicit that it is the hardware side of a three part project, with the onboard runtime and the reinforcement learning tools living in companion repositories. What sits in the tree matches that scope. There is an Assembly_Guide.pdf, a BOM.md, a PCBA/ directory holding the expansion board files, a structure/ directory with the models, a docs/ directory, and media/ for the images. COMMUNITY.md, CONTRIBUTING.md, LICENSING.md, ROADMAP.md and UPSTREAM.md round out the top level, which tells you that the project expects contributions, tracks a roadmap, keeps attribution to the upstream Microduck, and separates licensing questions into their own document. The actuator count and the controller are the two numbers that define the machine: fifteen Feetech 1910 serial servos and an Arduino UNO Q. The servos break down as 10 leg joints, 4 neck and head joints, and 1 mouth joint, while the structure is delivered as STL parts, with TPU designated files for the foot soles and the mouth parts. One detail matters for anyone reading the joint numbers: the motion policy outputs targets for 14 joints, and the mouth servo is controlled separately. Fifteen servos, fourteen policy outputs, one mouth. ## Two processors split the work between policy and actuation The Arduino UNO Q is doing two jobs at once, and the README separates them cleanly. The board is described as a Linux host for policy inference and the web UI, and as an STM32 microcontroller for servo and sensor communication. Both halves are used in the flow. The browser side handles setup, calibration and control, talking to the Linux side that holds the ONNX policy and the web UI. A training computer runs the simulation and reinforcement learning work and exports an ONNX policy to the host. From there a link called the Arduino Bridge connects the Linux side to the STM32 side, and the STM32 runs the servo and IMU loop over a serial bus to the fifteen servos. The QMI8658A six axis IMU feeds acceleration and angular velocity feedback back into that microcontroller. The expansion board carries the physical side of that: power distribution, servo connections and IMU integration. The README calls the diagram a functional overview and points you to the board design and assembly documentation for the electrical connections, which is the right instruction, because the diagram shows signal flow and not pin assignments. The architectural consequence is worth naming. A trained policy is not what makes the robot move; the policy emits joint targets that the STM32 loop then drives out over a serial bus. Policy quality and hardware timing are separate concerns, and the repository only covers the second one. ## The old boards have GND and SIGNAL reversed on three connectors The most consequential line in the README is a dated correction, and it is worth reading before anything else in this repository. The hardware correction is dated 2026-10-02. The old ArduinoUnoQ PCB reverses GND and SIGNAL on U3, U4 and U5. Owners of previously manufactured boards are told to disconnect power and follow the old-board wiring instructions in PCBA/README.md. Pin 2 power is unchanged, and the schematic and PCB sources have been updated. This is exactly the kind of issue that hardware projects carry and software projects do not, and it is a real limitation for anyone buying parts from a previous run or joining the project later. The fix is documented, but the burden falls on the builder: a board assembled from the earlier sources may route power and signal into the wrong pins on three connectors. There is a second, broader warning attached to the whole revision. The README marks the hardware revision as being for learning and testing only, and states that PCB fabrication for mass production is not recommended. For a hobby build that is an acceptable constraint. For anyone hoping to spin up a run of boards, it is a clear boundary set by the project itself rather than an inference on our part. ## Power handling around the servos is a safety matter The README carries a warning box with two instructions, and the second one is mechanical rather than electrical. The first is electrical: never connect or disconnect servos while powered, disconnect power before plugging or unplugging servos, and avoid stalling them. With fifteen servos on a shared serial bus, plugging one in live risks the servo and the board together, and a stalled servo can drag current that the power path is not sized for. The second warning covers the scope of the hardware: the revision is for learning and testing only, and PCB fabrication for mass production is not recommended. Both sit at the top of the README rather than buried in the documentation, which is the right place for them. For a builder, this shapes the order of operations. The battery pack in the bill of materials is listed as an 18650 battery 8.4V, with a charger that has a 5.5 by 2.1 mm DC barrel plug, so the correct sequence is to finish the mechanical build, wire the board with power disconnected, and only then energise the system. The README asks you to confirm the pack, charger, connector polarity and power requirements using the component notes in docs/BOM.md before sourcing or powering the build. ## The bill of materials separates the robot from the finished board The purchasing list in the README is a robot bill of materials, and the repository makes a point of distinguishing it from the PCB manufacturing BOM. The finished expansion board already includes its board level components, so the two lists answer different questions and should not be merged. The quantities are given in full, including the screw counts, which is unusual and useful. The list runs to one Arduino UNO Q in either 2 GB or 4 GB, one robot expansion board, fifteen Feetech 1910 servos, fifteen AMP three pin servo cables, the 8.4 V battery pack, the charger, then the fasteners and bearings: 200 M2 by 6 countersunk flat end self-tapping screws, 6 M2.3 by 8 flat top round head flat end self-tapping screws, 4 M3 by 16 round head machine screws, two 10 by 15 by 3 mm bearings and eleven 16 by 22 by 4 mm bearings. The fastener section is where the README spends the most attention, and the reason is a genuine trap. It asks you to identify the three fasteners before ordering, notes that items 7 and 8 are self-tapping screws with flat ends, and points out that items 8 and 9 share the same rounded side profile while differing in the top: item 8 has a flat top and item 9 has a gently domed top with a machine thread. The shape guide is labelled illustrative, and a photo is supplied as a head style reference rather than a size or thread specification. The BOM also has a fastener identification section to point to. Buying by that description, with parts sorted by thread type rather than head shape, is the difference between an assembly that goes together and one that does not. ## The structure directory stops short of documenting its own naming scheme The build instructions point you to the structure/ directory for the models, and add a promise that the filenames carry useful assembly information. The README then shows a table of filename patterns and their meanings, and the file we can read stops there, cut off mid-table. That truncation matters in a small but concrete way. The naming scheme is described as a feature of the repository, and the table is where you would learn it, but the pattern meanings are not in the visible text. What can be said is what the surrounding documentation establishes: the structure is delivered as STL parts, the body, leg, neck and head components are STL, and separate TPU designated STL files cover the foot soles and the mouth parts. The topic list on the repository also includes 3d-printing, and the media directory shows a prototype with printed parts, articulated legs, a movable head and beak. So the honest summary for a reader is that the printable structure is well covered by the file listing and the assembly guide, while the filename pattern table remains the piece of documentation to check in the repository itself before sorting parts for printing. The Assembly_Guide.pdf and the images in media/ are the places to look for what the finished joints are meant to look like, and the README also says the photos show project prototypes, so you should follow the assembly guide and the matching board files for your own build revision. ## Printing it yourself versus buying the upstream Microduck The upstream project is named in the README and in UPSTREAM.md. XGO-Duck is an adaptation of Pollen Robotics' Microduck, and the difference between the two paths is the difference between a build project and a purchase. The upstream Microduck is a ready made product. Taking that route means you receive assembled hardware and spend your time on the behaviour, which is exactly the part that the companion runtime and reinforcement learning repositories are built for: configure and calibrate the robot through the runtime's browser interface, study the simulation, train policies, explore your own motions, and export the resulting ONNX policy to the host. Printing and wiring the XGO-Duck yourself means you get a machine whose structure, board and firmware you can modify, and you can follow the workflow of the three column table the README presents, print, run, experiment. You also take on the parts list, the printing, the fastener identification problem and the board revision issue described above. The two are not equivalent for a first project. The hardware repository is the deeper commitment and the more instructive one, while the purchased robot is the faster path to the same simulation and training workflow. ## Conclusion Adopt xgoduck_hardware if you want a duck that you print, wire and program yourself and you are comfortable with a hardware revision that the README marks as unsuited to mass production. Do not adopt it as a base for a commercial PCB run, since the project states that fabrication for mass production is not recommended, and do not order boards from the earlier revision without reading PCBA/README.md, because the old ArduinoUnoQ PCB reverses GND and SIGNAL on U3, U4 and U5. Verify first that the fifteen servo positions line up with the joint map in the BOM notes, then confirm the fastener types against the shape guide before ordering screws. ## FAQ ### What hardware does the XGO-Duck robot use? XGO-Duck uses fifteen Feetech 1910 serial servos, split as 10 leg joints, 4 neck and head joints and 1 mouth joint, an Arduino UNO Q as the Linux host and STM32 controller, a QMI8658A six axis IMU, and a custom Luwu UNO Q expansion board for power distribution and servo connections. ### How many joints does the XGO-Duck motion policy control? The motion policy outputs targets for 14 joints. The mouth servo is the fifteenth servo and is controlled separately from the policy. ### Is it safe to plug a servo into the XGO-Duck board while it is powered? No. The README warns to never connect or disconnect servos while powered, to disconnect power before plugging or unplugging servos, and to avoid stalling them. ### What is the hardware correction dated 2026-10-02 in the xgoduck_hardware repository? The old ArduinoUnoQ PCB reverses GND and SIGNAL on U3, U4 and U5. Owners of previously manufactured boards are told to disconnect power and follow the old-board wiring instructions in PCBA/README.md, pin 2 power is unchanged, and the schematic and PCB sources are updated. ### Where do I get the software for the XGO-Duck robot? The hardware repository points to two companion repositories: xgoduck_runtime_arduino for the onboard runtime with its browser interface for setup, calibration and control, and xgoduck_rl for the simulation and reinforcement learning tools that train policies and export them as ONNX. ## Sources - [Issues](https://github.com/LuwuDynamics/xgoduck_hardware/issues) - [LuwuDynamics/xgoduck_hardware on GitHub](https://github.com/LuwuDynamics/xgoduck_hardware) - [Project website](https://www.xgorobot.com) - [README](https://github.com/LuwuDynamics/xgoduck_hardware/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/luwudynamics-xgoduck-hardware