Crash after takeoff,mission seems to restart mid-air


I need help figuring out what happened during this mission.(KDE Crash - Google Drive)
It seems the QUAD wanted to do another Takeoff just after it was midair heading to the first waypoint. Sadly if fell to the ground like a rock.
I had multiple auto missions executed with success with this drone before.

I attached the telemetry log as well.
Any input is highly appreciated.

Pixhawk 4 running Arducopter 4.2.0.
Quadcopter, 5.5kg, 6s, 17 inch propellers.
KDE motors and ESC

Thank you, all the best!


Are you sure that was not an failsafe RTL?

From what i could read in the log, there was no indication of a failsafe. Battery voltage was normal, amp draw as well.
The motors just stopped spinning after reaching desired altitude. In the telemetry log i could see for a brief moment while the QUAD was tumbling down “Mission 1 Takeoff” message and the status that it was disarmed.

Is there any other way to check if the drone was disarmed forcefully via mission planner?

Thank you,


The autopilot was definitely disarmed mid-flight. You can see the climb to altitude in green and then the copter is disarmed. What is interesting are the mission related messages.


I’m not sure what your mission looked like but perhaps the issue lies in how the waypoints were configured. There is a message indicating 2 waypoints but I think you had more than 2 waypoints defined for this mission. Perhaps the mission was corrupt and the upload (partially) failed?

Something is very wrong can you share the waypoint file so i can try it in the simulator, the way its going from takeoff to waypoint back to takeoff is very unusual.

im wondering is it something that mission planner has created and uploaded by mistake or are you getting somethiung corruption on your memory card.

I have uploaded the mission in Google Drive.
I tried reproducing this scenario (disarming midflight then engaging mission shortly after) in the simulator, but no success.
This same mission was successful on other attempts with different hardware.
Given the fact that I wasn’t present at the location when the crash occurred, it would be helpful to know if there are any other logs that mission planner records, besides telemetry. I am suspicious of human error on this one, but before I can take any conclusions I need to do more digging.

Thank you, all the best!


I connected the flight controller to my Pc and did a “read” command to check if the mission uploaded to the card coincides with the one from the PC.
Everything seems to be ok.
Attached are some snips with the mission from the FC.

how do you control the vehicle, i dont see any RC inputs?

FC is connected to a raspberry pi that has internet from a small factor teltonika router 4g.

Drone flies only in auto mode.


Is there an LTE log of all MAVlink commands that have been sent from the raspberry pi to the AP? It may be worth checking no DISARM command has come through the raspberry pi.

1 Like

thats my thought since it wasn’t a rouge RC input.

Good point. The interface of the RPI is not accessible for the operator, but I will look into that.
I am also waiting for CCTV footage from where the operator was standing, maybe I can see something on the screen. Although, quality will be awful…

There may be a specific (AP) reason for the midflight DISARM but I think the forum would be full of reports if there was something obvious wrong related to AUTO & missions.

It may be worthwhile to keep in mind the AP could have acted on a DISARM command that came from the RPI via LTE…

1 Like

Here is the messages from MavExplorer
2022-07-20 15:26:11.796 ArduCopter V4.2.0 (67892169)
2022-07-20 15:26:11.796 ChibiOS: 93e6e03d
2022-07-20 15:26:11.796 Pixhawk4-bdsh 003C0020 32375118 3236343
2022-07-20 15:26:11.796 Param space used: 1049/5376
2022-07-20 15:26:11.796 RC Protocol: None
2022-07-20 15:26:11.796 New mission
2022-07-20 15:26:11.802 New rally
2022-07-20 15:26:11.802 Frame: QUAD/X
2022-07-20 15:26:11.802 GPS 1: detected as u-blox at 230400 baud
2022-07-20 15:26:11.802 u-blox 1 HW: 00080000 SW: EXT CORE 3.01 (107900)
2022-07-20 15:26:13.741 Event: DATA_MOTORS_INTERLOCK_ENABLED
2022-07-20 15:26:15.975 Event: DATA_AUTO_ARMED
2022-07-20 15:26:15.975 Mission: 1 Takeoff
2022-07-20 15:26:15.977 Mission: 1 Takeoff
2022-07-20 15:26:16.010 Event: DATA_NOT_LANDED
2022-07-20 15:26:18.559 EKF3 IMU0 MAG0 in-flight yaw alignment complete
2022-07-20 15:26:18.560 Event: DATA_EKF_YAW_RESET
2022-07-20 15:26:18.562 EKF3 IMU1 MAG0 in-flight yaw alignment complete
2022-07-20 15:26:39.363 Mission: 2 WP
2022-07-20 15:26:40.298 Event: DATA_DISARMED
2022-07-20 15:26:40.298 Event: DATA_LAND_COMPLETE
2022-07-20 15:26:40.298 Event: DATA_LAND_COMPLETE_MAYBE
2022-07-20 15:26:40.299 Event: DATA_MOTORS_INTERLOCK_DISABLED
2022-07-20 15:26:40.300 Mission: 1 Takeoff
2022-07-20 15:26:54.478 PreArm: EKF3 Roll/Pitch inconsistent by 11 deg
2022-07-20 15:26:54.478 PreArm: Compasses inconsistent
2022-07-20 15:27:24.478 PreArm: Compasses inconsistent
2022-07-20 15:27:54.478 PreArm: Compasses inconsistent
2022-07-20 15:28:24.478 PreArm: Compasses inconsistent
2022-07-20 15:28:54.478 PreArm: Compasses inconsistent
2022-07-20 15:29:24.478 PreArm: Compasses inconsistent

Thank you all for your reply.

Upon checking CCTV footage there is clear proof that the operator dismissed two prompts on screen before the quad started to tumble.

The time of the dismissed prompts coincides with the disarm time from the logs.

Now for the hard part, understanding why the operator did that :slight_smile:

Is there any way to modify the layout of the buttons accessible in the “actions” tab?

Thank you,


Do you know what these two prompts are that were dismissed by the operator?

I cannot distinguish the text or see the cursor, but they look similar to the prompts you get when you try to disarm the quad while it’s airborne.

(A small rectangle followed by a slightly larger one in the middle of the screen)

I can see the horizon spinning right after the second prompt was dismissed.

If that is the case it should be logged in the (LTE) raspberry pi MAVlink command stream that feeds commands to the AP…if you can get hold of that log it will give you a pretty conclusive answer.

1 Like

the first prompt and displaying takeoff again in the log would be consistent with hitting the restart mission button on mission planner just above the disarm button.

1 Like

In my attempt to reproduce the crash in the simulator, ‘restart mission’ does not disarm the drone.

Will check RPI logs and then have a talk with the operator to hear his side of the story.