Interim Report

19.521 - Group ProjectInterim Report

Semi-Autonomous Unmanned Aerial Vehicle

Philipp KaragiannakisColin McGuireNiall McKenzie

Neil Sinclair

December 19, 2008

Mentor: Professor R. Stewart

Abstract

The SUAVE project aims to create a Semi-Autonomous Unmanned Aerial Vehicle for

use in observation and surveillance applications. A quadcopter helicopter based on a

commercial open-source project called Mikrokopter will be used as foundation. Further

systems will be added to increase the functionality of the quadcopter including an object

detection system, GPS-powered navigation and a bi-directional wireless communication

system using WiFi and GPRS. A camera will be integrated into the system to provide

an example of a potential surveillance application.

Currently the project is on schedule and all of the required hardware has been ob-

tained. The system design has been finalised and a work plan created to implement this

in the coming semester.

ii

Contents

1 Introduction 1

1.1 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Project Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Report Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Applications 3

2.1 Microwave Cavity Resonator . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Air Pollution Sensor (Inner-city) . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Remote Volcano Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.4 Camera Surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Background 5

3.1 How Quadcopter Works . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 Proportional Integral Derivative Control . . . . . . . . . . . . . . . . . . 7

3.3 Communication System . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.1 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.2 GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Object Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4.1 Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4.2 Imaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Design Methodology 13

4.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Navigation and Autonomous Control System . . . . . . . . . . . . . . . . 13

4.2.1 Requirements 1 and 3 Send and Receive commands and flight data

to the communication system . . . . . . . . . . . . . . . . . . . . 16

4.2.2 Requirement 2 Receive and Pre-Process Data . . . . . . . . . . . 16

4.2.3 Requirement 4 - Process Available Data and Decide on Movements

Required to Control the MikroKopter . . . . . . . . . . . . . . . . 17

4.2.4 Requirement 5 Disengage Manual Control and Control quadcopter

in Autonomous Mode . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.5 Requirement 6 Monitor Current Situation and Prepare for Au-

tonomous Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20


iii

5 Equipment 22

5.1 Flight Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Navigation System Equipment . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.1 Central Processing Unit . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.2 GPS Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.3 Magnometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3 Communications System . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.3.1 Freescale Coldfire Microcontroller . . . . . . . . . . . . . . . . . . 25

5.3.2 Fargo Maestro - 100 GPRS Modems . . . . . . . . . . . . . . . . 26

5.3.3 S103 WiFi Module . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.4 Surveillance Module and Compression . . . . . . . . . . . . . . . . . . . . 28


6 Progress to date 31

6.1 Construction and Test Flights . . . . . . . . . . . . . . . . . . . . . . . . 31

6.2 Selection of Navigation Equipment and Testing . . . . . . . . . . . . . . 32

6.2.1 Component Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.3 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33


7 Future Work and Goals 37

7.1 Navigation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.2 Communication System . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.3 Camera Surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38


8 Conclusion 39

A Risk Assessment 43

B Gantt Chart 47

List of Figures

1 quadcopter with mounted camera[2] . . . . . . . . . . . . . . . . . . . . . 4

2 quadcopter showing direction of each propeller[3] . . . . . . . . . . . . . 5

3 Thrust comparison of 10” and 12” propellers . . . . . . . . . . . . . . . . 8

4 PID controller[8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Illustration of using infrared or ultrasound to detect the presence of objects[11] 11

iv

6 RoboRealm example, showing the original image (left) and the edge de-

tected image (right)[12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7 RoboRealm example, showing the side-filled image (left) and the eroded

image (right)[12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

8 RoboRealm example, showing the final image overlaid with the original[12] 12

9 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

10 Basic Navigation System Connections . . . . . . . . . . . . . . . . . . . 14

11 Navigation Processor Data Inputs and Outputs . . . . . . . . . . . . . . 15

12 The three levels of control: go to command, object avoidance and basic

flight stabilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

13 Control loops used to achieve autonomous flight. (a) yaw: controls the

direction of vehicle (b) pitch: controls the horizontal movement. (c)

throttle: controls the height of the vehicle . . . . . . . . . . . . . . . . . 19

14 Transmission Structure of SUAVE communications . . . . . . . . . . . . 20

15 Reception Structure of SUAVE communications . . . . . . . . . . . . . . 20

16 Freescale MCF528x features[28] . . . . . . . . . . . . . . . . . . . . . . . 25

17 Freescale Coldfire Microcontroller and Development board . . . . . . . . 26

18 Fargo Maestro- 100 GPRS modems[29] . . . . . . . . . . . . . . . . . . . 26

19 S103 Wifi module[31] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

20 Polar response of a Parallax Ping Sensor, tested with a 12” square piece

of white card[33] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

21 MikroKopter kit before construction . . . . . . . . . . . . . . . . . . . . 31

22 Fully constructed MikroKopter . . . . . . . . . . . . . . . . . . . . . . . 32

23 Magnometer test rig schematic . . . . . . . . . . . . . . . . . . . . . . . 33

24 Circuit diagram of a Sharp Distance Measuring Sensor in use . . . . . . . 35

25 Screen captures of the output pin of the Sharp Distance Sensor . . . . . . 36

v

1 Introduction

Autonomous vehicles create substantial and varied engineering challenges. With ever in-

creasing processing power and the reduction in size, weight and cost of electronic devices,

this challenge can now be extended into the sky.

Designing and constructing an autonomous aerial vehicle is a substantial challenge

and requires knowledge of several areas, both mechanical and electrical. Expertise in

digital communications, control engineering, embedded system design and integration,

power economy and data processing are all required. This multidisciplinary aspect and

the novelty of flight appealed to all of the group members. A quad rotor helicopter

provides a stable and agile platform for surveillance. It avoids some of the complexities

involved with maintaining stable flight compared to a standard helicopter making it an

excellent choice for an initial autonomous aerial vehicle project.

1.1 Aims and Objectives

The aim of the project is to design and construct a Semi-autonomous Unmanned Aerial

Vehicle (SUAVE) for observation and surveillance.

The platform is based on a quad-rotor design which offers superior stability, ease of

control and payload capacity compared to a standard helicopter. A quad-rotor design is

also extremely agile and is free to move in any direction, making it ideal for surveillance

and observation.

A navigation system will incorporate basic object avoidance to allow safe autonomous

flight between predetermined points and wireless communications will facilitate the trans-

fer of control commands and sensor data between the vehicle and a base station.

The following objectives have been identified for this project:

• Construct a quad rotor helicopter and achieve manually controlled stable flight of

the vehicle using radio frequency (RF) control.

• Create a control system capable cable of autonomous hover.

• Create a system to facilitate wireless bi-directional data communication and control.

• Integrate a basic object detection system with an improved control system to avoid

collisions.

1

• Incorporate a navigation system to allow autonomous flight and navigation.

• Integrate a surveillance device and pre-process the data for transmission over the

communications channel.

1.2 Project Organisation

The project is divided into four manageable sections. Each group member is responsible

for one section yet substantial overlapping and crossovers exist. These sections were

assigned according to each members interests. A Gantt chart (Appendix B) was created

containing the parallel work streams to provide a schedule for the group to follow. To keep

all group members and the project mentor informed of progress, formal weekly meeting

are scheduled and an online record of the groups progress in the form of a blog, is kept

at http://project.rawxing.org

1.3 Report Structure

The aim of this report is to inform the reader of the current progress as of 18th December

2008, provide an overview of the design to be implemented and highlight the future work

required to meet the project objectives.

Section 2 details the possible applications of an autonomous quadrotor helicopter and

the chosen application for the SUAVE project.

Section 3 provides background information to aid the reader in understanding how a

quadrotor helicopter operates as well as providing an overview of the technologies which

will be referred to in this report.

Section 4 gives an overview of the current system design which will be implemented.

It is divided into the following sections: Navigation and Autonomous Control, Commu-

nications, Object Detection System and Camera and Video Compression. Each section

will discuss the architecture of the individual system, the connections to other systems

and the equipment selected.

Section 6 highlights the work accomplished to date in all sections and Section 7 dis-

cusses future work and goals and concludes the report.

Appendix A contains the specific risk assessment for this project as of 18th December

2008.

2

2 Applications

A number of options were considered as a possible final application for the quadcopter.

Below is a list of some of the applications investigated and the reasons why they were

eliminated.

2.1 Microwave Cavity Resonator

An idea put forward by Dr Ian Glover a Strathclyde lecturer involved testing the reflec-

tivity of air contained in the boundary layer. The boundary layer is the first few hundred

meters above the earths surface. The reflectivity of air affects the transmission of radio

waves. The proposed method of measurement included building a microwave cavity res-

onator. The resonator chamber would allow air to pass through it and by testing the

capacitance of the air the reflectivity could be determined. The rotating propellers posed

a problem because they would force air pass the cavity thus affecting the measurement.

A different method was to actively monitor the temperature and humidity of the sur-

rounding air and perform a calculation using the two variables. The problem with this is

obtaining an instantaneous and accurate measurement of the humidity. Once again the

rotating blades would affect the measurements.

2.2 Air Pollution Sensor (Inner-city)

It was thought that the vehicle could be used to navigate a pre-determined flight path

and measure several air pollutant levels en route. The resulting measurements could then

be used as an indication of the air pollution in a particular area of a city. However, after

some correspondence with the Technical Officer at the Land Environmental Services of

the Glasgow City Council the idea was abandoned. The main reasons came down to a

problem with the measurement sensors: they were either both large and bulky or a passive

measurement was needed. The passive measurement would once again be affected by the

moving vehicle and is usually taken over a longer period.

2.3 Remote Volcano Sensing

Andrew McGonigle, a Scottish scientist working for the University of Sheffield, has de-

veloped a novel means for determining whether or not a volcano is due to erupt[1]. It

involves sending a Radio Controlled (RC) helicopter into the crater of a volcano and

measuring the level of various gases. This information can then be processed once the

helicopter returns. We are hoping to develop an autonomous version of this which was

3

capable of transmitting the data back for real time processing. Once again the sensors

were the main reason this idea was abandoned. They were found to be too expensive and

there was nowhere to test the vehicle i.e. a local active volcano.

2.4 Camera Surveillance

Possibly the most obvious use for an aerial platform would be as a mount for a camera

so that it may be used as a mobile surveillance device, shown in Figure 1. A decision

was made to build the quadcopter for use as a platform for a camera which would be

connected via a standard serial connection such as RS232. The standardised connection

could then be used to attach different devices and essentially enable the quadcopter to

be used for a multitude of applications.

Figure 1: quadcopter with mounted camera[2]

4

3 Background

3.1 How Quadcopter Works

A quad-rotor helicopter avoids much of the complexity needed to fly a standard helicopter

by eliminating the need for variable pitch rotor blades and a thrust stabilising tail rotor.

Instead it uses four identical propellers which are evenly spaced; they each produce an

equal amount of lift and torque with each pair of opposing propellers being spun in the

same direction. This gives us a pair of clockwise and anti-clockwise propellers. This is

shown in Figure 2 below. By varying the thrust produced by the propellers, movement of

the helicopter in any direction is possible. One of the clockwise rotating arms is defined

as being the front of the vehicle and all movement is in relation to it.

Figure 2: quadcopter showing direction of each propeller[3]

As all the propellers are spinning at the same angular velocity, a yaw stabilising tail

rotor like the one found on a standard helicopter is not needed. Yaw is achieved by in-

creasing the torque produced by a pair of rotating motors – either the clockwise pair or the

anti-clockwise pair and decreasing the torque produced by the other pair. Similarly the

pitch of the rotors need not be altered. Instead, movements in the pitch (forward/back-

5

ward) and roll (left/right) axes can be achieved separately, simply by altering the thrust

produced by a pair of motors and all this can be done without affecting the yaw of the

vehicle. The front and rear propellers control the pitch of the vehicle while in flight and

the right and left propellers control the roll of the vehicle.

The Flight Control (FC) is the main controlling board on the quadcopter and all

the necessary sensors and microprocessors used to achieve and maintain stable flight are

located on this board. The gyroscopes (gyro, also known as rotational speed sensors) are

considered to be the most important of the onboard sensors. The programmed microcon-

troller uses the measurements from them to compensate for external influences such as

wind. The X, Y and Z axis are all assigned their own gyro and they measure the degrees

per second the vehicle turns in a certain plane.

The rate of angular change is measured using three accelerometers; once again each

axis is assigned its own accelerometer. It is possible to fly the vehicle without these

accelerometers however it would not be possible for the quadcopter to return to a level

state by itself. By including these sensors it is possible for the pilot to release the remote

control (RC) sticks and the vehicle will stabilise itself. The final sensor is a barometer

and it allows the vehicle to maintain a specific flying height.

Due to the nature of the project a strict power to weight ratio budget was designed.

From initial estimations, maximum payload for the vehicle would be about 400 grams.

The motors used in RC vehicles vary greatly so it was desired to find a light motor with

low power consumption. The main requirement was that it provided 1000 rpm V−1. A

Brushless motor fulfils the specifications. Brushless motors are more complicated to op-

erate because they need to change the DC supply voltage of the battery into a phased AC

(usually three phase) with a controlled power output so that the speed of the motors can

be accurately controlled. In total there are four Brushless Controllers (BL-Ctrl) one for

each motor. There are numerous BL-Ctrls on the market. To achieve a very stable level

of flight it is desired to change the throttle value very rapidly (<0.5m s−1); this would be

best done using an Inter-Integrated Circuit (I2C) bus interface.

Control of the vehicle is achieved through use of a RF transmitter and receiver pair. A

transmitter with a minimum of four channels is required to control the quadcopter in the

various planes. It must use Pulse Position Modulation (PPM). The receiver demodulates

the instructions given by the pilot and converts them into electrical signals. A receiver

with a summing signal is required for the MikroKopter (MK). This signal contains all of

6

the channels sent by the transmitter and is made available to the FC for processing.

The design of the frame is only limited by one factor: it must be as light as possible.

The frame designed took on a basic cross shape similar to many open source projects[4].

Bearing in mind that the frame must be lightweight some of the materials considered

include: aluminium, carbon fibre or polystyrene; it is possible to have a combination of

these. The most cost effective material for this project is aluminium because it is readily

available and cheap.

The batteries needed to power all the onboard electronics have to have a low weight to

power ratio so that maximum flight time may be achieved. The different types of battery

considered suitable for use in RC vehicles are: Lithium polymer (Lipo), Nickel-cadmium

(NiCd) and Nickel metal hydride battery (NiMh). The Lipo types are the most advanced

and offer the most power. They are volatile and must be handled with care but they

can have a capacity of over 10,000 mAh. NiMh batteries are a slightly older technology

but they are still capable of capacities around 5000 mAh. However if a poor quality of

battery is purchased then bad cells can develop quickly when the capacity is increased.

NiMh batteries are cheaper than Lipo batteries and are also less volatile. NiCd batteries

are the cheapest overall and have similar characteristics to that of NiMh but are unable

to achieve an equal capacity. A decent flying time is desired to test the software and

hardware which will be added and due to the powerful motors and large propellers the

best weight to power ratio with a high capacity can be achieved using the Lipo batteries.

The propellers play a major role on the take-off weight and the speed that the vehicle

will fly at. The diameter of the propellers as well as their pitch must be considered. Due

to the slow spinning motors a low pitch is desired. After using a thrust calculator it was

determined that a good combination for the propellers would be: 12” propellers with

4.5” pitch. A snapshot of the thrust calculator at 4000 rpm for 10” and 12” propellers

is shown below in Figure 3. The affect of altering the blade diameter by 2” doubles the

static thrust developed.

3.2 Proportional Integral Derivative Control

Proportional Integral Derivate (PID) control is a common method used to control pro-

cesses and robotic systems [5]. It allows automatic control of an output, depending on

the current output and various inputs. It consists of a combination of three individual

controllers combined together; Proportional, Integral and Derivative as shown in Figure 4.

7

Figure 3: Thrust comparison of 10” and 12” propellers

Figure 4: PID controller[8]

As shown in Figure 4, the error signal is an input minus the current output. This error

signal is processed by the PID controller and the outputs of each element are combined

to create the output to control the process.

8

Proportional control can be thought of as a gain. The error signal is multiplied by

the gain; Kp. It influences the amount the input has to change to cause a variation of

0-100% in the output[6].

Integral control uses feedback (most commonly positive) to reset the controller[7].

This is achieved by integrating the error signal and multiplying it by the gain, Ki. This

has the effect of controlling the output so it stabilises at a constant steady-state.

Differential control differentiates the error signal and multiplies it by the gain, Kd.

This influences the rate of change of the output signal.

Combining these three elements creates an effective controller which can be imple-

mented in software.

3.3 Communication System

3.3.1 WiFi

The WiFi version that will be implemented is 802.11b and it has the following characteristics[9]:

• Release Date - October 1999

• Frequency band - 2.4 GHz

• Typical Throughput - 4.5 Mbps

• Bit Rate - 11 Mbps

• Range (Indoor) - ∼38 m

These aspects describe how ideally suited it is to our application. Relevant appli-

cations are short range communications that do not require extremely large data rates.

This version of WiFi is very commonly used as a wireless LAN technology.

The main issue with 802.11b is that there are other devices that operate on the 2.4

GHz frequency band. These devices include microwaves, Bluetooth, baby monitors and

cordless phones. When these devices operate in the same region as 802.11b they cause

interference to occur in the WiFi signal.

9

3.3.2 GPRS

Whilst GSM is excellent for communications networks that involve the transmission and

reception of voice calls, it is not designed for the use of sending or receiving data. This

is due to the data rate of GSM not being high enough for data transmission.

GPRS (General Packet Radio Service) improves the performance of GSM to allow

it to send and receive data. GPRS is one of the communications technologies that are

classed as part of 2.5 G, these are designed to move the performance of 2G networks

closer to the performance of 3G networks. The bit rate of GPRS for a pair of Class 10

modems is 16- 24 kbps for uploading and 32- 48 kbps for downloading[10].

Due to GPRS being part of the standard cellular network, there is currently wide

coverage, especially in urban areas. This means that if a remote control device is being

controlled over the cellular network then it can be controlled from anywhere else with

network coverage, no matter how far away.

3.4 Object Detection

Robots have no spatial awareness (being non-human), and as such need to be constantly

updated with its surroundings. When the quadcopter is flying from Point A to Point

B, it is important that it does not collide with any obstacles on route. There are two

potential paths for Object Detection: Sensing and Imaging.

3.4.1 Sensing

The Sensing approach uses either Ultrasound or Infrared waves to detect the presence of

objects. A short pulse is emitted from a transmitter and then a detector will receive the

reflected signal. Either the time delay or the magnitude of the signal will then be used

to calculate the distance to any objects within range of the sensor. This approach, as

illustrated in Figure 5, is the same as is used with touchless hand driers found in public

toilets.

There are three types of outputs that can be taken from a distance sensor: Analogue

Range, Pulse Width Modulation (PWM) Range and Distance switch.

Analogue Range is a variable voltage output (between ground and the supply volt-

age) that is dependent on the distance to the object. This can then be quantised using

a Analogue-to-Digital Converter (ADC) and with the aid of a look-up table, a distance

realised. A PWM range output works in a similar manner, where by the pulse width is

10

Figure 5: Illustration of using infrared or ultrasound to detect the presence of objects[11]

varied dependent on distance. The Distance Switch is the most basic of the three, and

when an object is within range of the sensor, the output is toggled (either High to Low

or vice-versa).

3.4.2 Imaging

The use of a camera allows the quadcopter to ”see” the surrounding environment. Robo-

Realm has open source software[12] showing how a simple webcam can be used to detect

objects and calculate a safe route. Firstly edge detection is applied to an image as seen

in Figure 6.

Figure 6: RoboRealm example, showing the original image (left) and the edge detectedimage (right)[12]

A technique called ”side-fill” is used whereby a vertical line is taken from the bottom

of the image and white is placed in each pixel, until an edge is detected, at which point

the rest of the line is filled black. The white area of the image is then eroded by an object

such that the area left is large enough for the vehicle to pass. These steps are shown in

Figure 7.

11

Figure 7: RoboRealm example, showing the side-filled image (left) and the eroded image(right)[12]

The image is smoothed and the white pixel with the greatest y value is found and it

is this pixel that the vehicle aims for. In this example, as seen in Figure 8, this is at the

x value of 193.

Figure 8: RoboRealm example, showing the final image overlaid with the original[12]

12

4 Design Methodology

This section details the architecture of the overall system, and the design of and inter-

connections between internal subsystems.

4.1 System Overview

A diagram of the complete system is shown in Figure 9. The navigation system controls

the actual flight of the quadcopter and passes flight telemetry (current position, heading,

height, battery level, gyroscope and accelerometer values) to the communications system

to send back to the user. The communications system receives control commands to tell

the quadcopter where to go (latitude/longitude/height) from the user and passes them

to the navigation system. It also encodes and transmits sensor data back to the user.

The object detection system will detect objects in the quadcopters path and inform the

navigation system which will take the appropriate action.

Figure 9: System Overview

Communication between the systems will be via an I2C bus. The navigation system

will act as the master device and will ask the other two systems for data when required.

This will be discussed further in Section 4.2.2.

The design of the navigation, communications and object detection systems are de-

tailed in the sections below.

4.2 Navigation and Autonomous Control System

The navigation system is centred around a microcontroller hereby referred to as NAVPRO.

This is the centre of the whole system, controlling the overall operation of the Unmanned

Aerial Vehicle (UAV) and acting as master to the other communication and object de-

tection systems (ODS). The MKFC will be used to maintain stable flight when manually

13

and autonomously controlled.

To meet the requirements specified in Section 1.1, a Global Positioning System (GPS)

module and magnometer are required for autonomous flight. The GPS module allows the

quadcopter to be aware of its current location (by providing a latitude and longitude)

and the magnometer allows the quadcopter to be aware of its current orientation to allow

it to know in which direction to start moving.

A diagram of the navigation system and internal and external connections is shown

in Figure 10.

Figure 10: Basic Navigation System Connections

The primary requirements of the navigation processor are:

R1 - Receive instructions from the communications system to determine mode of

operation (manual flight or autonomous flight).

R2 - Receive and pre-process the following data:

• Current position from the GPS module.

• Current orientation from the magnometer.

• Object alerts from the object detection system.

14

• Current height, fuel (battery level), pitch, yaw and role accelerometer and

integral data from the MKFC.

R3 - Send the current flight telemetry (as specified in R2) to the communication

system.

R4 - Process available data as specified in R2 to decide on movements required to

control the MikroKopter.

R5 - Disengage manual control and send control commands to the MikroKopter FC

when in autonomous mode.

R6 - Monitor current system and prepare for autonomous control when in manual

mode.

Each requirement also requires a specific hardware and software design, detailed be-

low. The flow of data to and from NAVPRO is shown in Figure 11.

Figure 11: Navigation Processor Data Inputs and Outputs

15

4.2.1 Requirements 1 and 3 Send and Receive commands and flight data to

the communication system

Communication between Communications Processor (COMPRO) and Navigations Pro-

cessor (NAVPRO) will be via the I2C bus. There is also an option to use the second

asynchronous serial port on the NAVPRO if the loading on the I2C bus becomes too

high, but the I2C bus is the preferred option.

4.2.2 Requirement 2 Receive and Pre-Process Data

Three separate communication methods will be used to allow the NAVPRO to obtain all

data required for autonomous flight as shown in Figure 11. All the current data values

will be stored in RAM for use to fulfil Requirement 4.

As the I2C bus will be used to allow four devices to communicate, timing will be very

important. The COMPRO will act as the master device and will request data from each

device in a predefined sequence at a regular interval. This will ensure the NAVPRO will

have all the data required to make a decision and fly the quadcopter when required.

GPS-320FW GPS Module

The GPS-320FW module utilises an asynchronous serial connection to send and re-

ceive data. Therefore one of the NAVPRO SCI modules will be used to obtain positional

data and initialise the GPS module when needed. The current position will be updated

at 1Hz which is the maximum rate supported by the GPS-320FW. The serial interface

protocol is based on the National Marine Electronics Associations NMEA 0183 ASCII

interface specification which consists of a string of ASCII characters which contain all

relevant positional data. The NAVPRO will decode these messages and extract the cur-

rent position from these.

CMPS-03 Magnometer

The CMPS-03 magnometer will be interfaced via the I2C bus due to the ease of use

and the low refresh rate required.

Object Detection System

The ODS will communicate with NAVPRO via the I2C bus. The Object Detection

16

System (ODS) will send data with required actions (e.g. change in direction, stop) to the

NAVPRO. The NAVPRO will send commands to request data from the object detection

system and to manage the I2C bus. A relatively low data transfer rate, roughly 6 times

per second, will be required to communicate with ODC.

MikroKopter Flight Controller

Communication with the MikroKopter FC will be using the SPI interface. This will

allow the NAVPRO to send control commands to the MikroKopter flight controller and

receive the current battery level, height, nick, roll and yaw accelerometer values and gy-

roscope positions. These values are already sent by the MKFC for debugging using the

MikroKopter tool; these same values will be sent to the COMPRO.

The MikroKopter flight controller software will be modified to output the flight data

and receive control commands over the SPI interface. The control commands will mimic

those sent via the RF transmitter i.e. provide a value for pitch, yaw, thrust and roll.

The software will also contain a function to use either control commands from the PPM

receiver or disable this input and use the NAVPRO.

Communications System

The MikroKopter will receive commands from the COMPRO over the I2C bus. These

commands will be sent periodically.

4.2.3 Requirement 4 - Process Available Data and Decide on Movements

Required to Control the MikroKopter

The NAVPRO will use all the available data to decide on the best course of action to

control the MikroKopter. There are three levels of control required as shown in Figure 12.

The highest level is the Go to Command. This command will be received by the

NAVPRO from the COMPRO and will be the ultimate destination of the quadcopter. It

is made up of three parts: GPS latitude, GPS longitude and height. This will be stored

in a memory location and will be compared the current GPS latitude, longitude, height

and orientation to decide on what action is required.

The next level is the object avoidance. The NAVPRO must make sure there is no

threat to the quadcopter in its current situation to meet the go to command; if there is

it must act to stop to quadcopter.

17

Figure 12: The three levels of control: go to command, object avoidance and basic flightstabilisation

The lowest level is the basic flight stabilisation. This underpins the two layers above

and is used to carry out the go to command and satisfy the object avoidance. Initially

all autonomous movements of the quadcopter will be made by rotating and pitching the

vehicle. A set of control loops based on PID controllers (section 1.2) will be used to

control the pitch, yaw and height of the craft by providing pseudo control values to the

MKFC. The MKFC will stabilise the roll of the vehicle. A block diagram of the control

loops is shown in Figure 13. The ‘system’ block refers to the physical movement of the

aircraft. There may be some options to use the control loops on the MKFC to help

implement this requirement. This will be investigated further.

4.2.4 Requirement 5 Disengage Manual Control and Control quadcopter in

Autonomous Mode

The MKFC has two sets of input command variables for thrust, yaw, pitch and roll:

‘externalStick’ and stick. The ‘externalStick’ set of variables will be used for autonomous

commands and will be set to the values sent over the SPI channel from the NAVPRO.

There will be two methods of engaging autonomous control, through the manual RF

transmitter or via the advanced communications link (see Section 4.3). The software

on the MKFC will be modified to let one of the RF PPM channels toggle autonomous

mode and select whether to use primary or secondary control commands. The MKFC

will then communicate with the NAVPRO which mode it is in. An alternative will be

via the COMPRO. When the COMPRO sends a signal to engage autonomous mode the

NAVPRO will contact the MKFC to disengage manual control, hold position and wait

for further instructions.

18

Figure 13: Control loops used to achieve autonomous flight. (a) yaw: controls thedirection of vehicle (b) pitch: controls the horizontal movement. (c) throttle: controlsthe height of the vehicle

19

4.2.5 Requirement 6 Monitor Current Situation and Prepare for Autonomous

Control

Requirement 5 demands that autonomous mode must be able to be switched on at any

time therefore the NAVPRO will carry out its calculations to maintain the current posi-

tion at all times but let the MKFC regain control via RF.

4.3 Communications

The design of the communications section of the project is in the form shown in Figure 14

and 15.

Figure 14: Transmission Structure of SUAVE communications

Figure 15: Reception Structure of SUAVE communications

The methodology is such that the data taken by the camera is passed to the micro-

controller using the serial output, this data is then stored within the microcontroller. A

large amount of RAM is required to store the data from the camera due to the resolution

and the number of frames created by the camera. Once the data has been compressed,

the data is then output through another serial connection to the GPRS modem or WiFi

module for wireless transmission.

When there is navigation data sent from the base station, the quadcopter has to

receive this information and move appropriately. The data that is received will be a

series of bytes that make up a packet; this packet will then be broken up to obtain the

navigation data. The navigation data will then be transmitted down the I2C to another

Coldfire board and processed to determine what movements the user requests from the

quadcopter.

20


The question arises as to how often objects must be searched for and how often the results

of the searches are returned to the Navigations module. Consideration must be taken as

to the maximum speed and stopping distance of the quadcopter, and the range of the

sensors. For example, if the quadcopter is flying at 5 m s −1 and the sensors have a range

of 1 m, then searching must be performed at least 5 times a second in the direction of

travel. Alternatively, continuous searching may be performed and the results are com-

municated to the Navigation module at least 5 times a second. These calculations take

no consideration of the stopping distance, so the refresh rate may in fact have to be higher.

If the decision is made to only communicate when objects are detected, the problem of

a busy communications bus (assuming a shared bus – the Magnometer uses I2C and the

GPS module uses an Asynchronous Serial link) may delay the transmission. This delay

could prove disastrous for the vehicle. It is due to this problem that continuous searching

will be used for this application and that the Navigation Module will periodically contact

the Object Detection System asking for a status update.

As mentioned in Section 3.4, the Infrared and ultrasound sensors have the possibilities

of variable outputs (be that voltage or pulse width), however, to find a microcontroller

that has the capabilities of multiple ADCs and PWM captures would prove problematic.

To overcome this, one pin could be used as an input, i.e. either a PWM capture pin or a

serial connection for an ADC, and each sensor is then toggled using separate pins. This

has the advantage of using a microcontroller with a lower specification, but now removes

the ability to have continuous sensing in all directions. If, however, distance switching

sensors are used, single pins can be used.

21

5 Equipment

5.1 Flight Control

As the flight controller is key to the ability to perform stable, autonomous flight, a sub-

stantial amount of time was spent deciding whether to build a flight controller or buy an

off-the-shelf model.

The advantage of building a flight controller is the flexibility to meet the exact spec-

ifications of the project. The disadvantage is the substantial amount of time required

to design and construct the flight controller which could be spent on creating advanced

navigation functionality. For this reason, several off-the-shelf flight controllers were con-

sidered using the following factors:

• Ease of integration and modification number and types of input-output ports, re-

programmable, open source.

• Performance Flight history and community opinions, stability etc.

• Cost

Several contenders were considered:

Wolferl 3.1 UAVP - Universal Aerial Video Platform

The UAVP [13] is an international open source project to create a reasonably priced

quadcopter. The flight controller is called Wolferl. Wolferl utilizes three gyros, a 3-

axis linear accelerometer, a compass sensor and a barometric sensor. The addition of

a compass sensor is an advantage over competing flight controllers but there are some

disadvantages:

• A populated and tested Universal Aerial Video Platform” V3.1x Flight Controller

Board can be purchased for £265[14] which is expensive.

• An 8 bit PIC16F876 PIC is the processor for the unit and is heavily utilized already

which would make it difficult to add functionality to the flight controller.

These disadvantages made it unsuitable for the project.

22

Paparazzi

Paparazzi is open source hardware and software platform for autonomous aircraft [15].

It is designed for airplanes but there is evidence that it has been adapted for a quadcopter

[16]. The paparazzi control board is called Tiny [17] and incorporates a GPS module and

a powerful LPC2148 microcontroller. It is available preassembled with GPS module but

no gyros, accelerometers and barometric sensors (IMU) for £160 [18]. To use the Tiny,

an IMU will be required which is likely to raise the total price to an unacceptable level.

The GPS integration is advantageous but there is little example software for quadcopters

available which means the software would have to be written from scratch. The high

price and the lack of a skeleton software made paparazzi unattractive.

MikroKopter

The MikroKopter flight controller (MKFC) [19] is an open source flight controller

which is part of the MikroKopter project. The MikroKopter project includes frame

designs, a flight controller, electronic speed controllers, a magnometer and a GPS based

navigation board yet the latter two are not open source. The MKFC was selected for the

SUAVE project for the following reasons:

• The MKFC is an open source software project which allows the code to be changed

and adapted to suit the needs of this project.

• A high quality software application is available (Flight Tool) for debugging, testing

and changing the flight parameters and settings.

• A strong and enthusiastic community exists [20] which helped ensure the MKFC

met our specifications.

• The MKFC has several synchronous and asynchronous input-output ports which

allow interfacing with external hardware.

• The MKFC costs £170 [21] which is cheaper than other flight controllers especially

considering the high performance evident from various videos and user comments

on the internet [22].

23

5.2 Navigation System Equipment

5.2.1 Central Processing Unit

A central processing unit is required to perform the navigation calculations and control the

navigation peripherals as detailed in Section 4.2. The Freescale Coldfire MCF528CVF66

Microcontroller (MCU) was selected for the following reasons:

• The MCU has a similar specification to the LPC2148 used in the Tiny flight con-

troller which performs autonomous navigation (Section 5.1):

– 32 bit

– 66,80 MHZ clock speed

– 512kb ROM,

– 64kB RAM

• The MCU also has a number of input-output ports which are required for interfacing

with the other systems and peripherals, these are: 1xSPI (synchronous serial port)

3xSCI (asynchronous serial port) 1xI2C (Inter-Integrated Circuit) port.

• A development board was available within the department

5.2.2 GPS Module

Several GPS modules were considered including those used in other autonomous vehicle

projects such as the LEA-4P [16] but proved inhibitively expensive despite good perfor-

mance. After researching alternatives the RF Solutions GPS-320FW was selected [23].

The GPS-320FW was selected due to its excellent specifications, integrated ceramic an-

tenna and a synchronous TTL level interface despite the low price (£24) [24]. It features

-155dBM tracking sensitivity, 5m CEP accuracy (positional error) and a 1Hz update rate

which make it suitable for the SUAVE project.

5.2.3 Magnometer

The CMPS-03 magnetic compass [25] was selected for use as it was used successfully in

a robotics project last year[26]. It can be interfaced with using I2C or by capturing and

decoding a pulse width modulated signal, creating flexibility in the system. The module

also preprocesses data and so outputs the current heading as a number of degrees from

north (0.0o to 359.9o) which simplifies the coding required on the navigation processor.

24

5.3 Communications System

The hardware platforms within the project were chosen with the knowledge that they

would be connected together to work as a whole in the final implementation. Once con-

nected the hardware will have the ability to take video (camera), process the information

(Freescale Coldfire MCF5282CVF66) and transmit wirelessly (GSM modem of GPRS

modem).

5.3.1 Freescale Coldfire Microcontroller

The choice of processing devices used for the project had to fulfil the requirements of both

the communications and other aspects of the project. The physical requirements of the

communications processing device were that it had significant process power, large size

flash, an I2C, 2 SCI ports, TCP/IP stack and a real time operating system[27]. These

are the requirements because receiving video from the camera and transmitting it via

the communications hardware needs to be completed in real time with little delay. The

choices for this were a Freescale Coldfire microcontroller or a Gumstix microcontroller as

they both have high processing power.

The features of this microcontroller can be viewed in Figure 16.

Figure 16: Freescale MCF528x features[28]

The Freescale microcontroller board that will be implemented into the quadcopter

design is a MCF5282CVF66. This is shown in Figure 17.

25

Figure 17: Freescale Coldfire Microcontroller and Development board

The decision for this was a Freescale Coldfire microcontroller. Due to the departments

strong relationship with Freescale these were already being stored within the university

for use within student projects. The MCF5282CVF66 has an excellent learning and

prototyping environment in the form of the Freescale Codewarrior. The choice of micro-

controller was also made quick and easy by the Freescale C & I Microselector tool.

5.3.2 Fargo Maestro - 100 GPRS Modems

The requirement from the GPRS modem is that it has the ability to change the RS232

signal from the microcontroller into a wireless transmission in the format required and

vice versa. The data rates involved have to be high enough to be able to handle a constant

transmission of video data, they should be able to handle RS232 data, and they should

be as small and light as possible.

The GPRS modems that will be used are Fargo Maestro - 100 as these fit the purpose

that is required for the project and have already been bought by the university. The

modem that will be used are shown in Figure 18.

Figure 18: Fargo Maestro- 100 GPRS modems[29]

26

The Fargo Maestro-100 has the following features[30]:

• Dualband GSM 900/1800 MHz.

• Support Data, SMS, Voice and Fax.

• Max Power Output: 2 W (900 MHZ), 1 W (1800 MHz).

• GPRS Class B Class 10 (4Rx+1 or 3Rx+2Tx) at maximum speed.

• SimToolKit Class 2.

• AT command set.

And the following interfaces:

• SIM Holder.

• 15-pin Sub D connector (serial and audio connection).

• 4-pin power supply connector.

• External Antenna.

5.3.3 S103 WiFi Module

The WiFi module that will be used is a S103 WLAN Compact Serial Module as this

is small, light and should automatically do all the conversions required to change the

RS232 output from the microcontroller to the WiFi data transmission and vice versa.

The module is shown in Figure 19.

Figure 19: S103 Wifi module[31]

27

The S103 WLAN Compact Serial Module has the following features[31]:

• UDP version configurable baud rate (9600, 38400, 57600, 115200 bps).

• TCP version configurable baud rate (9600, 38400, 57600 bps).

• Full-duplex (serial data in and out).

• Hardware flow control.

• Firmware upgrade through RS232 port.

• Easy set-up via console or web page.

• LED status and activity indicators for easy installation, monitoring and diagnostics.

• Link to WLAN Access Point (infrastructure mode).

5.4 Surveillance Module and Compression

Deciding to use a camera introduced an interesting set of problems. Firstly not only does

the camera need to be light and robust but it must also have a suitable viewing range.

The biggest challenge will be encoding the video data so that it may be transmitted back

to a base station over a WiFi or GPRS link. The live video quality must be kept as high

as possible and the latency with which the base station receives and decodes the data

must be as low as possible.

There are numerous cheap cameras and web cams on the market. These are mostly

of the CMOS (Complementary Metal Oxide Semiconductor) and CCD (Charged Couple

Device) types. This design helps to keep the cost of these cameras low, however, the

majority of these only have a very limited ability to capture video from a distance. A

second problem is that the video data must be compressed so that it may be transmitted

over a low rate data link.

A second approach is to purchase an integrated system which combines video cap-

ture and compression. Such a device is the CAM-VGA 100 module on offer by Round

Solutions[32]. It is an integrated serial camera board module that can be attached to a

wireless host being used as a video camera or a JPEG compressed still camera. It pro-

vides RS232 serial interface and a JPEG compression engine which acts as a low cost and

low powered camera module for use with GPRS/GSM modules. The main application

of such a device is on mobile phones or PDAs and thus the picture quality and viewing

28

range will limited.

If a readymade system, such as the one described above was purchased, the data rates

would be restrained to those designed by the manufacturer. The solution which offers

the most flexibility, would be to design a camera board module, with our own camera

and a video codec. This would involve buying a CMOS camera board and implement-

ing a video codec. There are a number of codecs which fit our purpose these include:

MPEG4, MJPEG, Strathclyde Compression Transform (SCT), H.263 or H.264. MPEG4,

H.263 and H.264 are all more complex to implement than MJPEG but offer superior com-

pression. Not enough is known about the SCT and some more investigation will need to

be carried out before a final decision is made on which compression technique will be used.


When using the sensing approach, as detailed in Section 3.4, an imaginary protective

barrier could be formed around the quadcopter, and if an object is detected within this

barrier, evasive action is taken. However, this leads to the problem that if the vehicle is

required to navigate a corridor that is narrower than the barrier surrounding the vehicle;

the system would not allow the vehicle to pass and would force it to find a different route.

In this case, using a method that allows the exact distance to be detected would be ad-

vantageous. What needs to be considered is the complexity of the navigation system;

does the system need to adapt its trajectory on-the-fly, or does it stop and re-evaluate

its potential options? Initially it was decided that non-adaptive navigation would be an

easier route to take and if time is sufficient, adaptive navigation will be implemented.

As mentioned in Section 3.4, ultrasound or infrared could be used to sense if an object

was within range of the quadcopter. Ultrasound detecters appear to need a highly re-

flective surface, and also have a poor polar response to flat surfaces, as shown in Figure 20.

Use of an imaging device is, by default, a far more complex option, however, it can

return much more usable results and can allow the navigation module to be more efficient

in its evasive actions. When an object is encountered and the vehicle starts to rotate to

avoid the object, constant information can be passed to the navigation module to inform

it if the object has been cleared. The use of imaging is also very limited; one camera

requires a substantial amount of processing power (compared to Ultrasound or Infrared

sensors). Object detection is also limited to one direction, which means the quadcopter

must rotate if it is to see potentially viable routes. It is for these reasons that distance

29

Figure 20: Polar response of a Parallax Ping Sensor, tested with a 12” square piece ofwhite card[33]

sensing will be used in all directions.

During development, a Microchip PIC microcontroller will be used for the Object

Detection system as to minimise the complexity of having multiple systems running

on the one processor. In order for the Object Detection System to communicate with

the Navigation module, the PIC selected must have the capabilities of I2C or RS232.

The microcontroller must also have room for multiple inputs; for these reasons, the

Microchip PIC16F876 was chosen[34]. A PIC microcontroller has the advantage over

a conventional Microcontroller Development Board (like the Freescale Coldfire board

being used in the Communications and Navigations modules) as it does not have any

unnecessary components (such as DACs, switches) and has a very low power consumption.

30

6 Progress to date

This section details the work accomplished as of 17th December 2008. The work ac-

complished falls into four sections; selection and construction of quadcopter, selection of

navigation equipment and testing, selection of communications equipment and selection

and testing of object detection equipment. Each of these sections is detailed below.

6.1 Construction and Test Flights

The complete MK set was purchased and a kit containing all the components shown in

Figure 21 was received. Building the frame was the first step of construction. The MK

came with preassembled control boards and brushless motor controllers. All the surface

mounted components were already soldered on.

Figure 21: MikroKopter kit before construction

However, several bulkier pieces such as electrolytic capacitors, switches, the baromet-

ric sensor and the header connectors still required soldering. The wiring assembly used

to carry the power and control signals was prepared. All the parts were then connected

together and a successful dry test of the electronics was undertaken. All the separate

components were then brought together and placed on the frame. The propellers were

mounted and a pre-flight check was carried out. Using the MK Tool, the RC transmitter

channels were configured to match the MK receiver and a successful maiden test flight

was made[35]. Figure 22 below shows the MK after construction.

31

Figure 22: Fully constructed MikroKopter

6.2 Selection of Navigation Equipment and Testing

Two core elements of the navigation and control system had to be selected: the standard

flight controller which performs basic stabilisation of the quadcopter and the advanced

navigation system which will add the functionality required to meet the objectives in

Section 1.1.

As the flight controller is key to the ability to perform stable, autonomous flight, a

substantial amount of time was spent deciding whether to build a flight controller or buy

an off-the-shelf model.

To ensure the specifications of the GPS unit, magnometer and microcontroller are

suitable to meet the project objectives several modules were considered as described in

Section 5.2.

6.2.1 Component Testing

Currently only the CMPS-03 magnometer has been tested. It was tested by interfacing it

via I2C with a Softec HCS12E128 starter kit. This starter kit was used due to the avail-

ability of I2C on the microcontroller and the authors familiarity with the board and the

opportunity to reuse I2C code from a previous project. A Freescale PBMCUSLK devel-

opment board with an LCD module was used as an output device to display the compass

heading. The MC9S12E128 drove the LCD module via the Serial Peripheral Interface

32

(SPI). Jump leads were constructed to connect the required pins on the MC9S12E128 to

the CMPS03 and PBMCUSLK. A circuit diagram is shown in Figure 23.

Figure 23: Magnometer test rig schematic

The magnometer functioned as expected and a 3 digit number representing degrees

from North was displayed on the LCD. A possible problem emerged during testing as

when the compass is tilted an error occurs to the heading. The further the magnometer

is tilted from horizontal, the larger the error. This will have to be addressed, possibly

with adjusting the value using the gyroscope values.

6.3 Communications

When confronted with the challenge of communications between a mobile aerial vehicle

and a base station there are many aspects that need to be considered. The data rate,

range, cost and availability were the main properties that were compared when investi-

gating communication systems. Another challenge is finding a processing device that has

the processing power to take the data in, process it and transmit it via some communi-

33

cations hardware. All of the processing has to be completed without a high level of lag

as it needs to be transmitted in real time.

After consideration the choice of communications protocol was reduced to WiFi, GSM

(GPRS), HSDPA and RF. The investigation came to the following conclusions:

• High Speed Download Packet Access (HSDPA) is too expensive to implement due

to the costs of the hardware and the monthly subscription costs for the use of 3G

services. As a final implementation rather than a proof of concept this would be

the ideal choice of communications standard due to its high data rates and large

range. The large coverage is due to the wide availability of 3G, it is available in

most urban areas making it ideal for surveillance use.

• RF is cheap to implement and has a range of up to 10 km. The range is large

enough to control the quadcopter as the battery life is only 10 - 15 minutes which

limits the distance that it can cover. The main problem with RF is that it is not as

readily available as other standards, so only covers the distance from an RF trans-

mitter. Another issue is that the data rate is only up to 10 kbps which is not high

enough for good quality video transmission. The MikroKopter is equipped with a

basic RF receiver that can be used for control, but will not be upgraded for data

communications.

• GSM (GPRS) is cheap to implement due to the maturity of the technology. The

range of GPRS is large as it works over the cellular network so will work anywhere

there is a GSM signal, most urban areas have very good signal quality. The data

rate of the GPRS class 10 modems is 16-24kbps upload and 32-48kbps download.

In theory this will be large enough to send a decent quality video stream. GPRS

offers the ideal balance of range, cost and availability and will be implemented in

this project.

• WiFi is a good choice as proof of concept, as it is relatively cheap to implement

and has a wide enough range for testing purposes. The data rate for the WiFi

transceiver is 11Mbps which is large enough for good quality video transmission.

For proof of concept, this will be used before GPRS is implemented as it has a wide

enough range for testing. WiFi is more suited to close range applications and is

therefore easier to demonstrate at the Trade Fair.

34

SUAVE control will initially use RF as this comes as standard on the MikroKopter.

This will be upgraded to WiFi as this is the best choice for a proof of concept and is

easy to demonstrate. Finally the communications to and from the quadcopter will be

implemented in GSM, this is the best choice of standard for the final implementation of

the project as it increases the possible applications of the quadcopter.


A Sharp GP2Y0D310K Distance Measuring Sensor was obtained and some basic test-

ing was carried out on it. When the sensor was set up in the configuration shown in

Figure 24, it was found that when no object was within range, the output pin was at a

fixed 5 V (that being the supply voltage) and if an object came within range, a pulse was

seen at the output. However, this pulse was only 3 mV in magnitude and as such could

be regarded as zero; these outputs are shown in Figure 25. It should be noted that the

output signal was taken from the pin LED FB, as the pin Vo was very noisy.

Figure 24: Circuit diagram of a Sharp Distance Measuring Sensor in use

The output from the sensor was fed into a PIC16F876 microcontroller and if an object

was detected to be within range of the sensor, an LED would light. As yet, no testing

35

Figure 25: Screen captures of the output pin of the Sharp Distance Sensor

has been done to determine a polar pattern for this sensor.

36

7 Future Work and Goals

7.1 Navigation System

The GPS unit and MKFC will be first tested to make sure they can be interfaced with

and the required data can be sent to and from them. This will be done using the

Freescale MC9S12C32 as the development environment is less complex than the Freescale

MCF528CVF66.

The control loops specified in Section 4.2.3 will then be created in software on the

Freescale MCF528CVF66 for autonomous flight. These will be implemented one at a

time to test their performance, starting with the height then the yaw and pitch.

The first objective will be to achieve autonomous stationary hover at a constant

height. This will then be expanded to include autonomous take off and landing.

The final stage will involve integrating the ODS and COMPRO systems to allow the

quadcopter to avoid objects and go to a GPS position. The control loops will then be

improved to allow stable autonomous flight in an direction.

7.2 Communication System

The design of the communications section of the project has been completed. The future

work required is to implement a bi-directional link using WiFi. This is necessary for

the final implementation of the project because without the ability to communicate the

quadcopter cannot transmit data back to a base station. More specifically the ability to

communicate via WiFi then GPRS is required to advance the range of the quadcopter

and extend the applications that can be completed using this equipment.

The tasks that still have to be completed are:

• Testing of the output of the WiFi module.

• Connect the WiFi module to a laptop wirelessly.

• Testing the range and effectiveness of the WiFi module using the quadcopter.

• Implement an override to stop autonomous mode and enter manual mode.

• Implement the GPRS modems into the quadcopter design in place of the WiFi

module.

37

• Test the output of the GPRS modems.

• Test the effectiveness of the WiFi module using the quadcopter.

Once these are completed, the communications used within the quadcopter will allow

it to be used for various applications.

7.3 Camera Surveillance

Now that a final application has been decided upon the next step is to implement the

camera and coding system. This will then be tested to ensure the ability to encode

and decode the video data while maintaining a reasonable quality. Finally the ability to

transmit the coded data over the communications channel needs to be tested. This final

section will involve a close collaboration with the communications module.


The use of Ultrasound has not been fully explored, but initial explorations show that it

requires a highly reflective surface with which to operate. Also, all suitable ultrasound

detectors researched use PWM[33] as the default output method; as a result this will

increase the complexity of the overall system.

Sensors with a larger range (in the order of 1 m) will be sought and tested. Ideally,

Analogue Range sensors will be used, and converted to Distance switches. This is so that

if time is sufficient, the actual distance between the sensor and object can be realised and

can be used to improve the Navigation module’s reaction to objects.

A communications link between the navigation module and the Object Detection

System will also have to be devised; the link will be either Serial or I2C. To test this, a

simple link will be set up between the main PIC and either another PIC (in the case of

I2C) or a computer (in the case of Serial).

38

8 Conclusion

In order to meet the specifications in Section 1.1, a Gantt Chart was created listing the

main tasks required to complete each objective. This can be found in Appendix B. Cur-

rently the project is on schedule and even some of the work streams are ahead of schedule

such as testing the magnometer (Section 6.2).

The overall system architecture and the individual design of the internal systems has

been finalised and equipment choices have been made. All the equipment required to cre-

ate the autonomous vehicle is now present apart from the camera. Each group member

has planned the work required to implement the design of their individual sections over

the coming semester as shown in the Gantt chart.

The MikroKopter has been constructed and is currently undergoing flight tests to

judge the potential performance of the quadcopter and allow experimentation with the

flight controller parameters. This period will also allow the team to improve their piloting

skills in order to meet the upcoming milestone of manually controlled flight.

Four weeks have been set aside at the end of semester two (6th April 2009 to 3rd May

2009) to allow for the final report to be written and the exhibition at the trade show

event to be planned.

39

References

[1] BBC, Volcano scientist wins accolade.

http://news.bbc.co.uk/1/hi/scotland/edinburgh and east/7735284.stm

Accessed: 26th November 2008

[2] MikroKopter, en / MikroKopter (2008)

http://www.mikrokopter.de/ucwiki/en/MikroKopter/

Accessed: 15th December 2008

[3] RC Helicopter, Quad rotor helicopter design

http://www.rchelicopter.com/category/rc-helicopter-construction-design/rc-helicopter-

quad-rotor-design


[4] Quadcopter, Quadcopter Home (2008)

http://www.quadcopter.org

Accessed: 11th December

[5] Petropolakis, Dr L., EE405 Robotics Notes, (University of Strathclyde, 2007)

[6] Ogata, Katsuhiko, Modern Control Engineering, (Prentice Hall, 2002)

[7] Shaw, John, The PID Control Algorithm (2006)

http://learncontrol.com/pid/description.htm


[8] Radhesh PID Controller Simplified (2008)

http://radhesh.wordpress.com/2008/05/11/pid-controller-simplified/


[9] IEEE, IEEE 802.11 WIRELESS LOCAL AREA NETWORKS (2008)

http://www.ieee802.org/11/

Accessed: 3rd December 2008

[10] Mobile Phones UK, GPRS (General Packet Radio Service), HSCSD & EDGE

(2008)

http://www.mobile-phones-uk.org.uk/gprs.htm


[11] SHARP, GP2Y0D310K Datasheet (2006)

40

[12] RoboRealm, Obstacle Avoidance (2008)

http://www.roborealm.com/tutorial/Obstacle Avoidance/slide010.php


[13] Guindehi, Amir, Universal Aerial Platform (2008)

http://uavp.ch/moin/FrontPage


[14] Quadroufo, UAVP Flight Controller + 5 Sensors

http://www.quadroufo.com/product info.php?products id=29


[15] Community, Paparazzi Paparazzi (2008)

http://paparazzi.enac.fr/wiki/Index.php/Main Page


[16] –, Booz (2008)

http://paparazzi.enac.fr/wiki/Booz


[17] –, Tiny V2 (2008)

http://paparazzi.enac.fr/wiki/Tiny v2


[18] PPZUAV, Tiny (2008)

http://ppzuav.com/osc/catalog/product info.php?cPath=4 2&products id=35 Ac-

cessed: 17th December 2008

[19] french-copter, IngoBusker Translated by, FlightController Manual - English.

MikroKopter.de (2007)

http://www.mikrokopter.de/ucwiki/en/FlightCtrlManual


[20] Busker, Holger Buss & Ingo, MikroKopter Forum - International Area.

http://forum.mikrokopter.de/forum-17.html


[21] Schweiz, Quadrokopter Flight-Ctrl V1.3

http://www.flyinghigh.ch/index.php/home.html?page=shop.product details&flypage

=flypage.tpl&product id=4&category id=2


41

[22] –, MikroKopter - Von der ersten Schraube bis zum Flug

http://www.mikrokopter.com/ucwiki/VideoAbspielen?id=106


[23] Solutions, RF, GPS-320FW Datasheet (2008)

[24] RF Solutions, Board Level GPS Receivers (2007)

http://www.rfsolutions.co.uk/acatalog/Board Level GPS Receiver Module.html


[25] Rapid, CMPS-03 Datasheet (2003)

[26] Ali Alvi et al., Advanced Robot Control. (University of Strathclyde, 2008)

[27] Freescale Semiconductor, MCF5282 Integrated Microcontroller Product Brief

(2006)

[28] Freescale Semiconductor, MCF528X Product Summary Page

http://www.freescale.com/webapp/sps/site/prod summary.jsp?code=MCF528X&fsrch=1


[29] ECT soft, Hardware Specifications

http://www.ectsoft.net/ect-products.html

Accessed: 1st December 2008

[30] RF Solutions, GSM20 and GSM 100T Modem Datasheet (2004)

[31] Wireless Products, S103 WLAN Compact Serial Module Datasheet (2007)

[32] Solutions, R, CAM-VGA100 User Manual (2004)

http://www.areasx.com/files/articoli/8122/CAM-VGA100-User-ManualV2-0.pdf


[33] Parallax, PING))) Ultrasonic Distance Sensor (#28015) Datasheet (2008)

[34] Microchip, PIC16F87X Datasheet (2001)

[35] Suave Project Blog, Construction and test flight

http://suave.rawxing.org/archives/84


42

A Risk Assessment

SPECIFIC PROJECT RISK ASSESSMENT FORM Section A Department Electronic and Electrical Engineering. Project/Works Title Semi-autonomous unmanned aerial vehicle. Description of Work Activity Build and test quad rotor RC autonomous helicopter. Section B Description of significant hazards: (e.g. slipping/tripping; fire; work at height; pressure systems; electricity; dust; fumes; manual handling; noise; poor lighting; low temperatures; vehicles; moving parts of machinery; etc) Flying vehicle; possibility of fire and fumes; rotating propellers. Section C Groups who may be at risk: Staff/Students with Special Needs ❒ Inexperienced Staff x Academic Staff ❒ Office Staff ❒ Maintenance Staff ❒ Technicians ❒ Postgraduates ❒ Undergraduates ❒ Lone Workers ❒ Contractors ❒ Visitors ❒ Members of Public x Other ❒ Specify _________________________

43

Section D Assess the foreseeable risks from the hazards identified and state the controls to be implemented to eliminate or minimise the risk where it is reasonably practicable to do so. Give priority to those risks which affect large numbers of people and/or could result in serious harm. Apply the following principles, if possible, in the following order: Remove the risk completely Try a less risky option Prevent access to hazard (eg guarding) Organise work to reduce exposure to hazard Issue personal protective equipment Provide welfare facilities (eg washing facilities for removal of contamination) This section should be used to specify the scheme of work which should include details of the significant controls, safety procedures and working methods which need to be adhered to. It should also refer to existing safety procedures, eg already contained in the departmental safety regulations or University local rules. The following should also be considered in the risk assessment process: Do the control measures - meet the standards set by the legal requirements? - comply with a recognised industry standard? - represent good practice?

- reduce risk as far as reasonably practicable? Flying Vehicle- Vehicle will be flown outdoors and indoors. When flying indoors the room will be closed to the general public. During outdoor testing an open area that is closed to the general public will be sought. Good weather conditions are required i.e. no wind or rain. Public liability insurance will be taken out Fire/ Fumes- Lithium polymer batteries are being used; these are dangerous if handled incorrectly. Manufacturer’s guidelines regarding recharging will be adhered to. A balanced charger with a timer cut-off has been purchased. Non-flammable surface is required (Pyrex bowl with sand). Fire extinguishers of class B and C are at the end of the hall if needed. The battery will be disposed of if damaged. Rotating Propellers- All people will be kept from being close to the vehicle once the motors have been started. Safety goggles will be worn when the vehicle is being tested. If required a guard will be in place over the propellers. The transmitter instructions for activating the vehicle will be adhered to.

44

Section E Accreditation Assessor: Signature Print Date Supervisor: Signature Print Date Signature of all persons receiving a copy of this risk assessment. Philipp Karagiannakis 10/12/2008 Signature Print Date Colin McGuire 10/12/2008 Signature Print Date Niall McKenzie 10/12/2008 Signature Print Date Neil Sinclair 10/12/2008 Signature Print Date Signature Print Date Signature Print Date Signature Print Date Date of next assessment(s) 1. 2. 3. Note:

1. The completed risk assessment form must be kept by the assessor and supervisor with a copy given to Departmental Safety Convener.

2. The assessment must be reviewed and where appropriate revised if there is reason to suspect it is no longer valid or there has been a significant change to the task procedure.

3. The responsibility for ensuring that the risk assessment is suitable and sufficient lies with the Supervisor not with the Departmental Safety Convener.

4. A copy of this assessment must be retained by the Department for as long as is relevant (in case of the form being used as a COSHH risk assessment this must be kept for 30 years and in some cases 40 years after the project or works are terminated).

46

B Gantt Chart

SUAVE - Gantt Chart

19/12/08 1/1

Name Start Finish November 2008 December 2008 January 2009 February 2009 March 2009 April 2009

03 10 17 24 01 08 15 22 29 05 12 19 26 02 09 16 23 02 09 16 23 30 06 13 20 27

Offical Project Milestones & Paperwork 08/11/2008 03/05/2009

Write Final Report 06/04/2009 03/05/2009

Prepare Interim Presentation 01/02/2009 09/02/2009

Write Interim Report 08/12/2008 21/12/2008

Statement of Intent 08/11/2008 08/11/2008

Final Report & Presentation 03/05/2009 03/05/2009

Individual Interviews 14/11/2008 14/11/2008

Individual Interviews 19/02/2009 19/02/2009

Interim Presentation 12/02/2009 12/02/2009

Interim Report 21/12/2008 21/12/2008

Subsystem Development 03/11/2008 06/04/2009

Video System 08/12/2008 06/04/2009

Investigation of Video Codec 08/12/2008 22/12/2008

Video Codec Implementation on Board 22/12/2008 02/02/2009

Video Codec Implementation at the Groun 05/01/2009 16/02/2009

Integration with Communications System 22/12/2008 06/04/2009

Skeleton Vehicle 03/11/2008 21/12/2008

Order Parts 09/11/2008 09/11/2008

Quadcopter Purchase Decision 03/11/2008 17/11/2008

Vehicle Construction and Test Flights 16/11/2008 08/12/2008

Tuning for manually controlled stable fligh 08/12/2008 21/12/2008

Manually Controlled Stable Flight 21/12/2008 21/12/2008

Object Detection System 11/11/2008 06/04/2009

Investivative Options 11/11/2008 21/01/2009

Simple test of IK 01/12/2008 19/12/2008

Test of Ultrasound 26/01/2009 11/02/2009

Test of IR 26/01/2009 11/02/2009

Choice of Sensor 11/02/2009 11/02/2009

I2C/Serial Link 19/01/2009 30/01/2009

I2C Finished 30/01/2009 30/01/2009

Integration with Navigation 11/02/2009 06/04/2009

Basic Detection 13/03/2009 13/03/2009

Autonomous Flight and Navigation 22/12/2008 05/04/2009

GPS & Magnomoter Testing & Integration 22/12/2008 02/01/2009

Design and Implement Control Algorithms 04/01/2009 20/02/2009

Integrate Object Detection and Communic 15/02/2009 06/03/2009

Achieve Autonomous Flight Between Two 30/03/2009 30/03/2009

Design and Implement Navigation Algorith 23/02/2009 05/04/2009

Acheive Stable Autonomous Hover 20/02/2009 20/02/2009

Bi-directional Data Communication 11/11/2008 06/04/2009

Communication Standards Comparison 11/11/2008 17/11/2008

WiFi Hardware Comparison 17/11/2008 01/12/2008

GSM Hardware Comparison 17/11/2008 01/12/2008

Microcontroller Decision 03/12/2008 12/12/2008

Exams 19/12/2008 25/01/2009

WiFi Implementation 12/12/2008 08/02/2009

Testing the output from the WiFi modul 12/12/2008 19/12/2008

Connecting the WiFi module wirelessly t 25/01/2009 27/01/2009

Obtain the navigation data from the pac 27/01/2009 02/02/2009

Pass the navigation data though the IIC 02/02/2009 03/02/2009

Testing the range and reliability of the 03/02/2009 08/02/2009

Implement an override to stop autonom 03/02/2009 08/02/2009

GPRS Implementation 09/02/2009 06/04/2009

Testing the output from the GPRS mod 09/02/2009 16/02/2009

Transmission from the modems 16/02/2009 26/02/2009

Reception to the modems 26/02/2009 06/03/2009

Obtain navigation data form the packets 06/03/2009 20/03/2009

Pass the navigation data though the IIC 20/03/2009 27/03/2009

Testing the range and reliability of the G 27/03/2009 03/04/2009

Implement an override to stop autonom 04/04/2009 06/04/2009

47

Interim Report

Documents

Transcript of Interim Report