Lumipad ← Back to homepage
Library · Reference

Firmware, over time.

Once the drone is configured and flying, firmware becomes a long-running concern. New INAV releases ship every few months. ESC firmware quietly diverges across the fleet. A partner org's twelve drones drift to twelve different versions. A bootloader corrupts. This page is what you read after fc-setup.html — the management layer for everything firmware-related across the drone's working life.

Version 1.0 · Updated 05·2026 Author: Lumipad Engineering License: CC-BY-SA-4.0 Languages: EN
4
Distinct firmware layers
~6 mo
Typical update cadence
3
ESC firmware ecosystems
95%
"Bricked" FCs that recover
How to read this page

Firmware is several things, not one.

Most alumni use "firmware" as a single word, but a working drone runs at least four distinct pieces of software that all need management: the FC firmware (INAV / BetaFlight / ArduPilot), the ESC firmware (BLHeli_S / BLHeli_32 / BlueJay), the bootloaders that allow re-flashing, and the configurator software that talks to all of them. Each has its own versioning, its own update cadence, its own failure modes.

This page is structured as a long-form reference covering all four layers. Read top to bottom your first time through to build a coherent mental model; return via the side TOC for specific concerns. Sections 5 and 6 are written for partner orgs running fleets and alumni building custom firmware respectively — most readers can skim or skip them.

Section 01 Mental model before any keystrokes

The firmware landscape.

A working drone runs four distinct kinds of software. Most alumni discover this only when one of them needs updating and they realise they don't know which "firmware" the question refers to. This section maps the whole landscape so the rest of the page makes sense.

The four firmware-like things in a typical Lumipad cohort drone:

Layer What it is Examples Updates how often
FC
Flight controller firmware The main brain. Runs the flight code: gyro processing, motor mixing, mode logic, OSD, mission execution.
INAV, BetaFlight, ArduPilot
Major versions every 12-18 months; minor patches every 2-3 months
ESC
ESC firmware Runs on each Electronic Speed Controller. Handles the actual motor commutation, current limiting, telemetry. Receives DSHOT commands from the FC.
BLHeli_S, BLHeli_32, BlueJay
BlueJay updates monthly during active development; BLHeli_S is essentially frozen; BLHeli_32 updates a few times per year
BL
Bootloader Tiny low-level code that runs first on power-up. Decides whether to launch the FC firmware or enter DFU mode for re-flashing. Effectively read-only in normal use.
STM32 native bootloader (built into the chip), or custom bootloaders shipped with some FCs
Almost never. Some FCs ship with old bootloaders that need updating once.
CFG
Configurator software Runs on your laptop, not the drone. The GUI you use to flash and configure the FC and ESCs. Each FC firmware has its own configurator.
INAV Configurator, BetaFlight Configurator, BLHeli Configurator, Mission Planner
Versioned with the FC firmware — INAV Configurator 7.x for INAV firmware 7.x

The configurator and the firmware versions need to match, especially across major versions. INAV Configurator 7.x cannot reliably configure INAV firmware 8.x; INAV Configurator 6.x cannot configure 7.x. Cross-version mismatch is a common source of "settings keep reverting" or "can't connect" errors. When you update FC firmware, update the configurator on the same laptop at the same time.

Bootloaders are the most stable layer — most alumni go years without touching them. The exception: a few cohort default FCs (the SpeedyBee F405 V4 in particular) shipped with an early bootloader that doesn't support some newer DFU operations. If your FC dates from before mid-2024 and you've never updated the bootloader, see Section 04.

Section 02 Decision-making, not procedure

When to update, when not.

The honest answer to "should I update?" is most often "no, not yet." A drone running a stable INAV 7.1.2 doesn't need to become a drone running INAV 7.1.3 unless 7.1.3 fixes something you actually care about. The "if it ain't broke" principle is doing real work here. This section is about the small number of cases where you should update, and the larger number where you shouldn't.

Three categories of update, ranked by urgency:

  • Security or safety patches — rare in this ecosystem (most flight controller firmware doesn't connect to networks), but when they happen, update promptly. Recent example: an INAV 7.1.2 bug that caused failsafe to misfire on certain receivers; 7.1.3 fixed it. Worth updating.
  • Bug fixes affecting your specific build — read the changelog. If the fix doesn't apply to your FC, your sensors, or your typical missions, you don't need it. Most "fixes" don't affect cohort default builds.
  • New features — the most over-applied reason to update. New features mostly serve specific edge cases; for survey work, the existing feature set is mature and complete. Don't update for features you won't use.

The cohort recommendation: track the latest stable major version, but lag one or two minor versions behind. As of mid-2026, INAV 7.x is the stable major; we're running 7.1.2 across most cohort drones (skipping 7.1.0 entirely because it had known issues, and not yet adopting 7.1.3 because 7.1.2 works fine for our use cases). When 8.0 stable ships and matures for ~6 months, we'll plan a coordinated migration.

Reading a changelog usefully

Most firmware projects publish a changelog with each release. Reading them quickly without getting lost:

  1. Search for your FC's target name (e.g. SPEEDYBEEF405V4) in the changelog. Anything mentioning your specific FC matters more than generic changes.
  2. Search for keywords from your config: "failsafe", "RTH", your receiver protocol, your GPS module. If a change touches one of these, read the entry carefully.
  3. Skim the rest. Most entries are racing-pilot tuning improvements, FPV freestyle features, or specific FCs that aren't yours. None of this matters for survey work.

If after this scan you find nothing relevant, the update isn't required. Note the version in your logbook for awareness, and revisit at the next update.

Update procedure when you do decide to update — the same as fc-setup.html Section 03's flash procedure, with three additions:

  1. Save your current config first. CLI: diff all, copy the entire output. This is non-negotiable. Updates occasionally break configs in ways the configurator's "preserve settings" option doesn't catch.
  2. Update the configurator on your laptop at the same time. Match major versions: configurator 7.x for firmware 7.x.
  3. Test on the bench before flying. After updating: full Phase A pre-arm checklist (fc-setup.html Section 10). Most updates that go wrong reveal themselves during this check.

What to do if an update breaks something: revert. Roll back to the previous version using the same flash procedure. Save the broken version's config dump first if possible — the firmware project's bug trackers benefit from real reproduction cases. Then re-flash the previous stable version and restore your saved config.

Section 03 Often overlooked; sometimes worth attention

ESC firmware.

The ESC firmware is the layer most alumni never touch. Default settings work for default builds, and fc-setup.html covers the basics. This section goes deeper: which ESC firmware ecosystem you have, what the trade-offs are, and the small number of cases where ESC firmware tuning produces noticeable improvement.

Three ESC firmware ecosystems are relevant in 2026:

  • BLHeli_S — the older, simpler ecosystem. Runs on cheaper EFM8-based ESCs (Bouk-class chips). Limited features, fixed-function. Effectively frozen — no significant updates since 2022. Most ESCs in cohort default builds run BLHeli_S.
  • BLHeli_32 — the modern ecosystem with active development. Runs on ARM-based ESCs. More features (RPM telemetry, advanced filtering, motor parameter tuning). Closed source, with some controversy in the FPV community over licensing.
  • BlueJay — the open-source alternative to BLHeli_S, running on the same hardware. Active development, RPM filtering support, mostly drop-in replacement for BLHeli_S. Increasingly the cohort recommendation for new builds.

For Lumipad cohort defaults, the recommendation has shifted over time:

Build Default ESC Recommended firmware Why
5"
SpeedyBee BLS 50A 4-in-1 EFM8-based, ships with BLHeli_S 16.7.
BlueJay (replace BLHeli_S)
RPM filtering improves PID tuning headroom; fully open-source; same hardware so the swap is firmware-only.
7"
iFlight BLITZ E60S 4-in-1 ARM-based, ships with BLHeli_32.
BLHeli_32 (keep stock)
BlueJay doesn't run on this hardware; BLHeli_32 is mature and well-supported. Don't switch unless you have a specific reason.
10"
T-Motor Flame 60A individual ARM-based, ships with BLHeli_32 or AM32 depending on batch.
Stock firmware (whatever it ships with)
10" individual ESCs from premium brands ship with well-tuned firmware. Re-flashing is rarely an improvement.

BlueJay flash procedure (when replacing BLHeli_S):

  1. Open BLHeli Configurator (or BLHeliSuite32 — works for BlueJay too despite the name).
  2. Connect to FC via USB; click "Read Setup". The configurator detects the ESCs through the FC.
  3. For each ESC: click "Flash BlueJay". Select the appropriate target (matching the ESC's MCU). Wait for the flash to complete.
  4. After all four ESCs are flashed, "Read Setup" again to verify all four show BlueJay firmware.
  5. Configure: enable RPM filtering at the FC level (INAV: Configuration tab → "Bidirectional DSHOT" must be enabled).

Settings worth tuning in BLHeli_32 / BlueJay beyond the cohort defaults:

  • Bidirectional DSHOT — must be ON for RPM filtering. Significant noise improvement in flight.
  • Demag compensation — set to "High" for builds with smaller props or higher-KV motors. Prevents desync at low throttle.
  • Beep volume — adjust to a level you can hear in the field. Some defaults are inaudible outdoors.
  • Beacon delay — how long after motor stop the beacon starts (for finding crashed drones). Default 60s is fine; 30s is more aggressive.

Most other ESC parameters can stay default. Tuning beyond this list is racing-pilot territory and rarely benefits survey work.

Section 04 Read on bootloader updates; reference for recoveries

Bootloaders & recovery.

Bootloaders are the unglamorous layer that lets everything else recover from mistakes. Most alumni never deal with the bootloader directly — DFU mode just works. The exceptions are rare but real: an FC that won't enter DFU at all, a bootloader that itself has a bug, or a corruption that survives normal recovery.

The bootloader is a small piece of code burned into the FC's microcontroller at the factory. On power-on, the bootloader runs first; it checks whether to launch the main FC firmware or enter DFU mode (depending on whether a button is held, a pad is shorted, or a flag is set). Once it decides, it hands control to the FC firmware and gets out of the way.

For most alumni, the bootloader is invisible. The only reason to think about it is when something goes wrong with re-flashing: if DFU mode itself isn't working, the bootloader is the suspect.

Three bootloader-related problems and their solutions:

Symptom Likely cause Solution Difficulty
A
FC won't enter DFU mode Holding the bootloader button + USB plug doesn't put the FC in DFU. OS shows nothing.
USB cable is charge-only (try another); BOOT button on FC is broken (use solder pads instead); rare bootloader bug requiring SWD reflash.
Easy to medium. Try cable swap first. Then try shorting BOOT pads with tweezers. Last resort: SWD programmer (~₱1,500).
B
FC enters DFU but flash always fails DFU mode visible to OS, configurator detects, but flashing errors out partway through.
Marginal USB power (low-quality laptop USB port, USB hub); flash file corrupted; old bootloader that doesn't support newer flash sizes.
Medium. Try direct USB to laptop (skip hubs). Re-download the firmware file. If you have a SpeedyBee F405 V4 from before mid-2024, the bootloader may need updating — see SpeedyBee's manufacturer documentation for the procedure.
C
FC briefly works after flash, then bricks again Configurator connects, settings look right, but on next power-cycle the FC behaves as if it was never flashed. Or panics on first arm.
Power supply issue (FC voltage drops below threshold mid-flash); a hardware fault in the FC itself; in rare cases, a corrupted EEPROM region.
Hard. Try flashing with FC powered from battery (4S/6S through ESCs) rather than USB-only — gives more stable power. If still failing: the FC has a hardware fault and needs replacement.

SWD programmer recovery (last resort)

For FCs that won't enter DFU mode at all and have a hardware-level issue with the BOOT button or related circuitry, an SWD (Serial Wire Debug) programmer can flash the chip directly via its debug pads. This is genuinely a last resort:

  1. You need an SWD programmer. ST-Link V2 clones are ~₱1,500 online.
  2. You need to identify and access the SWD pads on the FC PCB. Most modern FCs have these as testpoints — small unmarked pads near the main MCU. Datasheet required.
  3. You need software (STM32CubeProgrammer, or open-source alternatives) and the correct firmware .elf or .hex file.
  4. Solder thin wires to the SWD pads (or use spring pogo pins). Connect to the programmer. Flash.

Cohort instructors typically don't recommend this for individual alumni — at this level of difficulty, replacing the FC (₱2,200) is usually faster than recovering it. SWD recovery makes sense for partner orgs with multiple drones where one FC failure shouldn't cost the whole drone. If you're at this point, ask in alumni Slack first; someone has probably faced your specific failure mode.

Updating a bootloader itself is a separate operation from updating FC firmware. Most alumni will never need to do this. The exception, mentioned above, is some early SpeedyBee F405 V4 boards from before mid-2024 that shipped with a bootloader missing newer DFU features. If you have such a board:

  1. Identify the version. The configurator's MCU info (or boot screen) shows the bootloader version. Below 1.4 is the old version.
  2. Download the bootloader update from SpeedyBee's product page (a small .bin file).
  3. Flash via STM32CubeProgrammer using SWD (same procedure as above), or use SpeedyBee's official update tool if available.
  4. Verify by checking the bootloader version after update.

This is a one-time operation. Once updated, the bootloader will support all current and near-future DFU operations.

Section 05 For partner orgs and alumni with 3+ drones

Fleet firmware management.

Once you have more than two or three drones, firmware drift becomes a real operational concern. Drone A is on INAV 7.0.4; Drone B is on 7.1.2; Drone C is on a custom build the previous owner left behind. Configurations that worked on one don't work on another. This section is about keeping a fleet coherent.

Three problems show up in fleets that don't show up with single drones:

  • Version drift — different drones run different firmware. Switching pilots between drones means re-learning quirks. Configurations don't port cleanly. Diagnostics become harder.
  • Update logistics — updating twelve drones in coordinated fashion is meaningfully different from updating one. Power supplies, cables, scheduling, regression testing.
  • Knowledge silos — when only one person has updated firmware on the fleet, that person becomes a bottleneck. If they leave, the next firmware update becomes a project.

The Lumipad fleet management approach has three components:

Component What it covers How it works Effort
1
Version logbook One spreadsheet per fleet, tracking each drone's current FC firmware, ESC firmware, configurator version, and date last updated.
Updated whenever any firmware change happens. Lives in the fleet operator's shared drive. Reviewed monthly.
Low. ~5 min per update event.
2
Coordinated update windows All drones in the fleet update together on a planned date — typically once or twice a year. Between windows, the fleet runs the same versions across all drones.
2-3 day work session: backup all configs, flash all drones to new version, test each, restore configs. Roll back any that misbehave.
Medium. ~30 min per drone for full update + test cycle.
3
Pinned cohort default config One canonical INAV CLI dump per cohort default build (5A, 7A, 10A). Stored in version control. Used as the baseline when restoring drones.
Updated when the canonical config changes (new prop, new battery, refined PIDs). Drones across the fleet pull from this single source.
Low. Maintained by Lumipad engineering; downloaded by partner orgs.

The version logbook is the most important of the three. The discipline of writing down what changed when, on which drone, prevents most fleet management problems before they start. The downloadable spreadsheet template (linked at the top of this page) provides the structure; partner orgs adapt it to their context.

Coordinated update windows are easier to manage than rolling updates because the entire fleet stays consistent. Rolling updates create a window where some drones are on the new version and others aren't, and that's exactly when configurator-version mismatches cause problems. Pick a date, do them all, test each, then return the fleet to service.

Don't update right before a major mission. The Lumipad team has a hard rule: no firmware changes within two weeks of a scheduled survey. Updates introduce a small but real risk of unexpected behaviour; that risk is acceptable on a low-stakes test flight, not on a paying client mission. Schedule updates during quieter periods.

Section 06 Advanced; skip on first read

Custom firmware.

Building INAV (or BetaFlight, or BlueJay) from source code with custom modifications. Used by alumni doing research-grade work, partner orgs with specific hardware that needs custom support, or contributors fixing bugs upstream. Most readers will never need this; included for completeness.

Reasons to build firmware from source:

  • Custom target support — your FC isn't in the official supported list, but the underlying MCU is supported. You can write a custom target file and compile firmware for it.
  • Specific feature combinations — INAV's official builds disable some features by default to fit in flash memory. Building from source lets you enable just the features you need.
  • Bug fixes upstream — found a bug, fixed it, want to flash the fix before it ships in a stable release. Building from source is how.
  • Research applications — adding custom flight modes, sensor integrations, or telemetry channels for academic or research work.

Reasons NOT to build from source:

  • "Latest features" — if the feature you want is in master but not in stable, wait for stable. Master is unstable for production use.
  • "Better performance" — custom-tuned firmware is rarely meaningfully faster than stock for survey work. Tuning happens at the configuration level, not the firmware level.
  • "More secure" — these are open-source projects without significant attack surface. Building from source doesn't add security in any meaningful way.

The build environment for INAV (the cohort default firmware):

  1. Linux (Ubuntu 22.04 or similar; macOS works with extra setup; Windows works via WSL2). Cohort recommends Ubuntu.
  2. ARM cross-compiler toolchain. INAV's documentation lists exact version requirements; usually gcc-arm-none-eabi 10.x or 11.x.
  3. Make and Python 3.x.
  4. About 2GB free disk space for the source tree and build artifacts.

The basic build commands (from the INAV repo root):

  1. git clone https://github.com/iNavFlight/inav.git — clone the source tree.
  2. cd inav
  3. git checkout 7.1.2 — switch to the stable tag you want as your baseline.
  4. make TARGET=SPEEDYBEEF405V4 — build firmware for the cohort default FC. The output is a .hex file in the obj/ directory.
  5. Flash the resulting .hex via the configurator's "Load Firmware (Local)" option, same as any other firmware flash.

Building from source is well-documented in each project's repository. The README and the developer documentation cover edge cases the above doesn't. Once the build environment is set up, recompiling is fast (~2-3 minutes for a clean build of INAV).

For alumni or partner orgs interested in contributing fixes back upstream, the INAV project has clear contribution guidelines. The community is welcoming. Most accepted contributions start as bug reports with reproduction cases (which alumni in the field are well-positioned to provide), then escalate to fixes once the contributor is comfortable with the codebase.

Numbers worth knowing

Six firmware reference numbers.

Quick reference for version cadences, recovery costs, and the few specific values that matter across firmware management decisions.

7.1.2
Cohort INAV version
Stable; one minor behind latest
2 wks
Update freeze before missions
Hard rule for paying client work
~30 min
Per-drone update + test
Plan fleet windows accordingly
₱1,500
SWD programmer (last resort)
For deep recoveries
₱2,200
FC replacement cost
Often faster than recovery
~2-3 min
Clean source build
INAV from clean tree
Real firmware scenarios

Four firmware decisions from alumni and partner orgs.

Concrete cases where firmware management decisions had to be made. Each is a real situation faced by Lumipad engineering or partner orgs in the past 12 months. The right answer is rarely "always update" or "never update" — it's specific to the context.

"INAV 7.1.3 just shipped. Should we update the cohort fleet?"

After a minor INAV release

Read the changelog. 7.1.3's notable change was a fix for receiver protocol timing affecting some FrSky receivers. Cohort uses ELRS, not FrSky — the fix doesn't apply to us. Don't update. Note 7.1.3 in the version logbook so we know we considered it; revisit when 7.1.4 ships or when something genuinely affects us. The "if it ain't broke" principle wins here.

"Partner org wants their twelve drones on the same firmware as ours."

Coordinated fleet management

Share the cohort default config dump and current version (INAV 7.1.2 + BlueJay on ESCs). Help them set up a coordinated update window — typically a 3-day work session covering backup, flash, test, and config restore for all twelve. Add their fleet to the version logbook templates we share. Maintaining version parity across our fleet and theirs makes troubleshooting and parts compatibility easier for everyone.

"I just bought a used drone. The previous owner had custom firmware."

Acquired a non-standard drone

Don't try to figure out what the previous owner did. Wipe and start fresh: flash stock cohort default firmware (current stable), restore the cohort default config dump, run the full Phase A pre-arm checklist. The drone is now indistinguishable from a freshly-built cohort drone. Custom firmware from unknown sources may have undocumented modifications, untested edge cases, or hidden bugs. Not worth investigating.

"My FC won't connect to the configurator anymore."

Recovery scenario

Walk down Section 04's symptom table. Try cable swap first (many "bricked" FCs are cable problems). Try shorting BOOT pads if the button doesn't work. If still stuck after 30 minutes: order a new FC and replace. SWD recovery is technically possible but rarely worth the time vs replacement. Save the bricked FC for a partner org that has SWD capability and might recover it as a learning exercise.

Frequently asked

Questions worth answering carefully.

What happens if I just never update firmware? +

Mostly nothing. A drone running INAV 6.1 from 2023 will continue to fly perfectly well in 2026. The firmware doesn't degrade. The flight modes work the same. The hardware doesn't care about year-over-year version drift.

Three things you'd lose by staying on old versions: (1) bug fixes — most don't affect cohort defaults, but rare ones might; (2) compatibility with newer accessories — a new GPS module, a new receiver protocol may require firmware support; (3) community support — when you ask in alumni Slack and you're three major versions behind, expect some friendly nudging.

The cohort recommendation: update once a year on average, in coordinated fashion. More often if security or safety patches ship; less often if everything is working and missions are running.

How do I know which firmware version my drone is currently on? +

Connect to the configurator. The connection summary at the top shows: firmware target name (e.g. SPEEDYBEEF405V4), firmware name and version (e.g. INAV 7.1.2), build date, and FC hardware ID. All four are useful identifiers.

For ESC firmware: from the configurator, open the BLHeli passthrough tab and click "Read Setup". Each ESC reports its firmware name and version (e.g. BLHeli_S 16.7 or BlueJay 0.21).

Document all of this in your fleet's version logbook. Even for single-drone owners, a one-line note saying "Drone A: INAV 7.1.2, BlueJay 0.21, last updated 2026-03-15" is extremely useful when something goes wrong six months later.

Can different ESCs in the same drone run different firmware versions? +

Technically yes; in practice, don't. ESCs are designed to be flashed as a group; the BLHeli passthrough tab flashes them in sequence, all to the same target. Mixed-firmware ESCs can produce subtle motor sync issues that are hard to diagnose.

The exception: if one ESC has been replaced after a crash, it ships with whatever stock firmware it came with. After replacing, do a passthrough flash to bring all four ESCs back to the same firmware version. Verify by reading setup after replacement.

What's the deal with BLHeli_32 being closed-source? Should I avoid it? +

BLHeli_32 is closed-source, which is unusual in the FPV ecosystem. The reason is historical (the maintainer chose not to open-source it for a mix of business and aesthetic reasons). The community has reacted in two ways: by maintaining BLHeli_S as long as possible, and by building open-source alternatives like BlueJay and AM32.

Practical consequences for cohort builds: BLHeli_32 still works fine and is well-supported. Updates are slower than BlueJay, but the firmware is mature. The 7" cohort default uses ESCs that run BLHeli_32 because the hardware is BLHeli_32-only.

For new builds where you have a choice: prefer BlueJay or AM32 for ideological openness; prefer BLHeli_32 for stability and maturity. Either is fine for cohort survey work. The performance differences are small enough that pilot skill, build quality, and configuration matter more.

Is it safe to update firmware between batteries during a flying day? +

No. Firmware updates carry a non-zero risk of breaking something subtly. Discovering that risk in the air is not the goal. Don't update during a flying session, especially not during a paying mission.

The Lumipad rule: firmware updates happen on bench days, not flying days. Two-week freeze before scheduled missions. Test thoroughly on the bench (Phase A pre-arm checklist) and on a low-stakes hover before resuming higher-stakes flying.

What about ArduPilot? Most of this page focuses on INAV. +

ArduPilot has its own ecosystem and the principles transfer but the specifics differ. ArduPilot uses Mission Planner (not INAV Configurator), parameter files (not CLI dumps), and a different release cadence. The "when to update" decision-making (Section 02) applies the same way; the procedure is just executed in ArduPilot's tooling.

For ArduPilot-specific firmware management, the project's own documentation at ardupilot.org is comprehensive and current. The Mission Planner has built-in firmware update tools that handle most of what alumni need. ArduPilot also has a stronger forum culture; questions about firmware get good answers there.

The cohort uses ArduPilot only for 10" research-grade builds. For most alumni, INAV-focused firmware management is what matters.

Should I be worried about firmware backdoors or supply chain attacks? +

For the threat models alumni typically face, no. The relevant projects (INAV, BetaFlight, BlueJay) are open-source, widely audited, and have no commercial incentive for malicious code. Releases are built reproducibly from public source; the binaries you flash match the source you can read.

For partner orgs working in sensitive contexts (research with proprietary data, government applications, etc.), the answer might shift. Building from source on trusted infrastructure (Section 06) gives you the strongest assurance about what's actually running. For most alumni, this is overkill — but it's worth knowing the option exists.

The realistic firmware risk isn't backdoors; it's bugs. A firmware bug that misfires failsafe is more likely than a firmware backdoor. Mitigate the realistic risk: stable versions, coordinated testing, version logbooks.

What if INAV stops being maintained? +

Possible long-term concern, not a current one. INAV has been in active development since 2015 and has a reasonably active maintainer pool. But every open-source project is one or two key maintainers away from stagnation, and the FPV/drone firmware space is crowded with projects competing for the same contributor time.

If INAV did go dormant, the practical migration path would be ArduPilot. The two firmwares share many concepts (waypoint missions, GPS modes, failsafe logic), and migration would be a project — not impossibly hard, but requiring re-setup of every drone and re-tuning of pilot habits.

The cohort's mitigation: stay on stable INAV versions, document configurations thoroughly (so we could re-create them on ArduPilot if needed), and watch the project's commit cadence as an early warning. As of mid-2026, there's no concern.