11 minutes ago, MattNischan said:

I just want to be super clear: what I describe there is a method for doing this, not that any particular mod group has done it yet (or will be doing it). When I say "they" I meant what I am assuming Robert and his enterprising developer are attempting. Again, since the PID is more or less just a super low gain slight bank angle corrector (against the target bank angle from the model calculation), there is no tweaking the PID for any amount of degrees. This proposed heading override algorithm just uses the autopilot code against itself to roll out when the coder decides.

As far as the actual lateral navigation system of the default fs9gps autopilot, I think between the thorough testing here and the description from the source itself, I'd say we have pretty much a complete picture of how it works.

-Matt

When I read your algorithm, my programmer brain started jabbering like a monkey on a rock after a banana, and I forgot all about the context.  Sorry.

What you suggest is actually a great idea on the surface.  I know you can do that in the UI using Javascript.  I knew I could do it using FSUIPC LUA code.  I might mess around trying it just for fun until the next patch!

Thanks for the input and idea.

B

There is also a free Python library that can interact with SimConnect variables, if people want a more friendly programming environment and don't want to drop $25 on FSUIPC - https://pypi.org/project/SimConnect/

1 hour ago, bdwhittle64 said:

TBM 930 AP TEST RESULTS (12/07/20)

I just did a flight test in the C172 (G1000) model and found that while the heading PID was ignored, the plane still acted like there was one present -- the plane turned as usual no matter what you put in the heading PID parameters.  See my earlier post for more info on that.

 

I just saw this post and I confirm you are right. You can (at least for heading changes) completely remove or zero all the heading PID values and it will still turn. However if you reduce the roll proportional value to near zero or zero there will be a small turn or no turn. But it isn't quite so straightforward. You can manipulate both the integral and derivative controls to in effect increase the bank (although you will likely get an overshoot or an oscillation) and you can also manipulate both to lessen the effect of the early roll out. I've been tweaking this for several weeks among other things, and there is a sweet spot which partially defeats the very early return to level. But it throws up other problems too.

It takes quite a lot of lateral thinking to defeat these things!

Edited December 8, 20205 yr by robert young

8 hours ago, MattNischan said:

I just want to be super clear: what I describe there is a method for doing this, not that any particular mod group has done it yet (or will be doing it). When I say "they" I meant what I am assuming Robert and his enterprising developer are attempting. Again, since the PID is more or less just a super low gain slight bank angle corrector (against the target bank angle from the model calculation), there is no tweaking the PID for any amount of degrees. This proposed heading override algorithm just uses the autopilot code against itself to roll out when the coder decides.

As far as the actual lateral navigation system of the default fs9gps autopilot, I think between the thorough testing here and the description from the source itself, I'd say we have pretty much a complete picture of how it works.

-Matt

This, the other above comments, and the description you posted in the thread you linked to make a lot of sense (and line up with my own expectations of how this system would have been sensibly implemented). I.e. The main outer loop is likely a proper model based MIMO state space controller, or something broadly equivalent to that, and based on (probably a linearised version of) their own flight model. The inner PID loops are then just used to track the outer loop setpoints and help account for unmodelled disturbance inputs, like the gusts in their wind/weather system for example, and perhaps giving the option to fine-tune the response on a per-aircraft basis, leaving the main control common between them.

The approach you first suggested, essentially tricking the system with an artificial heading command to get the response you want sounds do-able. Though I feel it falls into the "a bit of a hack" territory, as long as the end user experience is okay then I guess it doesn't matter. We've got to work with the tools we're given, not the ones we need. There's a metaphor about watching a butcher make a sausage which I can't quite recall.

The JS API sounds pretty fully featured given all the stuff you guys have achieved. That's awesome. I'm excited to see what you guys have come up with! 

FSUIPC EXPERIMENT

I messed around this morning with a LUA program that implement Matt's idea of using  a fake heading bug change to force a greater bank until with 5 degrees of the final heading.

At first I got distracted by a different idea because there is an offset that should allow you to directly set the bank angle.  I couldn't get that to work whether in AP mode or with AP off.  Nuts.

So then I went back to Matt's idea because I knew I could set the heading bug -- I already do that with my VRInsight MCP Combo II Boeing peripheral.  Then I ran into a logic problem:

The proposed workaround needs to remember the real heading bug setting that was dialed in, but you instantly run into a problem.  Since you're using the bug to force a larger heading change in order to get a bigger bank, the logic has to add about 45 degrees to what was the real heading bug setting.  The result is that as soon as the pilot moves the heading bug past 5 degrees from the current heading, the bug is going to jump to the heading we're programmatically setting and any additional changes are going to be relative to the new bug position.

The pilot will be unable to reduce the turn with the heading knob because the logic is going to keep it 45 degrees away until within 5 degrees of heading error.  The only way to get out of it is to press the heading button off, then on again to synch the bug with the current heading.

As Nick said, this turns out to be solidly in the "hack" category and just isn't worth it if we're about to get a fix from Asobo.

ANALYSIS

More and more of the offsets and functions in the FSX SDK no longer work in MSFS.  That's not entirely unexpected, but these are exactly the kinds of problems developers have trying to do anything useful until Asobo fixes some core functionality and exposes their interface in the SDK / SimConnect / UI.  

And until they document everything!!!

My heart goes out to the mod groups and third party developers.  I sure hope they get a good Christmas present from Asobo in the form of core functionality and a well documented, much more complete SDK.  Hey Santa!  Are you listening?!

B

6 hours ago, Nick W said:

There's a metaphor about watching a butcher make a sausage which I can't quite recall.

I believe it's something like, There are two things you do not want to watch being made: laws and sausages.

I would add a third: flight sims.

B

IN CASE YOU FORGOT -- OR NEVER KNEW

For the serious pilots amongst us, until we get the fix from Asobo you can still have fun flying VFR in heading mode or IFR in VOR or GPS mode by:

1. Hand flying course and heading changes until you're within a few degrees, then switch the AP back on in HDG or NAV mode.

2. Making a turn / intercept using HDG mode the whole way and using the trick of setting the HDG bug 90 degrees or more from the desired heading, then pressing the HDG knob to instant sync the heading bug to the current heading when about 5 degrees to go.  You'll have to dial the final heading back in again, but it's just 5 degrees off.

Hey that gives me an idea.  I think I'll use FSUIPC and mess with pitch trim. Right now these flight models do not act like a real plane.  Flying by hand is not that hard in a real plane because you can trim for a climb, descent, or level flight very easily.  In MSFS it's practically impossible.

Can anyone else see how red my forehead is getting?  It's from banging my head against the wall!

B

 

Brian, a wee bit off topic, but you wouldn't be related to Frank, would you? 😉

...jim

 

42 minutes ago, bdwhittle64 said:

As Nick said, this turns out to be solidly in the "hack" category and just isn't worth it if we're about to get a fix from Asobo.

Yeah, this is why I mentioned this approach requires panel and instrument code. But it definitely can work, if you modify those things as well to track your own "heading bug" on top.

But, I'd lean the same way, it's definitely to a hack to get the thing to do what you want in this way.

-Matt

HOTFIX (12/08/20) -- QUICK TBM TEST FLIGHT RESULTS

* Heading PID still has no effect (I commented it out), so the AP logic is still directly controlling the turn behavior.

* Max bank parameters are in effect again.  

* TEST #1 -- CONTROL MAX BANK LIMIT
I had the max at 10 from my previous testing and it did limit the max bank to 10.  I changed it back to the 30, 15 (normal / reduced bank) and it worked, now limiting the max bank to 30 degrees.

* TEST #2 -- CONTROL RATE OF ROLL-IN
Not thoroughly tested, but the initial roll-in behavior seemed to match what you would get if using the acceleration and velocity parameters.

* Roll-out behavior is better, maintaining a much more reasonable bank angle until the final 10 degrees.  Better there (less time), but still very slow compared to desired roll-out to final heading.

* There was no wing rocking observed with weather clear and the wind layer deleted.  I didn't have time to try it with gusts and cloud turbulence.  Maybe tomorrow.

* And it looks like whatever they changed to keep third party aircraft (Mooney) from CTDs, it also fixed the Resync crashing as well.  I used to only be able to resync about 5 or 6 times, but during today's test flight I must have resynched at least 15 or so.  Rock solid.

I'm looking forward to hearing your feedback.

B

Todays Hotfix was not for the CTD experienced by many 3pd aircraft. There is also suppose to be another hotfix in a day or two. Hopefully that one addresses AP problems.