Singapore Wrap-Up, Pneu Scooter v1.-1 Test Drive

Wow, somehow an entire month has passed since I started my SUTD visit. Singapore, while incredibly hot and humid every day, is actually a very nice country to stay in for an extended period of time. The food is inexpensive and good, the traffic is light, public transportation is clean and effective, and there are plenty of places to find stuff.

...stuff which inevitably winds up at Gecko Works.

If I am allowed one complaint (besides the one that everyone will have, which is the incessant humidity), I would say I strongly dislike the nature of retail. Namely, shuffling sideways through crowds in the impossibly narrow aisles of a tiny shop trying to find something, and then having to ask how much everything costs (pretty much giving away that I am a foreigner with no likely sense of a fair price). The concept that you can tell me whatever price you want to tell me, and then tell the next person that comes in something completely different, is not appealing at all.

Anyway, my flight out is in eight hours and I'll be returning to Cambridge, MA, where it is the same temperature in F as it is here in C. That means very little in the way of outdoor scooter testing is going to occur for the next few months, so I had to get at least one test ride in while I'm here! There's just one tiny problem - you know, the one that is basically the feeder for 90% of my blog posts - the one that is never really solved: Motor Controller Issues.

I'll get back to those, but as I remind myself that Pneu Scooter is more than just a vehicle for testing one particular controller, I feel obligated to put more emphasis on its completion, minus one custom part. So I will designate this the build summary and maiden voyage of Pneu Scooter Version 1.-1:

The principle new technology for me in this project was a new flavor of custom-made miniature hub motor built into the side of a pneumatic wheel, which will provide a much more cushy ride than the 80A urethane bricks on BWD or even a normal Razor scooter wheel. The trick is avoiding the valve stem, since miniature hub motors need every millimeter of radius they can get to produce sufficient torque. The solution here, which comes with the added benefit of minimal wheel modification, is to simply offset the hub motor onto the side opposite the valve stem.

Like so.

Ok, so it's not as elegant and compact as the ultra-miniature hub motor from RazEr, but it's easy to make and the ride is wonderful. And it uses up the leftover custom stator laminations laser-cut by Proto Laminations for BWD. And, I got to try out a new technique that I've been ranting about for a while: making the can out of stacked waterjet-cut plates with magnet-aligning grooves. I classify that as a total win, especially for thin-profile motors where only a few plates are necessary.

I also got a chance to cancel some of the bad juju of BWD's handlebar mount with a much beefier front-end solution:

In total I used about 6" of my 20' of aluminum.

Here's the fully-assembled vehicle right out front of Gecko Works:

I like the simple, square look and the fact that it is stealthy enough to pass for a regular Razor scoo-wait what the fuck is that lump on the back of the deck?

Laaaaaaaaaaame.

Yes, it's one of those cheesy electric bike controllers that I found in plastic bags at the e-bike store. Yes, it's lame and noisy. (You can hear it buzzing away in the video, occasionally drowned out by the crane-mounted jackhammer that's been demolishing half of Singapore for the last week or so.) Yes, it totally ruins the stealthy look of the scooter. Yes, I should be capable of producing a working brushless motor controller by now. Yes, I am a failure.

Actually, I did manage to do a lot of independent troubleshooting by moving the 3ph HD controller over to an electric bike. Decoupling the electrical and mechanical tasks was a good idea, since it allowed me to finish the scooter mechanicals while simultaneously testing the controller on a known-to-be-functional vehicle. What I discovered were two (possibly related) problems that I need to solve:

1. The current sensors readings are garbage. The DC sensor reading is clean, but totally incorrect. The two phase current sensors are just noise. Well, not just noise, but I'll get to that. Since I rely on the current sensors for field-oriented control, this is generally bad.
2. The microcontroller will occasionally jump out of valid code and/or lock up, forcing a watchdog timer reset. This results in a momentary loss of torque. It's definitely load-dependent, meaning it could very well be caused by some kind of induced noise from the power side. (As a side note, I found a great reference in ST Application Note AN1015 on how to make EMC-robust software.)

One thing we don't have at Gecko Works is an oscilloscope. So, getting a clean picture of the current sensor signals noise was not an option. But, I generally suspected PWM-induced noise, and after taking a look at the sensor data, I remembered a trick I learned from this Prof in 2.671, the only undergraduate class with notes that, time and time again, I actually find myself going back to use. The clue was that the sensor data, with the wheel locked so that all current should be DC, still appeared to be periodic:

It looks as though the current is oscillating at exactly 5Hz. However, nothing at all in the system is happening at 5Hz, so this doesn't make sense. And random white noise would not show up as neatly periodic. The trick is that it's actually aliasing of a higher frequency noise source, namely the PWM. I was 99% sure of this because of the details: The data is transmitted at a frequency of 20Hz. Nyquist says that the highest frequency you can record at 20Hz is 10Hz. 20Hz will look like 0Hz (this make sense). 11Hz will look like 9Hz (this requires a bit more thought). 15Hz will look like 5Hz. In fact, (10n+5)Hz for any integer n will look like 5Hz. The PWM frequency is 15,625Hz. Since the PWM and the data transmission are created from the same clock source, it makes total sense that the PWM noise appears as an aliased signal in the current sensors.

The extra 1% of certainty: By changing the PWM frequency to 15,564Hz I can test this theory. Sure enough:

It's a little harder to see, since 4 doesn't go evenly into 10, but the period is now 4Hz, which is what 15,564Hz should fold down to, given a 20Hz sample rate. Case closed, it's PWM noise. Who needs an oscilloscope?!

After spending about 10 seconds looking at the board schematic and layout, I realized why my current sensor signals are mostly noise. I included an RC filter at the output of each sensor, but with R=10kΩ and C=1.5nF, it ain't filtering 16kHz. I honestly have no idea why I chose 1.5nF...it very well could have been a typo. The other, possibly larger problem (since the motor's own inductance should filter the current a great deal more than is reflected in the data) is where I put the capacitors. In power circuits, where you put things is probably even more important than what you put. In this case, I put the capacitors near to the current sensors, leaving a long stretch of high-impedance trace antenna going right under the MOSFETs:

I'll have to fix this in a later board revision. For now, adding (properly sized) capacitors right at the STM32 breakout pins seems to do the trick. A 10nF at the pin reading the Phase C current sensor revealed a beautiful and accurate current signal behind all that noise:

So for now, I should be able to solder some capacitor sculptures onto this board to make it work. That may not be the end of the troubleshooting, but at least it will be one large part taken care of. It'll be much easier to proceed when I can trust the sensor data. 

Ah, more electrical troubleshooting. Something to look forward to when I get back... :-/