On 12/5/2020 at 8:37 PM, JimBrown said:

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

...jim

 

Go into the config screens and under General, the is a line at the bottom called "Developer".  Turn that on and exit config.  You should see the developer mode menu at the top of the screen.  Check the menus at the right.  One of them has an option to download the SDK.

Don't hold your breath for any documentation... yet.

FSUIPC7 exposes and documents most of what's available in the SDK, although it lags behind the release of an SDK update.  Rather than writing external C++ programs and linking it to the MSFS SDK, you can do a whole lot of stuff in FSUIPC instead.

FSUIPC (paid version) allows you to map all of your buttons and axes instead of having to do it in MSFS.  The exception is for functions where a key bind is available in MSFS, but not yet in the SDK.  In that case, you can still map buttons in FSUIPC that will send that keystroke to MSFS -- if it has the focus. 

For programming sophisticated functions, monitoring sim variables and sim UI components, it uses a compiled scripting language called LUA.  FSUIPC's LUA implementation can monitor sim and peripheral events, memory location changes, and do about anything you need if you are a knowledgeable programmer.

I highly recommend it for all levels of simmer.  The key and axis assignments (and calibration and sensitivity curves)  are worth the price alone.  For cockpit builders and advanced simmers, it's essential.

The price is currently 24.99 euros.  Now I don't know how many dollars that is, but let's just say it's pretty darn cheap for what it can do.  I've been using it for many, many years (thanks Pete and John Dowson).  It has worked for early FS versions, P3D, X-Plane, and now MSFS.

I'm not a shill for them, so I'll leave to you to use the wonderful internet and search for FSUIPC7.

Also check out the official MSFS section on the SDK, although right now all the topics are mostly about scenery development.

B

Edited December 7, 20205 yr by bdwhittle64

Thanks for the info.

I'm familiar with LUA, as it is used as a scripting addon to the Jeti Radio Control transmitter I use for my turbine jets (my other hobby). Will look into FSUIPC7.

I mentioned above that I would try to have a play with things yesterday. I did, but it was cut short. I mentioned that I had seen 60 degree banking when doing 180 degree heading changes. Not quite. I did set the max bank to 60 degrees, but would see about 55 degrees shortly after initiating the heading change, but it would roll out a bit to about 40 degrees for most of the turn, then at 30 degrees to go to the new heading would exhibit the usual slow heading capture thing.

I did the same thing with NAV by doing a direct to a waypoint directly behind me. Same behavior.

All the best,

...jim

PS. Here's my other hobby... 😉

14 minutes ago, JimBrown said:

PS. Here's my other hobby

Wow -- very impressive. Do you fly your jets in formation?!   😮

The trouble with that hobby for me is the ratio of hundreds of hours to build, and mere seconds to crash.  At least with the sim at worst I just have to restart the program. 😉

Al

Edited December 7, 20205 yr by ark

32 minutes ago, ark said:

The trouble with that hobby for me is the ratio of hundreds of hours to build, and mere seconds to crash.  At least with the sim at worst I just have to restart the program. 😉

These days it's not so bad. Those two jets came out of the box looking like that. All I had to do was install the equipment. Takes about 15 to 20 hours. Which is fine by me, as I prefer flying to building.

Oh, and yeah, this hobby is the definition of "disposable income". 😉

...jim

 

On 12/6/2020 at 7:03 AM, bdwhittle64 said:

Assume my theoretical heading mode turn strategy of:

My understanding of the lateral nav, from our interaction with Asobo, is more like:

1. AP reads angular error between desired heading and current.

2. The AP formulaically generates a desired roll angle based on that error, clamped at the max roll angle configured in the cfgs.

3. The AP commands an aileron output based on a flight/aero model to roll towards the bank angle at a sensible rate, modulated by the error between the desired bank angle and the current bank angle.

4. The bank PID has extremely limited output gain, and only has enough gain authority to correct for small errors in the desired bank angle due to things like turbulence or other asymmetries.

The fact that the PID did not appreciably change the behavior of the turn when disabled is a result of the above.

5 hours ago, bdwhittle64 said:

Robert Young said he thought airliner AP logic was different than small GA.

This is incorrect. All planes in the sim use the same fs9gps based autopilot system, GA, airliner, or otherwise. There are no airplanes in the wild right now not using the stock fs9gps AP, except for the FBW A320NX while in fly-by-wire mode.

 

On 12/6/2020 at 7:14 AM, bdwhittle64 said:

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.

I take that to mean that either they've worked with Asobo to tune the autopilot algorithms or that they've built their own AFCS. I don't think there probably are any other options there.

 

On 12/6/2020 at 7:03 AM, bdwhittle64 said:

Robert Young says he thinks they've found a way to override the PID bank angle.

You can't override the PID bank angle, since the PID more or less doesn't control the bank angle now, but you can do what they are trying: you can take over the AP panel to generate an excessive desired heading, and then cancel out the excess when you want the plane to roll out.

So, the algorithm would effectively be:

* When a user selects any left or right turn heading, take the desired heading, save it, and instead send to the real AP a max heading diff turn (via the key event K:HEADING_BUG_SET): so, if it's a left turn, always send the AP -179 degrees from current heading, if it's a right turn, send the AP +179 degrees from current heading. Every frame, keep pegging the turn to +/- 179 based on the turn direction. This will keep the bank angle maximized during the turn, since the angular error never really gets smaller.

* When within a much more sensible distance to the actual desired heading, say 10 degrees or so, cancel all the excess heading being fed to the AP by using K:HEADING_BUG_SET again to set the actual desired heading. This will cause the AP to roll out, make the rollout start much later than if you had let it do it normally.

The issue with this is it isn't just a nice simple ai.cfg change, you're talking panel customization for sure and potentially custom JS or WASM code, if you don't want to run that whole loop in goofy reverse polish notation XML. It is a solution, though.

-Matt

1 hour ago, MattNischan said:

So, the algorithm would effectively be:

* When a user selects any left or right turn heading, take the desired heading, save it, and instead send to the real AP a max heading diff turn (via the key event K:HEADING_BUG_SET): so, if it's a left turn, always send the AP -179 degrees from current heading, if it's a right turn, send the AP +179 degrees from current heading. Every frame, keep pegging the turn to +/- 179 based on the turn direction. This will keep the bank angle maximized during the turn, since the angular error never really gets smaller.

* When within a much more sensible distance to the actual desired heading, say 10 degrees or so, cancel all the excess heading being fed to the AP by using K:HEADING_BUG_SET again to set the actual desired heading. This will cause the AP to roll out, make the rollout start much later than if you had let it do it normally.

The issue with this is it isn't just a nice simple ai.cfg change, you're talking panel customization for sure and potentially custom JS or WASM code, if you don't want to run that whole loop in goofy reverse polish notation XML. It is a solution, though.

-Matt

Great information, Matt.  This explains my recent test results with the C172 and the TBM.  See my next post on the TBM results.

7 hours ago, bdwhittle64 said:

 

 

Edited December 7, 20205 yr by robert young

1 hour ago, MattNischan said:

7 hours ago, bdwhittle64 said:

Robert Young said he thought airliner AP logic was different than small GA.

This is incorrect. All planes in the sim use the same fs9gps based autopilot system, GA, airliner, or otherwise. There are no airplanes in the wild right now not using the stock fs9gps AP, except for the FBW A320NX while in fly-by-wire mode.

I didn't actually say that! I said that the "special case" of the modded A320 was probably different because of their custom (FBW) programming. Matt is right - all aircraft apart from rare special cases use the standard a/p coding.

You can't override the PID bank angle.......

I didn't say you could do this either!

 

 

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.

TBM TEST FLIGHT

The TBM test flight confirms the same thing -- the heading PID parameters are ignored, but the plane still turns with a roll (bank) proportional to the heading error below 90 degrees.  It went very close to 30 degrees bank at 90.  With 10 degrees left in the turn, the plane does a little wobble in the bank angle, then continues with the very slow, then very, very slow roll out.

Above 90 degrees the bank angle reaches a constant 30 degrees until it reaches 89 degrees left in the turn, then it does the proportional PID behavior described above.

TBM MAX BANK, ACCELERATION, AND VELOCITY PARAMETERS

Jim pointed out that those parameters are in the SYSTEMS.CFG file.  I tested them and they had no effect -- no effect -- on the TBM turn.  The clear proof of this is that the observed behavior during a turn greater than 90 degrees was the the constant max bank was 30 degrees.  I tested it with the max_bank set to 25, 15, and 10 -- it had no effect and still went to 30.

ANALYSIS

The AP is not commanding the heading PID to control the turn.  It's doing it itself.  The only config file tweaks we can make to affect the turn behavior is the roll PID -- and maybe the roll stability and moment of inertia in the FLIGHTMODEL.CFG file.

FURTHER INFORMATION

See Matt's recent post in this thread about the way the mod groups have been able to affect the turn behavior and get close to the normal behavior we had before the patch.  It explains how they've been able to "override" Asobo's AP behavior for the initial part of the turn, and then tweak the default roll PID for the final few degrees.

B

 

1 hour ago, JimBrown said:

These days it's not so bad. Those two jets came out of the box looking like that. All I had to do was install the equipment. Takes about 15 to 20 hours. Which is fine by me, as I prefer flying to building.

Oh, and yeah, this hobby is the definition of "disposable income". 😉

...jim

 

Man, that's cool, but it brings back such bad memories.  My favorite plane is the P-51, way back in the day, I spent weeks and weeks building a balsa RC model, with aluminum wings and body everything.  It was like 2 feet long.  

I got an RC instructor to go with me to test fly it.  He was going to get it in the air then let me fly it, then he would land it.  We didn't have a dual controller setup.  When he got it in the air, we tried to swap the controller and the dadgum thing went into a spin that neither of us could recover from.

Disposible income indeed!

I love a lot of those YouTube RC videos.  There is some cool stuff in that hobby!

B

1 hour ago, MattNischan said:

So, the algorithm would effectively be:

* When a user selects any left or right turn heading, take the desired heading, save it, and instead send to the real AP a max heading diff turn (via the key event K:HEADING_BUG_SET): so, if it's a left turn, always send the AP -179 degrees from current heading, if it's a right turn, send the AP +179 degrees from current heading. Every frame, keep pegging the turn to +/- 179 based on the turn direction. This will keep the bank angle maximized during the turn, since the angular error never really gets smaller.

* When within a much more sensible distance to the actual desired heading, say 10 degrees or so, cancel all the excess heading being fed to the AP by using K:HEADING_BUG_SET again to set the actual desired heading. This will cause the AP to roll out, make the rollout start much later than if you had let it do it normally.

The issue with this is it isn't just a nice simple ai.cfg change, you're talking panel customization for sure and potentially custom JS or WASM code, if you don't want to run that whole loop in goofy reverse polish notation XML. It is a solution, though.

-Matt

UI-BASED WORKAROUND VERSUS FSUIPC LOGIC

I use FSUIPC7 extensively to support my peripherals, and I have LUA logic to directly control the desired heading and set the heading bug.  I don't use the virtual autopilot controls (altitude, VS, or heading) or trim (elevator, aileron, or rudder) with the mouse because you get the runaway behavior.

So I could do what you describe in FSUIPC -- remember the true desired heading, but set the heading bug over 90 degrees away until the plane heading is within 5 degrees or so.  That would work for now, but wouldn't that make the heading bug visually act goofy? 

And what about NAV and LOC modes? The heading bug doesn't affect them, but maybe there's an equivalent MSFS setting to do that.  I'll have to check that.  

In NAV or LOC mode, you may not need to do that if you do realistic flight planning.  A realistic flight plan typically gives you turns of 90 degrees or less and plenty of time (and room) to make the turn.  ATC usually gives turns of 45 degrees or less when vectoring, and by FAA rules, must not exceed 35 degrees when vectoring to intercept the ILS.  The current workaround may do that acceptably for ATC vectors and for flying from an IAF on your own.

In any case, writing UI code (Javascript I assume) to manipulate the heading bug is genius.  Once Asobo gives you guys (all modders and third party developers) a decent SDK and solid core foundation, just imagine how quickly we're going to see great aircraft based on the defaults, and awesome custom aircraft (like Aerosoft's CRJ).  Can't wait!

B

6 minutes ago, bdwhittle64 said:

See Matt's recent post in this thread about the way the mod groups have been able to affect the turn behavior and get close to the normal behavior we had before the patch.  It explains how they've been able to "override" Asobo's AP behavior for the initial part of the turn, and then tweak the default roll PID for the final few degrees.

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

34 minutes ago, robert young said:

 

Glad to see you in this thread!

Clearly, I value your opinions and investigate a lot of your theories.  Equally as clearly, I suck at quoting you correctly, but you (and everyone else) knows I have your back.

This black box testing and analysis has been very confusing because nothing is as it seems.  Rather than a "cascade" of PIDs controlling the behavior, there is code voodoo and disregard of PID behavior as implied by the config files.

I'm pretty much giving up on this until the next patch.  After the patch, and assuming some decent SDK documentation, all of this conjecture will have just been an educational exercise in understanding flight sim AP control techniques, learning exactly what PIDs do to control things, and a discovery of some of the differences between MSFS control and FSX control.

Flying is more interesting, but this is pretty fun during breaks.

Your friend -- whether you like it or not,

Brian Whittle

Just now, bdwhittle64 said:

Glad to see you in this thread!

Clearly, I value your opinions and investigate a lot of your theories.  Equally as clearly, I suck at quoting you correctly, but you (and everyone else) knows I have your back.

This black box testing and analysis has been very confusing because nothing is as it seems.  Rather than a "cascade" of PIDs controlling the behavior, there is code voodoo and disregard of PID behavior as implied by the config files.

I'm pretty much giving up on this until the next patch.  After the patch, and assuming some decent SDK documentation, all of this conjecture will have just been an educational exercise in understanding flight sim AP control techniques, learning exactly what PIDs do to control things, and a discovery of some of the differences between MSFS control and FSX control.

Flying is more interesting, but this is pretty fun during breaks.

Your friend -- whether you like it or not,

Brian Whittle

Yes, it's often a walk through a maze and it's enough to make you wish for a deck chair in the sun with a cool drink and a more rewarding contemplation! Nearly everything connected with simulators is a constant battle with limitations and frustrations permanently in the way. I do understand what you are going through. And I agree, sometimes flying, albeit in imperfect virtual machinery, is probably better for the soul.

3 minutes ago, bdwhittle64 said:

So I could do what you describe in FSUIPC -- remember the true desired heading, but set the heading bug over 90 degrees away until the plane heading is within 5 degrees or so.  That would work for now, but wouldn't that make the heading bug visually act goofy?

This is true: without additional instrument changes in the code (which yes, is JS, but is not all UI code, there's all the systems logic in there as well that's on top of the default sim provided stuff) the heading bug will not be correctly positioned.

5 minutes ago, bdwhittle64 said:

And what about NAV and LOC modes? The heading bug doesn't affect them, but maybe there's an equivalent MSFS setting to do that.  I'll have to check that.  

There isn't an equivalent plane simvar or key event to manupulate the desired track: that's all set by the fs9gps flight plan system, which is what the current in-sim flight plan system is based on. You can only manipulate this by creating custom waypoints with fs9gps, but I will note that I absolutely under no circumstances recommend that: the fs9gps system is currently not thread-safe and loves to CTD or corrupt flight plans when changing it.

 

8 minutes ago, bdwhittle64 said:

Once Asobo gives you guys (all modders and third party developers) a decent SDK and solid core foundation, just imagine how quickly we're going to see great aircraft based on the defaults, and awesome custom aircraft (like Aerosoft's CRJ).  Can't wait!

In all honesty, the APIs available on the JS side are more than sufficient for fully modeled aircraft systems. Between the available JS APIs and a bit of WASM for special cases, it's totally possible to model just about whatever you want to. For example, the next version of the Working Title CJ4 will have a completely custom flight plan system not at all based on fs9gps that will give you legs that match the charts, all based on the existing (and very good) NavBlue data that the sim was not currently using; custom LNAV for that that handles special cases not currently possible in the system like intercept legs and discontinuities; the ability to totally change approaches even while on the approach and go direct-to/delete/modify any fix; a fully functioning FADEC complete with correct flat-rating and climb thrust adjustment; full VNAV including all the correct modes, with user settable restrictions; full RNAV simulation and approach modes with the correct sensitivities for each phase of flight at the correct distances, including angular sensitivity with LPV; and more.

-Matt