Although Recommendations 2 and 3 were primarily based on experience with Auto GCAS as implemented on the F-16, similar hypothetical situations could also have occurred with the SUAV implementation. The resultant lessons learned will still have important significance for future Auto GCAS projects.
SUAV Auto GCAS “Common Interface” Module
The SUAV Auto GCAS implemented integrity management checks in several different ways. These methods were heavily influenced by the hardware configuration (refer to figs. 11(a) and 11(b)).
The smartphone hosted all of the Auto GCAS-specific algorithms. The smartphone also hosted a limited set of integrity management checks that were only applied to incoming data from the UI (either the laptop computer or the Gumstix® personal computer). After initial power-up, the smartphone was ready and waiting for incoming data from the UI. The actions taken by the smartphone depended upon the mode state, as discussed in the “SUAV Mode States” section below.
The UI hosted the integrity management checks. When the smartphone was on the ground, these checks were hosted on the UI laptop computer. When the smartphone was on board the aircraft, these checks were hosted on the Gumstix® personal computer.
Regardless of the location of the smartphone, the UI integrity management checks were applied for two sets of incoming data. One set of checks was applied to incoming data from the smartphone. The other set of checks was applied to incoming data from the Piccolo II autopilot (as communicated through the Piccolo II autopilot ground station when the smartphone was on the ground).
27 The three basic types of SUAV Auto GCAS integrity management checks were:
Signal conditioning,
Exception handling, and
Connectivity and throughput checks.
Each type of integrity management check is discussed in the following sections.
Signal Conditioning
Preliminary flight-test data indicated that the noise levels of the Piccolo-II-autopilot-calculated winds and sensed roll rate could skew the performance of the Auto GCAS algorithm if not smoothed. Therefore, an attempt was made to apply moving averages to the relevant outputs from the Piccolo II autopilot.
Those moving averages were applied within the UI software to avoid adding computational load to the smartphone software. When the smartphone was on the ground, the UI smoothing was hosted on the UI laptop computer. When the smartphone was on board the aircraft, the UI smoothing was hosted on the Gumstix® personal computer.
The implementation of the various smoothing algorithms was considered a low priority during the design process for this flight-test demonstration project. The end result was that a moving average was not applied to the wind values as input to the Auto GCAS algorithm, only to some of the wind parameters available in the post-flight data. Therefore, the Auto GCAS avoidance maneuver decisions were made solely on the instantaneous wind values provided as output from the Piccolo II autopilot.
A moving average smoothing algorithm was implemented on the roll rate input as intended. An error was found in the roll rate averaging affecting the data that were used to derive algorithm parameters. The software problem was corrected; however, given a lack of funding and time to re-evaluate and correct the affected algorithm coefficients, the decision was made to simply zero out the roll rate input to the Auto GCAS algorithm because of its status as a secondary parameter.
Based on early flight-test results it was decided that the load factor output from the Piccolo II autopilot did not require smoothing. The load factor noise was typically associated with engine vibration and was at a high enough frequency not to interfere with the Auto GCAS. However, later flights were conducted in a more turbulent environment, in which the load factor variations due to turbulence could easily exceed +/-0.5 g. Because the maximum Auto GCAS command capability was established to emulate a medium-to-large UAV with a 40-deg bank angle limit, the maximum sustained load factor was approximately 1.3 g. That limit placed the entire normal maneuvering envelope of the test aircraft roughly between 1.0 and 1.3 g, which was overshadowed by the turbulence response of +/-0.5 g or greater.
Because the Auto GCAS avoidance maneuver decisions were made solely on the instantaneous load factor values output from the Piccolo II autopilot, the timing of the initiation was particularly susceptible to turbulence effects. In hindsight, it would have been better to also include a smoothing algorithm for the load factor before it was input to the Auto GCAS algorithm in order to minimize the potential for inappropriate activations due to turbulence. Another option would have been to remove the load factor as an input to Auto GCAS because of the poor signal-to-noise ratio.
The various ways to implement and optimize Auto GCAS-related smoothing algorithms is one of the remaining technical issues that warrant additional research to provide future projects with a more solid foundation. Each platform will undoubtedly require some unique smoothing concepts, but there may also be generic smoothing concepts that could apply across multiple parameters on multiple platforms.
28
Recommendation 4 (R4): Future Auto GCAS projects should pay special attention to the input