EVER '11

I'm back!

EVER (the international conference on Ecological Vehicles and Renewable Energies, except with the R and E reversed because it is French) is my favorite conference EVER. Last time, the Cap Kart crew and I went in 2009, confused a lot of professors, and ate crepes. This time, Charles and I went in 2011, confused a lot of professors, and ate crepes. Oh, and test-drove an electric box thing that (probably) ran on an Arduino:

...all the Nissan Leaves were spoken for, okay?

Actually, I kinda liked it because you could clearly feel all the inner workings of the electric drive. It reminded me of the Cap Kart...you had to press an LED-lit button with an arrow on it to choose forward or reverse, and it had the turning radius of a small truck. Not sure how well that bodes for commercialization, but it was fun in sport mode, anyway.

Actually, we were there to present a paper on Miniature Electric Hub Motors, which if you're new to this game, is the key technology in Pneu Scooter, BWD, and about one third of the crazy things Charles builds. Generally speaking, the miniature hub motors are more of a fun hobby for us, but we really couldn't pass up this opportunity to disrupt the atmosphere of an academic conference with them.

Yo, where can we park these?

Oh right, I forgot to mention that we brought hardware. As it turns out, both Pneu Scooter and RazEr rEVolution fit well into checked air baggage. (I took Pneu Scooter to and from Singapore as I was completing it.) The only tricky part is the lithium batteries, but according to the TSA, one large (up to 300Wh) battery installed in a device is allowed in checked baggage. Pneu Scooter's battery clocks in at 145Wh, so I should be fine, right? ... Right?

Overall, the presentation was well-received. The chair for our session was Professor Zhu, who is sort-of like a permanent magnet motor deity. In fact, at EVER '09, he delivered the keynote presentation on fractional-slot PM motors, which is exactly the type that we tend to use for the mini hub motors. Of course, then, one of our main goals was to get Prof. Zhu to test drive the scooters.

Mission accomplished.

The academic conference was fairly standard - a lot of math. The highlight, for me, was a dirt-simple explanation of sensorless control using a flux observer that is exactly what I've been looking for. Sensorless control may be silly for EVs, but I'm still willing to give it a try just to see if I can implement it on my hardware. My hunch is that I will have to improve my current sensors a bit. (3ph 4.0?)

The best thing about bringing vehicles, though, is that we got to crash some of the concurrent events, such as the two-wheel vehicle Ride and Drive...

...and the two-wheel vehicle Acceleration Test...

...which I'm not sure we were supposed to be allowed to do. Considering that the other entries all used pedal assist (and one had more than the nominal two wheels), and absolutely none of them fit in a suitcase, the mini hub motor scooters put up a good fight. I think most people were surprised; I don't know if that's because the scooters actually kept up with the e-bikes, or if it was because they had no idea where we came from or if we were even entered in the race.

Overall, another fun trip to the weird bubblestate of Monaco. I leave you with my proposal for how all suitcases should be constructed:

Fuck little plastic wheels.

Pneu Scooter: Sensorboard v2

Hrm, all this excitement about snow scooters that don't really work when it turns out that my other electric kick scooter has done a pretty good job this winter. Except it gets really, really dirty:

Ugh.

Especially now that the two-to-three-foot mountains of snow on the side of the road have started to melt, the combination of dirty snow, road salt, and sand has become a bit of a problem. You'd think corrosion or electrical failure would have taken out Pneu Scooter by now. But in fact the only issue I've had is somebody beasting it up and down the hallway so hard that the fuse blew, taking out some critical controller hardware with it. Or some critical controller hardware blew, taking out the fuse with it.

In either case, I essentially had to replace half the active components on the controller, and the IXYS MOSFET brick. One current sensor and all? the gate drivers also ate it. After I rebuilt the controller, things seemed to be working except for one very odd new symptom: For the first 30 seconds or so of riding, one or more of the Hall effect sensors would produce sporadic faults that caused the rotor position estimator to fail and the controller to "click". 

This didn't seem like the microcontroller reset problem that I solved a while back, more like simple sensor faults. My hunch is that the same transient that killed everything else also messed with one or more sensors. And the fact that the problem consistently fixed itself after about 30 seconds of riding a) made me fairly sure it was the type of problem that I couldn't fix using deterministic troubleshooting procedures b) made me not really care. But, in preparation for the Friday Energy Showcase of the MIT Energy Conference, I decided to finally replace the sensors.

Step one was to laser cut a new sensor mount: 

The original sensor mount was made from polycarbonate and I cut the 2.5"-radius inner surface with a giant boring head in the mill. Lacking the courage and time to attempt this again, I opted for the wimpy solution of just throwing files at the laser cutter. The downside is that the first metallic object large enough to get jammed between the sensors and the wheel may just crack the acrylic right off. But the upside is that I can now put little sensor alignment features right on the part, saving me some careful measuring and gluing.

Also, t-nuts.

+ sensors + wiring + Amazing Goop =

Maybe the sensors will also be more protected from dirt and debris now that they are recessed into the plastic and potted with goop. If not, I can just hit print a few more times on the laser cutter and make a bunch of spares. Replacing individual sensors is virtually impossible, but having entire spare boards seems like a good idea given how fragile the sensors seem to be. I've also switched to the simpler, cheaper, and hopefully more reliable ATS177 Hall effect sensor.

Here's how it fits in with the wheel:

The sense magnet strip has held up pretty well. It definitely needs to be cleaned frequently, because it picks up magnetic dirt and debris off the ground, but overall it's not a bad solution for making a sensored motor without the commitment of internal sensors. As a reminder, the rubber strip magnet I used is McMaster P/N 3651K4. Some day soon I will revisit sensorless control, or hybrid control that only uses sensors at low speed. (3ph v4.0???). But for now, things are at least back to a working state.

Here's Pneu Scooter and RazEr rEVolution at the Energy Showcase:

"Does it generate electricity?"

- No, it consumes it.

"Are you selling them?"

- No.

"Do you have a business strategy?"

- No.

"Is it really saving energy if it replaces walking?"

- No.

"Do you have a card?"

- No.

Snow Scooter: 40 hours of work, 15 seconds of fame.

There's the 15 seconds of fame out of the way, now the 40 hours of work:

Last week, it was nearly 60ºF and the Cambridge permafrost and giant piles of snow all melted away. But they were pretty disgusting anyway, by this point. On Friday, I saw that there was a chance of a fresh coating of snow for Monday. And since I don't know what the rest of the spring will bring, I decided I might only have one chance to produce some marginally functional snow scooter. And as you can see from the video, it is exactly that: marginally functional. Or it was, for 15 seconds, until it sucked up a pebble and destroyed the left side motor. Here's how it all went down:

I finished the rear drive module a couple weeks ago, but because of me being an idiot issues with the front meta-bearing, the front drive module was left hanging. Also, the front drive module contains the Victor 883107-7 controller boxes, which needed to be water-resistant. I couldn't use t-nuts, so I had to drill and tap everything. To speed up this process, I marked all the holes in place through their matching clearance holes on other parts. Then, this:

It's actually not too bad when you have a depth setting and can just drill to a mark every time. Blind tapping sucks, but I recently invested in some nice new 4-40 plug and bottoming taps so I felt like I was putting them to good use. One problem is that, even without t-nuts, the tabs and slots still leave gaps, which are exaggerated by the taper of the waterjet. So despite everything, I still needed to seal the inside of the controller boxes with Goop to the best of my abilities:

To the controllers themselves, I added a 1/4" aluminum heat transfer plate to get heat off the bottom copper plane and into the scooter chassis, which is itself cooled by snow. In between the plate and the copper, a thin sheet of silicone thermal transfer pad provides electrical insulation while still conducting heat off the board. The board sits on 1/4" nylon standoffs (also for isolation). Here's the board in place:

I used 14AWG overcooked pasta wire from Hobby King, which turned out to be very necessary since I didn't leave much room at all for the power wiring to squeeze past the edge of the controller board. Only the absurd flexibility of this high-strand-count wire made it possible to get power to the bottom of the board. You can also see the motor wire exit strategy in that picture. Here's a closer look:

The wire runs down the body of the motor, between two of the metabearing bearings, and out of the pulley assembly through a pair of slots in the center rail. Again, only possible thanks to the magic of high-stand-count wire. Wiring the controllers was relatively easy. The controller boxes have Deans connector ports for interfacing to the outside world (battery, motors). Here's the overall layout:

A quick bench test at this point confirmed that both controllers were indeed still operational and that the front metabearing, which I violently bent back into something resembling a circle, was not totally destroyed. That's all the proof I needed to move on to the fun part, which was cutting and splicing the timing belt tank tracks. After calculating the desired track length, I cut the 2" wide timing belt (McMaster 7959K32) into two such lengths and prepared to join them into continuous belts.

One thing I learned accidentally when building my 2.007 robot way back when is that regular old cyanoacrylate (Super Glue) works disturbingly well for bonding rubber belts. I even tried commercial products advertised as rubber adhesives, but CA worked better than those, too. So I didn't bother with other adhesives this time. But in order to make a very strong bond, the CA joint needs to act in shear. This means a lap joint, and the best way I could think of to do this without increasing the maximum belt thickness was as such:

Speaking of my 2.007 robot, I found the missing tank tread and cut it up to make the rubber strips needed for the lap joint:

Poor robot.

One tread dies so that another may live:

These are both about 29.75" in unstretched length. Thanks to the giant compression springs, the pulleys should keep the belts in tension at around 25-50lbf each. I have enough room to remove one more tooth from each belt if necessary, and the tension in that case would be over 50lbf each.

Before final assembly, I made a Y-splitter for both the battery power and the throttle signal, so that one signal controls both motors. One of the goals that had to be dropped in order to meet the snow deadline was differential steering, where each controller gets a separate throttle signal and can drive the motors with different torques. The belts are so close together that I don't know how much net steering torque this would actually contribute, but it's an interesting idea that I want to try at some point. Here are the Y-cables passing through the open space between the two drive modules:

At this point, I was ready to put the belt on. Since the springs together push with upwards of 100lbf, I needed a way to hold them while slipping the belts on from the side:

Large clamp to the rescue.

The belt goes on first, then the front and rear side panels. I also made some quick bogie wheels out of 1" LDPE stock:

These take up much of the normal force on the treads, keeping them from rubbing on the bottom covers of the controller boxes. However, in the video you can see that the pulleys tend to slip a lot. Without the normal force of the tread against the drive pulley, it was hard to get enough torque transmitted. Possible solutions include more tension and sandpaper or other friction coating on the drive pulleys.

And here it is all together:

"Wait a minute. Did you just steal Pneu Scooter's front fork and attach it to snow scooter?!"

Yes. I'll give it back. But it was already snowing at this point so I had to get something on there. It's supposed to be a ski or a ski/wheel combo but for now I thought just a wheel would be fine.

I had some trouble with the belt getting sucked into one side's drive pulley. The problem seemed to be a small offset at the glue joint that was riding up on the rim of the pulley every so often and getting jammed between the pulley and the deck. The solution was to just turn the belt around, so that the small offset would move try to climb the more forgiving inboard pulley rim rather than the sharp outboard rim. If that made no sense...well just trust me.

After that, I borrowed a 19.8V FusionPack from Matthew and went outside...

And, well, you already saw what happened there. I guess the immediate cause of failure was a pebble...

...which got sucked into the thin gap between the tread and the deck, jamming the left side and burning out the (already heavily stressed) motor. The other obvious flaw was the lack of adequate friction between the pulley and the belt, which was not unforeseen and will need to be addressed. With all the weight on the bogie wheels, the pulleys prefer to just slip instead of driving the track. I think this can be easily solved. 

The more fundamental flaw is the debris protection and the fact that the motors are being run with no concern at all for overload conditions. I was sort-of imagining that the snow would cool them off, but the pulleys actually keep snow and water out decently enough that motor heating is now a problem. As for the debris, I just need some kind of brush to keep rocks and stuff out of that gap, I think.

Some parts of the design worked well, though. The metabearings did fine, even the one I mashed on the 20-ton press by accident. Overall, the 540-motor into Banebots gearbox seems to be a good solution, I just need to find the right 540 motor. Perhaps it's time to seriously consider going brushless...

MEMS / Snow Scooter / Panzerkitten / Thing

Cambridge got its first dumping of snow, about two feet of it. And even though it's already mostly melted or trucked away, the pressure's on to create what I call the Micro Electrical-Maniacal Snowmachine, or MEMS for short. (Just so I bait and switch more common search hits like "MIT MEMS"?) Or maybe, as I was thinking yesterday, I should call it Panzerkitten. After all, it is a small, cute, harmless tank tread vehicle.

Thank you, Charles, for the illustration... You can go back to building unnecessarily dangerous and impractical competing vehicles now.

But then again, the seed for this name, "Panzerketten," seems to refer to jewelery that resembles tank tracks, not tank tracks themselves as the literal translation offered by Google would suggest? So it might not actually make any sense. I'll probably just keep calling it "snow scooter" or "the thing" anyway, so it doesn't really matter. If you have a strong opinion, let me know...

Anyway, I got the first batch of waterjet-cut parts for the thing from Big Blue Saw. (I've grown out of the phase where I try to negotiate with the on-campus shop staff about waterjet fees. Plus this way, anyone can make a snow scooter!) For budgetary reasons, I started with just the center plates, which are where all the action happens:

The front (swordfish) plate is like the spine of the scooter, giving the deck some rigidity as well as supporting the front drive module. The drive modules are probably the most interesting part of this build, and I'm trying some new tricks with them to mount the gearmotors inside the track pulleys. To facilitate this, I start with four stainless steel bearings on each side of the center plate:

Pictured: about $40 of stainless hardware. :(

These four bearings form a metabearing on which the pulley itself rides. The pulley is just an aluminum tube with a lip and a metabearing race machined in it on one side. The pulleys are hollow so that the motor and gearbox fit inside them.

Metabearing race.

Copy-paste three more times.

You can really see how the metabearing works in this last picture. The four small bearings ride around in the race cut out on the inside of the pulley, and the result is a lot more space efficient than one giant ring bearing. It only works because the loads are low: the treads get maybe 2/3 of the gross vehicle weight, so maybe 100lbs, and that's spread out across four metabearings on the center plate, four regular bearings on the side plates, and the bogie wheels. The last picture also shows the exit strategy for the two motor leads. The only way to get them out is through slots in the center plate, since there will be spinning pulley and tank tread everywhere else.

The pulleys also get end caps. So far, I've only managed to work out the details of the drive end caps, the ones on the gearbox side. The idler end caps will need to be redesigned to accommodate the longer 550 motors I have planned. As it is, there is virtually no room for wiring. In the mean time, I made two drive caps, complete with 1/2" keyed bore:

They're pressed into the pulleys with Loctite 609, since they transmit torque to the tracks. The small raised edge around the bore is for spacing the pulley out a bit from the side plate's bearing. Both the pulley and the end cap are tapered a little to help keep the track from snagging or trying to jump off. Speaking of tracks, here's where it starts to look real:

What do you normally use 2" wide timing belt for?

I made all these parts while waiting for my Beanbots gearmotors. Beanbots gearboxes occupy a very special place in my mind. On the one hand, they used to make some pretty crappy gearboxes. They lacked proper alignment features, had miserable axial tolerances, tore the shit out of their brass gearteeth, and stripped out the low-carbon output carriers. But this was like...back in 2007. I spent so much time reverse-engineering these gearboxes that I have a spare carrier plate I made out of tool steel on my key chain.

My bad luck charm.

Now, though, they are very well-made. Steel gears, hardened carrier plates, axial spacers, and alignment features other than through-bolts are all standard. Everything is tight, the backlash is minimal, and they run smooth, all for a fraction of what you'd pay for precision planetary gearboxes. Totally legit. It's almost like a totally different company...

...almost.

After I geased my grearboxes, I popped one into the rear center plate to check the fit:

I spec'ed 8-32 bolts to attach the gearbox to the center plate, when in fact the regular gearbox screws are 6-32. But since I had to drill out the tapped holes in the gearbox anyway, that was no big deal. The 8-32s clear everything just fine. With the two pulleys in place, it disappears:

Except for the motor length, there were no clearance issues and it runs smoothly. With the stock RS550 motor, 12V gives 1,000rpm no load at the pulley. That's 9mph at the ground. At 18V, 13mph. The next test will probably be to see how much torque this drive puts out. If it's more than adequate, I can trade back for a little more speed by going to 16:1 gearboxes, changing to a faster 550 motor, or both. If the torque is merely adequate, I'll probably have to live with the 10mph top speed. If the torque is inadequate, well then I'm screwed.

Before I make that call, though, there are more non-trivial tasks to accomplish. The idler pulley end caps need to be redesigned to handle the longer motor. I need a way to join the belt and to make sure I can get it on and off easily. I need the side plates, the ski, and another Razor A3 to sacrifice. And I need controllers. Speaking of which......well this post is too long already so I'll hold off on that.

Pneu Scooter Test Drive Data / 3ph v3.1 / New Project Teaser...

Building your own custom motor controller suuuuuuuuuuuuuucks, but it means I get free wireless data acquisition on my vehicles. I use XBee 2.4GHz transceivers to stream out things like battery voltage, motor current, speed, etc. to a waiting laptop which displays it in real time and/or records it.

An XBee radio on the 3ph HD.

Even though I made an utter mess of the HD in the last post, the data acquisition works fine. And it's not unbearably cold outside yet, so I wanted to do a short test-drive with the patched-up controller before it's too late. Minor problem: The controller sits inside the aluminum deck Faraday cage and the transmitter range with the on-chip antenna was terrible. This is easily solved by using a little external antenna flap thing that I got from Digi-Key, which attaches to the version of the XBee with U.FL connector and comes up through the back of the deck:

Other minor problem: the receiving program needs to be running on a laptop. This is why I need a fanless netbook, but for now I figured it's cold enough that I can run my laptop, closed, in my backpack, fans pointed upward. (I have an abusive relationship with my laptops...) 

Mobile wireless link established, and awake during daylight hours for pretty much the first time since returning from Singapore, I went for my first on-campus test-drive:

The Nordschleife, not to be confused with the Ostschleife.

Here's some raw current and speed data from the first 1/3 of this run:

What does it mean?

Raw data is raw, but here are some whole-trip statistics:

• Trip Distance (measured): 2.1 mi
• Capacity Used: 1.17 - 1.39 Ah
• Energy Used: 38.6 - 45.9 Wh
• Efficiency: 18.6-22.0 Wh/mi
• Peak Power In: 543 W
• Peak Power Out: 375 W (est.)
• Top Speed: 14 mph

These are very nice numbers. The variance in energy use estimate is due to slightly different integrals from the DC current sensors and the AC current sensors. I tend to trust the AC current sensors a bit more, and they're giving a worst-case estimate on par with RazEr's 25Wh/mi, so let's go with that. I won't even bother converting that to mpge because the value is absurd. 

These efficiency numbers give the scooter a best-case range of about 6 miles, though I would expect something more like 4-5 miles for a reasonable SOC range. Not bad for two DeWalt drill batteries. The lithium-polymer pack I had in Singapore (two of these) would have extended the range to about 7-8 miles without adding any weight.

I also did a few more controlled tests. First, a no-load test confirms 1,520rpm at 33V. That's a Kv of 46rpm/V, or a Kt of 0.21Nm/A, right on target. This corresponds to a ground speed of 27mph, but friction and drag will always load down the top speed. I would estimate that the loaded top-speed of this scooter is about 20mph, and I will confirm this when I have mechanical brakes. ;)

I also repeated a test from the early days of my field-oriented control adventures: a launch with and without d-axis/phase control. Here's the original explanation: Part 1 and Part 2. Here's Pneu Scooter without d-axis control:

The controller here can't adjust the phase of the sine waves driving the coils, only their amplitude. As speed increases, the motor's inductance causes current to lag onto the d-axis. To keep a steady q-axis current (torque-producing current at right angles to the rotor flux), it must increase the overall magnitude of the current to accommodate for the lag.

Here's the launch again, with d-axis control on:

Now the phase of the driving sine waves is unlocked, and as the speed increases it is feedback-controlled to keep the d-axis current at zero. In this case, about 17º of phase advance is required at 12mph. The total current magnitude stays steady and equal to the q-axis current. Nothing new here, just more demonstration of the modified synchronous current regulator at work.

Next order of business: Go back and make some of the 3ph HD hacks permanent in a new minor version of the controller, the 3ph 3.1. Here's the board:

It looks...pretty much identical to the last one. I moved the DC/DC converter to the bottom of the board, even though the capacitors technically don't clear vertically. They're only off by about 0.4mm, and I can use some gap-filling silicone padding to space out the MOSFET brick a bit more if necessary. That frees up tons of space for moving the analog RC filters right next to the microcontroller pins and adding a crapload of capacitance everywhere, two things that helped get the HD in working order.

The biggest change is the addition of an isolated 5V logic supply, in the form of a DCR021205. These are similar to the isolated supplies I use on the higher-current controllers to feed the gate drivers, but these convert from 12V to a regulated and isolated 5V. The interesting thing is that the logic can't float arbitrarily: the IRS21844 gate drivers allow only a +/-5V level shift between logic and power ground. And the battery voltage measurement needs some kind of reference, since I'm not using analog isolators. But in theory, no current should flow from power ground to logic ground without going through the DCR02. You can see how I dealt with this problem here:

If you see what I did, shut up.

If this quasi-isolated logic supply doesn't fix the problem, then I would be forced to go back to something more drastic like optically-isolated gate drive. But since the HD is working pretty decently now with just the addition of a 10Ω resistor between logic and power ground, I think this will do the trick. Though I would like to be able to turn the peak current up to about 60A if this cleans up the noise significantly. Look for an update in a few weeks when I get the new boards.

And before I forget, a New Project Teaser for you to guess on:

+7959K32

Pneu Scooter v1.0: Stealth Mode

I'm back from Singapore and jet-lagged as hell, which means plenty of off-hours work and blog-post-writing.

After three days (nights, whatever) of troubleshooting, Pneu Scooter and the 3ph HD controller have been reunited:

This is the controller configuration for which the scooter was designed, so it fits perfectly under the deck, behind the LiFePO4 battery pack and fuse. In Singapore, I ran into two flavors of trouble with the controller: the current sensor signals were mostly noise and the microcontroller would spontaneously jump out of valid code execution, resulting in a hiccup when the watchdog timer forced a reset. Both were load-dependent phenomena, likely caused by power/signal interference. 

This board isn't as nicely isolated as the higher-power controllers I've built; there are no optocouplers or isolated DC/DC supplies. Everything runs on a common ground, though I did my best to avoid ground loops and keep the power and signal sections as separate as possible. In a later board revision, I will explore some options of explicitly isolating the logic power. For now, though, I broke out the box of capacitors and started adding them wherever I thought some extra filtering might help:

The interesting structure on the left is a row of 10nF ceramic capacitors acting as local filters for the current sensor analog signals. This was the solution I explored in the last post for cleaning up the current signals. It did the trick nicely, and so I'll integrate them onto the next revision of this board. With the current sensors back to a reliable state, I had no trouble implementing the field-oriented current control algorithm that I've come to love. If you missed that part of my life, here's a summary.

Unfortunately, the current sensor fix didn't eliminate the spontaneous resets. These seem to be caused by the processor losing its place in the code. It's not completely shutting down; sometimes the PWM peripheral keeps running in the background. The STM32F103 has a wonderful trick whereby it can tell you what the cause of the most recent reset was (page 109 of 1072 in the FM). Using this, I confirmed that the hiccups are watchdog timer resets, and if it comes down to it, I can actually handle the problem with a clever software fix, as outlined in AN1015.

Fixing a hardware problem in software isn't beneath me, but I first wanted to exhaust all other options. I tried increasing the size and quantity of local bypass capacitors on the signal board. Adding a bunch of 4.7uF ceramic caps to power pins seemed to help, but didn't completely eliminate the problem. I was also only running 20A at the time, and the end goal for this controller and motor is 40A or more peak for hill climbing. To test at higher loads, I added 1mΩ resistors in parallel with the ACS714 current sensors.

These resistors effectively increase the range of the sensor (normally +/-30A) by halving the amount of current that actually flows through it. This is a more compact solution, I find, than using larger current sensors. At 40A drive current, the hiccups came back in full force. I tried other small tricks like setting all unused pins to ground and selectively disabling non-critical features. But nothing seemed to make a significant difference.

The breakthrough was a trick that I learned from...actually I have no idea when or where I learned it. Some time ago, I started naming my ground nets differently to keep them separate in my head and in the schematic. There's the physical connection to the negative battery terminal, which is power ground. Ideally, all of the motor's return current goes this way. There's a gate drive ground, which in many cases is the same as power ground. And there's the logic ground, which should be kept as clean as possible. I connect them all with zero-ohm resistors so that I know they are tied together at one and only one place.

That is...unless there are unintended couplings in ICs or on the board or in free space or whatever. The trick is to quasi-isolate the three grounds by changing the zero-ohm resistors to 10Ω. There's nothing special about this value; it's just the largest resistance that results in less than 1/10W dissipation with 100mA flowing through it. (That's about how much the gate drive and logic draw, most of which goes straight into the XBee transmitter.) The extra bit of resistance, combined with the bypass capacitors on each power supply, creates an RC filter that suppresses high-frequency power transients.

This relatively minor change brought the hiccup frequency down from "every time you throttle past 50%" to "every once in a while at full throttle" at 40A. So, it didn't completely solve the problem but it definitely hints at a path to a complete solution: total isolation of the logic supply. While I explore this option for a board revision, though, the current solution is very ridable. With the sine-wave drive engaged, the scooter is virtually silent. It's actually not unbearably cold yet in Cambridge, so I'll be able to test drive it outside this week and take some performance data. For now, though, here's some video at our favorite indoor vehicle test facility: