Go to OpenBDX.org and register to get the full files and build guide!
The first time I saw Disney’s BDX droids was at Nvidia GTC in March 2024, in San Jose. Moritz Bächer was presenting Disney Research’s “Design and Control of a Bipedal Robotic Character,” and Disney brought three droids onto the conference floor: Besh (blue), Grek (green), and Oskar (orange).
They were the most lifelike robots I had ever seen, but what made them remarkable was not that they performed a task. It was that people immediately treated them like characters. Within seconds, the crowd stopped seeing motors and control loops. They saw droids with personality. I remember thinking that these droids would be incredible for children’s hospital visits or troop appearances with the Star Wars costuming groups I am part of, and like almost everyone who sees them, I wanted one. Unlike most people, I was crazy enough to try building one, and I was not alone.
The Disney paper became the map. It showed enough about actuation, mechanical design, and control strategy to make an open build feel possible, while leaving plenty of practical details unresolved.
The Start of OpenBDX
Up to that point, the droid builder community had understandably focused on recreating them as affordably as possible. My instinct was to reduce unknowns first: follow the known-good hardware direction, prove the system, and optimize later. The project was already complex enough without adding more complexity on top. The easiest place to start was the mechanical design.
As a software engineer with no mechanical design background, I needed a way to design the legs around the same actuators Disney outlined in their paper. I needed something approachable, but still precise enough for real mechanical work. Shapr3D ended up being the perfect find: it runs on the iPad, uses the Pencil naturally, and made CAD feel much less intimidating.
That first mechanical version started as my attempt to turn the paper into something real, but the project quickly became bigger than one person. In June 2024, I went to DroidCon in Indianapolis and met Mimir Reynisson, another builder who had already been pushing hard on his own version of the droid. He had a moving version, had designed PCBs that allowed Nvidia Jetsons to communicate with the motors, and had also built a head PCB to control the eyes, lamp, sounds, and ear servos.
Meeting Mimir made it clear that this could become more than a one-off replica attempt. The project needed mechanical design, electronics, firmware, software, simulation, animation tools, and a build process other people could follow. No single person was going to cover all of that well.
With my background, I naturally focused on the ROS side: robot description, camera interfaces, visual odometry, mapping, object detection and tracking, SteamDuck control from the Steam Deck, and the bridge into Mimir’s PuddleDuck runtime. Early on, though, those pieces were secondary. The first priority was getting BDX to walk stably. Mimir led much of the hardware, firmware, runtime, reinforcement learning, and web tooling work, including OpenBDX Studio, Duckmation, GaitForge, and Waddlescope.
Later, when the printed leg parts started showing weaknesses around the A1 motors, Florian Bieregger joined at exactly the right moment. With his mechanical engineering background, he began redesigning the CNC leg parts, work that grew into the current full mechanical redesign and build guide.
BDX Anatomy
Visually, OpenBDX may look like one more Star Wars droid, but mechanically it is closer to a real-world humanoid. That makes it much more complex than a typical astromech-style build: it has to balance, shift weight, coordinate leg motion, and still feel like a character. Each leg has five degrees of freedom: hip yaw, hip roll, hip pitch, knee, and ankle. The foot does not have a separate ankle roll joint, so the angled foot pad helps compensate mechanically. The upper body adds four more degrees of freedom for neck pitch, head pitch, head yaw, and head roll, plus two small servos for the antennas.
The main leg actuators follow the Disney-inspired hardware direction: Unitree A1 motors for the knee, hip pitch, and hip roll, and Unitree Go-M8010-6 actuators for the ankles, hip yaw and neck pitch. The head uses Dynamixel XH540 servos, with 12V or 24V options, and the antennas use XC330 or the newer XL330 servos.
Compute is split between two Nvidia Jetson Orin NX modules, one in the chest and one in the head, connected over Ethernet. That is more compute than the walking policy alone needs, but it leaves room for perception, mapping, state estimation, navigation, and more advanced behaviors without disturbing timing-critical control.
One of the main components is PuddleDuck, a custom chest board designed by Mimir. It uses a Teensy microcontroller to bridge USB from the Orin to six independent RS485 motor buses, while also handling audio amplifiers, NeoPixel lighting, IMU connections, I2C, CAN, and R/C input options through SBUS or serial radio. That gives the software a clean path to command the motors and read feedback needed for control.
Feedback comes from a frame-mounted BNO085 IMU, the actuators themselves, and onboard cameras. The robot uses depth cameras for visual odometry and SLAM, with additional chest and head cameras available for perception work. In the current walking stack, the policy receives a 76-value observation and outputs 14 joint actions, which PuddleDuck sends to the actuators while reading fresh motor feedback back into the Orin.
The Walking Policy and Training
The hardest part of this project was never making a droid that looked right while standing still. It was making a droid that could move like a character without falling over.
That is where BDX is very different from most droid builds. With an astromech, a human operator can directly pilot the base and trigger animations on top. With a small biped, that doesn’t work. Fourteen joints have to be coordinated continuously. A person with a remote control cannot directly puppeteer that many motors in real time while also keeping the robot balanced; frankly, most of us have enough trouble managing our own joints. The operator can choose where the character should go and what kind of pose or expression it should make, but the robot has to solve the joint motion itself.
The Disney paper pointed us toward the right idea: use an animation reference motion, then train a control policy that can follow those references while still reacting to the real physics of a walking robot. In OpenBDX, we train walking policies in simulation using reinforcement learning, primarily with MJLab and PPO, and we have also trained policies in Isaac Lab that transferred successfully to the physical droid. The training setup uses polynomial imitation references generated from our own gait-authoring tools, then progresses through a curriculum that adds pushes, variation, rougher terrain, and recovery behavior. It also uses domain randomization, varying things like weight, friction, motor response, and other physical parameters so the policy is not trained only for one perfect simulated robot. The goal is not just to make the robot step forward in a simulator. The goal is to produce a policy that can keep the droid balanced while still preserving the personality of the gait.
OpenBDX Studio wraps part of this workflow as Gait Forge, a Studio-facing workspace for our Automagerie gait playground. Gait Forge is used for tuning and previewing gait behavior against the selected BDX asset pack. Studio launches Automagerie with the current robot assets rather than maintaining a separate fork. That matters because the tools need to stay connected to the same robot description and motion assumptions that feed training and deployment.
Once trained, the policy is exported as an ONNX model. On the robot, that model runs on the chest Jetson Orin NX through the PuddleDuck runtime. Instead of commanding individual motors from the remote, the operator sends a compact command vector: forward and lateral velocity, turn rate, body height, head and neck pose, trunk posture. The policy receives that command vector along with IMU data, joint positions, joint velocities, recent actions, and motor target history. It then outputs the joint targets for the legs and upper body. PuddleDuck handles the timing-critical interface to the actuators.
This approach also gave us a way to make the droid feel alive while it was still being driven. Duckmation, another part of the OpenBDX ecosystem, creates emote scripts that feed into the same policy interface. These emotes are not fixed motor poses that take over the robot; they are layered on top of live control. Walking direction and turn rate stay under the operator’s control, while the emote can add head, neck, trunk, height, and antenna motion. That means the droid can keep walking or turning while an expression is playing. Assuming the policy can keep it upright, of course.
Before trusting the policy with an expensive droid, the team first checked it in simulation. We ran the policy in Isaac Sim as a sim-to-sim test, using that as another verification step before deploying it to the physical robot. When the policy moved from simulation to the robot, and after fixing some feedback issues and other bugs in the runtime, the transfer turned out surprisingly good. The robot behaved very close to how it behaved in simulation, which is exactly what you hope for and rarely get for free.
The first walking test for me happened on September 2025 after Mimir had done his first tests, before the CNC leg parts were finished and before the droid even had a head installed. It was an important milestone, but it still felt like a test rig proving a point.
The moment it really became real for me was Denver Fan Expo on May 2026. Mechanically the droid was finished and the walk was still unstable. We were obviously not done. But after months of CAD, electronics, software, simulation, broken assumptions, and mechanical redesigns, the droid was finally walking in the real world. It was no longer just a paper, a model, or a collection of parts. It was a character starting to come alive under its own control.
Duckmation: Making Motion Feel Alive
Walking is only part of what makes a droid feel alive. The other part is the way it looks around, reacts, shifts its body, flicks its antennas, changes its lights, or plays a sound at exactly the right moment.
That is the problem Duckmation is meant to solve. Not everyone building a droid is an animator, and not everyone has access to professional animation software. We wanted a tool that a builder could open, understand, and use to create their own emotes without needing to become a character animation expert first. It needed to stay simple, but still expose enough control to make the result look intentional instead of robotic in the bad way.
Duckmation gives builders a timeline for authoring those personality moments. An emote can include body height, body lean, body tilt, body twist, neck pitch, head pitch, head yaw, head roll, and antenna motion. It also supports non-motion cues such as sound, eye state, lamp state, and light bar commands. That means a scan, a happy dance, or a curious head turn can be treated as one coordinated performance instead of a pile of separate scripts. For builders who already have a preferred animation workflow, Duckmation does not have to be the only authoring path; compatible emotes can also be exported from other tools and played through the same system.
The preview matters as much as the editor. A movement that looks good as numbers in a file may look awkward on the actual robot. Duckmation uses Waddlescope, another tool in the OpenBDX ecosystem, to preview the animation on the selected droid model with the same asset pack and policy that would run on the hardware. The goal is to let someone adjust timing, easing, curves, and poses while seeing something close to what the droid will actually do.
When an emote is saved, Duckmation exports a runtime JSON file for the robot. Under the hood, that file is sampled into dense frames that the PuddleDuck runtime can play back. The important part is that those frames are not motor positions that bypass the walking system. They become command inputs to the same policy interface used for live control.
That is what makes the system useful on a walking character. The operator can still drive the droid while the emote plays. The walking direction, lateral movement, and turning stay live, while Duckmation layers expressive motion and show cues on top. A scan can happen while the droid is being guided through a room. A happy reaction can include head motion, antennas, sound, and lights without taking away basic control.
For OpenBDX, that is the difference between a robot that walks and a droid that performs. Locomotion gives it mobility. Duckmation gives builders a way to add character.
WaddleScope: Crash the Sim, Not the Robot
The more pieces a robot has, the easier it is to break something at the worst possible time. A walking policy might be good. An emote might be good. A Steam Deck control change might be good. But the real question is what happens when all of those pieces are connected to the same robot at the same time.
That is where WaddleScope fits into the OpenBDX pipeline. WaddleScope is a browser-based MuJoCo simulator and policy player for the droid. It can load the same ONNX policies used by the robot, the same robot asset packs used by the rest of the tools, and the same Duckmation emotes that run through the PuddleDuck runtime. It is the place where everything gets tied back together before we risk the physical machine.
For simple policy testing, WaddleScope lets us run the droid in simulation and see how the trained controller behaves. It supports click-to-goal navigation, where you click on the ground to give the simulated droid somewhere to walk. Internally, that gives us a practical way to test navigation commands without putting the physical robot at risk.
The more important use is integration testing. If I change the Steam Deck controls, I can check the behavior in WaddleScope before trying it on the robot. For example, I used it while changing how neck pitch up and down behaved. The same applies to more expressive control changes: if looking all the way to one side should also bring the trunk around at extreme joystick positions, WaddleScope gives us a way to see whether that layered command still behaves correctly with the policy.
It is also useful for Duckmation. An emote can be previewed on top of the live policy command space, so it is not just a floating animation disconnected from locomotion. You can see how a scan, head turn, or happy motion behaves while the droid is also capable of walking.
That becomes especially important for the broader OpenBDX project. Through the OpenBDX forums, people can share policies and emotes. WaddleScope gives others a way to preview those contributions directly on the site, even if they have not built a droid yet. Someone can design an emote, load it in the simulator, and see how it would behave on a real OpenBDX-style robot.
Simulation does not remove the need for hardware testing. The physical robot always has the final vote. But WaddleScope moves many mistakes earlier in the process, where they are cheaper, safer, and less likely to end with expensive parts making expensive noises.
OpenBDX: From Builder to Community
OpenBDX.org is now live as the hub for the project. Since launching on September 2, the site has grown to more than 1,300 registered, verified users, and at least 25 ducks are being built around the world using the current design.
The goal is not just to publish a pile of files and walk away. Builders can sign in with GitHub, create a profile, download STL files, get OpenBDX Studio, grab support files, and follow the build guide. The site also includes forums where people can share what they are making, download policies or emotes from other builders, keep a build journal, and compare notes as the design evolves.
Builders do not have to train their own walking policy to get started. OpenBDX provides known-working policies, and the community can share improved policies over time. Because the policies are trained with domain randomization, they are not tuned only for one perfectly identical robot. Small differences in weight, friction, motor response, and build variation are part of what the policy sees during training, which makes shared policies more practical across real-world builds. Someone building a droid can use an existing policy, preview it in WaddleScope, and only dive into training if they want to experiment with new gaits, hardware changes, or more advanced behavior.
The same idea extends beyond motion. OpenBDX also includes Paint Booth, a tool for experimenting with visual designs before committing to a paint scheme. Builders can try different looks, preview how they might feel on the droid, and share those ideas with the community. For a project this complex, even the visual choices become part of the collaboration.
That is the broader point of OpenBDX. Not everyone who wants to contribute needs to build a complete droid from day one. Some people may design emotes. Some may improve documentation. Some may test policies, create paint schemes, refine printable parts, write software, or help another builder get unstuck. The robot itself is the obvious focus, but the real project is the active ecosystem around it.
Disney’s paper showed what was possible. OpenBDX is our attempt to turn that inspiration into something builders can study, modify, improve, and bring into the real world together.
This article appeared in Make: Volume 99.
ADVERTISEMENT
