gz plant hovers with an attitude limit-cycle (~1 rad/s roll/pitch, motor thrash 0.1↔1.0)

[avrabe]

Observed (v1.117 video/bench sessions, real gz plant)

The gz falcon-quad hover is stable in position/altitude but carries a persistent attitude limit-cycle: roll/pitch rates near 1 rad/s with the motor commands thrashing pair-wise between ~0.1 and 1.0 (saturation-to-saturation) — visible in every FC_DEBUG trace and in the release-video footage. The analytic SimBackend hover is clean (rates ≈ 0), so this is a gz-plant-specific loop-tuning issue (rate-loop gain vs the real motor lag/inertia, possibly the ADRC b0=60 reconciliation from v1.113 being right on average but marginal in phase).

Why it matters

1. It held the rotor-out FDI's near-level/low-rate gate chronically shut on gz — the FDI lost the race against the runaway detector on a genuine rotor kill (v1.117 diagnosis; worked around by widening the rate gate 1→2 rad/s, justified because the v1.115 command-aligned residual carries the false-trip protection).
2. It burns control authority + energy and looks bad in the release footage.
3. On the real X500 V2 this class of limit cycle = motor heating + vibration.

Scope

Root-cause the oscillation on the gz plant (rate-loop phase margin at 250 Hz: ADRC ω_o/ω_c/b0 vs the gz motor time constant; consider the NOTCH-P01 filtering arc), fix, and add a regression bound: steady-hover motor-command RMS deviation < some threshold in the gz smoke. Candidate for the v1.122 filtering slice or its own tuning slice.