The DENTIST BUILD REPORT - Stories from the undergraduate home front




This design revolved around two very special components, a second generation Toyota Prius motor and accompanying motor controller. Why do you need a car motor? Very good question! The answer is essentially that no one makes consumer/hobby motors in the 50kW range. They just don’t. Because then they’re car or airplane motors. The truly best single motor for this design is revealed later, but the first stab we took happened to be the Prius motor. Additionally, Nick Kirkby, a MITERS alumnus, had gone and hacked at a Prius motor before, so we were fairly confident we could get this particular motor to spin for our purposes.

We bought the whole Prius Hybrid Synergy Drive (the hybrid part of the Prius) from a junkyard for $250. That includes a big and small Prius motor (MG2 and MG1 respectively), gear train, and aluminum casing. A major motivation for choosing the Prius over some other motor was in fact the cheapness of the parts and availability at junkyards. Here’s a lovely picture I stole from the wikipedia page on it:

image goes here

For our purposes, we used the MG1, or smaller motor, which is reported to be a 33 kW motor spinning at 8,000 rpm according to Oak Ridge National Laboratories(1). That would be geared up to a theoretical 16,000 rpm at the drum. The motor itself was quoted at “27 lbs” (minus housing, wires, and everything else, which we discovered later).

The main fancy feature of this motor is the fact that it’s a brushless motor. Combat robotics has a deep love for brushed motors because there’s no real need for control - modulating the input voltage up and down is all you need. For brushless DC motors, like this one, and like a good number of Hobby aircraft motors, higher power density, higher torque per watt, and no brushes to wear out makes them much better motors than traditional brushed DC motors. But due to their design which requires more advanced controllers, sometimes sensors and microcontrollers to go and crap themselves in the middle of battle, they’ve only slowly made their way into combat robotics. Because of their superior weight-to-power ratio though, they are first choice for a high power weapon motor like ours, and also what we believe is the next wave in combat robotics. The motor is also quite “pancakey” - that is having a large diameter versus its width. This makes the motor have more torque compared to a similar power motor. Getting the slowest speed/highest torque motor we could find would make the gear ratio smaller, thus making the gears lighter in the end.


To turn a motor this powerful, you need an equally powerful controller. The Prius Motor met its match with the Prius Controller (affectionately named the Prius Brick), which is a fancy two-for-one deal motor controller. It has one 400A, 1200V side and another 200A side for both motors inside of the Prius. The brick also comes with auto-overcurrent shutoff protection, and was also previously reverse engineered by some lovely people and firmware developed by the wonderful Bayley Wang Bayley Wang using STM Nucleos and a few choice resolver-to-encoder IC’s. It’s a beast of a motor controller, and is one of the few controllers ever in Battlebots to feature IGBTs over MOSFETs.

Being in a robot, we couldn’t afford water cooling but picked the next best thing - heat sinking to an ice box and still theoretically perilously running our motor controller for a mere 5 minutes before it would have stopped functioning. The original controller sat in a beautifully sealed aluminum box, far too large for our weight-concious baby I mean robot.

Prius Brick Stats (approx):


Theory is hard, practice sucks. One of the first problems we ran into was mounting. Our first attempt was awful, as we tried to machine a custom mount out of billets of aluminum. Unfortunately a picture doesn’t exist, but imagine three 2x4 billets of aluminum, precariously holding two plates together where a rotor and stator were precariously mounted inside. Only the gentlest of breezes, minor tremors, or coughs would upset their delicate alignment, causing the motor to crunch sadly.

It worked well enough for benchtop testing, but the mounting required careful tapping and squeezing to keep everything aligned. It would never have worked in a combat robot. //Landon: It also took about 4 days to make of entirely one-off manually-machined components, so making a spare was impossible under the time constraints.

Our second idea for mounting was to carve out part of the aluminum casing holding the motor such the stator and rotor would have perfectly Toyota-manufactured alignment. The best way to get that one part was to sawzall off part of it, and then shave down the rest of the mount on a mill.

image goes here

Michael, in a heroic effort, shaved off 13 lbs of aluminum chips. The motor and case weighed 47 lbs, after shaving.

Now, in a 250 lb robot, 47 lbs of motor is 47 lbs that isn’t armor, isn’t frame, isn’t battery, or any other part of the robot. 47 lbs of motor means everything else on the robot is weak in exchange for an absurdly heavy weapon motor.

On top of that, the Prius brick was extra heavy, coming in at 6 Pounds, plus 2 pounds of water cooling and 7 pounds of film capacitor. Running at 220V plus a drive pack, we had 12 4Ah 6S LiPos making 16 pounds of battery. And this is all electrical weight - the whole rest of the robot needs weight to. We were quickly running out of weight.

We tried a lot of different designs to try to fit this heavy-ass motor and heavy-ass electrical system into a 250lb CAD model. We switched to titanium, then switched back to aluminum, turned side armor into swiss cheese - lots of desperate engineering. But in the end the designs became too strained, time was running short, and decided to drop the Prius motor from the design.

Prius Motor Stats:



  1. Oak Ridge National Laboratory as part of their research takes apart foreign cars and examines their innards. As part of this you can find their reports for the Prius, along with specs, graphs, and so on online. The MG1 motor is referred to as “the generator” in these reports.
  2. View all buildlog entries