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.

Toolpost Spindle, Part 2

I've mostly finished the toolpost spindle.

I found the perfect spindle motor on All Electronics, of all places, for $17.  It's a very cute brushless inrunner.  I dyno-ed it at 500 watts peak output at 48V, running of a 17A sensorless e-bike motor controller.  I forgot to take a picture of the inside, but the rotor has a thin steel sleeve around it, so the magnets won't fly off the rotor at high speed.  So I'm not worried about running it at 48V, even though it's nominally a 24V or so motor.


Unfortunately, none of my motor controllers are quite the right for this thing.  I wanted ~48 V, 10-20 amps, with hall sensor position feedback, and closed-loop speed control.  Fortunately, Charles and Bayley recently acquired a massive pile of mostly-not-working hoverboards.  The motor controllers in hoverboards pretty much exactly fit the bill.  They even do closed loop speed control with hall feedback!  I did a little investigation, and it seems like they run ST's motor library, doing dual-FOC on an STM32F103.  At low, speeds, they block-commutate, and at high speeds the phase currents become sinusoidal once they can interpolate between hall edges.

Phase current at low speed, scoped with the LEM-Stick:


Phase current at higher speed:


Fortunately, other people have figured out the serial protocol the hoverboard controllers use, so it was fairly straightforward to get it spinning the motor.


Unfotunately, the hall effect sensors in the All Electronics motor had very advanced timing, in the wrong direction for my application.  I opened up the motor, broke the glue holding down the hall sensor PCB, and reversed the timing:


I CNC milled an aluminum connector housing, for a DB25 connector.  Each phase has 6 parallel pins, plus 5 pins for hall sensors:  The steel front plate was made with a Bridgeport and hand files to match the motor curvature.  The 2-stepped HTD pulley was done on the CNC mill.



I made a height adjuster out of a chunk of steel.  I still need to make a nice thumbwheel for it.



I shoved a Nucleo and the hoverboard controller into the shell of an old G5 Mac Mini.  The power button on the left also came from a hoverboard, and I found an appropriately labeled knob to stick on the speed potentiometer:


Here it is mounted on the toolpost.  The spacing between the two pulleys is fixed, and I was able to choose the two sets of pulleys to have almost exactly the same center distances and belt lengths, so there's no need for a belt tensioner:



I've used it for a few jobs so far., including in-place drilling a bolt patterns into a big pulley and hub I turned, and also for deburring some internal ring gears:

May 29, 2017

Motor Dyno Efficiency Mapping

I finished up the code for automatically generating and post-processing efficiency maps on the motor dyno.  You give it a maximum speed, a maximum command vs speed, and number of points to sample in speed and command, and it auto-generates a time-stamped .csv file my dyno software can read.  Then the dyno plays back the time series, and logs the data.  To extract the points of interest, the log has a flag in it, which is set to 1 after each operating  point has settled, and 0 the rest of the time.  The post-processing script just finds all the intervals where the flag is 1, averages all the samples collected over that period, and combines them into one point.  So each point on the efficiency map is from several seconds of data.

Here's a video clip showing part of the process.  The motor being tested is a cheap knock-off of a Tiger Motor U8, at 22 volts, and 22 peak phase amps.


Here's the scatter plot of data points tested during the efficiency map:


And here's the data interpolated into a surface, in the classic efficiency map style:

I wouldn't read too much into the relatively low numbers (~74% peak efficiency), as this test was only at 22V and high peak current and these motors are good to spin much faster on more volts.

Also, some time soon I'm going to add a motor data page to the site, with whatever data I pull off the dyno on it, so keep your eye on the top bar.  I figure it might eventually be a useful resource, to have a page with lots of electric motor performance curves, efficiency maps, etc. on it.

March 31, 2017

Encoder Autocalibration for Brushless Motors: Offset and Eccentricity

I finally got around to writing a position sensor auto-calibration procedure, for measuring the orientation of the position sensor relative to the stator.  Until now, I've been manually measuring that position by setting my U phase high, and V and W low to, lock the rotor to the D-axis, looking at the position sensor reading about a few of these points, and hard-coding them into my firmware.

This process should work regardless of the order the motor phases are plugged in to the controller, or how the position sensor is initially oriented.

Step 1:  Determine Phase Ordering

The purpose of this step is so that commanding positive current on the q-axis produces torque in the direction that causes the encoder angle to increase.  Basically, the process is to apply a large, slowly rotating current to a "virtual" D-axis.  The rotor will closely follow this rotation.  This is basically equivalent to driving the motor like a stepper motor with microstepping.  As the current rotates around, if the encoder count is increasing in the positive direction, then everything's good.  If the encoder count is decreasing, then swap the voltage outputs and current sensor inputs on two phases.  Now the motor will rotate the correct direction.

In pseudo-code:


v_d = 1;                                                            // Volts on the D-Axis
v_q = 0;
reference_angle = 0;                                                
start_angle = encoder.GetPosition();                                //starting position
while(reference_angle < 2*Pi){
    [v_u, v_v, v_w] = abc_transform(reference_angle, v_d, v_q, 0)   //inverse dq0 transform to get phase voltages
    wait();                                                         //give the rotor some time to settle into position
    reference_angle += .001;
    }
end_angle = encoder.GetPosition();                                  // final position
if(start_angle - end_angle > 0){                                    // if position decreased, swap phases
    swap_phases();                                                  
    }


Step 2:  Measure Encoder Offset

Now that the motor spins the right direction, you can measure the DC offset of the encoder.  Just like before, apply volts to the  D axis, and slowly rotate the axis through a whole mechanical rotation both backwards and forwards.

Looking at the position sensor output vs the reference angle, you'll see something like this.


Zooming in a bit, you can see some ripple in the tracking from cogging torque:


Looking at the error between the reference angle and the actual rotor angle, things get a little bit more confusing.  The error plot below has a few interesting features.

First, and most obviously, the mechanical offset of the encoder is just the average value of the error.  The electrical offset (which is what we actually care about for commutation) is just mod((mechanical error) * (number of pole pairs) , 2π). 

The high frequency ripple (which in this zoomed-out view looks almost like noise), is from the cogging torque (the ripple that showed up in the red trace above).  

Right in the middle of the plot, there's a jump downwards.  This is where the motor switches direction.  Since the motor has friction and inertia, it always lags slightly behind the reference angle, so that lag switches sides when the motor switches directions.  

Then there's some low-frequency, much larger ripple on top of the signal.  This is from eccentricity of the position sensing IC/its magnet.  In my case, it's because I accidentally messed up the design of a PCB and placed the IC 0.5 mm off to one side.  The total peak-to-peak height of this ripple is only around 0.03 radians, or 1.7 degrees, which doesn't sound like a lot.  However, I'm using a 21 pole-pair motor, which means that 1.7 degrees of mechanical error translates to 36 degrees of electrical error.  Enough to seriously throw off commutation.  The next step will go through how I corrected for the error from eccentricity.  While this won't be nearly as much of a problem once I get the new round of boards in, there will always be a little error in the placement of the IC (especially when they're hand-soldered by me), so having this feature is still definitely useful.

Step 3:  Eccentricity Correction

The first trick for correcting for the eccentricity is separating out the error from cogging and friction from the eccentricity error.  

Friction is easy.  Just average the samples rotating forwards with the samples rotating backwards.  Then plotting error you have something like this 


Removing the ripple from cogging torque took some more thought, but it turns out can be done extremely effectively.  My initial though was to just low-pass filter the signal, and hope that cogging could be sufficiently attenuated without changing the eccentricity part of the signal too much.  Honestly, for this particular motor with lots of pole-pairs and many cogging steps per electrical cycle, that would have probably worked just fine.  But you can do better, and make the result more easily applicable to other motors.

The trick is to take advantage some properties of motors and FIR filters.  Since the motor is rotationally symmetric, the frequency of the cogging ripple must be some integer multiple of the electrical frequency.  FIR filters can be designed such that they have zero gain at certain frequencies and harmonics of those frequencies.  So you can easily design a filter that has zero gain at the electrical frequency, and all multiples of it, nearly perfectly cancelling out the cogging ripple without affecting lower frequencies.  I'm using basically the simplest possible FIR filter - I just average n samples around the point of interest, and choose n such that the samples I'm averaging exactly span one electrical cycle.  This should work pretty well on any motor, as long as the number of pole pairs is larger than the highest harmonic from eccentricity.  Here's what the the filtered version of the signal looks like:


Now, with that filtered signal, you can build a lookup-table to correct the encoder output.  It doesn't even need to be particularly high-resolution, since the signal varies slowly - I'm using 128 points, and it works great.  The lookup table is generated by subtracting the average value off of the error, and then converting the error back into raw encoder counts.  I'm cheating a little bit and using the reference position as the x-axis, rather than the actual encoder value, because it's nice and evenly spaced into a grid already.  This approximation works quite well though. 

Here are three lookup tables generated independently, showing the consistency of this technique:


My latest round of motor control firmware can be found here, if you want to look through the autocalibration code.  It's fairly unpleasant to read, but it is well commented.  The code as a whole is very much a work in progress, so don't expect to put it on anything and have it work out-of-the-box.

At some point I'll throw a high-resolution optical encoder on the output to quantify the improvement in position error, but in terms of torque ripple, this process qualitatively improved things enormously.

March 30, 2017

Lathe Toolpost Spindle

I've been thinking for a while it would be nice to have live tooling for the MITERSlathe, for things like grinding and indexed drilling parts like hubs.

So far I've made everything out of random bits and pieces found at MITERS.  For the spindle, I started out with this old R8 to ER16 adapter:


I meticulously turned the shank down to 20mm.  I used sandpaper and Scotchbrite to bring the shaft to within a couple tenths down the whole length.



This was an incredibly satisfying measurement.


The bearings lightly press on the shaft - it's a tight enough fit that you just barely need an arbor press, but you can still easily un-press the bearings without damaging them.

Here's some of the housing machining.  I started out with this huge brick of mystery-steel I found on the floor of MITERS.  I got really lucky - it happened to be perfectly sized for machining a tool-holder,  and machined wonderfully.  It fly-cuts especially nicely, producing an incredibly shiny surface:



I squared up the block on the mill, cut the dovetail, and spot-drilled the spindle bore.



I did all the spindle boring on the lathe.  I started out by placing the housing on the toolpost, centering it vertically, and indicating the back face to be parallel to the travel of the lathe.  I put drills in the lathe's collet chuck, and use the lathe kind of like a horizontal  boring mill, to guarantee that the spindle bore was true to the  the lathe's travel:



To machine the bearing bores, I put the housing in the 4-jaw chuck and indicated in the drilled holes, as well as the faces, to make sure the housing was both square and centered.  I used this big indexable drill bit as a boring bar, because it has wonderfully sharp positive-rake inserts which produces a much better surface finish with low cutting pressure than the usual negative-rake turning inserts do.


I used a different bearing arrangement than I did with the tiny lathe, and I'm very satisfied with how it turned out.  I only had deep-groove ball  bearings to work with, rather than angular contact bearings, and I used a 3-bearing arrangement.  There's a pair of bearings at the front of the spindle, with a 0.002" shim between their inner races.  When the spindle housing is assembled, the outer races get squeezed together, so the shim provides a fixed preload.  This puts the bearings in a face-to-face arrangement, making the spindle somewhat tolerant to misalignment of the back bearing, if there is any.  The back bearing is a very close slip fit into the housing, and the outer race is lightly preloaded outwards by a wavy washer, to keep the balls in contact with both races.  Finally, there's a spacer between the inner races of the front and back bearings.  When the bolt on the back of the spindle is tightened, it squeezes down on the inner races and spacer, locking everything together.

Over all, I'm much happier with how this arrangement worked out compared to the lathe spindle.  Since preload is fixed, it takes no fussing to get the spindle to spin smoothly without slop, assuming the shim is sized correctly.  Also, since the front bearings are so close together, the preload will hardly change as the spindle heats up and expands.  For the lathe, I left the spindle on for a while, and pre-loaded the bearings with the spindle at normal operating temperature.


A plate on the front of the housing presses the outer races of the bearings together, to preload the bearings:



To test it out, I threw a Lovejoy coupling on the back, and a mating one on the output shaft of an old orbital sander motor, which was roughly appropriate speed.  Conclusion:  the spindle part works great, and, unsurprisingly, the orbital sander motor was terrible.  Needs more brushless servo.



Here are the two mounting configurations.  I tested it out with a 3/8" endmill, and the spindle was rock solid, producing an excellent surface finish without any signs of chattering.



Still to do:
- Find a better spindle motor, and make a motor attachment and height stop.
- Make an indexing system for the lathe spindle, so you can precisely lock the spindle to certain angles.