Is AutoTune safe on a 20 kg aircraft?

The question

You have a 20 kg aircraft on 29-inch props. It flies, more or less. The tune came from somewhere — a similar build, a forum post, a supplier's starting parameters — and you would like it to be better. Somebody suggests AutoTune.

It is a reasonable suggestion, and the question behind it is a serious one, because the failure mode is not a broken prop. Search the ArduPilot forums for autotune on large multirotors and you will find the same three stories repeated: the procedure aborts because it cannot determine a usable twitch size; the procedure completes and hands back a tune that is far too aggressive to fly; or the aircraft does not survive the procedure at all. ArduPilot's own documentation does not oversell it either — it warns that the process can produce gains that leave the vehicle unflyable, and that you should be ready to take back control.

So the honest answer is not yes and it is not no. It is: understand what the procedure actually does, because on your aircraft the thing it does is dangerous in a way it is not on a 250 g quad.

What AutoTune actually does

It is not magic, and it is not analysis. It is an experiment the aircraft runs on itself, in the air, at your expense.

The procedure commands deliberate, sharp attitude inputs — twitches — on one axis at a time. It measures how the aircraft responds to each one: how fast it starts rotating, how much it overshoots, whether it rings afterwards. Then it raises a gain, twitches again, and watches for the response to change character. It keeps doing that until it sees the onset of instability, and then it backs off to leave a margin.

Read that again, because everything else in this article follows from it.

The procedure works by deliberately approaching instability. That is not a side effect or a bug. That is the method. It cannot find where the limit is without going and touching the limit. On a 250 g aircraft that is an excellent bargain: the worst case is a hard landing, a snapped prop, an evening. On a 20 kg aircraft with 29-inch props, the thing the algorithm is deliberately walking toward is a crash you cannot afford, involving a machine with the kinetic energy of a falling motorcycle and a rotor disc you would not want to be near.

Nothing about the algorithm knows this. It has no concept of what your airframe costs.

Why it struggles on heavy aircraft

The reported failures are not bad luck. They fall out of the assumptions the method makes, and heavy aircraft break most of them.

It needs the aircraft to respond to a twitch. The measurement is the whole procedure — if the response cannot be characterised, nothing downstream is valid. A heavy aircraft with modest thrust-to-weight and enormous rotational inertia responds slowly and weakly. Push it, and it takes its time deciding to rotate. The response the algorithm gets back can be too small, too slow, or too smeared in time for it to extract anything from, and that is precisely what "Twitch Size Determination Failed" is telling you. It is not a mysterious error. It is the algorithm saying I asked your aircraft a question and I cannot understand the answer.

It needs headroom. A twitch is a sharp differential thrust change: some motors up, some down, hard, right now. If your aircraft hovers at high throttle — which large, heavily-loaded platforms very often do — there is not much "up" left. The motors saturate. What the algorithm then measures is not the response of an aircraft to a commanded twitch; it is the response of an aircraft to whatever fraction of that twitch the motors could actually deliver. It does not know the difference, and it will happily derive gains from a measurement that was never the measurement it thought it was making.

It assumes a reasonably rigid airframe. Large frames flex. Long arms flex a lot. When the algorithm twitches a flexy airframe, some of what the gyro reports is the aircraft rotating and some of it is the frame ringing — structural resonance, not rigid-body motion. The algorithm has no way to separate the two, so it tunes against the sum, and you end up with a tune that is partly a response to your frame's mechanical modes.

It needs calm air and space. A 20 kg aircraft executing deliberate, sharp attitude twitches needs a large, empty, still area with nothing and nobody in it. Wind corrupts the measurement, because the algorithm cannot tell a gust from a response. And if it departs, it departs with a great deal of energy and a large turning circle.

It needs a starting tune that already flies. This is the most commonly ignored precondition and the most important one. AutoTune refines; it does not rescue. It assumes it is starting from an aircraft that is stable and controllable, and that its job is to sharpen it. If you point it at an aircraft that is already marginal — oscillating, mushy, fighting itself — it will conduct its experiment on that aircraft, and the instability it goes looking for is much closer than it expects. People reach for autotune precisely when the aircraft flies badly. That is exactly backwards.

When it is reasonable

None of this is an argument that autotune is bad. It is a legitimate, widely-used, well-engineered tool, and on a well-built aircraft it does a better job than most pilots do by hand. It has tuned a very large number of large multirotors successfully.

It is reasonable when all of the following are true. Treat this as a checklist, not a mood:

• The aircraft already flies stably on a manual tune. You can hover it, translate it, stop it, and it holds attitude cleanly without ringing.
• The mechanics are sound: props balanced, arms stiff and tight, no cracked joints, CG where it should be, vibration levels known and low.
• There is thrust headroom — the aircraft is not hovering near the top of its motor authority.
• The frame is stiff enough that its structural modes are well clear of what the control loop operates in.
• Conditions are calm and you have altitude, open space, and nothing valuable downwind.
• You know how to abort, you have the switch in your hand, and you have rehearsed reaching for it.
• Logging is on.

If you cannot tick all of those, the answer to "should I run autotune" is not "run it carefully." It is "fix the thing that failed the checklist first."

How to de-risk it

Get a manually flyable tune first. This is the whole game. Start from a sane baseline for the size of aircraft — not a 5-inch freestyle tune, not somebody else's numbers — and work it by hand until it is genuinely stable. Tuning a heavy quad is its own discipline, and understanding what each term actually responds to is not optional if you intend to judge whether the machine's answer is sane.

Fix the mechanics before the software. Vibration, prop balance, frame stiffness, CG. Autotune will faithfully tune around a mechanical fault and hand you a tune that depends on that fault continuing to exist. Then you tighten the arm bolts, and the aircraft is no longer the aircraft the tune was written for.

One axis at a time, if the firmware allows it. ArduPilot's implementation lets you select which axes to tune. Do roll, land, look at the result, and only then decide whether to continue. A short procedure you can reason about beats a long one you have to sit through.

Altitude, space, calm air, and a hand on the switch. Give yourself vertical room to recover in, and horizontal room to be wrong in.

Know how you abort and what happens when you do — before you start. Not during. Which switch, what mode it drops back into, whether the original gains are restored or the partially-tuned ones stay live, and whether the aircraft will be flyable in that state. If you cannot answer those three questions from memory, you are not ready to arm.

Log everything. Every twitch, every gain step, the whole flight. When it goes wrong, the log is the only account of what happened that is not a memory.

Rehearse it somewhere that costs nothing. You cannot run ArduPilot's autotune in SITL Forge today. What you can do — and what actually matters here — is take a heavy airframe with your motors, your props and your mass, and go and find the edge of stability yourself, deliberately, repeatedly, at no cost. Wind the gains up until it starts to ring. Watch how a 20 kg aircraft diverges, how fast it goes from slightly twitchy to unrecoverable, and how much time you actually have between noticing and acting. That number is usually much smaller than people expect, and finding it out in the sim is considerably better than finding it out with the airframe.

The uncomfortable conclusion

AutoTune's entire method is to walk an aircraft toward instability and stop just before it gets there.

The heavier the aircraft, the less margin there is between "just before" and "too late" — because the aircraft is slower to respond, slower to stop, closer to its thrust limits, and more likely to be measured wrongly in the first place. And the heavier the aircraft, the more it costs to be on the wrong side of that line.

That is not an argument against autotune. It is an argument for having already seen what your aircraft does at the edge — with your own eyes, in a place where it does not matter — before you ask a machine to take it there for you.