X-Plane Flight Model Esoterica

[tkyler 88]

This is a post that I tend to write every few years for new users who are curious about x-plane….and also as an excuse to break from working. As x-plane grows, new users approach it with trepidation, pre-conceived notions and prejudices in my experiences and such feelings are not entirely unwarranted as Laminar hasn't always been a juggernaut of information dissemination. Laminar are famous for limited documentation, or at least was in that past. We are getting better but the sim develops quickly and there is a lot to document. Now the bad thing about this is there is a lot of misinformation and confusion out there and bewilderment on behalf of new users that, in my opinion, is fully reasonable, indeed downright expected on a sizable scale. The good thing about it though is that Laminar is always busy improving the sim…and I mean constantly. So for those of us who like that aspect, x-plane is a good thing.

 

So this post is but general ramblings about x-plane's flight model. I have not seen the flight model code, I don't get "explanations" from Austin…..ok, sometimes I do, but I have developed aircraft for x-plane for about 5 years now and as a mechanical engineer with a background in FEA, numerical methods, and a bit of physics, I know enough about computer numerical modeling and finite element techniques, which BET (blade element theory) is, to draw some conclusions about the approach Austin has taken. In addition, I'm currently studying aircraft design, albeit in a hobby capacity and one has only to take a thorough look around plane-maker to get a feel for what's going on. This post is for those curious about the flight model on the most "surfacy" of levels.

 

For engineering types like myself and Austin, the term "model" usually means a mathematical representation of some physical behavior…..a simple equation if you will. If you remember from your early school years, you can take an equation like, y = x^2, and evaluate it at whole integer values like, 1, 2, 3, 4, etc. If you were to evaluate that equation at four points and put it in a table of x vs. y and interpolate between the data points, then you would have something akin to a "table based simulation" with 4 data points. The closer together the data points, the better the simulation. (think calculus). Now the other alternative is to use the equation itself and evaluate it at any value between 1 and 4, yielding an infinite number of values….theoretically of course. Now I know this case is simplified, but when you are modeling various parameters of aircraft performance or systems, where governing equations can get very complex, then sometimes, you just have to go out and measure aircraft performance at discrete intervals and plot it in a table. The more accurate your measurements and data, the more accurate your simulation. This is why a table based simulation of known values can be very accurate…but you have to have lots of known data to achieve it.

 

Again, for engineering types, we don't want to have to build something just so we can then measure it and see how it works. What if a design doesn't exist? We would much rather find some math relation that describes (models) how it works and then we can use the math equation instead of actually building something just to use the measurements. In a very simplified nutshell, this is what x-plane does. It uses well established governing equations of motion, dynamics and physics…along with modern finite element techniques, in order to model flight behavior. Now in any equation though, you have to give it input. You cannot get a 'y' value without inputing a 'x' value. So there's 2 things that determine just how good the results are. 1.) The accuracy of the equation relative to the phenomenon it seeks to model and 2.) the quality of the input to the equation. If a phenomena exhibts exponential behavior, then a linear equation is not a good equation to use. The 'accuracy of the equation" is Austin's part. This is the code that nobody but Austin sees. It's probably based on lots of experimentation, white papers, textbooks, aeronautical knowledge and certainly very well known, proven and accepted finite element techniques; however, MANY other phenomenon, particularly systems, are also probably 'quick and dirty', approximate, estimated or generic and in simple need of improvement. Austin may be an expert at aeronautics, but that does not mean he's an expert in hydraulics or electricity, etc. Whether or not these aspects get improved are probably more a matter of business decisions and timing. For example, why alter a manifold pressure model that is approximate enough for 80% of situations when chasing down the last 20% of accuracy means a 10x increase in time? For these cases, x-plane offers a customization mechanism for programmers that pretty much allows one to achieve whatever accuracy they desire.

 

So when a new user fires up x-plane for the first time and an aircraft feels "twitchy" or lacks roll momentum, then you have to question both contributions to the result, that is the equations and the input. As stated, you cannot really look at the equations, BUT you can infer some of them by poking around plane-maker. Next you call into question the quality of the input. Let us take the absolute best example in x-plane, 'twitchy' or over-sensitive aircraft. This is not a flaw in x-plane's flight model code, it's a flaw in the flight model input. A twitchy aircraft is one that is overly sensitive in pitch, roll or yaw. For you geek types, you know that acceleration around an axis is dependent upon the mass moment of inertia, which is further dependent on what is called in the "radii of gyration". The greater the radii of gyration, the more resistant a body is to rotation. Well it just so happens that there is a place in plane-maker where you can set "custom" radii of gyration parameters. If you do not do this, then x-plane will estimate it but it ALWAYS does so on the low side. If you open an aircraft in plane-maker and there is no custom radii of gyration set, you will probably have a twitchy aircraft. The reason Austin's estimation of ROG is conservative is because the radii of gyration is dependent on the weight distribution in an aircraft. this is NOT easy to predict and is more a function of how the aircraft is built…even how heavy the pilot is, how much cargo and where it is, etc. By simply putting in custom radii of gyration values, you can improve the "feel" of an aircraft model immensely.

 

The 2nd best 'trick' to improve x-plane's feel is what are called "phase outs". We MUST acquiesce that there are limitations to simulating flight on a computer. We don't feel G-forces, we don't have force feedback…we don't deal with control surface mass, etc. In such cases, we have to come up with ways to simulate what we perceive in flight. Phase outs simulates the effort necessary to deflect controls at high speeds. If you are in a 172, managing 150 kias somehow and tried to pull back on the yoke to full deflection, you're muscles (as well as the plane) would have something to say about that…and in addition, you're muscles/nervous system are infinitely more sensitive than a joystick; however, with a joystick and no force feedback, it's no problem, we just yank back much more than we dare would in reality. Phase-outs is a method in plane-maker whereby you limit control surface deflection by a percentage over certain speed ranges. So when you yank bank on your joystick at 150 kias with no force feedback, the plane won't go skyrocketing up. It's not 100% accurate, but neither are we really flying nor experiencing forces so compromises have to be made……and when armed with a bit of knowledge and common sense experience in perception, we can get pretty close.

 

My point here is not to convince a majority of those to overlook their "less than ideal" experiences with x-plane or make excuses defending Austin, but simply to provide some information for those curious…and perhaps give hope that with naught but a few minutes of tweaking, that their purchase was not in vain and what was once a bad experience can be made into a good one. It would not be the first time I have seen it. X-Plane is a very good simulator of flight and a "not bad" simulator of systems. Most seasoned x-plane developers will get defensive when users generically use the term "x-plane" because to them, 'x-plane' is the equation and the aircraft is the input...and 9 times out of 10, it's the input that is in need of improvment, not the sim itself. Does this matter to most users? of course not, but then again, this post isn't for most users....only the curious. (or bored)

 

Tom Kyler

Laminar

V10 aircraft

V10 scenery

[jcomm 5,961]

Tom,

 

EXCELLENT POST! What else can I say :-)

[WarpD 824]

This statement brings up more questions than answers:

because the radii of gyration is dependent on the weight distribution in an aircraft. this is NOT easy to predict and is more a function of how the aircraft is built

 

I know in FS that you can define all stations in an aircraft... each passenger seat etc by position related to the reference datum point which is offset from the aerodynamic chord of the aircraft. Based on that, it's relatively easy to define weight and balance behavior of an aircraft in FS.

 

Are you saying that the same is not possible within X-Plane and that instead of telling X-Plane exactly where each seat or cargo or fuel tanks are physically that you have to create ROG inferences instead?

 

Since when we climb into a real aircraft with a weight and balance sheet filled out, I find it odd that you would state it's not easy to 'predict' weight distribution. Or I am perhaps completely misunderstanding what you are saying.

[Paul Golding 92]

This statement brings up more questions than answers:

 

 

I know in FS that you can define all stations in an aircraft... each passenger seat etc by position related to the reference datum point which is offset from the aerodynamic chord of the aircraft. Based on that, it's relatively easy to define weight and balance behavior of an aircraft in FS.

 

Are you saying that the same is not possible within X-Plane and that instead of telling X-Plane exactly where each seat or cargo or fuel tanks are physically that you have to create ROG inferences instead?

 

Since when we climb into a real aircraft with a weight and balance sheet filled out, I find it odd that you would state it's not easy to 'predict' weight distribution. Or I am perhaps completely misunderstanding what you are saying.

I get the impression the ROG doesn't just relate to the aircraft load distribution Ed, it's to include the aircraft itself. But then I'm often wrong.

[tkyler 88]

I get the impression the ROG doesn't just relate to the aircraft load distribution Ed, it's to include the aircraft itself. But then I'm often wrong.

 

Not this time Paul :)

 

 

Hey Ed,

 

Once again, it's more of an engineer mentality. For any given aircraft mass configuration, you will have exactly one ROG value. Of course that value is dependent upon mass distribution and what we have here is Austin's preference for absolute flexiblity. While some prefer to think in terms of "tangible" masses, like chairs, bodies and such, and let the software do the math, the end result is still a single ROG and CoG value for a given mass configuration. I am guessing here, but it's probably Austin's mentality that a developer can manage weight and balance however they want through custom programming and simply adjust the ROG dynamically to reflect it. I see no reason someone cannot write a generic plug-in to manage weight and balance using a more common, "chair is here, cargo is here" paradigm....it would not surprise me if it has already been done, BUT, x-plane does not provide for this type of itemized weight and balance management within it's interface, it would be done 3rd party through custom plugin programming. Though some may disagree with the approach, the flexible, design oriented, engineering paradigm is part of x-plane's identity and pedigree and will probably not change significantly....but I digress, the issue is not weight and balance.

 

Regarding "not easy to predict". Weight and balance effects are ridiculously easy to predict but this calculation is on top of an existing ROG, which is dependent upon aircraft design details. So when I speak of custom ROG, I am talking about how many stringers, how thick, what material.....how heavy a hose may be in an engine compartment, how heavy the battery is, where it's located, ballast amount and location...all sorts of stuff that you can't guess because in reality you never know what a user might put in their basic design (not cargo, fuel or passengers), especially when the software also targets aircraft design. By letting the designer choose the absolute ROG, you can obtain more flexibility and accuracy than just setting weight and balance items and letting the software pick the ROG of the base aircraft. Specifying masses added to an aircraft does not address the problem of calculating proper ROG for the basic empty aircraft. I would suspect that somewhere in the FS flight model, you have to specify rotational intertia somewhere?...before adding additional masses. So to answer your question more directly, it is NOT currently possible to add masses to an aircraft in the paradigm you are used to. It IS possible, through programming a plugin, to do just about anything you want, including simulating a cargo mass sliding back on a steep takeoff, changing CoG and RoG in real time as it slides back. Such simulation of physics (or access to write your own) is the cornerstone of what Austin wants and so that's what we get. In time, we will probably see 3rd party authors create cool add-ons and that's when the flexibility will really shine in my opinion.

 

Tom

[WarpD 824]

Yeah... ok... but as a developer I read it this way: "X-Plane does not calculate weight and balance."

 

Thus as fuel is burned off, the aircraft's CoG and other critical aspects of flight dynamics aren't changing.

 

I can honestly state that the base empty weight center of gravity should already take into consideration of equipment placement and thus any further calculations are not necessary 'on the fly' as the equipment doesn't go anywhere. Of course, if you want to mimic dynamic forces of a wing loss (can't really imagine why) I can see a reason to do it dynamically... otherwise, I really don't see a point.

 

We're simulating flight... are we not? Certain aspects of the flight are 'set in stone' and won't change throughout the flight. However, based on what you're telling me, certain aspects that do change throughout the flight aren't actually modeled and require the third-party developer to create an addon to do this.

 

Once again, correct me if I'm wrong.

 

Lest anyone wander into this thread and start trying to smack me around... let's be absurdly crystal clear. I'm trying to get all the real differences between developing for FS and developing for X-Plane out in the 'open'. As a person who works in the FS area... I find information regarding X-Plane development hidden and murky.

[Musart 2]

Take a look at this engineer opinion about modeling (see last video on the page)

 

http://aricciardi.we...ing-videos.html

[Paul Golding 92]

So Tom, I'm going to assume that ROG isn't a know factual figure and even worse, it isn't a realistically calculable one either?

 

So whilst I can understand the merits of doing things this way, it doesn't seem that it would result in some kind of scientificaly verifiable outcome. Not that I personally have an issue with this, after all, most "discoveries" in the MS flight model were made out of a hit and miss approach.

 

So, going with my assumptions again, one just puts a number in for the ROG and gives it a try and repeats until we can get a real world pilot to say "that's how it feels".

 

And Ed, I agree with the "murky" comment! That said, threads like this help and it would be nice to see it grow and get pinned at the top too.

[tkyler 88]

No problem Ed. Learning anything new always takes adjustment. I find the tenacious ones thrive.

 

FIRST I have to digress again. I opened planemaker 10 and there is a page for specifying up to 8 misc weights and their longitudinal locations..and also a tab for evaluting CG. Setting these would most assuredly affect the RoG that x-plane calculates. Using a custom RoG however, would override these settings.

 

If we look at what changes during a flight, we have what? fuel mass, maybe shifting cargo, or in the case of an airliner, folks moving around. In small GA, I doubt you'd see any significant change in mass distribution. So I'll address these one by one. X-Plane accounts for fuel mass effects, BUT only at a single point of application for each tank, thus in a situation where the CoG of a fuel mass moves, say in a trapezoidal shaped tank in a delta wing, that would have to be done with custom programming (I think IXEG does this). The default x-plane model will reduce RoG in roll (for wing tanks anyways) as fuel is depleted but as mentioned before, the RoG with full fuel is calculated on top of the base ROG.

 

I can honestly state that the base empty weight center of gravity should already take into consideration of equipment placement and thus any further calculations are not necessary 'on the fly' as the equipment doesn't go anywhere.

 

I wholeheartedly agree, but recall we are talking about RoG and not CoG. CoG IS fixed by you the author and only changes if you change it via a slider in the aircraft menu so it is not dynamically adjusted except through custom programming. RoG on the other hand, does change as fuel is depleted.

 

 

RoG takes into account mass distribution of every atom in an aircraft. A baseball bat, being tapered has a greater RoG about it's base than does a stick of same length and mass, but uniform cross-section. So if you were to add up the mass of every atom from the nose of the aircraft to the tail you could calculate the RoG accurately. In real life we can't do this off course, so in x-plane, all you really know is cross sections and areas and the misc weights specificed as well as fuel locations. X-Plane probably uses some "average" value to calculate RoG from the aircraft shape, assuming stressed skin construction and approximates the mass distribution. It also MIGHT....don't know cause Austin's never told me....it MIGHT make an assumption about engine weight, occupant weight, but I doubt it accounts for battery weight, oil weight, avionics weight, etc etc and probably why the value is always a bit low. In real aircraft design, the list of things to calculate as a"first approximation" is indeed a much "longer list" than x-plane provides, including such things as pullys, cables, electrical harness, etc.

 

So perhaps you can see that basic, empty plane RoG is dependent upon every atom and it's location and there is no way for x-plane to know this. So a good and certainly decent procedure is to enter the RoG values that x-plane calculates as custom values and then adjust them up from there until it feels right. If you want to calculate the real RoG of a existing airplane, you COULD put an aircraft on a giant gimble and do some acceleration tests or even diagram out a plane with as many masses as you can come up with and calculate RoG to within an acceptable level....but listing 30 instruments and tryingn to find out their weight is not my idea of a good time.

 

RoG is realistically calculable only if you are as thorough as reality. In modern engineering softwares, if you put all the geometry into your CAD model and specify the material/weight of each, you can get very accurate, but we are talking really high detail here. In 'general' aircraft design, it is (usually) perfectly acceptable to get "approximately close" as that is what a "factor of safety" is all about...those unknows you just can't get. Setting RoG, with a bit of knowledge and "gut feeling" experience, you can get within a satisfactory "approximate range" and for me, that is perfectly fine.

 

Tom

[WarpD 824]

And yet it's totally artificial and bears only an individuals 'perception' towards reality. Hmmm... not sure I can agree it's a good approach.

 

CoG is not a finite value as it shifts both left and right as well as fore and aft in flight. I have detailed information regarding how CoG changes in flight for several aircraft and I can toss such information into a spreadsheet and plot all aspects of the CoG with relation to the CoL for a given aircraft.

 

This has a huge impact on the performance of an aircraft in flight so I have to ask how this is accomplished in X-Plane.

 

I'm really not seeing where RoG provides accurate flight performance with regards to weight and balance at all.

[Kabs 0]

Actually the way I understand it (and I may be wrong), RoG and CoG are two different things, both of which are simulated in x-plane. The RoG is the determines how quickly/easily the airplane rotates about an axis when a control input is applied. The smaller the RoG the twitchier the airplane. CoG (also simulated in x-plane) detemines the tendency of the airplane to have a particular orientation.

 

Lets take rotation about the longitudinal axis (bank) of the airplane.

Suppose we start out with full fuel in the wings. At this point the airplane has a higher RoG and is less twitchy. As fuel is depleted (assume equal burn for both tanks) the CoG across the wings axis remains the same, but the RoG becomes smaller. The airplane must become more twitchy.

 

CoG alone cannot be used to calculate this effect, and this is why RoG is required.

 

In effect a change in CoG will have an effect on RoG, but RoG can also change when there is no change in CoG

 

Kabs

[tkyler 88]

And yet it's totally artificial and bears only an individuals 'perception' towards reality. ..........

 

That is an incorrect statement Ed.

 

We shoud back up as I think our fundamental vocabularies are different. What is is that you want to do/see ? ...and I'll try my best to relate that to x-plane's flight model. I don't want to dilute the thread with too much debate though so if I can't provide further clarification on the flight model, useful to others with my responses, then we can continue the discussion somewhere else.

[60North 120]

The XP default mass & inertia model is sufficient for most aircraft. And, if you

for some reason should not be satisfied, you write a plugin.

 

As Tom and Kabs explain, RoG is just a variable in the inertia equation.

If you place a bunch of static point masses or use one RoG will give you the same end inertia.

 

The main reasons a CoG would change in flight are;

- Fuel burn

- Firing a weapon

- Slung loads

- Water ballast

 

XP models mass points and inertia for those variables. The static mass is covered by the CG.

Different static payload locations are covered by moving CoG.

 

In other words RoG covers the static mass and the above dynamic masses are calculated separately.

Since the aircraft will always rotate around the CoG (with one exception..), the RoG center moves with it.

 

And yes it's artificial, I doubt you PC will weigh in at 500.000lb if you put that into your FS B747 either <<'L' smiley removed by MOD - folks, please be civil to one another>>

 

M

[WarpD 824]

That is an incorrect statement Ed.

 

We shoud back up as I think our fundamental vocabularies are different. What is is that you want to do/see ? ...and I'll try my best to relate that to x-plane's flight model. I don't want to dilute the thread with too much debate though so if I can't provide further clarification on the flight model, useful to others with my responses, then we can continue the discussion somewhere else.

 

I want to define all mass positions... just like I can in FS. In FS, you define the empty weight CoG and it's mass (weight). You then define the positions in x/y/z coordinates of all the loading 'stations', be they fuel tanks or seats or cargo. You also define fuel load by it's x/y/z position combined with it's maximum load.

 

This combined with MOI values is how you define the balance of an aircraft in FS... and when done properly results in a fairly accurate behavior.

 

Now... how do I accomplish the same in X-Plane without writing an addon?

 

MortenM... your input was dismissive and insulting (using the 'loser' smiley to end your post is completely inappropriate)... I'm seeking answers, not attitude... and it was going along well until now.

[tkyler 88]

Ok..excellent Ed. In Planemaker, there is a menu item called, "weight and balance". In that menu, you specify the x, y, z position of the basic CoG, along with a fore and aft limit and several weight values. THEN, there is another tab where you can specify up to 8 "miscellaneous weights"...and you can give them each a name. These are intended for any "non fuel tank" weight, be it ballast, people, cargo, etc. There is only longitudinal offsets from the datum for these weights though, no lateral offsets. In addition, there is a "fuel tab" where you specify tanks, their locations, and their fuel ratios. With these defined, x-plane will ADD the effect of these masses to the basic RoG value to determine rotation rates about pitch, roll and yaw axes. During flight though, only the fuel depletion will affect the MoI dynamically. "people moving and shifting" is not simulated by default; however, there is a slider in the xplane menu during run-time where you can adjust the CoG forward or backward slightly to simulate slight shifts in CoG....a bit inconvenient to stop the sim while in a menu I know, but at least its there.

 

Where the custom RoG comes in is to simulate the basic empty weight Moi with no fuel, people are cargo. This value is usually too low by x-plane and so the aircraft feel twitchy. So you should adjust this value and THEN go ahead an add in all your other masses via the weight and balance screen and x-plane will calculate the resultant forces on the aircraft depending on attitude, airflow, angles, etc.

 

You mention, "This combined with MOI values...." I am assuming you assign MOI values in MSFS then? Setting a custom RoG is the exact same thing. In fact, the RoG is s term in the MoI equation; however, so is mass, which is handled by your weight settings in x-plane...which takes gravity into account, which is why Austin can do a simulation on Mars..or the moon. The only independent variable in the MoI equation is the RoG...austin handles the mass.

 

Tom K