Thursday, January 28, 2010

EAM: Single-Winding Back EMF Test

I finished up the sheet metal can of axial motor fluxage:



It's four layers thick, squeezed down from 12" ID to 9" ID by painstakingly tightening the hose clamps, flexing the can a bit to get it to slip, then tightening again, for about three hours. That's after I used up an entire cutoff wheel to cut it out of the large roll. Don't worry, I cut the ends of the clamps off before I ran it. This isn't part of the real motor, it's just a hack to get a more realistic result from the single-winding test. See this post for a better explanation.

Now, I'll admit, I kinda over-hyped this experiment. Although I still wouldn't want to be anywhere near it, this was a low-power test...no real load is being applied to either motor. So, although it looks "terrifyingly epic," the kart motor had no trouble at all getting it up to speed with just a bit of throttle. In "low gear," that means roughly 1,500 RPM. The vibration was just about as bad as I expected. (Remember, it only has one stator segment in place...) But, nothing broke. Here's a video. If you look carefully, you can actually see the entire test rig flexing.

But it's clearly generating a trapezoidal back EMF, and it got above the minimum speed I set for a valid result (1,000RPM). This is more so that the kinetic energy of the rotor overwhelms the push-pull of the magnetic forces, giving a smooth speed. Smooth here is a relative term.


The peak of the trapezoidal back EMF is proportional to motor speed, and the constant of proportionality in this case turns out to be 5.7 Volts per 1,000 RPM. Without the flux jacket, it is 5.2 Volts per 1,000 RPM. I expected a bigger difference, but maybe there are return paths I don't know about that are doing the job of the flux jacket already.

More importantly, how does this compare to the prediction? Well...the shape is right. And it's within a factor of two, so I probably didn't really mess up the calculations. But, plain-old math assuming a 1 Tesla airgap magnetic field predicts 9.7 Volts per 1,000RPM with this geometry and number of turns. A linearized simulation with FEMM predicts 9.6 Volts per 1,000RPM.

I have no idea if adding in the rest of the segments will make up the 40% difference, or some of it. Let's say it didn't, for now. Since back EMF tells you most of what you need to know about a motor, these results are very useful. Extrapolating these results, which are for a single winding on a single segment, to the whole motor gives the following as a rough performance estimate:
Operating Voltage: 96V-144V
Top Speed: 4,000RPM @ 144V
Torque Constant: 0.33Nm/A
Peak Torque: 66Nm @ 200A
Peak Power (3-minute): 20kW @ 3,000RPM and 200A
Continuous Power: 10kW @ 3,000RPM and 100A
That puts it squarely in the category of "small EV motor." It's the next step up from the kart motor, I guess. It could run well on inexpensive Kelly brushless controllers. Doubled-up, it would make a nice rear axle motor set, although I'd wind it for direct drive: lower speed, more torque. The catch: you have to build it! And in low quantities, the stator segments are still pretty expensive to produce. Please somebody steal this design, fix it up a bit if you like, and make one like it in large enough quantities to be under $2,000. I'll buy it! Seriously. Let me know when you do. Until then I'll be figuring out how the heck I might assemble the whole thing...

Sunday, January 24, 2010

Epic Axial Motor - IAProgress

It's been quite a while since I've done a post on the axial motor. In the last post, things were just starting to get built and the big question was how to validate the performance of the motor without actually building the whole thing. "Performance" meaning...? The predicted torque/speed curve, the thermal characteristics, the efficiency, or even just does it shred itself into tiny little pieces? I'll get back to that. First, build updates:


"Master of the EZ Trak" Mike N. put together two beautiful rotor halves worth of aluminum and steel. The magnets, as scary as they look, were actually very easy to put in. Only problem is that in the process of gluing them, the magnet O.D. changed enough that the wonderfully-machined inner surface of the magnet retaining ring didn't slip on anymore. I came up with a quick fix, but I don't think Mike will like it:

Sorry Mike. :(

I am fairly certain that this piece will need to be replaced in the next version anyway, for reasons I will get to in a bit. This first build is really meant to be a learning experience, with the possibility also of collecting some data on the back EMF. By learning the voltage generated by a single stator segment and winding, the torque/speed curve of the whole motor can be extrapolated (to a degree). Which is good, because I only have enough material and time to build one stator segment.

One problem I avoided for as long as possible but finally had to deal with is getting the conical bearings to be properly loaded, even with a single stator segment. The axial forces in a motor like this are tremendous and the imbalance of having just one steel segment makes it very difficult to line up the rotor halves and load the bearings instead of just having one half slam down on the face of the stator segment. The "solution" I pursued was one of undersized axial spacers that, when they go into tension, pull on the rotor halves with more force than the magnetic attraction of the single segment. Like this:


The problem was that we didn't design the rotor back-iron to screw into the spacers from the side. And I had already put the magnets in... Time for some very careful drilling.

On the plus side, it is self-fixturing and has built-in chip collection.


Not wanting to cut too much on the first try, I left them a little long. As expected, it was impossible to get an air gap on both sides of the stator segment. One or the other rotor half would just slam down:


In the end, I wound up making the spacers a good 0.020" undersized. This sounds huge, and I expect some of it is actually being taken up by the rotor back iron flexing. But whatever, it got the job done:

Air gap on both sides!

I'm not thrilled with this solution. Mostly because I don't think it's stiff enough to last. I am fairly convinced that what's really needed is a no-nonsense 1/2"-thick solid aluminum can that goes around the whole thing. It would do the job of both the magnet retaining rings and the spacers. I will look into this option. But for now, I need a steel can. Here's why:

(Warning: Science Content)
************************
I learned in freshman physics (the hardest class I took at MIT?) that if something looks symmetric, it probably is. The full axial motor certainly looks symmetric. But this version with one tooth...certainly not. Well, how to trick it into thinking it's symmetric? Mostly, I care about the magnetic circuit formed between the rotor disks, stator segments, and permanent magnets. In the case of symmetry, there's no telling which rotor half is which. They should therefore be at the same magnetic potential.

With just one stator segment, though, there is no clear return path for magnetic flux and the rotor halves will rapidly shift from "N" to "S" as the motor rotates, shooting off field lines into space for lack of a better place to put them. Not good. Solution: connect them with a giant steel can. This will force them to be at the same magnetic potential, just as a wire forces two nodes to have the same voltage. This is probably a close approximation to the symmetric case with all stator segments in place.
************************

So, I need to make a giant steel can, preferably not out of one solid piece of steel since it would be very hard to make. On radial motors, this might be called a flux jacket. Cue the giant role of sheet stock:

Don't worry, it's not a solid roll. It's only about 3/16" thick.

The dotted line is where I will be attacking it with a cutoff disk. The enormous hose clamps are to keep it rolled up. (It's under an incredible amount of tension.) They might also be useful for squeezing it down to the correct diameter. I'm sort-of winging this part, since it isn't part of the real motor, so don't expect much...

I also need a way to spin the motor so that I can measure the back EMF of the single stator winding. Chain drive seems like a good option, for reasons that will become clear momentarily. I made some quick disconnect hubs...


...which I lost for an hour in MITERS. Turns out after cutting them off I, without noticing, put them on the lathe tool holder post and then put the regular tool holder back on top of them:


No wonder I couldn't find them. Anyway, they provide a quick mounting solution for sprockets of various sizes and tooth counts. Altogether, the motor (minus its forthcoming flux jacket) looks like this now:


So all that's left is to find a suitable test rig. Normally when I test a motor, I just stick it in a drill and hook up the leads to a scope. But this is...bigger. The test rig will need enough torque to overcome the large cogging force of the single, unbalanced stator segment. And it will need to get up to a high enough speed that the rotor inertia damps out the speed ripple created by this cogging. I only have access to one machine with enough power to pull this off:


You might be surprised, but this is only the second most dangerous thing ever to be driven by the kart motor. (The kart itself is the third and last.) The first...well I don't talk about that anymore.

Actually, I'm not that worried. The biggest problem will be vibrations. It's going to vibrate like crazy with just one stator segment. I predict I will only get about 10-30 seconds of useful data collection time per run before something breaks. My money is on the spacers. When your experiment is almost guaranteed to end in catastrophic failure, you can't be disappointed. And you take appropriate safety precautions such as not being near it when it does. Everything will be recorded on high-speed video, including a scope channel with the back EMF, while I stand...somewhere else.

As for the future of this project...well, if the back EMF test fails miserably that's easy. If it actually works, well then it may or may not continue. I don't really have a use for this motor, nor does anyone else around here, really. It's meant to be cheap, easy to build, and easy to test. But for me, with my resources, it is none of those. I'm pretty sure somebody else with more skill and access to better equipment could build this motor or a better one in much less time. It's still fun, though, and a good learning experience. So, I'd like to finish it, but no guarantees.

For now, insane, one-shot, near-certain-destruction testing awaits!



Tuesday, January 19, 2010

Arrrrr, see?

Pirate radio...control.

I've been wanting to get my hands on a serious RC vehicle for some time now. Here it is:


It's a Team Associated TC4, 1/1oth scale 4WD remote-controlled car. Ignore the absurd-looking battery pack; I have no idea where that came from. I was lucky enough to get some drive time on the one nice day of weather we've had in the Boston area in the last two months. Conclusion: This thing is fun. I have literally zero RC experience (although I have driven robots) , but this seemed to be fairly easy to get the hang of, at least up to moderate speeds. Maybe it's the 4WD.

The car itself is mind-bogglingly impressive in mechanical detail. It's a shaft-driven 4WD with two ball differentials. There is no center differential, but the front and rear can be adjusted for more or less slip. It's got four-wheel independent suspension with adjustable springs and shocks. Lots of tiny screws, ball joints, linkages, all with tweakable settings. I don't even know where to start...

...Oh wait, yes I do: the motor.


This is the stock motor, a Reedy Radon brushed DC motor which has but one spec: 30,000 RPM. Thanks a lot. If there's one thing I hate about RC components it's the downright lack of real documentation. Coming from the world of robotic and electric vehicle components, it bothers me a lot to have a motor with no specs. So in case anyone else in the whole wide web is wondering, I decided to go ahead and measure the Reedy Radon using standard DC motor specifications: torque constant, back EMF constant, and winding resistance. Here ya go:
  • Motor: Reedy Radon
  • Type: Brushed DC
  • Turns: 17
  • Winding Resistance: ~69mΩ
  • Torque Constant: 0.00262 N-m/A
  • Back EMF Constant: 0.00262 V/(rad/s)
  • "kV": 3,650 RPM/V
(The resistance is only approximate because brushed motor resistance is sort-of hard to nail down. It depends a good deal on the brushes.)

And yes, if you use a fully-charged 7.2V NiCad battery pack, this nets you about 30,000RPM, which with the stock gearing is about 30mph. If you use a 9.9V A123 26650 pack, then you are just insane. And yes, this is quite a lot of punch for a three-pound car:


Cue gratuitous use of high-speed cameras.

It would be hard, then, for me to say something bad about this motor. In fact, I love brushed motors and for $23 this seems like a terrific option with plenty of power. But seriously do you think I could live with myself if I didn't at least try putting a brushless motor in it? The problem is, brushless motors for RC cars are expensive. Here are just a few examples:

CMS 36-4600 (Castle Creations, $100)
Velineon 3500 (Traxxas, $75)
Reedy 5000kV (Team Associated, $50)

Also, they are all specified by the wonderfully inverted "kV" rating. Higher kV means more RPM per Volt, so they go faster, right? Well...not really. That's only true if you're stuck with the voltage you're given. I'll take a low kV motor and a higher voltage any day. Conventional motor wisdom says this is almost always more efficient. In the age of lithium batteries, a 20V RC car is not unreasonable.

But still, I'm not paying $50-$100 for a motor that's easier to manufacture than the brushed one. And don't even get me started on controllers....RC controllers are amazing devices with unparalleled power density, but some of them are way overpriced. Interestingly, we live in a global economy and there are Inexpensive Chinese Brushless Motors (ICBMs, © 2010 Charles Guan, used without permission) on the market. I snagged this one for $15.95, minus my $2.99 Hobby King store credit (which I got for browsing but never buying anything). So what exactly does a $13 brushless motor look like?

Like this.

You're probably saying: "It has a reflective purple sticker and says 'HIGH TECH SUPER' on it. It must be a piece of garbage compared to those other motors." Well I don't know anything about those other motors because the RC companies don't publish any useful information about them. At least this motor is cheap enough for me to buy, ship, and test. Most importantly, I would like to know the torque constant and winding resistance so I can compare it to the stock motor. So I hooked it up to a dynamometer:

Yep.

Actually, I later figured out that 3.2mm motor shafts fit nicely into a 1/8" dremel collet, so I could do some higher-speed testing. The procedure is really simple: spin motor, measure back EMF on oscilloscope.


It's definitely not a trapezoid (ideal BLDC) or a sinusoid (ideal BLAC). It's more like a sinusoid with fifth harmonic added in. Try it. It's a two-pole motor with who-knows-what-kind-of-magnetization, so the odd shape is not surprising. Rather than fret about it, I chose instead to just use the RMS measure and pretend it was a sine wave. Using some motor math tricks, I can get a decent torque constant estimate this way. I can also measure the resistance very easily. Here are the results:
  • Motor: Hobby King 13.5T RC Car Motor
  • Type: Sensored BLDC
  • Turns: 13.5
  • Phase Resistance: 16mΩ
  • Torque Constant: 0.00314 N-m/A
  • Back EMF Constant: 0.00314 V/(rad/s)
Okay, 16mΩ is low. I'm pretty much sold on that spec alone. That's where motor heating (I²R losses) comes from, so the lower the better. And the torque constant? That's for sinusoidal drive, and it's higher than the stocked brushed motor. More torque per Amp and less I²R in the same size means better motor.

What about kV, though? I didn't list it because it has no clear meaning in sinusoidal drive. But I can say that I think it's significantly lower than the stated value of 3,150 RPM/V. Meaning, more torque, but higher voltage required for high speed. That's fine for me, since I wouldn't mind using a 6s (19.8V) A123 26650 pack. And my controller won't even run below 18V.

Oh, right, I forgot to mention the other important difference. Unlike the three more expensive brushless motors of the same size, this one is sensored. It has integrated Hall effect sensors that detect the position of the rotor, same as the scooter motors and the majority of small EV BLDC motors. Not only does that work perfectly with my controller, but it will give better starting torque.

This is one insane deal of a motor for $13. As long as it doesn't explode or something. I know you won't believe me until I actually put it in the car and demonstrate, so I should get on that. Hopefully by then the snow will melt and I can drive again.

Wednesday, January 13, 2010

3ph Duo Wrap-Up Part 2: Control

This is the conclusion to:
3ph Duo Wrap-Up Part 1: Field-Oriented

And falling squarely in the category of "ZOMG," the unabridged (but barely edited) 78-page Rev0 write-up that does not include specific software implementation at all yet because I am so sick of looking at it:
3ph Duo: 2 x 1kW Brushless Motor Controller
w/ Field Oriented Control
Design Notes [DRAFT]

It does have a lot of other cool stuff, though, including MOSFET selection and analysis, a more detailed F.O.C. explanation, BLDC vs. BLAC analysis, mechanical design, etc. etc. etc. I promise I will update it with some software details when I can stomach it again. Comments greatly appreciated...

When we left off, the controller was just barely able to generate six sine wave PWM outputs (three each for two motors) and estimate the position and speed of the rotor based on Hall effect sensors. Using this position estimate and current sensors, it could also measure the vector current, expressed in the two-dimensional d-q coordinate system we set up to make life easy. The purpose of Part 2 (of 2, thankfully) is to explain what we do with this information that makes field-oriented control so useful.

Part 1 hinted at the purpose of field-oriented control. (No, it's not just for making the motor quieter.) The goal is to place all of the current on the q-axis, right in between magnets, where it can pull hardest on the magnets and produce the most torque. Any current lagging behind onto the d-axis because of motor inductance is not doing useful work. This is now a controls problem.

I've taken just about every controls class at MIT (although I did drop a couple half-way through), so sometimes I take for granted that everyone understands the basics of a feedback control system. But for the sake of fulfilling my New Year's Resolution, I won't. The idea is really simple: You measure a value, in this case current, and compare it to the value you desire. If the desired value is higher than the measured value, you do something that will increase the current. If the desired value is lower than the measured value, you do something that will decrease the current. The result is a corrective action that always tries to bring the measured and desired values together. Textbook feedback loop:

Not that kind of plant. Plant is whatever thing you are controlling.

It's borderline common sense. If the water's too hot, you turn the heat down. If it's too cold, you turn the heat up. If you're good, you can predict the overshoot and preemptively turn the heat down so as not to burn yourself. Eventually, you get to the right temperature. Only by adding math do we manage to make control systems more complicated than that.

Anyway, this is what we can do with both the d-axis and the q-axis current that we figured out how to measure in Part 1. Enter the "synchronous current regulator," a special application of the textbook feedback loop to these types of motor control problems. It's synchronous because it works in the rotating d-q coordinate system we set up before. A block diagram is worth 1,000 words in this case:

Synchronous Current Regulator. Click to enlarge.

Calm down, calm down, it's not that bad. The circle with the M? That's the motor. The triangle? That's the three-phase inverter, i.e. all of the power electronics hardware. Everything else is software. The Park transform? That's the trigonometry part that projects the A, B, and C coil current measurements onto the d-axis and q-axis, just like in Part 1. It needs the rotor position to do so. Then there are two feedback controllers: one for the d-axis and one for the q-axis. The d-axis controller's desired value is always zero. The q-axis controller's desired value is the torque command, and can be positive (accelerate) or negative (brake). The outputs, called PWMs, are switching signals that set the average voltage command on each of the three phases.

Now, that's not exactly what I did, but it's pretty damn close. Here's mine:

Modified Synchronous Current Regulator. Click to enlarge.

The differences are small. Instead of an inverse Park transform to project back from d-axis and q-axis voltage commands to A, B, and C voltage commands, I use the fast-loop sine wave generator that caused so much trouble in Part 1. And instead of a magical rotor position measurement, likely derived from an encoder or resolver, I use Hall effect sensors and interpolation. I chose to do this because cheap motors have Hall effect sensors, not encoders or resolvers.

The feedback loops are the same. Well...not quite. The difference is what comes out of the d-axis and q-axis controllers. Can you spot it? In the standard version, a d-axis and q-axis voltage (PWM) come out, then get tranformed back into values for A, B, and C voltage. This requires more trig in the fast loop...not good for my poor little processor. In the modified version, a phase (angle) and magnitude come out of the d-axis and q-axis controllers, respectively. Phase is a simple shift in the sine table...no big deal. Magnitude is a scaling operation, which, as we saw in Part 1 is still a pain in the ass on a microcontroller with no hardware multiplier, but it's not as bad as more trig. At least it scales all three values equally.

Where the heck did that modification come from? It's actually one of the first things I wrote down, and I never considered doing it anyway else. It's the least processor-intensive and most physically intuitive, IMO, even if it's non-standard. But does it actually work? Well, after about a month of screwing around with software, I finally got to the point where I could run this controller in earnest, under load, with the modified synchronous current regulator. First, here's what happens when the d-axis controller is turned off, meaning no phase angle correction can be implemented...the same as fixed-timing:


This looks very similar to the measurement done in Part 1 on the front motor. As the motor increases in speed, the effect of current lag is more and more pronounced, putting more current on the d-axis. The rear motor shows the effect even more, since it has a higher inductance. The controller tries to keep the q-axis, torque-producing current constant. The result is that the total current, the vector sum of d-axis and q-axis components (or of A, B, and C components), must increase in order to maintain constant torque.

Now the same motor and load with the d-axis phase control on,


Plain as day, the phase advance takes out the d-axis current. Just 13º lead or so is all it takes on this motor at 600RPM. Meanwhile, the q-axis controller makes sure torque is held constant. If you want proof, look at the acceleration times in both cases...they are very similar. But in the case of full d- and q-axis control, the total current is reduced thanks to the zero d-axis component. This is clearly a more efficient operating point.

And just so you don't think I'm pulling your leg, it does work with two motors at the same time:

(Believe me, I did consider leaving this test out and hoping nobody would notice...)


Well there you have it, theorized and confirmed in experiment. The modified synchronous current regulator works. (I honestly was never sure it would, but I would have bet on it.) I can't compare it to the standard synchronous current regulator because the standard version simply would not run on my hardware. But, I did simulate the difference and I can assure you I was pleased with the result. If you don't believe me, read the unabridged version.

And that's the end of the 3ph Duo field-oriented control upgrade. What? Were you expecting some dramatic ending? That's not how things work when 90% of the upgrade is done in software. You do a lot of work for...something that looks the same as it did before. That's why there are no pictures of videos of real things in this post. The only good thing about code is that once you do it, you can copy-paste it for years. (Have you ever wondered where all my data comes from? I never talk about data acquisition software...)

Anyway, now that that's done, I feel the incredible urge to go build something. Something fast.....

Friday, January 8, 2010

3ph Duo Wrap-Up Part 1: Field-Oriented

After the single most difficult embedded programming challenge I've ever faced, I am finally ready to wrap-up the 3ph Duo field-oriented control upgrade. This is a slight hardware tweak and major software overhaul that, together, allow my dual-channel, 1-kW per channel brushless motor controller to operate as a true AC (sine wave) motor controller with field-oriented control. This post, Part 1 of 2, explains the "field-orienting" part. "Control" is left for Part 2. A massive (and I mean massive) write-up is also coming, if you really can't get enough of this stuff.

But my New Year's Resolution is to make my blog posts a little more understandable, so this might be a good time to review the big picture: What the heck is field-oriented control? And don't use any big words or cite any 355-page Master's theses. Okay, here's a motor with two magnets and three coils of wire:

To be more specific, it's a two-pole, three-phase outrunner motor. The stator has three coils, A, B, and C, spaced by 120º. The rotor has two magnets, N and S, spaced by 180º. It's about the simplest BLDC motor you could imagine, and thankfully the electrical coordinate system lines up with the physical coordinate system. Speaking of coordinate systems, let's define one:

The problem is 2-dimensional, so a simple set of perpendicular axes is useful. In motor control, the axes are called d (direct) and q (quadrature) instead of x and y, and they are defined with respect to the rotor. So, as the rotor rotates, so do the axes. The d-axis is always lined up with the magnets, and the q-axis is always 1/4-cycle ahead of the d-axis. (So, in the picture above, the motor is rotating counterclockwise.) If the motor had more poles, the axes would not be physically at right angles, but the d-axis would always be on magnets and the q-axis would always be in between magnets.

To get the motor to spin, the current is sent through the coils, turning them and the steel around them into electromagnets. These electromagnets attract or repel the permanent magnets. By alternating the direction of current in the coils, a rotational motion is created. Another way to look at it is that the coils are used to create a rotating magnetic field and the magnets are pulled along by this field.

The coils A, B, and C are aligned at 120º intervals, so any quantity (current, voltage, magnetic flux) that can be attributed to a coil has a particular direction to it. In other words, these quantities are vectors. As such, they can be projected onto any set of axes we want using simple trigonometry. In field-oriented control, these quantities are projected on the d-axis and q-axis as we have defined above. A simple example:


In this case, current is sent into coils B and C, and comes out of coil A. The magnitudes, represented by the lengths of the red arrows, are such that currents A+B+C = 0, since the coils are all connected at a single point. These three vectors, if added together, would give only d-axis current. (Current A has no q-axis component; B and C have equal and opposite components on the q-axis.)

But what does this mean for the motor? Well, the current passing through the coils turns them into electromagnets. The d-axis, which has the permanent magnets on it, would like to align itself with the electromagnet being created by the coils. In this case, it already is aligned. The motor is perfectly happy where it is and will resist being moved in either direction. To see how torque is produced, imagine this case:


Here, the resultant current is entirely on the q-axis. The magnets still want to align themselves with the current, though, so the rotor will try to rotate counterclockwise, producing torque as it does. By keeping the resultant current (the sum of the three current vectors, A, B, and C) on the q-axis as the motor rotates, the rotor is always trying to catch up and producing the maximum amount of torque.

The ultimate goal of field-oriented control is to be able to directly control both the magnitude and the angle of the total current vector by using the individual coils. Since the angle is defined with respect to the rotor, this requires knowledge of the rotor position. In order to make the vector math easier, everything is assumed to be a sine wave and the power electronics used to drive the coils produce a sine wave ouput.

This is very different than traditional BLDC control where the output is a square wave, and there is no knowledge or control of the current angle. In BLDC controllers, the timing of coil firing is fixed by Hall-effect sensors. Why not just fix the timing so that the coil fires on the q-axis, you say? Well, you can, and for most motors this works pretty well. However, the coils are also inductors, and inductors resist rapid changes in current. Thus, it takes time for current to build up in the coil after it has been fired. This delay means that although you may be firing on the q-axis, some current will lag behind and wind up on the d-axis:


Because the current is no longer on the q-axis exclusively, torque and/or efficiency are reduced. The actual angle by which the current lags is a function of motor inductance, resistance, and speed, so it is very difficult to predict the lag ahead of time and dead-reckon the correct coil firing time. (Some controllers do this! You will get back some of the torque, of course.) Field-oriented control can directly measure and control this effect. This post will focus on the measurement aspect, arguably the hardest part. Part 2 will focus on control.

In this ECN article, Daniel Torres says:
The most common technique utilized for controlling BLDC motors is trapezoidal control. However, both PMSM and BLDC motors can be controlled using sinusoidal control and Field Oriented Control (FOC).

FOC has become more popular in recent years, due to the fact that the cost required to implement this technique is no longer a constraint. The available technology and manufacturing processes now make it possible to implement this control technique in a 16-bit, fixed-point machine, such as Microchip’s dsPIC Digital Signal Controllers (DSCs).
And here are some application notes specific to the dsPIC that illustrate sinusoidal control and field-oriented control of BLDC motors:

AN1017: Sinusoidal Control of PMSM Motors with dsPIC30F DSC
AN1078: Sensorless Field Oriented Control of PMSM Motors
These very informative application notes both use the dsPIC30F, which, I will grant, is a fixed-point 16-bit processor. (It doesn't have hardware floating-point capability like an ARM or Pentium processor might have). But what it does have that my poor little MSP430F2274 does not is a 30Mhz instruction clock and single-cycle multiplier. Without the hardware mutiplier, the processor can only multiply by a power of 2 or add things together, meaning it takes several shift/add steps to multiply two arbitrary numbers by each other. In other words, while the dsPIC can multiply two numbers together in 33 nanoseconds (!!) it takes me somewhere in the neighborhood of 4,000 nanoseconds. :(

With that in mind, what exactly needs to happen for my controller to be able to execute sinusoidal, field-oriented control? First, let's focus on the sine wave part. As it turns out, this was the most difficult part of my particular endeavor. The hardware for producing a sine wave output is virtually the same as it is for square-wave BLDC control: six transistors (MOSFET or IGBT) switching at high speed to produce three voltages on the motor terminals. I'll spare you the details, but they'll be in the final write-up.

Although it didn't start out as such, my control program wound up converging on a pretty typical fast loop/slow loop configuration. The fast loop, which caused all the problems, handles sine wave generation and runs at the switching frequency of the transistors, which in this case is about 14.4kHz. This loop is responsible for looking up the base voltages from a table of sine values (doing actual trigonometry is out of the question) and then scaling them by some magnitude. It is also responsible for estimating rotor speed and position, which unfortunately involves a division. The problem here is that, while Daniel Torres insists it can be done, I don't have a hardware multiplier for scaling. Oh, and I need to do it for two motors. So how screwed was I? This little test reveals how screwed:


What you see there is a signal that turns on at the start of every 14.4kHz fast loop and turns off when the fast loop code is finished. In the 69 microseconds between each cycle, I needed to do six look-ups, six scaling operations, and occasionally two divisions! (Remember that each multiply takes about 4 microseconds.) The brighter line is the time it takes when not doing the divisions. The dimmer line is the extra time it takes to do the two divisions. You can see the code did finish in time, but only just barely, with about 2 microseconds to spare for all the other processes, including the slow control loop! You know how your computer gets when one program starts using 99% of the processor? Yeah, that's what happens. And occasionally the fast loop code would not finish on time...then very bad things happen. I needed to get back at least a tiny bit of processor time for the slow loop. (Or, you know, get a faster controller or just settle for one motor. NO!)

Here are just a few of the many tricks I needed to pull for this to work:
  1. You don't need to calculate all three values for each motor. Since they are balanced sine waves, A+B+C = 0 applies. It is sufficient to look up and scale two, then do a simple subtraction to find the third. This was hugely important.
  2. It's faster to use a variable zero-sequence voltage. I made a horrible attempt to explain this in a previous post. It basically means not adding in an extra offset to center the sine waves at half the DC (battery) voltage.
  3. 99.999% of the time, the motor speeds aren't calculated in the same fast loop. This is because a Hall-effect sensor triggers the calculation, and the chance of two coming in at the same time is very slim. But when it happens, the two divisions can cause the fast loop to fail. The simple solution: don't even try processing two. If they both come in, make one wait until the next cycle. An extra 69 microseconds is not going to make much of a difference to the speed calculation.
The result is a fast loop with a lot more cushion:


Now even with a division, the loop finishes in 53 microseconds. This leaves plenty of time for the slow loop to sneak in some processing time each cycle. The slow loop, which only runs once every 8.2 milliseconds, has plenty of time, about 120 fast loop cycles, to finish. This is time-division multi-threading...on an embedded processor. Wheeeeee!

The slow loop, running in these gaps of left-over processing time, does all the real work. It measures currents, voltages, throttle signals, initiates wireless data communication, and, oh yeah, it runs the control loop. But that's a topic for Part 2 of this wrap-up. The important thing to mention now is that, despite being slow, the loop knows the position of the rotor at the moment when current is measured in all three coils. (Okay, again, only two are measured. The third is calculated from A+B+C = 0.) So, it can project the three currents onto the d-axis and q-axis just like in the example above. Thus, the field is oriented! We know exactly where it is, even when it is lagging behind our coil timing.

Here is an example of this measurement, done on the front scooter motor under load:


What you see there is exactly what you would expect with no control of the coil timing, if they are fired at the same angle no matter what. The q-axis current is held steady at 20A. (The controller does do this.) But as the motor increases in speed, some current starts to lag into the d-axis. You could, in fact, use this data to estimate the motor inductance. (Actually, you need to know its resistance as well.) Sparing you the details, which will be in the huge write-up, you get about 0.1mH, which is about right...at least the right order of magnitude.

So the current lag really does exist, even on motors with relatively low inductance. The rear scooter motor is even more susceptible, since it has more turns per winding and thus a higher inductance. But if you have an accurate measurement of the current as a vector, with the d-axis and q-axis components known, it is a simple matter to advance the coil timing in real time to make up for the lag. This is the topic for next week, though, since this post is already too long! Also because my plant threw a tire so I can't take any more data until I get more urethane glue...

I have awesome plants.

Tuesday, January 5, 2010

"The problem with your blog is, I can't understand any of it." -Ken Colton

Happy New Year! Time for my first post of twenty-oh-ten. My New Year's resolution is to work on my blog post explanations a little, if for no other reason that so that my brother (who made my awesome site banner^^^) can follow along when not reinventing the internet. Shouldn't be that hard...I just need to stop talking about software, right?

I'm back in Cambridge and back to work, getting ready for another fun-filled year of 2.007: Design and Manufacturing I (OpenCourseWare from last year for those of you working on your FREE MIT education). Although the stardard box of raw metal and plastic stock is pretty much unchanged, we have some new and exciting additions to the kit this year. For one, everyone gets there very own small fireworks Lithium Polymer battery and charger thanks to dirt cheap overseas manufacturing. There's a whole new line of servos and gearmotors this year, too, which means that I may finally be free of the curse of the Tamiya 72001 Planetary Gearbox Kit.

DO NOT WANT!!!

How about Project Updates?

Well I must admit I've been spending most of my project-time on making this microcontroller do impossible things that it wasn't designed for, like simultaneous field-oriented control of two motors. You might think I'm wasting my time, but allow me to motivate this with a scenario:

You're stranded on an island after a plane crash, but after hours of walking the shore you find a boat. This boat happens to be powered by two brushless motors, and it happens to come with all the batteries, power electronics, and maps and charts you'd need to make it home by dinner.

Motivated now?

But there's just one problem. Your boat is missing a controller. Your laptop, cell phone, and iPod were all destroyed in the crash. But wait, in your back pocket:

Yes, a TI-83.

That's the type of controller we're talking about here. A graphing calculator. Not even a new one. That's roughly the processing power equivalent of the MSP430F2274. But hey, it's all you got. At least it's better than an Arduino. Oh, and also, it isn't sufficient to control one motor, because clearly the boat will go in circles. So now you see why this is important. And if you're already putting in the effort, you might as well make it quiet.

Well if I was stranded on an island, I would have starved to death, because I've been working on the software for this thing for two weeks now (not including the holiday break). Software, though, is a thankless job that produces literally no tangible evidence of progress, which is part of the reason why my recent blog posts have degraded to pretty much indecipherable gibberish (that I assure you is cleverly-constructed and efficient code) .....

BUT NO MORE. Next, I will show an actual, measurable result. And it's more than just that the motor runs more quietly...that's a nice bonus, but it's not the ultimate goal of the upgrade. Look for a post by the end of the week.

And how about the other projects? Well, I plan to do some serious work on the axial motor this month. Even if it's doomed to failure, I'd like to get there quickly. First step is to make some combination hub adapters / bearing retaining plates. Then, spacers that will give the rotors at least some small chance of being aligned to each other. Then, assembly and the single-tooth test, which is about the most boring way to test a motor ever but gives me all the information I will need and costs nothing to do.

Those are the two big ones. Might throw in a brand new mini-project along the way...depending on how things go. 2010 begins.