Nitpick #1: It's still a good deal larger than some of the nice RC plane controllers out there. Okay, but it's a full vehicle controller! And I already made it much much smaller than v1.0 so it would fit inside the scooter deck! Okay fine:
I swear this as short as it can get.
Now it's 1.047" from heat sink surface to tallest component. (Previously 1.205".) That makes it shorter than, for random example, a 26650-sized battery. How did I do that?
The LEM current sensors are gone, which brings me to...
Nitpick #2: The current sensing was not great. I had this clever idea that you could sense current in a BLDC system using only a single sensor, since one phase is always off. Well...not really. It works great at stall and at low speeds, but at high speeds the inductance of the motor starts to make it so that even when a phase is "off" it still conducts for some time. Conversely, the phase you think is on may take some time to start conducting. So at any given time, all three phases might actually be carrying current."Real" controllers use two sensors on two phases. The third is easy to find, since Ia+Ib+Ic=0. So I ditched the LEM sensor for two of this wonderful find: the Allegro Microsystems ACS714. It's a 30A bi-directional current sensor with 0-5V output. And it's surface mount, so it takes up much less space. I'm out of analog ports, so there will have to be a 2x1 multiplexer to read in two currents per motor. But since the ADC is multiplexed inside the microcontroller anyway, this shouldn't affect processing time.
Nitpick #3: It's somewhat expensive. But it runs two motors! And trasmits data wirelessly! Recession? What are you talking about? Okay, fine. How about this deal: Four of the ACS714 at $4 each and two $0.50 multiplexers gives $17. Versus two LEM current sensors, totalling $38. That's a savings of $21 per board. But wait, there's more. The most expensive set of components on the board are actually the six DCP021515 isolated high-side supplies, which used to cost $12.25 a piece. Magically, they are now $11.75 on Digi-Key. Well, as it turns out, there is actually a lower-power version of this, named the DCP011515. The 02 vs. 01 means 2W versus 1W. The gate drive requirements for this controller are way less than 1W, so there's no reason to use the 2W chip. How much, you ask? $9.83. So that's a total savings of $14 per board. For a total of $35 chopped off the total cost. That brings the total component cost down to about $235 per board in single I-can't-make-even-the-first-price-break quantities.
Nitpick #4: It's still just a brushless DC controller. Well, as it turns out, the microcontroller has plenty of processing power left over. I figured out that running the existing code, the interrupt routine that handles motor commutation wouldn't start to run into problems until scooter speed of Mach 4.5. So most of the time it's just sitting around waiting for something to happen. Well, now there are two current sensors. That, plus some math, is really all you need for full AC vector control. Well, you also need three independent PWM channels per motor to generate the sine waves. Luckily for me, the TI MSP430F2274 has exactly that many:
This is a plot of three sine waves generated by PWM signals from a single timer. They are phase-shifted by 120ยบ, as they would be in a 3-phase motor. Since the controller isn't really fast enough to do trig operations, they are produced by stepping through an 8-bit memory table of sine values. These would be the average voltages sent to the motor, and compared to the square-wave drive of BLDC, it should make for a much smoother start-up.
But that's not the end of the story. Controlling the voltages to be sine waves that are in sync with the rotor is nice, but you still have the problem of inductance causing the motor current to lag at high speed. As the current lags, less of it goes into producing torque. (Current that is in sync with the rotor magnet flux is what produces torque.) One solution is to advance the phase of the voltage wave a bit to make up for it. The trick is, how much? You can be all open-loop about it and just guess, since it will likely be proportional to speed. Or you can literally measure and feedback-control the current at a higher bandwidth than the stator electrical frequency. (Which is the number of pole pairs times the rotor angular velocity.) But that's really, really fast. The scooter motors, which are relatively slow, can get up to nearly 200Hz. So the controller would have to run in the kHz range! And it would have to handle six independent current control loops. There's processing power left over, but not that much.
So, I propose a compromise: A low-bandwidth phase advance control loop. At a leisurely pace, the controller measures the three phase currents (per motor). Using some fancy math, it can convert that into two values: Iq, the quadrature-axis current, which is current that is in sync with rotor flux and therefore producing torque, and Id, the direct-axis current, which is current that is out of phase with rotor flux. Using two separate control loops, the voltage would be adjusted to set Iq (and thus torque) and the phase would be adjusted to set Id. This would be the basic idea, in power-point block diagram form:
The sine wave generator is always running, but the sensing and control happens asynchronously at a much slower rate. So, many electrical periods may pass between updates of the phase and magnitude of the voltage. But that might just be okay. The idea here is that Id is feedback-controlled to be zero by adjusting the phase of the voltage sine waves, while Iq is feedback-controlled by adjusting the magnitude of the voltage sine waves to give the desired torque. If you want to get even fancier, Id can be controlled to be non-zero for field weakening, which uses some of the current to fight the magnets and reduce the back EMF for the purpose of achieving higher top speed. The controllers themselves could be P or PI or PID controllers.
Will this actually work? I have no idea. It has the nice benefit of being completely asynchronous, so I can keep slowing it down until the controller is happy with the processing speeds. Although I think it will have no trouble at 100Hz. I also wonder about the two control loops sort-of fighting each other or oscillating. My hunch is that it can be tuned to run stably. But that's just a hunch.
Anyway, if it works, it will be quite an advanced little board. But even if this low-bandwidth AC control scheme fails miserably, I still get a smaller, lighter, cheaper, and better BLDC version. Win-win.
(As usual, new schematic/documentation to come pending testing.)
No comments:
Post a Comment