Would anyone like to partner up with me in order to fix the heading a/p issue? I have narrowed the problem down to be a likely sim var setting which would require someone with a good knowledge of simconnect , WASM and xml programming in order to change the variables that are truncating the roll mode in MSFS. I'm 100% certain that the PID values in the ai.cfg files will never solve the problem as the hard coded wing leveler over-rides anything you write to the ai.cfg file. We would need to access the code that controls the roll and wing leveler routines. I suspect there are no more than a couple of lines of code to free up the proper heading mode routines.

Please PM me if you think you can help. Many thanks.

Edited December 4, 20205 yr by robert young

Robert,

I'm not a programmer, but I do wish you luck with your efforts to tackle the A/P heading issue. 

Hans

Robert,

The code that controls the sim AP is not accessible from aircraft code, either in WASM or in JS. I don't think it would be possible to alter the rate at which the AP rolls out, since that bank angle is controlled by the internal AP control loop, using the angular distance as an input and the desired bank angle as an output.

If you have a SimVar that you think is influencing things, I'm all ears, but in my investigations changing the behavior meant writing a new AP entirely.

-Matt

1 hour ago, MattNischan said:

Robert,

The code that controls the sim AP is not accessible from aircraft code, either in WASM or in JS. I don't think it would be possible to alter the rate at which the AP rolls out, since that bank angle is controlled by the internal AP control loop, using the angular distance as an input and the desired bank angle as an output.

If you have a SimVar that you think is influencing things, I'm all ears, but in my investigations changing the behavior meant writing a new AP entirely.

-Matt

That sounds very bad news. However, looking closely at the various files involved, there is a reference to sim var  a/p controls that do address the roll or wing level parameters. I think that all is required is access to that code in order to alter the settings there. I'm fairly convinced that is what the "update" did. Of course we are all in the dark here, but there are some commands in various a/p files that all lead to sim var controls related to wing leveling. The internal AP control loop cannot be so remote as to be inaccessible. I do not possess the skills to reveal them, but I am pretty sure somebody does.

Thanks for your contribution.

Good luck in your search, Robert. I hope someone steps up.

Robert,

Can you tell me the specific simvars to which you're referring and which files appear to be affecting them? It would help if I understood more clearly what you mean here.

If you're referring to the key events for the wing leveler such as `K:AP_WING_LEVELER` or the associated sim var `AUTOPILOT WING LEVELER`, the only thing possible from aircraft code is to trigger those, which will engage wing leveling. When those get engaged automatically during lateral navigation is not within aircraft code at all. Additionally, other key events or simvars that would look interesting to use or adjust, such as `AUTOPILOT BANK HOLD` or `K:MAX_BANK_INC`/`K:MAX_BANK_DEC` can also only be set from aircraft code but aren't adjusted during the control loop.

The current sim autopilot code is in the compiled FlightSimulator.exe executable and associated DLLs. I can say with 100% certainty that there is no ability to influence it outside of PID adjustments or hacking into the executable memory at run time (very much not recommended). All of the aircraft code that currently exists does not at all contain the autopilot control loop code nor can it influence that code other than to turn AP modes on or off. This is as true for WASM as it is for JS. It's not a matter of just having sufficient tenacity or ingenuity: it simply is in the compiled executable, and that's where things stand.

I wish I had better information, but we're at the mercy of Asobo or other third parties such as ourselves, FlyByWire, and paid vendors who are experimenting now with implementing our own AFCS.

-Matt

45 minutes ago, MattNischan said:

Robert,

Can you tell me the specific simvars to which you're referring and which files appear to be affecting them? It would help if I understood more clearly what you mean here.

If you're referring to the key events for the wing leveler such as `K:AP_WING_LEVELER` or the associated sim var `AUTOPILOT WING LEVELER`, the only thing possible from aircraft code is to trigger those, which will engage wing leveling. When those get engaged automatically during lateral navigation is not within aircraft code at all. Additionally, other key events or simvars that would look interesting to use or adjust, such as `AUTOPILOT BANK HOLD` or `K:MAX_BANK_INC`/`K:MAX_BANK_DEC` can also only be set from aircraft code but aren't adjusted during the control loop.

The current sim autopilot code is in the compiled FlightSimulator.exe executable and associated DLLs. I can say with 100% certainty that there is no ability to influence it outside of PID adjustments or hacking into the executable memory at run time (very much not recommended). All of the aircraft code that currently exists does not at all contain the autopilot control loop code nor can it influence that code other than to turn AP modes on or off. This is as true for WASM as it is for JS. It's not a matter of just having sufficient tenacity or ingenuity: it simply is in the compiled executable, and that's where things stand.

I wish I had better information, but we're at the mercy of Asobo or other third parties such as ourselves, FlyByWire, and paid vendors who are experimenting now with implementing our own AFCS.

-Matt

Hi Matt, although that is rather bad news, I was hoping there might be an over-ride possibility. Are you absolutely certain that these parameters are embedded in the exe file or are there possibilities in the code within xml or related files? It looks like you are fairly certain these parameters are not alterable. I realise it is a dead end trying to alter these values via any normal user-accessible file or any cfg file. I know this having spent many hours travelling along a pointless path. Many a/p references in xml files refer constantly to the K:AP simvars values but do not specify where those variables are stored. It is most definitely those variables that control why the heading a/p settings have slowed down to a crawl.

All the discussions about ai.cfg settings and the mythical assistance to FBW only address the ai.cfg and that is not a solution. It is sticky plaster. Is the whole thing impossible? Is the only solution to persuade Asobo to reverse the update to the a/p?

Edited December 4, 20205 yr by robert young

The assistance was indeed not mythical, and Asobo provided us with the same assistance. I can tell you exactly how the current iteration of the AP works.

The AP picks a bank angle based on a formula that reads the angular distance between the desired heading and the current heading. That feeds into a control loop that is model based: it picks a an appropriate aileron output to reach a desired roll rate to achieve that bank angle based on a physically based model that matches the sim model. The PID portion of the control loop corrects only for small errors and asymmetries that the model cannot instantaneously account for. The bank angle chosen for a given heading error is thus tied to this code, which is in the executable, and does not have any external knobs that influence it. As a side note, in my AFCS research this model based approach is actually becoming quite popular in the AFCS world, and can be more stable.

It was indicated to us that a factor would be added to the aircraft cfg to control the angular error to bank angle conversion in the future. I would stress, though, that our conversations definitely do not represent any kind of guarantee of future features, support, or the like. Just relaying the information as we were given it from the nice folks there.

The ai.cfg fix was not intended to address the rate at which the turns complete (nor really can it very effectively, given the current setup); it was only meant to address the integral windup issue that caused the control loop to be unable to command but a tiny bit of roll in one of the two directions.

-Matt

Edited December 4, 20205 yr by MattNischan

1 hour ago, MattNischan said:

The assistance was indeed not mythical, and Asobo provided us with the same assistance. I can tell you exactly how the current iteration of the AP works.

The AP picks a bank angle based on a formula that reads the angular distance between the desired heading and the current heading. That feeds into a control loop that is model based: it picks a an appropriate aileron output to reach a desired roll rate to achieve that bank angle based on a physically based model that matches the sim model. The PID portion of the control loop corrects only for small errors and asymmetries that the model cannot instantaneously account for. The bank angle chosen for a given heading error is thus tied to this code, which is in the executable, and does not have any external knobs that influence it. As a side note, in my AFCS research this model based approach is actually becoming quite popular in the AFCS world, and can be more stable.

It was indicated to us that a factor would be added to the aircraft cfg to control the angular error to bank angle conversion in the future. I would stress, though, that our conversations definitely do not represent any kind of guarantee of future features, support, or the like. Just relaying the information as we were given it from the nice folks there.

The ai.cfg fix was not intended to address the rate at which the turns complete (nor really can it very effectively, given the current setup); it was only meant to address the integral windup issue that caused the control loop to be unable to command but a tiny bit of roll in one of the two directions.

-Matt

Again understood, and especially understand that you are relaying, not taking a position. But if I may, I think the "fix" was odd given that it did not address the underlying problem at all. I tried the very same PID "workaround" and all it did was to very slightly alleviate the core problem, not solve it. I don't know how many posts you've seen on this subject but I think that the "update" was totally unnecessary. The PID controls were adequate to dial out excesses already. But a global cessation of roll far too early is never going to be a solution and surely nor is a PID tweak which only slightly alleviates it.

The problem is that Asobo's a/p model does not pick an "appropriate" aileron output to reach a desired roll rate. It does the precise opposite! It picks an entirely inappropriate bank angle, so that for example even if you are within 10 degrees of an ILS capture it simply will not bank - rather it sort of yaws and drifts but then undershoots or overshoots the target. It is almost comical to watch. It doesn't work.

If you run FSX you will find that in 95% of cases the core autopilot works fine. I know people have got used to writing off FSX (and P3d) but the fact is their autopilots worked remarkably well. If you run the FSX C172 it rolls out of a turn almost perfectly, as do many more sophisticated aircraft, achieving level wings almost precisely at the point where the heading is achieved. The current a/p in MSFS begins to roll level at least 40 degrees before it needs to, and this has enormous implications for ILS capture as well. While I appreciate that the Asobo team means well, I am still baffled as to why they changed something that was not a problem in the first place.

I simply do not understand why they keep fiddling with the core autopilot which they inherited from FSX. If they simply deleted everything they have added and return to the legacy code, in my view it would be much better. I say this with no ill-intent. I am stating a view based on empirical evidence. Again though, I realise you are just passing on info and I'm not shooting the messenger!  But thanks for the heads up which I appreciate.

Edited December 4, 20205 yr by robert young

1 minute ago, robert young said:

I tried the very same PID "workaround" and all it did was to very slightly alleviate the core problem, not solve it.

Again, it was not intended to address globally sluggish heading intercept. The only thing it was intending to fix is the integral windup issue: when this was triggered you would see swift greater-than-fifty-degrees bank that would send the plane into a spiral in one direction and the inability to bank more than a few degrees in the other, no matter how much heading you dialed in.

4 minutes ago, robert young said:

It picks an entirely inappropriate bank angle, so that for example even if you are within 10 degrees of an ILS capture it simply will not bank

My assumption is, based on my AFCS work and explorations, that this method was chosen because it offers superior roll stability in a simulator environment with an unbounded set of possible flight model configurations. My other assumption, not based on any chat with Asobo, is that the existing FSX autopilot was probably incompatible for a similar reason: the choices it made did may not have commanded flight surface inputs that made sense with the new flight model, or was unable to track the less static air simulation without oscillating.

I think whether or not the angular error to bank angle curve is steep enough is probably somewhat evident: it definitely needs to be steepened, as we've all noted. However, what nobody has really noticed is that AP roll stability is definitely improved in this patch. So, things are not universally just getting worse. I agree that a few more eyes on this behavior probably would have been helpful. I would also note that they generally tend to read a lot of feedback, so I have hope that this kind of issue will be addressed.

Nonetheless, for now we don't really have much choice but to sit with our slightly lazy autopilots.

10 minutes ago, robert young said:

Again though, I realise you are just passing on info and I'm not shooting the messenger!  But thanks for the heads up which I appreciate.

But of course! I hate to see people upset or running into unsolvable and/or informationally limited problems. I definitely try to be as informative and as helpful as I can be.

-Matt

8 minutes ago, MattNischan said:

My assumption is, based on my AFCS work and explorations, that this method was chosen because it offers superior roll stability in a simulator environment with an unbounded set of possible flight model configurations. My other assumption, not based on any chat with Asobo, is that the existing FSX autopilot was probably incompatible for a similar reason: the choices it made did may not have commanded flight surface inputs that made sense with the new flight model, or was unable to track the less static air simulation without oscillating.

Just a quick response here. The roll stabiility can be adequately addressed with the flight_model.cfg. Unfortunately you cannot see it now since the update has ruined it, but prior to the update the Bonanza Turbo V3 mod captured ILS's perfectly, captured a heading perfectly and quickly, and rolled off a turn within about five degrees while never overshooting or undershooting. The Turbo mod had a very flexible yaw which could achieve a 30 degree side slip with ease, but there was no yaw or roll instability. I'm not claiming it was clever. It just took a quite a bit of tuning of the flight model in concert with the ai.cfg file. In other words, It worked without any need whatsoever to change the a/p core values before the update.

Edited December 4, 20205 yr by robert young

1 minute ago, robert young said:

The roll stabilities can be adequately addressed with the flight_model.cfg

I don't disagree with you that the plane flight model roll stability can be improved, but I was speaking of the autopilot roll stability. Not every plane will have a pristine flight model cfg, and not every plane has perfect roll stability in real life. So, you need to pick an algorithm that has the best chance of success over the largest set of input conditions.

I'm not saying it's universally the right choice in every situation, but the choice to make this change here seems completely sensible. In fact, we all wouldn't be having this discussion if the update shipped with a steeper error/bank curve, and everything else that had a less than ideal flight model would be improved for free alongside. One only needs to look at the rocking at altitude of planes like the Longitude, which seem to have been tweaked in PID gains just about every update, to understand that sometimes alternative control loops are worth investigating.

-Matt

On 12/4/2020 at 10:30 AM, MattNischan said:

The AP picks a bank angle based on a formula that reads the angular distance between the desired heading and the current heading. That feeds into a control loop that is model based: it picks a an appropriate aileron output to reach a desired roll rate to achieve that bank angle based on a physically based model that matches the sim model.

I am no expert on the specifics of programming the internals of a simulator autopilot, which in many cases requires digitally emulating what (in the real world), is often a fundamentally analog system - but I do have many years of technical experience maintaining and installing real autopilot systems, ranging from small GA to transport category aircraft.

Asobo’s explanation of how a heading change is implemented is a bit concerning, because that is not how a real autopilot works for anything other than very minor heading changes.

When changing heading, an autopilot always attempts to maintain a constant rate of turn, not a specific bank angle, (except at higher airspeeds).

Real-time rate of turn is always first and foremost in the control loop. Indeed, many autopilots in lower-performance GA aircraft monitor only the rate gyro in the turn coordinator (or AHRS), with the set point for the end of turn provided by the heading bug on the DG or HSI.

An analog DG/HSI outputs an error voltage proportional to the difference between current heading and the position of the heading bug. That error signal reduces to zero as the heading is acquired. Digital flight instruments use ARINC-429 data words for current heading, bug position etc.

More complex autopilots do directly monitor the current heading, and may factor the current vs. desired heading into the roll-out calculation, but simpler ones look only at turn rate.

For a given rate of turn, the required bank angle is directly proportional to true airspeed. 

For aircraft with true airspeeds below 150 knots, an autopilot will normally turn the aircraft at “standard rate” of 3 degrees per second. At higher airspeeds, the turn will be performed either at 1/2 standard rate (1.5 degrees per second), or at a maximum bank angle of (typically) 25 degrees. High performance jet aircraft may further reduce the maximum allowable bank angle above certain altitudes or airspeeds.

Higher airspeeds are the only flight regime where a specific  bank angle is used for autopilot-commanded heading changes - otherwise rate of turn is king, and the resulting bank angle “is what it is”.

Now, at a constant airspeed, the autopilot may indeed appear to hold a constant bank angle once the turn is established, but “behind the scenes”, rate of turn (in degrees per second) is what the autopilot is using to control the turn - not bank angle.

I certainly don’t question the the need for a variety of digital PID controllers in a software emulation of a real world hardware system. In physical analog autopilots, the “real thing” is probably easier to implement. For instance, in an analog control loop, the mathematical operations of integration and differentiation can be performed in hardware with simple resistor/capacitor networks used in conjunction with operational amplifiers.

It is interesting to note that the very first operational yaw damper created for  the B-47 bomber prototype in 1950 was literally cobbled together in two days by a Boeing engineer using a salvaged rate gyro and some off-the-shelf components. It worked very well.

 

2 hours ago, JRBarrett said:

I am no expert on the specifics of programming the internals of a simulator autopilot, which in many cases requires digitally emulating what (in the real world), is often a fundamentally analog system - but I do have many years of technical experience maintaining and installing real autopilot systems, ranging from small GA to transport category aircraft.

Asobo’s explanation of how a heading change is implemented is a bit concerning, because that is not how a real autopilot works for anything other than very minor heading changes.....etc

 

Brilliant info JRB. Thank you so much for this.

Edited December 5, 20205 yr by robert young

2 hours ago, JRBarrett said:

Asobo’s explanation of how a heading change is implemented is a bit concerning, because that is not how a real autopilot works for anything other than very minor heading changes.

Please don't take my explanation as gospel pseudo-code of the implementation.

When I say it measures angular error and commands a bank, it may very well be attempting to command a bank angle for the current airspeed that gets you to standard rate. The guts between angular error and bank angle and what is going on there I can't say.

The gist here was that the control loop that's in the feedback path is not primarily in charge of the total commanded bank, the feed-forward model based path is, so that's why there isn't presently a user-adjustable way of changing the gain of that stage.

Indeed, I agree, in some sense building this stuff with opamps and standard negative feedback paths and integrators is a ton more intuitive (if you have analog circuit experience that is, I suppose, lol). Grab me a crummy old TL072 and we'll make a nice slew limited control loop, no problem.

My honest guess from observation, though, is that the AFCS is probably set up to command a roll at a specific roll rate to the configured max bank angle, and then decrease the commanded bank angle as the angular error decreases.

-Matt