DirectDrive v1.0: First Three-Phase Tests

After provisionally solving the first big problem with DirectDrive v1.0, the current sensor coupling, it was time to port my three-phase brushless field-oriented control software over and do some testing on an actual motor. I decided not to bother with Pneu Scooter's hub motor, since at most it could handle 750-1,000W for a short period of time and I'm looking to hit 5-10kW peak. Though really it would be a better intermediate step than what I wound up using...

Nothing about this seems like a good idea now.

"Isn't using an electric ducted fan to load test a motor controller a great idea? It can sink tons of power and it cools itself!" Well, that was the original thought anyway. This is the giant 120mm EDF from Hobby King, which can produce upwards of 4kg of thrust (the same as KM Scooter's eight blower fans...combined). They're meant to be used in model jets, but you could probably do other things silly things with them if you wanted. I bought one specifically for load testing, since they're only $43. Mine uses a this 4030-1100 motor.

With this load tester, I thought I would try something new for sensing rotor position. I printed out an optical encoder disk with eight black and white segments, which I double-side taped to the back of the motor:

And I used a three-phase set of infrared optical reflectance sensors to pick up the signal:

These mimic the function of the Hall effect sensors I would normally use in this application. They differ in a few important and annoying ways, though. For one, they are analog sensors, producing a variable voltage in response to the relative reflectance of the surface in front of them. To get them to act as digital inputs, I have to set them up with a 10k pull-up resistor and put them at about 4mm from the encoder disk. Then, they produce a 4Vpp square-ish wave. But with a 10k resistor, the normal RC filter I would use on the Hall effect sensors won't work, so I had to swap it for one with lower capacitance. The net result is a sensor signal that is less precise and more vulnerable to noise than Hall effect sensors would be.

Back to that in a minute. First, I made the awesome copper heat sink a more permanent feature by drilling and tapping 4-40 mounting holes for it:

Notice that I still have the wires coming straight off the board in the direction that minimizes coupling of the two Hall effect-based phase current sensors. I set up the load test rig on what has become the Table of Load Test Rigs:

Notice the face-to-face dynamometer in the background.

The software on my laptop might look familiar. It's the same GUI and data logging setup I used for Cap Kart and Pneu Scooter - very handy tool. One thing that's nice about DirectDrive is that, for whatever reason, it doesn't cause my USB port to freak out when it's under load. So far I have not had to use the XBee radio to collect data.

I somehow managed to get the right sensor and phase combinations on the first try, and was happy to see that  the motor spun up nicely. The current sensors, temperature sensor, and other bits and pieces seemed to be working properly. But the motor was drawing way too much current, even no-load (with the fan rotor removed). By that I mean it was drawing almost as much current with the fan as without. Now, this is a load test, so in some sense that's good, but I would prefer the majority of the power to get dumped into the air, not the motor.

After a day of debating (grad student-ing), I decided that the most likely cause was the shady optical sensor rig. On a hunch, I took the data I had collected from the test run and did a histogram of the sensor states. There are six: 001, 011, 010, 110, 100, and 101. If everything is working properly, they should all occur with the same frequency.

If instead your sensor histogram is giving you the middle finger, well then you know you have issues. You can even figure out what the issue is with a little bit of logic:

The top set is what the sensor signals should look like if things are working properly. The bottom set has Phase A shifted left a bit. The result adds time to states 3 and 4 and removes time from states 2 and 5. And guess what:

That was exactly the problem.

I was able to tweak the position of the Phase A, and it definitely helped, but I think the motor still draws a lot more no-load current than it could if the sensor timing were more consistent. The edges of the square waves are also pretty soft, and I'm relying on the input pin Schmitt triggers to make it work. It only gets uglier at higher speeds.

Speaking of high speeds, there is another reason why this is a stupid load test. Thus far, the fastest motor I've run with my FOC code is the 40,000rpm 2-pole inrunner from my RC car. But at those speeds, the rotor position estimate starts to become imprecise and unreliable. Now this is a 20,000rpm 8-pole outrunner. The electrical frequency is over 1,000Hz. Trying to fit a sine wave at 10kHz onto 1,000Hz is almost useless. High speed FOC is an interesting problem, but not one that I want to solve simultaneously while load-testing a brand new controller design.

So, sadly, I may have to abandon my new load tester. It can get to high currents, since the motor has such a low resistance. De-tuning the timing by even a few degrees in either direction causes the current to quickly shoot up, even at low speeds. So I ran it at 50A, and nothing seemed to mind, but it's 50A at something like 6V output instead of the 50A at 40V output, which would be a much more interesting test. Unless I can get the fan rotor up above 10,000rpm, which isn't going to happen easily, there's just no way to get any power through it.

Time for a new plan.