Add opt-in multirotor chirp measurements

[Raffi1202]

Multirotor Blackbox experiments currently require manual stick excitation. This adds an opt-in, repeatable rate chirp on maintenance-10.x: one selected axis, two seconds to settle, then a 20-second logarithmic sweep from 2 to 60 Hz with a one-second amplitude fade at each end.

This is an experimental measurement feature, not a completed autotuner. It does not change PID gains, filters, rates or EZ-Tune values. Keeping acquisition separate allows the control-loop excitation and recorded signals to be reviewed and validated before adding an estimator or a Configurator tuning workflow.

Behavior

• Disabled by default (chirp_axis = OFF). Three settings select axis, a dedicated receiver trigger channel and peak excitation amplitude.
• Requires an armed conventional multirotor using the multirotor PID controller, manual-throttle ANGLE flight, valid receiver input and active CHIRP Blackbox recording at >=600 Hz.
• A low trigger must be observed under valid conditions before a high trigger starts a run. Completion and abort cannot restart while the trigger remains high.
• Checks pilot input, throttle changes, navigation/failsafe/mixer state, programming overrides, tilt/rate limits, motor mix headroom, logging availability, configuration/profile changes and update gaps. Excitation becomes zero on the first PID update observing an inhibit.
• Adds excitation immediately before the multicopter rate controller, after level control and setpoint limiting. Logs phase, axis, excitation, frequency, inhibit bits, actual controller setpoint/feedback and limited PID sum in the eight debug fields.
• Appends the CHIRP debug ID without renumbering existing IDs. Uses a separate parameter group; no existing configuration group is reset. No MSP payload or flight-mode ID changes.

Existing work / overlap check

I checked the 10.x source and open/closed firmware and Configurator PRs for chirp, frequency sweeps, system identification and multirotor autotuning. No existing chirp implementation was found. Related work is Q-Tune #8546, which detects oscillations from flight samples; this PR neither copies nor replaces its detector. It is also related to #10433, but this measurement-only change does not resolve the request for automatic multirotor tuning.

Validation

• 17 production-code unit tests pass via the repository CMake/GoogleTest setup, including 40 flight-adapter guard scenarios. Generator tests cover bounded output, frequency evolution, one-shot behavior, timing gaps and microsecond wrap.
• Both new test suites also pass with AddressSanitizer and UndefinedBehaviorSanitizer.
• Release builds pass with GCC 13.2.1: SPEEDYBEEF405V4, MATEKH743, IFLIGHT_BLITZ_F722_X1, ZEEZF73030V3, IFLIGHT_BLITZ_ATF435.
• macOS SITL builds and runs. Actual SITL CLI smoke check verifies defaults, invalid-setting rejection, the CHIRP debug lookup, and settings persistence across save/restart using an isolated test EEPROM.
• CLI documentation regenerated with src/utils/update_cli_docs.py and checked for reproducibility; git diff --check passes.

Reproduce the unit checks:

cmake -S . -B build/unit -DTOOLCHAIN=none
cmake --build build/unit --target chirp_unittest chirp_flight_unittest
ctest --test-dir build/unit/src/test -R '^Chirp' --output-on-failure

Why this remains a draft

No real aircraft/device tests or closed-loop flight-dynamics simulation have been performed. Target CPU cost, recording throughput and staged flight validation are still needed. Mixer headroom reflects the preceding mixer update, and Blackbox failure detection follows its normal state machine; completion is not proof of valid identification data. ANGLE feedback, CD and the configured gyro/predictor paths remain active, so the gyro/excitation ratio alone must not be treated as an open-loop plant or used directly to recommend gains. These limitations and the full logging/abort contract are documented in docs/Multirotor Chirp.md.

[github-actions]

RAM / Flash usage vs. base commit 86a0441 — commit a2ddc9c

Target	Flash Δ	RAM Δ
MATEKF405	+2368 B (+0.33%)	CCM: ±0 B (±0.00%) RAM: +48 B (+0.04%)
MATEKF722	+2024 B (+0.42%)	ITCM_RAM: +152 B (+1.22%) RAM: +32 B (+0.04%) TCM: ±0 B (±0.00%)
MATEKF765	+2328 B (+0.31%)	DTCM_RAM: ±0 B (±0.00%) SRAM1: +48 B (+0.04%)
MATEKH743	+2272 B (+0.28%)	D2_RAM: ±0 B (±0.00%) DTCM_RAM: ±0 B (±0.00%) ITCM_RAM: +120 B (+0.74%) RAM: +32 B (+0.02%)

See RAM/flash optimization guide for techniques to reduce usage.

[github-actions]

Test firmware build ready — commit a2ddc9c

Download firmware for PR #12010

250 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.