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.
- Enable arbitrary euler angle for Mag rotation
- new CUSTOM rotation enum out of the normal enum range
- mag_rot: automatically change to custom if euler rot is set
- sensor_calibration: Magnetometer save custom rotation parameters
- mag_cal: cross mention rotation parameters
- This allows the user to see the RPY options when searching for the rotation parameter
---------
Co-authored-by: Junwoo Hwang <junwoo@auterion.com>
Co-authored-by: bresch <[brescianimathieu@gmail.com](mailto:brescianimathieu@gmail.com)>
Co-authored-by: Daniel Agar <daniel@agar.ca>
- this was an experiment to casually monitor sensor offsets relative to temperature, but now that all calibration offsets can be adjusted post-flight the stored temperature can be misleading
- deleting to save a little bit of flash (and storing the temperature wasn't useful)
- centralize logic for selecting a preferred calibration slot
- automatically use existing calibration slot if it exists, otherwise
find first available slot, with a preference for a requested index
- existing commander calibration methods rewrite all calibration slots
to match current sensor ordering
In some cases, the fitness of the optimizer does not shrink at each
iteration, causing the "decreasing fitness check" to fail. This stops
the optimization and returns with sub-optimal, or unrealistic results.
- handle saving the mag bias per sensor (across all estimator instances using that mag) in sensors/vehicle_magnetometer
- this is now saving back to the actual mag calibration CAL_MAGn_OFF{X,Y,Z}
- ekf2 reset mag mag bias on any magnetometer or calibration change
- use Kalman filter scheme to update stored mag bias parameters using all available bias estimates for that sensor
Co-authored-by: Paul Riseborough <gncsolns@gmail.com>
- drivers/tone_alarm: move to ModuleBase and purge CDev (/dev/tone_alarm0)
- drivers/tone_alarm: only run on tune_control publication (or scheduled note) rather than continuously
- drivers/tone_alarm: use HRT to schedule tone stop (prevents potential disruption)
- msg/tune_control: add tune_id numbering
- systemcmds/tune_control: add "error" special case tune_id
- move all tune_control publication to new uORB::PublicationQueued<>
- start tone_alarm immediately after board defaults are loaded to fix potential startup issues
- for SITL (or other boards with no TONE output) print common messages (startup, error, etc)
- this allows the default priority to be set differently for internal/external sensors
- accel and gyro initialize default priority like mag in preparation for fully supporting external sensors
- fixes#15652
- use proper Mavlink MAV_CMD_FIXED_MAG_CAL_YAW command for initiating magnetometer quick cal
- MAV_CMD_FIXED_MAG_CAL_YAW allows specifying the yaw and optionally latitude and longitude if the vehicle doesn't have GPS
- remove all remaining IOCTLs for accel and gyro and handle all calibration entirely in sensors module with parameters
- sensor_accel and sensor_gyro are now always raw sensor data
- calibration procedures no longer need to first clear existing values before starting
- temperature calibration (TC) remove all scale (SCL) parameters
- gyro and baro scale are completely unused
- regular accel calibration scale can be used (CAL_ACC*_xSCALE) instead of TC scale
Jeff Katz