ENOUGH TALKING -- LET'S FLY!!

Nick said something in his post that sounds fun.  He said that if we wanted to understand more about how a PID works, experiment with different values.  That's what I'm going to do!

DEVELOPER MODE NEEDED

Don't forget to back up and restore your original AI.CFG file!!

Since the experiments are going to require numerous tweaks to the AI.CFG file, you can use developer mode can to avoid having to restart the sim each time. 

1. Set up your flight get (or start) in the air with the desired aircraft (I'm using a C172 for simplicity).

2. Go into settings and click on Developer.  Turn on Developer mode -- you'll get the developer menu at the top of the sim screen once you save and exit the configuration screens.

2. From the Developer File menu, start a new project.  Just accept all the defaults -- we're not actually going to do anything at the project level.

3. Click on the Developer / Tools / Aircraft Editor menu option.

4. An aircraft editor window pops up.  Left everything alone.  It will already be looking at the plane you loaded.

5. Make any desired changes to the AI.CFG file, save it, and in the aircraft editor's File menu, hit Resync.

Within about ten seconds, this will completely reload the aircraft at the current position (in flight) with the engines running.  You can resync while paused in the configuration screens if you want.  Once flying again, you may have to retrim or move throttles and stuff to get it back to a stable, but I usually just quickly hit heading select, altitude hold, then AP on and move the throttle a little bit.  Bam, I'm stable, ready for the next test.

Do this as many times as you want, but be aware that on my (pretty decent system), the sim crashes after about 10 resyncs.

EXPERIMENT SETUP

I'm going to use the same experiment setup I documented earlier.  There's a link to that post at the end of this one.

PID EXPERIMENTS

Edit: The PID parameters line in the AI.CFG file are in this order: P Gain, I Gain, D Gain, I boundary, D boundary

Tweak the nav parameters in the AI.CFG file to isolate the P logic by setting the I and D gains to 0.0.  Experiment with the P gain effect by starting level on a heading and then introduce increasing heading changes.

Do the same with the I and D parameters, setting their respective gain to 0.0 to disable it.

Don't forget to save the config file and resync each time!

Document your results, letting us know how the P logic (by itself) affected the behavior of the turn, what D does, and what I does.  The result metrics and answers that we're looking for are things like:

1. What factor(s) P, I, and/or D caused an increase or decrease in bank angle amount? 

2. Was the response a proportional response? 

3. Was the response curved or linear?

4. What was P, I, and D reacting to: 

  a. Heading error (difference between desired "set point" and current heading)? 

  b. Rate of change in the heading error (how fast it was approaching the set point)?

5. Without D or I, where did the oscillations stop, and how long did it take?

6. How does the P gain affect the bank behavior -- is it a stabilizing or destabilizing influence?

7. What was needed to eliminate wing rocking?

8. Could you find any combination of settings that produced a constant initial turn?

LET US KNOW

I suggest treating this as a lab experiment, where you write up your results in a short report rather than an interactive thread.  Then, once a significant amount of reports are submitted and read, let's start a discussion of the conclusions and educate ourselves on anything anomalous.  We've even got a PhD in the subject on this thread (Nick) that we might convince to act as the Professor.  

But most of all have fun flying around and learning more about the internals of the sim and PID control as it applies to flight behavior.

B

LINK TO EXPERIMENT SETUP

 

Edited December 5, 20205 yr by bdwhittle64
Added decode of PID parameters in AI.CFG

I'm happy to give opinions from whatever angle you feel is most helpful for everyone. I have a decent amount of control theory type experience (on this project we're using a PID for our FADEC coming up, I whipped up a pretty accurate AFCS as well in a couple days when this bug first hit to give us a potential out), have been knee deep in AP mode state machine logic for the next release of the CJ4, and of course also deal with the display side.

So pretty much whatever seems reasonable to tackle I'm happy to educate on, as well as any learnings that folks have questions on as far as the available API surfaces go at the moment.

-Matt

2 hours ago, bdwhittle64 said:

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.

Have a peek in the "systems.cfg" file, scroll to the bottom. There is an [AUTOPILOT] section. Contained within that section is:

max_bank = 25
max_bank_acceleration = 30
max_bank_velocity = 15

Is the above what you are looking for with regards to exposed max_bank set?

Have a good one!

...jim

 

4 hours ago, JimBrown said:

Have a peek in the "systems.cfg" file, scroll to the bottom. There is an [AUTOPILOT] section. Contained within that section is:

max_bank = 25
max_bank_acceleration = 30
max_bank_velocity = 15

Is the above what you are looking for with regards to exposed max_bank set?

Have a good one!

...jim

 

See?  Let that be a lesson to you.  As soon as you think I'm pretty smart and must be right about something -- be afraid.  Be very afraid. 

Thanks, Jim.  

I had said that Asobo didn't give us those settings, but clearly I was wrong.  So what can we conclude from this? I mean besides the fact that I'm a dumbass -- "He's brain dead, Jim."

It looks like FSX, P3D, and MSFS all have exposed basically the same AP control parameters, and using Occam's Razor here, pre-patch 7 they probably very, very similar AP designs and implementations.

If so, maybe Robert Young and a ton of other simmers are right about Asobo simply breaking something that didn't need fixing. Release the hounds! Let's track this down!

By the way, the Scientific Method for figuring out how the Asobo AP logic works would consists of the following steps:

1. Observe / measure the behavior of the AP (for turns).

2. Form a hypothesis that would explain the observed behavior.

3. Construct experiments that would prove that hypothesis, and state what the predicted results will be if the hypothesis is true.

4. Perform the experiments and observe / measure the results.

5. If the predicted results do not match the experimental results, then form a new hypothese and repeat from number 3.

As new data comes in, what was a good hypothesis must prove it accounts for the new data, or else a new hypothesis must created and proven.

In that vein, my original hypothesis still stands.  The AP in FSX and P3D uses the following strategies for controlling a heading change:

1. An initial, non-PID, non-linear roll-in from level to max_bank.  The bank angle goes from 0 to max_bank_velocity using an acceleration of max_bank_acceleration.

2. A second phase where the max_bank is held constrant until some number of degrees of heading error is left.

3. A final phase where PID control is used to roll out on the final heading.

The steam gauge Cessna 172 is encrypted and has no SYSTEMS.CFG file, but here is the TBM930 file.  The 930 AP has a button for reduce bank as do many airliners, so I assume the "max_bank = 30, 15" line is specifying the full bank as 30 and the reduced bank mode as 15.

TBM930 SYSTEMS.CFG FILE EXCERPT

[AUTOPILOT]
autopilot_available = 1
flight_director_available = 1
default_vertical_speed = 1000
autothrottle_available = 0
pitch_takeoff_ga = 8
max_pitch = 25
max_pitch_acceleration = 1
max_pitch_velocity_lo_alt = 2
max_pitch_velocity_hi_alt = 1.5
max_pitch_velocity_lo_alt_breakpoint = 20000
max_pitch_velocity_hi_alt_breakpoint = 28000
max_bank = 30,15
max_bank_acceleration = 5
max_bank_velocity = 10
max_throttle_rate = 0.1
yaw_damper_gain = 1
default_pitch_mode = 1
default_bank_mode = 3
autothrottle_arming_required = 0
autothrottle_takeoff_ga = 0
autothrottle_max_rpm = 90
use_no_default_bank = 1
use_no_default_pitch = 1
alt_mode_slot_index = 2
 

29 minutes ago, bdwhittle64 said:

See?  Let that be a lesson to you.  As soon as you think I'm pretty smart and must be right about something -- be afraid.  Be very afraid. 

Thanks, Jim.  

I had said that Asobo didn't give us those settings, but clearly I was wrong.  So what can we conclude from this? I mean besides the fact that I'm a dumbass -- "He's brain dead, Jim."

It looks like FSX, P3D, and MSFS all have exposed basically the same AP control parameters, and using Occam's Razor here, pre-patch 7 they probably very, very similar AP designs and implementations.

If so, maybe Robert Young and a ton of other simmers are right about Asobo simply breaking something that didn't need fixing. Release the hounds! Let's track this down!

By the way, the Scientific Method for figuring out how the Asobo AP logic works would consists of the following steps:

1. Observe / measure the behavior of the AP (for turns).

2. Form a hypothesis that would explain the observed behavior.

3. Construct experiments that would prove that hypothesis, and state what the predicted results will be if the hypothesis is true.

4. Perform the experiments and observe / measure the results.

5. If the predicted results do not match the experimental results, then form a new hypothese and repeat from number 3.

As new data comes in, what was a good hypothesis must prove it accounts for the new data, or else a new hypothesis must created and proven.

In that vein, my original hypothesis still stands.  The AP in FSX and P3D uses the following strategies for controlling a heading change:

1. An initial, non-PID, non-linear roll-in from level to max_bank.  The bank angle goes from 0 to max_bank_velocity using an acceleration of max_bank_acceleration.

2. A second phase where the max_bank is held constrant until some number of degrees of heading error is left.

3. A final phase where PID control is used to roll out on the final heading.

The steam gauge Cessna 172 is encrypted and has no SYSTEMS.CFG file, but here is the TBM930 file.  The 930 AP has a button for reduce bank as do many airliners, so I assume the "max_bank = 30, 15" line is specifying the full bank as 30 and the reduced bank mode as 15.

TBM930 SYSTEMS.CFG FILE EXCERPT

[AUTOPILOT]
autopilot_available = 1
flight_director_available = 1
default_vertical_speed = 1000
autothrottle_available = 0
pitch_takeoff_ga = 8
max_pitch = 25
max_pitch_acceleration = 1
max_pitch_velocity_lo_alt = 2
max_pitch_velocity_hi_alt = 1.5
max_pitch_velocity_lo_alt_breakpoint = 20000
max_pitch_velocity_hi_alt_breakpoint = 28000
max_bank = 30,15
max_bank_acceleration = 5
max_bank_velocity = 10
max_throttle_rate = 0.1
yaw_damper_gain = 1
default_pitch_mode = 1
default_bank_mode = 3
autothrottle_arming_required = 0
autothrottle_takeoff_ga = 0
autothrottle_max_rpm = 90
use_no_default_bank = 1
use_no_default_pitch = 1
alt_mode_slot_index = 2
 

I can remember somebody telling me that these values only affect the legacy flight model. Can't tell if thats true or not.

Also if i am not mistaken they affect HDG mode only and not AP NAV mode.

Edited December 5, 20205 yr by ThomseN_inc

5 hours ago, MattNischan said:

I'm happy to give opinions from whatever angle you feel is most helpful for everyone. I have a decent amount of control theory type experience (on this project we're using a PID for our FADEC coming up, I whipped up a pretty accurate AFCS as well in a couple days when this bug first hit to give us a potential out), have been knee deep in AP mode state machine logic for the next release of the CJ4, and of course also deal with the display side.

So pretty much whatever seems reasonable to tackle I'm happy to educate on, as well as any learnings that folks have questions on as far as the available API surfaces go at the moment.

-Matt

Thanks, Matt.  Your participation and input is appreciated.

I'm trying to do a little team-building and expert resource networking here.  I'm very technical, and very broadly (many different jobs) experienced (old), and have a private pilot's license and over 250 hours of single, dual (training), and IFR (training) time in my log book.  I often waste a lot of time trying to find an answer to my questions, much of it going spent going down blind alleys.

I'm hoping this thread brings together an expert resource network can come together in this forum when a topic of sufficient interest is raised.  I want to be like a secret society that can be summoned when one of us has engaged the enemy, and lend each other support.

Take the example of Robert and the thought that the FBW or Working Title (you) group can change the underlying code by modding the UI or tweaking PIDs.  The enemy is lack of understanding, and you did your part to educate.  But when it's not entirely successful, or maybe you're not completely sure you're entirely correct, where to you go to quickly get help?

I want this thread (and eventually an informal group) to be somewhere you can post the topic and situation, and get experts to jump in.  We could go to a thread you point us to, and make posts to support your position and help you educate.  Eventually, the more technical simmers might start reading threads we (the group or one of its members) originate to get the truth about something before subjecting themselves to all the misperceptions and negativity out there.

Overall, I want to be a positive force for MSFS, so that they are encouraged to progress and not get dragged down.  This particular sim is history in the making, and 20 years from now (I'll be 85), I want to have some good -- even if they're false -- memories of being somehow involved during its early days.  Forming a network of experts that serve as a resource to help the mod and third party dev groups would make those memories real.

B

27 minutes ago, ThomseN_inc said:

I can remember somebody telling me that these values only affect the legacy flight model. Can't tell if thats true or not.

Also if i am not mistaken they affect HDG mode only and not AP NAV mode.

Okay, here's that thing one of my ex-wives hated about me.  Instead of giving you a simple answer, I'm going to ask you to answer your own question.  If you can't after a reasonable time, then I will give you the simple answer.

YOU'VE JUST BEEN PROMOTED TO TEST PILOT

As the new test pilot, we need you to do a little preparation.

First, let's eliminate variables that might cause confusion and invalid assumptions.  Use the default C172 experiment setup documented in this thread.  You'll know you are being affected by the turn bug if:

1. There isn't a constant bank of 25 degrees (in the Cessna) in the initial part of the turn.

2. When turning to intercept the course or heading, the bank change slows WAY down with still around 5 degrees of heading change left.

3. From there it takes a minute or longer to change the final few degrees.

DOES IT AFFECT MODERN MODE OR JUST LEGACY?

Your first mission will answer that question.  Make sure your config is set to Modern mode, then go flying.  Tune in a nearby VOR, dial in a course to the VOR that is 45 degrees off your current heading.  We want to make the AP do a 45 degree turn to intercept the radial.  Set the autopilot to NAV to tell the AP to fly to, and intercept, that radial.

Write down initial bank angle, how long it held that bank angle (be prepared for it to reach a bank angle and then immediately reverse and start decreasing), the number of degrees left when it "stalled", and the total time it took to turn the whole 45 degrees.  We'll need those metrics in your second mission.

Did it exhibit the bugged behavior?  If so, you've just proven it does affect modern mode is NOT just limited to legacy!  Well done, Pilot.

DO THE NAV PARAMETERS ALSO AFFECT HEADING MODE?

This is a very good question and answer isn't obvious, so here's a little more information about APs that will make more sense.

If you think about what you're doing when intercepting a Localizer course, VOR radial or a GPS / FMS course, it's really just the AP:

1. First changing heading to an intercept track toward the desired course.

2. Then waiting until the point it decides to turn to the new heading to intercept that course.

3. Then changing heading as needed to maintain that track.

So instead of you telling the AP a new heading, it's calculating the new headings itself.  And here's the thought exercise answer -- the AP is doing the exact same thing as you do with the heading rotary dial, it's just doing it at different times to fly to, intercept, and track a radial or course. You are telling the AP what heading to fly in HDG mode, and the AP is telling itself what heading to fly.

Theoretically, since there are no separate hdg_ parameters -- just nav_ -- the AP should be using the same turn logic.  Let's test that by going flying again.

TEST PILOT MISSION 2

This one is really simple.  Get up in the air again in the C172 (same experimental setup as before).  Fly due north (or some easily seen heading), synchonize the heading bug, and turn on the AP in heading hold mode.  Wait until the aircraft is stable on that heading.

Now turn the heading bug 45 degrees from the current heading and observe the behavior just as in the other test.

Did it initially turn to a max bank of 25 degrees?  If not, then heading mode also suffers from the turn bug.  Did the measured behavior very closely match the turn made in NAV mode in the first mission?  If the max bank angle matched, if the "stall" point matched, and did total turn time match?

If so, then the nav_ parameters also control the HDG mode turns.  If the behavior was very different -- and you're sure both NAV and HDG modes made a 45 degree turn -- then there must be different parameters or logic controlling HDG mode turns.

REPORT YOUR FINDINGS

So now, based upon your expert, professional, flight test experience, how do you answer the following questions?

1. Do the nav_ parameters only affect legacy mode behavior, or are they used to also control the modern mode turns?

2. Clearly the nav_ parameters affect AP turns in NAV mode.  Do they also affect turns in HDG mode?

We await your response.

B

1 hour ago, ThomseN_inc said:

I can remember somebody telling me that these values only affect the legacy flight model. Can't tell if thats true or not.

Also if i am not mistaken they affect HDG mode only and not AP NAV mode.

Oh, no. Yet ANOTHER bonehead move by me. 

Thomsen, after reading my original response I realized you might have been referring the max_bank control parameters.  I'm leaving the original reply for anybody that wants to play with the questions and experiment with finding an answer themselves.

To answer the max_bank questions:

1. As I understand it, Legacy mode should not be used with any Asobo planes -- I've never even tried it, so I don't know.

2. Unfortunately, in the current release, we know those parameters are not used, because experiments in both NAV and HDG mode show that the max bank angle is not achieved nor held constant.

I wish we could test the pre-patch version to get those answers.  When they issue a patch that supposedly fixes the turn logic, you can bet your last dollar I'm going to be testing the heck out of it.  If you don't beat me to it, I hereby swear a Klingon blood oath to find out for you.

"I'm a simmer, not aeronautical engineer!"

B

1 hour ago, bdwhittle64 said:

2. Unfortunately, in the current release, we know those parameters are not used, because experiments in both NAV and HDG mode show that the max bank angle is not achieved nor held constant.

I beg to differ with you.

I was playing around with the max bank angle in the DA-40NG the other day. I seem to recall that, at least in HDG mode, if the change in heading is large enough (I was selecting a 180 degree change), I could get the DA to achieve a 60 degree bank. Which it held until about 30 degrees remaining to the new heading at which point it started rolling out. Too early. And taking that inexecrable long time to reach the selected heading.

I did not have the time to try it in NAV mode.

My impression (not fully tested) is that any change in heading less that 30 degrees will result in the defined max bank angle not being reached.

Tomorrow is Sunday. I may have some time to have more of a play at these settings.

Does anyone know what these entries do? What values are valid?

default_bank_mode = 3
use_no_default_bank = 1

Maybe I should install the SDK. Never done that before. Anyone know how?

...jim

 

Edited December 6, 20205 yr by JimBrown

11 hours ago, bdwhittle64 said:

Okay, here's that thing one of my ex-wives hated about me.  Instead of giving you a simple answer, I'm going to ask you to answer your own question.  If you can't after a reasonable time, then I will give you the simple answer.

YOU'VE JUST BEEN PROMOTED TO TEST PILOT

As the new test pilot, we need you to do a little preparation.

First, let's eliminate variables that might cause confusion and invalid assumptions.  Use the default C172 experiment setup documented in this thread.  You'll know you are being affected by the turn bug if:

1. There isn't a constant bank of 25 degrees (in the Cessna) in the initial part of the turn.

2. When turning to intercept the course or heading, the bank change slows WAY down with still around 5 degrees of heading change left.

3. From there it takes a minute or longer to change the final few degrees.

DOES IT AFFECT MODERN MODE OR JUST LEGACY?

Your first mission will answer that question.  Make sure your config is set to Modern mode, then go flying.  Tune in a nearby VOR, dial in a course to the VOR that is 45 degrees off your current heading.  We want to make the AP do a 45 degree turn to intercept the radial.  Set the autopilot to NAV to tell the AP to fly to, and intercept, that radial.

Write down initial bank angle, how long it held that bank angle (be prepared for it to reach a bank angle and then immediately reverse and start decreasing), the number of degrees left when it "stalled", and the total time it took to turn the whole 45 degrees.  We'll need those metrics in your second mission.

Did it exhibit the bugged behavior?  If so, you've just proven it does affect modern mode is NOT just limited to legacy!  Well done, Pilot.

DO THE NAV PARAMETERS ALSO AFFECT HEADING MODE?

This is a very good question and answer isn't obvious, so here's a little more information about APs that will make more sense.

If you think about what you're doing when intercepting a Localizer course, VOR radial or a GPS / FMS course, it's really just the AP:

1. First changing heading to an intercept track toward the desired course.

2. Then waiting until the point it decides to turn to the new heading to intercept that course.

3. Then changing heading as needed to maintain that track.

So instead of you telling the AP a new heading, it's calculating the new headings itself.  And here's the thought exercise answer -- the AP is doing the exact same thing as you do with the heading rotary dial, it's just doing it at different times to fly to, intercept, and track a radial or course. You are telling the AP what heading to fly in HDG mode, and the AP is telling itself what heading to fly.

Theoretically, since there are no separate hdg_ parameters -- just nav_ -- the AP should be using the same turn logic.  Let's test that by going flying again.

TEST PILOT MISSION 2

This one is really simple.  Get up in the air again in the C172 (same experimental setup as before).  Fly due north (or some easily seen heading), synchonize the heading bug, and turn on the AP in heading hold mode.  Wait until the aircraft is stable on that heading.

Now turn the heading bug 45 degrees from the current heading and observe the behavior just as in the other test.

Did it initially turn to a max bank of 25 degrees?  If not, then heading mode also suffers from the turn bug.  Did the measured behavior very closely match the turn made in NAV mode in the first mission?  If the max bank angle matched, if the "stall" point matched, and did total turn time match?

If so, then the nav_ parameters also control the HDG mode turns.  If the behavior was very different -- and you're sure both NAV and HDG modes made a 45 degree turn -- then there must be different parameters or logic controlling HDG mode turns.

REPORT YOUR FINDINGS

So now, based upon your expert, professional, flight test experience, how do you answer the following questions?

1. Do the nav_ parameters only affect legacy mode behavior, or are they used to also control the modern mode turns?

2. Clearly the nav_ parameters affect AP turns in NAV mode.  Do they also affect turns in HDG mode?

We await your response.

B

Unfortunately i have to decline my duties as a testpilot here as i am not willing to fiddle around anymore. I tweaked and tweaked for years in FSX and i tweaked and tweaked for weeks now in MSFS and i feel its time for Asobo to do the work now. Wake me up when those things are fixed by the Devs.

8 minutes ago, ThomseN_inc said:

Unfortunately i have to decline my duties as a testpilot here as i am not willing to fiddle around anymore. I tweaked and tweaked for years in FSX and i tweaked and tweaked for weeks now in MSFS and i feel its time for Asobo to do the work now. Wake me up when those things are fixed by the Devs.

Yeah, I'm beginning to lose enthusiasm for this as well.  There are some new developments:

The Aerosoft forums are claiming victory on their CRJ plane, although they make some telling statements:

1. They still need Asobo to make some immediate code changes if they are going to make their Christmas deadline.

2. They have been working on it 14 hours a day, 7 days a week for a long time, now.

2. Even so, the product will not be feature-complete in that timeframe.

3. They've seen Robert Young's thread (which I contributed to), and said "he is going to be surprised" by their autopilot behavior.  I don't know what that means.

4. Aerosoft made comments about our conclusions being based only on the "published SDK", implying that they have access to an unpublished one and inside info about the upcoming patch?  This is undoubtedly true and we won't hear anything more about it because of NDAs.

So I'm feeling pretty sure we'll have the AP turn behavior properly fixed in the next patch.  Since it's only two weeks or so away, as is supposedly the Aerosoft CRJ, I'm inclined to dial back and just wait.

Again, sorry for misunderstanding your original post.

B

 

31 minutes ago, bdwhittle64 said:

Yeah, I'm beginning to lose enthusiasm for this as well.  There are some new developments:

The Aerosoft forums are claiming victory on their CRJ plane, although they make some telling statements:

1. They still need Asobo to make some immediate code changes if they are going to make their Christmas deadline.

2. They have been working on it 14 hours a day, 7 days a week for a long time, now.

2. Even so, the product will not be feature-complete in that timeframe.

3. They've seen Robert Young's thread (which I contributed to), and said "he is going to be surprised" by their autopilot behavior.  I don't know what that means.

4. Aerosoft made comments about our conclusions being based only on the "published SDK", implying that they have access to an unpublished one and inside info about the upcoming patch?  This is undoubtedly true and we won't hear anything more about it because of NDAs.

So I'm feeling pretty sure we'll have the AP turn behavior properly fixed in the next patch.  Since it's only two weeks or so away, as is supposedly the Aerosoft CRJ, I'm inclined to dial back and just wait.

Again, sorry for misunderstanding your original post.

B

 

I am all good here! No offense taken! :)

QUESTION FOR THE PID EXPERTS

Assume my theoretical heading mode turn strategy of:

1. An acceleration formula to control the initial roll-in to a max bank angle.

2. Holding that bank angle until time to roll out (based on 10 degree heading change left).

3. PID control of the last 10 degrees, using PID settings tuned to that specific aircraft (in the AI.CFG file).

Now consider that strategy when used by the AP to intercept a course (localizer, VOR radial, or GPS course).

The autopilot will first command a heading change to intercept the course.  It will use the heading change strategy for that without worrying about the time or distance it takes to make the turn.  But what about knowing when to turn to the new course, and what heading will keep it on the course despite wind, etc.?

So assume we're straight and level on the heading toward our intercept point, how does the AP know when to begin the turn to intercept the course? That turn-in point calculation is based on speed, the exact time needed to turn, the effects of wind on the turn, and the final heading as corrected for wind to stay on track. 

We know the roll-in time (its a constant) and we can calculate the constant bank time based on initial heading error, but is the last 10-degree PID time constant?

If so, then the AP can somewhat accurately calculate the total distance of the turn to course, thus being able to figure out when to start the turn.

If they are not using a known PID time and heading error transition point, wouldn't that mean that the PID would have to be turned to intercept the final course without regard to the time it would take? It would start at some arbitrary distance (or time) from the intercept point, and just proportionally turn to the final course, right?

Robert Young says he thinks they've found a way to override the PID bank angle. I think I could do it using FSUIPC, but even if that works for heading mode, isn't that going to badly screw up the AP course intercept calculations?  Won't it give the behavior that's been reported before where the aircraft misses the intercept (short or long) and then flies parallel to the course at some fixed distance?

B

AEROSOFT CRJ IMPLICATIONS FOR AP BUG FIXES AND THE SDK

To quote Animal House, "All pigs are equal, but some pigs are more equal than others."

Aerosoft is an official MSFS third party partner.  It's no big surprise that they would have advance access to new information, materials, functionality, and SDK changes.  They are rather smug about it, too, which I take as a good sign for us, modders, and non-partner third-party developers.  Aerosoft is a business, and they are smug because they have a competitive advantage going into Christmas.

In case you missed it, members of Aerosoft in the forums are claiming victory on their CRJ plane, although they make some telling statements:

1. They still need Asobo to make some immediate code changes if they are going to make their Christmas deadline.

2. They have been working on it 14 hours a day, 7 days a week for a long time, now.

2. Even so, the product will not be feature-complete in that timeframe.

3. They've seen Robert Young's thread (which I contributed to), and said "he is going to be surprised" by their autopilot behavior.  I don't know what that means.

4. Aerosoft made comments about our conclusions being based only on the "published SDK", implying that they have access to an unpublished one and inside info about the upcoming patch?  This is undoubtedly true and we won't hear anything more about it because of NDAs.

So I'm feeling pretty sure we'll have the AP turn behavior properly fixed in the next patch.  Since it's only two weeks or so away, as is supposedly the Aerosoft CRJ, I'm inclined to dial back and just wait.

TEST RESULTS: HEADING PID CHANGES IN C172 G1000 MODEL

Robert Young said he thought airliner AP logic was different than small GA.  The test flight I just made says he's right, at least for the default C172 G1000 model.

I tried changing the heading PID parameters, and they had no effect.  I zeroed out all the parameters, and in HDG mode, the AP still commanded a turn.  I upped the gain on the heading parameters, and it made no difference.  The AP commanded the turn with the same behavior I've seen in the TBM and Caravan, and that has been reported for the other planes.

The roll PID parameters DID work as expected to change the behavior of the turn.

ANALYSIS

It appears that the AP on this particular plane is (right now) using some default heading control and ignoring the heading PID parameters.  Now I'm suddenly unsure about some previous testing.  I recall just tweaking the roll parameters to try to achieve some reasonable facsimile of what we had before, but once I figured out that I couldn't, I started leaving the roll PID setting alone and moved on to the heading PID.

I assumed the AP was commanding the heading PID, which in turn was commanding the roll PID.  It is definitely not that way with this plane -- or it is, but they have an internal PID that doesn't use the config file parameters.

CONSPIRACY THEORIES

Not really, but from a software development perspective, Asobo is definitely changing the way the underlying AP code works, moving away from the way FSX/P3D does it.  

The mod workarounds looked like they changed both the heading and roll PID parameters, but now I'm not sure, so I'm going to test the heading PID impact again in the C172 steam gauge plane, and in the TBM.  I'll let you know what I find out.

B