Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 8 additions & 7 deletions src/main/flight/imu.c
Original file line number Diff line number Diff line change
Expand Up @@ -703,19 +703,20 @@ static void imuCalculateTurnRateacceleration(fpVector3_t *vEstcentrifugalAccelBF
//fixed wing only
static float lastspeed = -1.0f;
float currentspeed = 0;
if (isGPSTrustworthy()){
//first speed choice is gps
currentspeed = GPS3DspeedFiltered;
*acc_ignore_slope_multipiler = 4.0f;
}
#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()){
Comment on lines 706 to +715
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

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

//first speed choice is gps
currentspeed = GPS3DspeedFiltered;
*acc_ignore_slope_multipiler = 4.0f;
}
else
{
//third choice is fixedWingReferenceAirspeed
Expand Down