MASTER'S THESIS. Autonomous Takeoff and Landing for Quadcopters. Robert Lindberg Master of Science in Engineering Technology Space Engineering

Transcription

1 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

2 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

3 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örn Wahlströms fond and Ångpanneföreningens Forskningsstiftelse for the financial support in forms of scholarships 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

4 Contents Abstract Acknowledgements ii iii 1 Introduction Background Research Questions Thesis Structure Methodology Construct a Conceptual Framework Develop a System Architecture Analyze and Design the System Build the (Prototype) System Experiment, observe, and evaluate the system Literature Review 6 4 Initial System Overview Connections Mission Planner MAVLink PuTTY Design and Development Overview and Connections Sonar Mounting Calibration ArduPilot Mega Setup APM Software Sonar Sensor fusion Custom mode BeagleBone Black Mounting Setup BBB Software iv

5 6 Experiment Design and Results Optimal Time Constant for Frame Setup Optimal Time Constant for Free Flying Target Altitude for Free Flying Conclusions 42 8 Future Research 43 Appendix 48 v

6 List of Figures 1 The Xaricraft x650v8 quadcopter The initial system as it was before any modifications Overview of the software and protocols Overview of the autonomous system Mounting of the sonar on the back of the quadcopter Plotted calibration results for sonar Custom mode flow chart Mounting of the BBB on top of the quadcopter pc flow chart apm flow chart input flow chart cmd flow chart The frame used for the experiments RMS distance average between sonar altitude and target altitude according to which the optimal value for T C Z should be about 3 s RMS distance average between filtered altitude and target altitude according to which the optimal value should be somewhere between 3 s and 7 s Average number of oscillations per minute. Higher value of T C Z results in less oscillations Quadcopter average takeoff time for each experiment. The takeoff time does not seem to be noticeably affected by T C Z Quadcopter average landing time for each experiment. The landing time does not seem to be noticeably affected by T C Z The setup for the free fly experiments 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 Average takeoff time for different target altitudes. Increased target altitude results in decreased takeoff time Average landing time for different target altitudes. Increased target altitude results in increased landing time Average number of oscillations per minute for different target altitudes vi

7 List of Tables 1 Calibration results for sonar. Bold values are above the minimum distance and are the ones used for the calibration Results from sonar measurements. Bold values are the lowest value for each column Results from filter measurements. Bold values are the lowest value for each column Results from sonar measurements for different T C Z values. Bold values are the lowest value for each column Results from filter measurements for different T C Z values. Bold values are the lowest value for each column Results from sonar measurements for different target altitudes. Bold values are the lowest value for each column Results from filter measurements for different target altitudes. Bold values are the lowest value for each column vii

8 List of Equations 1 Sonar distance-voltage dependency Complementary filter Position error viii

9 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

10 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 firmware used on the autopilot there are already autonomous takeoff 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

11 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

12 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 Development 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 five 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 specified. The requirements were described as follows for the system on the quadcopter: Takeoff 3

13 A command to make the quadcopter reach a specified 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

14 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 integration 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

15 3 Literature Review There are two main types of UAV control today, piloted and autonomous. Piloted 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

16 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

17 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, first 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 modification of the software or protocol itself, shown in Figure Connections A receiver is connected to the input side of the APM with five connectors that control roll, pitch, yaw, throttle, and flight 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

18 Figure 2: The initial system as it was before any modifications. Figure 3: Overview of the software and protocols. 9

19 4.2 Mission Planner Mission Planner (MP) version 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 headeronly 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

20 5 Design and Development When familiarised with the existing system and software tools the development and modifications 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 supplements 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 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 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

21 Figure 4: Overview of the autonomous system. 12

22 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] 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 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

23 4 Sonar Calibration Distance (m) 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 (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 flying and for this project the ArduPilot Mega 2.5 was used. The base firmware installed 14

24 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)

25 is the ArduCopter 3.15 and all modifications during the project were made and based on this firmware 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 reflect the arm configuration 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

26 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 finishing 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 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 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

27 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) compensation 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 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 p(t) = p b (t 1) + 1 (a(t) g) 100dt τ p e(t)dt τ p e(t)dt τ p e(t)dt (2) where p(t) is the estimated position and p b (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

28 acceleration and τ is the time constant that is used to calibrate the fusion. The position error p e (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 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

29 Figure 7: Custom mode flow chart. 20

30 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 flown 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 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 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 fibre 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 final build BBB was powered via the battery through a barrel connector, although the USB connector had been used during the design process Setup Before the BBB could be used it had to be setup accordingly. The BBB comes delivered with the Angstrom Distribution OS, so first things that had to be done was to install Ubuntu. That was done by flashing 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

31 Figure 8: Mounting of the BBB on top of the quadcopter 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 takeoff 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

32 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

33 Figure 9: pc flow chart. Figure 10: apm flow chart. 24

34 Figure 11: input flow chart. 25

35 Figure 12: cmd flow chart. 26

36 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 T C Z in the APM software. The value of T C Z sets the impact sonar measurements and IMU estimations will have on the filtered altitude as described in section where T C 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 T C 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

37 with a span of 5 is used to make a curve fit 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 T C 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 T C Z 3. Remove the USB cable from PC to APM 4. Connect the battery 28

38 Figure 13: The frame used for the experiments. 29

39 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 T C 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

40 Table 2: Results from sonar measurements. Bold values are the lowest value for each column. TC Z RMS target Takeoff time Landing time Oscillations (s) (cm) (s) (s) (min 1 ) Table 3: Results from filter measurements. Bold values are the lowest value for each column. TC Z RMS target Takeoff time Landing time Oscillations (s) (cm) (s) (s) (min 1 )

41 0.1 RMS Sonar Target Altitude Distance to target altitude (m) Time Constant TC_Z (s) Figure 14: RMS distance average between sonar altitude and target altitude according to which the optimal value for T C Z should be about 3 s. 0.1 RMS Difference Filtered Target Altitude Distance to target altitude (m) Time Constant TC_Z (s) Figure 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

42 Oscillations Average Number of Oscillations per Minute Time Constant TC_Z (s) Figure 16: Average number of oscillations per minute. Higher value of T C 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

43 10 Average Takeoff Time 9 Average Takeoff Time (s) 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 T C 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 T C 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 T C 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

44 2.5 Average Landing Time Average Landing Time (s) 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 T C 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

45 Figure 19: The setup for the free fly 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