Technical: PID control use in the MSFS AP

[bdwhittle64 39]

In Patch 7 (11/25/20), Asobo did something to the autopilot code that caused some adverse behavior.  Assuming a simple heading mode change of 45 degrees, the problem is exhibited by the following behavior.

1. The initial bank angle is not constant and not steep enough.  It is based on the difference between the current heading and the desired heading.  This indicates PID-only control.

2. The bank angle reduces rapidly and proportionally from max bank to a very small bank with around 5-10 degrees of heading change left to go.  This, too, strongly indicates PID-only control.

3. The last 5 degrees of heading change (the roll out to the final heading / course) takes a very, very long time (2 minutes in recent tests).

Quite a few of us has been investigating this and have come to the conclusion that patch 7 removed the FSX way of doing things and went entirely PID for the whole turn.  For context, and further discussion in this thread, FSX and P3D handled a 45 degree bank by:

1. Using a simple bank angle acceleration to a constant bank velocity change until a max bank angle was reached.

2. Maintaining that max bank until 10 degrees or so away from the desired heading.

3. Transitioning to PID control for the final 10 degree roll out.

Another use case of PID control is to maintain the commanded heading without excessive wing rocking.  The problem with PID-only control is that if you tune it for fairly acceptable heading changes, you get the wing rocking.

THE INTENT OF THIS THREAD

I see a lot of exasperation and anger expressed in the flight sim forums.  I see a lack of understanding of technical concepts such as PID control at the solo process level, and especially at the system level where one PID process feeds another PID process.  

I would like to PID control's role discussed in terms of how it is, or should be, used in flight simulator systems.  I want to start with the current AP heading control, since it is currently flawed, worked correctly until the last update, has caused Asobo to work with the Fly By Wire mod team to come up with a temporary workaround, and an official Asobo AP fix is expected in the next (Dec 22?) update.

I want to analyze the heck out of the current problem, the effectiveness of the workaround, the way P3D and FSX do it, and then once the official fix comes out, I want to analyze the fix.

THE BENEFIT OF THIS THREAD

Let's face it.  We're going to have technical bugs in this sim for a long time, and third party developers and modders need some way to gain understanding of how Asobo systems work (or don't work) despite the lack of documentation and the delay in completing the SDK. 

When something's hurting (annoying bug), it helps to rub it (at least investigate it while we wait for a fix) and get sympathy from someone (talk about it).  There are a lot of logical, technical, experienced people in this forum that would get some relief and even enjoyment by figuring out Asobo systems before even Asobo figures them out, and later analyzing a fix to see if you were right.

I love this sim already, and the way I handle a bug is to fly VFR, figure out a tweak in the config files, or jump in a forum and try to clear the fog of misunderstanding, settle the anger and frustration through objective and rational investigation and analysis.

I hope to find others in this forum that enjoys doing the same thing and join the discussion. 

[jrw4 624]

If I were to judge from this article,

https://developer.x-plane.com/article/x-plane-autopilot-params/

apparently X-Plane "works with cascaded PID controllers." What's really interesting is that the user can actually tweak the PID parameters in real time using XP's Developer menu without fussing with configurations files, etc.

So it seems that users can experiment with the parameters to their hearts' content.

Enjoy.

[marsman2020 1,310]

Excellent explanation on that X-Plane page.  Would be nice if the MSFS SDK had a similar explanation.

[bdwhittle64 39]

Here's a good experiment to duplicate my tests and discuss the results.

I researched the C172 Classic (steam gauge and Garmin 530 / 430 suite) this morning to verify if it, too, is affected by the patch 7 bug. The G1000 172 should work exactly the same.  Just use heading mode and altitude hold with the same environmental setup.

No mods, and the flight model config file is encrypted and last changed by Asobo on 11/24, the date of the patch.  The AI.CFG file is unencrypted and editable, but I have made no changes.  The file date is 8/18/20, so Asobo has not updated it since release?

Right off the bat, that tells us something important for our analysis.  Since only the PID settings have been changed by Asobo in Patch 7 and not the flight model, we're left with just two possibilities to explain any AP anomalies: the PID settings and/or code changes to the AP turn logic.

ASOBO'S AI.CFG SETTINGS FOR THE C172 AS TESTED

rollPID = 2.4, 0.3,  1.1, 8.0,  100.0
headingPID = 2.0, 0.01, 2.0, 0.2, 1.0

INITIAL TEST CONDITIONS

No wind or gusts -- achieved by creating a custom preset with clear weather, then select and delete wind layer.  Clear weather eliminates cloud turbulence and shadow thermals.

Aircraft positioned over the open ocean with no land masses nearby -- this eliminates any updrafts, downdrafts, and other terrain-caused turbulence.

TEST #1 -- 90 DEGREE HEADING CHANGE

- Roll-in: Relatively rapid increase in bank
- Max bank: 21 degrees
- Time from roll-in to max bank: 7 seconds
- Time max bank is sustained: 0 seconds
- Behavior once max banks start to decrease: 
  - Proportional decrease from max bank down to 10 degrees heading error
  - Very slow (2 minutes?) roll-out of the final 10 degrees to wings level on course
= Total time to achieve new heading: Around 3 minutes

TEST #2 -- 10 DEGREE HEADING CHANGE

- Roll-in: Very slow increase in bank
- Max bank: 5 degrees
- Time from roll-in to max bank: 10 seconds
- Time max bank is sustained: 0 seconds
- Behavior once max banks start to decrease: 
  - Very slow bank decrease to about 2 degrees
  - Very, very slow roll-out of the final 2 degrees to wings level on course
= Total time to achieve new heading: Around 2 minutes 30 seconds

TEST #3 -- CONSTANT HEADING CONTROL WITH NO WIND OR GUSTS

Stable, as expected.  No wing rocking.

TEST #4 -- CONSTANT HEADING CONTROL WITH 30 KT WIND, BUT NO GUSTS

Heading and roll stable with plane pushed off track by wing (as expected).

TEST #5 -- CONSTANT HEADING CONTROL WITH 10 KT WIND AND 50% GUSTS

Bobbing around, but no predictable wing oscillations (rocking) and heading remains within 1 degree.  Plane is pushed off ground track as expected.

[haklis 7]

Yes, that was a good article. 

Cascaded PID is another way of saying "nested control loops" which I mentioned in the other thread. 

The inner loops must be tuned and stable before moving on to the next one. It is a ton of info about control threory out there. 

Håkon

[bdwhittle64 39]

31 minutes ago, jrw4 said:

If I were to judge from this article,

https://developer.x-plane.com/article/x-plane-autopilot-params/

apparently X-Plane "works with cascaded PID controllers." What's really interesting is that the user can actually tweak the PID parameters in real time using XP's Developer menu without fussing with configurations files, etc.

So it seems that users can experiment with the parameters to their hearts' content.

Enjoy.

Now we're talking.  This is what Håkon said in the other thread:

"The initial roll rate could maybe come from the PID controller - with a bank angle limit. So initially the P part will let's say command a bank angle of 90deg for a 90deg heading change, but if the angle is capped at 25deg one will have constant bank angle with a gradusl rollout from 25deg from the target heading. 

In a control system there are often nested control loops. The actuation of the ailerons to achieve a certain bank angle is also a control loop.  However if the input -output correlation is well known this loop can be improved in response by using feed forward. This is a eg. a lookup table to give the base or open loop response and then fine tune with a pid on top with limited authority.

This was just some thoughts that popped up while reading this thread. I have done some work with PID regulators previously. The basic principles for a control loop is simple, however it can be notoriously difficult to find a stable, good performing loop under all conditions.  

Håkon"

[bdwhittle64 39]

Just now, haklis said:

Yes, that was a good article. 

Cascaded PID is another way of saying "nested control loops" which I mentioned in the other thread. 

The inner loops must be tuned and stable before moving on to the next one. It is a ton of info about control threory out there. 

Håkon

Man, I had just posted about you comment in the other thread when the notification beep went off.  You just beat me by a millisecond!

[bdwhittle64 39]

4 minutes ago, haklis said:

Yes, that was a good article. 

Cascaded PID is another way of saying "nested control loops" which I mentioned in the other thread. 

The inner loops must be tuned and stable before moving on to the next one. It is a ton of info about control threory out there. 

Håkon

We also need to discuss the concepts multiple inputs into a single PID process.  For example, a heading change may be currently commanding a 20 degree bank and the roll PID is stable at that bank.  Suddenly, turbulence rocks the wings, causing the plane to roll back to 15 degrees.  That is a raw adverse input that directly affects the roll error without going through a nested PID.  

We thus have both nested PID inputs and raw inputs into a PID process.

[haklis 7]

3 minutes ago, bdwhittle64 said:

Man, I had just posted about you comment in the other thread when the notification beep went off.  You just beat me by a millisecond!

Yeah, that was close. 

The x-plane article mentions 

• The time  as “roll response”, which is calculated based on airspeed, maximum bank angle and the parameter “roll rate”, or how fast the airplane is allowed to roll.

That would be the open loop or feed forward part. You can calculate approximately how much aileron deflection you need based on airspeed etc.,  but there will always be some atmospherical variables that changes that slightly. So in order to be precise on need a pid on top of the open loop. 

It seems like the control info is there, it is more about access to the right sim parameters and control loops I guess. I am not into modding so I don't know much about that.  

The FBW team have probably done a lot of this already.  Impressive! 

---

[haklis 7]

4 minutes ago, bdwhittle64 said:

We also need to discuss the concepts multiple inputs into a single PID process.  For example, a heading change may be currently commanding a 20 degree bank and the roll PID is stable at that bank.  Suddenly, turbulence rocks the wings, causing the plane to roll back to 15 degrees.  That is a raw adverse input that directly affects the roll error without going through a nested PID.  

We thus have both nested PID inputs and raw inputs into a PID process.

This time you posted first! 🙂

[Nick W 7]

I figured I might contribute here as I've got some experience with controls. I did my PhD on control systems engineering. I also did post-doc research in a lab where we'd hooked up X-plane to a physical fuel rig into which we could inject faults, to study the effect of damage to UAVs and how mission/flight profiles can be reconfigured autonomously when a fuel system is damaged. I've had some exposure to the topic.

PID basics

 This is a pretty good overview of PID control -> https://www.ni.com/en-th/innovations/white-papers/06/pid-theory-explained.html

"Setpoint" and "error" are the first things to know. The setpoint is the output you want, for example your heading. The error is the difference between your setpoint and you present heading. As the name implies, there's three components to PID; the proportional, integral and derivative components. They each influence the controlled inputs to the system, e.g. the ailerons, in a different way.

The proportional part just multiplies the error. If the error is large, the control action will be large. If the error is small, the control action will be small. So far so good, but the issue is that as your error gets very small, the control action becomes tiny too, so you won't 100% reach your setpoint. The integral part is used to deal with that.

The integral part looks at the error over time - you can think of it as something that multiplies the cumulative sum of error over a certain duration. A small amount of integral action will push the steady state error of the controlled system to zero, but it also causes you to overshoot your setpoint. If your integral action is too aggressive, your system will osciallate around the setpoint for quite a while before settling. In the worst case you get something called "wind up" as the controller saturates. I won't go into that other than to say its undesirable. So to deal with overshoot you've got the final component: derivative.

The derivative component looks at the rate of change of the controlled variable. You can think of it as a damper/brake. E.g. if your rate of change of heading is high, the derviative component will counteract that. This helps reduce overshoot and osciallation. The problem is that where you've got noise on your measured variable, the derivative component can see very high instantaneous rates of change, and in the worst case can cause the system to become unstable. You need to be conservative with it.

Tuning PID controllers

If you want to control a single-input-single-output (SISO) linear system, then tuning a PID control is simple - you specify your requirements in terms of response time, overshoot, settling time etc, do the maths, and you've got an optimal solution. The problem is I've never seen a linear SISO system outside of a text book. Most systems are non-linear, and I assume sim aircraft are too. What I mean by that there is a non-linear relationship between the control action and the effect on the system under control, and it varies depending on the system's state. So you have to compromise and find PID parameters that are "good enough" and the system behaves within some sensible limits. This is furthermore complicated by the fact that we're looking at a multiple-input-multiple-output (MIMO) system - you're controlling pitch, roll, yaw etc all at once, so you've got several PID controls to contend with. They're likely themselves causing further non-linearities and interactions themselves. Tuning a complex system like that is something of a black art, though there are rules of thumb you can follow (one of those is described in the link above). 

What I think Asobo are actually doing

This is just speculation, but I doubt Asobo have just designed a couple of PID loops and called it a day. We can see they definately are using PID for parts of the control scheme, given the parameter names in the config file, but I'd not be surprised if these relate to "inner loops", with extra outer loops defining the setpoints these PIDs are tracking. I've not looked through the full config, but it's possible we'd find some extra clues as to the nature of the outer loop(s) there. If I were designing this (and forced to use PID!), I'd have an outer loop dynamically selecting sensible setpoints in real-time, based on the aerodynamic properties, current state, and mechanical limits of the aircraft being simulated. They might even have some super fancy non-linear state-space calculations going on in the background - given it's a sim they do technically have access to complete comprehensive information about the state of the aircraft and it's environment, so it would be mathematically possible (albeit not in the actual spirit of a sim, because you'd not have a fully determined state vector in the real world!).

There's an additional observation. Now, I don't want to point fingers, because again this is speculation, but I think there could be an issue with how the controls are affected by the simulation rate. I think we've all seen that some aircraft in the sim "porpoise" or osciallte when left under autopilot with a high sim rate. That makes me suspect that the controllers sample rates are fixed and not in sync with the simulation rate. Basically, if you're running the sim at 8X speed, then the controller needs to sample and output at 8X it's normal rate too, if you want the controls to have the same behaviour. Oscillations like that indicate too much integral action. It's exactly what you'd see if the sample/ouput rate was effectively reduced with respect to the sim rate, and the PID parameters remained unchanged. If this is indeed the case, that's a significant oversight, albeit one which can be rectified without them needing to go right back to the drawing board.

Suggestions

If you want to identify which PID component each of the numbers in the config refer to, then adjust them individually. Just considering heading for example, if the number you've increased causes a high initial bank angle which reduces over time, then that's your proportional component. If the number you've increased results in higher levels oscillation/hunting, then that's your integral component. If the number you've changed causes the plane to invert and rip off the wings and other random instability, then that'll be the derivative component. Once you've found out which is which, then you can refer to the summary of the PID components above to figure out what you're likely to get, and tweak the parameters until you're satisfied. That said, if my assumption about these being inner loop parameters is correct, the amount we can influence the AP behaviour will be limited.

There's five values on that config item. I don't know what the reamining two are. Have Asobo provided any documentation?

I've never done any modding of MSFS, but it looks to me that all we can do is change parameters,. We can't design our own control regime from the ground up in a Lua script or similar. Is that correct?

TL;DR

The above is a long way of saying PID control nessecitates compromise. It seems to me that there's only a limited scope to change the overall AP behaviour given the tools we have available. It could be tweaked but I wouldn't expect dramatic improvements, but we could make it dramatically worse! The tweaking process would involve a lot of trial/error to get the right "feel", rather than being a mathematical excercise. I hope Asobo haven't made the error I described above, and I don't want to point fingers without more evidence, but if I'm being honest I reckon they have, which is a shame. Full documentation of the various config items would be useful and would save a lot of time when modding.

I've not modded MSFS before, but I do have approx 13 years of experience developing software, in both enterprise and safety critical engineering contexts. I've got experience with controls too. If anyone is working on AP mods (or any other mods really) and needs some help, I'd be happy to pitch in a few hours each week. I've recently got into simming for fun, so would enjoy helping out in this regard if there's a contribution I can make.

 

[bdwhittle64 39]

Welcome to the discussion, Nick!

In answer to some your questions, no, Asobo has not provided any significant documentation on the internals of the sim, and the SDK is very incomplete as yet.  It's basically a black box to us, with the AI.CFG and flight_model.cfg files as our only clue as to how the internals work. We can tweak the parameters in those files and observe the resulting behavior, and we can compare it to the behavior of FSX.  We can compare the controls and parameters we're given by Asobo to those given by FSX / P3D and try to draw conclusions.

But I want to stress that this should be fun, not work.  I am insanely curious about anything and everything.  To me, this is like Oak Island or The Divinci Code or a logic puzzle -- or a game of Clue.  I hope mod teams and even third-party developers -- heck, maybe even Asobo itself -- can make use of your contributions.  They (or at least community moderators) read these forums, so given the current AP behavior and their trying to help the FBW (A320NX) mod team with their PID settings workaround, maybe we might provide something useful for them.  Also be aware that they recently published an opening for someone with PID knowledge and experience.  It's clearly not a strength for them right now. 

If you're willing, a very valuable role for you in this thread is to continue to educate us on PID control at the plant level and in a system.  Maybe more importantly, however, as we discuss things, help us catch any incorrect assertions, theories, or assumptions.  I think most of us here have used PID control in various physical or software applications, and probably all of us have some understanding of calculus, but I would imagine very few of us have your level of understanding of the complete picture.

This sim is a work in progress that is based on old FSX code base, which used a single CG point as the aircraft.  So does P3D.  Those models did not have the "thousands of points" of control surface sensing that Asobo has added.  FSX and P3D turn behavior worked, and so did this sim until patch 7 -- or did it?  I'm with you -- I think at 1x sim rate it appears to, but at 8x it's porpoising and rocking like crazy, and even at 1x the yaw is wiggling like crazy with gusty wind or any turbulence.  These are all symptoms of PID control issues, and I think symptoms of system feedback oscillations that you don't get in a single-point model like FSX.  I assume MSFS is somewhere between FSX and X-Plane.

I suggest we have some fun analyzing the behavior and the black box of the sim, not trying to solve the problem or telling Asobo what they must do.  Sure, let's talk about how we might do it, but I wouldn't go too far down that dead end.  I have made my living for over 40 years doing software development and education -- and it is never as simple as it seems.  Business decisions ALWAYS cripple software development.  You tell the higher-ups, "This will take two years."  They say, "You've got 1 or we'll find someone who can do it in that time."  I sense that the Microsoft and Asobo teams are very good -- and getting better -- but they had to release the product in half the time with half the resources they needed.  It will get better rapidly, but they can't focus on just one area.  They're still spread too thin -- and I've been there many, many times.  Us telling them what they need to do and how to prioritize things is not something I will do.

Meanwhile, the forums are clamoring for roll-backs with every release. It's cool that we have such passion for this flight sim, and the sheer amount of clamoring does put pressure on Microsoft and Asobo to rapidly improve the sim.  See this linked thread for a good sample of the state of the forums.  It's progenitor of this thread, and is the first time I decided to post -- EVER.  (But I've been a lurker for many, many years).

 

[MattNischan 3,778]

I don't know if you all caught this thread, but I provide some explanation of how the lateral guidance works in MSFS here, straight from info provided to us by Asobo:

https://www.avsim.com/forums/topic/590931-request-for-programmer/?do=findComment&comment=4423358

-Matt

Edited December 5, 2020 by MattNischan

[bdwhittle64 39]

P3D Turn Control Parameters vs MSFS

Here is a P3D AI.CFG excerpt from Al in another thread:

[autopilot]
autopilot_available=1
......

max_bank=25.0
max_bank_acceleration=1.8
max_bank_velocity=3.00
......
nav_proportional_control=9.00
nav_integrator_control=0.25
nav_derivative_control=0.00
nav_integrator_boundary=2.50
nav_derivative_boundary=0.00
gs_proportional_control=9.52
gs_integrator_control=0.26
gs_derivative_control=0.00
gs_integrator_boundary=0.70
gs_derivative_boundary=0.00

---

The bottom parameters are the same as we have in MSFS (abbreviated FS from now on), but we don't have (at least exposed) the max_bank set.  

The observed behavior of FSX, P3D, and pre-patch FS was characterized by an initial roll-in (not linear) to the max bank (25 degrees in this case) and a constant hold of that angle until the point it started to decrease.  These parameters seem to indicate system (AP) control of when to transition from max bank to some bank decrease strategy.  From the presence of non-zero PID parameters, it's clear that the final roll-out and GS control is PID-based.

Note: In these parameters, a value of 0.0 disables the logic.

The prefix "nav" makes me believe that the AP is the one selecting the max bank hold strategy at first, then the bank decrease strategy at some point.  The fact that the Derivative (damping) factor is disabled (0.0), makes this a PI control.  The Integrator boundary parameter of 2.50 means that the Integrator is inactive unless the heading error is within 2.5 degrees of the set point (final heading / course).

Assuming no wind, gusts, or other adverse inputs, the course and heading will be the same, so let's just use heading as the set point and the feedback value.

Thoughts?

 

[bdwhittle64 39]

30 minutes ago, MattNischan said:

I don't know if you all caught this thread, but I provide some explanation of how the lateral guidance works in MSFS here, straight from info provided to us by Asobo:

https://www.avsim.com/forums/topic/590931-request-for-programmer/?do=findComment&comment=4423358

-Matt

I read it and replied in the other thread with a Model-View-Controller (software design pattern) explanation.  Robert is very inquisitive, passionate, and persistent (traits I share and admire), but he is still learning that just because you can see a view of the model, and just because someone gives you some knob to turn or button to push (controller), that does no mean that knob or button can control (modify) the model (activate some function or change the data).

We do have open CFG files for the default planes, and some useful adjustments can be made to some things, but nothing is going fix the current AP turn bug except Asobo.  The guys in this thread -- maybe we should come up with a cool name -- know we can't fix the current problem because it is absolutely needs a code change.  We dispassionately know that Asobo must fix it quickly (in the Dec 22 patch?) and they will. 

But the great majority of the forum has no thought except, It wasn't broken before, so why did you "fix" it?  Robert and those like him aren't satisfied just complaining and waiting impatiently, so they educate themselves, experiment with tweaking what they can, and expend a tremendous amount of energy trying to find a solution that doesn't depend on Asobo's timeline.  Again, traits I share and admire.

So if we can't have a solution right now, what else can we do?  We can do what you do.  I've read some of your other posts, and you do a good job trying to not just say, "Sorry, can't be done," and instead spend a lot of time trying to educate them as to why.  One of my ex-wives (yes, I've had several), used to get really annoyed at me because I never gave her a simple answer.  I had to go into teacher mode and explain beforehand why the simple answer was "no".  

I tried doing a lot of education in Robert's thread, but in the end felt I was hijacking it.  Thus this thread. 

I don't know about the others, but I would welcome your continued contributions from a UI developer perspective.  We've been discussing the Model here so far -- the AP logic in heading or nav mode -- but I'm quite certain we're going to end up spit-balling about the Controller -- the UI calling AP functions.  Examples are when you spin the heading or course know to select a new course.  When you press the Bank button to limit the AP to half banks, etc.

These thread will eventually be more appropriate in the SDK category, but for right now, since Asobo has given us a black box sim with a severely limited SDK and no documentation, we're all just guessing.

B