Disney’s BDX droids — the small, expressive, bipedal robots that debuted walking around theme parks — were never meant to be something you could build yourself. OpenBDX is the open-source, community-driven attempt to change that, documented in detail on Make: by project lead Jaime Machuca, who credits Mimir Reynisson (hardware, firmware, runtime, and the reinforcement-learning side) and Florian Bieregger (mechanical redesign of the CNC leg parts) as core collaborators.
The hardware stack
This isn’t a simplified hobbyist version — it’s a genuinely serious robotics build:
- Actuators: Unitree A1 motors at the knee and hip (pitch and roll), Unitree Go-M8010-6 at the ankles, hip yaw, and neck pitch, plus Dynamixel XH540 (head) and XC330/XL330 (antennas)
- Compute: two Nvidia Jetson Orin NX modules, one in the chest and one in the head, linked over Ethernet
- Control board: “PuddleDuck,” a custom Teensy-based chest board bridging USB to six RS485 motor buses
- Sensors: a BNO085 IMU plus depth cameras for visual odometry, SLAM, and a dedicated chest/head camera pair
- CAD: designed in Shapr3D, on an iPad
Walking is a trained policy, not hand-coded motion
The “learning to waddle” in the project’s own framing is literal. The gait runs on PPO (Proximal Policy Optimization) reinforcement learning, trained in simulation using MJLab, Isaac Lab, and Isaac Sim for sim-to-sim verification before anything touches real hardware. The policy follows polynomial animation references generated by the team’s own gait-authoring tools, rather than learning a gait from nothing — so the walk keeps a designed “personality” instead of converging on whatever stiff, efficient motion a reward function alone would produce.
Training adds a curriculum: random pushes, rough terrain, and recovery behavior, plus domain randomization across weight, friction, and motor response — standard sim-to-real techniques meant to make a policy robust to exactly the kind of small mismatches between simulation and the real world that usually break a transfer. The trained policy takes a 76-value observation and outputs 14 joint actions, gets exported to ONNX, and runs directly on the robot’s onboard Jetsons. The team reports the transfer worked: behavior on the physical droid tracked closely with what the simulation predicted.
A whole internal toolchain, not just a robot
What’s notable about OpenBDX beyond the robot itself is the tooling built around it: OpenBDX Studio with Gait Forge for designing walking cycles, Duckmation for authoring emotes/expressions, WaddleScope (a browser-based MuJoCo simulator anyone can poke at without owning hardware), and Paint Booth for previewing paint schemes before committing to a physical build. There’s no public GitHub repo for the project — interested builders are directed to openbdx.org, where new accounts (via GitHub sign-in, no invitation required) unlock the full build guide: 149 assembly steps and 304 unique BOM items, per the site’s own numbers.
Why this is a notable creative-hardware project
Most open-source robot replicas stop at “here’s how to build the mechanism.” OpenBDX ships a full simulation-to-hardware training pipeline alongside the mechanical build — meaning a builder isn’t just assembling a kit, they’re inheriting an entire RL development environment for tuning or extending the droid’s behavior afterward. That’s a meaningfully higher ceiling than most maker-robotics projects offer.
Related Reading
- OpenBDX Duck Robot: Learning to Waddle — Make:
- OpenBDX — official build community site
- A Raspberry Pi, an ESP32, and a Magnet Under the Board Are Running This Ouija Séance — our coverage of another hobbyist build with a serious software stack underneath
- TinyML: Getting Started With Microcontroller Inference — our tutorial, relevant background for running trained models on embedded hardware