Flight Simulation Final Report

International School of Engineering
Chulalongkorn University
FLIGHT SIMULATION
Raksok Khankhampoch
E-mail: k.raksok@live.com
ID: 503 13960 21 Phone: 085 393 5599
Sorasit Thongjeen
E-mail: sorasit_wasup@hotmail.com
ID: 503 14359 21

Phone: 080 595 7849
Advisor: Asst. Prof. Niphon Wansophark
Signature
Date
Academic Year 2010
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 ai rcraft 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
Page 1 | AERO Senior Project Final Report 2010
Flight Simulation
validation data to enable the simulator developer to compare the simulator dynamics and performance with actual aircraft data. From the manufacturers 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 pullup 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
Flight Simulation
AERO Senior Project Final Report 2010 | Page 2
straightforward with modern data acquisition hardware, the typical resolution of sampled data is only 1216 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 2050ms 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.
Flight Simulation
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 Microsofts 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 were 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, its 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 theres 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, multiplatform, 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
Flight Simulation
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, FlightGears 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.
Flight Simulation
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,
Flight Simulation
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
Flight Simulation
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> <command>property-scale</command> <property>/controls/flight/elevator</property> <factor type="double">-1.0</factor> <squared type="bool">true</squared> </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> <command>nasal</command> <script>controls.applyBrakes(1)</script> </binding> <mod-up> <binding> <command>nasal</command> <script>controls.applyBrakes(0)</script> </binding> </mod-up> </button> <button n="0"> <desc>Brakes</desc> <binding> <command>nasal</command> <script>controls.applyBrakes(1)</script> </binding> Code 1: Default input configuration device
Flight Simulation
Code 1 (cont.): Default input configuration device
<mod-up> <binding> <command>nasal</command> <script>controls.applyBrakes(0)</script> </binding> </mod-up> </button>
<button n="1"> <desc>Elevator trim up</desc> <repeatable type="bool">true</repeatable> <binding> <command>nasal</command> <script>controls.elevatorTrim(1)</script> </binding> </button> <button n="2"> <desc>Elevator trim down</desc> <repeatable type="bool">true</repeatable> <binding> <command>nasal</command> <script>controls.elevatorTrim(-1)</script> </binding> </button> </PropertyList>
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 didnt 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> <command>property-scale</command> <property>/controls/flight/aileron</property> <squared type="bool">true</squared> </binding> </axis> <axis n="1"> <desc>Elevator</desc> <binding> <command>property-scale</command> <property>/controls/flight/elevator</property> <factor type="double">-1.0</factor> <squared type="bool">true</squared> </binding>
Flight Simulation
</axis> <axis n="3"> <desc>Elevator Trim</desc> <binding> <command>property-scale</command> <property>/controls/flight/elevetor-trim</property> <factor type="double">1.0</factor> </binding> </axis> <axis n="4"> <desc>Rudder Trim</desc> <binding> <command>property-scale</command> <property>/controls/flight/rudder-trim</property> <offset type="double">0.0</offset> <factor type="double">1.0</factor> </binding> </axis> <axis n="5"> <desc>Aileron Trim</desc> <binding> <command>property-scale</command> <property>/controls/flight/aileron-trim</property> <offset type="double">0.0</offset> <factor type="double">1.0</factor> <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> <command>nasal</command> <script>controls.throttleAxis()</script> </binding> </axis> <axis n="1"> <desc>Throttle-2</desc> <binding> <command>nasal</command> <script>controls.throttleAxis()</script> </binding> </axis> <button n="0"> <name>T1</name> <desc>Flaps Up</desc> <repeatable>false</repeatable> <binding> <command>nasal</command> <script>controls.flapsDown(-1)</script> </binding> <mod-up> <binding>
Flight Simulation
<command>nasal</command> <script>controls.flapsDown(0)</script> </binding> </mod-up> </button> <button n="1"> <name>T2</name> <desc>Flaps Down</desc> <repeatable>false</repeatable> <binding> <command>nasal</command> <script>controls.flapsDown(1)</script> </binding> <mod-up> <binding> <command>nasal</command> <script>controls.flapsDown(0)</script> </binding> </mod-up> </button> <button n="4"> <name>P1</name> desc>Start Engine</desc> <repeatable>false</repeatable> <binding> <command>nasal</command> <script>controls.startEngine(1)</script> </binding> <mod-up> <binding> <command>nasal</command> <script>controls.startEngine(0)</script> </binding> </mod-up> </button> <button n="5"> <name>P2</name> <desc>Toggle Parking Brake</desc> <binding> <command>nasal</command> <script>controls.applyParkingBrake(1)</script> </binding> <mod-up> <binding> <command>nasal</command> <script>controls.applyParkingBrake(0)</script> </binding> </mod-up> </button> <button n="6"> <name>P3</name> <desc>Pause Simulation</desc> <repeatable>false</repeatable> <binding> <command>property-toggle</command> <property>/sim/freeze/master</property> </binding> <binding> <command>property-toggle</command>
Flight Simulation
<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> <command>nasal</command> <script>aircraft.HUD.cycle_color()</script> </binding> </button> <button n="8"> <name>P5</name> <desc>Toggle Landing Gear</desc> <binding> <command>nasal</command> <script>controls.gearToggle()</script> </binding> </button> <button n="9"> <name>P6</name> <desc>Toggle 2D/3D cockpit</desc> <binding> <command>nasal</command> <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>
Flight Simulation
</button> <button n="11"> <name>P8</name> <desc>Cycle View</desc> <binding> <command>nasal</command> <script>view.stepView(1)</script> </binding> </button> </PropertyList>
Rudder pedal configuration file

*note: since differential brake function wasnt working as expect (too sensitive) it has been disable for convenient, however, can be re-enable if needed.
<?xml version="1.0"?> <PropertyList> <name>Logitech G940 Pedals</name>  <axis n="3"> <desc>Rudder</desc> <binding> <command>property-scale</command> <property>/controls/flight/rudder</property> <factor>1.0</factor> <offset>0.0</offset> </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 wasnt configured because they are rarely use in our research environment that focus on developing aircraft model not flying.
Flight Simulation
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-fdm=socket,out,60,127.0.0.1,5500,udp --native-ctrls=socket,out,60,127.0.0.1,5501,udp --native-fdm=socket,out,60,127.0.0.1,5507,udp -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 cant 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.
cd "C:\Program Files\FlightGear\bin\Win64" ECHO running flightgear fgfs --fg-root="C:\Program Files (x86)\FlightGear\data" --fgscenery="C:\Program Files (x86)\FlightGear\data\Scenery";"C:\Program Files (x86)\FlightGear\scenery";"C:\Program Files (x86)\FlightGear\terrasync" --aircraft=dhc2W --timeofday=noon --nativefdm=socket,in,60,127.0.0.1,5500,udp --nativectrls=socket,in,60,127.0.0.1,5501,udp --fdm=null --disable-hud --disablesound --prop:/sim/ai/enabled=false --prop:/sim/ai-traffic/enabled=false -prop:/sim/rendering/bump-mapping=false --prop:/sim/rendering/drawotw=false
Code 2: The batch file code for running the main environment instance of FlightGear.
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.
Flight Simulation
Code 3: The batch file code for running instrument in middle display.
cd "C:\Program Files\FlightGear\bin\Win64" ECHO running flightgear fgfs --fg-root="C:\Program Files (x86)\FlightGear\data" --fgscenery="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 --nativefdm=socket,in,60,127.0.0.1,5507,udp --nativectrls=socket,in,60,127.0.0.1,5508,udp --fdm=null --disable-hud --disablesound --prop:/sim/ai/enabled=false --prop:/sim/ai-traffic/enabled=false -prop:/sim/rendering/bump-mapping=false --prop:/sim/rendering/drawotw=false
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. --native-fdm=socket,out,60,169.200.94.211,5509,udp --native-ctrls=socket,out,60,169.200.94.211,5510,udp 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 cant be used for conduct the research if it cant 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.
<?xml version="1.0"?> <PropertyList> <logging> <log> <enabled>true</enabled> <filename>Flight-log.csv</filename> <interval-ms>1000</interval-ms> <delimiter>,</delimiter> <entry> <enabled>true</enabled> <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
Flight Simulation
<entry> <enabled>true</enabled> <title>Elevator condition</title> <property>/controls/flight/elevator</property> </entry> <entry> <enabled>true</enabled> <title>Aileron condition</title> <property>/controls/flight/aileron</property> </entry> <entry> <enabled>true</enabled> <title>Roll</title> <property>/orientation/roll-deg</property> </entry> <entry> <enabled>true</enabled> <title>Pitch</title> <property>/orientation/pitch-deg</property> </entry> <entry> <enabled>true</enabled> <title>Yaw</title> <property>/orientation/heading-deg</property> </entry> <entry> <enabled>true</enabled> <title>Acceleration in Z-Axis(fps^2)</title> <property>/accelerations/pilot/z-accel-fps_sec</property> </entry> <entry> <enabled>true</enabled> <title>Rate Height (h-dot)(fps)</title> <property>/fdm/jsbsim/velocities/h-dot-fps</property> </entry> <entry> <enabled>true</enabled> <title>Acceleration in X-Axis(fps^2)</title> <property>/accelerations/pilot/x-accel-fps_sec</property> </entry> <entry> <enabled>true</enabled> <title>Airspeed(kt)</title> <property>/velocities/airspeed-kt</property> </entry> <entry> <enabled>true</enabled> <title>Mach</title> <property>/velocities/mach</property> </entry> <entry> <enabled>true</enabled> <title>Height(ft)</title> <property>/position/altitude-ft</property> </entry> <entry> <enabled>true</enabled> <title>Throttle%</title> <property>/controls/engines/throttle</property> </entry> <entry> <enabled>true</enabled> <title>Latitude(deg)</title> <property>/position/latitude-deg</property> </entry>
Code 4 (cont.): Logging code that use during simulation test flight include validation process
Flight Simulation
Code 4 (cont.): Logging code that use during simulation test flight include validation process
<entry> <enabled>true</enabled> <title>Longtitude(deg)</title> <property>/position/longtitude-deg</property> </entry> </log> </logging> </PropertyList>
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.
Table 1: DATCOM Addressable configurations
Configuration
Program remarks 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 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 Longitudinal methods reflect only a mid-wing position. Lateral directional solutions consider high and low-wing positions. 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 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.
Body
Wing, Horizontal Tail Body-wing bodyhorizontal
Wing-body-tail
Non-standard geometries

Special configuration
Flight Simulation
Low aspect ratio wing or wing-body configurations are treated at subsonic. Two-dimensional flap and transverse jet effects are also treated at hypersonic.
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 longitudinalstability 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.
Flight Simulation
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, singleslotted, double-slotted, fowler, and leading edge flaps and slats. Control devices, such as trailingedge 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 allmovable or flying. In this case, output as a function of angle of attack consists of horizontalstabilizer 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.
Flight Simulation
Table 2: High Lift/Control Device Output
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.
Flight Simulation
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
Flight Simulation
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) M < 0.6 0.6 < M < 1.4 M > 1.4 M > 1.4 and the hypersonic flag is set Mach Regime Subsonic Transonic Supersonic Hypersonic
Flight Simulation
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) M < STMACH STMACH < M < TSMACH M > TSMACH M > TSMACH and the hypersonic flag is set Mach Regime Subsonic Transonic Supersonic Hypersonic
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
Flight Simulation
2.
3.
4.
5.
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. 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. 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 nondimensional chord stations (x/c of 0.0, 0.001, 0.002, and 0.003. 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. 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.
Flight Simulation
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.
Flight Simulation
High Lift/Control Device Output
Table 2:
Flight Simulation
Table 3:
Flight Simulation
Table 5:
Flight Simulation
Talbe (Top) 6: Required namelist fro analysis of special configuraions
Table (bottom) 7: Input unit options
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.
Flight Simulation
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 userspecified 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 Jorgensens method, which is applicable from zero to 180 degrees angle of attack. Jorgensens 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
Flight Simulation
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 secondlevel 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
Flight Simulation
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.
Flight Simulation
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) 1 thru 4 input(s) NACA Purpose The unique letters NACA designate that at airfoil is to be defined Any delimiter Purpose Planforms for which the airfoil designation applies Wing(W), Horizontal tail (H), Vertical Tail (V), or ventral Fin (F) Type of airfoil section; 1-series (1), 4-digit (4), 5-digit (5), 6-series (6). or supersonic (S) Input designation; columns are free-field (blanks are ignored)
5 Card Column(s) 6
input(s) W, H, V, or F
7 8
Any delimiter 1, 4, 5, 6, S
9 10 thru 80
Any delimeter Designation
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).
Flight Simulation
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 dervatives 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
Flight Simulation
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.
Flight Simulation
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 users 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 linearlift-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.
Flight Simulation
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 lateral reference length. CNR - Vehicle yawing derivative based on the product of reference area and the square of the lateral reference length. CLR - Vehicle rolling derivative based on the product of reference area and the square of the lateral reference length.
Flight Simulation
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.
Flight Simulation
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 hingemoment 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.
Flight Simulation
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.
Figure 2: Seneca II
5.2.17.2 Input code

NACA NACA NACA NACA W V H F 5 4 4 4 65415 0009 0009 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,
Flight Simulation
X(1) =0.0, 1.54, 6.56, R(1) =0.0, 0.98, 2.03, ZU(1)=3.61, 4.49, 5.31, ZL(1)=3.61, 2.82, 2.46, ITYPE=1.0, METHOD=1.0$
9.25, 15.7, 26.6, 2.03, 2.03, 0.0, 6.43, 5.64, 4.63, 2.23, 2.07, 3.58,
$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
Flight Simulation
5.2.17.4 Aerodynamics output

<!-********************************************************************** AERODYNAMICS ********************************************************************** --> <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>   <!-The following ground effect tables are NOT generated by DATCOM, but provide representative effects. These terms are not currently used in this model. --> <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-macft</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-macft</independentVar> <tableData> 0.0 0.480 0.1 0.515 0.15 0.629 0.2 0.709 0.3 0.815
Flight Simulation
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-factorlift</property> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <table> <independentVar lookup="row">aero/alphadeg</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
Flight Simulation
18.00 20.00 </tableData> </table> </product> </function>
1.322 .9168
<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/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>aero/ci2vel</property> <table> <independentVar lookup="row">aero/alphadeg</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> </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>
Flight Simulation
<property>aero/alphadot-deg_sec</property> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>aero/ci2vel</property> <table> <independentVar lookup="row">aero/alphadeg</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> </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-factorlift</property> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <table> <independentVar lookup="row">aero/alphadeg</independentVar>
Flight Simulation
<tableData> -8.000 -6.000 -4.000 -2.000 .000 2.000 3.000 4.000 5.000 6.000 7.000 8.000 9.000 10.00 11.00 12.00 14.00 16.00 18.00 20.00 </tableData> </table> </product> </function> </axis>
.2278E-01 .1766E-01 .1613E-01 .1805E-01 .2404E-01 .3401E-01 .4062E-01 .4834E-01 .5717E-01 .6715E-01 .7737E-01 .8715E-01 .9703E-01 .1068 .1163 .1255 .1420 .1483 .1165 .1043
<!-********************************************************************** -> <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/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>aero/beta-deg</property> <table> <independentVar lookup="row">aero/alphadeg</independentVar> <tableData> -8.000 -.8926E-02 -6.000 -.8926E-02 -4.000 -.8926E-02 -2.000 -.8926E-02 .000 -.8926E-02 2.000 -.8926E-02
Flight Simulation
3.000 4.000 5.000 6.000 7.000 8.000 9.000 10.00 11.00 12.00 14.00 16.00 18.00 20.00 </tableData> </table> </product> </function>
-.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02 -.8926E-02
<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/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>aero/bi2vel</property> <table> <independentVar lookup="row">aero/alphadeg</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
Flight Simulation
</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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>aero/bi2vel</property> <value> .000 </value> </product> </function>  <function name="aero/coefficient/CyDr"> <description> Side Force due to rudder(DATCOM does not calculate) </description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>fcs/rudder-pos-deg</property> <value> .000 </value> </product> </function>  <function name="aero/coefficient/CyDa"> <description> Side Force due to aileron(DATCOM does not calculate) Usually neglected </description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>fcs/left-aileron-pos-deg</property> <value> .000 </value> </product>
Flight Simulation
</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>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/beta-deg</property> <table> <independentVar lookup="row">aero/alphadeg</independentVar> <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> <property>aero/qbar-psf</property>
Flight Simulation
<property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/bi2vel</property> <property>velocities/p-aero-rad_sec</property> <table> <independentVar lookup="row">aero/alphadeg</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> </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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/bi2vel</property> <property>velocities/r-aero-rad_sec</property> <table> <independentVar lookup="row">aero/alphadeg</independentVar> <tableData> -8.000 .1000E-29 -6.000 .1000E-29 -4.000 .1000E-29 -2.000 .1000E-29 .000 .1000E-29
Flight Simulation
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> <property>metrics/bw-ft</property> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>fcs/rudder-pos-deg</property> <value> .000 </value> </product> </function> </axis> <!-********************************************************************** -> <axis name="PITCH"> <function name="aero/coefficient/Cm_basic"> <description> Basic_Pitch_moment_coefficient </description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/cbarw-ft</property> <table> <independentVar lookup="row">aero/alphadeg</independentVar>
Flight Simulation
<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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/cbarw-ft</property> <property>aero/ci2vel</property> <property>velocities/q-aero-rad_sec</property> <table> <independentVar lookup="row">aero/alphadeg</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
Flight Simulation
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/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/cbarw-ft</property> <property>aero/ci2vel</property> <property>aero/alphadot-deg_sec</property> <table> <independentVar lookup="row">aero/alphadeg</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> </function> <function name="aero/coefficient/CmDe"> <description>
Flight Simulation
Pitch moment coefficient due to elevator deflection Positive surface deflection is trailing edge down </description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/cbarw-ft</property> <table> <independentVar lookup="row">fcs/elevator-posdeg</independentVar> <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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/beta-deg</property> <table> <independentVar lookup="row">aero/alphadeg</independentVar> <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
Flight Simulation
12.00 14.00 16.00 18.00 20.00 </tableData> </table> </product> </function>
.1041E-02 .1041E-02 .1041E-02 .1041E-02 .1041E-02
<function name="aero/coefficient/Cnp"> <description> Yaw moment coefficient due to roll rate(per degree) Reduces Dutch Roll damping positive value desireable </description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/bi2vel</property> <property>velocities/p-aero-rad_sec</property> <table> <independentVar lookup="row">aero/alphadeg</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> </function> <function name="aero/coefficient/Cnr"> <description>
Flight Simulation
Yaw Moment coefficient due to yaw rate(per degree) Main contributor to damping of Dutch Roll </description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/bi2vel</property> <property>velocities/r-aero-rad_sec</property> <table> <independentVar lookup="row">aero/alphadeg</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> </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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>fcs/rudder-pos-deg</property> <value> -.1047E-02</value>
Flight Simulation
</product> </function> </axis> <!-********************************************************************** -> <function name="aero/elev_hinge_moment_ft_lbs"> <description> Elevator hinge moment in ft-lbs HM = q * S * Cbar * ( Ch0 + Cha*alpha + Chd*delta ) Positive causes trailing edge down movement Ch0 is used to artifically trim HM to zero </description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <value> .000 </value>  <value> .1000E-29</value>  <sum> <!-<property>aero/Ch0_elev</property> --> <product> <property>aero/alpha-deg</property> <table> 
Ch-delta
<independentVar lookup="row"> fcs/elevator-pos-deg</independentVar> <tableData>  <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>
Flight Simulation
<z>0</z> </location> </metrics> <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> <ground_reactions> <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="BOGEY" name="LEFT_MAIN"> <location unit="IN"> <x> 239.62 </x> <y> -43.20 </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"> 10000.00 </spring_coeff> <damping_coeff unit="LBS/FT/SEC"> 2000.00 </damping_coeff> <max_steer unit="DEG">0</max_steer> <brake_group>LEFT</brake_group> <retractable>1</retractable> </contact> <contact type="BOGEY" name="RIGHT_MAIN"> <location unit="IN"> <x> 239.62 </x> <y> 43.20 </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"> 10000.00 </spring_coeff>
Flight Simulation
<damping_coeff unit="LBS/FT/SEC"> 2000.00 </damping_coeff> <max_steer unit="DEG">0</max_steer> <brake_group>RIGHT</brake_group> <retractable>1</retractable> </contact> <contact type="STRUCTURE" name="LEFT_WING"> <location unit="IN"> <x> 230.40 </x> <y> -20.00 </y> <z> -12.00 </z> </location> <static_friction> 0.80 </static_friction> <dynamic_friction> 0.50 </dynamic_friction> <spring_coeff unit="LBS/FT"> 10000.00 </spring_coeff> <damping_coeff unit="LBS/FT/SEC"> 2000.00 </damping_coeff> </contact> <contact type="STRUCTURE" name="RIGHT_WING"> <location unit="IN"> <x> 230.40 </x> <y> 20.00 </y> <z> -12.00 </z> </location> <static_friction> 0.80 </static_friction> <dynamic_friction> 0.50 </dynamic_friction> <spring_coeff unit="LBS/FT"> 10000.00 </spring_coeff> <damping_coeff unit="LBS/FT/SEC"> 2000.00 </damping_coeff> </contact> </ground_reactions> <propulsion> <engine file="PED_engine"> <location unit="IN"> <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"> <location unit="IN"> <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> </thruster> </engine> <tank type="FUEL" number="0">
Flight Simulation
<location unit="IN"> <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> <tank type="FUEL" number="1"> <location unit="IN"> <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> </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> <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> </aerosurface_scale> </channel> <channel name="Roll"> <summer name="Roll Trim Sum"> <input>fcs/aileron-cmd-norm</input> <input>fcs/roll-trim-cmd-norm</input> <clipto>
Flight Simulation
<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> <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> <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> <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> </aerosurface_scale> </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>
Flight Simulation
<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> <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> </aerosurface_scale> </channel> <channel name="Flaps"> <kinematic name="Flaps Control"> <input>fcs/flap-cmd-norm</input> <traverse> <setting> <position> 0 </position> <time> 0 </time> </setting> <setting> <position> 15 </position> <time> 4 </time> </setting> <setting> <position> 30 </position> <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> </aerosurface_scale> </channel> <channel name="Landing Gear"> <kinematic name="Gear Control">
Flight Simulation
<input>gear/gear-cmd-norm</input> <traverse> <setting> <position> 0 </position> <time> 0 </time> </setting> <setting> <position> 1 </position> <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> <position> 0 </position> <time> 0 </time> </setting> <setting> <position> 1 </position> <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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <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>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>fcs/flap-pos-deg</property> <value> 0.01333 </value> </product>
Flight Simulation
</function> <function name="aero/coefficient/dCLsb"> <description>Delta_Lift_due_to_speedbrake</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <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>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>fcs/elevator-pos-rad</property> <value>0.2</value> </product> </function> </axis> <axis name="DRAG"> <function name="aero/coefficient/CD0"> <description>Drag_at_zero_lift</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <table> <independentVar lookup="row">aero/alpha-rad</independentVar> <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/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>aero/cl-squared</property> <value>0.04</value> </product> </function> <function name="aero/coefficient/CDmach"> <description>Drag_due_to_mach</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <table> <independentVar lookup="row">velocities/mach</independentVar> <tableData> 0.00 0.000
Flight Simulation
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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>fcs/flap-pos-deg</property> <value> 0.00100 </value> </product> </function> <function name="aero/coefficient/CDgear"> <description>Drag_due_to_gear</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>gear/gear-pos-norm</property> <value>0.03</value> </product> </function> <function name="aero/coefficient/CDsb"> <description>Drag_due_to_speedbrakes</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>fcs/speedbrake-pos-norm</property> <value>0.024</value> </product> </function> <function name="aero/coefficient/CDbeta"> <description>Drag_due_to_sideslip</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <abs><property>fcs/elevator-pos-norm</property></abs>
Flight Simulation
<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/qbar-psf</property> <property>metrics/Sw-sqft</property> <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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/beta-rad</property> <value>-0.1</value> </product> </function> <function name="aero/coefficient/Clp"> <description>Roll_moment_due_to_roll_rate</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/bi2vel</property> <property>velocities/p-aero-rad_sec</property> <value>-0.4</value> </product> </function> <function name="aero/coefficient/Clr"> <description>Roll_moment_due_to_yaw_rate</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/bi2vel</property> <property>velocities/r-aero-rad_sec</property> <value>0.15</value> </product> </function> <function name="aero/coefficient/Clda"> <description>Roll_moment_due_to_aileron</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property>
Flight Simulation
<property>fcs/left-aileron-pos-rad</property> <table> <independentVar lookup="row">velocities/mach</independentVar> <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>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <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/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/cbarw-ft</property> <property>aero/alpha-rad</property> <value>-0.5</value> </product> </function> <function name="aero/coefficient/Cmde"> <description>Pitch_moment_due_to_elevator</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/cbarw-ft</property> <property>fcs/elevator-pos-rad</property> <table> <independentVar lookup="row">velocities/mach</independentVar> <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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/cbarw-ft</property> <property>aero/ci2vel</property> <property>velocities/q-aero-rad_sec</property>
Flight Simulation
<value>-12</value> </product> </function> <function name="aero/coefficient/Cmadot"> <description>Pitch_moment_due_to_alpha_rate</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/cbarw-ft</property> <property>aero/ci2vel</property> <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> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/beta-rad</property> <value>0.12</value> </product> </function> <function name="aero/coefficient/Cnr"> <description>Yaw_moment_due_to_yaw_rate</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>aero/bi2vel</property> <property>velocities/r-aero-rad_sec</property> <value>-0.15</value> </product> </function> <function name="aero/coefficient/Cndr"> <description>Yaw_moment_due_to_rudder</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>fcs/rudder-pos-rad</property> <value>-0.1</value> </product> </function> <function name="aero/coefficient/Cnda"> <description>Adverse_yaw</description> <product> <property>aero/qbar-psf</property> <property>metrics/Sw-sqft</property> <property>metrics/bw-ft</property> <property>fcs/left-aileron-pos-rad</property> <value>-0.01</value>
Flight Simulation
</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
<?xml version="1.0"?> <!-File: my_engine.xml Author: Aero-Matic v 0.82 Inputs: name: my_engine type: piston power: 1000.0 hp augmented? no injected? no --> <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
Flight Simulation
<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>-
Flight Simulation
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
Figure 27: Cover of 747 jumbo jet simulation model data
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
Flight Simulation
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
Flight Simulation
Figure 29: Drawing of 747 jumbo jet
Flight Simulation
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
Flight Simulation
Data (Case 1: Flap 10, Weight 707,200 lb.) Velocity
Airspeed(kt)
200 180 160 140 120 100 80 60 40 20 0 40 50 60 70 80 Airspeed(kt)
By compare data from NASA we can approximate the data from 10 second interval it acceleration to approximately 40 Kt.
Flight Simulation
Elevator deflection angle
Elevator Defection Angle(deg)

1
0
40 -1 -2 -3 -4 -5 -6 50 60 70 80
The result graph compare to the NASA data was tend exactly the same as NASA data with the deflection was down to -5 degrees.
Flight Simulation
Body pitch angle
Body Pitch Angle(deg)

12
10
0 40 50 60 70 80
The data was tending to be the same as NASA data document.
Flight Simulation
Height and rate height
Height(ft)
50 45 40 35 30 25 20 15 10 5 0 40 50 60 70 80
Height(ft)
Rate Height (h-dot)(fps)

14 12 10 8 6 4 2 0 -2 40 50 60 70 80 Rate Height (hdot)(fps)
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.
Flight Simulation
Data (Case 2: Flap 20, Weight 527,200 lb.) Velocity
Airspeed(kt)
200 180 160 140 120
100
80 60 40 20 0 60 65 70 75 80 85 90 95 100
Airspeed(kt)
By compare data from NASA we can approximate the data from 10 second interval it acceleration to approximately 50 Kt.
Flight Simulation
Elevator deflection angle

1.00E+00 0.00E+00 60 -1.00E+00 -2.00E+00 -3.00E+00 Elevator Defection Angle(deg) -4.00E+00 -5.00E+00 -6.00E+00 70 80 90 100
-7.00E+00
-8.00E+00
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.
Flight Simulation
Body pitch angle

14 12 10 8
6
4 2 0 60 70 80 90 100
Longtitude(deg)
The data was tending to be the same as NASA data document.
Flight Simulation
Height and rate height
Height(ft)
70 60 50 40 30 20 10 0 60 70 80 90 100 Height(ft)
Rate Height (h-dot)(fps)

25 20 15 10 5 0 60 -5 70 80 90 100 Rate Height (hdot)(fps)
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.
Flight Simulation
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.
Time
7 6 5 Time (min) 4 3 2 1 0 0.65 0.7 0.75 0.8 Mach 0.85 0.9 0.95 1 Time
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.
Flight Simulation
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 cant 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.
<?xml version="1.0"?> <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>
Flight Simulation
</view>  </camera>  <gui> <window> <name type="string">Panel</name> </window> </gui> </camera-group> </rendering> </sim> </PropertyList>
This is the layout code for primary flight display.

<?xml version="1.0"?> <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>
Flight Simulation
<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>
Flight Simulation
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
<?xml version="1.0"?> <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> <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> <name type="string">Panel</name> </window> </gui> </camera-group> </rendering> </sim> </PropertyList>
This is the code for layout the middle display.

<?xml version="1.0"?> <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>
Flight Simulation
<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
Flight Simulation
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
Figure 31 : Finished terminal.
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 its 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)
Flight Simulation
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 facilities can be open as the center and charge for service.
Flight Simulation
REFERENCES
1. 2. 3.
4. 5. 6. 7. 8.
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. Bandu N. Pamadi, (1998) Performance, Stability, Dynamics, and Control of Airplanes 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 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 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 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 David R. Miller dave@inkdrop.net ,(Update edition 4 Mar, 2006) Multiple Monitors in FlightGear: Quick and Dirty [Electronic format] Available at http://www.inkdrop.net/dave/multimon.pdf 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

Flight Simulation Final Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Flight Simulation Final Report

Uploaded by

Copyright:

Available Formats

International School of Engineering

ID: 503 13960 21 Phone: 085 393 5599

ID: 503 14359 21

Advisor: Asst. Prof. Niphon Wansophark

Academic Year 2010

2.1.1. Equation of motion

2.1.2. Aircraft model

Page 1 | AERO Senior Project Final Report 2010

2.1.3. Aircraft stability and control

2.2.1. Data acquisition

AERO Senior Project Final Report 2010 | Page 2

2.2.2. Visual system

Page 3 | AERO Senior Project Final Report 2010

2.3.1 What make FlightGear difference than others simulator?

AERO Senior Project Final Report 2010 | Page 4

2.4.1 What exactly is JSBSim?

Page 5 | AERO Senior Project Final Report 2010

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

3.1 Results of a flight simulation software methods survey.

3.2 Status of AIAA modeling and simulation format standard.

AERO Senior Project Final Report 2010 | Page 6

Page 7 | AERO Senior Project Final Report 2010

5.1.1 Input device modification

AERO Senior Project Final Report 2010 | Page 8

Code 1 (cont.): Default input configuration device

<mod-up> <binding> <command>nasal</command> <script>controls.applyBrakes(0)</script> </binding> </mod-up> </button>

Joystick configuration file

Page 9 | AERO Senior Project Final Report 2010

Throttle configuration file

AERO Senior Project Final Report 2010 | Page 10

Page 11 | AERO Senior Project Final Report 2010

AERO Senior Project Final Report 2010 | Page 12

Rudder pedal configuration file

Page 13 | AERO Senior Project Final Report 2010

5.1.2 Multi-instance configuration

AERO Senior Project Final Report 2010 | Page 14

5.1.3 Multi-computer configuration

5.1.4 Logging configuration

Page 15 | AERO Senior Project Final Report 2010

AERO Senior Project Final Report 2010 | Page 16

<entry> <enabled>true</enabled> <title>Longtitude(deg)</title> <property>/position/longtitude-deg</property> </entry> </log> </logging> </PropertyList>

5.2 DATCOM Program capability

5.2.1 Addressable configurations

Table 1: DATCOM Addressable configurations

Wing, Horizontal Tail Body-wing bodyhorizontal

Page 17 | AERO Senior Project Final Report 2010

5.2.2 Basic configuration data

5.2.2.1 Static Stability Characteristics

AERO Senior Project Final Report 2010 | Page 18

5.2.2.2 Dynamic Stability Characteristics

5.2.2.3 High-Lift and Control Characteristics

5.2.2.4 Trim Option

Page 19 | AERO Senior Project Final Report 2010

Table 2: High Lift/Control Device Output

5.2.3.2 Aerodynamic Control at Hypersonic Speeds

AERO Senior Project Final Report 2010 | Page 20

5.2.3.3 Transverse-jet Control Effectiveness

Page 21 | AERO Senior Project Final Report 2010

5.2.4 Operational considerations

5.2.4.1 Flight Condition Control

5.2.4.2 Mach Regimes

AERO Senior Project Final Report 2010 | Page 22

5.2.4.3 Input Diagnostics

5.2.4.4 Airfoil Section Module