Data for HIL simulation is collected in the same manner as the data collected during flight testing: the data is logged on-board during the simulation, and downloaded later to be parsed and analyzed. The parsing and analysis process makes use of the FLOC APM Log File Parser GUI, shown in Figure 10.14, and is comprised of basic log parsing scripts, written in Matlab by two Cal Poly Graduate Students, Michael Darling and Adam Chase, as well modifications and additional Matlab scripts to support the needs of formation flight data analysis.
Figure 10.14: FLOC APM Log Parser Tool
The nature of the data contained in the log files made these data sets ideal candidates for conversion in to Matlab Timeseries objects, which provide built-in support for data re-sampling, synchronization, isolation, statistical analysis, and
more. During the process of simulation data analysis, three bugs were discov-ered which ultimately complicated the data synchronization and analysis process.
1)The GPS UTC timestamp, which is used as the primary means to synchronize data between the three UAVs, is improperly converted during transfer from X-Plane to the APM board. Fortunately, the issue was discovered to be a variable overflow problem, which can be corrected upon reading in the logged value. 2)The GPS UTC times are not fully synchronized between each HIL station running sep-arate instances of X-Plane. Therefore, although visually in the same place at the same time, there is an offset in the time recorded in the logfiles. This problem caused a larger headache, requiring each data set to be manually adjusted so that the offset is eliminated. Thankfully, switching all three members into Formation mode at essentially the same time made these offset values easier to identify.
3)While running in real-time with the flight-ready firmware, the timing of the software loops is provided by the digital sensors, which sample data at 200Hz and trigger the 50Hz loop after every fourth sample. Unfortunately, during HIL, the emulated sensor data provided by X-Plane does not stream in at a constant rate, causing log file entries that are sampled irregularly. This irregular sample rate is corrected with the robust re-sampling method built into the Timeseries objects, using linear interpolation or zero-order holds, depending on the type of data, to re-sample the data so that is represented at the expected rates. With these corrections in place, the HIL simulation data very closely resembles the type and format of data collected during flight testing. For the purpose of anal-ysis and plot generation, the HIL simulation data is re-sampled to provide all of the values at a rate equivalent to 5Hz. Accordingly, error is introduced into the presented data in the form of uncertainty attributed to the data corrections, filtering, reduction, and extrapolation techniques.
11 Flight Testing
Besides the challenge of working with hardware and embedded systems, which generally apply implementation limitations and can be prone to failure, simula-tion is often preferred over flight test demonstrasimula-tion in academia due to the amount of risk involved in these tests and the organization required for success.
11.48 Requirements
Flight test demonstration of not just one but multiple UAVs must have clear test requirements defined in order to achieve success. References [49] and [89]
provide valuable insight and suggestions for flight testing requirements and pro-cedures, which have been incorporated in to this work. Many of the requirements shown in Figure 11.1 are straight-forward. However, in some cases, a brief dis-cussion will provide greater clarity with respect to their necessity.
In terms of hardware requirements, the need for data collection and in-flight monitoring is self-evident. However, as suggested by reference [49], data should be logged in two forms: On-board and through a telemetry link. This adds redundancy to the data collection process, ensuring data is protected against corruption or loss. Required support equipment is also listed under hardware, and could include a power supply for the ground control station and battery charger, as well as any equipment needed to take relevant measurements, such as a weight scale, multi-meter, etc. The software requirements are driven by a need for an interface to monitor multiple UAVs all at once and be able to modify parameters in flight for each UAV. Additionally, for flight tests which utilize the concept of “virtual leadership”, a portable HIL simulator is required.
Figure 11.1: Flow-down for formation flight testing requirements
138
One of the most significant differences between flight test demonstration and simulation demonstration, from an operational standpoint, is the personnel re-quirement for flight testing. For testing N UAVs, a minimum of 2N + 1 people are required to support the test: N pilots, N support members, and a test man-ager. To fully document the test with photos and video, more support personnel is required as well. Another concern that does not surface in simulation-based studies is the requirement for a suitable test environment, which includes test field location, openness, and liability coverage. Good weather is another important re-quirement due to the disproportionate effect that atmospheric disturbances have on small UAVs compared to larger aircraft.
Lastly, documentation requirements ensure the proper controls are in place, maximizing the opportunity for success. Other aspects of documentation include the observations, audio recordings, photographs, and video that gives some con-text to the analysis and presentation of results.