Friday, December 10, 2010

Brake, Lights, Tacos, and the Rad Hardened 3ph 3.1

I've been braving the cold to get in more Pneu Scooter test driving. The first test drive was this 2.1 mile campus tour, after which I predicted a total range of 4-5 miles. But in order to actually test that, I wanted to take it off campus to one of the locations that I felt might be in striking distance: Taco Bell. (I was also hungry.)

Before I even started that trip, though, I had to put on the brakes.

No, literally.

Like everything else about the front fork design, the brake layout just somehow works. I didn't plan it beyond having a pretty good idea where I would attach the calipers (which came from here). The strange vertical orientation of the pads was not part of the plan but worked out nicely anyway. The metal disks serving as makeshift brake surfaces are massive shims I got from McFaster-Carr (PN: 97063A136). (Seriously, I missed being able to just order random shit like this so much when I was in Singapore.)

Pneu Scooter does have regenerative braking. Not the type that you put on a roller coaster in order to power an entire amusement park. (Seriously people? Do you not understand regenerative braking or do you not understand roller coasters?) But it does capture an insignificant amount of kinetic energy as you slow down. I have it set to pull 10A back out of the motor when you fully release the throttle, which is enough drag that I almost never need to stop any faster. The mechanical brakes are mostly just a back-up in case the controller fails.

I should be adding brake lights, or handlebar headlights, or something related to safety, but instead I went with running board lighting:

It's just four LEDs powered by the balance leads for the batteries, which are up front anyway. The LEDs are embedded into the side of the polycarbonate skid plate, so some of the light creates a Tron-like stripe on the bottom of the deck. I think it's less obnoxious than cold cathodes.

So, off to Taco Bell!

This is what it looks like to go to Taco Bell.

Notice the phase advance effectively canceling out d-axis current the whole way. (What?) I've got to believe this adds a mile or so to the total range of the scooter, as compared to blind current magnitude control or something like that. It's ensuring that every amp that goes in is producing torque.

Here's a 60 second window of relatively high power cruising:

The peak is about 750W in and 500W out. You can see it tracking the q-axis command so well that the command and the measured value basically overlap. The total round trip summed to 3.7 miles, with an energy consumption of 90Wh, for an efficiency stat of 24 Wh/mile. Of the nominal 4.4Ah capacity, 2.7Ah were used. From this I conclude that the full range is probably about 5 miles, on the high end of what I estimated last time. The stator was borderline frighteningly hot after the trip, so I don't think I can push the current much more than what it was here (40A peak).

You might also notice the random downward spikes in the current data. These are the microcontroller program counter getting randomly thrown into empty program memory due to something horrible that I don't even want to think about. I've got the watchdog timer set to reset the processor if the control loop stops running, but each reset is accompanied by a momentary loss of torque that is somewhat disquieting, especially since it tends to happen at peak current. I added a bunch of countermeasures to the 3ph HD to try to eliminate these resets, but none completely solved the problem.

Cue the Rad Hardened 3ph 3.1.

Ok, it's not actually radiation hardened, but it is protected in many ways from the sorts of noisy electromagnetic nastiness that accompany a 40A hard-switching power system. I don't know or care exactly which of the additional protections contributes most; this is more of a shotgun approach to noise reduction employing everything short of optocoupled gate drive (the fallback plan). Here's the new, cleanly net-labeled schematic of v3.1.

(Click to enlarge.)

The new logic power supply is an isolated 2W DC/DC converter made by TI (DCR021205). After finding that some extra resistance in the connection between logic and power ground greatly improved the performance of the previous controller, I decided an isolated supply might be a good idea. Somehow, TI crammed a transformer-based 2W DC/DC converter into this:

(For scale, that is a 1206 capacitor.)

This is great, except, I can't really float the grounds, for two reasons: One, my battery voltage measurement is not isolated; it's just a resistive divider and low-pass filter feeding the ADC. And two, the gate drive can only tolerate a +/-5V offset between logic and power ground. So, I still need to tie the grounds together, but ideally no current should be flowing directly between the two. Dilemma? Yes. That's why I have the value=IDK resistor bypassing the isolated supply. I honestly don't know how to choose it. I randomly guessed 1k, and it seems to work, but there is a 1.3V drop across it right now. Why? I don't know. If it doesn't impact functionality, I don't really care.

Stage two of the ruggedization plan involved, to steal a phrase from Amy, "capping the shit out of everything." The capacitor in the picture above is just one of many 100uF, 1206-package low-ESR ceramic capacitors now bypassing the 5V and 3.3V rails across the board. Additionally, I moved all the low-pass filter capacitors right next to their respective ADC pins to eliminate the current sensor noise I discovered in Singapore:

Also pictured above: more large bypass caps and a 5V transient voltage suppressing Zener diode. This is designed to absorb voltage spikes by breaking down at a known voltage, protecting other components on the 3.3V line. I neglected to put one on the 5V line in the board design, so I made a flying Zener:

To make all this room on the board, I had to move the switching 15V power supply (now 13.5V to accommodate the 12V input of the DCR021205) down to the bottom side, which creates a bit of a problem because the electrolytic capacitors are taller than the IXYS MOSFET module by about 1mm. I'll have to fill this additional gap with a thermal transfer pad on the bottom of the FET (which is probably a good idea anyway). But now, the top side is all logic, and the bottom side is all serious business:

Pictured: All that parts that violate FCC standards.

I used to worry about finding more IXYS three-phase modules, because they have a very unique footprint and so my design is married to them. However, Mouser seems to stock them now. I would like to try some of the other flavors (75V/120A) if they ever show up. For now, I have horded enough to last for quite a while:

 This is my favorite box ever.

I made a few other minor changes that may or may not have contributed to the overall noise reduction:
  • Individual local bypass capacitors for the three current sensors. (Previously, all shared a single 5V bypass.)
  • A ferrite chip in series with the 5V trace that feeds the STM32 board (L2 in the schematic). This should help filter any current spikes attempting to go toward the microcontroller. In retrospect, a common-mode choke probably makes more sense.
  • Local low-ESR ceramic bypass for the 5V pin going to the Hall effect sensors. Since the problems seem to only occur when the motor is moving, I thought there was a slim possibility that the sensors might be contributing. Even if not, it's just extra bypass for the 5V line.
  • 1k series resistors (R50-R53) on all the gate drive digital outputs (three PWMs and a shutdown signal). I'm not sure why, but I thought it might help if the noise is coupling in from the gate drivers themselves.
The down side of making so many changes at once is that I have no idea which ones specifically make a difference. The up side is that I give myself the highest probability of solving the problem. And, I'm happy to report, the problem is solved. Here is a clean full-throttle (40A) launch:

Command following is spot-on and he torque output is very smooth. I haven't test-driven it enough to say that the random resets are gone forever, but I have yet to observe one on the new controller.

Next step: Combining this with the MIDI engine to make the worlds first? vehicular MIDI instrument.


  1. Add functional brake lights!! Not for the sake of safety of course....but that would be really cool.

  2. The brakes do have a switch built into them that I could tap into... But where would I put the lights? At deck level? They'd be too low for anyone to see.

  3. Make a shirt LEDs built in that signal braking and turning. Like this: