Crash during AutoTune - uncommanded pitch movement during roll tuning - ArduCopter 4.7.0-beta3

RobinIJ · October 1, 2026, 3:42pm

Follow up to my post above. I found two more issues with the same cause. Code in the rate path that assumes it runs once per main loop, which isn’t true with the fast-rate thread any more. Checked against Copter-4.7.1 and master (755258d).

rate_controller_run_dt() runs once per rate-thread sample with fast rate, but calls two helpers assuming main-loop timing:

PD boost compounds: update_throttle_gain_boost() multiplies _pd_scale by (1+ATC_THR_G_BOOST) on every rate-thread call and it is only reset once per main loop which results in (1+G_BOOST)^n, no limit (my post above). This is not confined to autotuning. It happens in normal flight as well.
Angle P boost is never applied without fast rate, compounds with fast rate: since c683d8c16 (4.7.0) _angle_P_scale is reset in rate_controller_target_reset(), right after the rate run applies the boost and before update_flight_mode() runs the angle controller. So the angle controller reads 1.0, while ATSC.AngPScX logs the boost. With fast rate the rate thread keeps multiplying after the reset. QuadPlane (Q_A_THR_G_BOOST) has the same order, so its angle P boost is also dead since 4.7.0.
THR_MIX slews too fast: update_throttle_rpy_mix() steps by the main loop _dt_s but runs at the rate loop rate, so both ramps are (rate loop / main loop) times too fast. With defaults the 0.8 s ramp down becomes 0.32 s at 1 kHz / 400 Hz, 0.16 s at 2 kHz.

Conditions: FSTRATE_ENABLE ≠ 0 for 1 and 3, ATC_THR_G_BOOST > 0 for 1 and 2 (both default 0).

Claude reproduced all three in SITL for me, on master with ATC_THR_G_BOOST = 0.4 and an extra log message for the angle P scale the angle controller actually reads. SITL’s gyro is fixed at 1 kHz, so the rate thread can’t run faster than that. To get more rate-thread runs per main loop, SCHED_LOOP_RATE was lowered instead: 400 / 200 / 100 Hz gives 2.5 / 5 / 10 runs per main loop.

Without fast rate: max ATSC.PDScX is 1.4. ATSC.AngPScX logs 1.96, but the angle controller reads 1.0 in every boosted loop.
With fast rate: max ATSC.PDScX is 1.4^8 / 1.4^9 / 1.4^16, and the angle controller reads between 1.96^1 and 1.96^6. The exponents vary with how SITL schedules the threads.
THR_MIX slews at 5.0 / 10 / 20 per s up and 1.25 / 2.5 / 5.0 per s down, instead of 2.0 and 0.5.

I’ll open a PR with a SITL test that shows the problem and a suggested fix. Just give me a couple days to get this right. I could also fly before/after logs on my 7" to not only rely on the simulations.

rmackay9 · October 1, 2026, 10:01pm

Hi @RobinIJ,

Thanks again for this. The PR is greatly appreciated!

FYI @Leonardthall @andyp1per

andyp1per · October 2, 2026, 8:25am

Hi @RobinIJ if you could leave it with me I would be grateful - you have identified several different issues here and some of them are going to get caught up with other PR’s in motion. Very nice catch!

andyp1per · October 2, 2026, 8:33am

@rmackay9 this could explain why sysid does not currently work with fast rates

andyp1per · October 2, 2026, 9:13am

github.com/ArduPilot/ardupilot

AC_AttitudeControl: fix throttle-gain boost and throttle mix with the fast rate thread (#34583)

master ← andyp1per:pr-rate-thread-gboost

opened 09:05AM - 02 Oct 26 UTC

andyp1per

+88 -23

### Summary If you fly with the fast rate thread and ATC_THR_G_BOOST set, a thr…ottle punch multiplies the roll and pitch PD gains by the boost on every rate thread run instead of once per loop, so for a moment the gains can be thousands of times their tuned value. Reported on the forum by RobinIJ, whose logs showed ATSC.PDScX of 8820 and 17287 at 4 kHz / 200 Hz, exact powers of 1.4. Separately, the angle P half of the boost has done nothing since 4.7.0, with or without the rate thread, and with the rate thread the throttle mix ramps 2.5 to 10 times faster than designed. This applies the boost once per main loop, restores the angle P boost, and slews the throttle mix with the rate controller's own dt. ### Classification & Testing (check all that apply and add your own) - [ ] Checked by a human programmer - [x] Automated test(s) verify changes (e.g. unit test, autotest) - [x] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware New autotest ThrottleGainBoostRateThread (1 kHz rate thread, 200 Hz loop, ATC_THR_G_BOOST=0.4) fails on master with a max PD scale of 10.5 and angle P scale of 111, and passes with this PR at exactly 1.4 and 1.96. It also requires the rate thread to have run, since without it the scales are 1.4 and 1.96 regardless. SITL at 1 kHz / 200 Hz: the throttle mix rose at 10.9/s on master and 1.9/s with this PR, against the intended 2.0/s. ### Description The angle P boost was lost in c683d8c16, which moved the angle P reset into rate_controller_target_reset(). That runs after the rate controller applies the boost and before the angle controller reads it, while ATSC still logged the boosted value. Anyone with ATC_THR_G_BOOST or Q_A_THR_G_BOOST set gets the angle P boost (up to 4x) back on throttle punches, as in 4.6, and the acro I scale follows it. Worth considering for 4.7.x. Detail for reviewers, not needed to review the change in outline: - The PD boost is applied to a copy inside the rate controller, so it tracks the throttle slew at the rate thread rate and writes no shared state. Angle P is only read by the angle controller, once per loop, so it is applied in a Multi override of rate_controller_target_reset(), the one per-loop hook that runs after the reset and before the angle controller. That is why the reset is virtual again. - ATSC cannot show the angle P fix. Without the rate thread, master logged AngPScX 1.96 while the angle controller read 1.0. A temporary probe inside the angle controller read 1.0 on master and 1.96 with this PR, with and without the rate thread. An ATSC assertion in ThrottleGainBoost would pass on master, so there is none. - QuadPlane's setup_rp_fw_angle_gains() sets rather than multiplies the angle P scale above low airspeed, so in those states the boost is still replaced, as it was before 4.7. - The land detector waits for the throttle mix to reach its minimum. With the rate thread, where the immediate reset does not apply, the ramp down now takes its designed time rather than a fraction of it. - Not fixed here: with the rate thread, the rate controller can still run between the per-loop reset of the PD/I scales and sysid inputs and update_flight_mode() rebuilding them. That is the follow-up PR.

github.com/ArduPilot/ardupilot

AC_AttitudeControl: record per-loop rate modifiers for the fast rate thread (#34584)

master ← andyp1per:pr-rate-thread-scale-reset

opened 09:05AM - 02 Oct 26 UTC

andyp1per

+118 -25

### Summary Depends on #34583; only the last two commits are new here. If you …fly with the fast rate thread, then for part of every main loop the rate controller runs without the landed gain reduction (ATC_LAND_*_MULT), without the acro I scaling, and without any SystemID injection. The main loop resets those modifiers early in the loop and the flight mode rebuilds them later, and the rate thread runs in between. Landed with ATC_LAND_R_MULT=0.5 in SITL at 1 kHz / 400 Hz, 10% of rate thread runs used the full PD gain. This gives the rate controller a recorded copy of the modifiers, taken as soon as update_flight_mode() has built them. ### Classification & Testing (check all that apply and add your own) - [ ] Checked by a human programmer - [x] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware SITL with temporary probes, 1 kHz rate thread, 400 Hz loop: - Landed, ATC_LAND_R_MULT=0.5, PD scale used by each rate thread run: 10% at 1.0 on master, 0 of 7753 with this PR. - SystemID RATE_ROLL chirp, delay from the mode setting a sample to the rate thread applying it: median 2.5 ms (one loop) when recorded only at the reset, 0.83 ms when recorded after update_flight_mode(). ### Description Without the rate thread, and in QuadPlane, rate_controller_run() records the modifiers immediately before running, so nothing changes there. Detail for reviewers, not needed to review the change in outline: - The record is four Vector3f copied without synchronisation, so a rate run can occasionally pair one loop's PD scale with the previous loop's I scale. Each is a valid per-loop value and it lasts one sample, against the unscaled gains and missing sysid it replaces. #34208 publishes the rate target with a sequence counter; the same mechanism can publish these once it lands. - Recording before the reset is kept so any vehicle that does not call record_rate_modifiers() still gets a complete set, one loop later. - The remaining 0.83 ms SystemID delay is because ModeSystemId logs RATE inside run(), before the record. - There is no permanent autotest. With a 1 kHz rate thread the logger drops RATE and ATSC rows independently, and a raced sample has every scale at 1.0, so ATSC skips it entirely. Both numbers above come from temporary log probes in the rate controller.

RobinIJ · October 2, 2026, 10:22am

Yes of course. Glad I could hep figure this one out.
I went through both PRs. #34583 matches what I found for all three issues, and applying the PD boost to a local copy is cleaner than what I had in mind.
#34584 fits what I see in my 7" logs: ACRO rate-loop-only at 2 kHz / 400 Hz, 13% of rate controller runs with I scale 1 instead of ATC_ANG_*_P. That’s the same gap as for the landed gain reduction.
Thanks for the quick fixes!

andyp1per · October 2, 2026, 10:32am

This also negatively impacts ACRO_OPTIONS=2 as well - so again a very good find!