Add throttle gauge option to OSD

[MrD-RC]

Allow pilots to see the throttle as a vertical digital gauge. Similar appearance to the VSI vario gauge. Nothing shown is 0% throttle. 10 up arrows is full throttle. The element takes up 5 vertical characters.

Fixes #10723

Test

If anyone has a flight controller with a canvas OSD (FrSky PixelOSD). If they could confirm this is correct. It would be great. I plan on digging mine out when I have the time. But if someone beats me to it, I would be most grateful.

Requires Configurator iNavFlight/inav-configurator#2354

[sensei-hacker]

If someone could please test this, that would be great.
In particular if you can test any weird cases you might think of, any way it might break.

[MrD-RC]

/review

[qodo-code-review]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ✅ 10723 - PR Code Verified Compliant requirements: Add a visual throttle position indicator to the OSD, similar in style to the existing vertical vario indicator. Indicator should render as a vertical gauge composed of segments/arrows that increase with throttle. Ideally support canvas and grid OSD backends so it works across devices (including PixelOSD/canvas). Take minimal screen real estate; rough target similar to vario (about 5 vertical characters). Optionally allow scaled/controlled throttle value when autopilot/nav is controlling throttle. Provide default layout position so users can enable easily. Ensure appropriate symbols are defined for the new gauge rendering. Requires further human verification: Visual alignment and appearance across different OSD implementations, especially canvas devices (e.g., PixelOSD). User experience validation that the gauge is readable under flight conditions. Configurator integration and UI toggles (depends on external PR).

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

⚡ Recommended focus areas for review Update Throttling The canvas path caches prevThr and returns early for changes < 10%. This may cause the gauge to lag or not update when throttle oscillates within that range, diverging from grid rendering which always updates. Consider per-instance state or removing the threshold, or at least aligning behavior across backends. static uint8_t prevThr = 0; if (ABS(prevThr - thrPos) < 10) { return; } Erase Strategy Both osdGridBufferClearGridRect and displayCanvasClearRect are called before drawing. Validate this double-clear is necessary and not redundant or harmful on some canvas backends. Also confirm bounds use OSD_THROTTLE_GAUGE_HEIGHT_ROWS matches 5 rows exactly. osdGridBufferClearGridRect(gx, gy, 1, OSD_THROTTLE_GAUGE_HEIGHT_ROWS); int x = gx * canvas->gridElementWidth; int w = canvas->gridElementWidth; int y = gy * canvas->gridElementHeight; int h = OSD_THROTTLE_GAUGE_HEIGHT_ROWS * canvas->gridElementHeight; displayCanvasClearRect(canvas, x, y, w, h); Value Scaling Choice The gauge uses getThrottlePercent(navigationIsControllingThrottle()). Confirm this matches user expectations (manual vs NAV-controlled throttle) and is consistent with other OSD throttle displays. Edge cases at arming/disarmed or failsafe should be verified. case OSD_THROTTLE_GAUGE: { bool useScaled = navigationIsControllingThrottle(); osdThrottleGauge(osdDisplayPort, osdGetDisplayPortCanvas(), OSD_DRAW_POINT_GRID(elemPosX, elemPosY), getThrottlePercent(useScaled)); return true;

[MrD-RC]

PixelOSD still needs testing. The Updating Throttle and Erase Strategy can be checked then.

Updating Throttle should be fine. The scale only has 10% throttle increments. So if it has not moved by 10%, save the processing time. With Erase Strategy, one of the erase calls may be able to be removed.

The Value Scaling Choice is fine and has been verified on MAX7456 analogue and digital systems.

[MrD-RC]

Now tested on Canvas mode OSD (Pixel OSD)

[qodo-code-review]

PR Compliance Guide 🔍

All compliance sections have been disabled in the configurations.

[sensei-hacker]

Considering a throttle change from 75 to 84, would it make sense to do skip out early precisely when the gauge wouldn't change, using something like this?:

prevThr  = throttle / OSD_THROTTLE_GAUGE_HEIGHT_ROWS
...

if (prevThr == throttle / OSD_THROTTLE_GAUGE_HEIGHT_ROWS) {
  skip out early
} 

That way it does update when the throttle goes to a new bracket.

[MrD-RC]

You make a very good point. I'll make an update PR.

[MrD-RC]

Update: #11101