FF v1.0: First Spin-Up

Actually first, a little bit of micro quadrotor: I modified the timing of the TB6588FG motor control ICs on 4pcb. They were initially set by me to 0º (neutral) timing and I never thought about it after that. But since I discovered that command saturation on one motor is the cause of instability at low battery voltages, I thought I would give the timing adjustment a try. The theory: with advanced timing, the motor will generally spin faster for a given voltage command. The average command required to hover will be lower, so the margin left for control will be increased.

I ran it with 15º and 30º timing, flying from a full battery until it became too difficult to keep in the air (typically around 3-5 minutes). The average command did in fact decrease with advanced timing, although not by much:

Experimentally, the 15º setting seemed to be the best of the three. The 30º may have had more command margin for control, but it had shorter flight time, possibly because it uses too much current. The real solution might be to use a 3S/370mAh battery instead of the 2S/460mAh, since the TB6588FG would actually prefer more voltage and it would give lots of command margin.

Okay, I'm putting the micro PCB quadrotor away again, I swear. (I'll have to build a pico PCB quadrotor soon to keep up with the miniaturization trend.)

My FF v1.0 compact motor controller boards are in. It's the smallest (physically) motor controller I've attempted to build so far, with a footprint of 3.0"x1.5". Unlike my vehicle controllers, it's also designed to run without a heat sink, so it can be heat shrunk and buried inside of something.

The size and placement of the DC bus capacitors in this version is not ideal. I would prefer to have one or two long electrolytic capacitors sticking out the side in the direction of the wires, then maybe an array of ceramic ones mounted on the board. With that configuration, it would be only as thick as two sides of FETs. The XBee is an optional add-on that can be used for wireless programming, data acquisition, or radio control. Otherwise, it will have headers for PWM or serial-based control sticking out from the side opposite the power wires.

The most critical thing to test on this new controller is the Texas Instruments DRV8301 three-phase gate driver / dual current shunt amplifier / auxiliary buck converter controller / washer / dryer / smartphone / multi-tool. After a small amount of messing around with SPI code (the DRV8301 is configured by SPI, whereas the DRV8302 has hard-wired resistors for changing settings), I was able to get the gate drivers running. I had accidentally specified an insufficient amount of gate drive power supply capacitance, on the GVDD pin of the DRV8301, so I initially got a flood of GVDD undervoltage faults. After bumping it up to a 4.7μF, 16V 0603 (those exist?) I got much better results:

High side (top) and low side (bottom) gate drive waveforms.

High side turn-on and low side turn-off.

High side turn-off and low side turn-on.

GVDD ripple during low side turn-on.

First observation: Yes, I am using a new Tektronix DSO. It's...idk, I miss using the analog one. But this one can save images directly to a USB stick. The future is now.

The turn-on and turn-off times look appropriate for a 2A-peak gate driver on an IRFS3004-7 monsterFET. I get the impression reading the DRV8301 datasheet that this is slightly beyond the scale of FETs this chip was designed to drive. But it seems to handle it okay with the scaled-up GVDD and bootstrap capacitors. The last image is the GVDD ripple when all three low side FETs turn on simultaneously (also allowing the bootstrap caps to simultanously recharge). With the 4.7μF GVDD capacitor, the voltage dips from 11.5V to about 10V. The unvervoltage fault kicks in at 8V, so I think I'm still okay.

My shady math indicates that with these turn-on / turn-off times, the switching losses should be about 20W at 15.625kHz, 25V, and 50A RMS. Add to that about another 10W of conduction losses and the total dissipation at peak current would be 30W. I'm counting on the heat sinking of the wires, which I have no good way to quantify, so I'll have to wait and see if this is an acceptable amount of dissipation. It's also entirely possible that the whole thing freaks out due to noise way before 50A RMS.

So far, I've ported the code over from 3ph v3.1 (Pneu Scooter's present controller) to FF v1.0 for testing. Since I had already switched it to synchronous current sampling and sensorless control, the only real modifications required were changing around some pin definitions and adding the SPI configuration routine. After fidgeting for a few minutes with current sensor polarities, it now spins Pneu Scooter's motor the way it should:

And it is running entirely sensorless, using the same flux estimator as 3ph v3.1. One really interesting discovery is that it produces a nearly identical flux estimate vs. angle plot:

From 3ph v3.1.

From FF v1.0.

I'm not surprised that the flux estimate has the same magnitude and general shape, since it is the same motor. What's surprising is that the irregularities are the same. There's a break at about 200º that I have yet to find a good explanation for. Also, there are sections that are cleaner than others. I thought this might be due to differences in the current sensors or something, but this is entirely new hardware so now I am wondering if it's a software issue. I'll have to replicate the same plot for the other two phases to see if there are more clues to this mystery.

But why am I testing it on a scooter? I want to use it on a giant hexrotor. So far, all of my sensorless testing has been done on a 14-pole motor that maxes out at about 1,500rpm, so about 175Hz. Now, I need to run it at 10,000rpm with the same pole count. 1,168Hz commutation with a 15.625kHz switching controller is going to be a real challenge. So for the next short while I will be attempting to modify the software for high speed operation, and then testing it side-by-side against a commercial controller on some high-RPM brushless outrunners.

Once it's undergone sufficient load testing that I am convinced it won't just blow up, I will post the design files.

Next week I will be attending the Texas Instruments C2000 MCU Real-Time Industrial Control Training in Waltham, MA, where I will likely be ridiculed for using ST microcontrollers with TI gate drivers. In any case, I will hopefully learn some more motor control tips and tricks from the experts, including Dave (Wisconsin) Wilson from the TI Motorblog. I first found this blog when he posted the Ten Commandments of Digital [Motor] Control (Part 1 2 3 4 5), which is a must-read for anyone who wants to do motor magic. I'll likely make a summary post after the workshop concludes on Thursday.