Table of Contents
Component Placement in Aircraft
The Ardupilot was secured in the fuselage, just under the wings. This was the most accessible location and had the most available space for wiring components to the Ardupilot. The communication antenna is secured to the inner fuselage wall with Velcro. Figure B.1.2 shows the connections that must be made to ArduPilot after each component in installed in the aircraft.
A pitot tube was installed in the right wing, approximately one foot from the center of the plane as recommended by the manufacturer. The GPS unit was originally placed inside the wings, but was ultimately moved to the nose section of the aircraft in order to achieve an unobstructed line-of-sight to the satellites.
For aerial imaging, the GoPro pointed down out of the fuselage through an existing hole towards the back of the main fuselage section (fig. B.1.5). Figure B.1.6 shows the first person CMOS camera location and protective cover. The cover was made of balsa and covered in MonoKote. The protective cover was added to prevent debris from damaging the camera and video transmitter in the event of a rough landing.
Nexstar Mini EP with wings removed in order to access main fuselage for Ardupilot and sensor installation.
ArduPilot Wiring Diagram
Location of Ardupilot and MinimOSD inside fuselage. Both components were secured to aircraft using Velcro. The existing adhesive on the Velcro was not strong enough, so the Velcro was epoxied on to the wall of the fuselage.
Location of pitot tube on right wing. The static and dynamic pressure output was connected to the sensor via silicone tubes that were fed through the wing into the fuselage. The static tube was marked with a red band.
The GoPro Hero3 was mounted inside the rear of the main fuselage. It was mounted on a small Styrofoam board with a cut out for the lens. The Styrofoam was both for holding the camera in place and reducing shock to the GoPro in the event of an impact. The GoPro was secured to the foam board and the fuselage using a Velcro strap.
Location of FPV camera and protective shield.
1. Wing Fault
A hole was cut in the MonoKote covering an open 2.5 inch by 2.5 inch square section in the wing located next to the aileron servo. A square door was laser cut out of balsa stock. A servo was installed on the door and a cantilevered beam was epoxied in the wing to act as a post for the servo to latch on to. Packing tape was used as a hinge between the trap door and the wing.
2. Rudder Failure
The rudder was cut into two pieces, being sure not to cut along a hinge. A spring pin was epoxied to each of the two rudder halves. A metal pin was soldered to copper wire. The pin needed a close fit in the pins to maintain the rigidity of the rudder when no fault was initiated, but needed enough clearance for it to be removed from the spring pins with a servo. A plastic tube was heated and then bent to form a channel for the copper wire to be fed into the fuselage. The copper wire was then fed through the tube, into the fuselage, and then connected to a servo that was mounted in the tail section of the plane.
3. Access Door
An access door needed to be created on the side of the tail section of the fuselage to enable the installation and removal of the GoPro. The MonoKote was cut away and a door was cut out of balsa stock. Magnets were salvaged from the battery door of the damaged fuselage and glued to the access door as well as the inside of the fuselage. The magnets helped to "lock" the door shut and packaging tape was used as a hinge.
HardwareFigure B.3.1 shows the 30 pin gopro interface bus cable.
Figure B.3.2 shows the EEPROM chip with 0x05 programmed into the first memory address for use with the gopro interface cable. It also shows two of the red level converters needed to translate the 5 V TTL logic levels used on ArduPilot to the 3.3 V logic levels used by gopro.
Figure B.3.3 shows the aileron fault relay. It
goes inline with the aileron servo cable and has a 5 V
trigger line. The trigger drives the base of a transistor
as seen in Figure B.3.4 so it must be driven
with 5 V to enable the servo. When the trigger is pulled
low or left floating, the servo will be disabled.
Figure B.3.3 Fabricated Aileron Fault
Prelude The ArduPilot firmware code is stored in svn at web/public/ArduPlane-2.70. The "trunk" contains the stock ArduPilot version 2.70 code. Several branches of the code are stored under "branches", each containing different features. The branches can be compared against trunk using svn diff in order to see exactly what changes were made to each.
1. Aux_Servos Branch - Fault System Alterations have been made to the ArduPlane firmware in order to implement the desired operations as specified by the Customer Needs.
The firmware was changed to control servos on the auxiliary channels to trigger the faults on UAV. When triggered, the firmware is responsible for moving the servo from the neutral position to the release position where the fault would cause the appropriate section of the UAV to be detached. The positions are determined by fixed PWM values and the release position lasts about two seconds.
2. Fault_Accel Branch - Accelerometer Data Logging An AP_AIC library was added to facilitate logging of analog signals on ArduPilots analog input channels (AIC). Channels 0-2 are already used by airspeed, current and voltage analog sensors, so channels 3-11 are configured for this purpose. The AIC channels can be tested through the mission planner terminal by using the "test" menu and typing "aic". This will continuously read out the values present on the inputs. These readings can also be logged to the on-board flash memory during a flight by going to the "logs" terminal menu and typing "enable AIC".
Anything in the code with "AIC" in the name is custom code related to this system.
Another small feature of this branch can be accessed through the "test->eeprom" terminal menu. The code for this command is contained in test.cpp file where all the other terminal menu code resides. Running the eeprom command will attempt to write the hex value 0x05 into address 0x00 of an eeprom connected to the ArduPilot external I2C bus. The code assumes the eeprom is device is located at address 0xA0 on the I2C bus. This is useful because the GoPro interface bus requires an eeprom to be connected and programmed with this value. An eeprom chip with this procedure done is included with the hardware.
In order to better organize the log files downloaded from the internal flash memory after a flight, a companion perl script was also written called ardu_exctact.pl. It simply reorganizes the data into a columnar format which is easier to work with in a spreadsheet program like excel for plotting purposes. In order to use the script, you will need to have perl installed (see http://www.perl.org/get.html). As an argument the script takes only the filename of a .log file (NOT a .tlog from the telemetry, only .log files from on-board memory).
3. GoPro_Control Branch note that this code is untested.
The GoPro control branch code can be found here, and one can recognize the changes in the code by searching for "P13231" in the comments. The primary changes are made in arduplane.pde (the file where "setup" and "main" loops are located) as well as the addition of the library GPC.h header file and GPC.cpp C++ file. The code for GoPro Control works, but controlling the process from the mission planner GUI was not recognized, mainly for the complication of the C# code which the GUI is programmed in.
See also the hardware section for interface info.
4. Mission Planner/GUI
Adjustments were also made to the Mission Planner software application to reflect the changes made onto the firmware. Under the Flight Data menu, the "Servo" tab was renamed to "Faults". In this tab, the "Low" and "Toggle" buttons have vanished and the "High" button was renamed to "Trigger" for auxiliary channels 5 and 6. Furthermore, the text boxes were disabled to prevent the user from attempting to change the PWM values.