November 2, 2017

Stall Torque Test Stand

To better characterize the big kart motor, I threw together a stall torque test stand.  This was actually several months ago, but I'm just now getting around to documenting things.

The stall-tester consists of a precision-length stick attached to the motor shaft, and a 50 kg load cell on the end of the stick.  I added ball joints on each end of the load cell, to ensure that it is in pure tension or compression.


To visualize and log the data, I made a pared-down version of my dyno control gui:



The basic goal of testing was to brute-force determine the motor torque vs D and Q current.  Ideally, torque should be easy to calculate from the D and Q axis inductances and permanent magnet flux linkage, by the classic torque equation \(\tau =\frac{3}{2}\cdot p \cdot i_{q}(\lambda_{pm}+(L_{d} - L_{q})i_{d})\).  But we're driving the motor hard enough that it saturates fairly substantially. This changes both the inductances and flux linkage, and makes analytically solving for torque (and modeling the motor in general, without FEA) challenging.  Using our various motor-models, we've gotten decent results, but a bit of low-end torque has been eluding us.

To take the measurements, we swept current phase angle from pi/2 to pi, and current magnitude from 0 to 180A.  At each phase setpoint, current was ramped up from zero to 180 over about 2 seconds.  Torque was logged from the load cell, and D and Q axis currents were logged over serial from the motor controller.

The time-series data looked like this:



After a little processing (3-sample median filter to throw out some single-sample glitches from the strain gauge amplifier, and torque-constant sanity check to throw away points between each ramp), the 3-D scatter plot of the points looked like this:



A problem I seem to run into all the time is trying to fit a smooth surface to time-series data.  In the past I've usually used MATLAB's griddata to do it like this, but this approach has a number of annoying problems, like that it can't extrapolate, and the surface generally ends up kind of "lumpy".  Fortunately, I finally found an excellent script, gridfit, which worked beautifully for this problem.



Finding the phase that produces the most torque for each current magnitude, you get the following trajectory.  As you'd expect, at low currents most of the current is on the Q-axis (phase equal to pi/2), and it shifts onto the D axis as current increases.


Superimposed on top of the surface of all the data, the trajectory looks like this.  It's pretty coarse looking at low currents, but that part isn't too important anyway.




This is the maximum torque per amp (MTPA) trajectory, which is what the motor should operate along until it reaches base speed and you no longer have enough voltage to operate along the trajectory.

Excitingly, the motor seems like it still has plenty of torque capability left, even at 180 amps.  Torque constant is dropping off somewhat, but it looks like breaking 60 N-m should be no problem.  On one motor we should be able to hit just over a G of acceleration, and with 2 motors, easily break traction on command.

October 26, 2017

A brief introduction to the big go kart, and machining some PolyChain sprockets

Brief Introduction:
Go read Bayley's introduction.  TL:DR:  Racing kart frame with hybrid car parts based powertrain and custom motor control.  We've done a lot of motor modeling, characterization, and control over the last year, and the go kart is getting quite performant.  But we're not quite squeezing all the possible performance out of the KIA HSGs yet.  And the kart's going to get a second motor.


Sprockets
Right now the go kart uses Gates Micro-V belts, because the HSG's come with those pulleys pre-attached.  However, we're driving the motors a fair bit harder than the car they came from did.  The v-belts, even with a huge amount of tension, slip at ~45 N-m of torque, and we've been able to hit nearly 60 N-m at 180 phase amps.  So we're switching the kart over to Gates PolyChain GT Carbon belts, which are basically the best synchronous belts you can get.  The inch wide Micro-V belt is getting replaced with a 12mm wide, 8mm pitch PolyChain belt, which should be good for substantially more torque.

You can download CAD models of the sprockets from Gates, but, as they warn you on the website, the tooth geometry of the sprockets is not actually accurate, since the tooth profile is proprietary.  My first plan was to try to figure out the tooth profiles from the patents (1, 2), but it turns out if you just ask nicely, Gates will send you the tooth profile drawings  drawings for the sprockets you want.

We went for a reduction of 4:1, with a 20 tooth motor sprocket and an 80 tooth sprocket on the axle.  The big sprockets were too big to fit on the MITERS CNC mill, so I did them on my lab's Haas SMM.  For fun I GoPro'd the entire machining process for one of them:






Getting a good finish on the teeth required many very shallow passes - the minimum curvature radius in the grooves is very close to matching the 3mm end mill I was using, so I had to go really slowly to avoid chatter at the high-engagement areas.



The motor-side sprocket was done on the MITERS CNC.  I still need to broach the keyway in it, and turn a clamping hub for the big sprocket.


Here's one of them partially installed on the go kart.  Still needs a hub to clamp the axle.


So low profile!




Back to the subject of squeezing all the performance out of the KIA HSG, next kart post will be about a stall test stand we through together for motor characterization.

October 4, 2017

Extremely Chinese Brushless Power System Dyno-ing

I did some data-gathering for Dane on a generic looking 48V 1800W brushless electric scooter motor widely available on ebay and aliexpress, paired with a 1500W E-bike controller. 

Check out the full data here.


The motor had basically no shaft to speak of - it has a left-hand threaded stud on the end, and 2 flats which engage with a stamped #25 chain sprocket.  Since there wasn't enough shaft to grab onto with a collet, I made a "terrorist coupling", with three steel pins that engage with the sprocket teeth:



I plugged the analog output of the talk-to-everything board  into the throttle connector so I could sweep throttle commands in an automated way.  It was a little tricky to tune the throttle ranges, because of how the e-bike controller works.  As far as I can tell, the throttle commands voltage, not current, until you hit the DC bus current limit.  That means that at low-speed, the torque vs. throttle position curve is really steep: very small changes in throttle position mean huge changes in torque, thanks to the voltage-mode control.  The motor is also capable of slightly more than the ~10 N-m the dyno is good for, so I had to carefully tune the throttle range so that the dyno could regulate speed.

Dyno-ing in progress:



Initially I put the dyno in inertia-simulation mode, and did a spin-up using a hand held twist throttle to see what the full-throttle performance was like.  Data below ~1200 RPM was cropped because it was pretty noisy.  This whole spin-up only lasted a few seconds so the plot is little rough.  The motor is legitimately good for almost 2000 mechanical watts.  Surprising given the 1500 watt rating on the motor controller.  Efficiency is rather poor, topping out at around 80%.


The high-speed end of the torque curve is a little bit strange looking, and I don't have a good explanation as to why.  Probably something to do with the internal hall sensors and commutation scheme of the controller.

After figuring out what throttle ranges worked at a range of speeds, I did a full automated sweep of speeds and throttle setpoints to get the full operating maps.  Again, the full data is in the database.  The e-bike controller wasn't set up for regen, so all the maps are 1st quadrant only.

September 17, 2017

Planar Magnetic Headphones, Part 2

I finished putting together a housing for a single driver.  CNC milled aluminum goodness:

The machining was done in two operations.  All the fancy 3d profiling was done with the part flipped over and held in soft jaws.


Front side:



Back side, before gluing in the magnets:


Here's the assembled driver.  I'm using a cheap off-the-shelf pair of earpads.




This version sounded pretty terrible.  The pcbway flex-pcb was way too thick, making it both too heavy and too stiff.  The response was way to heavy at low frequencies, with a terrible ~100 hz resonance, and there were all sorts of weird notches in the frequency response.  But it did make sound, so that was a good start.

I ordered some Pyralux samples from Dupont, and tried etching my own drivers.  I first tried with the LF7012R variety, which has 1/2 oz copper, 13 micron kapton layer, and 13 micron adhesive.  I measured the total thickness to be 45 microns where there was copper, and ~25 microns without copper, which is half the thickness of the pcbway material.  At the time I thought that was their thinnest material, but I hadn't looked through their datasheets carefully enough.  The AC 091200EV material has 1/4 oz copper, 12 micron kapton, and no adhesive layer, so it should be in total something like 20-25 microns thick with copper, and 12 without.  I've got a sample of that on the way, and will report back when I've etched some.

After a few tries I figured out a pretty good process for etching the pyralux.  I did the classic toner transfer and ferric chloride etching method.  The etching part worked really well, but doing the toner transfer proved finicky.  It took a few tries with a few different laser printers to get the process to work.

Etched:


Assembled into the driver:


This one sounds much, much better, although there's definitely still a little weirdness going on.  Listening to it plugged into a function generator and sweeping frequencies, the low-frequency resonance is gone, and over all it's much flatter, but there are still some strange notches in the response.  Unfortunately I don't have a good setup for quantifying the frequency response at the moment, but it's definitely a little off right now.  But it's getting better.  I'm hopeful that the even thinner flex pcb material will improve the situation further.  Reducing tension in the membrane might help as well.


September 1, 2017

Dynamometer Database

Now that I have a good process for collecting data on the motor dynamometer, and the appropriate scripts for quickly processing the data, I put up a page dedicated to motor dyno data.  You can also find it in the navigation bar up top.  There's only one motor two motors on it right now, but it will slowly get populated as I get a chance to run more tests.

I'm not sure if anyone else will actually find this useful, but it seems like there's a growing number of people doing legitimate robotics and other cool stuff with hobby-grade motors, so I might as well share what data I've got.

August 20, 2017

Planar Magnetic Headphones, Part 1

A brief break from 3-phase electric motors, for a different kind of electromagnetic actuator.

Planar magnetic (a.k.a. "orthodynamic", "isodynamic", etc) drivers are a pretty neat topology of linear motor, which, as far as I can tell, has found no application besides speakers and headphones.  Here's a well-diagrammed explanation of how they work.

Instead of a voicecoil actuator which drives a stiff cone back and forth, like a conventional speaker driver, a thin membrane with conductive traces sandwiched within a funny magnet arrangement moves back and forth.

image credit: innerfidelity.com
I won't try to argue that this is "better" than a conventional driver in any way, because frankly I don't care.  It is cool, though, and also a perfect excuse to send out for some flex-PCB's, which my go-to PCB vendor, PCBWay, recently started offering for quite reasonable prices

I started out by playing with magnet arrangements in FEMM, to see how sensitive this arrangement was to changes in magnet dimensions and spacing, and I ended up here:

This uses 1/8" square N52 magnets, with a 2mm airgap, and 9mm pitch.  The array 2 inches long (into the page), and each bar is a pair of 1/8" x 1/8" x 1" magnets, which are cheaply available on ebay:


Here's the tangential flux density (which is the normal force producing component)  in the middle of the air gap:


Doubling the depth of the magnets got it up to .5T peak (the path around the magnet gets longer, so less flux leaks through it), but I decided it wasn't worth the more than double magnet cost (they are harder to find magnetized through the small face).

Here's what the actual flex pcb coil looks like.  The traces go up and down in the regions of ±.35T field in the plot above.  This was very unpleasant to draw in Eagle.  0.25mm trace width with .5mm pitch.  PCBWay claims to be able to do .1mm between traces, but I didn't want to push it.


For the actual PCB, I chose single layer, 75µm flexible adhesiveless base, .1mm FPC thickness, no solder mask, and 1/3 oz copper, to keep the board as light and flexible as possible. Maybe a 2-sided trace would have been better, for a higher ratio of conductor to pcb material, but this whole thing is an experiment anyway.


Front:  A few of them came out a little wrinkly.  Not sure why, or if it will cause problems.  In retrospect, it might have been a good idea to put a thick copper trace around the outside of the whole board, to stiffen up the perimeter.  Coil resistance came out to 16 ohms.


Back:


I CNC milled half of a housing out of some Delrin:



Glued in the magnets:


There's a lip on the housing that will apply some tension to the flex pcb to hold it flat, once both halves of the housing are made, but it was secure enough for some testing with only one half.



It actually works even with only half of the magnet arrangement - half the magnet gets you half the flux density.  It should produce the same volume on roughly half the power, once the whole thing is assembled.



I'll reserve qualitative judgement until the whole thing is assembled, but from the brief testing I've done on this single partially assembled driver, it seems promising.

August 13, 2017

Reamer Regrinding

In the near future I'll need to make a bunch of things with tight-tolerance 22 mm bores, so instead of buying a 22 mm reamer, or just boring the holes like a normal person, I tried out re-grinding a 7/8" reamer (22.225 mm) reamer down to 20 mm by setting up my toolpost spindle as a toolpost grinder.

Here's the setup:


The reamer is set up between centers, and the toolpost spindle has a 4" grinding wheel on an arbor.  There's a mist-coolant dispenser to keep everything cool and lubricated.  The center on the chuck-side was turned in place out of some steel scrap, to ensure its concentricity with the spindle.

a

All together it turned out pretty well.  I turned down the shank and ground it as well, so it will fit in the lathe's drill chuck.




I overshot my target 22 mm by 5 microns, but that's not too shabby, considering the ticks on the lathe's cross slide are 25.4 microns each.  It seems to cut a tiny bit oversized, so it works out in the end to give me a very tight slip fit onto a 20mm ground shaft.

This method leaves no relief behind the cutting edges, so as you might expect, they drag a little bit.  The surface finish inside the bore is okay, but definitely not as nice as I'm used to getting with reamers.  Over all, this was definitely way more time and effort than just boring the holes like I normally would, but it was a fun exercise, and good to get some experience using a toolpost grinder.

May 30, 2017

Vector Hysteresis FOC

Here's round 3 of wrapping up draft blog posts I've been sitting on for a while.

This came out of thinking about sliding mode control and direct torque control, thanks to the nonlinear controls class I took this past term.  I did a more formal writeup for my final paper for the class, in the (unlikely) case you find that a more readable format.

In a typical FOC implementation, phase currents are measured and transformed into the rotor frame to get d and q axis currents.  Then two PI loops are run to control the d and q currents, with some feed-forward deal with the coupling between the voltage equations.  The two PI controllers output d and q voltages, which are transformed back to the stator frame, and approximated with PWM.

This usually works great, but here's another controller I thought of which is (maybe) conceptually easier, and requires no controller design or gain calculating to work.  In fact, it doesn't even use any motor parameters.  And it doesn't even use PWM.  At every step, it just picks which switches to turn on and off.  Because of how it works, it's quite robust to changing parameters, like the motor's inductance changing when it saturates.  Also, it has as fast as possible response given the open-loop dynamics of the motor.

The basic idea is as follows:  Given the position of the rotor and errors in d and q currents, which switches should be turned on and off to make the error decrease as fast as possible?

Every loop cycle, the controller measures current, looks at the error and where the rotor is, and chooses the switch states that send the current error towards zero the fastest.

While it probably looks very confusing at first, I think the vector diagram below best explains the situation:



First, there are six vectors drawn in black, V1-V6, which represent the six stator voltage vectors.  Each of these corresponds to a set of switch-states.  The states with all switches on or all switches off are not used.  Then there's the ĩ vector in blue, which is the vector sum of the d and q current errors.  In red is the (negative of the) vector from motor dynamics, minus inductance.  Looking at the motor voltage equations in d and q:

$$V_{d} = R_{d}i_{d} + L_{d}\frac{d i_{d}}{dt} - \omega L_{q}i_{q}$$
$$V_{q} = R_{q}i_{q} + L_{q}\frac{d i_{q}}{dt} + \omega(L_{d}i_{d} + \lambda_{r})$$

Vdynamics is equal to the vector sum of 
$$ -R_{d}i_{d}  + \omega L_{q}i_{q}$$
and
$$-R_{q}i_{q}  - \omega(L_{d}i_{d} + \lambda_{r})$$
in the d and q directions, respectively.

If the d-axis component of stator voltage plus the d-axis component of the dynamics is positive, then id will increase, and the same for the q axis.

The green vectors are di/dt scaled by inductance - mostly their direction is what matters.  Given a dynamics vector and one of the stator vectors, the six di/dt vectors are the possible directions the current will change in.

Basically:

$$V_{stator} + V_{dynamics} =  L\frac{d i}{dt}$$

The intuition is, pick the stator voltage vector which causes the di/dt vector to be in the right direction.  The "right" direction is the direction of the error vector, ĩ.  In the 1-D case, if error is positive, that means that actual current is less than desired current, so di/dt should be positive to cause current to increase.

To pick the right set of switch states, just take the dot product of the error vector and the six stator vectors, and then pick the switch state corresponding to the largest dot product.  But wait, that's not the right thing to do, is it?  Shouldn't I be picking the switch state which causes the dot product of the di/dt vectors and error vector to be the largest?  Yes, but fortunately these two decisions are actually the same.  Vdynamics is added to all the stator vectors, and dot products distribute.  So you can ignore the Vdynamics vector, and just pick based on the stator voltage vectors and the error vector.

To limit switching frequency, you can also add a "hysteresis circle" around the origin.  As in, if the error vector lies within the circle, don't change switch states:

Does it actually work?

Well, my motor model says it does.  This is also using a motor model which includes a lookup table for inductance and flux linkage saturation.  The motor parameters are from a KIA hybrid starter generator at 160 volts, with switching frequency limited to 15 kHz.  I also threw in some real hardware effects like a few amps of noise on the current sensors, and 12 μs of propagation delay (which occurs in the Toyota Prius inverter).


Here's what phase current looks like at ~20 phase amps.  As expected, it has way more ripple than a linear controller would, since the minimum switch on-time is one loop period, but it's quite tolerable - especially given the 200A max current of this system.


"It works is simulation" is where most people would have stopped, especially for a class project, but what's the point of controls if you don't put it on hardware?  And then ride your hardware:


This is an electric go kart started by Bayley and Nick last summer, with lots of work by myself and other MITERS-folk in it as well.  Eventually it will get its own thorough documentation but, but as a brief overview, it's a stock shifter kart frame, with the motor from a KIA hybrid, the inverter from a Prius, the battery from a Battlebot, and a bunch of custom motor control logic.

So how'd it work?  Here's 20 phase amps on the actual motor, as measured by LEM-stick.  Hey, that plot looks really familiar!



And here's a log from spinning up the wheels off the ground.  d-axis current stops tracking around 1000 rad/s, because the reference currents were generated using an in correct inductance.  So the commanded trajectory was actually un-trackable.



Qualitatively, it performed quite well.  It produces an audible white-noise hiss from the extra current ripple.  1600 rad/s in the plot above corresponds to a ground speed of over 130 mph, although in reality on the ground the kart won't have the power (nor the space, in Cambridge at least) to go that fast.  Yet.



To make if very clear, this type of controller is often not feasible to implement - for small hobby motors, for example, the inductance is too low for this to work with reasonable loop frequencies.  This is one reason PWM is great - the timing resolution of when the switches turn on and off is dictated by a super-fast timer that runs in the background, rather than by the timing of the control loop.  So for a given loop rate, normal PWM-based approaches will have way less current ripple than this controller.  But for some motors (in particular high-inductance motors like those in electric cars), the numbers actually work out fairly favorably, and you can get away with running this controller at reasonable speeds.

There are certainly some improvements that could be made to this by including motor parameters to reduce current ripple, but I haven't tried any of them out yet.

Also, I thought I was really cool and came up with something new here, but (unsurprisingly) it turns out other people have already done similar things.  Although they don't put it on hardware.