use config file to "flip" instead of calculating inverted coords for use in flight model --> www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> FlightGear Coordinate Systems

FlightGear Coordinate Systems

Draft

FlightGear positions models, whether static buildings or moving aircraft, in the three dimensional environment using latitude, longitude and altitude. I will call this the FlightGear World Coordinate system, which this document will only touch upon. Each model is placed in this three dimensional world, but also may be (and generally is) composed from one or more three dimensional objects. Each of the three dimensional objects making up the model is positioned relative to a 3d origin (0,0,0). The origin is positioned at a given location in the world coordinate system.

To simulate and model an aircraft, FlightGear may require a number of coordinate systems. The Flight Data Model may define a number of coordinate systems, which some may be for internal use or are concerned with the flight model and of no concern to the modeler or the visual model. FlightGear needs at least one coordinate system to position the aircraft in the world environment, another to position the the parts of the aircraft model, and a third within the flight data model matching significant points in the aircraft model to the the flight data model.

The coordinate system positioning models in the FlightGear environment will be called the FlightGear World Coordinate System. The system positioning objects of the 3d model will be called the FlightGear Visual Model Coordinate System. The system for positioning significant features of the aircraft for use by the Flight Data Model will be called the FlightGear Flight Data Model Coordinate System, which does not include other systems used by the flight data model, only those that relate to the visual model.

The FlightGear Visual Coordinate System

This system provides a frame of reference for locating elements of a visual model with respect to its origin. When the model is rendered in the FlightGear visual environment, it also decides the orientation of the model. It also defines how the model moves, which axes represent pitch, roll and yaw. It does not specify where in the FlightGear environment the model appears, which is specified by the latitude, longitude and altitude of the world coordinates.

It is important, as will be seen, to relate the visual coordinates to the flight data model coordinates. For example, if they do not correspond, the aircraft may visually pitch about the tail or nose (or even some location outside the aircraft) instead of the wing.

FlightGear visual coordinate system.

Flight Data Model Coordinate Systems

A flight data model defines the performance characteristics of an aircraft and the physical locations of important features, such as the location of wings, stabilizers and points where the aircraft contacts the ground (landing gear). The FDM may use one or more coordinate systems, some for internal use, but there is at least one coordinate system that specifies the locations for important parts of the aircraft. The parts are specified relative to the FDM coordinate system origin (0,0,0).

This FDM coordinate system must be, well, coordinated with the visual model. Otherwise, the visual model's movements will not occur in the correct place. It may move with an apparent center of gravity somewhere outside, for example, forward of the nose instead of the actual center of gravity.

The origin of FDM coords may be matched up with the origin of the visual model coords, or it may be offset. This offset is called the Visual Reference Point. Although expressed as a coordinate (x,y,z) it represents an offset, or the distance between the visual model origin and the flight data model origin. This allows the visual model maker to place the nose of the aircraft at the origin and the flight data model maker to place the parts of the aircraft important to the flight data model relative to the origin without worrying where the same parts are visually represented.

Although FlightGear comes with a number of flight data models, the most widely used are Yasim and JSBSim. Each has its own coordinate system (five in the case of JSBSim!).

Yasim Coordinates

Yasim flight data model coordinate system.

In the Yasim coordinate system the X axis is directed fore, not aft, the typical direction for aircraft plans. The aircraft direction of motion when moving forward is in the direction of the positive X axis.

If you imagine the fuselage of the aircraft (the longitudinal axis) placed along the X axis, the nose of the aircraft points in the same direction as the X axis (in a positive direction).

JSBSim Coordinates

JSBSim flight data model coordinate system.

Understanding the Difference Between Yasim and JSBSim Coordinate Systems

Comparing JSBSim and Yasim coordinate systems.

To illustrate the relation between Yasim and JSBSim coordinate systems:

Hold your right hand out in front of you. Point your index finger forward, move your second (middle) finger toward the palm (in case you might be double jointed!) until it is at 90 degrees to the first finger, raise your thumb until it is 90 degrees to the other fingers (pointing straight up). Your index finger represents the direction of the X axis, the second finger represents the direction of the Y axis and the thumb represents the direction of the Z axis.

Continue holding your hand in this position. Turn your hand (hopefully your wrist and arm will follow...) until the index finger rotates 180 degrees and is pointing at you. The X is back (pointing toward you), the Y is right (relative to yourself) and the Z is up.

It may help to think of yourself as an aircraft. With the nose pointing forward, like your nose, and you back pointing aft.

YASim and JSBSim coordinates translate between each other with a 180 degree rotation about the Z axis. That does not change the handedness.

This is a specific application of a rule or trick designed to demonstrate the handedness of a three dimensional coordinate system. See (http://en.wikipedia.org/wiki Cartesian_coordinate_system) for an explanation of handedness and the right and left handed rules.

An easy way to remember the Yasim coordinate system is: The X is forward (pointing away from you), the Y is left, the Z is up.

Reconciling the Flight and Visual Models

Yasim

Yasim reports to FlightGear the location of the origin in aircraft coodinates (FDM coordinates), which means the Yasmin aircraft will appear to rotate about the origin of the visual aircraft model (except for any repositioning due to 'offset' in the aircraft configuration.

Visual Reference Point

VERY DRAFT: This needs rethinking.

The Visual Referenece Point is a feature specific to the JSBSim flight data model. This section aims to explain the visual reference point and related ideas, such as how center of gravity applies to all of this.

Suppose you and a friend intend to model an aircraft. Suppose the FDM modeler places the origin a short distance in front of the aircraft nose.

Note: In aircraft maintenance documents, the reference position is typically placed a few meters in front of the nose.

Visual reference point.

This illustration is valid for the JSBSim coordinate system. It is intended to show you how the various elements relate in any coordinate system, however, the axes may be oriented differentl depending on the flight data model (However, since currently only JSBSim implements VRP, you do not have to worry about that for now). You only need to take away from this the concept of how the model coordinate system works and how the visual reference point relates to it. (Remember, this is a visualization of the aircraft in the flight data model. The FDM never actually describes a visual model).

Suppose the visual model maker placed the nose of the aircraft at the origin:

Visual reference point.

The two models must be reconciled. Otherwise, the flight data model will not correspond to what is rendered visually in the simulation.

Visual reference point.

To do this, the idea of a Visual Reference Point is introduced. The VRP is not actually a point, but is an offset from the origin expressed as a coordinate. [Is this correct?]

Important: The Visual Reference Point pertains only to the Flight Data Model. It is not part of the FlightGear simulator proper, but belongs only to the flight data model. Several FDMs are avaialble for user with FlightGear. Each may or may not implement a VRP. How the VRP is used is determined by the FDM in use. At the time of writing the VRP only applies to JSBSim FDM. The VRP is specified to the FDM. It is only meaningful to the FDM. [Not sure about this]It is not a point or location, but is an offset expressed as in point form (x,y,z).

Center of Gravity

The most important point to remember about center of gravity as it relates to FlightGear is:

The flight data model rotates about the center of gravity.

There are no exceptions to this, otherwise, the flight data model for an aircraft would be flawed.

In real life aircraft rotate about their center of gravity.

The flight data model computes the center of gravity. It computes this location from the locations and weights of significant parts of the aircraft. It is the responsibility of the flight data model to report the position of the aircraft origin relative to the world (in terms of latitude, longitude and altitude). The flight data model is responsible for computing center of gravity; the FlightGear view is responisble for rendering the aircraft visual model.

Center of gravity comes in two varieties. The parts making up an aircraft can be evaluated to compute a static center of gravity. This is a fixed point, which does not move relative to the aircraft as you consume fuel (or change other quantities, such as shifting cargo, dropping tanks, sky divers leaving the plane, etc.). The static CG is an abstract value, which is not achieveable in a flying aircraft. It may exist with the empty weight aircraft sitting in a hanger or in the engineering calculations, but not in the real world during flight. The dynamic center of gravity calculation takes the changing factors into account. This is the true center of gravity during flight.

The Flight Data Model should compute a dynamic center of gravity for the greatest accuracy and realism. I say should, because FlightGear comes with a number of FDMs and anyone can write an FDM and plug it in to the simulation. Both major FDMs, Yasim and JSBSim compute a dynamic center of gravity. I cannot vouche for other FDMs, such as the UFO.

Experiment: Load a Yasim aircraft, open the Weight and Fuel settings dialog and move the sliders around. Watch how the aircraft reacts. You have just proved Yasim computes a dynamic center of gravity.

Note: Not all parts of an aircraft are modeled by the flight data model. Only those which contribute significantly to the accuracy of the model, the efficency of the simulation or the desired characteristics of flight are included in the model. For example, the weight and location of every gauge on the cockpit is not taken into account, although in some future flight data model, they potentially could figure into the center of gravity computation. Or in the Yasim model, "ballast" may be added to certain locations in the aircraft flight data model to collectively represent the effective weight of individual aircraft components left out of the model.

One confusing aspect of center of gravity, is the aircraft flight data model does not rotate about the origin, but about the center of gravity computed by the flight data model. Thus the model imitates real life. The function of the coordinate system is so the flight data model knows where are the parts of the aircraft are located. From the perspective of the flight data model, each part of the aircraft model is positioned relative the origin of its coordinate system. The aircraft as modeled by the FDM rotates about the center of gravity computed by the flight data model. (The flight data model does have its own coordinate system with an origin).

The Center of Gravity Problem

The center of gravity problem can be stated simply:

The visual model does not rotate about the center of gravity.

To make this clear, the visual model is not rendered at the center of gravity computed by the flight data model, but at a fixed location determined by the visual model origin. The outside view points the 3d camera to the visual model origin. The aircraft model rotates about this location. If the model's nose is placed at the origin, the aircraft will appear to rotate about the nose. If the origin is placed on the fuselage near the wing, it will appear to rotate about the wing. If the orgin is placed somewhere out ahead of the nose, it will appear to rotate at a point in empty space in front of the aircraft.

If you wish the aircraft visual model to move about the center of gravity, the best you can do is choose a location as close as possible to the expected center of gravity typical for the aircraft.

To demonstrate the problem, you can try the following experiment in FlightGear.

Experiment: Make a few loops in the Sunrise (an aircraft with the visual origin set to the nose) and the Heinkel (an aircraft with the visual origin set close to the expected center of gravity). Compare how both models look from the outside view. Rotate the view so you see the aircraft from the side. Pitch the aircraft. You should see one pitching about the nose and the other pitching about the middle.

The center of gravity for an aircraft may change during a flight. As fuel is consumed, the center of gravity will change. If cargo or passengers were to shift, the center of gravity would change. When this happens, the fixed "center of gravity" you chose for your model may differ from the actual center of gravity computed by the flight data model.

Placing the visual model close to the approximate center of gravity works because typical changes in center of gravity are small. The center of gravity for a small aircraft does not vary enough for a viewer to see the difference. It may vary sufficiently for a larger aircraft, such as an airliner. Many aircraft will experience only a small change of center of gravity with fuel consumption, because the fuel load is arranged so changes in center of gravity are small. There are very few aircraft (the Concorde comes to mind) that have significant center of gravity changes due to fuel distribution.

One thing to keep in mind, is the visual model representation of center of gravity is always technically inaccurate. People may speak of "center of gravity" for a visual model, but that only refers to either a specific center of gravity for the aircraft itself when not fueld, loaded and flying or to an approximate expected center of gravity during flight.

The 3d Model Coordinate System

The application used to construct and modify 3d models also uses a coordinate system. These are fairly standard across 3d editors. It is important to understand how the 3d model coordinates relate to the flight data coordinates and visual model coordinates when building an aircraft.

Important Points for the Aircraft Model Builder

Before you begin to model an aircraft, there are some important points to keep in mind.

It can be difficult to envision the flight data model. There is no visual representation or virtural parts to manipulate like a visual model in a 3d editor has. Only a few significant parts of the aircraft are represented, such as the wings, the horiztonal stabilizer, the vertical stabilizer, etc., which are simplified and disembodied from the other parts of the aircraft. Each part is positioned within the aircraft coordinate system used by the flight data model relative to the origin. The vertical stabilizer is so many meters away from the origin, the root of the left wing is so many meters to the left of the origin, etc. The center of gravity computed by the flight data model is positioned somewhere it this frame of refernce also. What is difficult to grasp, is when computing the next state for the aircraft, the parts of the aircraft defined in this framework rotate around the computed center of gravity. However, for Yasim, the position of the aircraft coordintate _origin_ is reported, not the position of the center of gravity.

The FDM model has an origin, a (0,0,0) point in its coordinate system. The visual model has an origin, (0,0,0) point in its coordinate system. The position of aircraft parts must correspond in each model. For example, the wheel must be in the same location as the FDM contact point, the vertical stabilizer must be the same distance from the origin in the FDM model as it is in the visual model. The origin is not the same as the reference point you find in an aircraft manual or engineering plan. Both may be in the same location, but they are not the same. Do not become confused by all the origins and reference points. The origin in the FDM model is a reference point for parts of the aircraft in the FDM. The origin in the 3d model is a reference point for locating parts of the aircraft in the 3d model. The parts of the aircraft must be in the same position in each model for the aircraft to be modeled correctly. Otherwise, the wheel in the FDM model may contact the ground before the wheel in the visual model appears to touch the ground.

What does it mean to "place the aircraft in the flight data model at the expected or static center of gravity?" All parts defined in the FDM model are placed relative to the origin. So a wing at (3,3,3) is 3 meters up from the origin, three meters to one side of the origin and three meters back or in front of the origin (depending on what coorindate system you use). In any event is is 3 meters x, 3 meters y and 3 meters z away from the origin. But where is this origin in relation to the real aircraft? Only by matching the origin of the flight data model aircraft up with the origin of the visual model or aircraft plans can we place the parts in the FDM coordinates. If a plan exists, which shows the vstab is 12 meters negative X axis from an origin on the plans, then we need to make the FDM origin that on the plans. Then specify 12 meters back from the origin in the FDM. This works as long as the plans coord system and the FDM coord system match. The same is true for the visual model. One would match the origin of the visual model to the FDM origin, so if the vstab was 12 meters X in the model, it would be 12 meters X in the FDM. Now, there may be a difference coordinate system or origin in the plans than the visual model.