Why ArduPilot Drones Flip on Takeoff (and What the Log Tells You)

TL;DR: A drone that flips on takeoff is one of the loudest configuration symptoms in ArduPilot. The cause is almost never the autopilot — it’s the firmware mixing motor commands for the wrong frame, the wrong motor order, or with one rotor turning the wrong direction. The log signature is consistent: a clean arm, throttle climbs, the airframe tips toward one corner before any pilot input could explain it. Plot RCOU.C1–C4 against ATT.DesRoll and ATT.DesPitch for the first 2 seconds, check FRAME_CLASS and FRAME_TYPE against your physical airframe, and verify motor direction with the Mission Planner motor test — the answer is almost always one of those three checks.

What ArduPilot actually does at takeoff

When you push throttle above the arming threshold, the autopilot in Stabilise or AltHold spools all motors up to the configured idle, then increases throttle on every motor proportionally to your input. The mixing — how individual motor commands are calculated from the desired roll, pitch, yaw, and throttle — depends entirely on FRAME_CLASS (Copter, Hex, Octo, etc.) and FRAME_TYPE (X, Plus, V, H, etc.).

If either of those parameters is wrong for your physical airframe, the autopilot will command the wrong motors to spin faster than the others for any given desired attitude. At takeoff, when the autopilot is trying to hold neutral attitude, the wrong mixing produces a consistent roll or pitch that the controller can’t cancel because every correction makes it worse.

The log signature of a takeoff flip

Open the log and zoom into the two seconds around the arm-to-flip window. The pattern:

• RCOU.C1–C4 climb together at the start (motors spool up).
• One motor (or one pair) climbs faster than the others — the wrong mixing producing a corner-up torque.
• ATT.Roll or ATT.Pitch begin to diverge from ATT.DesRoll / ATT.DesPitch within ~200 ms of throttle climb.
• The autopilot tries to compensate by saturating the opposite corner’s motor — RCOU shows one channel at SERVOn_MAX while another sits at SERVOn_MIN.
• The airframe rolls past the angle the controller can recover from; ERR Subsys=12 ECode=2 (CRASH_CHECK_LOSS_OF_CONTROL) fires and the autopilot disarms.

The three things to check

1. FRAME_CLASS. 1 = Quad, 2 = Hex, 3 = Octo, 4 = Y6, 5 = Heli, 6 = Tri, 7 = OctoQuad, 8 = Heli_Dual, 12 = DodecaHexa, etc. Match this against the physical motor count and arrangement.
2. FRAME_TYPE. 0 = Plus, 1 = X, 2 = V, 3 = H, 4 = V-Tail, 5 = A-Tail, etc. This is the mistake we see most often — FRAME_TYPE = 0 (Plus) on an X-configuration quad, or vice versa.
3. Motor direction. Each motor has a defined spin direction based on its position in the frame. Mission Planner’s motor test (Setup → Mandatory Hardware → Motor Test) spins motors A, B, C, D one at a time. The labelled motor must spin in the labelled direction; if any are reversed, swap two of three motor wires for that ESC.

Reading it in Mission Planner

Plot RCOU.C1–C4 alongside ATT.Roll, ATT.DesRoll, ATT.Pitch, ATT.DesPitch:

• If RCOU shows the autopilot trying to compensate (one channel saturating high while another saturates low) before any pilot input could explain it, you have a mixing problem — frame configuration is the suspect.
• If the same motor channel always tries to do the opposite of what the autopilot wants (the controller pushes throttle up, that motor responds late or weakly), suspect motor direction or ESC calibration.

Confirming it in MAVExplorer

MAV> graph RCOU.C1 RCOU.C2 RCOU.C3 RCOU.C4
MAV> graph ATT.DesRoll ATT.Roll ATT.DesPitch ATT.Pitch
MAV> param show FRAME_CLASS FRAME_TYPE

The parameter dump tells you what the firmware was actually configured for. Match it against your physical wiring before re-arming.

Confirming on the bench — the only fix you should trust

Before another takeoff attempt:

1. Remove the propellers.
2. Connect to Mission Planner.
3. Setup → Mandatory Hardware → Motor Test.
4. Run each motor (A, B, C, D, …) one at a time at low throttle. The Mission Planner display tells you which motor letter it’s spinning; the physical motor must match the diagram for your frame type, and it must spin in the labelled direction.
5. If a motor spins the wrong way: swap any two of the three motor wires going to that ESC.
6. If the wrong physical motor spins for "Motor A": your motor wiring order to the autopilot is wrong; identify the correct order from the ArduPilot frame diagram.

Re-arm only after every motor passes both the identity and the direction test.

When this isn’t a frame mixing problem

• One dead ESC. The motor doesn’t respond at all; the autopilot can’t roll because the missing thrust isn’t there to compensate. RCOU.Cn for that motor will climb but the airframe ignores it. See our ESC desync post.
• One reversed prop. Right physical motor, right direction, wrong propeller shape. The CW prop on a CCW motor (or vice versa) produces negative thrust at idle. The flip happens immediately when you advance throttle.
• Wrong rotor direction for a coaxial / Y6 frame. Y6 and similar configurations have upper and lower rotors that must turn opposite directions. Mixing them up produces violent yaw, not a clean flip.
• Untuned PIDs on a heavy build. Default rate gains too low for a heavy or large airframe can produce a slow lean that looks like a flip in the first second. RCOU won’t show the saturating-corner pattern; the climb is more gradual.

What to do before the next attempt

1. Verify FRAME_CLASS and FRAME_TYPE against the official ArduPilot frame diagrams.
2. Run the Mission Planner motor test with propellers removed.
3. Visually verify CW vs CCW propellers match the motor diagram.
4. If the build is new, do a tethered hover at ankle height first — cheap insurance.
5. If still flipping, log a hover-attempt and re-read this post.

When LogHat helps — and when it doesn’t

LogHat flags the saturating-corner RCOU pattern in the takeoff window, surfaces the FRAME_CLASS and FRAME_TYPE values at arm time, and the Vector AI cross-references against known mis-configurations. What we can’t do is verify your physical wiring — the motor test on the bench is the only way to confirm the firmware’s motor A is your physical motor A.