Classic British Flight Sim

I have been fiddling about attempting to produce an FS9 acft cfg and panel which more closely resembles the real life aircraft.
When the autopilot is switched on to 'ILS approach' the aircraft starts to oscillate about 5* about the roll axis, this gets worse as the speed is decreased. Does anyone have any ideas how that fault may be cured?

Immediately the autopilot is switched off during the landing approach the FS9 aircraft egains its stability and the rest of the approach can be flown quite steadily by hand.

Hi,

This sounds like one of two things.

Either the Centre of Gravity (COG) is wrong and the autopilot is trying to correct it or you have a mismatch between values for the roll stability and the roll moment of inertia (MOI) in the cfg file. If the MOI value for an axis is too low compared to the stability value for the same axis you get this oscillation which can occur at high speeds under manual as well as autopilot control.

Change the COG by about 0.5ft either way and see the difference. This will probably mean changing the trim for take-off and landing. Also check the undercarriage positions to prevent nose or tail tipping under heavy braking. if you have to move the CFG undercarriage positions beyond their visible counterpart, the COG is way out !!!

The MOI/ stability mismatch solution is to increase the MOI value until you can run the plane at full throttle at low level under autopilot (<3000ft) without the oscillations. The value of the increase will depend on a number of other factors such as aircraft weight and loading, centre of gravity position, top speed etc. Sometimes a doubling of the current number will work and sometimes a 10 fold increase is needed. The actual number you end up with is not important. Increasing the MOI may affect the inertia of the axis such that it "swings" more than before during axis movement, in which case reducing the stability value may be needed. Generally, play with the changes until you get it right.

A good tip before you start fiddling is to retain the original data by either making a copy of the cfg file or placing "//" before the current numbers and put your revised number to the left of the "//".

A final point, if you increase both the MOI and the stability to give good handling at high speed (especially if a jet), you may need to increase the "authority" of the axis in order to retain low speed manoeuverability.

To me that sounds like the kind of behaviour you can get by messing with these parameters in the aircraft.cfg [autopilot] section:-

nav_proportional_control=12.00
nav_integrator_control=0.25
nav_derivative_control=0.00
nav_integrator_boundary=2.50
nav_derivative_boundary=0.00

The numbers above are from the default FS2004 737.

I've long forgotten exactly what these parameters are supposed to do.
Think you may find it's too small a 'nav_integrator_boundary' or too large a 'nav_integrator_control'.
I know you generally only need zero entries for 'nav_derivative_control' and 'nav_derivative_boundary'.

I'd just pick a similar aircraft that works ok & try the numbers from that.

DM

For DM:

Many thanks for your suggestion I did try fiddling about in the area you suggested but to no avail.

I have spent some hours over the past few days re-writing an acft cfg to match up with the data, (dimensions, weights etc) with information gathered from the web and from one of the 'Warpaint' series of books dealing with this specific aircraft. I have aways found it puzzling that with all the information available a number of FS designers upload aircraft whose flight models do not resemble the real world aircraft that they purport to imitate. My first task was to write in the real world weights and dimensions and, working from a three view plan of the aircraft to ensure that the acft cfg contained the correct relative positioning of wing and tailplane apex/wing/tailplane in relation to a fixed point at which I judged the real world aircraft CofG to be.

Having done that I re-calculated the pitch, roll and yaw MOIs working with a constant which is the MTOW divided by 32.2. The formulae for MOI calculation is contained in an old publication originally released by Flight Simulator World and Abacus "We Fly the World" entitled 'Flight Dynamics for Microsoft Flight Simulator' written by Tom Goodrick. That document might have been released as far back as FS95!!! and is, including appendices, 51 pages in length. It does make interesting reading for those interested in FS mathematical modelling.

I then select my aircraft with the modified acft cfg in FS9 and look at the little diagram in 'Aircraft/Fuel and Payload' which gives an indication of the position of the CofG of the acft just modified. If you do this with a lot of FS acft you might be surprised to see that their CofGs are nowhere near the area of 1/4 to 1/3 of the wing chord on the little diagram. I aim to get the CofG of any acft I modify into that area before I attempt to fly in FS9. This does mean that you might have to move the reference point and every other acft component position until that position of the CofG is attained. I only modify acft via the cfg because have no means of getting into the AIR file to examine that most important point, namely the postion of 'the centre of lift.' That means that sometimes, no matter how many hours I put in I cannot make an FS9 acft imitate the flying characteristics of the real world aircraft. So that exercise would have been a failure and the whole modified files are deleted.

Assuming that my mods have resulted in a reasonable postion for the CofG I then go into what seem to be a never ending series of 'ccts and bumps.' That can lead to re-positioning of the u/c contact points or to the 'delete' bin. If the modified acft flies ccts OK and can be controlled reasonably smoothly by hand and then by autopilot I carry out some 'night' landings, and if they go OK it is off for some X-cntry day and night flights to test fuel consumption - altering the acft cfg fuel tank content and or consumption rate to match that published range figures for the real world aircraft. If all goes well the modified acft stays in my hangar. Carrier acft are also checked for 'cat' launches from the deck and arrested landings.

I should like to stress that most of my work is done so that the modified acft can take off and fly ccts by hand or with the autopilot as it would be for ILS approaches in the real world, if you have to stagger into the air and cannot control a landing then there is really no point in keeping that acft.

For Degsy:
I always try to maintain all the control factors in the 'Flight Tuning' as 1.0 but on this occasion having tried shifting the CofG etc. forwards and then backwards on this aircraft by 0.5ft I found that while I could still land the acft from an ILS approach by hand with no wing rocking, shifting the CofG in either direction did not cure the roll oscillations when using the autopilot for the ILS approach to within 1.5nm of the threshold. Finally, your suggestion which worked was to alter the 'Roll Stability' from first, 1.0 to 2.0, which did cure the roll oscillations on A/P approaches and then to reduce that factor from 2.0 to 1.5 so that I can now make steady ILS approaches with no wing rocking on autopilot. Bit of a cheat, especially after all the work in researching the real life aircraft data and altering the acft cfg to 'real world' values - but then I have always said the I only 'fiddle about' with the acft cfg!!

I have found that it is important to retain the acft cfg and AIR files for the modified acft as a matched pair for I believe that as one alters the acft cfg in FS9 some of the data in the matched AIR file is automatically altered - so it is no good just taking the original acft cfg out of an aircraft file and rep[lacing it with a modified acft cfg - the resulting acft might not behave as expected.

Over the years I have found that one has to consider the acft cfg plus AIR file, the 'Model' file and the image of the acft seen on the screen as three quite separate units. For example: If you decide that the original aircraft has lights that are not correctly positioned and decide to correct those positions by reference to a three view plan placing the measurements from the plan into the acft cfg [Lights] section relative to the chosen reference point - you might get a surprise when you switch your modified lights 'on.' Sometimes they are not where they should be and you have to jigger about with those distances in that acft cfg so that the lights are correctly positioned when the acft is viewed on the screen. Why this is so I have no idea for it suggests that the 'Model', presumably built from a three view plan, is rendered on the screen in FS to a different scale from the acft measurements given in the cfg. Perhaps Rick knows why that can occur?

Ah well - Evening meal has just been announced - then it will be F1 Practice and 'Strictly Come Dancing' - no 'Merlin' this evening - after that I can get out of the hangar to do some flying!!

Hobby,

Glad you've got a satisfactory conclusion.

As an inveterate flight dynamics fiddler I agree with your comments about flight dynamics not matching the visual model and I've spent many hours getting a plane to fly "right". As a general rule, if the visual model is good then I'm prepared to put the work in, otherwise it gets binned. In fairness to aircraft designers, I couldn't make a visual model to save my life, so I can't really knock those who are excellent visual model artists but can't manage the FD.

On your point about the cfg and air files - they must be a pair as the air file reads the data in the cfg, but not all of the air file data comes from the cfg file, some is only in the air file. There are air file readers about, notably "Aired", but most of the important factors are in the cfg file.

I'm not sure how you configured the cfg against your 3 view drawings, but my usual method of rewriting the cfg (and hence the air) file is to use lights to mark the positions, then use the data for the longitudinal/lateral/vertical points in their respective positions. This is much more accurate than trying to work from a scale drawing, and easier to see what you're doing, but of course only works if the visual model is a good representation of the real thing.

Re the [Flight Tuning] values, remember that "1.0" maintains the core value within set the air file and although you can go into the air file and make amendments, there are often scalers in there that are not linear. The cfg scaling is linear so you can amend this in proportion to the impact you see. Since this principle applies to all the cfg scalars, it makes amendments much easier and this is the reason why the actual numbers you end up with are not important. By changing the scalars you could actually make an Extra 300 have the stability and inertia of a 747 and vice versa !!

Finally, with oscillating axes my approach to the MOIs is to double the numbers until I get no oscillations with autopilot at sea level at maximum speed whilst retaining sufficient manual axis authority at approach and landing speeds. As a non-real-pilot I have no idea whether the final result mimics the actual plane but my experience of being a passenger in a range of real aircraft tells me it's about right.

Oh yes, I count fiddling a big part of the fun of this passion of ours....

Thanks Degsy. Agreed on the subject of a good looking model (acft!!) takes hours and not worth the effort if the acft looks out of character in FS.

Are there any other forum members who fiddle the acft cfg and AIR files?

Hobby -
I have tampered with them from time to time and in varying degrees.
One thing I have noticed with APs, is that in FS aircraft where the AP responds to the Heading bug input, if you reduce the heading (ie initiate a left turn) the plane will always turn a bit to the right, before responding correctly. I have also noticed that when I hand-fly until "established on the beam" if I then switch to the AP in Appr mode, the plane immediately starts weaving in the yaw axis. I strongly suspect that the FS AP assumes a coupled rudder/aileron setup, even though on my system that coordination is disabled as I have a CH Yoke/Pedals/Quad setup.
As far as I know, that ('always turn right first') is caused by a bug in the FS2004 coding and there is no 'fix'. I believe what I have described provides a mechanism for uncontrolled oscillation, but I can't prove it.
This used to bother me, but in the course of testing for cause, I learned to hand-fly ILS approaches, so I didn't need the AP after all!
A very interesting thread, just the same - thankyou.
ATB
MikeW

Hi,

Although I hand fly most of the time I do sometimes find that going into and out of autopilot results in some form of oscillation on one or more axes. I've usually put vertical moves down to COG and trim conflicts as often the amount of trim for hand flying is different to that set by the autopilot. There most be a similar "feature" in the roll and yaw axes for the "swaying" on heading. I've never fully researched these as I don't find them too annoying.

I suspect that the kick from heading hold to APR is due to the difference between the compass bearing and the ILS bearing, as some are offset to the "raw" runway heading. Perhaps the best way to manage the autopilot APR control is to lock the height and direction manually a long way out, then intersect the ILS bearing and use NAV hold, then switching APR when the glidepath hits level.

On a curving approach in a warbird, I don't see this problem...