The first release candidate, published on 24 September, adds terrain-relative altitude data, predictive coordinated waypoint turns, airspeed or 3D-ground-speed control, DroneCAN, a broader MAVLink implementation and automatic VTOL transition logic. Those features touch navigation, peripheral wiring, mission control and transition behavior at the same time.
That makes INAV 10 potentially useful for more capable fixed-wing and VTOL builds. It also makes upgrade discipline more important. This is pre-release software, and the INAV project explicitly recommends the 9.1.x branch for pilots who want reliability and bug fixes rather than early access to new features.
Terrain data changes what altitude control can mean
Conventional GPS altitude tells the controller where the aircraft is vertically relative to a reference, but it does not describe the ground underneath a route. That distinction becomes important on long fixed-wing flights over changing terrain.
INAV 10 can use preloaded terrain data on an SD card to derive altitude above ground level from the aircraft's GPS position. The new Terrain AGL Hold mode can then use that information for altitude control.
The practical value is not that an SD card suddenly replaces all other altitude sensing. It is that a mission can reason about terrain rather than holding one absolute altitude while the ground rises and falls underneath it.
For a fixed-wing aircraft covering hills, valleys or a long corridor, that can make route design more consistent with the physical landscape. It also creates a new dependency: the quality and coverage of the terrain dataset become part of the navigation chain. Builders should verify the loaded map coverage and treat terrain data as another input that can be stale, incomplete or wrong.
INAV's release notes point users to a terrain map generator for preparing the data. That preparation belongs in preflight planning, not as an afterthought after the aircraft has already been configured.
Predictive turns address a fixed-wing geometry problem
Waypoint navigation is straightforward to describe but harder to fly well with an airplane. A multicopter can slow, stop or pivot with far fewer geometric constraints. A fixed-wing aircraft has a turn radius determined by speed, bank angle, wind and controller behavior.
INAV 10 introduces predictive coordinated waypoint turns that are planned as geometric arcs sized to the aircraft's actual turn radius. That is a more useful model than treating a waypoint as a point the airplane should simply reach before beginning the next leg.
The release also adds Fixed-wing Auto Speed mode, which can hold a selected airspeed or 3D ground speed rather than using thrust-based cruise as the primary control target.
Those two features belong together. Turn geometry depends on speed. If the controller has a more explicit speed target and a more realistic model of how the aircraft can bend its path, mission tracking should become less dependent on tuning around a simplistic waypoint transition.
That does not eliminate the need to tune the airframe. Airspeed sensing, wind, bank limits and energy management still matter. The value is that the navigation logic has better primitives to work with.
DroneCAN changes the wiring conversation
The addition of DroneCAN is important for larger builds because it moves some peripherals away from point-to-point serial wiring and toward a shared CAN bus.
INAV describes DroneCAN as a peer-to-peer CAN system for peripherals with unique node IDs, configured through a new DroneCAN tab in Configurator. On a larger fixed-wing platform, that can reduce wiring complexity and make it easier to distribute sensors or other devices around the airframe.
CAN is not automatically simpler in every small model. A compact wing with a few short UART runs may gain little from adding another bus. The benefit grows as the aircraft becomes physically larger, carries more peripherals or needs a more robust way to connect devices over longer cable runs.
Builders should also separate electrical robustness from configuration robustness. A shared bus can reduce wiring, but a bus problem can affect multiple devices. Termination, power distribution, connector quality and node configuration need the same attention previously given to individual serial links.
MAVLink makes INAV a better participant in a larger system
The MAVLink work in INAV 10 is similarly significant because it pushes the controller toward deeper integration with ground software and external systems.
The release notes list RC override over MAVLink serial RX, MSP-over-MAVLink tunneling, mission upload and download, guided navigation control and native MLRS receiver integration. INAV also renamed older MAVLink settings into a new mavlink_port1_* scheme as part of its move toward multi-port support.
For a simple recreational airplane, much of this may be unnecessary. For a mapping platform, experimental autonomous aircraft or larger research build, the ability to exchange missions and guided commands through a standard protocol can reduce custom glue code.
It also increases the number of paths through which the aircraft can be commanded. That makes interface testing important. A builder should know which source has control, how a link loss is handled, what happens when commands conflict and how the configured failsafes behave when an external mission computer disappears.
More integration is useful only when control authority remains understandable.
VTOL transition logic moves another critical phase into the controller
INAV 10 adds an automatic VTOL transition mode based on airspeed with a fallback timer. The release notes also describe stabilization and lift-control smoothing during the transition.
Transition is one of the most failure-sensitive parts of a hybrid aircraft. The controller has to move from vertical lift to wing-borne flight without allowing airspeed, attitude or lift to collapse. A timer-only transition cannot know whether the aircraft actually reached the expected aerodynamic state. An airspeed-based condition provides a more physical trigger, while the fallback timer prevents one bad sensor reading from leaving the aircraft in an indefinite transition.
That is a better control concept, but it also raises the standard for sensor validation. If transition logic depends on airspeed, a blocked pitot tube, poor calibration or noisy sensor now affects more than a dashboard number.
A sensible test program should separate bench validation, restrained or low-risk transition tests and full mission use. The fallback behavior deserves as much attention as the nominal transition.
The upgrade method is part of the safety case
The least glamorous INAV 10 change may be the one most likely to catch experienced users: configuration migration.
INAV says firmware 10.0 and Configurator 10.0 major versions must match. For automatic migration from 9.x, the project instructs users to back up through the Firmware Flasher tab, flash INAV 10 with Full Chip Erase enabled, then restore through the same Configurator path.
The project is unusually explicit that pasting a CLI diff all directly does not run the automatic migration. Several settings have been removed or renamed, including MAVLink parameters and the fixed-wing waypoint-turn setting. GPS defaults also change for configurations that do not already carry explicit values.
That means the familiar habit of saving a diff, flashing and pasting the diff back can produce a configuration that looks superficially familiar while missing the intended migration.
For a release candidate, the safer workflow is straightforward:
- Save the existing configuration and keep the original firmware available.
- Install the matching INAV Configurator 10.0.
- Use Configurator's Backup Config path before flashing.
- Flash with Full Chip Erase.
- Restore through Configurator so migration runs.
- Review every warning and every renamed or removed setting.
- Verify sensor orientation, receiver input, servo direction, motor output, modes, failsafes and navigation settings on the bench.
- Fly a conservative test profile before restoring a full autonomous mission.
That process is slower than treating firmware as a phone update. It is also appropriate for software that controls an aircraft.
Who should test RC1 now
INAV 10.0.0-RC1 is most interesting today for builders who can test deliberately and who need one of the new capabilities: terrain-aware fixed-wing operation, DroneCAN peripherals, improved MAVLink integration, new supported hardware or VTOL transition work.
An aircraft that is already reliable and does not need those features has a simpler answer. INAV itself recommends staying on the latest 9.1.x release if reliability and bug fixes are the priority.
The release candidate is valuable because it shows where INAV is going. The project is making fixed-wing navigation more geometric, peripheral integration more networked and mission control more interoperable. Those are meaningful changes for technically ambitious RC and civilian UAS builds.
They are also exactly the kind of changes that deserve a controlled test aircraft before they reach the machine you depend on.