Latest Asobo update has radically changed the a/p

[leprechaunlive 1,852]

12 hours ago, bdwhittle64 said:

Leprechaun?  Sounds like you might be Irish.  Have you ever met a Frenchman?  They're all cheeky... it's what I like about them!

Dude im even worse than that. Im French, but i lived a long time in Ireland 😄

[bdwhittle64 39]

12 hours ago, ark said:

Strange, don't think that is accurate.

Yes, for example, the below is from a P3D aircraft.cfg file for a default aircraft. Tweaking these values certainly makes a difference.

[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

........

Al

Hi, Al.  This is very, very interesting to me and apparently quite a few others.

So if tweaking any of these parameters in P3D does make a difference, then as you say, they are indeed using PID control of the user aircraft.

There are a couple of things to note in this config file excerpt -- a couple of things that may indeed shed light on how FSX/P3D works (well), and exactly how Asobo went wrong.

First, look at the 3 max_bank parameters and ask yourself, Why are these parameters there, and why doesn't Asobo current have them?  Also ask, What is one of the current AP turn behaviors that we're complaining about?

Answer: During the first part of the turn when there is a larger heading "error" (difference between the current heading and the desired heading), we do not get an initial, constant bank angle.  I stated that Asobo needed to give us a way to specify such an initial bank, and then transition to PID control to roll out.

What info would such an initial turn algorithm need to give us the desired behavior?  How about max bank angle, max velocity of bank angle increase (3 degrees per second in this case), and how quickly do we go from 0 degrees bank to that 3 degrees per second (1.8 degrees per second per second, or 1.8 degrees per second squared in this case).

If my assumption is correct and this is controlling the initial part of the turn, we can predict how the algorithm should behave.  Assuming a 90 degree turn, the plane will start with a bank angle of 0, then change the bank angle until it reaches a max bank of 25 degrees (common heading change and IFR standard bank for all but slower GA aircraft).  Will it go from 0 to 25 degrees in a linear fashion -- i.e. will we reach 12.5 degrees bank at 1/2 the total time?  No.  

At 1 second, the bank will be 1.8 degrees due to the acceleration parameter.  A 2 seconds, it will be around 5.8 because during the 2nd second it would have another 1.8, but that would put the velocity over the max of 3.00.  So instead, it would accelerate another 1.2 degrees (bringing the velocity to 3 degrees per second), and then remain constant at 3 degrees from now on to the max bank.

Recap: At 1 second, 1.8 degrees bank.  At 2 seconds, around 5.8 degrees bank.  The rest of the way to max bank (25), it will use a bank velocity of 3 degrees per second.  If max bank is 25, and we've already reached 5.8, then we have 19.2 degrees to go at 3 degrees per second.  That equals 19.2 / 3.0 = 6.4 more seconds to reach max bank. 

Total time from level, rolling into the turn, and reaching a constant bank angle should therefore be the first 2 seconds of bank acceleration + 6.4 seconds of linear bank angle change = 8.4 seconds from level to max bank on the aircraft with this config file.  

Could you verify that time in P3D and report back to us?

BACK TO THE FIXED TURN VS PID CONTROL DEBATE

So the P3D documentation is wrong, and so therefore am I.  Al's new evidence shows PID is used for user aircraft, but it also seems to indicate that P3D does not use it for the initial, constant bank part of the turn.  It does have a realistic roll-in algorithm to get to the constant max bank angle rather than an instant level to 3 degrees an up behavior.

I've taken the strong position that proper, realistic, turn behavior requires non-PID control initially, followed by a transition to PID control for roll-out.  I think Al's evidence strongly supports that position, and also supports the theory that Asobo quit using the FSX/P3D turn logic and rolled their own, trying to use only PID control for the whole thing.

I think it's just as clear that what Robert says is true, although I would put it a little differently.  The old maxim, "If it ain't broke, don't fix it" would seem to apply here.  They should clean up the code as desired, but this should not be something left to coders.  The Architect and Designer should gain an understanding of what an AP is trying to accomplish with bank angle during a commanded turn.  Rather than reinventing the wheel, from a design standpoint I would look at how FSX did it (they have rights to that code base), and use that as a starting point for both behavior and coding.  Clean it up and make it your own, but the design and implementation ain't broke, so don't fix it. In the software world, there's even a name for cleaning code up without breaking it -- it's called "refactoring".

STILL TO COME

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.

 

 

 

[bdwhittle64 39]

57 minutes ago, leprechaunlive said:

Dude im even worse than that. Im French, but i lived a long time in Ireland 😄

I'm picturing the cheeky b*stard guard at the top of the castle in Monty Python's Holy Grail, but flinging sheep dung and shouting insults in a limerick style and cadence.

[leprechaunlive 1,852]

5 minutes ago, bdwhittle64 said:

I'm picturing the cheeky b*stard guard at the top of the castle in Monty Python's Holy Grail, but flinging sheep dung and shouting insults in a limerick style and cadence.

Yep, thats me but more of a Cork style tho 😄

Edited December 4, 2020 by leprechaunlive

[bdwhittle64 39]

Hey, Bert, I didn't know you were a high muckity-muck and famous and all that.  I was following up on Mars Man's idea of using RealityXP as a target for the SDK.  I went to their web site and looked up the RealityXP GNS530, and the first thing I see is a quote from you, "Sr AVSIM Staff Reviewer". 

I'm a little confused by that, however.  Are you a senior guy at AVSIM responsible for reviewing its staff members?  Or are you a senior staff member charged with reviewing stuff like the 530XP? 😎

Just kidding.  I'm going to read your review first to see if it answers the questions I have.  If not, I'll dig down on their web site.

[bdwhittle64 39]

21 hours ago, Bert Pieke said:

I see no sign of this in the C172 or Bonanza... the initial turn is at a fixed bank angle and only the last 30 degrees appear to be PID controlled.  After the latest patch still a bit slow to finish the turn, but acceptable..

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

[OSM 683]

18 minutes ago, bdwhittle64 said:

...I'm interested in hearing your thoughts (and others). 

Hi! Just want to add to your research that Asobo didn't make any changes to Carenado`s M20R and PA44 but both airplanes have the same broken autopilot.

[bdwhittle64 39]

9 minutes ago, OSM said:

Hi! Just want to add to your research that Asobo didn't make any changes to Carenado`s M20R and PA44 but both airplanes have the same broken autopilot.

Excellent point, and another important perspective to dispel the fog of confusion in these forums.  

Robert's tweaker frustration (not in the drug user sense -- at least I don't think so), Modders mod frustration, third party developer frustration, and simmer exasperation and vitriol aimed at Asobo have some clear justification.  I'm not condoning the WAY those things are expressed in the forums, but I do understand it.

If the aircraft you mentioned do indeed exhibit similar AP anomalies since the last patch, and as you say, Asobo could not have changed anything in their AI.CFG file, then we're getting very close to indisputably proving that ALL aircraft suffer the same AP defect since Patch 7.  And it follows that if the anomalous behavior persists despite PID changes to ANY aircraft, then it's not the PID settings that are at fault. 

Conclusion?  It's an AP logic code change common to all APs, and that can only have been done by Asobo.

It's easy to tell if an AP / aircraft suffers from this problem -- even with the Working Title A320NX and CJ4 mods, or the Longitude mod.  Even after collaboration with Asobo, the current work-around can only tweak the PID settings, which cannot give us the previous (correct) behavior of a constant bank angle until it's time to roll out.

So to tell if your aircraft AP logic is flawed, go into heading mode and set a new heading 45 degrees left or right of your current heading.  If it doesn't bank to around 25 degrees and stay there until within 10 degrees of the new heading, you have the problem.  Further confirmation is if it takes an eternity (a minute or more) to go the final 5 degrees, you have the problem.

Good catch, OSM!

[robert young 2,897]

8 minutes ago, bdwhittle64 said:

Excellent point, and another important perspective to dispel the fog of confusion in these forums.  

Robert's tweaker frustration (not in the drug user sense -- at least I don't think so), Modders mod frustration, third party developer frustration, and simmer exasperation and vitriol aimed at Asobo have some clear justification.  I'm not condoning the WAY those things are expressed in the forums, but I do understand it.

I do not express vitriol and I don't aim anything! If something is plain wrong I say so. That does not impute the sincerity of intent of anyone else. If I get things wrong and someone wishes to point it out, I would reflect and admit it. We all make mistakes, and I have my share of them. This is not a personal issue at all. I realise Asobo are doing their best and are probably under a lot of pressure.

[ark 1,288]

5 hours ago, bdwhittle64 said:

Total time from level, rolling into the turn, and reaching a constant bank angle should therefore be the first 2 seconds of bank acceleration + 6.4 seconds of linear bank angle change = 8.4 seconds from level to max bank on the aircraft with this config file.  

Could you verify that time in P3D and report back to us?

Yes, that time is approximately correct (a bit low maybe) as best as I could measure it. BTW, after 2 sec I think the bank would be less than 4 degs, not that this changes the overall premise here.

Al

Edited December 4, 2020 by ark

[marsman2020 1,310]

I'd strongly recommend everyone take a look at Matt's useful posts in this thread - where information provided by Asobo on the inner workings of the A/P is relayed. 

 

[JimBrown 596]

1 hour ago, bdwhittle64 said:

even with the Working Title A320NX and CJ4 mods, or the Longitude mod

Careful there... You're going to get the Fly By Wire guys upset with you. 😉

Fly By Wire are the ones doing the A320NX mod.

Working Title are the ones doing the G3000, G1000, Gx and CJ4 mods.

All the best,

...jim

[bdwhittle64 39]

2 hours ago, robert young said:

I do not express vitriol and I don't aim anything! If something is plain wrong I say so. That does not impute the sincerity of intent of anyone else. If I get things wrong and someone wishes to point it out, I would reflect and admit it. We all make mistakes, and I have my share of them. This is not a personal issue at all. I realise Asobo are doing their best and are probably under a lot of pressure.

I apologize for any misunderstanding.  I only meant to provide positive input and support your effort to figure out exactly what is wrong with the AP lateral nav issue, maybe find a workaround, but ultimately more fully understand how AP logic and flight control works -- or should work -- in MSFS.

This is your thread, so if my posts are derailing your intention, I apologize.  There is a lot more investigation and analysis to be done (I think it's fun).  Perhaps it's time for a new thread dedicated to that.

[robert young 2,897]

7 minutes ago, bdwhittle64 said:

I apologize for any misunderstanding.  I only meant to provide positive input and support your effort to figure out exactly what is wrong with the AP lateral nav issue, maybe find a workaround, but ultimately more fully understand how AP logic and flight control works -- or should work -- in MSFS.

This is your thread, so if my posts are derailing your intention, I apologize.  There is a lot more investigation and analysis to be done (I think it's fun).  Perhaps it's time for a new thread dedicated to that.

No worries. But I don't actually think there is more investigation needed. I feel that some people are over-complicating things. The issue is simple. You cannot have an autopilot that takes nearly a minute to turn a few degrees and call that a viable flight simulator. All that is needed is for the roll out on a heading capture to happen later, like it did before the update. It really is not advanced stuff.

[bdwhittle64 39]

1 hour ago, JimBrown said:

Careful there... You're going to get the Fly By Wire guys upset with you. 😉

Fly By Wire are the ones doing the A320NX mod.

Working Title are the ones doing the G3000, G1000, Gx and CJ4 mods.

All the best,

...jim

Oops!  You're right.  I meant the FBW guys, not Working Title.

Actually, that is a good segue to another little bit of software development theory that will help clarify the AP fog.  It's called the Model View Controller (MVC) design pattern and it applies here.

In the MSFS AP system, there is the:

-  Model -- the data (flight plan, internal variables, etc.), the core logic, and essentially everything other than what you see on the difference interfaces.

- View -- the visual presentations that let you see the model's data in different formats (moving maps, flight plan representation on an FMS or GPS screen).

- Controller -- the interfaces that allow you to change the model (flight plan, heading vs nav mode, etc).  It's the GPS buttons, knobs, and data entry screens.  The same things on the FMC or the Garmin 530 and 430 APs.

Right now, we have the AP View fairly complete, and good mods adding more than the default View provides.  The mods are possible on the default planes because they are done in web-based tools and the files can be edited.  The mod teams primarily use XML and Javascript to provide enhanced views.  MSFS provides pretty good support for the Model changes (flight plan legs, distances, next waypoint, nav mode, heading and alt mode activation / deactivation etc.).  So they can display a whole lot about the aircraft and what it's doing.

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.