7 hours ago, bdwhittle64 said:

 

I still want to discuss PID control in more detail, and specifically explore the two PID "boundary" parameters we have in FSX, P3D, and MSFS.  Those are the integral boundary and derivative boundary parameters see in Al's config file excerpt.

 

 

 

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

 

1 hour ago, bdwhittle64 said:

The Controller, on the other hand, is of yet very incomplete.  Do you know of any mod that allows an external physical device to control the GPS buttons?  Does Asobo even have entries in the control screens that you can bind keystrokes to?  No.  And even when they do in the configuration screens, through SimConnect, or through the SDK, the Controller calls can only trigger existing logic in the Model.  It can't change that logic.

Round and round we go -- Asobo has to make any changes to the AP logic, and has to provide triggers to that logic before any mod or third party has the tools the need.

There are no keybinds for many GPS buttons (dual rotary encoder, etc.) but some companies have written their own code to do it (Such as RealSimGear - http://help.realsimgear.com/en/articles/4460892-microsoft-flight-sim-2020-support )

MSFS needs to add the ability to bind keys t0 many of these function natively.

58 minutes ago, haklis said:

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

 

Hi, Håkon.  I was hoping to find people like you and some others that have contributed to this thread.  I've just started a new thread of my own where people who know PID control can further analyze and investigate what appears to be a core piece of MSFS technology.  In the AI.CFG file (the open ones) you can see that they use PID on brakes, steering, altitude and flight level control (2 different PIDs), auto-throttle, heading, roll, yaw, and pitch, etc.

I think my work here is pretty much done so join me over there.  The thread name is "Technical: PID control in MSFS AP".

5 hours ago, bdwhittle64 said:

Okay, so 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. 

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.

You said you didn't see the undesired behavior in the C172.  I did see the same behavior as in the other planes we've discussed.  Assuming we're talking about the same aircraft, and assuming we're using the vanilla aircraft as deployed by Asobo in patch 7, then if they don't behave the same way it comes down to use case.  I set up test cases that eliminated variable such as wind, wind gusts, thermals, cloud-generated turbulence, etc.  I also used specific heading change amounts to create reproducible experiments so anyone can verify my conclusions.

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.

ANALYSIS

I'm interested in hearing your thoughts (and others).  I'll let it percolate -- I need to eat lunch and at least do a little bit of work. I'll provide my analysis this afternoon.

B

MY ANALYSIS AND CONCLUSIONS AT THIS POINT

1.  The AP on all planes exhibit the lack of an initial roll-in to a max bank that is held constant until roll-out.

2.  The AP on all planes exhibit the extremely slow roll out for the last few degrees of heading change.

3.  ALL planes therefore have the heading bug we've discussed, and no tweaks, mods, or even third party aircraft is immune.

4.  The plane behavior clearly demonstrates that the bug is caused by PID-only turn logic.

5.  Asobo collaboration with the FBW group supports the conclusion that the bug is due to PID-only turn logic.

6.  The fact that Asobo cannot offer anything but a PID workaround until a code update is released confirmation that this is a code problem that Asobo caused, and that only Asobo can fix.

Since Robert feels no further investigation is needed on this issue, I think I should wind down my part in this thread. 

However, I'm not finished gnawing on this PID thing like a dog gnawing a bone and greasing the floor with it.  I start a new thread called "Technical: Use of PID control in MSFS APs".  You're welcome to join me there for more technical torture.

 

52 minutes ago, Phantoms said:

There are no keybinds for many GPS buttons (dual rotary encoder, etc.)

You can actually do that now using Midi device and Lorby Axis & Ohs. I have a rotary knob set for Altiude that you turn for 1000 feet, or press the knob once and it goes to 100 feet. It was surprisingly easy to set up that way.

2 hours ago, Phantoms said:

There are no keybinds for many GPS buttons (dual rotary encoder, etc.) but some companies have written their own code to do it (Such as RealSimGear - http://help.realsimgear.com/en/articles/4460892-microsoft-flight-sim-2020-support )

MSFS needs to add the ability to bind keys t0 many of these function natively.

There are keybinds for all of the AP functions (AP on/off, modes, and incrementing and decrementing the HDG, CRS, VS, FLC, etc settings).  There are also keybinds for the radio functions (increment and decrement COM/NAV and swap).  There are not keybinds for the softkeys at the bottom of the G1000, or the FMS knob, flight plan buttons etc.

So while there are things missing - you can do 90% of what is needed via controllers right now if needed.

2 hours ago, Mikeingreen said:

You can actually do that now using Midi device and Lorby Axis & Ohs. I have a rotary knob set for Altiude that you turn for 1000 feet, or press the knob once and it goes to 100 feet. It was surprisingly easy to set up that way.

Will it do the knobs such as range in the G1000 or the selector knob in the GNS530?

Edited December 5, 20205 yr by Phantoms

1 hour ago, Phantoms said:

Will it do the knobs such as range in the G1000 or the selector knob in the GNS530?

Yes, I have it set for the G3000 and another profile for the G1000. LAAO in fact makes a separate profile for each aircraft. You can save a template to help setting up each one to save time. You don't really use and axis setting but the program makes MSFS think it is a rotary using the varient that Marsman mentioned. My X-Touch has 8 rotary knobs so you can set not only ALT, but also HDG, CRS and Nav & Comm radios as well. A good thread explaining it all is here: Axis and Ohs: Help and questions - Self-Service / Peripherals - Microsoft Flight Simulator Forums.

16 hours ago, bdwhittle64 said:

I still want to discuss PID control in more detail, and specifically explore the two PID "boundary" parameters we have in FSX, P3D, and MSFS.  Those are the integral boundary and derivative boundary parameters see in Al's config file excerpt.

Nearly all of the points raised about PID issues can be solved by going back to the autopilot pre-update then making MINOR adjustments. I say again, all, or almost all of the issues reported with so-called broken autopilots, death spirals, out-of-control aircraft, over-runs, over-shoots and under-shoots by various users could have been solved by staying with the a/p as it was and then individually tuning the PID controls of the individual aircraft that suffered the reported problems. While the pre-update a/p was not perfect, it was adequate. It is now no longer adequate, but totally unuseable.

I didn't mean to imply no discussion is any longer needed altogether. What I mean is that until or unless the current a/p at least returns to its former self, no amount of analysis is going to alter or address the fundamental mistake of neutering the roll controller in a turn.

One of the main problems reported was that aircraft would start banking on a heading or Lnav command and then never stop banking, then end up in a spiral that never ends, or they would start un-controllable oscillation in roll, This is a classic case of too high a value applied probably to the integral controller of either the roll or heading PID, or both. But instead of addressing that singular problem what Asobo has done is to GLOBALLY ruin the level wings component of the Roll mode by commanding a wings level a ridiculous 40 degrees before it needs to.

This does not solve ANY of the problems reported. It just makes them look as though they were solved. In the meantime that tweak has ruined the a/p for everyone. I say again, you cannot have a simulator which claims to be viable where a simple heading change takes up to three times longer than it should.

This is like fixing the loose steering of a car by making the wheels turn so little that you cannot get around even a shallow corner.

It is entirely the wrong solution. I say yet again, the FSX a/p system was perfectly adequate for the vast majority of aircraft: defaults, large, small and the majority of addon aircraft. Where complex aircraft needed more complex a/p capability for FMC related functions, they created their own in tandem with the standard autoplilot. It worked. Flawlessly in most cases.

There is nothing wrong with PID controls in principle. They have been used for well over a century in various forms and there is a reason for that. They have proven time and time again to be an elegant and simple way to control movement and can be applied to everything from engines, to robots, to production machinery, to ships, aircraft, rockets and every conceivable application. In order for them to work, they need to be as ELEGANTLY SIMPLE as possible. The more convoluted stuff you add to the basic principle the more likely you are to get clashing controls, disturbance, oscillations and missed targets because each layer of complication introduces more unpredictability unless they are very finely tuned.

That is why the three simple controls work: Proportional to reduce the heading "error" to zero, Integral to boost the signal and/or stop over-runs where necessary, and Derivative to smooth out and damp the whole operation when needed. In order to have proper heading control all aircraft MUST BANK to turn. You cannot do it with a vague drift or yaw. You need a healthy ROLL otherwise aircraft cannot turn, and they cannot even turn properly through just a few degrees without it. By the time the current a/p heading gets to less than 5 degrees to go, the update commands an almost zero roll component. 5 degrees might not seem much, but if you observe closely, with the current a/p all aircraft mush, drift and yaw their way uncertainly over those 5 degrees. If anything THIS is causing the very yaw oscillations some are complaining about.

Even a ONE degree heading change still needs the aircraft to bank. But at one degree to go, the current a/p doesn't bank the aircraft at all. It relies on YAW to get there. Wrong!!! You still need BANK. This to me is so blindingly obvious. You cannot fix these problems by reducing the ability to bank the aeroplane. It is just plain nuts.

Edited December 5, 20205 yr by robert young

Just out of curiousity, can all issues with the AP, general flight dynamics etc be solved by changing the aircraft itself? I.e can we expect great out of the box performance when the first payware airliners show up, or is it also in the source code of the flightsim itself?

I know the FBW version is heaps better than the default, but when I fly the Toliss A321 in Xplane, there difference is MASSIVE. Now, I understand that it is not fair to compare it with a 3rd party aircraft that costs more than FS2020 itself, but my point is if the potential is there in FS as well or if the code is holding it back

Edited December 5, 20205 yr by flightsim1818

26 minutes ago, flightsim1818 said:

Just out of curiousity, can all issues with the AP, general flight dynamics etc be solved by changing the aircraft itself? I.e can we expect great out of the box performance when the first payware airliners show up, or is it also in the source code of the flightsim itself?

I know the FBW version is heaps better than the default, but when I fly the Toliss A321 in Xplane, there difference is MASSIVE. Now, I understand that it is not fair to compare it with a 3rd party aircraft that costs more than FS2020 itself, but my point is if the potential is there in FS as well or if the code is holding it back

All aircraft, wherever they come from, will suffer the same a/p issues relating to bank (or lack thereof) and heading, unless their developers can create some kind of code to over-ride what are clearly hard-coded changes by Asobo and even that looks like it is probably not possible. Without wishing to say this without going blue in the face, nothing in the PID controls or individual autopilots of the individual aircraft are going to overcome it. Which is why I implore people who care to keep the pressure, politely but firmly, on Asobo to change it at least back to where it was.

28 minutes ago, robert young said:

All aircraft, wherever they come from, will suffer the same a/p issues relating to bank (or lack thereof) and heading, unless their developers can create some kind of code to over-ride what are clearly hard-coded changes by Asobo and even that looks like it is probably not possible. Without wishing to say this without going blue in the face, nothing in the PID controls or individual autopilots of the individual aircraft are going to overcome it. Which is why I implore people who care to keep the pressure, politely but firmly, on Asobo to change it at least back to where it was.

That's not good news. Looks like I will keep FS uninstalled and stick with Xplane for a little longer then. I really hope Asobo will get this fixed because you just can't beat that scenery.

Just now, flightsim1818 said:

That's not good news. Looks like I will keep FS uninstalled and stick with Xplane for a little longer then. I really hope Asobo will get this fixed because you just can't beat that scenery.

Agreed. It is a great shame. I too have re-installed both FSX and P3d and though the visual feast is a pale shadow of MSFS, at least I can get some satisfaction and pleasure accurately and usually flawlessly flying from A to B on autopilot without all this silly heading nonsense.

Thanks guys some very interesting thoughts and and knowledge shared with us

 

14 hours ago, Phantoms said:

There are no keybinds for many GPS buttons (dual rotary encoder, etc.) but some companies have written their own code to do it (Such as RealSimGear - http://help.realsimgear.com/en/articles/4460892-microsoft-flight-sim-2020-support )

MSFS needs to add the ability to bind keys t0 many of these function natively.

There is some confusion about the difference between the autopilot controls, radio controls, and the GPS unit controls. As of this moment, NOBODY -- not RealSimGear, and not RealityXP -- can do anything but model the Garmin GPS interface and call the exposed functions or key mappings present in MSFS. If the function doesn't have a key mapping, and isn't exposed via SimConnect and in the SDK, the interface cannot activate that code.

RealSimGear quote (from your linked document) regarding current issues:

* When using the HDG knob press (heading SYNC), the heading bug is set to 0 degrees (North) instead of the current heading

* TBM panel still only has about 1/2 of its functionality

* VNAV button on G1000, GFC500/700, does not work

* FLC/IAS button on G1000, GFC500/700, does not work

* Toggling of the APR and BC only turn those modes on, not off

* Long press of CLR (or any long press) does not work

--

Those things have no key mapping and are not in SimConnect or the SDK.  They will be in there eventually, but not yet.

B