Master's Thesis

MASTER'S THESIS

Autonomous Takeoff and Landing for Quadcopters

Robert Lindberg 2015

Master of Science in Engineering Technology Space Engineering

Luleå University of Technology Department of Computer Science, Electrical and Space Engineering Abstract

In this project an automated takeoff and landing system for quadcopters was devised. This will make unmanned aerial vehicles (UAVs) less dependent of human supervision which could improve for example swarms of quadcopters where humans cannot control all in detail. Quadcopters are used due to their mobility and ability to hover over a specific location, useful for surveillance and search missions. The system is self-contained and real time processing is done on board. To make the project possible, software for an onboard computer had to be developed and put on the quadcopter. The onboard computer is controlled from a ground station which can give high level commands such as takeoff, land and change altitude. Experiments were conducted in a laboratory environment to measure the effectiveness of the takeoff, hovering, and landing commands. The parameter used to control the sensor fusion, the time constant in z direction, was found to have an optimal value of 3.0 s. When tracking the desired altitude the root mean square error is in the order of a few centimetres.

ii Acknowledgements

I would like to thank my supervisor Dr. Jan Carlo Barca at Swarm Robotics Laboratory and Monash University for giving me the opportunity to doing an interesting research project while also experiencing a new country. Dr. Hoam Chung for the expertise and help you have given me throughout the project. Senthooran Ilankaikone for the all the time you spent helping me when I needed an extra hand and for all the ideas to make this project possible, even though we did not get a dancing pole in the lab. I would also like to thank Stiftelsen BjörnWahlströmsfond and Angpan-˚ neföreningensForskningsstiftelse for the financial support in forms of schol- arships during my time in Australia. Also to my parents who have supported me during my studies as well as and helping to move and carry my stuff around. Everything from clearing out my apartment in Kiruna at -40 ◦C to carrying sofas in Melbourne at +30 ◦C. Finally to my friends, both new and old, that made the trip to Australia a memory for life.

iii Contents

Abstract ii

Acknowledgements iii

1 Introduction 1 1.1 Background ...... 1 1.2 Research Questions ...... 1 1.3 Thesis Structure ...... 2

2 Methodology 3 2.1 Construct a Conceptual Framework ...... 3 2.2 Develop a System Architecture ...... 3 2.3 Analyze and Design the System ...... 4 2.4 Build the (Prototype) System ...... 5 2.5 Experiment, observe, and evaluate the system ...... 5

3 Literature Review 6

4 Initial System Overview 8 4.1 Connections ...... 8 4.2 Mission Planner ...... 10 4.3 MAVLink ...... 10 4.4 PuTTY ...... 10

5 Design and Development 11 5.1 Overview and Connections ...... 11 5.2 Sonar ...... 13 5.2.1 Mounting ...... 13 5.2.2 Calibration ...... 13 5.3 ArduPilot Mega ...... 14 5.3.1 Setup ...... 16 5.3.2 APM Software ...... 17 5.3.2.1 Sonar ...... 17 5.3.2.2 Sensor fusion ...... 18 5.3.2.3 Custom mode ...... 19 5.4 BeagleBone Black ...... 21 5.4.1 Mounting ...... 21 5.4.2 Setup ...... 21 5.4.3 BBB Software ...... 22

iv 6 Experiment Design and Results 27 6.1 Optimal Time Constant for Frame Setup ...... 28 6.2 Optimal Time Constant for Free Flying ...... 34 6.3 Target Altitude for Free Flying ...... 38

7 Conclusions 42

8 Future Research 43

Appendix 48

v List of Figures

1 The Xaricraft x650v8 quadcopter...... 8 2 The initial system as it was before any modifications. . . . . 9 3 Overview of the software and protocols...... 9 4 Overview of the autonomous system...... 12 5 Mounting of the sonar on the back of the quadcopter. . . . . 13 6 Plotted calibration results for sonar...... 14 7 Custom mode flow chart...... 20 8 Mounting of the BBB on top of the quadcopter...... 22 9 pc flow chart...... 24 10 apm flow chart...... 24 11 input flow chart...... 25 12 cmd flow chart...... 26 13 The frame used for the experiments...... 29 14 RMS distance average between sonar altitude and target altitude according to which the optimal value for TC Z should be about 3 s...... 32 15 RMS distance average between filtered altitude and target altitude according to which the optimal value should be somewhere between 3 s and 7 s...... 32 16 Average number of oscillations per minute. Higher value of TC Z results in less oscillations...... 33 17 Quadcopter average takeoff time for each experiment. The takeoff time does not seem to be noticeably affected by TC Z. 34 18 Quadcopter average landing time for each experiment. The landing time does not seem to be noticeably affected by TC Z. 35 19 The setup for the free fly experiments...... 36 20 RMS distance average between sonar altitude and target altitude for different target altitudes. Higher target altitude increases the average distance between the quadcopter and target altitude during the flight...... 39 21 Average takeoff time for different target altitudes. Increased target altitude results in decreased takeoff time...... 40 22 Average landing time for different target altitudes. Increased target altitude results in increased landing time...... 41 23 Average number of oscillations per minute for different target altitudes...... 41

vi List of Tables

1 Calibration results for sonar. Bold values are above the minimum distance and are the ones used for the calibration. . . . 15 2 Results from sonar measurements. Bold values are the lowest value for each column...... 31 3 Results from filter measurements. Bold values are the lowest value for each column...... 31 4 Results from sonar measurements for different TC Z values. Bold values are the lowest value for each column...... 37 5 Results from filter measurements for different TC Z values. Bold values are the lowest value for each column...... 37 6 Results from sonar measurements for different target altitudes. Bold values are the lowest value for each column...... 38 7 Results from filter measurements for different target altitudes. Bold values are the lowest value for each column...... 39

vii List of Equations

1 Sonar distance-voltage dependency ...... 14 2 Complementary ﬁlter ...... 18 3 Position error ...... 19

viii List of Acronyms

AN Analogue APM Ardupilot Mega 2.5 BBB BeagleBone Black ESC Electronic Speed Control GND Ground IR Infrared IMU Inertial Measurement Unit MP Mission Planner MAVLink Micro Air Vehicle Communication Protocol RMS Root Mean Square SLAM Simultaneous Localization And Mapping

ix 1 Introduction

This research is about devising an autonomous takeoff and landing system for quadcopters. An autonomous system would reduce the need of human supervision and would therefore increase the possible fields of use. This is a first step to develop a fully autonomous system that could be used for e.g. surveillance or search and rescue missions. No human supervision means the system can be active on a constant basis and also reducing the risk of human mistakes. This is also essential for swarm robotics where it is not possible to control every unit in detail. The system is required to work in an indoor environment and therefore no GPS or barometer can be used. The reason a barometer cannot be used is because it measures air pressure and the turbulence from the quadcopter may give unreliable results. The system is also a first step to implement a custom mode that can be modified further in the future to implement more functions. The final goal for the quadcopters are to be able to land and takeoff to a specific height in unknown terrain, so no help such as markers or maps have been used.

1.1 Background

For the ﬁrmware used on the autopilot there are already autonomous takeoﬀ and landing functions available when using waypoint navigation. The problem with this is that it requires an active GPS connection to work and since that is not an option for this project new functions had to be devised.

1.2 Research Questions

Three research questions were devised to guide the course of the project. • How to set and reach a target altitude with the quadcopter? • How to make the quadcopter hold the altitude until further notice? • How to make the quadcopter perform a safe landing?

1 1.3 Thesis Structure

Chapter 1 is this short introduction to the problem and which research questions that is expected to be answered during the course of the research. Chapter 2 is about the research methodology used to make sure the research results are valid. Chapter 3 offers a literature review where previous work are presented. Also why this research is important and what problems there are. Chapter 4 provides a short explanation of the functions of the system before the modifications. It also explains the software used to help in this project. Chapter 5 describes the design process and final design of all the modified parts of the system. This also includes both the development and how everything was calibrated and set up to work properly. Chapter 6 presents the experiments made to verify the research questions.

2 2 Methodology

A research methodology was adapted to increase the chance of success by following a guideline on how to proceed with the research. A System De- velopment Research Methodology [1] was selected as it has been proven to work in earlier research made by people in the Swarm Robotics Laboratory which therefore also have experience working with it. It provides ﬁve steps to follow during the research. 1. Construct a Conceptual Framework 2. Develop a System Architecture 3. Analyze and Design the System 4. Build the (Prototype) System 5. Observe and Evaluate the System

2.1 Construct a Conceptual Framework

The first step of the methodology is to explore the field and identify relevant research questions [1]. This should be done by reviewing relevant literature, but since much in the field is done by hobbyists it is also important to study and learn from the work they present. After the significance of the questions has been justified they should be in focus for the rest of the research. For this case the important difference compared to previous work done with autonomous takeoff, hovering and landing is that previous both GPS and barometer had been used. For this research only a sonar sensor was used in addition to the inertial measurement unit (IMU) to fulfil the requirements. The research was also aimed to modify an existing firmware to make it a platform for further research, something that might have been hard to do without a modified firmware.

2.2 Develop a System Architecture

In the second step the system requirements and constraints should be spec- iﬁed. The requirements were described as follows for the system on the quadcopter: • Takeoﬀ

3 – A command to make the quadcopter reach a speciﬁed height and keep it there until further notice. – The height should be possible to verify. • Landing – A command to make the quadcopter land safely. – Verify landing • The system should work in real time • No markers or motion capture system should be used • Only onboard sensors should be used • All processing should be real time and on board • The system should be able to be calibrated

2.3 Analyze and Design the System

The third step is about analysing and designing the system in relation to scientific and technical knowledge in the studied domain. Various alternatives should be evaluated which for this research meant different alternatives for altitude measurements were considered. A sonar and an IR sensor were tested and compared. Much of the hardware of the design was already decided since the quadcopter were already built such that the autopilot should be an ArduPilot Mega 2.5 (APM) and that the on board computer should be a BeagleBone Black (BBB), although the communication between the APM and BBB was not finalised. That is also the case for the communication between the quadcopter and the ground station as well as which ground station that should be used. In terms of software development this step was used to decide which functions that were needed and what parts that should be on the BBB and on the APM respectively.

4 2.4 Build the (Prototype) System

As the fourth step a prototype system should be built to test the system in a real-world setting. This makes it possible to demonstrate the functions and can provide advantages and disadvantages of the system [1]. The building phase included several steps to make sure each component was working before putting everything together. First the BBB and APM inte- gration was made using a USB cable to make it as simple as possible. Another USB cable was connected to the BBB from a PC for direct communication from the ground station. When both communication lines were confirmed to work, the development of functions for both BBB and APM could proceed simultaneously. When the components were working as intended, both USB cables were removed to finalise the design. For the connection between the BBB and the APM it was replaced by a serial connection that utilised the UART ports on both components. The communication link between the BBB and the ground station was replaced with a wireless connection to ensure the quadcopter could fly without constraints.

2.5 Experiment, observe, and evaluate the system

The final step was to test and evaluate the system in relation to the requirements specified earlier. This was made by building a frame that could test the ability to hold the altitude and measure the oscillations without risking the quadcopter to crash before it had been tested enough. The second part of the experiment phase was a free fly test where an operator would control the quadcopter in terms of roll and pitch while the altitude was fully monitored and controlled by the autonomous system. Both experiments resulted in data that were analysed to find the optimal parameter values. Some free fly tests for optical observations were also made.

5 3 Literature Review

There are two main types of UAV control today, piloted and autonomous. Pi- loted UAVs are controlled by a human operator in real time while autonomous UAVs generate low-level flight commands in response to high level goals [2]. No matter what type is used there are cases where a partly autonomous system is necessary to ensure the safety of the UAV and the surroundings. Three examples are loss of communication link, hardware/software errors, and GPS failure [2]. In any of these three cases a pilot could lose control of the UAV and an autonomous system could save the UAV. The next step is to include the UAVs in a swarm to faster be able to cover a larger area. Today the most advanced UAVS is often controlled by one or more ground operators, but as they become cheaper and more capable it is not possible to have multiple operators for each UAV. By improving the autonomous capabilities the ground operators can focus on controlling the swarm instead of each individual unit [3] Similar research has already been done in the field, e.g. where the IMU for the APM 2.5 is tested together with a sonar [4]. The APM integrate IMU was compared against an external YEI 3 Space Sensor with the conclusion that the integrated one was superior. According to the conclusions the root mean square (RMS) error for the integrated IMU was less than 1◦which should be enough for the course of this research. Since something need to be able to measure the distance to the ground several options were investigated. Two of the most popular systems due to being relatively cheap is sonar and infrared (IR) sensor. The advantages and disadvantages for each of the sensors are discussed by Prattico et al [5]. Since IR sensors are using a narrow beam that is reflected and then observed it means it can have great resolution when observing the surroundings. Sonars on the other hand have a beam width that is varying with distance and is therefore difficult to know exactly where the object is relative to the sonar [5]. A disadvantage for the IR sensor is that certain surfaces such as mirrors and glass are impossible to intercept [5]. Vision based landing using different types of cameras has also been used in several cases [6], [7], [8], [9], [10]. Although vision based systems opens up for more possibilities of more accurate surface mapping, they also comes with some disadvantages. Many are dependant on landmarks or markers and the systems are often heavy, expensive and some also requires high computational cost. All this should be avoided in this project which means it should be a

6 self contained, real time system. This means another onboard computer has to be used in addition to the APM, something that has not be overly explored in past research.

7 Figure 1: The Xaricraft x650v8 quadcopter.

4 Initial System Overview

The initial platform consist of a Xaricraft x650v8 quadcopter that had been equipped with an APM autopilot, shown in Figure 1. The autopilots main functions are to execute commands that are given by the ground operator and stabilise the quadcopter. Since the goal of the thesis was to make the autonomous system to work on this already working manual system, ﬁrst thing to do was to reach an understanding of those parts before moving on to the development, shown in Figure 2. This also meant a couple of software and protocols had to be understood and used without any modiﬁcation of the software or protocol itself, shown in Figure 1

4.1 Connections

A receiver is connected to the input side of the APM with ﬁve connectors that control roll, pitch, yaw, throttle, and ﬂight mode. On the output side four electronic speed controls (ESC) are connected to allow the APM to individually control each motor. A battery is powering the system and is connected directly to each ESC. The APM is powered through the ESCs that are connected to the outputs.

8 Figure 2: The initial system as it was before any modiﬁcations.

Figure 3: Overview of the software and protocols.

9 4.2 Mission Planner

Mission Planner (MP) version 1.3.9 is a Windows based ground station software for APM which was used for the main part of the research [11]. It was used to calibrate the APM, giving ARM/DISARM commands, and download log files from it. It is also collecting live data from the APM which could be used during debug. The live data was also stored in a log file that could be analysed after flight.

4.3 MAVLink

Micro Air Vehicle Communication Protocol (MAVLink) is the protocol used by the APM for communication with the ground station [12]. It is a header- only library developed for use of micro air vehicles. Messages are sent over a serial link after they have been packed as C-structures. The message structure of the MAVLink message can be summarised as done by Balasubramanian [13]. 1. Message header 2. Message length 3. Sequence number 4. System ID - The system sending the message 5. Component ID - The component sending the message 6. Message ID - Type of message 7. Payload - The message information or command 8. Checksum Important to note is that system ID can be used to identify individual systems which means the system is scalable and can work within a swarm.

4.4 PuTTY

PuTTY is a client program used to connect and communicate with the BBB from a separate PC [14]. After connection has been established via SSH, it is possible to use the Ubuntu terminal on the BBB.

10 5 Design and Development

When familiarised with the existing system and software tools the development and modiﬁcations of the system could start. This section describes what have been done to make a working system, both in terms of setup and development. It starts with a short overview before going into details for each component.

5.1 Overview and Connections

Refer to Figure 4 for how everything is connected in the modified system. Note that everything in Figure 2 are still connected but not presented again in Figure 4. The core of the autonomous system is the BBB that supple- ments and instructs the APM via a serial communication. This is done by connecting the pins of UART 4 on the BBB to the telemetry port of the APM. Since BBB is using 3.3 V while APM is using 5 V a level converter had to be used in between. The baud rate is initially set to 57600 as this is the default setting for the APM when using the telemetry port. A sonar for altitude measurements was connected to the A0 port of the APM which consists of a 5 V output, ground, and signal in. This was connected to +5, GND (ground), and AN (analogue) respectively on the sonar which means the sonar output is 5 V analogue. Two separate wireless connections was used to communicate with the ground station. All automatic MAVLink communication was done via a XBee network. The Xbee router was connected to UART 1 on the BBB and the XBee communicator was connected to the USB port of the PC running the ground station. The baud rate was set to 57600 here as well. In addition to the wireless XBee connection an ad hoc wireless connection was also used between the ground station PC and the BBB. This was used for sending manual input commands to the BBB while flying e.g. to take off, change altitude and land. It also made it easier to access and upload new firmware to the BBB since it could be used instead of the USB cable otherwise needed. A USB dongle was connected to a USB hub which was connected to the USB port of the BBB. Another USB dongle was connected to the PC.

11 Figure 4: Overview of the autonomous system.

12 Figure 5: Mounting of the sonar on the back of the quadcopter.

5.2 Sonar

The sonar used is a LV-MaxSonar-EZ1 High Performance Sonar Range Finder. It provides distance with 2.54 cm resolution from 15 cm to 645 cm. A 5 V input was used together with an analogue output which yielded about 9.8 mV per resolution step [15].

5.2.1 Mounting

The sonar was mounted on the quad, 19 cm above the ground, 16.5 cm behind the centre of the quadcopter and aligned with the centre in the pitch axis direction, see Figure 5. The sonar was attached on a plate using four small double-coated adhesive soft pads that except for holding it in place also worked as vibration dampeners to further reduce noise induced by vibrations. The reason for the positioning was to put it as far away as possible from the motors and the rest of the electronics to avoid interference. This includes both sounds from the motors as well as electrical interference.

5.2.2 Calibration

The sonar was calibrated by using a laser distance measurer to measure the exact distance while recording the sonar voltage level for the same distance.

13 Sonar Calibration 4

3.5

2.5

1.5 Distance (m)

0.5

0 0 0.5 1 1.5 2 2.5 3 Voltage (V)

Figure 6: Plotted calibration results for sonar.

The results are presented in Table 1. Main focus for the calibration was distances less than 2 meters since the quadcopter was constrained to fly lower than that during the tests due to the distance from the floor to the ceiling. Some of the measurements were made for distances shorter than the minimum distance of 15 cm and it can be seen how the voltage level is changing unexpectedly for those values in Table 1. Therefore only values above 15 cm was used for the calibration. After the values had been plotted in Figure 6, a linear dependency could be assumed and an equation was derived by using a first order polynomial curve fit resulting in f(x) = 1.27x + 0.05 (1) where f(x) is the distance in meters and x is the voltage level of the sonar output.

5.3 ArduPilot Mega

The auto pilot is responsible for all low level commands when ﬂying and for this project the ArduPilot Mega 2.5 was used. The base ﬁrmware installed

14 Table 1: Calibration results for sonar. Bold values are above the minimum distance and are the ones used for the calibration.

Voltage (V) Distance (m) 0.109 0.141 0.110 0.076 0.111 0.167 0.129 0.188 0.139 0.209 0.167 0.256 0.227 0.326 0.246 0.369 0.325 0.463 0.346 0.496 0.366 0.556 0.446 0.606 0.524 0.717 0.662 0.875 0.782 1.023 0.982 1.280 1.160 1.524 1.258 1.622 1.400 1.819 1.476 1.930 1.655 2.141 1.788 2.325 1.990 2.570 2.242 2.896 2.862 3.673

15 is the ArduCopter 3.15 and all modiﬁcations during the project were made and based on this ﬁrmware.

5.3.1 Setup

Before the APM could be used the following had to be calibrated [16]. • Frame type • Compass Calibration • Accelerometer Calibration • Radio Calibration • Flight Modes All of the calibrations were made using the Mission Planner software with the APM mounted on the quadcopter. Even though not all parts will be used by the system, everything were calibrated. This is done to avoid problems when arming the quadcopter since Mission Planner has a pre-arm check that prevents arming if anything is not calibrated.

Frame Type

The frame type should be set to reﬂect the arm conﬁguration of the quadcopter, which in this case is the “X”-type.

Compass Calibration

The compass was not used in this project but was still calibrated for reasons mentioned above and also in case it will be needed in the future. The calibration was done by using “Live calibration” which means the correct orientation will automatically be found by slowly rotating the APM so each side points down towards the ground for a few seconds each.

Accelerometer Calibration

The calibration of the accelerometers was done by putting the quadcopter on all six sides in order (standing, left, right, front, back and top) and let it register each direction. This will compensate for if the APM is not mounted perfectly aligned with the rest of quadcopter.

16 Radio Calibration

Radio calibration is to let the APM learn maximum, minimum and centre position of the sticks on the transmitter. This is done by moving all the sticks to their maximum positions and before ﬁnishing leaving them in the centre position.

Flight Modes

It is possible to change the flight mode with sticks and buttons on the transmitter and this is set up in the flight modes menu. This was used as a safety precaution to make it possible to switch to a standard flight mode in case the modified one did not perform as expected.

5.3.2 APM Software

ArduCopter 3.15 is a fully functional firmware that can be used when flying the quadcopter by manual control or by GPS based waypoint navigation. However, to implement an autonomous takeoff and landing function some modifications had to be made for different parts of the firmware.

5.3.2.1 Sonar

By default in the firmware version used, the sonar data was sampled but only used on board without being sent to the ground station. MAVLink has one message type intended for this type of data named rangefinder that could be used, but since this message lack any type of time stamp for the data it had to be modified slightly to include that. The time is taken from the internal clock of the APM. The new message that includes time stamp was generated by using the MAVLink Generator [17]. The rangefinder message was then added to the data stream already transmitting the attitude data from the APM. One of the main changes to the firmware was that previously most of the altitude data had been based on the internal barometer. Since all of the flying during this project was to be carried out indoors the barometer will not give accurate values due to turbulence created by the quadcopter itself when flying in contained areas. Therefore everything relying on barometer measurements had to be changed to rely on sonar measurements instead.

17 To make this possible, the function that handles the sampling located in the Rangefinder.cpp library had to be rewritten. Previously the sampling was handled by a scheduler that updated the rangefinder with a preset frequency. The sampled value was then only available in the main code and not for the external libraries that previously had been using barometer altitude data. To solve this the latest value is now stored as a variable in Rangefinder.cpp as well as a variable in the main code like before. This makes it possible to retrieve the latest value by reading the variable in Rangefinder.cpp from anywhere, including external libraries, while still maintaining the functions in the main code that are using the old variable. Since the sonar measures the absolute distance and therefore will be affected by change in attitude by the quadcopter (in contrast to a barometer) compen- sation for this was implemented and briefly tested. It was however decided to not use it during this project since the sonar will not measure in a straight line due to the beam width. This means that for low altitudes, compensating for attitude changes actually made the results worse.

5.3.2.2 Sensor fusion

The APM is continuously receiving a target altitude from the BBB and this value is compared to the latest estimated altitude and then compensated for by changing the throttle effect. A complementary filter is used for altitude estimation. This filter was already implemented for fusion of barometer and IMU data, but has been changed to use sonar altitude instead of barometer altitude. The complementary filter combines a low pass filter with a high pass filter to generate an accurate estimate [18]. For this application it is used to fuse the distance data from the sonar with the IMU accelerometer data. The low pass filter is applied to the accelerometer data to reduce the high frequency noise that is induced by vibrations. The high pass filter is at the same time used to always use the latest sonar altitude measurement. This can be seen in the equation 1 p(t) = p (t − 1) + (a(t) − g) ∗ 100dt2 b 2 1 1 3 3 + p (t)dt3 + p (t)dt2 + p (t)dt (2) 2 τ 3 e τ 2 e τ e where p(t) is the estimated position and pb(t) is the estimated position before position correction which is derived from the last position before position correction together with the velocity of the quadcopter. a(t) is the measured

18 acceleration and τ is the time constant that is used to calibrate the fusion. The position error pe(t) = s(t) − p(t − 1) (3) is the error in position compared to sonar measurements which used for the position correction and s(t) is the measured sonar altitude. Equation 2 and 3 are only applicable for positions in z direction. It can be seen in equations 2 and 3 that a low τ value should give the sonar measurements more impact, and a high τ value should increase the accelerometer impact on the estimated altitude and will also result in slower changes.

5.3.2.3 Custom mode

A custom mode was implemented on the APM and it is only when the APM is in this mode it is listening to commands from the BBB. To make it possible to activate this mode from the ground station without having to modify the source code, the already existing guided mode was changed into the custom mode. This means whenever guided mode is activated by any source the APM will go into the custom mode. Each mode consists of four sub modes that control roll-pitch, yaw, thrust and navigation. This means already available sub modes could be used for everything except the throttle sub mode. Figure 7 shows the software flow of the custom mode. In this mode it is first checked that the latest target altitude command received from the BBB is no older than 200 ms or otherwise the quadcopter will immediately land as a safety precaution. This means that if the APM and the BBB for any reason lose contact the quadcopter will initiate landing within 200 ms. The firmware already has a function to detect when the quadcopter is standing on the ground by measuring the altitude change compared to the throttle output. If no altitude change is seen when the throttle output has reached minimum it is assumed the quadcopter has landed. If that is the case, slow start will slew the motors from current speed to maximum when the quadcopter is taking off. There is a safety function that requires the throttle on the transmitter to be raised to a certain level before the takeoff is initiated. This has been removed to make it possible to control the altitude for the quadcopter from the ground station only. The last step is to check for a target altitude of 0 which is defined as landing command. If it is 0 the quadcopter will land by holding a fixed landing speed

19 Figure 7: Custom mode ﬂow chart.

20 until it reaches the ground and then wait for further commands. If the target altitude is anything else except 0 internal altitude hold functions are used to reach and hold the target altitude. While the custom mode is active the altitude is fully controlled by the target altitude received by BBB and the pilot is not able to change the altitude with the transmitter. The pilot will however be able to control the pitch and roll of the quadcopter. Since it is ﬂown indoors, turbulence amongst other factors will create drift that needs to be compensated for manually. This is because x and y position cannot be acquired without GPS which is not accessible indoors and the IMU is not accurate enough to use for this purpose.

5.4 BeagleBone Black

BBB is a low-cost development platform and was running Ubuntu 13.10 during this project [19]. It is used as the onboard computer and works as a link between the APM and ground station as well as controlling the APM in near real time.

5.4.1 Mounting

The BBB was at the center of the quadcopter, above the APM, where most room was available while still being protected by the top cover, see Figure 8. It was screwed onto a carbon ﬁbre plate with extenders to avoid any risks of short circuits. It requires a 5 V input and can be powered either with a USB cable connected to the micro USB port, or by a 2.1 mm barrel connector [20]. For the ﬁnal build BBB was powered via the battery through a barrel connector, although the USB connector had been used during the design process.

5.4.2 Setup

Before the BBB could be used it had to be setup accordingly. The BBB comes delivered with the Angstrom Distribution OS, so ﬁrst things that had to be done was to install Ubuntu. That was done by ﬂashing Ubuntu to the eMMC from a micro SD card. After this had been done once, the SD card is no longer needed so the SD card reader could be used for other things in the future. The entire setup procedure is described in Appendix.

21 Figure 8: Mounting of the BBB on top of the quadcopter.

5.4.3 BBB Software

The serial communication of the software is based on the C UART interface example by Meier [25]. The rest of the program for the BBB was written from scratch and the focus of the software was to support the autonomous takeoﬀ and landing function. But equally important was the possibility to extend and use it in the future, so even though some functions may seem unnecessary right now they have a purpose. The main function for the BBB is to pass on MAVLink messages from the APM to the ground station and vice versa while monitoring the data stream. It is also continuously looking for inputs and giving commands to the APM. All this is handled by four separate threads. • pc • apm • input • cmd pc continuously reads the serial port connected to the XBee for incoming messages from the ground station as shown in Figure 9. After the message is received it is decoded and there is a possibility to modify or supplement the message before it is encoded and passed on to the serial port connected to the

22 APM. It is transparent meaning from the APM point of view the messages are received directly from the ground station and from the ground station point of view it is sending the messages directly to the APM. apm continuously reads the serial port connected to the APM for incoming messages as shown in Figure 10. After the message is received it is decoded and there is a possibility to modify or supplement the message before it is encoded and passed on to the serial port connected to the XBee and transmitted to the ground station. It is transparent meaning from the APM point of view the messages are sent directly to the ground station and from the ground station point of view the messages are received directly from the APM. It is in apm the rangefinder data is decoded and monitored before it is decoded into a rangefinder message without timestamps. This is to make it possible for the ground station, which is expecting the MAVLink message to arrive without timestamp, to still be able to read and show the altitude without altering the ground station software. input monitors the inputs given in PuTTY directly to the BBB over the ad hoc network and depending on the command it will change the local mode on the BBB. • “help” will show available commands. • “t” will set TAKEOFF mode and take off to a preset altitude. • “l” will set LAND mode and set target altitude to 0.0 m. • “s X” will set FLY mode and set target altitude to X, where X is the altitude in meters. This is visualised in Figure 11. cmd updates the target altitude to the APM each time new sonar or attitude values are received from the APM as shown in Figure 12. This is monitored in the apm thread which will give a signal as soon as any of these two values have changed. In the cmd thread it will be controlled so that the sonar and attitude values are synced in time, and if they are the target altitude will be updated. The new altitude will be sent to the serial port connected to the APM as a MAVLink message.

23 Figure 9: pc ﬂow chart. Figure 10: apm ﬂow chart.

24 Figure 11: input ﬂow chart.

25 Figure 12: cmd ﬂow chart.

26 6 Experiment Design and Results

The experiments were conducted as two separate parts. In the first part the quadcopter was mounted to a frame that prevented it from moving in any direction except the z direction and to only be able to tilt in roll angle. The meaning with this part was to find the optimal value of the time constant in z direction, named TC Z in the APM software. The value of TC Z sets the impact sonar measurements and IMU estimations will have on the filtered altitude as described in section 5.3.2.2 where TC Z is interchangeable with τ in equation 2. A good value is essential to be able to hover steadily at the specified altitude. For the second part of the experiments the quadcopter could fly freely but a pilot controlled the roll and pitch with a transmitter. Also here the optimal parameter value of TC Z was analysed to find any differences between the frame test and free fly test since some of the conditions had changed. After the optimal value had been found it was tested for different altitudes to see how the behaviour changed. Since the measured distances and times probably could be improved with more fine tuning and by changing to better hardware it is the difference between each test that is more interesting than the actual values. For all the experiments the quadcopter was starting on the ground and began with a takeoff to the target altitude set. There it was kept for about one minute before the land command was given and when it landed it marked the end of that specific experiment run. Each experiment was conducted three times with exactly the same conditions to get a good average without spending too much time. Both raw sonar data as well as filtered data was used and main measurements were: • RMS difference between the target altitude and the measured altitude. This is the main part to minimise since a good value means the quadcopter is at average closer to the target altitude. • Takeoff time. This parameter is used to find out how fast the system is changing altitude. • Landing time. Similar to the takeoff time this parameter is used to find out how fast the system is changing altitude. • Number of oscillations. This value is used to see how stable the quadcopter is when holding the target altitude. The results are presented as tables and graphs where a moving average filter

27 with a span of 5 is used to make a curve ﬁt showing the trend line for each graph.

6.1 Optimal Time Constant for Frame Setup

The frame was created from two tripods that had a PVC pipe mounted between them that was fixed to the quadcopter, see Figure 13. To make it possible for the quadcopter to move freely in the z direction the pipe was mounted to the tripods with a T joint. This resulted in a weight increase of 400 g and after the landing gear had been removed a net increase of 300 g. At the very top of the tripods another PVC pipe was fixed to increase stability as well as preventing the tripods to flex in relative to each other. For each of the tripod legs sand bags weighing about 3 kg each were fixed to prevent the entire frame to fall over due to horizontal forces. Underneath the quadcopter a third PVC pipe was mounted that only acted as a reference point for the altitude measurements. The reasons for this was that when the quadcopter reached the maximum altitude the sonar beam would see the tripod legs, since the beam is wider further away from the sonar, and therefore the result would be incorrect. A PVC pipe was chosen to affect the turbulence created by the quadcopter as little as possible. When everything was set up the quadcopter could move about 40 cm in the z direction. To find the optimal balance between measured sonar altitude and estimated IMU altitude, different parameters for the sensor fusion were tested. This was done by changing the parameter value of TC Z. This could be done either by changing the initial value in the code before uploading it on the APM, or it could be changed via the full parameter list in the Mission Planner interface. It is possible to set to any decimal number between 0 and 30. A low value means sonar measurements have more effect on the estimated altitude and a higher value means the IMU is more important. All data was transferred to the PC by USB cable for these experiments. The following procedure was carried out for the frame parameter experiment: 1. Connect USB cable from PC to APM 2. Change and upload the value of parameter TC Z 3. Remove the USB cable from PC to APM 4. Connect the battery

28 Figure 13: The frame used for the experiments.

29 5. Run program on BBB 6. Connect Mission Planner 7. Wait for the altitude to stabilise 8. ARM command 9. Change mode to custom mode (guided mode in Mission Planner) 10. Takeoff command 11. Fly for about 60 seconds 12. Land command 13. DISARM command 14. Disconnect Mission Planner 15. Shut down program on BBB 16. Disconnect the battery 17. Connect to the APM via USB and download all logs (APM, Mission Planner and BBB) First each integer value between 1 s and 7 s were tested and it could be concluded that the best value should be somewhere there in between. The resolution was then improved to 0.5, so in the end all values between 1 s and 7.5 s with a 0.5 s resolution were tested. The optimal value was decided to be the one that showed the least RMS difference between the target altitude and the actual altitude after the quadcopter had reached the target altitude. A smaller RMS value means the distance and time spent away from the target altitude is minimised. Since no external altitude measurements were used it had to be assumed that the sonar would give good enough altitude measurements or that the filtered altitude estimate would be good enough. The results are shown in Table 2 and Table 3. The RMS value was calculated from the point the quadcopter had reached the target altitude until the land command was received. Removing the ascend phase negates the effect the time to reach target altitude otherwise would have. When looking at the RMS difference between the sonar altitude and the target altitude in Figure 14 it is clear that an optimal value of TC Z is about 3 s. If the value is too low or too high the square error is increasing meaning the quadcopter is spending more time away from the target altitude.

30 Table 2: Results from sonar measurements. Bold values are the lowest value for each column.

TC Z RMS target Takeoﬀ time Landing time Oscillations (s) (cm) (s) (s) (min−1) 1.0 6.22 4.44 1.70 13.1 1.5 4.30 4.06 2.05 11.5 2.0 3.24 4.99 1.82 12.6 2.5 2.89 4.35 2.05 10.4 3.0 2.61 4.06 1.77 14.0 3.5 2.95 4.78 1.49 12.6 4.0 3.30 3.94 1.91 9.0 4.5 3.38 3.72 1.54 8.4 5.0 3.95 8.25 2.09 7.8 5.5 4.58 4.73 1.81 6.9 6.0 4.93 7.56 2.31 5.3 6.5 5.40 5.90 1.76 3.2 7.0 4.33 5.09 1.48 6.5 7.5 8.40 4.25 1.67 2.5

Table 3: Results from ﬁlter measurements. Bold values are the lowest value for each column.

TC Z RMS target Takeoﬀ time Landing time Oscillations (s) (cm) (s) (s) (min−1) 1.0 4.88 4.67 2.33 13.1 1.5 2.91 4.43 2.58 10.5 2.0 1.91 5.24 2.87 8.7 2.5 1.60 4.73 2.41 7.3 3.0 1.18 4.52 4.93 6.6 3.5 1.35 5.64 2.05 4.7 4.0 1.40 4.50 2.19 4.9 4.5 1.41 4.37 4.19 3.5 5.0 1.78 9.28 2.72 2.7 5.5 1.47 5.32 1.76 3.6 6.0 1.49 8.04 4.21 3.1 6.5 1.58 6.39 2.58 2.6 7.0 1.17 6.03 13.18 2.9 7.5 2.12 5.18 11.35 2.1

31 RMS Sonar−Target Altitude 0.1

0.09

0.08

0.07

0.06

0.05

0.04

0.03

0.02

Distance to target altitude (m) 0.01

0 1 2 3 4 5 6 7 8 Time Constant TC_Z (s)

Figure 14: RMS distance average between sonar altitude and target altitude according to which the optimal value for TC Z should be about 3 s.

RMS Difference Filtered−Target Altitude 0.1

0.09

0.08

0.07

0.06

0.05

0.04

0.03

0.02

Distance to target altitude (m) 0.01

0 1 2 3 4 5 6 7 8 Time Constant TC_Z (s)

Figure 15: RMS distance average between ﬁltered altitude and target altitude according to which the optimal value should be somewhere between 3 s and 7 s.

32 Average Number of Oscillations per Minute 15 14 13 12 11 10 9 8 7 6

Oscillations 5 4 3 2 1 0 1 2 3 4 5 6 7 8 Time Constant TC_Z (s)

Figure 16: Average number of oscillations per minute. Higher value of TC Z results in less oscillations.

Looking at the RMS difference between the filtered altitude and the target altitude in Figure 15 similar patterns can be seen but not as obvious. It is clear that a too low value is bad, but between 3 s and 7 s the value seems to be about the same. The reason for this is probably once again due to higher values mean the filtered altitude is changing slower. Since the filtered altitude is depending on the parameter value this means the computations for estimated value will differ for each experiment. Therefore it has to be assumed that the sonar is giving most consistent values over the course of the experiments. Another conclusion can be drawn from the average number of oscillations per minute graph in Figure 16. The oscillations were calculated by adding 0.5 oscillations each time the altitude change from below to above the target altitude or vice versa. This should reduce the impact of noise since this means the measured altitude had to change two resolution steps to count as an oscillation. The graph shows that lower value will increase the oscillations rate of the quad, and this could be expected since lower values are more dependant on sonar altitude which is changing more rapidly. Higher values means less emphasis is put on the sonar measurements which will counteract fast changes. So for high values the quadcopter is oscillating less but since

33 Average Takeoff Time 10

2 Average Takeoff Time (s)

0 1 2 3 4 5 6 7 8 Time Constant TC_Z (s)

Figure 17: Quadcopter average takeoff time for each experiment. The takeoff time does not seem to be noticeably affected by TC Z. the changes are slower it also means that when the quadcopter is moving away from the target altitude it will also take longer time to react and move back to the target altitude. Takeoff time, Figure 17, was measured from the moment the takeoff command was received until the quadcopter reached the target altitude. Landing time, Figure 18, was measured from the landing command was received until an altitude of 55 cm was measured since the measure altitude when the quadcopter was on ground varied between 54 cm and 55 cm. Although it is hard to draw any definite conclusions from the takeoff and landing time since no clear pattern is shown, it seems like that the takeoff and landing time is not affected by the value of TC Z. More tests is needed before any definite conclusions can be drawn.

6.2 Optimal Time Constant for Free Flying

Also for the free flying tests the different values for the TC Z parameter were tested to find the optimal balance between sonar altitude and estimated IMU altitude. The reason this was tested also for the free flying was that since

34 Average Landing Time 2.5

1.5

0.5 Average Landing Time (s)

0 1 2 3 4 5 6 7 8 Time Constant TC_Z (s)

Figure 18: Quadcopter average landing time for each experiment. The landing time does not seem to be noticeably affected by TC Z. the frame made the quadcopter carry extra weight and some friction was created by the frame itself it was not sure the same parameter value would be optimal when none of these factors were present. Also since a pilot was controlling the quadcopter to compensate for drift this might also have an impact. Target altitude was set to 1 meter which is pretty close to the 0.75 cm used for the frame experiments considering the target altitude for frame was based on the PVC pipe placed beneath the quadcopter some distance above the ground. The free fly experiments were executed inside a safety net of dimensions about 4.7 x 2.8 x 2.5 m with the ground station and transmitter available from the outside. The following procedure was carried out for the free fly parameter experiment: 1. Connect the battery 2. Run program on BBB 3. Connect Mission Planner 4. Change parameter value through Mission Planner full parameter list 5. Wait for the altitude to stabilise

35 Figure 19: The setup for the free ﬂy experiments.

6. ARM command 7. Change mode to custom mode (guided mode in Mission Planner) 8. Takeoff command 9. Fly for about 60 seconds 10. Land command 11. DISARM command 12. Disconnect Mission Planner 13. Shut down program on BBB 14. Download log from BBB 15. Disconnect the battery 16. Download log from Mission Planner Since the the APM can store multiple logs all experiments were completed before the APM was connected via USB to download all APM logs. Another difference from the frame experiments was that the parameter value was changed via Mission Planner instead of uploading new firmware. The reason for this was to save time and that during the frame tests it had not yet been discovered it was possible to do via Mission Planner.

36 Table 4: Results from sonar measurements for diﬀerent TC Z values. Bold values are the lowest value for each column.

TC Z RMS target Takeoﬀ time Landing time Oscillations (s) (cm) (s) (s) (min−1) 1.0 4.02 3.54 2.14 21.89 2.0 3.04 3.34 2.08 21.60 3.0 3.30 3.72 2.21 18.07 4.0 6.33 5.52 2.12 9.43 5.0 5.38 4.90 2.23 7.10 6.0 8.25 7.13 2.20 7.38 7.0 4.49 4.88 2.15 13.15 8.0 10.22 5.31 2.44 5.52 9.0 9.96 10.03 2.11 9.79 10.0 5.99 4.16 2.23 8.48

Table 5: Results from ﬁlter measurements for diﬀerent TC Z values. Bold values are the lowest value for each column.

TC Z RMS target Takeoﬀ time Landing time Oscillations (s) (cm) (s) (s) (min−1) 1.0 3.09 4.18 2.05 17.92 2.0 1.57 3.79 2.03 10.71 3.0 1.41 4.25 2.08 8.42 4.0 2.46 6.17 1.89 5.22 5.0 1.62 6.89 2.01 4.78 6.0 2.90 14.73 1.95 4.46 7.0 1.25 5.81 1.97 6.50 8.0 2.61 6.24 2.00 3.44 9.0 2.17 11.19 1.95 3.61 10.0 2.03 6.67 1.95 4.16

37 Table 6: Results from sonar measurements for diﬀerent target altitudes. Bold values are the lowest value for each column.

TC Z RMS target Takeoﬀ time Landing time Oscillations (s) (cm) (s) (s) (min−1) 0.50 3.69 4.78 0.31 17.55 0.75 4.54 3.95 1.60 20.43 1.00 3.30 3.72 2.21 18.07 1.25 4.33 4.56 2.61 13.02 1.50 6.18 4.04 3.15 21.81 1.75 5.30 3.61 3.57 17.38 2.00 6.32 3.43 3.97 21.27

Similar patterns can be seen for the free fly experiments, Table 4 and Table 5, as were seen for the frame experiments, but not as obvious. This is most likely due to the fact that to prevent the quadcopter to drift into the net the pilot had to manually control the quadcopter. The variation in roll and pitch angle that came out of this that obviously were not the same for each flight should increase the variance for the results. Since the impact from the pilot is that much greater, this is also the reason for only testing every integer value. Using a higher resolution would not necessary give a better result, instead to improve the result it should probably be done by doing more flights for each parameter value. With this in mind it was assumed that the best parameter value was the same as for the frame experiments.

6.3 Target Altitude for Free Flying

After the optimal time constant parameter value had been decided, that one was used for the rest of the experiments. Takeoff to different altitudes were tested by giving the command “s X” for different commands in PuTTY when the quadcopter was standing on the ground. Altitudes between 0.5 m and 2.0 m were tested with 0.25 m resolution. For the free flying tests the quadcopter could move freely within an area contained by the safety net. The pilot would control the roll and pitch angle to prevent drift into the net but tried to use as small motions as possible since tilting the quadcopter too much would affect the measured sonar distance. Also here the sonar latitude and filter altitude was about the same so it was decided the sonar data should be used here as well. The results are presented in Table 6 and Table 7.

38 Table 7: Results from ﬁlter measurements for diﬀerent target altitudes. Bold values are the lowest value for each column.

TC Z RMS target Takeoﬀ time Landing time Oscillations (s) (cm) (s) (s) (min−1) 0.50 1.81 5.85 0.04 7.26 0.75 2.33 4.33 1.34 8.54 1.00 1.41 4.25 2.08 8.42 1.25 1.94 4.92 2.44 7.53 1.50 2.59 4.52 3.04 11.27 1.75 2.30 4.50 3.61 11.77 2.00 2.73 5.01 4.02 9.85

RMS Sonar−Target Altitude 0.1

0.09

0.08

0.07

0.06

0.05

0.04

0.03

0.02

Distance to target altitude (m) 0.01

0 0 0.25 0.5 0.75 1 1.25 1.5 1.75 2 2.25 2.5 Target Altitude (m)

Figure 20: RMS distance average between sonar altitude and target altitude for diﬀerent target altitudes. Higher target altitude increases the average distance between the quadcopter and target altitude during the ﬂight.

39 Average Takeoff Time 6

3 Time (s) 2

0 0 0.25 0.5 0.75 1 1.25 1.5 1.75 2 2.25 2.5 Target Altitude (m)

Figure 21: Average takeoff time for different target altitudes. Increased target altitude results in decreased takeoff time.

The general impression from Figure 20 is that the RMS between the sonar altitude and target altitude increases slightly as the target altitude increases. It is possible that this is an effect from not compensating the altitude measurement when the quadcopter is tilting since the effect will increase at higher altitudes. The best value seems to be at about 1 m which could be explained by that this is about in the middle of the room and therefore less self induced turbulence is affecting the quadcopter. One interesting note is that the takeoff time actually decreases as the target altitude increases, which can be seen in Figure 21. This was also seen while during the experiments that the quadcopter took off more aggressively when the target altitude was higher. The landing time does not give any surprises as the landing speed is set as a fixed value in the code and therefore should be linear to the distance, which is clearly shown in Figure 22. For the oscillations in Figure 23 no clear pattern between the target altitude and number of oscillations could be found. This could indicate that the turbulence, which is more substantial when close to the floor or ceiling, does not influence the oscillation pattern by a lot.

40 Average Landing Time 5

Time (s) 2

0 0 0.25 0.5 0.75 1 1.25 1.5 1.75 2 2.25 2.5 Target Altitude (m)

Figure 22: Average landing time for diﬀerent target altitudes. Increased target altitude results in increased landing time.

Average Number of Oscillations per Minute 25

10 Oscillations

0 0 0.25 0.5 0.75 1 1.25 1.5 1.75 2 2.25 2.5 Target Altitude (m)

Figure 23: Average number of oscillations per minute for diﬀerent target altitudes.

41 7 Conclusions

After the end of the project it can be concluded that all three research questions have been answered. Most time was spent on how to set and reach a target altitude since it was not clear from the beginning if this should be mainly controlled from the APM or the BBB. In the end most of the com- putation was put on the APM to let the BBB only control and instruct the APM. This made it possible to use many of the functions already available on the APM while the BBB could perform some of the ground operator’s tasks. The system can be used to takeoff, hold, and landing by setting the target altitude from the BBB and let the APM autonomously track that altitude. The solution to let the BBB control the altitude but let the APM calculate current altitude and compensate for that is something that is new, although similar solutions surely have been made with different hardware. Before the work with the takeoff and landing system even could start some work on the hardware had to be done so all connections were correct and working. Also the development of the BBB is in many cases not directly related to the takeoff and landing system so this meant less time could actually be spent on the system. Still it was necessary for the system to work and the development of the BBB as an onboard computer is something that will continue in the future as more functions are added. Now when the base has been established it should be easier for developers to focus more in their specific implementation. A lot of modifications had to be done on the APM to make indoor flight possible since much previously relied on the barometer and GPS system. This does not mean however that all these functions have been removed. As much as possible these were kept to be possible to use as a supplement to the new takeoff and landing function for flights outdoor. No external dependencies except the ground station is needed for the system to work. The ground system is only required to give high level commands so the system is self contained and could be disconnected as soon as the instruc- tions have been given and the quadcopter system would still work.

42 8 Future Research

Since this was the first step of creating a fully autonomous system for quadcopters there is quite a lot to be done in the future. Many of the functions implemented are only in some sort of simple first version state and could be both improved and optimised. A dynamic change of vertical speed should improve the altitude hold function to fine tune when approaching the target altitude. It should also improve the takeoff and landing time by reducing the speed only when close to the target altitude or ground. The current filter used for sensor fusion of sonar and IMU data is proven to work but there are theories that a Kalman filter could improve the fusion with a better estimation. One problem with that is the APM is about to reach its maximum potential and such a filter probably then have to be moved to the BBB. This would introduce other problems such that real time and sync issues could become a factor when evaluating which filter is best. By setting up a model of the system that is compared to the experiments could then help to simulate future algorithms. Since the MAVLink message for rangefinder data was modified to include timestamps it is possible to compare so the latest IMU data is in sync with the latest rangefinder data when it is received at the BBB (IMU data is already including a time stamp). Although this does not have any immediate impact on the system for now since all of the computations are made on the APM, it will make it possible to move heavy computations from the APM to the BBB in the future, e.g. a Kalman filter. One problem with the current design is that the WiFi channel used are shared with many other devices such as mobile phones. When the quadcopters operate in crowded areas the channel easily becomes saturated and can affect the communication ability. To prevent this other wireless communication alternatives must be explored. When the quadcopter is able to takeoff, fly and land autonomously it means that it can by itself take the decision when it is time to land by monitor the battery level and take action accordingly. Combine this with a system for recharge, such as using solar panels, and the quadcopter then do not have to return to a recharge station for each charge cycle. It can just land, recharge, takeoff and continue where it was before. A long term goal with the system is that it should be able to by itself deter- mine where it is possible to land without the risk of not being able to takeoff again. This means to both avoid to steep slopes as well as objects lying on

43 the ground. Ideas of using cameras for this was discussed during the project but not further investigated due to lack of time. When landing on uneven ground it is also possible that the sonar will be closer to the ground than its minimum distance. This has to be taken into account since strange values otherwise may prevent the quadcopter to take off again. Another big step that is currently already in development is to implement simultaneous localization and mapping (SLAM) to work together with the system. This would make it possible for the quadcopter to localise its current position in x and y directions in addition to z and then full information of its current position. This opens up for fully autonomous flight indoor without any external systems. In general the system would benefit from any additional sensor, camera or something else. This could be used both for redundancy and to calibrate the system. As it is now the sonar has to sort of control itself since it is the only direct contact with the outside world. When the system is working on one unit it should also be scalable to a swarm of multiple units to use its full potential. This could give rise to other problems such as interference between the quad copters and more that have to be taken into account. Solving all these problems is the ultimate goal that would make it possible for quadcopters to without human supervision explore, search, or surveillance areas without being affected by exhaustion or human errors.

44 References

[1] Nunamaker JF Jr, Chen M, Purdin TDM. System Development in Infor- mation System Research. J Manage Inform Syst. 1991; 7(3):89-106 [2] Patterson T, McClean S, Morrow P, Parr G, Luo C. Timely autonomous identification of UAV safe landing zones. Image Vis Comput. 2014 Jul 3; 32(2014):568–578 [3] Wei Y, Blake MB, Madey GR. An Operation-time Simulation Framework for UAV Swarm Configuration and Mission Planning. In: Alexandrov V, Lees M, Krzhizhanovskaya V, Dongarra J, Sloot PMA, editors. 2013 Inter- national Conference on Computational Science; 2013 Jun 5-7; Barcelona, Spain. Amsterdam: Elsevier; 2013. p. 1949-1958 [4] Pradana A, Dikairono R, Purwanto D, Design of Quadrotor Hovering System Based on Inertial Measurement Unit Sensor. Surabaya, Indone- sia: Electrical Engineering Department, Faculty of Industrial Technology, Sepuluh Nopember Institute of Technology [5] Prattico F, Cera C, Petroni F. A new hybrid infrared-ultrasonic electronic travel aids for blind people. Sens Actuators A Phys. 2013 Oct 15; 201(2013):363-370 [6] Templeton T, Shim DH, Geyer C, Sastry SS. Autonomous Vision-based Landing and Terrain Mapping Using an MPC-controlled Unmanned Ro- torcraft. In: Hutchinson S, editor. 2007 IEEE International Conference on Robotics and Automation; 2007 Apr 10-14; Roma, Italy. IEEE; 2007. p. 1349-1356 [7] Yang S, Scherer SA, Zell A. An Onboard Monocular Vision System for Autonomous Takeoff, Hovering and Landing of a Micro Aerial Vehicle. J Intell Robot Syst. 2012 Sep 13; 69(1-4):499-515 [8] Herisse B, Russotto FX, Hamel T, Mahony R. Hovering flight and vertical landing control of a VTOL Unmanned Aerial Vehicle using Optical Flow. 2008 IEEE/RSJ International Conference on Intelligent Robots and Systems; 2008 Sep 22-26; Nice, France. IEEE; 2008. p. 801-806 [9] Cesetti A, Frontoni E, Mancini A, Zingaretti P, Longhi S. A Vision-Based Guidance System for UAV Navigationand Safe Landing using Natural Landmarks. J Intell Robot Syst. 2009 Oct 21; 57(1-4):233-257

45 [10] Yang A, Scherer SA, Schauwecker K, Zell A. Onboard Monocular Vision for Landing of an MAV on a Landing Site Speciﬁed by a Single Reference Image. 2013 International Conference on Unmanned Aircraft Systems (ICUAS); 2013 May 28-31; Atlanta, GA, USA. IEEE; 2013. p. 318-325 [11] Mission Planner Overview [Internet]. [cited 2014 Sep 22]. Available from: http://planner.ardupilot.com/wiki/mission-planner-overview/ [12] MAVLink [Internet]. [cited 2014 Sep 2]. Available from: http://qgroundcontrol.org/mavlink/start [13] Balasubramanian S. MavLink Tutorial for Absolute Dummies (Part –I) [Internet]. [Cited 2014 Oct 9]. Available from http://api.ning.com/ﬁles/i*tFWQTF2R*7Mmw7hksAU-u9IABKNDO9 apguOiSOCfvi2znk1tXhur0Bt00jTOldFvob-Sczg3*lDcgChG26QaHZpz EcISM5/MAVLINK FOR DUMMIESPart1 v.1.1.pdf [14] PuTTY [Internet]. [Cited 2014 Sep 5] Available from: http://www.chiark.greenend.org.uk/ sgtatham/putty/

[15] LV-MaxSonar R -EZ1TM High Performance Sonar Range Finder [Inter- net]. [cited 2014 Sep 4]. Available from: http://www.maxbotix.com/documents/MB1010 Datasheet.pdf [16] Mandatory Hardware Conﬁguration [Internet]. [cited 2014 Sep 1]. Avail- able from: http://copter.ardupilot.com/wiki/initial-setup/conﬁguring-hardware/ [17] MAVLink Generator (C/C++, Python) [Internet]. [cited 2014 Oct 2]. Available from: http://qgroundcontrol.org/mavlink/generator [18] Higgins WT Jr. A Comparison of Complementary and Kalman Filtering. IEEE Trans Aerosp Electron Syst. 1975 May; AES-11(3):321-325 [19] BeagleBone Black [Internet]. [updated 2014 Aug 22;cited 2014 Sep 2]. Available from: http://beagleboard.org/black [20] Frequently Asked Questions [Internet]. [updated 2014 May 8;cited 2014 Sep 22] Available from: http://beagleboard.org/Support/FAQ

46 [21] Schaenzle J. Wireless Communication Between Raspberry Pi and Your Computer. 2013 Apr 22 [cited 2014 Oct 9]. Atomic Spin [Internet]. Available from: http://spin.atomicobject.com/2013/04/22/raspberry-pi-wireless- communication/ [22] Molloy D. Getting Started – USB Network Adapter on the Beaglebone [Internet]. [cited 2014 Sep 5]. Available from: http://derekmolloy.ie/beaglebone/getting-started-usb-network-adapter- on-the-beaglebone/ [23] Molloy D. Automatically Setting the Beaglebone Black Time Using NTP [Internet]. 2013 May 18 [cited 2014 Sep 5]. Available from: http://derekmolloy.ie/automatically-setting-the-beaglebone-black-time- using-ntp/ [24] Clark J. BeagleBone Black Serial UART Device Tree Overlays for Ubuntu and Debian Wheezy (tty01, tty02, tty04, tty05 .dtbo ﬁles) [Internet]. 2013 June 17 [cited 2014 Sep 5] Available from: http://www.armhf.com/beaglebone-black-serial-uart-device-tree- overlays-for-ubuntu-and-debian-wheezy-tty01-tty02-tty04-tty05-dtbo- ﬁles/ [25] Meier L. C Uart Interface Example [Internet]. Available from: https://github.com/mavlink/c uart interface example

47 Appendix

Setup of BBB

Following setup steps had to be done after each power reset of the BBB, but for convenience everything was put together in a script that was run on start up.

Connection

PuTTY was used to connect to the IP address of the BBB, which by default for an ethernet connection is 192.168.7.2. For wireless connection, the address is set manually when setting up the wireless connection on the BBB. To set up an ad hoc wireless connection on the BBB the network interface file has to be modified slightly. Since this means the BBB will work as the router it is also needs to be configured as a DHCP server to be able to assign an IP address to the ground station PC. When this is done the network should be visible and possible to connect from the PC [21]. Some issues were found when trying to set up the ad hoc network. Firstly the BBB was not able to recognise the USB dongle if it was connected directly to the USB port. But when connecting it through the USB hub it was recognised and since this solution also solved some other problems no further investigation was made. Other problems were such as more than one USB port will be needed in the future and that the USB dongle connected directly to the USB port was not going to fit underneath the top cover and therefore risked to get damaged.

Internet

To make things easier when updating software an internet connection was established directly to the BBB following the steps below [22]. Both connection with USB cable as well as wireless connection was used during the project. 1. Power the BBB with a USB cable connected to the computer that should share the internet connection. • For wireless connection the BBB needs to be powered by either USB cable or 2.1 mm barrel connector. Both the BBB and the

48 host computer should have a USB dongle connected. 2. In Control Panel → Network and Sharing Centre → Change adapter settings enter the properties for network of the computer connected to the internet. In the Sharing tab enable Allow other network users to connect through this computer’s Internet connection. 3. In the properties for the LINUX USB Ethernet → Internet Protocol Version 4 (TCP/IPv4) all settings should be changed to obtain automatically. • For wireless connection the properties for equivalent wireless connection should be changed in the same way. 4. Connect to the BBB using PuTTY and enter following • sudo /sbin/route add default gw 192.168.7.1 • echo “nameserver 8.8.8.8” | sudo tee –a /etc/resolv.conf

Set date

When compiling a ﬁle on the BBB that has been edited on the outside it is important the time for both systems are in sync. Since an internet connection was established the easiest way to update the clock on the BBB was by automatically update it from the internet using ntpdate [23]. First the correct time zone was set. 1. Remove the current local time zone • sudo rm /etc/localtime 2. Link to the correct local time zone, in this case Melbourne • sudo ln -s /usr/share/zoneinfo/Australia/Melbourne /etc/localtime Then ntpdate was installed. Each time the BBB is restarted following command has to be executed to update the time. • sudo /usr/bin/ntpdate –b –s –u au.pool.ntp.org

UART

To setup the serial ports so UART could be used the following procedure was executed.

49 1. Download the four *.dtbo ﬁles from [24]. 2. Add the user that will be using the ports to the dialout group. Each time the BBB is restarted, enter the following 1. cd /sys/devices/bone capemgr.* 2. sudo bash –c “echo portname > slots” where portname is the ﬁlename for the port that should be used as UART without the –00A0 part.