In a typical FOC implementation, phase currents are measured and transformed into the rotor frame to get d and q axis currents. Then two PI loops are run to control the d and q currents, with some feed-forward deal with the coupling between the voltage equations. The two PI controllers output d and q voltages, which are transformed back to the stator frame, and approximated with PWM.

This usually works great, but here's another controller I thought of which is (maybe) conceptually easier, and requires no controller design or gain calculating to work. In fact, it doesn't even use any motor parameters. And it doesn't even use PWM. At every step, it just picks which switches to turn on and off. Because of how it works, it's quite robust to changing parameters, like the motor's inductance changing when it saturates. Also, it has as fast as possible response given the open-loop dynamics of the motor.

The basic idea is as follows: Given the position of the rotor and errors in d and q currents, which switches should be turned on and off to make the error decrease as fast as possible?

Every loop cycle, the controller measures current, looks at the error and where the rotor is, and chooses the switch states that send the current error towards zero the fastest.

While it probably looks very confusing at first, I think the vector diagram below best explains the situation:

First, there are six vectors drawn in black, V1-V6, which represent the six stator voltage vectors. Each of these corresponds to a set of switch-states. The states with all switches on or all switches off are not used. Then there's the ĩ vector in blue, which is the vector sum of the d and q current errors. In red is the (negative of the) vector from motor dynamics, minus inductance. Looking at the motor voltage equations in d and q:

If the d-axis component of stator voltage plus the d-axis component of the dynamics is positive, then id will increase, and the same for the q axis.

The green vectors are di/dt scaled by inductance - mostly their direction is what matters. Given a dynamics vector and one of the stator vectors, the six di/dt vectors are the possible directions the current will change in.

Basically:

$$V_{stator} + V_{dynamics} = L\frac{d i}{dt}$$

The intuition is, pick the stator voltage vector which causes the di/dt vector to be in the right direction. The "right" direction is the direction of the error vector, ĩ. In the 1-D case, if error is positive, that means that actual current is less than desired current, so di/dt should be positive to cause current to increase.

To pick the right set of switch states, just take the dot product of the error vector and the six stator vectors, and then pick the switch state corresponding to the largest dot product. But wait, that's not the right thing to do, is it? Shouldn't I be picking the switch state which causes the dot product of the di/dt vectors and error vector to be the largest? Yes, but fortunately these two decisions are actually the same. Vdynamics is added to all the stator vectors, and dot products distribute. So you can ignore the Vdynamics vector, and just pick based on the stator voltage vectors and the error vector.

To limit switching frequency, you can also add a "hysteresis circle" around the origin. As in, if the error vector lies within the circle, don't change switch states:

Does it actually work?

Well, my motor model says it does. This is also using a motor model which includes a lookup table for inductance and flux linkage saturation. The motor parameters are from a KIA hybrid starter generator at 160 volts, with switching frequency limited to 15 kHz. I also threw in some real hardware effects like a few amps of noise on the current sensors, and 12 μs of propagation delay (which occurs in the Toyota Prius inverter).

Here's what phase current looks like at ~20 phase amps. As expected, it has way more ripple than a linear controller would, since the minimum switch on-time is one loop period, but it's quite tolerable - especially given the 200A max current of this system.

"It works is simulation" is where most people would have stopped, especially for a class project, but what's the point of controls if you don't put it on hardware? And then ride your hardware:

This is an electric go kart started by Bayley and Nick last summer, with lots of work by myself and other MITERS-folk in it as well. Eventually it will get its own thorough documentation but, but as a brief overview, it's a stock shifter kart frame, with the motor from a KIA hybrid, the inverter from a Prius, the battery from a Battlebot, and a bunch of custom motor control logic.

So how'd it work? Here's 20 phase amps on the actual motor, as measured by LEM-stick. Hey, that plot looks really familiar!

And here's a log from spinning up the wheels off the ground. d-axis current stops tracking around 1000 rad/s, because the reference currents were generated using an in correct inductance. So the commanded trajectory was actually un-trackable.

Qualitatively, it performed quite well. It produces an audible white-noise hiss from the extra current ripple. 1600 rad/s in the plot above corresponds to a ground speed of over 130 mph, although in reality on the ground the kart won't have the power (nor the space, in Cambridge at least) to go that fast. Yet.

To make if very clear, this type of controller is often not feasible to implement - for small hobby motors, for example, the inductance is too low for this to work with reasonable loop frequencies. This is one reason PWM is great - the timing resolution of when the switches turn on and off is dictated by a super-fast timer that runs in the background, rather than by the timing of the control loop. So for a given loop rate, normal PWM-based approaches will have way less current ripple than this controller. But for some motors (in particular high-inductance motors like those in electric cars), the numbers actually work out fairly favorably, and you can get away with running this controller at reasonable speeds.

There are certainly some improvements that could be made to this by including motor parameters to reduce current ripple, but I haven't tried any of them out yet.

Also, I thought I was really cool and came up with something new here, but (unsurprisingly) it turns out other people have already done similar things. Although they don't put it on hardware.

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

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

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

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

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

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

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

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

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

May 29, 2017

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

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

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

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

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

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

May 8, 2017

** 12/5/2017 Update **
A number of people noticed that this post disappeared for a while. Here's why. Skip down for the actual teardown

TL:DR, Emrax is a shitty company. They seem to have no/poor protection of their IP, and are willing to bully college students to keep pictures of their motors off the internet.

On July 4, I received the following message through the contact form on this site, typos and all:

Dear Mr. Ben,I am a representative of EMRAX company. We have come across your web site, where you have published disassembled EMRAX motor. We want you to removie this article. We are signing Non-disclosure agreement with every our customer. I believe that also Massachusetts Institute of Technology (MIT) has signed it. Consider this agreement and remobe the article as soon as possible. I am waiting for your reply.If you have any further questions feel free to contact me.

Hmm, sounds fishy. I don't buy it. My response:

Me:

Hi, This particular motor was not purchased by myself or by MIT - it was donated to the MIT electric vehicle team by a company a number of years ago, and lent to me by the the electric vehicle team. I do not believe that I am held to any agreement in the NDA signed by the original purchaser.

There was some more back-and-forth.

Emrax:

thank you for your reply. NDA is valid also for any third parties that are involved. Please remove the article as soon as possible.

Me:

You have not provided me with any evidence that I need to remove the article. At the very least, could you send me a copy of the NDA?

Emrax:

sorry for delayed response. We have summer holidays there days, so only a few people are working now.I have forwarded this email to our Sales department. We will look into our archive of NDA-s, because it was written some time ago. We will also send it to MIT.---I have attached our “General Terms and Conditions” – they are also published on our web site. Please take a look at the Item 15 – Intellectual Property Rights. They are also published on our website. Article should be removed as soon as possible.

That is not a copy of the NDA. 14(c) in the "general terms and conditions" implies the NDA is a separate document.

Furthermore, your "general terms" define "intellectual property rights" as:"any patents, trademarks, registered designs and all applications for their registration, copyrights or design rights or any rights similar to these rights. "

I do not believe that photographs of the inside of the motor qualify as your intellectual property. I am not infringing upon any patents, copyrighted material, or trademarks of yours.

After this, I don't hear anything from Emrax for a while. I'm pretty sure they have no legitimate claim for asking me to take down these pictures, and even if they did, I'm not sure how they would enforce them.

For a little while I thought I was done with this nonsense, but then I got an email from the captain of MIT's FSAE team, saying that they were trying to purchase a custom-wound motor from Emrax, but emrax was refusing to sell to them until I removed this post.

I sent this to Emrax:

I have just received word from the MIT FSAE team that you are withholding the sale of a motor to them until I remove the article, on the grounds that my pictures violate the NDA FSAE signed when they first purchased a motor from you. I would like to reiterate that I am not and have never been affiliated with the MIT FSAE team, and the motor I took apart was not purchased by or ever used by MIT FSAE.

Using MIT FSAE to bully me into removing the article is unfair to FSAE, and reflects quite poorly on you as a company.

Unsurprisingly, I didn't hear anything back from Emrax, but I did remove this post, because I didn't want to screw over the FSAE team. While it seems Emrax has no actual legal grounds for making me remove these pictures, they do have the right to refuse to do business with someone.

Now FSAE has their custom Emrax motor, so I'm putting this back online, along with the story of how shitty Emrax is. So if you or your friends are ever thinking about doing business with Emrax, beware.

************

And back to the teardown...

The EMRAX series of motors are some really impressive axial-flux motors, designed in Slovenia, for applications like ultralight aircraft. Thanks to their absurd datasheet numbers, they seem to be the favorite choice of FSAE teams everywhere.

The particular model we took apart (228LV) turns out to be particularly miserable to control. It's combination of ultra-low resistance (1.12 mΩ) and inductance (10 uH) means you would need to switch ~100 kHz at rated voltage, in order to have reasonable amounts of current ripple just from the PWM, which is kind of unreasonable for silicon MOSFETs or IGBT's of sufficient current and voltage rating. So it's a great motor, but not very useful unless you can afford to build a GaN-FET or SiC-FET inverter for it. Since CRC has two of these motors, Bayley and I decided it was worth the risk of disassembling one, to learn what magic-sauce goes on inside.

Here's the motor we started out with. There was a layer of blue tape around the outside to stop metal shavings from getting inside the motor during bench-testing. Like any good hobby-grade motor, the rotor and housing are full of holes for weight reduction and airflow.

After pulling off the stator of the resolver, we ran into this really obnoxious locknut, which was peened over into a keyway on the shaft to prevent you from removing it. Fortunately, the steel isn't particularly hard, and a diamond-coated dremel grinding attachment made short work of the peened over bits.

Here's the rotor of the resolver. The bolt on the left has a tapered head, so as you tighten it, it drives the split in the shaft apart, so it grips the inside of the motor shaft.

Next step was pulling the rotor. This is always hairy business with axial flux motors, because of the huge magnetic forces holding the halves of the motor together. In the past, this has been done at MITERS like this, but there ended up being a better way for this motor. First, we pulled the set-screws along the outside if the rotor.

I drilled and tapped a 5/8" -11 thread into the end of the shaft that came with the motor, and used the bolt like a crank-extractor to pull the top half of the rotor away from the steel motor shaft.

Bolt all oiled-up and ready for cranking:

*Pop*

And, here's the magic-sauce revealed.....

wait a second, there isn't any magic-sauce. This is pretty much exactly what I was expecting. The motor has a YASA-style construction, with independent segments of steel lamination and winding, all fixed to an aluminum hub.

Everything on the inside is thoroughly doused in epoxy and some red stuff I've seen in other motors before but don't know the name of:

And here's the magnet array. Each magnet is made from 3 sub-magnets. Not sure why exactly. Ease of assembly, maybe? There's no halbach array, or any other magnetic fanciness going on, at least as far as I can tell.

Before taking the motor apart, I thought there might be a hallbach array, since the entire rotor appeared to be aluminum, but no flux seemed to leak out the back of the rotor. However, scraping off some of the epoxy between the magnets, it looks like there is indeed some steel behind the magnets:

Zoomed in view. I can't tell if those are actual laminations, or just coarsely-turned steel, but it definitely feels like steel.

And here's the fully exposed stator.

Both halves of the rotor had an "N" scratched into the anodizing by hand, presumably to help line up the magnets on the two halves of the rotor.