GA Pilots "AP crashes my Plane" is NOT pilot error, its a BUG

There have been many reports of players claiming the AP Crashes their Plane, and it is often dismissed as Pilot error.

I really do not think this is the case.

The GA AP can get into an unstable state (like its servos are locked at end of travel), and when it is engaged, it instantly gives Full Aileron deflection, and the Trim runs fast to an end-stop.

While cycling the AP power does not reset it, re-loading the plane (even when flying) in Dev Mode, will RESET the AP, back to a stable state.

One way to force the AP into this unstable state is to allow the plane to CRASH, with AP on, and leave it crashed for a few minutes, before slewing back up into the air, and resuming flying.

AGREED, not realistic, but neither is the AP getting into this Unstable mode, that cannot be corrected by cycling the Aircraft electrical power.
I cannot believe that the AP is really simulating a Toppled Gyro !!

Here is a short Video, of the C172, with its AP “broken”, and it clearly shown that when the AP is now turned on.

(1) Ailerons go instantly to max deflection.
(2) Trim runs quickly to endstop.

Turning OFF the AP, the Ailerons (Yoke) instantly returns to a centered state !!

1 Like

I always play with crash damage on, maybe this is why I’ve never had any AP issues?

In any case, I haven’t experienced any autopilot issues that I couldn’t later attribute confidently to pilot error somewhere in the system or an incorrect setting, etc (excluding the random back course bug on the 787 and 320 which happens randomly, but not GA planes). I’m not saying this is your case, and I certainly don’t dismiss the possibility of a bug, I have just personally never experienced such problems in nearly 1000h of flight time, except for a hotfix to the nxi which very briefly broke it but was quickly updated and fixed. At least, any significant issues. I think minor quirks periodically are just the way it goes - in sim and IRL. But if it’s this frequent for you that seems like an issue.

Do you have to crash and then slew back up to trigger the issue?

Cheers

3 Likes

Not necessarily, but that seems to be one way to trigger the issue.

Other have reported that just turning on and off the AP, when on the ground, has a similar effect of messing up the AP, once they are in the air, and turning the AP on…

This should not happen, as one way to test the AP on the Ground (In RL), is to turn it on, and dial in a left and right heading, etc

2 Likes

Ah I see. Curious now so I will check it out.

To be fair, a lot of the time folks say AP crashed their plane I see them using AI Autopilot, which yes it crashes your plane almost always :smiley:

1 Like

I don’t currently have the problem shown in the video, but I have a Brunner yoke, and autopilot often tries to kill me through increasing levels of oscillation.
It’s not clear to me if that’s because of the sim or if it’s because the control loading software is reacting to the autopilot’s moving and creating the oscillation.

So confused why are you taking off on water with wheels?! What is going on!

I agree that there are bugs in the autopilot but there are also pilot errors operating autopilots. Sometimes it is difficult to determine if an error is a bug or a pilot error…

FWIW, IRL there are autopilot bugs (sort of frightening, IMHO). Here is an article describing a problem with the 787 autopilot flying an ILS. B787 Autopilot Problem

I have no idea how MSFS or other flight simulators are designed or where they obtain actual information about aircraft systems. This begs the question about how exactly should flight simulators model the real word. The article describes the 787 autopilot problem. Should MSFS and other simulators duplicate the real live bug in simulated 787s? Or should the real world “bug” be “fixed” in the simulators?

This is all theoretical stuff, probably with no good answers. I guess we assume that simulators simulate as best as possible a perfect world (which does not exist).

Yes. I had this the fist day after SU5. The first flight I did (in c152) was the discovery New York, because I wanted to check the promised improvements in the performance. When I noticed the AP pilot option decided to check that as well. It did not take longer than 5 minutes and the plane crashed. I have not used it since. Anyway, I like to be the pilot flying in a simulator, so it’s a feature I don’t really care about.

PC Version

I have experienced this issue. I identified what caused it for me:

DESCRIPTION OF INCIDENT:
While climbing to altitude in my P-38, I set for cruise power instead of climb power. During my introspective investigation into the incident, “it was discovered that” I had failed to complete the After Takeoff Checklist. I gradually lost all my energy. The autopilot continually compensated with nose up trim until I ultimately began to stall.

The incident was ultimately addressed by disengaging the Autopilot for the remainder of the flight. It did not result in a virtual fatal mishap.

RESULTING AFFECT ON AUTOPILOT:
After recovering from stall and returning to level flight, I engaged autopilot. It remained in full nose up trim and caused me to nearly depart controlled flight again. This condition remained and cycling the autopilot several times did not correct the issue.

UNSUCCESSFUL CORRECTIVE ACTIONS TAKEN:

  • While re-engaging autopilot, I compensated for the full trim deflection of autopilot to stay in controlled flight - hoping that the autopilot just needed time to slowly return to normal control input levels and expected behavior. I made several attempts, but this corrective action was ultimately unsuccessful.
  • Resetting the horizontal stabilizer trim to 0 after returning to level flight and prior to re-engaging the Autopilot did not resolve the problem.
  • Setting a lower altitude capture and -1700 vertical speed appeared to bring AP back to expected behavior quickly. It followed the command until reaching the lower altitude. Once reaching the set altitude, AP appeared to want to return to full nose up deflection and began pulling me up and out of controlled flight.

INITIAL THEORY OF SUSPECTED CAUSE:
The subsequent malfunction of the Autopilot’s logic by being operated to its limit was initiated as a result of Pilot error in failing to complete and follow the after take off checklist. This resulted in the continued inability of the Autopilot to maintain a desired flight path.

Since I typically fly with no failures, Modern FM, and no Flight Assists, I chalked it up as as a simulated in flight failure of my Autopilot - initiated by pilot error. I disengaged autopilot and I continued to hand fly the rest of the flight without further incident.

ADDITIONAL OBSERVATION / CONFIRMATION:
As mentioned by N6722C, engaging autopilot on the ground appears to cause issues.

I use the Logitech Multipanel. I used to be able to pre-arm Alt and VS without the autopilot engaging itself while still on the ramp after getting IFR Clearance. I observed the issue in my following flight in a Cessna 172 Classic - right after my incident in the P-38.

Lately, if I try to pre-arm Alt or VS, the Logitech Multipanel will automatically engage the Autopilot while I’m still on the ramp until I disengage it. The result is that when I engage AP after takeoff, the autopilot behaves as if it was already at a high trim deflection setting and begins to pitch or dive me out of my intended flight path and controlled flight. The autopilot appeared to return to normal functionality later after troubleshooting it at a higher altitude.

Maybe we’ll get relief in SU VII

I had this happen last night in the Carenado Arrow. In windy conditions the aircraft struggled to hold altitude. I let it go for a while as I lost then gained airspeed over a mountain range until AOA increased and I slowed to the stall warning horn and had to take over.

My trim was all messed up even with AP off and I had to keep a tremendous amount of pressure to keep the nose down and gain kinetic energy. It was hard to tell what was wind and what was the aircraft but the trim tab felt locked full nose up - flown in updrafts over mountains plenty. I should add I tried a negative climb rate in the AP before taking over and it wouldn’t drop the nose on AP.

I cycled the AP on and off several times before everything recovered and the rest of the flight went relatively smoothly.

Definitely not user error as I had been on alt hold for about an hour and in a 75% power cruise (9k ft, 7 deg. C, 2500 rpm and a bit over 21” MAP) to deal with the windy conditions.

I’ve don’t think I’ve ever had this happen to me. I say “think” because I remember a single occasion where I had used active pause mode with the AP enabled, and I left it in that state for several minutes. When I exited pause the plane rapidly nosed downwards so I disconnected AP, and re-trimmed manually.

I don’t use the AP all that much, but this was the only occasion this happened. In normal flight, not pressing pause, never.

I cannot get the AP (KAP140) in C172 to go unstable by the use of Active Pause.

However, when it does go unstable, it remains unstable, until the plane is reloaded (either by exiting FLY, or by re-loading the plane in Dev Mode)

So a poor work around is to re-load the Plane in Dev Mode. (and move on !! )

Does the instability show in the primary controls, with them lurching around the moment the AP is enabled?

Yes – watch the Video

Sorry, I should have added an audio commentary.

Watch the AP display, to see when the AP is being switched on and off.

1 Like

Have you experienced this without dev mode?

As for me, yes. I have never used developer mode.

You can see the position of the yoke snap to centre almost instantly, presumably when you turn the AP off.

That’s really weird.

Have you tried disabling AP for Pitch and Roll in the CLS Profile Manager?
That’s what works for me.

1 year ago (almost exactly) i mentioned what was wrong with the autopilot.

The problem is that the autopilot will wind up and will yeet the plane. You can see this happening in the dev menu.
I removed (dramatically reduced) the Integral part of my autopilot configs to prevent this.

1 Like

Interesting – I can see why that may help, but it may not be the correct solution to the problem.

Assuming it is the Integral “winding up”, and therefore reducing the Integral covers up the issue, then maybe the correct solution is to
(1) make sure the Integral is correctly Limited.
(2) make sure the Integral is Zeroed, when the AP is turned off / power removed.

Unfortunately, Asobo do not currently provide a way to read/write the Internals of the AP PID, so users are somewhat limited in both determining exactly what is the cause, or what a possible solution is.
(Maybe I am wrong, maybe this is exposed in some way … in Dev Menu ? )

The other question is, what causes the Integral to “wind up” into a state where it cannot unwind – and requires the plane be re-loaded, to initialize it back to zero.