Crash
Towards the end of the year, December 30th, we were going to fly to collect some data to verify our attitude estimation filters. It was a bright clear day, cold, with almost no wind to speak of.
As per our usual routine, we set up down at the field, and flew the small R/C plane first to make sure that flying conditions were appropriately benign.
We did our first flight around the patch with the UAV, and it seemed to be doing fine. We were suffering telemetry dropouts, and we were a bit paranoid because we had crashed from an R/C outage on the prior flight. We had replace the RX with a better one that would not suffer from signal fading.
After a 5-6 minute flight, we landed and swapped out the battery. We tried to download the flight data off of the SD card, but could not get it to read. We figured we would get some more data and then call it a day.
As an important note, the autopilot at this point is passively listening in on the R/C and recording the sensors. It is not driving anything, and is just there as a passenger on the aircraft.
About two minutes into the flight, the pilot (Greg) called out that he had lost control of the A/C and it went into a steep dive ending with a loud crunch into the parking lot.
We have destroyed our UAV, and we need to take a few moments to learn the lessons from this painful experience.
(1) While this is a setback (even a huge one), we will rebuild and get the AP airborne again. We've lost some money, and more time, but we come back from this.
With that, onto the lessons:
(2) We were way to quick to assume we understood why we had lost the R/C receiver on the previous flight; we need to be much more methodical about fault isolation and detection. In the rush to get things flying, there are some design decisions that are looking like they need to be revisited, and fixed.
(3) The R/C system *is* our safety backup. All we have been doing for the last two flight tests (both of which ended in crashes from the same fault) is flying an R/C airplane with an extra payload. This should be something we can do until the cows come home without fault or flaw.
(4) Weight and balance of the aircraft is a whole lot more critical than we think. The aircraft must be trimmed in such a way as to maintain a low speed glide when the power is cut to the surfaces. Greg was flying with full up trim on the elevator servo--when the power failed, the servo went to its geometric center, and the UAV went into a steep dive. The aircraft does not need to be an imitation of a lawn dart on decent.
(5) Wiring and rigging need to be addressed so that the autopilot and radio are protected during a crash. We can play with what is left of the UAV fuselage, but I think the AP would be best seated behind the wing if possible, and definitely *not* with the battery behind it.
(6) We have the data, lets be methodical and systematic. Don't guess, and don't assume you are right. Come up with a hypothesis, and then see if you can prove it wrong with the data. The signatures of the failure are there, we just need to tease it out of the data.
So, where do we go from here? The four main tasks facing us before we can fly again are:
(7) Damage assessment: we need to know what works, and what does not. We have a dead LiPo battery, a dead SD logger, a mostly dead motor, etc. Happily, the AP itself is alive and working. Each subsystem needs to have a test procedure that can validate whether it is alive and healthy or not. While this should already exist, if it does not we are going to have to make them (for instance, gyro data can be viewed in the ground station while the AP is on the rate table).
(8) Attitude estimation: with the data we have, the Kalman filter and noise in the sensors needs to be tuned and resolved. We need to demonstrate reliable and robust attitude estimation.
(9) Position estimation: this requires attitude estimation to work, but we need to validate it and show the entire flight reconstruction.
(10) Hardware in the loop simulator: again, we should be able to recreate the flight from the recorded data and play it over and over again on the hardware. We'll use this to validate our models.
(11) Fault isolation: it is pretty clear that we have a problem in the power that glitches the R/C receiver. From a dead turn on on the bench, it can take as long as 10 seconds to recover, but what do intermittent glitches do the the R/C? The data is there, and then we need to go and look back at the previous flights and see what happened and for how long. This demon has been in the UAV since the beginning, and we need to figure out where he hides and banish him forever.
(12) Rebuild: this is an opportunity as much as a burden. Yes, it is going to take a while, but it will also give us the opportunity to fix mistakes or better design things now with the experience that we have had from building this one. Once we figure out what we have working (see 7 above), we'll put in an order to buy new parts.