Betaflight vs iNAV vs ArduPilot: which one, and why

The short version

If you fly by hand and the point of the aircraft is the flying — freestyle, racing, chase, anything you steer through — use Betaflight. It exists for exactly that, it is better at it than the other two, and the reasons it is better are structural rather than incidental.

If you want the aircraft to go somewhere on its own, on a hobby-grade airframe, and especially if it has wings — use iNAV. It is the sensible middle: real GPS navigation, waypoint missions, return-to-home, position and altitude hold, without asking you to learn a professional autopilot from scratch.

If the aircraft is doing a job — heavy lift, survey, inspection, research, anything where losing it is a serious event — use ArduPilot. It is the oldest, deepest and most capable of the three, and the price of that capability is that you will spend real time learning it. That price is worth paying when the aircraft is worth something.

Those are the answers. Everything below is the reasoning, and the honest caveats.

The three, side by side

Betaflight — what it is genuinely for, and where it stops

Betaflight descends from Baseflight and Cleanflight, and its entire evolution has been driven by one question: how faithfully and how quickly can the aircraft do what the pilot's thumbs just asked? Everything about it follows from that.

That focus has produced things nothing else matches. Its rate model — the way stick deflection maps to a commanded angular rate — is the most refined in the hobby, and it is the reason a well-tuned Betaflight quad feels connected in a way a navigation-first firmware usually does not. Its filtering stack (RPM filtering above all) is genuinely state of the art for coping with a noisy, vibrating, high-power airframe. And Blackbox, with the analysis tooling around it, is the best tuning feedback loop available anywhere in small aircraft. If you want to understand a PID controller, Betaflight plus a Blackbox log is the place to learn.

Where it stops is autonomy, and here you should be precise rather than dismissive. It is not true that Betaflight has no navigation: modern versions ship GPS Rescue, which will bring an aircraft home on a lost link, and a basic position-hold capability. Those features work, and on a freestyle quad they are worth having.

But they are a safety net, not a mission system. There is no waypoint planner, no route logic, no autoland, no state estimator built around the assumption that the aircraft must know exactly where it is at all times. Betaflight's design centre is a pilot with a link. Take the pilot away and it is doing its best, not doing its job.

iNAV — what it adds, and what it costs you

iNAV forked from Cleanflight and went in the other direction: it kept the manual flight feel broadly familiar, then built a real navigation stack on top. Waypoint missions, return-to-home, altitude and position hold, autolaunch and autoland, navigation-aware failsafe. It is the firmware for someone who wants the aircraft to go and do something without signing up for a professional autopilot.

Calling it "Betaflight with GPS" is unfair and misses the point. The navigation layer is substantial, it is where the project's effort goes, and it is particularly strong on fixed wing — a domain Betaflight does not seriously address at all. If you are flying a wing or a plane and you want it to hold altitude, fly a route, and come back, iNAV is the obvious and correct answer, and it is very good at it.

What it costs you is on both flanks. Against Betaflight: a multirotor tune in iNAV generally will not feel quite as sharp in the hands as an equivalent Betaflight tune, because the last five percent of stick feel is not the project's obsession. Against ArduPilot: the estimation and failsafe machinery is simpler, the parameter surface is shallower, and the ecosystem around it — ground stations, logging, commercial support, redundancy options — is thinner. That simplicity is exactly why people choose it; it is not free.

ArduPilot — what it adds, and what it costs you

ArduPilot is the oldest of the three by a wide margin, and it was never a hobby-FPV project. It is a general-purpose autopilot: the same codebase flies multirotors, fixed wings, VTOLs, ground rovers and submarines, and it is used commercially, industrially and in research.

What that buys you is depth of a different kind. A proper Extended Kalman Filter fusing GPS, IMU, baro, magnetometer, rangefinder and optical flow into a single, monitored state estimate — with the machinery to notice when a sensor is lying and reject it. Failsafe logic with real branching, not a single fallback. Mission plans with conditional behaviour. Geofences. Terrain following. Sensor and even flight-controller redundancy. MAVLink as a first-class control and telemetry protocol, and mature ground stations — Mission Planner, QGroundControl — to drive it.

The cost is that all of this is in front of you. ArduPilot has thousands of parameters, and while the defaults are sane and the autotune is good, the mental model you need before you can safely debug it is much larger than the other two. The documentation is excellent and reads like an aviation reference manual, because that is what it is.

And it is not, contrary to the folklore, unusable for FPV. People fly it manually, in acro, and enjoy it. It is simply not optimised for that last increment of stick feel, and you would be taking on a great deal of complexity to get something Betaflight hands you on day one.

How to choose

Do not start from what you already know. Start from what the aircraft is for.

1. Is the point of this aircraft the act of flying it? Freestyle, racing, chasing, cinematic manual work. → Betaflight. Stop here. Everything else is a distraction.
2. Is the point that it goes somewhere, on a hobby-grade airframe? Long range, mapping-ish flights, a wing that should come home on its own. → iNAV. Especially if it has wings.
3. Is the aircraft doing a job for somebody, or is it heavy, or is losing it a serious event? Heavy lift, survey, inspection, research, commercial operation, anything with a payload or a customer. → ArduPilot.

And be honest about the gradient hiding in that list: weight and money push you rightwards. A 250 g quad that costs €150 can be flown empirically — you learn by crashing, and it is cheap. A 5 kg airframe carrying something cannot. As the airframe gets heavier, the consequences of a bad state estimate or a naive failsafe stop being annoying and start being dangerous, and you begin wanting the firmware that has thought hardest about what happens when things go wrong. That is ArduPilot, and it is the honest reason serious heavy platforms end up there even when the pilot started in Betaflight and loved it.

What they all share

It is worth saying plainly, because the tribalism obscures it: underneath, all three are cascaded PID controllers. An inner loop tracks angular rate from the gyro at high frequency; an outer loop — your sticks in acro, an attitude controller in angle mode, a position controller in a navigation mode — feeds it a rate setpoint. Add filtering, because gyros are noisy and D-terms amplify noise. Add mixing, because you have four motors and three axes plus thrust.

That is every one of them. What differs is what sits outside the rate loop and how much of it there is. Which means the intuition you build in one — why D-term oscillation heats motors, why filtering costs you phase delay, why a heavy airframe needs different gains than a light one — transfers to all three. You are not starting over. You are adding layers.

Try them, rather than reading about them

All three run in SITL. Betaflight, iNAV and ArduPilot each ship a build target that runs the real firmware as a program on your PC, closing the control loop against a simulator instead of a real airframe.

This is not a small detail. It means the question at the top of this article is empirically answerable, for free. You can fly the same aircraft under two firmwares, in the same conditions, with the same sticks — feel the difference in the rate response, set up a waypoint mission and see how much configuration it actually took, deliberately trigger a failsafe and watch what each one decides to do. Then choose with an opinion of your own rather than someone else's.

The hardest part of choosing a firmware is that the cost of being wrong is normally a rebuild, a reflash, and a weekend. In SITL it is nothing. Take advantage of that.