iNavFlight
Fixed-wing Angle mode, after flying normally for a while, the pitch axis suddenly dives down without warning, completely out of control.
In iNav 8.0.1 fixed-wing Angle mode, after flying normally for a while, the pitch axis suddenly dives down without warning, completely out of control.
Current Behavior
At 3:46:787 in my log and video, my fixed-wing aircraft inexplicably pitched down to -19 degrees for about 3 seconds, at that time, I was in angle mode and pulling back on the pitch to counter the dive. During those 3 seconds, the nose was raised to a level position. I intended to use the "Continuously trim servos on Fixed Wing" feature to fix the leveling issue, but after centering the stick for about 3 seconds, the system did not automatically level the aircraft; instead, it continued to accelerate into a dive. At this point, the pitch axis was completely out of control. I attempted to pull up the nose with the stick, but it had no effect, only increasing the dive angle further down, ultimately resulting in a 90-degree vertical crash to the ground. Prior to this, all three axes were functioning normally.
Steps to Reproduce
Initially, execute a roll in acro mode, then switch to angle mode and fly normally. After a few minutes, the pitch axis suddenly becomes uncontrollable. I am not sure if this can be reproduced this way, but the previous instances of this issue occurred after executing a roll in acro mode.
Expected behavior
I expect all axes to be controllable in angle mode.
Additional context
This issue has frequently occurred after upgrading to firmware 8.0, especially after performing a complete roll in acro mode and then switching to angle mode, each time resulting in an uncontrolled dive. However, in previous flights, I did not select the "Continuously trim servos on Fixed Wing" option. When I encountered this situation, switching to SERVO AUTOTRIM mode could automatically recover, but this time, having checked the "Continuously trim servos on Fixed Wing" option in the configuration, I had no opportunity to switch modes, resulting in the crash.
The horizon drift issue has completely disappeared since version 7.0, but it reappeared in 8.0.
video: https://drive.google.com/file/d/17Zcc_W43F6X0JcPMDidtaFBQN4TMzDVU/view?usp=sharing diff: https://drive.google.com/file/d/1VskCqvKygYLZPbr5vddOxnz_n-uNmrGB/view?usp=sharing log: https://drive.google.com/file/d/1IaUyQCITSKWt5BKKKI5qRKmaPevZoctk/view?usp=drive_link
Here is a video overlayed with pitch PID and other log data.
Setpoint [pitch] is green,
Heading [pitch] is red,
PID Sum [pitch] is yellow,
Gyro [pitch] is blue.
At 0:54, problems began to occur. I was still in angle mode, and pitch is out of control. After centering the stick, the nose started pointing down. Later, the dive became increasingly severe. To avoid the aircraft crashing onto the road, I could still perform a roll to adjust, but the pitch control was completely ineffective.
video: https://drive.google.com/file/d/1EVlY280eN1XhLrQw_v39DqYRblXqio6v/view?usp=sharing
Looks like it was trying to level out in the final dive but the PID control pitch up output was minimal caused by a large I term pitch down offset. Looking at the servo 1 output control movements seem minimal throughout possibly causing the small pitch up PID output to be ineffective.
This is where Manual mode is the best way of recovering from stabilisation problems rather than using auto trimming modes that will likely just make things worse.
In the final stage, the flight controller seemed unaware that it was nosediving. The PID did not respond at all to the difference between the aircraft's angle of attack and the stick input, but the pitch angle was clearly recorded approaching 90 degrees, while I was also pulling on the stick trying to raise the nose. This is definitely abnormal.
Does it mean that enabling the "Continuously trim servos on Fixed Wing" option is not a good idea?
It's not normal for the controls to lock out obviously. However, if you look at the log screen shot you can see that there is a pitch up demand, pid_sum[pitch] (-ve = pitch up), during the dive but it's small due to a significant pitch down PID_I[pitch] term which is only countered by a relatively small PID_F[pitch] term. The relatively small PID_F[pitch] term is likely caused by the fact fw_ff_pitch is set pretty low at 30. I'd expect this to be bigger otherwise you end up with limited pitch control travel. It's not obvious why the PID_I[pitch] term was stuck with a pitch down bias. Was there a pitch up trim problem ?
Personally I don't use any of the auto trim functions, prefer to mechanically trim everything correctly.
I think I've found the problem. There are two segments of abnormal PID. One segment starts from 2:20 with a full roll and goes until 2:57 when it switches back to angle mode. The other segment is from 3:38 when a full pitch stick input was manually applied until the crash. In both segments, the I value is pushed down to a very large fixed value, while the feedforward (ff) is ridiculously low and even negative, which causes the final PID sum to be extremely low. In the first segment, the pitch was still able to control the aircraft, but in the second segment, full stick input couldn't control it, leading to the crash. Why are the PID values like this in these two segments?
1 segment：
2 segment：
I think I've found the problem. There are two segments of abnormal PID. One segment starts from 2:20 with a full roll and goes until 2:57 when it switches back to angle mode. The other segment is from 3:38 when a full pitch stick input was manually applied until the crash. In both segments, the I value is pushed down to a very large fixed value, while the feedforward (ff) is ridiculously low and even negative, which causes the final PID sum to be extremely low. In the first segment, the pitch was still able to control the aircraft, but in the second segment, full stick input couldn't control it, leading to the crash. Why are the PID values like this in these two segments?
Don't forget that -ve values on pitch = pitch up so -ve PID sum and FF is climbing.
No offense intended, but it seems we are not on the same page. Here, a positive PID sum indicates that the aircraft is climbing, while a negative PID sum indicates that the aircraft is diving.
Or it could be due to the alignment issue, as my flight controller is inverted.
You're confusing attitudes with rates, they're not the same thing. PID_sum is controlling rate of pitch not pitch angle. When you apply a pitch control input in Angle it tries to maintain a given pitch angle by maintaining 0 pitch rate at that pitch angle. PID_sum can be +ve or -ve to achieve this depending on whether you're over or under the desired pitch angle and what actual pitch rates are. With the pitch stick centered it simply tries to maintain level/0 degrees pitch (or -2 degs in your case since you have fw_level_pitch_trim = 2.0). Look at 3:30 in the log as an example of this.
Either way pitch up is -ve regardless of FC orientation. Just an INAV quirk that is generally pretty confusing given it's opposite of the normal convention.
Thank you for your answer. I haven't read the INAV source code and don't have a good understanding of the underlying principles. I feel that the issues mentioned above cannot be resolved simply through configuration parameters or by improving the aircraft's physical performance, and they have occurred more than once. If anyone can help solve this problem, I would be very grateful.
Solution is fw_ff_pitch needs to be probably 3 times larger, i.e. 90+, although this does depend on the overall control setup. If that was the case in the example above with full pitch up stick then PID_F[pitch] would have been -375 rather than -125 and PID_sum[pitch] would have been -291 rather than -41. PID_sum[pitch] drives the pitch servo output based on +-500 limits so -291 makes a big difference compared to -41.