3ph HD: Controller Port, Part 1

The summer's coming to an end, and one of my goals was to finish my transition from the MSP430F2274 to the STM32F103. Changing microcontrollers is a real pain in the ass, and not something I would want to do more than once every couple years. To motivate the transition, I am building yet another motor controller, the 3ph HD, that will have all the functionality of a half-3ph-Duo, but with twice the power and, most importantly, the ability to play three MIDI tracks through the motor.

Here's the new board. It's 3.9"x1.55", which is exactly half the footprint of the 3ph Duo. This is made possible by the compact IR21844 (or I guess it's now the IRS21844) gate drivers, the footprints for which you can see in the upper-left corner of the board. The MOSFET mini-brick, if it's not clear, goes on the other side. I've also apparently now completely given up silkscreened component designators (R12, C15, etc).

What the heck was that resistor again? ::Opens EAGLE.::

The soldering went easily enough, and there were no mechanical interferences. Here are a few views of the assembled board:

The capacitors I was worried about  (the small ones) clear by about 0.5mm...

The business end.

It might be small, but I really hope that with an adequate heat sink this board can hit the 2kW mark. That would make it pretty ideal as a scooter/bike controller, though I have no immediate vehicular plans for it. Before I can even begin thinking about that, though, I have to go through the arduous process of porting the control software to the new microcontroller. And before even that, the low-level functionality that one takes for granted like: "How do I even set a bit?" "How do interrupts work?" "How do I read an analog value?" I call it the "primer," because it's the absolutely essential bit of microcontroller-specific syntax.

Luckily, the STM32 lay of the land is very compatible with that of the MSP430. In fact that's one of the reasons I chose this over other ARM-based microcontrollers. Timers and PWMs are handled in a very similar fashion, as is analog-to-digital conversion. Interrupts are a bit different, but not in a bad way. The prioritization and nesting mechanism for them is much more apparent, which is good because I plan to use it. The biggest advantage, though, is the hardware multiplier. Oh, what I would have done for a hardware multiplier on the last controller...

Speaking of which, after I ported the bulk of the core functionality, I couldn't resist a benchmark. I copy-pasted the field-oriented control code from the previous 3ph controller (the scooter one) and changed the relevant variable names. The STM32 has a wonderful "extra" timer called SysTick that can generate high-priority interrupts. I decided to use SysTick to do my dirty work, the sine wave interpolation routine. This is the "fast loop" of the FOC code, the one that gave me all the problems in the 3ph Duo.

In the Duo, I hijacked one of the PWM timers to process the fast loop at 14.5kHz. It make sense: Why interpolate faster than your PWM generation? But it messes with the PWMs and required a good deal of hacking to get it to finish in ~50μs to give the slow loop some foreground time in which to run. This scope trace shows the relative time spent in the fast loop (high) and out of it (low):

Not ideal.

A lot of that 50-ish microseconds is spent scaling the PWM.  (The sine table look-up is actually pretty quick.) That's because the MSP430F2274 doesn't have a hardware multiplier, so it spends several dozen clock ticks shifting and adding things to "multiply" two numbers together. Division is even worse: The dimmer line in the scope trace is the extra time it takes to calculate the motor speed, which involves a single integer division.

The STM32 is an entirely different beast. Even though it has the same clock frequency (16MHz), it eats integer multiplies for breakfast and spits them out in one clock cycle. The result is a much faster fast loop, without pulling any hacks.

With SysTick set comfortably at 10kHz, the fast loop only runs at 10% capacity, including the division  for speed calculation. Certainly the slow loop also needs some processing time, but I never ran into problems with it even on the 3ph Duo, so there should still be plenty of leftover processing capacity. It could be used for things like sensorless state estimation, more advanced control loops, or injecting MIDI tracks into the phase PWMs...

First, though, I need to get back to the state where I know the core control algorithm is working.

Cue the scooter motors.

I made a nice heatsink block and hooked everything up to the rear motor of the BWD scooter. Unfortunately the USB connector on this board is sort-of flaky, so I'm going to need to change it or find some XBees that haven't been infected with the 10C0 firmware/virus. (Seriously, all my XBees have been bricked by this firmware from 2008...) But hey, once I figure that out, it'll give me a chance to test wireless programming.

I did manage to get the controller running in "dumb" mode so far, just setting a fixed magnitude for the sine waves and letting 'em run. This confirms most of the hardware functionality, since in order for the motor to spin correctly (not with horrible noises) the three gate drivers, six MOSFETs, and three Hall effect sensors all need to be doing their jobs. So at least I didn't totally mess up the board. 

In fact, as I would have expected, the motor is almost totally silent with sinusoidal commutation. I tried to take video of it, but there is so much background noise from fans (it's 90º in Cambridge) that it's not clear that the motor itself is silent. So you'll have to wait for the next video. Except by then it might not be silent anymore.......

3ph HD: I'm serious about this MIDI thing,

While I've been waiting for the circuit boards for the 3ph HD, I could have been porting every piece of code I've ever written for microcontrollers over to the STM32F103. At least, all the things I would need to make a functioning motor controller: clocks and timers, PWM output, digital I/O, ADC, UART communication, interrupt handlers. All of that. It's a known unknown. In other words, I know what I have to do and I just haven't spent the time scouring the 1,072-page reference manual for all the right register and bit names to make that stuff work.

The "clock tree". Page 84/1072.

After I wade through the fundamentals, I'll also have to port over the actual motor control algorithm. It will be indistinguishable from the controller currently implemented on the 3ph Duo, a modified version of something called a synchronous current regulator. If you're really really interested, I updated my documentation of the control scheme to include some fun new graphs.

Oh, I get it now.

Enough of that.

Instead, I've been working on the unknown unknown: how to encode the three tracks of music to be played on the three phases of the motor? I settled quickly on MIDI, for two reasons. One: It efficiently encodes the type of audio I want to play, namely three tracks of music. No vocals. No intermediate frequencies. Just what you can find on the keys of a piano. I'm not saying you can't send pure audio to the motor (just use it like a speaker), but my goal is to replicate 8-bit video game music, which is a simpler format. Which brings me to the second reason for using MIDI: Tons and tons of 8-bit music libraries.

And yes, I have picked out the first test song. I've pretty much had the first song picked out since before I started the project. It's known only as "Track 1" and is from Top Gear for the SNES. (Trivia: The first video game I ever owned. It came way before the car show.) It's also got one of the best 8-bit soundtracks ever. If you don't believe me, ask Muse.

Time for another VB GUI, to piss off my programmer friends.

I must admit, I enjoyed writing a MIDI file parser. It's nice when you write code that won't cause things to blow up or fall over if it doesn't work. If it doesn't parse correctly you just...try again. Is this what I passed up by not pursuing my early career ambitions as a programmer? Risk/danger free debugging? Anyway, I know it's right now because the length of time of the parsed data is the length of the song, and I can see from the note visualization that it's at least got the general melodic form of "Track 1".

MIDI is actually pretty easy to parse, if you don't care about anything other than notes. Every event has a delta-time stamp. By incrementing an absolute time counter while stepping through the file, every note can be assigned an absolute time stamp. This is what I will send to the controller: [Timestamp, Note]. Since the controller can't store a full song in RAM, there will be three streams of this and some yet-to-be-determined buffering routine, but that's essentially the plan. There are "note on" and "note off" commands, but I'll lump everything into one packet format and send an inaudible frequency like 20kHz as the "off" note.

Now I should get back to the motor controller part...

Cap Kart: Shakedown

First, some new test drive video:




As good as that looks, it did not come easy. In the last test drive, the kart suffered a MOSFET failure after just a few runs. For those unfamiliar with power electronics and motor control, the MOSFETs (or IGBTs in higher voltage controllers) are the primary elements that control how much current gets sent to the electric motor. A good analogy in an internal combustion engine might be the throttle body. When they fail, it's usually the end of driving.

IXYS VMM 1500-0075P: Possibly the largest MOSFET you can actually buy.

Tracing through the data from the last test drive shows the MOSFET failure clearly enough, but only offers hints about the cause. My best guess was that the 12V supply was insufficient for the gate drive optocouplers (Avago HCPL-3120) that turn the MOSFETs on and off. They're really designed for 15V supplies, and the combination of a smaller 12V battery and a higher gate charge requirement on the large MOSFETs may have tipped them just over the edge. If they shut down permanently, the kart should just coast, but if they shut down and come back on after a brief interval, the MOSFETs may see a quick burst of current since the controller feedback loop had been broken and it needs to "find itself." Should this destroy the FETs? Probably not. Did it? I don't know.

In any case, the data and some bench experiments confirmed the presence of some current spikes when running the gate drive on 12V. Switching to 15V eliminated these spikes. Since the gate drive runs off its own battery anyway (for noise immunity), it was an easy matter to change to a small 4S lithium polymer battery, at 14.8V nominal. In a moment of pure overkill, the battery of choice is now a 1.8Ah Turnigy Nano-Tech. Yes, a batttery that could potentially supply 45-90A, powering the 0.5A gate drive and logic circuit on the kart. Where did I put those fuses?

Electrical problems out of the way, it was clearly time to move on to some sort of mechanical failure. And the most obvious place for that would be in the brand new rear axle differential.

Why can't it be this easy?!

After the first test drive, we noticed that one of the snap rings holding the gears on their respective shafts in the differential had popped off and was nowhere to be found. The entire case had also shifted a good quarter-inch. Rather than admit the obvious - that some unconstrained axial forces knocked the snap ring off - we chose to assign questionable blame to things like loose set screws and misaligned chain. Well, the following week we made it as far as the elevator before the snap ring popped off again.

The full extent of last week's test drive.

So, we took it back up the elevator, cried for a while, then decided that what was really needed was a better way to constrain the differential axially. After a few hours of trying to avoid taking the whole differential off the kart, we wound up taking the whole differential off the kart. And by that point, the easiest solution was just to add spacers to the shafts that fix the distance between the outer and inner bearings, as shown in this top view:

The outer bearings are already well-constrained by the shelf that we built around the rear axle. The new spacers, in red, fix the differential in place axially. As an added bonus, one side's spacer accurately sets the gap for the brake disk. This fix took us an entire day, and since we can really only test drive on the weekends, it basically meant one fewer test drive this summer. Bummed as we were, the fix was important. There is no acceptable outcome if the gears fall out of the differential.

Back to present day. If you're keeping track, we're due for an electrical failure now.

The goals for this test drive was to abuse/test the rear axle a bit on our slalom course, and to see if the change to a 15V gate drive supply would save the MOSFETs. The first goal was met unquestionably. No snap rings fell off and the differential seemed perfectly happy the entire time. Congats, Max. The slalom, which was pretty damn near impossible in 2008, is now too easy with the lighter kart and differential. The only real mechanical issue left to deal with on the kart is the somewhat squishy brakes.

Back to the controller. One of the untested bits of the new software was the Costas Variable Transmission that does constant-power field weakening on the separately-excited DC motor. I decided I would just go for it:

You can see me flooring it, the armature PWM maxing out, then the field PWM dropping to almost nil as the kart continues to speed up. The armature current holds at a pretty constant 250A and the battery voltage is right at the 30V cutoff. This seems to work exactly as designed. Upon releasing the pedal, the field PWM first increases, then the arm-- ugh not again. Almost as soon as the current goes negative, bad things happen. Zooming in on the one-second interval around the fault:

Here I've highlighted three interesting intervals. In interval 1, the huge negative current spike (-560A) is detected. It would be easy to blame such a spike on bad regen control tuning, but if that were the case, the power would be going back onto the battery and the DC bus voltage would skyrocket. Instead, it does the opposite, dipping to 15V and then even 10V. To me, this suggests that a ton of power is coming out of the motor and out of the batteries at the same time. And there's really only one place for that power to be going...straight into the MOSFETs...

Luckily, the new fault detection software picks up the problem almost instantly and shuts down the drive. (Thus, it has twice prevented further destruction.) The hard faults cause the PWM drivers to shut down immediately, which is why the armature and field commands drop to zero. Interval 2 is the time between the drive turning off and the contactor opening. (Some time is given to allow inductive energy to be dissipated.) Unfortunately, by this point, the MOSFETs are totally dead. It's clear that current is still going into the motor and coming out of the batteries, even with no drive command. This actually shows up as a brief burst of acceleration, since the controller is no longer capable of throttling the current. The contactor opens between interval 2 and 3, less than a half second after the fault, at which point the bus voltage starts draining through whatever horrible new low-resistance paths have been created in the MOSFETs.

All this happened while I was happily driving along. I didn't realize there had even been a fault until I came to a stop and noticed the DC bus voltage was reading 5V. At least the new software is way smarter than I am. At this point, screw electronics. Seriously. I don't know what the failure mechanism was and the data stream does not show anything that would indicate a cause, only effects. The only thing significantly different about this controller than the one that ran the kart in 2008 are the IXYS FETs. From an experimental troubleshooting point of view, replacing these was the next best target.

Enter MetalFET.

After the previous MOSFET failure, I decided to enact a Plan B since we have only a limited number of IXYS MOSFET replacements. Plan B was a custom-designed circuit board that is more copper than not. And I'm not talking ground planes. I'm talking a serious current-carrying copper bus bar and FR4 sandwich, hence the metal part of MetalFET. Oh yeah, and the FET part...tiny MOSFETs. Tiny only in size, though. These are seven-legged IRFS3107 HEXFETs, the most badass MOSFETs in existence as far as I'm concerned. 

Sorry IXYS, stealing your critical dimensions.

The board and associated aluminum/brass hardware adapts these tiny FETs to the same form factor as the IXYS MOSFET brick, facilitating drop-in replacement. The kart formerly ran on the through-hole version of these IR FETs, four in parallel for 300A. But they were mounted to bus bars that doubled as heat sinks. To get a similar thermal performance for these surface mount FETs, I used unmasked boards and screwed 1/4" aluminum heat transfer blocks to the drain planes of both sides:

The truth, though, is that I really did not want to use these. The IXYS FETs are a much nicer, more professional-looking solution. These are a hack I came up with in a few hours of work (plus three days of waiting for circuit boards). The Cap Kart knows just exactly how to push me to the limits of my patience, hence the original post title. So with really very little time left of summer test driving, we swapped to an untested, locally-grown MOSFET module.

Something traumatizing about the first Cap Kart test drives must have still been in the back of my head, because a few weeks ago I went to Radio Shack to replace the 350W inverter I bought back in 2008 and subsequently lost. Pretty much the only reason I would ever need a 350W inverter would be for field soldering off a 12V battery, and pretty much the only reason I would ever need to do that would be to fix the Cap Kart. And as luck (or lack thereof) would have it, I was able to put it to good use, if only once, to move the gate drive wires over to the untested MetalFET.

Yes, the homemade MOSFET module is now zip-tied to the shelf.

Honestly, I would have given this less than 50/50 odds of working, especially since it was completely untested. But, as luck would have it, it works totally fine. All of the test drive video above was run on the MetalFET. At times it was a bit warm...not hot, just a bit warm... So there you have it - a $30 hack that works where the $300 MOSFET modules fail. Go figure.

That nightmare out of the way, time for some more fun. Here's a run that uses the "three speed manual" mode:

You can see the system traverse peak power three times, with the estimated motor output power (P_Vemf) holding steady at around 5-6kW. While the Costas Variable Transmission mode will do this smoothly and automatically, the goal of three speed mode is to actually feel the gear change "kick" as the field voltage is varied in steps.

And here's one more battery I-V curve:

This is the widest one yet, covering -75A to 300A. The battery internal resistance (V/I slope) remains constant over that whole range. They may not be the most powerful batteries, but the Thundersky cells are remarkably consistent.

The Cap Kart: Overinstrumented? Yes. Of questionable power electronic legitimacy? Yes. But a lot of fun to drive.

3ph HD: Time for yet another motor controller.

I've pretty much stopped designing motor controllers for particular projects and am now just designing projects that allow me to build new motor controllers...

I am thoroughly satisfied with the 3ph Duo v2.1, which I've documented extensively. It's clocked a non-trivial number of miles on the BWD Scooter as well as on my RC car, and soon it will see use on Jed's electric long board. In summary, it's a 2 x 1kW dual sensored motor controller with sinusoidal commutation and field-oriented control.

 3ph Duo v2.1

I even managed to accidentally troubleshoot a longstanding issue with motor "crackling" at high load. Turns out it was due to unstable gate drive and the solution was simply to increase the gate resistor (now 30Ω instead of 10Ω). It doesn't harm switching speed much, since the IXYS GWM MOSFET modules have gate capacitances of only about 9nF. Rule of thumb: Switching time is approximately R*C = 30Ω*9nF=270ns. Still only a small fraction of the PWM period.

Having two motors on one board is convenient for the scooter, but in general it would probably be more useful to have independent controllers that are half the size and half the price. And why not also twice the power? Here is the quick list of features and improvements I am targeting for the 3ph HD, v3.0 in the 3ph series.

1. 1 x 2kW brushless DC (really PM synchronous since v2.1) motor control in half the volume claim of the 3ph Duo v2.1. (So, you could put two next to each other for a controller the same size as the Duo, but with twice the power handling.) Depending on the FET and bus capacitor selection, it could be from 80A@24V to 40A@48V.
   
   
2. Runs on my shiny new wootstick 2.0 (STM32F103-based) microcontroller board. I really need to learn how to program for this 32-bit chip and this will be the perfect motivation. Each controller gets its own dedicated 32-bit processor with three independent timers. No more computational efficiency hacks required. I can also explore sensorless and induction motor control, which require an extra level of processing beyond what I've done so far with field-oriented control.
   
   
3. Uses the cheaper gate drive I tried out on the HexBridge (Arduino BLDC shield). This will keep the costs down so that two of these are no more expensive than a single 3ph Duo, even with independent signal boards. It also saves a ton of board space.
   
   
4. Smaller DC/DC converter. I ran the numbers and discovered that the bulk of my power draw is XBee Pro transmit current, which is ~200mA. (The voltage doesn't matter, since everything from 15V down is through linear regulators.) So I spec'ed a 500mA DC/DC converter instead of a 1A one.

And here's the form factor:

I decided to go with cutting the 3ph Duo volume in half length-wise. This board is 3.90"x1.55", with the possibility of wires sticking out in either of those dimensions depending on the particular mounting provisions. The four 10mm bus capacitors are significantly more than the Duo had, which will add to the current capacity. It has two 5mm standoffs in opposing corners for mounting to a heatsink. The IXYS GWM module is on the bottom, as usual, where its heat transfer tab can be pasted to the sink:

Also on the bottom is a low-profile inductor for the DC/DC converter. The passives for the converter turned out to be the hardest part of designing this board. I wanted to stick with the familiar line of NatSemi converters that I've used for a while now, but they switch relatively slowly and so they really need electrolytic capacitors. But I also wanted to stick the entire DC/DC converter under the microcontroller board, which left just 5.9mm vertical clearance.

Solution: 5.8mm capacitors.

This is why I need EAGLE and SolidWorks open at the same time... But even that isn't good enough, since my 3D model of the microcontroller board doesn't really show what's on the underside. In the end, I had to just look at it in real life. There are a few vias, but no solder joints or objects protruding into the vertical space where the capacitors will go. Which leads me to the question no real circuit designer would have to ask: Are the capacitor cans even isolated? I think they are, but I don't know. If not, Kapton.

Besides the extra bus capacitors, the increased current-handling capability will come from better power trace routing:

In fact, there really aren't even power traces anymore. Wires get soldered very near to the power leads of the IXYS module. There are now three ACS714 current sensors: two phases and one on the DC input. This could be useful for Coulomb counting and/or fault detection. (If 2kW are going in but only 30W are going out......) Each sensor is optionally bypassed by two 1206 chip resistors. This hack allows the nominally +/-30A sensors to work at higher loads by sensing only part of the current.

I guess I have yet to mention why it's called the 3ph HD. It's High Def, yo. Or High Density, since it has twice the volumetric power density of the 3ph Duo.

Or is it Harmonic Drive?

Even though each of the STM32F103's three timers has four channels of PWM output, and one even has three channels dedicated to motor control, I chose instead to use one channel from each of the three timers to drive the three phases in this controller. This wasteful resource allocation pretty much prohibits me from using timers for anything that can't be counted at PWM frequency. (Or does it?) But, it allows me to get to the point of this whole endeavor: Piping three-track 8-bit music through the motor as it runs.

Yes, the main field-oriented controller will still be doing its thing, producing sine waves. These sine waves aren't what you hear, though. In fact, they're pretty much silent since they form a balanced three-phase set. What you will hear is the intentionally low PWM frequency of each phase's half-bridge. (Now you see why the abundance of bus capacitors?) Each phase gets a music track, a sequence of notes and durations, probably. The notes set the frequency of each of the three timers. Ring tones for your motor.

As usual, schematic / files to come if it works.

Auto-Gyro-Twitch

You can probably tell from the first video that Twitch, Jr. is not the easiest robot to drive. Trying to remember which way is forward is just the beginning of the problem. (Which way is forward?) There is also bit of variance between the relative speeds of each motor under the same nominal command. This gets exaggerated by the 4WD omni wheel configuration, especially on an uneven surface.

Here's where a gyro (yaw rate sensor) comes in handy. These tiny MEMS sensors measure angular velocity and produce an analog signal. The signal can be processed by a controller for tasks such as self-balancing, or level flight. In the case of Twitch, I really just want it to keep the robot on a fixed heading unless I tell it to rotate. This should be a simple feedback controller. I learned about that in 2.00...wait actually I did it in high school.

 Lol.

Anyway, six years of training later and it shouldn't be that hard to create a yaw-rate stabilized robot, right? Right?

Well, where do I start? First problem: Twitch's original control mapping software resided on the transmitter side, in the Visual Basic program that interfaces with the USB gamepad. In order to integrate the yaw-rate control loop, the entire mapping algorithm, including the state machine that sets which driving mode is active, had to be moved onto the microcontroller. Okay, this was mostly just tedious, not really difficult. Then I soldered on some more headers in empty protoboard space and added the sensor, a Sparkfun breakout of the LPY530AL 300º/s gyro.

Except, Twitch has a densely-packed electronics bay already, so it's gonna be a tight fit.

 See the headers?

Things had to bend a little, but everything seemed to still work. So, I uploaded the new mapping code with the yaw rate control loop and put it on the ground for some testing. After swapping to sideways mode, though, the receiver radio died. :( I've only killed an XBee radio once before and that was by applying 12VAC to it... So something very bad must have happened. Upon further inspection:

There you can see the radio and a small bit of the gyro in the upper-left corner of the image. You can also make out the plastic back of a Mabuchi motor and a piece of electrical tape. The electrical tape I put there later to cover the exposed motor terminal, which happened to just barely intersect the 3.3V and GND pins on the gyro when the motor swung over into sideways mode. So, the switching 8V line to the motor got momentarily switched onto 3.3V and/or GND. Amazingly, the gyro survived. But the radio did not. After bending the tab out of an interfering path, covering it with electrical tape, and replacing the radio, Twitch was back in business:

The yaw-rate stabilization definitely helps. By request I also added a mode that automatically selects the wheel position based on where the translation joystick is. Actually, this is how I meant to do it originally, I was just lazy and had buttons for changing wheel positions instead. But, now it's much closer to fulfilling the original vision.

Cap Kart: Destroyer of MOSFETs

First, some new test drive video.

Cheesy flashback effect courtesy of Windows Movie Maker. The point is that it turns now, and without drawing 100+ amps to skid-steer one of the rear wheels. This is thanks to the custom-built axial differential spliced in to the kart's rear axle. It works as designed, allowing the wheels to move at different speeds without any slip. This makes easy work of the tight turn at the end of our test strip / slalom course. (Thank you MIT Parking and Transportation and the MIT PD for continued access to the only pothole-free piece of asphalt in Cambridge. It runs under a building and is therefore shielded from the elements.)

You might notice that the test drive was relatively short and the speeds were relatively low. This was the first real run of the new rear axle, new batteries, and new MOSFETs, so we took it relatively easy. Though, in my experience, MOSFETs for the kart don't fail due to steady applied load; they fail spectacularly and for unknown reasons. Cue spectacular MOSFET failure.

This is a graph very similar to the battery testing data in this post, showing a very linear battery load characteristic with a resistance of about 3mΩ per cell. The kart pulls 7kW from the 12S Thundersky 40Ah pack while staying above the low-voltage cutoff. This isn't indicative of a continuous rating for the cells, but it's nice to know that they can hit about 6C peak at least. There is a...minor deviation...from the nice linear battery graph, though. The battery voltage dips way down to nearly 10V while the motor current sensor registers relatively little draw. This means current is going somewhere else. And the only other place it can go, really, is straight through the low-side MOSFET. If you believe that the cell resistance is load-invariant, then this basically means 1,000A shoot-through.

Now, the Cap Kart is no stranger to shoot-through. It's destroyed several half-bridge motor controllers this way on both the field and the armature side. The gate drive is passively protected against shoot-through under normal conditions, so when it happens it's a good indication that the MOSFET has been destroyed. Usually, this is accompanied by fire. But the new Cap Kart has some clever tricks.

Here is a one-second snapsot of the possible shoot-through event. In this frame, the kart reports 17 data packets. It actually only reports every seven control loops, to conserve bandwidth, so really it cycles through about 120 control loops in this frame. You can see the pedal starting to be depressed, followed by an increase in the armature PWM and normal-looking rise in motor current. The first two graphs are about all the old Cap Kart could keep track of, and nothing there is cause for alarm. It's the third graph, of the DC bus voltage, that sets off one of the kart's new fault detections. The DC bus voltage dropping so far is a good indication of a short-circuit, and it triggers an "undervoltage fault" which shuts down the high-side drive and opens the contactor. All in the span of a few tenths of a second. So fast, the battery pack fuse didn't even blow. Yay programming. The FET is still dead, but at least it wasn't dead and on fire.

I was just making sure it was dead.

Why did the FET die? Well, I don't want to spend too much time trying to answer that question because I might never know for sure. It almost certainly wasn't caused by heating from the normal load...it never is. The gate drive and signal side are the same as always, but the new FETs are significantly larger than the 4xIRFB3207 version that ran the kart until now. In fact, they're the largest FETs I've ever seen. The VMM 1500-0075, aka the gigaFET. (Yours for a reasonable price through the magic of eBay.) Could it be that the larger FET has larger parasitic capacitance and is thus more prone to spurious dv/dt-induced turn-on? Could it be that the kart is now running true regenerative braking with synchronous rectification, which is like asking for shoot-through? Could it be that a gate drive wire momentarily lost good contact? Honestly, I don't know.

My engineering approach to such problems is to hedge my bets. Some potential solutions are trivial: Ditch the horrible spring-loaded output terminals on the gate driver board in favor of something that inspires a little more confidence that wires won't be randomly popping loose. Other fixes are more intricate: Implement negative gate drive on the low-side MOSFET to pull the gate low enough that dv/dt-induced gate charge doesn't turn it on. There's also the brute force approach that has served us very well so far: Acquire more MOSFETs and learn how to change them quickly. And the "go back to what works" approach of switching to smaller MOSFETs in parallel. Heck, why not just make a drop-in replacement for the gigaFETs that uses 4xIRFS3107?

Why not indeed?

This board nets even more spare MOSFETs, plus the opportunity to desolder individual ones if need be. Maybe the lower gate charge will make it easier to drive, too. Maybe some combination of these solutions is what is required to get it to not spontaneously self-destruct. And if all else fails, there's always the option of permanently shorting the low-side gates to create a boring non-regenerative-braking kart. Let's hope it doesn't come to that.

The good news: It's way easier to get the kart out for testing thanks to our new shop space.

How did we ever do this without a freight elevator?

 And lastly, some pictures that should indicate how seriously we are about getting it up and running:

Does anyone know how MOSFETs work??

Edgerton Center Engineering Design 2010: Project Highlights

What did you do this summer??

I think the projects speak for themselves, but in case they don't I'll be happy to throw in my own passive-aggressive editorial.

A message to MIT Project Classes (yes you, 2.007/2.009/6.01/6.131/etc): This is what we do at the Edgerton Center in three weeks with high school students.When they come to MIT, they will be bored by what you have to offer. Start making cooler stuff faster or you will lose your most talented students to apathy and/or frustration.

That out of the way, here's a brief run-down of the projects. Some of them may get posted as Instructables in the near future.

Quadrotor!
In each project, an MIT student works with a group of [2 to 6] high school students to research, design, and build a real engineering project. There were supposed to be three projects, but so many people wanted to make a quadrotor that it became the fourth and largest group. And of course I got drafted into leading it.

I have literally zero experience with flying vehicles, but for whatever reason the quadrotor team took my very brief and pulled-out-of-somewhere explanation ("It's like two segways and a tank steer robot.") and ran with it, producing a functional, if twitchy, quad copter build for about $250 with parts from Hobby King and Sparkfun. You might not believe me, but I barely did any work on this project. The fact that it flies is sort-of amazing. It's definitely getting an Instructable.

LED Pong
First there was Pong. Then there was Beer Pong. Now there is LED Pong. The game is played on a 4x3x(8x8) LED matrix. (That's 768 individually-soldered LEDs.) It's just like original pong, except that, like 3/4 of this year's projects, it's controlled by two accelerometers.

Bling Segw@y
I must admit I am deathly afraid of posting video of this on the internet. The reason being that I fear the torrent of emails that will follow. I lived through the first DIY Segway email storm and I don't really want to do it again. Please direct your segway questions to the internet or to the technical documentation on the original website. Kthx.

That said, the new and improved version has something I've been dreaming about for a very long time: a 1/2" polycarbonate base. But they didn't stop there. They added a 1" polycarbonate handlebar and a not-insignificant wattage of LEDs. It's so bright that I can't even really take a picture of it. With the new handlebar comes tighter, more controllable steering.

ExkateCD
The Exkate electric longboard is cool, but it's heavy and doesn't turn. Jed's team came up with a solution: Make it lighter and more maneuverable. (Duh.) They switched it to lithium polymer batteries (formerly lead acid). They also implemented custom-built dual CIM-planetary-gear-belt-drive-pods. I can't really explain them...they're just awesome. With 2WD and springier trucks, it can take much tighter turns, even under power. But it goes last because it doesn't fly and it doesn't have any lights.

Oh wait...

TS-LFP40AHA In-System Data

As part of the Cap Kart Summer 2010 upgrade, we switched from 79Ah @ 36V lead-acid batteries to 40Ah @ 39.6V lithium iron phosphate batteries (Thundersky TS-LFP40AHA). The old batteries weighed 159lbs. The new ones weigh 42lbs. We got them from Elite Power Solutions, and they even came with little carrying handles:

One of three 13.2V modules.

The loss in capacity is somewhat overstated since lead acid batteries are rated at fractional C rates, while the lithium ion batteries are rated at 1C. They also came with balancing boards, but they don't even fit on the cells. (The drain FETs don't clear the vent caps without additional washers to space them out vertically from the terminals.) Not worth the extra $100. Get yourself one of these instead for $13. They don't balance the cells for you, but they do have an audible alarm for over and under voltage, so you know to stop driving or stop charging and balance if necessary.

I was a little worried about the power-handling capability of these cells, since they are only rated for 3C continuous discharge (120A). The kart at full tilt sends 300A to the motor. I wasn't expecting 300A from the cells (except at high speeds, the motor current is higher than the battery current), but something around 5C or higher for peak discharge would be nice. The internet is fairly bad at documenting the capability of these cells. The closest thing to consensus I found was a per-cell resistance of about 3.5mΩ. Assuming a low-voltage cutoff of 2.5V and an open-circuit voltage of 3.3V, that gives a peak current of (3.3V-2.5V)/0.0035Ω = 229A, and a peak power of 2.5V*229A = 573W. With 12 cells, that's almost 7kW, which would be just about right for the kart.

Enough math. Here's some on-kart test data:

This is for the full 12S battery pack and includes the resistance of the bus bars, fuse, wiring, manual switch, and contactor. It's at about 75% SOC and shows both charge (regen) and discharge data. The output is very linear, which I guess makes sense for a cell with relative high DC resistance. The resistance per cell came out to about 3mΩ and it has no trouble putting out 6kW, with still a bit of room before the low voltage cutoff (30V for a 12S pack). In other words, works as advertised by the internet or slightly better. For the price, hard to beat these cells. But don't expect to win a drag race against A123s.

If nothing explodes, there should be new kart test drive video soon!

Cap Kart Summer Rebuild 4

The Cap Kart runs again, field driver curse notwithstanding.

First, the mechanics. We just needed to mount the freshly-cut rear axle to the outputs of the brand new differential. Except how do you connect a 34mm I.D. hollow axle to a 1-1/4" (31.75mm) keyed shaft?

Step 1: Fill the gap with a flimsy-looking aluminum sleeve.

Step 2: Fill the keyway with flimsly looking 8-32 small pattern hex nuts.

Step 3: Fill the nuts with flimsy-looking 8-32 brass-tipped set screws.

The only good thing I can say about this is that it doesn't do what you think it does. The 8-32 screws are not in shear; they're in compression, pushing up on the nut and down on the shaft, such that at least some of the torque is transmitted through friction interfaces and there isn't any backlash. I don't know if that makes me feel any better about it, since couplers for this size shaft tend to be much beefier looking. But this costs nothing, weighs nothing, and might work. My horrible standard for judging this is that the traction-limited rear wheel torque is something like 100ft-lbf. And I would totally hang off a 1-foot bar attached to this...

...Moving on to software.

Is that a game?

We finally got to load the code. Costas wrote the State Machine of Doom to handle the multi-mode electronic transmission, as well as a whole new set of fault codes that I wish we had back in 2008 when we were regularly blowing up motor controllers. The kart transmits 13 bytes of diagnostics back to a waiting laptop at 20Hz, including one byte of potential faults ranging from "hard faults" such as loss of accelerator signal to "soft faults" like battery power limiting. If anything goes terribly wrong with the controller, the data logger is like the black box.

Even if things go right, the data is still useful for performance analysis. For example, testing the effective resistance of our brand new 40Ah Thunder Sky batteries.

What you see there is actual kart data recorded during a bench test. Battery current is the same as motor current, in this case, because it was run up to 100% PWM and full throttle before engaging the load (i.e. the brakes). Since the motor controller measures motor current and battery voltage, it was a simple matter to cross-plot them to find the effective resistance of the pack. A 6V sag at 150A gives a pack resistance of about 40mΩ, or a per-cell resistance of about 3.3mΩ, right on target. That means an effective peak power of about 7kW from the 12S battery pack (taking 2.5V per cell as a soft limit), the majority of which goes to the ground (we hope). Add in an extra 3kW of on-demand capacitor boost and you get reasonable power out of just 50lbs of energy storage.

That all seems very easy, but if Summer 2008 was any indication, there is no way it all just works. And if one part were to break, I know exactly which one it would be. So continues the curse of the field controller.

Now, there's no real technical challenge to the field controller. It's not like the monster 300A synchronous half-bridge that drives the armature. It's a 10-15A drive into a load that looks like a 1.3Ω resistor and a giant inductor. The current in sets the field strength of the SepEx motor, which in turn sets the torque-speed curve.

But the problem isn't ever a technical one. Curses don't work that way. For example, one time, the reversing switch welded itself shut, taking out the rest of the controller when it was switched back to forward, shorting the battery through the field-drive FETs. This time, the curse first manifested itself in the form of some really shady-looking gate drive waveforms:

That turned out to be a simple problem to fix; it was only on the high-side drive which led me to the conclusion that it just needed a bit more bootstrap capacitor and a bit less pull-down resistor. But it still made this annoying crackling sound at high loads. In fact, it's very similar to the crackling sound I've heard before and always attributed to the switching regulators on my controllers. Except this controller doesn't have any switching regulators... I decided to investigate more. And by investigate, I mean destroy the entire field controller.

This is what happens when you use two of the same color alligator clips. Inevitably, you clip the two load leads together and the two outputs together. This short-circuit immediately vaporized a trace on the circuit board...

...which in some cases would be fine. But this time the resulting voltage spike took out 3 out of 4 MOSFETs and both gate drivers. Are you starting to see what I mean by the curse?

Anyway, with a new set of MOSFETs and gate drivers, plus a little help from real electrical engineers, I finally tracked down the source of the crackling to over-aggressive gate drive. The turn-on waveform would occasionally ring or go unstable. Turns out in some instances it actually helps to slow down the gate drive a tiny bit to regain stability. Kinda defies my whole understanding of gate drive, which to this point had been "go as fast and as hard as possible." It makes me wonder if I can go back to my old controllers and fix the crackling the same way...

But for now, everything could finally go back together for a spin-up of the brand new rear axle: