flight simulation final report

International School of Engineering

Chulalongkorn University

FLIGHT SIMULATION

Raksok Khankhampoch ID: 503 13960 21

E-mail: [email protected] Phone: 085 393 5599

Sorasit Thongjeen ID: 503 14359 21

E-mail: [email protected] Phone: 080 595 7849

Advisor: Asst. Prof. Niphon Wansophark Signature Date .

Academic Year 2010

| AERO Senior Project Final Report 2010 Flight Simulation

1. Introduction

In the past, because of complexity of the calculation process inside the system, flight simulation is

limited only for a group of expert scientist or engineers whose can afford a mainframe computer

or a super computer to handle such a level of calculation, and another reason for it to be confine

only within a group of expert is that each mainframe required specific input code to be programed

to handle the process. So, the development is confine only in major institute.

However, since the starting of the silicon age, consumer level computers are becoming smaller

whereas having higher calculation power. Also from the development of software in both quality

and compatibility to have better method of presenting and operating (i.e. no specific code need to

be program for each kind of machine). With these two major reason, a possibility of the building

flight simulation on consumer level computer arise and has been continuing develop widely

around the world for many application (e.g. flight control development, flight test support).

This project was motivated from those reasons, and for the benefit of Aerospace engineering

students at ISE, Faculty of engineering, Chulalongkorn University that can use this system in

aircraft design process. The flight simulations that use in aircraft design process are difference

from those that use for crew training or entertainment purpose (gaming) which is a level of data

acquisition. For a design process, it is almost 2 times higher level of data acquisition than that for

training.

The flight simulation system is a large scale project compose with significant level of complexity

with the limitation of time, this project will concentrate on the control system of the aircraft.

Therefore, the expected out comes at the end of the project is to use this flight simulation system

to observe the handling quality of the aircraft.

2. Background

2.1 Flight dynamics

The main component for flight dynamics are

2.1.1. Equation of motion

The equations of motion are focal point of all flight simulators. They determine the state of the

simulator, taking all the inputs, including pilot controls, winds, aerodynamic terms and engine

terms to compute the variables that represent the state of the simulated aircraft, particularly

forces, moments, attitude, altitude, heading and velocities. This translation of inputs to outputs

depends on the equations of motions used to resolve the linear and rotary motion of the aircraft

and includes the aerodynamic data for the aircraft, details of the undercarriage and engine data,

usually provided in the form of tables and graphs of data.

2.1.2. Aircraft model

The aerodynamic model enables the aerodynamic forces and moments to be computed. For

example, the coefficient of lift may be derived as a function of the angle of attack where the

specific aerodynamic coefficients are defined in the aerodynamic database.

The aerodynamic data is provided as a large database, typically in the form of several thousand

graphs of the aerodynamic variables, often as functions of two or three variables. This database is

likely to have been obtained from a combination of flight testing, wind tunnel tests and possibly

computational fluid dynamics (CFD) analysis. The database will also include a vast amount of

Flight Simulation AERO Senior Project Final Report 2010 | Page 2

validation data to enable the simulator developer to compare the simulator dynamics and

performance with actual aircraft data. From the manufacturer‟s perspective, this data has high

commercial value and is usually provided as part of a confidential agreement between the

operator, the aircraft manufacturer and the simulator manufacturer.

The aerodynamics model is possibly the most critical element of a flight simulator/simulation. An

error in modeling the aircraft aerodynamics can lead to a simulation which might fail.

Consequently, the aerodynamic data package produced by the aircraft manufacturer is

expensive. For this reason, there are very few detailed data packages available in the public

domain. Although it is possible to acquire this data from flight trials, the cost of aircraft

instrumentation, operation of flight trials, data recording and data analysis can be prohibitive to

simulator companies. This is an issue sometimes missed by prospective simulator developers;

there is no simple way to acquire this data and just a few errors in the aerodynamic data package

can result in an unacceptable aircraft model. For this reason, in this project the aerodynamics

data are compute from the computer program which gives an acceptable set of data.

2.1.3. Aircraft stability and control

The airplane is a dynamic system with six degrees of freedom, three in translation and three in

rotation. In general, airplane motion is characterized by three linear and three angular

accelerations under the action of gravitational, Inertial, and aerodynamic and propulsive forces

and moments. However, a significant portion of the airplane's flight envelope consists of steady

flight conditions such as cruise, climb, or glide. For such flight conditions, the principles of static

equilibrium can be applied. This approach can be extended to some class of maneuvers like pull -

up from a dive in vertical plane or a steady turn in horizontal plane. This background will also be

helpful to understand the dynamic motion of the airplane.

2.2 Computer simulation

Apart from the flight dynamic, the computer simulation is the parts where all the simulation

process performs. These important components are:

2.2.1. Data acquisition

In a flight simulation system the flight deck is an exact replica of the aircraft flight deck. Indeed,

some of the equipment in the simulator may use actual aircraft parts, as it may be more

expensive to fabricate a facsimile than to purchase the certified aircraft equipment. In addition to

the primary flight controls (control column, rudder pedals, brakes, flap selector, gear selector,

etc.), every lever, selector, knob and switch must be interfaced to the appropriate simulator

module.

Some of these inputs provide digital data (0 or 1), often referred to as discrete data, whereas

other inputs are analogue data. The current selection of inputs must be sampled during each

frame, converted to an appropriate value and passed to the relevant simulator module. For some

sub-systems, for example, a radio panel, these inputs are monitored and computed by a local

processor in the module and passed as serial data or parallel data. Nevertheless, a full flight

simulator may have several hundred inputs. Typically, the sampling and storage of this data is

handled by one (or more) processor(s), dedicated to the data acquisition function.

For analogue data, particularly for the flight controls, data capture is critical to the fidelity of the

simulator. The data acquisition software is responsible for minimizing any delay in capturing the

data, for ensuring that the resolution of the data is as high as possible and that any signal

conditioning or filtering of the data is correctly applied. In practice, data is derived from simulator

signals by analogue-to-digital conversion hardware. Although sampling at rates up to 60 Hz is


straightforward with modern data acquisition hardware, the typical resolution of sampled data is

only 12–16 bits, which is far below the resolution of data used elsewhere in the simulation. In

addition, this data is measured by potentiometers that are inherently noisy or linear voltage

differential transformers (LVDTs); as the signals are small (in terms of current), they are

susceptible to noise and interference from other signals and considerable effort is given to

providing a good earth connection and cable shielding for analogue signals in order to minimize

any signal distortion from interference.

2.2.2. Visual system

The visual system provides a number of channels of real-time images seen from the pilot eye

position. Initially, a database of objects is loaded into the visual system memory. The database

may contain fields, airfields, roads, lakes, coastline, vehicles, buildings, trees, forest, vegetation

and aircraft. Various standards exist to generate these entities, with OpenFlight probably the

most widely used format. Each object is reduced to colored and textured polygons (usually

triangles), defined in the coordinate system (and units) of the database. Quite often these objects

are arranged in some geometric order so that different levels of detail can be displayed according

to the distance from the object.

As the aircraft maneuvers, the pilot eye position and orientation are computed in the equations of

motion and the scene is rendered every frame (typically 60 Hz). Depending on the imaging

system, there is a delay between acquiring a new eye position and the pilot seeing the projected

image (in addition to any delay in computing the pilot eye position and passing this information to

the visual system). This delay, often referred to as visual latency, must be kept to a minimum but

can extend to three or four frames (four frames at 50 Hz is 80ms). A value of 100ms is generally

accepted as the worst case allowable latency (depending on the aircraft dynamics) and figures of

20–50ms are more commonly quoted for current flight simulators.

The quality of the visual system depends very much on the characteristics of the underlying

graphics engine. A graphics card will be bounded in terms of the draw rate to render polygons

and also the fill rate to texture the polygons. As more scene detail is added, the frame rate may

drop below the minimum value for a particular simulator. Similarly, if the polygon count is reduced

to increase the rendering rate, the scene detail may reduce to an unacceptable level. These

values also depend on:

• The display resolution (in terms of pixels) – if the resolution is increased, the drawing rate is

reduced as more pixels need to be drawn per unit area;

• The display refresh rate – if the refresh rate is increased, less time is available per frame for

rendering;

• The memory access speed of the graphic frame buffer memory – each pixel must be written

to the frame buffer every frame;

• The architecture of the graphic processor – particularly, its interface to the frame buffer

memory;

• Any anti-aliasing applied to smooth polygon edges – considerable processing is needed to

generate smooth edges.


2.3 FlightGear

2.3.1 What make FlightGear difference than others simulator?

Did you ever want to fly a plane yourself, but lacked the money or ability to do so? Are you a real

pilot looking to improve your skills without having to take off? Do you want to try some dangerous

maneuvers without risking your life? Or do you just want to have fun with a more serious game

without any violence? If any of these questions apply to you, PC flight simulators are just for you.

You may already have some experience using Microsoft‟s c Flight Simulator or any other of the

commercially available PC flight simulators. As the price tag of those is usually within the $50

range, buying one of them should not be a serious problem given that running any serious PC

flight simulator requires PC hardware within the $1500 range, despite dropping prices.

With so many commercially available flight simulators, why would we spend thousands of hours of

programming and design work to build a free flight simulator? Well, there are many reasons, but

here are the major ones:

All of the commercial simulators have a serious drawback: they are made by a small group of

developers defining their properties according to what is important to them and providing

limited interfaces to end users. Anyone who has ever tried to contact a commercial developer

would agree that getting your voice heard in that environment is a major challenge. In

contrast, FlightGear is designed by the people and for the people with everything out in the

open.

Commercial simulators are usually a compromise of features and usability. Most commercial

developers want to be able to serve a broad segment of the population, including serious

pilots, beginners, and even casual gamers. In reality the result is always a compromise due to

deadlines and funding. As FlightGear is free and open, there is no need for such a

compromise. We have no publisher breathing down our necks, and we‟re all volunteers that

make our own deadlines. We are also at liberty to support markets that no commercial

developer would consider viable, like the scientific research community.

Due to their closed-source nature, commercial simulators keep developers with excellent

ideas and skills from contributing to the products. With FlightGear, developers of all skill levels

and ideas have the potential to make a huge impact on the project. Contributing to a project

as large and complex as FlightGear is very rewarding and provides the developers with a

great deal of pride in knowing that we are shaping the future of a great simulator.

Beyond everything else, it‟s just plain fun! I suppose you could compare us to real pilots that

build kit-planes or scratch-built. Sure, we can go out a buy a pre-built aircraft, but there‟s just

something special about building one yourself.

The points mentioned above form the basis of why we created FlightGear. With those motivations

in mind, we have set out to create a high-quality flight simulator that aims to be a civilian, multi-

platform, open, user-supported, and user extensible platform. Let us take a closer look at each of

these characteristics:

Civilian: The project is primarily aimed at civilian flight simulation. It should be appropriate for

simulating general aviation as well as civilian aircraft. Our long-term goal is to have FlightGear

FAA-approved as a flight training device. To the disappointment of some users, it is currently not

a combat simulator; however, these features are not explicitly excluded. We just have not had a

developer that was seriously interested in systems necessary for combat simulation.

Multi-platform: The developers are attempting to keep the code as platform independent as

possible. This is based on their observation that people interested in flight simulations run quite a


variety of computer hardware and operating systems. The present code supports the following

Operating Systems:

- Linux (any distribution and platform),

- Windows NT/2000/XP (Intel/AMD platform),

- Windows 95/98/ME,

- BSD UNIX,

- Sun-OS,

- Mac OS X

At present, there is no other known flight simulator – commercial or free – supporting such a

broad range of platforms.

Open: The project is not restricted to a static or elite cadre of developers. Anyone who feels they

are able to contribute is most welcome. The code (including documentation) is copyrighted under

the terms of the GNU General Public License (GPL). The GPL is often misunderstood. In simple

terms it states that you can copy and freely distribute the program(s) so licensed. You can modify

them if you like and even charge as much money as want to for the distribution of the modified or

original program. However, when distributing the software you must make it available to the

recipients in source code as well and it must retain the original copyrights. In short:

”You can do anything with the software except make it non-free”.

The full text of the GPL can be obtained from the FlightGear source code or from gnu website:

http://www.gnu.org/copyleft/gpl.html.

User-supported and user-extensible: Unlike most commercial simulators, FlightGear‟s scenery

and aircraft formats, internal variables, APIs, and everything else are user accessible and

documented from the beginning. Even without any explicit development documentation (which

naturally has to be written at some point), one can always go to the source code to see how

something works. It is the goal of the developers to build a basic engine to which scenery

designers, panel engineers, maybe adventure or ATC routine writers, sound artists, and others

can build upon. It is our hope that the project, including the developers and end users, will benefi t

from the creativity and ideas of the hundreds of talented “simmers” around the world.

Without doubt, the success of the Linux project, initiated by Linus Torvalds, inspired several of the

developers. Not only has Linux shown that distributed development of highly sophisticated

software projects over the Internet is possible, it has also proven that such an effort can surpass

the level of quality of competing commercial products.

2.4 JSBSim

2.4.1 What exactly is JSBSim?

From an application programming perspective, JSBSim is a collection of program code mostly

written in the C++ programming language (but some C language routines are included). Some of

the C++ classes that comprise JSBSim model physical entities such as the atmosphere, a flight

control system, or an engine. Some of the classes encapsulate concepts or mathematical

constructs such as the equations of motion, a matrix, quaternion, or vector. Some classes

manage collections of other objects. Taken together, the JSBSim application takes control inputs,

calculates and sums the forces and moments that result from those control inputs and the

environment, and advances the state of the vehicle (velocity, orientation, position, etc.) in discrete

time steps.

http://www.gnu.org/copyleft/gpl.html


JSBSim has been built and run on a wide variety of platforms such as a PC running Windows or

Linux, Apple Macintosh, and even the IRIX operating system from Silicon Graphics. The free

GNU g++ compiler easily compiles JSBSim, and other compilers such as those from Borland and

Microsoft also work well.

From a user perspective (assuming that the user is not involved in programming), JSBSim can be

viewed as sort of a ―black box‖ which is supplied with input files in XML format. These XML files

contain descriptions of an aerospace vehicle, engines, scripts, and so on. When these files are

loaded into JSBSim, they direct it to model the flight of that vehicle in real-time as part of a larger

simulation framework (such as FlightGear or OpenEaagles), or faster than real-time in a batch

mode.

2.4.2 Who is it for, and how can it be used?

The JSBSim flight dynamics model (FDM) software library is meant to be reasonably easy to

comprehend, and is designed to be useful to advanced aerospace engineering students. Due to

the ease with which it can be configured, it has also proven to be useful to industry professionals

in a number of ways. It has been incorporated into larger, full-featured, flight simulation

applications and architectures (such as FlightGear, Outerra, and OpenEaagles), and has been

used as a batch simulation tool in industry and academia.

3. Literature review

The literature reviews for this project are presented here.

3.1 Results of a flight simulation software methods survey.

A ten-page questionnaire was mailed to members of the AIAA Flight Simulation Technical

Committee in the spring of 1994. The survey inquired about various aspects of developing and

maintaining flight simulation software, as well as a few questions dealing with characterization of

each facility. As of this report, 19 completed surveys (out of 74 sent out) have been received. This

paper summarizes those responses.

3.2 Status of AIAA modeling and simulation format standard.

Aircraft flight dynamic models are developed in many different source formats. When an aircraft

simulation was used entirely in-house, this diversity was not a problem. In recent years, however,

a single stovepipe entity taking an aircraft from concept to production is rare. Instead, teaming

arrangements with other manufacturing concerns and government agencies are now the norm. As

a result, the sharing of aircraft flight dynamic models is much more commonplace. Unfortunately,

each organization has their own simulation framework, coding standard, source language, and

data format, which requires a laborious and error-prone manual translation or re-hosting of the

simulation model between team members. To alleviate this time-consuming re-hosting, the

American Institute of Aeronautics and Astronautics (AIAA) Modeling and Simulation Technical

Committee (MSTC) has developed a text-based flight dynamic model exchange format, which

represents a 'neutral ground' standard that is facility and programming-language-independent

while providing distinct advantages over current practices. The cost and time required sharing and

updating aerodynamics, control laws, mass and inertia, and other flight dynamic components of

the equations of motion of an aircraft or spacecraft simulation can thereby be reduced. A 2002

paper1 estimated over $6 million in savings could be realized for one military aircraft type alone.

This paper describes the result of efforts by the MSTC to develop a standard flight dynamic model

exchange standard based on a specialized extensible markup language grammar. This standard,


the Dynamic Aerospace Vehicle Exchange Markup Language (DAVE-ML), is now being proposed

as an ANSI/ISO standard.

3.3 Modeling and Autonomous Flight Simulation of a Small Unmanned

Aerial Vehicle

This project describes the use of FlightGear, an open-source flight simulator, and JSBSim, an

open-source flight dynamics model, to model and simulate a small autonomous Unmanned Aerial

Vehicle (UAV).

A small commercial electric engine Cessna-182 radio controlled (RC) aircraft was chosen to

represent the UAV. The first step was to create the required JSBSim aircraft configuration files by

using the Aeromatic v0.8, a free web application to create aircraft configuration files for use with

the JSBSim. The next step was to make educated guesses to refine important sections in the

created configuration files with the assistance of available data of similar UAV.

In order to perform a visual simulation, a 3D model for the Cessna-182 (RC) was created using

AC3D, a commercial 3D modeling software tool.

To fly the modeled UAV autonomously a tuning process was made for the built-in generic PID

(proportional, integral, and derivative) autopilot of FlightGear, which has the ability to hold aircraft

velocity, vertical aircraft speed, altitude, pitch angle, angle of attack, bank angle, and true

heading.

Finally, a flight path, which contains a number of waypoints chosen over a selected area using

Google Earth map, was constructed. In order to use the chosen waypoints with FlightGear

navigation system, a unique ID was assigned to each waypoint, and the FlightGear database was

altered to include the new waypoints with their IDs. The outcome of the project was a complete

JSBSim flight dynamic model for the Cessna-182 (RC), with 3D model for visual simulation and

an effective autopilot. A good autonomous flight simulation was performed.

This project concluded that modeling and simulating a UAV accurately is not an easy task, due to

the need to calculate many parameters either by physical measurements, experiments, or

estimation from available data of similar UAV, or by software tools.

4. Objective

The objectives of this engineering flight simulation are the following

Be able to build the flight simulation system.

Be able to validate the result of the simulation.

Be able to use the valid system to evaluate the particular system of the desire aircraft.

5. Methodology

5.1 Simulation engine modification

FlightGear is the flight simulation system that already come with the packed of tools ready for use

as single user. However, the objective of this project was to create the flight simulation system

that aids in designing, learning and researching. Therefore, the standard package of FlightGear is

needed to be modified and customized to be compatible with our purpose of use.

This section will discuss about, how the system have been modified and the reason of the

modification of the following component in the system


5.1.1 Input device modification

Since the Joystick that purchases to use in the flight simulation system is not already support by

FlightGear, therefore, manual configuration is required.

According to the information shown in FlightGear , FlightGear treats each component of the

Joystick system as individual input device each one assign to the default input configuration which

known to cause problem.

<?xml version="1.0"?>

<PropertyList>

<name>default</name>

<axis n="0">

<desc>Aileron</desc>

<binding>

<command>property-scale</command>

<property>/controls/flight/aileron</property>

<squared type="bool">true</squared>

</binding>

</axis>

<axis n="1">

<desc>Elevator</desc>

<binding>


<property>/controls/flight/elevator</property>

<factor type="double">-1.0</factor>


</binding>

</axis>

<axis n="2">

<desc>Throttle</desc>

<binding>

<command>nasal</command>

<script>controls.throttleAxis()</script>

</binding>

</axis>

<button n="0">

<desc>Brakes</desc>

<binding>


<script>controls.applyBrakes(1)</script>

</binding>

<mod-up>

<binding>



</binding>

</mod-up>

</button>

<button n="0">

<desc>Brakes</desc>

<binding>



</binding>

Code 1:

Default input device configuration


The reason known to cause trouble are the way FlightGear treat the G940 System as individual

input device as mention before, and Logitech G940 is new product in market, FlightGear didn‟t

have any pre-configure file to support, as a result when start FlightGear there will be three n = 0

axis each from the stick, throttle and rudder pedal that can use to control the aileron.

To solve this issue, the separate configuration file for each of the device in the Joystick system

must be provided for FlightGear, which are Joystick configuration, Throttle configuration, and

Rudder configuration. Each with dedicate name for each device.

This following code is the configuration that custom made for the system. We have to put these 3

files into \Inputs\Joystick\Logitech folder in FlightGear data folder (normally is “C:\Program File

(x86)\FlightGear\data\Inputs\Joystick\Logitech” to make FlightGear recognize its.

Joystick configuration file <?xml version="1.0"?>

<PropertyList>

<name>Logitech G940 Joystick</name>

<axis n="0">

<desc>Aileron</desc>

<binding>




</binding>

</axis>

<axis n="1">

<desc>Elevator</desc>

<binding>



<factor type="double">-1.0</factor>


</binding>

<mod-up>

<binding>



</binding>

</mod-up>

</button>

<button n="1">

<desc>Elevator trim up</desc>

<repeatable type="bool">true</repeatable>

<binding>


<script>controls.elevatorTrim(1)</script>

</binding>

</button>

<button n="2">

<desc>Elevator trim down</desc>

<repeatable type="bool">true</repeatable>

<binding>


<script>controls.elevatorTrim(-1)</script>

</binding>

</button>

</PropertyList>

Code 1 (cont.):

Default input device configuration


</axis>

<axis n="3">

<desc>Elevator Trim</desc>

<binding>


<property>/controls/flight/elevetor-trim</property>

<factor type="double">1.0</factor>

</binding>

</axis>

<axis n="4">

<desc>Rudder Trim</desc>

<binding>


<property>/controls/flight/rudder-trim</property>

<offset type="double">0.0</offset>


</binding>

</axis>

<axis n="5">

<desc>Aileron Trim</desc>

<binding>


<property>/controls/flight/aileron-trim</property>

<offset type="double">0.0</offset>


<squared type="bool">false</squared>

</binding>

</axis>

</PropertyList>-

Throttle configuration file <?xml version="1.0"?>

<PropertyList>

<name>Logitech G940 Throttle</name>

<axis n="0">

<desc>Throttle-1</desc>

<binding>



</binding>

</axis>

<axis n="1">

<desc>Throttle-2</desc>

<binding>



</binding>

</axis>

<button n="0">

<name>T1</name>

<desc>Flaps Up</desc>

<repeatable>false</repeatable>

<binding>


<script>controls.flapsDown(-1)</script>

</binding>

<mod-up>

<binding>


<property>/sim/freeze/clock</property>

</binding>

<binding>

<condition>

<property>/sim/freeze/replay-state</property>

</condition>

<command>property-assign</command>

<property>/sim/freeze/replay-state</property>

<value type="int">0</value>

</binding>

</button>

<button n="7">

<name>P4</name>

<desc>Toggle HUD</desc>

<binding>


<script>aircraft.HUD.cycle_color()</script>

</binding>

</button>

<button n="8">

<name>P5</name>

<desc>Toggle Landing Gear</desc>

<binding>


<script>controls.gearToggle()</script>

</binding>

</button>

<button n="9">

<name>P6</name>

<desc>Toggle 2D/3D cockpit</desc>

<binding>


<script>

if(getprop("/sim/allow-toggle-cockpit")) {

setprop("/sim/current-view/internal", !getprop(

"/sim/current-view/internal"));

setprop("/sim/view/internal", getprop("/sim/current-view/internal"));

setprop("/sim/virtual-cockpit", !getprop("/sim/virtual-cockpit"));

if(getprop("/sim/current-view/internal")) {

setprop("/sim/current-view/heading-offset-deg", getprop(

"/sim/current-view/config/heading-offset-deg"));

setprop("/sim/current-view/pitch-offset-deg", getprop(

"/sim/current-view/config/pitch-offset-deg"));

} else {

setprop("/sim/current-view/heading-offset-deg", 0);

setprop("/sim/current-view/pitch-offset-deg", 0);

}

}

</script>

</binding>

</button>

<button n="10">

<name>P7</name>

<desc>Pilot View</desc>

<binding>

<command>property-assign</command>

<property>/sim/current-view/view-number</property>

<value>0</value>

</binding>

</button>

<button n="11">

<name>P8</name>

<desc>Cycle View</desc>

<binding>


<script>view.stepView(1)</script>

</binding>

</button>

</PropertyList>

Rudder pedal configuration file *note: since differential brake function wasn‟t working as expect (too sensitive) it has been

disable for convenient, however, can be re-enable if needed.


<PropertyList>

<name>Logitech G940 Pedals</name>



<axis n="3">

<desc>Rudder</desc>

<binding>


<property>/controls/flight/rudder</property>



</binding>

</axis>

</PropertyList>-

With these 3 configuration files, Joystick, throttle, and rudder pedal work again as it should, still

this configuration were rough fixed some function are completely left out for example, the button

on joystick wasn‟t configured because they are rarely use in our research environment that focus

on developing aircraft model not flying.


5.1.2 Multi-instance configuration

FlightGear is the scalable systems, which means each of its instances can be configure to do

certain job for example, one FlightGear instance can be configure to take responsible in Flight

dynamic model calculation, while another instance is responsible for displaying the environment.

The advantage of this multi-instance capability is that you can run everything from one computer

with multiple displays connected by have one of the instance take-over the responsibility of each

display to display the map and the middle panel (which will be discuss later ) and the main

graphic render display. Thus, this multi-instance capability is benefit for the small facility with low

amount of funding like us.

The key concept of configure multi-instance is that use loopback IP-address which will allow

computer to ping back to itself to simulate the network transfer data inside one computer. So, for

the main instance that will receive input and calculate flight dynamic of aircraft, these two

parameter have to be add before run the instance

--native-fdm=socket,out,60,127.0.0.1,5500,udp

--native-ctrls=socket,out,60,127.0.0.1,5501,udp

And in our case that have to run 2 others instance in parallel we need to add another set of this

line with change in port number (5500, 5501) the parameter when run the main instance will

become,




–-native-ctrls=socket,out,60,127.0.0.1,5508,udp

Now move to the client or child instance that will be receiving the data from the main instance.

These parameters also needed to be added. However, we can‟t use the main launcher program

like the main instance. Every time we want to run the child instance it has to be done by

command prompt which is take time to type the command, thus, it better to put every command

into batch file.

The batch file is simply the set of command that will execute together when the batch is run. So it

needs to create one for each instance. The above code is for the external environment instance

that goes to projector next code is the view that goes to the middle display of panel.

cd "C:\Program Files\FlightGear\bin\Win64"

ECHO running flightgear

fgfs --fg-root="C:\Program Files (x86)\FlightGear\data" --fg-

scenery="C:\Program Files (x86)\FlightGear\data\Scenery";"C:\Program

Files (x86)\FlightGear\scenery";"C:\Program Files

(x86)\FlightGear\terrasync" --aircraft=dhc2W --timeofday=noon --native-

fdm=socket,in,60,127.0.0.1,5500,udp --native-

ctrls=socket,in,60,127.0.0.1,5501,udp --fdm=null --disable-hud --disable-

sound --prop:/sim/ai/enabled=false --prop:/sim/ai-traffic/enabled=false -

-prop:/sim/rendering/bump-mapping=false --prop:/sim/rendering/draw-

otw=false

Code 2:

The batch file code for running the main environment instance of FlightGear.


5.1.3 Multi-computer configuration

Due to the technical limitation of the hardware, multi-computer have been implies to take over the

primary flight display (PFD) and the secondary display.

The idea of multi-computer is simple as the multi-instance for FlightGear, except instead of

loopback to the main computer, it actually sends out the data package to other computer.

For example, the IP Address of a computer that have main instance running is 169.200.94.210,

while IP address for client computer is 169.200.94.211. The configuration line in main instance

should look like this.



And the configuration parameter at the client computer should look like this

--native-fdm=socket,in,60,169.200.94.210,5509,udp

--native-ctrls=socket,in,60,169.200.94.210,5510,udp

Note that there is the change between “in” mode and “out” mode and IP address differences due

to the change of system.

5.1.4 Logging configuration

This simulation system can‟t be used for conduct the research if it can‟t log out data during flight

to analyses, there are several ways to log the data out from FlightGear, this is the simple one

which is to create another configuration file that tell FlightGear what variable that need to track

and load that configuration file into FlightGear main instance before running. The following code is

the configuration code that we recently use.


<PropertyList>

<logging>

<log>

<enabled>true</enabled>

<filename>Flight-log.csv</filename>

<interval-ms>1000</interval-ms>

<delimiter>,</delimiter>

<entry>


<title>Elevator Defection Angle(deg)</title>

<property>/fdm/jsbsim/fcs/elevator-pos-deg</property>

</entry>

Code 4:

Logging code that use during simulation test flight include validation process

cd "C:\Program Files\FlightGear\bin\Win64"

ECHO running flightgear

fgfs --fg-root="C:\Program Files (x86)\FlightGear\data" --fg-

scenery="C:\Program Files (x86)\FlightGear\data\Scenery";"C:\Program

Files (x86)\FlightGear\scenery";"C:\Program Files

(x86)\FlightGear\terrasync" --aircraft=SenecaII-panelonly2 --

geometry=1280x1024 --timeofday=noon --native-

fdm=socket,in,60,127.0.0.1,5507,udp --native-

ctrls=socket,in,60,127.0.0.1,5508,udp --fdm=null --disable-hud --disable-

sound --prop:/sim/ai/enabled=false --prop:/sim/ai-traffic/enabled=false -

-prop:/sim/rendering/bump-mapping=false --prop:/sim/rendering/draw-

otw=false

Code 3:

The batch file code for running instrument in middle display.


<entry>


<title>Elevator condition</title>


</entry>

<entry>


<title>Aileron condition</title>


</entry>

<entry>


<title>Roll</title>

<property>/orientation/roll-deg</property>

</entry>

<entry>


<title>Pitch</title>

<property>/orientation/pitch-deg</property>

</entry>

<entry>


<title>Yaw</title>

<property>/orientation/heading-deg</property>

</entry>

<entry>


<title>Acceleration in Z-Axis(fps^2)</title>

<property>/accelerations/pilot/z-accel-fps_sec</property>

</entry>

<entry>


<title>Rate Height (h-dot)(fps)</title>

<property>/fdm/jsbsim/velocities/h-dot-fps</property>

</entry>

<entry>


<title>Acceleration in X-Axis(fps^2)</title>

<property>/accelerations/pilot/x-accel-fps_sec</property>

</entry>

<entry>


<title>Airspeed(kt)</title>

<property>/velocities/airspeed-kt</property>

</entry>

<entry>


<title>Mach</title>

<property>/velocities/mach</property>

</entry>

<entry>


<title>Height(ft)</title>

<property>/position/altitude-ft</property>

</entry>

<entry>


<title>Throttle%</title>

<property>/controls/engines/throttle</property>

</entry>

<entry>


<title>Latitude(deg)</title>

<property>/position/latitude-deg</property>

</entry>

Code 4 (cont.):



5.2 DATCOM Program capability

This section has been prepared to assist user in his decision process concerning the applicability

of the USAF Stability and Control Digital Datcom to his particular requirements. For specific

questions dealing with method validity and limitations, the user is strongly encouraged to refer to

the USAF Stability and Control Datcom document. Much of the flexibility inherent in the Datcom

methods has been retained by allowing the user to substitute experimental or refined analytical

data at intermediate computation levels.

Extrapolations beyond the normal range of the Datcom methods are provided by the program;

however, each time an extrapolation is employed, a message is printed which identifies the point

at which the extrapolation is made and the results of the extrapolation. Supplemental output is

available via the “dump” and “partial output” options which give the user access to key

intermediate parameters to aid verification or adjustment of computations. The following

paragraphs discuss primary program capabilities as well as selected qualifiers and limitations.

5.2.1 Addressable configurations

In general, Datcom treats the traditional body-wing-tail geometries including control effectiveness

for a variety of high-lift /control devices. High-lift/control output is generally in terms of the

incremental effects due to deflection. The user must integrate these incremental effects with the

“basic” configuration output. Certain Datcom methods applicable to reentry type vehicles are also

available. Therefore, the Digital Datcom addressable geometries include the “basic” traditional

aircraft concepts (including canard configurations), and unique geometries which are identified as

“special” configurations. Table 1 summarizes the addressable configurations accommodated by

the program.

<entry>


<title>Longtitude(deg)</title>

<property>/position/longtitude-deg</property>

</entry>

</log>

</logging>

</PropertyList>

Code 4 (cont.):


Configuration Program remarks

Body

Primarily bodies of revolution, or close approximations, are treated. Transonic methods for most of the aerodynamic data do not exist. The recommended procedure requires fairing between subsonic and supersonic data using available data as a guide

Wing, Horizontal Tail

Straight tapered, cranked, or double delta planforms are treated. Effect of sweep, taper and incidence are included. Linear twist is treated at subsonic Mach numbers, dihedral effects are present in the lateral directional data

Body-wing body-horizontal

Longitudinal methods reflect only a mid-wing position. Lateral directional solutions consider high and low-wing positions.

Wing-body-tail

The various geometry combinations are given in table. Wing downwash methods are restricted to straight tapered planforms. Effects of twin vertical tails are included in the static lateral directional data at subsonic Mach numbers.

Non-standard geometries

Non-standard configurations are simulated using “basic” configuration techniques. Strakes can be run via a double delta wing. A body-canard-wing is input as wing-body-horizontal tail. The forward lifting surface is input as a wing and the aft surface as a horizontal tail.

Special configuration

Low aspect ratio wing or wing-body configurations are treated at subsonic. Two-dimensional flap and transverse jet effects are also treated at hypersonic.

Table 1:

DATCOM Addressable configurations


5.2.2 Basic configuration data

The capabilities discussed below apply to basic configurations, i.e., traditional body-wing-tail

concepts.

5.2.2.1 Static Stability Characteristics

The longitudinal and lateral-directional stability characteristics provided by the Datcom and the

Digital Datcom are in the stability-axis system. Body-axis normal force and axial-force coefficients

are also included in the output for convenience of the user. For those speed regimes and

configurations where Datcom methods are available, the Digital Datcom output provides the

longitudinal coefficient , , , , and the derivatives

, , , ,

Output for configurations with a wing and horizontal tail also includes downwash and the local

dynamic-pressure ratio in the region of the tail. Subsonic data that include propeller power, jet

power, or ground effects are also available. Power and ground effects are limited to the

longitudinal aerodynamic characteristics.

Users are cautioned that the Datcom does not rigorously treat aerodynamics in the transonic

speed regime, and a fairing between subsonic and supersonic solutions is often the

recommended procedure. Digital Datcom uses linear and nonlinear fairings through specific

points; however, the user may find another fairing more acceptable. The experimental data input

option allows the user to revise the transonic fairings on configuration components, perform

parametric analyses on test configurations, and apply better method results (or data) for

configuration build-up.

Datcom body aerodynamic characteristics can be obtained at all Mach numbers only for bodies of

revolution. Digital Datcom can also provide subsonic longitudinal data for cambered bodies of

arbitrary cross section. The cambered body capability is restricted to subsonic longitudinal-

stability solutions.

Straight-tapered and no straight-tapered wings including effects of sweep, taper, and incidence

can be treated by the program. The effect of linear twist can be treated at subsonic Mach

numbers. Dihedral influences are included in lateral directional stability derivatives and wing wake

location used in the calculation of longitudinal data. Airfoil section characteristics or a required

input, although most of these characteristics may be generated using the Airfoil Section Module.

Users are advised to be mindful of section characteristics which are sensitive to Reynolds

number, particularly in cases where very low Reynolds number estimates are of interest. A typical

example would be pretest estimates for small, laminar flow wind tunnels where Reynolds

numbers on the order of 100,000 are common

Users should be aware that the Datcom and Digital Datcom employ turbulent skin friction

methods in the computation of friction drag values. Estimates for cases involving significant

wetted areas in laminar flow will require adjustment by the user.

Wing-body-tail configurations which may be addressed. These capabilities permit the user to

analyze complete configurations, including canard and conventional aircraft arrangements.

Component aerodynamic contributions and configuration build-up data are available through the

use of the “BUILD” option. Using this option, the user can isolate component aerodynamic

contributions in a similar fashion to break down data from a wind tunnel where.


Twin vertical panels can be placed either on the wing or horizontal tail. Analysis can be performed

with both twin vertical tail panels and a conventional vertical tail specified though interference

effects between the three panels is not computed. The influence of twin vertical tails is included

only in the lateral directional stability characteristics at subsonic speeds.

5.2.2.2 Dynamic Stability Characteristics

The pitch, acceleration, rolls and yaw derivatives of

, , , , , , ,

are computed for each component and the build-up configurations. The experimental data option

of the program (Section 4.5) permits the user to substitute experimental data for key parameters

involved in dynamic derivative solutions, such as body

and wing-body

. Any improvement in

the accuracy of these key parameters will produce significant improvement in the dynamic

stability estimates. Use of experimental data substitution for this purpose is strongly

recommended.

5.2.2.3 High-Lift and Control Characteristics

High-lift devices that can be analyzed by the Datcom methods include jet flaps, split, plain, single-

slotted, double-slotted, fowler, and leading edge flaps and slats. Control devices, such as trailing-

edge flap-type controls and spoilers, can also be treated. In general terms, the program provides

the incremental effects of high lift or control device deflections at zero angle of attack.

The majority of the high-lift-device methods deal with subsonic lift, drag, and pitching-moment

effects with flap deflection. General capabilities for jet flaps, symmetrically deflected high-lift

devices, or trailing-edge control devices include lift, moment, and maximum-lift increments along

with drag-polar increments and hinge-moment derivatives. For translating devices the lift-curve

slope is also computed. Asymmetrical deflection of wing control devices can be analyzed for

rolling and yawing effectiveness. Rolling effectiveness may be obtained for all movable

differentially-deflected horizontal stabilizers. The speed regimes where these capabilities exist are

shown in Table 3.

Control modes employing all-moving wing or tail surfaces can also be addressed with the

program. This is accomplished by executing multiple cases with a variety of panel incidence

angles.

5.2.2.4 Trim Option

Trim data can be calculated at subsonic speeds. Digital Datcom manipulates computed stability

and control characteristics to provide trim output (static Cm=0.0). The trim option is available in

two modes. One mode treats configurations with a trim control device on the wing or horizontal

tail. Output is presented as a function of angle of attack and consists of control deflection angles

required to trim and the associated longitudinal aerodynamic characteristics shown in Table 3.

The second mode treats conventional wing-body-tail configurations where the horizontal-tail is all-

movable or “flying.” In this case, output as a function of angle of attack consists of horizontal-

stabilizer deflection (or incidence) angle required to trim; untrimmed stabilizer , , and

hinge-moment coefficients; trimmed stabilizer , and hinge moment coefficients; and total

wing-body-tail and . Body-canard-tail configurations may be trimmed by calculating the

stability characteristics at a variety of canard incidence angles and manually calculating the trim

data.


5.2.3 Special configuration data

5.2.3.1 Low-Aspect-Ratio Wings and Wing-Body Combinations

Datcom provides methods which apply to 1ifting reentry vehicles at subsonic speeds. Digital

Datcom output provides longitudinal coefficients , , , and and the derivatives

, , , ,

5.2.3.2 Aerodynamic Control at Hypersonic Speeds

The USAF Stability and Control Datcom contain some special control methods for high-speed

vehicles. These include hypersonic flap methods which are incorporated into Digital Datcom. The

flap methods are restricted to Mach numbers greater than 5, angles of attack between zero and

20 degrees and deflections into the wind. A two-dimensional flow field is determined and oblique

shock relations are used to describe the flow field.

Table 2:

High Lift/Control Device Output


Data output from the hypersonic control-flap methods are incremental normal- and axial-force

coefficients, associated hinge moments, and center-of-pressure location. These data are found

from the local pressure distributions on the flap and in regions forward of the flap. The analysis

includes the effects of flow separation due to windward flap deflection by providing estimates for

separation induced pressures forward of the flap and reattachment on the flap, Users may specify

laminar or turbulent boundary layers.

5.2.3.3 Transverse-jet Control Effectiveness

Datcom provides a procedure for preliminary sizing of a two-dimensional transverse-jet control

system in hypersonic flow, assuming that the nozzle is located at the aft end of the surface. The

method evaluates the interaction of the transverse jet with the local flow field. A favorable

interaction will produce amplification forces that increase control effectiveness.

The Datcom method is restricted to control jets located on windward surfaces in a Mach number

range of 2 to 20. In addition, the method is invalid for altitudes where mean free paths approach

the jet-width dimension.

The transverse control jet method requires a user-specified time history of local flow parameters

Figure 1:

Special Configuration


and control force required to trim or maneuver. With these data, the minimum jet plenum pressure

is then employed to calculate the nozzle throat diameter and the jet plenum pressure and

propellant weight requirements to trim or maneuver the vehicle.

5.2.4 Operational considerations

There are several operational considerations the user needs to understand in order to take

maximum advantage of Digital Datcom.

5.2.4.1 Flight Condition Control

Digital Datcom requires Mach number and Reynolds number to define the flight conditions. This

requirement can be satisfied by defining combinations of Mach number, velocity, Reynolds

number, altitude, and pressure and temperature. The input options for speed reference and

atmospheric conditions that satisfy the requirement are given in Figure 3, the speed reference is

input as either Mach number or velocity, and the atmospheric conditions as either altitude or free

stream pressure and temperature. The specific reference and atmospheric conditions are then

used to calculate Reynolds number.

The program may loop on speed reference and atmospheric conditions three different ways, a

given by the variable LOOP in Figure 3. In this discussion, and in Figure 3, the speed reference is

referred to as Mach number and atmospheric conditions as altitude. The three options for

program looping on Mach number and altitude are listed and discussed below.

LOOP = 1 - Vary Mach and altitude together. The program executes at the first Mach number

and first altitude, the second Mach number and second altitude, and continues for all the flight

conditions. In the input data, NMACH must equal NALT and NMACH flight conditions are

executed. This option should be selected when the Reynolds number is input, and must be

selected when atmospheric conditions are not input.

LOOP = 2 - Vary Mach number at fixed altitude. The program executes using the first altitude

and cycles through each Mach number in the input list, the second altitude and cycles through

each Mach number, and continues until each altitude has been selected. Atmospheric

conditions oust be input for this option and NMACH times NALT flight conditions are

executed.

LOOP = 3 - Vary altitude at fixed Mach number. The program executes using the first Mach

number and cycles through each altitude in the input list, the second Mach number and cycles

through each altitude and continues until each Mach number has been selected. Atmospheric

conditions must be input for this option and NMACH times NALT flight conditions are

executed.

5.2.4.2 Mach Regimes

Aerodynamic stability methods are defined in Datcom as a function of vehicle configuration and

Mach regime. Digital Datcom logic determines the configuration being analyzed by identifying the

particular input name lists that are present within a case. The Mach regime is normally

determined according to the following criteria:

Mach number (M) Mach Regime

M < 0.6 Subsonic

0.6 < M < 1.4 Transonic

M > 1.4 Supersonic

M > 1.4 Hypersonic

and the hypersonic

flag is set


These limits were selected to conform to most Datcom methods. However, some methods are

valid for a larger Mach number range. Some subsonic methods are valid up to a Mach number of

0.7 or 0.8. The user has the option to increase the subsonic Mach number limit using the variable

STMACH. The program will permit this variable to be in the range: 0.6 < STMACH < 0.99. In the

same fashion, the supersonic Mach limit can be reduced using the variable TSMACH. The

program will permit this value be in the range: 1.01 < TSMACH < 1.40. The program will default to

the limits of each variable if the range is exceeded. The Mach regimes are then defined as

follows:

Mach Number (M) Mach Regime

M < STMACH Subsonic

STMACH < M < TSMACH Transonic

M > TSMACH Supersonic

M > TSMACH Hypersonic

and the hypersonic flag is set

5.2.4.3 Input Diagnostics

There to an input diagnostic analysis module in Digital Datcom this scans all of the input data

cards prior to program execution. A listing of all input data is given and any errors are flagged. It

checks all name list cards for correct name list name and variable name spelling, checks the

numerical inputs for syntax errors, and checks for legal control cards. The name list and control

cards are described in Section 3.

This module does not “fix up” input errors. It will, however, insert a name list termination if it is not

found. Digital Datcom will attempt to execute all cases as input by the user even if errors are

detected.

5.2.4.4 Airfoil Section Module

The airfoil section module can be used to calculate the required geometric and. aerodynamic

input parameters for virtually any user defined airfoil section. This module substantially simplifies

the user's input preparation.

An airfoil section is defined by one of the following methods:

1. An airfoil section designation (for NACA, double wedge, circular arc, or hexagonal airfoils)

2. Section upper and lower Cartesian coordinates, or

3. Section mean line and thickness distribution.

The airfoil section module uses Weber's method (References 2 to 4) to calculate the inviscid

aerodynamic characteristics. A viscous correction is applied to the section lift curve slope, cg . In

addition a 5% correlation factor (suggested in Datcom, page 4.1.1.2-2) is applied to bring the

results in line with experimental data.

The airfoil section is assumed to be parallel to the free stream. Skewed airfoils can be handled by

supplying the section coordinates parallel to the free stream. The module will calculate the

characteristics of any input airfoil, so the user must determine whether the results are applicable

to his particular situation. Five general characteristics of the module should be noted.

1. For subsonic Mach numbers, the module computes the airfoil subsonic section characteristics

and the results can be considered accurate for Mach numbers less than the crest critical

Mach number. Near crest critical Mach number, flow mixing due to the upper surface shock

will make the boundary layer correction invalid. Compressibility corrections also become


invalid. The module also computes the required geometric variables at all speeds, and for

transonic and supersonic speeds these are the only required inputs. Mach equals zero data

are always supplied.

2. Because of the nature of the solution, predictions for an airfoil whose maximum camber is

greater than 6% of the chord will lose accuracy. Accuracy will also diminish when the

maximum airfoil thickness exceeds approximately 12% of the chord, or large viscous

interactions are present such as with supercritical airfoils.

3. When section Cartesian coordinates or mean line and thickness distribution coordinates are

specified, the user must adequately define the leading edge region to prevent surface curve

fits that have infinite slope. This can be accomplished by supplying section ordinates at non-

dimensional chord stations (x/c of 0.0, 0.001, 0.002, and 0.003.

4. If the leading edge radius is not specified in the airfoil section input, the user must insure that

the first and second coordinate points lie on the leading edge radius. For sharp nosed airfoils

the user must specify a zero leading edge radius.

5. The computational algorithm can be sensitive to the “smoothness” of the input coordinates.

Therefore, the user should insure that the input data contains no unintentional fluctuations.

Considering that Datcom procedures are preliminary design methods, it is at least as

important to provide smoothly varying coordinates. as it is to accurately define the airfoil

geometry.

5.2.4.5 Operational Limitations

Several operational limitations exist in Digital Datcom. These limitations are listed below without

extensive discussion or justification. Some pertinent operational techniques are also listed.

The forward lifting surface is always input as the wing and the aft lifting surface as the

horizontal tail. This convention is used regardless of the nature o! the configuration.

Twin vertical tail methods are only applicable to lateral stability parameters at subsonic

speeds.

Airfoil section characteristics are assumed to be constant across the airfoil span, or an

average for the panel. Inboard and outboard panels of cranked or double-delta planforms can

have their individual panel leading edge radii and maximum thickness ratios specified

separately.

If airfoil sections are simultaneously specified for the same aerodynamic surface by an NACA

designation and by coordinates, the coordinate information will take precedence.

Jet and propeller power effects are only applied to the longitudinal stability parameters at

subsonic speeds. Jet and propeller power effects cannot be applied simultaneously.

Ground effect methods are only applicable to longitudinal stability parameters at subsonic

speeds.

Only one high lift or control device can be analyzed at a time. The effect of high lift and control

devices on downwash is not calculated. The effects of multiple devices can be calculated by

using the experimental data input option to supply the effects of one device and allowing

Digital Datcom to calculate the incremental effects of the second device.

Jet flaps are considered to be symmetrical high lift and control devices. The methods are only

applicable to the longitudinal stability parameters at subsonic speeds.

The program uses the input namelist names to define the configuration components to be

synthesized. For example, the presence of namelist

5.2.5 Definition of inputs

The Digital Datcom basic input data unit is the “case.” A “case” is a set of input data that defines a

configuration and its flight conditions. The case consists of inputs from up to four data groups.


Group I inputs define the flight conditions and reference dimensions.

Group II inputs specify the basic configuration geometry for conventional configurations,

defining the body, wing and tail surfaces and their relative locations.

Group III inputs specify additional configuration definition, such as engines, flaps, control tabs,

ground effects or twin vertical panels. This input group also defines those “special”

configurations that cannot be described using Group II inputs and include low aspect ratio

wing and wing-body configurations, transverse jet control and hypersonic flaps.

Group IV inputs control the execution of the case, or job for multiple cases, and allow the user

to choose some of the special options, or to obtain extra output.

5.2.6 INPUT TECHNIQUE

Two techniques are generally available for introducing input data into a Fortran computer

program: namelist and fixed format. Digital Datcom employs the namelist input technique for input

Groups I, II and III since it is the most convenient and flexible for this application. Its use reduces

the possibility of input errors and increases the utility of the program as follows:

Variables within a namelist may be input in any order;

Namelist variables are not restricted to particular card columns;

Only required input variables need be included; and

A variable may be included more than once within a namelist, but the last value to appear will

be used.

All namelist input variables (and program data blocks) are initialized “UNUSED” (1.0E-60 on CDC systems) prior to case execution. Therefore, omission of pertinent input variables may result in the “UNUSED” value to be used in calculations. However, the “UNUSED” value is often used as a switch for program control, so the user should not indiscriminately use dummy inputs. All Digital Datcom numeric constants require a decimal point. The Fortran variable names that are implied INTEGERS (name begins with I, J, K, L, M, or N) are declared REAL and must be specified in either “E” or “F” format (X.XXXEYY or X.XXX).

Group IV inputs are the “case control cards.” Though they are input in a fixed format, their use has the characteristic of a namelist. since (with the exception of the case termination card) they can be placed in any order or location in the input data.

Table 4 defines the namelists and control cards that can be input to the program. Since not all namelist inputs are required to define a particular problem or configuration, those namelists required for various analyses are summarized in Tables 5 through 7. Use of these tables will save time in preparing namelist inputs for a specific problem.

The user has the option to specify the system of units to be used, English or Metric. Table 8 summarizes the systems available, and defines the case control card required to invoke each option. For clarity, the namelist variable description charts which follow have a column titled “Units” using the following nomenclature:

l denotes units of length: feet, inches, meters, or centimeters

A denotes units of area: ft2, in2, m2, or cm2

Deg denotes angular measure in degrees, or temperature in degrees Rankine or

degrees Kelvin

F denotes units of force; pounds or Newtons

t denotes units of time; seconds.

Specific input parameters, geometric illustrations, and supporting data are provided throughout

the report. To aid the user in reading these figures, the character „0' defines the number zero and

the character „O‟ the fifteenth letter in the alphabet.


Table

2:

Hig

h L

ift/Co

ntro

l Devic

e

Ou

tput


Ta

ble

3:

Hig

h L

ift/Co

ntro

l Devic

e

Ou

tpu

t


Ta

ble

5:

Hig

h L

ift/Contro

l Devic

e

Ou

tpu

t


5.2.7 GROUP I INPUT DATA

Namelist, FLTCON, defines the case flight conditions. The user may opt to provide Mach number

and Reynolds number per unit length for each case to be computed. In this case, input

preparation requires that the user compute Reynolds number for each Mach number, and altitude

combination he desires to run. However, the program has a standard atmosphere model, which

accurately simulates the 1962 Standard Atmosphere for geometric altitudes from -16,404 feet to

2,296,588 feet, that can be used to eliminate the Reynolds number input requirement and

provides the user the option to employ Mach number or velocity as the flight speed reference. The

user may specify Mach numbers (or velocities) and altitudes for each case and program

computations will employ the atmosphere model to determine pressure, temperature, Reynolds

number and other required parameters to support method applications.

Talbe (Top) 6:

Required namelist fro analysis of special configuraions

Table (bottom) 7:

Input unit options


Also incorporated is the provision for optional inputs of pressure and temperature by the user. The

program will override the standard atmosphere and compute flow condition parameters consistent

with the pressure and temperature inputs. This option will permit Digital Datcom applications such

as wind tunnel model analyses at test section conditions.

If the NACA control card is used. The Reynolds number and Mach number must be defined using

the variables RNNUB and MACH.

Other optional inputs include vehicle weight and flight path angle (“WT” and “GAMMA”). These

parameters are of particular interest when using the Trim Option. The trim flight conditions are

output as an additional line of output with the trim data and the steady flight lift coefficient is output

with the untrimmed data.

Use of the variable LOOP enables the user to run cases at fixed altitude with varying Mach

number (or velocity), at fixed Mach number (or velocity) at varying altitudes, or varying speed and

altitude together.

Non-dimensional aerodynamic coefficients generated by Digital Datcom may be based on user-

specified reference area and lengths. These reference parameters are input via namelist

OPTINS. If the reference area is not specified, it is set equal to the theoretical planform area of

the wing. This wing area includes the fuselage area subtended by the extension of the wing

leading and trailing edges to the body center line. The longitudinal reference length, if not

specified in OPTINS, in set equal to the theoretical wing mean aerodynamic chord. The lateral

reference length is set equal to the wing span when it is not user specified. Reference parameters

contained in OPTINS must be specified for body-alone configurations since the default reference

parameters are based on wing geometry. It is suggested that values near the magnitude of body

maximum cross-sectional area be used for the reference area and body maximum diameter for

the longitudinal and lateral reference lengths.

The output format generally provides at least three significant digits in the solution when user

specified reference parameters are of the same order of magnitude as the default reference

parameters. If the user specifies reference parameters that are orders of magnitude different from

the wing area or aerodynamic chord, some output data can overflow the output format or print

only zeros. This may happen in rare instances and would require readjustment of the reference

parameters.

5.2.8 GROUP II INPUT DATA

The namelist SYNTHS defines the basic configuration synthesis parameters. The user has the

option to apply a scale factor to his geometry which permits full scale configuration dimensions to

be input for an analysis of a wind tunnel model. The program will use the scale factor to scale the

input data to model dimensions. The variable used is “SCALE.”

The body configuration is defined using the namelist BODY. The variable METHOD enables the

user to select either the traditional Datcom methods for body , and at low angles of attack

(default), or Jorgensen‟s method, which is applicable from zero to 180 degrees angle of attack.

Jorgensen‟s method can be used by selecting “METHOD=2” subsonically or supersonically.

Users are encouraged to consult the Datcom for details concerning these methods. Digital

Datcom will accept an arbitrary origin for the body coordinate system, i.e., body station “zero” is or

required to be at the fuselage nose.

The planform geometry of each of the aerodynamic surfaces are input using the namelist

WGPLNF, HTPLNF, VTPLNF and VFPLNF. The section aerodynamic characteristics for these


surfaces are input using either the section characteristics namelists WGSCHR, HTSCHR,

VTSCHR and VFSCHR. Airfoil characteristics are assumed constant for each panel of the

planform.

The USAF Datcom contains three methods for the computation of forward lifting surface

downwash field effects on aft lifting surface aerodynamics. The user is cautioned not to apply the

empirically based subsonic Method 2 outside the bounds. Method 1 is recommended as an

optional approach for the / regime of 1.0 to 1.5. By default, Digital Datcom selects Method 3

for / less than 0.5 and Method 1 for span ratios greater than or equal to 1.5.

Using the variable DWASH In namelist WGSCHR, the user has the option of applying Method 1

or 2. Method 2 is applicable at subsonic Mach numbers and span ratios of 1.25 to 3.6.

Aspect ratio classification is required to employ the Datcom straight tapered wing solutions for

wing or tail lift in the subsonic and transonic Mach regimes. Classification of lifting surface aspect

ratio as either high or low results in the selection of appropriate methods for computation. The

USAF Datcom uses a classification parameter, which depends upon planform taper ratio and

leading edge sweep. It also notes an overlap regime where the user may employ either the low or

high aspect ratio methods. Digital Datcom allows the user to specify the aspect ratio method to be

used in this overlap regime using the parameter ARCL in the section namelists. High aspect ratio

methods are automatically selected for unswept, untapered wings with aspect ratios of 3.5 or

more if ARCL is not input.

Transonically, several parameters need to be defined to obtain the panel lift characteristics.

Those required variables are summarized In Figures 10 and 11 and are input using the

experimental data substitution namelist EXPRnn. Additionally, intermediate data may be

available, for example ( /dβ)/ , which requires experimental data to complete. By use of the

experimental data input namelist EXPRnn, data can be made available to complete these second-

level computations.

The namelist EXPRnn can also be used to substitute selected configuration data with known test

results for some Datcom method output and build a new configuration based on existing data.

This option is most useful for theoretically expanding a wind tunnel test data base for analysis of

non-tested configurations.

5.2.9 GROUP III INPUT DATA

The namelists required for additional or “special” configuration definition. Specifically, the

namelists PROPWR, JETPWR, GRNDEF, TVTPAN, ASYFLP and CONTAB enable the user to

“build upon” the configuration defined through Group II inputs. The remaining namelists LARWB,

TRNJET and HYPEFF define “stand alone” configurations whose namelists are not used with

Group II inputs.

The inputs for propeller power or jet power effects are made through namelists PROPWR and

JETPWE, respectively. The number of engines allowable is one or two and the engines may be

located anywhere on the configuration. The configuration must have a body and a wing defined

and, optionally, a horizontal tail and a vertical tail. Since the Datcom method accounts for

incremental aerodynamic effects due to power, configuration changes required to account for

proper placement of the engine(s) on the configuration (e.g., pylons) are not taken into account.

Twin vertical panels, defined by namelist TVTPAN, can be defined on either the wing or horizontal

tail. Since the method only computes the incremental lateral stability results, “end-plate” effects on

the longitudinal characteristics are not calculated. If the twin vertical panels are present on the


horizontal tail and a vertical tail or ventral fin is specified, the mutual interference among the

panels is not computed.

Inputs for the high lift and control devices are made with the namelists SYMFLP, ASYFLP and

CONTAB. In general, the eight flap types defined using SYMFLP (variable FTYPE) are assumed

to be located on the most aft lifting surface, either horizontal tail or wing if a horizontal tail is not

defined. Jet flaps, also defined using SYMFLP, will always be located on the wing, even with the

presence of a horizontal tail. Control tabs (namelist CONTAB) are assumed to be mounted a plain

trailing edge flap (FTYPE=1); therefore, for a control tab analysis namelists CONTAB and

SYMFLP (with FTYPE=1) must both be input. For ASYFLP namelist inputs, the spoiler and

aileron devices (STYPE of 1. 2. 3. or 4.) are defined for the wing, even with the presence of a

horizontal tail, whereas the all-moveable horizontal tail (STYPE=5.0) is, of course, a horizontal tail

device.

5.2.10 GROUP IV INPUT DATA

All Datcom control cards must start in card Column 1. The control card name cannot contain any

embedded blanks unless the name consists of two words; they are then separated by a single

blank. All but the case termination card (NEXT CASE) may be inserted anywhere within a case

(including the middle of any namelist). Each control card is defined below and examples of their

usage are illustrated in the example problems of Section 7.

5.2.10.1 Case Control

NAMELIST - When this card is encountered, the content of each applicable namelist is dumped

for the case in the input system of units. This option is recommended if there is doubt about the

input values being used, especially when the SAVE option has been used.

SAVE - When this control card is present in a case, input data for the case are preserved for use

in following case. Thus, data encountered in the following case will update the saved data. Values

not input in the new case will remain unchanged. Use of the SAVE card also allows minimum

inputs for multiple case jobs. The total number of appearances of all namelists in consecutive

SAVE cases cannot exceed 300; this includes multiple appearances of the same namelist. An

error message is printed and the case is terminated if the 300 namelist limit is exceeded. Note, if

both SAVE and NEXT CASE cards appear in the last input case, the last case will be executed

twice.

The NACA, DERIV and DIM control cards are the only control cards affected by the SAVE card;

i.e., no other control cards can be saved from case to case.

DIM FT, DIM IN, DIM M, DIM CM - When any of these cards are encountered, the input and

output data are specified in the stated system of units. DIM FT is the default.

NEXT CASE - When this card is encountered, the program terminates the reading of input data

and begins execution of the case. Case data are destroyed following execution of a case unless a

SAVE card is present. The presence of this card behind last input case is optional.


5.2.10.2 Execution Control

TRIM - If this card is included in the case input, trim calculations will be performed for each

subsonic Mach number within the case. A vehicle may be trimmed by deflecting a control device

on the wing or horizontal tail or by deflecting an all-movable horizontal stabilizer.

DAMP - The presence of this card in a case will provide dynamic derivative results (for

addressable configurations) In addition to the standard static-derivative output.

NACA - This card provides in NACA airfoil section. designation (or supersonic airfoil definition) for

use in the airfoil section module. It is used in conjunction with, or in place of, the airfoil section

characteristics namelists. The airfoil section module calculates the airfoil section characteristics

designated and is executed if either a NACA control card is present or the variable TYPEIN is

defined in the appropriate section characteristic namelist (WGSCHR, HTSCHR, VTSCHR or

VFSCHR). Note that if airfoil coordinates and the NACA card are specified for the same

aerodynamic surface, the airfoil coordinate specification will be used. Therefore, if coordinates

have been specified in a previous case and the SAVE option is in effect, “TYPEIN” must be set

equal to “UNUSED” for the presence of an NACA card to be recognized for that aerodynamic

surface. The airfoil designated with card will be used for both panels of cranked or double-delta

planforms.

The form of this control card and the required parameters are given below.

Card Column(s) input(s) Purpose

1 thru 4 NACA The unique letters NACA

designate that at airfoil

is to be defined

5 Any delimiter

Card Column(s) input(s) Purpose

6 W, H, V, or F Planforms for which the

airfoil designation applies

Wing(W), Horizontal tail (H),

Vertical Tail (V), or ventral

Fin (F)

7 Any delimiter

8 1, 4, 5, 6, S Type of airfoil section;

1-series (1), 4-digit (4),

5-digit (5), 6-series (6).

or supersonic (S)

9 Any delimeter

10 thru 80 Designation Input designation; columns

are free-field (blanks are

ignored)

Only fifteen (15) characters are accepted in the airfoil designation. The vocabulary consists of the

numbers zero (0) through nine (9), the letter “A”, and the special characters comma, period,

hyphen and equal sign. Any characters input that are not in the vocabulary list will be interpreted

as the number zero (0).


5.2.10.3 Output Control

CASEID - This card provides a case identification that. Is printed as part of the output headings.

This identification can be any user defined case title, and must appear in card columns 7 through

80.

DUMP NAME1, NAME2, ... - This card is used to print the contents of the named arrays in the

foot-pound-second system of units. For example, if the control card read was “DUMP FLC, A” the

flight conditions array FLC and the wing array A would be printed prior to the conventional output.

If more names are desired than can fit in the available space on one card, additional dump cards

may be included.

DUMP CASE - This card is similar to the “DUMP NAME1, ...” control card. When this card is

present in a case, all the arrays (defined in Appendix C) that are used during case execution are

printed prior to the conventional output. The values in the arrays are in the foot-pound-second

system of units.

DUMP INPUT - This card is similar to the “DUMP CASE” card except that it forces a dump of all

input data blocks used for the case.

DUMP IOM - This card is similar to the “DUMP CASE” card except that all the output arrays for

the case are dumped.

DUMP ALL - This card is similar to the “DUMP CASE” card. Its use dumps all program arrays,

even if not used for the case.

DERIV RAD - This card causes the static and dynamic stability der±vatives to be output in radian

measure. The output will be in degree measure unless this flag is set. The flag remains set until a

DERIV DEG control card is encountered, even if

“NEXT CASE” cards are subsequently encountered.

DERIV DEG - This card causes the static and dynamic stability derivatives to be output in degree

measure. The remaining characteristics of this control card are the same as the DERIV RAD card.

DERIV DEG is the default.

PART - This card provides auxiliary and partial outputs at each Mach number in the case. These

outputs are automatically provided for all cases at transonic Mach numbers.

BUILD - This control card provides configuration build-up data. Conventional static and dynamic

stability data are output for all of the applicable basic configuration combinations.

PLOT - This control card causes data generated by the program to be written to logical unit 13,

which can be retained for input to the Plot Module.

5.2.11 Definition of output

Digital Datcom results are output at the Mach numbers specified in namelist FLTCON. At each

Mach number, output consists of a general heading, reference parameters, input error messages,

array dumps, and specific aerodynamic characteristics as a function of angle of attack and/or flap

deflection angle. Separate output formats are provided for the following sets of related

aerodynamic data: static longitudinal and lateral stability, dynamic derivatives, high lift and control,

trim option, transverse-jet effectiveness, and control effectiveness at hypersonic speeds. Since


computer output is limited symbolically, definitions form the output symbols used within the

related output sets is given. The Datcom engineering symbol follows the output symbol notation

when appropriate, unless otherwise noted, all results are presented in the stability axis coordinate

system.

5.2.12 Static and dynamic stability output

The primary outputs of Digital Datcom are the static and dynamic stability data for a configuration.

Definitions of the output notations are given below.

5.2.12.1 General headings

Case identification information is contained in the output heading and consists of the following:

the version of Datcom from which the program methodologies are derived, the type of vehicle

configuration (e.g. body alone or wing-body) for which aerodynamic characteristics are output,

and supplemental user-specified case identification information if the CASEID control card is

used.

5.2.12.2 Reference Parameters

Reference parameters and flight-condition output are defined as follows:

• MACH NUMBER - Mach at which output was calculated. This parameter is user-specified In

namelist FLTCON, or calculated from the altitude and velocity inputs.

• ALTITUDE - Altitude (if user input) at which Reynolds number was calculated. This optional

parameter is user specified in namelist FLTCON.

• VELOCITY - Freestream velocity (if user input) at which Mach number and Reynolds number

was calculated. This optional parameter is user specified in namelist FLTCON.

• PRESSURE - Freestream atmospheric pressure at which output was calculated (function of

altitude). This parameter can also be user specified in namelist FLTCON.

• TEMPERATURE - Freestream atmospheric temperature at which output was calculated

(function of altitude). This parameter can also be user specified in namelist FLTCON.

• REYNOLDS NO. - This flight condition parameter is the Reynolds number per unit length and is

user-specified (or input) in namelist FLTCON.

• REFERENCE AREA - Digital Datcom aerodynamic characteristics are based on this reference

area. It is either user-specified in namelist OPTINS or is equal to the planform area of the

theoretical wing.

• REFERENCE LENGTH - LONGITUDINAL - The Digital Datcom pitching moment coefficient is

based on this reference length. It is either user-specified in namelist OPTINS or is equal to the

mean aerodynamic chord of the theoretical wing.

• REFERENCE LENGTH - LATERAL - The Digital Datcom yawing moment and rolling-moment

derivatives are based on this reference length. It is either user-specified in namelist OPTINS or is

set equal to the wing span.


• MOMENT REFERENCE CENTER - The moment reference center location for vehicle moments

(and rotations). It is user-specified in namelist SYNTHS and output as XCG(HORIZ) and

ZCG(VERT).

• ALPHA - This is the angle-of-attack array that is user specified in namelist FLTCON. The angles

are expressed in degrees.

5.2.13 Static Longitudinal and Lateral Stability

Aerodynamic characteristics that are available as output from Digital Datcom are presented as a

function of vehicle configuration and speed regime. The stability derivatives are expressed per

degree or per radian at the user‟s option.

• CD - Vehicle drag coefficient based on the reference area and presented a function of angle of

attack. If Datcom methods are available to calculate zero-lift drag but not to calculate CD versus

alpha, the value of CD is printed as output at the first alpha. CD is positive when the drag is an aft

acting load.

• CL - Vehicle lift coefficient based on the reference area and presented as a function of angle of

attack. CL is positive when the lift is an up acting load.

• CM - Vehicle pitching-moment coefficient based on the reference area and longitudinal

reference length and presented as a function of angle of attack. Positive pitching moment causes

a nose-up vehicle rotation.

• CN - Vehicle (body axis) normal-force coefficient based on the reference area and presented as

a function of angle of attack. CN is positive when the normal force is in the +Z direction.

• CA - Vehicle (body axis) axial-force coefficient based on the reference area and presented as a

function of angle of attack. CA Is positive when the axial force is in the +X direction.

• XCP - The distance between the vehicle moment reference center and the center of pressure

divided by the longitudinal reference length. Positive is a location forward of the center of gravity.

If output is given only for the first angle of attack, or for those cases where pitching moment (CM)

is not computed, the value(s) define the aerodynamic-center location; i.e., XCP=

dCm/dCL - (XCG-Xac) /c

• CLA - Derivative of lift coefficient with respect to alpha. If CLA is output versus angle of attack,

these values correspond to numerical derivatives of the lift curve. When a single value of CLA is

output at the first angle of attack, this output is the linear-lift-region derivative. CLA is based on

the reference area.

• CMA - Derivative of the pitching-moment coefficient with respect to alpha. If CMA is output

versus angle of attack, the values correspond to numerical derivatives of the pitching-moment

curve. When a single value of CMA is output at the first angle of attack, this output is the linear-

lift-region derivative. CMA is based on the reference area and longitudinal reference length.

• CYB - Derivative of side-force coefficient with respect to sideslip angle. When CYB in defined

independent of the angle of attack, output is printed at the first angle of attack. CYB is based on

the reference area.


• CNB - Derivative of yawing-moment coefficient with respect to sideslip angle. When CNB is

defined independent of angle of attack, output is printed at the first angle of attack. CNB is based

on the reference area and lateral reference length.

• CLB - Derivative of rolling-moment coefficient with respect to sideslip angle presented as a

function of angle of attack. CLB is based on the reference area and lateral reference length.

• Q/QINF - Ratio of dynamic pressure at the horizontal tail to the freestream value presented a

function of angle of attack. When a single value of Q/QINF is output at the first angle of attack,

this output is the linear-lift region value.

• EPSILON - Downwash angle at horizontal tail expressed in degrees. Downwash angle has the

same algebraic sign as the lift coefficient. Positive downwash implies that the local angle of attack

of the horizontal tail is less than the free-stream angle of attack.

• D (EPSLON)/D (ALPHA) - Derivative of downwash angle with respect to angle of attack. When a

single value of D (EPSLON)/ D (ALPHA) is output at the first angle of attack, it corresponds to the

linear-lift-region derivative.

5.2.14 Dynamic Derivatives

Aerodynamic characteristics that are available as outputs from Digital Datcom are presented as a

function of vehicle configuration and speed regime. Dynamic stability derivatives are expressed

per degree or per radian at the users‟ option.

• CLQ - Vehicle pitching derivative based on the product of reference area and longitudinal

reference length.

• CMQ - Vehicle pitching derivative based on the product of reference area and the square of the

longitudinal reference length.

• CLAD - Vehicle acceleration derivative based on the product of reference area and longitudinal

reference length.

• CMAD - Vehicle acceleration derivative based on the product of reference area and the square

of the longitudinal reference length.

• CLP - Vehicle rolling derivative based on the product of reference area and the square of the

lateral reference length.

• CYP - Vehicle rolling derivative based on the product of reference area and lateral reference

length.

• CNP - Vehicle rolling derivative based on the product of reference area and the square of the


• CNR - Vehicle yawing derivative based on the product of reference area and the square of the


• CLR - Vehicle rolling derivative based on the product of reference area and the square of the



5.2.15 High Lift and Control

This output consists of two basic categories: symmetrical deflection of high lift and/or

control devices, and asymmetrical control surfaces. The high lift/control data follow the same sign

convention and the static aerodynamic coefficients. Users are urged to consult the Datcom for

limitations and constraints imposed upon these characteristics. Outputs obtained from

symmetrical flap analysis are as follows.

• DELTA - Control-surface streamwise deflection angle. Positive trailing edge down, Values of this

array are user-specified in namelist SYMFLP.

• D(CL) - Incremental lift coefficient in the linear-lift angle-of-attack range due to deflection of

control surface. Based on reference area and presented as a function of deflection angle.

• D(CM) - Incremental pitching-moment coefficient due to control surface deflection valid in the

linear lift angle-of-attack range. Based on the product of reference area and longitudinal reference

length. Output is a function of deflection angle.

• D(CL MAX) - Incremental maximum-lift coefficient. Based on reference area and presented as a

function of deflection angle.

• D(CD MIN) - Incremental minimum drag coefficient due to control or flap deflection. Based on

reference area and presented as a function of deflection angle.

• D(CDI) - Incremental induced-drag coefficient due to flap deflection based on reference area

and presented as a function of angle-of-attack and deflection angle.

• (CLA)D - Lift-curve slope of the deflected, translated surface based on reference area and

presented as a function of deflection angle.

• (CH)A - Control-surface hinge-moment derivative due to angle of attack based on the product of

the control surface area and the control surface chord, . A positive hinge moment will tend to

rotate the flap trailing edge down.

• (CH)D - Control-surface hinge-moment derivative due to control deflection based on the product

of the control surface area and the control surface chord. A positive hinge moment will tend to

rotate the flap trailing edge down.

Output obtained from asymmetrical control surfaces are given below. Left and right are related to

a forward facing observer:

• DELTAL - Left lifting surface streamwise control deflection angle. Positive trailing edge down.

Values in this array are user-specified in namelist ASYFLP.

• DELTAR - Right lifting-surface streamwise control deflection angle. Positive trailing edge down.

Values in this array are user-specified in namelist ASYFLP.3

• XS/C - Streamwise distance from wing leading edge to spoiler lip. Values in this array are input

via namelist ASYFLP

• HS/C - Projected height of spoiler measured from and normal to airfoil mean line. Values in this

array are input via namelist ASYFLP.


• DD/C - Projected height of deflector for spoiler-slot-deflector control. Values in this array are

input via namelist ASYFLP.

• DS/C - Projected height of spoiler control. Values in this array are input via namelist ASYFLP.

• (CL) ROLL - Incremental rolling moment coefficient due to asymmetrical deflection of control

surface based on the product of reference area and lateral reference length. Positive rolling

moment is right wing down.

• CN - Incremental yawing-moment coefficient due to asymmetrical deflection of control surface

based on the product of reference area and lateral reference length. Positive yawing moment is

nose right.

5.2.16 Trim Option

The Digital Datcom trim option provides subsonic longitudinal characteristics at the calculated trim

deflection angle of the control device. The trim calculations assume unaccelerated flight; i.e., the

static pitching moment is set to zero without accounting for any contribution from a non-zero pitch

rate. Trim output is also provided for an all-movable horizontal stabilizer at subsonic speeds.

These data include untrimmed stabilizer coefficients CD, CL, Cm, and the hinge moment

coefficients, stabilizer trim incidence and trimmed stabilizer coefficients CD, Cm, and the hinge-

moment coefficient; wing-body-tail CD and CL with stabilizer at trim deflection angle. Additional

Digital Datcom symbols used in output are as follows:

• HM - Stabilizer hinge-moment coefficient based on the product of reference area and

longitudinal reference length. Positive hinge moment will tend to rotate the stabilizer leading edge

up and trailing edge down.

• ALIHT - Stabilizer incidence required to trim expressed in degrees. Positive incidence, or

deflection, is trailing edge down. The all-movable horizontal stabilizer trim output is presented as

a function of angle of attack.


5.2.17 Test model

5.2.17.1 SenecaII

Assumption: Some of the value will be assume close to real value from the lack of the information

and may need the real sizing of the real aircraft for each section.

5.2.17.2 Input code NACA W 5 65415

NACA V 4 0009

NACA H 4 0009

NACA F 4 0009

$FLTCON NMACH=1.0,

MACH(1)=0.2418852,

NALPHA=20.0,

ALSCHD(1)= -8.0, -6.0, -4.0, -2.0, 0.0,

2.0, 3.0, 4.0, 5.0, 6.0,

7.0, 8.0, 9.0, 10.0, 11.0,

12.0, 14.0, 16.0, 18.0, 20.0,

NALT=3.0,

ALT(1)=0.0, 10000.0, 20000.0,

STMACH=0.6,

TSMACH=1.4,

TR=1.0,

WT=4500.0,

LOOP=1.0$

$OPTINS ROUGFC=0.30E-3,

SREF=208.7, CBARR=5.18, BLREF=38.906$

$SYNTHS XCG=9.46, ZCG=0.0,

XW=6.73, ZW=2.49, ALIW=3.7,

XH=24.9, ZH=4.17, ALIH=0.0, HINAX=25.9,

VERTUP=.TRUE., SCALE=1.0,

XV=20.0, ZV=0.0,

XVF=25.1,ZVF=4.0$

XV=20.0, ZV=4.0,

XVF=19.5,ZVF=5.0$

$BODY NX=6.0,

Figure 2:

Seneca II


X(1) =0.0, 1.54, 6.56, 9.25, 15.7, 26.6,

R(1) =0.0, 0.98, 2.03, 2.03, 2.03, 0.0,

ZU(1)=3.61, 4.49, 5.31, 6.43, 5.64, 4.63,

ZL(1)=3.61, 2.82, 2.46, 2.23, 2.07, 3.58,

ITYPE=1.0, METHOD=1.0$

$WGPLNF CHRDTP=5.41, SSPNOP=14.8, SSPNE=17.5, SSPN=19.4,

CHRDBP=5.42, CHRDR=7.36, SAVSI=25.0, CHSTAT=0.0,

TWISTA=-3.0, DHDADI=7.0, DHDADO=7.0, TYPE=1.0$

$VTPLNF CHRDTP=2.62, SSPNE=4.92, SSPN=6.23, CHRDR=6.56,

SAVSI=39.8, CHSTAT=0.0, TYPE=1.0$

$VFPLNF CHRDTP=0.0, SSPNE=0.75, SSPN=2.39, CHRDR=5.31,

SAVSI=66.5, CHSTAT=0.0, TYPE=1.0$

$HTPLNF CHRDTP=2.89, SSPNE=6.16, SSPN=6.76, CHRDR=2.89,

SAVSI=0.0, CHSTAT=0.0, TWISTA=0.0, DHDADI=0.0,

TYPE=1.0$

$PROPWR AIETLP=0.0,NENGSP=2.0,THSTCP=0.0,

PHALOC=4.5,PHVLOC=4.0,PRPRAD=3.75,

ENGFCT=0.8,NOPBPE=3.0,

YP=6.0,CROT=.FALSE.$

5.2.17.3 Geometry output from program

Figure 3:

Geometry output from DATCOM

5.2.17.4 Aerodynamics output



<aerodynamics>

<alphalimits unit="DEG">

<min>-5.0</min>

<max>14.0</max>

</alphalimits>

<hysteresis_limits unit="DEG">

<min> 5.0</min>

<max>20.0</max>

</hysteresis_limits>



<!-- **************************************

ASSUMPTIONS AND LIMITATIONS

There is no interaction between deflected surfaces modeled

so there is no change in elevator effects with the flaps

deflected, for example.

Terms known to be missing from DATCOM:

Power effects

Ground effects

Cyr, CyDr, Cyda, ClDr, Cndr

**************************************

-->



<function name="aero/function/ground-effect-factor-lift">

<description>Change in lift due to ground effect

factor</description>

<product>

<table>

<independentVar lookup="row">aero/h_b-mac-

ft</independentVar>

<tableData>

0.0 1.203

0.1 1.127

0.15 1.090

0.2 1.073

0.3 1.046

0.4 1.055

0.5 1.019

0.6 1.013

0.7 1.008

0.8 1.006

0.9 1.003

1.0 1.002

1.1 1.0

</tableData>

</table>

</product>

</function>

<function name="aero/function/ground-effect-factor-drag">

<description>Change in drag due to ground effect</description>

<product>

<table>

<independentVar lookup="row">aero/h_b-mac-

ft</independentVar>

<tableData>

0.0 0.480

0.1 0.515

0.15 0.629

0.2 0.709

0.3 0.815

0.4 0.882

0.5 0.928

0.6 0.962

0.7 0.988

0.8 1.0

0.9 1.0

1.0 1.0

1.1 1.0

</tableData>

</table>

</product>

</function>

<!--

********************************************************************** -

->

<axis name="LIFT">

<function name="aero/coefficient/CLwbh">

<description>

Lift due to alpha

Increase in CL decreases Period and damping,Dutch Roll

damping

CL is low for landing

</description>

<product>

<property>aero/function/ground-effect-factor-

lift</property>

<property>aero/qbar-psf</property>

<property>metrics/Sw-sqft</property>

<table>

<independentVar lookup="row">aero/alpha-

deg</independentVar>

<tableData>

-8.000 -.3288

-6.000 -.1409

-4.000 .4592E-01

-2.000 .2387

.000 .4373

2.000 .6412

3.000 .7442

4.000 .8487

5.000 .9543

6.000 1.061

7.000 1.163

8.000 1.254

9.000 1.336

10.00 1.412

11.00 1.480

12.00 1.540

14.00 1.631

16.00 1.643


18.00 1.322

20.00 .9168

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/CLq">

<description>

Basic Lift Coefficient due to pitch rate(per degree)

</description>

<product>

<property>velocities/q-aero-rad_sec</property>

<value>57.29577951</value>



<property>aero/ci2vel</property>

<table>



<tableData>

-8.000 .1000E-29

-6.000 .1000E-29

-4.000 .1000E-29

-2.000 .1000E-29

.000 .1000E-29

2.000 .1000E-29

3.000 .1000E-29

4.000 .1000E-29

5.000 .1000E-29

6.000 .1000E-29

7.000 .1000E-29

8.000 .1000E-29

9.000 .1000E-29

10.00 .1000E-29

11.00 .1000E-29

12.00 .1000E-29

14.00 .1000E-29

16.00 .1000E-29

18.00 .1000E-29

20.00 .1000E-29

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/CLad">

<description>

Basic Lift Coefficient due to AOA rate(per degree)

Important contributor to Short-Period damping

For low Cla, aircraft must land at high alpha

</description>

<product>

<property>aero/alphadot-deg_sec</property>




<table>



<tableData>

-8.000 .1000E-29

-6.000 .1000E-29

-4.000 .1000E-29

-2.000 .1000E-29

.000 .1000E-29

2.000 .1000E-29

3.000 .1000E-29

4.000 .1000E-29

5.000 .1000E-29

6.000 .1000E-29

7.000 .1000E-29

8.000 .1000E-29

9.000 .1000E-29

10.00 .1000E-29

11.00 .1000E-29

12.00 .1000E-29

14.00 .1000E-29

16.00 .1000E-29

18.00 .1000E-29

20.00 .1000E-29

</tableData>

</table>

</product>

</function>

</axis>

<!--

********************************************************************** -

->

<axis name="DRAG">

<function name="aero/coefficient/CD">

<description>

Basic Drag Coefficient

Sense: Always positive

Main contributor to Phugoid damping: Greater Cd, Better

damping

</description>

<product>

<property>aero/function/ground-effect-factor-

lift</property>



<table>

<tableData>

-8.000 .2278E-01

-6.000 .1766E-01

-4.000 .1613E-01

-2.000 .1805E-01

.000 .2404E-01

2.000 .3401E-01

3.000 .4062E-01

4.000 .4834E-01

5.000 .5717E-01

6.000 .6715E-01

7.000 .7737E-01

8.000 .8715E-01

9.000 .9703E-01

10.00 .1068

11.00 .1163

12.00 .1255

14.00 .1420

16.00 .1483

18.00 .1165

20.00 .1043

</tableData>

</table>

</product>

</function>

</axis>

<!--

********************************************************************** -

->

<axis name="SIDE">

<function name="aero/coefficient/Cyb">

<description>

Side Force coefficient due to Sideslip(per degree)

Contributes to damping of Dutch Roll mode

</description>

<product>



<property>aero/beta-deg</property>

<table>



<tableData>

-8.000 -.8926E-02

-6.000 -.8926E-02

-4.000 -.8926E-02

-2.000 -.8926E-02

.000 -.8926E-02

2.000 -.8926E-02


3.000 -.8926E-02

4.000 -.8926E-02

5.000 -.8926E-02

6.000 -.8926E-02

7.000 -.8926E-02

8.000 -.8926E-02

9.000 -.8926E-02

10.00 -.8926E-02

11.00 -.8926E-02

12.00 -.8926E-02

14.00 -.8926E-02

16.00 -.8926E-02

18.00 -.8926E-02

20.00 -.8926E-02

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/Cyp">

<description>

Side Force Coefficient due to Roll Rate(per degree)

</description>

<product>

<property>velocities/p-aero-rad_sec</property>

<value>57.29577951</value>



<property>aero/bi2vel</property>

<table>



<tableData>

-8.000 .1000E-29

-6.000 .1000E-29

-4.000 .1000E-29

-2.000 .1000E-29

.000 .1000E-29

2.000 .1000E-29

3.000 .1000E-29

4.000 .1000E-29

5.000 .1000E-29

6.000 .1000E-29

7.000 .1000E-29

8.000 .1000E-29

9.000 .1000E-29

10.00 .1000E-29

11.00 .1000E-29

12.00 .1000E-29

14.00 .1000E-29

16.00 .1000E-29

18.00 .1000E-29

20.00 .1000E-29

</tableData>

</table>

</product>

</function>



<function name="aero/coefficient/Cyr">

<description>

Side Force due to Yaw Rate(DATCOM does not calculate)

Effect is small

</description>

<product>

<property>velocities/r-aero-rad_sec</property>




<value> .000 </value>

</product>

</function>



<function name="aero/coefficient/CyDr">

<description>

Side Force due to rudder(DATCOM does not calculate)

</description>

<product>



<property>fcs/rudder-pos-deg</property>


</product>

</function>



<function name="aero/coefficient/CyDa">

<description>

Side Force due to aileron(DATCOM does not calculate)

Usually neglected

</description>

<product>



<property>fcs/left-aileron-pos-deg</property>


</product>

</function>

</axis>

<!--

********************************************************************** -

->

<axis name="ROLL">

<function name="aero/coefficient/Clb">

<description>

Roll Moment coefficient due to Beta(per degree)

Decrease of Clb to small negative value improves Dutch

Roll Damping

High Positive value leads to excessive spiral instability

</description>

<product>



<property>metrics/bw-ft</property>


<table>



<tableData>

-8.000 -.2576E-02

-6.000 -.2902E-02

-4.000 -.3225E-02

-2.000 -.3561E-02

.000 -.3909E-02

2.000 -.4268E-02

3.000 -.4450E-02

4.000 -.4635E-02

5.000 -.4823E-02

6.000 -.5013E-02

7.000 -.5192E-02

8.000 -.5347E-02

9.000 -.5483E-02

10.00 -.5604E-02

11.00 -.5707E-02

12.00 -.5792E-02

14.00 -.5895E-02

16.00 -.5831E-02

18.00 -.5013E-02

20.00 -.4033E-02

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/Clp">

<description>

Roll Moment coefficient due to roll rate(per degree)

Clp alone determines damping-in-roll characteristics

</description>

<product>






<table>



<tableData>

-8.000 .1000E-29

-6.000 .1000E-29

-4.000 .1000E-29

-2.000 .1000E-29

.000 .1000E-29

2.000 .1000E-29

3.000 .1000E-29

4.000 .1000E-29

5.000 .1000E-29

6.000 .1000E-29

7.000 .1000E-29

8.000 .1000E-29

9.000 .1000E-29

10.00 .1000E-29

11.00 .1000E-29

12.00 .1000E-29

14.00 .1000E-29

16.00 .1000E-29

18.00 .1000E-29

20.00 .1000E-29

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/Clr">

<description>

Roll Moment coefficient due to yaw rate(per degree)

Considerable effect on Spiral mode. Large

positive values leads to strong sprial instability.

</description>

<product>






<table>



<tableData>

-8.000 .1000E-29

-6.000 .1000E-29

-4.000 .1000E-29

-2.000 .1000E-29

.000 .1000E-29

2.000 .1000E-29

3.000 .1000E-29

4.000 .1000E-29

5.000 .1000E-29

6.000 .1000E-29

7.000 .1000E-29

8.000 .1000E-29

9.000 .1000E-29

10.00 .1000E-29

11.00 .1000E-29

12.00 .1000E-29

14.00 .1000E-29

16.00 .1000E-29

18.00 .1000E-29

20.00 .1000E-29

</tableData>

</table>

</product>

</function>



<function name="aero/coefficient/ClDr">

<description>

Roll moment due to rudder(DATCOM does not calculate)

Usually insignificant in dynamic stability considerations

but is ued in autopilot work

</description>

<product>






</product>

</function>

</axis>

<!--

********************************************************************** -

->

<axis name="PITCH">

<function name="aero/coefficient/Cm_basic">

<description>

Basic_Pitch_moment_coefficient

</description>

<product>



<property>metrics/cbarw-ft</property>

<table>


<tableData>

-8.000 .2903

-6.000 .2344

-4.000 .1782

-2.000 .1187

.000 .5816E-01

2.000 -.6828E-02

3.000 -.4044E-01

4.000 -.7522E-01

5.000 -.1116

6.000 -.1502

7.000 -.1899

8.000 -.2317

9.000 -.2768

10.00 -.3228

11.00 -.3716

12.00 -.4217

14.00 .000

16.00 .000

18.00 .000

20.00 .000

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/Cmq">

<description>

Pitch moment coefficient due to pitch rate(per degree)

Pitch Damping Derivative

Very important to Short Period damping of oscillations

</description>

<product>






<table>



<tableData>

-8.000 .1000E-29

-6.000 .1000E-29

-4.000 .1000E-29

-2.000 .1000E-29

.000 .1000E-29

2.000 .1000E-29

3.000 .1000E-29

4.000 .1000E-29

5.000 .1000E-29

6.000 .1000E-29

7.000 .1000E-29

8.000 .1000E-29


9.000 .1000E-29

10.00 .1000E-29

11.00 .1000E-29

12.00 .1000E-29

14.00 .1000E-29

16.00 .1000E-29

18.00 .1000E-29

20.00 .1000E-29

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/Cmadot">

<description>

Pitch moment coefficient due to AOA rate(per degree)

Negitive Cmad increase Short Period damping

</description>

<product>





<property>aero/alphadot-deg_sec</property>

<table>



<tableData>

-8.000 .1000E-29

-6.000 .1000E-29

-4.000 .1000E-29

-2.000 .1000E-29

.000 .1000E-29

2.000 .1000E-29

3.000 .1000E-29

4.000 .1000E-29

5.000 .1000E-29

6.000 .1000E-29

7.000 .1000E-29

8.000 .1000E-29

9.000 .1000E-29

10.00 .1000E-29

11.00 .1000E-29

12.00 .1000E-29

14.00 .1000E-29

16.00 .1000E-29

18.00 .1000E-29

20.00 .1000E-29

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/CmDe">

<description>

Pitch moment coefficient due to elevator deflection

Positive surface deflection is trailing edge down

</description>

<product>




<table>

<independentVar lookup="row">fcs/elevator-pos-


<tableData>



</tableData>

</table>

</product>

<function>

</axis>

<!--

********************************************************************** -

->

<axis name="YAW">

<function name="aero/coefficient/Cnb">

<description>

Yaw moment coefficient due to sideslip(per degree)

Determines Dutch Roll and Spiral characteristics

Prevents side-slip and yawing moments

</description>

<product>





<table>



<tableData>

-8.000 .1041E-02

-6.000 .1041E-02

-4.000 .1041E-02

-2.000 .1041E-02

.000 .1041E-02

2.000 .1041E-02

3.000 .1041E-02

4.000 .1041E-02

5.000 .1041E-02

6.000 .1041E-02

7.000 .1041E-02

8.000 .1041E-02

9.000 .1041E-02

10.00 .1041E-02

11.00 .1041E-02


12.00 .1041E-02

14.00 .1041E-02

16.00 .1041E-02

18.00 .1041E-02

20.00 .1041E-02

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/Cnp">

<description>

Yaw moment coefficient due to roll rate(per degree)

Reduces Dutch Roll damping

positive value desireable

</description>

<product>






<table>



<tableData>

-8.000 .1000E-29

-6.000 .1000E-29

-4.000 .1000E-29

-2.000 .1000E-29

.000 .1000E-29

2.000 .1000E-29

3.000 .1000E-29

4.000 .1000E-29

5.000 .1000E-29

6.000 .1000E-29

7.000 .1000E-29

8.000 .1000E-29

9.000 .1000E-29

10.00 .1000E-29

11.00 .1000E-29

12.00 .1000E-29

14.00 .1000E-29

16.00 .1000E-29

18.00 .1000E-29

20.00 .1000E-29

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/Cnr">

<description>

Yaw Moment coefficient due to yaw rate(per degree)

Main contributor to damping of Dutch Roll

</description>

<product>






<table>



<tableData>

-8.000 .1000E-29

-6.000 .1000E-29

-4.000 .1000E-29

-2.000 .1000E-29

.000 .1000E-29

2.000 .1000E-29

3.000 .1000E-29

4.000 .1000E-29

5.000 .1000E-29

6.000 .1000E-29

7.000 .1000E-29

8.000 .1000E-29

9.000 .1000E-29

10.00 .1000E-29

11.00 .1000E-29

12.00 .1000E-29

14.00 .1000E-29

16.00 .1000E-29

18.00 .1000E-29

20.00 .1000E-29

</tableData>

</table>

</product>

</function>



<function name="aero/coefficient/CnDr">

<description>

Yaw Coefficient due to rudder(DATCOM does not calculate)

High value for controllablity, low value

for good dynamic stability

</description>

<product>





<value> -.1047E-02</value>

</product>

</function>

</axis>



<value> .1000E-29</value> 

<sum>



<product>

<property>aero/alpha-deg</property>

<table> <!-- Ch-alpha --

>

<independentVar lookup="row">

aero/alpha-deg</independentVar>

<tableData>

-8.000 .1000E-29

-6.000 .1000E-29

-4.000 .1000E-29

-2.000 .1000E-29

.000 .1000E-29

2.000 .1000E-29

3.000 .1000E-29

4.000 .1000E-29

5.000 .1000E-29

6.000 .1000E-29

7.000 .1000E-29

8.000 .1000E-29

9.000 .1000E-29

10.00 .1000E-29

11.00 .1000E-29

12.00 .1000E-29

14.00 .1000E-29

16.00 .1000E-29

18.00 .1000E-29

20.00 .1000E-29

</tableData>

</table>

</product>

<product>

<property>fcs/elevator-pos-deg</property>

<table> 

<independentVar lookup="row">

fcs/elevator-pos-deg</independentVar>

<tableData>

<!-- **********************************************

No surface deflections specified in input file

********************************************** --

>

</tableData>

</table>

</product>

</sum>

</product>

</function>

</aerodynamics>


5.2.17.5 Graphs

Figure 4:

Graph plot form result of DATCOM

Figure 5:



Figure 6:


Figure 7:



Figure 8 :


Figure 9:



5.2.18 Input control card

This section will provide user with easy input value of aircraft configuration to Digital Datcom. The

control card will provide instruction for each specific value command to user.

The control card can be dividing mainly in 3 groups.

1. Flight condition

2. Synthesis Parameters and Body Configuration Parameters

3. Propulsion system, symmetrical and asymmetrical flight

Group 1 Card 1: Flight Condition

Table 8:

Namelist FLTCON.

Table 9:

Input option to satisfy the Mach number and Reynolde number input requirements


Group 1 Card 2: Reference Parameters

Figure 10:

Name list Options and roughness factors for use in name list options.


Group 2 Card 1: Synthesis Parameters

Table 10:

Namelist synths

Figure 11:

Input for Name list synths – synthesis parameters

Variable Input

Variable Input

XCG

XV

ZCG

ZV

XW

XVF

ZW

ZVF

ALIH

SCALE

XH

ALIH

ZH

Table11 :

Variable input


Group 2 Card 2: Body Configuration Parameters (1)

Figure 12:

Body configurations parameters


Group 2 Card 2: Body Configuration Parameters (2)

Variable Input

NX X

S

P

R

ZU

ZL

BNOSE BLN BTAIL BLA ITYPE

Note:

IN NAMELIST BODY, ONLY THE FOLLOWING COMBINATIONS OF VARIABLES CAN BE USED

* FOR A CIRCULAR BODY, SPECIFY X AND R OR X AND S

* FOR AN ELLIPTICAL BODY, SPECIFY X AND R OR X AND S, AND THE VARIABLE ELLIP

* FOR OTHER BODY SHAPES X, R, S, AND P MUST ALL BE SPECIFIED

Table 13:

Variable input

Table 12:

Body configuration parameters (cont.)


Group 2 Card 3: Wing Planform (1)

Figure 13:

Wing Planform input cards


Group 2 Card 3: Wing Planform (2)

Variable Input

CHRDR

CHRDTP

SSPN

SSPNE

SAVSI

CHSTAT

TWISTA

DHDAI

TYPE

Table 14:

Wing Planform input cars (cont.)


Group 2 Card 4: Wing Sectional Characteristics Parameters (1)

Figure 14:

Input for namelists WGSCHR, HTSCHR, VTSCHR and VFSCHR –Section characteristic



Table 15:

Wing Sectional characteristics parameters


Figure 15:

Wave Drag factors for sharp nose airfoils



The section aerodynamic characteristics for these surfaces are

* input using either the sectional characteristics namelists WGSCHR,

* HTSCHR, VTSCHR and VFSCHR and/or the NACA control cards. Airfoil

* characteristics are assummed constant for each panel of the planform.

* To avoid having to input all the airfoil sectional characteristics, you can specify

the NACA airfoil designation.

* NACA x y zzzzzz

* where:

* column 1-4 NACA

* 5 any deliminator

* 6 W, H, V, or F Planform for which the airfoil

* designation applies: Wing, Horizontal

* tail, Vertical tail, or Ventral fin.

* 7 any deliminator

* 8 1,4,5,6,S Type of airfoil section: 1-series,

* 4-digit, 5-digit, 6-series, or Supersonic

* 9 any deliminator

* 10-80 Designation, columns are free format, blanks are ignored

Input

NACA W

NACA H

NACA V



Horizontal Tail planform variables

* CHRDTP Tip chord

* SSPNOP Semi-span outboard panel. Not required for straight tapered planform.

* SSPNE Semi-span exposed panel

* SSPN Semi-span theoretical panel from theoretical root chord

* CHRDBP Chord at breakpoint

* CHRDR Chord root

* SAVSI Inboard panel sweep angle

* CHSTAT Reference chord station for inboard and outboard panel sweep angles

fraction of chord

* TWISTA Twist angle, negative leading edge rotated down (from

* SSPNDD Semi-span of outboard panel with dihedral

* DHDADI Dihedral angle of inboard panel

* DHDADO Dihedral angle of outboard panel. If DHDADI=DHDADO only input DHDADI

* TYPE 1.0 - Straight tapered planform

* 2.0 - Double delta planform (aspect ratio <= 3)

* 3.0 - Cranked planform (aspect ratio > 3)

* SHB Portion of fuselage side area that lies between Mach lines

* originating from leading and trailing edges of horizontal

* tail exposed root chord (array 20).

* Only required for supersonic and hypersonic speed regimes.

* SEXT Portion of extended fueslage side area that lies between

* Mach lines originating from leading and trailing edges of

* horizontal tail exposed root chord (array 20)


* RLPH Longitudinal distance between CG and centroid of Sh(B)

* positive aft of CG


Variable Input Variable Input

CHRDR CHSTAT

SSPN TWISTA

SSPNE DHDADI

SAVSI TYPE

Table 16:

Variable and inputs



Vertical Fin planform variables

* CHRDR Chord root

* CHRDBP Chord at breakpoint

* CHRDTP Tip chord

* SSPNOP Semi-span outboard panel

* SSPNE Semi-span exposed panel

* SSPN Semi-span theoretical panel from theoretical root chord

* SAVSI Inboard panel sweep angle

* CHSTAT Reference chord station for inboard and outboard panel

sweep angles fraction of chord



* TYPE 1.0 - Straight tapered planform

* 2.0 - Double delta planform (aspect ratio <= 3)

* 3.0 - Cranked planform (aspect ratio > 3)

* SVWB Portion of exposed vertical panel area that lies between Mach lines emanating

from leading and trailing edges of wing exposed root

from leading and trailing edges of wing exposed root chord (array 20)

Only required for supersonic and hypersonic speed regimes.

* SVB Area of exposed vertical panel not influenced by wing or horizontal tail (array 20)


* SVHB Portion of exposed vertical panel area that lies between Mach lines emanating



CHRDR CHSTAT

CHRDTP DHDADO

SSPN TYPE

SSPNE SAVSI

Table 17:

Variable and inputs


Group 3 Card 1: Propellor Power Parameters

Figure 16:

Propeller power parameters


AIETLP NOPBPE

NENGSP BAPR75

THSTCP YP

PHALOC CROT

PHVLOC BWAPR3

PRPRAD BWAPR6

ENGFCT BWAPR9

Table 18:

Variable and inputs


Group 3 Card 2: Jet Power Parameters


AIETLJ

JESTMP NENGSJ

JELLOC

THSTCJ

JETOTP JIALOC

AMBSTP

JEVLOC

JERAD JEALOC

JEVELO

JINLTA

AMBTMP JEANGL

Table 19:

Variable and inputs

Figure 17:

Jet power parameters


Group 3 Card 3: Ground effects Parameters

Figure 18:

Ground effect parameters

Variable Input

NGH

GRDHT

Table 20:

Variable and inputs


Group 3 Card 4: Twin-Vertical Panel INPUT

Variable Input

BVP

BVP

BDV

BH

SV

VPHITE

VLP

ZP

Table 21:

Variable and inputs

Figure 19:

Jet power parameters


Group 3 Card 5: Symetrical Flap Deflection parameters (1)

Figure 20:

Symetrical flap deflection parameters



b

Figure 21:

Symetrical flap deflection parameters (cont.)



Figure 22:




Figure 23:



FTYPE CB

NDELTA TC

DELTA NTYPE

PHETE JETFLP

CHRDFI CMU

CHRDFO DELJET

SPANFI EFFJET

SPANFO DOBDEF

CPRMEI DOBCIN

CPRMEO DOBCOT

CAPINB SCLD

CAPOUT

Table 22:

Variable and inputs


Group 3 Card 6: Asymetrical Control Deflection Input (1)

Figure 24:



Group 3 Card 6: Asymetrical Control Deflection Input (2)

Figure 25:



STYPE DELTAS

NDELTA XSOC

SPANFI XSPRME

SPANFO HSOC

PHETE CHRDFI

DELTAL CHRDFO

DELTAR DELTAD

Table 23:

Variable and inputs


5.3 Aircraft Modeling

This section is dedicated to the procedure of modeling any aircraft to be use in FlightGear it not

the real procedure of create one aircraft for FlightGear but to modify the existing one into our own

design. The reason for this lies in the time limitation for this project, in order to finish it in time, it is

necessary to cut out the complex parts.

Since FlightGear is the mathematic driven program, the properties of the aircraft are independent

of its 3D model, to skip the complexity of modeling 3d model in 3d software. The modification will

be made on these 3 main parts which are the main aircraft configuration file, engine configuration

file and propeller configuration file (in case of the propeller driven aircraft).

5.3.1 Aircraft structure

Before drive deep into the structure of each configuration file, it is important to understand the

structure of the aircraft folder in flight gear, to know where is to modify and where is not to.

FlightGear store data, including aircraft in the data folder under FlightGear directory. To start

create our own aircraft first duplicate some aircraft inside Aircraft directory and rename it.

Inside each aircraft folder will compose of mainly the main configuration file which is present in

the 1st level of directory (green border all xml document), engine configuration inside engines

directory, model to store the 3d model for aircraft, and system folder that contain all other file like

instrument which is not our interest. Therefore the editing will be made only to those file in green

border.

5.3.2 Main configuration

Main means every important data will be put here, starting from the basic geometry, weight and

position, control surface location, engine location, fuel tank location, landing gear location, and

aerodynamic coefficient for aircraft.

This is the most complex file that need careful attention when create/modify, however, we don‟t

have to create it from the scratch. There are guide line and template script that will generate the

file through this address: http://jsbsim.sourceforge.net/aeromatic2.html

Figure 26:

Folder Structure green border indicated the folder that are safe to modify while red border indicated the folder that risk to make the aircraft not readable or not function by FlightGear, orange border shown the customize file that can be delete or edit

http://jsbsim.sourceforge.net/aeromatic2.html


Visit above link and grab the template from there, make sure to select the approximate value that

close to the desire aircraft for example, Number of engine, landing gear layout, and engine type.

The template file may come with pre-load data, ignoring it for now. It will be modify later

The following subsection will go through each of the section in the template file and give the basic

idea of how to modify the value.

Since the XML is readable programing language, we can directly modify the value inside the tag

without worrying about background in XML. However, it is more convenient to divide the main

configuration into small section.

5.3.2.1 Metric section

Metric section mainly concerns about the basic properties of the aircraft, which are wing area,

wing span, wing incidence angle, and chord line, horizontal tail area and arm length from

aerodynamics reference point(depend on each design), and vertical tail area and arm length.

Also, the location of the reference point, the pilot eye location and velocity reference point are

declared here. The sample of the section shown below

5.3.2.2 Mass balance section

This section is about mass of the aircraft, for simplicity the mass of the aircraft can be treating as

point mass at the cg location. However, to increase accuracy it can goes to the very detailed

setting by loading passenger seat by seat. It is totally depend on the user specification. The

sample of the mass balance with the point mass system is shown below.

<metrics>

<wingarea unit="FT2"> 714.29 </wingarea>

<wingspan unit="FT" > 40.00 </wingspan>

<wing_incidence> 2.00 </wing_incidence>

<chord unit="FT" > 17.86 </chord>

<htailarea unit="FT2"> 114.29 </htailarea>

<htailarm unit="FT" > 20.80 </htailarm>

<vtailarea unit="FT2"> 71.43 </vtailarea>

<vtailarm unit="FT" > 20.00 </vtailarm>

<location name="AERORP" unit="IN">

<x> 230.40 </x>

<y> 0.00 </y>

<z> 0.00 </z>

</location>

<location name="EYEPOINT" unit="IN">

<x> 62.40 </x>

<y> -18.00 </y>

<z> 45.00 </z>

</location>

<location name="VRP" unit="IN">

<x>0</x>

<y>0</y>

<z>0</z>

</location>

</metrics>

Code 5:

Metric section in main configuration file with pre-load data generated from Aeromatic.

<mass_balance>

<ixx unit="SLUG*FT2"> 5434 </ixx>

<iyy unit="SLUG*FT2"> 9660 </iyy>

<izz unit="SLUG*FT2"> 13148 </izz>

<emptywt unit="LBS" > 6000 </emptywt>

<location name="CG" unit="IN">

<x> 230.40 </x>

<y> 0.00 </y>

<z> -12.00 </z>

</location>

</mass_balance>

Code 6:

Mass balance section in main configuration file with pre-load data generated from Aeromatic.


5.3.2.3 Undercarriage section

The main function of this section is to define the boundary of the aircraft about where and how it

reacts to the ground, there are two main parts in this section first the landing gear part and

second the aircraft surface part. The flexibility is on the same level of the previous mass balance

section, the configuration can varies from the very detailed to the very rough one with only at

nose, wing-tip, tail, and landing gear have reaction with the ground.

The level of complexity is depend on how do you want to use the simulation, depend on the

objective of that simulation session whether it is to verified control system, structural, or ordinary

test flight

Below is the sample of the code for bogey (gear) and for the structure (surface)

5.3.2.4 Propulsion section

Propulsion section consists of 2 main configuration types first to tell FlightGear location and the

orientation of the engine, and location of the fuel tank and initial fuel loading.

This is the part where the engine name in engine folder (see 5.3.1) will be declared and load into

FlightGear.

Another optional configuration that might appear here is the propeller configuration, if the aircraft

using turbo-prop or piston prop engine the propeller file in engines folder (see 5.31) will be load

and declared in the similar manner as the engine configuration file.

Noticing that apart from the loading in mass balance section, here also have fuel loading, hence,

if there are need to change in take-off weight, this weight will play important role as well as the

loading in the mass and balance section.

The example of the code with preload data can be found in next page

<contact type="BOGEY" name="NOSE">

<location unit="IN">

<x> 62.40 </x>

<y> 0.00 </y>

<z> -57.60 </z>

</location>

<static_friction> 0.80 </static_friction>

<dynamic_friction> 0.50 </dynamic_friction>

<rolling_friction> 0.02 </rolling_friction>

<spring_coeff unit="LBS/FT"> 3000.00 </spring_coeff>

<damping_coeff unit="LBS/FT/SEC"> 1000.00 </damping_coeff>

<max_steer unit="DEG"> 5.00 </max_steer>

<brake_group>NONE</brake_group>

<retractable>1</retractable>

</contact>

///////////////////////

<contact type="STRUCTURE" name="LEFT_WING">


<x> 230.40 </x>

<y> -20.00 </y>

<z> -12.00 </z>

</location>





</contact>

Code7 :

Undercarriage section in main configuration file with pre-load data generated from Aeromatic.


5.3.2.5 Flight Controls section

This section is about the control surface configure for aircraft divide into individual channel each

channel is control only specific control surface for example : aileron, rudder, elevator, including

landing gear retraction control. The sample code is shown below

<engine file="PED_engine">


<x> 36.00 </x>

<y> 0.00 </y>

<z> 0.00 </z>

</location>

<orient unit="DEG">

<pitch> 0.00 </pitch>

<roll> 0.00 </roll>

<yaw> 0.00 </yaw>

</orient>

<feed>0</feed>

<thruster file="PED_prop">


<x> 36.00 </x>

<y> 0.00 </y>

<z> 0.00 </z>

</location>

<orient unit="DEG">


<roll> 0.00 </roll>

<yaw> 0.00 </yaw>

</orient>

</thruster>

</engine>

<tank type="FUEL" number="0">


<x> 230.40 </x>

<y> 0.00 </y>

<z> -12.00 </z>

</location>

<capacity unit="LBS"> 100.00 </capacity>

<contents unit="LBS"> 50.00 </contents>

</tank>

Code 8 :

Propulsion section in main configuration file with pre-load data generated from Aeromatic.

<channel name="Pitch">

<summer name="Pitch Trim Sum">

<input>fcs/elevator-cmd-norm</input>

<input>fcs/pitch-trim-cmd-norm</input>

<clipto>

<min> -1 </min>

<max> 1 </max>

</clipto>

</summer>

<aerosurface_scale name="Elevator Control">

<input>fcs/pitch-trim-sum</input>

<range>

<min> -0.35 </min>

<max> 0.35 </max>

</range>

<output>fcs/elevator-pos-rad</output>

</aerosurface_scale>

<aerosurface_scale name="elevator normalization">

<input>fcs/elevator-pos-rad</input>

<domain>

<min> -0.35 </min>

<max> 0.35 </max>

</domain>

Code 9 :

Flight Control section in main configuration file with pre-load data generated from Aeromatic.


If the desire aircraft didn‟t have a specific type of the control surface that need to manually

configuration, it acceptable to use this generated version of the code.

5.3.2.6 Aerodynamics section

The last, the hardest and the most important section the aerodynamics part; it is the heart of any

aircraft model, because the simulation will derive the force from this data.

The aerodynamics section composes of lift axis, drag axis, side axis, pitch axis, roll axis and yaw

axis each section divide into small function that derive the coefficient from the aerodynamic data

from experiment or from the result of DATCOM.

We can substitute the result from DATCOM here, in the table data section, according to each

corresponding value such as, CL vs Alpha, CL vs Beta etc.

<axis name="LIFT">

<function name="aero/coefficient/CLalpha">

<description>Lift_due_to_alpha</description>

<product>



<table>

<independentVar lookup="row">aero/alpha-rad</independentVar>

<tableData>

-0.20 -0.750

0.00 0.250

0.23 1.400

0.60 0.710

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/dCLflap">

<description>Delta_Lift_due_to_flaps</description>

<product>



<property>fcs/flap-pos-deg</property>

<value> 0.01333 </value>

</product>

</function>

<function name="aero/coefficient/dCLsb">

<description>Delta_Lift_due_to_speedbrake</description>

<product>



<property>fcs/speedbrake-pos-norm</property>

<value>0</value>

</product>

</function>

<function name="aero/coefficient/CLde">

<description>Lift_due_to_Elevator_Deflection</description>

<product>



<property>fcs/elevator-pos-rad</property>

<value>0.2</value>

</product>

</function>

</axis>

Code10 :


<range>

<min> -1 </min>

<max> 1 </max>

</range>

<output>fcs/elevator-pos-norm</output>


</channel>

Code 9(cont):


5.3.2.7 Sample of main configuration file


<?xml-stylesheet type="text/xsl"

href="http://jsbsim.sourceforge.net/JSBSim.xsl"?>

<fdm_config name="PED" version="2.0" release="ALPHA"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="http://jsbsim.sourceforge.net/JSBSim.xsd">

<fileheader>

<author> Aeromatic v 0.91 </author>

<filecreationdate> 2011-03-30 </filecreationdate>

<version>$Revision: 1.10 $</version>

<description> Models a PED. </description>

</fileheader>



<metrics>

<wingarea unit="FT2"> 714.29 </wingarea>

<wingspan unit="FT" > 40.00 </wingspan>

<wing_incidence> 2.00 </wing_incidence>

<chord unit="FT" > 17.86 </chord>

<htailarea unit="FT2"> 114.29 </htailarea>

<htailarm unit="FT" > 20.80 </htailarm>

<vtailarea unit="FT2"> 71.43 </vtailarea>

<vtailarm unit="FT" > 20.00 </vtailarm>

<location name="AERORP" unit="IN">

<x> 230.40 </x>

<y> 0.00 </y>

<z> 0.00 </z>

</location>

<location name="EYEPOINT" unit="IN">

<x> 62.40 </x>

<y> -18.00 </y>

<z> 45.00 </z>

</location>

<location name="VRP" unit="IN">

<x>0</x>

<y>0</y>



<max_steer unit="DEG">0</max_steer>

<brake_group>RIGHT</brake_group>


</contact>

<contact type="STRUCTURE" name="LEFT_WING">


<x> 230.40 </x>

<y> -20.00 </y>

<z> -12.00 </z>

</location>





</contact>

<contact type="STRUCTURE" name="RIGHT_WING">


<x> 230.40 </x>

<y> 20.00 </y>

<z> -12.00 </z>

</location>





</contact>

</ground_reactions>

<propulsion>

<engine file="PED_engine">


<x> 36.00 </x>

<y> 0.00 </y>

<z> 0.00 </z>

</location>

<orient unit="DEG">


<roll> 0.00 </roll>

<yaw> 0.00 </yaw>

</orient>

<feed>0</feed>

<thruster file="PED_prop">


<x> 36.00 </x>

<y> 0.00 </y>

<z> 0.00 </z>

</location>

<orient unit="DEG">


<roll> 0.00 </roll>

<yaw> 0.00 </yaw>

</orient>

</thruster>

</engine>




<x> 230.40 </x>

<y> 0.00 </y>

<z> -12.00 </z>

</location>



</tank>



<x> 230.40 </x>

<y> 0.00 </y>

<z> -12.00 </z>

</location>



</tank>

</propulsion>

<flight_control name="FCS: PED">

<channel name="Pitch">

<summer name="Pitch Trim Sum">

<input>fcs/elevator-cmd-norm</input>

<input>fcs/pitch-trim-cmd-norm</input>

<clipto>

<min> -1 </min>

<max> 1 </max>

</clipto>

</summer>

<aerosurface_scale name="Elevator Control">

<input>fcs/pitch-trim-sum</input>

<range>

<min> -0.35 </min>

<max> 0.35 </max>

</range>

<output>fcs/elevator-pos-rad</output>


<aerosurface_scale name="elevator normalization">

<input>fcs/elevator-pos-rad</input>

<domain>

<min> -0.35 </min>

<max> 0.35 </max>

</domain>

<range>

<min> -1 </min>

<max> 1 </max>

</range>

<output>fcs/elevator-pos-norm</output>


</channel>

<channel name="Roll">

<summer name="Roll Trim Sum">

<input>fcs/aileron-cmd-norm</input>

<input>fcs/roll-trim-cmd-norm</input>

<clipto>


<min> -1 </min>

<max> 1 </max>

</clipto>

</summer>

<aerosurface_scale name="Left Aileron Control">

<input>fcs/roll-trim-sum</input>

<range>

<min> -0.35 </min>

<max> 0.35 </max>

</range>

<output>fcs/left-aileron-pos-rad</output>


<aerosurface_scale name="Right Aileron Control">

<input>fcs/roll-trim-sum</input>

<range>

<min> -0.35 </min>

<max> 0.35 </max>

</range>

<output>fcs/right-aileron-pos-rad</output>


<aerosurface_scale name="left aileron normalization">

<input>fcs/left-aileron-pos-rad</input>

<domain>

<min> -0.35 </min>

<max> 0.35 </max>

</domain>

<range>

<min> -1 </min>

<max> 1 </max>

</range>

<output>fcs/left-aileron-pos-norm</output>


<aerosurface_scale name="right aileron normalization">

<input>fcs/right-aileron-pos-rad</input>

<domain>

<min> -0.35 </min>

<max> 0.35 </max>

</domain>

<range>

<min> -1 </min>

<max> 1 </max>

</range>

<output>fcs/right-aileron-pos-norm</output>


</channel>

<channel name="Yaw">

<summer name="Rudder Command Sum">

<input>fcs/rudder-cmd-norm</input>

<input>fcs/yaw-trim-cmd-norm</input>

<clipto>

<min> -0.35 </min>

<max> 0.35 </max>

</clipto>

</summer>


<aerosurface_scale name="Rudder Control">

<input>fcs/rudder-command-sum</input>

<range>

<min> -0.35 </min>

<max> 0.35 </max>

</range>

<output>fcs/rudder-pos-rad</output>


<aerosurface_scale name="rudder normalization">

<input>fcs/rudder-pos-rad</input>

<domain>

<min> -0.35 </min>

<max> 0.35 </max>

</domain>

<range>

<min> -1 </min>

<max> 1 </max>

</range>

<output>fcs/rudder-pos-norm</output>


</channel>

<channel name="Flaps">

<kinematic name="Flaps Control">

<input>fcs/flap-cmd-norm</input>

<traverse>

<setting>

<position> 0 </position>

<time> 0 </time>

</setting>

<setting>


<time> 4 </time>

</setting>

<setting>


<time> 3 </time>

</setting>

</traverse>

<output>fcs/flap-pos-deg</output>

</kinematic>

<aerosurface_scale name="flap normalization">

<input>fcs/flap-pos-deg</input>

<domain>

<min> 0 </min>

<max> 30 </max>

</domain>

<range>

<min> 0 </min>

<max> 1 </max>

</range>

<output>fcs/flap-pos-norm</output>


</channel>

<channel name="Landing Gear">

<kinematic name="Gear Control">


<input>gear/gear-cmd-norm</input>

<traverse>

<setting>


<time> 0 </time>

</setting>

<setting>


<time> 5 </time>

</setting>

</traverse>

<output>gear/gear-pos-norm</output>

</kinematic>

</channel>

<channel name="Speedbrake">

<kinematic name="Speedbrake Control">

<input>fcs/speedbrake-cmd-norm</input>

<traverse>

<setting>


<time> 0 </time>

</setting>

<setting>


<time> 1 </time>

</setting>

</traverse>

<output>fcs/speedbrake-pos-norm</output>

</kinematic>

</channel>

</flight_control>

<aerodynamics>

<axis name="LIFT">

<function name="aero/coefficient/CLalpha">

<description>Lift_due_to_alpha</description>

<product>



<table>


<tableData>

-0.20 -0.750

0.00 0.250

0.23 1.400

0.60 0.710

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/dCLflap">

<description>Delta_Lift_due_to_flaps</description>

<product>





</product>


</function>

<function name="aero/coefficient/dCLsb">

<description>Delta_Lift_due_to_speedbrake</description>

<product>




<value>0</value>

</product>

</function>

<function name="aero/coefficient/CLde">

<description>Lift_due_to_Elevator_Deflection</description>

<product>




<value>0.2</value>

</product>

</function>

</axis>

<axis name="DRAG">

<function name="aero/coefficient/CD0">

<description>Drag_at_zero_lift</description>

<product>



<table>


<tableData>

-1.57 1.500

-0.26 0.031

0.00 0.024

0.26 0.031

1.57 1.500

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/CDi">

<description>Induced_drag</description>

<product>



<property>aero/cl-squared</property>

<value>0.04</value>

</product>

</function>

<function name="aero/coefficient/CDmach">

<description>Drag_due_to_mach</description>

<product>



<table>

<independentVar lookup="row">velocities/mach</independentVar>

<tableData>

0.00 0.000


0.7 0.000

1.10 0.023

1.80 0.015

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/CDflap">

<description>Drag_due_to_flaps</description>

<product>





</product>

</function>

<function name="aero/coefficient/CDgear">

<description>Drag_due_to_gear</description>

<product>



<property>gear/gear-pos-norm</property>

<value>0.03</value>

</product>

</function>

<function name="aero/coefficient/CDsb">

<description>Drag_due_to_speedbrakes</description>

<product>




<value>0.024</value>

</product>

</function>

<function name="aero/coefficient/CDbeta">

<description>Drag_due_to_sideslip</description>

<product>



<table>

<independentVar lookup="row">aero/beta-rad</independentVar>

<tableData>

-1.57 1.230

-0.26 0.050

0.00 0.000

0.26 0.050

1.57 1.230

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/CDde">

<description>Drag_due_to_Elevator_Deflection</description>

<product>



<abs><property>fcs/elevator-pos-norm</property></abs>


<value>0.04</value>

</product>

</function>

</axis>

<axis name="SIDE">

<function name="aero/coefficient/CYb">

<description>Side_force_due_to_beta</description>

<product>



<property>aero/beta-rad</property>

<value>-1</value>

</product>

</function>

</axis>

<axis name="ROLL">

<function name="aero/coefficient/Clb">

<description>Roll_moment_due_to_beta</description>

<product>





<value>-0.1</value>

</product>

</function>

<function name="aero/coefficient/Clp">

<description>Roll_moment_due_to_roll_rate</description>

<product>






<value>-0.4</value>

</product>

</function>

<function name="aero/coefficient/Clr">

<description>Roll_moment_due_to_yaw_rate</description>

<product>






<value>0.15</value>

</product>

</function>

<function name="aero/coefficient/Clda">

<description>Roll_moment_due_to_aileron</description>

<product>





<property>fcs/left-aileron-pos-rad</property>

<table>


<tableData>

0.0 0.170

2.0 0.057

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/Cldr">

<description>Roll_moment_due_to_rudder</description>

<product>




<property>fcs/rudder-pos-rad</property>

<value>0.01</value>

</product>

</function>

</axis>

<axis name="PITCH">

<function name="aero/coefficient/Cmalpha">

<description>Pitch_moment_due_to_alpha</description>

<product>




<property>aero/alpha-rad</property>

<value>-0.5</value>

</product>

</function>

<function name="aero/coefficient/Cmde">

<description>Pitch_moment_due_to_elevator</description>

<product>





<table>


<tableData>

0.0 -1.100

2.0 -0.275

</tableData>

</table>

</product>

</function>

<function name="aero/coefficient/Cmq">

<description>Pitch_moment_due_to_pitch_rate</description>

<product>







<value>-12</value>

</product>

</function>

<function name="aero/coefficient/Cmadot">

<description>Pitch_moment_due_to_alpha_rate</description>

<product>





<property>aero/alphadot-rad_sec</property>

<value>-7</value>

</product>

</function>

</axis>

<axis name="YAW">

<function name="aero/coefficient/Cnb">

<description>Yaw_moment_due_to_beta</description>

<product>





<value>0.12</value>

</product>

</function>

<function name="aero/coefficient/Cnr">

<description>Yaw_moment_due_to_yaw_rate</description>

<product>






<value>-0.15</value>

</product>

</function>

<function name="aero/coefficient/Cndr">

<description>Yaw_moment_due_to_rudder</description>

<product>




<property>fcs/rudder-pos-rad</property>

<value>-0.1</value>

</product>

</function>

<function name="aero/coefficient/Cnda">

<description>Adverse_yaw</description>

<product>




<property>fcs/left-aileron-pos-rad</property>

<value>-0.01</value>

</product>

</function>

</axis>

</aerodynamics>

</fdm_config>

5.3.3 Engine configuration

If the input data that use to generate the template file are correct and acceptable the result will be

acceptable as well. However, there is some case that we need to create the engine file manually

that is when we model electric motor.

To model electric motor simply chose the piston as engine type when generate the template then

modify open the engine configuration file and modify the “piston_engine” to “electric_engine”,

then modify thrust be careful when changing between the unit make sure that the unit is

consistent, remember to remove cycles tag and sparkfailsdrop tag since it not exist in electric

motor.

Here is the sample file of engine configuration




<piston_engine name="my_engine">

<minmp unit="INHG"> 6.0 </minmp>

<maxmp unit="INHG"> 28.5 </maxmp>

<displacement unit="IN3"> 1900.00 </displacement>

<maxhp> 1000.00 </maxhp>

<cycles> 4.0 </cycles>

<idlerpm> 700.0 </idlerpm>

<maxrpm> 2800.0 </maxrpm>

<maxthrottle> 1.0 </maxthrottle>

<minthrottle> 0.1 </minthrottle>

<sparkfaildrop> 0.1 </sparkfaildrop>

<volumetric-efficiency> 0.85 </volumetric-efficiency>

</piston_engine>

-

5.3.4 Propeller configuration

This propeller configuration will be required when piston engine or turbo prop engine has been

selected for the aircraft. Technically this file is the coefficient of the propeller section into small

pieces, the default value is based on symmetric airfoil experiment data, therefore if our aircraft

has its own specific value for propeller here is the place to place it.

Also in the template generator script there is a function to model the variable pitch propeller, it is

also base on the experiment data of symmetrical airfoil.

Sample of the propeller configuration can be founded below

<propeller name="prop">

<ixx> 10.52 </ixx>

<diameter unit="IN"> 96.0 </diameter>

<numblades> 4 </numblades>

<gearratio> 1.15 </gearratio>

<p_factor> 7.58 </p_factor>

<table name="C_THRUST" type="internal">

<tableData>

0.0 0.1803

0.1 0.1729

0.2 0.1654

0.3 0.1522

0.4 0.1367

0.5 0.1204

0.6 0.0974

0.7 0.0740

0.8 0.0400

1.0 -0.0136

1.2 -0.0710

1.4 -0.1277

</tableData>

</table>

<table name="C_POWER" type="internal">

<tableData>

0.0 0.1211

0.1 0.1211

0.2 0.1182

0.3 0.1153

0.4 0.1087

0.5 0.0996

0.6 0.0915

0.7 0.0768

0.8 0.0627

1.0 0.0225

1.2 -0.0358

1.4 -0.1078

1.6 -0.1829

</tableData>

</table>



<table name="CT_MACH" type="internal">

<tableData>

0.85 1.0

1.05 0.8

</tableData>

</table>



<table name="CP_MACH" type="internal">

<tableData>

0.85 1.0

1.05 1.8

2.00 1.4

</tableData>

</table>

</propeller>-


5.4 Validation of Flight Simulation

5.4.1 Introduction

From our platform of flight simulation will be used in any experiment that need to use the

simulation of real environment with the design aircraft so the simulation need to be ensure that it

will provide the reasonable and precise to the real environment that aircraft expecting to handle.

The method used to test this simulation was to validate the model of the aircraft that run on flight

simulation environment program (FlightGear) by compare the data of some flight testing in each

condition with the company (Boeing aircraft industry) who construct and testing that aircraft.

Validation consists of two forms of model testing, although strictly both are interdependent.

Performance tests are, for the most part, based on steady-state measurements, for example,

maximum level speed, engine-out climb rate or time to reach V1 from brakes release or sideslip

angles for rudder input. The other form of tests involve the system dynamics to ensure that the

response of the system to inputs is correct, for example, the pitching moment change caused by a

change of engine thrust, response in yaw and roll resulting from an engine failure or pitch rate

response with a flight control law.

5.4.2 Document

The Boeing Company provided NASA-Ames Research Center with mathematical models and

data to simulate the flying qualities and characteristics of the Boeing 747 on the NASA Flight

Simulator for Advanced Aircraft (FSAA).

5.4.3 Airplane Description

The Boeing 747 is a very large four-fanjet intercontinental transport designed to operate from

existing international airports. To obtain the necessary low speed characteristics the wing has

triple-slotted trailing flaps and Krueger type leading edge flaps. The Krueger flaps outboard of the

Figure 27:

Cover of 747 jumbo jet simulation model data


inboard nacelle are variable cambered and slotted while the inboard Krueger flaps are standard

unslotted. The main landing gear consists of a pair of wing mounted four-wheel trucks and a pair

of body mounted four-wheel trucks which are slightly aft of the wing. A load equalizing system

between the trucks on each side with limited travel allows the center of pitch rotation to be

midway between the two pairs of trucks. Longitudinal control is obtained through four elevator

segments and a movable stabilizer. The lateral control employs five spoiler panels, an inboard

aileron between the inboard and outboard flaps, and an outboard aileron which operates with

flaps down only on each wing. The five spoiler panels on each wing also operate symmetrically as

speed brakes in conjunction with the most inboard sixth spoiler panel. Directional control is

obtained from two rudder segments.

Figure 28:

Summary of area and dimensions


Figure 29:

Drawing of 747 jumbo jet


5.4.4 Case that use for validation

5.4.4.1 Take-off

Two takeoffs at different gross weights were performed to verify the takeoff acceleration. The

simulation of basic drag characteristics, thrust lapse rate, ground effect in taxi attitudes, rolling

coefficient of friction and inertia effects are indirectly checked by timing takeoff acceleration.

Figure 30:

Load and configuration for take-off case


Data (Case 1: Flap 10, Weight 707,200 lb.)

Velocity

By compare data from NASA we can approximate the data from 10 second interval it acceleration to approximately 40 Kt.

0

20

40

60

80

100

120

140

160

180

200

40 50 60 70 80

Airspeed(kt)

Airspeed(kt)


Elevator deflection angle

The result graph compare to the NASA data was tend exactly the same as NASA data with the deflection was down to -5 degrees.

-6

-5

-4

-3

-2

-1

0

1

40 50 60 70 80

Elevator Defection Angle(deg)

Elevator DefectionAngle(deg)


Body pitch angle

The data was tending to be the same as NASA data document.

0

2

4

6

8

10

12

40 50 60 70 80

Body Pitch Angle(deg)



Height and rate height

Observe from NASA data can be obtain height change from interval 40 feet from starting point and the rate height was tend to be the same as data that obtain from our flight test.

0

5

10

15

20

25

30

35

40

45

50

40 50 60 70 80

Height(ft)

Height(ft)

-2

0

2

4

6

8

10

12

14

40 50 60 70 80

Rate Height (h-dot)(fps)



Data (Case 2: Flap 20, Weight 527,200 lb.)

Velocity

By compare data from NASA we can approximate the data from 10 second interval it acceleration to approximately 50 Kt.

0

20

40

60

80

100

120

140

160

180

200

60 65 70 75 80 85 90 95 100

Airspeed(kt)

Airspeed(kt)


Elevator deflection angle

The result graph compare to the NASA data was tend exactly the same as NASA data with the deflection was down to approximately -7 degrees.

-8.00E+00

-7.00E+00

-6.00E+00

-5.00E+00

-4.00E+00

-3.00E+00

-2.00E+00

-1.00E+00

0.00E+00

1.00E+00

60 70 80 90 100




Body pitch angle

The data was tending to be the same as NASA data document.

0

2

4

6

8

10

12

14

60 70 80 90 100


Longtitude(deg)


Height and rate height

Observe from NASA data can be obtain height change from interval 60 feet from starting point and the rate height was tend to be the same as data that obtain from our flight test.

0

10

20

30

40

50

60

70

60 70 80 90 100

Height(ft)

Height(ft)

-5

0

5

10

15

20

25

60 70 80 90 100




5.4.4.2 Inflight accelerations

The acceleration condition was performed by starting at M = .65 with maximum continuous thrust and accelerating to the maximum speed. Speed and time data were obtained from the cockpit.

The graph was tend to be the same as NASA data but the maximum flight speed was different due to the effect of the pilot when control the aircraft to be close to steady state that aircraft might not be in steady level flight so the aircraft might be pitch down and cause acceleration to flight.

0

1

2

3

4

5

6

7

0.65 0.7 0.75 0.8 0.85 0.9 0.95 1

Tim

e (m

in)

Mach

Time

Time

5.5 Instrument panel coding

Now that everything all function in right way, it times to goes to develop some front user interface

to give information to user which is instrument panel.

As mention earlier in this section that time is the main issue for this flight simulation project and

with that time limit, we can‟t create new standalone instrument system instead using FlightGear

core engine with extra modification. This method allowed us to achieved instrument even in the

small limited time.

The packages that come with FlightGear contain standard instrument and some default pre-model

aircrafts for example, Cessna-182 (which is the default model) and Boeing 777-200ER. According

to our panel design we need 5 displays that show 4 set of information with one display as

duplicate of another.

The information that will be put up front of pilot are divided into 4 set

5.5.1 Primary flight display

Primary flight display, as the name suggest all primary information for flying is shown here which compose of, airspeed indicator, turn and bank indicator, altitude indicator, heading indicator, artificial globe and vertical speed indicator.

This display using the preset and premade texture from Boeing 777-200ER but it not good idea to modify the original code of the 777-200 instrument which may cause fatal error for both 777 model and FlightGear when running, so, simply duplicate all file that inside instrument directory of 777-200 and leave the original unchanged, then a dummy aircraft were created to use as medium to call the instrument of 777-200 by re-routing the instrument loading process to the 777-200 primary display that already set to fit the layout.

This is the dummy aircraft coding to call the instrument.


<PropertyList include="SenecaII-base.xml">

<sim>

<author>Torsten Dreyer</author>

<description>PA34-200T Seneca II (no 3d model, 2d panel only)</description>

<aircraft-version>1.0</aircraft-version>

<status>production</status>

<flight-model>jsb</flight-model>

<aero>SenecaII-jsbsim</aero>

<model>

<path>Aircraft/SenecaII/Models/nothing.ac</path>

</model>

<panel>





<path>Aircraft/777-200/Models/Instruments/CTO/pfd-panel2.xml</path>

<visibility>true</visibility>

</panel>

<rendering>

<camera-group>

<camera>

<window>

<name type="string">Panel</name>

<host-name type="string"></host-name>

<display>0</display>

<screen>0</screen>

<fullscreen type = "bool">false</fullscreen>

</window>

<view>

<heading-deg type = "double">0</heading-deg>

</view>



</camera>



<gui>

<window>


</window>

</gui>

</camera-group>

</rendering>

</sim>

</PropertyList>

This is the layout code for primary flight display.


<PropertyList>

<name>PFD Panel</name>

<background>Aircraft/777-200/Models/Instruments/CTO/black.png</background>

<w>1280</w>

<h>800</h>

<instruments>

<instrument include="hdg.xml">

<name>HDG</name>

<x>225</x>

<y>88.0</y>

<w>268</w>

<h>80</h>

</instrument>

<instrument include="ai.xml">

<name>AI</name>

<x>226</x>

<y>310.0</y>

<w>276</w>

<h>264</h>

</instrument>

<instrument include="speed.xml">

<name>Spd</name>

<x>48</x>

<y>312</y>

<w>68</w>

<h>356</h>

</instrument>

<instrument include="alttape.xml">

<name>Alttape</name>

<x>410</x>

<y>310</y>

<w>66</w>

<h>352</h>

</instrument>

<instrument include="vsi.xml">

<name>vsi</name>

<x>480</x>

<y>312</y>

<w>52</w>

<h>240</h>

</instrument>



<instrument include="mask.xml">

<name>mask</name>

<x>256</x>

<y>300</y>

<w>512</w>

<h>512</h>

</instrument>

<instrument include="loc-scale.xml">

<name>loc-scale</name>

<x>226</x>

<y>176</y>

<w>156</w>

<h>16</h>

</instrument>

<instrument include="gs-scale.xml">

<name>gs-scale</name>

<x>356</x>

<y>308.4</y>

<w>16</w>

<h>156</h>

</instrument>

<instrument include="pfdtext.xml">

<name>overlay-text</name>

<x>256</x>

<y>300</y>

<w>512</w>

<h>512</h>

</instrument>



<instrument include="APP.xml">

<name>ND</name>

<x>768</x>

<y>300</y>

<w>512</w>

<h>512</h>

</instrument>

<instrument include="apptext.xml">

<name>ND</name>

<x>768</x>

<y>300</y>

<w>512</w>

<h>512</h>

</instrument>

</instruments>

</PropertyList>

5.5.2 Navigation display

Navigation display right now the only use of it is to show the heading of the aircraft and the bearing with the airport VOR direction.

Now same as primary display, 777-200 instrument will be load through the same dummy aircraft, we only need to prepare the layout to be called.

The the layout code for navigation display were code together with the primary flight display because it will display together in same monitor.

5.5.3 Middle Display

Thrust display and backup (analog) instrument will be place here. Instruments in this display are coming from many places all over the FlightGear data directory, some are from the default instrument collection in main instrument library, however, throttle layout is from the 777-200 again.

This is the dummy aircraft code for the middle display


<PropertyList include="SenecaII-base.xml">

<sim>

<author>Torsten Dreyer</author>

<description>PA34-200T Seneca II (no 3d model, 2d panel only)</description>

<aircraft-version>1.0</aircraft-version>

<status>production</status>

<flight-model>jsb</flight-model>

<aero>SenecaII-jsbsim</aero>

<model>

<path>Aircraft/SenecaII/Models/nothing.ac</path>

</model>

<panel>





<path>Aircraft/777-200/Models/Instruments/CTO/eicas-panel.xml</path>

<visibility>true</visibility>

</panel>

<rendering>

<camera-group>

<camera>

<window>




<screen>0</screen>

<fullscreen type = "bool">false</fullscreen>

</window>

<view>

<heading-deg type = "double">0</heading-deg>

</view>



</camera>

<!--<camera>

<window>

<name type="string">StraightAhead</name>



<screen>1</screen>

<fullscreen type = "bool">true</fullscreen>

</window>

<view>

<heading-deg type = "double">0.0</heading-deg>

<pitch-deg type = "double">10.0</pitch-deg>

</view>

<frustum>

<top>0.133</top>


<left>-.1668</left>


<near>0.4</near>

<far>120000.0</far>

</frustum>

</camera>-->

<gui>

<window>


</window>

</gui>

</camera-group>

</rendering>

</sim>

</PropertyList> This is the code for layout the middle display.


<PropertyList>

<name>EFIS Panel</name>

<background>Aircraft/777-200/Models/Instruments/CTO/MD/black.png</background>

<w>1280</w>

<h>960</h>

<instruments>

<instrument include="LHepr.xml">

<name>LHepr</name>

<x>400</x>

<y>400</y>

<w>110</w>

<h>110</h>

</instrument>

<instrument include="RHepr.xml">

<name>RHepr</name>

<x>556</x>

<y>400</y>

<w>110</w>

<h>110</h>

</instrument>

<instrument include="LHn1.xml">

<name>LHn1</name>

<x>400</x>

<y>290</y>

<w>110</w>

<h>110</h>

</instrument>

<instrument include="RHn1.xml">

<name>RHn1</name>

<x>556</x>

<y>290</y>

<w>110</w>

<h>110</h>

</instrument>

<instrument include="Gear.xml">

<name>gear-annun</name>

<x>750</x>

<y>450</y>


<w>51</w>

<h>40</h>

</instrument>

<instrument include="Flaps.xml">

<name>flaps</name>

<x>650</x>

<y>400</y>

<w>40</w>

<h>100</h>

</instrument>

<instrument include="eicastext.xml">

<name>text</name>

<x>622</x>

<y>275</y>

<w>610</w>

<h>386</h>

</instrument>

<instrument include="ati-c172s.xml">

<name>Attitude Gyro</name>

<x>125</x>

<y>618</y>

<w>200</w>

<h>200</h>

</instrument>

<instrument include="alt-c172s.xml">

<name>Altimeter</name>

<x>125</x>

<y>418</y>

<w>200</w>

<h>200</h>

</instrument>

<instrument include="trn-c172s.xml">

<name>Turn Coordinator</name>

<x>125</x>

<y>218</y>

<w>200</w>

<h>200</h>

</instrument>

<instrument include="clock.xml">

<name>Clock</name>

<x>440</x>

<y>100</y>

<w>200</w>

<h>200</h>

</instrument>

</instruments>

</PropertyList>

5.5.4 Map

Map and trace route of the vehicle, this is additional software for FlightGear called Atlas. The idea of atlas is simple, it receives the coordinate via the socket network from main FlightGear instance and plots it on the map, Atlas also has capability to display tower radio frequency and VOR, and DME frequency.

there are some thing that need to be done before running Atlas which is to generate map and thumbnail for Atlas.

This procedure was done in command prompts of window. (Assuming Atlas was installed at default directory) execute one line at a time.

> cd C:\Program Files (x86)\FlightGear\bin\win32 > set FG_ROOT=C:\Program Files\FlightGear\data > set FG_SCENERY=C:\Program Files\FlightGear\Data\Scenery;C:\Program Files\FlightGear\Scenery > map --size=256 --atlas=C:\Program Files\FlightGear\data\Atlas > map --size=64 --atlas=C:\Program Files\FlightGear\data\Atlas\lowres


6. Scope of project

Since engineering flight simulation system is board system combined from many sub-systems

such as, control system, visual system, engine, instrument and navigation, to cover all system will

consume time longer than the senior project period. So to be able to finished with the limit

knowledge and time, the scopes (limitations) of this system are set to be

Only the system required for simulate aircraft will be concern throughout the project, any

others systems are neglect.

The details of how to modeling a 3D geometry, rigging and animation of aircraft 3D model,

also the details of how to code the flight dynamic model are not included and will not be

discuss in this project.

The input to the system are control stick, rudder, and thrust level.

7. Results

At the end of this project, the objective of setting up the flight simulation system that can perform

basic analysis and give an experience of flying aircraft has fulfills even the backbone system is

little hard to handle and lack of tool to playing around with the aircraft configuration due to

shortage in time and resources.

Also, from section 5.4 the validation of flight simulation it‟s shown an acceptable accuracy of

result that produce from the simulation. The result can be used as crossed checked with result

from the equation. So, it is possible to analysis any aircraft design from scratch with this flight

simulation system.

Last, the simulation framework or simulation concepts have been layout; a further development

will be discussion in next section (section 8)

Figure 31 :

Finished terminal.


8. Conclusion and future work

Flight simulation system is the system that solve the equation of motion (6 degree of freedoms)

when the given aircraft model are subject to any flight conditions which is called flight dynamics

model, with the visual generation system the result of simulation can be convert and project into

real-time visualization, which helps understand the result from the equation of motion which are

the coefficients of lift, drag, and side forces and roll, pitch, and yaw moments

The combination of FlightGear Flight Simulator and JSBSim Flight Dynamic model, which are

open source projects written in the C++ programming language and used in this project, provided

a solid base for building the scalable simulation environment.

This project was intent to build the basic simulation environment that have potential of holding

new feature without modifies the core system, Although many challenges were faced at the

beginning of the project due to the need to investigate different approaches, and the lack of clear

documentation for FlightGear, the aims of the project were met, and the project objectives

specified in section 4 were all achieved.

As mention earlier this project was opens the door to the new area of knowledge and new area of

learning for aerospace engineering students that wish to continue perform a future work in this

project, it is hold unbound potential of developing this system as long as there are basic idea

layout for them. Student can further enhance the core system functionality, increase stability of

system by decreasing FlightGear resource usage, develop interaction panel, integrate the control

system in to simulation process, implement fully functional avionics system, and even develop the

motion system.

As for the faculty, the facility from this project give many benefits, it can be used as tool aid the

teaching in aircraft design class, avionics class, aircraft stability and control class, and aerospace

engineering laboratory class. or if it has been further develop to the certain level (if it could obtain

the FAA certificate it would be great). When reach that level this flight simulation faci lities can be

open as the center and charge for service.


REFERENCES

1. David Allerton, (2009). Principles of flight simulation (1st edition). Available: No.:629.13252078 AA434P at Center of

Academic Resources, Chulalongkorn University Use Arial 16pt. bold for title, and Arial 8pt. regular for references.

2. Bandu N. Pamadi, (1998) Performance, Stability, Dynamics, and Control of Airplanes

3. E. Bruce Jackson, (August 7-9, 1995). Results of a Flight Simulation Software Methods Survey. Presented at AIAA Flight

Simulation Technologies Conference. [Electronic format]. Available at NASA Technical reports server (NTRS) Document ID:

19970012788

4. E. Bruce Jackson and Bruce L. Hildreth, Status of the AIAA modeling and simulation format standard. [Electronic format]

Available at freepatentsonline.com keyword: flight simulation

5. Jon S. Berndt and the JSBSim Development Team (2010) JSBSim An open source, platform-independent, flight dynamics

model in C++ [Electronic format] Availble at http://jsbsim.sf.net

6. Michael Basler, Martin Spott, Stuart Buchanan, Jon Berndt, Bernhard Buckel, Cameron Moore, Curt Olson, Dave Perry,

Michael Selig, Darrell Walisser, and others, (2011) The FlightGear Manual [Electronic format]. Available at http://flightgear.org

7. David R. Miller [email protected] ,(Update edition 4 Mar, 2006) Multiple Monitors in FlightGear: Quick and Dirty [Electronic

format] Available at http://www.inkdrop.net/dave/multimon.pdf

8. Tarek Abdunabi, (August 2006) Modelling and Autonomous Flight Simulation of a Small Unmanned Aerial Vehicle [Electronic

format] Available at http://jsbsim.sf.net

flight simulation final report

Documents