Advanced Tuning: FW coordinated WP turn settings - comes with FW #11812

[b14ckyy]

Summary

Belongs to iNavFlight/inav#11812

Updates the Advanced Tuning → General Navigation Settings box for the new FW coordinated
waypoint turn system:

• Replaces the removed nav_fw_wp_turn_smoothing dropdown with the new consolidated
  nav_fw_wp_turn_mode select (DIRECT / COORD_FLYBY / COORD_FLYOVER / COORD_FLYINTO —
  values populate from the FC).
• Adds nav_fw_wp_turn_max_lead_time (3000–12000 ms) — the cap on how early a COORD_FLYBY
  turn may start before the waypoint.
• Help texts for both, covering all four turn modes, the path-tracking S-turn variant of
  COORD_FLYOVER, and the note that autoland approaches always fly COORD_FLYBY.

The turn feed-forward gain and control-ease settings intentionally get no UI — they stay
CLI-only while the system proves itself in the field.

Drive-by: fixes a config-setion → config-section class typo in the same box.

Testing

Verified against the firmware branch on MATEKF765: dropdown values populate correctly from the
FC settings table, save/reload round-trips, tooltips render.

[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

Advanced Tuning: add coordinated WP turn mode and max lead time

✨ Enhancement 🐞 Bug fix 📝 Documentation 🕐 10-20 Minutes

AI Description

• Replace legacy WP turn smoothing control with firmware-driven WP turn mode select.
• Add max lead time limit input for COORD_FLYBY waypoint turns.
• Update help text and fix a CSS class typo in the navigation settings box.

Diagram

graph TD
  FW[("FC settings")] --> SB(["Settings binder"]) --> AT["advanced_tuning.html"] --> UI["Advanced Tuning UI"]
  MSG[/"messages.json"/] --> TT["Help/tooltips"] --> UI
  subgraph Legend
    direction LR
    _fw[(Database)] ~~~ _svc([Service]) ~~~ _file["UI file"] ~~~ _doc[/"i18n JSON"/]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Add placeholder keys to all locales in this PR

• ➕ Avoids missing-key fallback behavior in non-English UI
• ➕ Makes translation work discoverable for maintainers
• ➖ Adds noise across many locale files
• ➖ Requires translator follow-up that may not be available immediately

2. Keep old UI control and map to new setting internally

• ➕ Minimizes UI change for existing users
• ➕ Could preserve older documentation wording
• ➖ Risks mismatch with firmware semantics and available modes
• ➖ Adds maintenance burden and confusion during transition

Recommendation: The PR’s approach (directly exposing the new consolidated nav_fw_wp_turn_mode and adding nav_fw_wp_turn_max_lead_time) is the cleanest and least error-prone alignment with firmware. Consider a follow-up to add stub i18n keys for other locales (or update translations) if missing-key fallback becomes a UX issue.

Files changed (2) +20 / -8

Enhancement (1) +10 / -4

advanced_tuning.htmlSwap WP turn smoothing control for mode select and add lead-time input +10/-4

Swap WP turn smoothing control for mode select and add lead-time input

• Fixes a config-section class typo so the General Navigation Settings box styles correctly. Replaces the nav_fw_wp_turn_smoothing select with a new nav_fw_wp_turn_mode select and adds a numeric nav_fw_wp_turn_max_lead_time input with min/max/step and tooltip bindings.

tabs/advanced_tuning.html

Documentation (1) +10 / -4

messages.jsonRename WP turn label and add coordinated turn mode/lead-time help +10/-4

Rename WP turn label and add coordinated turn mode/lead-time help

• Replaces the removed wpTurnSmoothing strings with new wpTurnMode strings describing DIRECT and coordinated turn behaviors. Adds new wpTurnMaxLeadTime label/help text, including guidance and valid range for COORD_FLYBY lead-time limiting.

locale/en/messages.json

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

Code Review by Qodo

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

1. No old-FW turn control 🐞 Bug ≡ Correctness

Description

The Advanced Tuning UI now only binds to nav_fw_wp_turn_mode, so on firmware that does not expose
this setting the Settings loader will remove the control entirely, leaving no waypoint turn setting
configurable in the UI. This is caused by Settings.configureInputs removing missing-setting inputs
and the PR removing the previous nav_fw_wp_turn_smoothing control.

Code

tabs/advanced_tuning.html[R681-683]

+                            <select id="wpTurnMode" data-setting="nav_fw_wp_turn_mode"></select>
+                            <label for="wpTurnMode"><span data-i18n="wpTurnMode"></span></label>
+                            <div for="wpTurnMode" class="helpicon cf_tip" data-i18n_title="wpTurnModeHelp"></div>

Evidence

The new UI only references the new setting name, while Settings.configureInputs deletes any input
whose setting doesn’t exist on the connected FC; with the old UI removed, older firmware will end up
with neither control present.

tabs/advanced_tuning.html[680-690]
js/settings.js[119-132]

Agent prompt

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

## Issue description
Advanced Tuning removed the `nav_fw_wp_turn_smoothing` UI and replaced it with `nav_fw_wp_turn_mode`. The Settings system removes UI inputs whose `data-setting` doesn’t exist on the connected firmware, so connecting to firmware that lacks `nav_fw_wp_turn_mode` will delete the new control and leave **no waypoint turn configuration** exposed.
### Issue Context
The Settings framework is explicitly designed to support differing firmware setting sets by removing unknown inputs at runtime.
### Fix Focus Areas
- tabs/advanced_tuning.html[680-690]
- js/settings.js[119-132]
- locale/en/messages.json[3708-3722]
### Expected fix
- Re-introduce the old control (e.g., a second `<select>` bound to `nav_fw_wp_turn_smoothing`) alongside the new one.
- Use the existing Settings behavior (remove missing inputs) so only the relevant control appears for the connected firmware.
- Restore the removed `wpTurnSmoothing` / `wpTurnSmoothingHelp` strings in `locale/en/messages.json` if you re-add the old UI element.

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

---

2. Locale keys not updated 🐞 Bug ⚙ Maintainability

Description

The UI now uses i18n keys wpTurnMode/wpTurnMaxLeadTime, but only locale/en defines them while other
locales still only contain the removed wpTurnSmoothing strings. As a result, non-English users will
fall back to English for these labels/tooltips and lose existing translations.

Code

tabs/advanced_tuning.html[R682-689]

+                            <label for="wpTurnMode"><span data-i18n="wpTurnMode"></span></label>
+                            <div for="wpTurnMode" class="helpicon cf_tip" data-i18n_title="wpTurnModeHelp"></div>
+                        </div>
+
+                        <div class="number">
+                            <input type="number" id="wpTurnMaxLeadTime" data-unit="msec" data-setting="nav_fw_wp_turn_max_lead_time" data-setting-multiplier="1" step="100" min="3000" max="12000" />
+                            <label for="wpTurnMaxLeadTime"><span data-i18n="wpTurnMaxLeadTime"></span></label>
+                            <div for="wpTurnMaxLeadTime" class="helpicon cf_tip" data-i18n_title="wpTurnMaxLeadTimeHelp"></div>

Evidence

The HTML references the new i18n keys; English defines them, but e.g. German/Bulgarian/Japanese
locale files still only define the old wpTurnSmoothing keys. The localization system is configured
to fall back to English, so the UI will regress to English strings for those locales.

tabs/advanced_tuning.html[680-690]
locale/en/messages.json[3711-3722]
locale/de/messages.json[3590-3599]
locale/bg/messages.json[3511-3522]
locale/ja/messages.json[3534-3545]
js/localization.js[21-33]

Agent prompt

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

## Issue description
New UI strings (`wpTurnMode`, `wpTurnModeHelp`, `wpTurnMaxLeadTime`, `wpTurnMaxLeadTimeHelp`) were added only to `locale/en/messages.json`. Other locales still contain the old `wpTurnSmoothing` keys but don’t define the new ones, causing translation regression.
### Issue Context
Localization uses i18next with `fallbackLng: 'en'`, so missing keys in non-English locales will silently fall back to English.
### Fix Focus Areas
- tabs/advanced_tuning.html[680-690]
- locale/en/messages.json[3711-3722]
- locale/de/messages.json[3590-3599]
- locale/bg/messages.json[3511-3522]
- locale/ja/messages.json[3534-3545]
- js/localization.js[21-33]
### Expected fix
- Add the new keys to all supported locale files (`de`, `ja`, `ru`, `bg`, `uk`, `zh_CN`).
- If translations aren’t available yet, copy the English strings temporarily to avoid showing unrelated/obsolete translations and to keep keys consistent across locales.

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

---

3. Input step size ignored ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The new nav_fw_wp_turn_max_lead_time input sets step="100", but Settings.configureInputs overwrites
numeric inputs’ data-step to 1 and unit conversion prioritizes data-step over the HTML step
attribute. As a result, the UI will not actually step by 100ms as intended.

Code

tabs/advanced_tuning.html[R687-689]

+                            <input type="number" id="wpTurnMaxLeadTime" data-unit="msec" data-setting="nav_fw_wp_turn_max_lead_time" data-setting-multiplier="1" step="100" min="3000" max="12000" />
+                            <label for="wpTurnMaxLeadTime"><span data-i18n="wpTurnMaxLeadTime"></span></label>
+                            <div for="wpTurnMaxLeadTime" class="helpicon cf_tip" data-i18n_title="wpTurnMaxLeadTimeHelp"></div>

Evidence

The new input declares a 100ms step, but Settings.configureInputs sets data-step=1 for numeric
inputs; convertToUnitSetting then computes the final step using data-step first, overriding the HTML
step.

tabs/advanced_tuning.html[686-689]
js/settings.js[181-185]
js/settings.js[551-567]

Agent prompt

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

## Issue description
The PR adds an integer `<input>` with `step="100"`, but Settings processing forces `data("step", 1)` for non-float numeric settings and later derives the rendered `step` from `data("step")` first. This defeats the PR’s step intent.
### Issue Context
`convertToUnitSetting()` uses `element.data("step")` before `element.attr('step')`, so once `configureInputs()` sets data-step, the HTML step attribute won’t matter.
### Fix Focus Areas
- tabs/advanced_tuning.html[686-689]
- js/settings.js[181-185]
- js/settings.js[551-567]
### Expected fix
Choose one:
1) Update `Settings.configureInputs()` so it does **not** overwrite an existing step when one is already declared (e.g., only set `input.data('step', 1)` if `input.data('step')` is undefined and there is no `step` attribute), or
2) Remove `step="100"` from the HTML since it is currently ineffective (and rely on firmware min/max only).

ⓘ 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 add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[github-actions]

Configurator test build ready — commit 9c67a2c

Download build artifacts for PR #2711

Available platforms (scroll to the Artifacts section at the bottom of the run page):

• Windows x64 (ZIP, MSI) and x32 (ZIP, MSI)
• macOS arm64 (ZIP, DMG) and x64 (ZIP, DMG)
• Linux x64 (DEB, RPM, ZIP) and aarch64 (DEB, RPM, ZIP)

A GitHub login is required to download artifacts. Build is for testing only.

[sensei-hacker]

I am assembling 10.0.0RC1 today, so today is the cut-off for new features.
Can we address the step issue (Qodo comment # 2) real quick?

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[b14ckyy]

@sensei-hacker done