Czech Technical University in Prague Faculty of Electrical Engineering
DIPLOMA THESIS Algorithms for Autonomous Flight of Unmanned Helicopters
Prague, 2012
Author: Miloˇ s Kruml
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem svou diplomovou pr´aci vypracoval samostatnˇe a pouˇzil jsem pouze podklady (literaturu, projekty, SW atd.) uveden´e v pˇriloˇzen´em seznamu.
V Praze dne podpis
i
Podˇ ekov´ an´ı Dˇekuji pˇredevˇs´ım vedouc´ımu svoj´ı diplomov´e pr´ace Ing. M. Rollovi Ph.D. za pomoc pˇri vytv´aˇren´ı t´eto pr´ace a za poskytnut´ı materi´al˚ u pro jej´ı zpracov´an´ı. D´ale tak´e dˇekuji Ing. M. Seleck´emu za konzultace v oblasti vytv´aˇren´ı programov´e ˇc´asti t´eto pr´ace a v neposledn´ı ˇradˇe tak´e vˇsem dalˇs´ım vyuˇcuj´ıc´ım, kteˇr´ı mi pˇred´avali zkuˇsenosti a vˇedomosti bˇehem cel´eho m´eho studia. Chtˇel bych tak´e podˇekovat svoj´ı rodinˇe, kter´a mi toto studium umoˇznila a bˇehem cel´eho studia mne podporovala.
ii
Acknowledgements First of all I thank to my diploma thesis supervisor Ing. M. Rollo Ph.D. for helping me create this thesis and for providing me materials for its process. Than I thank to Ing. M. Seleck´ y for consultations about software design and not in the end to all other teachers who were providing skills and knowledge during my entire studies. I would also like to thank to my family for supporting me during my studies.
iii
iv
Abstrakt Diplomov´a pr´ace pojedn´av´a o algoritmech pro autonomn´ı let bezpilotn´ıch vrtuln´ık˚ u. Pr´ace popisuje koncept voln´eho letu a architekturu syst´emu navrˇzen´eho pro integraci bezpilotn´ıch prostˇredk˚ u do takov´eho prostˇred´ı. Navrˇzen´ y koncept byl ovˇeˇren praktick´ ym nasazen´ım na bezpilotn´ı kvadropt´ery Mikrokopter a vyuˇz´ıv´a syst´em AgentFly. V pr´aci je pops´ana konstrukce helikopt´ery, integrace vˇsech softwarov´ ych a hardwarov´ ych modul˚ u a jej´ı rozˇs´ıˇren´ı o pˇr´ıdavn´ y palubn´ı poˇc´ıtaˇc Gumstix. K pl´anov´an´ı trajektori´ı byl pouˇzit algoritmus AA*. Byla zv´aˇzena i moˇznost vyˇzit´ı algoritmu Hexgrid ve spojen´ı s algoritmem Lazy Theta*, coˇz se uk´azalo jako vhodn´e ˇreˇsen´ı do prostˇred´ı s vysok´ ym poˇctem statick´ ych pˇrek´aˇzek. V pr´aci jsou d´ale pops´any algoritmy pro ˇreˇsen´ı kolizn´ıch situac´ı a jejich rozˇs´ıˇren´ı pro oblast bezpilotn´ıch helikopt´er. Vˇsechny algoritmy byly otestov´any na re´aln´em hardwaru.
v
Abstract The main objective of this diploma thesis is analysis, design and implementation of algorithms for autonomous flight of umnanned helicopters. Thesis explains concept of freeflight and architecture of system designed for integration of UAVs into such environment. Designed concept was verified by deployment on unmanned quadcopter Mikrokopter and is based on AgentFly framework. Structure of Mikrokopter UAV, integration of all software and hardware modules and its extension by Gumstix SOC onboard computer is described. AA* algorithm was used for trajectory planning. Usage of HexGrid planning algorithm in combination with LazyTheta* algorithm is discussed and proved to be a useful solution for environments with high number of static obstacles. Thesis also describes collision avoidance algorithms and their extension for area of unmanned helicopters. All algorithms were tested in a set of field experiments.
vi
viii
Contents Table of Figures
xiii
Table of Tables
xv
1 Introduction
1
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Classification of UAVs
5
2.1
Construction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Degree of autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4
Range, Altitude and Endurance . . . . . . . . . . . . . . . . . . . . . . .
8
3 Mikrokopter Aerial Vehicle 3.1
11
System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.1
Mechanical Components . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.1.1
Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.1.2
Landing gear and Battery holder . . . . . . . . . . . . .
12
3.1.1.3
Motors and Propellers . . . . . . . . . . . . . . . . . . .
13
3.1.2
Electronic components . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.3
Flight Controller . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.3.1
Radio control . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.4
Brushless Controllers . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.5
Navigation Controller . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.6
Additional components . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.6.1
16
GPS module . . . . . . . . . . . . . . . . . . . . . . . . ix
3.1.6.2
Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.6.3
Camera mount . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.6.4
Power source . . . . . . . . . . . . . . . . . . . . . . . .
17
Mikrokopter Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.1
I2C bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.2
SPI bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
Mikrokopter software . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.1
MikrokopterTool . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.1.1
Default Mikrokopter flight modes . . . . . . . . . . . . .
20
3.3.2
Mikrokopter OSD . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3.3
Mikrokopter setting . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.4
Gumstix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.5
Communication with Mikrokopter UAV . . . . . . . . . . . . . . . . . . .
23
3.5.1
Mikrokopter Serial protocol . . . . . . . . . . . . . . . . . . . . .
23
3.5.2
Hardware connection . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2
3.3
4 System architecture design 4.1
27
AgentFly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.1.1
Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.1.2
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.1.3
Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5 Communication
33
5.1
Received packet processing . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2
Transmitted packet processing . . . . . . . . . . . . . . . . . . . . . . . .
36
5.2.1
37
Waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Flight Planning
39
6.1
AA* - Accelered A* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.2
Hexgrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.3
Implementation and testing . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.3.1
Plan conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6.3.2
Plan checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
7 Collision Detection and Deconfliction 7.1
Collision Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
47 47
7.2
Collision Deconfliction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
7.2.1
Iterative peer-to-peer collision avoidance - IPPCA . . . . . . . . .
49
7.2.2
Multiparty collision avoidance - MPCA . . . . . . . . . . . . . . .
49
8 Simulation and Experiments 8.1
8.2
53
Computer Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
8.1.1
Simulated Mikrokopter UAV . . . . . . . . . . . . . . . . . . . . .
53
8.1.2
Hybrid Simulation . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
8.2.1
Basic experiment . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
8.2.2
Navigation experiment . . . . . . . . . . . . . . . . . . . . . . . .
57
8.2.3
Autonomous planning experiment . . . . . . . . . . . . . . . . . .
57
8.2.4
Autonomous flight with Collision avoidance . . . . . . . . . . . .
58
9 Conclusion
61
9.1
Thesis achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
9.2
Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
References
64
A Implementations
I
A.1 Mikrokopter communication protocol . . . . . . . . . . . . . . . . . . . .
I
A.1.1 Modified-base64 code . . . . . . . . . . . . . . . . . . . . . . . . .
I
A.1.1.1 Cyclic Redundancy Check . . . . . . . . . . . . . . . . .
II
A.2 S32 conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III
B Disk contents
V
xi
xii
List of Figures 1.1
Example of different UAVs . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.1
Example of fixed-wing UAV . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2
Example of helicopter UAV . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
Example of rocket UAV . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.4
Example of hybrid UAV . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.5
General Atomics - Predator C . . . . . . . . . . . . . . . . . . . . . . . .
8
2.6
Helios Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1
Mikrokopter UAV basic set . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2
Basic frame construction . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.3
Main stack of PCBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.4
Landing gear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.5
Battery holder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.6
Mikrokopter system scheme . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.7
Flight controller - top side . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.8
Flight controller - bottom side . . . . . . . . . . . . . . . . . . . . . . . .
15
3.9
Brushless controller - top side . . . . . . . . . . . . . . . . . . . . . . . .
15
3.10 Brushless controller - bottom side . . . . . . . . . . . . . . . . . . . . . .
15
3.11 Navigation controller - top side . . . . . . . . . . . . . . . . . . . . . . .
16
3.12 Navigation controller - bottom side . . . . . . . . . . . . . . . . . . . . .
16
3.13 GPS module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.14 Bluetooth modules in protective cover . . . . . . . . . . . . . . . . . . . .
17
3.15 I2C scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.16 SPI scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.17 Mikrokopter Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.18 Example of Mikrokopter OSD with waypoint route . . . . . . . . . . . .
21
3.19 Example of mission plan . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
xiii
3.20 Gumstix Overo Fire module . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.21 Tobi expansion board . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.22 Mikrokopter serial protocol . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.23 Ribon 10-pin layout scheme . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.24 Converter basic electronic scheme . . . . . . . . . . . . . . . . . . . . . .
24
4.1
System structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2
UAV internal structure . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.3
Ground station internal structure . . . . . . . . . . . . . . . . . . . . . .
29
4.4
Example of AgentFly system visualization in 2D perspective . . . . . . .
31
4.5
Example of AgentFly system visualization in 3D perspective . . . . . . .
31
5.1
Communication architecture core . . . . . . . . . . . . . . . . . . . . . .
33
5.2
Extended architecture core . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.3
Base64 byte conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
6.1
The two-dimensional example of the adaptive sampling, from [1] . . . . .
40
6.2
Example of generated successors, from [1] . . . . . . . . . . . . . . . . . .
41
6.3
Representation of adjacent states on hexagonal grid, from [8] . . . . . . .
42
6.4
Visualization of planned path by Hexgrid with colored open nodes . . . .
43
6.5
Part of track in visualization . . . . . . . . . . . . . . . . . . . . . . . . .
44
6.6
Interpolated part of track in MK-OSD . . . . . . . . . . . . . . . . . . .
44
7.1
Example of collision situation, from [4] . . . . . . . . . . . . . . . . . . .
48
7.2
Evasive maneuver to right, from [4] . . . . . . . . . . . . . . . . . . . . .
49
7.3
Example of super-conflict situation of ten aircraft . . . . . . . . . . . . .
52
7.4
Example collision free trajectories . . . . . . . . . . . . . . . . . . . . . .
52
8.1
Core of engine architecture . . . . . . . . . . . . . . . . . . . . . . . . . .
54
8.2
Hybrid simulation visualization example . . . . . . . . . . . . . . . . . .
55
8.3
Hybrid simulation visualization example in 3D perpective . . . . . . . . .
55
8.4
Mikrokopter UAV during flight . . . . . . . . . . . . . . . . . . . . . . .
56
8.5
Scenario model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
8.6
Trajectories before replanning from collision avoidance . . . . . . . . . .
58
8.7
Trajectories after replanning from collision avoidance . . . . . . . . . . .
59
xiv
List of Tables 5.1
Waypoint mandatory variables and their description . . . . . . . . . . . .
xv
38
xvi
Chapter 1 Introduction An unmanned Aerial Vehicle (UAV), also known as drone, is an aircraft without a human pilot on board. Biggest and most advanced category of UAVs are airplanes, sometimes referred as CTOLs1 . Another category are helicopters, sometimes referred as VTOLs2 . Air traffic is currently directed by Air Traffic Control. This service is provided by ground-based operators. Their primary purpose is to direct an aircraft in a way to prevent collision situations, to organize the traffic flow, to provide information (about other aircraft, weather, etc.). This task is getting more difficult with growing density of air traffic. There are some concepts which are trying to solve this issue. One of them is Free-Flight concept. This concept uses no centralized control. Free flight eliminates the need for Air Traffic Control operators by giving the responsibility to the Pilot In Command.3 This gives the pilot the ability to change trajectory in mid-flight. In this concept Air Traffic Control is responsible just for coordination of aircraft in terminal sector. One of systems based on this concept is AgentFly which is currently developed by Agent Technology Center at Department of Computer Science and Engineering of Czech Technical University in Prague. Developed algorithms and whole system described in thesis is based on AgentFly.
1
CTOL - Continuous Take-Off and Landings VTOL - Vertical Take-Off and Landing 3 Pilot in Command(PIC) is person or system aboard the aircraft responsible for its operation and 2
safety. PIC must be legally certified by International Civil Aviation Organization.
1
2
1.1
CHAPTER 1. INTRODUCTION
Motivation
The goal of the AgentFly system is to be capable of controlling air traffic autonomously. During development of such a system there is need to verify software concepts by developing them on real UAVs and carrying out hardware simulations. Systems based on AgentFly are currently capable of autonomous flight of group of unmanned airplanes. If we would like to control whole air traffic we have to control flight of helicopters as well. From that reason we need to add helicopters (VTOLs) to these hardware simulations. To do so concepts and software architecture for their control have to be developed.
1.2
Goals
To be able to add helicopters to these simulations we need to proceed several steps. First of all we have to build a hardware VTOL platform which will allow us to carry out all required experiments. We decided to build our system on Mikrokopter UAV produced by Mikrokopter Gmbh, Germany. Than a proper communication on both hardware and software level among all components and modules has to be designed. When the Mikrokopter UAV and communication structure is built we have to integrate all software components which are provided by AgentFly system, like trajectory planners, collision avoidance algorithms, visualization and software simulation and deploy all necessary modules on UAV. Finally we will carry out a set of experiments to verify proper function of all components and designed free-flight concept.
Figure 1.1: Example of different UAVs
1.3. THESIS STRUCTURE
1.3
3
Thesis structure
This thesis is organized as follows. In chapter 2 we describe the taxonomy of UAVs regarding their construction, degree of autonomy and purpose. Chapter 3 introduces Mikrokopter Aerial Vehicle, explains its mechanical construction, electronic equipment and integration of additional onboard computer Gumstix. We also discuss all relevant parameters of used HW modules. In chapter 4 we give an overview of architecture of system we designed to verify out free-flight concept. We discuss software modules running onboard as well as on ground station and principle of communication in the system. Individual communication channels and protocols are described in more details in Section 5. Sections 6 and 7 introduce trajectory planning and collision avoidance algorithms provided by AgentFly system that were extended and deployed on Mikrokopter UAV. Arrangement of each experiment together with its results are discussed in chapter 8. Finally, chapter 9 concludes this thesis.
4
CHAPTER 1. INTRODUCTION
Chapter 2 Classification of UAVs There is a wide variety of different UAVs and they could be classified according to several attributes. The most important attributes are: • construction • degree of autonomy • purpose • range, altitude and endurance Classification presented in thich chapter is not an official or exhaustive one. It presents one point of view on classification of UAVs, which was important from point of view of this work.
2.1
Construction
From construction aspect UAVs can be divided into four basic groups - fixed-wings, helicopters, rocket-based and hybrid. Fixed-wings (Fig. 2.1) are most widespread and have some big advantages against other concepts especially range, endurance and payload. Helicopters (Fig. 2.2) are designed for other bunch of missions. They do not need big runway for take of and landing1 and are capable of another set of maneuvers. Their biggest disadvantage is their short endurance because helicopter flight is not as aerodynamically 1
They are sometimes referred as VTOL(Vertical Take Off and Landing) or UAH(Unmanned Aerial
Helicopter).
5
6
CHAPTER 2. CLASSIFICATION OF UAVS
effective as plane flight2 . Rocket-based UAVs (Fig. 2.3) are mainly rockets missiles and UAVs used as targets simulating enemy aircraft or missile. Hybrid UAVs do not have unified construction or propulsion(animal-inspired wings for example in Fig. 2.4).
2.2
Figure 2.1: Example of fixed-wing UAV
Figure 2.2: Example of helicopter UAV
Figure 2.3: Example of rocket UAV
Figure 2.4: Example of hybrid UAV
Degree of autonomy
Today’s UAVs often combine remote control and some level of computerized automation. More sophisticated versions may have guidance systems to perform low-level human pilot duties such as speed and flight-path stabilization, and simple scripted functions such as waypoint navigation. Level of autonomy could be classified in these levels: • Sensor fusion - UAV is capable of information fuse from different on-board sensor and uses them for example for flight stabilization or waypoint navigation. 2
Planes lift force is generated on wing by flowing fluid. Helicopter lift is generated just by propellers.
2.3. PURPOSE
7
• Path planning - Determining an optimal path for vehicle to go while meeting certain objectives and mission constraints. • Single plane mission planning - Solving single plane missions • Task allocation and scheduling - Determining the optimal distribution of tasks among a group of UAVs, with time and resource constraints. • Cooperative tactics - Formulating an optimal sequence and spatial distribution of activities between UAVs in order to maximize chance of success in any given mission scenario.
2.3
Purpose
UAV can be also divided by their purpose of use. These categories are the most important.
• Target and decoy – providing ground and aerial gunnery a target that simulates an enemy aircraft or missile. • Reconnaissance – providing battlefield intelligence. • Combat – providing attack capability for high-risk missions, also known as Unmanned Aerial Combat Vehicle (UACV). • Logistics – UAVs specifically designed for cargo and logistics operation. • Research and development – used to further develop UAV technologies to be integrated into field deployed UAV aircraft. • Environment measurement and recording - UAVs used for photo or video capture or for measurement of substances contained in environment.
8
CHAPTER 2. CLASSIFICATION OF UAVS
2.4
Range, Altitude and Endurance
Range, altitude and endurance are some of the most important aspects in UAVs design which corresponds to UAV purpose. Needs for endurance and range are most significant in military sector. The most widely used military UAV with long range is a Predator (Fig. 2.5). Its last in public known version is capable of flight time about 48 hours with cruise speed about 900 km/h. There is no classification of civilian UAVs. Military UAVs are classified by US Air Force tiers: • Tier N/A - Small/Micro UAVs • Tier I - Low altitude, long endurance • Tier II - Medium altitude, long endurance • Tier II+: - High altitude, long endurance conventional UAV. Altitude: 60,000 to 65,000 feet (19,800 m), less than 560 km/h airspeed, 3,000-nautical-mile (6,000 km) radius, 24 hour time-on-station capability. • Tier III-: High altitude, long endurance low-observable UAV. Same parameters as, and complementary to, the Tier II+ aircraft.
Figure 2.5: General Atomics - Predator C
2.4. RANGE, ALTITUDE AND ENDURANCE
9
Absolute record in altitude holds Helios Prototype (Fig. 2.6), designed and manufactured by NASA. This solar-powered UAV reached altitude of 29 524 m3 and in addition, the aircraft spent more than 40 minutes above 29 000 m. NASA Helios Prototype was built to develop the technologies that would allow long-term, high-altitude aircraft to serve as ”atmospheric satellites”, to perform atmospheric research tasks as well as serve as communications platforms.
Figure 2.6: Helios Prototype
3
On August 13, 2001, world record for sustained horizontal flight by a winged aircraft.
10
CHAPTER 2. CLASSIFICATION OF UAVS
Chapter 3 Mikrokopter Aerial Vehicle Mikrokopter Unmanned Aerial Vehicle (further referred as Mikrokopter UAV) is a multirotor helicopter based system. It has several independent rotors with propellers which are responsible for aerial movement of the whole system. Minimum standard number of rotors is four, maximum for Mikrokopter based system is twelve.
Figure 3.1: Mikrokopter UAV basic set
11
12
CHAPTER 3. MIKROKOPTER AERIAL VEHICLE
3.1
System Components
All basic components used for Mikrokopter construction can be divided in two main categories: mechanical and electronic.
3.1.1
Mechanical Components
Mechanical components are frame, landing gear, battery holder, engines and propellers.
3.1.1.1
Frame
Base of mechanical construction (Fig. 3.2) form two plates holding four arms on whose ends motors are placed. Center stack with electronics (Fig. 3.3) is mounted in the middle. There is a chassis mounted on the bottom of center plates which protects the battery, which is attached from bellow to center plates.
Figure 3.2: Basic frame construction
3.1.1.2
Figure 3.3: Main stack of PCBs
Landing gear and Battery holder
There is landing gear (Fig. 3.4) mounted on bottom of frame. Because there was a need to connect addition computer module, special holder for this computer module and battery had to be designed
3.1. SYSTEM COMPONENTS
Figure 3.4: Landing gear
3.1.1.3
13
Figure 3.5: Battery holder
Motors and Propellers
Motors are controlled by voltage with no-load speed of 760 rpm/V. It is 14-pol brushless outrunner with high torque delivering direct drive for quick response. Its maximum mechanical power is 110 W and weights about 60 g. Basic propellers are 10x4.5. When 3S Li-Pol battery is used than there is need to use 12x3.8 slow fly propellers.
3.1.2
Electronic components
Mikrokopter UAV electronic set consists of three PCBs1 . These are Flight Controller, Navigation Controller and Brushless Controllers. These boards are formed in stack configuration connected to frame (Fig. 3.2) as is shown in Fig. 3.3. Last important system component is GPS board which is connected to Navigation Controller. It is equipped with u-blox LEA-6S GPS unit. Components scheme is shown in Fig. 3.6.
3.1.3
Flight Controller
Flight controller is the main electronic component. This board is responsible for basic air stabilization, particular engines control, relative height measurement and altitude control when it is enabled. It is also possible to connect buzzer and two sets of diodes to better show actual Mikrokopter state (errors and battery warning). 1
PCB - Printed circuit board is used to mechanically support and electrically connect electronic
components using conductive pathways, tracks or signal traces etched from copper sheets laminated onto a non-conductive substrate.
14
CHAPTER 3. MIKROKOPTER AERIAL VEHICLE
Figure 3.6: Mikrokopter system scheme
Flight controller uses two basic data buses to handle all its actions. There are I2C bus for engine control (Brushless Controllers), SPI bus for communication with with Navigation Controller. These buses will be described later in more detail. Flight controller has several base electronic components: - 8-bit, 16MHz microCPU - MEMS2 gyroscope and 3D accelerometer - pressure sensor - 5 servo outputs
2
MEMS (Micro-electro-mechanical system) is the technology of very small devices used predominantly
for measuring purposes
3.1. SYSTEM COMPONENTS
Figure 3.7: Flight controller - top side
3.1.3.1
15
Figure 3.8: Flight controller - bottom side
Radio control
Radio control is basic control tool for Mikrokopter UAV. It consist of remote controller and signal receiver, both manufactured by Futaba. It uses seven channels. Four of them are used to basic movement (gas, pitch, roll and yaw) and three rest are used for altitude control, GPS mode control and carefree control.
3.1.4
Brushless Controllers
Brushless controllers are basically drive microcontrollers. They are supplied with power directly from battery and controlled by I2C signals from Flight Controller.
Figure 3.9: Brushless controller - top side
3.1.5
Figure 3.10: Brushless controller - bottom side
Navigation Controller
Navigation controller provides Mikrokopter with GPS navigation a compass values. It is equipped with ARM-9 microcontroller, micro-SD card slot and integrated compass sensor. In combination with Mikrokopter GPS Navigation Controller is able to acquire GPS coordinates and navigate through set of predefined waypoints (if there is a connection
16
CHAPTER 3. MIKROKOPTER AERIAL VEHICLE
to additional computer, it is able to add waypoints dynamically during flight). Micro-SD card is used for GPS trajectory logging. Log interval is by default set to 500 ms, interval under 200 ms could cause problems with computational performance.
Figure 3.11: Navigation controller - top side
3.1.6
Additional components
3.1.6.1
GPS module
Figure 3.12: Navigation controller - bottom side
Mikrokopter UAV uses special dedicated GPS module (Fig. 3.13). Its refresh rate is 10 Hz. Mikrokopter uses at least six satellites for safety. Flight using GPS is not possible until signal from at least six satellites is acquired.
3.1.6.2
Bluetooth
Bluetooth is one of possible wireless communication channels that Mikrokopter UAV could use for its communication with MK-tool software on PC.
3.1.6.3
Camera mount
As was already mentioned in section 3.1.3., Mikrokopter is capable to drive servos. They can control camera mount so that the image/video capturing angle can change by remote control. System is also capable to deal with angle changes of Mikrokopter UAV and tries automatically hold camera mount in the same plane as was initially set.
3.2. MIKROKOPTER BUSES 3.1.6.4
17
Power source
Lithium-Polymer batteries are system’s only power source. All devices can run from 3S (11,1 V) to 5S (18,5 V), but 4S (14,8 V) are recomended. Attention has to be paid to propellers because if system is switched from 4S to 3S revolutions of motors decrease and appropriate propellers have to be used.
Figure 3.13: GPS module
3.2 3.2.1
Figure 3.14: Bluetooth modules in protective cover
Mikrokopter Buses I2C bus
I2C (Internal-internal circuit) is a multi-master serial single-ended computer bus invented by Philips that is used to attach low-speed peripherals. I2C uses only two bidirectional open-drain lines, pulled up with resistors on voltage supply line. Typical voltages used are 5 V or 3,3 V. This bus specifies two data lines: • SDA - serial data line • SCL - serial clock The I2C reference design has either 7-bit or 10-bit (depending on the device used) address space. Common I2C bus speeds are 100 kbit/s in standard mode and 10 kbit/s in low-speed mode. This bus is used to connect Flight Controller with Brushless Controllers.
18
CHAPTER 3. MIKROKOPTER AERIAL VEHICLE
Figure 3.15: I2C scheme
3.2.2
SPI bus
The Serial Peripheral Interface bus is a synchronous serial data link standard. SPI is used for communication between Flight Controller and Navigation Controller. This bus uses master/slave mode where master initializes communication link and defines data frame. SPI allows multiple slave devices but master device has to have individual slave select lines for each slave device. This bus specifies four logic signals:
• SCLK - serial clock(output from master device)
• MOSI - master output/slave input
• MISO - master input/slave output
• SS - slave select(output master from master device, active low)
Figure 3.16: SPI scheme
3.3. MIKROKOPTER SOFTWARE
3.3 3.3.1
19
Mikrokopter software MikrokopterTool
MikrokopterTool is basic control software provided by manufacturer. These are its major tasks: • flight modes settings • error check • graphical interface for telemetry • motor check and test utilities
Figure 3.17: Mikrokopter Tool
20
CHAPTER 3. MIKROKOPTER AERIAL VEHICLE
3.3.1.1
Default Mikrokopter flight modes
• Altitude hold - it controls Mikrokopter flight altitude autonomously. It uses information from pressure sensor on Flight Controller. When it is switched on than Mikrokopter holds current altitude. It works reliably from altitude 2 m above ground3 . • GPS mode - it uses three modes - Free, Position Hold, Coming Home. Free - Mikrokopter flies without any assistance (excl. Altitude hold). Position hold - Mikrokopter uses GPS and magnetometer to hold actual air position. Its position is changed only by movement of remote controller sticks. Coming home - In this mode Mikrokopter firstly flies uploaded set of waypoints and than it flies to its home position4 . • Carefree control - when this mode is enabled than Mikrokopter UAV heading is determined by angle between vectors from home position to north and its current position.
3.3.2
Mikrokopter OSD
Mikrokopter OSD5 is software tool for waypoint navigation. Mikrokopter waypoints are specified by these data: • longitude - standard east-west geographic coordinate • latitude - standard north-south geographic coordinate • altitude - height above ground in [dm] • heading - heading to north in [deg] • altitude rate - max allowed vertical speed in [dm/s] • speed - movement speed between waypoints in [dm/s] 3 4
When Mikrokopter is lower than 2 m than it is affected by aerodynamics of its propellers Home position is determined position when Mikrokopter starts its engines and altitude of Home
position is set in Mikrokopter settings 5 OSD - on screen display
3.3. MIKROKOPTER SOFTWARE
21
Additional data which could be set are waypoint id, waypoint type and some other which are not important for our purpose. This tool allows to insert 2d picture of environment which the Mikrokopter will fly in. This picture has to be tagged with GPS coordinates. Than it is possible to select mission waypoints in this graphic interface and Mikrokopter will fly by uploaded set of waypoints. It is also possible to wait on selected waypoint for defined time.
Figure 3.18: Example of Mikrokopter OSD with waypoint route
3.3.3
Mikrokopter setting
Mikrokopter setting affects its flight behavior. There are setting for flight stability, height stability, GPS and navigation settings, camera mount servo settings, diodes and signalization settings, etc.
22
CHAPTER 3. MIKROKOPTER AERIAL VEHICLE
Figure 3.19: Example of mission plan
3.4
Gumstix
Gumstix is small single-board computer. The software stack is Linux based, built using the open embedded framework. Gumstix Overo series is based on Texas Instrument OMAP processor built on ARM Cortex-A8 architecture. Its clock speed is 720 MHz, it is equipped with 512 MB of RAM memory and 512 MB of flash memory. It offers wide range of functions including OMAP6 , PXA7 , microSD, Bluetooth and 802.11g wireless interfaces, synchronous and asynchronous serial, USB, 10/100 Ethernet, RS-232 and DVID. This module is very compact - 58 mm long, 17 mm wide, 4,2 mm height. An expansion board (Tobi board) is used for providing I/O interfaces and other Gumstix Overo components to the rest of the system and to control Gumstix Overo computer as well as programs running on it. For this purposes Tobi board provides console I/O trough miniUSB socket and serial link(Rx/Tx) trough 40-pin header. Other devices like HDMi, Ethernet, OTG, 3,5 mm audio jack are also included but they are not relevant for our purposes.
Figure 3.20: Gumstix Overo Fire module 6
Figure 3.21: Tobi expansion board
OMAP - Open Multimedia Application Platform is category of proprietary system on chip (SoCs). It
includes ARM architecture based processor core co-equipped with one or more specialized co-processors. 7 PXA - part of microprocessor core responsible for I/O devices control
3.5. COMMUNICATION WITH MIKROKOPTER UAV
3.5
23
Communication with Mikrokopter UAV
The most suitable way of how to communicate with Mikrokopter UAV control system is serial link between Gumstix unit Navigation Controller. This link uses standard Rx and Tx lines and runs its own Mikrokopter serial data transfer protocol. This protocol uses base64-based algorithm for representation of binary data in an ASCII string format by translating it into a radix-648 representation. Cyclic redundancy check is used to verify that packet was not damaged during transport.
3.5.1
Mikrokopter Serial protocol
For communication on software level Mikrokopter UAV uses its own serial protocol. The protocol is based on individual serial data frames that are organized as shown in (Fig. 3.22) and its parts are described in the following list: • Start-byte - ASCII # - decimal value 35 • Address byte - ASCII character a + address of corresponding board according to Mikrokopter serial protocol (0 - GeneralCommands, 1 - FlightCtrl, 2 - NaviCtrl, 3 - MK3Mag, 5 - BlCtrl) - decimal value 97 • ID-byte - ASCII character that corresponds to specific command • N-byte of data - N-data bytes coded in modified-base64 (in Appendix A) • CRC check - two bytes of CRC (In appendix A) • Stop-byte - ASCII sign \r (carriage return) - decimal value 13
Figure 3.22: Mikrokopter serial protocol
8
The radix is the number of unique digits, including zero, that a positional numeric system uses to
represent numbers.
24
3.5.2
CHAPTER 3. MIKROKOPTER AERIAL VEHICLE
Hardware connection
Mikrokopter UAV uses serial link as default external communication tool. This communication link is integrated as 10-pin ribbon interface which is present on Flight-Ctrl board as on Navi-Ctrl board. This serial link uses standard RX (data receive - in) and TX (data transmit - out) lines for data connection, 5 V power supply and GND (ground). It is working with default TTL (transistor-transistor-logic). It is a class of digital circuits built from bipolar junction transistors and resistors. Default voltage logic levels are 0-0,8 V interpreted as logical 0 and 2-5 V as logical 1 on the input and 0-0,3 V as logical 0 and 2,7-5 V as logical 1 on the output and power voltage tolerance is 4,5-5,5 V.
Figure 3.23: Ribon 10-pin layout scheme
Decreasing voltages are today’s trend in electronics. Commonly used voltage levels are 3,3 V, 2,5 V, 1,8 V and 1,2 V. Gumstix uses 1,8 V GPIO standard for communication. From that reason, there is a need to assemble logic level converter between TTL 5 V logic on Mikrokopter UAV and GPIO 1,8 V on 40-pin header on Tobi board. A board was designed. Its scheme is shown on Fig. 3.24.
Figure 3.24: Converter basic electronic scheme
For conversion from TTL 5 V to GPIO 1,8 V voltage divider is used. For conversion from GPIO 1,8 V to TTL 5 V integrated circuit BSS138 (Appendix A) is used which is
3.5. COMMUNICATION WITH MIKROKOPTER UAV
25
Logic level enhancement mode field effect transistor. This integrated circuit is capable of converting logical levels from 1,2 V till 5 V. Up and down logic levels are defined by supply voltage so for this conversion we need both 5 V and 1,8 V supply voltages. Its maximum time delay is 36 ns.
26
CHAPTER 3. MIKROKOPTER AERIAL VEHICLE
Chapter 4 System architecture design Designed system has to be able to run and control multiple entities. System (in Fig. 4.1) consist of one Ground station and one or more UAVs. Wi-Fi network is used for their communication. Structure of Wi-Fi network allows each entity (Ground station is considered also as entity) to communicate with any other as it is shown in Fig. 4.1. Each entity is equipped by Wi-Fi modem.
Figure 4.1: System structure
UAV’s (aerial entity) internal structure is shown in Fig. 4.2. Gumstix unit with Wi-Fi modem was added to Mikrokopter UAV. It allows autonomous control of UAV. Implemented code runs on this Gumstix unit. This code is based on AgentFly system which will be described in more details in section [cislo sekce kde bude AF]. Most important class is Plane Agent which integrates modules (Trajectory Planner, Collision Solver ), communication interfaces and other components to provide system functionality. This structure runs on each real entity. 27
28
CHAPTER 4. SYSTEM ARCHITECTURE DESIGN
Figure 4.2: UAV internal structure
Ground station’s internal structure (Fig. 4.3) is more complex. Original system from Mikrokopter manufacturer is capable of communication with one entity by Bluetooth connection and to receive and display basic telemetry data. This Ground station has to be capable to communicate with multiple entities, to visualize their position and telemetry and to control these simulations. It also has to be capable to generate and run simulated entities. This simulation engine already works for airplanes in AgentFly so it was just customized for helicopters.
4.1
AgentFly
AgentFly is a multi-agent system enabling large-scale simulation of civilian and unmanned air traffic. AgentFly is implemented on Aglobe platform [5]. System integrates advanced flight path planning, decentralized collision avoidance with highly detailed models of the airplanes and the environment. It is based on Free flight concept.
4.1. AGENTFLY
29
Figure 4.3: Ground station internal structure
Our system is based on AgentFly and uses some functions which are already implemented in AgentFly, mainly communication, scenario manager, configuration parser and visualization.
4.1.1
Communication
Communication is handled by two basic tools in this system. First of them are topics. Topic are multicast messages which are broadcasted to all entities, but entity has to be subscribed to this topic service to accept it and then handle contained information/data. From this, it is obvious that topics do not need addresses and they have to use ServerTopicConstant1 , content2 and reason3 , but it is not mandatory. 1
This is used to identify topic and its content Content can be random object, but must be serializable 3 Reasons are used for additional classification of data, such as when position is set to behavior it 2
could be general position data and reason would remain null or it could be park point and than reason
30
CHAPTER 4. SYSTEM ARCHITECTURE DESIGN On the other hand, Messages, which is the second communication tool, are strictly
addressed. Messages are little bit more complex, also have content and reason as Topics and these two work completely the same and as addition there is sender address, receiver address and performative which works as content identification.
4.1.2
Configuration
Configuration determines whole scenario, environment, number and type of entities, their own missions and it even specifies which behavior, planner and also collision solver will be used for given entity. During system start, simulation manager calls configuration parser. Visualization settings are also parse from this configuration.
4.1.3
Visualization
Visualization is very important part of AgentFly system, because it is proper method of data representation in these large simulations. Telemetry from all real entities is updated one time per second. Telemetry contains position data, pitch, roll, yaw and battery voltage. There is example of 2d visualization in Fig. 4.4 and 3d visualization in Fig. 4.5. In Fig. 4.5 is shown safety zone cylinder around UAV. No-flight zones are colored to orange. Also mission waypoints are shown there.
will contain string PARKPOINT
4.1. AGENTFLY
Figure 4.4: Example of AgentFly system visualization in 2D perspective
Figure 4.5: Example of AgentFly system visualization in 3D perspective
31
32
CHAPTER 4. SYSTEM ARCHITECTURE DESIGN
Chapter 5 Communication Because there is no known satisfying communication architecture between Mikrokopter UAV and device using Java1 programming language, the communication architecture between AgentFly and Mikrokopter UAV had to be designed. Core of this architecture is shown in Fig. 5.1.
Figure 5.1: Communication architecture core
As it is shown on Fig. 5.1, architecture contains several classes and two interfaces (UAVConnector and ConnectionOwner ). Architecture has two sections - Java and C. All from section Java is running on Java virtual machine as rest of the AgentFly system. SerialComm handles communication on hardware level on Gumstix. It defines baud rate, 1
In other programming languages also. Java is used primarily because AgentFly is implemented in
Java.
33
34
CHAPTER 5. COMMUNICATION
serial link and socket2 which are used for input/output operation between Java virtual machine and serial link. Serial link works on GPIO 1,8 V standard as was mentioned previously. This communication structure is designed mainly for communication between AgnetFly system and Mikrokopter UAV, but from development reasons was suitable to be able of to communicate with simulation or by MK-USB. The extended architecture (Fig. 5.2) is capable to connect directly to Mikrokopter UAV through MK-USB with AgentFly air container running on PC and to be connected to simulated Mikrokopter UAV engine which runs on PC for basic testing and development.
Figure 5.2: Extended architecture core
Interface UAVConnector defines all functions required to establish and close connection and for sending data packets. Implementations of these functions are totally different in all connectors. For example connect function, which is responsible for initialization of connection between program and propriety device or class, in GXConnector connect output stream buffer to Java socket. In SerialConnector class connect function tries to open serial port which is MK-USB plugged in and in SimulationConnector, connect function initializes simulated Mikrokopter UAV engine. Other fuctions, like sendPacket(), are also different, but all of them work in a similar way. UAVConnector is responsible mainly for data transmitting (output stream) and, on the other hand, ConnectionOwner is responsible for data receiving (input stream). 2
Socket in Java is an endpoint in a standard connection. The Socket class implements methods which
take care of all the overhead required in communication.
5.1. RECEIVED PACKET PROCESSING
35
This interface handles LinkedList which stores complete incoming packets. Packets are recognized in GXConnector (or SerialConnector or SimulationConnector ) by reading input stream as ASCII characters until there startbyte is found. When startbyte is found than all characters are stored in ByteBuffer3 until a character which correspond to stopbyte is read. ByteBuffer content is than exported to byte array. Before this array is added to LinkedList of arrived packets it is checked in GXPacket class. Packet check consists of three levels where all of them are needed for packet to be marked as valid packet and added to LinkedList. First level just checks if there is enough charaters(bytes) in array4 . Second level checks if special characters (address byte and command byte) have valid values. Last level is cyclic redundancy check. After these checks pass, packed is added to LinkedeList and function responsible for packet processing is called.
5.1
Received packet processing
After packet income and verification pass, there is need to proceed several more steps before packet data became accessible. First step is modified-base64 decoding procedure. This modified-base64 encoding basically takes three byte of data and converts them into four byte and than to each this byte value adds ASCII sign ”=” (decimal value 61). Mechanism of three to four byte conversion is shown in Fig. 5.3. The rest two bits in new bytes are set to default values (zero). Now we have to reverse this procedure to access data. After that, decoded packet is distinguished according to its address byte and send to process to FlightCtrl class, NaviCtrl class, MK3Mag class, BlCtrl class or to GeneralCommand class. Most important of these is NaviCtrl class because all important packets from Mikrokopter UAV are created in Navigation Controller. Specifically these are Waypoint packet and Navi-OSD packet. Waypoint packet contains just number of waypoints currently uploaded in Mikrokopter UAV waypoint list and it is sent by Mikrokopter UAV when valid waypoint arrives. For us it works as confirmation that waypoint which we tried to upload to Mikrokopter UAV was succesfully transmitted. Mikrokopter UAV also makes beep sound when it arrives. Navi3
A ByteBuffer is a flexible array which grows when elements are appended. There are also methods
to append names to byte buffers and to convert byte buffers to names. 4 It is done simply by check if array size fits into minimal and maximal packet length.
36
CHAPTER 5. COMMUNICATION
Figure 5.3: Base64 byte conversion
OSD packet contains complete telemetry and has over 80 bytes and over 110 bytes when base64 encoded (just data). This telemetry consists of GPS and altitude coordinates of current position, home position and target5 position, air and ground speed, heading data from GPS, magnetometer and from gyro (inertial unit), battery voltage info, current waypoint index, distance and heading deviation from target and home position, nick (pitch) and roll, altitude info from pressure sensore and flags which describe Mikrokopter UAV devices state. This information is used to monitor deviation from flight plan, to inform other entities in shared space and as data for visualization.
5.2
Transmitted packet processing
Functions for data upload from Gumstix to Mikrokopter UAV are implemented in UAVCommunication class. There are several types of data that we are uploading. We use mainly Navi-OSD data request packet and waypoint packet. Mikrokopter UAV does not send any packet by itself, all provided information are on demand. Navi-OSD request packet specifies how often Navi-OSD packet should be provided in multiple of 10 ms. For ex5
Target position is position which si Mikrokopter UAV currently moving on (next waypoint).
5.2. TRANSMITTED PACKET PROCESSING
37
ample where there is value 25 than Navi-OSD packets are provided every 250 ms. This request is sent to Mikrokopter UAV every 4 second. Waypoint packet contains GPS coordinates in 10E-07 deg (longitude and latitude), altitude in dm, heading, wp index, wp type, altitude rate and speed. Heading has three possible setups. If it contains 0, than it mean that heading to target is set, if it is from 1 till 360 than heading is fixed to value as azimuth and when it contains negative number than it means that Mikrokopter UAV is oriented to POI6
5.2.1
Waypoint
For better handling of waypoints, Waypoint class was implemented. This class contains all data required for waypoint navigation, upload and path planning. At first, it contains coordinates, both GPS and Cartesian. GPS has longitude and latitude both in deg and altitude in m above ground. Cartesian coordinates use simple x,y,z variables (x corresponds to longitude, y to latitude and z to altitude). Cartesian coordinates are used because AgentFly system uses path navigation in Cartesian system. For conversion between GPS and Cartesian coordinates are used functions based world rotation and translation. World rotation uses rotation matrix and world translation vector. For their computation it is necessary to know origin point which is commonly representing [0,0,0] position in Cartesian and home position in GPS coordinate system. Another variables of Waypoint class are wpIndex which determine waypoint sequence and speed which UAV should be moving with. Waypoint requires another process steps before it is uploaded. First of all is to adapt numeric format. As it was mentioned before, longitude and latitude values need to be multiplied by 107 , altitude multiplied by 10 and also speed, which is in Mikrokopter UAV used in cm/s, multiplied by 102 and altitude rate, which is in Mikrokopter UAV used in dm/s, multiplied by 10.
After setting all mandatory values, Waypoint is ready to proceed to another step - conversion to byte field. As shown in Table 5.1, all mandatory variables have to be handled in specific way. Integers (s32) have to be cut in four bytes, short (s16) has to be cut in two byte and all unsigned variables have to be converted from their signed (Java default) format to unsigned format. Multi-byte variables (s32, s16) have to be 6
POI - Point Of Interest
38
CHAPTER 5. COMMUNICATION var id data type 1
s32
var name
units
edit description
Longitude
deg
107
GPS coordinate
7
2
s32
Latitude
deg
10
GPS coordinate
3
s32
Altitude
m
10
GPS height above ground
4
u8
Status
-
-
decribes validity of wp data
5
s16
Heading
deg
1
orientation
9
u8
Index
-
-
index of wp in sequence
10
u8
wp type
-
-
type of wp
12
u8
Altitude rate
m/s
10
climb speed
13
u8
Speed
m/s
102
speed between wps
Table 5.1: Waypoint mandatory variables and their description
also switched from big endian (Java default) to little endian (C default). Conversion algorithm of s32 in Appendix A. When this conversions are complete (size of byte array representing waypoint is then 30 byte) it is time for modified-base64 encoding. After successful encoding, start-byte, address-byte and command-byte are added. Cyclic redundancy check is then counted for whole data array. Its value is appended at the end of array followed by stop byte. Now the packet is ready to be send. To ensure that Mikrokopter UAV will be able to process incoming packet, delay between individual packets was set 50 ms.
Chapter 6 Flight Planning Planning, in general, is one of the major fields of research in artificial intelligence. Path planning algorithms are used for finding path between two states, start (S) and goal (G), in space. In case of aircrafts, it is proper to find their trajectories. Difference between path and trajectory is that trajectory is function of time. So the trajectory is continuous function from a certain time interval. From that, a trajectory planning problem is set by entity’s (aircraft) initial dynamic configuration, goal dynamic configuration and set of constrains defined by space. This is very complex problem and there are a lot of teams all over the world solving this problem. There are a lot of different algorithms for trajectory planning but for purposes of our goals two of them were chosen - AA* and Hexgrid. Both these planning algorithms are used in AgentFly system and provide nearly optimal trajectory.
6.1
AA* - Accelered A*
AA* algorithm is principle based on A* algorithm. A* uses a best-first search and finds a least-cost path from a given initial state to one goal state. As A* traverses the graph, it follows a path of the lowest known heuristic cost, keeping a sorted priority queue of alternate path segments along the way. It uses a distance-plus-cost heuristic function of node to determine the order in which the search visits nodes in the tree [1]. AA* improves A* by using adaptive sampling of space. It allows dynamic sampling that provides good balanced compromise between computation time to find nearly optimal trajectory and sufficient level of searched space. Horizontal and vertical direction 39
40
CHAPTER 6. FLIGHT PLANNING
of sampling are distinguished. Sampling step is determined by distance between actual position and obstacle position. The increasing density of samples in area close to obstacle is shown in Fig. 6.1.
Figure 6.1: Two-dimensional example of the adaptive sampling, from [1]
Size of sampling step is corresponding to distance to closest obstacle in way that the distance from the closest obstacle will not be lower than double of sample step. As protection against generating too much successors there is a rule that only three successors will be generated. First represents straight element with distance of sample step and two others are turn elements with minimum radius (Fig. 6.2). According to way how states are generated path would contain unnecessary lot of turn elements and will became longer. Because of these needs, path needs to be smooth. More about path smoothing in [1].
6.2
Hexgrid
Hexgrid is not classical path planning algorithm. It is principle how to convert space into state-space. Hexgrid uses hexagons as a grid for space sampling. This process is called tessellation. Generally tessellation is the process of creating a two-dimensional plane using the repetition of a geometric shape with no overlaps and no gaps. Generalizations to higher dimensions are also possible. Tessellations are classified as regular, semi-regular
6.2. HEXGRID
41
Figure 6.2: Example of generated successors, from [1]
and irregular. Regular tessellation uses only one kind of geometric shapes, semi-regular uses more kinds of geometric shapes, but they still have to be organized. Irregular tessellation uses variety of different shapes and has no general organization. From that is obvious that only regular tessellation is suitable for this space division. Vertically is space divided in planes which must be considered as flight levels. Then, the discretization of the space forms structure similar to honeycomb. Hexagon size should be corresponding to size of obstacles, because during tessellation are these cells marked as allowed when there is no obstacle inside or as denied when there is an obstacle or its part. To be able to find path on hexagon tessellation it is necessary to use some path planning algorithm. As best option Lazy Theta* algorithm was chosen. Theta* is based on A* algorithm, but Theta* is capable of connecting nonadjacent states. Theta* connects two nonadjacent states when there is a straight line between them which does not go trough any denied cells (LOS1 ). Lazy Theta* is extension of Theta* algorithm. The only difference is that Lazy Theta* optimistically presumes that connection between found nonadjacent states is possible for reducing LOS. LOS is computed after the selected node is chosen from open-node list. There are 14 adjacent states in this space discretization (Fig. 6.3 plus two for adjacent flight levels) and, from that, there are three basic maneuvers defined on hexgrid - straight, turn and pitch. Straight represents direct flight to adjacent state. Turn maneuvers are on basic level limited to turn by multiple of π/6. Pitch maneuver represent 1
LOS - Line Of Sight
42
CHAPTER 6. FLIGHT PLANNING
change of flight level [9].
Figure 6.3: Representation of adjacent states on hexagonal grid, from [8]
AgentFly system is capable to visualize Hexgrid and cells which are in open-node list are colored to blue (Fig. 6.4).
6.3
Implementation and testing
In difference to Hexgrid, the AA* was not originally designed for VTOLs, but for CTOLs2 , so there was a need to customize AA* algorithm to expand flight planning option for VTOLs. VTOLs are able to stop in the air or move just vertically in difference to CTOLs. Hexgrid algorithm was designed for VTOLs, so there was nothing to customized. In this configuration both planning algorithm are capable of nearly the same set of maneuvers. From experiments of AA* and Hexgrid algorithms in [7] it is clear, that Hexgrid with Lazy Theta* shows very good performance but only in environments with pregenerated hexgrid map. Generation of this map is computationally very difficult. Until the map generation will not be optimalized the hexgrid algorithms are almost unusable. It is clear that only AA* planning algorithm can be used at present. 2
CTOL - Conventional Take-Off and Landing
6.3. IMPLEMENTATION AND TESTING
43
Figure 6.4: Visualization of planned path by Hexgrid with colored open nodes
6.3.1
Plan conversion
In AgentFly system when the plan is finished it has a form of elements3 . These elements together are forming continuous path. These elements are used to build flight plan wraper which you can see in Fig. 4.5 and in Fig. 4.4. This from of plan is not acceptable for Mikrokopter UAV. Therefore we had to implement some algorithm which will extract waypoints from this plan. That is not complicated for straight elements (only first and last points of straight element are converted to waypoints). Other elements are more complicated. All turn elements are interpolated to waypoints that way so the trajectory vector (yaw) can change at most by 10◦ . This path interpolation is shown in Fig. 6.5 and in Fig. 6.6. In Fig. 6.5 the path is surrounded by its wrapper and on Fig. 6.6 the path is already interpolated to waypoints. 3
These elements are for example: straight element, turn element, spiral element, etc.
44
CHAPTER 6. FLIGHT PLANNING
Figure 6.5: Part of track in visualization
Figure 6.6: Interpolated part of track in MK-OSD
6.3.2
Plan checking
Deviation from plan is checked automatically by Monitor thread which compares actual position with expected plan position. This check does not run only in space but also in time. When the difference between actual and expected position is over limit replanning processis starting. Replanning works the same way as initial planning, only start position is different.
Chapter 7 Collision Detection and Deconfliction As was mentioned in chapters before, AgentFly system is conceptually built on free-flight concept. This concept is based on aircraft mutual communication and also on their ability to mutually solve collision situations. Algorithm to solve this problem has to deal with fact that aircraft is moving (initial position is changing) during the time algorithm is solving collision situation. Helicopter is able to stop during flight but that is highly ineffective in majority of situations. In free-flight concept aircraft can communicate between themselves and so they are capable of exchanging flight plans or their parts. In Agentfly system, there are two algorithms used for collision deconfliction - Iterative peer-to-peer collision avoidance (IPPCA) and Multiparty collision avoidance (MPCA).
7.1
Collision Detection
Collision is detected when there is disruption of safety zone of aircraft by another aircraft. Aircraft safety zone is represented as a cylinder around aircraft. Different aircraft can have different safety zone. In practice it works that when some aircraft gets into communication distance it is ask to send flight plan. This flight plans exchange is mutual and both aircraft check if there is possibility of collision. 45
46
CHAPTER 7. COLLISION DETECTION AND DECONFLICTION
Figure 7.1: Example of collision situation, from [4]
In Fig. 7.1 you can see an example of collision situation when time t1 is time of first possible collision and time t2 is time of last possible collision. These collisions are possible because collision is not detected at time when aircraft mutually crash in themselves but at the moment when aircraft Aj touches aircraft’s Ai safety zone. They both detect the same collision because they both have second’s aircraft’s flight plan fp.
7.2
Collision Deconfliction
Both mentioned algorithms (IPPCA and MPCA) use evaluation function to find out the best flight trajectory. To evaluate the path price same function as for trajectory planning is used. Price of a new flight plan is not computed from that part only but from whole flight plan. Both algorithms use same bunch of maneuvers: turn left or right, climb, descent, acceleration, deceleration and zero maneuver1 . In case of VTOL is possible to advance this set by stop and reverse maneuvers. This two maneuvers could be used during some super-conflict2 or in small space but in open-space are these two maneuvers very inefficient. Evasive maneuver set is defined as m(f pi , Wi , u, tum , t1 , t2 ), where f pi is flight plan being modified, Wi contains sequence of points of interest, u is a parameter of evasive maneuver, tum defines position in flight plan f pi after which can be this flight plan edited and t1 and t2 define position in flight plan f pi , where will be the evasive maneuver used. 1 2
Zero maneuver holds still the same speed and direction. When a multiple aircraft detect collision to multiple others.
7.2. COLLISION DECONFLICTION
47
Generation of new maneuver can fail if maneuver is not feasible. All maneuvers have to satisfy condition tum < t1 < t2 . Evasive maneuvers use two points of interests w1 , w2 as it is shown in Fig. 7.2 (evasive maneuver turn right). Even if there is just acceleration or deceleration as first point, the aircraft have to get to original (mostly optimal) speed on second point.
Figure 7.2: Evasive maneuver to right, from [4]
7.2.1
Iterative peer-to-peer collision avoidance - IPPCA
IPPCA algorithm solves collision only in pair of two aircraft. If there is more aircraft, the IPPCA algorithm runs multiple times. If there are more than three aircraft is possible to run more instances of this algorithm. Each of them solves collision situation for another pair of aircraft. Collision with shortest time are preferred and solved as first. If there are more aircraft heading to same collision situation (as in Fig. 7.3) than aircraft A1 randomly chooses aircraft A2 and tries to solve the collision. After that, aircraft A1 choose aircraft Ai , which has shortest collision time with aircraft A1 and runs this algorithm same for all aircraft until collision free trajectory is found for all of them (as in Fig. 7.4).
7.2.2
Multiparty collision avoidance - MPCA
MPCA algorithm generates groups of co-working aircraft which have common collisions in their flight plans. Because of this principle, new flight plans do not generate new collisions. MPCA algorithm needs only one run to solve collision in group of aircraft but
48
CHAPTER 7. COLLISION DETECTION AND DECONFLICTION
Algorithm 1 IPPCA algorithm, from [7] Hj ← GetM ostImportantOpponent(); u ← 1; Fi ← null; repeat Fi ← P repareEvasions(f pi , Wi , u, t1 , t2 , M ); cost ← M aximumCost(f pi , Wi , u, t1 , t2 ); Fi ← ExtW ithAllCheaper(f pi , Wi , u, t1 , t2 , M, cost); SendEvasions(Fi , Hj ); Fj ← W aitF orOpponentsEvasions(Hj ) Si ← P repareN egotiationSet(Fi , Fj ); u + +; until Si ! = null f pi ← SelectSolutions(Si , Hj ) ApplyF lightP lan(f pi ); it is more complex and computationally difficult than IPPCA algorithm. Aircraft could have two roles in this algorithm: • coordinator of collision situation • participant Only one aircraft could be coordinator of collision situation (it has also participant role). Other aircraft are participants. The aircraft which as first found out collision becomes coordinator. Coordinator than asks all other aircraft involved in collision to participate. MPCA algorithm uses for pathfinding algorithm based on A* where its state-space is defined by states which represent flight plans of participants. State-space is generate during collision solving process. There are just original flight plans in open list at the beginning. From that moment algorithm works that it choose lowest price state and checks if that solution is collision free. Expansions are managed that the pair of aircraft which are in collision are asked to generate set of evasive maneuvers for this situation. This evasive maneuvers are generated as in IPPCA algorithm.
7.2. COLLISION DECONFLICTION
Algorithm 2 MPCA algorithm, from [7] Grounp ← H s0 ← InitialState(); OP EN ← s0 ; while OP EN ! = null do scurrent ← RemoveBest(OP EN ); Hinv ← AllCollisions(scurrent ); if Hinv ! = null then InviteAircraf t(Hinv ); Group ← Group ∪ Hinv ; scurrent ← ExtState(scurrent ) end if if HasN oCollision(scurrent ) then ApplyF lightP lan(scurrent ); return; end if I ← SelectP air(scurrent ); u ← 1; repeat S ← P repareEvasion(scurrent , I, u); u + +; until S! = null N ← GenerateN ewStates(S, scurrent ); OP EN ← OP EN ∪ N ; end while F ailure(Group)
49
50
CHAPTER 7. COLLISION DETECTION AND DECONFLICTION
Figure 7.3: Example of super-conflict situation of ten aircraft
Figure 7.4: Example collision free trajectories
Chapter 8 Simulation and Experiments Purely software simulations were run before the system was deployed on hardware. After successful simulation was system deployed on hardware and tried alone without other entities, either real or simulated. After pass these experiments last step to simulation of multiple entities with collision avoidance mechanisms was taken.
8.1
Computer Simulations
AgentFly system provides tools for simulations. These simulation runs on ground platform but aerial platform is not involved. To be able to involve aerial platform program part to computer simulation was needed to develop engine which simulates Mikrokopter UAV.
8.1.1
Simulated Mikrokopter UAV
This engine is important to verify whether the designed architecture and whole implemented code works. The requirement for this engine is generally to behave as much as real Mikrokopter UAV as possible. There is no need to implement all functions and commands which Mikrokopter UAV supports because all of them are not used in our system. Waypoints utilities were necessary functions which have to be implemented on receive side and telemetry (OSD-packet) on transmit side of designed engine. Designed architecture (Fig. 8.1) consist of three basic classes - Receiver, Flight Engine and Transmitter. Receiver is responsible for income of packets, their verification, 51
52
CHAPTER 8. SIMULATION AND EXPERIMENTS
encoding and processing of their data. Packets are transmitted in form of byte arrays1 . These arrays proceed the same check as arrays which arrive from Mikrokopter. First of all there is CRC check, than the data from packet are encoded from modified-base64 and then they are processed. When waypoint is received than it is added to list of waypoints. Transmitter is responsible for providing telemetry packets. These packets use actual position from FlightEngine and than process it into Mikrokopter UAV packet. These packets are send to SimulationConnector every 190 ms like it is default in Mikrokopter UAV. FlightEngine uses uploaded waypoints from SimulationConnector and counts position every 50 ms. This engine is not capable of computing pitch, roll and yaw and for purposes of this simulation basic 3D position is enough.
Figure 8.1: Core of engine architecture
This engine is need before the program is tried on real Mikrokopter UAV. After implemented solution is verified it is deployed on real Mikrokopter UAV.
8.1.2
Hybrid Simulation
Hybrid simulation is type of simulation where one or more simulation entities are real and one or more entities are simulated. This simulation is used to ensure that all subsystems are running reliably before more real UAV are plugged in shared space. This simulation was also run with simulated Mikrokopter UAV before was system deployed on hardware. 1
Definition - http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Byte.html
8.1. COMPUTER SIMULATIONS
Figure 8.2: Hybrid simulation visualization example
Figure 8.3: Hybrid simulation visualization example in 3D perpective
53
54
8.2
CHAPTER 8. SIMULATION AND EXPERIMENTS
Experiments
We have carried out a set of experiments to verify that implemented system works in situation it was designed for. These experiments gradually increase their difficulty level.
8.2.1
Basic experiment
First we had to test if assembled UAV is capable of simple flight which is controlled by remote operator. During that test it was also possible to verify that pressure sensor is working properly and that the model is able to hold flight level automatically even during 2D maneuvers. Flight behavior is strongly affected by weather conditions. Even quite slow wind (1-3 m/s) shows significant position drift. UAV has auto-trim function what is observable in windless conditions (UAV holds its position).
Figure 8.4: Mikrokopter UAV during flight
8.2. EXPERIMENTS
8.2.2
55
Navigation experiment
Navigation controller and GPS units were used in next level of experiments. Flight using GPS waypoints was tried. For that purpose, Mikrokopter software was used. Ground texture with GPS marks were exported from GeoMapTool2 . GPS flight stabilization helps to hold UAV position, even in windy conditions (up to 5 m/s, flight in weather conditions with wind speed over 5 m/s is not safe), in radius about 1 m.
8.2.3
Autonomous planning experiment
Direct connection between AA* planner and Mikrokopter was tested. Scenario in Fig. 8.5 was used for this experiment. This environment is quite complex so path planning took over 35 seconds on Gumstix. Hexgrid algorithm was about 40% faster but it had worked with pregenerated environment map. Than the plan was interpolated to waypoints which were upload to Mikrokopter UAV to flight it through.
Figure 8.5: Scenario model
2
GeoMapTool is freeware web application capable of export images with GPS marks which can be
used for Mikrokopter software - http://www.geomaptool.de
56
8.2.4
CHAPTER 8. SIMULATION AND EXPERIMENTS
Autonomous flight with Collision avoidance
Final step of flight experiments was complete system with autonomous flight. Communication over WiFi was already tested in laboratory. AA* planner works in scenarios with less obstacles much better and in these condition it provides nearly same performance as Hexgrid algorithms even with pregenerated map. IPPCA algorithm was used for collision avoidance during this experiment. It took place in area 50 x 50 m. Scenario was set to collision situation between real UAV and one simulated entity. Fig. 8.6 shows original trajectories before collision deconfliction and Fig. 8.7 shows replanned collision free trajectories.
Figure 8.6: Trajectories before replanning from collision avoidance
Original trajectories was intentionally crossed to cause collision situation in this scenario. In Fig. 8.6, there is green between entities which marks that entities are solve collision situation in this moment. Collision free trajectories (in Fig. 8.7) were replanned within eight seconds after simulation start. New trajectories were replanned in the same flight level as original trajectories so altitude changes were not needed. This scenario was using all designed system components (communication, trajectory planning and collision avoidance).
8.2. EXPERIMENTS
57
Figure 8.7: Trajectories after replanning from collision avoidance
Complex experiment proved that designed architecture and implementation works as was expected. Unfortunately inappropriate weather condition did not allow another tests (i.e. speed calibration or more complex scenarios).
58
CHAPTER 8. SIMULATION AND EXPERIMENTS
Chapter 9 Conclusion Goal of this thesis was to design and implement software system for control of autonomous flight of unmanned helicopters. They were represented by Mikrokopter UAV which was assembled as a first part of this thesis. Thesis provides description of basic hardware modules, software components, designed architecture and deployment on real UAV. All these goals were successfully tested in set of field experiments on Mikrokopter UAV and Gumstix on-board computer. Based on results of experiments we discovered that AA* is currently the most suitable planning algorithm in most of possible missions and scenario, just in environments with a lot of obstacles Hexgrid planner provides better performance. All algorithms and solutions were thoroughly tested and verified in AgentFly system with use of Aglobe framework and later deployed on hardware to minimize possible risk of accident. Collision detection and deconfliction was tested on simulated entities and than in hybrid simulation when one aircraft was real and the second one was simulated. AA* algorithm was used for re-planning in collision situations. These experiments proved functionallity of proposed system and shown to be suitable for future free-flight concept.
9.1
Thesis achievements
• Mikrokopter UAV with customized battery holder and center stack of PCB was assembled. Gumstix SOC was integrated as additional onboard computer. • Connection for data exchange between Navigation controller and Gumstix was designed, appropriate communication protocol was implemented. 59
60
CHAPTER 9. CONCLUSION • Algorithms for autonomous trajectory planning were integrated into designed system based on AgentFly framework. • Autonomous helicopter was integrated into a shared space with other simulated autonomous UAVs. • Algorithm for collision detection and deconfliction was integrated into a system. • Designed and implemented solutions were experimentally verified.
9.2
Future work
Our work on Mikrokopter UAV project will continue. System will be extensively tested and calibrated. Hexgrid algorithm will be optimized, mainly the environment map generation. Main future goals are to run two real VTOLs in shared space and their integration to shared space with other type of aircraft, especially fixed-wing. This integration will require development of new communication platform because with planes included in the field experiments the communication range required grows rapidly.
Bibliography ˇ SL ˇ AK, ´ [1] SI D.; (2011), Autonomous Collision Avoidance in Air-Traffic Domain, PhD ˇ Thesis, CVUT v Praze ˇ SL ˇ AK, ´ ˇ ˇ [2] SI D.; SAMEK, J.; PECHOU CEK, M. (2011)Decentralized Algorithms for Collision Avoidance in Airspace, In PADGHAM et al. (Ed.) Proceedings of 7th Internation Conference on Autonomous Agents and Multi-Agent Systems (AAMAS), Estoril, Portugal, ISBN 978-098-1738-130 ˇ SL ˇ AK, ´ [3] SI D. et al. (2011), AGENTFLY: NAS-wide simulation framework integrating algorithms for automated collision avoidance, In Integrated Communications, Navigation and Surveilance Conference (ICNS), F7-1 - F7-11, IEEE, ISBN 978-14577-0593 ˇ SL ˇ AK, ´ ˇ ˇ [4] SI D.; VOLF, P.; PECHOU CEK, M. (2011), Agent-Based Cooperative Decentralized Airplane Collision Avoidance, Transaction on Intelligent Transportation Systems, 36-46, IEEE, ISSN 1524-9050 ˇ SL ˇ AK, ´ ´ ˇ ˇ [5] SI D.; REHAK, M.; PECHOU CEK, M (2005), A-globe: Multi-agent Platform with Advanced Simulation and Visualization Support, In SKOWRON, A. et al. (Ed.) Web Intelligence, 805-806, IEEE Computer Society, ISBN 0-7695-2415-X [6] AUSTIN, R. (2010), Unmanned Air Systems: UAV Design, Development and Deployment, Wiley ˇ ´IK, T. (2012), Pl´anova´an´ı trajektori´ı a ˇreˇsen´ı kolizn´ıch situac´ı pro autonomn´ı [7] BEL ˇ bezpilotn´ı helikopt´ery, Diploma Thesis, CVUT v Praze [8] CHRPA, L.; (2011), Trajectory Planning: Augmented Path Planning Methods by Considering Dynamic Properties of Autonomous Entities 61
62
BIBLIOGRAPHY
[9] CHRPA, L.; (2011), Trajectory Planning on Grids: Considering Speed Limit Constrains, Proceedings of SACLIOS, IOS Press, 60-69 [10] CHRPA, L.; KOMENDA, A. (2011), Smoothed Hex-grid Trajectory Plannning Using Helicopter Dynamics, Proceedings of International Conference on Intelligence (ICAART), SciTePress Press, 629-632, ISBN 978-989-8425-40
Apendix A Implementations A.1 A.1.1
Mikrokopter communication protocol Modified-base64 code
Base64 encoding schemes are commonly used when there is a need to encode binary data. This is to ensure that the data remain intact without modification during transport. This is to ensure that the data remain intact without modification during transport. This algorithm is used for encoding data to modified-base64: void encode64(char cmd, char addr, char *snd, char len) { int pt = 0; char a,b,c; char ptr = 0; sendBuffer[pt++] = ’#’;
// Start-Byte
sendBuffer[pt++] = ’a’ + addr;
// Adress
sendBuffer[pt++] = cmd;
// Command
while(len) { if(len) { a = snd[ptr++]; len--;} else a = 0; if(len) { b = snd[ptr++]; len--;} else b = 0; if(len) { c = snd[ptr++]; len--;} else c = 0; sendBuffer[pt++] = ’=’ + (a >> 2); sendBuffer[pt++] = ’=’ + (((a & 0x03) > 4)); sendBuffer[pt++] = ’=’ + (((b & 0x0f) > 6)); sendBuffer[pt++] = ’=’ + ( c & 0x3f); } addCRC(); }
I
II
APENDIX A. IMPLEMENTATIONS This algorithm is used for decoding data from modified-base64: void decode64(char *ptrOut, char len, char ptrIn, char max) { char a,b,c,d; char ptr = 0; char x,y,z; while(len) { a = rxdBuffer[ptrIn++] - ’=’; b = rxdBuffer[ptrIn++] - ’=’; c = rxdBuffer[ptrIn++] - ’=’; d = rxdBuffer[ptrIn++] - ’=’; if(ptrIn > max - 2) break; x = (a > 4); y = ((b & 0x0f) > 2); z = ((c & 0x03)
