A Multi-Disciplinary Rotorcraft Simulation Facility Composed of Commodity Components and Open Source Software. Abstract

Transcription

1 A Multi-Disciplinary Rotorcraft Simulation Facility Composed of Commodity Components and Open Source Software Joseph F. Horn Derek O. Bridges Charu Sharma Leonard V. Lopes Kenneth S. Brentner Assistant Professor Graduate Research Assistants Associate Professor Department of Aerospace Engineering The Pennsylvania State University University Park, PA Abstract A low-cost rotorcraft simulation facility was developed for university-based multi-disciplinary research programs. The objective was to develop a flexible and effective research facility with minimal initial costs and little to no recurring costs. The simulation facility was constructed entirely from commercially available commodity hardware components. Several PC computers are linked together via a local network to form a graphical cluster. The arrangement allows multiple displays and multiple compute nodes to interact. The facility uses the free, opensource FlightGear simulation code and the U.S. Army / NASA GENHEL flight dynamics model. The system is being used for advanced research programs in the areas of flight control design, advanced rotorcraft flight dynamics modeling, and near real-time acoustics simulation. The use of free open-source source software was found to be challenging due to the lack of documentation, but it provided the flexibility and cost-effectiveness needed for the project. Some weaknesses related to the control feel and latencies were noted, but were found to be acceptable for this engineering research facility. Introduction The performance, availability, and affordability of computers, display systems, and networking systems are constantly improving. Furthermore, there is an ongoing movement devoted to the development of inexpensive, open-source software. Both of these trends have increased the feasibility of developing real-time rotorcraft simulation facilities within a university research environment. Real-time simulation can be a valuable tool within academia. Some universities have even developed high-fidelity simulation facilities capable of performing true handling qualities analyses [1]. A high-end handling qualities simulator often features a motion base, wide field of view projection systems, realistic control inceptors, and proprietary software. The development of this type of facility is cost-prohibitive for many institutions. However, the use of a low-cost engineering simulation facility can be quite valuable for both education and graduate research. Even with limited fidelity, a real-time simulation is quite useful for the development of flight dynamics models and flight control systems, because it provides timely visualization of aircraft response and a reasonable assessment of the handling characteristics. Real-time simulation is also helpful for education, since students can more readily grasp concepts related to flight dynamics and feedback control by observing these concepts in simulation. For example, students can observe a phugoid oscillation or see how feedback control can stabilize an inherently unstable aircraft. In addition to the traditional disciplines associated with flight simulation (e.g. flight dynamics, control design, handling qualities), it is envisioned that a real-time simulation might also be used for research related to other aerospace disciplines such as aerodynamics and acoustics. This paper presents the development of a low-cost rotorcraft simulation facility for use in multidisciplinary research and education at Penn State University. Several examples of low-cost, real-time engineering simulation tools are present throughout the rotorcraft community. NASA Ames Research Center has developed the Real-time Interactive Prototype Technology Integration / Development Environment (RIPTIDE) [2]. This software provides an integrated environment for development of simulation mathematical models, control system designs, and cockpit-display concepts. RIPTIDE is currently being used at the Georgia Institute of Technology to study Carefree Maneuvering Technology [3]. Boeing Helicopters has developed a distributed simulation architecture using low cost PC/Linux clusters [4]. A new Multi-Disciplinary Rotorcraft Simulation Facility is currently being developed at Penn State University. Some of the applications of this facility are as follows: 1. Education in rotorcraft stability and control

2 2. Flight controls and cueing system research 3. Advanced flight dynamics modeling 4. Rotorcraft acoustics research 5. Real-time visualization of complex flow fields The facility is designed to have maximum flexibility with minimal costs, and thus it is constructed entirely with commodity hardware components and opensource software. It incorporates a cluster of PC systems that can communicate through a variety of network protocols. The cluster is highly expandable and can incorporate a number of different node types, which perform either compute or graphical operations. The heart of the system uses the Linux operating systems and the FlightGear flight simulator software. FlightGear is an open-source, multi-platform, cooperative flight simulator development project [5]. The source code for the entire project is publicly available and licensed under the GNU General Public License. The FlightGear code has already seen application in other university research projects [6]. In this project FlightGear is primarily used for its graphics engine while the U.S. Army / NASA Ames GENHEL code [7] is used for the flight dynamics math model. The GENHEL code can be run on a separate computer from FlightGear by two-way transmission of data via network sockets. Several upgrades to the GENHEL model have been implemented to allow increased functionality and improved user interface. Implementation The main objective in the design of the PSU Rotorcraft Flight Simulation Facility was to achieve a highly flexible real-time simulation tool at a relatively low cost. The initial cost had to be kept within a budget constraint of $45K, and the system had to avoid large recurring costs (for example, annual software licenses and maintenance fees). In order to achieve this, the system does not use any custom components. It is composed entirely of commercial off the shelf hardware components, including the computers, plasma displays, LCD displays, sound system, and control inceptors. The system also uses free open-source software, including the Linux operating system, GNU compilers, and the FlightGear simulation software. In order to model the rotorcraft flight dynamics, a public domain version of the GENHEL code (provided by NASA Ames) is used. Multiple computers are connected in a graphical cluster using network socket communications to provide multiple out-the-window displays, cockpit instruments, and an operator station. Photographs of the simulation facility are shown in Figures 1 and 2. Plasma s Speaker LCD Instrument s Flight Link Controls Figure 1 The PSU Rotorcraft Flight Simulation Facility, View #1

3 Amplifier Computer Cabinet Operator Station Figure 2 The PSU Rotorcraft Flight Simulation Facility, View #2 Hardware Implementation A schematic of the hardware architecture is shown in Figure 3. The diagram illustrates the interconnections of all the existing and planned components of the simulator. Detailed description of the hardware components are listed below., Computing, and Controls Hardware The main hardware components of the system include the following: 1. Three Panasonic 42 inch HDTV flat-panel plasma displays are used for the main out-the-window graphics. The displays are mounted on moveable floor stands in order to allow for maximum flexibility. Plasma displays were chosen over a projector system due to their superior definition and brightness. Multiple displays can be arranged to provide a wrap-around view. Furthermore, the cost of plasma displays has decreased significantly in the last several years, resulting in an affordable alternative to a projector system. 2. Four Samsung 15 inch, high contrast LCD displays are available for auxiliary displays. Two displays can be used for cockpit instruments and two additional displays are used as consoles for the operator station. The operator consoles can monitor the out-the-window displays, in addition to displaying information related to preprocessing and postprocessing of simulator results. selection is performed using a 4-port KVM switch. LCD displays were chosen since they require minimal desk space and power with a price comparable to CRT monitors. 3. The computers used for the simulation are typical high-end PC computers with NVIDIA GeForce 4 Ti4600 AGP graphics cards, with simultaneous analog and digital video capability. The computers are rack mounted in a 25U cabinet to minimize the footprint of the facility. 4. Rotary wing flight controls, which include a cyclic stick, collective lever, seat, and pedals, were purchased from Flight Link Aviation Training Devices. The cyclic stick and pedals have a built in spring gradient, but do not have recentering capability (force-trim release). The collective lever has variable friction, but no backdrive. The lack of back-drive and stick trim capability is a significant drawback, but the controls are well suited for the cost constraints of this facility. The cyclic stick also features a number of buttons that can serve different functions in the simulation. In addition, a joystick can be used in place of the cyclic stick and collective lever to provide an alternative three-axis sidestick control for the simulator.

4 Graphical Cluster The flight simulator has been configured in an arrangement we refer to as a graphical Beowulf cluster. The basic design is based on the Beowulf cluster, a widely used multi-computer architecture in which several commodity computers (typically PCs) are linked together within a private network to provide large-scale parallel computations. In the current flight simulator, the nodes are connected together in the same way (and with the same software) as a traditional Beowulf cluster, but each node has graphical capabilities and provides a visual output. In this setup each node is a graphical workstation consisting of high-end graphics cards supporting multiple displays, sound cards with high audio quality playback. All of the graphical nodes are connected to the displays via digital and/or analog input/output. A server node acts as the gateway to the external network and takes care of distributing work to the slave nodes. In addition, other types of nodes can be linked to the server, for example the flight dynamics model and the acoustics subsystem run on separate compute nodes. Sound System An advanced sound system was implemented primarily for research on rotorcraft acoustics simulations as described below. Thus the system is mainly used to generate playback of external noise simulations, although an internal noise component of the simulation may be added in the future. The system uses an off the shelf Sony 6.1 surround sound home theatre system with a Dolby Digital/DTS receiver. The surround sound capability of the system has not been utilized in the initial phase of the acoustic simulation. To generate the low frequency noise, which is characteristic of helicopter rotor noise, a high power subwoofer is used in place of the standard subwoofer. Two different versions of a SVS CS-Plus subwoofer with low frequency response (down to ~16Hz) have been tested. In one configuration, the subwoofer is driven by a Samsung dual channel 1000 watt (500 watt per channel) amplifier. In a second configuration, the SVS PC-Plus subwoofer has a built in 525 watt BASH amplifier, which also has low frequency response (~16Hz). Both subwoofers can be used simultaneously to generate intense low frequency rotor noise. Out-the-Window s Instrument Panel Plasma Plasma Plasma LCD LCD Network Switch Master GENHEL (Windows) KVM Switch Audio Surround Sound System CHARM LCD Keyboard + Mouse LCD Keyboard + Mouse Operator Station Video Connection Network Connection Keyboard/Mouse Connection Audio Connection Existing Component Planned Component Figure 3 PSU Rotorcraft Simulator Hardware Schematic

5 Software Implementation The simulator incorporates several different software packages running on different nodes. The schematic in Figure 4 illustrates how data is transferred between the different programs. A description of the key software components and how they were implemented is given below. FlightGear At the heart of the simulator software is the FlightGear simulation package, which acts as the primary graphics engine, coordinates network communication between sub-systems, and reads in pilot control inputs. FlightGear is a free, open-source simulation code that is portable across many different processors and operating systems. The code is written in C++ and uses OpenGL graphics. It also is linked with the free, open-source gaming library PLIB. For this application, FlightGear is compiled and run under the Linux operating system. FlightGear supports synchronization of multiple displays together to form a panoramic or wrap around view. An unlimited number of display channels are permitted, where each channel is a separate process on a network socket. There is built-in support for network socket communication and the display synchronizing is built on top of this support. FlightGear allows both UDP and TCP protocol in the network communication. In this application the User Datagram Protocol (UDP) is used. UDP is a connectionless transport-layer protocol that belongs to the Internet protocol family. The UDP protocol was selected over TCP because it has a very small overhead, thus having a minimal effect on frame rate. UDP headers contain fewer bytes and consume less network overhead than TCP. FlightGear also allows for modification of the graphical database, and it supports a number of different formats for inserting graphical models. For example, a model of a UH-60 coast guard helicopter was used to provide a third-person view of the aircraft, and a model of an LHA ship was added for use in studying shipboard operations. The main drawback of FlighGear is that it lacks the extensive documentation and support that is often available with commercially sold software. There is some on-line documentation and README files, but many advanced features (such as the capability to interface with external flight dynamics models as discussed below) are not well documented. This is partly alleviated by the fact that the code is opensource. Furthermore, the FlightGear development community itself is open and the developers freely exchange information about the code with advanced users and other developers. MATLAB (Windows) Initialization Initialization Initialization Rotor Data WOPWOP Rotor Loading GENHEL (Windows) Rotor Wake CHARM (Windows) Control Data Flight Dynamics Data Sound Flight Controls Control Data FlightGear Graphics s s s Control Inputs Visual Data Pilot Figure 4 PSU Rotorcraft Simulator Software Schematic

6 GENHEL Flight Dynamics Model FlightGear incorporates a number of different built-in flight dynamics models, but these are primarily for fixed-wing aircraft and are not suitable for accurate simulation of rotorcraft. The flight dynamics model selected for the simulator is the U.S. Army / NASA Ames GENHEL model of the UH-60A Blackhawk [7]. This is a well established FORTRAN based simulation code made available to PSU by NASA Ames Rotorcraft Division. The code represents an accurate representation of the UH-60A flight dynamics but it does not provide any out-the-window graphics or an interface for pilot control inputs. Furthermore, the code operates from input files and does not have a graphical user interface. Thus, the main software development work involved with this project was to interface the GENHEL math model with FlightGear and to provide an improved user interface for the operator (this is discussed in the next section). Initially we exploited the open-source nature of FlightGear, by developing a new flight dynamics module within the FlightGear code. This required recoding of the GENHEL model into C++, incorporating the new module into the FlightGear code, and recompiling and re-linking. This was not an ideal solution. Porting the GENHEL code into C++ is a tedious process and requires re-validation of the model. Nonetheless, a working version of GENHEL was eventually ported into a FlightGear module, but many features such as the engine module were never ported. As the project evolved, new versions of FlightGear were released that allowed support of external flight dynamics models. This enabled a better solution for integrating the GENHEL flight dynamics. FlightGear can use its built-in network socket communication to transmit data to and from an external flight model running on a separate computer. Clearly this is more efficient since the flight dynamics calculations and the graphics processing do not need to run on the same processor. Furthermore, the original GENHEL FORTRAN code can remain essentially unchanged, so no further validation is required. This also improves modularity of the simulator in that the GENHEL code can be modified and recompiled independently of any other software. The FlightGear code also required minimal modification in this configuration. The only software development required was to implement a network interface for GENHEL. FlightGear uses two native protocols for interfacing with an external flight model. The native FDM protocol is used to receive flight dynamics data (position, attitude, etc ) from the external flight model. The native controls protocol is used to send the pilot control inputs (cyclic, pedals, collective, and discretes) to the external flight model. Two C++ header files define the two native protocol classes, which are essentially data structures containing all the data passed. These headers are linked with the GENHEL code along with a function to send and receive data via network sockets. The GENHEL code is compiled and executed with Visual Studio under the Windows 2000 operations system. The Visual Studio environment was used because it provides debugging features and allows easy compilation of mixed-language code (needed to include the C++ network interface). The fact that GENHEL and FlightGear ran on two different operating systems did not present any major obstacles. However, one must be careful about ensuring that the ports used are not blocked or restricted in each of the operating systems. Also, it was necessary to make some modifications to the native controls class in FlightGear because of slight differences in the way Windows and Linux handle the alignment of double precision variables in C++ data structures. In addition to the network interface with FlightGear, a number of modifications and improvements have been made to the original GENHEL code. The most notable of these are listed below: 1. A modified main executive was added to control execution of the GENHEL model. The main GENHEL model is a separate subroutine partitioned from the main executive. The executive controls timing for real-time operation, transmission of data to and from FlightGear, and can be used to implement modified flight control laws. 2. Prescribed pilot control inputs can be read in from files into the main executive in order to run check cases. 3. A pilot model is available in the main executable in order to simulate prescribed flight trajectories read from a file. The pilot model is based on an optimal control model (OCM) representation of the human pilot [9] and uses airspeed scheduled MIMO control laws to autonomously track a 3-D trajectory. 4. The code was modified to allow variation in the number of blade segments. A larger number of blade segments are necessary for acoustics calculations. 5. The CHARM free wake module has been integrated with the GENHEL code [19]. The CHARM free wake can be used for inflow calculations and rotortail interactions. 6. The code was modified to allow output of blade loading data compatible with the PSU-WOPWOP

7 acoustics code. This enables the acoustics playback discussed later in this paper. 7. The GENHEL code can read in CFD solutions of a ship airwake in order to accurately simulate helicopter flight in shipboard operations [9]. 8. The model of the stability augmentation system (SAS) and flight path stabilization system (FPS) have been modified so that individual axes can be turned on or off. Execution of FlightGear As shown in Figure 1, the FlightGear software must be executed on several different Linux nodes, and a number of network communications between different executions of FlightGear and the GENHEL math model need to be established. A master node reads the pilot control inputs, handles communication with GENHEL, and sends data to the slave nodes. Meanwhile, the slave nodes simply receive data from the master node and drive the out-the-window displays. This complex execution of the FlightGear software is automated using shell scripts and the extensive array of command line options available in FlightGear. For example: 1. The execute script on the master node starts the FlightGear program on all the slave nodes remotely (using the fgfsnode* script as described below). In addition, it executes FlightGear on the master node, with the instructions to: receive flight dynamics data from the GENHEL node via port 5501 (using nativefdm option), transmit pilot control data to the GENHEL node via port 5502 (using native-ctrls options), and send flight dynamics data to the three slave nodes driving out the window displays via ports 5502, 5503, and 5504 (also using native-fdm option). This script is shown in Figure On a slave node, for example node 1, fgfsnode1 executes FlightGear with instructions to receive all flight dynamics data from the master node via port 5503 (using the native-fdm option). The slave nodes might also set different field of view options for example to set left and right window views. This script is shown in Figure 6. Once the FlightGear software is executed it runs completely independently of the flight dynamics calculations. If no flight dynamics data is sent from GENHEL, it simply goes into a freeze mode waiting for new coordinates to be sent. Thus, the scripts require only a one-shot execution, all resets and retrims are handled on the flight dynamics side through a separate operator interface for GENHEL described below. # Start FlightGear on the slave nodes rsh node1 /home/flightsim/fgfsnode1 & rsh node2 /home/flightsim/fgfsnode2 & rsh node3 /home/flightsim/fgfsnode3 & # Start FlightGear on the Master node, listen for data from Genhel and send data to the slave nodes using UDP protocol. cd /usr/local/flightgear-0.9.3/bin./fgfs --fg-root=/usr/local/flightgear fdm=external --native-fdm=socket,in,30,,5501,udp --native-ctrls=socket,out,30, ,5502,udp --native-fdm=socket,out,30, ,5503,udp --native-fdm=socket,out,30, ,5504,udp --native-fdm=socket,out,30, ,5505,udp # fgfsnode1 Figure 5 Master Execute Script cd /usr/local/flightgear-0.9.3/bin export DISPLAY=localhost:0.0 # Start FlightGear on 1, listen for data from the Master node./fgfs --fg-root=/usr/local/flightgear fdm=null --native-fdm=socket,in,30,,5503,udp --view-offset=0.0 --fov= disable-panel --disable-hud Figure 6 Slave Execute Script MATLAB Interface In order to provide a straightforward interface for the simulator operator, a graphical user interface (GUI) has been designed in MATLAB [20]. The GUI (shown in Figure 6) allows the simulator operator to set a number of options for the GENHEL code. These options include: 1.) Initial conditions: e.g. position, altitude, airspeed, and heading. 2.) Aircraft properties: e.g. weight, inertias, C.G. data. 3.) AFCS settings: SAS, FPS, or user-defined control laws. 4). Mode of operation: real-time piloted simulation, prescribed control inputs, or pilot model. 5) Simulation variables: rotor inflow model, number of blade segments, data output for PSU-WOPWOP. Without the GUI, these options must be set by editing a number of text input files, but in this case MATLAB automatically generates these input files and then executes the GENHEL code. After the simulation run is complete

8 MATLAB processes any output files and provides time history plots. The GUI incorporates a number of related tools, including plotting options for multiple simulation runs, automated trim sweeps, and an interactive routine to design aircraft trajectories for use with the GENHEL pilot model (see Figure 7). The trajectory design tool allows users to specify a set of waypoints in 3-D space, with specified speed, heading, and flight path at each point. Optimal control theory is used to generate a smooth trajectory between waypoints which minimizes a weighted average of acceleration and maneuver time. Once the trajectory is designed the OCM pilot model can autonomously fly the maneuver, while the simulator provides a graphical display. Figure 6 MATLAB-based Graphical User Interface Figure 7 Trajectory Design Graphical User Interface

9 Acoustics Simulation Interface During flight simulation, the aircraft position and attitude, main rotor blade loading, and blade motions can be recorded throughout the maneuver. (The tail rotor data is currently not saved, but could be utilized in future implementations.) The data recording is initiated by a button on the control stick. After a maneuver is completed, the noise at a single observer can be calculated and heard in a playback mode. The aircraft state and main rotor data are then read by the acoustic prediction code PSU-WOPWOP [10-13]. PSU-WOPWOP is based upon the same theoretical basis as the NASA WOPWOP code [14], but can be used to predict the noise of maneuvering rotorcraft with multiple rotors. PSU-WOPWOP has been implemented in Fortran 95 with an object-oriented design. It uses a source-time-dominant algorithm to compute the noise from Farassat s Formulation 1A [15] of the Ffowcs Williams-Hawkings (FW-H) equation [16] at an arbitrary observer location. PSU- WOPWOP also has an option to use a compactchordwise loading model that is well suited to the output of GENHEL i.e., it only requires blade loading as a function of span and rotor azimuth. This approximation is faster than using full surface pressure integration. The combination of the sourcetime-dominant algorithm and the compact chordwise loading noise model enable PSU-WOPWOP to run approximately 50 times faster than a maneuver version of the NASA WOPWOP code (for stationary observers). Although the current implementation of PSU-WOPWOP only works in a playback mode, the speed of PSU-WOPWOP makes the possibility of real-time acoustic prediction and flight dynamics coupling. After calculating the acoustic pressure, PSU- WOPWOP converts the pressure signal into an audio file format. The flight is then played back with the sound from PSU-WOPWOP played over the sound system and the maneuver shown on the plasma screens from the point of view of the observer simultaneously. Cost Analysis Software Costs: All software used in this project fell into one the following categories: 1. Free / Open-Source Software (e.g. FlightGear, Linux) 2. Software developed at PSU or provided to PSU for research purposes (PSU-WOPWOP, GENHEL) 3. Commercially available software for which PSU already owned licenses (e.g. MATLAB, Visual Studio, Windows) Thus, software costs were essentially negligible. Hardware Costs: All hardware components are commodity components readily available on-line or in retail stores. Approximate costs of the major hardware components are listed below. Some of the components were available at educational discounts: Component Approximate Cost FlightLink Controls $2.0 K 3 HDTV Plasma s $18.2 K and Stands 4 LCD s $1.7 K 6 Computers $10.6 K Sound system $2.5 K Cables, power supply, $2.6 K cabinets, accessories Total $37.6 K Table 1 Hardware Costs The overall cost of building the system was kept below $40K, with minimal recurring costs. Furthermore, the system is readily expandable with additional funds. Multi-Disciplinary Research Applications The flight simulation facility is being used for a number of different research project at Penn State Rotorcraft Center of Excellence, spanning a number of different disciplines, including flight dynamics, controls, aerodynamics, and acoustics. Advanced Flight Control Design An important application of the facility is in the area of advanced flight control design. The GENHEL code has been modified to allow simulation of an advanced fly-by-wire flight control system. Individual channels of the existing SAS control laws can be disabled and replaced with user-defined control laws. For example, a model-following control law with attitude command / attitude hold (ACAH) response type was developed and tested in the simulator. With the touch of a button on the cyclic stick, the automatic flight control system can be switched between the basic UH-60 limitedauthority SAS to the full-authority model-following controller. This is a powerful method for demonstrating the potential differences in handling characteristics of a FBW controller and for illustrating basic concepts such as ACAH response type. As discussed above, a limitation of the current control hardware is the lack of re-centering or trim capability

10 for the pilot controls. To help mitigate this problem, a software emulation of force trim release has been implemented. When the pilot presses the thumb button on the cyclic stick, the controls are temporarily disabled. The pilot can then re-center the stick and release the button, and the software offsets the stick input so that the neutral position matches the stick position when the button was pressed. Thus, the pilot can trim the aircraft while holding force on the stick and then use button to relieve the stick force. Furthermore, the hat switch on the cyclic stick is programmed to provide small adjustments to the cyclic stick input so it effectively acts as a software emulated beep trim. In the future, a joystick will be integrated with the system to simulate a sidestick control. Some commercially available joysticks have some limited force feedback capability and might eventually be used for research on carefree maneuvering cueing systems [8]. Although, the simulator was found to be effective at testing and demonstrating advanced control laws, its effectiveness for handling qualities analysis may be somewhat limited. The main limitations observed were: 1. The spring gradient, friction, and damping characteristics of the controls were not adjustable and the existing feel characteristics were not necessarily representative of a real aircraft. The system also lacked force trim release as described above. This could be remedied by purchasing better control hardware but would result in significant cost increase. 2. Latencies: Some significant latency was noted in the system for rapid control inputs. The latency is thought to be primarily due to transport delays in the network socket communication between GENHEL and FlightGear. The code is currently being refined to minimize this delay. This might also be solved by using shared memory systems instead of network sockets, but would require significant increase in cost and complexity. Simulation of Shipboard Operations The simulation facility is being used in current research on helicopter shipboard operations. This research investigates the effect of turbulent ship airwakes on the flight dynamics and handling qualities of helicopters operating in the vicinity of the ship. CFD solutions of the ship airwake are integrated with the flight dynamics model to study the impact on pilot workload [9]. Past studies have used the facility primarily as a visualization tool. The aircraft flight path and attitude are calculated offline and then played back in the simulator to see the motion of the aircraft relative to the ship. Modifications are currently under way to allow the ship airwake data interact with the simulation during real-time flight. The networking capability of the facility will be helpful in this implementation, because the CFD solutions can be calculated and stored on separate computers and then relayed to the flight model via network socket communication. The CFD databases of time-varying airwake require enormous disk storage, and the simulation will need to constantly access this data in real-time. By installing the database on a separate machine, the real-time capability of the simulator will be preserved. Acoustics Simulation of Maneuvering Flight The acoustic simulation system has been designed to predict and play the noise from of a rotorcraft, initially in a playback mode, but eventually in real time [10]. The playback mode starts with a simulated flight, which could be flown by either a pilot or a computer model. During the flight simulation, aircraft position, attitude, blade loading, and blade motion are all recorded. These quantities are provided as input to the PSU-WOPWOP noise prediction code to predict the rotor noise during the flight. The acoustic pressure output from PSU-WOPWOP is then converted into an audio file format and played back over a high-fidelity audio subsystem of the flight simulator. This simulation will represent the noise heard by an observer at a fixed position on the ground. The initial acoustic prediction will focus on low frequency rotor noise. The hardware is capable of surround sound, which can be utilized through noise computations for each of the separate speakers. In the future it is planned to develop a real-time noise prediction capability; therefore, the simulation hardware has been developed for that task. In realtime noise simulation, the pilot will be able to hear or monitor the noise the rotorcraft is radiating on a particular observer location. This information will provide feedback, which will enable the pilot to adjust the flight controls to minimize the noise for a noise sensitive area on the ground. Directional acoustic predictions (surround sound) require several noise calculations to provide the directionality; hence, they are not planned for initial real-time noise prediction. Integration of Free Wake Model Free wake models have proven to be an accurate means for modeling the inflow dynamics of helicopter rotors. Current simulation models primarily use finite-state wake models in order to run in real-time. However, recent advances have demonstrated the potential for using free wake models in real-time simulation [11]. Free wake representation of the main rotor wake has the potential of solving the so-called

11 off-axis coupling discrepancy in current blade element simulations of rotorcraft, and it can also be used to model the complex interactions of the main rotor wake and the empennage [12]. The CHARM free wake model has been integrated with the GENHEL simulation model. Preliminary results of this model were presented in reference 19. The wake model can potentially increase the fidelity of the simulation, and provide accurate model of rotor tail interaction without empirical correction factors. A visualization tool can be used to animate the rotor wake vortices in real-time as the aircraft is maneuvered, allowing researchers to better understand the behavior of the rotor wake in maneuvering flight. The CHARM module has a number of input parameters that can be adjusted to adjust the level accuracy and speed of execution. The module can run in real-time with certain options or run with more fidelity with other options. Currently, a number of different variations in the input parameters are being analyzed to study the trade-off between fidelity and real-time performance. Eventually, the CHARM module will run on a separate node in parallel to the main GENHEL module. This would greatly increase speed of execution and allow real-time operation with a more sophisticated wake. Conclusions Overall, the simulation facility met the prescribed objectives. A real-time rotorcraft simulation suitable for university based research was developed within relatively restrictive cost constraints. Currently, the simulator has some limitations in it effectiveness for handling qualities analysis due to issues with control inceptor feel characteristics and latencies. These limitations could be addressed with some upgrades to the current equipment, but the facility was not intended for true handling qualities analysis. Instead, the system has proven to be quite effective tool engineering research applications. The simulator can be used for flight path visualization and coupled acoustics / flight dynamics simulation. The system is also quite effective for flight control design and analysis, and for simulation model development. The greatest potential for this facility lies in its expandability. New functionality can be achieved by tying different nodes into the cluster. For example, adding a free wake node or ship airwake node will expand the modeling capability of the system while maintaining real-time performance. The availability of free open-source software was found to be essential for this project. Inexpensive commercially sold software was found to be too restrictive for our advanced applications. On the other hand, more professional grade rotorcraft simulation software was prohibitively expensive. FlightGear is free software developed by a community of developers working in their spare time, but it is nonetheless a powerful high end simulation tool. The main difficulty is the lack of documentation for advanced features of the software. But the fact that the code is open-source maximizes its flexibility and thus it is an effective tool if experienced programmers are available. The flexibility coupled with the fact that it is free makes it ideal for universities or small R&D businesses. References 1. Padfield, G.D., White, M.D., Flight Simulation in Academia: HELIFLIGHT in Its First Year of Operation, The Challenge of Realistic Rotorcraft Simulation RAeS Conference, London, United Kingdom, November Mansur, M.H., Frye, M., Mettler, B., and Montegut, M., Rapid Prototyping and Evaluation of Control Systems Designs for Manned and Unmanned Applications, American Helicopter Society 56 th Annual Forum, Virginia Beach, VA, May Jeram, G.J., Open Design for Helicopter Active Systems, American Helicopter Society 58 th Annual Forum, Montreal, Canada, June Redkoles, P., Distributed Flight Simulation Architectures Using a PC/Linux Cluster, American Helicopter Society 59 th Annual Forum, Phoenix, AZ, May Perry, A.R. and Olson, C. "FlightGear from History to Future", LinuxTag 2001, Stuttgart, Germany, July Deters, R.W., Dimlock, G.A., Selig, M.S., Icing Encounter Flight Simulator with an Integrated Smart Icing System, AIAA Modeling and Simulation Technologies Conference and Exhibit, Monterey, CA, Aug. 5-8, Howlett, J., UH-60A BLACK HAWK Engineering Simulation Program: Volume I Mathematical Model, NASA CR , USAAVSCOM TR 89-A-001, September Sahani, N.A., Horn, J.F., Jeram, G., and Prasad, J.V.R. Hub Moment Limit Protection Using Neural Network Prediction, American Helicopter Society 60 th Annual Forum, Baltimore, Maryland, June Lee, D, Horn, J.F., Sezer-Uzol, N., and Long, L.N., Simulation of Pilot Control Activity During Helicopter Shipboard Operations,

12 Proceedings of the AIAA Atmospheric Flight Mechanics Conference, Austin, TX, August 9-11, Brentner, K.S., Lopes, L., Chen, H., and Horn, J.F., Near Real-Time Simulation of Rotorcraft Acoustics and Flight Dynamics, Proceedings of the American Helicopter Society 59 th Annual Forum, Phoenix, AZ, May Brentner, K. S., Bres, G. A., Perez, G. and Jones, H. E. (2002). Maneuvering Rotorcraft Noise Prediction: A New Code for a New Problem. AHS Aerodynamics, Acoustics, and Test and Evaluation Technical Specialists Meeting, San Francisco, CA. 12. Brentner, K. S., Perez, G., Bres, G. and Jones, H. E. (2002). Toward a Better Understanding of Maneuvering Rotorcraft Noise. AHS 58 th Annual Forum, Montreal, Quebec, Canada. 13. Chen, H., Brentner, K. S., Lopes, L. V., Horn, J, F (2004) A Study of Rotorcraft Noise Prediction in Maneuvering Flight, AIAA 42 nd Annual Aerospace Meeting and Exhibit, Reno, NV. 14. Brentner, K. S., Prediction of Helicopter Discrete Frequency Rotor Noise A Computer Program Incorporating Realistic Blade Motions and Advanced Formulation, NASA TM 87721, October Farrasat, F. and Succi, G. P., The Prediction of Helicopter Discrete Frequency Noise, Vertica, Vol. 8, No 4, 1983, pp Ffowcs Williams, J. E. and Hawkings, D. L., Sound Generation by Turbulence and Surface in Arbitrary Motion, Philosophical Transactions of the Royal Society, London, Series A, Vol. 264, No 1151, May 1969, pp Wachspress, D.A., Quackenbush, T.R., and Boschitsch, A.H., First-Principles Free-Vortex Wake Analysis for Helicopters and Tiltrotors, American Helicopter Society 59 th Annual Forum, Phoenix, AZ, May Spoldi, S., and Ruckel, P., High Fidelity Helicopter Simulation using Free Wake, Lifting Line Trail, and Blade Element Tail Rotor Models, American Helicopter Society 59 th Annual Forum, Phoenix, AZ, May Kothmann, B.D., Lu., Y., DeBrun, E., and Horn, J., Prospective on Rotorcraft Aerodynamic Modeling for Flight Dynamics Applications, American Helicopter Society 4 th Decennial Specialist s Conference on Aeromechanics, San Francisco, CA, January 21-23, Anon., Building GUIs with MATLAB Version 5, The MathWorks, Inc., June 1997.