Delhi Technological University

2011 AUVSI STUDENT UAS COMPETITION Team UAS DTU Journal Paper

ABSTRACT This paper provides a summary of the Delhi Technological Universitys UAS, ASTRA, designed to meet the objectives of AUVSI student UAS competition. ASTRA (Autonomous Surveying and Terrestrial Reconnaissance Aircraft) is a modified Sig Rascal 110 R/C aircraft controlled by the ArduPilot Mega, an open-source autopilot. Capable of following dynamically changing waypoints, ASTRA provides real time reconnaissance to an Imagery terminal on ground using a gimbal stabilized point and shoot camera. The transmission of captured images takes place on a 2.4GHz secured wireless link. The received images are then processed for actionable intelligence. Modular in design, ASTRA can be brought to flying state in less than 40 minutes. Safety being of paramount importance in all aspects of UAS operations, ASTRA can be controlled by its Mission Control Centre over a 2.4 GHz secured wireless link as a Remotely Piloted Vehicle (RPV) and also by a 2.4 GHz Radio transmitter remote under full manual control. This paper gives a detailed description of ASTRAs system along with the design rationale including the teams objectives in building the system. The paper also describes the UAS flight operations and concludes with a description of the testing that has been performed to show that the mission can be completed safely and successfully.

Delhi Technological University

Table of Contents 1 Introduction .......................................................................................................................................... 3 1.1 Mission Requirements Analysis .................................................................................................... 3 1.2 Systems Engineering Approach..................................................................................................... 3 1.3 Flight Systems Overview ............................................................................................................... 4 2 Systems Design and development ........................................................................................................ 4 2.1 Air Vehicle Design ......................................................................................................................... 4 2.1.1 Overview ............................................................................................................................... 4 2.1.2 Design Approach ................................................................................................................... 5 2.1.3 Airframe ................................................................................................................................ 5 2.1.4 Propulsion ............................................................................................................................. 6 2.1.5 Developmental Tests and Adjustments ................................................................................ 6 2.2 Imagery System Design ................................................................................................................. 7 2.2.1 Overview ............................................................................................................................... 7 2.2.2 Design Approach ................................................................................................................... 7 2.2.3 Acquisition system ................................................................................................................ 8 2.2.4 Image processing .................................................................................................................. 9 2.3 Autopilot ..................................................................................................................................... 10 2.3.1 Overview ............................................................................................................................. 10 2.3.2 Ardu Pilot Mega (APM) ....................................................................................................... 10 2.3.3 Sensors & On Board Peripherals ......................................................................................... 11 2.3.4 Hardware in the Loop Simulation (HILS) ............................................................................. 11 2.3.5 AutoPilot Integration and Testing ....................................................................................... 11 2.3.6 Autopilot Safety Considerations ......................................................................................... 12 2.4 Communications System Design ................................................................................................. 12 2.4.1 Design approach ................................................................................................................. 12 2.4.2 Developmental Tests and Adjustments .............................................................................. 13 2.5 Ground Station ............................................................................................................................ 13 2.5.1 Imagery Terminal ................................................................................................................ 13 2.5.2 Mission Control Centre ....................................................................................................... 14 2.6 Power Systems ............................................................................................................................ 15 2.6.1 Design approach ................................................................................................................. 15 2.7 System Layout ............................................................................................................................. 15 3 Mission Planning ................................................................................................................................. 16 4 Flight Operations................................................................................................................................. 17 4.1 Process Flow-chart ...................................................................................................................... 17 4.2 Flight Crew description ............................................................................................................... 17 4.3 Safety .......................................................................................................................................... 18 5 Safety and Risks Register .................................................................................................................... 18 6 Flight Tests and Evaluation ................................................................................................................. 20 7 Conclusion ........................................................................................................................................... 20 8 Acknowledgement .............................................................................................................................. 20 9 References .......................................................................................................................................... 21

Delhi Technological University

1 Introduction
1.1 Mission Requirements Analysis
The AUVSI student UAS competition simulates a real life mission where ASTRA has to perform autonomously in a hostile territory while providing the ground station operators with suitable intelligence data. Based on the CONOPs, a Key Performance Parameters (KPP) chart was prepared, that was used by the team to identify goals on which further work was to be done once threshold were complete: Characteristic Autonomy and Flight planning Threshold Static Waypoints Objective Dynamically adjustable waypoints, Take-off and Landing, re-adjustable search area. Autonomous character and shape recognition, GPS and orientation mapping. Color identification. 20 minutes(Imagery, recognition and location done in simultaneous real time) Minimum GTOW with least acoustic signature. Manual plus, through GS as RPV for added redundancy. Different networks for each of imagery, manual and auto control.(Improves safety and reliability ) Return Home on link failure and Autonomous landing.

Imagery

Acquisition identification

and

Visual

Mission Time

Aircraft Control Communications

Within 40 minutes (Imagery, recognition and location done at conclusion) Max. GTOW 55 lb Manual (at all times) Different wireless bridges for manual control and MCC

Safety

Failsafe: Spiral Dive

Table 1: Key Performance Parameters for ASTRA

1.2 Systems Engineering Approach

The team followed a structured Systems Engineering approach to face the 2011 SUAS challenge. The design process was divided in 3 major phases: 1. Analysis 2. Preliminary Design 3. Systems Integration and Testing.

In Analysis phase, the team thoroughly studied the shortcomings and failures of previous years system. KPP charts were prepared to direct the improvements in each sub-system. The team allocated their resources and time on the basis of these KPP charts. The Preliminary Design phase involved subsystems integration, after which extensive laboratory testing and field testing was done. The components were required to perform reliably without any failure. This practice proved beneficial later as it facilitated our systems integration effort, due to dependability of our subsystem modules.

Delhi Technological University

The final phase, Systems Integration and Testing, involved putting together all the subsystem modules on one platform, which were then tested in flight. The behavior and performance of the complete system was observed and necessary alterations were made.

1.3 Flight Systems Overview

Payload

Flight Control System

Air Speed Sensor Gimbal Camera Onboard Computer Battery 1 Battery2

GPS

Battery 1

SBC Autopilot Wireless router Wireless Router Rx Flight Servos

2.4 GHz

2.4 GHz

2.4 GHz

TX

Wireless Router

Wireless Router

Imagery Terminal

Mission Control Centre

2
2.1

Systems Design and development

Air Vehicle Design
Overview

2.1.1

The airframe being used this year is SIG RASCAL 110 ARF. It is a fixed wing conventional tail air vehicle with an elliptical wing planform that renders stable flight characteristics. The air vehicles tractor propulsion system constitutes a Hacker A60 22S brushless outrunner motor in conjunction with a 19X8

Delhi Technological University

Nylon propeller. The system is powered by two Thunder Power 5-cell LiPo 8000mAh batteries connected in series which deliver a maximum of 37 volts. The airframe is modified to accommodate the gimbal and camera housing inside the fuselage. The airframe complies with Academy of Model Aeronautics (AMA) National Model Safety code and meets all the requirements of the AUVSI Seafarers Chapter. Parameter Wing Span Empty weight GTOW Propulsion Power Endurance Stall: Cruise: Max Velocity Payload volume Specification 110 inches 10 lbs 18 lbs Hacker A60 22S 19X8 prop 10S Thunder Power LiPo 26 mins 22: 34: 48 KIAS 560 cu-inch Table 2: Specification chart for the Aircraft 2.1.2 Design Approach

The team evaluated its performance in AUVSIs SUAS 2010 and assessed the points of improvement. Since it was decided to make the system autonomous with a commercially available auto-pilot, in contrast to the indigenous system employed in previous years, the avionics volume was anticipated to be compact and simplified, early in the design phase. This gave the independence to opt for a larger payload. To assist the team in autopilot design and development, the airframe needed to have smooth and stable flight characteristics. It was observed during several flight tests last year that the engine powered airframe increased the Man Maintennce Hours per Flight Hour (MMH/FH) and offered vibration issues for the flight control and navigation system. Besides, frequent engine cut-outs and unreliable performance under hot environmental conditions posed a major safety concern. To assist in timely mission-readiness during flight tests, the airframe needed to be repairable in case of hard-impact landings or damages due to strong cross-winds. With the problems thus identified, the team set some Key Performance Parameters specific to competition mission requirements: Parameter Payload Volume Payload Weight Turnaround time per flight Endurance Reparability Objective >300 cu-inch >5 lbs <40 mins >25mins Quick

Table 3: Key Performance Parameters for Aircraft System 2.1.3 Airframe The team considered other available RC aircrafts and after a weighted evaluation, decided to stick with the previously used Sig Rascal 110 airframe. The teams two year experience confirmed its stable aerodynamics for the competition. Stability and control derivatives for this plane were also available in case team requires it for Hardware-in-the-loop-simulation (HILS).

Delhi Technological University

The modified payload bay is placed directly under the wings which are separable and provide greater access to the payload bay and a suitable forward CG position. To accommodate the gimbal, the underbelly of the aircraft has been modified to grant +/- 45 degree pan capability with the fully extended Canon G10 lens. The balsa and hard-wood construction of the airframe provides good reparability. The region around the payload aperture has been reinforced using C-fiber rods epoxied into the semimonocoque ensuring integrity of the payload system. The main and tail landing gear have been reinforced to withstand hard-impact landings on tarmac. The tips of the propeller blades have been painted to increase their visibility. The top, underbelly and the sides have a bright monokote covering to facilitate visibility in the air and in the event of a crash. 2.1.4 Propulsion The team had been using OS 1.60 glow engine for propulsion since 2009. The teams past years experience with engine had been pretty rough, as engines performance was unpredictable especially during elevated temperatures. Further, if the engine stopped in mid-air, the system would require an emergency landing, which also had been a potent reason for crashes. During Analysis Phase, it was decided that in order to accomplish mission objectives within the tasking window of 40 minutes, the airframe should have a quick turnaround time, in case it requires an emergency landing during mission. In view of the above points, it was decided to shift propulsion system from engine to an electric motor.

Figure 1: Hacker A60 mounted on ASTRA

Figure 2: Flight data-log from ESC

A detailed study for selection of appropriate motor and propeller combination was done using MotoCalc. The selected motor was then tested in lab for its thrust values at various speeds. Using a 10S 8000 mAh LiPo battery, the endurance was estimated to be around 26 minutes as average power consumption during actual flights was around 700W. Moreover, motor provides significantly dampened vibrations which aid in Imagery and reduced noise in IMU. 2.1.5 Developmental Tests and Adjustments The selection criteria for the final propeller configuration were based on ground testing in the lab. Three propellers 19X8, 20X8 and 18X10 were tested on the bench under different temperature conditions to plot thrust variation with throttle, maximum and average current draw and endurance. Based on these tests the final configuration chosen was 19X8. Subsequent flight tests have revealed close proximity between the expected and achieved endurances. The expected average endurance is 26 minutes.

Delhi Technological University

The aircraft can be assembled in less than 8 minutes. The empty airframe was tested with ballast weight simulating payloads by first executing a drop-test from a height of 6 inches. Observing the deflections induced in the main landing gear, it was decided to strengthen the duralumin gear with a tensioned cord to limit the bending. In-flight performance was closely observed to ensure structural integrity in the aircrafts entire flight envelope. A deflector plate was attached to the airframe just ahead of the payload aperture to address drag concerns. The aircraft has completed mission objectives at temperatures of 115 deg F on surface and has successfully completed take-offs and landings at cross-winds of 12 knots and gusts of 13 knots. The aircraft can be disintegrated in less than 5 minutes and has a suitable storage volume for transportation.

Figure 3: ASTRA airframe shipment ready

Figure 4: ASTRA airframe flight-ready

2.2 Imagery System Design

2.2.1 Overview The objective of the mission requires the imagery system to autonomously detect scattered targets on the ground in a specified search area. During the flight, our roll stabilized gimbaled camera continuously shoots over-head images. These are then transmitted down to the Imagery Terminal for final processing. The actionable intelligence to be provided would consist of the shape, background color, alphanumeric, alphanumeric color, orientation along with the GPS coordinates of the image.

Figure 5: Imagery system layout

2.2.2 Design Approach Learning from past experiences, a decision was made in favor of capturing few high quality individual images over real-time inferior quality video. This required a high resolution digital camera small enough to be stabilized by a gimbal.

Delhi Technological University

The 2010 system provided VGA quality video at 30 fps using an Axis 207 network camera. Although 30 fps provided a smooth interlaced video, the low resolution of snapshots prohibited digital zoom and it was difficult to even manually recognize targets. To achieve better image stabilization in flight, a survey for a COTS gimbal was done. Since no gimbals met our requirements and budget, a robust in-house gimbal system was designed and tested.

Threshold Characteristic Objective Characteristic High resolution Images at 1 High resolution images at 1image image every 4 seconds per second. Nadir stability at all times. Nadir stability with controllable gimbal. Adjustable Zoom All camera parameters controllable Shape Recognition Real time shape recognition. Color identification in Target Color of both shape and alphanumeric Visual GPS coordinate of Target Real time GPS coordinates Visual Character recognition Real time character recognition Orientation identification GUI for Images

Where we stand. Threshold: 1 image every 3.4 seconds. Threshold

Real time identification GUI with real time recognition and Threshold: Easy to use GUI with identification of images. manual character recognition. Table 4: Key Performance Parameters for Imagery System Type Weight Resolution and Zoom FOV Max Shutter Speed Image Stabilization Compact, Digital Point and Shoot 390 g 14.1 MP at 5x Optical Zoom 45 degrees 1/4000 Optical

Objective: All main camera parameters can be controlled Threshold Threshold: Color of Shape and Alphanumeric can be identified. Threshold Threshold: Provided if picture quality is excellent. orientation Threshold: Manually possible

2.2.3 Acquisition system After evaluating various potential options for the camera, the team finally decided to use the Canon G10 for the competition.

Table 5: Specification chart for Canon G10 The on-board SBC controls all camera parameters like zoom level, shutter speed, and aperture width using the open source libgphoto library. Utilizing the cameras built in SDRAM directly and thus bypassing the memory card enables a great performance increase, allowing images to be captured from the camera at nearly 1/3 fps. The images are stored locally on the on-board SBC and also transmitted to the ground station. A rsync command continuously synchronizes the images between the on-board SBC and the ground imagery terminal. The advantage of this feature is that even in an event of a link disconnection, the queued up images get transmitted when the link gets re-established. Due to the limited bandwidth, transferring an image takes about 2-3 seconds which is about the same time as required to capture one image. Validated through many flight tests, the team is confident of using sweep algorithms with this time interval to adequately detect all targets in real time.

Delhi Technological University

A single axis roll compensation gimbal has been fabricated to provide image stabilization. Roll compensation was deemed necessary as during the flight tests, it was observed that aircraft sometime banked as much as 45 degrees. The designed gimbal, which is controlled through autopilot, can provide roll compensation up to 25 degrees. 2.2.4 Image processing The team uses the following process for providing complete actionable intelligence to the Marines.

Image Acquisition

Filtering and Segmentation

Morphology Operations

Connected Components Analysis

Histogram Analysis

Shape Recognition

Letter Recognition

Graphical User Interface

Figure 6: Image processing pipeline

The operating methodology implemented involves searching for sharp, continuous color change against the background. All such candidate shapes are then filtered for false positives, following which color detection is performed. The largest peak corresponds to the shape color and the next major peak that of the letter. The extracted images are then sent to their respective classifiers. The OpenCV Computer Vision C/C++ library has been utilized in the teams efforts because of its greater processing speed as it is optimized for low level processing; it supports a large variety of image processing functions, and is portable to all operating platforms. 2.2.4.1 Shape Recognition Shape recognition is performed by a novel approach wherein a ray is traced along the outer contour of the target and the corresponding distance from the centroid noted for each angle. This results in a graph with peaks corresponding to maximum distance from the centroid and valleys corresponding to the minimum distance.

Figure 7: Shape Recognition - Behind the scenes

Delhi Technological University 10

Utilizing a derivative curve of the distances the pixels corresponding to the valleys and peaks are determined. Based on the relative distances and angles between these characteristic points, shape classification is performed to robustly recognize triangles, quadrilaterals, polygons, circles, semicircles and shapes like stars and crosses. This recognition schema has the advantage that firstly, it is invariant to scale, rotation, and skew and secondly, it does not give any false positives as a signature based approach might. 2.2.4.2 Letter Recognition For letter recognition a large number of approaches have been implemented however, none of the techniques have been robust. The primary reason for this is the very small and distorted nature of the segmented characters obtained from the image. The current approach involves using Hu moments for letter description. Hu moments are a set of seven scale and rotation invariant numbers, or feature descriptors, which can be used to classify letters. The closest letter is matched to the given image by a least distance method. This method reliably recognizes letters that have very little symmetry and/or are of good quality.

2.3 Autopilot
2.3.1 Overview Due to persistent issues in developing a robust in-house autopilot, the team decided to choose a COTS product for 2011. So, a competitive analysis was done based on parameters like schedule, budget, ease of procurement, ease of integration and tuning for various available autopilots. Finally Ardu-Pilot Mega, an open-source autopilot, was chosen amongst Piccolo, Kestrel, Micropilot, Paparazzi, Attopilot and others. After comprehensive ground testing and flight tests, the team was able to achieve all threshold parameters of their KPP chart. Parameter Autonomy Navigation Modularity Take off & landing Gimbal stabilization Threshold Attitude stability Static Waypoints Integration with ASTRA Manual 1 axis stability Objective Waypoint navigation Dynamic waypoints Plug & play with similar sized aircrafts Autonomous Complete gimbal control with target locking, and manual override for en-route search. Where we stand Objective Objective Threshold Threshold Threshold

Table 6: Key Performance Parameters for autopilot 2.3.2 Ardu-Pilot Mega (APM)

APM is an Arduino compatible, open source autopilot which uses Atmega128 for processing and Atmega 328 for failsafe/PPM encoding. It also has an onboard hardware multiplexer to switch between RC and autopilot mode. Above the processor board resides a set of sensors constituting IMU shield that provides attitude information to the APM. It provides complete "Hardware-in-the-loop" simulation for simulating the performance of aircraft on ground. Its two-way telemetry and in-flight commands capability using the powerful MAV Link protocol provides dynamic control to ASTRA.

Delhi Technological University 11

Full mission scripting with point-and-click desktop utilities provides full control of ASTRA from the Ground station. 2.3.3 Sensors & On Board Peripherals APM has an integrated IMU which provides roll, pitch, yaw, gyroscopic rates and accelerations. The IMU was chosen over an infrared based thermo-pile sensor as thermopiles effectiveness reduces significantly in fog. An onboard voltage sensor can provide actual battery levels to the Mission Control Centre (MCC). This feature can warn us in case of depleting battery. APM also provides an in-flight data logger that is used for post flight analysis. Garmin 18x WAAS enabled GPS receiver provides precise 3D position of ASTRA. The RUAV ALT51 airspeed sensor from Rissa UAV Systems provides accurate airspeed data to the autopilot through an in between SBC. The team uses TS-7800 SBC to process the incoming data from airspeed sensor and GPS to route it to the autopilot. It also pipes the GPS altitude and coordinates to the imagery SBC for geo referencing of targets.

2.3.4 Hardware in the Loop Simulation (HILS) With no prior experience of tuning an autopilot, a thorough HILS was a necessary task before actual flight autonomy could be achieved. APM offers the capability of HILS using X-planes flight simulator. Xplanes model of SIG Rascal 110 was made on which navigation and stability gains were tuned in the virtual environment. The simulation environment also helped the control team to get acquainted with the autopilot features & be better prepared to perform an autonomous mission later.

2.3.5 AutoPilot Integration and Testing A gradual and progressive approach towards the objective of achieving complete autonomy was followed. The team started with converting 54 wingspan Multiplex Easy Star into an autonomous aircraft. The aircraft besides having stable flight characteristics could be easily repaired in an event of crash as it was foam made. Next the team tuned the autopilot with a size 60 Boomerang RC aircraft. Complete HILS on both the aircrafts was done to simulate their performance in real flight and adjusting the stability gains, in case required. After actual flights and a post-flight review, gains were re-adjusted to further improve stability and navigation for next flight. Once dynamic autonomy was achieved on Boomerang, the team was convinced to move their system onto SIG Rascal 110, the airframe to be used in AUVI SUAS 2011. Selection of altimeter and airspeed sensors was done only after intensive ground and field testing. To ensure precise altitude readings, the barometric altimeter was sealed in a balsa-box. This eliminated any possibility of a turbulent airflow hampering its performance. The performance of these sensors was later re-adjusted and validated in the subsequent flights.

Delhi Technological University 12

Figure 8: Autopilot system layout

2.3.6 Autopilot Safety Considerations Safety of the operators and the surrounding environment is a prime concern in an autonomous mission. In the event of any equipment failure, the autopilot failsafe is realized in two ways. The first is the customized autopilot failsafe that continuously keeps a track of R/C radio link, losing which it engages failsafe. The second is a PPM multiplexer which allows the RC pilot to manually over-ride the aircraft any time during flight. The autopilot failsafe has been designed in accordance with the rules set up by AUVSI for the competition. In absence of RC radio link for 30 seconds, AutoPilot initiates a spiral dive maneuver as a failsafe measure. PPM multiplexer basically behaves as a Receiver Multiplexer (Rx Mux) in case of any failure. This enables a full manual override through the R/C link in case plane behaves abnormally in mid-air.

2.4 Communications System Design

2.4.1 Design approach: A robust and reliable communication link is imperative for ASTRA flight operations. The teams persistent stint with unpredictable communication failures last year provided reasons to look for a complete system redesign. It was found that the build quality of antennae and Ethernet cables in 2010 was inferior and hence demanded replacement.

Delhi Technological University 13

The team procured high-gain directional Yagi and Patch antennae and an intensive ground-based testing and simulation commenced. A number of permutations and combinations were tried as part of Developmental Tests to arrive at the final configuration. The system shows great performance in a non-urban environment and marked improvement over serial modems in an urban environment (university campus). The team has successfully implemented the new communication system in flight and no link loss observed till date proves its readiness to be employed in SUAS 2011. 2.4.2 Developmental Tests and Adjustments After through testing with serial modems it was confirmed that due to inherently low baud rates modems showed considerable lag & packet losses during telemetry. Further, serial modem was unable to hold such large quantities of data which led to slow update rate at MCC and loss of data packets. Thus, the team shifted to the previously verified TCP/IP based communication system. TCP/IP is a trusted protocol with many additional built in features that ensured encryption and reliability of the communication system. Serial to Ethernet converter is used to convert serial data to TCP/IP format. The system is capable of automatic reconnection in case of link loss. The final communication system has a total of 3 wireless links between ground station and the aircraft: a) 2.4 GHz wireless link for telemetry and control through MCC. b) 2.4 GHz wireless link for image transmission. c) 2.4 GHz R/C Radio link for manual control of aircraft.

2.5 Ground Station

2.5.1 Imagery Terminal To present all target information as actionable intelligence, a platform independent Qt GUI has been designed that presents the current image transferred from the Beagle-Board. In flight the camera is assumed to be pointing straight down due to the nadir oriented gimbal. Using the bearing and altitude values obtained from the autopilot, the pixels to distance scale is calculated and the GPS coordinates of the targets determined.

Figure 9: Imagery terminal screenshot

Delhi Technological University 14

Additionally, to facilitate visual comprehension, a grid is overlaid over the image which divides the ground into longitudinal and latitudinal degrees. The GPS coordinates of points in the image below the cursor is showed in real time in the status bar. The imagery terminal displays the incoming images on the secondary monitor while the operator works on the primary monitor. Due to the assisted nature of the processing task, the operator cycles through the images manually, positively identifying the targets acquired by the software and those skipped by it. The final decision of noting the target lies with the operator. The operator can also tag a target manually by dragging a box around it on the GUI. For each positively identified target a pop up window is displayed which is used to fill in the details missed out by the software. On submitting the data, a copy of the target is made in a specified folder and its data is logged in an excel file with the corresponding file URL. The GPS coordinates of all the acquired images are tagged in their EXIF data which permits geo-tagging all the pictures on any GIS or mapping software. Such a feature will be implemented in further iterations of the GUI. 2.5.2 Mission Control Centre The DTU-UAS Mission Control Centre (MCC) is the interface on ground with the autopilot. It runs HappyKillMore GCS software which is the virtual cockpit of ASTRA. It provides a moving 3D display of the instantaneous aircraft attitude, overlaid on a map of the search area, as ASTRA moves through waypoints. It has the feature to dynamically change waypoints once the aircraft is in air, and define new search areas. A plug-in has been developed which allows the MCC to interface with Google Earth. This facilitates overlaying clearly defined no-fly zones and search areas on a satellite imagery map of the terrain below the UAS. Warning alarms are generated if communication link is lost or battery level is too low. The MCC provides a current display of air vehicle position with respect to no-fly zones and search areas. Altitude and airspeed data is also visible.

Figure 10: Mission Control Centre screenshot

Delhi Technological University 15 2.6 Power Systems:

2.6.1 Design approach Experience gained from previous competitions and flight tests showed that the avionics battery must be capable enough to support multiple flights and pre-flight preparations. A chart of individual power consumption by avionics components was constructed & an estimated battery time was calculated. The battery size was then accordingly decided. S No. 1 2 3 4 5 Component Quantity Power Consumption(W) Ardupilot Mega(including sensors) 1 2 TS-7800 Single Board Computer 1 5 Beagle Board 1 5 Wireless routers 2 16 Camera 1 5 Total 33 Table 7: Power requirement chart

As evident from the table, a maximum of 33 watts of power is required to power ASTRA for an estimated 1 hour flight time. A primary Lithium Polymer battery serves the purpose for above. Currently, the flight servos are powered by the primary battery that also powers the avionics. So to add redundancy, a secondary battery is included to exclusively power the RC receiver & flight servos. In case the primary avionics battery fails in flight, the servo power system automatically shifts to secondary battery and keeps the vehicle in control. To provide a regulated power supply to various avionics subsystems, Battery Elimination Circuit (BEC) is used. Castle Creations programmable BEC can provide regulated output voltage between 4.8V to 12.5V at high amperage ratings. They are light and small and cause minimal EM radiation. A central power control board has been developed to selectively power the systems during testing and debugging to save battery. Also an avionics startup procedure has been established between the Ground Station Team and Aircraft team to ensure proper startup and shut down of ASTRA. As a safety measure, the avionics and servo battery voltages are available at all times at the MCC.

2.7 System Layout

Since the competition demands minimum turnaround time, importance was given to system integration, avionics placement and modularity. The component placement was done keeping in mind the following concerns: 1. 2. 3. 4. 5. Static Margin of Aircraft Heating effects and desired cooling of components Accommodation of Gimbaled camera Removal of components in case of emergency Frequently replaced components should be quickly accessible

The effort was to make the avionics systems easily accessible at all times. This was fruitful when lots of flight tests were conducted in a compressed schedule. This greatly shortened the turnaround time due to decreased clutter of onboard avionics.

Delhi Technological University 16

Figure 11: Systems placement

The batteries were placed in the front of fuselage, since a positive static margin was required. Also the heavier components like gimbaled camera and the wireless routers were placed about CG and lighter components like SBCs and antennas were let to reside in the aft fuselage. The initial placement of avionics components was done using CAD. The 3-D model of SIG 110 and avionics were drafted in SolidWorks, which helped in ensuring a neat hassle-free layout. All the antennae were placed far away from each other. Frequently accessed components were placed in the upper deck. Secure and neat wiring is a key parameter in ensuring the safety of UAS in flight. It also aids in quick debugging in case any problems arise. Keeping these factors in mind, the wiring routes were designed during the preliminary phase of the design. All wires are labeled to ease connections. All the connectors used are unique so as to prevent any accidental connections. All wires to the control surfaces servos are twisted and have ferrite beads as filters to prevent any glitches. All co-axial cables are also shielded. All Ethernet and serial cables are locked so as to prevent any accidental disconnections. The entire system has been designed such that it could be assembled to flight-ready condition by a single operator in less than 20 minutes.

Mission Planning:

Mission Planning is a critical event in the Flight Testing Protocol of DTUs ASTRA. Generally it starts 7 days prior to a scheduled flight test after a detailed post-flight review of the previous test. The systems performance is gauged to identify points of improvement and a set of objectives is defined. The team outlines a flowchart of subsequent flights to be made based on success/failure criteria of each individual flight. A detailed flight path is pre-planned in the lab using Google Earth and the waypoints are defined for autonomous flight prior to leaving the lab. This ensures minimum preparation time on ground and

Delhi Technological University 17

be flightready within the 40 minutes set-up time frame. A Pre-Flight Review is done in which the Flight Test Director briefs the Flight Crew about the objectives and outlines individual crew responsibilities. Once the aircraft is on ground, the Safety Officer checks the wind speed to determine the runway direction and conveys it to the Flight Director. All changes to the flight plans between subsequent flights are relayed by the Flight Test Director to the Safety Officer and the RC Pilot.

Flight Operations:

4.1 Process Flow-chart:

Team UAS DTU extensively follows standard operational procedures developed over the years with repeated flight tests. The entire UAS mission is divided into five stages:

M1 M2 M3 M4 M5

Pre-Flight Briefing
Groundstation set-up Airframe preparation Tx/Rx range check, Airframe check Communications check, Flight modes check ASTRA performing ISR Post-flight Checks and Mission De-briefing

4.2 Flight Crew description:

Flight Director: Responsible for the overall management of the mission. He gives the final go ahead for take-off after ascertaining that the Ground Station Team and the Airframe Team are ready. The director ensures information is passed smoothly between Ground Station Team, Safety Officer and RC pilot. There is a defined operational procedure for transitioning from manual to autonomous control that involves the MCC operator, Flight Director and RC Pilot. Safety Officer: The Safety Officer oversees the entire mission to keep a check on potentially unsafe situations. He is responsible for safety of the spectators and flight crew. He confirms the direction of run-way and ensures the ground is clear for safe flight operations. He performs range check of the RC control. In case of an emergency landing, the R/C pilot informs him of potential landing spots for the aircraft and he acts on a pre-defined checklist to ensure least damage. Airframe Lead: He is primarily responsible for assembly of the airframe within the stipulated time-frame. He has to ensure that the airframe conforms to the safety norms set by SUAS requirements. He then gives the go-ahead to the Flight Director. MCC Operator: His task is to set up the communication module and report to the flight director when both the telemetry and imagery Wi-Fi links are established. In flight, he observes the telemetry data on the MCC and informs about the state of aircraft to Flight Director at regular intervals of time.

Delhi Technological University 18

Imagery Operator: He ensures an optimal setting for the imagery. He also loads the images which are to be processed autonomously at the Imagery Terminal. At the end of mission execution, he generates the Excel sheet containing actionable target parameters. Antennae Operator: He is responsible for ensuring that the ground station antennae are properly tracking the aircraft at all times. He continuously observes the wireless strength and confirms with the MCC operator.

4.3 Safety:
R/C Pilot

Flight Director

Safety Officer

Airframe Lead

MCC Operator

Imagery Operator

Figure 12: Command Flow

Safety is a major concern during any UAS operation. To ensure hassle-free mission execution, every flight crew member has a designated check-list which includes reaction under emergency situations. During flight operations under normal conditions, the R/C pilot receives commands only via the Flight Director. While the aircraft is in air, the Safety Officer is stationed near the pilot. In case of emergency landing announcement from the pilot, he executes operational procedures to ensure the landing spot is clear and the overall safety of spectators and flight crew. The Safety Officer is always equipped with standard first-aid kit in case of any mishaps. The team has established a Go/ No-go criteria based on previous experiences which are strictly adhered to. ASTRA shall not fly under the following circumstances: If there is any precipitation. If there is an approaching thunder-storm. If the visibility is less than 2 miles. If GPS lock fails. If there is any perceptible damage during taxiing or other ground operations. If range test fails before 200 feet on the primary R/C link with all wireless devices operational. If control surfaces show glitches. If winds exceed 20 knots. If there is low light.

5 Safety and Risks Register

Based on past failures and possible risks experienced from several flight tests, a detailed Failure Modes and Effects Analysis (FMEA) approach was employed to devise a meticulous Risk Mitigation Protocol to be followed by flight crew during flight tests. This practice ensures the systems flight readiness to meet the competitive safety requirements of AUVSI SUAS 2011.

Delhi Technological University 19

Risk Mitigation Steps are divided into 3 categories: Code Blue : Mission continues; Manual override Code Yellow: Mission continues; Manual override Code Red : Mission failure; Emergency Landing or Spiral Dive

Failure Mode Telemetry loss

Indication link Warning on MCC Warning on imagery terminal Notification once Failsafe activated

Step 1 Switch to Manual; while wireless router is rebooted Continue with Mission Control switched to RPV Manual search begins; while Autopilot rebooted. Switch to manual; reset altitude sensor

Step 2

Step 3

If link re-established, If reboot fails, Switch to then emergency Autonomous search. landing. N/A Landing through RPV N/A N/A

Imagery link loss R/C link loss

Autopilot re- Demo Servos display boot in flight on MCC Plane dives down, erratic behavior on MCC

Loss in altitude

Aircraft enters Indicated no-fly-zone display Avionics battery Indicated low voltage display Component disintegration

on

MCC

Falling debris, erratic behavior.

MCC terminal No output on screen crashes Imagery Terminal Crashes Loss of airspeed No output on screen Plane dives down, erratic behavior

If AutoPilot successfully rebooted; N/A Switch to Autonomous search. If sensor rectifies; Switch to N/A Autonomous search. If issue persists, Switch to manual; Switch to Auto; search adjust navigation observe continues in PID manual Emergency Autonomous mission Landing; Change N/A resumed. battery Emergency Landing; Mission N/A N/A Call-off Switch to manual; If MCC terminal ready; Backup terminal Switch to N/A brought in Autonomous search. Flight continues; Backup terminal N/A N/A brought in. Switch to manual; If airspeed issue check groundspeed persists; switch to GPS N/A v/s airspeed. speed and continue.

Delhi Technological University 20

6 Flight Tests and Evaluation

Since 2010 competition, team UAS-DTU has flown its system 25 times spread over 8 flight tests. Over the course of this flight season, ASTRA has accumulated 210 minutes of total flight time of which 120 minutes were autonomous. ASTRAs two crashes have led to major system overhauls which further improved the systems reliability. The first crash on 9 April 2011 wrecked the on-board gimbal and camera. It was then realized that gimbal should be housed inside the fuselage to ensure safety of camera in case rough landings may occur. The next major crash occurred on 23 April 2011 when ASTRAs left wing snapped off in mid-air while performing a pull-up maneuver. The damage on fuselage and wings was catastrophic and beyond repair. Learning from the mistakes, a safety protocol was followed in re-construction of the teams back-up airframe. The critical attachment points were strengthened and the structure around the payload aperture was reinforced. The pre-flight safety checks were revised.

7 Conclusion
The teams key approach for design of 2011 system had been to provide with a commercially viable modular product that can be repeatedly used for terrestrial reconnaissance missions. The team has ensured a back-up of all components including the airframe itself. All the components in the backup airframe have already been integrated and system has been brought to flight-ready state. The team has practiced mock simulations of the competition. Other flight tests have also been carried out following pre-defined flight procedures and protocols. This practice has improved teams coordination and operational efficiency, and has significantly reduced mission completion time. The best mission completion time stands at around 30 minutes, which the team hopes to reduce even further while practicing more flight tests in the last week of May and in early June. Validated with 8 successful flight tests and over 120 minutes of autonomous flight time, ASTRA can now successfully follow the pre-defined waypoints, perform aerial imagery, filter potent targets and identify their color, position and shape. The system also has the capability to dynamically adjust the waypoints and search-area during mission. The team is confident about the systems performance and its competition readiness.

8 Acknowledgement
The team UAS-DTU is grateful to Lockheed Martin Aeronautics Company for their continuous support in the project. The team also recognizes the support of former team members who helped the team in preparing flight plans and execution of mission. The Team would like to thank the project advisors Prof. N S Raghava and Dr. D S Nagesh. The team acknowledges the invaluable contribution of Delhi Technological University Vice Chancellor Prof. P B Sharma for his constant support and encouragement to the project.

Delhi Technological University 21

9 References
1. 2. 3. 4. 5. 6. 7. 8. www.solidworks.com www.diydrones.com www.canon.com www.garmin.com www.ruav.ru www.beagleboard.org www.embeddedarm.com opencv.willowgarage.com - SolidWorks 3D Design Software - Developers of APM autopilot - Digital Camera - GPS Receiver - Airspeed Data Sensor - Single Board Computer - Single Board Computer from Technologic Systems - Open Computer Vision