Seg...stick.

I'm testing my theory that the internet is an infinite Segway sink.

Segstick is like a....Segway...but built from DeWalt drills and an Arduino...in two days. Obviously it's not very good, but it unquestionably balances. For once I've offloaded my build onto Instructables for the world to see:

http://www.instructables.com/id/Segstick/

You should build something in the next two days, too, and enter to win a laser cutter. Or enter something you've already built. Or build a fusion reactor. Free laser cutter!

If you want to see some better self-balancing vehicles, check out:
The DIY Segway - Vintage 2007, yet we still can't live it down.
Segfault - Charles' totally analog Segway. Yes, op-amps.

MIDI Scooter...

It was only a matter of time...

I merged my MIDI-playing code with my scooter-driving code and put them both on the new, rad-hardened 3ph v3.1 controller. A brief summary of what exactly is going on here:

1. Laptop program parses a MIDI file and I choose three tracks that look interesting.
2. XBee radio streams MIDI data wirelessly to the motor controller.
3. Motor controller uses the frequency of the MIDI note as the PWM frequency.
4. Each phase corresponds to one MIDI track. Three phases can play three tracks simultaneously.

For kicks, here's the code for both ends of the system.

Because the PWM frequency is independent of the motor speed, this all happens more-or-less in the background while the regular motor control algorithm runs in the foreground. Meaning, I can ride the scooter around at low speeds without noticing any difference in performance. At high speeds, when the note frequencies get close to the commutation frequencies, bad things would happen.

The real motivation for this was to demonstrate just how much extra processing power there is to be squandered in this motor control setup. The MIDI routine now dominates both the processor usage and the data bandwidth. The motor controller itself, which is full field-oriented sinusoidal control, runs in the leftover gaps, and is still fast enough to execute a 1kHz current/torque controller. Yay 32-bit processors.

Micro Electro-Maniacal Snowmachine: Intro

It's time that I explain this. As I've been complaining about ever since I got back from 90ºF and humid Singapore, Cambridge is descending into the darkness of another cold, dry winter. This does not bode well for my small vehicles.

For one, it's too cold to really ride around with anything other than a ski mask and gloves. But apparently people on bikes managed to do it, so maybe I just need to not be a wimp. The bigger problem, which hasn't appeared yet but will in the near future, is the snow/slush/permafrost that covers the streets and sidewalks. Pneumatic tires or not, this is not kick scooter weather.

So is it time to pack up for the winter? Or, is it time for a kick-ass fleet of snowbound vehicles? I think that latter. I won't ruin the other surprises, but I'm ready to introduce my contribution, the smallest and lightest conveyance of the fleet:

The Micro Electro-Maniacal Snowmachine

MEMS

It is an electric...snow scooter. So far as I can tell, there is nothing else that you can possibly put in that category. I goggled on internet for "snow scooter" and found only manual snow scooters like this and gas-powered snow scooters like this. Meet the intersection, a portable electric snowmobile that you stand on. Now, the details:

The dual treads are actually nothing but inverted 2" timing belt (McMaster PN 7959K32). It's sold in open lengths, which means I'll have to join it. But since I'm not using the "timing" part of the timing belt, I can probably get away with some ugliness here. The total length of belt used is about five feet.

There are two drive modules: one fixed at the front and one floating at the rear. The rear drive module slides back and forth for belt tensioning. The two modules are pushed apart by the two massive springs in the gap between them. Together, the springs generate about 100lbf for tensioning. I considered other tensioning methods, but this seemed to be the most direct way to exert force along the pulley centers.

Now the fun part, the drive modules. Starting with the floating rear drive:

Each drive module has a Banebots P60 gearbox and 540-sized motor contained within the pulley/roller. The bearing arrangement gets interesting. Blowing it up for a better look:

The drive pulley end cap is keyed for the P60 output shaft, and it will be pressed and bonded to the drive pulley itself. That's torque transmission, but what about radial loading? Half the load of each roller goes into the bearing in the side plate. (On the idle pulley, there is a dummy shaft pressed into the end cap.) The other half is taken up by a ring of baby bearings sticking out of the mid plate. Thus each roller is doubly supported without the need for a giant ring bearing. I've never tried this before, but it looks simple enough.

Moving to the front drive module, which totally looks like a swordfish:

The front pulleys contain an identical Banebots P60 gearmotor, but flipped so that it drives the other belt. This was one of the motivating factors for pursuing the two track setup. Lack of timing belts wider than 2" was another. With two tracks, it's possible to exert a bit of differential torque as well, which should help with maneuvering on snow and ice. 

The front drive module has another hidden secret:

Yes, for once I am not designing a speed controller for this project. The Victor 883/884 fits the bill just fine and I can cram it into a bulletproof enclosure, not exposed to the outside environment, within the tread volume. The fans are useless in this case, so I'll probably remove them.Two Deans ports and a three-position header port provide access for battery, motor, and signal connections. Motor wires pass through channels in the mid plates to get into the pulleys.

Deans ports entering the waterproof Victor box.

Wire entry channels for the embedded gearmotors.

And last, the ski, which steals its Razer A3 interface from Pneu Scooter's front fork:

The Razer A3 handlebar bolts to the deck, and the ski attaches where the fork/suspension pin goes. Speaking of Pneu Scooter, I've got two spare wheels...

Could be useful for on-road testing...

So that's it, a tread drive entirely contained in 3" of height under the deck of a scooter. The batteries will have to be external, but that's okay because there is no shortage of space on the top of the deck this time. It's as long as Pneu Scooter's deck, but because the rear wheel isn't in the way, there's an extra 3" to play with. In total, the weight will be something like 20-25lbs, basically the lightest powered snow vehicle ever?

How about performance? Wellllll that depends a lot on the 540 motors. If I go with the stock BaneBots option, an RS-550, then I'll be targeting a top speed of about 10mph. The good news is that I should be able to get enough torque to pull pretty hard (40-50lbf at the treads). I will be employing direct phase-change cooling on the surface of the motor, so I think I can push the motors pretty much as hard as I want. As always, I have a few back-up plans if I need a bit more power. Let's hope it doesn't come to that...

Let the winter build begin.

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.

Cool Projects [in "HD"]

Showing off a sampling of recent MITERS projects for a Japanese TV shoot:

The projects in this video are:

• Sound-Reactive EL Wire Suits by Luke O. and Adrian G.
• Twtich, Jr.
• Bionic Goggles by Josh G.
• Dendō rōrāsukēto! RazEr Blades by Charles G.
• Pneu Scooter.
• LOLrio Kart by Charles G.

Also present:

• Musical Tesla Coil by Tyler C. and Matthew H.
• Melon Scooter by Charles G.
• LED Fasionwear by Emily K.
• High-Five Machine (which was off because it almost took out the boom mic).

For links to other cool projects, check out miters.mit.edu.

Twitch, Jr. is my twitchy little robot that can't decide which way it wants to go, so it just goes every way. The four-wheel linkage steering is based on a FIRST robot I saw on YouTube some time ago. Pneu Scooter, which wasn't really part of the TV show, is my silent/stealth electric Razor scooter with pneumatic tires, a direct-drive hub motor, and sinusoidal field-oriented control.

I'm also test-driving a new video setup here. I've been doing project video since...forever, but I've finally moved to HD. Well, sort-of. I will now shoot in HD with a new camera I get in a Cyber Middle-of-the-Night-Sunday deal that probably was a pricing mistake. It's a Panasonic HDC-SD60 which shoots 1080i onto an SD card. (We must be in the future...) It's also got a 25x optical zoom and image stabilizer, which is a must-have for me. Since almost all of my videos are destined for the web anyway, the outputs will still be relatively low-res 480p, but now they're widescreen on TechTV!

Since I had absolutely no HD editing capability, I also finally updated to Windows 7 and got Windows Live Movie Maker 2011. I was somehow able to update my operating system in a few hours without even signing off of Gmail... And WLMM11 supports HD formats, so I don't have to make a custom video converter this time around. Is it possible that Microsoft made something that just works? I'm still sort-of in shock.

More projects and more video await!

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:

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... :-/

Gecko Works, Stuff@SG, Pneu Scooter MechE

I'm just about at week 3.14 of my visit to SUTD, where one of my tasks is to help set up an interim interim workshop. The interim campus, with its Pappalardo Lab-sized fabrication facility, won't be open until April. In the mean time, we are in a workshop known as "the shed". No, seriously. Since "the shed" is not a very inspiring workshop name, we've renamed it Gecko Works. (Because the surrounding area has an abundance of geckos. And not the friendly type that try to sell you car insurance. More like the type that jump out of the toilet when you flush it.)

As of last post, Gecko Works was pretty empty. Since then, workbenches and about half of the tools have arrived. A virtual Gecko Tour:

Welcome to the SUTD interim interim shop facility.

 Here is a sample of the workbenches. This one is patiently awaiting welders.

The "What the fuck is all that noise?" table. 

 Cuttin', drillin', tappin'.

Baby arbor press is very cute. Perfect for baby wheels.

At this point, we're just lacking the Heavy Machinery: MIG and TIG welders, benchtop CNC mill and lathe. Odds of it arriving before we leave: slim. Oh well. At least we got the basics laid out. There's also a 3D printer, though it hasn't been moved down from the main SUTD offices yet. Hopefully, this will be more than just a six-month temporary shop. The goal is that it will be a prototype for a "fabrication cell" that can be copy-pasted into the interim and final campus. It's small enough that each team in a project-based class could get their own cell in which to work and store their hardware.

My in-between-other-things task has been to go around the country (it's not that big) looking for good places to buy commonly-needed engineering supplies. For anyone who happens to be in Singapore looking for stuff, here's a running list of places I've found to be convenient and legitimate sources of the types of stuff I typically need: Stuff@SG. My only warning: Do not go to Sim Lim Square.

Don't go here.

Go to Sim Lim Tower:

Go here.

They are not the same thing. Sim Lim Square is like if you took Radio Shack and made it six floors. Six floors of bullshit consumer electronics stores with two electrical supply stores hidden on floors 2 and 6. (If you expand Radio Shack to six floors, these would be analogous to the poorly-stocked bins of resistors.) But if you didn't know that Sim Lim Tower exists right across the street, and is full of real electrical hardware stores, you could easily be fooled into thinking that Sim Lim Square is the right place. Not saying that happened to me......just be warned.

Supply chain in place and tools at the ready, I decided to spend Saturday pretending that I'm a MechE for once instead of working on motor controllers. To make sure I don't revert to EE ways (and to keep the aluminum chips out of it), I moved my controller off of Pneu Scooter and onto the first official SUTD electric vehicle:

Who says electric bikes are dorky?

It's got a 36V, 46-pole (O_o) hub motor that I can use for independently beating the software bugs out of this damn controller, or blowing it up. I'd be happy with either outcome. But more on that in a later post. While I have unFETtered access to Pneu Scooter, it's time to face an old demon: mounting a Razor scooter handlebar rigidly to a custom deck. BWD had serious problems because it had only thin sheet metal flanges for mounting stuff. Even with the equivalent of a two-piece clamp holding the front together, it still makes creaky noises when you step on it and the handlebar never quite returns to the same place when you fold it up. Clearly this experience calls for a degree of overcompensation on Pneu Scooter.

METAL.

From the 20 feet of 5"x1/4" aluminum I bought, this is what I needed. Ten 4-40 screws into the 0.26" side walls of the u-channel should do the trick. A few more in the front may also come later, depending on how thoroughly I feel like erasing the impending failure-feeling associated with BWD's handlebar mount from my subconscious. Mounting provisions taken care of, I couldn't resist taking it for a quick unpowered spin in the parking lot, so I put the Razor handlebar on with the original wheel:

Odd...

It looks silly, but it coasts nicely enough. Only the slightest bit of noticeable drag from the motor at normal kick speeds. This is good, because if the controller fails or the battery runs out, it's nice to be able to unplug it and kick your way back home.

The last piece of the puzzle is the front fork. I thought this would be moderately difficult to modify. Not so. The Razor A3 comes with a shock-absorbing hinged front fork, as opposed to the welded solid Razor Spark front fork we used on BWD. This one comes apart with one screw, leaving two nice mounting surfaces for a custom job:

The normal fork fits flush to the inside surface of those flanges. Turns out if I instead fit a custom fork to the outside surfaces, the width is perfect for clearing the 6"x1.25" pneumatic wheels. I whipped up the necessary plate geometries out of some more of my infinite 1/4" bar stock.

It's still missing the spacer that bumps up against the rubber shock absorber. And yes, it is being held together with drill bits. I don't have the proper screws and will have to make a trip to Homely Hardware on Monday so I can finish this off. But aside from that, there are no obstacles remaining in the mechanical path to completion. Which means I'll be back working on software or something soon...