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!