overriding MSFS autopilot

[Guest adameke777]

Is it possible to "override" the default MSFS autopilot with a custom-designed one ? Can this be done by creating a DLL module (not a gauge) ?

[Guest PAtom]

should be possible. as far as i know, the PSS a320 autopilot isn

[Guest _ak]

Not sure about module.But of course you can write replacement for autopilot.I do this right now. It's very primitive now, only pitch and bank holding there, but of course I will improve it :)

[badderjet 181]

As a gauge, DLL, or what?

[Guest _ak]

A C++ class inside multigauge

[Guest bartels]

What you want, gauge or DLL both is possible. Mine are always gauges (Sperry,Navomatic, autohover,..). Gauges are just DLLs in a different folder and different names.Arne Bartels

[Guest Ron Freimuth]

>What you want, gauge or DLL both is possible. Mine are always>gauges (Sperry,Navomatic, autohover,..). Gauges are just DLLs>in a different folder and different names.>Arne Bartels I expect I can do most any 'autopilot' function in XML. I now have many of the 'state variables' displayed in my Jet Test Gauge. 'l, m, n, p, q, r' V, Vdot, VS, Vdot, etc. IOW, Roll, Pitch, Yaw and their rate deriviatives, also speeds. I also have the rates filtered with an adjustable 'low pass' filter. Just the sorts of variables needed for 'PID' FB systems. The main trick is to combine such state variables and drive a usable FS event. I do think one has to bypass the JS inputs with such control. As you did in that Sperry. However, I may be able to hit the three trim axis with K: events and leave the JS control working. I found FS9 has a crude Yaw Damper, the Rudder moves a little to counter Yaw oscillations when it is turned on (and set to 'Yaw_damper_gain'= 0.2 or higher. That aircraft.cfg line doesn't appear to be a 'gain', rather a BOOL that switches off/on around 0.2. I want to see if I can control the rudder trim (can't control the rudder since that wouild lock out the 'pedals') with a gauge to make a more realistic Yaw Damper. If that worked, it would be desirable to make 'rudder trim' variations invisible on the panel, and also allow normal pilot settable trim. The FB gains, etc. could be defined in one XML file that was specific for the AC involved, the same base code would do for all. I assume an xml 'autopilot' gauge could be put in the AC panel folder in FS9. Or, perhaps the basic gauge could be common in gaugesautopilot and the specific parameters set in a file in each AC panel folder that used it. That's just a basic 'autopilot'. One could control the flight path of an AC with more program logic. Also Mixture and Prop. I may experiment with 'best range', 'best speed', 'best endurance' control. Push a panel button and the AC is controlled to get the optimum AoA, IAS, etc. That requires information from the AIR file, but I could set such parameters manually in the gauge. Ron

[Guest]

Ron, sorry, but I think XML autopilot is mmmmmm sadomazo . . .:) For example, IAS via PITCH mode on XML - you not affraid it?Using C or C++ autopilot making not so difficult and such autopilot is more flexible for use it in different planes with a little modification. Vladimir.

[Guest Ron Freimuth]

>Ron, sorry, but I think XML autopilot is mmmmmm sadomazo . .>.:) >For example, IAS via PITCH mode on XML - you not affraid it?>Using C or C++ autopilot making not so difficult and such>autopilot is more flexible for use it in different planes with>a little modification. >Vladimir. One needs Values and Rates. I programmed an XML Test Gauge to display pitch, roll, yaw, AoA, and their rates. Also, TAS and VS and how fast they change (Vdot and VSdot). In addition, I have a simple algorithm to set 'frequency response'. It would take me some time to learn C gauge programming, XML is easy to change during flight. Also, there are some XML parameters not available as Token Variables. Main problem is to control the aircraft and not lock out the joystick. Perhaps only change the trim values. FS9 has some PID autopilot settings in aircraft.cfg. However, I don't think all work as they should. One can set maximum Bank Angle, but can't change it. In FS2K one could set Bank Angle to decrease at lower speeds in the AIR file.Ron

[badderjet 181]

>Also, TAS and VS and how fast they change (Vdot and VSdot). I wonder how you got the TAS acc/deceleration? Could you explain how you did it? For my C version doesn't really do, jumps around like mad etc..

[Guest _ak]

Hm. Can you show a demo?

[Guest Ron Freimuth]

>>Also, TAS and VS and how fast they change (Vdot and VSdot).>>>I wonder how you got the TAS acc/deceleration? Could you>explain how you did it? For my C version doesn't really do,>jumps around like mad etc.. For rates, such as 'pitch rate', I get a new Pitch value every dos tick. I take the difference between successive values and filter with about 0.3 sec time constant. I display these rates to 0.001 deg/sec and they tend to jitter only in the last digit when the AC is stable on autopilot. More when things are changing, but should be quite adequate. It may be the XML stuff gets fairly high priority at the tick18. Just don't do too much on one tick or your calculations are likely to be interrupted by a different thread. Get the critical values early in the code flow, before the code is interrupted. Do the differences, etc. after getting the critical variables. I'm careful to read all the variables sequentially, then filter a bit later. Finally, I display everything sequentially. There is a tick18 in C tokens also. It should be pretty stable. 18 samples per second should be fast enough for autopilot stuff. I've got the test gauge code working pretty good now, main problem is to get the display window and lines to fit. ;) I broke the Jet gauge into "Jet Display" and "TestBase" XML files. I calculate more than I have room to display. I just counted 60 numbers displayed in the Test Gauge window. Some are simply FS variables, others involve some calculations. I'll be making it available with some limited explanation soon. Further, when I get more XML things working I'll have Herve' post some at his WEB site. The same algorithm that 'filters' the rates can be used to set a long, 'exponential' delay for things like Fuel Tank Temperature. My test gauge doesn't seem to hurt frame rates unless I expand the window a lot. In fact, I'm running on a 467 MHz PII system. ;) I initialize some 'constants' only once, that includes some calculations for the Time Constant factors. One could calculate and enter them manually, but why not let the XML code do it? I Strobe different blocks of calculations at a submultiple of the 18/sec tick. No need to calculate anything but the rates at the full speed. I set up four strobes and could one as short as 'every tick' and another so long your computer would die before the strobe blinked the second time. BTW, my test gauges seemed to mess up the FS autopilot switches. I learned about the 'c' "clear stack" yesterday and added a few "c's" in my code to keep the stack from overflowing. Haven't seen the messed up autopilot since. Other than for the fact that C token variables don't include all the useful parameters available for XML, it should be easy enough to convert an XML gauge to C. Or, simply code the algorithms directly in C. Ron

[Guest _ak]

>> Other than for the fact that C token variables don't include>all the useful parameters available for XML, it should be easy>enough to convert an XML gauge to C.Which values available in XML but not in C?

[Guest bartels]

In C gauges the PANEL_SERVICE_PRE_UPDATE service_id os called every 1/18th second, so the gauge callback is a good place for the autopilot code in C. I don't have my damping constants at and, but 0.3 sec sounds good. There are however some variables that change almost in the same frequency.Arne Bartels

[Guest Ron Freimuth]

>> Other than for the fact that C token variables don't>include all the useful parameters available for XML, it should be>easy enough to convert an XML gauge to C.>>Which values available in XML but not in C? (A:Ambient Pressure,atm) Pressure in Atmospheres, 1.000 at ISA SL. Or, set the units to inHg, and you get 29.92... at SL. But, you don't have to convert inHg to the normalized "Atmosphers" in XML. Saves finding the exact conversion factors. This may not be in the C tokens: "(A:Total Weight,pounds)". You can set kg, etc. Herve' Sors got 'total weight' for his AFSD through an undocumented FS variable via FSUIPC. These lines calculate the important Dynamic Pressure, q:(A:ambient density,Slug/ft3) (>L:rho_a,number)(L:TAS_fps,number) sqr (L:rho_a,number) * 0.50 (>L:q_dp,number) I'm sure one can calculate the factors requred to generate 'engineering units' such as slugs/ft3, in a C gauge. But I know Herve' had to go though a lot of trouble calculating some things for AFSD that I simply got from A: variables with the appropriate unit. -------------- It looks like most of the other variables I used are virtually the same as one gets from Token Variables. I got Roll, Pitch, and Yaw in degrees, so didn't have to convert from radians. I was looking over 'gauges,h' and noted some arcane state arrays. Some of those might be the most appropriate way to obtain rates, rather than taking successive differences of the three attitude variables (also, velocities). I know there are XML parameters for Vx, Vy, an Vz. But not accelerations. TAS (feet per sec) is in the direction of AC travel, different from Vx except in level flight. However '(Vertical Speed,feet per sec)' is the same as Vz. It is easy to get the flight Slope from ASIN (VS/TAS) when both are in the same units. DO NOT use 'IAS' for anything but a panel indication. It may have an offset (small AC) and includes 'compressability error'. TAS and Mach are virtually exact in MSFS, and are simply related by SQRT(Ta/To). I have NO strings in Test Base.xml. I started with an example of XML code done for a commerical release and I think a 'trick' is used to to scan and generate all the L:Variables without using a bunch of strings. My strings are in Jet Display, which only does a few misc conversions in the display strings. I can't seem to attach anything in this Forum. So, can't attach my code. But, it will be availabe one way or the other. I'm sure others can clean it up and get the display better. Note any L:Variables one generates can be displayed with an independent XML gauge, so one can see what his variables are doing, then take out the display when he no longer needs it. One could start the 'calculations' 'gauge' automatically (visible=1), but there is nothing displayed unless the Display gauge is brought up. Of course, that was done in C gauges also. Finally, for rates that have to be consistent with the FS 'RATE', one should normalize the 'Time Constants' and the 'per second' so they change with RATE. For my test display I don't and the rates change when the FS RATE changes. The rates are in real time, not FS time. Slowing the sim rate to 1/4 lets me watch the parameters more easily, but I have to remember rates also drop to 1/4.Ron