Add in flight OSD menu mode via switch

[TheCryxh]

This PR introduces the ability to safely open and use the CMS OSD menu while the aircraft is armed in flight. Previously, CMS access was strictly hard-blocked while armed.

The goal is to allow pilots (especially fixed-wing and long-range multirotor flyers) to tune PIDs, adjust rates, switch profiles, change VTX power/channels, or tweak battery thresholds in real time during cruise/loiter without having to land and disarm.

InFlightOsd.mp4

---

Safety

Because stick inputs are hijacked to navigate the OSD menu, strict safety layers are enforced:

1. NAV-Mode Gate:
   • The menu will only open if the aircraft is flying in a stabilized navigation mode (POSHOLD, CRUISE, RTH, ALTHOLD, COURSE_HOLD).
   • If triggered in manual/acro/angle modes, access is silently rejected and a hardware-blinking USE NAV MODES FOR MENU warning is displayed on the OSD.
2. 3-Second Activation Hold:
   • Flipping the switch starts a 3-second countdown (MENU IN X.X) on the OSD before opening, preventing accidental switch flicks.
3. Instant Emergency Auto-Collapse:
   • The menu immediately force-closes and restores full stick authority if:
     • The pilot switches out of NAV mode (e.g. back to Acro/Manual)
     • Failsafe triggers (RTH / Emergency landing)
     • The aircraft is disarmed
     • The activation switch is turned OFF
4. Inactivity Timeout:
   • A 15-second idle timer automatically closes the CMS if no stick input is detected. The OSD displays a clean countdown (CLOSING IN X) during the last 10 seconds.
5. Switch Latching:
   • When the menu closes (via timeout, manual exit, or emergency), the switch is latched to prevent re-opening loops until the switch is cycled OFF.
6. Zero In-Flight EEPROM Writes:
   • All in-flight adjustments modify RAM only. Blocking operations (EEPROM saves / reboot triggers) are strictly suppressed while armed.

---

Menu Structure In Flight

Ground Menu (Disarmed)

• 100% untouched and original. When disarmed, the full CMS menu structure is preserved with all factory items (EZTUNE, FILTERING, MECHANICS, SAVE+REBOOT, etc.).

In-Flight Menu (Armed)

To prevent misleading the pilot, the in-flight hierarchy only exposes settings that apply 100% in real time to RAM:

• PID PROF: Profile switching with instant schedulePidGainsUpdate() & navigationUsePIDs().
• PID (RPY + FF): Requires explicit SET -> YES confirmation before committing to RAM. BACK safely cancels.
• PID ALTMAG & PID GPSNAV: Dedicated navigation PID tuning with explicit SET confirmation.
• RATE PROF: Rate profile switching with immediate activateControlConfig() (updates throttle curves mid/expo live).
• RATE & MANU RATE: Rates & expo applied live every loop.
• NAVIGATION: RTH altitude, cruise throttle, auto speed, bank angle, etc. (read live by navigation tasks).
• BATTERY: Live cell count & voltage threshold updates via non-blocking in-flight batteryInit().
• VTX CONTROL: Instant hardware frequency/power changes without triggering EEPROM save notifications.
• OSD & MISC: OSD layout previews and throttle idle.

Intentionally Excluded from In-Flight Menu (by design):

• SAVE+REBOOT / SAVE+EXIT (prohibited while flying)
• BLACKBOX & MIXER & SERVOS (dangerous / irrelevant in flight)
• FILTERING & EZTUNE (filter cutoffs are only initialized at boot; editing them mid-air does not recalculate active filter coefficients)
• MECHANICS (contains static filter cutoffs like CD LPF and iTerm cutoff)
• FS PROCEDURE (preventing accidental failsafe setting changes during flight)
• BATTERY AUTOSWITCH (one-time ground detection feature)
  (P.S.: Some of the categories that were removed are still shown in my video—just ignore them.)

---

Testing

• Flight tested and verified on my own setup (SpeedyBee F405 Mini target). Live PID updates, VTX control, timeouts, and failsafe collapses all behaved as expected (see demo video above).
• Since this is a new workflow, further testing and feedback from the community and maintainers across different targets, fixed-wings, and multirotors is necessary!
• For easy testing without requiring immediate Configurator changes, the mode is currently mapped to BOXUSER4. For an official merge into INAV 10, a dedicated mode like IN-FLIGHT MENU or OSD MENU must be added to inav-configurator.

[github-actions]

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

• maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

• maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

---

This is an automated suggestion to help route contributions to the appropriate branch.

[Jetrell]

I'm not sure you want Course Hold. It doesn't hold altitude by itself. While the other nav modes you mentioned do hold altitude. Which makes more sense if you are accessing the CMS while flying.

Most of that stuff can be accessed and controlled by using the Programming Framework.. But I guess this won't require an extra Aux channel to be used, just the sticks.

[TheCryxh]

Thanks for the feedback @Jetrell

I've updated the PR to drop standalone Course Hold, so only modes that hold altitude (POSHOLD, RTH, WP, ALTHOLD) are allowed. Since CRUISE mode includes AltHold, it will still work as intended.

And yes, exactly, the main goal here is simplicity. You only need a single AUX switch to open the menu and then use standard sticks to navigate and adjust everything visually, without needing extra AUX channels, pots, or complex Logic Conditions.

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Enable safe in-flight CMS (OSD) menu via AUX switch with NAV-mode guards

✨ Enhancement 🕐 40+ Minutes

AI Description

• Add in-flight CMS open/close flow on BOXUSER4 with NAV-mode + failsafe gating
• Provide OSD feedback (open countdown, NAV-required warning, inactivity close countdown)
• Split ground vs in-flight menu trees and suppress unsafe actions (save/reboot, EEPROM writes)

Diagram

graph TD
  A["RC Modes (BOXUSER4)"] --> B["cmsUpdate() gating"] --> C["cmsMenuOpen()"] --> D["In-flight menu tree"]
  B --> E["Countdown + latch state"]
  E --> F["OSD system messages"]
  C --> G["cmsInMenu flag"] --> H["fc_core RC override"]
  D --> I["Battery/VTX/PID live actions"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Introduce a dedicated BOXCMS / BOXOSDMENU mode (vs BOXUSER4)

• ➕ Clearer UX and prevents collision with user-defined modes
• ➕ Allows configurator/CLI docs to explicitly describe safety behavior
• ➕ Easier to evolve (e.g., per-mode parameters for hold time/timeout)
• ➖ Requires coordinated configurator + firmware updates
• ➖ Adds mode surface area and compatibility concerns across targets

2. Navigate in-flight CMS via dedicated AUX channels (no stick hijack)

• ➕ Avoids neutralizing roll/pitch/yaw, reducing reliance on NAV stabilization
• ➕ Potentially safer for platforms where stick authority is critical
• ➖ Consumes multiple AUX channels and transmitter switches
• ➖ Bigger UI/UX change and more complex input mapping

3. Permit only a minimal 'quick-tune' subset instead of full CMS navigation

• ➕ Smaller safety envelope and less chance of pilot confusion mid-flight
• ➕ Less code churn in CMS menu definitions
• ➖ Does not unlock the broader CMS workflows (profile switching, VTX changes, etc.)
• ➖ May require a parallel UI system anyway

Recommendation: The PR’s approach (NAV-mode gate + activation hold + forced collapse + inactivity timeout + RAM-only writes) is the right baseline for enabling in-flight CMS with acceptable safety. For upstreaming, the biggest follow-up is replacing BOXUSER4 with a dedicated mode and documenting/parameterizing the timers; the core gating and forced-collapse logic should remain the primary safety mechanism.

Files changed (14) +414 / -19

Enhancement (14) +414 / -19

cms.cAdd guarded in-flight CMS open/close flow with countdown, latch, and timeout +138/-13

Add guarded in-flight CMS open/close flow with countdown, latch, and timeout

• Introduces BOXUSER4-based in-flight CMS activation gated by NAV modes, armed state, and no failsafe. Adds a 3-second open countdown, switch latch to prevent re-open loops, forced close when safety conditions are lost, and a 15-second inactivity auto-exit with an on-screen closing countdown. Splits ground vs in-flight behavior (no servo disable while armed, suppress save/reboot, disable yaw gesture keys while in-flight).

src/main/cms/cms.c

cms.hExpose CMS countdown/latch state to other modules +5/-0

Expose CMS countdown/latch state to other modules

• Adds public APIs to query the in-flight open countdown, inactivity close countdown, and switch latch state for OSD messaging and UI feedback.

src/main/cms/cms.h

cms_menu_battery.cMake battery changes take effect live while armed + add in-flight battery menu +37/-1

Make battery changes take effect live while armed + add in-flight battery menu

• Calls batteryInit() when exiting battery-related menus while armed so voltage/cell thresholds apply immediately. Adds a reduced in-flight battery menu that focuses on profile selection and settings without relying on ground-only flows.

src/main/cms/cms_menu_battery.c

cms_menu_battery.hDeclare in-flight battery menu export +1/-0

Declare in-flight battery menu export

• Exports cmsx_menuBatteryInFlight for use in the in-flight root menu tree.

src/main/cms/cms_menu_battery.h

cms_menu_builtin.cAdd dedicated in-flight root menus (Main/Features) with safe subset +57/-0

Add dedicated in-flight root menus (Main/Features) with safe subset

• Introduces menuMainInFlight and a trimmed Features submenu that expose navigation, VTX, LED (optional), OSD, battery, info, and in-flight misc, while excluding ground-only/unsafe items like save/reboot and other high-risk sections.

src/main/cms/cms_menu_builtin.c

cms_menu_builtin.hDeclare in-flight main menu export +1/-0

Declare in-flight main menu export

• Exports menuMainInFlight so cms.c can select the appropriate root menu when opened while armed.

src/main/cms/cms_menu_builtin.h

cms_menu_imu.cEnable live PID/profile changes and add explicit 'SET' confirmation submenus +104/-3

Enable live PID/profile changes and add explicit 'SET' confirmation submenus

• Applies PID/profile changes immediately (schedulePidGainsUpdate(), navigationUsePIDs(), activateControlConfig()) to support real-time tuning. Replaces on-exit PID writebacks with explicit confirmation submenus (PID, ALTMAG, GPSNAV) to avoid accidental commits while navigating. Adds a dedicated in-flight PID TUNING menu exposing only live-safe tuning paths.

src/main/cms/cms_menu_imu.c

cms_menu_imu.hDeclare in-flight IMU/PID tuning menu export +1/-0

Declare in-flight IMU/PID tuning menu export

• Exports cmsx_menuImuInFlight for inclusion in the in-flight main menu tree.

src/main/cms/cms_menu_imu.h

cms_menu_misc.cAdd trimmed in-flight misc menu +30/-0

Add trimmed in-flight misc menu

• Creates cmsx_menuMiscInFlight with a small set of live-safe settings (e.g., throttle idle and selected OSD settings) for use while armed.

src/main/cms/cms_menu_misc.c

cms_menu_misc.hDeclare in-flight misc menu export +1/-0

Declare in-flight misc menu export

• Exports cmsx_menuMiscInFlight for inclusion in the in-flight main menu tree.

src/main/cms/cms_menu_misc.h

cms_menu_vtx.cSuppress VTX EEPROM save notifications while armed +4/-1

Suppress VTX EEPROM save notifications while armed

• Prevents saveConfigAndNotify() from running while armed so in-flight VTX changes remain non-blocking and RAM-only.

src/main/cms/cms_menu_vtx.c

fc_core.cNeutralize roll/pitch/yaw commands while in-flight CMS is active +21/-0

Neutralize roll/pitch/yaw commands while in-flight CMS is active

• When CMS is open and the aircraft is armed, forces roll/pitch/yaw rcCommand values to neutral while allowing throttle passthrough. Ensures failsafeUpdateRcCommandValues() still runs on new RX data so RC link loss is still detected promptly.

src/main/fc/fc_core.c

osd.cAdd OSD warnings and activation countdown for in-flight CMS +13/-1

Add OSD warnings and activation countdown for in-flight CMS

• Displays a 'MENU IN X.X' countdown during the 3-second activation delay and shows a blinking 'USE NAV MODES FOR MENU' warning when BOXUSER4 is active but NAV gating prevents opening. Ensures the NAV-required warning blinks similarly to failsafe messages for attention.

src/main/io/osd.c

osd.hAdd OSD message string for NAV-required CMS warning +1/-0

Add OSD message string for NAV-required CMS warning

• Defines OSD_MSG_MENU_NAV_REQ ("USE NAV MODES FOR MENU") used by OSD system messaging when in-flight CMS activation is rejected.

src/main/io/osd.h

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Auto-close skips onExit ✓ Resolved 🐞 Bug ≡ Correctness

Description

cmsUpdate() force-closes the in-flight CMS with cmsMenuExit(..., CMS_EXIT) on safety loss/timeout,
but cmsMenuExit() does not run per-menu onExit callbacks for CMS_EXIT. This can leave temporary
state enabled after the menu collapses (e.g., OSD layout preview override is only cleared in
menuOsdElements.onExit).

Code

src/main/cms/cms.c[R1448-1451]

+        if (cmsOpenedInFlight && (!IS_RC_MODE_ACTIVE(BOXUSER4) || !ARMING_FLAG(ARMED)
+                                  || FLIGHT_MODE(FAILSAFE_MODE) || !cmsIsNavModeActive())) {
+            cmsMenuExit(pCurrentDisplay, (void *)CMS_EXIT);
+            return;

Evidence

The PR introduces automatic closes via CMS_EXIT, but CMS_EXIT intentionally performs no onExit
dispatch; meanwhile some menus depend on onExit for cleanup (OSD preview override). Because the
in-flight menu includes OSD, this cleanup can be skipped when the CMS collapses due to
timeout/safety/switch-off.

src/main/cms/cms.c[1411-1457]
src/main/cms/cms.c[908-944]
src/main/cms/cms_menu_builtin.c[186-199]
src/main/cms/cms_menu_osd.c[336-394]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
In-flight auto-close paths call `cmsMenuExit(..., CMS_EXIT)`, but `cmsMenuExit()` does not dispatch `onExit` callbacks for `CMS_EXIT`. Menus that rely on `onExit` for cleanup (e.g. OSD layout preview override) can leave that transient state active after an emergency/timeout close.
### Issue Context
- In-flight main menu includes the OSD submenu (`cmsx_menuOsd`), which can enter `menuOsdElements` that sets an OSD override on enter and clears it on exit.
- Safety close / inactivity close uses `CMS_EXIT`, not `cmsMenuBack()`, so no stack unwinding happens.
### Fix Focus Areas
- Ensure auto-close (safety/timeout/switch-off) triggers the same cleanup as backing out of menus:
- Call `currentCtx.menu->onExit(...)` if present.
- Optionally iterate `menuStack[]` and call `onExit` for each stacked menu (similar to the popup-save traversal) to guarantee cleanup.
- Keep the “no EEPROM save/reboot while armed” restriction intact.
- src/main/cms/cms.c[908-944]
- src/main/cms/cms.c[1443-1457]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Course-hold nav gate missing 🐞 Bug ≡ Correctness

Description

cmsIsNavModeActive() is used to allow opening/keeping the in-flight CMS, but it omits
NAV_COURSE_HOLD_MODE. As a result, COURSE_HOLD will be treated as unsafe: the menu cannot be opened
in COURSE_HOLD and will also be force-closed if COURSE_HOLD is the only active nav mode.

Code

src/main/cms/cms.c[R1392-1395]

+    return FLIGHT_MODE(NAV_POSHOLD_MODE) ||
+           FLIGHT_MODE(NAV_RTH_MODE) ||
+           FLIGHT_MODE(NAV_WP_MODE) ||
+           FLIGHT_MODE(NAV_ALTHOLD_MODE);

Evidence

NAV_COURSE_HOLD_MODE is defined as a flightMode flag, but the helper used for in-flight menu gating
checks only POSHOLD/RTH/WP/ALTHOLD, so COURSE_HOLD fails the gate.

src/main/cms/cms.c[1390-1396]
src/main/fc/runtime_config.h[90-104]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`cmsIsNavModeActive()` does not consider `NAV_COURSE_HOLD_MODE` as an allowed stabilized mode for in-flight CMS. This blocks the feature (and triggers emergency close) in COURSE_HOLD.
### Issue Context
`NAV_COURSE_HOLD_MODE` is a first-class flight mode flag.
### Fix Focus Areas
- Add `FLIGHT_MODE(NAV_COURSE_HOLD_MODE)` to `cmsIsNavModeActive()`.
- Re-check both open and forced-close conditions that depend on this helper.
- src/main/cms/cms.c[1390-1396]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. batteryInit resets live state ✓ Resolved 🐞 Bug ☼ Reliability

Description

The battery CMS menus call batteryInit() when exiting while armed, which resets batteryState and
voltage thresholds to zero. If throttle VBAT compensation is enabled, mixerThrottleCommand will use
calculateThrottleCompensationFactor() based on batteryFullVoltage=0 until batteryUpdate recomputes,
changing throttle scaling transiently.

Code

src/main/cms/cms_menu_battery.c[R66-68]

+    if (ARMING_FLAG(ARMED)) {
+        batteryInit();
+    }

Evidence

The new in-flight battery menus explicitly call batteryInit() when armed. batteryInit() zeros
battery state/thresholds, while throttle VBAT compensation uses batteryFullVoltage via
calculateThrottleCompensationFactor() in the mixer, so exiting the battery menu can affect throttle
scaling until the next battery state recomputation.

src/main/cms/cms_menu_battery.c[60-68]
src/main/cms/cms_menu_battery.c[100-109]
src/main/sensors/battery.c[201-208]
src/main/sensors/battery.c[506-509]
src/main/flight/mixer.c[595-603]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Calling `batteryInit()` while armed resets live battery runtime state (`batteryState`, cell count, and voltage thresholds). This can transiently change behaviors that depend on those values (notably throttle VBAT compensation which uses `batteryFullVoltage`).
### Issue Context
The CMS battery menus already write settings directly; they only need to refresh derived thresholds/state, not reset battery presence.
### Fix Focus Areas
- Replace `batteryInit()` (armed path) with a new targeted refresh that:
- recomputes `batteryFullVoltage/batteryWarningVoltage/batteryCriticalVoltage` based on current `batteryCellCount` and current battery profile, without forcing `batteryState = BATTERY_NOT_PRESENT`.
- avoids transiently zeroing values used in the mixer.
- If a new battery API is needed, implement it in `sensors/battery.c` and expose via `sensors/battery.h`.
- src/main/cms/cms_menu_battery.c[60-68]
- src/main/cms/cms_menu_battery.c[100-109]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

2. Course-hold nav gate missing 🐞 Bug ≡ Correctness

cmsIsNavModeActive() is used to allow opening/keeping the in-flight CMS, but it omits
NAV_COURSE_HOLD_MODE. As a result, COURSE_HOLD will be treated as unsafe: the menu cannot be opened
in COURSE_HOLD and will also be force-closed if COURSE_HOLD is the only active nav mode.

Agent Prompt

### Issue description
`cmsIsNavModeActive()` does not consider `NAV_COURSE_HOLD_MODE` as an allowed stabilized mode for in-flight CMS. This blocks the feature (and triggers emergency close) in COURSE_HOLD.

### Issue Context
`NAV_COURSE_HOLD_MODE` is a first-class flight mode flag.

### Fix Focus Areas
- Add `FLIGHT_MODE(NAV_COURSE_HOLD_MODE)` to `cmsIsNavModeActive()`.
- Re-check both open and forced-close conditions that depend on this helper.

- src/main/cms/cms.c[1390-1396]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools