Monday, December 31, 2012

DRSSTC Δt3: Driver Testing

To start with, the MITERS-originated oneTesla Kickstarter is now up (and already funded!), so you can now buy your very own musical Tesla coil kit. It's pretty amazing: up to 23" sparks from a 10" coil using regular old TO-X IGBTs. And the custom MIDI interrupter can play up to two MIDI notes at the same time.

Anyway, work has been progressing on my Dual-Resonant Solid-State Tesla Coil. I finished most of the mechanical construction in Δt1 and Δt2, so that mostly left soldering and testing of the driving electronics. The power electronics comprise a MOSFET H-bridge, using just one IRFP4668 and one APT100S20B Schottky diode per leg (with the option to add a second FET per leg for higher power). This, combined with 2000uF of electrolytic bus capacitor and the ACNW3190 optically-isolated gate drivers form the power board, which rests on a large heat sink directly below the coil.

I found 10ft of energy chain and bought 10ft of shielding from the last Swapfest for making a a long run of shielded cable to go from the power board to the signal board.

The cable has 15V power, ground, and four differential gate drive signals, each in a cable shielded with signal ground. The gate drive signals are relatively low-impedance, since they drive the opto gate drive LEDs. At least a few mA is required to change their state, so they should be relatively immune to EMI, compared to logic-level signals. However, it's still very, very necessary that the LED drive lines be tightly grouped and shielded. The outer shielding is connected to RF ground at the base of the coil, and is mostly there to protect against arc strikes on the cable assembly.

The whole thing coils up for clean storage.
On the signal end, a wootstick 2.0 running an STM32F103CBT6 at 72MHz provides the brains. I was finally able to get the ARM micro to run at full speed (72MHz in this case). Over a year ago when I was first venturing into sensorless motor control I ran into a mysterious problem that was limiting me to 56MHz. Turns out it was a flash memory access latency setting, explained on page 60 out of 1096 in The F-Ing Manual. In case anyone else is having the same problem (I doubt it, since almost everyone else uses the standard peripheral library), the missing line of code was just:

FLASH->ACR |= 2;

Anyway, having full 72MHz operation is nice because even though there isn't much processor-intensive control code, the frequencies and timing on the Tesla coil are much faster than those of the motor controller.

The switches and lights on the right side control and indicate various levels of arming the coil, including the 15V gate drive power supply, a precharge and a main relay, and the logic power supply. In order to isolate the microcontroller logic supply from the 15V gate drive supply, I use the DCR021205 that worked so well on my 3ph v3.1 motor controllers.

Next up, my favorite part: testing gate drivers! For starters, I set up one of the timers on the STM32 to put out a ~150kHz gate drive waveform. (Two complementary pairs, 180º out of phase with each other.)

Having confirmed, that the timers and outputs were working, I hooked up the 10-foot signal cable and did my best to scope the gate signals themselves. I switched back to the analog scope, because it's just not possible to get as clean a picture of the rise/fall on the crappy digital ones (yes, I am a scope hipster). I also made myself a hack low-inductance differential probe for measuring the high side gate signal:

Since I chose all the gate resistor values with two FETs in parallel, the gate drive on a single FET was a little faster than I would have wanted. (Switching too fast causes major di/dt and dv/dt transients as the frequency content of the switching waveform starts to excite the parasitics of the gate drive and MOSFET.) So, to slow things down just a little bit, I added a bit more external resistance to the output of the gate drivers:

I swear this was the best way to do this...
With a total external gate resistance of about 8Ω, here's the low side turn-off and high side turn-on with no voltage on the bus:

The rise/fall times are ~100ns and the deadtime is about 377ns, using 220-ohm / 1.5nF on the deadtime generating circuit. With bus voltage, the turn-on and turn-off will be longer due to the Miller plateau, but it should still be well shorter than the deadtime. At 150kHz, two 377ns deadtimes accounts for about 11% of the PWM cycle. This would be a bit long for motor controller operation, but it's okay for the Tesla coil driver, which will spend most of it's on-time operation at or near 50% anyway.

As usual, I built a Visual Basic GUI to control the whole thing:

It sets the drive frequency of the resonant circuit (for tuning to the resonant frequency), as well as the duty cycle profile over a finite number of cycles that make up a single "pulse" sent to the primary. The duty cycle for each cycle can be ramped up to some maximum value, held, and then ramped down. The GUI also sets the frequency at which the pulses are generated, which is what will ultimately be used to play MIDI notes. Here's a quick video showing the GUI tuning process with just the primary:

You can seem me playing with the pulse lengths, as well as the drive frequency and some other parameters. A single pulse on the primary with no secondary present looks like this:

The current on the primary (measured using a current transformer) rings up to some maximum value quickly as the square wave voltage excites the resonant circuit. (The current itself is mostly sinusoidal.) Then, after the drive pulse ends, the energy in the primary is slowly dissipated in its resistance. With a secondary in place, energy would be coupled into the secondary coil and the primary current would look a lot different. But for testing purposes, using the primary alone at low voltage allows me to actually scope things.

The first thing to check is the primary resonant frequency. From the design, I was targeting something in the range of 135-150kHz. Tapping the real-life primary coil at approximately 6 turns gave me a resonant frequency of 154.5kHz, measured by sweeping the drive frequency around to find the maximum ring-up. This gives a primary inductance at 6 turns of 10.6μH, since the primary capacitance was easily measured to be almost exactly 100nF. So, I'll probably have to move the tap out a little to get it in tune with the secondary. (The target frequencies for best coupling were 151kHz and 136kHz.)

Next, I wanted to use the decay time to estimate the real-life primary resistance. I could probably have just put in the peak values as initial conditions in a SPICE simulation of just the primary LRC resonant circuit. But, since I have a full SPICE simulation of the driver already, I decided to make things more complicated by having my VB GUI export gate drive waveforms to the SPICE sim, which would simulate the entire pulse sequence. I then tweaked the resistance value until the decay envelope on the SPICE sim matched up exactly with the one on the scope:

The magic number in this case was about 90mΩ, which seems accurate given that the skin depth on my 8AWG grounding wire is probably making it act more like 14AWG wire. But anyway, I now have a more precise simulation of the exact pulse sequence, including ramping and duty cycle control. This should be useful when it comes time to ramp up the power.

Speaking of which, I discovered the USB limit for this power system. As is also the case on many of my motor controllers, USB communication and high power simply don't mix and above a certain current (40A in this case) the GUI starts to get comm. errors. Typically, the micro and all the logic circuity can continue to operate without any issues - it's just a problem with the serial communication. Since I suspected this might be an issue, the plan is to use an XBee link to between my laptop and the logic board, the same trick I use to get data off of motor controllers while they're running. It may seem like running an RF link instead of a wired connection would be a bad idea in a Tesla coil environment, but I've been down this decision path before and the XBee always seems to win...

Next step: ramping up the power, tuning, and hopefully generating the first sparks!

Wednesday, December 12, 2012 Space!

This might seem like a radical departure from the normal content of my blog, but I assure you that by the end of the post you will see that it is not. But yes, for I think the very first time I am going to post about a computer game! I'm not much of a gamer: the only game for which I ever achieved "fan" status was Gran Turismo, an epic racing game that frustrates most players because of the hyper-realistic physics engine.

Now I think I have achieved fan status for a new game: Kerbal Space Program, an epic space game that frustrates most players because of the hyper-realistic physics engine.

The Kerbals are a race of tiny green men who choose to go to the moon and do other things, not because it is easy, and not because it is hard, but because they seemingly have nothing better to do with their time and no monetary constraints or self-preservation instincts to keep them tied to the ground on their home planet, Kerbin.

"This will certainly go somewhere when we press the launch button."
The game has been under development for two years and is still pre-release. I was introduced to it by my brother back when there was only Kerbin and one moon. There is now a free version (v0.13.3) and a paid version (v0.18.1 at the time of writing). The paid version includes a vast solar system, more parts, and more features such as EVA (spacewalking) and docking. The real benefit of the paid version is that it gets you access to any and all future updates including the release version.

Thus far the pre-release versions have been true "open-world" games...except even that concept ceases to capture the nature of the game when there are six worlds and many moons to explore. While future versions will likely have "career" modes with a set of missions and a budget, the game right now has no concept of money or points. You build a spacecraft out of a set of parts, and then fly it to wherever you want.

Including, if you want, the top of the vehicle assembly building.
The parts inventory is made more entertaining by the descriptions of what each part does, which reflect the essential character of the Kerbals to some extent:
"The TR-18A Stack Decoupler is equipped with a (hopefully) small explosive charge, that will sever the structural linkage between itself and whatever it's connected to."
 "A monster of an engine for heavy lifting purposes, the Mainsail's power rivals that of entire small nations."
Also, parts are not limited to spacecraft: newer versions of the game include jet engines and aircraft parts, as well as a horizontal runway for commencing normal flight:

But although the sandbox aspect and the snap-together rockets and relatively humorous Kerbals make the game seem like it would be a good iPad app to kill time on the bus, the real nature and challenge of the game comes from the physics engine, which is based on real orbital mechanics in the Kerbol System, where planets are generally smaller but denser than those of the actual solar system. (Kerbin has the same surface gravity, 9.81m/s², as Earth, but is only 600km in radius.)

The first thing KSP teaches you is just how damn hard it actually is to get something into orbit. Getting into orbit is not the same as getting into space. A balloon can get into space (almost). To get into orbit, you have to both get out of the atmosphere and build up enough horizontal velocity so that you no longer need to spend fuel to fight gravity. (You fall as fast as the planet curves away from you.) For low Kerbin orbit, this requires a speed of about 2,000m/s.

But because you're fighting gravity and aerodynamic drag on the way up, the actual amount of propulsion needed is much higher than would be required to go from 0 to 2km/s in space. In fact, the actual speed increase (ΔV) you would be able to achieve in space using the amount of fuel required to launch into low Kerbin orbit is something like 4.5km/s. To put any sizable payload, like a ship that can go to the moon (called Mun in the game) and back, into orbit requires a pretty large rocket.

Note the speed is still well below orbital velocity.
So the next thing the game teaches you is what spacecraft are mostly made of: fuel. The rocket equation tells you that the ΔV you can achieve with a particular rocket is limited by only two things: how fast the exhaust is, which is a property of the engine, and what fraction of the rocket's mass gets thrown out the back. Only the ratio of starting to ending mass matters, so a small rocket or a large rocket can get into orbit equally well if they have the same engine and are both 70% made of fuel. The only reason to use a larger rocket is so you can put more final mass into orbit.

The realistic physics lead you to create multistage rockets. Once on stage's fuel is used up, you detach it to get rid of the dead weight (thereby increasing the percentage of the remaining mass that is fuel). There are also trade-offs among different engines: some have higher exhaust velocity but too low of a burn rate to produce enough thrust to get into orbit. These are better for maneuvering in space. So you wind up having to think carefully about the design of the spacecraft if you want to go farther.

For example, you can go to Duna, the Kerbol System equivalent of Mars.
Another cool feature just recently added to the game is docking. If you think aiming for a small moon is hard, try aiming for another ship which has no gravitational attraction with which to pull you in when you get close enough. Maneuvering two ships in orbit to the point where they could be docked was by far the hardest thing I've had to do in the game so far. But the reward is an almost unlimited ability to build larger ships or refuel in space.

The game does not (yet) have an autopilot that will help you launch, land, dock, transfer orbits, etc. But it does have a nifty maneuver planner that will show you the anticipated result of a maneuver at some point in your orbit. It will show you which way to point your ship and give you a countdown of how long to burn your engines to get where you want to go. But you still control the pointing and burning, so it's still a bit hard to do really precise long-range orbital maneuvers. For example, it's possible to do single slingshots but something like a Voyager trip would be very hard to do without a more advanced planning and autopilot system.

So far, I have been able to make successful trips to the Mun and return. I also made a one-way trip to Duna, which was punctuated by a harrowing untested parachute descent which barely cleared a crater wall.

Clearing the crater wall by about 1km while still going 0.5km/s...
Looking out from the crater rim to the landing site.
My current spacecraft, designed from scratch for interplanetary travel in v0.18.1, looks like this:

Stage 1 is driven by four Mainsail engines, the largest in the game, and burns for the first ~75 seconds of the launch. Stage 2 has a single Mainsail engine and burns for another ~85 seconds. These two massive stages are able to produce a total ΔV of 3.39km/s (Yes, I calculated it. As an interesting comparison, the ΔV possible from the two stages combined into one, with five engines all burning, is about 2.92km/s.) While quite heroic given the massive payload, this is not enough to get into low Kerbin orbit, so Stage 3 has to do some work on the way up.

Stages 3 and 4 combined are the interplanetary portion of the ship, designed for taking three Kerbals to the far reaches of the Kerbol System, and maybe sometimes back.

Stage 3 uses four of the "atomic" engines (strange name since they run on normal liquid fuel...) which are the most efficient stock engine (highest exhaust velocity). But they have relatively low thrust, so they're not great for getting off the planet. They work best for long burns to perform transfer orbits. Stage 4 is the lander itself, which uses the "Poodle" engine. This engine has enough thrust to get off a small planet or moon. You can see it landed on the Mun in the first image of the post.

Stage 3 and 4 can produce a whopping 5.67km/s total ΔV. That should be plenty to go to most destinations and back from some. I think it can do a landing and return from Mun, Minimum, or Duna, although the latter two are untested. A Duna return in particular would be hard due to the uncertain amount of fuel required to land on and take off from Duna. (Minimus requires very little fuel for this since it's tiny and has no atmosphere.) Other planets are either too massive or too far (or both) for a landing and return trip, I think. But flybys and one-way trips to almost anywhere should be possible.

But, Stage 3 consumes about half its fuel just to get into Kerbin orbit. That's why I was so excited to try out the docking feature. Now I can combine two ships in Kerbin orbit and transfer full fuel to one of them. I can even use most of the remaining fuel in the second ship to boost the whole assembly out into deep orbit, a trick that should bump the whole mission's ΔV starting from low Kerbin Orbit to something like 6.52km/s. That amount of fuel should provide plenty of deep space maneuvering ability for going to check out places like Laythe, a potentially habitable moon of Jool (Kerbol Jupiter)...

So many possibilities.
And now I feel the need to apologize for any number of person-hours of productivity this post will cause to be lost forever into deep space.

Saturday, November 24, 2012

DRSSTC Δt2: Primary Construction

It's been a long, long time since I first started putting together my first Tesla coil, and now I'm finally back at it. It was supposed to be a summer project, but I guess I spent too much time designing it and got distracted when the time came to actually put it together. But I'm glad I got through the secondary winding while I still had momentum. Recently, I had a crazy dream where some MITERS people were testing coils and blew up a transformer outside, so I went to hide my secondary but couldn't find it in a pile of neglected, unwinding coils. Anyway, that inspired me to get back to work.

This update is mostly about the construction of the primary circuit, consisting of an flat spiral inductor and a series capacitor that form one half of the resonant power transfer. The circuit elements are easy enough to construct: the inductor is only 6-8 turns and the capacitor is an off-the-shelf component. But they are integrated into the base of the coil, so I had some mechanical work to do (for once...).

The spiral coil is made with 8AWG grounding wire (McMaster P/N 7512K641). 25 feet of it was just barely enough to make the complete spiral on a 20in diameter circular base of 0.25in-thick polycarbonate. I marked out the spiral by unwrapping a string from an appropriately-sized spool fixed to the center of the base. Then, I drilled two small holes on either side of the spiral marker line in 90º intervals. These holes served as small zip-tie mounting points to hold the grounding wire in shape around the spiral.

Originally, I had planned to have the spiral coil on top of the polycarbonate base, as in this rendering. However,  I settled on flipping the base upside down so that the coil is below it. This makes more sense from a keep-the-high-voltage-covered perspective, although only as a supplement to the higher-priority safety plan of "don't go near it at all ever". The performance hit from decreasing the coupling would matter, but I intentionally wound the primary closer to the bottom of its PVC pipe coil form to keep the designed distance between primary and secondary coils about the same.

I calculated six turn for the primary, but added an extra turn and a half for tuning, to adjust the primary's resonant frequency. Tuning requires a movable tap of some kind, which I decided to make from scratch since jumper cable clips seemed like a bad idea.

Since the primary circuit has a total resistance of only about 70mΩ, it was important not to add a significant amount in the form of contact resistance. (Especially considering that the peak current going through the connection could be several hundred amps and the RMS current as high as maybe 50A.) I opted for a homemade screw terminal made from a small aluminum block with a copper strip bent around one side. Most of the current probably goes through the aluminum, but the copper gives it a second path that doesn't involve steel cap screws. Attached to the spiral coil, it looks like this:

Did not notice that sign when I took the picture...
I haven't measured the contact resistance, but I imagine it will add a couple milliOhms at most. To adjust the tap position for tuning, the two cap screws are loosened and the block is moved around the coil to a new location. This is the node between the inductor and the capacitor in the primary circuit, and as such is the highest-voltage point on the primary, designed to hit about 3kV in operation. I used some high-voltage noodle wire (McMaster P/N 9620T22) to connect the clamp to the capacitor; probably overkill, but it looks cool too.

Speaking of capacitor, I put together a 3S3P pack of 100nF CDE 940C30P1K-F film caps to make the primary capacitor:

It's hard to see through the double layer of heat shrink, but each capacitor has a string of four 1/4-Watt resistors of 250kΩ each, for a total of 1MΩ. These act to balance the series capacitors and also to drain the bank quickly (RC = 100ms) when it's disconnected from power. I used four resistors in series per capacitor, and three capacitors in series for the bank, so each resistor only sees about 1/12th 3kV peak (250V peak).

One other small but annoying mechanical task was making something to hold the secondary coil in place. Luckily, I found a PVC fitting of the right diameter and managed to just barely blind-tap some 4-40 holes into the side of it to hold it to the polycarbonate base:

A wire passing up through the base connects the secondary coil to ground, through one of the 80/20 columns on the side of the driver box. I'll probably add some insulation to the screw head, since it sits right below the high voltage node on the outside of the primary coil. The secondary slips right onto the PVC fitting, and it almost looks like a functional Tesla coil:

I should be able to start testing the driver next. (It's build and mostly wired.) The first task will be identifying the resonant frequency of the primary, since my driver isn't self-resonant. I will probably run some low-voltage frequency sweeps and mark out some taps on the spiral for a range of resonant frequencies around 150kHz. Once I know what the tunable range is, I can pick a spot and try it out with the secondary at increasing levels of power and re-tune as necessary. (Since it's not self-resonant, I'll have two tuning "knobs": moving the tap and adjusting the drive frequency.)

So, some day soon there will be sparks! ...and eventually music. And if you're getting impatient (understandably, since my progress has been disappointingly slow), you can soon make your own with a kit from oneTesla, started by a few HV-competent MITERS members for all your musical Tesla coil needs.

Monday, October 15, 2012

VPPC 2012

Last week I attended the IEEE Vehicle Power and Propulsion Conference (VPPC) in Seoul. I haven't been to an academic conference since EVER '11, so it was interesting to see what's new in the world of traction systems.

Everything is greeeeeeeeen.
There were some industry representatives present as well, most notably Hyundai/Kia, LG Chem, and Toyota. The cutaway car above is a Kia K5 (Optima, in the US) hybrid. Keynote speeches on the latest Hyundai/Kia and Toyota hybrid systems were interesting and offered comparisons to the full EV Nissan Leaf and the range-extended hybrid Chevy Volt. Left out was any mention of the Tesla Model S, which is presumably in a different price/performance range.

The conference venue was the very nice Seoul Olympic Parktel:

The Olympic Park was a nice exception to the otherwise huge and somewhat crowded city of Seoul (pop. 10.4M) and since I was jet-lagged and waking up at 5AM, I went for a walk through the park in the morning. I felt pretty stupid for not bringing my Talon quad with me - I thought there would be no open space in which to fly it around.

Oops, wrong.
Anyway, back to traction systems. I went to the conference to present my Masters research, which is admittedly behind where I am currently at in terms of combining my version of field-oriented control and sensorless position estimation. In retrospect, I could have focused more on the sensorless stuff; there were not many other presentations on sensorless permanent magnet synchronous motor control.

There were a number of presentations on traction motors of all flavors. Most of the commercial hybrids have converged on internal permanent magnet synchronous motors (IPMSMs) for their combination of good torque density and good high-speed field-weakening characteristics. However, the anti-permanent magnet sentiment that I noticed at the SMMA conference a few years ago is still strong in the research world. There were many presentations on wound-field synchronous motors, switched reluctance motors, and induction motors.

Oh hi, Professor Kirtley. Haven't I seen this before? I feel less bad about presenting two-year-old research now.
I do agree that for full-scale EVs, induction motors make a lot of sense. The cost of permanent magnets for a 200hp traction motor is significant. A well-designed induction motor (I'm looking at you, Prof. Kirtley) would still have a slightly lower specific power, but I don't think we're talking about a factor of two - more like 20-50% more weight per horsepower. But, the most significant weight hog in a full-scale EV is the battery pack and an extra 50lbs dedicated to motor weight isn't the end of the world. Furthermore, full-scale EVs can benefit from the inherent field-weakening capability and inverter fault tolerance of induction motors when operating at highway speeds. (PMSM field weakening to overcome back EMF limits is frighteningly dependent on the inverter not failing.)

For hybrids, or full-scale EVs with distributed motors (2WD/4WD), or for small-scale EVs like bikes, motorcycles, and scooters, I can't imagine switching away from the clearly superior performance of NdFeB magnets. I'm also not convinced a reduction of export of rare-earth materials means a drastic increase in price of finished products like magnets and motors from China. Maybe the price was just unreasonably low before? In any case, going backwards to older technology seems wrong to me.

One other exciting group of presentations (for me anyway) was from the semiconductor industry.

A representative from Infineon made the point that the mechanical complexity of the internal combustion engine is being replaced by complexity in the power electronics and control of electric motors in EVs. IGBTs  are currently the semiconductors of choice in EV traction systems. Active research includes new packaging that eliminates bond wires (a major reliability bottleneck, since they are susceptible to thermal cycling stress) and enables double-sided cooling. Further in the future, high voltage/high temperature SiC MOSFET/JFET devices are coming (squee).

There was also a big emphasis on battery charging solutions. The standards for battery charging (levels, connectors) are mostly worked out now, so there are some real-world implementations coming on line. In fact, I saw one actually in use, unrelated to the conference, while out being a tourist in Seoul:

These chargers were at the top of a very large hill leading to Seoul Tower, which is a huge tourist trap and therefore serviced by lots of tour buses. At first I thought it was cool to see an electric (or maybe hybrid) bus charging at the top of the hill. But then I thought about how bad of an idea that could be. What if you start at the top of a large hill with a fully charged battery? Surely, the controller will not allow you to regen, and you will put higher-than-normal loads on the mechanical brakes. I'm sure they're designed to handle the full braking power of the bus with no regen, but still: wouldn't it make more sense to put the chargers at the bottom of the hill?

Anyway, if you do make it to the top of the hill, you are rewarded with a 30-minute wait to take an elevator to the observation deck and attempt to take pictures through a glass window with reflections of yourself and the gift shop behind you and fingerprints all over the glass. Most of the pictures come out like this:

With enough camera fidgeting I got this:

I would estimate that about 2/3 of the height comes from the large hill that the buses climb and only about 1/3 is the tower itself. It should give you an idea of how big Seoul is: this view only covers about half the city. Overall it was a great venue and an interesting conference. Here are some more pictures:

Tuesday, October 2, 2012

Maker Faire NY 2012

I spent the last weekend at a DIY 3D printer convention Maker Faire NY with the MITERS crew showing off some projects from the past year, as well as some older ones. Last year was my first time attending a full Maker Faire, although I've done the Cambridge Mini Maker Faire several times. Armed with a better understanding of exactly how many little kids with inattentive parents were going to try to touch, climb on, and ride the sharp and dangerous projects, I came better prepared this year:

Yes, tinyKart made it down again, this time with a new license plate. Getting it down was a little trickier than last year, since we had to bring nine people plus all the projects in one minivan and one Jeep. That meant going a step further than the two-piece configuration that made it down last year. This year, tinyKart was packed entirely flat and stuck in the back of the minivan along with all of my other small projects:

And I just sat in the seat the whole way down.
I almost didn't bring tinyKart this year, but I'm sort-of glad I did because it was able to finally get a tiny bit of "track" time on the Power Racing Series track at Maker Faire. The Power Racing Series is a relatively new racing league for modified Power Wheels-style cars. tinyKart is obviously not a modified Power Wheels, so it was ineligible to win any races. (Although as some places seem proud to point out, it was apparently eligible to lose them...) 

Still, it was fun to get a little track time in an ultralight kart that was never really designed for anything of the sort, which weighs 55lbs and can be brought down in the back of a minivan. If you want to see what it actually can do, here's Max taking it for some laps with little traffic to slow him down:

It's a viable go-kart with handling that is way better than it should be, given the custom and very flexible chassis. I got to run some laps in the wet and it was quite amazing. By the second day of the Faire, it had incurred a bit of race damage and was down to one wheel drive and a single disk brake. Then, it started raining. No matter, it was still awesome:

So, tinyKart is a little broken after this trip. It's been due for maintenance anyway, so this will be a good motivator to fix it up and finally put on new controllers. Other than that, it needs completely new spindles, since two of them got bent up in brushes with the track barriers. It also needs a new belt and a new steering linkage. (The part which is called a "fusible" in French for reasons I now understand more completely.) And some of the non-structural front frame got beat up. No major structural or powertrain damage though.

Kinda glad we kept those corners in the design.
Of course there were also many copters at this year's Faire. Here's the selection of MITERS flying objects that made the trip down:

From left to right, there was 4pcb (which didn't get to fly since it's mostly an indoor copter), my versatile Talon Quad, Nick's feather-light tricopter, and Banks' Derpcopter. There were several other groups with flying things at the Faire. One that particularly caught my eye was the AeroQuad booth, which had several nice FPV frames:

Generally, it was too crowded to fly around, but there were a few opportunities to do so at the field near the AeroQuad booth. My brother and I also decided to head in early on Sunday to get some aerial video before the crowds showed up. Of particular interest was the (real) Titan rocket, which is a bit over 100 feet tall. Here's some GoPro video from the Faire before it opened on Sunday:

The Talon has been flying great with FFv1.2s motor controllers and the modded KK2.0 firmware. It's mostly limited by my piloting skills and lack of FPV equipment at this point.

Photo credit: Matthew Honickman.
I also brought Pneu Scooter, and as luck would have it the rear tire got a leak the week before Maker Faire just like last year. So just like last year, I took the entire wheel/motor assembly apart, cleaned everything out, and replaced the wheel. I also took the opportunity to extend the phase wires so they would not have to be cut every time I need to replace the wheel.

After the wheel change, I also tried and failed to get a 3ph v4.0 controller in Pneu Scooter for the Faire. But since I ran out of time, I went back to the trusty v3.1 and it worked with no problems for the entire event. It's by far the best way to get around the venue when it's crowded.

That's it for the project updates, but here are some more pictures I collected from the Faire:

Chibikarts and hexarideablepods.
Ground clearance?
Runs on two D&D motors.
MITERS won an editor's choice award from Make.
I hope those are all used metro cards.
One of these things is not like the others...
Ben's scooter hauling most of MITERS back to the cars at the end of the Faire.