Embedded Files
Till date, one of the key challenges in rotorcraft flight simulators is the need to preserve sufficient accuracy in the underlying math model while getting the analysis to run in real-time. Owing to the interdependent nature of body motion, blade motions and wake characteristics, most math models have to be stripped down to the bare essentials to execute quickly and give a realistic feel to the simulator. However, the same simplifications that allow the code to run faster also introduce errors. The end result is that the helicopter simulator experience doesn't feel *real* enough to mimic the actual vehicle. For complicated math models, this trade-off between runtime speed and accuracy requires a delicate balancing act on the part of the simulation engineer. So long as computational complexity of the problem exceeds current capacity (a combination of cache levels and processor speed), real-time simulation of the elastic blade dynamics using single-threaded applications is difficult to achieve. The graph below shows the historical trends for transistor count and clock speed - the determining factors for code execution speed.
CPU Statistics (1970-2010) from Intel, Wikipedia.
Core clock speed stagnates from 2003 onwards due to heat dissipation constraints
The picture above shows four trend lines for the evolution of CPU manufacturing. The top three lines show transistor count, core clock speed and power required to run and cool the CPU. Consistent with the famous observation known as Moore's law, transistor count continues to increase exponentially (green line). However, clock speed (blue line) stagnated at about 3 GHz around 2003. As micro-manufacturing standards improved, transistor heat dissipation became a limiting constraint for deciding core clock speeds. To continue delivering performance improvements over the years, manufacturers switched focus to multi-core CPUs with approximately the same clock speed per core.
CPU performance adjusted for parallel processing.
Slope change at 2003 indicates advent of multi-core manufacturing
The graph above shows the evolution of computing performance adjusted for parallel processing. Up to 2003, a 64% increase in core clock speed per year was enabled by micro-manufacturing. After 2003, the continued growth in performance improvements at 21% per year was enabled by parallel computing.
To avoid compromising the accuracy of a real-time helicopter simulation, I adapted numerical algorithms specific to helicopter flight to use parallel computing paradigms and realize faster simulations without accuracy compromises. These efforts are documented in a recent publication.
Using a combination of algorithmic improvements, serial optimization and load-balanced parallelization techniques, I demonstrated
24x speed-up for trim analysis (performance and vibration in steady flight)
88x speed-up for transient flight analysis (free-flight response to pilot controls)
With these massive improvements enabled by parallel computing and selective code optimization, comprehensive analysis with flap-lag-torsion dynamics can be used as the flight dynamics engine for a helicopter simulator. Usually, only rigid blades or limited degrees of freedom are used to simulate free-flight response to pilot controls. However, the order-of-magnitude improvements made allow me to use the dynamics without any simplifications or tweaks for performance, vibration and flight simulation. So I did that too.
Python framework to integrate low-level comprehensive analysis with pilot interface
Using a modern Python-Fortran90 interface, I auto-generated Python APIs to the driving Fortran routines for time marching. Using interfaces to X-plane developed by NASA Glen and freely available joystick drivers, the entire simulation is integrated with a Python framework shown above. By turning "off" X-plane's dynamics, the comprehensive analysis is used as the flight dynamics and rotor dynamics engine to simulate helicopter and blade response to pilot controls. Positions and orientations from the analysis are fed to X-plane as prescribed motions, and display updates are automatically performed in X-plane.
CAD models of all vehicles concerned are built in Blender and imported into X-plane. The final output looks no different from what an X-plane simulation looks like, but the underlying dynamics are under the full control of the rotorcraft analyst. Some example helicopters in X-plane are shown below.
View from pilot seat, looking straight
The time delay for acquiring pilot input, updating the display and other communication overhead allows for up to 300Hz update depending on the time required for the vehicle position update.
Google Sites
Report abuse