Figuring out the source of a crash

On Saturday I attempted to test my UAV out with the birds. It was decided that we should do a test flight sans bird just to check that everything was working ok first. I set up the UAV and attempted to arm it, but for some reason it would not arm. I had previously configured the controller settings as:
I was only intending on using Stabilize and AltHold, and so had these two modes on switches next to each other.  I was attempting to launch in Stabilize mode.  I had previously set the ARMING_CHECK parameter to 0, so factors such as GPs fix should not have prevented arming.  I was jugling my laptop and controller at the time, and suddenly the UAV armed then flipped itself over.  A colleague grabbed the UAV and held on to it until it had died.  It kicked up quite a bit of grit (resulting in a dirty laptop), and caught a stone.  The stone twister one of the prop motors on it’s stand, which I have had to glue back in place.  It was not clear at the time what had caused the flip, and so I looked at the logs afterwards.

The graph of the gyroscope values show the crash quite well.  The point at which the UAV worked out that it had “crashed” can also be seen, and it is the point at which the UAV thankfully cut out.  However, if you look at the flight modes, it is quite interesting.  I had confirmed the flight modes on the controller thoroughly before the flight, and had confirmed with my assisting colleague that they were mapped correctly.  However, from looking at the logs, it can be seen that the UAV believed that it was in AltHold mode from the start, before transitioning to Auto mode.  All though the ARMING_CHECK parameter is not concerned with flight modes, it seems likely that the controller would prevent the UAV from arming when in AltHold mode, as the altitude to be held would be that of the ground.  What is interesting is that the two top customisable commands on the interface (Stabilize and AltHold in this case) have had some issues before.  On previous test flights we have had the option that is currently AltHold be set to AltHold but behave as though it was in a different mode.  Due to how the flight modes are set up, going from Stabilize to Auto takes one flick of a switch, whereas going from AltHold to Auto requires to switches to be pushed in opposite directions.  What I believe has happened here is that I had the switches seet to Stabilize mode, but the UAV was interpreting this as being the next mode over, AltHold.  The mode is dictated by PWM (pulse width modulation), with each mode being associated with a range of values.  As these two modes are neighbouring bands, it’s possible that the PWM value was out by enough to cause it to be interpreted as belonging to the neighbouring band.  Indeed, in the initial screenshot the value can be seen to be 1169.  The edge of the band is 1230, which is not too far from this value.  It seems possible that the value may have jumped enough to change mode.  Some testing will need to be done to verify this.  I suspect that during the flight I accidentally hit the switch that changed the UAV in to Auto mode.  As I said, this would require a single switch if the controller was in the Stabilize position, but two opposing switches if the controller was in the AltHold position.  In my mind this adds weight to the theory that the PWM value had drifted to the next band.  As for the flip, the Auto mode explains this.  The flight man remaining on the system is for Aberystwyth (this flight took place in Gloucester), and so when it entered Auto mode the UAV attempted to fly for Aberystwyth.  The UAV seemed to stick at a 45 degree angle when attempting to flick, which is the maximum angle that the UAV would use when trying to move.  Thankfully as this took place on the ground, it was easy to restrain.  As the UAV seems capable of arming in Auto mode, perhaps I could just create a flight plan for the next Gloucester test and have the UAV fly it autonomously.