I wanted a model which could encompass controller effects like sample time, switching, PWM resolution, A/D resolution, sensor noise, etc, and generally be, well, as general as possible, so that I can use it for arbitrary motors and motor controllers. I started out doing most of the model in the D-Q frame, but realized to get what I want, it really makes more sense to do all the motor modeling at the phases, and then just use the transformations as necessary for control purposes. You know, like how motors work in real life.
In working through this problem, I finally sat down and did a bunch of motor modeling math by hand, which I should probably have done a while ago. Fortunately Bayley was semi-coincidentally working through similar problems at the same time, to do some optimization for controlling hybrid car motors for a go kart, so we did some back-and forth to sanity check results.
Rather than putting it all here, I spent the time to write up a nice Latex-ed document with my notes, which can be found here. This is just the analytical portion of the modeling - i.e. coming up with the equations that actually get solved by a computer.
Here you go.
With that part of the problem out of the way, I could actually implement the equations in MATLAB, and do interesting things with them.
Here are a couple useful sanity checks for making sure the motor equations were behaving like I expected them to once implemented, and some other experimentation.
Open Circuit Back-EMF
i.e., spin the motor with the phases floating, and measure the voltage between terminals. This is the classic test I use all the time to quickly estimate motor parameters of random motors. The next few plots are for the hybrid car motor being used in the go-kart.
Short-Circuit Torque Vs Speed
i.e. Short the motor terminals together and spin the motor. For low speeds, the motor looks behaves like a resistor, so expected result is that there's a damping torque proportional to angular velocity. But as speed increases, the motor behaves like an inductor, not a resistor, so damping should drop off to a constant value. The crossover speed should be right around the motor's R/L break frequency. And so it is:
The plot above, and those following are per pole pair. This is a 3 pole pair motor, so actual torque and speed get multiplied and divided by 3 respectively.
PM and Reluctance Torque vs Current Angle
Looking at the permanent magnet and reluctance components of torque vs the relative angle of the stator current to the rotor, the expected plot looks like this. Here's the result for the same hybrid motor (this plot's actually a little out-of-date, but it gets the picture across)
Auto-Generate "Optimal" Current Trajectories
Unlike for the classic surface-permanent-magnet "brushless" motor, where you typically want to just put all the current on the Q-axis (neglecting field-weakening), internal permanent magnet motors (like those in most hybrid cars) needed to be treated differently. I wrote a script which sweeps operating speeds, and for every speed and current setpoint finds the current phase angle which produces the most torque. A pretty cool thing about this method is that it automatically produces the correct field-weakening trajectory for operation above base speed. No need to think about how to move through current circles and voltage ellipses.
Here's the whole positive-torque, positive-speed operating region, for the same hybrid car motor as above, with a 160V bus and 200 phase amp limit. This map can be used to generate a lookup table for motor controller - for a given speed and torque command, what are the best d and q axis currents. In this case I've formatted it as current magnitude and phase, instead of d and q current, because that makes the table a little more convenient to generate.
(currents numbers are larger than 200A peak just because of the way I've defined my dq0 transform, but this corresponds to 200 peak phase amps) The dark-blue regions are unreachable operating points.
I added a naive implementation of switching to the model. I implemented this very much like how a microcontroller does PWM, with an up-down counting counter, like this. Unfortunately this method means I have to simulate way more timesteps than necessary - 40 kHz pwm with 12 bits of PWM resolution, this method has to simulate 1/(40,000 * 2^12) steps per second, which is way faster than the actual dynamics of the motor behave. There are cleverer ways around this, but I haven't gotten around to trying anything else yet.
Here's what phase currents look like with 40 kHz switching on one of my MultiStar Elite 5208 motors. You can see the fuzz on top of the sinusoids from the switching.
Zooming in, you can see the double-peaked ripple caused by the center-aligned PWM:
Here's a link to all the repository of MATLAB code: Beware, it's kind of an organizational disaster right now, but eventually it'll get organized and commented better, I promise.
Don't worry, I'll be back with more dyno progress and more building physical things soon.