Append guidance course (navDesiredHeading) to MSP_NAV_STATUS

[MartinovEm]

What

Append one field to the end of MSP_NAV_STATUS:

• navDesiredHeading (u16, centidegrees [0..36000)) — the nav controller's desired course/track.

New layout: u8 mode | u8 state | u8 activeWpAction | u8 activeWpNumber | u8 error | u16 headingHoldTarget | u16 navDesiredHeading.

Appended at the tail, so existing consumers that parse the 7-byte reply keep working; new consumers read the extra 2 bytes only when the payload is long enough. No new getter — navDesiredHeading is already an exported global, set every nav cycle (wrap_36000(posControl.desiredState.yaw)). Also removes a long-dead commented-out target_bearing line in the same handler.

Why this value specifically

navDesiredHeading is the flight controller's own guidance output — the course it is actively steering toward — and a client cannot compute it itself:

• In cruise / course-hold there is no waypoint leg at all; the desired track is internal FC state (the course captured at engage, then stick-adjustable). A client has no other source for it.
• In RTH / direct-to / waypoint nav it's the controller's actual steering command, which can differ from naive geometry (e.g. tail-first handling).

This is the one piece missing from MSP for a faithful desired-track / CDI / HSI course pointer.

Why the related values are deliberately omitted

Cross-track error, bearing-to-destination and distance-to-destination were left out on purpose — a client can already compute them: for a waypoint mission it downloads the mission (MSP_WP) and derives bearing/distance/XTE from its own GPS position and the waypoint lat/lon (planar geometry; sub-metre precision is pointless at these ranges). In the no-waypoint modes there's no leg, so XTE/distance aren't even meaningful — only the course is. MSP_NAV_STATUS is polled often, so it's kept lean: expose only what the consumer cannot calculate.

Note vs the existing field

The existing u16 getHeadingHoldTarget() (bytes 5-6) is the commanded heading (heading-hold target). The new navDesiredHeading is the desired course/track toward the active leg — complementary, not a duplicate.

Compatibility

Purely additive — appended at the tail, no existing field moved. Consumers should gate display on mode/state (the value is stale when no nav mode is active).

Testing

Built clean on INAV SITL with -DWARNINGS_AS_ERRORS=ON.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[b14ckyy]

Hey @MartinovEm
It would be better if you target the PR towards maintenance-10.x since 9.1 is locked in and only receives bugfixes. We would also need time to test it against different applications to make sure nothing breaks.

[MartinovEm]

Thanks @b14ckyy — done. Rebased onto maintenance-10.x and switched the PR base to it. Clean rebase (only fc_msp.c touched) and it builds clean on SITL with warnings-as-errors.