Spontaneous Drone Take-off and Crash

Hi guys,

I have a quadcopter running Arducopter version 4.0.3 on a Pixhawk Cube Orange
The radio is a Microhard, RC input via Arduino pro mini between the Microhard and Pixhawk.

I had a strange anomaly recently in which the drone armed on its own within 5 seconds of power on. It then proceeded to take off and flip, and then continue running for roughly 10 seconds upside down before the motors stopped again.

There was no connection established with GCS during this entire event and the Pixhawk did not begin logging. I have LOG_DISARMED disabled (set to 0) so I do not have logs from before arming, but it seems strange that there was no log generated once the motors started.

This aircraft had been flying normally before this incident, with no changes made since the previous flight the day before. I have since been unable to replicate this event.

Can anyone help me get to the bottom of what might have caused this?

  1. Is the SDcard correctly recognized?
  2. Can you log to it?
  3. How are you making sure that the arduino can not arm the copter?

Yes, the SDcard is recognised and the Pixhawk logs to it successfully.

The arduino technically can send arming commands to the Pixhawk, but it only converts the data format sent from the Microhard to the correct format for the Pixhawk. The Microhard did not connect to the GCS so there should not have been anything being sent to the arduino.

Any command sent by the arduino must be interpreted by the Pixhawk regardless. Is it possible that in the few seconds between power on and the motor start, all pre-arm checks passed? (I have arming_check set to all)

It could still help if you posted the log.

There is no log from the crash.
Pre-arm logging was disabled, and the log appears to have not started on arm either.

I have attached a log of the Pixhawk boot from starting the system on the table after the crash in case that is what you mean.

Log File

@AGoodwin - unfortunately - there is not much to say here. The fact that nothing got logged, indicates that this was not an arming.
you did not use safetyswitch - but that’s in no way an explanation.
BRD_SAFETY_MASK is correctly configured too, so I am out of ideas.

did you trigger a motor test? that would bypass logging AFAIK

@amilcarlucas I did not deliberately trigger a motor test.
The only way I know how to do that is via a mission planner application, which was not connected.

Is there another way that a motor test could have been triggered?