DESIGN OF A SCHWEIZER 1-26 FLIGHT SIMULATOR

Transcription

1 Multi-Disciplinary Engineering Design Conference Kate Gleason College of Engineering Rochester Institute of Technology Rochester, New York Project Number: DESIGN OF A SCHWEIZER 1-26 FLIGHT SIMULATOR Kara Mather Ryan Stoddard Brittany Soracco Jonah Williams ABSTRACT This document discusses the design, implementation, and evaluation of a Schweizer 1-26 glider simulator. The simulator was based on a tripod motion platform and supported limited heave, roll, and pitch accelerations in response to pilot inputs. The simulator used the FlightGear open-source project to provide a visual display for pilot control. The completed simulator was shown to provide a believable flight experience and was installed as a museum exhibit demonstrating glider flight. INTRODUCTION The National Soaring Museum sponsored a multidisciplinary senior design project at the Rochester Institute of Technology in order to produce a motion capable flight simulator which would give museum visitors an accurate sensation of flight in a Schweizer 1-26 glider. The RIT student design team was tasked with developing a system which would accurately reproduce the flight performance of a 1-26 and provide the sensation of glider flight to museum visitors. The final simulator was to exceed the capabilities of any of the glider simulations or exhibits currently available at the museum and was intended to become a major element of the museum's Schweizer exhibit. This project was motivated by a donation to the National Soaring Museum of a prototype tripod motion platform from Sarnicola Simulations Systems. The motion platform was to form the core of the flight simulator allowing a pilot, seated in a 1-26 cockpit, to experience limited accelerations sufficient to emulate flight. With the donation of this platform it became feasible to complete a flight simulator on a budget affordable for the project sponsor. NOMENCLATURE DAC: Digital to Analog Converter GENTEST: A basic program for direct user control of a motion platform. LCD: Liquid Crystal Display OROS FFT: A noise and vibration analysis software package. TCP: Transmission Control Protocol UDP: User Datagram Protocol FlightGear: An open-source flight simulator project. JSBSim: An open-source flight dynamics engine. LinAir: Program for calculating aerodynamic characteristics. Plib: An open-source software library for cross platform game development, used by FlightGear. SimGear: An open-source generic simulation engine, a component of FlightGear. SIMULATING FLIGHT In order to provide an immersive experience for a simulator pilot the flight simulator would have to provide a visual representation of the terrain visible from a glider in flight. Equally importantly the simulator would require a flight dynamics engine capable of calculating the glider's response to control inputs at various speeds and orientations. The design 2005 Rochester Institute of Technology

2 Proceedings of the Multi-Disciplinary Engineering Design Conference Page 2 and development of a full flight dynamics engine or a rendered flight environment was well beyond the resources available for this project. It was therefore of critical importance to select an existing set of products which would provide the features required to implement the project's goals. Initial research by the College of Engineering students suggested that several different products were available which might prove to be suitable. Microsoft Flight Simulator, X-Plane, and FlightGear were all selected as viable candidates due to their visual capabilities, sufficiently advanced flight dynamics, and support for outputting real time aircraft data. In the analysis of each of these design options it was clear that the time required to manage and extend such complex software projects would not allow the engineering team to complete a functional simulator in the 9 month period available. Rather than reduce the feature set of the final design the engineering team elected to expand the scope of the design project and sponsor a second senior design project with RIT's Software Engineering department. This Software Engineering team was tasked with the selection, modification, and maintenance of a flight dynamics engine and software flight simulator appropriate for use in controlling the motion platform. Joint review of the available flight simulators by both teams concluded that FlightGear and the JSBSim flight simulator would be the optimal choice for this project. Both systems were open source projects with active development communities allowing full access to and reasonable documentation of the source code. This was determined to be essential in order to output positional flight data to the motion platform at a reliable frequency. SCHWEIZER 1-26 CONTROLS In order to establish the minimum control set required for the pilot to control the simulation it was first necessary to establish the controls and instrumentation required to fly a 1-26 glider. After conferring with experienced glider pilots it was found that a the simulator would require a minimum of three control inputs; stick, rudder, and dive brakes, and three instrument readouts; altitude, airspeed, and rate of climb. This control set was therefore adopted as a core requirement of the final simulation. In order to maintain the original look and feel of the cockpit controls the original stick and rudder pedals mounted in the 1-26 cockpit were reused. Control cables which formerly linked these inputs to the control surfaces on the wings and tail were mechanically linked to a set of USB joysticks which, in turn, sent input signals to the simulator's computer. The use of commercial joysticks as data acquisition devices proved to be an inexpensive solution which did not depend on any specific vendor. By treating each joystick as a modular input device it was possible to modify or replace joysticks without making any changes to the rest of the system. This allowed the project sponsor to replace failing joysticks easily, extending the lifespan of the simulator. Additionally, the modularity of this design allowed the simulation to be controlled either from the motion platform or from a conventional desktop setup. Figure 1: 1-26 Controls CUSTOMIZING FLIGHTGEAR Initial testing of FlightGear and the related software projects it depends on revealed that the system could not differentiate between multiple joystick devices of the same model. It also revealed that a maximum of two joysticks were supported on Windows operating systems. These restrictions were incompatible with the hardware design for the control inputs. Further analysis of the software indicated that the FlightGear could be readily modified to identify each joystick as a unique device. The original implementation used the device name set in the Windows registry for each joystick as the device's identifier. Multiple joysticks from the same manufacturer would therefore use the same device driver and fail to receive unique identifiers. The input device initialization functions within FlightGear were therefore updated to append a unique suffix to each device's identifier when duplicate devices were encountered. Testing revealed that this modification allowed multiple identical joysticks to provide unique inputs to the software. In order to add support for additional joysticks in a Windows environment it was necessary to update the Plib project's joystick interface. At the time, the current release of Plib included a hard coded limit on the number of joysticks supported on Windows 06003

3 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 3 systems which did not reflect the actual limitations of the underlying operating system. This appeared to be the result of minimal maintenance or development work having been performed on the Windows platform libraries within Plib. The joystick detection and initialization code was therefore updated to query the operating system for the maximum number of joysticks which might be present. On Windows 95 or more recent systems this increased joystick support to 16 unique devices. FLIGHT DYNAMICS MODEL: One of the National Soaring Museum s requirements was that the simulator behaves as close to a Schweizer 1-26 glider as possible. To accomplish this, the flight characteristics of the Schweizer 1-26 had to be defined. These characteristics were necessary to determine what effects a disturbance would have on the aircraft. Figure 2: 1-26 Scale Drawing[3] Anything that forces an aircraft out of a steady state condition is considered a disturbance; such as a gust of wind or a control surface deflection. The aircraft's reaction to a disturbance depends mostly on its geometry and weight. It was critically important to determine how deflections in the control surfaces, a change in the aircraft s geometry, would alter the aircraft's motion. It was hoped that Schweizer Aircraft Corporation could provide much of the necessary aircraft data. Unfortunately, because the Schweizer 1-26 was designed in 1953 and went out of production in 1981 the aircraft stability and control data was no longer available. Instead it was necessary to use the aircraft s weight and geometric data, taken from the scale drawing seen in Fig. 2, to derive an estimate for these values. The data needed for the flight dynamics model was calculated analytically using the computer program LinAir. LinAir, computes the aerodynamic characteristics of multi-element nonplanar, lifting surfaces. LinAir is frequently used in the aerospace industry to obtain a quick look at new designs. LinAir gave excellent estimates of the aircraft stability and control derivatives necessary to create an accurate flight dynamics model. A JSBSim flight model was created using the estimated data from LinAir. The flight performance of this model was then compared to flight performance characteristics taken from the 1-26 flight manual and test flights. Given a known stall speed, sink, roll, and loop rates for the glider and additional subjective feedback from experienced pilots it was possible to adjust the flight dynamics model until it matched a Schweizer Figure 3: LinAir Model, Top View Figure 4: LinAir Model, Side View Copyright 2005 by Rochester Institute of Technology

4 Proceedings of the Multi-Disciplinary Engineering Design Conference Page 4 VISUAL CUEING The realism of a pilot s experience in the simulator was dependent on the presence of various sensory cues provided by the system. The primary interface for the pilot s interaction with the simulation was a visual display rendering the forward view from the simulated glider. The success of desktop computer flight simulations has demonstrated that visual feedback alone is sufficient to provide a reasonable level of immersion in the simulator. As such it was considered essential to provide as accurate and highly detailed a visual display as possible. A projection display system was selected as an ideal mechanism to maximize the display area without adding a significant load to the motion platform. It was calculated that a commercial projector intended for home or office use would be able to provide a 44 inch wide display 55 inches in front of the pilot. This image filled approximately 40 degrees of the pilot s vision. This was a significant improvement over any other feasible display system. Additionally, the accelerations the platform produced during operation were found to be within the safe limits for operation of the projector. The final visual display was found to provide sufficient feedback for pilots to navigate and land the aircraft easily. The Software Engineering team was also able to include many of the landmarks found at the Harris Hill airstrip in the simulation, matching the simulated environment to real world conditions at the final exhibit location. INSTRUMENT DISPLAYS A basic instrument display including a veriometer, altimeter, and air speed indicator was required for a pilot to correctly operate the glider. The instruments for the Schweizer 1-26 simulator were implemented in software and displayed on 3.5 by 5 inch LCD flat panels mounted in the instrument panel. Software was chosen over hardware for several reasons. The first was that it was a cost-effective solution. The LCDs were donated to the project, and commercial replica instruments would have been over $500. With a software solution the only cost to our project was $75 for two video cards. Secondly software offered ease of repair and duplication. A custom hardware implementation of the instruments would have been very difficult for the sponsor to repair or replace. Finally, the software was written to provide ease of extensibility. If in the future more instruments are desired the program could be easily extended to accommodate them. instruments at least 10, but ideally 30 or more, times a second so that the pilot did not see noticeable lag on the instruments. However, FlightGear did not need to receive any response from the instrument program. Additionally, because the data expired very quickly it would not have been productive to have FlightGear retransmit dropped packets. This, combined with no significant penalty for out of order data, meant that the instrument program did not need to acknowledge received packets. Furthermore, the incidence of dropped or lost packets was nonexistent within our system because the transmission and receipt of the message occurred within a single computer. Because of all of these requirements UDP was chosen for instrument data transmission. UDP does not seek to provide order guarantees or transmission reliability, and as a consequence it is a very fast and processor efficient protocol. In order to render the instrument displays the program was required to display graphics on specific monitors and rapidly rotate layered images to update the instrument readouts. The programming language Java was chosen to implement the instruments because of its native UDP support and extensive graphical management capabilities. The graphical element of the project was relatively complicated due to the need to display multiple instrument windows on specific monitors. Image layering and rotation are nontrivial and can be dependent on the hardware platform being used. Java provides libraries that allowed us handle these image manipulations independent from the specific hardware and operating system used. This made the final program flexible, portable and extensible. MOTION CUEING In addition to visual cues, inertial cues were also provided to the simulator pilot in order to enhance the simulation experience. These cues were generated by a 3-degree of freedom motion platform (see Fig. 5). Due to the limitations of the platform, duplicating the orientation of the simulated aircraft was impossible. A more effective approach was to simulate the accelerations felt by the pilot. Accelerations can be directly sensed by the pilot unlike velocities or positions. It was important for the instruments to receive data from FlightGear frequently enough to update the 06003

5 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 5 Figure 5: Motion Platform In order to effectively create the sensation of flight it was important to consider how pilots, and humans in general, sense motion. The vestibular system in the inner ear senses orientation and accelerations. The brain combines the information from the vestibular system with information from the visual system and determines the body s state of motion. If some of the cues from the sensory systems are missing, the brain makes an educated guess. In general, simulators can be very effective if they provide sufficient cues to fool the rider into believing that they are moving in a certain manner. In this case, the visualization system provided information on the orientation of the aircraft but it could not send information to a pilot s inner ear. Motion cuing can provided these signals but had to be implemented carefully. If conflicting signals were provided, the brain could not reconcile the information and as a result the pilot would experience motion sickness. Therefore it was important to provide consistent visual and motion cues. In order to reproduce the accelerations experienced during a glider flight it was necessary to design filters and control system to convert the acceleration data generated by FlightGear into safe displacements of the motion platform. It was critical that the control system not only keep the platform within its safe physical limits but also prevent unexpected or high speed motions which might injure the pilot. A controller card was provided with the platform which outputted position signals to the three actuators and received position feedback from potentiometers linked to each actuator. This card was used as the controller in the new cueing system due to the fact that it was specifically designed for the platform and provided smoothing filters that minimized sharp changes in acceleration. This functionality could not be easily duplicated in software and would not be as reliable as the hardware equivalent. The dynamics of the controller card and platform were characterized in order to aid in the design and simulation process. Open loop frequency response plots were generated for the controller card in OROS FFT Analyzer software. A random multi-sinusoidal signal was inputed into the controller card and the output was measured for each of the three output channels. The software converted time-domain response plots into the frequency domain by performing the Fast Fourier Transform. Sixteen hundred data points were taken at frequencies ranging from 0 Hz to 50 Hz. Bode plots were generated for each channel. These plots were then used to determine the transfer function for the controller card (see Fig. 8). The system character of the platform was also characterized. A non-destructive method could not be found to determine the open loop transfer function of the platform. As a result the closed loop response for the entire motion system (controller card and platform with feedback) was measured. GENTEST was used to generate various heave sinusoidal inputs ranging from 0.4 rad/sec to 15 rad/sec. OROS FFT Analyzer software was used to measure the input voltage sent to the Sarnicola controller card and the output position of the motion platform. A potentiometer was mounted to the platform in order to measure the displacement of the actuators. Twenty seconds of data were taken at a sampling frequency of 50 samples per second. Amplitude, attenuation and phase shift were determined for each forcing frequency and Bode plots were generated from the results (see figure 6). A step response was also measured for the platform (see figure 7). The Single Input, Single Output (SISO) systems tool in Matlab was used to determine the form of the platform transfer function from both the frequency and transient response characteristics. The final system parameters are listed below in Table 1. Figure 6: Closed Loop Bode Plots of Motion System Copyright 2005 by Rochester Institute of Technology

6 Proceedings of the Multi-Disciplinary Engineering Design Conference Page 6 Filtering the acceleration was not enough to provide cues for rapid sequential maneuvers. In order to utilize the full range of motion for the platform it had to be homed after each maneuver. The home position of the platform was defined as the position at one half of full extension of each actuator. This allowed the platform maximum travel in all axes. In order to perform this homing motion a washout filter was used. This filter slowly returned the platform to a home position, slowly enough that the rider did not sense the movement. Figure 7: Step Response of Motion System Figure 8: Block Diagram of Motion System Controller Card Platform K = 24.4 K = 0.87 z = 2.0 z = 127 p = 23.8 p1 = 2.2 p2 = 37.2 Table 1: Platform Transfer Function Parameters Once the platform and controller card system dynamics were characterized, filters could be designed to determine what signals should be sent to each actuator. The platform could not perform extended accelerations due to the physical limits of the actuators. However, since the largest inertial cues resulted from changes in accelerations, simulating the onset of accelerations provided enough information to the pilot to give the feeling of various maneuvers. A first order high pass filter was used to filter out extended accelerations. The basic functionality can be seen in Fig. 9. Figure 9: First Order High Pass Filter The second filter also acted as an integrator, converting acceleration to position. If a washout filter was not used the integration process would have resulted in, at best, a constant velocity and ever increasing position. This would have quickly driven the platform to its physical limits. The washout filter was a second-order low pass filter where the input acceleration was a disturbance to the system. The reference signal was the home position of the platform. The block diagram of both filters can be seen in Fig. 10. The form for both filters was taken from a cuing paper written by the designer of the controller card for the motion platform [1]. Figure 10: Filter Block Diagram [adapted from Fig. 2] Simulations were run in Matlab to test the functionality of the filters for various input scenarios, parameter values, and sampling times. The digital filters were then implemented as finite difference equations in C++. The motion platform could provide inertial cues in the roll, pitch, and heave directions. Experienced pilots were consulted to determine which forces were most prevalent during normal flight. Heave was determined to be the most significant force and as such most of the actuator travel was devoted to providing these cues. Roll was also used to give the pilot a feeling of slip as a result of uncoordinated turns. A turn is uncoordinated if there is an inappropriate amount of rudder applied for a given stick position

7 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 7 The functions took input accelerations in the heave and lateral directions from Flight Gear and converted them to heave and roll cues on the motion platform. Safety limits on actuator position and acceleration were provided by the filter in order to ensure pilot safety and prevent damage to the platform components. Extensive testing was done to adjust the parameters of the filters. Both pilot opinions and recorded data were used to analyze and adjust the cuing performance. Due to the subjective nature of human experiences it was necessary to iteratively refine the filter parameters until pilots would not frequently encounter the limits of the platform s range of motion. Additionally, the filter s response had to be adjusted until its acceleration scaling felt appropriate and the settling time did not introduce a noticeable acceleration. MOTION PLATFORM CONTROL In order to send the output signals generated by the acceleration cueing filter to the motion platform it was necessary to develop a software control module for the platform. It was critical that the control system not only keep the platform within its safe physical limits but also prevent unexpected or high speed motions which might injure the pilot. Basic control of the motion platform was therefore governed by a platform controller software module, implemented as a state machine, on the simulation computer. This controller was responsible for enabling or disabling motion of the platform and returning the platform to safe positions for the pilot to enter or exit the cockpit. Additionally, the controller managed a number of separate threads which handled message passing. The controller provided a TCP and UDP server which received control commands and acceleration data from FlightGear. Every 10 milliseconds the controller updated the output voltages of two DACs, which controlled the platform's position. Additionally the controller's internal state was displayed on a set of LED indicators mounted on the motion platform. This allowed the simulation operator to immediately determine if the motion platform was in a safe state for a pilot to enter or exit the cockpit, or for the operator to approach the platform. RESULTS The final design implemented in the flight simulator and the data flow between components is shown in Fig 11. The flight simulator provided an accurate model of flight in a Schweizer 1-26 glider. Experienced 1-26 pilots demonstrated their ability to fly the simulated aircraft accurately and reported that the motion of the platform improved the quality of the simulation. Additionally, inexperienced glider pilots were able to demonstrate reasonable control of the aircraft and found the motion of the platform intuitive. It was the project sponsor s opinion that the simulator offered a sufficiently accurate experience and that the design would allow it to become a major feature of the National Soaring Museum s collection. Copyright 2005 by Rochester Institute of Technology Figure 11: Dataflow Diagram

8 Proceedings of the Multi-Disciplinary Engineering Design Conference Page 8 ACKNOWLEDGMENTS The 1-26 simulator team would like to thank the following individuals. Norm Smith, Director of Operations of the National Soaring Museum for his sponsorship of this project. Dr. Kevin Kochersberger, from RIT s department of mechanical engineering, for serving as our mentor for this project. Dr. Alan Nye, from RIT s department of mechanical engineering, for serving as the project coordinator. Dave Hathaway, from RIT s department of mechanical engineering, for his assistance during the construction of the project. Ryan Smith, for his advice and for landing safely. Paul Mezzanini, from RIT s department of computer engineering, for his generous donation to the project. Dr. Yorke Brown, for his advice and for sharing his work with us. We would also like to recognize the following group and organizations for their contributions to the project; Sarnicola Simulation Systems, Inc, the FlightGear development team, the JSBSim development team, and the 1-26 Association. Finally we wish to recognize the outstanding accomplishments of the EdgeTime software engineering senior design team; Chris Guy, Zebulon Ford-Reitz, Matt Mullin, Karen Roth, and Stefan Schmid. Their work and dedication to this project have been critical to its success. REFERENCES [1] Brown, Yorke. Cuing Algorithms for Vehicle Simulation. August 5, 1994, pp [2] Brown, Yorke. Cuing Algorithms for Vehicle Simulation. August 5, 1994, pp 4. [3] Lake Elsinore Soaring Club, January [4] 1-26 Association, 126association.org. [5] FlightGear, flightgear.org. [6] SimGear, simgear.org. [7] JSBSim, jsbsim.sourceforge.net [8] Plib, plib.sourceforge.net