Flying Flux v1.0

New speed record: 9 days between motor controller designs.

3ph v4.0 was finished up last week, and even though it's an x.0 and I sometimes have bad luck on new major versions, I am pretty confident in the design overall. Pushing the 3ph line back to optically-isolated gate drive puts it in the same class as some of my most reliable controllers to date, such as Cap Kart's half-bridge, the Victor 883107-7, and 3ph v2.1. It's a low-risk modification that I think will pay off in cleaner analog signals and higher reliability.

And now that 3ph has become the stable design, I need a new experimental design. I've been meaning to try out a motor controller based on the Texas Instruments DRV8301 since it came out. This "everything chip" combines a three-phase gate driver with two current shunt amplifiers, an on-board gate drive supply with charge pump, and a separate buck converter for powering external logic. It seems too good to be true.

I've also been meaning to build an motor controllers to satisfy the requirements of RC aircraft, which is no easy task. I am much more at home with vehicle controllers where I can afford the weight of giant heat sinks, and the volume of separate logic and power boards, and the cost of fully-isolated gate drivers. But my RC friends have been urging me to try to execute advanced BLDC control with the power density and economics of commercial ESCs.

And then there's this:

Some clever people sent me a Cinestar 6 hexrotor frame, complete with motors, knowing that I wouldn't last long before deciding to build custom ESCs for it. To be fair, the commercial ESC that goes with it, a MikroKopter BL-Ctrl v2.0, is way more compact than anything I would make. But, it's an ATmega168/328-powered-square-wave-drive-ESC-with-direct-battery-voltage-derived-discrete-component-gate-drive that I can't bring myself to use.

So then, Shane, stop hiding behind massive heat sinks and low-RPM vehicle motors and design an ESC:

Introducing: Flying Flux v1.0

A quick overview of the features:

• MOSFETS: IRFS3107-7 (75V) or IRFS3004-7 (40V), depending on the application. I love the D2Pak-7's. Cap Kart (all 300A of it) runs through four of these in parallel. There will be no heat sink other than the copper on the board and the wires coming off it, so I'm entirely relying on the low Rds to keep it cool. It's a heat-shrink-to-waterproof-style design.
  
  
  
  
  
• Gate Drive: DRV8301, the everything chip, a 2A gate driver and a risky bet. I'm generally not a fan of everything chips because they put power and signal together in a way that makes EMI isolation very difficult. But it can't be any worse than driving MOFET gates directly with an ATmega328, right? I hope?
  
  
  
  
  
• Current Sense: Two phase return current shunts, plus the internal amplifiers on the DRV8301. This is my first attempt at using current shunts instead of Hall effect sensors. Pros: potentially more accurate, conducive to synchronous sampling. Cons: Not isolated. That risk seems to roll up into the overall DRV8301 risk.
  
  
  
  
  
• Logic Supply: The last trick up the DRV8301's sleeve, an on-board buck converter. It already has an internal gate drive supply, but this extra buck converter can be used to power the logic at 5V. It's compact and relatively beefy: up to 1.5A output.
  
  
  
  
  
• Micro: Would I use anything other than an STM32F103 at this point? I can directly port SSCFOCC over to this controller, although it will need considerably work to get up to the commutation frequency required to drive high-speed outrunners (target: 1200Hz). This is the first motor controller I've done with an integrated STM32F103, not on its own separate logic board. Noise is by far my biggest worry. Every pin going toward the gate driver has a resistor in series with it and I do my best to keep the grounds separate, but I won't sleep as well as I do with optically-isolated gate drive and separate logic boards.
  
  
  
  
  
• Inputs: Here is where this controller is much more capable than any of my previous ones. In order to accommodate as many possible applications as possible, I included every input I could think of. On the left side of the controller, there are three multi-purpose inputs that can be used for Hall effect sensors or A/B/Z encoder tracks or phase voltage sensing (on board) or as general purpose analog or digital I/O. On the top of the board are UART, I2C, analog, and PWM inputs for control. I2C and UART outputs can be used to send data back to the master controller. Oh, and I snuck on one more option:
  
  

  

  On-board XBee.

  The board can be programmed either with a standard FTDI adapter or no-touch over XBee. I was a little annoyed to find out the the FTDI adapters don't use RTS and DTR, the two useful signals for triggering the bootloader. They use CTS and DTR, and CTS can't really do anything. Why, Sparkfun, why? I guess it matches the FTDI cable. Why, FTDI, why? Anyway, this necessitates a boot mode button for wired programming. The XBee can handle DTR and RTS, so it can do completely wireless no-touch programming.

That's the design in a nutshell. As usual, I will post the schematic and build files once it's confirmed to be not DOA. It was a very complex routing job, but strangely cleaner/easier than 3ph v4.0. I think I was just on a roll from having designed two controllers in a row. I also learned a new EAGLE trick, which I call a bus rotation. Picture this scenario: you have four related signals (e.g. VCC, GND, TX, RX) and you want to change their order  for more convenient routing, specifically by shifting the sequence by one. You could do this with vias, but if you're right on top of something and can't spare the opposite layer space:

1206 resistor network to the rescue.

Of course, the goal will be to demonstrate SSCFOCC in a direct side-by-side comparison to a commercial square wave commutation, fixed-timing ESC. One nice thing about propellers (as opposed to scooters) is that they provide a very repeatable load that is (in the case of static thrust, as on a multirotor) only a function of RPM. So, I will consider the project a success if I can run the same motor and prop to the same RPM with less power input than a square-wave controller at optimal timing. Or maybe, to demonstrate the benefits of field-oriented control, run at several different RPMs in a reasonable operating range and show greater total efficiency.

There's a lot of work to be done on the way to that goal, though. So far, I haven't had much success with high-RPM field-oriented control. My RC car sort-of did it, but that was with Hall effect sensors and the rotor angle was still way off, so the efficiency sucked. I believe it's mostly a matter of filters and control, accounting for any sources of lag that the field-oriented control doesn't automatically take up. That, and pushing the control loop up to 32kHz, should be able to make it work. Fun.

For now, I can at least take a short break from EAGLE while I wait for the boards.