XGO-Duck: Open-Source Bipedal Robot

What is XGO-Duck & why did it catch our eye?

XGO-Duck is an open-source bipedal robot created by Luwu Dynamics that pairs 3D-printed mechanics with reinforcement learning locomotion. Running on the hybrid Qualcomm and STM32 architecture of the Arduino Uno Q, it replicates dynamic bipedal balancing, somersault recoveries, and beak manipulation using 15 serial bus servos without requiring proprietary enterprise robotics hardware.

Most viral robotics demos on social media leave builders with severe buyer frustration. You watch a sleek video of a charming tabletop biped, check the link in the bio, and discover an exclusive waitlist, a closed proprietary API, or a four-figure enterprise research price tag. When the viral Microduck concept from Pollen Robotics surfaced earlier this year, everyone wanted one on their desk, but few teams had access to physical hardware.

When our team at ZeroShot Studio saw Luwu Dynamics drop the XGO-Duck repository, we immediately stopped what we were doing. Luwu Dynamics did not just publish a stylized CAD shell; they released a complete open-source hardware and software pipeline. The project provides printable 3MF and STL files, a custom expansion board PCB layout with an on-board IMU, a clean bill of materials, and trained neural network policies that run directly on edge silicon.

What hardware specs power the robot under the hood?

Under the hood, XGO-Duck splits its compute workload across an application processor running Linux and a real-time microcontroller managing high-speed serial bus communications. The core compute engine is the Arduino Uno Q, which integrates a Qualcomm QRB2210 host processor with an STM32U585 microcontroller on a single compact footprint.

The 15 Feetech bus servos provide the degrees of freedom needed for authentic bipedal motion. Each leg packs multiple servos for hip yaw, roll, pitch, knee flexion, and ankle compensation, while additional actuators drive neck tilt, head rotation, and beak gripping. Because each servo carries an internal 12-bit magnetic encoder with 0.088 degree resolution, the control system reads exact joint angles in real time rather than guessing positions blindly.

The DIY factor: Can you actually build and mod it?

We evaluate every piece of hardware in our Hardware zone through a ruthless maker lens. Can a single developer or small studio source the parts, print the structure, solder the board, and write firmware without running into vendor lock-in?

With XGO-Duck, the build pipeline is remarkably approachable:

1. Clean 3D Print Profiles: The structural parts do not require industrial SLS or resin printers. Luwu Dynamics tuned the tolerances for desktop FDM printers running standard PLA or tough PETG. The models include pre-oriented build files that fit on standard 256 mm build plates.
2. Standard Sourced Fasteners: The fastener list is fully specified in the documentation. You need M2 × 6 flat-end self-tapping screws, M2.3 × 8 flat-top screws, M3 × 16 machine bolts, and standard 10 × 15 × 3 mm and 16 × 22 × 4 mm sealed bearings.
3. Open Gerber and Fabrication Files: The expansion board is not a secret black box. The repository includes complete schematic drawings and manufacturing BOM files for instant ordering via JLCPCB or PCBWay.

flowchart LR
    Host["Qualcomm QRB2210 (Debian Linux)"] -->|Internal Bridge| MCU["STM32U585 Coprocessor"]
    MCU -->|1 Mbps TTL Serial| Servos["15x Feetech Bus Servos"]
    IMU["QMI8658A 6-Axis IMU"] -->|I2C Telemetry| MCU
    Host -->|Local Wi-Fi / WebSockets| Agent["OpenClaw / Coding Agent"]

The split architecture between Linux and the real-time MCU is the real architectural win here. If your high-level Python code stumbles or an experimental policy throws a division-by-zero error, the underlying STM32 coprocessor continues serving safe watchdog routines to prevent the servos from stripping gears.

How does it hook into coding agents and vibe coding?

The most exciting shift in embedded robotics is using autonomous coding agents to develop physical behaviors. When we work with tools like Cursor, Claude Code, and OpenClaw, we do not spend three days writing custom serial byte parsers. We point the agent at the hardware protocol and let it scaffold clean integration drivers.

Because XGO-Duck exposes an asynchronous runtime over local Wi-Fi via xgoduck_runtime_arduino, you can command behaviors, inspect joint telemetry, and trigger reinforcement learning policies from Python scripts.

Here is a minimal telemetry client harness we tested for pulling real-time IMU attitude and joint angles into an agent loop:

# Real-time telemetry inspector for XGO-Duckimport timeimport requestsROBOT_HOST = "http://xgo-duck.local:8080"def get_duck_telemetry():    """Query live IMU and servo telemetry from the on-board runtime."""    try:        response = requests.get(f"{ROBOT_HOST}/api/telemetry", timeout=1.5)        response.raise_for_status()        data = response.json()                imu = data.get("imu", {})        servos = data.get("servos", [])                pitch = imu.get("pitch", 0.0)        roll = imu.get("roll", 0.0)                print(f"[telemetry] Pitch: {pitch:.2f} deg | Roll: {roll:.2f} deg | Active Servos: {len(servos)}")        return data    except requests.RequestException as err:        print(f"[telemetry] Connection error: {err}")        return Noneif __name__ == "__main__":    for _ in range(5):        get_duck_telemetry()        time.sleep(0.5)

The machine learning layer in xgoduck_rl is equally clean. Motion policies are trained using Proximal Policy Optimization (PPO) in NVIDIA MuJoCo and mjlab. Once a policy learns to stabilize against external shoves, recover from a backflip, or pick up a foam block, the neural network weights are exported to ONNX format. The Qualcomm chip on the Arduino Uno Q executes the ONNX graph locally, feeding target angle vectors to the joint controller at fixed 50 Hz intervals.

What is the catch before you order parts?

No maker build is without friction. Before you fire up your 3D printer or place component orders, keep these real-world constraints in mind:

• Component Sourcing Lead Times: While the 3D-printed parts take roughly 24 to 36 hours of print time, sourcing 15 Feetech HD-1910-C001 serial servos and the Arduino Uno Q will require shipping from specialized suppliers or international distributors.
• Battery Safety and High Peak Currents: Bipedal balancing produces aggressive current spikes. When all 15 servos counter a sudden wobble, total current draw can spike over 5A. You must use high-discharge 18650 cells rated for at least 3C with a dependable battery management system.
• Tolerances and Calibration: 3D printer calibration matters significantly. If your printer over-extrudes by even 0.2 mm, the bearing pockets and servo brackets will bind, causing joint friction and overheating the servos during balance loops.

What are we building with it next in the lab?

At ZeroShot Studio, we treat hardware platforms as physical nodes in our agent ecosystem. We are integrating XGO-Duck into our workshop automation pipeline across three experiments:

1. Desk Sentinel Agent: Pairing the duck with our local OpenClaw on a VPS setup so the physical robot acts as a physical desk notification avatar, nodding on successful automated deployments and physically shaking its head when a test suite fails.
2. Vision-Guided Object Retrieval: Mounting an edge camera module to explore autonomous micro-cleanup tasks, using local quantized vision models to find and retrieve dropped hex keys from the workbench.
3. Interactive Coding Skills: Authoring a companion skill package in our resources directory that allows coding agents to generate novel gaits and choreographies through conversational prompting.

FAQ

Can I build XGO-Duck with a standard Arduino Uno or Raspberry Pi? The mechanical frame can technically be adapted, but the software stack is designed around the hybrid architecture of the Arduino Uno Q. The Uno Q combines a 2.0 GHz quad-core Qualcomm chip running Debian Linux with an STM32 coprocessor for low-latency servo bus timing. A standard microcontroller lacks the RAM and compute to run ONNX reinforcement learning policies, while a standalone Raspberry Pi lacks the real-time deterministic hardware timer coprocessor.

What filament is recommended for printing the mechanical parts? PETG or ABS/ASA is strongly recommended for structural joint brackets and servo housings due to heat resistance and layer adhesion. Standard PLA works well for cosmetic shell pieces like the head, beak, and decorative tail covers.

Do I need a GPU workstation to train the robot policies? No, unless you want to invent entirely new motion behaviors. Luwu Dynamics provides pre-trained ONNX locomotion checkpoints in the repository for walking, rolling, getting up, and object grasping. You can load those pre-compiled policies straight onto the robot without running local MuJoCo training passes.