Table of Contents
Final Project StatusThe table below lays out the overarching goals of the projects, and identifies those that were successfully met and those that were not.
|Completed Actions||Incomplete Actions|
|Wing & Rudder Fault Seeding||Aileron Fault Seeding|
|GoPro Mounting Scheme||Fault Detection|
|Flight Data Acquisition||Integrated Control of GoPro|
|Accelerometer Data Logging|
|FPV System Integration|
Figure M.1.1 reviews the specification set during MSD I and indicates which specifications were met, which were unverified, and which were unmet.
Fault SeedingThe fault for the aileron has to be implemented in the firmware. The relay circuit allows for one of the ailerons to be disabled without disabling the other one. The firmware has to be responsible for disconnecting the servo from the PWM signal to deny the user from controlling the aileron.
Fault DetectionThe fault detection system should be able to detect a change in a HIGH or LOW value when the fault is triggered (e.g. the relay circuit on the wing fault). These values should be connected to the I/O pins as the PWM ports will give unreliable results. There is existing code within the firmware that uses the terminal in test mode to output the PWM values of the channels. Channel 8's value has been replaced with a value being detected from I/O pin 3 to determine if this change in value can be detected. Therefore, this code has not been tested to verify functionality.
Once this changed has been detected, the software application must be informed that a fault has been triggered. Using the MAVLINK protocol, a packet with the necessary information has to be sent from the firmware so that the application can process the packet. Once processed, the application will display to the user that a fault has been initiated by displaying a visually appealing warning.
Integrated Control of GoProThe GoPro Camera should be able to be remotely triggered to take pictures aboard the aircraft from the ground station. This has been accomplished using ardupilot before by other RC aircraft enthusiasts and our design is largely based off the scheme they've come up with. The primary source for our implementation of GoPro-Arduino control can be found here.
Figure M.4.1 shows the level converters, and EEPROM needed to control the GoPro. The level converters are needed because GoPro is a 3.3V device and Ardupilot is a 5V device. The EEPROM is needed because a memory device with 0x05 should be read by GoPro at the first memory location in order to enable the GoPro bus. The EEPROM has already had 0x05 written to the first register, and the level converter documentation can be found here. See also the fault_accel code branch which contains a test routine for writing 0x05 to the first register of an eeprom on the ArduPlane I2C bus. It can be found by going to the "test" and then "eeprom" terminal menus in the MissionPlanner GUI when connected to ArduPlane over USB.
Figure M.4.2 shows the cable to connect to the GoPro breakout bus. The pin numbering can be found here.
The GoPro branch code can be found here. The file Arduplane.pde is where the main arduplane program is written and some pages have been made. To view these changes simply locate (ctrl+f) the word "P13231" in the comments to view the changes made. In addition to this, libraries 'GPC.h' and 'GPC.cpp' (GPC standing for GoPro Control) can be found in the libraries folder and are instrumental in the functionality of the remote triggering. Unfortunately, adding this functionality to the GUI proved more difficult than otherwise expected and will have to be incorporated by a future team. Any further questions regarding GoPro remote triggering can be sent to firstname.lastname@example.org