February 3, 2016

Motor Control Progress: Working Hardware, and a Field Oriented Control Implementation

Over winter break I finished EAGLE-ing up a first revision of motor control hardware, and sent out for boards from 3PCB first week in January.  This version is shaped like a Nucleo for ease of modification and debugging.  Once I get motor control stuff solid, I'll redesign it with the microcontroller on the same board.  

I'm using TI's DRV8302 chip-that-does-everything.  It has built in 3 phase gate drive (with configurable deadtime), 2 amplifiers for low-side current shunts (with selectable gain), and buck converter for your logic (just add your own inductor, capacitor, diode, and feedback resistors).  

I wasn't particularly aggressive with component-packing, but there's still lots of empty space on the board.  Layout turned out okay, but because of the unfortunate shape of the Nucleo I had to rout the PWM traces around the entire board.  Should be tolerable since they aren't super sensitive signals.


A week later, boards and a Digikey box appeared:


Here's an assembled board.  For FETs, I'm using these ones from NXP.  40V, 2.5 mOhm, 35.5 nC "100 Amp" logic level fets.  The TI-Everything-Chip is particularly awful to assemble by hand.  I did it with a nice Weller station and a microscope.    I found one mistake on the board, which was that I routed the gate drive enable pin on the DRV8302 to a pin that gets used by the Nucleo for other functions.  I cut the trace and jumpered it to a different pin.


Here's the bottom of the board, minus electrolytic bus caps.


I threw together a motor test jig out of scrap.  It's a random optical encoder coupled to the motor.  Eventually the giant encoder will get replaced with either a small optical encoder or a hall-effect based angle sensor (attractive for their absolute position sensing)


At this point I started working on the motor control stuff.  After much struggling, I've now become  a little more comfortable with STM32F4 register-twiddling.  

First thing was making sure the gate drive worked and getting center-timed PWM up and running.  I implemented a sinusoidal pwm block for my code, which I'll later replace with proper SVM for better bus utilization.  Hey, it works!



After adding some encoder code borrowed from my closed-loop subwoofer project I was able to do some voltage-mode commutation.  Here's the motor running under "voltage mode FOC", if you will.  Basically, at this point I could specify d and q axis voltages and do the appropriate (inverse) transforms to convert those to 3-phase motor phase voltages, but didn't  have the current transforms/control loops wrapped around everything yet:



Around here I observed some serious "crunchiness" in my commutation.  At first I thought it was something wrong with my sine generation, as it happened periodically at a multiple of electrical frequency, but it turned out to be a hardware issue.  Remember those PWM traces I had to route around the outside of the entire board?  Turns out, when two PWM edges aligned (meaning two switching events coincided), the extra noise introduced everywhere was enough to sometimes falsely switch the input to the gate driver.  This means that for small portions of each electrical cycle, the motor would draw more current and produce much less torque, since it was fighting itself.  Here's the scope freaking out at one such instance:


The fix was to add some capacitance on the inputs of the gate driver.  A tiny 0603 120 pF cap on each input completely solved the issue.  Fortunately, all three traces had a via directly by a ground plane, so the fix was very easy.  I think improved layout with a micro on the same board should also fix this problem.

Problem-solving caps circled in red

Next step was to get synchronous current sampling working.  Since I'm using low-side shunts for current sensing, the voltage drop across the shunt is only representative of phase current when the low side transistor is on.  The rest of the time there's no current through the shunt.  This means sampling of the current sense amplifiers must be synced with the PWM.  This has the added benefit of reducing switching-induced noise on the current signal.

Another day and a half of register-twiddling later, I got that figured out.  Top three traces are the high-side PWM duty cycles, and the bottom trace is the current sampling - in other words, toggle pin high (for timing only), sample both ADC's, do ADC conversions, toggle pin low.  


A close-up of the sampling period.  The cycle takes 400 ns, which means if it starts at the center the PWM alignment, I can get ~98% duty cycle at 20 kHz before the sampling period starts overlapping switching.


Here's  what a couple amps of phase current looks like, writing the value from the ADC straight to the DAC to look at it on the scope.  No filtering at all.  Pretty darn clean.


Now with proper current measurement, I could finish the FOC implementation and wrap current loops around everything.  I spent another day an a half trying to figure out why my current transformations (from phase currents to d-q axis currents) weren't behaving like I expected.

The symptom was that, instead of DC values for d and q current (while commanding constant d-q voltages),  I was observing a constant-amplitude sinusoid at the electrical frequency, for both d and q currents.  I was doing all my debugging on the oscilloscope, by writing signals to the DAC.  Everything looked right on the scope, so I spent a long time staring at my transforms to figure out where I had made a typo.  Then I actually printed some values to my computer over serial and quickly figured out the problem - a huge DC-offset in my current measurements.  I didn't see this on the oscilloscope, because the values written to the DAC rolled over and appeared to still be centered about zero.

The problem was in my current-zeroing method.  When the microcontroller powered on,  it averaged 1000 samples from both current channels, to find the zero-current offset.  The problem was that I was doing this before enabling the gate drive on the DRV8302.  Turns out, the enable pin enables both the gate drive and the current sense amplifiers, so my zeroing procedure was zeroing to a floating value.  Enabling gate drive and then zeroing fixed everything.

Here's a video with q-axis current displayed on the scope, with a constant q-voltage commanded.  As expected, it's a DC value in steady-state:



Sweet!  Now it was current control loop time. First step was to go and measure my motor's q and d axis inductance (assumed to be the same, since this is a surface permanent magnet motor).  To do this, I put a shunt in series with the motor, applied a voltage step to the shunt/motor (phase A positive, phases B and C grounded), measured the voltage rise time across the shunt, and used the total resistance and rise time to calculate inductance.  Here's a good reference for measuring motor parameters.

In this shot, turqoise is the voltage across the shunt (proportional to the current through the motor) and magenta is the voltage step (done by plugging in a power supply lead).


This came up with a synchronous inductance of ~33 µH.  With the d/q inductance and resistance, I could design a current loop.

I designed a discrete-time PI current controller for a 10 Khz sample rate.  I haven't (yet) been particularly aggressive with sample rate or controller design, so I could probably push crossover significantly higher.  The designed controller (used for both d and q axis currents) has a crossover at ~ 600 Hz with 56 degrees of phase margin.  This corresponds to (electromagnetic) torque bandwidth.


Here's what I expected the step response to look like.



And here's the actual q-axis step response, after implementing the controller.  Whoah, that actually looks like what I was expecting!  Response is slightly slower and more damped than expected, but results are pretty close.  I didn't even have to adjust my loop gains at all to get this response.  Thank you, 2.171.  I'd guess I either miscalculated a hardware gain somewhere or my inductance measurement is a bit off, or something like that.  As expected, I could likely push the loop a bit harder without needing to sample faster, to squeeze some extra torque bandwidth out (if I really need to).


Here's the motor doing ±.7 q-amp steps:


So what's next?  Well, first, the MultiStar Elite motors I loved in my motor roundup dropped down to $42.15 on Hobbyking (once you log in), making them a clear winner.  I've already got some more on the way for multi-dof leg building.

Motor control is not quite done.  I still need to do some more stress-testing to catch any glitches.  I also need to decide on a final position sensor soon.  Small optical encoders can be had cheaply, but I don't like the necessity of rotating through the index line on the encoder on startup to determine absolute position.  Hall-effect rotation sensors are nice for their absolute position, but I already know how to use encoders and I've never messed with the hall rotation sensors before.

Next hardware steps are laying out a new version of the motor controller with the hardware patches I made and an STM32F446 on board.  Ideally, I'd be able to stuff everything in a board with the same footprint as the motor, so it could bolt straight on the back.

I also need to start thinking about the mechanical bits soon - mostly how to build a single-stage planetary gearbox around these motors inexpensively.

That's all for now!  Stay tuned for more exciting motor shenanigans.

January 25, 2016

Snow Bike Part 2: How Does Snow Work?

Snow Bike was more or less finished Saturday night, just in time for playing in several inches of snow before it all got plowed and salted.

Here's the motor mount, made from a couple more aluminum plates.


I cut a ski mount from a section of 3" square tubing, and pressed some brass bushings in.  The axle is a standard bike axle.  I have some long gas springs I might eventually add to the ski to return it to a neutral position, but haven't gotten around to that yet.



With seat and electronics.  The battery and motor controller are held by a bent polycarbonate shell which drapes over the frame.  I also added footpegs at the back.


I wired up all the electronics, only to find out that the hall sensors I had previously repaired the wires for were actually completely dead.  So I cracked the motor open again, and stuffed some new hall sensors in slots that weren't already filled with sensors and epoxy.

Bringing out in the snow immediately uncovered a problem.  The motor shaft was cut very short, and had two flats ground in it, so there was very little interference between my clamping motor sprocket and the shaft.  Any real torque, and the sprocket would slip off.  I thought about making a new shaft for the motor, but in the interest of time I first tried saving the situation with a giant set screw.  I drilled and tapped the sprocket-retaining shaft collar for a huge 1/4-20 set screw, and drilled a matching dimple in the end of the motor shaft, so there's both clamping action and positive interference holding the sprocket on.  Worst case, the shaft gets wrecked and I have to make a new one, but this was a last-ditch effort, so I don't mind that.

Second (and more fatal) problem was the shape of the track rollers.  The tracks would quickly get filled with snow, which was compacted by the rollers and clogged the teeth.  This stopped the track from engaging properly, and caused it to bind.  I think the answer is to just remove most of the width of the teeth, so that there's space between the teeth and the matching part of the track.  A bigger gap should make it much more difficult for snow to collect and jam things up.

Next time there's a good snow forecast, I'll fix the track roller problems and get this running again.

January 21, 2016

Emergency Snow Bike, Part 1

After the absurd amount of snow Massachusetts got last winter, I decided to prepare myself for the net winter by grabbing a pair of small snow blower treads on Ebay.  On Monday of this week, there were rumors of a foot of snow this coming weekend, so I decided to punt everything else for a few days, put the treads to use, and build an emergency snow vehicle.  Although the snow forecasts are no longer so exciting, at some point this winter it'll snow enough for some fun snow riding.

Here's the preview:


That's the frame from Herpybike, modified to accept a threadless mountain bike fork.  I removed the original 1" threaded fork, banged out the headset cups, and re-bored the head tube to accept the cups for a 1 1/8" headset.

For the tracks, I made a pair of track rollers from some scrap plastic.  The plastic centers are clamped by the original scooter wheel hubs, which conveniently already have axles and bearings.


The plastic bits were machined on the CNC mill, which was covered in lovely red and white confetti afterwards:


Here's the mostly-assembled track pod.  Two aluminum plates space the track rollers and allow the tread to be tensioned.  Don't worry, the wingnuts are temporary.


The fork is going to get a ski, and I'm temporarily borrowing the power system from Nick's old 2.007 vehicle, derpscooter.  I'm fixing the hall sensor wires, which managed to get caught in the rotor and shredded.


More to come soon.

January 15, 2016

Closed Loop Subwoofer With Interferometer Feedback, Part 2: The Hardware

In Part 1, I documented quadrature-encoder-ing with the Nucleo boards, and talked about some ways to sense speaker cone velocity.

Here's the hardware. 


So what's going on up there?

To the left of the speaker is an interferometer built by Peter.  This particular configuration of interferometer results in two out-of-phase interference patterns, which (for this project) are conditioned into a digital quadrature signal, just like an encoder.

A HeNe laser is split and directed at two retroreflectors - one on the back of the speaker driver, and one fixed to the optical breadboard.  The reflected paths re-intersect each other and interfere.  The interference pattern changes as the moving half of the path changes length, and this changing pattern is picked up by a pair of photodiodes.  Here's a diagram of the laser path, because words are hard sometimes.  The blue circle is where the interference happens.  The interference pattern on each beam cycles every 1/2 wavelength of displacement, (since the beam path lengthens by twice the movement of the speaker), and since the two interference patterns are ~90 degrees out of phase, the edges of the digital output are spaced 1/2 that again, so every 1/4 wavelength of speaker displacement.  That's 158.2 nm for this laser.  I can't do justice to the explanation for why the two outputs are out of phase, so I'm not going to try.




The laser passes through the convenient hole in the back of the driver, and bounces off a tiny retroreflector attached to the back of the cone.


A pair of photodiodes pick up the interference patterns.


The sensing and control is done through this glorious stack of arduino-shield-shaped objects.  From top to bottom:

A Pololu motor driver, to drive the speaker
An circuit to DC bias the audio input for the microcontroller's ADC
A photodiode, to quadrature converter board
An Arduino, just used as a spacer
A signal to BNC board, for debugging on a scope
An STM32F446 Nucleo board, running the show


Here's a closer look at the photodiode to quadrature converter, also built by Peter.  The signal from each photodiodes goes through a transimpedance amplifier and then to a comparator, to convert them to square waves.  The two trim pots for each channel set the hysteresis and reference voltage of the comparator.  A little LED on each channel blinks out the comparator output state, which is extremely useful for debugging.


For the speaker, I picked up a super cheap 10" car audio subwoofer.  Notice the faux carbon fiber aesthetic cone glued in front of the actual cone.  Quality.  Claims 250 Watts RMS, and a kW peak.



The speaker took some significant modification to stuff a retroreflector inside.  I sliced off the voice coil magnet assembly with a bandsaw, and cleaned up the driver on the Bridgeport with a slitting saw.


I happened to scrounge a machined round piece of aluminum which was already almost the exact size I needed to reattach the magnet.  I did some minor operations on it and bolted it to the magnet assembly.


The tiny retroreflector was pressed into a little 3D printed jig, which was then glued into the back of the cone.  Fortunately, there was a convenient flat plastic surface to glue to.  The 3D printed bit centers the reflector in a cavity on the back of the cone.



In part 3, I'll go through the controls stuff.

January 6, 2016

Motor Characterization for Small Running Robots

a.k.a. HobbyKing Cheetah.

Bear with me, this is going to be a long one.

Tl;DR: 

I characterize a bunch of cheap brushless motors to investigate their usefulness in small running robots.  Each motor gets a mechanical teardown and brief characterization.  Scroll to the bottom for conclusions.

Background

I've worked on small running robots in the past, in the Biomimetic Robotics Lab.  That robot was designed to be extremely low-cost, built out of super cheap off-the-shelf DC gearmotors, which proved to be a hugely limiting factor in terms of the kind of running the robot was capable of.

So here's the basic idea:  The hobby remote-control-things market has produced an abundance of cheap, light, super powerful motors.  This type of motor has showed up in my fleet of small electric vehicles, and many other people's vehicles, multi-copters, airplanes, etc. long before me.  But not in robots as precision or fast, torque controlled actuators.

There are a couple reasons for this, I think.  First, suitable motor controllers don't really exist.  There are super expensive small brushless controllers made by companies like Maxon, and slightly less expensive (but larger) industrial-grade servo drives by the likes of AMC.  These could be convinced to work by appending your own sensor array to a hobby motor.  However, these motors tend to be hot-wound (i.e. low torque constant, low resistance, low inductance), so they want lots of amps and relatively few volts, which doesn't play nicely with the fancy servo drives.  On the other end of the spectrum, there are the hobby grade controllers which usually are awful for anything other than RC vehicles, as they lack any form of current or torque control.

As I'm interested in using these motors in dynamic running robots, all these motor control options become even less useful.  The fancy industrial drives might output 10 amps all day, but won't give you a drop more than 10 amps ever.  For running, on the other hand, that's not what you want.  Instead, you want many times your continuous current for short bursts and much less current the rest of the time.  So more dynamic current limiting is required.

Thanks to Nick's last semester at MIT working on the Derpbike (a.k.a Bremsthesis), I'm making this a senior thesis project.  While I technically don't need to do one to graduate as I'm doing course 2A (the flexible MechE option), it's an excellent excuse to spend all of next term at MITERS working on my own project for credit.  My end-goal for the semester is to get all the necessary motor control stuff worked out and build a prototype 2 degree-of-freedom leg using hobby RC motors.

Motor Characterization

I've started out this project by acquiring a pile of small brushless motors I thought would be suitable for this kind or robot, and characterizing them to figure out which are the best.  These were visually narrowed down from the vast array of available motors by geometry.  In general, pancake-shaped (large diameter, small depth) is best for high torque density1.

This can be seen with a little motor dimensional analysis.  Assume your rotor and stator are two rings of constant thickness, and radius and depth can be varied (not too unreasonable, although not all-encompassing).  Motor torque will be proportional to both air gap surface area and air gap radius.  So for a fixed air gap surface area (which means fixed mass, in this case)  increasing diameter means increasing torque per mass.

Obviously there are many practical reasons why this might not be perfectly true (motor supporting material mass may scale differently, thinner motor means larger percent of windings in the end turns, etc.) but it's a good place to start from.

Here's the pile of motors I ended up with.  From left to right, the Turnigy HD 5208 Gimbal Motor, Turnigy Multistar Elite 5010, Gartt ML 5208, Turnigy Multistar 4830, Turnigy Multistar 4822, and Flycat i-Rotor 5010:




Methodology

The goal of this motor characterization is to get a good first-order understanding of each motor's electromagnetic performance, as well as gauge the quality of construction and ease with which these motors could be adapted to legged robot applications.  All the characterization was done with a benchtop power supply, a pair of multimeters, a cordless drill, and an oscilloscope:


The two parameters I measured were line-to-line resistance and line-to-line back-EMF waveform at constant speed (hence the cordless drill).  From these numbers, I can calculate the torque constant (Kt) and  "motor constant" (Km) by finding Kt/sqrt(R).  This number tells how much torque a motor can produce for a given amount of power dissipation in the windings (the units also work out to N*m/sqrt(watts).  It is important to note that this number is independent of how the motor is wound (assuming constant pattern and same amount of copper).  In other words, rewinding a motor to have twice the turns will give it twice the torque constant and four times the resistance, meaning the motor constant is unchanged.  The motor's ability to produce torque (looking at just resistive loss) is not dependent on how "hot" or "cold" it is wound.  I find this to be a common point of confusion.

So, motor constant is a very limited motor performance metric, but if you just want a good idea of how much motor you have, it's a useful number.

Furthermore, perhaps a good metric of how well your motor's materials are used to produce torque would be Km/sqrt(mass).  Sticking two identical motors end to end would double the mass and increase the motor constant by a factor of sqrt(2), so this number would remain constant.

Turnigy HD 5208 Gimbal Motor
Link
Price: $39.20





The rotor is axially constrained by a single e-clip.  The shaft and bearings are very small diameter, and there's no extra shaft sticking out of either end.


There is plenty of space for more copper on the stator.  The windings are a single strand of very fine wire.


Extra-thick laminations.  Another indication that this motor wasn't designed to spin fast:


Nice thick magnets.  There's no visible balancing done to the rotor.


Back EMF on the scope:  This is nominally a 31 RPM/Volt motor.


Torque Constant:  0.3558 N*m/A
Resistance:  11.7 Ω
Motor Constant:  0.1040 N*m/sqrt(watt)

Turnigy Multistar Elite 5010
Link
Price: $52.69  $42.15 as of 1/29

This is a beautiful motor.  You pay for it, but Hobbyking really outdid themselves here.  For an extra $15 over other motors of similar size, you get absolutely beautiful single-strand, perfect windings, curved N45SH magnets, and an overall just really nice feeling motor.





Solid construction all around.  Big shaft and bearings.  Shaft axially constrained by a locktite-ed screw.


Rather disappointingly, there's a lot more space for copper on the stator.  However, I think for multirotor-duty, this actually is a good thing.  I bet these motors are exceptionally well cooled with air forced past them by propellers, considering the thick, clean windings and room for airflow between stator slots.  Also take notice of the tapered ends of the stator teeth.  Every other motor tested has right angles at the ends of the stator teeth.  Hard to say what this does without seeing the FEA.


As expected, it has nice, thin laminations:


A closer look at the curved magnets.  Also some small daubs of blue balancing goop.


Drill-o-metered back EMF.  This is nominally a 274 RPM/Volt Motor.  Fairly sinusoidal looking.


Torque Constant:  0.03844 N*m/A
Resistance:  128 mΩ
Motor Constant:  0.1074 N*m/sqrt(watt)

Gartt ML 5208
Link
Price: $38-$45

I had high hopes for this motor.  I managed to offer them down to $38 on ebay, making it cheaper than most equivalently sized motors from Hobbyking.  Unlike the two motors above, it has 22 rather than 14 poles.  A nice thing about having more pole pairs is that there's less flux between poles (because each pole is smaller area).  I was hoping this would mean that the rotor can would be less leaky (i.e. less flux leaking out of it).  This indeed appears to be the case - you can barely feel metal objects stick to the can of the motor.





Solid construction here too.  Again, big bearings, big shaft, snap ring and screw to axially retain the rotor.  The magnet fill is pretty low though.


The windings are "Hobbykinged" with a bundle of parallel strands.  Cleanly done, though.  The cutouts in the stator between the bearings and the windings are interesting.


Nice thin laminations:


More balancing compound, and a better look at the magnets:


Back EMF.  This is nominally a 340 RPM/Volt motor.  Some much more noticeable harmonics on this one.



Torque Constant:  0.02885 N*m/A
Resistance:  97.5 mΩ
Motor Constant:  0.0924 N*m/sqrt(watt)

Turnigy Multistar 4830
Link
Price: $43.29

This motor has a different aspect ratio than the rest of them - longer axially, smaller diameter.  Like the one above, it's a 22 pole motor.  Rather annoyingly, it came in a fancy metal box with foam cutouts on the inside.  I'd  have preferred cheap cardboard packaging and a couple dollars less expensive motor.





Well constructed here.  Not sure why so many washers at the end of the shaft, but like before it's a screw plus snap ring to hold the can on.






Good magnet fill, and a little balancing done to the rotor:


Eww, some big 5th harmonic in that back EMF.  This is nominally a 420 RPM/Volt motor.



Torque Constant:  0.0245 N*m/A
Resistance:  102.8mΩ
Motor Constant:  0.0764N*m/sqrt(watt)

Turnigy Multistar 4822
Link
Price: $32.91

I was expecting this motor to just be a shortened version of the 30mm motor, but there are a surprising number of changes between the two besides the stator length.





The rotor retention is different - this one just has a snap ring, while the 30 mm one had a snap ring and a screw-on cap to the shaft:


The bearings and shaft are also smaller:



As usual, there's some balancing goop on the rotor:


I was expecting the back EMF waveform to look pretty much the same as the 30mm version of the motor, but to my surprise it showed none of that 5th harmonic, and was very sinusoidal.  Not sure what's going on here to cause the difference between the two.  I can't imagine the winding pattern is different between the motors.  This is nominally a 390 RPM/Volt motor.



Torque Constant:  0.0258 N*m/A
Resistance:  205 mΩ
Motor Constant:  0.0569 N*m/sqrt(watt)

Flycat i-Rotor 5010
Link
Price:  $14.49

With its $14 price point, this motor is the odd one out.  I got this motor because I searched "5010 Brushless Motor" on ebay, and didn't read the description carefully enough.  Usually, "5010" means the motor has a 50mm diameter, 10mm tall stator.  For this motor, those are the outer dimensions.  The actual stator is much, much smaller.  No surprises here, the motor is smaller than the others, and construction quality is about as awful as you would expect for a $14 motor.




Nice exposed underbelly.  Makes it lighter, right?


The rotor is axially retained by a retaining ring and bronze washer.  I managed to send the retaining ring flying across MITERS never to be seen again.  I can't say I'm particularly broken up about the loss.  Small diameter bearings and shaft.


Messy single-strand winding.  More or less as expected.



Despite the lack of visible balancing, the motor was okay sounding when I spun it up with an RC airplane controller.


Back EMF.  This is nominally a 360 RPM/Volt motor.



Torque Constant:  .0287 N*m/A
Resistance:  286 mΩ
Motor Constant:  .0574 N*m/sqrt(watt)

Conclusion

Here's a nice table:


Motor
Torque Constant (N*m/A)
Resistance (mΩ)
Motor Constant (N*m/sqrt(watt))
Mass without leads (g)
Price ($)
Turnigy HD 5208
0.3558
11,700
0.104
167
39.20
Turnigy Multistar Elite 5010
0.03844
128.0
0.1074
183
52.69
Gartt Ml 5208
0.02885
97.5
0.0924
173
38.00
Turnigy Multistar 4830
0.0245
102.8
0.0764
162
43.29
Turnigy Multistar 4822
0.0258
205
0.0569
100
32.91
Flycat i-Rotor 5010
0.0287
286
0.0574
90
14.49

The real competition here is between the top three motors - the Turnigy gimbal motor, Multistar Elite, and the Gartt.  The bottom two are bit smaller than the size range I'm interested in, and the Multistar 4830 is strictly worse than the others for similar cost and weight.

Rather to my surprise, just from numbers, the Turnigy Gimbal motor does quite well.  A solid second in terms of motor constant, lighter than its two competitors, and basically the same price as the Gartt.  From feasability of using in a robot, though, it doesn't look so good.  To get equivalent performance from the gimbal motor to a, say, 20 V system with the other two motors, I'd need a 200V bus!  Not too tasty.  Its mechanical construction is generally worse than the others, as well.  So the conclusion is....unclear.  The Multistar Elite is just so nice... the extra 40% cost over the Gartt seems palatable when considering the overall cost of building a robot.  18%  larger motor constant, back EMF is more sinusoidal, thermal performance I'd guess is better (although I have done no analysis or experimentation to back this claim up), and it just feels nice.

**Edit**
As of 1/29/2016, the Multistar Elite motors have dropped to $42.15, making them a clear winner in this motor shootout.
****

Next steps:  I have already designed and laid out  motor controller hardware (for now as a Nucleo shield.  Once I get control stuff working I'll put the micro on board), and will send out for boards and parts from digikey shortly.  Then I can get crunching away on motor control.  I still need to decide on position sensing method.

There's also a lot of mechanical design work that needs to be done to integrate these motors into legs.  Like the full-sized cheetah robot, I'd like to use a single state planetary reduction, so that needs to get figured out.

Stay tuned.  This is gonna be good.