Automatic fixed-wing P/I/D tuning: scope and approach before implementation

[Raffi1202]

Follow-up to #12013, which was a proposal rather than a PR. The goal here is to agree on scope and approach before more code is written. Target branch for any code would be maintenance-11.x.

Problem

Fixed-wing setup today needs three separate in-flight modes (AUTO TUNE, SERVO AUTOTRIM or the FW_AUTOTRIM feature, AUTO LEVEL TRIM), and none of them sets P, I or D:

• flight/pid_autotune.c learns FF and, depending on fw_autotune_rate_adjustment, the maximum rates. P/I/D stay at defaults or at whatever the pilot enters.
• P/I/D derived from FF were removed in Don't change P, I and D during FW autotune #7461 because they flew poorly, particularly on flying wings.
• Manual P/I/D tuning with slow servos is hard to get right in practice (Overcomplicated PIDFF tuning in fixed wing #9392).

Proposed end state

After takeoff, one switch starts one sequence:

servo trim -> roll identification -> pitch identification -> rate gains -> check -> shared fw_p_level -> level trim -> servo trim re-check -> final check -> result held until landing -> pilot accepts or discards on the ground

• Roll and pitch only by default, so a two-servo flying wing is covered. No yaw.
• Stick input, the switch, failsafe/RTH or loss of eligibility end the experiment on the next control cycle and roll the settings back.
• No in-flight flash write. An unrelated config save must not persist trial gains.
• Navigation keeps the aircraft in bounded straight legs with recovery turns instead of an unbounded straight run.
• fw_i_level (filter cutoff) and fw_d_level (HORIZON transition) stay untouched.
• Out of scope for a first version: VTOL, tailsitters, rudder-only roll, stall or max-speed search, TECS-style energy control, automatic TPA/APA schedule changes.

Full requirements (state machine, session ownership, persistence, validation gates): fixed-wing-automatic-tuning.md @ a14677c

Estimator prototype

Kept on the fork branch fixed-wing-tuning-10x, not built into firmware (source, tests):

• Second-order ARX per axis: y[k] = -a1*y[k-1] - a2*y[k-2] + b1*u[k-1] + b2*u[k-2] + b3*u[k-3] + offset
• Incremental Givens QR instead of normal equations, about 200 bytes of state per axis
• Rejects too few samples, constant or rank-deficient input, unstable or marginal poles, reversed static gain and non-finite values
• Free-running validation on held-out data

Known gaps (from the review of #12013)

1. Closed-loop bias. The unit tests feed the excitation directly into an open-loop, noise-free plant, which is the one case where least-squares ARX is unbiased. In flight the PID is active, so u depends on gyro noise and the estimate is biased. Plan: use the injected excitation as instrument (IV or two-stage), plus a closed-loop test with a PID and measurement noise that shows the remaining bias at the intended SNR.
2. Replay against real logs. Blackbox already logs gyroADC, axisP/I/D/F, rcCommand and servo[] (when servo logging is enabled). The estimator should run offline against real fixed-wing logs before anything runs onboard. Open: which logging rate is realistic on F4/F7, and whether logged servo[] (after mixing and limits) or the PID sum is the better plant input.
3. Excitation, gain synthesis and acceptance thresholds are not defined. They need flight data first.

Questions

1. Is P/I/D identification for fixed wing wanted at all, or should AUTO TUNE stay FF/rate-only?
2. If yes: offline first (estimator as a log-analysis tool, with pilot-flown doublets) or onboard with automatic excitation from the start?
3. Excitation: pilot-flown doublets, injection on the rate setpoint, or injection on the PID output? Setpoint injection gives a clean instrument, but the plant input then passes through the controller.
4. Synthesis: design against a target closed-loop response, or keep INAV's FF-dominant structure (FF from the existing autotune, P/I/D only for disturbance rejection)?
5. Is the one-switch sequence the right unit, or should the first deliverable only add P/I/D to the existing AUTO TUNE mode?

Not done

• No flight, no hardware-in-the-loop, no SITL flight with the estimator. All results are unit tests against a synthetic two-lag plant.
• Excitation amplitudes and thresholds need input from people who tune fixed wings regularly before anything is proposed.

Related

• Don't change P, I and D during FW autotune #7461: FF-derived P/I/D removed
• Overcomplicated PIDFF tuning in fixed wing #9392: fixed-wing PIDFF tuning hard in practice
• Suggestion: Autotune sets TPA breakpoint  #7124: autotune setting the TPA breakpoint
• Freeze airspeed estimation in autotune mode #11124: airspeed estimate disturbed during AUTO TUNE manoeuvres
• iNAV 9.0.0 (SPEDYBEEF405WINGV2): Auto Level Trim in ANGLE leads to pitch control loss and dive; pitch PID output becomes zero, sticks not passed to servos (roll OK) #11320 (open): pitch control loss with AUTO LEVEL TRIM in ANGLE on a flying wing, relevant for the level-trim phase
• Add airspeed TPA support #11042 / Improve APA safety: pitot validation, reduced gains, safe defaults #11222: airspeed attenuation, no competing speed-scaling path intended
• Add opt-in multirotor chirp measurements #12010: multirotor chirp measurements, separate work with different excitation and controller assumptions
• PX4 fixed-wing autotune, ArduPilot Plane autotune