I Built Disney’s Star Wars Robot

Added: 2026-05-12

[00:00:00]This is my homemade version of Disney's viral  Star Wars robot. And yes, it can actually walk.

[00:00:05]But I didn't program it to do that. It actually  taught itself how to walk. Over the past 2 years, these characters from Disney research have been  blowing up the internet. And the second I saw them, my brain said, "I have to build one." Now,  I did have Disney's research papers and videos as a reference, but there's a massive gap between  seeing how it works and me actually building it myself. No... You see, for the longest time,  building a robot that walks on two legs was one of the toughest challenges in engineering.  But lately, things have changed. Thanks to a technique called reinforcement learning, this  kind of tech is finally becoming accessible.

[00:00:38]And if I can figure this out with some  motors, a 3D printer, and a decent GPU, it really opens the door for what's possible for  anyone willing to put in the work. And lately, over the past year, I've been putting this  all together. And today, I'm going to show you exactly how I did it. from building the robot  to getting it to learn to walk in simulation and finally how I was able to make it walk in  the real world. Firstly, let's start with the hardware and what we already know about the  BDX droid. If you've played Jedi Fall in Order, you'll recognize this little guy as a cousin to  BD1. But this isn't just a video game character anymore. Disney Research built this to be a fully  autonomous walking actor. In fact, it's even set to appear in the new Mandalorian movie coming out  later this month. To make it walk, Disney designed each leg with 5° of freedom, so 10 for the legs  in total. Then you've got the upper body. There's one actuator in the neck and three in the head.  Lastly, there is also an actuator in each ear. So, for starters, I knew I needed 16 actuators. Disney  uses high-end actuators from Unitry and Dynamixel, but as you can imagine, they're priced for  industrial budgets. Replicating that build 1:1 would cost over $7,500 in actuators alone.  Since I wanted to keep this build accessible without sacrificing quality, I needed a better  alternative. If you watched my last video, you know I did a deep dive into these Robstride  Quasi direct drive motors. They give me that same high torque performance as the motors Disney used,  but for a fraction of the cost, bringing the total to all 16 actuators down to just around $2,800.  Three different kinds of actuators were used in my build based on torque and size requirements.  For the brain of the robot, which is responsible for controlling the actuators, I've chosen the  Jetson Orin Nano because it's the exact PC that Disney uses, and it's both extremely powerful and  affordable. To power the whole robot, I've decided to go with a 40 volt lithium ion lawn mower  battery. It's much safer than building my own, and it was already surprisingly affordable.  The last thing I needed was an IMU. Basically, this sensor tells the robot exactly how it's  tilted and how fast it's rotating in 3D space.

[00:02:31]This is how the robot is able to know its  orientation and see if it's starting to fall over and has to correct itself. Now that the  actuators and these three components were chosen, we can begin to build the robot. I 3D printed the  whole thing out of PETG with high infill. It's cheap and fast, but I severely underestimated the  strength of these motors. These 60 Newton meter motors I chose are extremely powerful. Over  and over again, I continuously broke the 3D printed hip roll joint as this is the joint  that has to fight against gravity the most.

[00:02:58]My plastic parts just couldn't handle the stress.  I'd finish an assembly, try to get it to stand, and it would just snap. She just That's That's a  snap, right? I ended up reprinting and rebolting these hip connectors more times than I'd like to  admit. It became pretty clear that plastic just wasn't going to hold up. And this is where the  sponsor of this video comes in, JLC CNC. They are a trusted CNC machining partner that offers fast,  affordable, and high precision custom parts for makers and engineers like myself. And honestly,  this was my first time ever ordering custom CNC parts, and I was surprised at how easy it was.  I was able to easily export my designs from CAD and upload them directly to JLC CNC. You get  factory direct efficiency with an instant quote, and you can actually get custom CNC parts starting  at just $1 with no hidden setup fees. I chose to get the hip roll connections made out of aluminum  so that it would be light and never break again. I also ordered an aluminum base plate for the head  as the current size didn't fit on my 3D printer.

[00:03:53]Because they offer fast turnaround times, the  parts arrived in as little as three business days.

[00:03:57]Opening the box honestly felt like Christmas.  The 3 to five axis precision is incredible, and the parts matched my design specifications  perfectly. If you want to get your next CNC part made starting at just $1, JLC CNC also offers new  registered users up to $123 in coupons through the link in the description. It's easily one of the  best upgrades I've made to this robot. With the frame now reinforced with these aluminum parts,  the mechanical build was complete. The next step was getting it to move. Now, historically, if you  wanted a bipedal robot to walk, you had to perform inverse kinematics, manually solving complex  physics equations to plot out the trajectory for every single joint. It wasn't necessarily,  per se, impossible, but for a solar builder, it was incredibly timeconuming to get right.  So, instead, I followed where the industry is going toward reinforcement learning. Instead of  programming the robot how to walk, I let it figure out itself. I dropped my robot into a simulation  where it starts out completely clueless, just trying random movements, falling over and  trying again. Every time it does something good, like staying balanced or moving forward, it  gets rewarded. Fall over, punished. At first, it's awful. But over time, it starts to figure  out what actually works. And because this is all happening in a computer, I can train not just  one robot, but thousands at the same time. So, what would take years in the real world happens in  just a few hours. But first, in order to do that, I had to bring my robot into the digital world.  So to do that, I took my CAD model and turned it into a digital twin using a URDF file, which is  one of the standard formats for defining robots in simulation. It basically describes everything  the simulator needs to replicate the robot. The mass of each link, the position and orientation  of every joint, the joint limits, and how powerful each actuator is. Once that was set up, I could  finally drop my robot into the simulation and begin training. To train my robot to walk, I  used the framework called MJ Lab, a combination of Nvidius Isaac Lab and Mujoko, two of the most  widely used simulation tools for robotics. I owe a massive shout out to Louisis Lule for showing  me the ropes with this. Without his help, it would have taken me much longer to get the robot  walking in the simulator. Now, when it comes to getting a robot like this to walk in simulation,  there are a few different approaches. Disney uses imitation learning where the robot learns  from reference motion, often guided directly by professional animators who essentially act out  the movements for it to copy. But unfortunately, I don't have access to anything like that. So  instead, I use pure reinforcement learning where the robot learns entirely through trial and error  based only on rewards and penalties I define. In reinforcement learning, what I'm actually training  is called a policy, which is essentially the brain of the robot that decides what to do at any moment  based on sensor input. To create that policy, I had to define a few key components. Inputs,  outputs, rewards, penalties, terminations, and a curriculum. The inputs are the data the  policy learns from to make decisions. In my case, the policy runs at 50 Hz, meaning it reads sensor  data from the robot and outputs new motor commands 50 times every second. For locomotion, the  inputs generally include projected gravity, which tells the robot its orientation relative  to the ground, and angular velocity from the IMU.

[00:06:58]While some robots use base linear velocity data,  that's not always readily available without complex filtering. And fortunately, the robot can  walk just fine without it. On top of the IMU data, we use joint encoders for the position and  velocity of every motor, plus a velocity command. And this is essentially the speed I want  the robot to walk at, whether that's forward, backwards, side to side, or rotating. The final  input to the policy is called the last action, which is simply the previous set of motor commands  the policy output. This gives the robot a bit of memory between time steps so its movements stay  smooth. Once all of these inputs were defined, I set up the rewards and penalties. It's actually  quite a simple concept. I give the robot a reward if it behaves the way I want and a penalty  if it does something unwanted. For instance, I reward the robot for tracking the velocity  command, lifting its feet to a certain height, and staying upright. I penalize it for hitting  joint limits, using excessively high torqus, or slamming its feet into the ground. To make it  easier for the robot to learn, I also introduced a curriculum. At the beginning of training, the  robot only has to learn to walk at slow speeds.

[00:08:00]As training advances, we increase the velocity  requirements. Lastly, I added terminations, which basically reset the training if the robot  falls over, so it learns to avoid that behavior entirely. Now that everything was set up, I  could finally begin to train my robot to walk in simulation. Once the training was finished, I  had a policy that walked perfectly in simulation.

[00:08:21]But moving that to the real robot is a massive  challenge called sim tore. The real world is messy with friction, motor delay, and unpredictable  terrain. To fix this, I use domain randomization.

[00:08:32]I essentially forced the robot to train in a  chaotic, noisy environment. I randomly changed the robot's mass, added noise to the IMU and  encoder data, randomized the floor friction, and even added latency to the motors. If the robot can  learn to walk through that chaos in the simulator, the real world feels easy. When it comes to  deploying a trained policy on real hardware, I highly recommend running some safety checks first,  unless that is you want to break your robot. I learned this the hard way. I had a few joints  with the wrong clockwise direction and others where I'd accidentally swap the joint order, like  sending an ankle command to the knee. Even the IMU orientation can be a trap. If I lean it forward,  see, it falls backwards in Sim. So that direction is flipped. If the robot thinks up is down, it's  going to do some pretty violent things. Now, in order to reduce the chances of this actually  happening, I created a hardware abstraction layer. This allowed me to test my walking policy  on my computer using the exact same code I'd eventually run on the actual robot. And after  fixing those initial bugs, I finally saw motion that actually looked like walking, and it was  incredibly rewarding. That said, the walk still wasn't perfect. As you can see in the footage,  the robot was clearly favoring its right foot, behaving differently than it did in the sim. After  watching Skyific's recent video on his own walking robot, I saw he was graphing his motor positions  to compare sim versus reality. I wanted to do the same. I took two of my leg motors and built the  test setup to run a chirp signal, essentially just a sine wave with increasing frequency on both  the real motor and a simulated one. By comparing the response graphs, I was able to tune the motor  delay and the rotor inertia until the simulation finally matched the real world hardware. After  this, I then retrained the policy with these new accurate motor values, and the difference was  night and day. The walk became more symmetric, and the robot could finally walk forward,  backwards, and even turn on command. Seeing it walk in the real world for the first time  felt like watching a child take its first steps.

[00:10:23]All that hard work over the past year had finally  paid off. Another thing I love about reinforcement learning robots is they can learn to recover  from being pushed at least most of the time.

[00:10:36]Again, really this entire process of bridging the  gap between simulation and real world hardware was actually the focus of my bachelor's  end project. I wrote a paper on creating a blueprint for accessible bipedal robotics.  And after a lot of work, I was proud to walk away with a 9 out of 10. So now I have my very  own walking Star Wars robot. But honestly, getting it to walk is only half the story  because the real magic is in making it feel alive. This is where Disney is honestly  on another level. They don't just focus on movement. They focus on character. Things like  sound, LEDs, and expressive antenna movements, what they call show functions, are what turn  a robot into something that feels intentional, not just mechanical. Now, I've already started  adding some of these ideas into my own build.

[00:11:17]And the next step for me is to push that further  with proper emote behaviors and more refined gate control. So it starts to feel less like a machine  and more like a character. Now this project is fully open source. So if you want to dive into the  code, explore the CAD or build your own version, everything is linked in the description. And while  the full version is still quite expensive, there's also a smaller version you can build for under  $400. And there's already a growing community around it. Now, if you've enjoyed the build,  consider subscribing. I've got a lot more planned for this guy in the near future. And thanks  for watching and I'll see you in the next one.