Fix MSP2_INAV_WIND returning stale non-zero values when invalid - #11762
Conversation
getEstimatedHorizontalWindSpeed() was called unconditionally, so once
the wind estimate becomes invalid (e.g. the 15-minute stationary-altitude
timeout in wind_estimator.c), MSP2_INAV_WIND kept sending the last
computed windSpeed/windAngle instead of zero. estimatedWind[] is never
reset when hasValidWindEstimate clears, only the flags byte reflected
validity. This contradicted the message's own documentation ("returns
zeroes when wind estimation is not compiled in or not yet valid") and
diverged from every other consumer of this API (gps.c, osd.c,
rth_estimator.c, navigation.c, imu.c, mavlink_streams.c,
logic_condition.c, pitotmeter.c), all of which check
isEstimatedWindSpeedValid() before reading the value rather than relying
on the estimator to self-zero.
Reported by Qodo's automated review on PR iNavFlight#11761 (a release/9.1 ->
maintenance-10.x merge that carried this pre-existing bug forward,
unrelated to that merge itself). Fixed at the source (release/9.1) so it
flows forward on the next maintenance-10.x sync.
PR Summary by QodoMSP2_INAV_WIND: zero wind speed/angle when estimate is invalid
AI Description
Diagram
High-Level Assessment
Files changed (1)
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTo customize comments, go to the Qodo configuration screen, or learn more in the docs. |
|
Test firmware build ready — commit Download firmware for PR #11762 244 targets built. Find your board's
|
Summary
Flagged by Qodo's automated review on PR #11761 (a
release/9.1→maintenance-10.xmerge PR):MSP2_INAV_WIND's handler infc_msp.ccalledgetEstimatedHorizontalWindSpeed()unconditionally and only usedisEstimatedWindSpeedValid()to set theflagsbyte, not to gate the actualwindSpeed/windAnglevalues. Confirmed real:wind_estimator.c,estimatedWind[]is written only inside the successful-estimate branch ofupdateWindEstimator()(the low-pass filter update) — it is never reset whenhasValidWindEstimateclears (timeout at 15 min without altitude change, orvalidityScoredecaying to 0 from repeated stale updates).getEstimatedHorizontalWindSpeed()keeps returning the last computed value indefinitely, while theflagsbyte correctly reports invalid.MSP2_INAV_WIND's own documentation (docs/development/msp/msp_messages.json): "returns zeroes when wind estimation is not compiled in or not yet valid. Check bit 0 offlagsbefore using speed/angle values."io/gps.c,io/osd.c,flight/rth_estimator.c,navigation/navigation.c,flight/imu.c,mavlink/mavlink_streams.c,programming/logic_condition.c,sensors/pitotmeter.c.MSP2_INAV_WINDwas the only caller that didn't.Changes
src/main/fc/fc_msp.c: gatewindSpeed/windAngleonisEstimatedWindSpeedValid(), matching the established pattern and the message's documented contract — send0, 0, flags=0when invalid, the real values withflags=1when valid.Testing
USE_WIND_ESTIMATOR+USE_GPSboth active viatarget/common.h) — compiles cleanly, zero warnings/errors infc_msp.corwind_estimator.c.wind_estimator.c:estimatedWind[]has exactly one write site (the filter update inside the successful-estimate branch) and no reset path, confirming the staleness is real and not just a theoretical race.getEstimatedWindSpeed()/getEstimatedHorizontalWindSpeed()/isEstimatedWindSpeedValid()insrc/mainto confirm the fix matches the codebase-wide convention rather than introducing a new one.Targets
release/9.1per this repo's bugfix base-branch convention; will flow forward tomaintenance-10.xon the next sync.