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)

[AndreyAgafonov]

Environment

Hardware
• FC: Speedybee F405 Wing v2
• ESC: SUMMIT 60X 60A Brushless Speed Controller
• Motor: T-Motor 2808 1300KV
• Video: DJI O3 Air Unit
• GPS: u-blox M10
• Receiver: Radiomaster RP4TD ExpressLRS 2.4GHz
• Battery: LiPo 6S 4000mAh (6S1P)
• Airframe: flying wing (elevons)

Firmware / Software
• iNAV: 9.0.0
• Target: SPEDYBEEF405WINGV2

⸻

Summary

On the first flight after build, after switching from ACRO to ANGLE and enabling AUTO LEVEL TRIM, the aircraft almost immediately lost pitch control and slowly pitched nose-down into the ground. During the dive pitch stick input did not affect servo outputs (roll still worked). Logs suggest pitch PID output goes to zero in ANGLE (both stabilization + stick mixing for pitch effectively stopped), while FC clearly “knew” the craft was falling (gyro valid, pid_error_pitch present).

⸻

Steps to Reproduce (flight sequence)
1. Takeoff, climb.
2. Switch to ANGLE, then immediately to LOITER — behavior OK.
3. Take manual control.
4. Switch to ACRO, run Autotune — behavior OK.
5. Fly a bit in ACRO — OK.
6. Switch to ANGLE.
7. Enable AUTO LEVEL TRIM.
8. Within seconds: pitch control is lost, craft begins nose-down dive, no pitch response from sticks. Crash.

I did not manage to switch back to MANUAL in time.

⸻

Expected Behavior
• Switching to ANGLE should maintain stabilized pitch attitude and should not command a pitch-down divergence.
• Enabling AUTO LEVEL TRIM should not disable pitch stabilization or stick-to-servo mixing.
• Pitch stick input should always be reflected in servo outputs according to mixer settings.

⸻

Actual Behavior
• After ANGLE + AUTO LEVEL TRIM:
• Both elevons move to a position lower than in straight ACRO flight, causing gradual nose-down tendency.
• During the dive, iNAV does not attempt to recover pitch despite valid gyro and visible pitch error.
• Pitch stick input does not pass to servos at the moment of падение.
• Roll works (stick + stabilization), problem appears pitch-only.

⸻

Observations / Evidence from Logs

Servo output positions (approx)
• Straight flight (before): 1520 / 1660
• Nose-up in ACRO: 1450 / 1750
• After switching to ANGLE: 1560 / 1630

Elevon directions
• Servo 1: value down == elevon up
• Servo 2: value up == elevon up

So after switching to ANGLE, both elevons moved “down” compared to straight ACRO, leaving the wing no option but to start lowering the nose.

ALT_TRUSTED flag
• ALT_TRUSTED intermittently dropped (likely GPS quality issues), but this should not matter for ANGLE/ACRO.

Key strange points
1. Elevons moved pitch-down when switching to ANGLE.
2. During dive, iNAV didn’t try to raise nose although it “saw” the fall (pid_error_pitch present, gyro valid).
3. At the same time, pitch stick signal was not forwarded to servos.
4. It looks like pitch PID output gets disabled in ANGLE (pitch PID term becomes zero). In ACRO there was accumulated I-term + stick signal; after entering ANGLE it becomes zeros.
5. Issue is pitch-only; roll channel continued to work.

Coordinates in logs are modified for privacy.

⸻

Questions / What I’m asking
• What could cause pitch stabilization + pitch stick mixing to effectively stop in ANGLE mode right after enabling AUTO LEVEL TRIM?
• Is this a known iNAV 9.0.0 issue on wings / SPEDYBEEF405WINGV2 target?
• Are there specific settings (mixer, servo directions, trims, AUTO LEVEL TRIM usage rules) that could explain this behavior?

⸻

Attachments
• Flight controller blackbox log
• Radio log
• iNAV configuration dump (CLI diff / full dump)

⸻

Additional Notes
• First flight after build.
• No obvious failsafes/critical errors seen in the log; log “looks clean” aside from behavior described.

dump.txt
output.csv
LOG00012.TXT

[breadoven]

I think this might be caused by the same issue as #11049 except in this case it's causing problems with the vertical position estimates. Z velocity and position in the log are erratic and obviously overflowing (see 1:27) with navEPV seemingly dropping out to 0. In fact navEPV is becoming massive causing Altitude to no longer be trusted. It only appears as 0 in the log because it's overflowing the blackbox data variable. And accVib in the log shows a lot of vibration which is the trigger for the issue in #11049. I assume the prop wasn't well balanced.

Auto level trim actually uses vertical velocity as the control datum and since this was stuck on 0 I'm guessing it confused the PID loop. There's probably an error in the code here because activation of Auto level trim doesn't appear to check if Altitude is trusted which it should do because it won't work otherwise.

The issue in #1049 should be fixed in 9.1 by #11270. In the meantime you need to ensure there isn't excessive vibration which is the main cause of the problem.

[AndreyAgafonov]

The flight controller is dual-locked on the fuselage, and I've even flown with damaged propellers when the frame was completely rippled. But I don't turn on auto level trim during these times. Perhaps this is the issue. But then again, I've never experienced such problems before.

[AndreyAgafonov]

And shouldn't the vibration have affected the roll control? The roll control continued to work during the fall.