Proceedings - Rochester Institute of Technologyedge.rit.edu/.../WorkingDocuments/TechnicalPaper_P13231.docx · Web viewThe video system is a CMOS video camera and includes a MinimOSD

Multidisciplinary Senior Design ConferenceKate Gleason College of Engineering

Rochester Institute of TechnologyRochester, New York 14623

Project Number: 13231

UAV GROUND-STATION AND SEEDED FAULT DETECTION

Stephen WessMechanical Engineering

Dennis VegaComputer Engineering

Aurora KiehlMechanical Engineering

Scott NeumanElectrical Engineering

Jeremie SnyderElectrical Engineering

ABSTRACT With the operation of Unmanned Aerial Vehicles (UAVs) expanding to a wider population of users there is

greater need to present data in an intuitive and easily accessible form. There is also a growing need for advanced users of UAVs to monitor the health of the vehicle as it carries out its mission. The UAV Ground Station & Seeded Fault Control project addresses both of these concerns. Using an off-the-shelf radio-controlled (RC) aircraft, a test bed has been developed with the following capabilities: 1) automated flight via GPS waypoints; 2) flight data acquisition and associated telemetry system; 3) video capture and associated telemetry system; 4) aerial imagery; 5) seeded failures; and 6) data storage and display. Built around the use of ArduPilot, an Arduino based, open-source autopilot system, the test bed proved to be capable of following a flight plan of GPS waypoints created on the ground station by a user. The test bed also successfully acquired, stored, and displayed relevant flight data, provided real-time video coupled with flight data to users on the ground, captured aerial imagery, enabled users to initiate seeded faults from the ground, and displayed the fault status to the user.

INTRODUCTION The UAV Ground Station & Seeded Fault Control project is a member of a family of UAV projects under the

guidance of the project customer, Dr. Jason Kolodziej at the Rochester Institute of Technology. Past projects within the family include the design and fabrication of multiple UAV airframes, the development of an aerial imaging payload, and the design of telemetry and control systems.

Given the mixed results of the telemetry and control system projects, the current project took a new direction by implementing a commercial-off-the-shelf (COTS) autopilot, flight data collection, and telemetry system. Rather than implementing the autopilot system on one of the existing, more sophisticated UAV airframes, the system was installed on a ready-to-fly RC aircraft. This aircraft will be a test bed where systems and components can be proven before being integrated on the primary UAV.

The goals of the project were expanded to include the capability for users to initiate faults on-board the UAV while in flight from the ground. This will allow for the future development of health monitoring capabilities. The test bed is designed so that faults represent damage common to a UAV in the field. These faults will not compromise the flight worthiness of the airframe, but will affect the overall performance of the UAV. They are also designed in a manner so that they can be reset upon landing.

Copyright © 2013 Rochester Institute of Technology

Proceedings of the Multidisciplinary Senior Design Conference Page 2

Accelerometers will be installed on the airframe in multiple locations providing data on the effects the seeded failures have on the flight performance of the UAV. These accelerometers act as a crude health monitoring systems that will be developed in subsequent projects.

Another important aspect of the project is data collection and display. Measurements of the aircraft’s roll, pitch, and yaw along with airspeed, altitude, and location data must be collected and be made available to users on the ground in real time. Not only should the data be available, but it should also be presented in such a way that engages the user – for example, graphics or plots rather than numerical tables.

The function tree in Fig. 1 shows the overall scope and goals of the project translate into lower-level requirements.

Figure 1. System Overview

PROCESS & DESIGN

1) System Level: Tables 1 and 2 list the customer needs and resulting specifications the final product must meet. These needs and specifications were relied upon to determine which systems were to be integrated in the product and also provided the criteria by which to weigh various solution options. The list of needs includes the overall system goals along with additional constraints set forth by the customer. The specifications set forth in Table 2 are testable parameters that can be quantified or observed such that at the conclusion of the design process, the final product can be said to meet (or fail to meet) a particular spec, and thus, a particular customer need.

Figure 2 lays out the system architecture generated to meet the customer needs. The architecture lists several specific components that were selected in the early phases of the design process based upon their potential to satisfy the system specifications. The selection process for each of these system components will be discussed in greater detail in subsequent sections.

Table 1. Customer Needs Figure 2. System Architecture

Project P13231

Need #

Importance(9 = most important)

Description

CN1 9 In flight measurement of telemetry dataCN2 9 Displays telemetry data on ground station for user

CN3 9 Automated control of flight path from the ground station

CN4 9 UAV and ground station communicate wirelesslyCN5 3 Manual control of the aircraftCN6 3 Attain reasonable flight times

CN7 3 Ability to initiate a seeded fault from the ground station

CN8 3 Ability to initiate a take image command from the ground station

CN9 3 Detect faults/failures on the aircraft in flightCN10 3 Display fault/failure status on the ground stationCN11 3 Log telemetry dataCN12 3 UAV can be easily transportedCN13 3 Easy to maintain and service the UAVCN14 3 Easy to fly the UAV

CN15 1 Obtain pseudo-real time imagery or video at ground station

Proceedings of the Multi-Disciplinary Senior Design Conference Page 3

Spec # Source Function Specification (Metric) Unit of

MeasureMarginal

ValueIdeal Value Comment

S1 CN1,2 Comm. Telemetry Data Refresh Rate Hz >1 >10 Telemetry data refresh rate for

user observation onlyS2 CN2,3,4 Comm. Range feet 1000 5000 Typical RC aircraft rangeS3 CN1 Telem. GPS location resolution feet -- <10S4 CN1 Telem. Altitude resolution feet -- <10S5 CN1 Telem. Inertial measurements res. degrees -- <2S6 CN1 Telem. Airspeed resolution mph -- <2S7 CN2 Telem. GUI displays flight data Yes/No -- Yes Real-time telem. data disp.

S8 CN3 GUI GUI accepts GPS waypoint commands Yes/No -- Yes Controls flight path through

waypoints

S9 CN5 Control Automated flight controls allow for manual override Yes/No -- Yes Allows pilot take-off/landing

S10 CN6 UAV Minimum flight time min >10 >20

S11 CN7 Control Number of seeded faults Quant. 1 3 Different faults that can be initiated by user

S12 CN7,8 ControlAbility to send simple

commands from ground station to UAV

Yes/No -- Yes

Commands can be initiated separate from standard flight control commands (ex. take

image, initiate fault)S13 CN9 Sensors Fault detection accuracy % -- 100% Detection of seeded faults

S14 CN10 GUI Fault status indicator incorporated in GUI Yes/No -- Yes Visual indication that fault has

been detectedS15 CN11 Logging Data storage MB >1 >10 Telemetry data storageS16 CN12 UAV Wingspan ft <4 <5S17 CN13 UAV Power source type -- BatteryS18 CN14 UAV Wing Type type -- High-wing Greatly improves aircraft stability

S19 CN15 Video On-Screen Display Yes/No -- Yes If video is pursued, telemetry data should be overlaid

S20 CN15 Video Video resolution pixels -- 640x480

S21 CN7 UAV Number of servos controlling each aileron #/aileron -- 1 Allows for control of one aileron

to be disabledTable 2. System Specifications

2) Autopilot System: The commercially available package, ArduPilot, was selected for the autopilot system because it best fulfilled our needs and specs at the lowest cost. Other options considered included writing custom C, MATLAB, or LabVIEW programs, as well as other more sophisticated and expensive commercially available options. ArduPilot is a plug-and-play, open-source system which eliminates the need to create a program from scratch as would be the case if MATLAB or LabVIEW were used. ArduPilot was selected because it would require minimal programming, it included many built in sensors, and it could be easily integrated with additional onboard sensors. Using ArduPilot allowed for less time spent programming an autopilot system and more time in the testing phase, which is critical for a project in which the ability to test is dependent on the weather conditions.

The final product must be open-source. This will allow for features to be added in and modifications to be made to the firmware as needed. Because ArduPilot is open-source and already has a well-developed community, it was the best option for the autopilot system.

In addition to its ease of implementation, ArduPilot was also chosen because of its ability to acquire telemetry data wirelessly, to log flight data, and to switch between autonomous and manual flight. In addition to its ability to fly between waypoints it has a number of modes including manual mode, stabilize mode, and two fly-by-wire modes. ArduPilot also features a built-in 3-axis gyro for measuring roll, pitch, and yaw. The hardware is packaged in such a way that it fits easily in the fuselage area of the relatively small test-bed RC aircraft. Figure 3 shows the hardware installed in the aircraft.

ArduPilot uses a free software application, Mission Planner as its user interface. Mission Planner allows the user to create a flight plan by plotting waypoints on a map made of satellite imagery. The flight plan can be written to the hardware from wirelessly via a telemetry link. In flight, Mission Planner can be used to select the desired flight mode. While in flight, regardless of the flight mode, flight data is transmitted to Mission Planner from ArduPilot and displayed real-time. This allows the user to track roll, pitch, airspeed, altitude, and other measurements simultaneously. Figure 4 shows a screenshot of Mission Planner during a flight.



Figure 3. ArduPilot in Airframe Figure4. Mission Planner

3) First Person Video (FPV) System: The video system is a CMOS video camera and includes a MinimOSD interface. The CMOS video camera is an analog camera, which is necessary for the MinimOSD to display real-time measurements. The video transmitter operates at 5.8GHz and streams to the ground station with the MinimOSD overlay.

The CMOS video camera+3DR video transmitter kit was chosen over other video systems because of its higher resolution, smaller size, and relatively low price. The 5.8 GHz transmitter had the lowest risk of losing signal when the system moves out of line of sight or becomes partially obscured from the receiver at the ground-station. The CMOS camera was easily mounted in the forward section of the plane so as not to obstruct any airflow and protect the camera in the event of a crash landing. The MinimOSD was also incorporated into the system. It was connected between the ArduPilot and the camera. No extra software was required to implement the on screen display in the video feed.

4) Seeded Faults : Three fault initiation systems are rudder failure, aileron failure, and wing section failure. The rudder failure involves using a servo to pull a pin connecting two pieces of the rudder. The aileron failure involves using a relay which, when 5 volts is applied, cuts power from ArduPilot to the aileron. This forces the aircraft to rely on a single aileron for roll control. The wing section failure involves a servo-released spring-loaded mechanism which pushes out part of the wing section.

The faults were chosen by their ease of implementation and relevance to real-world situations (ex. Loss of control surface, gunshot, etc.). Three faults were chosen: 1) rudder failure; 2) loss of aileron control; and 3) hole in lifting surface.

The loss of rudder control is implemented by attaching top and bottom of the rudder by a pin and pulling the pin when the fault is triggered. The rudder was cut in half and spring pins were secured to each half. A metal pin was selected to fit inside the spring pins. It was important to maintain contact between the spring and the pin in order to pass an electrical signal for the detection and to maintain a rigid connection when no fault is being triggered to maintain the use of the rudder control surface. This pin was soldered to a copper wire that was fed through a plastic guide tube into the fuselage. Inside the fuselage, a servo connects to the other end of the copper wire and pulls the wire to release the pin when the rudder failure is triggered. Figure 5 shows the pin and spring design after implementation.

Each aileron is controlled by one signal that is split at a Y-cable. In order to cut the signal to one of the servos without affecting the other a relay circuit needed to be placed between ArduPilot and the servo located on the right wing (after the split in the cable).

The hole in lifting surface is implemented by creating a flap, or “door” in the wing fig. 6. A servo was placed on the door, both to latch on to a beam inside the wing and to give the door enough weight to drop down into the airstream. Generally this flap will remain closed so the performance of the plane will not be affected in flight when the fault is not initiated. However, when the surface fault is triggered a servo arm will move 45 degrees and release the flap which will drop down into the airstream under its own weight.

Project P13231


Figure 5 – Rudder Fault Figure 6. Wing Fault

5) Accelerometer Data Collection and Storage: In order to monitor the health and status of the aircraft against faults, accelerometers are placed at each of the wing tips and in the tail. Placement at these locations creates a larger moment arm from the center of gravity and accentuates any signals the accelerometers may pick up. Ultimately, the intent is for subsequent project iterations to compare this data against the movements expected as a result of control inputs. Any deviations may then indicate some fault has occurred.

In order to improve the amount of data available to future fault detection algorithms, 3-axis accelerometers are used. The accelerometers output a 0 – 3.3 V analog voltage centered at 1.65 V (half the maximum). The 10-bit DAC on-board the ArduPilot microcontroller is used to read these voltages. The DAC is referenced to 5 V, so measurements are limited to 66% of the maximum theoretical resolution. Measurements are performed at approximately 50 Hz across all nine channels and recorded in the 4 MB on-board flash memory. Initial testing shows that despite aliasing issues with higher frequency accelerations, magnitude can still be detected reliably. This may or may not be an issue with future fault detection algorithm development.

6) Aerial Imagery System : The still image camera must have at least 3MP resolution and be remotely triggered through ArduPilot. The pictures do not have to be sent to the ground station, but are allowed to remain on the camera in SD card storage. The two options considered are the GoPro Hero 3 silver edition (11MP) and the Mini DV spy camera (5MP).

The Mini DV spy camera was initially selected for the aerial imaging. This camera was easy to disassemble and modifications for in flight triggering were possible, however the image quality was not as high as anticipated. Ultimately the Go Pro Hero3 was selected because of its versatility and robustness. The GoPro is connected to the ArduPilot using a 3.3v to 5v converter cable. A correct sequence of toggling highs and lows on the GoPro bus ID

pins trigger the camera to take a picture. This is accomplished by a custom program added to ArduPilot. Time lapse programs on the Hero3 were an added benefit if the user did not want to trigger the camera through the ArduPilot software.

Figure 7. Still Image from GoPro Hero 3 Silver Edition Figure 8: Pin Diagram for Connecting GoPro & ArduPilot

7) RC Aircraft: The RC aircraft selected to act as the test for each of the systems is the Hobbico Nexstar Mini EP (fig. 9&10) because it is large enough to house ArduPilot along with all other components and is relatively inexpensive. It is constructed from balsa wood so it was easier to modify and integrate the seeded faults, as compared to a foam aircraft. The battery used to power the aircraft is an 11.1V 2200mAh Turnigy LiPo battery. In order to ensure our aircraft can fly the entire mission duration of 10 minutes, the battery life divided by the current draw should exceed 10 minutes. Since the bulk of current draw is due to the motor (~10A maximum) compared to the rest of the components (~100mA) one can see the max flight time is 2200/10000 hours or 13.2 minutes. This means our aircraft should meet its goal of an ideal flight time of 10 minutes.



Figure 9. Hobbico Nexstar Mini EP Figure 10. ArduPilot in Mini EP

The lift for the Nexstar Mini EP was calculated for a range of airspeeds at various angles of attack using Eq. (1) assuming the coefficient of lift was linearly related to the angle of attack for small angles as in Eq. (2). This was used as an approximation for the weight that the airplane would be able to carry and sustain flight. Subtracting the weight of the aircraft then yielded the payload capacity. The payload capacity calculated would serve as an upper bound for the total weight of the system components that would be added to the aircraft. In examining fig. 11, the lift was calculated to be between 1.5 and 2.25 pounds for lower airspeeds. Through benchmarking, it was determined that the Mini EP operated up to 35-40 MPH and could lift approximately 3.0 pounds. For this project it was decided to keep the overall system weight below 2.5-3.0 pounds. The final weight is roughly 2.8 pounds.

L=12¿CL∗ρ∗V 2∗A (1)

CL=2∗π∗α (2)

Figure 11. Lift versus Airspeed

RESULTS AND DISCUSSION

1) Autopilot System: ArduPilot has been tested using three methods: computer simulation, flight testing, and on-the-ground data collection.

The ArduPilot was simulated using a hardware-in-the-loop technique involving the ArduPilot hardware and a mathematical model of a UAV. Using the flight simulator, X-Plane, for the UAV model, the ArduPilot has demonstrated the capabilities of different flight modes, data acquisition, and GPS tracking. During the simulation, the UAV model was flown in a virtual airport which provided GPS coordinates. Also, there were flight measurements being provided such as altitude, groundspeed, roll, and pitch when the UAV was being flown or on the ground. ArduPilot would then record all the data onto the on-board memory and through the telemetry link as if a genuine flight was occurring. The simulation verified that ArduPilot fulfilled all the requirements which allowed us to proceed with using the hardware on the chosen UAV.

Our on-the-ground tests proved that ArduPilot is capable of meeting specifications on the data acquisition and display systems. Measurements for airspeed, airframe orientation, and location satisfy their respective data resolution requirements. The ground test data has shown that the onboard sensors are sufficient in terms of accuracy and that the GPS location does meet the specification that it must be accurate within 10ft (it has shown to be

Project P13231


consistent accurate within 7ft). Testing also confirmed that data is collected at 50Hz (greater than the specified 10Hz). Not only is the data logged at a rate higher than specified, it is also refreshed at the ground station at a rate close to 1 Hz, which is the minimum required data refresh rate found in the specifications.

Flight testing has been performed to evaluate the performance of the automated flight mode and related requirements. The Mission Planner has been successfully used to enter waypoints on a map and create a flight plan, which meets one the most important customer needs and subsequent spec. The system also demonstrated its capability to easily transfer between automated flight and manual control, which is another specification. Takeoffs have been consistently performed by the pilot with control transferred to the autopilot once airborne. The autopilot system has also been toggled between manual and automatic control multiple time while in flight without issue.

At the time of the writing of this paper, the automated flight mode was not functioning as desired. During two flight tests, the aircraft made no attempt to follow the flight plan. After investigating the problem, it was determined that the primary cause was poor satellite reception, causing the GPS unit to lose satellite fix and thus, leaving the autopilot unable to fly to the desired waypoints. Modifications were made to the mounting location of the GPS unit. It was moved from under the wings in the fuselage area and mounted on the top side of the aircraft’s nose. This gave the unit’s antenna an unobstructed line of sight to the satellites. Subsequent testing with this new configuration showed that the GPS unit was maintaining a satellite fix. However, this correction did not entirely solve the problem with the automated flight mode. Additional flight testing showed that while the aircraft was in automated flight mode, it was attempting to navigate to the waypoints but experiencing difficulties. In an attempt to correct this issue, alterations have been made to the built in PID control scheme for the control surfaces. At the time of the writing of this paper, these adjustments have not yet been tested. However, because ArduPilot has been proven capable in the past of following a flight plan (in an airframe not associated with the UAV ground-station project), it is expected that this issue will be resolved.

Other than the issues with the automated flight mode, ArduPilot has performed as expected in its other operational modes. Return to launch (RTL) mode performed as expected upon testing. When initiated, the aircraft returned to its set home location and circled overhead. Furthermore, stabilize mode has also been verified to be functioning properly.

2) 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. 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.

3) Accelerometer Data Collection and Storage: The accelerometer system has produced good initial results. Figure 12 shows the x, y and z axes of the tail accelerometer during a 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 room for all nine channels of accelerometers, along with logging of ArduPilot IMU and attitude data. All data sets were logged at the same 50 Hz rate.



Figure 12. Accelerometer Flight Data4) Seeded Faults: The seeded faults have been implemented by connecting a servo to a surface of the UAV

which has been fabricated to detach upon force input. Through the firmware and the software application, controlling servos involves changing the PWM signal on the auxiliary channels. This causes the servo to move from a neutral position to a release position where enough force is being applied to disengage the surface from the UAV. Mission Planner is responsible for sending the command to initiate the fault while ArduPilot responds to the command by switching the PWM signal of the servo to its release position. The faults currently implemented are on the wing and rudder of the UAV.

Both the wing fault and the rudder fault have been tested on the ground. The wing failure successfully initiates with a command from Mission Planner and can easily be reset. The rudder failure has also been tested and demonstrated successful operation. However, the rudder failure initiation sequence was not implemented in ArduPilot at the time of the writing of this paper and is thus unverified. The open/closed circuit fault detection method has been tested on the ground with a multi-meter. This test verified that an electrical path is created and maintained when the faults have not been initiated and that the path is indeed broken when the faults are seeded. This detection process was in the implementation stage during the writing of this paper and not yet tested in conjunction with ArduPilot.

5) Aerial Imagery System : The aerial imagery system consisting of a GoPro Hero3 integrated with ArduPilot was only partially tested at the time this paper was written. 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 integration of the GoPro with ArduPilot was scheduled to be tested in the day after the writing of this paper. For testing the GoPro system, after getting the code to compile successfully on Arduino Sketch, The GoPro bus connector and ArduPilot’s GPIO pins are soldered together and the code is run in order to take a picture when prompted.

CONCLUSIONS AND RECOMMENDATIONSThe UAV ground-station project has successfully resulted in providing a test bed for proving and testing

systems prior to these systems being integrated on the final product UAV. The various systems incorporated in the design have been demonstrated to satisfy the needs of the customer (or will have been after the publication of this paper). The following goals have been demonstrated by the final product: 1) seeded faults can be initiated on an airframe in a non-destructive, resettable manner; 2) ArduPilot is a capable autopilot for navigation via GPS waypoints; 3) data can be collected, logged, and transmitted to the ground in flight; and 4) aerial imagery can be obtained remotely.

Additional testing time was desired, as delays in the design and build process somewhat reduced our available testing time. As a result, some of the systems were unproven to some degree at the time of the writing of this paper.

As the project moves forward, it is recommended that if the test-bed is expected to undergo significant use and testing, a larger airframe should be purchased. This is because the current payload is the maximum weight the Nexstar Mini EP can carry. A larger airframe will also reduce the setup/teardown time for tests that were present with the Mini EP due to its tight spaces and little room for working.

Project P13231


REFERENCES [1] "Home - Ardupilot-mega - Official ArduPlane Repository - Google Project Hosting." Home - Ardupilot-mega -

Official ArduPlane Repository - Google Project Hosting. N.p., n.d. Web. Winter 2012/2013..

ACKNOWLEDGMENTS The authors would like to extend special thanks to Phil Nguyen for volunteering his time to fill the role of

project test pilot. The authors would also like to thank the team guide, Dr. Kolodziej. The project was funded by previous contributions from Impact Technologies.
