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

Imagery

Acquisition
identification

Mission Time

Aircraft

Within 40 minutes (Imagery,

recognition and location done at
conclusion)
Max. GTOW 55 lb

Control

Manual (at all times)

Communications

Different wireless bridges for

manual control and MCC

Safety

Failsafe: Spiral Dive

and

Visual

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.

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

Flight Control System

Payload

Air Speed
Sensor

GPS

Gimbal
Camera
Onboard Computer
Battery2

Battery 1
SBC

Battery 1

Autopilot
Wireless router
Wireless Router

2.4 GHz

Rx

2.4 GHz

Flight Servos

2.4 GHz

TX

Wireless Router

Imagery Terminal

Wireless Router

Mission Control Centre

Systems Design and development

2.1
2.1.1

Air Vehicle Design

Overview

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

Specification

Wing Span

110 inches

Empty weight

10 lbs

GTOW
Propulsion

18 lbs
Hacker A60 22S 19X8 prop

Power

10S Thunder Power LiPo

Endurance

26 mins

Stall: Cruise: Max Velocity

Payload volume

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

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

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

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.

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

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

Threshold

Objective

Where we stand

Autonomy
Navigation
Modularity

Attitude stability
Static Waypoints
Integration with ASTRA

Objective
Objective
Threshold

Take off & landing

Gimbal
stabilization

Manual
1 axis stability

Waypoint navigation
Dynamic waypoints
Plug & play with similar sized
aircrafts
Autonomous
Complete gimbal control with
target locking, and manual
override for en-route search.

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

Pre-Flight Briefing

M2

Groundstation set-up
Airframe preparation

M3

Tx/Rx range check, Airframe check

Communications check, Flight modes check

M4
M5

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

MCC Operator

Airframe Lead

Safety Officer

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

Failure Mode
Telemetry
loss

: Mission failure; Emergency Landing or Spiral Dive

Indication
link Warning on MCC

Imagery link loss

R/C link loss

Warning on imagery
terminal
Notification
once
Failsafe activated

Autopilot
re- Demo Servos display
boot in flight
on MCC

Loss in altitude

Plane dives down,

erratic behavior

Aircraft enters Indicated

no-fly-zone
display

on

MCC

Avionics battery Indicated

low voltage
display

on

MCC

Component
disintegration

Falling debris, erratic

behavior.

MCC
terminal
No output on screen
crashes
Imagery
Terminal Crashes

No output on screen

Loss of airspeed

Plane dives down,

erratic behavior

Step 1

Step 2

Step 3

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

If link re-established, If reboot fails,

Switch
to then emergency
Autonomous search.
landing.
N/A

N/A

Landing through RPV

N/A

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