Fix: Prioritize Airspeed over GPS for turn acceleration compensation#11312
Open
shota3527 wants to merge 3 commits intoiNavFlight:masterfrom
Open
Fix: Prioritize Airspeed over GPS for turn acceleration compensation#11312shota3527 wants to merge 3 commits intoiNavFlight:masterfrom
shota3527 wants to merge 3 commits intoiNavFlight:masterfrom
Conversation
Branch Targeting SuggestionYou've targeted the
If This is an automated suggestion to help route contributions to the appropriate branch. |
Contributor
Review Summary by QodoPrioritize airspeed over GPS for turn rate acceleration
WalkthroughsDescription• Prioritize airspeed over GPS for turn acceleration compensation • Airspeed now primary choice, GPS becomes fallback option • Corrects centripetal acceleration calculation for aerodynamic lift • Aligns with physics: lift depends on airspeed, not ground speed Diagramflowchart LR
A["Speed Selection Logic"] --> B["Check Pitot/Airspeed"]
B -->|Valid| C["Use Airspeed<br/>multiplier=4.0"]
B -->|Invalid| D["Check GPS"]
D -->|Trustworthy| E["Use GPS Speed<br/>multiplier=4.0"]
D -->|Invalid| F["Use Reference<br/>Airspeed"]
C --> G["Calculate Centrifugal<br/>Acceleration"]
E --> G
F --> G
File Changes1. src/main/flight/imu.c
|
Contributor
Code Review by Qodo
✅
🐞 Bug ⛯ Reliability |
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
Comment on lines
706
to
715
| #ifdef USE_PITOT | ||
| else if (sensors(SENSOR_PITOT) && pitotIsHealthy()) | ||
| if (pitotValidForAirspeed()) | ||
| { | ||
| // second choice is pitot | ||
| currentspeed = getAirspeedEstimate(); | ||
| *acc_ignore_slope_multipiler = 2.0f; | ||
| *acc_ignore_slope_multipiler = 4.0f; | ||
| } | ||
| else | ||
| #endif | ||
| if (isGPSTrustworthy()){ |
Contributor
There was a problem hiding this comment.
1. Pitot failure trips early 🐞 Bug ⛯ Reliability
• imuCalculateTurnRateacceleration() now calls pitotValidForAirspeed() from the main PID/attitude loop hot-path. • pitotValidForAirspeed() increments pitotFailureCounter per call and uses PITOT_FAILURE_THRESHOLD with an explicit ~100Hz timing assumption; at PID-loop rates this can declare pitot failure orders of magnitude faster than intended. • Result can be false pitot failure detection (forcing GPS/virtual fallback) and additional CPU load in a critical control loop.
Agent Prompt
### Issue description
`imuCalculateTurnRateacceleration()` calls `pitotValidForAirspeed()` in the main PID/attitude loop. `pitotValidForAirspeed()` updates failure counters per call and uses thresholds documented for ~100Hz operation, so calling it at PID-loop rates can cause premature pitot failure detection and unnecessary CPU load.
### Issue Context
- `pitotValidForAirspeed()` contains stateful failure detection (`pitotFailureCounter`, `pitotHardwareFailed`) and assumes a bounded call frequency.
- IMU/attitude is updated from `taskMainPidLoop`, typically much faster than PITOT task frequency.
### Fix Focus Areas
- src/main/flight/imu.c[701-719]
- src/main/sensors/pitotmeter.c[436-493]
- src/main/fc/fc_tasks.c[571-577]
- src/main/fc/fc_core.c[904-939]
### Suggested approach
- Add a cached boolean (e.g., `pitotAirspeedValidCached`) updated **once per PITOT task run** (or in `pitotUpdate()`), by calling `pitotValidForAirspeed()` there.
- In `imuCalculateTurnRateacceleration()`, use the cached boolean instead of calling `pitotValidForAirspeed()` directly.
- If needed, expose a side-effect-free accessor for IMU usage (e.g., `pitotIsHealthy() && pitotIsCalibrationComplete() && !pitotHasFailed()`) and keep plausibility counters in the PITOT update task only.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I did some research recently and found that the first choice to calculate Centrifugal Acceleration should be
gyro_angular_rate * airspeed, instead of GPS absolute speed.Centripetal acceleration is generated by aerodynamic lift, which depends on Airspeed, not Ground Speed. My previous assumption to prioritize GPS here was a mistake.
Example Case (Hovering into Wind):
Consider a scenario where the aircraft is flying into a strong headwind matching its cruise speed:
If the aircraft performs a turn (theta radian at omega rate):
velocity=0, new "normal“velocity = v * theta, speed change(accleration) isv * theta - 0= v * omega0 * omega = 0. The wings generate a centripetal force ofv * omega.v * omega,If airspeed is not valid, then fall back to GPS speed.
Reference:
Euston et al. (2008), Section A. Acceleration Compensation Using Airspeed Data:
https://users.cecs.anu.edu.au/~Jonghyuk.Kim/pdf/2008_Euston_iros_v1.04.pdf