I should put the PCB quadrotor away...

...but it's just so addicting. I implemented a few simple improvements:

On the suggestion of Max H., I added 1" nylon standoffs to each of the four corners as landing gear:

You might also notice that the motor looks a little different. Although the landing gear does the job of keeping the quadrotor level during takeoff, it also transmits much more of the impact of landing into the motor. (Previously, it was being absorbed by the LiPo battery...) Now, except in the rare soft landing, the impact would dislodge the motor can almost every time. I tried a few different types of adhesive, but they were too brittle and the surface area was too small for them to withstand the shock. In a moment rage-induced inspiration, I found a piece of heat shrink that fit over the motor and cut it so it would just overhang the can when it shrank, which is what you see above. This turned out to be the best idea of the week: after heat shrinking, there have been no further motor can failures.

With the risk certainty of crash landing directly on the LiPo eliminated, I also upgraded to the more potent chemistry of the Turnigy nano-tech line, specifically the 2S, 460mAh, 25-40C pack:

Can it explode just from looking at it?

It's roughly the same size, weight, voltage, and price as the lower-power LiPo I've been testing with, but it has a much lower internal resistance, which means less voltage sag under load. The difference is noticeable, with lower throttle for takeoff and also similar flight time despite the slightly lower capacity, since the motor controllers stay above their low-voltage cutoff longer.

I made one more change which has nothing to do with the quadrotor itself: I decided to take Ryan A.'s advice and fly with a PS2-style gamepad instead of a joystick:

I haven't tried flying with a Weller power supply yet...

It's generally better for controlling robots, so I'm not sure why I expected the joystick to be more appropriate for a quadrotor. The only other quadrotor I've flown used a standard RC flight transmitter, which is closer to a gamepad than a joystick. Thumbs are more precise and faster than entire arms, or even if you're doing it right, wrists. The gamepad has a spring-loaded throttle, which I thought would be problematic. But, with no altitude control anyway, I am always going to be adjusting the throttle even to hover, so it doesn't matter if I have to keep pressure on it. 

Up to now, it sort-of flew, but it would tend to drift around a lot. The series of small changes helped, but I still wasn't really satisfied with stationary hovering. I had speculated that the control loop itself was working and stable, but that the zero angles in pitch and roll were wandering, causing it to sporadically dart off in some direction. With enough space, I could still catch it and bring it back to center, but the immediate goal was to be able to fly it in a small room. For that, a more consistent zero would be necessary. 

To troubleshoot any further, I had to spend some time getting the data acquisition up and running. This should be easy since I've been doing it the same way forever, but for some reason it took me half a day to get the XBee radios to cooperate. And I had to settle for 19200bps transmission because 57600bps seems to be very tricky with XBees, particularly when wireless bootloading is involved. I've had the same problem with the STM32 chip, and I swear I will sit down and actually solve this soon. Anyway, once I had the data running, I did a test run at full throttle with the quadrotor held down on the bench. 

My theory that the power supply was sagging, causing the ADC readings to be offset under load, was quickly disproved and replaced by a new theory:

Specifically, that the sensor signals are total garbage. What you're looking at is a plot of the angular rate signal coming from the +/-300deg/s pitch gyro...while the quadrotor is stationary. So, the noise amplitude is half the full range of the sensor. The complementary filter, which relies heavily on the gyro for computing the angle, is understandably confused, reporting an angle that wanders from -5deg to 11deg, again while the quadrotor is stationary.

And here is where I possibly violate the golden rule of troubleshooting. ("If you can hear it, it's a mechanical problem. If you can smell it, it's an electrical problem. Everything else is a software problem.") I have implemented both hardware and software filters to take out high frequency noise from the inertial sensor signals. But somehow, a massive amount of noise was still making it through. Probing with an oscilloscope revealed it to be broad-spectrum noise, including some low enough to make it through all my filters, with a little bit of an 800Hz sine wave on top of everything. The cause seems obvious now, but I'm so used to electrical noise in high-current motor controllers that I at first neglected to even think about mechanical noise. The test to separate the two was simple:

Running at full throttle with the inertial sensors off-board, the data tell the story:

The rate sensor noise is completely gone, and the angle stays much closer to zero, where it should be. This very clearly points to mechanical vibration as the source of the noise, and more so it suggests that only a mechanical solution will work; the noise is so destructive to the gyro that no amount of hardware or software filtering will take it out. So, having the inertial sensor sitting on headers is no longer an option, and it's time to break out the foam tape:

Attempt #1 used foam-tape only and replaced the headers with a long loop of flexible wire, so as not to transmit vibration through the connections.

Well now that didn't really work at all.

After this failure, I decided to switch over to the C part of the mechanical RC filter by adding some mass to the sensor board:

Sorry, Ryan.

I also made the tape thicker and looser.

The extra mass of the small aluminum plate helps the sensor board establish its own frame of reference that rejects high frequency vibrations that do make it through the tape. And the data:

Hrmmm.

Well, it doesn't look much better, visually. But the noise amplitude is a tiny bit lower and, more importantly, the angle doesn't wander around as much. (The times it does are when I was picking it up and moving it. You can tell because the rate is very clean there.) At least it gives me a little bit of hope that the vibrations can be damped enough to make the signals usable. I decided to give this configuration a chance in flight, using the best controller gains I'd established thus far:

Somewhat surprisingly, the small amount of noise reduction makes a huge difference in flight. (Well, combined with the other changes I made above.) You'll notice that I've changed venues and can actually fly it in this smaller classroom now. It still wanders around a little, but I at least feel much more in control of the wandering. I even manage to land smoothly a couple of times. And the data?

Well, that's basically still noise. Maybe there is more useful information contained in the average rate, but it's still visually lost in the noise. I think more drastic isolation measures, maybe combined with more aggressive filtering, will be required for it to give a clean rate signal. Ideally, it should reject everything above about 100Hz. Since the sensor board mass is still very low, I suspect I will need an even more compliant mount. What the heck is more compliant than loose foam tape?

But anyway, I am happy that its hovering can be contained to a 10'x10' area now...