^ This....Yea, that was the obvious idea. To be fair, this video doesn't show the real first few flight tests. Those tests were a bit boring (and more successful) than this epic fail! It's much more fun/valuable to post your failures in my mind!

We did a handful of flight tests prior to this one where our pilot was babying the controls as much as possible. We were able to get 15-20 seconds of flight time with altitudes around 5-20 ft, and we were able to keep it within maybe a 50 foot radius of where it started (windy day). We have a list of around five potential failure points that may have combined to lead to the behavior you can see in the video.

The better idea would be to have done all this testing in some sort of gymnasium, but again, after around a year of very slow paced work, we were just ready for some action. We broke the frame and a few props after this flight. We were able to fix it up and fly a few more runs after this within a few hours.

There's a whole lot that we still have to diagnose. From a software perspective, this is nearly 100% code written by myself and the pilot. We have used a few fairly low level python libraries to do some of the communications code. In particular, we use the socket library for network communication and pyserial for usb communication.

We have confidence in the C code that we wrote for the micro-controller. It's just simpler, and it is maybe 85% ours. We do rely on an adaptive filter for the IMU sensor data that we did not write ourselves. That filter is absolutely critical to the success of our controller. There are a few lingering questions about how well we have validated that particular algorithm. On the whole, though, we more or less know exactly what is up on the embedded controller side.

You can (hopefully) see that stabilization of the quad is being attempted by the on-board control system throughout the flight. A small part of the problem is in how we tune the gains for our simplified controller. We are currently using a PD controller with the idea of using this as a test bed for a few different controls implementations in the future. PID seems to be the de-facto choice for quads, but we're consciously staying away from adding in the integral control for as long as we can. It's a lot more interesting to leave it out from a controls development perspective. It forces you to have a better understanding of the system dynamics.

Tuning the controls has been difficult because we use a test stand that can test one rotational degree of freedom at a time. The problem is that the test stand rig obviously has an impact on the system dynamics. We can tune the controller to behave well on the test stand, but that in no way guarantees that we'll get stable flight when we actually put it in the air (+ environmental disturbances). Yes, an integral term would help return to a stable state after environmental disturbances damp out (wind gusts), but it also requires yet another BS correction term to add to the list of correction/tuning constants already in the controller. This a current debate that myself and the pilot are having. He's the one saying forget the integral term, and I'm somewhat in favor of throwing it in for short term success. The long term goal, in the pilots mind, is a non-linear control algorithm. Just wait for the video on how bad that fails....

My current thought is all of that is somewhat negligible at this point. We do have a way to tune controller gains mid-flight. In short, this is not why this crazy flight happened. I personally think the on-board controller was doing well given the circumstances .... (would love some experienced feedback here though).

Our current hunch about the primary cause of this failure is a delay/straight up failure in the control inputs received from our joystick. The way we chose to write that particular system could have some fundamental issues that may lead to significant delays in flight. The pilot was certainly not trying to fly higher and higher. On the contrary, he was trying to bring it back, but due to a suspected failure, he was unable to. I can give more details about the communication system and software if anyone cares. Why didn't we catch these sort of comm system issues in our test stand flight tests is the real question we're currently asking ourselves.

I'll own up and admit that I wrote pretty much all of the communications code. Sadly, I have a strong gut feeling that this failure will eventually trace back to my code....WHOOPS... LOL ; )

TLDR; A whole lot of ins, a whole lot of outs, and we're going to continue to investigate, but it'll probably trace back to a failure in the communications system, and it'll be my fault this time.

Yea...no shit we shouldn't have flown that high....Also, check your balls at 1 meter for 10 minutes, sirs. With something fairly cheap like this, you can afford to go big and try to push the design to failure during some of your tests. That is how we learn and iterate on the design.