Table of Contents
Test PlansTest plans were written during the final stages of MSD I and the early stages of MSD II. See the following link for a copy of the test plan document.
All tests performed through the design process have been documented in the spreadsheet available below. The spreadsheet includes information on the date/time/place of the testing, the weather conditions (if relevant), the goals going into the test, and the results of the test.
Testing Records Document: Test Records (Downloads an Excel spreadsheet)
1. GPS Test
The GPS accuracy was tested on the ground prior to flight testing. The aircraft was driven around the RIT campus with ArduPilot running. The route was recorded and plotted on a map (Fig. B.2.1). The accuracy of the GPS was verified within 7 feet. This was consistent with the manufacturer specifications.
2. Flight Tests
Multiple flight tests were performed throughout the spring quarter to verify the functionality of the various systems. Flights were needed to validate the performance of the autopilot capabilities, the first-person-video system, and the aerial imagery capabilities. The data from all flight tests along with the logs of the ground test of the autopilot were saved. The "tlog" files can be found by following the log file link below.
Flight Log files: Flight Logs (Must have ArduPilot Mission Planner installed to view the logs)
Link to download Mission Planner: Mission Planner Free Download
Data collection and display was the first feature tested. Figure B.2.2 shows a graph of altitude, airspeed, and ground speed versus time generated in Mission Planner. The altitude is graphed with respect to the left y-axis and the speeds are plotted with respect to the right y-axis. All units are metric. Airspeed and groundspeed are plotted in meters/second and altitude is shown in meters above sea level.
A successful test of the autopilot mode was quite elusive. A failure in the assembly of the aircraft resulting in the destruction of an airframe in the second flight test before auto mode was even engaged. Subsequent flight tests experienced issues obtaining a GPS fix. After this issue was corrected, flight tests of the autopilot system were attempted and failed due to procedural errors made when creating the flight plan and because of communication issues between the groundstation and ArduPilot. When these errors were corrected, another flight test was performed only to have the aircraft crash when under autopilot control due to incorrectly set gains for the autopilot PID controls. The aircraft when into an unstable mode and impacted the ground before control was returned to the pilot.
To view footage taken by the on-board GoPro of the crash in auto mode click the link: Flight Test Crash
On May 17th, 2013, two successful flight tests were achieved. Auto mode successfully navigated two different flight plans consisting of 4 waypoints and a home location.
Besides the validation of proper function of autopilot, these tests also showed that ArduPilot is capable of resuming its mission after being switched to manual mode mid-mission. ArduPilot is also capable of performing its mission without communication with the groundstation. During the second flight test, communication was lost for a period of 10 seconds. During this time, ArduPilot successfully navigated to a waypoint and changed course to the next waypoint before communication with the groundstation was reestablished. Some data was lost when the communication failure occurred. This data was not transmitted to the ground, but could be acquired by downloading the logs stored on ArduPilot if the desired data had been set to be collected. Figures B.2.3 & B.2.4 show a screenshot of Mission Planner while a flight plan was being followed in auto mode. The yellow indicator in each figure points towards the waypoint the aircraft was navigating towards at the time of the screenshot.
Configuration Files: The ArduPilot configuration file that was used for these successful flight tests has been saved and can be downloaded here. The file contains the PID settings and limits on the flight parameters (such as max pitch, roll, etc). This file can be loaded into Mission Planner and used as a starting point for future flight tests.
3. First-Person-Video (FPV) System
The first person video system has proven successful in each of its flight tests. The video quality has been consistently adequate except for some minor interference during one test flight. The heads-up-display functions as expected; no issues have arisen with it. The mounting scheme proved to be successful as well; there was no visible motion of the camera during flight. Figure B.2.5 shows a screenshot of the FPV display while in flight.
At the ground-station, the analog composite video feed is converted to a digital file via WinTV (a video capture and recording device). After the purchase of a current WinTV version the digital video maintained a 1:1 time ratio, whereas the previous version saved the converted video at roughly half-speed playback. A typical file size for a 7 minute duration flight is sub-300Mb. The new version of WinTV solved the file size issue and the playback time issue experienced when using the outdated version of WinTV.
To view footage captured by the FPV system and recorded by the WinTV setup during flight tests at the Imagine RIT festival, click the links below. (Thanks to Phil Nguyen for lending his piloting skills for these tests).
4. Aerial Imagery
Initially, a $30 Mini DV spy camera was investigated for possible use as the aerial imaging system. The image quality was not as high as desired (see fig. B.2.6 below). The GoPro Hero3 was then selected for the application.
Several flight tests with the GoPro in time lapse mode were performed to ensure that the mounting system for the camera kept the camera secured and that the camera’s view was unobstructed. The tests verified that neither of these concerns were a problem.
The following are images taken from three flight tests. The GoPro gave exceptional results, however, there was a fish-eye effect from the wide viewing angle of the lens. These pictures were taken using the GoPro's built in time-lapse mode. Pictures were taken once every five seconds. To view more pictures from each flight test series click here.
Figure B.2.7, Figure B.2.8, & Figure B.2.9 Aerial Imagery via GoPro Hero3
5. Accelerometer Data
Testing of the accelerometers was performed on a shake table to determine if the data obtained could be analyzed to determine the frequency of the vibrations. The test showed that due to the limited sampling rate, the accelerometers can not be used for frequency determination. However, acceleration magnitudes can be obtained. Data acquired from the accelerometers showed them to be accurately reading 1g in the presence of gravity. Figure B.2.10 shows the data accumulated from the shake table test.
The accelerometers were also tested in flight. Figure B.2.11 shows the x, y and z axes of the tail accelerometer during one such flight test. Aliasing continues to be an issue due to low sampling rate, but acceleration magnitudes are accurately captured and are consistent with those taken by the ArduPilot inertial measurement unit. The 4 MB flash memory also proved to be sufficiently large to hold the data logs produced. For 10 minute flight tests, there was enough data storage capacity for all nine channels of accelerometers, along with the logging of the ArduPilot IMU and attitude data. All data sets were logged at the 50 Hz rate.
Notice in Figure B.2.11 the blue data, which represents acceleration in the Z direction flips from +1g to -1g near the very end of the flight. This occurred when the plane flipped upside down after landing.
To view and download the raw data files acquired from the accelerometers during multiple tests, follow the link: Accelerometer Data
6. Seeded Faults
Table-top tests of the seeded faults were performed. The servo was triggered through Mission planner.
1. Wing Fault:
When the fault was initialized in Mission Planner, it was observed that the trap door dropped from the latched position into what would be the airstream. The door could be reset by holding it against the "latch beam" inside the wing and triggering the fault so that the servo arm would clear the beam.
2. Rudder Failure:
When the fault was initialized in Mission Planner, the servo pulled the copper wire connected to the connector pin. The pin was pulled out of the top spring pin releasing the top half of the rudder, allowing it to move freely. The pin could be easily reset once the servo returned to the neutral position.