Commit Graph
1 Commits
Author SHA1 Message Date
Jeff Katz 5cdf5ac482 fix(commander): calibration CPU starvation on linux (#26608)
On Linux targets with high-rate external sensor data (>1000Hz), all
sensor calibrations (gyro, accel, mag) can freeze PX4 by starving
other threads of CPU. Normal flight is unaffected — only calibration
triggers the problem.

Two compounding issues in the calibration worker threads:

1. calibrate_cancel_check() creates a new uORB::Subscription on every
   call, which triggers getDeviceNodeLocked() — an O(n) linear strcmp
   scan through all uORB nodes. In gyro/mag calibration this was called
   on every sensor sample, consuming the majority of CPU in strcmp alone.

2. SubscriptionBlocking::updatedBlocking() returns immediately when data
   is already available (it only blocks when no data is pending). With
   continuous high-rate sensor data, the calibration loops never yield,
   spinning at 100% CPU.

These problems are addressed with this patch as follows:

- Throttle calibrate_cancel_check() to once per 200ms in gyro
  and mag calibration loops.

- Add 1ms px4_usleep() yield before updatedBlocking()/updateBlocking()
  in all calibration loops (gyro, accel, mag, orientation detection).
  This caps the effective loop rate at ~1000Hz — still far above what
  calibration needs (250-750 samples).

- Force Commander main loop to sleep during calibration so it does not
  compete with calibration worker threads for CPU.

Tested under Linux (x64, aarch64) both with RT and non-RT scheduling,
with sensor data arriving at ~3600Hz. Calibration completes normally
and no longer results in a deadlocked process.
2026-03-06 10:11:24 -09:00