I've updated my Hobby King large motor inventory checker:
http://web.mit.edu/scolton/www/aremelons.html
Previously it had only the three "melon"-class motors, so-called because at 80mm OD, they are roughly the size of melons. (So called by whom? What kind of melons? Not watermelons...) These motors haven't been in stock at Hobby King in quite a long time, though they are starting to pop up in other places.
But there are other large motor candidates that are interesting to keep track of, including the brand new shiny SK3 line, which is the new "grapefruit"-class of 63mm motors. Somewhat dissapointingly, the SK3-63xx motors are actually 59mm in outer diameter. (The old 63xx grapefruit-class motors were truly 63mm.)
That said, tinyKart's older-model SK-6374-170 motors are falling apart due to poor construction and lack of a large radial can bearing. (And unrelenting abuse...) I will try replacing them with SK3-6464-190's I bought for a potential tinyKart swap a while ago. They have a can bearing and should be able to run to higher speeds without shaking themselves apart. They also weigh 1/3lb less, each. But, they have a higher resistance (37mΩ as opposed to 23mΩ), so they will generate more heat and/or less torque. Testing to come soon...
In the large motor category, there is also a durian class and a guava class that are relatively new and nicely-built. If you're interested in inexpensive RC plane motors that can be re-purposed into electric vehicle traction applications, this consolidated inventory list might help you choose.
Showing posts with label motor. Show all posts
Showing posts with label motor. Show all posts
Tuesday, October 25, 2011
Friday, May 7, 2010
2.00thesis
Design and Prototyping Methods for Brushless Motors and Motor Control
Actually you should read James Mevey's thesis instead.
Actually you should read James Mevey's thesis instead.
Sunday, December 13, 2009
3ph Duo: Codefest, Part II
If nothing in my last post made any sense, this is what I was trying to say:
I used my good camera w/ directional microphone, and set up the scooter frame so that it would resonate. The difference is pretty clear here. Everything you hear translates to what you would feel while riding it, so the ride will be much smoother as well.
I finally worked out all the sign (+/-) kinks. The remaining task is to make it fault-tolerant and load test. The Hall effect sensors are not perfect, and they can occasionally throw in a false signal or miss a real signal. This becomes even more important when they are being relied upon for a speed estimate that drives the sine waves. The motor and MOSFETs should be able to tolerate a glitch like this, but at high speeds it can cause a draw-down on the main capacitor, which can sometimes cause the microcontroller to spontaneously jump out of the program loop. So it would be better if this didn't happen...
More to come.
I used my good camera w/ directional microphone, and set up the scooter frame so that it would resonate. The difference is pretty clear here. Everything you hear translates to what you would feel while riding it, so the ride will be much smoother as well.
I finally worked out all the sign (+/-) kinks. The remaining task is to make it fault-tolerant and load test. The Hall effect sensors are not perfect, and they can occasionally throw in a false signal or miss a real signal. This becomes even more important when they are being relied upon for a speed estimate that drives the sine waves. The motor and MOSFETs should be able to tolerate a glitch like this, but at high speeds it can cause a draw-down on the main capacitor, which can sometimes cause the microcontroller to spontaneously jump out of the program loop. So it would be better if this didn't happen...
More to come.
Thursday, December 10, 2009
3ph Duo: Codefest
These days, most people are surprised when I tell them that my background is in mechanical engineering, not electrical, since more often then not I am troubleshooting some circuit or winding a giant inductor or something. But probably the thing that nobody knows is that my real background is in software. Okay, not in the educational sense, but I've been programming things since I was like...ten. I won't make any claims about my actual skill, but I will say that on more than one occasion I have been saved by a bit of software fidgeting that I probably couldn't have done if I hadn't been writing all those games (e.g. Pokemon Hunter and Pokemon Hunter II) when I was too little to use power tools.
In one of the saddest tragedies of my life, the original source code for Pokemon Hunter (written in QBASIC!) has been lost forever, but I assure you the graphics looked roughly like this.
In one of the saddest tragedies of my life, the original source code for Pokemon Hunter (written in QBASIC!) has been lost forever, but I assure you the graphics looked roughly like this.Oh yeah, this is a post about my brushless motor controller. Or, the latest of them, anyway. If you've lost track, here is a side-by-side comparison of the three real iterations it has gone through:
Left-to-Right: Newest, Middle, Oldest
Left-to-Right: Newest, Middle, OldestFirst was the double-stack IRFB3077-based controller (right), my very first shot at three-phase brushless motor control. While it has the distinction of MOSFETs so powerful they caused the aluminum bus bars to desolder themselves (Yes, you can solder aluminum.), it was impractically large for the scooter because each one only controlled one motor. Next was the greatly compacted 3ph Duo, so named because it controlled two motors from a single board using two IXYS GWM 100-01X1 six-pack MOSFET bridges as the inverter stages. And it works. But as I described in the last post, that won't stop me from making yet another one.
The most obvious visible change is the lack of LEM current sensors. These were large and expensive and have been replaced by the ACS714 surface-mount sensors, two each per motor. Two each so that I can effectively measure three-phase currents, instead of assuming that only two phases conduct current at a given time. If you want to know more about why I am concerned with this, this post sort-of sums it up. The goal is to implement full sine wave commutation with the possibility of phase adjustment, something that would separate this controller from other similarly sized and priced small vehicle brushless motor controllers on the market. Turns out from a hardware standpoint, this is very easy. The microcontroller I use, the TI MSP430F2274 already has six independent PWM output channels (three per motor). So the circuit board is essentially the same, with a few signals re-routed to make room for the six PWM pins.
The real challenge is the software. This is not a 32-bit processor with native floating-point. It is a regular old 16-bit mixed-signal processor that runs at a relatively poky 16Mhz and doesn't even have hardware multiply. Your cell phone probably has 10x more processing power. To roughly lay out the challenge: the PWMs are refreshed at a rate of 15kHz, setting the upper limit on the resolution of the sine waves generated. (You get 15,000 points per second with which to draw the sine function.) But to use all 15,000 points per second, six PWM values must be generated and scaled appropriately at every refresh. The clock speed is 16MHz, so all this has to happen in less than 1,000 clock cycles. To give you an idea of how hard this is, just multiplying two integer numbers together takes about 70 clock cycles on this chip. Forget about fractions and definitely forget about trigonometric functions. The only way to generate a sine wave is to use a look-up table, in this case 256 bytes in memory that store the value of the sine function for various angles. To set a baseline, this is how I originally implemented a sine-wave look-up on six channels:
The most obvious visible change is the lack of LEM current sensors. These were large and expensive and have been replaced by the ACS714 surface-mount sensors, two each per motor. Two each so that I can effectively measure three-phase currents, instead of assuming that only two phases conduct current at a given time. If you want to know more about why I am concerned with this, this post sort-of sums it up. The goal is to implement full sine wave commutation with the possibility of phase adjustment, something that would separate this controller from other similarly sized and priced small vehicle brushless motor controllers on the market. Turns out from a hardware standpoint, this is very easy. The microcontroller I use, the TI MSP430F2274 already has six independent PWM output channels (three per motor). So the circuit board is essentially the same, with a few signals re-routed to make room for the six PWM pins.
The real challenge is the software. This is not a 32-bit processor with native floating-point. It is a regular old 16-bit mixed-signal processor that runs at a relatively poky 16Mhz and doesn't even have hardware multiply. Your cell phone probably has 10x more processing power. To roughly lay out the challenge: the PWMs are refreshed at a rate of 15kHz, setting the upper limit on the resolution of the sine waves generated. (You get 15,000 points per second with which to draw the sine function.) But to use all 15,000 points per second, six PWM values must be generated and scaled appropriately at every refresh. The clock speed is 16MHz, so all this has to happen in less than 1,000 clock cycles. To give you an idea of how hard this is, just multiplying two integer numbers together takes about 70 clock cycles on this chip. Forget about fractions and definitely forget about trigonometric functions. The only way to generate a sine wave is to use a look-up table, in this case 256 bytes in memory that store the value of the sine function for various angles. To set a baseline, this is how I originally implemented a sine-wave look-up on six channels:
aidx_int += aspeed;
aidx = aidx_int >> 8;
atemp = SIN8LUT[aidx];
btemp = SIN8LUT[(unsigned char)(aidx - TWOTHIRDSPI)];
ctemp = SIN8LUT[(unsigned char)(aidx + TWOTHIRDSPI)];
atemp = 65023 - ((atemp * amag) >> 6) + ((127 * amag) >> 6);
btemp = 65023 - ((btemp * amag) >> 6) + ((127 * amag) >> 6);
ctemp = 65023 - ((ctemp * amag) >> 6) + ((127 * amag) >> 6);
uidx_int += uspeed;
uidx = uidx_int >> 8;
utemp = SIN8LUT[uidx];
vtemp = SIN8LUT[(unsigned char)(uidx - TWOTHIRDSPI)];
wtemp = SIN8LUT[(unsigned char)(uidx + TWOTHIRDSPI)];
utemp = 65023 - ((utemp * umag) >> 6) + ((127 * umag) >> 6);
vtemp = 65023 - ((vtemp * umag) >> 6) + ((127 * umag) >> 6);
wtemp = 65023 - ((wtemp * umag) >> 6) + ((127 * umag) >> 6);
One motor is ABC, the other is UVW. This steps through the sine table at some speed, looking up values with an independent index for each motor. Then, it scales those values by some magnitude and shifts them such that their PWM-average outputs are sine wave voltages centered at half the DC voltage:
The PWM outputs, normalized to the DC (battery) voltage, for full-command (top) and half-command (bottom). In both cases, they are centered at half the battery voltage.
The PWM outputs, normalized to the DC (battery) voltage, for full-command (top) and half-command (bottom). In both cases, they are centered at half the battery voltage.
Well, this almost worked. It worked with 1, 2, 3, and 4 channels. But with 5 or 6 channels, the interrupts starting running into each other because it took longer than 1,000 clock cycles to get through that block of code. Luckily, it's not a very efficient way of doing things, so the next few paragraphs will describe how it was trimmed down. First, the zero-sequence hack. I don't know of anyone who refers to it as such, but this is my favorite motor code hack of all time. A lot of the code above is being used simply to offset the PWM values so that they are always centered at 50% duty cycle. This is...stupid. (Maybe not, but I declare it to be so.) So I ditched that drive method in favor of one that always puts the peak of the sine waves at +Vbat, like this:
The modified drive signals at full-command (top) and half-command (bottom).
The modified drive signals at full-command (top) and half-command (bottom).
The difference is that, except at full command, the three sine waves are shifted up to higher voltages with respect to the battery. But what really matters, as far as the motor is concerned, is the relative voltage across the three phases, which is the same in either case. The same amount of current will come out of or go into each wire, and the bulk shift does not change the motor operation. It does, however, greatly simplify the code:
This signal is high when the processor is in a PWM interrupt executing the above block of code.
aidx_int += aspeed;The extra multiplication of the magnitude to get the sine waves in the right place is gone. So is the bulk offset. All that's left is a negative of the magnitude times the sine value. (Don't ask why it's negative...you don't want to know.) This manipulation gets the interrupt routine down to a size where it can actually run at 15kHz...barely. The processor utilization is up near 60%:
aidx = aidx_int >> 8;
atemp = SIN8LUT[aidx];
btemp = SIN8LUT[(unsigned char)(aidx - TWOTHIRDSPI)];
ctemp = SIN8LUT[(unsigned char)(aidx + TWOTHIRDSPI)];
atemp = -((atemp * amag) >> 6);
btemp = -((btemp * amag) >> 6);
ctemp = -((ctemp * amag) >> 6);
uidx_int += uspeed;
uidx = uidx_int >> 8;
utemp = SIN8LUT[uidx];
vtemp = SIN8LUT[(unsigned char)(uidx - TWOTHIRDSPI)];
wtemp = SIN8LUT[(unsigned char)(uidx + TWOTHIRDSPI)];
utemp = -((utemp * umag) >> 6);
vtemp = -((vtemp * umag) >> 6);
wtemp = -((wtemp * umag) >> 6);
This signal is high when the processor is in a PWM interrupt executing the above block of code.Of that, roughly half of the time is spent just doing the six multiplications. There are tricks for fast software multiplication, but only if one of the operands is known a priori (not the case here). The sine table look-ups, as fast as they are, also take up some time. The adds and shifts are relatively small contributions. Amazingly, though, this actually works. Try getting your computer to do anything when its processor is being utilized by background processes 60% of the time. (Okay, dual core...I know...) But this can still execute a slow loop with control and data acquisition functions and read in more interrupts from the hall-effect sensors. It's still a little quirky, but it didn't collapse in a mess of horrible interrupt stack Jenga blocks like I thought it might.
But...it can actually be even more efficient. The key observation is in the nature of the outputs, a balanced three-phase set of voltages. This type of output only really has two degrees of freedome...magnitude and phase. So you should really only have to look up two numbers, right? (Can you see it coming?) If you add the sine of any three angles separated by 120º each, you get zero. Try it. Or have Wolfram Alpha try it. Here's my proposal: Look up and scale two sine values per motor. The third is the sum of the first two, negated. C = -(A+B). W = -(U+V). It's a bit more complicated because of magnitude offsets, but if this offset is calculated based on the magnitude in the slow loop, it can be simply added to the third value:
That's a far stretch in the name of efficient computation, but I assure you it makes a difference. Although everything seemed to be more-or-less working even with the bulkier interrupt. It's always good to write simple code, for many reasons. Which reminds me of another good one:
Yep, finally ran out of program memory. And I sure as hell am not going to buy the $N,000 full version of IAR Embedded Workbench. For the record, no compiler is worth that much money. It's not like Solidworks or some specialized simulation program that costs a lot of money to develop. It's a f*cking compiler. It takes C code and makes assembly code based on a set of well-understood standards. Even if I were using it for a commercially, it would be more worth my time to get a free GCC compiler and learn how to use Eclipse. Screw you, IAR. But I love your free version. :) So I will just have to keep my code size down.
Now might be a good time to step back and ask what the heck I am doing. Optimizing this one timy bit of code is a long way from making a new sine-commutated motor controller, and I have a long way to go before I can say I've finished the latter. But with the sine wave generator running at 15kHz in the background, all that's really left is to integrate the Hall effect sensors and some sort of master control loop.
The Hall effect sensors are really easy...dare I say easier than they are with the normal six-step commutation scheme where they drive a state machine. When a sensor hit comes in, you abandon whatever position you were at before and jump to the "correct" place in the sine table. "Correct" is tricky, and this is where a phase offset can be added in. But for now, I will rely on the scooter's moveable Hall sensors to make this work. The other piece of the puzzle is to set the speed of advance through the sine table, aspeed and uspeed in the code above. This is done by (carefully) estimating the time of one electrical cycle, which is six Hall effect transitions or in this case 1/7th of a revolution. I say carefully because this breaks down at low speed and also can be "glitchy". So there is more software work to be done here.
Lastly, the master control loop. This is where the high-level implementation happens. Eventually, this will hopefully measure and control both the quadrature- and the direct-axis current. The quadrature-axis current is the current that actually pulls on the magnets, creating torque. The direct-axis current can be used to change the torque-speed curve by countering the magnets, but I doubt this will make much difference for the scooter motors. Anyway, there is still some work to be done before this method of control is fully functional. For now, it is easy enough to create something that works by just controlling some semi-arbitrary current measurement, or even just running it open loop. This is where I am now...testing the subsystems to make sure they are working reliably before I integrate everything in the master loop.
But that didn't stop me from trying to ride it. The most noticeable difference (besides the fear that it might jump out of the program loop and short the motor at any moment) is the reduced torque ripple. You can actually hear the difference between DC (six-step) operation and AC (sine wave) operaiton. Okay, maybe you can't really hear the difference...but that's mostly because my microphone is terrible and the sensors were still not quite in the right place in either case. But there is definitely less high-frequency noise. If you don't believe me, believe MATLAB:
I promise I will do a better job capturing the results in a future update. That is, assuming I don't go crazy from debugging software. It's usually not my favorite thing to do. There's some fun in squeezing every last drop of computational power out of this thing, but I would still rather be making something tangible. Although in the end that's what this is for, so that's one plus. And if things go downhill, the old controller worked perfectly fine. Which...hrm...why am I doing this again?
I also promise a massive technical write-up for anyone who is interested in how this thing actually works. Ha...funny...nobody cares about controller. But there will be a write-up nonetheless.
But...it can actually be even more efficient. The key observation is in the nature of the outputs, a balanced three-phase set of voltages. This type of output only really has two degrees of freedome...magnitude and phase. So you should really only have to look up two numbers, right? (Can you see it coming?) If you add the sine of any three angles separated by 120º each, you get zero. Try it. Or have Wolfram Alpha try it. Here's my proposal: Look up and scale two sine values per motor. The third is the sum of the first two, negated. C = -(A+B). W = -(U+V). It's a bit more complicated because of magnitude offsets, but if this offset is calculated based on the magnitude in the slow loop, it can be simply added to the third value:
uidx_int += uspeed;That's two fewer table look-ups and two fewer multiplies. The resulting interrupt should run 30% faster, giving back valuable clock time. Again, don't ask why everything is negated...
uidx = uidx_int >> 8;
utemp = SIN8LUT[uidx];
vtemp = SIN8LUT[(unsigned char)(uidx - TWOTHIRDSPI)];
utemp = -((utemp * umag) >> 6);
vtemp = -((vtemp * umag) >> 6);
wtemp = utemp + vtemp - woffset;
aidx_int += aspeed;
aidx = aidx_int >> 8;
atemp = SIN8LUT[aidx];
btemp = SIN8LUT[(unsigned char)(aidx - TWOTHIRDSPI)];
atemp = -((atemp * amag) >> 6);
btemp = -((btemp * amag) >> 6);
ctemp = atemp + btemp - coffset;
That's a far stretch in the name of efficient computation, but I assure you it makes a difference. Although everything seemed to be more-or-less working even with the bulkier interrupt. It's always good to write simple code, for many reasons. Which reminds me of another good one:
Yep, finally ran out of program memory. And I sure as hell am not going to buy the $N,000 full version of IAR Embedded Workbench. For the record, no compiler is worth that much money. It's not like Solidworks or some specialized simulation program that costs a lot of money to develop. It's a f*cking compiler. It takes C code and makes assembly code based on a set of well-understood standards. Even if I were using it for a commercially, it would be more worth my time to get a free GCC compiler and learn how to use Eclipse. Screw you, IAR. But I love your free version. :) So I will just have to keep my code size down.
Now might be a good time to step back and ask what the heck I am doing. Optimizing this one timy bit of code is a long way from making a new sine-commutated motor controller, and I have a long way to go before I can say I've finished the latter. But with the sine wave generator running at 15kHz in the background, all that's really left is to integrate the Hall effect sensors and some sort of master control loop.
The Hall effect sensors are really easy...dare I say easier than they are with the normal six-step commutation scheme where they drive a state machine. When a sensor hit comes in, you abandon whatever position you were at before and jump to the "correct" place in the sine table. "Correct" is tricky, and this is where a phase offset can be added in. But for now, I will rely on the scooter's moveable Hall sensors to make this work. The other piece of the puzzle is to set the speed of advance through the sine table, aspeed and uspeed in the code above. This is done by (carefully) estimating the time of one electrical cycle, which is six Hall effect transitions or in this case 1/7th of a revolution. I say carefully because this breaks down at low speed and also can be "glitchy". So there is more software work to be done here.
Lastly, the master control loop. This is where the high-level implementation happens. Eventually, this will hopefully measure and control both the quadrature- and the direct-axis current. The quadrature-axis current is the current that actually pulls on the magnets, creating torque. The direct-axis current can be used to change the torque-speed curve by countering the magnets, but I doubt this will make much difference for the scooter motors. Anyway, there is still some work to be done before this method of control is fully functional. For now, it is easy enough to create something that works by just controlling some semi-arbitrary current measurement, or even just running it open loop. This is where I am now...testing the subsystems to make sure they are working reliably before I integrate everything in the master loop.
But that didn't stop me from trying to ride it. The most noticeable difference (besides the fear that it might jump out of the program loop and short the motor at any moment) is the reduced torque ripple. You can actually hear the difference between DC (six-step) operation and AC (sine wave) operaiton. Okay, maybe you can't really hear the difference...but that's mostly because my microphone is terrible and the sensors were still not quite in the right place in either case. But there is definitely less high-frequency noise. If you don't believe me, believe MATLAB:
I also promise a massive technical write-up for anyone who is interested in how this thing actually works. Ha...funny...nobody cares about controller. But there will be a write-up nonetheless.
Wednesday, November 25, 2009
Everything You Ever Wanted to Know About Brushless Motors
I've been doing a lot of reading lately about brushless motors and their control. Every once in a while I find a good application note or paper or website that makes something clearer to me. (Other times, the information I find contradicts other things I've read or just makes things more confusing.) But just last week I stumbled across the single most consistent and thorough explanation of motors I have ever seen, a Master's thesis by James Mevey from Kansas State.
Make no mistake, this is not a quick read (355 pages), and it requires a basic background in electromagnetism, circuit theory, and electric machine theory. But I promise you that if you have at any point been frustrated by the inconsistent or incomplete treatment of electic motors found on the interwebs, or by the abstracted and overly complex theory in research papers and electric machine textbooks, this report is what you've been missing.
It's clear that the author put a tremendous amount of effort into this thesis, more than I can even comprehend.The explanations are clear, but not simplified. The notations are internally consistent and many (most?) variations found in other literature are explained and compared in tables, charts, and figures. Oh, the figures! They are all HAND DRAWN. And not like my hand drawn pictures.
Is that a jellyfish stuck inside an axial flux motor?
Make no mistake, this is not a quick read (355 pages), and it requires a basic background in electromagnetism, circuit theory, and electric machine theory. But I promise you that if you have at any point been frustrated by the inconsistent or incomplete treatment of electic motors found on the interwebs, or by the abstracted and overly complex theory in research papers and electric machine textbooks, this report is what you've been missing.
It's clear that the author put a tremendous amount of effort into this thesis, more than I can even comprehend.The explanations are clear, but not simplified. The notations are internally consistent and many (most?) variations found in other literature are explained and compared in tables, charts, and figures. Oh, the figures! They are all HAND DRAWN. And not like my hand drawn pictures.
Is that a jellyfish stuck inside an axial flux motor?No, nothing like that. These have all the nice scale and readability of computer-generated graphics, but with the friendly this-isn't-as-complicated-as-it-sounds style of whiteboard sketches. Almost like a comic strip. About electric mtors. Look for yourself!
Anyway, I'm not telling you to read the whole thing (yes I am) but I did. In case you're busy watching football or eating Thanksgiving dinner (I will be, but I already read it), I can do a book review-style highlight of the most important concepts that I got out of it, without going into detail or ruining the ending.
1. Back EMF and torque are two sides of the same coin.
I sort-of knew this already. In a brushed motor, the back EMF constant (relating voltage produced at the open motor terminals to the speed of the motor) and the torque constant (relating torque produced to the current passing through the motor) are the same number. The simple explanation for this is that after all the electrico-magneto-mechanical interactions that happen inside the motor, the only thing that really matters is power conservation. Pushing current into a voltage (such as the back EMF) is positive power. This results in a positive torque (torque attempting to increase the speed of the motor).
The conversion is lossless. All the losses are taken into account by adding resistors to the electrical model and/or damping to the mechanical model. So if you put 500 electrical Watts into the back EMF, you will get 500 mechanial Watts out. If you divide by the speed of the motor, this gives you the torque. This is always true. At zero speed, you can take the limit of this to find that torque is still proportional to current. For negative power (generating), you have to be pulling negative current out of a positive back EMF (or pushing positive current into a negative back EMF).
Anyway, I'm not telling you to read the whole thing (yes I am) but I did. In case you're busy watching football or eating Thanksgiving dinner (I will be, but I already read it), I can do a book review-style highlight of the most important concepts that I got out of it, without going into detail or ruining the ending.
1. Back EMF and torque are two sides of the same coin.
I sort-of knew this already. In a brushed motor, the back EMF constant (relating voltage produced at the open motor terminals to the speed of the motor) and the torque constant (relating torque produced to the current passing through the motor) are the same number. The simple explanation for this is that after all the electrico-magneto-mechanical interactions that happen inside the motor, the only thing that really matters is power conservation. Pushing current into a voltage (such as the back EMF) is positive power. This results in a positive torque (torque attempting to increase the speed of the motor).
The conversion is lossless. All the losses are taken into account by adding resistors to the electrical model and/or damping to the mechanical model. So if you put 500 electrical Watts into the back EMF, you will get 500 mechanial Watts out. If you divide by the speed of the motor, this gives you the torque. This is always true. At zero speed, you can take the limit of this to find that torque is still proportional to current. For negative power (generating), you have to be pulling negative current out of a positive back EMF (or pushing positive current into a negative back EMF).
The simple DC motor model.
The thing made clear to me by James Mevey's thesis was that this model works just as well for a brushless DC motor. The power conservation through back EMF works the same way. You can prove this using a few different E&M and/or field theory tricks. (He does all of them, for good measure.) But intuitively it also makes sense that there needs to be something to push against, namely the back EMF, for power to be converted. In the limit as the back EMF and speed go to zero, torque is still proportional to current.
But, unlike a brushed DC motor, the shape of the back EMF of each phase of a brushless motor is a function of rotor position and is periodic. It repeats every two poles, so for a 14-pole motor like on the scooter, it repeats seven times per revoltion. This base shape then gets scaled by the speed. It's as if the back EMF "constant" for a given phase is actually a periodic function of the rotor position. That's sort-of obvious, but the less obvious conclusion is that, taking the limit of the power conversion through the back EMF as speed approaches zero, the torque "constant" is the same period function of rotor position. So another way to look at it is that the torque produced by each phase is simply the base shape of this same rotor position-dependent function multiplied by the current going into the phase. This is also always true.
2. None of the above changes for trapezoidal (BLDC) vs. sinusoidal (BLAC/PMSM) motors.
Just by applying the very simple power-conserving back EMF idea, you can analyze any motor with any drive. I was wondering about the functional differences between BLDC and BLAC/PMSM. James Mevey says:
But, unlike a brushed DC motor, the shape of the back EMF of each phase of a brushless motor is a function of rotor position and is periodic. It repeats every two poles, so for a 14-pole motor like on the scooter, it repeats seven times per revoltion. This base shape then gets scaled by the speed. It's as if the back EMF "constant" for a given phase is actually a periodic function of the rotor position. That's sort-of obvious, but the less obvious conclusion is that, taking the limit of the power conversion through the back EMF as speed approaches zero, the torque "constant" is the same period function of rotor position. So another way to look at it is that the torque produced by each phase is simply the base shape of this same rotor position-dependent function multiplied by the current going into the phase. This is also always true.
2. None of the above changes for trapezoidal (BLDC) vs. sinusoidal (BLAC/PMSM) motors.
Just by applying the very simple power-conserving back EMF idea, you can analyze any motor with any drive. I was wondering about the functional differences between BLDC and BLAC/PMSM. James Mevey says:
"It is the author’s opinion that the difference between trap and sine BPMs is surrounded by more misunderstanding and confusion than any other subject in the field of brushless motor control..."I am inclined to agree. But this thesis makes it very clear that the only functional difference is the shape of the waveforms (both the back EMF and the drive waveform). BLDC refers to motors with more-or-less trapezoidal back EMF, common in small motors. Like this:
From the scooter motors, line-to-line and assumed line-to-neutral.
Why is it trapezoidal? This is entirely due to the geometry of the motor. It has nothing to do with the controller, which should be obvious (although for some reason it's not) since this measurement can be made with nothing attached to the motor at all. It has to do with the layout of magnets and coils and steel. The more you can see sharp transitions in magnets, coils, or steel, the more trapezoidal it becomes. This is common in small motors because it's easier to make a motor with concentrated windings and discrete, non-skewed magnets.
As a counter-example, larger motors often called "brushless AC" or "permanent magnet AC" tend to have skewed magnets and overlapped windings in a large number of slots, so their back EMF looks more sinusoidal. These motors can (should) be driven with a pure AC signal. If, for example, the back EMF and current are both sine waves that are in phase, and there are three balanced phases separated by 120º electrical, the power (torque) produced will be constant. Try adding together three sin^2 waves (current times backEMF) shifted by 1/3 period each. Or have Wolfram Alpha do it for you. There is clearly an advantage to having constant torque in things like large machines, electric vehicles, etc.
But what about BLDC motors with trapezoidal back EMFs? Well, this is where things get more interesting. You can drive them with a signal that looks like a square wave, except with gaps where the trapezoid has non-zero slope. Like this:
Ignore the blips.
To the extent which you back EMF is truly a trapezoid with a 120º-wide top, you can split the drive into six equal-length segments, two positive, two negative, and two off. By doing so, you get zero current during the sloped part of the trapezoid and full current during the flat part. Multiplying back EMF by current still gives power (torque). Accounting for all three phases, offset by 1/3 period each, also gives constant power (torque). This is the basis of brushless DC motor control. It's very simple to implement in software or even just pure logic chips. Since it relies only on 60º position estimates, it can be easily accomplished with three hall-effect sensors or with many sensorless estimation methods.
If they are simpler to make and to control, but yet still give constant ripple-free power, why not make all brushless motors this way? Well, for one, the purely trapezoidal back EMF is not realistic. It may not be as flat, for as long, as the 120º approximation. Things tend to smooth out into sinusoids if you let them. Which brings up the next point: what happens when you account for inductance?
That's the same square-wave drive, but now with a reasonable inductance factored in. Permanent magnet motors tend to have low inductance in general, but even so it still distorts the shape of the drive current at even modest speeds. It's not even a clean low-pass filter. That's because the drive inverter has flyback diodes start to conduct current during the "off" period. And on top of all that, the whole thing is phase-shifted so that current and back EMF no longer line up perfectly. The net result is a power (torque) fluctuation. The good news is that the fluctuation is at six times the commutation frequency, and so at high speed the system inertia easily damps it out. The bad news is it's still significantly lower than the torque produced at zero speed, since the low pass filter takes power out of the harmonics and moves the whole thing out of phase with the back EMF. The other bad news is that the diode conduction in the controller can start to cause more heating in otherwise highly-efficient MOSFET drives.
There is an obvious benefit to using sinusoidal drive, then. Everything, after passing through a low-pass filter, gets closer to looking like a sine wave anyway. You can also eliminate the diode conduction periods which throw the whole analysis off. And if your motor is designed to have sinusoidal back EMF, everything works nicely and all that's left are magnitude and phase shifts. To the extent which a trapezoidal motor can be thought of as having a fundamental sinusoidal component, some of the analysis used in sinusoidal drive can also be applied to trapezoidal motors, understanding that there will be harmonic distortion. But everthing still works within the back EMF power conservation analysis method for figuring out torque.
3. Field-oriented control is all about keeping current and back EMF in phase.
There are a lot of complicated ways to explain it, but the one that makes the most sense to me is that the goal of field-oriented control is to make up for the phase lag that comes in at high speed when the inductance start to become significant. Obviously for induction motors, there is more to it. But for permanent magnet motors, it's as simple as keeping the two sine waves (or whatever waves) of the back EMF and the current in phase as much as possible. This produces maximum torque, for reasons that should be obvious from the power conservation approach I keep mentioning.
The back EMF in a permanent magnet motor is fixed to the rotor position, always. This was another point of confusion for me, namely when it comes to field weakening. But field weakening is a lot simpler than I thought. It does not change the back EMF. The back EMF comes from the rotor magnets alone. What field weakening does is produce another field that fights the magnets in the air gap, reducing the flux to some degree. But this is all accounted for already! It's the inductor in the circuit! It's really that simple. But it only really makes sense if you look at things from the rotor reference frame, often called the d-q frame. (d = direct = in line with the magnet flux, q = quadrature = leading the magnet flux by 90º electrical). In this frame, there are only a few simple rules:
The first case is what things look like when the motor is spun up with no load. The voltage on the terminals (whether you apply it or not) is equal in magnitude to and in phase with the back EMF, which leads the magnets by 90 electrical degrees. (Keep in mind this whole picture is in electrical degrees, so you have to divide by the number of pole pairs to get the mechanical equivalent.) The second case is what happens when a load is applied to the motor without changing the relative position of the voltage. This would be like a simple hall-sensor or encoder based commutation that always fires the phases at the same position.,i.e. open-loop control. The problem is that at high speeds, current goes out of phase with back EMF, since some voltage is developed across the low pass filter. The sum of back EMF, voltage on the inductor, and voltage on the resistor is still equal to the voltage applied at the terminals, but this is a vector sum so things get tricky.
Now here are two cases where the relative phase of voltage can be controlled (advanced). For demonstration purposes, this could be done by physically rotating the position sensor on the motor. Obviously for control, it would instead be done by adding some phase offset in software. The left-most case is field-oriented torque control. The voltage is advanced to make up for the current lagging behind it. The net result is current in phase with back EMF, the theme of this story, and ideal torque. The right-most case is what happens when you advance the voltage even more. Now, current goes out of phase the other way, so some torque is lost. But, the other components of voltage rotate out of the way a little, allowing the back EMF (speed) to grow without increasing the voltage applied. This is field weakening. You trade off torque for a bit more speed. The back EMF could even be higher than the voltage applied, extending the speed range of the motor without increasing the DC supply voltage. How much of this you can get away with depends on the inductance of the motor. Generally, surface-mounted magnet motors have low inductance and limited field-weakening capability. But "limited' might still mean you can get 50% or 100% more speed!
To some extent, I knew this already. But the great thing about seeing it consistently presented is that I now understand why it works. And even more cool, I see that it's all part of the same, simple model. Everything is accounted for without even diving into the magnetic domain. You just measure back EMF, draw some triangles, and come up with the performance of the motor. It's all become simpler to comprehend because it fits into a minimalist model.
Now I have some more solid footing to stand on for the full-AC version of my controller. I can start thinking about field-oriented control, how it will interact with different motors (trapezoidal, sinusoidal) at different speeds, etc. I guess at heart I am more interested in motor control than in motors themselves, but as I can see now you can't understand one without the other!
READ IT! Here's the link again.
As a counter-example, larger motors often called "brushless AC" or "permanent magnet AC" tend to have skewed magnets and overlapped windings in a large number of slots, so their back EMF looks more sinusoidal. These motors can (should) be driven with a pure AC signal. If, for example, the back EMF and current are both sine waves that are in phase, and there are three balanced phases separated by 120º electrical, the power (torque) produced will be constant. Try adding together three sin^2 waves (current times backEMF) shifted by 1/3 period each. Or have Wolfram Alpha do it for you. There is clearly an advantage to having constant torque in things like large machines, electric vehicles, etc.
But what about BLDC motors with trapezoidal back EMFs? Well, this is where things get more interesting. You can drive them with a signal that looks like a square wave, except with gaps where the trapezoid has non-zero slope. Like this:
Ignore the blips.To the extent which you back EMF is truly a trapezoid with a 120º-wide top, you can split the drive into six equal-length segments, two positive, two negative, and two off. By doing so, you get zero current during the sloped part of the trapezoid and full current during the flat part. Multiplying back EMF by current still gives power (torque). Accounting for all three phases, offset by 1/3 period each, also gives constant power (torque). This is the basis of brushless DC motor control. It's very simple to implement in software or even just pure logic chips. Since it relies only on 60º position estimates, it can be easily accomplished with three hall-effect sensors or with many sensorless estimation methods.
If they are simpler to make and to control, but yet still give constant ripple-free power, why not make all brushless motors this way? Well, for one, the purely trapezoidal back EMF is not realistic. It may not be as flat, for as long, as the 120º approximation. Things tend to smooth out into sinusoids if you let them. Which brings up the next point: what happens when you account for inductance?
That's the same square-wave drive, but now with a reasonable inductance factored in. Permanent magnet motors tend to have low inductance in general, but even so it still distorts the shape of the drive current at even modest speeds. It's not even a clean low-pass filter. That's because the drive inverter has flyback diodes start to conduct current during the "off" period. And on top of all that, the whole thing is phase-shifted so that current and back EMF no longer line up perfectly. The net result is a power (torque) fluctuation. The good news is that the fluctuation is at six times the commutation frequency, and so at high speed the system inertia easily damps it out. The bad news is it's still significantly lower than the torque produced at zero speed, since the low pass filter takes power out of the harmonics and moves the whole thing out of phase with the back EMF. The other bad news is that the diode conduction in the controller can start to cause more heating in otherwise highly-efficient MOSFET drives.
There is an obvious benefit to using sinusoidal drive, then. Everything, after passing through a low-pass filter, gets closer to looking like a sine wave anyway. You can also eliminate the diode conduction periods which throw the whole analysis off. And if your motor is designed to have sinusoidal back EMF, everything works nicely and all that's left are magnitude and phase shifts. To the extent which a trapezoidal motor can be thought of as having a fundamental sinusoidal component, some of the analysis used in sinusoidal drive can also be applied to trapezoidal motors, understanding that there will be harmonic distortion. But everthing still works within the back EMF power conservation analysis method for figuring out torque.
3. Field-oriented control is all about keeping current and back EMF in phase.
There are a lot of complicated ways to explain it, but the one that makes the most sense to me is that the goal of field-oriented control is to make up for the phase lag that comes in at high speed when the inductance start to become significant. Obviously for induction motors, there is more to it. But for permanent magnet motors, it's as simple as keeping the two sine waves (or whatever waves) of the back EMF and the current in phase as much as possible. This produces maximum torque, for reasons that should be obvious from the power conservation approach I keep mentioning.
The back EMF in a permanent magnet motor is fixed to the rotor position, always. This was another point of confusion for me, namely when it comes to field weakening. But field weakening is a lot simpler than I thought. It does not change the back EMF. The back EMF comes from the rotor magnets alone. What field weakening does is produce another field that fights the magnets in the air gap, reducing the flux to some degree. But this is all accounted for already! It's the inductor in the circuit! It's really that simple. But it only really makes sense if you look at things from the rotor reference frame, often called the d-q frame. (d = direct = in line with the magnet flux, q = quadrature = leading the magnet flux by 90º electrical). In this frame, there are only a few simple rules:
- Back EMF leads magnet flux by 90º. That is, it is always on the q-axis.
- Voltage leads current by some amount determined by the motor inductance and resistance.
- Torque is proportional to the amount of current in phase with back EMF, i.e. the dot product.
The first case is what things look like when the motor is spun up with no load. The voltage on the terminals (whether you apply it or not) is equal in magnitude to and in phase with the back EMF, which leads the magnets by 90 electrical degrees. (Keep in mind this whole picture is in electrical degrees, so you have to divide by the number of pole pairs to get the mechanical equivalent.) The second case is what happens when a load is applied to the motor without changing the relative position of the voltage. This would be like a simple hall-sensor or encoder based commutation that always fires the phases at the same position.,i.e. open-loop control. The problem is that at high speeds, current goes out of phase with back EMF, since some voltage is developed across the low pass filter. The sum of back EMF, voltage on the inductor, and voltage on the resistor is still equal to the voltage applied at the terminals, but this is a vector sum so things get tricky.
Now here are two cases where the relative phase of voltage can be controlled (advanced). For demonstration purposes, this could be done by physically rotating the position sensor on the motor. Obviously for control, it would instead be done by adding some phase offset in software. The left-most case is field-oriented torque control. The voltage is advanced to make up for the current lagging behind it. The net result is current in phase with back EMF, the theme of this story, and ideal torque. The right-most case is what happens when you advance the voltage even more. Now, current goes out of phase the other way, so some torque is lost. But, the other components of voltage rotate out of the way a little, allowing the back EMF (speed) to grow without increasing the voltage applied. This is field weakening. You trade off torque for a bit more speed. The back EMF could even be higher than the voltage applied, extending the speed range of the motor without increasing the DC supply voltage. How much of this you can get away with depends on the inductance of the motor. Generally, surface-mounted magnet motors have low inductance and limited field-weakening capability. But "limited' might still mean you can get 50% or 100% more speed!
To some extent, I knew this already. But the great thing about seeing it consistently presented is that I now understand why it works. And even more cool, I see that it's all part of the same, simple model. Everything is accounted for without even diving into the magnetic domain. You just measure back EMF, draw some triangles, and come up with the performance of the motor. It's all become simpler to comprehend because it fits into a minimalist model.
Now I have some more solid footing to stand on for the full-AC version of my controller. I can start thinking about field-oriented control, how it will interact with different motors (trapezoidal, sinusoidal) at different speeds, etc. I guess at heart I am more interested in motor control than in motors themselves, but as I can see now you can't understand one without the other!
READ IT! Here's the link again.
Friday, November 6, 2009
SMMA Fall Technical Conference - Wrap-Up
Well, I don't really have any new pictures, so here's some dessert.Yesterday wrapped up my trip to the SMMA Fall Technical Conference and I failed to update the "live blog" (which I have decided never to do again) mostly because I spent many hours in the airport and on a plane. But anyway, I am back in Cambridge now. The trip was definitely a good one for me. I expected to learn a lot, and I did. Here's a few things that I came away with:
- The electric motor industry is very big, reaching out into many markets. The biggest ones seems to be industrial (big constant duty induction motors) and automotive (little accessory PM motors, not traction). But both of those markets took a big hit. The "new markets" are renewable generation (wind) and automotive traction. Almost everyone identified these markets, but few have stepped into them yet, it seems.
- There was a very interesting idea proposed by EMERF for a pre-competitive research consortium that could maybe focus on some of these new markets, or on PM issues. The thing that comes to mind for me is the FEMMulator. Here's what I mean: The "industry" is slow, and built on a large pool of experience and expertise and data from existing designs. And then there's the FEMMulator...a free program that one person wrote to run an iterative FEA design simulation on a brushless motor. Here's the "disruptive technology," except instead of a technology it's really more of a disruptive methodology. The idea that anyone can get access to enough information and computing power to design a motor these days means that the process is different...and a collaborative research intiative seems to make sense, IMO.
- On the technical side, there are a lot of things I know now that I will have to look at more closely. For one, segmented drive PWM. I thought I knew all there was to know about PWM in an h-bridge or inverter, but apparently not. So I will look into the more interesting methods and see if they could be applied to my controller at all. Also, there is a commercial sensorless zero-speed-start BLDC controller available call the DPFlex, from Agile Systems. It uses variations in inductance to measure starting position of the rotor. I knew this was possible and had been researched, but it's interesting to see one in production. I wonder if I could get my hands on one for cheap...or else it's good at least to know that it exists.
- There were also some ideas that were met with a bit of skepticism. There was QM Power, which, well I understand where the skepticism comes from. I actually thought their presentation was pretty good, but after going back and reading their website...their idea is either ridiculous or they do have a clever breakthrough and need to fire their entire marketing/promotional team for making it sound ridiculous. There's also a clever idea for a harmonic drive motor, which is like a harmonic drive gearbox but without the strain wave generator...you use electromagnetic forces to move the spline. That one is really clever, and it would certainly work. The question is how efficient it would be. But it would be great for robot actuators, etc.
- I got some good feedback on the axial motor concept. It's fairly unique even among axial motors, and most people think it could get very good power/torque density. Interesting to see how it works out.
Tuesday, November 3, 2009
SMMA Fall Technical Conference - Day 1
Today was the pre-conference workshops day, and that meant a four-hour course on "Fundamentals of Brushless Motor Control" for me.
Oh boy.
Oh boy.Despite the 8AM-ness of it, I got a lot out of it. It was just the right level for me...stuff I had seen before but don't full understand yet. Hence the reading material. That's the kind of thing that will keep me entertained for quite a while.
For one, I learned that there are more ways than I knew of to drive a PWM signal in an h-bridge or 3-phase bridge. I don't really understand some of the more clever ways yet, or the differences in performance, but it's something to look into in the controllers I build.
Other than that, today was Essex Active plant tour day. I learned what a slot wedge is:
A slot wedge.For one, I learned that there are more ways than I knew of to drive a PWM signal in an h-bridge or 3-phase bridge. I don't really understand some of the more clever ways yet, or the differences in performance, but it's something to look into in the controllers I build.
Other than that, today was Essex Active plant tour day. I learned what a slot wedge is:
It's a wedge that goes in slots. (Motor slots, of course.) It can be made of many things, including Nomex. The windings presumably go inside the wedge. And presumably the wedge is a tad longer than the slot. So the windings never touch steel. Genius. I wish I had some when we were winding the scooter motors. Oh well.
My table-top demo is ready and I will be manning the post early tomorrow morning. Then in the afternoon I present, right before AC Propulsion... Moderately frightening. More pictures tomorrow when that's all over with and I can relax a bit.
My table-top demo is ready and I will be manning the post early tomorrow morning. Then in the afternoon I present, right before AC Propulsion... Moderately frightening. More pictures tomorrow when that's all over with and I can relax a bit.
Monday, November 2, 2009
Live from Chicago: SMMA Fall 2009 Technical Conference
Here goes my first-ever attempt to use the blog in semi-real-time.
This week, I am in Chicago for the SMMA Fall 2009 Technical Conference.
The SMMA is "The Motor and Motion Assocation." (The 'S' is silent.) Actually it used to stand for the Small Motor Manufacturer's Association. I wonder if I can get it changed to the "Scooter Motor Manufacturer's Association." Probably not. But anyway, you can find more information on the SMMA, which serves as the trade association for the electric motor and motion control industries, here: http://www.smma.org.
I am participating in the conference thanks to support from the Electric Motor Education & Research Foundation (EMERF) which, as the name might suggest, is right up my alley. This foundation supports and promotes academic, pre-commercial electric motor R&D, as well as educational initiatives in the field of electric motors. More information is available here: http://www.emerf.org.
This all has to do with the BWD Scooter project. Since we had the completely original, not ripped-off at all idea of making brushless hub motors for a kick scooter, I made a contact at Proto Laminations who is also a member of the SMMA/EMERF. Having now actually made brushless hub motors for a scooter, I am going to present it, or, I guess, present the Summer Engineering Workshop and its fleet (yes, fleet now) of vehicles. Of course, the scooter is the only one that's in any way portable:
I did say "in any way."
This week, I am in Chicago for the SMMA Fall 2009 Technical Conference.
The SMMA is "The Motor and Motion Assocation." (The 'S' is silent.) Actually it used to stand for the Small Motor Manufacturer's Association. I wonder if I can get it changed to the "Scooter Motor Manufacturer's Association." Probably not. But anyway, you can find more information on the SMMA, which serves as the trade association for the electric motor and motion control industries, here: http://www.smma.org.
I am participating in the conference thanks to support from the Electric Motor Education & Research Foundation (EMERF) which, as the name might suggest, is right up my alley. This foundation supports and promotes academic, pre-commercial electric motor R&D, as well as educational initiatives in the field of electric motors. More information is available here: http://www.emerf.org.
This all has to do with the BWD Scooter project. Since we had the completely original, not ripped-off at all idea of making brushless hub motors for a kick scooter, I made a contact at Proto Laminations who is also a member of the SMMA/EMERF. Having now actually made brushless hub motors for a scooter, I am going to present it, or, I guess, present the Summer Engineering Workshop and its fleet (yes, fleet now) of vehicles. Of course, the scooter is the only one that's in any way portable:
I did say "in any way."And since it is generally not acceptable to ship/check/carry batteries that you made yourself, the A123 pack has to stay at home. But cordless drills (and their batteries) are totally fine:
All Tech men carry batteries...and cordless drills.
All Tech men carry batteries...and cordless drills.Ok TSA? So back off. Or don't:
Not surprising.
Not surprising.Actually, the trip out went smoothly. Actually, very smoothly. Actually, it was the single most coordinated thing I have ever seen at an airport. A full 50 minutes before the scheduled departure time, we were told to board the aircraft as quickly as possible because they were going to try to beat a storm. ~40 people got on and sat down, the jets spooled up, and we did a rolling takeoff 20 minutes early. Amazing. I honestly don't see what all the complaining is about air travel...
As for the scooter, it survived. Or wait, did it!? Why does the rear motor feel like it's got Jello in it? This is usually a sign of a phase-to-phase short, which, if you've ever shorted the leads on a PM motor, you know is electronic braking. Well, this was a scary few minutes of wondering if the phase windings somehow shorted during transport. But the problem was a lot simpler apparently:
?
As for the scooter, it survived. Or wait, did it!? Why does the rear motor feel like it's got Jello in it? This is usually a sign of a phase-to-phase short, which, if you've ever shorted the leads on a PM motor, you know is electronic braking. Well, this was a scary few minutes of wondering if the phase windings somehow shorted during transport. But the problem was a lot simpler apparently:
?Well, actually, I have no idea what the problem was. But I know what the solution was:
:(
- Remove strain relief zip-tie.
- Replace strain relief zip-tie.
:(But since it was non-functional, I guess it's okay.
Anyway, tomorrow I am taking an early-morning brushless motor control course where I might learn just how wrongly I've been doing it. So sleep may be in order. My presentation is on Wednesday, and I will post the slides right after. (But by now, you probably know what to expect.) And, of course, I will get to see all the other demos and presentations. Pictures and updates to come.
Anyway, tomorrow I am taking an early-morning brushless motor control course where I might learn just how wrongly I've been doing it. So sleep may be in order. My presentation is on Wednesday, and I will post the slides right after. (But by now, you probably know what to expect.) And, of course, I will get to see all the other demos and presentations. Pictures and updates to come.
Sunday, October 25, 2009
Updates: 3ph Duo and Epic Axial Motor
Being midway through the fall semester means starting to make preparations for 2.007, the annual MIT MechE robotics class/contest that happens in the spring term. While this involves a lot of manual labor in the form of building the contest tables, I can't actually show any pictures of that because it would give away the game. Besides the woodwork, there are also some more boring but necessary tasks to be done, such as testing new batteries:
What? Don't give me that look.
What? Don't give me that look.I'm not a very good multitasker, but if one of the tasks is watching a battery heat up a cup of water, I can do it. So here are some project updates and pictures in the meantime:
The 3ph Duo controller, the latest in my line of increasingly functional motor controllers, is finished. As in done, built, tested, working as planned. Here are a few pictures from the assembly, which, though not perfect, went pretty well:
The IXYS GWM 100-01X1, a wonderful 100V, "90A" three-phase MOSFET bridge package, was the key to this new controller, enabling two-channel, 1kW per channel BLDC control in a small form factor. Unfortunately, they only seem to be available from one place (Arrow) and only in the straight lead "-SL" version. This required some interesting bending, cutting, forcing, and soldering to get the chip to fit on my new circuit board:
It's not quite through-hole. Consider it...semi-surface mount. Same goes for the current sensors, which are designed to be through-hole but have their leads cut to length so they can sit flush with the sensor opposite the IXYS package. Not the cleanest assembly procedure ever, but it works. The IXYS package heat tab gets thermal pasted to a heat sink, and 5mm plastic stand-offs set the height correctly.
The 3ph Duo controller, the latest in my line of increasingly functional motor controllers, is finished. As in done, built, tested, working as planned. Here are a few pictures from the assembly, which, though not perfect, went pretty well:
The IXYS GWM 100-01X1, a wonderful 100V, "90A" three-phase MOSFET bridge package, was the key to this new controller, enabling two-channel, 1kW per channel BLDC control in a small form factor. Unfortunately, they only seem to be available from one place (Arrow) and only in the straight lead "-SL" version. This required some interesting bending, cutting, forcing, and soldering to get the chip to fit on my new circuit board:
All of the other IC components (HCPL-3120 optocoupled gate drivers, DCP021212 isolated high-side power supplies, LM2575 switching regulator, MC7805 linear regulator, OPA2340 R2R op-amps, and 74HC04 hex inverter) are now surface mount. The capacitors are still through-hole because I hate surface mount caps. But at least they are in the right place now.
The bus bar / heat sinks are gone and instead the power wires get soldered directly to surface-mount-style pads the board. This is something I saw in another ultra-thin controller. The signal connectors are still the same (Molex 0.1" R/A keyed).
These are all mostly form factor changes, but there were a few significant functional improvements as well. First, both motors now run on a single MSP430 microcontroller. Turns out this 16-bit, 16MHz chip can output enough PWMs on enough pins to pull this off. It processes twice the number of hall-effect interrupts as before, but some testing shows that even with two motors, the main loop execution breaks down at 1.6 million electrical RPM (228,000 mechanical RPM, or Mach 4.5, for the scooter). Basically, it makes the Arduino look silly.
Second, the current sensors now sense phase current, through a convoluted single-sensor synchronous measurement method that I wish I had never thought of. (It is a real pain to code, and is relatively noisy compared to sensing DC-link current, but at least it is a direct measure of actual motor current.) The current data looks a little noisy (about +/-4A noise on top of a 20A signal), so I've been working on software filtering mostly to clean it up even more for analysis, but the actual torque control feels smooth enough. The other data acquisition functions (all wireless) work great. Here's a cool test of the different motor constants measured cleanly at no-load:
This definitely shows the difference between the front motor (blue) with 60 windings per phase and the rear motor (green) with 90 windings per phase. Other interesting things I've done with the data acquisition: measured motor resistance (0.275-Ohm front, 0.355-Ohm rear) measured battery internal resistance (~0.075-Ohm for a 10S2P A123 26650 pack), measured top speed (~18mph), tested PI control of current (not very much benefit).
Oh, and most importantly, it fits in the deck:
The bus bar / heat sinks are gone and instead the power wires get soldered directly to surface-mount-style pads the board. This is something I saw in another ultra-thin controller. The signal connectors are still the same (Molex 0.1" R/A keyed).
These are all mostly form factor changes, but there were a few significant functional improvements as well. First, both motors now run on a single MSP430 microcontroller. Turns out this 16-bit, 16MHz chip can output enough PWMs on enough pins to pull this off. It processes twice the number of hall-effect interrupts as before, but some testing shows that even with two motors, the main loop execution breaks down at 1.6 million electrical RPM (228,000 mechanical RPM, or Mach 4.5, for the scooter). Basically, it makes the Arduino look silly.
Second, the current sensors now sense phase current, through a convoluted single-sensor synchronous measurement method that I wish I had never thought of. (It is a real pain to code, and is relatively noisy compared to sensing DC-link current, but at least it is a direct measure of actual motor current.) The current data looks a little noisy (about +/-4A noise on top of a 20A signal), so I've been working on software filtering mostly to clean it up even more for analysis, but the actual torque control feels smooth enough. The other data acquisition functions (all wireless) work great. Here's a cool test of the different motor constants measured cleanly at no-load:
This definitely shows the difference between the front motor (blue) with 60 windings per phase and the rear motor (green) with 90 windings per phase. Other interesting things I've done with the data acquisition: measured motor resistance (0.275-Ohm front, 0.355-Ohm rear) measured battery internal resistance (~0.075-Ohm for a 10S2P A123 26650 pack), measured top speed (~18mph), tested PI control of current (not very much benefit).
Oh, and most importantly, it fits in the deck:
So there. Everyone who asked why the original version was so big can be quiet now. I will be testing and writing this controller up very thoroughly, since it's in a state now to which few of my projects ever get. I'm not sure how useful it will be, since there is still a lot of "custom" in it, especially on the microcontroller side, but hopefully people find the bits and pieces useful at least. Somebody can design an Arduino adaptor for the power stage... For now, here is a link to the schematic, board files, source code, and other random bits and pieces for anyone who is interested.
Next up, the Epic Axial Motor. This is the beast. Although just 4" wide and 9" diameter, it will produce multiple tens of kW. I'd estimate it at around one horsepower per pound, minimum. Well, the simulation says so anyway.
Flux.
Next up, the Epic Axial Motor. This is the beast. Although just 4" wide and 9" diameter, it will produce multiple tens of kW. I'd estimate it at around one horsepower per pound, minimum. Well, the simulation says so anyway.
Flux.But I don't know, I don't really trust simulations yet. Although it did very well for the scooter motors. The goal here is to build the motor in stages, testing along the way to double-check or refine the simulation. The axial-flux design with two rotors and separable tapered roller bearings lends itself to "easy" assembly and disassembly for prototyping. "Easy" if you can safely accommodate for the 500 lbs or so of finger-nomming axial force. So anyway it's time to build.
Yes, I actually went into the machine shop and fabricated a metal part. Aren't you proud of me? I've been doing EE-type projects for so long that I forgot what it's like to go home with aluminum shaving in my hair. What's that? There are waterjet-cut parts in the background? Nonsense. I made those by hand. Okay fine, I got those from Big Blue Saw, which now has a low-taper waterjet! As for the rotor, Mike "Master of the EZ-Trak" Nawrot is going to produce the spinning magnets of doom. (It would take me a month...)
After that, it's on to winding a test set of stator segments. And by winding, I really mean folding, or something, since we are using concentric layers of 15-mil copper shim stock for massive current-carrying capability. I'm actually fairly excited to see how this works. It could have significant advantages over large-gauge magnet wire...or it could be a total failure. We'll see.
Next week = SMMA Fall Technical Conference in Chicago where I get to meet the pros.
After that, it's on to winding a test set of stator segments. And by winding, I really mean folding, or something, since we are using concentric layers of 15-mil copper shim stock for massive current-carrying capability. I'm actually fairly excited to see how this works. It could have significant advantages over large-gauge magnet wire...or it could be a total failure. We'll see.
Next week = SMMA Fall Technical Conference in Chicago where I get to meet the pros.
Thursday, September 10, 2009
What's Next: 3ph Duo Controller
Fall '09 is under way with an interesting set of old and new projects on the horizon. The most immediate is yet another motor controller - version 2.0 of the 3-phase brushless series and version 7.2? or something of the modular half-bridge design. A brief history:
Version 5, oddly enough not pictured, is the only one that has never blown up on the go-kart.
Version 5, oddly enough not pictured, is the only one that has never blown up on the go-kart.Version 1.0 of the 3ph brushless controller, after a bit of troubleshooting, works just fine. It's actually overkill for the application, namely driving a 500W in-wheel motor for the B.W.D. Scooter. The motors can handle a peak current of about 20A. The v1.0 controllers, fans enabled, were tested to handle 75A for 45 seconds on a single phase before the MOSFETs started to desolder themselves. Divide that up between three phases and you get something that would probably handle 75A continuously. Combine that with 48V-compatible MOSFETs (75V rated) and you get a 3.6kW controller...for 500W motors. However, overkill alone would never make me design a new controller. The biggest problem is this:
No Step.
Despite my best efforts to make this more compact than any controller I've designed before, there just isn't enough room for two of them on the scooter. The only solution was to have them stick out through the deck. This is bad for a few reasons: One, it takes up foot space and is going to get has gotten stepped on. Two, it just looks bad. The whole point of putting the motors in the wheels and the batteries under the deck is to make it look as compact and normal as possible. Also, stacking two controllers on top of each other makes one of the fans completely useless. (The fans, along with almost every other component that wasn't soldered down, get beaten up pretty badly due to vibration, too.)
So, the challenge for v2.0:
The Turnigy Sentilon 100A HV. Ok, I will admit this is impressive. It is one of the most beastly high-voltage hobby RC controllers out there: 100A @ 50V. That's a 5kW controller in a 60mm x 60mm x 11mm package. And it actually wouldn't be that hard or space-consuming to add a current-controlled feedback loop around this. (As-is, it only does voltage/speed control.) But it's not sensor-commutated. Meaning, startup torque will suffer. How much, I don't know. And keep in mind that despite the massive power, it still only runs one motor. Cost for two: $232.
The Kelly KBS48051. This is the cheapest serious-business EV brushless controller you can find for 48V. It can handle 20A continuous, 50A peak for one minute, so about 1-2kW. It is fully current/torque controlled with hallf-effect sensors and regen. You can program it, although getting real-time data off is a different story. The down sides: It's the same size as my v1.0 controller. And still, only one motor. Cost for two: $200.
Okay, down to business. The first step was to find a new MOSFET solution. As much as I love the IRFB3077, there is just no way 12 of them will fit. The key discovery was an inexpensive, integrated three-phase bridge module: The IXYS GWM series, specifically the GWM100-01X1-SL, which is the only one in stock anywhere (Arrow Electronics).
IXYS GWM100-01X1-SL
..the..
..deck.
No Step.So, the challenge for v2.0:
- Run both motors in current/torque control mode with a single controller.
- Maintain at least 40A continuous current capability on each motor, at up to 48V. Two 1.9kW controllers on one board will make it actually more powerful than a single v1.0 controller.
- Maintain the same x-y footprint as v1.0, if not smaller. This was easy: Eagle doesn't allow you to make boards larger than 80mm x 100mm.
- Shrink the maximum height so that everything fits within the scooter deck. This means the entire controller must occupy less than about 1.3" (35mm).
- Maintain the existing modular half-bridge driver design. It's optically isolated and I know it works. There are smaller, cheaper ICs that will do half-bridge drive, but now is not the time for radical design change.
- Maintain the ability to record and transmit data.
The Turnigy Sentilon 100A HV. Ok, I will admit this is impressive. It is one of the most beastly high-voltage hobby RC controllers out there: 100A @ 50V. That's a 5kW controller in a 60mm x 60mm x 11mm package. And it actually wouldn't be that hard or space-consuming to add a current-controlled feedback loop around this. (As-is, it only does voltage/speed control.) But it's not sensor-commutated. Meaning, startup torque will suffer. How much, I don't know. And keep in mind that despite the massive power, it still only runs one motor. Cost for two: $232.
The Kelly KBS48051. This is the cheapest serious-business EV brushless controller you can find for 48V. It can handle 20A continuous, 50A peak for one minute, so about 1-2kW. It is fully current/torque controlled with hallf-effect sensors and regen. You can program it, although getting real-time data off is a different story. The down sides: It's the same size as my v1.0 controller. And still, only one motor. Cost for two: $200.
Okay, down to business. The first step was to find a new MOSFET solution. As much as I love the IRFB3077, there is just no way 12 of them will fit. The key discovery was an inexpensive, integrated three-phase bridge module: The IXYS GWM series, specifically the GWM100-01X1-SL, which is the only one in stock anywhere (Arrow Electronics).
IXYS GWM100-01X1-SLAt $21 each, these replace six IRFB3077s at $2.79ea. I consider that a fair trade. Specifications-wise, they have about twice the resistance per FET (7.5mOhm), but also a higher voltage rating (100V). They are rated at 1.3K/W with a proper heat sink, which is about the same as the IRFB3077, except that these share a heat sink tab. I doubt they will match the performance of the 3077s, but 40A continuous per chip should be achievable.
The other key discovery was that I only need one MSP430F2274 microcontroller to generate all six channels. It has four output-compatible timers, but each timer is mulitplexed to two pins, so really there are eight available output pins that can do high-speed PWM. And there are only really two independent PWMs required (one for each motor). It should have no trouble handling the extra hall-effect encoder interrupts, too. The only real worry I have is the 4kB code limit imposed by my free version of IAR Embedded Workbench. Here's why:
Not a lot of space left.
If the code to control one motor costs 3,255 bytes...and I need to control two motors... Well, I tend to just assume that all software problems can be solved. Realistically, most of the code is overhead that doesn't need to be repeated. But let's just hope that they know that 4kB is 4,096 bytes, not 4,000 bytes. I will probably need those extra 96.
Ugh, why am I such an EE? New MOSFETs...software constaints.... WHAT ABOUT FITTING THE WHOLE THING INTO THE DECK? Which, I believe, was the original point of all this. Here:
It..
..fits..
..in..
The other key discovery was that I only need one MSP430F2274 microcontroller to generate all six channels. It has four output-compatible timers, but each timer is mulitplexed to two pins, so really there are eight available output pins that can do high-speed PWM. And there are only really two independent PWMs required (one for each motor). It should have no trouble handling the extra hall-effect encoder interrupts, too. The only real worry I have is the 4kB code limit imposed by my free version of IAR Embedded Workbench. Here's why:
Not a lot of space left.If the code to control one motor costs 3,255 bytes...and I need to control two motors... Well, I tend to just assume that all software problems can be solved. Realistically, most of the code is overhead that doesn't need to be repeated. But let's just hope that they know that 4kB is 4,096 bytes, not 4,000 bytes. I will probably need those extra 96.
Ugh, why am I such an EE? New MOSFETs...software constaints.... WHAT ABOUT FITTING THE WHOLE THING INTO THE DECK? Which, I believe, was the original point of all this. Here:
It..
..fits..
..in..
..the..
..deck.The IXYS FET modules get thermal pasted to the aluminum deck, which should make an excellent heat sink. Wires get soldered in directly like in the Turnigy - no more bus bars. The single MSP430F2274 controller board gets a new home dead-center. All the gate-drive circuits have been made surface mount and take up both sides of the board now. The 15V switching regulator and associated inductor are surface mount. The only thing that can't really be made smaller are the current sensors...but they are in the right place now, at least. The result: the board occupies only 1.2" of vertical space.
And the final cost of components? Let's see... $42 for the FETs + $23 for the MSP430 board + $32 for the radio + $73.50!!! for six isolated high-side supplies + $31.62 for twelve optically-isolated gate drivers + $32.74 for two current sensors + $8 for the 15V supply + $25 for misc passive components and connectors. $270. No, I didn't count the cost of circuit boards. But I'm only building one. Extrapolate to high quantities and the total cost here isn't that bad.
I'm sort-of hoping it just works. The only major hardware changes are the MOSFETs and the placement of the current sensors. The most likely failures are actually on the software side, since I changed so many of the pins. I tried my best to think through the pin assignments, but there's always the chance that I missed something that will result in a disappointing, smokeless failure. If so, there will have to be a version 2.1...
I'll post the new schematic after testing.
And the final cost of components? Let's see... $42 for the FETs + $23 for the MSP430 board + $32 for the radio + $73.50!!! for six isolated high-side supplies + $31.62 for twelve optically-isolated gate drivers + $32.74 for two current sensors + $8 for the 15V supply + $25 for misc passive components and connectors. $270. No, I didn't count the cost of circuit boards. But I'm only building one. Extrapolate to high quantities and the total cost here isn't that bad.
I'm sort-of hoping it just works. The only major hardware changes are the MOSFETs and the placement of the current sensors. The most likely failures are actually on the software side, since I changed so many of the pins. I tried my best to think through the pin assignments, but there's always the chance that I missed something that will result in a disappointing, smokeless failure. If so, there will have to be a version 2.1...
I'll post the new schematic after testing.
Sunday, July 26, 2009
Silence of the Cows
I was just thinking about how boring it would be to have a website that just exhibits a bunch of working projects, no matter how cool those projects are. Not very many of my projects make it to a working state in one shot, but one that came frighteningly close is my 3-phase motor controller. Version 0.0 was built as a term project for 6.690/6.061 (Intro. to Electric Power Systems). It was built in a week and worked with no problems on a small (200W is small around these parts...) induction motor, running a simple V/f control. I commented then that it was only a matter of time before it got scaled up...
So I made it smaller. Scaling up doesn't always mean it has to be bigger. What I call v1.0 is just a tad over 80mm x 100mm x 40mm. (This is the maximum board size in the free version of Eagle...) It's got six IRFreakingBig3207 MOSFETs on board right underneath a tiny (60mm x 10mm) but strong fan. As usual, I have already gotten my fingers owned by said fan. The heat sinks are not that great, just slivers of aluminum soldered to the circuit board. (Yes, you can solder aluminum.) But based on my previous experience with these FETs, I sort-of expected that they could do the job.
The job.
The job, by the way, is full torque control of a brushless DC motor built into the hub of a Razor scooter wheel, a la Charles Guan. It's the Summer Engineering Workshop '09 project, which means two things: 1) It will be cool. and 2) I will spend a lot of time making electronics for it. Sigh. Although unlike last year, we could actually buy a controller that does exactly what we want. Granted, this is pretty much the only one in existence and the manual refers to a color called "Reddle", which I suspect probably means orange, but it is still cheaper than making one. But when has that ever stopped me?
But wait, what about all those tiny RC plane controllers that can handle 100A? Well, first of all there aren't many that can run higher than 24V, and with these insane neodymium magnets the backEMF is going to be huge. But more importantly, they are not torque controlled. You set the throttle and they adjust the PWM to give you a proportion of the full voltage. This works fine for airplane propellors, which see increasing torque with increasing speed in a nice drag-based relationship. Electric vehicles, on the other hand, see max torque when they are sitting still. This means no forced-air cooling of the controller, and quite possibly if it is completely stalled two phases will take all of the load, so the current ratings would be much lower.
The key to torque control is the ability to measure and control current, which means putting a current sensor on the controller. In fact, it should mean putting TWO current sensors on the controller, since only two of three phases are active at any given time and you need at least two sensors to be guaranteed a measurement of an active phase. I manage with only one. I wish I could say it was clever design that allowed this, but instead it was just stupidity. I put the current sensor on the DC link...before the power gets inverted and sent to the motor.
Oops.
So there is mistake #1. I'm glad there was at least one...because otherwise I'd just have to write about how it works. The fix for mistake #1 is somewhat of a hack. In software, I can estimate the current going to the motor based on the PWM and the DC link current. There is a horrible divide-by-zero condition inherent in this, though. (Imagine the motor is spinning full speed and then the PWM goes to zero, shorting all the phases together.) So, something to think about for v2.0 is repositioning the current sensors to a place that makes sense.
But does that mean that v1.0 actually works without any wire hacks, any desoldering, any exploded FETs, any melted Zener diodes?! I think I would actually be sad if it did. Only load testing can tell. At 20A, no problems:
Even on a huge Etek motor, it effectively regulates the current in both directions. (Yes, it can do controlled regenerative braking.) This is actually a great demonstration of the torque control, because if you hooked up an RC controller to an Etek and went full throttle, there's a good chance it wouldn't survive, since it would apply the full voltage regardless of the N-hundred amps the Etek wants to draw. And 20A is about what we can put through the scooter motor before the windings start to heat up too much. But come on! I need to at least be competitive with the Kelly controller current ratings. Bring on the CIM-battle load test:
Mmmmm...ex-FIRST equipment.
These are wonderful 1/2-horsepower CIM motors from an old FIRST Robotics kit, in a nice cast-aluminum gearbox. They are meant to turn with each other for double the torque, but I prefer to make them fight each other by hooking red to black, black to red, and driving them with a single phase of the 3ph controller. If a single phase can handle the load, three phases sharing it should have no problem. So this should make a great worst-case scenario test. Let's try 50A!
Uh oh! At anything above 30A, it seems the controller has a tendency to produce a sound that I can only describe as "mooing." Yes, like a cow. It still works, but some low-frequency noise is coming in somewhere that makes the motors sound like they are ready to be milked. I originally thought it was some digital instability introduced by my current sensor hack, but after changing the gains and seeing no difference, I concluded that it was a real hardware problem! Hooray! There is something wrong with the design that isn't just a "no big deal I'll fix it in version 2.0." I actually get to troubleshoot something significant and fix it!
Well, that was easy. The 15V DC/DC converter which powers...everything on the board...needs an input capacitor closer to its...input. I thought the main caps would be sufficient but since they are on the opposite side of the high-side bus bar, all their effort goes into keeping the MOSFETs happy and they can't really help the DC/DC all that much. In power electronics, where you put things is almost more important than what you put. I should probably know that by now. But at least I have something to write about now.
The rest of the load testing went as expected. 50A for 60 seconds no problem. 75A for 45 seconds and then a shower of sparks as the heat sink melted through the high side input line which happened to be resting on it.
Not good.
A repeat of the 75A test almost made it to 60 seeconds, but then the MOSFETs started desoldering themselves. (They do that before they fail...amazingly.) So that's about the upper limit...for one phase. Call it 100A peak, 65A for one minute, 40A continuous. (I just made that up.) With all three phases running, I suspect this goes up at least by a factor of 1.5 or 2. Although at that point our scooter motor would be quite destroyed and our batteries would be dead.
So, the mooing has stopped, the controller works, and things look good for motor testing in the next week or so. But it wasn't easy. It shouldn't be. I hope it never is. Here is the v1.0 schematic and design files for anyone who might find it useful.
So I made it smaller. Scaling up doesn't always mean it has to be bigger. What I call v1.0 is just a tad over 80mm x 100mm x 40mm. (This is the maximum board size in the free version of Eagle...) It's got six IRFreakingBig3207 MOSFETs on board right underneath a tiny (60mm x 10mm) but strong fan. As usual, I have already gotten my fingers owned by said fan. The heat sinks are not that great, just slivers of aluminum soldered to the circuit board. (Yes, you can solder aluminum.) But based on my previous experience with these FETs, I sort-of expected that they could do the job.
The job.The job, by the way, is full torque control of a brushless DC motor built into the hub of a Razor scooter wheel, a la Charles Guan. It's the Summer Engineering Workshop '09 project, which means two things: 1) It will be cool. and 2) I will spend a lot of time making electronics for it. Sigh. Although unlike last year, we could actually buy a controller that does exactly what we want. Granted, this is pretty much the only one in existence and the manual refers to a color called "Reddle", which I suspect probably means orange, but it is still cheaper than making one. But when has that ever stopped me?
But wait, what about all those tiny RC plane controllers that can handle 100A? Well, first of all there aren't many that can run higher than 24V, and with these insane neodymium magnets the backEMF is going to be huge. But more importantly, they are not torque controlled. You set the throttle and they adjust the PWM to give you a proportion of the full voltage. This works fine for airplane propellors, which see increasing torque with increasing speed in a nice drag-based relationship. Electric vehicles, on the other hand, see max torque when they are sitting still. This means no forced-air cooling of the controller, and quite possibly if it is completely stalled two phases will take all of the load, so the current ratings would be much lower.
The key to torque control is the ability to measure and control current, which means putting a current sensor on the controller. In fact, it should mean putting TWO current sensors on the controller, since only two of three phases are active at any given time and you need at least two sensors to be guaranteed a measurement of an active phase. I manage with only one. I wish I could say it was clever design that allowed this, but instead it was just stupidity. I put the current sensor on the DC link...before the power gets inverted and sent to the motor.
Oops.So there is mistake #1. I'm glad there was at least one...because otherwise I'd just have to write about how it works. The fix for mistake #1 is somewhat of a hack. In software, I can estimate the current going to the motor based on the PWM and the DC link current. There is a horrible divide-by-zero condition inherent in this, though. (Imagine the motor is spinning full speed and then the PWM goes to zero, shorting all the phases together.) So, something to think about for v2.0 is repositioning the current sensors to a place that makes sense.
But does that mean that v1.0 actually works without any wire hacks, any desoldering, any exploded FETs, any melted Zener diodes?! I think I would actually be sad if it did. Only load testing can tell. At 20A, no problems:
Even on a huge Etek motor, it effectively regulates the current in both directions. (Yes, it can do controlled regenerative braking.) This is actually a great demonstration of the torque control, because if you hooked up an RC controller to an Etek and went full throttle, there's a good chance it wouldn't survive, since it would apply the full voltage regardless of the N-hundred amps the Etek wants to draw. And 20A is about what we can put through the scooter motor before the windings start to heat up too much. But come on! I need to at least be competitive with the Kelly controller current ratings. Bring on the CIM-battle load test:
Mmmmm...ex-FIRST equipment.These are wonderful 1/2-horsepower CIM motors from an old FIRST Robotics kit, in a nice cast-aluminum gearbox. They are meant to turn with each other for double the torque, but I prefer to make them fight each other by hooking red to black, black to red, and driving them with a single phase of the 3ph controller. If a single phase can handle the load, three phases sharing it should have no problem. So this should make a great worst-case scenario test. Let's try 50A!
Uh oh! At anything above 30A, it seems the controller has a tendency to produce a sound that I can only describe as "mooing." Yes, like a cow. It still works, but some low-frequency noise is coming in somewhere that makes the motors sound like they are ready to be milked. I originally thought it was some digital instability introduced by my current sensor hack, but after changing the gains and seeing no difference, I concluded that it was a real hardware problem! Hooray! There is something wrong with the design that isn't just a "no big deal I'll fix it in version 2.0." I actually get to troubleshoot something significant and fix it!
Well, that was easy. The 15V DC/DC converter which powers...everything on the board...needs an input capacitor closer to its...input. I thought the main caps would be sufficient but since they are on the opposite side of the high-side bus bar, all their effort goes into keeping the MOSFETs happy and they can't really help the DC/DC all that much. In power electronics, where you put things is almost more important than what you put. I should probably know that by now. But at least I have something to write about now.
The rest of the load testing went as expected. 50A for 60 seconds no problem. 75A for 45 seconds and then a shower of sparks as the heat sink melted through the high side input line which happened to be resting on it.
Not good.A repeat of the 75A test almost made it to 60 seeconds, but then the MOSFETs started desoldering themselves. (They do that before they fail...amazingly.) So that's about the upper limit...for one phase. Call it 100A peak, 65A for one minute, 40A continuous. (I just made that up.) With all three phases running, I suspect this goes up at least by a factor of 1.5 or 2. Although at that point our scooter motor would be quite destroyed and our batteries would be dead.
So, the mooing has stopped, the controller works, and things look good for motor testing in the next week or so. But it wasn't easy. It shouldn't be. I hope it never is. Here is the v1.0 schematic and design files for anyone who might find it useful.
Subscribe to:
Posts (Atom)