Development of an OpenGL stall recovery system in a restricted-resource boeing 737 simulator with external data feed for flight testing

The Trajectory Recovery System (TRS) is a stall recovery avionic developed at Florida Tech that provides a visual reference (a target) for a pilot to follow during a stall. The TRS is a redesigned Primary Flight Display (PFD) that replaces the common PFD only when the aircraft is stalling. This paper covers the software development of the TRS, including the integration into a Boeing 737-800 simulator for flight testing, and the way data is extrapolated for analysis. In the TRS view, a pilot doesn't see altitude, heading and speed gauges; instead, there is a target-looking object that moves around based on the TRS logic and guides pilot's pitch, roll, and throttle to recover from a near stall situation. The TRS PFD is implemented in Angel2D, a layer on top of the GL with simplified interface and 2D oriented functionality. It interfaces a Prepar3D simulator via SimConnect, and supplies the data to the lab software via a TCP socket. The PFD is implemented in C++ without code management and compiled into an executable using configuration pre-set by the Angel2D framework. The executable is then launched on the simulator and layered on top of the existing PFD, and it utilizes stock SimConnect library configuration on the simulator to connect. The TRS features additional capabilities like a console, which allows the user to have additional controls over the runtime variables for various experiments. It is also implemented using a modular approach, separating the decision making process from OpenGL interaction to provide maximum portability of the code for alternative implementations. The testing of the TRS demonstrated excellent performance given CPU constraints of the execution environment through the utilization of predefined bitmaps. The modularity of the system permits usage with any simulator and data recording software with minimal code changes. The Core base, on the other hand, is really restrictive due to the Angel2D solution, and cannot be easily transported to other devices. Such drawback is a result of inconsistent runtimes and compilers across the SDKs throughout the system.