5T746, Graduation project Eindhoven University of Technology Thales Nederland B.V
Store-and-Forward Networking Solutions with Autonomous Aerial Vehicles Robotics and Networking Shyam Balasubramanian (Embedded Systems, 0785610) Committee: Prof. Dr. H. Corporaal (TU/e) Dr. Ir. P.H.F.M. Verhoeven (TU/e) Ir. M. Wijtvliet (TU/e) Dr. Ir. M de Graaf (Thales) Dr. Ir. G.J. Hoekstra (Thales)
January 2, 2014
Abstract In this thesis, the technology of Mobile Ad-Hoc Networks (MANETs) along with Disruption Tolerant Networking (DTN), a store-and-forward approach, is made to interact with the navigation software of a multirotor aircraft to perform certain tasks during navigation, autonomously. The MANET is a popular research topic that deals with the routing of information between systems in motion. The DTN is a fairly new field of research that enables networking in extreme environments that may lack continuous network connectivity. Most of the prior work in the area of MANETs and DTN have been performed using simulations. This research aims to extend the mobile networking with DTN technology in order to improve the robustness of communication. A practical implementation presents the complex dynamics of wireless environments and poses new challenges. The multirotor is chosen as the mobile node and is made to fly to several waypoints (base stations) using GPS. It hovers in the given region by establishing an on-the-fly network connection. Exchange of required data such as files, video or any critical data exchange is initiated upon a successful connection. This concept leads us to diverse potential applications where network infrastructure is unavailable; such as in the field of military operations, surveillance of civilian areas and forwarding video images during search and rescue operations. The main focus of this research is on the deployment of an autonomous mobile node to exchange data with other static nodes, using DTN technology. Further, extensions to DTN are proposed and a new algorithm is developed to make autonomous networking more intelligent. Additional research and development has been carried out to improve the stability of the hovering platform and to extend the flight times. Keywords DTN - Disruption Tolerant Networking MANET - Mobile Ad-Hoc Networks UAV - Autonomous Multirotor, Multicopter, Micro-Aerial Vehicles or Drones
1
Acknowledgements This thesis is written as part of my master degree in Embedded Systems at Eindhoven University of Technology. The work in this thesis is conducted at Thales Nederland B.V., at Huizen. I have always had a deep interest for how stuff works and this especially applies to embedded systems and aerial robotics. The main motivation of this work is towards application specific multirotors. Implementing, experimenting and extending the state-of-the-art multirotor technology has been a perfect assignment for me. Working in the area of wireless networks has been an equally rewarding experience. I would like to extend my gratitude to prof. dr. Henk Corporaal, my graduation supervisor at Eindhoven University of Technology. His timely guidance and encouragement to explore the amazing world of multirotors has helped me immensely. I thank ir. Mark Wijtvliet whose ideas in thesis have helped me reflect on my work. I would like to show my appreciation to dr. ir. Richard Verhoeven for accepting to be part of this committee. At Thales Nederland B.V, I have been given the freedom to explore and to pursuit any new idea that I have come up with. For giving me such freedom in my work, and for their guidance, I would like to thank dr. ir. Maurits de Graaf and dr. ir. Gerard Hoekstra, my daily supervisors at Thales. My appreciation to Robert Hodkinson, for all the fruitful technical discussions we have had during my tenure. I thank my colleagues Javier, Stefan and Gertjan for critical review of my work and their timely feedback. My colleagues Sunil John, Suhas Pai and Ashwin Bhat, at the University of Eindhoven, who have encouraged me to pursue my dream. In the end, I offer my special thanks to Vimitha for her love and care and to make me into a better person. My family in India, for without whose love and encouragement I would have forgot to innovate. Shyam Balasubramanian Hilversum, January 1, 2014
2
About Thales Thales is a French company with top market presence, in both military and civilian domains. Thales is one of the most well known companies in the sectors of defense, ground transportation, civil security and aerospace.
Figure 1: Thales Group logo. Thales Nederland B.V is a Dutch brand of Thales group, has about 2,000 employees working at various branches, located in Hengelo (HQ), Enschede, Eindhoven, Delft and Huizen. Thales, located at Huizen, is the leading defence communications company in The Netherlands. It is a supplier of high quality integrated communications equipments for both the military and commercial organisations, with requirements for high technology multimedia networks.
3
Contents List of Abbreviations
7
1 Introduction
13
2 Related Work
17
3 Mobile Platform Selection 21 3.1 Classification of aerial vehicles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Multicopter platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3 Networking platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4 Wireless Networking 4.1 Internet protocol stack (TCP/IP) . 4.2 Wireless networks . . . . . . . . . . 4.3 Mobile ad-hoc network (MANET) 4.4 MANET routing protocols . . . . . 4.5 Selection of OLSR routing . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
34 34 35 37 38 41
5 Disruption Tolerant Networking 5.1 DTN history . . . . . . . . . . 5.2 Features of DTN . . . . . . . . 5.3 Bundle layer protocol . . . . . 5.4 IBR-DTN . . . . . . . . . . . . 5.5 IBR-DTN mechanism . . . . . 5.6 Limitations of DTN design . . 5.7 Extending the DTN design . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
43 43 44 45 48 49 52 52
. . . . . . .
. . . . . . .
6 Network Setup on Raspberry Pi 6.1 Node configuration . . . . . . . . . 6.2 MANET setup . . . . . . . . . . . 6.3 Mesh network . . . . . . . . . . . . 6.4 OLSR plugins . . . . . . . . . . . . 6.5 OLSR and IBR-DTN configuration 6.6 Communication between layers . .
. . . . . . . . . . . . . . . . . . . . settings . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
56 56 60 62 64 66 68
7 Multicopter Hardware 7.1 System architecture . . . 7.2 Sensors . . . . . . . . . . 7.3 Flight controller . . . . . 7.4 Electronics and actuators
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
69 70 70 73 74
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
4
. . . .
. . . .
. . . .
7.5 7.6 7.7 7.8 7.9
Power supply . . . . . . . . Communication equipment Frame specifications . . . . Networking hardware . . . . List of components . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
76 78 80 81 81
8 Multicopter Software 8.1 Mathematical model of the quadcopter 8.2 Sensor Fusion Algorithm . . . . . . . . 8.3 Quadcopter configuration . . . . . . . 8.4 Software architecture . . . . . . . . . . 8.5 Modes of operation . . . . . . . . . . . 8.6 Flight configuration . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
84 84 86 87 88 89 90
. . . . .
. . . . .
93 93 97 98 98 99
. . . . . . .
101 . 101 . 101 . 102 . 103 . 104 . 105 . 106
. . . . .
109 . 109 . 112 . 112 . 113 . 115
. . . . .
117 . 117 . 118 . 119 . 119 . 122
. . . . . .
127 . 127 . 128 . 131 . 133 . 135 . 136
9 Performance Analysis and Improvements 9.1 Measures to improve stability . . . . . . . . . . . 9.2 Hover tests . . . . . . . . . . . . . . . . . . . . . 9.3 Power consumption tests . . . . . . . . . . . . . . 9.3.1 Power consumed by networking hardware 9.3.2 Power consumed by aerial vehicle . . . . . 10 Aerial Network Protocol 10.1 Extended network stack . . . . . . 10.2 Background of the protocol . . . . 10.3 Aerial-network protocol . . . . . . 10.3.1 XML Configuration file . . 10.3.2 Query the OLSR and DTN 10.3.3 Client server architecture . 10.3.4 Network flight interaction .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
11 Waypoint Networking 11.1 ETX Measurements with antenna orientation 11.1.1 Tests with antenna orientation . . . . 11.2 Mission Planning . . . . . . . . . . . . . . . . 11.3 Waypoint networking . . . . . . . . . . . . . . 11.4 Results . . . . . . . . . . . . . . . . . . . . . . 12 Analysis of Interferences 12.1 Wireless devices on multicopter 12.2 Understanding power scale . . . 12.3 Frequency bands . . . . . . . . 12.3.1 2.4 GHz spectrum . . . 12.3.2 1.5 GHz spectrum . . . 13 Extended Flight Times 13.1 Motivation . . . . . . . . . 13.2 Factors affecting flight time 13.3 Selection of components . . 13.4 Power analysis . . . . . . . 13.5 Energy source . . . . . . . . 13.6 Flight time results . . . . .
. . . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
5
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . . .
14 Conclusions 138 14.1 Summary of contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 14.2 Insights and conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 14.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 A Hardware and Software Details
142
B Networking Principles
146
C Complete Network Configuration
149
Bibliography
173
6
List of Abbreviations
AHRS
Attitude and Heading Reference System
AP I
Application Programming Interface
BP A
bundle protocol agent
dB
Decibel
dBm
decibel-milliwatt
DCM
Direction Cosine Matrix
DHT
Distributed Hash Table
DSSS
Direct Sequence Spread Spectrum
DT N
Disruption Tolerant Networking
EEP ROM Electrically Erasable Programmable Read-Only Memory ESA
European Space Agency
ESSID
Extended Service Set Identification
ET X
Expected Transmission Time Metric
ET X
Expected Transmission count metric
F AA
Federal Aviation Administration
F HSS
Frequency Hopping Spread Spectrum
HT T P
Hypertext Transfer Protocol
ICM P
Internet Control Message Protocol
IET F
Internet Engineering Task Force
IM U
Inertial Measurement Unit
ISM
Industrial, Scientific and Medical band
LOS
Line-of-Sight
M AC
Media Access Control
M AN ET
Mobile Ad-Hoc Networks
M AV
Micro Aerial vehicles
7
N ASA
National Aeronautics and Space Administration
OLSR
Optimized Link State Routing
OSI
Open System Interconnection
P 2P
peer-to-peer
PC
Personal Computer
P ID
Proportional-Integral-Derivative
PWM
Pulse Width Modulation
QoS
Quality of Service
RF
Radio Frequency
RT C
Real-time clock
SAN ET
Static Ad-Hoc Networks
SenSaf ety Sensor Networks for Public Safety SN R
Signal-to-noise ratio
SQL
Structured Query Language
TTL
Time-to-live
U ART
Universal Asynchronous Receiver and Transmitter
U AV
Unmanned Aerial Vehicle
WP
Waypoint
TTL
Time-to -live
8
List of Figures 1
Thales Group logo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 3.2
Aerial Vehicle Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Effect of torque on a helicopter. The tail rotor compensates for the main rotor’s torque. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Various multicopter designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Open-source quadcopter hardware (a) Paparazzi, (b) Openpilot, (c) ArduPilot, (d) Pixhawk, (e) Mikrokopter, (f) KKmulticopter, (g) MultiWii, (h) Spiri Images may not be to scale, source [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A screenshot various processor boards that can be used for networking, (a)BeagleBoardxM, (b)BeagleBone Black, (c)Raspberry Pi, (d)PandaBoard, (e)Android phone, (f )TP-Link Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 3.4
3.5
4.1 4.2 4.3 4.4 4.5
5.1 5.2
5.3 5.4 5.5 5.6 6.1
6.2 6.3 6.4 6.5
The Internet Protocol Suite (TCP/IP) five-layered model. . . . . . . . . . . . . Infrastructure (Centralized) Vs. Ad-Hoc modes (Decentralized). Source: [2]. . . A possible path for a route request/reply from source (A) to Destination (D) in AODV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MPR node sends Topology control (TC) messages, Source: [3]. . . . . . . . . . Zone routing protocol. The intra-zone uses proactive while the inter-zone uses reactive protocol. Source: [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 34 . 36 . 39 . 41 . 41
Store-and-forwarding message switching technique. . . . . . . . . . . . . . . . . . Comparison of the Internet protocol stack(left) with the DTN protocol stack(right). DTN bundles can only be transmitted to/via nodes that follow the DTN protocol, Source [5]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nodes with bundle protocol supports communication with other DTN nodes with heterogeneous underlying protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . IBR-DTN architecture overview, taken from [6]. . . . . . . . . . . . . . . . . . . . Mechanism of bundle transmission and reception between two nodes. . . . . . . . Solution of event based trigger and handling on bundle reception. . . . . . . . . . Figure shows the standard 13 channels, as per 802.11 standard. Each channel has a bandwidth of 22 MHz; taken from Wikimedia commons(2.4 GHz Wi-Fi channels). The 14th channel is only available in Japan. . . . . . . . . . . . . . . A study of wireless devices sensed in the laboratory, using aircrack-ng, an opensource network tool. The BSSID (MAC addressed) of the systems have been hashed. Settings used for the ad-hoc network setup. . . . . . . . . . . . . . . . . . . . . . . The encircled number indicates the sub-network address. The ’X’ refers to the range of 1-255 devices or node identifiers. . . . . . . . . . . . . . . . . . . . . . . The wireless interface configuration (iwconfig) after set up. . . . . . . . . . . . .
9
3
44
45 46 48 51 54
57 57 58 58 59
6.6 6.7 6.8 6.9
6.10 6.11
6.12 6.13
7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9
7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17
8.1 8.2 8.3 8.4
The resulting interface configuration. Notice the hardware(MAC) address of the wireless device, along with broadcast address, transmitted and received packets. . . Indication of different (unnecessary) processes using the wireless interface. . . . . Modifying ifplugd daemon to prevent it from using the wireless interface. . . . . . Tests performed between two static Raspberry Pi nodes. Effect of HELLO interval tuning on neighbour discovery times, (a) establishes a reliable link with neighbour node in 29 seconds, (b) establishes a reliable link with neighbour node in 8 seconds. The network outlay consisting of six nodes, three of them are Raspberry Pi’s, two are TP-Link routers and one is a PC. . . . . . . . . . . . . . . . . . . . . . . . . Overview of currently available OLSR connections as seen by the TP-Link router. The current node’s static IP considered is 192.168.13.207. Note that there is a slight ambiguity in values with respect to Figure 6.10. The link costs are refreshed continuously. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The response received back from the local port immediately after the query. The figure shows three nodes discovered by the local node, each having a different cost. Illustration of communication between two nodes using OLSR and DTN, on the extended TCP/IP protocol stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . Schematic overview of the hardware . . . . . . . . . . . . . . . . . . . . . . . . . MPU6000 integrates accelerometer and gyroscope on a single chip, Source . . . . Figure shows a the 3-axis HMC5883L magnetometer . . . . . . . . . . . . . . . Figure shows the XL-Max Sonar sensor, MB 1200, used with the quadcopter . . . Figure showing multiple satellites that revolve around the earth’s orbit at all times ArduPilot, hardware v2.6, Taken from [7] . . . . . . . . . . . . . . . . . . . . . . . Inside the brushless outrunner motor, AC2830-358 850Kv . . . . . . . . . . . . . Figure shows a 20 Amp, Electronic speed control or ESC that provides varying high frequency AC voltage to the brushless motor . . . . . . . . . . . . . . . . . . A LIPO battery that delivers 1000mAh current at 30C, 11.1V. This figure is only used only for illustration purposes. A Zippy 5000mAh, 20C at 11V is used for the quadcopter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Non-linear effect of increase in weight against flight time, taken from [8]. . . . . Power module provides a clean power supply to on-board electronics and for voltage, current measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power distribution board to distribute power to the four ESCs, flight controller and Networking hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Two radio modules with antennas. . . . . . . . . . . . . . . . . . . . . . . . . . . The hand held transmitter sends control signals to the receiver on flight. . . . . . Figure shows the TP-Link wireless dongle based on 802.11g/n standards. . . . . . Figure shows the quadcopter constructed with aluminium frame. . . . . . . . . . . Figure shows the Raspberry Pi processor interfaced TP-Link WN722N wireless adaptor and a 5 Mega Pixel HD camera. . . . . . . . . . . . . . . . . . . . . . . . Quadcopter model, quantities and angles . . . . . . . . . . . . . . . . . . . . . . i, j, k are unity vectors co-directional with the body frame x, y, and z axes. Oxyz represents the body and OXYZ represent the global frame. . . . . . . . . . . . . Pitch, roll and yaw rotations are produced by varying the speed of the rotors in the two configurations. Yaw rotation is indicated only for ’+’ configuration. . . An overview of the software architecture with hover and navigation control. The hover controller is used as a backbone for waypoint navigation. . . . . . . . . .
10
59 60 60
62 63
63 65 68 69 70 71 71 72 73 74 75
76 77 78 78 79 80 80 81 81
. 84 . 86 . 87 . 89
8.5 8.6 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9
The RC controller displays the different controls available in terms of switches and knobs. The mode is changed via the 3-position switch. . . . . . . . . . . . . . 90 Illustration of steps taken for controller tuning. . . . . . . . . . . . . . . . . . . . 91 Application of double layered anti-vibration foam pads. Each pad measures 1.5 cm in thickness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The 3-axis accelerometer data recorded during hover. . . . . . . . . . . . . . . . Result of controller tuning for roll axis. The controller output tries to converge to its input. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use of Aluminium foil minimize the magnetic interference on compass. . . . . . An near-linear deviation of compass with increasing throttle. . . . . . . . . . . . Test to verify the stability of the platform in autonomous hovering mode. . . . . Hovering test in a windspeed of 18 kmph. The graph shows the attitude and thrust variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Raspberry Pi running OLSR actively, with an external power source. . . . . . . Test conducted to determine the power required for hovering. . . . . . . . . . . .
10.1 Extended TCP/IP network stack. . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Illustrates the role a (static or mobile) node during network transactions, at a waypoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Illustrates how the tasks are interpreted from the XML file. Each task, node is an object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Illustrates the network flight interaction. The aerial-network protocol runs on the networking hardware, the Raspberry Pi. . . . . . . . . . . . . . . . . . . . . . . 11.1 A mobile node (quadcopter) is used along with other static nodes in the MANET, during waypoint networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 A 4 dBi detachable wireless antenna with TP-Link WN722n wireless adapter. . 11.3 The figure shows, (a) the radiation pattern of a simple omnidirectional antenna, (b) and (c) shows the 4 dBi antenna gain pattern from a vertical and horizontal plane of view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Neighbour discovery tests performed with respect to antenna orientation. The tests are conducted between a static node placed on the ground and a mobile node hovering at a height of 5 meters. . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 An illustration of an indoor hovering, at Thales Nederland B.V. The mobile node exchanges data with the static node below. . . . . . . . . . . . . . . . . . . . . . 11.6 Mission waypoint planning. Three waypoints are plotted on this map. The take off point is marked as Home. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.7 The scenario tested during waypoint navigation. A total of three waypoints are planned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.8 Measured link quality (ETX) during the waypoint network navigation. . . . . . 12.1 The four wireless devices used on our multicopter. Top left: TP-Link WiFi (2.4 GHz); top right: 3DR telemetry (900 MHz); bottom left: FlySky RC receiver (2.4 GHz); bottom right: u-blox GPS receiver (1.575 GHz). . . . . . . . . . . . . . . 12.2 Using a spectrum analyser to study the DSSS, FHSS of the 2.4 GHz transmitter and the 2.4 GHz WiFi signal from Raspberry Pi’s wireless adapter. . . . . . . . 12.3 Data collected during actual flight. The graph shows sudden reduction of GPS satellite count at the time of camera trigger that resulted in a sudden bizarre flight behaviour. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4 Using a spectrum analyser to study the interference due to the camera. . . . . . 11
. 93 . 94 . . . .
95 96 96 97
. 98 . 98 . 99 . 101 . 102 . 105 . 107
. 109 . 110
. 111
. 111 . 112 . 113 . 115 . 116
. 117 . 122
. 123 . 124
12.5 Measures taken to minimize the interference created from the camera ribbon cable.125 13.1 13.2 13.3 13.4 13.5
Illustrates the induced air velocity below the propeller plane. . . . . . . . . . . . Illustrates the chosen 360 kV motors and propellers (not to scale). . . . . . . . After the integration of all components on the carbon fibre frame. . . . . . . . . Illustrates the different tested motor mount orientations. . . . . . . . . . . . . . An unconventional design that reduces the power consumed for hover, due to reduction in air drag on the quadcopter frame. . . . . . . . . . . . . . . . . . . . 13.6 Illustrates the Li-ion cells, when connected in 5S-4P configuration, supplies enormous power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.7 Putting together the Li-ion pack to be used on the quadcopter. . . . . . . . . . . 13.8 An outdoor test flight. The flight is autonomous and locked in GPS mode. Note that the motors are mounted in an inverted fashion. . . . . . . . . . . . . . . .
. . . .
128 132 133 134
. 134 . 135 . 135 . 136
A.1 Attitude tracking response of a quadcopter. Ardupilot based controller is found to be more accurate than other OSP controllers, based on ground-truth. The delay between reference and measured signal is due to the communication delay, Reference: The desired angle, Roll, Theta: Measured attitude of the quadcopter by Vicon, Source:[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 A.2 A screenshot of Ground station control available for different OSPs, (a) Paparazzi, (b) Openpilot, (c) Ardupilot, (d) Pixhawk, (e) Mikrokopter . . . . . . . . 145 B.1 The OSI standard is followed for network communication across all vendors. . . . 147 B.2 An experiment conducted when an obstacle is brought in between two nodes, sporadically. It can be seen the data rate is affected due to packet loss. . . . . . . . . 148 C.1 Real-time clock interfacing with the Raspberry Pi. . . . . . . . . . . . . . . . . . . 153
12
Chapter 1
Introduction Until the last decade, the term Unmanned Aerial Vehicle (UAV) was associated with large-sized drones used for autonomous missions by the military. Starting recently, the terminology of Micro Aerial Vehicles (MAVs) have emerged, made possible by the improvement in multiprocessor, sensors and actuator technologies. MAVs are usually categorized as small sized aerial vehicles weighing anywhere from a few grams to a few kilograms. Aerial robotics is a fast growing field with tremendous civil and military applications. It has lately seen increased popularity of multirotor aircraft such as the quadcopter. Extensive research is ongoing in the field of MAV platforms, for tracking robotics tasks in complex, three dimensional, indoor and outdoor environments. Most of the research in the field of MAV is concerned with improving surveillance features and to improve autonomous navigation capabilities of the vehicle themselves. However, as far as we are aware, little practical insight exists on the use of UAV or MAV for improving the communication network. The research in this thesis is exactly concerned with that, i.e. improving the capability of a wireless ad-hoc communications network by using a MAV. In the field of wireless networking, Mobile Ad-Hoc Networks (MANETs) have emerged that deal with routing of information between systems in motion. Military vehicles, as an example, are nodes where all have equal access (i.e. each node acts as an access point) and rely on MANETs for peer-to-peer communications. MANETs impose several challenges such as efficient routing of data, shortest data path to destination and battery efficient algorithms. Alongside, Disruption Tolerant Networking (DTN) is an up-and-coming technology that enables networking in extreme environments that may lack continuous network connectivity. Mission to Mars, planned networks in space, getting the internet to sub-Saharan villages, have all something in common. These are all examples of networking in extreme (terrestrial) environments that overwhelm traditional technology and demands new communication solutions. The DTN technology has been adopted by National Aeronautics and Space Administration (NASA) and European Space Agency (ESA) for interplanetary space communications, in the year 2012. This technology, proposes a store-and-forward approach to handle disruptions in communications; and delivers required data to the destination at the earliest time, whenever possible. This research is conducted at Thales in the context of Sensafety1 . The research aims to bring closer the diverse technologies of mobile mesh networks and DTN to closely interact with the aerial platform. The concept in this project opens up an additional direction for future research. 1
SenSafety, is a COMMIT project, that centers on safety and security in public spaces.
13
Contribution of this thesis In the context of both wireless networking and MAVs, most of the prior work has been conducted with simulation as a tool of choice. Implementations in each of these categories exist but the study of wireless networking in combination with MAVs, is a new field of research. MANETs has remained a popular research topic since the mid 1990s. Many academic papers evaluate protocols and study their abilities with varying degrees of mobility within a bounded space, usually with nodes reachable within a few hops of each other. MANET is a potential candidate for applications where networked mobility is important. With DTN, research and development is ongoing and its impact on applications in terrestrial environments is slowly being realized. Autonomous navigation with MAVs is not yet completely mature, due to the regulations imposed by FAA that dictates aerial vehicles to be in the Line-of-Sight (LoS) of the user. At the time of this writing, there is no practical insight available using all the three concepts integrated together i.e. MANET, DTN and autonomous multirotors, and analysis of its behaviour. In this thesis, we pursue research, propose new concepts and importantly, implement the new concepts in a working multirotor system. The integration and implementation of these three concepts in a single autonomous flying system is in itself a significant step forward with regard to the state of the art. Alongside, one of the major factors that limits the use of small-sized unmanned aerial vehicles, is the short flight times. It is shown in this research that this limitation can be overcome to a good extent. The following are the core contributions of this research: 1. Tests with MANET, DTN : Analysis and integration of MANET routing protocol and the DTN technology on resource constrained embedded systems and testing its use case with several nodes in the network. 2. Applicability of DTN : In this report, several improvements to the DTN architecture are proposed and implemented that make DTN better for use with applications. For example, four key aspects of DTN are addressed that currently limit its use on an application level. These are determining the source of the data sent, event based trigger on data reception, finding the received data’s file format and clock synchronization between sending and receiving nodes. This is interesting in the context of military applications with DTN. 3. Aerial-network protocol : Development of Aerial-network protocol that enables interaction between the navigation software and the other protocols on the networking stack. For example, autonomous network search of other (static) nodes and decisions on bi-directional exchange of data are established on the fly with this protocol. This is done on hovering in a region, to disseminate to or request data from other nodes while using a store and forward technique such as DTN. The network parameter such as link quality is determined to alter the behaviour of the hovering platform during a data exchange. 4. Hovering capability: Improve the hovering precision of the multirotor platform by researching and experimenting several methods such as vibration control, reduction of on-board magnetic field interference that directly affect the flight characteristics. The result is the multirotor hovering with sub-meter accuracy. 5. Study of on-board Interference: Analysis and resolution of unexpected on-board interferences on the mobile platform due to the use of multiple wireless devices, for communication.
14
6. Extended flight times: Flight times have been a major limitation of MAVs. Complementary to this research, a multi-rotor is hand designed with custom components. It is shown that this design significantly extends the flight times over contemporary multirotors. Further, an unconventional method is introduced by inverting the motor orientation on the multirotor leading to increase in flight time. The motivation for this development stems from understanding the power requirements for a given design.
Disciplines Involved 1. Wireless networking In the field of wireless networking, the research involves understanding the existing protocols for inter-node communication in Wide Area Networks (WAN). The concept of DTN is used in the context of wireless networks and improvements are proposed. The DTN technology being relatively new, requires study and experimentation before putting to use. The various networking tools such as arp and wireshark, serve as a useful aid while studying network behaviour and to troubleshoot problems. The aerial networking platform hosts four different wireless frequencies in the MHz to GHz range. The implications of wireless interferences in a practical setup is analysed and several insights are obtained. 2. Embedded systems The software for both navigation and networking are implemented on embedded hardware. The challenge lies in understanding the hardware components and implementing software that results in an expected behaviour. Navigation imposes certain real-time constraints that have to be met for a smooth flight operation. For embedded networking requirements, the protocols used or developed are based on C++, python and bash scripting languages. The ground control software is written in C# language for interaction with the flight controller via Universal Asynchronous Receiver and Transmitter (UART) interface. Suitable data logging has been performed at various stages to study the flight and networking characteristics and to troubleshoot problems. 3. Control The stable control of flight requires understanding the behaviour of closed loop systems. The software for any navigation system employs (several) closed loop mechanisms to maintain the stability of the platform. One of the important aspects of stability is governed by the Proportional-Integral-Derivative (PID) controller. A PID controller computes the error difference between the input from the sensor board and the desired target. The controller attempts to minimize this error by adjusting the output of the actuators, indirectly affecting the input. Tuning multiple PID controllers for the improved controller response, is part of this work. 4. Mechanical systems Amongst the most popular multirotor designs being researched, the quadrotor or quadcopter is the most popular. The structure of the frame design in general, must adhere to a specific weight distribution, uniformity and rigidity. During the phase of this research, three quadcopters are used at Thales. One mechanically constructed quadcopter is purchased for faster set up and for demonstration purposes. The other two are built from scratch, for raw experimentation and to serve as a backup. The weight of the aerial vehicle plays an important role with respect to its flight times. Thrust tests are performed for the analysis of predictable hover times.
15
Chapter Overview Related work are described in Chapter 2. The selection of hardware for flight navigation and networking for the mobile platform is introduced in Chapter 3. The basics of wireless networking concepts is presented in Chapter 4. Some of the most popular Mobile Ad-Hoc Network (MANET) routing protocols proposed by the Internet Engineering Task Force (IETF) are also presented in this chapter. In Chapter 5, Disruption Tolerant Networking (DTN) is discussed in detail. The improvements made towards the applicability of DTN for applications, is also presented. Chapter 6 discusses the setup of OLSR (Optimized Link State Routing) and DTN bundle protocol, analysis and its operation on embedded systems. Chapter 7 and 8, introduces the basic building blocks of multirotor hardware and discusses all components in detail. Further, an overview of the software architecture for the multicopter is presented. In Chapter 9, the analysis of the multicopter platform is discussed along with, methods that are used to improve the flight characteristics and its behaviour in real-flight, derived from the logged data. In Chapter 10, the aerial-network protocol developed for autonomous data transfer is discussed. This protocol is an extension of the TCP/IP network stack and takes advantage of the MANET routing and DTN protocol beneath it. Chapter 11 discusses the waypoint navigation and interaction of networking with autonomous flight. The analysis of the on-board interference due to different wireless devices are discussed in Chapter 12. This shows the interference can lead to bizarre aircraft behaviour. Analysis is presented and measures are described to minimize these effects. In Chapter 13, the design of the hand-built multicopter is discussed in detail. This proposes considerable improvement over contemporary multirotor flight times using custom components and different energy source. Comparison of flight times is shown between two different multicopters with the same payload. Finally, conclusion is presented in Chapter 14.
16
Chapter 2
Related Work The work in this thesis spans three important areas namely, Mobile Ad-Hoc Networks (MANETs), Disruption Tolerant Networks (DTN) and autonomous aerial robotics. Only a brief mention of the significant work in the area of this thesis is mentioned in this chapter.
Focus of this thesis The main focus of literature survey is in the following area: • Ad-hoc network capability of the autonomous robot such that it can act as a mobile node to bridge the gap between two sub-networks. • Integration of Disruption or Delay Tolerant Network (DTN) as a store and forward network strategy, for reliability of data transfer between regions of no-connectivity. • Deployment of an autonomous robot capable of flying waypoints
Relevant literature and contributions 1. An Autonomous Flying Robot for Network Robotics: In prior work to the paper, found in [9], large amount of theoretical work exists using simulation as a tool of choice. These often make simplified assumptions about the environment however, fail to capture complex dynamics of wireless environments. This area is only recently gaining popularity with ground wheeled robots in a mesh network. Integrating robots in real world in large scale wireless networks, specifically outdoors has seldom been the vision. This paper proposes and conducts experiment with a mobile platform in real wireless networks. In this paper, the author studies the effect of the parameters of the wireless networks such as signal-to-noise plus interference (SNIR), packet delivery rate (PDR) and packet error rate (PER) for the noisy environment. These parameters are affected due to external interferences that include cell phone devices and non-communication devices such as microwave ovens. The experiments are conducted in the HU-Berlin Adlershof campus with multiple indoor and outdoor nodes. The indoor Wi-Fi nodes are placed in several buildings, forming a fully connected wireless network.
17
Contributions Two experiments are conducted in this paper. In the first experiment, a mobile laptop is carried on foot around the campus for wireless network measurements and to study the noisy outdoor environment. The results indicate that the presence of two-ray interferences and reflections influence the wireless channels. In another experiment, an autonomous robot is used as the mobile platform. In autonomous mode, the processor executes the algorithm under investigation. The idea is to cope with the uncertain and noisy dynamic environment by adjusting the position of the robot to improve network performance based on the network parameters. The use of the robot is only done indoors for network measurements. The author has suggested the use of warping, a technique to guide the robot to achieve intelligent flight, however this is reserved as future work. 2. On Controlled Node Mobility in Delay-Tolerant Networks of a UAV : Mobile ad-hoc networks(MANETs) are playing an increased role of making ubiquitous computing and communication into a reality. In [10], two model based approaches to ferry data between regions of no connectivity is discussed. The route model designs discussed are namely, the chain-relay model and conveyor-belt model. Evaluation of the proposed route designs take into account the node velocity, node range, data rate and buffer size of the nodes. Further, a new route design has been suggested which takes into account multiple data rates with separation distance from a node. Initial evaluation suggests performance improvements over existing approaches on using this new route design. The models are based on simulation. Contributions This paper presents two models of communication and a new route design based on data rates. Chain-Relay Model : In this model, it is assumed that all participating nodes (i.e. ferries) are distributed along the connecting path between source and destination nodes, representing a chain. The source node passes the data to the first (nearest) ferry, which then transports it physically by movement to the next ferry along the path and returns to its original position. This hand-off process is repeated, until the last ferry or the destination node receives the data sent. Conveyor-Belt Model : In this model, it is assumed that each ferry travels the complete distance from the source to the destination before returning to its original position. It is noted that multiple ferries that share the same path increases the throughput and robustness of the system. A mathematical evaluation of these two models are studied based on node buffer size, the separation distance between successive nodes, radius of the coverage area of a node and the data rate in the coverage area. Variable Data Rate Communication Model This model makes use of variable data rates provided by IEEE 802.11 wireless interfaces. When the ferry is close to a node or another ferry, the communication rate is high and lowers with distance from the node; The rate decision is based on the Signal to noise power (SNR) and the packet success rate over the channel.
18
The ferry loads data from the source node and travels towards the destination. The ferry travels only as much distance as is necessary to transmit half the required data and then returns back the same path towards the source completing the remaining half of data transfer. This method has the advantage that it saves the total travel time and makes the process of data transmission or reception more efficient, in theory. This way the vehicle only moves as close to a node as necessary to complete the data transfer. 3. Robust Exploration Strategies for a Robot exploring a Wireless Network In [11], the importance of the integration of robots into wireless networks for a number of scenarios is presented. It introduces the concept of network exploration by finding the physical outline of the network with a mobile robot. For this algorithm, the robustness against noise is studied for several sensory inputs. Contributions The author proposes an algorithm for determining the physical layout of the wireless mesh network using a mobile robot. With no prior knowledge about the network, the integration of a robot into a wireless network is performed to gain knowledge about the physical and topological characteristics of this network. In other words, the robot explores the network. The first tasks to be solved for this include finding the nodes and outlining the network. Two basic assumptions are made. The mobile robot knows which general direction the network is located in and if a node is reachable via hop from another node. This paper suggests that relying on the Received Signal Strength Indication (RSSI) to determine a node’s location is a tedious task. The difficulties arise due to the non-linear relationship between RSSI and node distance. The algorithm consists of measuring only the relative direction of the nodes and to use the RSSI measurements in a minimum way. A directional antenna is used to determine the direction towards a node. The robustness of the algorithm is determined in terms of sensory noise for both direction estimation and RSSI measurements. A number of simulation runs and parameter study in the amount of noise for both parameters is conducted. This work proposes the algorithm. The author has reserved the robot to integrate itself into a wireless network as a future work. 4. Information delivery scheme of micro UAVs having limited communication range during tracking the moving target: In [12], the concept of a group of UAVs interacting together is mentioned. A micro UAV is used to find the moving target and number of other UAVs are constantly moved to provide information to the base station, while the target is moving. After locating the target within the search area, the UAVs move toward the base station to transmit this information using multihop ad-hoc connectivity. The UAVs have a limited range and information transmission is only possible through ad-hoc communication among these UAVs. Contributions In this paper, the concept of DTN technology is used. When communication among the UAVs is not possible when the target moves too far away from the base station, the UAVs retain the information of the target. Whenever a UAV node meets the other 19
UAV node, the information is transmitted via a store-and-forward approach, using DTN. The performance of the proposed methodology is evaluated using the NS-2 (Network Simulator). The prior work found in the area of this thesis, touch upon the concepts of aerial robotics, mobile ad-hoc routing and DTN technology. Many of them use simulation as a tool for evaluation. The prior work gives an idea on what contributions are already made in these areas and where it can be improved upon. This thesis draws motivation from [9], to integrate a mobile robot in wireless mesh networks. The concepts of MANETs and DTN are studied, to be implemented on the mobile node. Motivation from [10] is drawn to have a model similar to the data rate model discussed. We make use of the network parameter such as the link quality to adjust the behaviour of the hovering platform during data transactions.
20
Chapter 3
Mobile Platform Selection This chapter introduces the various platforms that can be used for aerial networking. In the first section 3.1 the reader is presented with different categories of aerial platforms in use today, followed by their benefits and drawbacks. The next section 3.2, discusses different multicopter designs and the various software and hardware projects available for use. The final section 3.3, lists the hardware choices available for use with networking.
3.1
Classification of aerial vehicles
The introduction of the term unmanned or drone has emerged only since the past decade with the idea of giving a flight more autonomy than with a manned flights. Figure 3.1 shows the different types of aerial vehicles in use today.
(a) Unmanned balloon
(c) Helicopter, with a main rotor and tail rotor
(b) RC airplane (fixed wing)
(d) Quadrotor or Quadcopter, with four rotors
Figure 3.1: Aerial Vehicle Categories
21
Figure 3.1a shows an individual holding a balloon with an orange parachute and a dropper reel that lowers the payload containing various sensors for atmospheric measurements. This balloon is two meters in diameter, is filled with helium gas and travels to about 35 km for atmospheric measurements. Figure 3.1b and 3.1c depicts airplane and helicopter, respectively, that have been in use since 1920s. Gliders and jet engines also participate in this category as were used during the world war. Under the same category, are Radio Controlled (RC) helicopters and airplanes in existence since 1980; being smaller in size are able to be remotely controlled by a hand held transmitter. The growth of the word autonomous (associated with the word drone) has been in use by military for a few decades now, the potential possibilities only being realized recently with small sized unmanned drones for the civilian market. Figure 3.1d shows a multicopter with four rotor blades. This category of aerial vehicles has seen a continuous rise in popularity due to its small size, flexibility, Vertical Take Off and Landing (VTOL) capability and ease of maintenance compared to its counterparts. The multicopter branches out into various sub categories, such as hexacopter (6 rotors), octocopter(8 rotors), decacopter(10 rotors), dodecacopter (12 rotors) and custom hybrid copters of different shapes and sizes. Nowadays, prototypes of hybrid copters can be seen emerging, an example prototype developed by TU-Delft, Netherlands (Quadshot), makes use of a quadcopter built over an RC airplane structure. It claims to achieve long distance flight at the speed of an RC airplane and hovering capability of a quadcopter, though has been found tedious to control due to its mixed nature of operation.
Aerial platform comparison Balloon The air balloon structure equipped with electronics is one of the possible candidates for Micro Aerial Vehicle (MAV). The balloons are usually used for inspection or data gathering at high altitudes (using hydrogen as the payload carrying medium). A recent development demonstrated the Raspberry Pi hardware coupled with various sensors for high altitude monitoring. It reached a peak height of of 39,994 meters with a payload of 200g, baloon volume of 3m2 with hydrogen as the carrying medium[13]. The flight time recorded was 24 hours. • Advantage: 1. Longer flight times due to hydrogen as a carrying medium. • Disadvantage: 1. A need for accurate setup, launch and monitoring on a regular basis from various GCS (Ground Control Station). 2. The user may have no control of adjusting its position in the air as it drifts away with wind.
RC airplane (Fixed wing) RC airplane have been in use for over three decades now. They are categorized as gas based that runs on fuel or electric based that runs on batteries. Both types are controlled via a user
22
controlled RC transmitter that communicates with an RC receiver on board the flight. The characteristic of an RC airplane matches closely with that of a commercial airplane. • Advantage: 1. Fast and continuous movement enables to reach long distances over a short time. 2. Models have been developed where an RC airplane propels itself on launch from hands of the user. 3. Fixed-wing airplanes are useful for high-altitude or long-range applications such as search and rescue, surveying and mapping large areas and crop inspection (when made autonomous). Moreover, they are ideal for aerial mapping and terrain modelling large areas, undertaking topographic surveys and mine sites. • Disadvantage: 1. RC airplanes have continuous movement thus, cannot be used to hover in air. 2. They require costly maintenance with gas based engines. 3. Occupies space due to large wing span of the RC airplane.
RC helicopter (rotary) In recent years, a new type of Micro Air Vehicle (MAV) has emerged as the small-scale equivalent of the full-sized helicopter. Radio-controlled helicopters are model aircraft that are distinct from RC airplanes due to the differences in construction, aerodynamics, and flight operation.
Figure 3.2: Effect of torque on a helicopter. The tail rotor compensates for the main rotor’s torque. The helicopter is a rotary or propeller-based system. Several basic designs of RC helicopters exist, of which some are more maneuverable than others based on its construction. Unlike the fixed wing models, these small sized copters are able to fly in every direction, horizontally and vertically, as well as able to hover in a fixed position. The cyclic controls (pitch and roll) and the tail rotor (yaw) are used to control the movement of the helicopter. The torque balancing is performed by the tail rotor pushing the air in the opposite direction of the main rotor’s torque as shown in Figure 3.2. Without the tail rotor, due to torque imbalance, the helicopter would spin almost as fast as the propeller and lose control. • Advantage: 1. Vertical Take Off and Landing (VTOL) and the ability to hover for an elongated period of time. 23
2. Applications such as detailed inspection or surveying hard-to-reach areas such as pipelines, power lines, bridges and rail tracks are possible. • Disadvantage: 1. The helicopter design comes with the presence of a large main rotor blade which can be unsafe in control for indoor flight tests. 2. Helicopter may require careful maintenance due to presence of delicate components such as swash plates which help to point the helicopter’s main rotor to a specific direction during pitch. 3. The main rotor blade creates significant noise during its operation.
Multicopter In contrast to the helicopter design that incorporates of two rotors, a multicopter or multirotor is a rotor craft having more than two rotors. Multicopters are able to hover and fly at low altitudes and low speeds, making them suitable for applications such as aerial photography, aerial video, power line inspections and land mapping operations. The multicopter closely resembles the helicopter in terms of capabilities and operation, however it adds to several other advantages in terms of ease of control and maneuverability.
(a) Tricopter (3 rotors)
(b) Quadcopter (4 rotors)
(c) Hexacopter (6 rotors)
(d) Octocopter (8 rotors)
Figure 3.3: Various multicopter designs • Advantage: 1. With a traditional helicopter design, a large primary rotor is used to generate lift, and changes in thrust are generally achieved by varying the pitch of the rotor blades. The changing of the speed of one large rotor requires too much time. Further, the 24
mechanical parts needed to adjust the pitch of the fast-spinning blade are complex and difficult to maintain. In case of Quadcopters, they are able to achieve thrust changes by varying the speed of each one of the smaller and lighter rotors thus, able to avoid using complicated variable pitch components[14]. 2. A traditional helicopter must require a tail rotor to counteract the torque created by the primary rotor. Quadcopters, on the other hand, do not require a tail rotor, since the counter-rotating rotors cancel out each other’s torques[14]. These primary differences lead quadcopters towards a simpler design that is cheaper to build and easier to maintain. • Disadvantage: 1. Quadcopters are difficult to control since its mass is concentrated in a small area, the rotors must react very quickly to counteract the tendency to tip over. Although simpler in mechanical construction, a quadcopter requires complicated electronics and software. The hardware controller feeds the corrective forces for balancing each of the motors at least 50 times per second. 2. For a given thrust, it is more efficient to have a single large rotor blade and multiple small blades. Quadcopters are relatively less efficient than a helicopter of the same size. The table 3.1 identifies the key characteristic of each of the various multicopter designs. This analyses would further help us to choose the appropriate design based on the requirement in this project. Please note that the octocopter has been omitted from the discussion for brevity reasons. The interested reader can extrapolate the understanding derived from the given table to understand its characteristics. This research is directed towards one of the requirements of Sensafety (also, mentioned in the Introduction). The research challenge is to monitor specific regions during a public event and forward data gathered using wireless networking. A prior work conducted at Thales by Heimans, et.al, in the context of Sensafety, is available in [15]. A quadcopter is chosen as the platform for research for the following reasons: 1. VTOL and ability to hover about a specific region in space. 2. The cost of a quadcopter design is economical as compared to a hexacopter. With more rotors, quadcopter makes a better choice than a tricopter design (refer to table 3.1). 3. Many Open Source Project (OSP) choices for hardware and software are available for a quadcopter design, see Appendix A. 4. The payload used in this project would amount to about 100 grams, that includes the networking hardware and a small high definition (HD) camera. A quadcopter platform can handle any given payload based on the motors and propeller combination used. The quadcopter platform with standard components weighs about 1.3 kgs without payload. For the given payload, the flight time will not be significantly affected.
25
Features
Simplicity
Tricopter Tricopters have to tilt the rear motor using a servo for movement and are relatively tedious to control.
Cost
Least expensive (3 motors, 3 ESCa )
Flight time
With a (large) propeller diameter and less weight, a slight increase in flight time can be expected
Payload capacity
Lesser payload capacity
Application
Applications where agility is more important
Stability
Stable but slow reaction to heavy winds due to lesser rotors
Failure
A Tricopter has higher chances of failure due to rotor malfunction
Feasibility for the project
Less design choices are available for frame construction
Quadcopter
Hexacopter
Quads are simpler and more reliable as the only moving parts are the propellers
Similar to a quad construction but due to increased rotors is slightly tedious
More expensive than a tricopter (4 motors, 4 ESCs) Comparable to a tricopter. With an additional rotor, thrust compensates for slight increase in total weight Greater payload due to slight additional thrust Better for aerial photography in monitoring specific regions
More expensive than a quadcopter (6 motors, 6 ESCs) Two additional rotors provide increased thrust that compensates for slight increase in total weight Can carry greater payload than a quadcopter
Better stability than a tricopter due to more rotors
With six rotors, improved stability can be expected
Survive malfunction of a failed rotor by giving up yaw control torque and using remaining props to tilt the axis of rotation (via software control) Most popular multicopter design and multiple frame types are available
Suitable to heavier cameras for photography
Hexacopter will perform fairly well with one less rotor available Useful to address applications having higher payload requirements
Table 3.1: Comparison between different types of Multicopters a
ESC: Electronic Speed Controllers are used to convert DC voltage from energy source along with Pulse Width Modulated(PWM) output signal from controller board to varying AC voltage to the brushless motors.
26
3.2
Multicopter platforms
This section presents an overview of the publicly available OSPs for a quadcopter. The OSPs help talented individual developers to contribute their knowledge on a common platform that results in faster development of hardware and software features, tested by many different community members. In addition, these projects allow researchers to extend the existing work done by others and provide a baseline comparison of various approaches. The term autopilot is often used, which is a hardware-software solution that offers algorithms to assist in navigation of the aircraft. The OSPs provide such autopilots and remain highly competitive with other commercial alternatives. They have proved to be successful for many research based applications [1]. The description of state-of-the-art OSPs available are presented as below:
Figure 3.4: Open-source quadcopter hardware (a) Paparazzi, (b) Openpilot, (c) ArduPilot, (d) Pixhawk, (e) Mikrokopter, (f) KKmulticopter, (g) MultiWii, (h) Spiri Images may not be to scale, source [1] 1. Paparazzi Paparazzi is one of the oldest used OSPs and in existence since 2003. It is an open source autopilot system oriented toward inexpensive aircraft. It started originally as a fixed-wing autopilot that now has extended its configuration for use with quadcopters. 27
The Paparazzi unmanned systems project is now being used and developed at the ENAC University and the MAVlab of the TU-Delft[16]. It provides Graphical User Interface (GUI) based Ground Control Station (GCS) and provides flight-path scripting that makes outdoor missions convenient. More information can be found in [16]. 2. Openpilot This project features a real-time operation system modified from FreeRTOS, which is an open source operating system. Openpilot supports fixed-wing and helicopter with some changes in software configuration. This platform is used by researchers and hobbyists working on aerial robotics or other mobile vehicular platforms where stabilization and guidance are required[17]. A GUI based GCS helps to tune the PID1 gains of the flight response. More information can be found in [17]. 3. ArduPilot ArduPilot is an autopilot project that is based on AVR architecture (extended to ARM architecture, in 2013). It supports both fixed-wing and multicopter platforms. The key highlights of this platform is the use of a well developed software interface GUI that is used as a research tool for data analysis, display flight information and tuning of controller gains. It supports configuration with several different GCS such as Mission Planner and Qgroundcontrol. More information can be found in [7]. It uses a combination of Lesser GPL and GPL v.3 license for its software unlike other OSPs that use only GPL license. 4. Pixhawk Pixhawk uses onboard computer-vision algorithms developed by ETH Zurich, Computer Vision Group [18]. Among the OSPs introduced in this section, only Pixhawk has computer vision and designed to support indoor navigation. It also provides GCS based Qgroundcontrol support that uses MAVLink protocol2 . This project has merged with the Ardupilot project in 2013 and the autopilot is now commonly called 3DR Pixhawk (3DR is the official manufacturer of open source hardware for Arducopter). 5. Mikrokopter Mikrokopter is a quadcopter autopilot system developed since 2006. A GUI based software for PID gain tuning and flight analysis is provided with this OSP. It may be interesting to note that in 2010, the University of Tasmania and the Australian Antarctic Division made use of Mikrokopter to monitor moss bed in Antarctica [1, pg.35]. 6. KKmulticopter This project has become KKmulticopter targets the hobby market interested in aerial photography using quadcopters. However, compared to other projects this provides the most basic configuration devoted to manual flight. It provides a tri-axial gyroscope for inertial measurement3 and a microcontroller for control. It provides no GCS and PID tuning is done using on board potentiometers. 7. MultiWii MultiWii is based on an Arduino board as the main processor. For inertial measurement, it uses accelerometers and gyros of the commercial off-the-shelf Wii motion controller from Nintendo[1, pg.36]. It provides a GCS for flight data analysis. 1
PID refers to Proportional-Integral-Derivative, the tuning gains that determine the responsiveness of the controller, and thus the flight 2 MAVLink: A protocol library for lightweight communication between Micro Air Vehicles (such as quadcopter) and ground control station(GCS) 3 Inertial measurement: An algorithm that runs on a dedicated hardware that measures and reports on a craft’s orientation, velocity and gravitational forces, using a combination of accelerometers and gyroscopes, sometimes also magnetometers.
28
8. Spiri Spiri is the latest addition to the OSPs, that started as a kickstarter project in mid 2013 and has seen rising popularity ever since. This platform is dedicated to quadcopters alone and aims as a developer-friendly small-scale quadcopter. It is a linux-based quadcopter that runs Ubuntu Linux with ROS (Robot Operating System); comes integrated with sensors, camera and Wifi. In addition, it allows to integrate cloud support and development tools. This platform has been prototyped and proven to work but not yet available. 9. Parrot AR.Drone Parrot AR.Drone is a radio controlled flying quadcopter built by the French company Parrot that has gained wide popularity since its inception in 2010. It is a light weight (≈400g) out of the box, ready to fly vehicle without requiring any specific configuration. The brain of the processor runs on a 1 GHz, 32 bit ARM Cortex A8 processor with 800MHz video DSP TMS320DMC64x. It consists of 3-axis gyroscope, accelerometers, magnetometers respectively, a down facing and front facing camera for image processing needs alongside a WiFi 802.11b/g standard hardware. Moreover, it comes with relatively soft props and a foam protective ring. It is a good choice for research, however the following points are taken into consideration before choosing our platform: (a) Limited functionality extension: AR.Drone is a proprietary platform that provides Open API model that exposes high level functions to send/receive certain commands using its standard protocol. It does however, allow developers to alter its firmware or make improvements in its software. (b) Upgrade to a newer firmware: Upgrading to the newer firmware usually means purchase of the newer processor that supports this firmware. AR.Drone 2.0 came with an newer firmware and support of limited GPS interface functionality. (c) Limited range of flight: The flight range and height is limited to the maximum range the Wi-Fi provides. (d) AR.Drone’s controller is a black box and its flight parameters come pre-tuned for use. Addition of payload will cause instability to the flight. (e) Operating outdoors: An important focus in this project is on outdoor navigation. AR.Drone is optimized for indoor use, provides good stability and reliability, however it is susceptible to winds due to its light weight and motor-propeller design. 10. Miscellaneous The platforms mentioned thus far are the most popular platforms in existence. There are however other flight controllers such as DJI Naza, Wookong and from Hobbyking. The former allows autonomous flight but comes packaged with a proprietary software that cannot be changed, while some others are either clones or not as popular as others. We limit our analysis to the platforms already described so as to keep our discussion succinct. Interested reader may explore the other platforms at his/her own discretion.
Quadcopter platform selection To build a multicopter, the hardware design and component choices are very important. From the above description, we select most likely candidates for our platform selection and specify their on board components. We omit further discussion of OSPs such as KKmulticopter, being used mainly for manual flight control due to limited sensors; Spiri as it is not yet released; MultiWii board has only partial support for altitude hold and functionality after GPS integration; AR.Drone is a partial open source hardware and software project with certain limitations 29
already discussed. The interested reader can go through Appendix A where details of hardware and software for the various OSPs are listed. Each of the important parameters in hardware such as types of sensors used, controller board and its features are discussed. In terms of software, the various attitude estimation algorithm that OSP provides have been closely studied and its description is given. In the end, the controller evaluation in terms of probable stability an OSP could offer along with its GCS support is illustrated. Given the various choice of OSPs and their detailed comparison(see appendix A), it was decided to use Ardupilot for research purposes. In summary, the ArduPilot offers: 1. Employment of onboard MPU-6000 Invensense chip having a small footprint that incorporates 3-axis acceleromter and 3-axis gyroscope onto a single chip. The flight controller itself weight ≈ 35g. 2. Multiple interfaces(such as I2C, SPI) and GPIO pins for interfacing external sensors such as sonar and magnetometer (i.e. compass). 3. Usage of Non-Linear Complementary Filter(NCF) uses a P-I closed loop controller feedback between the measured and desired attitude value, to minimize the error obtained. This results in a smooth attitude estimation. 4. Mature GCS that can be exploited for our own use and provides libraries for waypoint navigation. The GCS is programmed in C# and supports python scripting for extensions. The flight controller hosts the Atmega2560 microcontroller, and supports an extension of C++. More information can be found in appendix A. The ArduPilot OSP is used primarily for running the algorithms for stabilization and navigation. The stability of platform is of prime importance without which other tasks such as waypoint navigation, stable hovering and networking tasks cannot be performed reliably. The next section discusses the chosen of platform for networking.
3.3
Networking platforms
The primary requirement in this research is to develop a mobile networking platform. There is a need to isolate the microcontroller that is used as the flight controller from the networking process. This isolation helps keeping the two functionalities separate and detecting possible problems that may arise with the integration of the two. For instance, with both functionalities (navigation and networking) running simultaneously on a dedicated hardware may cause the aircraft to crash in case of a networking reset due to overload of packets or sudden surge of power.
Mobile networking requirements We start by listing our networking requirements before looking at the various alternatives for hardware selection: 1. Host a linux based Operating System (OS). Linux OS is the preferred option due to its ability to support a wide range of networking capabilities and security options. Examples of commonly used linux based OS are ubuntu, debian, fedora, openwrt, android, etc. 2. Sufficient support for wireless adapters that allow to run Ad-Hoc mode.
30
3. Availability of General Purpose Input and Output(GPIO) for interfacing. We could use GPIO pins to interface the networking hardware with the flight controller board, or other interfacing requirements. 4. Available forums for discussion of issues arising out of the use of hardware, wireless adapters4 and OS in general. 5. Easy integration of camera hardware for experimentation. 6. As a rough estimation, the hardware should be kept within a margin of 100-200 grams inclusive of the wireless adapter and camera. The weight of the hardware increases the total weight of the aerial platform and directly affects the total flight time.
Hardware options We discuss the various alternatives in choosing the right hardware. Figure 3.5 shows the various processors that are discussed below.
Figure 3.5: A screenshot various processor boards that can be used for networking, (a)BeagleBoard-xM, (b)BeagleBone Black, (c)Raspberry Pi, (d)PandaBoard, (e)Android phone, (f )TP-Link Router 1. BeagleBoard: The beagleBoard-xM hosts a 1 GHz Cortex-A8 CPU, 512 MB of RAM, and plenty of GPIO pins. It is low in power and supports many modern operating systems. This is the best candidate for selection as it sufficiently supports most of our project requirements. It has various options of connectivity such as on-board four-port hub with Ethernet,HDMI port and USB host. The drawbacks being the cost of board (120 e), additional cost of the High-Definition camera and a footprint of 3.25” x 3.25”, which is considered slightly large. 4
A Wi-Fi dongle is also called a wireless adapter.
31
2. BeagleBone Black: BeagleBone Black is a credit-card-sized Linux computer that has evolved out of the long lineage of BeagleBoard products into the current version; a small form-factor, powerful and expandable product. It is essentially a stripped down version of the BeagleBoard discussed above. It has a stable OS support for Angstrom linux, Android and Ubuntu. As of June 2013, its costs dropped by half to around 40 e. It has the option to boot either directly from the on-board chip or from the SD card. An external USB camera can be interfaced. 3. Raspberry Pi: Raspberry Pi is a low-cost and relatively high performance miniature computer based on Debian operating system. It runs on 700 MHz ARM11 processor, with 512MB of RAM. It has an ethernet port, two USB ports, one HDMI and several GPIO pins. At the time of this writing, Raspberry Pi released its 5 Mega Pixel High-Definition camera module that costs less than 20 e. The Raspberry Pi runs Raspbian OS which is a modified version of Debian OS and has stable support for device drivers for different wireless adapters. 4. PandaBoard: The PandaBoard is a miniature powerhouse, [19]. It hosts a dual-core Cortex A9 CPU with 1GB of RAM. It comes with a LAN port, Wi-Fi, Bluetooth and with addition of expansion connectors. The cost of the hardware is valued at 140 e. The PandaBoard supports a 5 Mega Pixel auto focus camera module(e-CAM57 MI5640 MOD) that can be bought separately. 5. Android Phone: An Android phone has lately become the trend globally and offers various functionalities. The android OS is open source and has support for the wireless Ad-hoc mode. However, it is to be noted that not all versions of android have support for the routing protocols that we employ in our research and thus, compatibility may become a problem. Moreover, the cost of the phone overruns the cost of a processor hardware that can support extended functionalities. With limited options of interfacing being a slight drawback, a USB interface is the only option left to communicate with the the flight controller. 6. TP-Link Router: The TP-Link wireless router is a combined wired/wireless network connection device designed specifically for office and personal use. It costs less than 30 e and runs an open source OpenWRT operating system that is based on the linux kernel. OpenWRT is primarily meant for routers and networking functionalities. It consists of mutiple ethernet port with multiple antennae for increasing the wireless range. It is an ideal candidate for use in mobile networking as it has clean support for the necessary routing protocols to be tested at Thales in addition to support of languages such as C++, python and bash that are used to develop the algorithms. The drawback however is the lack of GPIO pins for communication and the bulk size of the router. At the time of this writing, TP-Link introduced a pocket sized wireless router (TP-Link TL-WR702N) that is based on IEEE 802.11b/g/n standards. It is similar to the standard TP-Link router however is smaller in size with one ethernet interface. An ethernet to usb interface can help with communication with the flight controller however, interfacing a supported camera may pose problems.
32
Networking platform selection Given the various choice of networking platforms, we attempt to narrow down on the BeagleBone and Raspberry Pi hardware, both based on ARM architecture, a low-cost solution and adheres well to our requirements. A further classification is made between the two to bring out relevant features imposed by our requirement. Multiple boards would need to be purchased to create nodes in the mesh network. It can be seen from the comparison depicted in Table 3.2, the characteristic of both processors are nearly the same. Features Base Price Processor RAM Storage Operating Systems xPower Draw
BeagleBone Black 45 e 1GHz TI Sitara AM3359 ARM Cortex A8 512 MB DDR3L, 400 MHz 2 GB on-board flash and MicroSD Angstrom (Default), Ubuntu, Android 210-460 mA @5V
Raspberry Pi 35 e 700 MHz ARM1176JZFS 512 MB SDRAM, 400 MHz external SD card Raspbian, Ubuntu, Android 150-350 mA @5V
Peripherals
1 USB host, 1 mini-USB client, 10/100 Mbps Ethernet
GPIO pins
65 pins
2 USB hosts, 1 micro USB Power, 10/100 Mbps Ethernet, RPi camera connector 21 Pins
Table 3.2: Comparison between BeagleBone Black and Raspberry Pi as networking hardware. With the requirement of a camera on our mobile platform, the Raspberry Pi supports a 5 MP High Definition(HD) camera that is capable of 1080x720 pixels of video at 30 fps. The camera weighs just over 3g and has a dimension of 25mm x 20mm x 9mm. The camera is supported in the latest version of Raspbian. The overall weight of our networking hardware including the wireless adapter, camera and Raspberry Pi processor board weighs just over 100g. In conclusion, we choose the Raspberry pi due to its better support for camera, light weight and adheres well to our stated networking requirements.
33
Chapter 4
Wireless Networking This chapter starts out with a discussion of the basic layers of an TCP/IP model that forms the backbone for rest of the chapters related to networking. The section 4.2, presents an introduction to wireless networks. The section 4.3 and 4.4 discusses the MANETs and the routing protocols in use today. The last section 4.5 presents an analysis for choice of the MANET routing protocol used in this research project.
4.1
Internet protocol stack (TCP/IP)
The Internet Protocol Suite, TCP/IP, is a model of protocols used for communication over the internet and other similar networks. It is a five-layered networking model that emerged from the standard Open System Interconnection (OSI) seven-layered model.
Figure 4.1: The Internet Protocol Suite (TCP/IP) five-layered model. The TCP/IP or OSI reference model is adhered by all networking equipment and gives them the liberty to implement their own choice of protocol based on the application. Figure 4.1 shows
34
the standard five-layers of the model. The term TCP/IP refers to the TCP layer that resides over the IP layer in the protocol stack. For more details on OSI and TCP/IP suite, please refer to the Appendix B. Below, the description of each layer is given in brief with respect to Figure4.1. • Application layer : The end system generates or consumes user data. • Transport layer : The responsibility of this layer is end-to-end reliability in communication. The TCP transport protocol breaks the user data into manageable chunks called segments at the source. The segments are reassembled into user data at the destination. Two protocols can be used at this level, namely TCP and UDP. The choice to use which protocol is made based on the application’s transmission reliability requirements. On the internet, TCP is used. • Network layer : The routing and delivery of data is the key responsibility of this layer and a crucial component of this architecture. The IP network layer protocol encapsulates the TCP segments into datagrams. Routers primarily work at this level, as their function is to route or forward packets. • Data Link layer : The link layer protocol encapsulates IP datagrams into frames. This layer addresses the link-to-link transmission and reception of user data along with error control. • Physical layer : The physical protocol transmits and receives a sequence of frames as continuous bit streams. The bit stream is transmitted or received via physical media such as coaxial cable, fiber optics, and RF. In this research, we mainly focus on Network and Transport layers. We extend the TCP/IP model by adding extra layer(s) on top of the transport layer, discussed in Chapter 5 and Chapter 10.
4.2
Wireless networks
The fundamental difference between wired and wireless network is the broadcast nature of the transmission. A network that sends data over a cable from one point to the other, is known as a wired network or forms a local area network (LAN). On the other hand, data transmission over a wireless medium such as radio waves, is called a wireless network and forms a wireless local area network (WLAN). Wireless access is made possible by using wireless network adapters, devices that allows a system to join a another wireless device within its range. These adapters contain a radio transmitter and receiver that supports the IEEE 802.11 standards for Wi-Fi. Examples of devices using wireless adapters are home or office routers and Wi-fi dongles. Below we discuss the fundamental features of wireless LAN.
Wireless LAN features The wireless LAN is based on the following features: 1. It uses the unlicensed signalling frequency of 2.4 GHz and 5Ghz, part of the Industrial, Scientific and Medical (ISM).
35
2. Most devices use WLAN 802.11 IEEE standards. There are various versions of the 802.11 standard (such as 802.11b/g or n) where the network bandwidth supported varies between 2 Mb to 54 Mb per second, respectively. 3. It mainly operates under two modes namely, Infrastructure and Ad-Hoc mode. 4. The wireless nodes in the 802.11 standards are limited in range. Their usual range is between a few meters to 300 meters based on the device, frequency, transmission power and antenna characteristics. 5. The IEEE 802.11b/g/n utilizes the 2.40 - 2.48 GHz spectrum, as one of the ISM bands. This spectrum is sub-divided into various sub-frequencies or channels with a center frequency and bandwidth. Any wireless adapter operating in the 2.4 GHz spectrum operates in one of these 13 channels.
Wireless LAN modes • Infrastructure networks: An Infrastructure network is a Point-to-Multipoint connection. A single point or an intermediate access point (such as a router or PC running an access point software) is connected to one or many wireless devices. The various devices can be connected via a wired or wireless connection to the main base station or access point. The data from all connections pass through this access point. Figure 4.2 (a).
Figure 4.2: Infrastructure (Centralized) Vs. Ad-Hoc modes (Decentralized). Source: [2]. • Ad-Hoc networks: An Ad-Hoc network is deployed where wireless network infrastructure unavailable, also called an infrastructure-less network. It is a point-to-point or peer-to-peer (P2P) connection. It allows each node to wirelessly connect to the other node without the need of an intermediate access point (or infrastructure), Figure4.2(b). There is no restriction on any node to leave or join the wireless network. Ad hoc networks are classified as either Static Ad-Hoc Networks (SANET) or Mobile Ad-Hoc Networks (MANET). Traffic is transmitted to neighbours only when within its radio range when using ad-hoc mode, therefore a MANET routing protocol sets up and maintains traffic paths [4, Sec 2.1].
36
Cost Scalability
Infrastructure network Based on an access point and requires additional cost and set up Offers the advantage of scalability with more clients and with higher bandwidth
Range
More coverage due to higher power of fixed access point
Topology
In an infrastructure network, the variation of throughput and range can be anticipated
Data path
Due to direct connectivity with an access point, the data path is certain
Security
Extension
Strong levels of security are available with the infrastructure mode Uses LAN or WLAN for connection and access point provides the internet
Application
Based on the idea of a (immovable) access point in the given region
Failure
The failure of access point brings down the complete network
Ad-Hoc network Easier to set up, no additional network hardware beyond the nodes With many nodes on the same channel, the amount of interference grows and performance suffers Generally shorter working range due to limited power of the (mobile) ad-hoc nodes Due to the constant change in network topology, throughput and range varies No control over the path the data takes. The data from source to destination may hop over several nodes on the way Does not implement the strongest levels of security with ad hoc network Cannot bridge to wired LAN or to Internet without the use of special-purpose gateway Used only with WLAN and is meant for mobile of nodes that appear and disappear constantly Failure of a node, allows traffic to be routed via other nodes in range
Table 4.1: Comparison between Infrastructure and Ad-Hoc networks Table 4.1 shows the comparison between the Infrastructure and Ad-Hoc networks of operation. Although, the Infrastructure network offers several advantages over Ad-Hoc networks, the AdHoc network offers advantage in terms of mobility and independent wireless discovery of other nodes.
4.3
Mobile ad-hoc network (MANET)
A Mobile Ad-Hoc Network or MANET is a collection of wireless nodes dynamically forming a communication network without the use of centralized or pre-existing infrastructure [20]. The network consists of nodes that are independent in nature, that may be fixed or mobile and allowed to move in every direction. In MANETs, the nodes act as routers, forwarding traffic from source to destination node in multiple hop fashion [3, p.18]. MANET is an improved IP-based networking technology and offers many advantages to organizations that require wireless roaming. MANETs can be used with diverse applications such as in emergency services, battlefield, fire/safety/rescue that requires rapidly-deployable communications with efficient dynamic networking. Further, the nodes may be located on airplanes, ships, or ground vehicles; an army personnel can carry a small router configured to be part of a MANET, in his backpack, also referred to as wearable computing and communications. With the devices having a smaller footprint and given the potential impact this technology will have 37
in near future, other applications not yet realized will soon emerge [21]. In this thesis, we apply the concept of MANET with an autonomous UAV.
MANET features Before we proceed to discuss the routing protocol used by nodes in a MANET used to forward traffic between nodes, it is necessary to understand the various features and limitations in a MANET. The following are important points derived from RFC2501 for MANETs [21]: 1. Wireless equipment: A wireless node consists of transmitter, receiver and an antenna that can be omnidirectional (broadcast) or direction (point-to-point) or any other hybrid antenna. 2. Node Configuration: All nodes in a MANET operate on a specific channel or a frequency, along with the same SSID, to make it possible to communicate. 3. Dynamic topologies: The nodes are free to move and data is forward to one another typically via multi-hop fashion. The network topology often changes frequently and routing in nodes are designed to cope with these changes. 4. Bandwidth-constrained, variable capacity links: The efficiency of wireless links are lower than their hardwired counterparts. The maximum throughput may be lowered due to multiple interferences, fading, noise, etc. in the chosen frequency of operation. 5. Energy constrained operation: It can be understood that some or all of the nodes in a MANET rely on battery. One of the important system design criteria is thus, the need of optimization for energy conservation [21]. An efficient algorithm for energy conservation in MANET has been developed by Lopez, et al., Thales [2]. 6. Limited Physical Security: Mobile wireless networks are prone to increased eavesdropping, denial-of-service attacks and spoofing on their respective channels, in contrast to wired networks. As a benefit, decentralized nature of network control help MANETs cope with single node failures. This is due to clever routing strategies to get data to the destination. 7. Goal of MANETs: The goal of MANET is to provide effective operation over a wide range of mobile networks. In addition, MANETs should react efficiently to traffic demand and topological changes while maintaining effective routing in the mesh network [21]. In this respect, various routing protocols are discussed in literature to cope with the dynamic nature of MANET.
4.4
MANET routing protocols
In the last decade, MANET has undergone large amounts research regarding the various routing strategies suited to the dynamic nature of MANET. Routing in MANETs is a tedious task due to the mobility of the nodes. The mobility causes frequent changes in network topology and requires robust mechanisms to search for the nodes and maintain routes. When a node moves, the established paths with neighboring nodes may break which results in re-establishing new routing paths by searching for other possible routes, dynamically. Due to the inherent nature of wireless networks, error rates may be high and the different power levels between different 38
mobile nodes, make routing protocols more complicated. Many protocols have been proposed for MANETs. These routing protocols are classified as reactive, proactive or hybrid, each of with their own trade-off relative to the other. In the section below, a high level overview of the various routing protocol is given.
Reactive protocols In this routing scheme, route to a destination is only determined on explicit demand by flooding the entire network with Route Request packets (RRQ). The disadvantage using this scheme of protocol is high latency time in finding the route and extensive flooding can cause network clogging. Such protocols however, can reduce routing overhead in large networks on which there is no data-traffic, thereby is very appealing in the resource-limited environment. Examples of protocols in this scheme are: Ad hoc On-demand Distance Vector (AODV) routing, Dynamic Source Routing (DSR). Both of these routing, protocols have become well known standards for use in MANETs. • Ad hoc On-Demand Distance Vector Routing (AODV)
Figure 4.3: A possible path for a route request/reply from source (A) to Destination (D) in AODV. The AODV is a reactive routing protocol in MANETs, where a route to a destination is established, only on demand. With AODV, no resources is expended when no route is required. When a route is needed and not yet available in its routing table, a so called Route-Request (RREQ) packet is broadcasted. The route request packet is forwarded by all receiving nodes eventually reaching the destination. Once the RREQ packet arrives at the destination node, a Route-Reply (RREP) packet is returned along the same path to the source node, Figure 4.3. In case a node detects a broken link, a Route-Error (RERR) packet is sent to the affected nodes as per its routing table. There are many more design considerations not discussed here. More information can be found in RFC3561 [22].
Proactive protocols A proactive approach to MANET routing seeks to keep a constantly updated network topology understanding in all nodes. In theory, the complete network must be known to all nodes. This results in constant overhead of routing traffic, but avoids an initial delay in communication [4, Sec 2.2]. The proactive protocols are also referred to as Table driven protocols as each node in the network maintains the list of its neighbors. Some examples of protocols in this scheme are: Optimized Link State Routing (OLSR) , Destination Sequenced Distance Vector (DSDV) 39
routing, Better Approach To Mobile Adhoc Networking (BATMAN). The first two protocols are RFCs1 and the third protocol is yet to become a standard. The OLSR protocol (RFC 3626) is discussed below. • Optimized Link State Routing Protocol (OLSR) In OLSR, each node in the network maintains an updated list (routing table) containing the route to all destination nodes. The topology information is exchanged between the nodes on periodic basis. The main objective of OLSR is to minimize the control traffic by selecting a small number of nodes, known as Multi Point Relays (MPR) for flooding topological information [23]. MPR’s are used in in route calculation, and help in forming an optimal route from a given source to any destination. OLSR being a table-drive protocol, its operation mainly consists of maintaining and updating (route) information in a variety of tables. The data in these tables is based on the received control traffic from other nodes, and control traffic is generated based on data gathered from these tables. The route calculation is itself driven based on these table [4]. OLSR, generally proposes four types of periodic control messages: 1. HELLO - ’Hello’ messages are exchanged periodically with the one-hop neighbors to obtain neighborhood information. Using this information, each node in the network is able to construct a Multi Point Relay(MPR) set. Every node determines its MPR node based on the one-hop node that offers the best routes to the two-hop nodes and keeps a list of MPR nodes in the network. The ’Hello’ messages are sent in regular time intervals (e.g. 5 seconds) and are used for finding the information on link status and neighboring nodes. Figure 4.4 shows the MPR nodes in the mesh network that broadcast the route packets. 2. TC - Topology control messages are used for broadcasting information about its own advertized neighbours that includes its MPR set [23]. Hello messages are sent to only one hop neighbors whereas the TC messages are broadcasted throughout the entire network. 3. MID - Multiple Interface Declaration messages are transmitted by nodes that run OLSR and run on multiple interfaces (such as LAN and WAN). These messages lists all IP addresses in use the by node. 4. HNA - Host and Network Association (HNA) messages provide external routing information that makes it possible to connect to external addresses. HNA messages calculate this based on the IP address and the netmask address, to compute the resulting broadcast address. A drawback with OLSR is with the overhead caused while maintaining routes to all nodes, which is often found unnecessary. Insufficient provision of security is another drawback that is an area of current research [24]. On the other hand, all nodes can quickly obtain route information and establish a session, thereby resulting in faster forwarding of packets on request. 1
A Request for Comments (RFC) is a publication of the Internet Engineering Task Force (IETF) and the Internet Society, the principal technical development and standards-setting bodies for the Internet,Source
40
Figure 4.4: MPR node sends Topology control (TC) messages, Source: [3].
Hybrid protocols Hybrid methods combine proactive and reactive approaches to find efficient routes, with less control overhead [25]. An example of such a protocol is Zone Routing Protocol (ZRP). • Zone Routing Protocol (ZRP)
Figure 4.5: Zone routing protocol. The intra-zone uses proactive while the inter-zone uses reactive protocol. Source: [4]. Zone Routing Protocol ZRP divides the topology into routing zones and aims to utilize different routing protocols within and between these zones depending on the strengths and weaknesses of these protocols. The zone size is defined by a parameter 0 r0 that dictates the radius in hops. Intra-zone routing is carried out by a proactive protocol and interzones communicate via reactive protocol4.5. Within a zone, an up-to-date topological information on nearby nodes is available with no startup delay. While the inter-zone routing with reactive protocol, eliminates the need for nodes to keep an updated state of the entire network [4].
4.5
Selection of OLSR routing
In this research, OLSR protocol being an established proactive protocol is used on all nodes. Hybrid protocols are not applicable since the size of the network used is small. The aerial vehicle is considered as the mobile router node. It is important to note that all nodes in the network 41
must use the same routing protocol. Each routing protocol has its own control mechanism for finding routes. In this respect, the following factors are of importance: • Quick route discovery • Greater throughput • Low power consumption In [3], simulation was conducted on multiple nodes with OLSR (proactive), DSR and AODV (Reactive) routing protocols with respect to delay, network load and throughput performance in the MANET. It was found that OLSR offers low load on the network as compared to the other two protocols, up to 20 nodes. With increasing the number of nodes from 20 to 80, the network load using OLSR increases slightly. In terms of network load and throughput performance, OLSR showed the best result even for 80 nodes that were simulated in this experiment. To conclude, the OLSR protocol is chosen as it determines optimal routes between any two nodes (in terms of number of hops). It is suitable for dense and large networks and only distributes partial link state (trace of network topology and changes) information via MPR nodes. Additionally, the OLSR gathers link quality information (by using the Expected Transmission Time Metric (ETX) - A metric to assert link quality between nodes). Links that fail to maintain the quality requirements are considered disconnected. It is also to be noted that Thales Nederland B.V has researched OLSR routing in its other research projects [2]. It has been determined that OLSR serves better for routing in mobile mesh networks with respect to other state-of-the-art routing protocols. Experiments have been conducted for testing the power consumption with the OLSR protocol and its impact on the performance of the aerial vehicle. This is discussed further under section 9.3 in Chapter 10.
42
Chapter 5
Disruption Tolerant Networking Disruption or Delay Tolerant Networking (DTN), is an approach to computer networking that seeks to address the technical issues arising in heterogeneous networks that may lack instantaneous end-to-end paths. Examples are networks that operate over long haul in outer space, systems in motion or in extreme terrestrial environments. In this chapter, the history and an overview of DTN is presented in the first couple of sections. Section 5.3 presents overview of the DTN bundle protocol. Section 5.4 discusses IBRDTN, an implementation of DTN architecture and its associated utilities. In the last two sections we discuss the issues based on the current design of DTN and how this is resolved and extended to effectively use it during autonomous navigation.
5.1
DTN history
Disruption tolerant networking (DTN) is a relatively new area in the research field of networking communications. DTN concept originally emerged for use with deep interplanetary space communications (also called, Interplanetary networks or IPN), where communication suffers loss due to significantly long distances. The problems include: • Small window of time frame when communication can be attempted, also referred to as opportunistic contacts. This often is the case in space communications, due to the very nature of orbits of the planets. Point-to-point communications cannot always be continuous between satellites on different planets and data loss cannot be afforded due to disruption in communication (for instance, sun coming in between planet Earth and Mars). Just to establish a connection alone between two stations using TCP/IP, may take many hours. • Long delays produced by large distances in space. In case of terrestrial environments, MANETs also suffer similar problems. With mobile nodes, communication may not be continuous and often leads to disruptions in communication links. This occurs either due to the nodes being at a distance from each other or due to extreme conditions that persist in the environment causing high delays. To tackle these problems, the concept of interplanetary networks(IPN) has gradually been adapted to tackle communication problems in terrestrial networks.
43
5.2
Features of DTN
The usability of standard IP routing protocol is assumed to have the following characteristics: 1. Source and destination have continuous bi-directional end-to-end path. 2. Short round trip times between nodes. 3. Low error rates, i.e. relatively little loss or corruption of data on each link[Pg. 6]dtntutorial. 4. Bi-direction symmetric data rates. 5. Based on TCP/IP internet protocol suite and uses packet switching, see chapter on Wireless Networks, Figure 4.1. There are however, many evolving and potential communication environments that do not conform to the Internet’s underlying assumptions [5]. These environments can be characterized by: • Intermittent connectivity due to the absence of direct end-to-end path between the source and the destination. In these cases, application of TCP/IP cannot be applied. • Long or variable delay due to the long propagation delay and queuing delays at nodes that result in a loss of data. This implies that internet protocols cannot be relied upon, as most networks expect quick acknowledgement of data. • High bit error rates occur with the data lost in channels that results in retransmissions and increased network traffic. For a given link error rate, fewer transmissions can be expected with shorter hop-by-hop forwarding than internet-type end-to-end transmissions. As an example, military mobile ad-hoc networks are prone to the problems on intermittent connectivity, long variable delays and high error rates, due to the constant military movement and enemy jamming. Other networks where DTN is useful are with sensor networks in motion that rely on limited battery life; such nodes may not have continuous connectivity. The long distance (satellite) networks have significant delays where TCP/IP packet retransmissions can become costly. DTN overcomes these problems by employing a store-and-forward message switching in its core architecture, Figure 5.1. The email systems, also use store and forward technique, however they are different from DTN as these are not node-to-node relays. Email systems store the message in the central storage system which is independently queried by the destination host. With DTN, the complete message or fragments of data are moved hop-by-hop from one storage place to the next, along a path that eventually reaches the destination.
Figure 5.1: Store-and-forwarding message switching technique.
44
Each of the DTN (router) nodes necessitates a persistent storage for their queues. This is required because the communication link to the next hop node may not be immediately available and retransmission of message may occur. By moving messages in a single transfer on a hopby-hop basis via message switching provides the network nodes with immediate knowledge of size of messages and intermediate storage requirements [5].
5.3
Bundle layer protocol
The DTN architecture implements a store-and-forward message switching by introducing a new protocol layer, referred to as the bundle protocol hosted between the transport layer and the application layer. Figure 5.2.
Figure 5.2: Comparison of the Internet protocol stack(left) with the DTN protocol stack(right). DTN bundles can only be transmitted to/via nodes that follow the DTN protocol, Source [5]. The Bundle Protocol Agent (BPA) is a daemon (a process that persistently runs in the background) that assists to store-and-forward messages (bundles). Every node follows the same DTN bundle protocol. The DTN layer enables interoperability between diverse sub-networks having their own lower-layer protocols. As an example, a flying vehicle with TCP/IP, military network with UDP and the internet network can all be connected together via DTN interoperability. Bundles extend the data encapsulation hierarchy performed by the internet protocols [5]. The BPA inserts a few control messages via headers and trailers along with the application message that convey how the bundles should be processed, stored and handled by the next-hop neighbour, along with the user data. In intermittent communication links, the conversational TCP protocols (TCP involves multiple source-to-destination signalling round trips during data transfer), may involve significant time-lapse during end-to-end round trips and may fail completely. In contrast, DTN nodes 45
Figure 5.3: Nodes with bundle protocol supports communication with other DTN nodes with heterogeneous underlying protocols. communicate using simple sessions with minimal or no round trips [5], see Figure 5.3. The DTN protocol supports an optional acknowledgement for the transmitted messages to the destination.
Role of DTN Nodes A DTN node may act as a source, destination or forwarder of bundles. • DTN hosts: Only send or receive bundles, but does not forward them (like routers). • DTN routers: Forwards the bundles received, to nodes that implement the same lowerlayer protocols. • DTN gateways: These can be considered as special DTN routers that forward bundles to other nodes that implement different lower-layer protocols. This is how the bundle layer overlay supports different underlying architectures. In addition, DTN assigns unique identifiers for each node that may identify them based on a given region. A simple example for identifiers with two DTN nodes can be dtn : //node1 and dtn : //node2. The identifier naming can get more complex with more regions and nodes.
Classes of bundle service The DTN bundle protocol features the following class of service for a bundle: • Custody transfer: Custody refers to the bundle that is detained by a node and is considered its responsibility to deliver it to the destination Custody transfer is an optional service offered by the DTN that adds additional reliability. The retransmission responsibility of the bundle is delegated to the next-hop DTN node, so that the former can free its resources. • Return of receipt: This is a confirmation by the destination (not necessarily the next-hop neighbour) to the source that it has received the bundle. When this confirmation is received by the source
46
node, its resources are freed. This is different from custody transfer, where custodians are involved. • Time-to-live(TTL): A countdown timer is set upon release of a bundle by a custodian (owner). This is the time after which the bundle will be deleted or freed from the source node’s storage (memory or file system). • Priority of delivery: Mainly three modes of delivery are present namely, bulk, normal and expedited. However, this is not discussed further as it is not used within the scope of our research. A time-to-acknowledge timer is initiated with every bundle that requests an acknowledgement (either custodian or return receipt). When this timer expires and an acknowledgement is still not received, the bundle transfer is re-initiated but not removed from its file system yet.
DTN Routing Mechanisms Routing in the MANETs is performed at the IP level (Network layer, see Figure 4.1, Chapter 4). This layer is responsible for determining the next-hop neighbours and finding a path to deliver the given message fragments. MANETs are still based on the TCP/IP protocol suite and alone inefficient to use when disconnections occur [2, sec 6.2]. In order to deliver a bundle (say, a file) to the next available DTN node, the DTN routing mechanism determines the next-hop DTN node to which a bundle may be forwarded. Different routing mechanisms have been developed in literature, such as static neighbour routing, PRoPHET routing and Epidemic routing in DTN. Some of the available routing mechanisms are briefed below: 1. Default static neighbour routing: The bundle protocol agent or the daemon, only delivers bundles to its target DTN neighbours by a one-to-one transaction. 2. Epidemic routing: This is a flooding based protocol that increases the probability of delivery of a message by replicating it across all DTN neighbours the node comes in contact with. This is considered as the preferred routing protocol in critical military operations as it offers a higher guarantee for deliverance of a message. It is however, not very efficient in terms of storage capacity. Flooding creates multiple copies of the bundle and fills up the buffer (queue) of nodes. It is removed only when TTL of the bundle expires (which may be many hours long) or an acknowledgement from the destination is received. Quality of Service(QoS) is implemented with such routing, that assigns priority to bundles and makes bundle management more affordable. Interested reader can refer to the work done by Lopez et. al in [2], defines policies for queuing and bundle management with QoS. 3. PRoPHET routing: Epidemic routing is resource hungry as it does not deliberate to eliminate replication of messages and still improve the probability of message delivery. The Probabilistic Routing Protocol using History of Encounters and Transitivity (PRoPHET) protocol, maintains a set of probabilities of nodes encounters and uses it for successful delivery to known destinations in DTN. Note: A node that does not implement the DTN protocol layer cannot accept bundles from a node that uses DTN. In summary, all nodes need to run the DTN bundle protocol agent to accept and forward bundles. However, a non-DTN node can communicate with the DTN node on the IP level (network layer). 47
5.4
IBR-DTN
In the recent years, the DTN research has seen potential growth with many different implementations being developed based on DTN architecture. ION, DTN2 and IBR-DTN are currently the most preferred implementations of DTN. The Interplanetary Overlay Network (ION) software distribution is an implementation of DTN architecture, a product of Jet Propulsion Laboratory by Ohio University. It is designed specifically for the requirements of communication with space aircrafts. DTN2 is the DTN implementation reference project developed under Delay Tolerant Networking Research Group [sec. 6.3][2]. This is a direct implementation of DTN architecture, however provides only basic features for bundle management. IBR-DTN currently in development by Institute of Operating Systems and Computer Networks at TU Braunschweig in Germany, is a C++ implementation of the DTN bundle protocol. It is a portable and light weight development that can be used and extended for embedded systems. It supports portability to different architectures such as MIPS, ARM and x86. In addition, IBR-DTN is already used for experiments with routers at Thales Nederland B.V., and makes it a good case to go with this implementation of DTN. The IBR-DTN implementation of DTN is chosen for experimentation, as a proof of concept with the aerial vehicle. IBR-DTN is used on all communicating nodes. The source is compiled on the Raspberry Pi hardware, binaries are installed on the TP-Link router and linux based desktop systems, for use in our research.
IBR-DTN architecture Figure 5.4 shows the IBRDTN architecture, an implementation of DTN. IBR-DTN is a modular approach to DTN, where users can extend the existing design and add their own modules.
Figure 5.4: IBR-DTN architecture overview, taken from [6]. IBR-DTN is event driven architecture. The seven modules are discussed briefly only for completeness. Interested reader can get more information from [5] on this architecture. • Event Switch: Core module of IBR-DTN. It allows modules to register themselves and supports raising of events. Event switch enables the interaction between various modules. • Bundle Storage: The bundles can be stored before transmission (store and forward) or retrieved after reception from the bundle storage. The options of storage are in memory 48
(RAM), SQL database or persistent file system. • Connection Manager : Provides the facility to interact between the transport layer (TCP, UDP, HTTP) and the bundle layer. This mechanism is supported by a so called, convergence layer. • Discovery Agent: The Discovery Agent implements the DTN node awareness by supporting various discovery plug-ins. It supports two compatible plug-ins: the IP-Discovery frames compatible to DTN2 and DTN IP Neighbour Discovery [2, Sec 6.3]. • API Server : It provides a socket based Application Programming Interface (API) that comes from the TCP convergence layer. This interface could be a Unix domain socket or TCP based socket [2, Sec 6.3]. • Wall Clock : It reads the clock of the host to determine the global time. The timestamp provided by the wall clock is used as a reference for determining when a bundle should expire. This is done in order to synchronize time for all nodes. • Base Router : This module is responsible for the different routing protocols implemented as plug-ins in IBR-DTN. The base router module communicates with the discovery agent module through events, to know when a DTN node has been discovered.
5.5
IBR-DTN mechanism
The IBR-DTN daemon DTN daemon is the background process that is run on every DTN node. This daemon is an implementation of the IBR-DTN architecture discussed in Section 5.4. It hosts a central bundle management framework that enables modules to communicate with each other. Each DTN node is configured to use an interface such as wlan0 (wireless interface), and can therefore, actively use this interface to transmit and receive bundles. In order to transmit and receive bundles, the IBR-DTN features mainly three important tools for testing, the dtnsend and dtnrecv (abbreviated for dtn receive) and dtnping.
DTNSEND The dtnsend is a tool that allows users to generate bundle from a file and send it across to the destination. It connects to the dtn daemon using the DTN API and injects the bundle to the DTN. This is an executable and is run at the source node. By default, dtnsend provides a set of options defining properties of the bundle to be sent. The following are its properties: 1. filename: Specify the file to transfer. 2. destination: Set the destination node identifier (e.g. dtn://node name/filetransfer). The filetransfer is an arbitrary name of the type of the message. 3. lifetime: Specifies how long the bundle stays in the repository before expiring, in seconds. This is also known as the time-to-live (TTL). 4. priority: Set the bundle priority (0 = low, 1 = normal, 2 = high). In the work of Lopez, et.al [2], introduced further levels of priority for a bundle aiming at QoS (Quality of Service). 5. Other properties such as custody transfer, number of copies, encryption of the bundle, destination group are also available. 49
The command below, when executed, sends a file from the source node pi1 to destination node pi2 with address dtn://pi2. An expiry time of 600 seconds indicates that this bundle will expire and fail to be sent, if pi2 is not discovered within this time frame. When the bundle is successfully delivered, the source node deletes the delivered bundle from its repository. user@pi1: $ dtnsend dtn://pi2/filetransfer −−lifetime 600
DTNRECV On the other hand, dtnrecv must be executed at the destination node before receiving the bundles. The tool waits until the bundle that is initiated by the sending node, is received. On reception of the bundle, it displays the information received at the console output. It is however, important to note, that the bundle will be received by the dtn daemon automatically, when the two nodes discover each other. This is a tool that allows visible reception, for testing purposes. By default, dtnrecv provides a set of options defining properties of the bundle to be received. The properties of the expected bundle must match the properties of the bundle sent. The following are its properties: 1. filename: Write the incoming data to a file rather than the standard console output. 2. name: The type of the bundle sent. If dtnsend is initiated with an arbitrary type of ’filetransfer’, this must specified for the reception as well. 3. timeout: How long should we wait before the bundle arrives. 4. count: The number of bundles expected to be received. 5. Group: Receive the bundle destined for a specific group that the receiver is part of (set by source of the bundle). The command below, when executed expects to receive a bundle with the type indicated as filetransfer and stores the stream of bytes received into a file. user@pi2: $ dtnrecv −−name filetransfer dtnsend −−file
DTNPING As the name suggests, this generates the ping or short packet bursts from the source. This works similar to the IP level ping on layer 4 of TCP/IP model, that uses Internet Control Message Protocol between any two nodes. The dtnping works between the DTN layers of the two DTN nodes, to know their presence. The command below, sends a request from node pi1 to node pi2. If a reply is sent back to node pi1, indicates that that the two DTN nodes can see each other. This is used solely for tests between the DTN layers. user@pi1: $ dtnping dtn://pi2/echo
Working outline After reviewing the IBR-DTN architecture and understanding how it works, we now discuss the outline on how it functions. Figure 5.5 shows the mechanism of the bundle transmission and reception between two nodes.
50
Figure 5.5: Mechanism of bundle transmission and reception between two nodes. 1. The DTN daemon, as indicated in the figure, manages tight coupling between all blocks in the DTN architecture 5.4. This is run on all nodes, at all times. 2. The Discovery Agent discovers the neighbours of the node. The bundle initiated via dtnsend by a node is ready for dispatch once a node is available. If a node is not available, the bundle remains stored in the memory, file system or database, until the time-to-live of the bundle expires or the bundle is received by the destination. If the Discovery Agent is able to find its DTN neighbour (or an intermediate DTN node), the Base Router module is triggered via an event. 3. The Base Router module uses the configured DTN routing protocol settings such as static or epidemic, see Figure 5.4, to transmit the bundle. It first checks for presence of a bundle in system storage and if present, dispatches it via the daemon. 4. At the receiving end, the dtnrecv waits for the bundle, and stores the incoming stream of bytes (bundle) into the repository as a file or display it at the console.
51
5.6
Limitations of DTN design
With the knowledge on how the DTN architecture is implemented, exposed certain limitations with DTN from an application point of view. The DTN architecture allows a bundle to be received at the destination, however the bundle reception is done solely at the bundle protocol layer. The bundle protocol layer does the bundle management, processing and dispatching bundles to the target node. It hides all information pertaining to the properties of a bundle. At the end user side, the layer higher than the bundle layer, is unaware of the properties of the received bundle. It therefore, severely limits the use of DTN beyond node to node transfers. The following lists the current design features: 1. Source of bundle: The end user receives the bundle sent, but does not know who sent it. 2. No trigger on bundle reception: The end user does not have the immediate knowledge of reception of a bundle. A constant check is necessary to determine the presence of any received bundles, either in the file system or memory. The dtnrecv has the limitation that it needs to be executed before reception of a bundle. The dtnrecv writes incoming data stream into a file or displays at the console. 3. Indeterminate file format: The end user receives the contents into a file but not know the format of the file that is sent. Each bundle received is stored with a randomly created file name. Any bundle received is by default, stored with an alias such as 5bd650302346hk3k556nn4m432mm. From the alias of the bundle, it is not possible to easily determine if the bundle sent is a text file, a video message or a voice message. 4. Problem with clock synchronization: Before initiating a bundle transfer, the bundle layers of all network nodes synchronize time among themselves. This is required for consistent calculation of contact schedules and managing the bundle time-to-live throughout the DTN [5]. If the clocks on any of the nodes are found to be out of sync (even by a few seconds), the transaction is not initiated. This poses a severe challenge during testing. In our case, the bundle protocol is run on embedded systems. Having the correct time for all nodes poses a challenge. The possible solutions are a real-time clock or a gateway (access to internet connectivity) for clock synchronization, the latter which is not always feasible in MANETs.
5.7
Extending the DTN design
Solutions are found to overcome the shortcomings of the current IBR-DTN architecture, as discussed. The solutions by means of extension, are discussed below: 1. Know the source of bundle: Before a bundle is sent from the source node, the data is wrapped with trailers and headers by the bundle layer. This is shown in Table 5.1, where the user data constitutes the intended data to be sent and the others are headers and trailers. When the bundle is received at the destination, it uses the user data for processing and extracts the application-specific data for storage. However, no direct provision is offered by the bundle layer to know where the bundle came from.
52
Parameter Source Destination Class of service (CoS) Signature User Data
Value earth.sol.int, src: jpl.nasa.gov:6769 mars.sol.int, dst: jpl.nasa.gov:6769 Custody transfer, Normal priority, Time-to-live = 36 hours Application-specific data, including instructions to the destination for processing, storage, disposal and error handling. User data is not visible to bundle-protocol agents
Table 5.1: Displays the contents within a bundle, referred from [5]. The only way to the knowledge of source of a bundle is to understand how the bundle management takes place at the receiving end. It is then, necessary to capture the source of the payload (data) before the extracted data is stored into the system’s repository. 2. Trigger on bundle reception: The dtnrecv is a C++ program, when executed, waits for a bundle to be received. When the bundle (stream of bytes) is received, the data is copied to the local storage. This process is meant to be executed on a per transaction basis. Once the bundle is received, the process terminates. The dtnrecv process is redesigned to run as an independent background process, and trigger an event whenever a bundle is received by the node. This frees us from executing the dtnrecv process, time and again, on a per transaction basis. Also, the source and data are extracted from the bundle, every time any bundle destined for this node is received. This pair of information is then sent as parameters to an external script, to handle the received source and data. Figure 5.6 shows the algorithm devised to improve upon the dtnrecv mechanism. Bundle processing algorithm Algorithm 1 is based on Figure 5.6, describes the procedure to handle any number bundles received at any time. The client (host process) connects to the local DTN daemon server via a socket. As soon as the bundle is received by the beneficiary, an external bundle processing is initiated. The data are processed externally using a script and stores it in the desired location. The script can make use of the knowledge of the source, which is lacking with dtnrecv. After the data is handled, the temporary file created is removed. Three processes are involved in this operation. One is the DTN daemon server that is the heart of DTN, the external script for received bundle management and the host process that connects to the server. The host process is made to run actively, listening for bundles.
53
Algorithm 1 Received bundle processing Require: key bundleT ype, port, group, client, bundle, payload, source, tempP ath, active, ack Ensure: DTN daemon is running and active is set to true. 1: while active 6= false do 2: client ← createClient(bundleType, port, group) 3: ConnectToServer(client) [Wait for DTN daemon to respond] 4: bundle ← getBundle() [Get reference to the bundle received] 5: payload ← getPayload(bundle) [Extract the payload from the bundle] 6: source ← getSource(bundle) [Get the source from the bundle] 7: tempPath ← writeToTempFile(payload) [get the path of the temporary file created] 8: result ← externalScript(tempPath, source) [Process externally] 9: if result then 10: deleteFile(tempPath) 11: else 12: THROW Exception [Error processing bundle) 13: false → active
Figure 5.6: Solution of event based trigger and handling on bundle reception.
54
3. Tackling the file name, format problem: As described already, this is a concern if one wishes to store a received bundle and forward this bundle to some other node, in future. The bundle received by a node is stored with a randomly created file name. Further, the format of the file is unknown. This severely limits the possibility of information forwarding. As per the implementation in DTN architecture, it is not possible to know the name or file format of the data sent. This knowledge is not encrypted into the DTN bundle. A clever way found is to get around this problem is to archive (i.e. tar) the data before sending and on reception, this data is unarchived (i.e. untar). This offers a two-fold advantage: • Many data (files) can be clubbed together for sending to a destination node, rather than separate (dtnsend) transit of files. • The name and file format is now known. Possibilities emerge, to retransmit this data to other nodes, as required. Further, this information can be used on an application level. The solution devised by archiving and unarchiving of data, is used in the protocol developed for aerial data exchange, Chapter 10. No visible overhead is found with tar, untar as the size of file remains nearly the same. 4. Solution to clock synchronization problem: Two solutions have been devised to tackle the time-synchronisation problem. One is with the use of an external clock source with the hardware. The other is a software solution. (a) As per DTN design, each node’s timestamp requires to be synchronized with the other nodes timestamp. Even a slight difference in timestamps can cause a failed transaction. The DTN protocol is used on the Raspberry Pi hardware. Since, the Raspberry Pi is not always connected to the internet, it is not possible to keep track of the exact time. In order to have a sense of time, a solution is to interface a real-time clock (RTC) with the Raspberry Pi hardware. This enables it to keep up to the current time. An RTC module in interfaced with the Raspberry Pi hardware. For more information, please refer to Section C of appendix. (b) It is tedious to have an RTC interfaced on all DTN nodes in the network. A software solution is more preferable. Certain modifications are made to the start up script of IBR-DTN daemon to remove the time-synchronization dependency altogether. This enables all nodes to smoothly transit bundles without worrying about the time sense. This solution is used hereafter, and has been found to be useful for demonstrations. More on this is detailed in Section C of appendix.
55
Chapter 6
Network Setup on Raspberry Pi This chapter is about setting up of ad-hoc routing, OLSR and DTN protocols on the various nodes in the network as part of this research conducted at Thales Nederland B.V. In Section 6.1, the steps with respect to ad-hoc network setup on Linux based systems such as Raspberry Pi, personal computer and TP-Link routers is presented. The MANET configuration using OLSR is discussed in Section 6.2. The development and analyses of MANET nodes is presented in Section 6.3. The ability to retrieve useful information from the OLSR routing table, by the use of plugins is explained in Section 6.4. The essential configurations in OLSR and DTN is tabulated in Section 6.5. In the end, Section 6.6, illustrates how the communication between any two end-points in the network will work after a successful setup. The idea is to first set up an ad-hoc network in the laboratory and conduct experiments. Further, the IP routing protocol such as OLSR is tested on every node to extend the range of the network by two hops. The DTN is then integrated to make the store and forward approach possible. The main focus in this chapter is network setup on the Raspberry Pi. This applies equally well to other systems such as desktop PC running a Linux distribution and TP-Link routers that run OpenWRT operating system. Finally, the integration of one of the nodes with the UAV is established, to make it truly a MANET node.
6.1
Node configuration
Prior to the ad-hoc mode set up, the Raspberry Pi node is installed with the Raspbian OS, a Linux distribution based on Debian. Please refer to C for Raspbian OS installation instructions. The following are the five most essential parameters required for the ad-hoc network setup. 1. Mode: All nodes are configured to be ad-hoc, by setting the mode property of wireless device. 2. Network name: Nodes are configured with the same network name or Extended Service Set Identification (ESSID). It is used to identify a group of nodes that are connected together in the network. 3. Frequency or Channel : The nodes must operate on the same channel or frequency. Wireless channels are translated into a radio frequency. As per the EU standards, selection from channel 1 to 13 is allowed in the 2.4 GHz spectrum, Figure 6.1 shows the various channels in this range.
56
4. Cell Identity (Cell-ID): Set the cell-identity of the ad-hoc network. The cell-identity offers a set of unique hex-value pairs that force the network card to register the given accesspoint or ad-hoc network. The Cell-ID is derived from the ESSID and channel used. E.g. 00:60:1F:0D:B2:45 5. Transmission power : The transmission power of the wireless device can be set from 0 dbm (1 mW) upto 20 dBm (100 mW), as the maximum permissible limit. A table detailing this setup is listed in appendix, under Section C.
Figure 6.1: Figure shows the standard 13 channels, as per 802.11 standard. Each channel has a bandwidth of 22 MHz; taken from Wikimedia commons(2.4 GHz Wi-Fi channels). The 14th channel is only available in Japan.
Channel selection In the laboratory, where experiments are conducted, the presence of many wireless devices such as routers and other wireless equipment often result in interference on certain channels in the 2.4 GHz spectrum. In order to set up six nodes, all configured in ad-hoc mode, a channel selection is required. This is an important consideration as otherwise it becomes tedious to narrow down problems. A possible problem is with unexpected packet loss caused due to surrounding wireless interferences.
Figure 6.2: A study of wireless devices sensed in the laboratory, using aircrack-ng, an opensource network tool. The BSSID (MAC addressed) of the systems have been hashed. The 2.4 GHz Wi-Fi (802.11 b/g/n) spectrum is part of the ISM band is 83.5 MHz wide (2.4 GHz - 2.4835 GHz). It is made up of 13 channels, with 11 commonly used channels. Channels 12 and 13 are normally not used to avoid any potential interference in the adjacent restricted frequency band (2.48 - 2.5 GHz band). All channels occupy 22 MHz in the spectrum and all
57
adjacent channels are separated by 5 MHz. There is a minimum of 10 MHz overlap with the adjacent channels, see Figure 6.1. When set to channel 6, it invariably occupies the bandwidth of channel 5, 7 and half the bandwidth of channels 4 and 8. As a rule of thumb, it is suggested to be atleast 25 MHz away from neighbouring networks in order to avoid overlapping frequencies. Channels 3 and 10 were found to relatively safer while finding a suitable channel to use. Figure 6.2 displays all the available networks sensed in the vicinity after setup. The ad-hoc channel 10 with an arbitrary ESSID irt-ah-inria is chosen for our experiments. The Beacon frames contain certain control information and are transmitted periodically in each of the 11 channels to announce the presence of a wireless network. A higher beacon count indicates a minimum collision and a higher throughput.
Interface setup Figure 6.3 displays the settings used for configuring the network interface. The settings used for the configuration is based on the parameters discussed in Section 6.1. WLAN0 is the default name given to the wireless interface card and settings are made for this wireless interface used on a node. Note that the manual setting for the Cell-ID is in theory, not required. However, when a wireless adapter is used on a node, it is on certain occasions found to change to a different Cell-ID. One of the possible reason for this behaviour is due to the drop in power available to run the wireless device. This forces the wireless adapter to switch to another frequency as a counter measure, resulting in change of its ESSID. This ultimately, leads to a disconnection from other ad-hoc nodes in the network. Forcing the Cell-ID permits to retain the frequency and thus the connection, even in case of a power drop.
Figure 6.3: Settings used for the ad-hoc network setup.
Figure 6.4: The encircled number indicates the sub-network address. The ’X’ refers to the range of 1-255 devices or node identifiers. All nodes in the mesh network are configured with a static IPv4 IP address. To use a DHCP (to dynamically assign IP addresses) is not practical. A solution would be to use IPv6 stateless address configuration, where a unique IPv6-address can be constructed using MAC (Media 58
Access Control, has a unique number, for each wireless card). Figure 6.4 shows the ad-hoc nodes in two unique networks on the IP. To enable the devices to communicate with each other, we set the netmask of the node. A broadcast address is then computed by using the netmask and IP address of the node. The broadcast is set by the wireless device, that specifies to what all (external) networks it can reach based on the given netmask.
Figure 6.5: The wireless interface configuration (iwconfig) after set up.
Figure 6.6: The resulting interface configuration. Notice the hardware(MAC) address of the wireless device, along with broadcast address, transmitted and received packets. The configuration after the wireless device setup in the ad-hoc mode is shown in Figure 6.5. Channel 10 is used on all nodes and maps onto a frequency of 2.457 GHz. Figure 6.6 shows the interface configuration details with broadcast address. Freeing the interface A mention of a problem that is technical in nature is discussed here, for completeness. The steps detailed so far is expected to result in a peer-peer ad-hoc connection between Raspberry Pi nodes. However, it was noticed that even after several attempts it resulted in unpredictable communication. After analysis with networking tools such as airmon-ng, indicated that some processes use the wireless interface. Airmon-ng is a network analysis tool that amongst other features helps indicate the processes that use the specified interface. To get ad-hoc to work properly, it is required to terminate all the services that airmon-ng complains about. The following observations are noted: root@pi2: $ airmon-ng start wlan0 Figure 6.7 shows the different processes contending the use of wlan0 wireless interface. The wpa cli, wpa supplicant are used for the infrastructure mode while ifplugd is a daemon that automatically detects and configures interface(s) at boot time. The different processes take their turn in using the wireless interface. The wpa processes are terminated and ifplugd configuration is modified using the configuration file, as below: root@pi2: $ nano /etc/default/ifplugd In the configuration shown in Figure 6.8, the parameters INTERFACES and HOTPLUG INTERFACES can be removed or changed to point to interfaces such as eth0. Setting it to auto, all enables 59
Figure 6.7: Indication of different (unnecessary) processes using the wireless interface.
Figure 6.8: Modifying ifplugd daemon to prevent it from using the wireless interface. the daemon to be configured for all interfaces including wireless wlan0 interface, which is undesirable. The next section discusses the MANET setup using OLSR protocol. The ad-hoc network setup is an essential first step in making sure that one-hop communication between nodes work.
6.2
MANET setup
As discussed in Chapter 4, we use the OLSR protocol as our MANET protocol for communication between all static ground nodes and the aerial mobile node. OLSR routing protocol is implemented by OLSR open source group [26]. The OLSR source code is compiled for the Raspberry Pi that hosts an ARM processor. The compiled binaries are used on the TP-Link router, that is based on MIPS architecture running the OpenWRT OS. The Eclipse framework is used for programming in the Linux platform, refer to Appendix C for OLSR compilation procedure for the Raspberry Pi. OLSR creates a routing table that lists the other IP addresses it has connection to. In MANETs, nodes often come and go and for this reason the process of detection of nodes must be automatic. The OLSR carries along with it a daemon that runs as a background process to do this task. This daemon is called olsrd.
Tuning the OLSR With the mobile node as focus, it is required that when the aerial vehicle starts to hover in a region, it establishes a reliable connection with the ground node as early as possible. For this reason, we must judiciously tame the OLSR protocol to meet our expectations. OLSR provides a configuration file olsrd.conf, that consists of several parameters. The complete configuration file is found in the Appendix C. The following parameters are of prime importance:
60
1. HELLO Interval : OLSR sends periodic HELLO messages to locally detect neighbour changes and exchanges topology information among all nodes in the network to discover routes. These messages are generated and transmitted to all one-hop neighbours to achieve link-sensing, neighbour-sensing, two-hop neighbour-sensing and MPR selector sensing [4, Sec 3.6], already discussed in Chapter 4. In [27], the impact of setting the time refresh interval of OLSR hello messages on varying node density and node speed is studied, where simulation is conducted using NS2 network simulator. A couple of observations in this paper [27], are as follows: The impact of tuning the HELLO interval increases with increased node speed. When the network is relatively stable with less mobility, tuning HELLO interval has smaller impact than with high mobility. The average throughput decreases almost linearly with the increase of the HELLO interval. In our case, we deal with communication with the mobile node and consider to tune this parameter. Also, the OLSR must start its detection as early as it nears a given waypoint where the node is placed. As soon as it starts hovering in the given region, the data transaction is initiated as the connection is already sensed. There is a tradeoff between routing overhead increase and route stability improvements. This overhead can be expected to be minimum, as the nodes in our network are small. Inference from [27] is derived to reduce the Hello Interval by a multiple of 4, 5 or 10. The default HELLO interval is 5 seconds. With a factor of 5x5, this interval is reduced to 0.2 seconds. This decision is taken after testing different values for this parameter and our understanding based on simulation results already available in literature. We take minimum number of nodes used in the mesh network, to our advantage. 2. HELLO validity time: This interval determines how long does a node consider a link to be valid based on the past HELLO messages. In other words, a node connection is considered valid until this interval expires. For a mobile node, we reduce this time interval by the same factor of 5x5, to arrive at 1.6 seconds from the default 40 seconds (originally meant for static or semi-mobile nodes). 3. There are many other parameters that OLSR uses, that are listed at the end of this chapter, in Section 6.5. The same setup is maintained on all nodes for a predictable neighbour discovery.
61
(a) HELLO interval of 1.0 second
(b) HELLO interval of 0.2 seconds
Figure 6.9: Tests performed between two static Raspberry Pi nodes. Effect of HELLO interval tuning on neighbour discovery times, (a) establishes a reliable link with neighbour node in 29 seconds, (b) establishes a reliable link with neighbour node in 8 seconds. Shown in Figure 6.9 is the effect HELLO interval has on reliable discovery characteristics of one node as seen from the other. The two static nodes are placed 10 meters apart, both with a transmission power of 20dBm (100 mW). A reliable discovery is when the link quality, based on Expected Transmission Count (ETX) metric is close to 1.0 and below 2.0. The ETX value of 1.0 means a perfect link without any packet loss. ETX is discussed in the next section. In Figure 6.9a, both nodes are configured with the same HELLO interval of 1.0 second which results in achieving a reliable link quality in approximately 29 seconds. In Figure 6.9b, both nodes are configured with the HELLO interval of 0.2 seconds, results in a faster convergence to a reliable link quality in approximately 8 seconds. It is to be noted that the HELLO validity time is reduced by the same factor as HELLO interval for both nodes. The results show that the reduction in HELLO interval and validity times can help estimate faster, the link quality with the neighbour nodes. We limit our case of HELLO interval times to 0.2 seconds after validating the applicability of [27] and performing tests on HELLO intervals. Lowering this time would result in a higher contention in the network in the presence of more nodes. Also, in practice, the effective ping times between nodes can exceed 100 milliseconds, resulting in a higher rate of packet loss. In the case of the mobile node, a faster estimation of reliable link is preferable. Further, this will directly reduce the hovering time required during the data exchange.
6.3
Mesh network
Figure 6.10 shows a network setup in our laboratory, with six nodes. Notice how a chain of links tie all of the sparsely connected nodes together. The setup includes the following: 1. Nodes with IP’s 192.168.10.51, 52 and 53 are Raspberry Pi networking nodes. 2. IP 192.168.20.220 is associated with a PC (Personal Computer.
62
Figure 6.10: The network outlay consisting of six nodes, three of them are Raspberry Pi’s, two are TP-Link routers and one is a PC. 3. IP 192.168.13.207 and 192.168.11.207 are OpenWRT running on TP-Link wireless routers. It can be noticed that all nodes have directly or indirectly the knowledge of the farthest node. For example, node with IP ending .53 is connected to .220 and .52 via two hops. Note that the direct link (1-hop neighbours) between .53 and .207 shows Infinite. This is an indication that the link connecting the two nodes is very weak. In such a case, OLSR may choose another link say, via .51 to reach .207, or whichever link’s expected retransmission count(ETX) is lower to reach the target node. Refer to table in Figure 6.11.
Figure 6.11: Overview of currently available OLSR connections as seen by the TP-Link router. The current node’s static IP considered is 192.168.13.207. Note that there is a slight ambiguity in values with respect to Figure 6.10. The link costs are refreshed continuously. The LQ, NLQ and ETX parameters together determine how good the link to the neighbour node is. A source node determines these parameters by exchanging periodic HELLO messages between each other, and studies packet loss by doing so. • Link Quality(LQ): This is the quality of the link as determined by the source node. This represents the probability that a packet our neighbour sends reaches us.
63
• Neighbor Link Quality(NLQ): This is the quality of the link as determined by the next-hop node. This represents the probability that a packet that the source node sends reaches the neighbour. In other words, this is the neighbour’s view of the link quality. The value of LQ and NLQ is between 0 and 1. A value of 1 indicates a noise free channel. • Expected Transmission count metric (ETX): The ETX of a link is defined as the predicted number of transmissions and retransmissions required to send a packet over a link. The ETX of any given route is the sum of ETX of individual links in the route. For example, the ETX of a four-hop route with perfect link is four; the ETX of a one-hope route with 25% delivery ratio is 4. The table in Figure 6.11 shows clearly, the weakness of link between .53 and .207. ETX is also referred to as forward and reverse delivery ratios of the link, i.e. LQ and NLQ parameters. The sender will retransmit a packet not acknowledged in time. Every attempt to transmit a packet can be considered a Bernoulli trial, thus the expected number transmission is computed using the LQ and NLQ parameters, as: ET X =
1 (LQ)x(N LQ)
(6.1)
The ETX parameter varies between 1.0 and ∞. An ETX metric having an ∞ value, indicates that either the link is bad, or the node just got disconnected. How fast, this is updated depends mainly on the HELLO interval settings.
6.4
OLSR plugins
Plugins provide an extension to OLSR to query its internal database and gain some valuable information from a higher layer of network abstraction. A handful number of OLSR plugins exist such as Txtinfo, JSONinfo, NL80211 LQ plugins [26]. In order to derive the information on the discovered neighbours and the link quality measurements based on ETX metric, the Txtinfo plugin is used.
Txtinfo plugin To enable the Txtinfo plugin, the following command is appended to the standard OLSR configuration file. LoadPlugin ”olsrd txtinfo.so.0.1” { PlParam ”port” ”2008” PlParam ”accept” ”127.0.0.1” } This indicates that the port 2008 can be queried over the localhost. There are several commands that can be queried to this port and reply received from this port may be filtered out as desired. For example, the following command, ”/link” can be sent to the port 2008 by opening a local socket programmatically. The OLSR will return the current routing status as shown in Figure 6.12 in the form of a table. The figure displays the link cost obtained for each of the discovered nodes, also referred to as the ETX metric. This cost depends primarily on two factors, one being the interference in the channel and the other being the distance. A shorter distance between 64
two nodes would in most case, lead to lower cost. This cost will be used on our mobile node to determine the connection quality. This real-time knowledge of the connection quality thus, is used to make appropriate altitude adjustments autonomously, during the data exchange.
Figure 6.12: The response received back from the local port immediately after the query. The figure shows three nodes discovered by the local node, each having a different cost. For other possible commands using Txtinfo or other plugins, refer to the plugins section in [26].
65
6.5
OLSR and IBR-DTN configuration settings
OLSR configuration changes Table 6.1 lists the summary of the settings used in OLSR configuration file, olsrd.conf in PC based and Raspberry Pi environments, refer to the Appendix C for complete settings file. Parameter Interface
Value ”wlan0”
Ip4Broadcast HelloInterval
192.168.255.255 0.2
HelloValidityTime 1.6
TcInterval TcValidityTime
2.0 256.0
IpVersion Hna4
4 enabled
Willingness
7
LinkQualityLevel
2
Pollrate
0.05
TcRedundancy
2
Txtinfo plugin
-
Notes The chosen wireless interface (please verify your interface name via ifconfig) Broadcast IP for OLSR discovery Sets the interval of HELLO messages transmitted on this interface, in seconds Validity of HELLO messages generated, in seconds, on this interface. Set this to atleast 3*HELLO interval Sets the interval of TC messages, in seconds Sets the validity time announced in TC messages, in seconds, generated on this interface. Set this to atleast 3*TcInterval Olsrd supports both IP version 4 and 6 Hosts in the OLSR routed network may announce connectivity to external networks via HNA messages. Enable this option block for IPv4 networks Allows a node to act as relays of OLSR traffic. Can be set between 0-7 Computes link quality information based on information from other available nodes. Can be set between 0-2. Set to 2 to distribute all link quality information, for all nodes Sets the interval, in seconds, when olsrd event scheduler should be poll for updates. Default is 0.1 Specifies on how much neighbour information should be sent in TC messages, can be set between 0-2. Refer to OLSR plugins, Section 6.4
Table 6.1: The final OLSR configuration settings used for OLSR routing, OLSR v0.6.6 .
IBR-DTN configuration changes There are two important files that have been modified. The first one is the IBR-DTN configuration file (ibrdtnd.conf ) that lists all settings pertaining to running the daemon. The changed settings relevant to our study is given in Table 6.2. The other file is a script that initiates the daemon process (ibrdtnd ). Certain arguments can be appended to the daemon script to run the daemon with.
66
Parameter local uri
Value dtn://node.dtn
logfile
/home/pi/ibrdtn/ ibrdtn.log 1.0G
limit blocksize limit foreign blocksize
500M
api port
4550
fragmentation limit payload
yes 2M
storage path limit storage
/home/pi/ibrdtn/ bundles 500M
net interfaces routing
wlan0 epidemic
routing forwarding yes dht enabled yes
Notes The node is replaced by local dtn address. e.g. dtn://pi2.dtn. Leave it at its default The path of the log file. This can be changed by the user Limit the block size of all bundles. By default, 1.3 G (Gigabyte) is used Manage the space allotted for foreign bundles, when the current node acts only as an intermediate node. Kept at its default 500M (Megabyte) The port the daemon uses to bind on. Make sure it does not clash with other local application ports Yes, to enable bundle fragmentation The bundle size when bundle fragmentation is enabled. Default is 500K (Kilobyte) The storage path of bundles in transit Total space allotted for bundles. Change it according to your local memory constraints The interface to be used by DTN protocol layer The various routing options are: default (static neighbour routing), epidemic and prophet, refer to Chapter chp:dtn on DTN Forward the bundles to other nodes Default is set to No. Enable the DHT (Distributed Hash Table), a lookup table access for knowledge of other DTN nodes.
Table 6.2: The final DTN configuration settings used for bundle protocol, IBR-DTN v0.10.0.
Parameter DAEMON ARGS
Value –badclock
DAEMON ARGS
-i wlan0
Notes Append the badclock parameter in the daemon script, if it is required to completely avoid the time synchronization for bundles Append the interface name to the daemon script, if it is required to override the ibrdtnd.conf interface settings
Table 6.3: The final DTN daemon script settings used with IBR-DTN v0.10.0. The reader can reproduce this work by following the step by step setup instructions for installation in the Appendix C. The various configuration files for ad-hoc network configuration, OLSR and DTN configurations are also included in the appendix.
67
6.6
Communication between layers
By following all the steps given so far and in Appendix C, the reader should be able to successfully set up the OLSR and DTN protocols. One can now interact between the respective layers. Figure 6.13 shows the communication between two Raspberry Pi nodes. Each node has two primary addresses, a static IP address and an address for the DTN node. The OLSR protocol helps extend the node discovery by multiple hops.
Figure 6.13: Illustration of communication between two nodes using OLSR and DTN, on the extended TCP/IP protocol stack.
68
Chapter 7
Multicopter Hardware This chapter introduces the reader to the components necessary for the operation of a (mediumsized) quadcopter, subset of the multicopter, also referred to as multirotor. The necessary hardware components with respect to flight operation and networking along with the design decisions are discussed. It should however be noted, that all of the component types described herein can be used to build a hexacopter, octocopter or any custom designed multicopter; the modifications being in software and addition of actuator related components.
Figure 7.1: Schematic overview of the hardware
69
7.1
System architecture
Figure 7.1 shows the architecture of the entire system. The various hardware blocks are colored differently to enable the user to identify the component categories clearly.
7.2
Sensors
The various sensors used on board the quadcopter are discussed. The level of autonomy required by the aircraft dictates what sensors are in use.
Accelerometer An accelerometer is an electromechanical device that measures acceleration forces. It senses the resulting total acceleration composed of static (gravity) and dynamic (sudden start/ stop) accelerations. By measuring the amount of static acceleration due to gravity, we can measure the angle the device is tilted with respect to the earth. By sensing the dynamic acceleration, it is possible to analyse the way the device is moving. Its unit of measurement is either in m/s2 or in G-force(g). 1g equals the earth’s gravity at sea level. In order to measure acceleration of a stationary platform in all directions, a 3-axis accelerometer is used. However, things start to get much more complicated when the platform starts moving. When accelerating in a particular direction, this acceleration is added to whatever acceleration is provided by earth’s gravitation pull, making it tedious to distinguish the two. In addition, accelerometers are limited in their accuracy due to factors like vibration of the aircraft frame. So, accelerometers cannot be used alone to help keep an aircraft correctly oriented.
Gyroscope The gyroscope measures the rate of rotation around a particular axis. The purpose of gyroscope is the same as that of an accelerometer, that is to provide an attitude estimate for the device. If gyro is used to measure the rate of rotation around the roll axis of an aircraft, it will register a non-zero value until the aircraft stabilizes about this axis, when it would read a zero. To get an estimate of the orientation about an axis, we integrate the roll rate or roll angular velocity over time. However, gyros are prone to a known phenomena called gyro drift. The integration of discrete time samples results in accumulation of error over time and change in offset occurs with temperature differences. This leads to a slow drift of the measured orientation for an axis of the aircraft. Therefore, gyros alone cannot be used to keep an aircraft in a particular orientation.
Figure 7.2: MPU6000 integrates accelerometer and gyroscope on a single chip, Source A MEMS three-axis accelerometer and three-axis gyroscope are integrated on the same Invensense MPU-6000 chip, Figure 7.2. The values from this chip are read using the SPI1 interface, 1
The SPI or Serial Peripheral Interface bus is a synchronous serial data link that operates in master/slave mode where the master device initiates the data frame
70
by the flight controller.
Magnetometer By utilizing an accelerometer and gyroscope, a relative orientation can be measured for a quadcopter. It would however be of advantage to have some type of absolute reference, that both accelerometer and gyroscope do not provide.
Figure 7.3: Figure shows a the 3-axis HMC5883L magnetometer A magnetometer measures the geomagnetic field, providing an absolute reference for rotation of the aircraft with respect to the earth’s magnetic poles. The HMC5883L, a triaxial digital magnetometer is used by the flight controller over an I2C interface, to provide this reference for the mobile platform.
Barometer A barometric pressure sensor or a baro sensor enables to monitor the changes in atmospheric pressure. The air pressure increases or decreases steadily due to changing altitude and allows the sensor to have a measurable relationship with altitude. The MS5611 pressure sensor measures changes in air pressure and temperature. The temperature compensation is used along with measured air pressure to compute changes in height. The baro sensor is embedded onto the flight controller board itself. The controller reads the data from this sensor using the SPI interface.
Sonar The sonar sensor, similar to the pressure sensor is used to indicate the relative distance from a source or obstacle. A sonic pulse is emitted from the sensor and waits to receive an echo back as it bounces from the object it has hit. By measuring the time it takes for the pulse to be returned, the distance to the object can be computed.
Figure 7.4: Figure shows the XL-Max Sonar sensor, MB 1200, used with the quadcopter The XL-Maxsonar-EZ0 sensor is used below the platform of the quadcopter to measure the height of the platform and to stabilize itself about this stable height using feedback loop in software. The sonar sensor is susceptible to interference with nearby noise sources. One of the reasons for selection of this sensor is its inbuilt real-time noise rejection algorithm that results 71
in virtually noise free distance readings, as per its datasheet[28]. Its accuracy ranges from a minimum of 20cm to about 700cm. Beyond, 7 meters of height, we rely more on the air pressure as the sonar sensor becomes less accurate for height measurements. One of the drawbacks of using ultrasonic sensors is that the pulse emitted by this sensor is a wide beam cone shaped signal. Due to the shape of this pulse, an echo is returned by all objects the pulse comes in contact with. This is a reason why the pressure sensor along with sonar sensor is used for height measurements for reliability. In addition, a GPS receiver as discussed below, would enable a higher precision to height measurements.
Global positioning system (GPS) The three sensors, the accelerometer, gyroscope and compass helps identify the orientation of the body about its center of rotation (i.e. the relative orientation of the aircraft’s body (θ, φ ,ψ) with respect to its inertial frame of reference and does not have a knowledge of the global coordinates(x, y, z) that determine the position in 3D; refer to chapter 8. These sensors can hold the copter’s position well in a relatively windless environment (without external applied forces). However, with an external force would make the quadcopter move away from its current position (x,y,z ) and stabilize itself again about the target attitude. The air pressure and sonar sensors are used to estimate the altitude or height of the platform (i.e. the z coordinate). In order to get an idea of (x and y) coordinates, either an optical flow camera (that maps the pixels on the surface below the aircraft to measure any deviation due to movement) or a GPS to determine the latitude and longitude (i.e. x and y coordinate positions).
Figure 7.5: Figure showing multiple satellites that revolve around the earth’s orbit at all times GPS, or global positioning system, is a satellite-based navigation system consisting of 24 satellites placed into the earth’s orbit. Each satellite circles the earth in a very precise orbit twice a day, at a distance of 12,000 miles, Figure 7.5. The signals from these satellites are emitted via radio signals, and transmit signal information such as their current location and the exact time to a precision of a billionth of a second. The GPS receivers on ground, receive the information from various visible satellites and use the well known triangulation or trilateration method to compute the user’s exact location[29]. This method determines the relative position of objects by using the geometry of triangles; the receiver measures distance using time travel of radio signals. The accuracy of position estimation depends on the number of satellites that a GPS receiver is able to see. A GPS receiver must lock onto the signal of atleast three satellites to compute a 2D position (i.e. latitude and longitude), while with greater number of visible satellites, the receiver can compute the user’s 3D position 72
(i.e. latitude, longitude and altitude or x, y, z coordinates). With the current user’s position, the receiver is also able to calculate other information, such as ground speed, altitude, hdop (the horizontal dilution of precision in cm), etc. We use a sub-meter GPS precision LEA-6H chipset from uBlox as our GPS receiver for the quadcopter.
7.3
Flight controller
Figure 7.6 shows an overview of the main components on the ArduPilot flight controller. The key features with the controller we use for the quadcopter are listed below.
Figure 7.6: ArduPilot, hardware v2.6, Taken from [7] • Uses the Invensense 6DoF MPU-6000 with MEMS acceleromter and gyros; described in section A. The same board hosts a barometric pressure sensor. • Availability of dedicated pins for interfacing external magnetometer and sensors such as sonar and a GPS module of our choice. • A Telemetry port to send wireless commands to the ground station. • On-board 16 MB dataflash to log flight data. Custom data can be logged by writing to the dataflash’s EEPROM. • External IO pins for interfacing with external hardware. In this project, we interface a Raspberry PI using UART2 2
UART: Universal Asynchronous Receiver and Transmitter. This is a standard interface to communicate between a serial device and a microcontroller.
73
• Input and output pins for interfacing the RC receiver’s PWM (Pulse Width Modulation) output3 to feed output of microcontroller to the (four) Electronic Speed Controllers(ESC), respectively.
7.4
Electronics and actuators
The selection of the required components for the electronics and actuators is based solely on the user’s requirements. Our requirement is to get a hovering time of about 15-20 minutes; going beyond this margin involves further research and increased costs. The design should afford addition of extra payload and sustain the flight time. The flight time is affected by the choice of motors, battery and the propeller used. The state-of-the-art quadcopters fly an estimated 7-20 minutes.
Brushless motors A quadcopter has four motors, each with a propeller attached to it. In almost all multicopter designs, a brushless outrunner motor is used to drive the propellers. A reason to use this motor as compared to a normal DC motor is that they provide higher speeds and use less power to provide for the same speed. The brushless motors are more efficient (≈ 80%) and dissipate less heat as compared to DC motors that contain brush-transitions that result in a loss of efficiency.
Figure 7.7: Inside the brushless outrunner motor, AC2830-358 850Kv The name outrunner comes from the fact that the outside of the motor turns, contrary to the inner part of the motor. The outer part as seen from Figure 7.7 contains a series of magnets that provide the magnetic force to interact with the electromagnets on the stator, the inside part of the motor. The motors are activated using three wires that provide current to these electromagnets. These motors are also called multi-phase AC motors. The ESCs, discussed next, provide the required AC power to activate these motors. For the given AUW (All Up Weight) of 1.6 kgs, each motor would require at least 400g of thrust for take-off. To hover or fly at a suitable height, it can be expected to have a slightly greater thrust than 400g. As a general rule of thumb, the total thrust-to-weight ratio should be atleast 2 : 1, not adhering to which adversely affects the flight capability. Brushless motors come in many different varieties, where their size, current consumption and number of coil windings differ. The most important parameter in selection of a motor is Kv. It refers to the maximum revolutions per minute (RPM) the motor provides per volt. An 850Kv motor at 11V, for example, would provide 9350 RPM. For the requirements in this project, 3
PWM: Pulse Width Modulation (PWM) is a technique to represent an analog signal in the digital domain. For the digital signal, the duty cycle of the wave varies in accordance to the analog signal’s amplitude.
74
we choose the AC2830-358 850Kv motor with 10”x4.7 propeller4 . Table 7.1 shows the thrust generated versus power consumed for a AC2830-358 850Kv motor. The specifications take into account usage of a 10” propeller and a 3S LIPO power source. The weight of the motor is 62g.
Amp Wattage Thrust
25% 1A 11W 170g
50% 3.4A 38W 433g
70% 9A 100W 855g
100% 12.2A 135W 1095g
Table 7.1: The table lists the ampere draw, power consumed and thrust(in grams) obtained at different levels of activation. The specification differs slightly with different manufacturers. It is found during analysis in this thesis that there is the non-linear relation between thrust and power consumed above the take-off point until hover. Please refer to Chapter 9.
Electronic speed controller (ESC) The brushless motors used are true 3-phase AC motors. An ESC converts the DC power from the battery to AC power to the motors. They vary the amount of power by taking the (pwm) signal from the microcontroller. An ESC internally, is a trapezoidal wave generator that produces three separate waves (one that goes to each wire of the motor). It controls the speed (RPM) of the 3-phase AC motor by changing the frequency of the waves. The higher the frequency, the faster the props on the motors would turn.
Figure 7.8: Figure shows a 20 Amp, Electronic speed control or ESC that provides varying high frequency AC voltage to the brushless motor In Figure 7.8 notice the three (blue) wires that connect to the three wires of the brushless motor, as in Figure 7.7. The other side of the ESC receives the voltage (+/-) on red/black wires. Most modern ESCs incorporate a battery eliminator circuit (or BEC) to provide constant voltage for the on board electronics and RC receiver, removing the need for an extra battery for powering the receiver. The 3-wire servo lead as seen in this figure, receives varying pwm pulse from the microcontroller(white wire) and outputs a 5V signal to power the receiver (red/black wires). It is important to note that all on board electronics work at either 3.3V or 5V. The battery source for the quadcopter provides us with a much higher voltage that requires to be stepped down. 4
For a propeller (10x4.7): The first number indicates the blade length in inches and the latter indicates how far the propeller travels with each rotation.
75
ESCs come in different shapes and sizes and are categorized on how many amperes it can support. In Table 7.1 we discussed about the amperes drawn for the 850Kv motor and prop combination. 12.2A is found to be the maximum power consumed by this motor at full throttle. In order to keep a safe margin, a 20A ESC is suitable to keep it within limits of maximum current draw and to let it run cooler. Also, the specifications from the manufactures are based on work-bench results and may not truly depict the situation when the motors are moving in the air. As the last step towards selection, it is convenient for the ESCs to be programmable. The ESC comes with different firmwares, each having a different performance on the motor control. Simon K firmware is chosen for these four ESCs being optimized for the use of multicopters. Most ESCs receive information from microcontroller at 400Hz, with the maximum frequency being 500Hz (i.e. maximum of 2 ms PWM pulse width from microcontroller). SimonK’s firmware increases the rate at which the ESC sends the speed changes directly to the motor and removes the averaging function common to most regular ESCs; results in smoother motor accelerations and makes a difference in stability. An AVR programmer can be used to upload this firmware and make suitable modification via its flash tool. More information can be found in [30].
7.5
Power supply
The Lithium Polymer or LIPO batteries power RC models and plays an important part in the design. The LIPO batteries are chosen over other energy sources such as NiCd, NiMH or Li-Ion as they have the potential to deliver high discharge current at higher voltages, in other words deliver the high power required for the flying vehicles. From experience, the power required for hovering varies between 150 W for smaller aerial vehicles weighing approx. 1 kilogram, to about 1500 W for 7 kilogram vehicles.
Figure 7.9: A LIPO battery that delivers 1000mAh current at 30C, 11.1V. This figure is only used only for illustration purposes. A Zippy 5000mAh, 20C at 11V is used for the quadcopter. There are several numbers that classify the LIPO battery: 1. mAh rating: Determines how much power can be stored in a battery in relation to time. A 1000mAh battery can deliver a constant 1 Ampere of current for an hour. 2. C rating: The C rating is a measure of the maximum continuous current a battery can safely deliver. A 30C rating specifies, 30x1000mAh, or 30A of continuous current can be drawn at a time. Drawing current at 30A, however would drain the battery faster. For our design, the maximum current each of the four ESCs can handle is 20A. A low C-rated battery would supply low currents, thus not able to support a high kV brushless motor, making the motors less responsive to speed changes. On the other hand, a very high C-rating may indicate a heavier battery and inadvertently affect the flight time. 3. Number of Cells: The number of cells in the battery determine the voltage of the battery. Each cell measures a base voltage of 3.3V/cell and fully charged voltage of 4.2V/cell. A 3S (3 series cell) battery has a base voltage of 9.9V, nominal voltage of 11.1 V and fully charged voltage of 12.6V. A 3S-3P battery indicates 3 cells in series and 3 cells
76
in parallel leading to 11.1 V nominal voltage with thrice the amount of current capacity. A 1S and 2S batteries provide low power and are commonly used for powering receivers and for micro vehicles. 3S batteries are the standard batteries used for quadcopters while a 4S batteries are used for speed planes. LIPO selection criteria LIPO batteries are high energy density batteries and can be dangerous if not treated properly. As a first step it is necessary to go with known brands such as Turnigy and Zippy amongst others. Based on the parameters for LIPO batteries described, they come in different shapes, sizes and combinations. The LIPO battery is usually the heaviest part of the aerial vehicle and its selection would directly affect the flight time. As a basic rule, the power P (measured in Watts (W)) required to develop thrust (i.e. lifting capacity) T, expressed in Newton (N) is given by: P ∝
√
∼
T3
An interesting paper on this subject is found in [8] that depicts the non-linear effect of weight on flight times, also see Figure7.10.
Figure 7.10: Non-linear effect of increase in weight against flight time, taken from [8]. The selection procedure is given below: • Current to drive motors: Current/ESC x 4 = 20A x 4 = 80A • Number of cells: We select the 3S LIPO battery. A 4S battery is also a possible, though a 3S is found to perform better on a medium sized quadcopter, for the given motor and propeller combination. • Select the battery (manufacturer) that provides a higher power for a given weight. With each of the four ESCs drawing 20A current, the maximum current draw is 80A. A 3S 5000mAh, 20C LIPO, would be able to deliver 5Ah x 20C = 100C of current that suits our requirement. With the idea of keeping the weight to the minimum and getting maximum power, a 5000mAh LIPO is found to be better in comparison to 2200 mAh, 3600mAh, 6000mAh in the same category. A Zippy LIPO 3S, 5000mAh, 11.1V battery is 470g and is found to be 25g lighter than its Turnigy counterpart.
77
Power module The power module provides an easy way of supplying a clean power to the flight controller from a LIPO battery along with the current consumption and battery voltage measurements all via a 6-wire cable. It includes an on-board switching regulator that outputs 5.3V and a maximum of 2.25A, Figure 7.11. The thick red/black of the power module outputs 11.1V and connects to the power distribution unit that supplies the power to ESCs.
Figure 7.11: Power module provides a clean power supply to on-board electronics and for voltage, current measurements
Power distribution The power distribution, as the name suggests supplies power to all ESCs. It systematically organizes the various wires through a one power distributor PCB. Figure 7.12 shows the power distribution unit that is placed in the center of the quadcopter to power the four separate ESCs.
(a) Power distribution board(PDB) soldered with deans connectors
(b) The PDB at the center of quadcopter
Figure 7.12: Power distribution board to distribute power to the four ESCs, flight controller and Networking hardware
7.6
Communication equipment
Telemetry radio We use a pair of wireless devices operating at 433MHz (EU standards) to set up a wireless link between the quadcopter and the ground station. Real time flight data is displayed on the ground station and flight commands can be sent to the flight control in real time. It uses a
78
protocol called Micro Aerial Vehicle Link(or MAVLink) to transmit or receive data between the two. Figure 7.13 shows the ground module along with the air module. An FTDI to USB cable is usually used to connect the different modules to the flight controller and laptop, respectively. Note: The telemetry modules may have to be configured for use with the given power, air data rate, etc. This can be done using the GUI provided by manufacturer, for configuring the telemetry via FTDI.
Figure 7.13: Two radio modules with antennas.
Radio transmitter and receiver A radio controlled(RC) transmitter is used for manual control of the flight usually when being within the line of sight(LOS). We use a 9-channel user RC transmitter and an 8-channel RC receiver on flight. Each channel of the transmitter is assigned different functions. An example is presented below: • Channel 1,2,3,4: Pitch, roll, yaw, throttle • Channel 5: This is a 3-position switch. It is set to work in Manual control, Hover and Autonomous mission modes. The action is taken on the flick of the switch. • Channel 6: This is a potentiometer knob. In flight PID tuning of parameters can be achieved such as tuning the Proportional value for the roll axis. This is discussed further in chapter 9. • Channel 7,8: Not currently used.
The RC transmitter uses a transmitter module on its back that combines each of the 9 PWM5 channels (≈2ms each) into a PPM signal on the transmitter (≈20ms) and modulates it to 2.4GHz frequency before transmission. The receiver demodulates the signal and feeds the decoded PPM signal directly to the flight controller. The flight controller reverse engineers the PPM signal into various PWM channels for its use. Figure 7.14 shows the a)FlySky FS-TH9X Transmitter with 2.4GHz DJT Module b) FrSky D4R-II Receiver. The RC transmitter usually comes already flashed with the latest ER9X firmware for use with multitrotors. 5
PWM stands for Pulse Width Modulation and PPM stands for Pulse Position Modulation. PPM is combination of several PWM signals lined up back to back.
79
(a) FlySky FS-TH9X Transmitter with 2.4GHz DJT Module
(b) FrSky D4R-II Receiver
Figure 7.14: The hand held transmitter sends control signals to the receiver on flight.
Wireless LAN (WLAN) Wi-Fi is an accessory allowing computers, phones, routers or other devices to connect to the internet or communicate with one another wirelessly in a particular area. Wi-Fi is a wireless local area network (WLAN) product based on IEEE 802.11 standards. A Wi-Fi hardware is also called wireless adaptor. We test three different Wi-Fi wireless adaptors for use in our research namely, Wi-Pi 802.11n wireless adapter, Edimax ew-7811un and TP-Link WN722N. Wireless adaptors are used for bi-directional communication of data with other nodes in the mesh network. Figure 7.15 shows the TP-Link wireless adaptor that is used in our project.
Figure 7.15: Figure shows the TP-Link wireless dongle based on 802.11g/n standards.
7.7
Frame specifications
The frame of the quadcopter is the structure that holds all the components together. The frame should be rigid, able to survive crashes and to minimize the vibration coming from the motors. A medium-sized quadcopter is built with off-the-shelf hollow aluminium frames. Aluminium frames are chosen with the objective of outdoor navigation. An aluminium frame provides greater resistance to crash compared to a carbon fiber frame. The hollow aluminium arms weigh approx. 360g. With respect to the arm length, the term motor to motor(M2M) distance is often used. It 80
Figure 7.16: Figure shows the quadcopter constructed with aluminium frame. indicates the distance between the center of one motor to that of another motor of the same arm, Figure 7.16. The M2M distance usually depends on the diameter of the propellers used. There should be sufficient space between the propellers so as to avoid hitting each other. For the given design, 56 cms was found to be sufficient as per the manufacturers frame design.
7.8
Networking hardware
In the previous chapter 3, the different hardware that support networking were studied. The Raspberry Pi processor is found to be the preferrable choice.
Figure 7.17: Figure shows the Raspberry Pi processor interfaced TP-Link WN722N wireless adaptor and a 5 Mega Pixel HD camera. Figure 7.17 shows TP-Link wireless adaptor connected to Raspberry pi. An 8GB SD card is used with the raspberry pi that runs the Raspbian operating system and also used for storage of data. Also notice in the figure, the (video) camera shown is interfaced with Raspberry pi. Raspberry pi is used as one of the nodes in the network of nodes (i.e., mesh network). All nodes are configured in ad-hoc mode. One of the nodes is a mobile node (i.e. quadcopter) with other nodes being (static) routers. The TP-Link based wireless adaptor is found to have a better performance with the mobile node in terms of its wireless range and optimized device driver support for ad-hoc mode. We later used the same wireless adaptor on all nodes, for consistency of results. Raspberry Pi is interfaced with the flight controller via its GPIO pins.
7.9
List of components
The list of components purchased is presented in Table 7.2. Note: This table lists the base components required for construction of a quadcopter. Please 81
note that the spare components in various categories, wires, and connectors were bought and delivery charges are not included. Total estimate is ≈ 1150 e6 Table 7.2 is a reference list for the final components that are used. All the three quadrotors in this project use similar parts but from different manufacturers. The software on all quadrotors adhere to the same platform for consistent results. Only one quadrotor at Thales, is used for demonstration purposes.
6
Price at the time of writing, August 2013
82
Qty
Price( e)∗
1
107
1
55
1
62
Used for communication with GCS
1
30
XL-MaxSonar-EZ0, long range (≈7m)
4
10
Aluminium arms provide durability
1
12
APM Power Module (for 5V supply)
1
11
20 Amp ESCs
4
13
4
16
Receives varying voltage from ESCs to turn the rotors
4
6
Standard propellers for 850kV motors
1
16
1
85
1
25
2
22
1
120
Description ArduPilotMega(APM) v2.6 3DR ublox GPS with Magnetometer 3DR Radio 433Mhz ”Air” module (EU) Sonar sensor (MB1200) 3DR Quad arms (black, blue) Power Distribution board (PDB)
Brushless Outrunner Motor (AC2830-358, 850Kv) APC Propeller set, 10X47 SFP Style FrSky D4R-II Receiver FlySky FS-TH9X Transmitter, RF module Turnigy Accucel 6 charger LIPO batteries Networking Accessories
Notes Flight controller board consists of MPU6000 sensor, pressure sensor uBlox LEA-6H GPS module with an external magnetometer
Distributes current to speed controllers (oe ESCs) from energy source Conects directly to battery and supplies a clean 5 volt power supply to flight controller ESC is used with SimonK firmware. Converts DC to AC signal.
RSSI (PWM) and CPPM output. FrSky RC receiver is compatible with many other transmitters models. The transmitter operates in 9 different channels. A FrSky DJT module is used as the RF module at 2.4 GHz Upto 6 Cell balancer and charger for LIPO, Pb, NiCd batteries 5000mAh batteries, 11.1 V(≈490g) Includes Raspberry Pi, SD card, HDMI cable and other relevant components
Table 7.2: List of components for quadcopter and networking accessories. Base cost of ≈ 747 e.
83
Chapter 8
Multicopter Software In order to control the movements of the multicopter, it must be able to follow a reference position signal. The reference signal is generated by a higher level of control, that can either be the directed through the input of the RC transmitter or from a control algorithm that uses GPS or visual aid to provide this reference. This chapter describes the software to handle the task of following the reference signal, also referred to as local control. First, a simple mathematical model of the quadcopter is presented. This is followed by an overview of the functional blocks that describe autonomous tracking of a target and waypoint navigation using GPS. The same software can be used for quadcopter, hexacopters and other designs, with slight modifications.
8.1
Mathematical model of the quadcopter
This section defines a simple mathematical model of a quadcopter, that is used to derive a (local) controller. This model is based on the model proposed in literature, found in [31]. 2The introduction in this section is very brief and only defines the basic relations without actually deriving please refer to [31] for the derivations and details. 2 them, Mathematical model of quadcopter Figure 8.1 is taken from [31] and depicts the structure of the model of a quadcopter, the quantities used and itsstructure angles. The origin of the global axis frame of the reference, x, y, z is located The quadcopter is presented in Figure 1 including corresponding anin the center of mass of the quadcopter. The x axis is defined as always pointing towards gular velocities, torques and forces created by the four rotors (numbered from 1 to the
4). f4
f1
ω4
z
τM4 y
φ
ψ
ω1
zB
x
f3
yB
τM3
θ
τM1 xB
f2
τM2
ω3
ω2
Figure 8.1: Quadcopter model, quantities and angles
Figure 1: The inertial and body frames of a quadcopter 84
The absolute linear position of the quadcopter is defined in the inertial frame x,y,zaxes with ξ. The attitude, i.e. the angular position, is defined in the inertial frame with three Euler angles η. Pitch angle θ determines the rotation of the quadcopter around the y-axis. Roll angle φ determines the rotation around the x-axis and yaw
north, while the z axis is defined as pointing towards the zenith. With the use of the right-hand axis frame, the y axis always points to the west. The body axis frame xB , yB , zB has the origin at the origin of the global axis frame, but the axis of the body frame of reference always aligns with the arms of the quadcopter [32]. The attitude of the quadcopter (and thus, the body axis frame relative to the global axis frame) is denoted by the angles φ, θ and ψ. Roll, is the rotation around the x axis, is indicated with angle φ. Pitch, corresponds to rotation around the y axis, denoted by the angle θ, and angle ψ denotes ’yaw’, the rotation around the z axis. In this manner, the total position (linear and angular) of the quadcopter is given by the vector q, defined as follows: q = [x, y, z, φ, θ, ψ]>
(8.1)
The quadcopter is assumed to be a rigid body that is completely symmetrical around the z-axis, in terms of both weight distribution and size. This results in a diagonal inertia matrix: Ixx 0 0 I = 0 Iyy 0 0 0 Izz The values of the elements of I are determined by the actual weight distribution and size of the quadcopter.
Each of the four rotors, indexed by i ∈ {1, 2, 3, 4}, generate an upward force fi perpendicular to the zB -axis, the z axis of the body frame of reference, since they are connected to the propellers. ωi denotes the angular speed of rotor i. Since, the rotors and the propellers have a certain weight, a torque τMi around the rotor axis is generated by the rotation of each of the rotor [32, Chp. 3]. fi = kωi2 (8.2) τMi = bωi2 + IM ω˙i
(8.3)
In this equation, k is a lift constant, b is a drag constant and IMi is the moment of inertia of the rotor i. The total thrust T generated by the propellers is in the direction of the zB -axis and is normal to the earth’s surface when the roll and pitch angles are 0◦ . The angular torque τ~B expresses the torque in the body frame as a function of the rotor velocities [32, Chp. 3]. The torque τ~B determines the change in attitude, i.e. the roll, pitch or yaw angles.
T =
4 X i=1
fi = k
τφ τ~B = τθ = τψ
4 X
ωi2
i=1
lk(−ω22 + ω42 ) lk(−ω12 + ω32 ) 4 X TMi i=1
(8.4)
(8.5)
where, l is the distance from the center of the quadcopter to the center of the rotors. Shown in (8.4) and (8.5), the rotor speeds ωi determine the total thrust that in turn corresponds to the height of the quadcopter, and the change in roll, pitch and yaw angle. The task of the quadcopter stabilization thus, is to accurately control these speeds in a way that the roll, pitch, yaw and thrust converge to the desired values as early as possible. The interested reader can refer to the controller loop design that ArduPilot flight controller uses, found in [1, p. 3841] 85
8.2
Sensor Fusion Algorithm
To be able to find a reliable estimate of the orientation of the quadcopter in a 3D space, the data from different sensors requires to be fused together. The gyroscope can only measure the displacement relative to its starting position. The accelerometer can determine the absolute position but it is noisy and inaccurate when the object is in motion. The compass (or magnetometer) measurements are often corrupted by the induced magnetic fields due to the nearby rotors, ESCs and on-board electronics. There are multiple methods to reliably estimate the orientation of an object in 3D space. One of the most reliable methods is to use a Kalman filter approach. The Kalman filter estimates the noise on each of the sensors in order to optimize the reliability of the filtered position [33]. However, a Kalman filter comes at the cost of high computational load and complexity in implementation [32]. The term Inertial Measurement Unit (IMU) is often used to denote the sensor fusion algorithm that is implemented either in software or in hardware. The Ardupilot uses the MEMS accelerometers and gyros, that are read in software. The IMU is implemented in software. Direction Cosine Matrix (DCM) approach DCM is a sensor fusion algorithm to estimate the attitude of a rigid body in 3D space using multiple sensors. It is an alternative to the Kalman filter approach that faces complexity in implementation and high computational load. In this algorithm, the translation from the earth frame of reference to the body frame is captured as a 3x3 matrix, also referred to as the DCM-matrix. The orientation kinematics deals with calculation of the relative orientation of a body relative to a global or earth coordinate systems. It is thus, useful to attach a coordinate system to our body frame and refer to it as Oxyz. The other one is attached to our global frame and we refer to it as call OXYZ, Figure 8.2. It is assumed that during calibration (i.e. when the quadcopter is kept still), both the global and the body frames of reference have the same fixed origin at O.
Figure 8.2: i, j, k are unity vectors co-directional with the body frame x, y, and z axes. Oxyz represents the body and OXYZ represent the global frame. During flight, the data from the sensors is used to estimate how body frame moved relative to the global frame [33]. The gyros are used as the primary source of orientation information. It is important to note, that the gyros are prone to a phenomena called gyro drift due to the integration of the sensor values estimated over time and result in numerical errors. Accelerometers on the other hand, have no drift. A feedback loop mechanism is used with gyros, accelerometers and compass with a PI (Proportional-Integral) controller to determine the orientation of the
86
body in 3D space. The end goal being able to estimate the pitch, roll and yaw angles using this algorithm. The gyros and accelerometers when used together are found to sufficiently diminish the gyro drift on its 3-axis to less than 2 degree/ minute, due to the feedback mechanism that is employed in DCM. Further, the use of compass and GPS that provide a reference for the yaw, eliminates this drift almost entirely. From the 9 elements of DCM matrix, the three angles of orientation of the quadcopter may be determined as: θ or PITCH = -atan2(dcmMatrix[6],dcmMatrix[8]) φ or ROLL = atan2(dcmMatrix[7], dcmMatrix[8]) ψ or YAW = atan2(dcmMatrix[3], dcmMatrix[0]) The interested reader can refer to DCM algorithm in [34], for derivations of these equations. A DCM-based algorithm is included in most open source multicopter firmwares.
8.3
Quadcopter configuration
Figure 8.3 shows four rotors placed in a square shaped form. The rotors next to each other spin in the opposite direction to maintain the inherent stability of the quadcopter. The four rotors work together to provide an upward thrust such that each rotor provides enough thrust to lift 1 4 of the quad’s weight. The movement of the quadcopter is controlled by varying the relative thrusts of each of these four rotors to provide the lateral movement (pitch and roll) and change in direction (yaw), as discussed in Section 8.1.
Figure 8.3: Pitch, roll and yaw rotations are produced by varying the speed of the rotors in the two configurations. Yaw rotation is indicated only for ’+’ configuration. Depending on the orientation of the rotors with respect to the body coordinate system, there are two basic types of quadcopter configurations: plus and cross configurations as shown in Figure 8.3. • In the plus configuration, a pair of rotors spinning in the same direction are placed in the x and y directions, respectively. With this configuration, it is easier to control the aircraft, as each movement requires the controller to adjust the speeds of two rotors placed in the desired direction [35, Sec 2.3]. For example, to tilt or pitch forward, the motor 4 increases its thrust while decreasing the thrust of motor 3 providing a lean angle towards the front. 87
• The cross configuration, on the other hand, requires all four rotors to vary their rotation speed for any movement. For instance, to pitch or tilt forward, motors 2 and 4 provide an upward thrust while reducing simultaneously, the thrust of motors 1 and 3. Although the control system looks more complex, the cross configuration brings along an important advantage. The yaw rotation is the vehicle’s rotation about the center of mass. Yaw is induced by unbalanced aerodynamic torques. The quadcopter consists of opposite pair of rotors rotating Clockwise (CW) and Counter Clockwise (CCW), respectively; see Figure 8.3. The aerodynamic torque of one rotor pair cancels out the torque created by the second pair of rotors which rotates in the opposite direction. If all the four rotors apply an equal thrust, the quadcopter will stay pointing towards the same direction by effectively cancelling out the rotation torque. It is necessary to understand that the amount of torque required to rotate the aircraft is very similar for both configurations. A quadcopter with a payload, is less likely to reach its saturation (peak current usage), when using a cross configuration. In a cross configuration, for change in direction (or yaw) all four rotors change their speed in contrast to a plus configuration where only two rotor blades are used by doubling the amount speed change. Therefore, changing the speed of each rotor by a small amount is, as opposed to changing only two rotors speed at double the amount would keep the system safe from reaching the saturation point [35].
8.4
Software architecture
Figure 8.4 shows the software architecture of the multicopter with a functional block diagram. The same architecture applies to all designs of a multicopter. The various blocks are explained as under: • Read inertial sensors The input to this block are the 3-axis accelerometers and gyroscopes, respectively. The MEMS sensors integrates these two sensors on a single chip, described in Chapter 7. The raw values read from each of the sensors are used by the sensor fusion algorithm. • AHRS (Attitude and Heading Reference System) The AHRS receives the input from the Inertial sensor block, the 3-axis compass, GPS ground course and the barometer sensor. The GPS ground course helps in estimating the true north, measured in degrees. The values from all these sensors are combined in the sensor fusion algorithm to determine the attitude or true orientation of the aircraft (or quadcopter). The AHRS in general, forms the backbone of any navigation software. Many other advanced functionalities exist such as estimation of the navigation airspeed and GPS ground velocity that are used as part of the algorithm, not discussed in this thesis. • Altitude controller : The altitude controller receives inputs from the barometer and sonar sensors to estimate the altitude. It runs a closed loop feedback mechanism to minimize the error between the current and desired altitude. • Hover controller The hover controller primarily uses GPS sensor to obtain the latitude and longitude (x and y axis), amongst other parameters. The altitude (z − axis) is determined by the altitude controller, that is fed to this block. This forms the basis of autonomous hover, where a closed loop control feedback loop is used to minimize the error in the 3D position.
88
• WP navigation The foundation of the Waypoint (WP) navigation block is the hover controller. This takes the list of waypoints that the aircraft is instructed to navigate to, from the EEPROM (Electrically Erasable Programmable Read-Only Memory) memory. The user provides the waypoints via a GUI software, available to some open-source platforms. The AUTO mode is triggered from the RC transmitter to switch from a manual control to autonomous waypoint navigation.
Figure 8.4: An overview of the software architecture with hover and navigation control. The hover controller is used as a backbone for waypoint navigation.
8.5
Modes of operation
Figure 8.5 illustrates the description of the RC controller with six functionalities, namely, Channel 1-4 (Roll, pitch, yaw and thrust), Channel 5 (A three-position mode switch) and Channel 6 (controller tuning knob). The Channel 5 is used as a position mode switch. It has three positions, low, medium and high, is used to switch between the MANUAL mode, HOVER mode and AUTO mode of control. The MANUAL mode is a user control mode, where the user navigates the aircraft himself. The HOVER is the autonomous mode, that uses GPS for its position correction. The AUTO mode triggers the autonomous navigation of waypoints. The list of waypoints are read from memory and the aircraft navigates to the planned waypoints. The user can intervene at any point in time, by switching back to the MANUAL mode of operation, as a safety measure. The transmitter offers a total of nine different functionalities represented as 9 unique channels. However, for our purpose, we make use of only 6 channels. 89
Figure 8.5: The RC controller displays the different controls available in terms of switches and knobs. The mode is changed via the 3-position switch.
8.6
Flight configuration
In order to develop a multicopter that offers an expected behaviour, correct components require to be chosen along with the use of a stable software. The selection of components is described in Chapter 7. When the open-source software is built on the chosen flight controller, most often, does not lead to an expected flight behaviour. Often, changes are required to be done in software and certain procedure needs to be followed to make the multicopter behave as desired. The most important steps followed in almost all multicopter designs are listed below. 1. Accelerometer calibration The accelerometer calibration is performed to calibrate the 3-axis of the accelerometer sensor. This is an essential one-time step that tells the flight controller where each of the three axes point to. The flight controller must be placed on a plane surface when the accelerometer is calibrated and must be kept away from vibrations. This procedure determines the global frame of reference that is later used in flight as a reference for stabilization algorithm, refer to Section 8.1 on mathematical model of quadcopter. 2. Flight controller tuning There are various controllers defined in software. The most essential are the rate controller, hover controller (also referred to as the loiter controller, in ArduPilot open-source platform) and navigation controller. Each controller attempts to minimize a given error created within its controller loop. The controller forces the output to become closer to the input value, in the earliest possible time. In controller references, the P, I and D gain terms define the controller response. A mathematical representation of the relation between input and output of a basic closed loop controller is given by its transfer function u(t), see equation 8.6. The closed loop controller attempts to make the response of a non-linear system linear.
u(t) = Kp e(t) + Ki
Z
0
90
t
e(t) dt + Kd
d e(t) dt
(8.6)
(a) The GUI provided by the ArduPilot open-source platform for modifying the controller parameters.
(b) On-bench setup for controller tuning.
Figure 8.6: Illustration of steps taken for controller tuning. The Proportional, P depends on the present error, Integral, I on the accumulation of past errors, and Derivative, D is a prediction of future errors, based on the current rate of change. Figure 8.6a shows the parameters used for controller tuning. A lousy PID tuning of the controller can lead to the quadcopter going astray during actual flight. The PID setting highly depends on the thrust to weight ratio of the quadcopter. Figure 8.6b displays the on-bench setup during the controller tuning process. The reference to only two of the controllers are discussed below. (a) Rate controller : The P-I-D gains of the Rate controller relates to the stabilization characteristics of the quadcopter, on its three primary axes. Each of the gains in Rate Pitch, Rate Roll and Rate Yaw are tuned to make the quadcopter responsive on its three axes. This controller does not use GPS. The values of the P, I, and D usually remain in the range of 0.000 to 0.6000. The values determined after tuning are indicated in Figure 8.6a. The Rate controller gains can be tuned in flight using the transmitter’s CH6 knob. For more information, please refer to Tuning section in [7]. (b) Rate Loiter controller : The loiter or hover controller uses the GPS. It computes the error between the desired 3D location (latitude, longitude, altitude) against the computed location from the GPS. The tuning of this controller determines how well 91
the quadcopter tracks its desired position. The response of the hover controller also depends on the number of visible satellites.
92
Chapter 9
Performance Analysis and Improvements In order to perform successful networking transactions by hovering, it is desired that the multicopter presents stable hover characteristics. This chapter discusses several techniques that are researched to improve the hovering precision of the multicopter. The Section 9.1 discusses the measures taken to improve the stability of the platform. The tests performed during actual hover are illustrated in 9.2. The energy consumed by the MANET networking protocol run on the embedded systems is analysed in Section 9.3. In addition, thrust tests conducted to measure the amount of power consumed for hovering is also discussed. This leads us to estimate to flight time achievable with our design for performing networking tasks.
9.1
Measures to improve stability
1. Reduction in vibrations: Accelerometers are prone to noise due to external vibrations. The accelerometers are used in sensor fusion algorithm to estimate the attitude or orientation of the flying vehicles. The spinning motors induce vibrations on the air frame that eventually reach the accelerometer. Further, the wind affects the stability of the system as well. When the accelerometer readings are noisy, it affects the attitude estimation adversely.
Figure 9.1: Application of double layered anti-vibration foam pads. Each pad measures 1.5 cm in thickness. During a hover, the GPS velocity readings received from the satellites is used to determine the acceleration of the vehicle (acceleration is determined by taking the derivative of GPS 93
(a) Accelerometer (x,y,z) reading before vibration damping
(b) Accelerometer (x,y,z) reading after vibration damping
Figure 9.2: The 3-axis accelerometer data recorded during hover. velocity over time). The readings from the X and Y axes of the 3-axis accelerometer are compared with the acceleration as determined by the GPS, to compute the average acceleration. When the accelerometer is noisy, this affects the GPS position accuracy. With increased noise on accelerometers, results in increase in multicopter vibrations. This in turn results in inaccurate hovering characteristics and slightly higher power consumption (due to non-linear surge of power for stabilization). As part of this research, various methods have been tried to reduce the noise on the accelerometers. The idea is to isolate the accelerometer from high frequency vibrations, but conduct the lower frequency vibrations that might represent small changes in attitude. The techniques such as application of moon gel1 , rubber dampeners and anti-vibration foam pads are used. The best results are obtained using two consecutive layers of antivibration foam pads applied below the surface of the flight controller, see Figure 9.1. The 1
Moongel is a translucent sticky, gel-like substance used for vibration damping
94
results without and with the double-layered anti-vibration foam pads are shown in Figure 9.2a and Figure 9.2b, respectively. 2. Controller tuning: The controller tuning is introduced in Chapter 8. The controller tuning plays an essential role in stability of the multicopter. In order for the aerial platform to react swiftly to external disturbances, the controller gains must be chosen wisely. Figure 9.3 shows the controller’s response to the Roll axis. The data is logged at 10 Hz and the tests are conducted outdoors. The wind speed recorded during this test is 11 kmph. The steady state error obtained is approx. 2 degrees. The PID gains for the roll axis are found to be (0.13, 0.13, 0.0090), refer to Section 8.6 in Chapter 8. The pitch and yaw axis (not shown) are tuned similarly.
Figure 9.3: Result of controller tuning for roll axis. The controller output tries to converge to its input. 3. Magnetic interference on compass: The on-board compass provides an absolute reference for rotation of the aircraft with respect to the earth’s magnetic field. Thus, it is an essential sensor component for attitude estimation. The drawback is that the compass is susceptible to the magnetic interference created from the power-distribution-board, wires, ESC, motors and power source. This is one of the major drawbacks using a compass on any typical multicopter. With this in mind, the first step that is taken is to interface an external compass instead of using the on-board compass that the ArduPilot flight controller already provides. As a general practice, the compass is kept as far away from the sources of magnetic interference. As the second step, a few layers of aluminium foil are placed directly under the flight controller to minimize the magnetic field interference from the power distribution board, see Figure 9.4.
95
Figure 9.4: Use of Aluminium foil minimize the magnetic interference on compass. It is noticed that the magnetic interference on compass is directly proportional to the current drawn by the motors. The interference is linear with current drawn but not perfectly linear with throttle. A test is conducted to see the effect the throttle has on compass readings, shown in Figure 9.5. The figure shows a linear deviation of Z-component of compass with throttle. An available algorithm for compensation of magnetic field on compass is taken from the open-source platform, [7]. The algorithm computes the offsets for x, y and z components of the compass based on the static throttle tests. The static throttle tests are conducted (on ground) by varying the throttle values to determine the offsets required for the three axes. These offsets are saved in the EEPROM memory. During the actual flight, these offsets are added to the compass readings based on throttle required to hover. These offsets compensate for the change in compass readings due to magnetic interferences.
Figure 9.5: An near-linear deviation of compass with increasing throttle. 4. Barometer sensitivity to light: The barometric pressure (MS5611 sensor) on the flight controller is used to determine the altitude of the hovering platform. The datasheet for some of the popular pressure sensors indicate sensitivity to light, an example is Model 092 barometric pressure sensor, found in [36]. It is found that the MS5611 sensor is no different and is also sensitive to light. This came as a surprise since this behaviour is not indicated in its datasheet [37]. Tests conducted with simple torchlight on and off, on the pressure sensor chip indicates 96
drastic change in altitude readings. This behaviour lead to unexpected jumps in the quadcopter when it was flown at different times of the day. When this chip is covered with a black foam, the jumps vanished as the chip is now protected against direct sunlight.
9.2
Hover tests
After the measures taken to improve the stability of the hovering platform, tests are conducted outdoors. Figure 9.6 displays the autonomous hovering of the quadcopter. When one of the switches of the RC transmitter is switched high, the quadcopter goes into the autonomous hovering state. The hover test is conducted at 6 m, with a recorded windspeed of 8 kmph. The real-time data is logged onto the dataflash memory of the flight controller at a frequency of 20 Hz. It is seen from the figure, when the throttle input (marked red) is kept constant, the controller adjusts the thrust applied to the motors. The smooth line (indicated by blue) shows the platform is very well stabilized in the hover mode. A sub-meter hovering precision is obtained with 8 visible GPS satellites. The number of satellites visible are seen to vary from 7 to 14 during the day, over the Netherlands.
Figure 9.6: Test to verify the stability of the platform in autonomous hovering mode. Figure 9.7 illustrates another example of the flight tests with wind speeds of 18 kmph. The throttle output (marked as green) is adjusted rapidly to cope up with sudden bursts of wind. The reader should note that the throttle output also changes to compensate for the roll, pitch or yaw variation. For instance, when the wind from one direction pushes against the hovering platform, the motors are given an appropriate thrust. This thrust is directed in such a way so as to keep the hovering platform’s position intact. The effect of wind burst is clearly seen from the graph. There are only certain instances where the roll, pitch variations are seen, that translate to the output throttle to the motors. Also, it is seen that over a time duration of 3.5 minutes of recording, there is no visible yaw drift (marked in black). These tests are a direct indication of the stability achieved with the hovering platform.
97
Figure 9.7: Hovering test in a windspeed of 18 kmph. The graph shows the attitude and thrust variations.
9.3
Power consumption tests
This section studies the power consumption by the networking hardware and the aerial vehicle, separately. This analysis is essential to estimate the impact the networking will have on the overall flight time after integration with the aerial platform.
9.3.1
Power consumed by networking hardware
The reasons for selection of the OLSR protocol were discussed in section 4.5, Chapter 4. OLSR is preferred in terms of quick route discovery and greater throughput. To test the power consumption for a node in MANET, test is conducted with a Raspberry Pi hardware running OLSR protocol, with an external energy source. The energy source used is a 5V, 2600mAh Lithium-Ion battery. The wireless adapter used is TP-Link WN722n. The energy consumed by running the respective routing protocol is directly proportional to the average power dissipated by the hardware for handling the network load.
Figure 9.8: Raspberry Pi running OLSR actively, with an external power source. With the battery fully charged, data was continuously logged to a file using a script to keep 98
track of the time. When the battery is emptied, the last time logged is noted. It is seen that with the OLSR proactive protocol, the battery lasted for 2 hours and 46 minutes. We compute the power dissipated using the following benchmark: • Nominal voltage: 5V • Battery current: 2600mAh • Energy (in Watt-hours): 13 Wh 13Wh is consumed by the Raspberry Pi running for 2.77 hours, thus energy required by it is ≈ 4.7W h. In other words, it consumes 4.7W of continuous power every hour. Without the OLSR running, the Raspberry pi consumes ≈ 3.5W h of energy. This leads us to a 1.2 Wh estimate by the protocol alone. The power consumed by the camera is not considered as it is used only at specific instances, when required. As per the specifications, it requires 250 mA to operate.
9.3.2
Power consumed by aerial vehicle
A flying vehicle, such as a mid-sized quadcopter built in this project, uses the following configuration for its energy source: • Nominal voltage: 11.1V • Battery current: 5000mAh • Energy (in Watt-hours): 55 Wh
Figure 9.9: Test conducted to determine the power required for hovering. An experiment is conducted to estimate the amount of power required by the quadcopter to start hovering. The quadcopter design incorporates 850 kV motors, 10-inch propellers and weighs approx. 1.5 kg. With this experiment, a watt-meter is used, connected between the battery source and the quadcopter’s power distribution unit. The watt-meter measures the amount of current drawn, remaining battery voltage and the power consumed by the quadcopter. These experiments impart the knowledge of the take-off power for the vehicle and amount of time it is expected to hover in air. Figure 9.9 displays a test conducted for current draw against the power consumed by the quadcopter. The test reveals that the quadcopter starts hovering (at approx. 0.5 meter) with 19 A of current. The remaining battery voltage is measured at 12.3 V, during this experiment. This directly indicates that the power required to hover is approx. 235 W. It can also be
99
reasoned out that hovering would lead to a better flight performance in terms of the flight time than flying. Flying leads to non-linear increase and decrease of current leading to more stress on the battery. The current slowly increases as the voltage decreases to maintain a constant power output. The tests reveal that the power consumed for hovering is an important consideration for performing networking tasks. More power drawn indicates less flight times and thus, the inability to perform tasks for a long duration of time. It is observed that our quadcopter consumes ≈ 235W of power for hovering alone (measured using a Watt-meter, indoors); can hover for 14 minutes continuously consuming 235W h, before draining the energy source. It can be well understood that energy consumed by using the networking hardware (with OLSR proactive protocol) does not significantly affect the hovering time. For micro-UAVs however, the study of energy consumption using different routing protocols and consideration of the weight of the hardware may prove more useful in their objective selection.
100
Chapter 10
Aerial Network Protocol This chapter introduces the aerial-network protocol that closely interacts with the flight controller to accomplish tasks at a given waypoint. The chapter is divided into three main sections. The network stack extension is presented in Section 10.1. In Section 10.2, the background of the aerial-network protocol and its purpose is detailed. The various components of this protocol along with its working is described in Section 10.3.
10.1
Extended network stack
Similar to how the DTN is introduced over the transport layer protocol (layer 4) in the TCP/IP network stack, the aerial-network protocol is designed on top of the DTN layer (layer 5). The aerial-network protocol is designed to handle the bi-directional communication between the flight controller and the networking hardware. In addition, it brings together the implementation of existing and the developed DTN extensions, addresses a robust bundle management system and forwarding strategy, and listens to service requests from other nodes in the mesh network. Figure 10.1 shows the various protocols in the extended network stack. The layer 3, Network (IP) runs the OLSR protocol; layer 5, runs the DTN protocol and the aerial-network protocol runs on a layer above it.
Figure 10.1: Extended TCP/IP network stack.
10.2
Background of the protocol
The idea behind the aerial-network protocol is to bring together the concepts discussed so far, in Chapter 4 on MANET protocols, the DTN protocol in Chapter 5 and the multicopter software
101
discussed in Chapter 8. In other words, the aerial vehicle acts as a mobile router with the ability to store and forward data and adjust its navigation behaviour based on the networking parameters. All nodes in the mesh network use the same network stack, as seen in Figure 10.1. The purpose of the aerial-network protocol is to receive requests from other nodes in the network and service them. In addition, data is forwarded to or requested from the other nodes in the network. In summary, it functions as a publish all, subscribe network where nodes publish all information available to the network and the ones interested in a specific information can request the data. The publish and subscribe service is provided for data files such as photos, videos or text messages that need to be forwarded from one place to the other, over unreliable networks, irrespective of distance.
Figure 10.2: Illustrates the role a (static or mobile) node during network transactions, at a waypoint. Figure 10.2 shows the roles taken up by a node in the mesh network. Each node simultaneously assumes the role of a data receiver by listening to other nodes for requests and a data sender, to forward the bundles to other nodes. The following assumptions are valid for each node in the MANET: 1. Each node operates in the ad-hoc mode and is on the same wireless channel. Channel 10 is chosen, refer to Chapter 6. 2. The OLSR routing protocol is run on each node for one hop and two hop neighbour discovery. 3. Each node in the MANET is considered a DTN node. Thus, the DTN mechanism in built into every node. 4. Each node runs the aerial-network protocol.
10.3
Aerial-network protocol
On every node, the aerial-network protocol is responsible for the following operations: 1. Read the configuration file based on an XML. The XML configuration defines a node’s properties and the properties of tasks to initiate. 2. Trigger the OSLR, DTN daemons and received bundle processing. Access the internals of OLSR and DTN protocols to gather interesting network information. For the algorithm developed on ’received bundle processing’, refer to Section 5.7, in Chapter 5. 3. Initiate threads to listen to service requests from other nodes.
102
4. Initiate bi-directional communication between the flight controller and the (mobile) node. The networking hardware (Raspberry Pi) instructs the flight controller to hover, reduce its altitude based on the network parameters. Each of the points presented above are discussed below.
10.3.1
XML Configuration file
All nodes in the network, use an XML configuration file that defines certain properties of the node and the tasks required to be accomplished with other nodes during the mission. Through this configuration file, a node can be defined as either static or mobile. The XML configuration is read by each node at runtime, i.e. when the node is powered up. As an example, the XML configuration for a node is given below: pi1 v i d e o s , photos , today pi3 c r i t i c a l d a t a . mp4 , o p e r a t i o n . txt 30 t p l i n k 1 ...
pi2 mobile 8888 /home/ p i / i b r d t n ... The XML file presented above defines three tags namely, Tasks, Nodes and Accessories. An XML file is composed of tags and attributes. The various tags and attributes are explained briefly below: 103
1. Tasks tag: Three unique tasks can be defined. These are receive service (data), send data file and shoot video and forward. Each task also specifies a dependency. For instance, the task Vid1 is only initiated after the completion of task Rcv1, denoted by the depends on attribute. • Recv : Defines the service request to be issued to other nodes. These can be the request for videos and photos that have been obtained today. • Send : Defines the data that is to be sent across another node, marked as dest (destination). The data is delivered whenever the node is visible. • Video: Defines a video task that is initiated, denoted in seconds. When the videotime attribute is set to 0, a picture is taken instead of a video. Optionally, this data can be forwarded to other DTN nodes. 2. Nodes tag: List of nodes the current node expects to forward the data to. It consists of the following attributes: • name: The alias for a node, e.g. ’pi1’. • ip: The IP address of the node. This is only required when a service is requested from another node. The client (current node) contacts the server of another node in such a case. • dtnAddr : The DTN address of a node. See Section 5.5 in Chapter 5. • WaypointId : This property is used only for the node that is defined as a mobile, i.e. for the aerial vehicle. An ID is associated with a node’s location. For e.g., in a mission with three waypoints, the static node’s placement can be identified with an ID. 3. Accessories tag: The properties that each node uses internally, in its algorithm. • CurrentNode: The alias for the current node, e.g. ’pi2’. • NodeKind : The type of the current node. It can either be a static or a mobile node. For waypoint navigation, one of the nodes is defined to be mobile whereas other nodes use the static properties for this attribute. • Storage path: The storage path for the received or transmitted data (bundles). • ACK Port: Each node runs a server to service the requests issued by other nodes. It spawns a thread per client. The acknowledgement port opens up a socket for its connection. Figure 10.3 illustrates the use of the XML configuration and its interpretation. An objectoriented programming approach is used to convert the various task and node XML tags into task and node objects, respectively. The dependency block keeps track of the task objects in a queue and triggers the tasks based on its dependency. The miscellaneous accessories deal with the storage of data and other properties such as display the received data on the monitor (not shown as part of XML tags). These objects define the ’what’ part of aerial networking.
10.3.2
Query the OLSR and DTN
The OLSR and DTN daemons are triggered via a script, run on every node. The OLSR determines the one hop and two hop neighbours, whereas the DTN addresses store-and-forward of bundles between nodes.
104
Figure 10.3: Illustrates how the tasks are interpreted from the XML file. Each task, node is an object. With the help of OLSR Txtinfo plugin, discussed under Section 6.4, the OLSR is queried on its port over the localhost1 . The information returned by OLSR is filtered out to obtain the information on the ETX metric of the neighbouring node(s). The ETX metric determines the quality of connection. Based on the value of this metric, the altitude of the hovering platform is altered accordingly. The internals of DTN is queried in a similar fashion to the OLSR plugins, to determine the neighbour DTN nodes. The DTN is queried on its local port (defined in the DTN configuration file), to obtain this information as a list. This information is requested at 5 Hz and used for data logging purposes. Alongside running OLSR and DTN daemons, the received bundle processing is also run as a separate process. This process is an improvement over the DTNRecv process, discussed in Chapter 5, is an event based mechanism to manage the reception of any number of bundles received at any time. The bundles are stored systematically in the file system on reception.
10.3.3
Client server architecture
Each node simultaneously, acts as both a client and a server for data transactions. The node is a client because it issues data request to other nodes. The node is a server because it services the requests from other nodes. The server runs on each node and has a socket that is bound to a specific port number. All (service) requests coming to this port is analysed and serviced, 1
A localhost is that standard hostname given to the (current) machine itself.
105
when possible. The Algorithm 2 listed, runs as a separate background thread. It depicts the creation of a thread per client service request. The request received from a client is based on certain tags such as video, today, from pi3. Once the server receives this tag, it queries its repository based on this tag. It determines if a video has been received from the node ’pi3’, today. If the query succeeds, the required data is sent to the requesting node (the client) via DTN. Algorithm 2 Server processing Require: HOST, PORT, sock Ensure: socket sock object is initialized, HOST = ” (accept request from any IP) and PORT = 8888 (as set in XML configuration file) 1: bindToSocket(HOST, PORT) [Bind to a port] 2: sock.startlisten() [Start listening on the socket] 3: while true do 4: conn, addr = sock.accept() 5: start new thread(clientthread, conn) [Start a new thread for each client. The service request from each client is analysed and appropriate action is taken]
10.3.4
Network flight interaction
The flight controller is responsible for navigation of the aircraft from one waypoint to the other. The networking hardware, instructs the flight controller on actions the aircraft must take to successfully complete a data transaction. Figure 10.4 shows the interaction between the networking hardware (Raspberry Pi) and the flight controller. The Algorithm 3 presents the reader with the network flight interaction. The flight controller triggers an event as soon as it is reaches a radius of 5 meters around a waypoint. The networking hardware is informed of the aircraft’s arrival. If a task is found for this waypoint, the aircraft is informed to hover for a fixed time (kept as 60 seconds). During this time, the networking takes control and issues commands based on the completeness of the task back to the flight controller. The following commands are issued between the flight controller and the networking hardware. Flight controller commands The following are the commands issued by the flight controller to the networking hardware. 1. REACHED: This command is sent to the networking hardware when a waypoint is reached. The ID of the waypoint (WP ID) is also sent alongside. 2. ACK WP DONE : This command is only an acknowledgement from the flight controller, in response to the task complete command (NEXT WP). 3. TIMEOUT : The flight controller has its own timer that is run during the hover, at a waypoint. The time is set to be 5 minutes. Within this time, it is assumed that all tasks will be completed. When this timer expires, it interrupts the networking hardware to stop its current activities before it moves on to the next waypoint. 4. INTERRUPT : This command is passed to the networking hardware, whenever the user switches from the AUTO to MANUAL mode of control.
106
Figure 10.4: Illustrates the network flight interaction. The aerial-network protocol runs on the networking hardware, the Raspberry Pi. Networking hardware commands The following are the commands issued by the networking hardware to the flight controller. 1. HOVER: Requests the flight controller to hover for 60 seconds. This command is issued only once, each time a waypoint is reached, by default. 2. ADJ ALT : The navigation controller of the aircraft is informed to adjust the altitude based on the given link quality determined by OLSR. The altitude is adjusted either when a node is not found or when a node is detected but the ETX value is more than 3.0 during a data transaction. The altitude is reduced by half and is done once. The aircraft always stays 5 meters from the ground. 3. CIRCLE : If a pending task exists at the current waypoint and the task is not found in 60 seconds since its initiation, triggers the circle mode. In the circle mode, the aircraft navigates in a circular fashion around a Region of Interest (ROI), with a given radius (4 meters) and is initiated when atleast 5 meters above the ground. The circle mode is used but not fully tested. The implementation of CIRCLE mode is part of the open-source firmware. More information can be found in the Arducopter section in [7]. 4. HOVER EXT : Forces a hover extension by 15 seconds when the estimated time for the task is exceeded but the network is still busy with a transaction. 5. NEXT WP : This command instructs the flight controller to move on to the next waypoint, if there is one. This command is issued when there is no pending task, or the task is completed or the max permissible time is exceeded.
107
Algorithm 3 Network flight interaction Require: running, wp cmd, extension, done, time, max time, task started, adj alt, WP, CMD [enums] Ensure: running = true, serial object is initialized 1: readXML() [Read the XML configuration settings for this node] 2: StartDaemon() [Start the OLSR, DTN, bundle processing process] 3: listenToClients() [Initiate the server for this node] 4: while running do 5: wp cmd, wp ID ← readSerial() [Read the incoming commands] 6: if wp cmd is WP.REACHED then 7: wp busy ← true 8: task started ← initiateTasks(wp ID) [Search and initiate pending tasks] 9: start timer() 10: send Cmd(HOVER) 11: else 12: if wp cmd is WP.TIMEOUT or WP.INTERRUPT or WP.ACK WP DONE then 13: wp busy ← false extension ← 0 14: stop timer() 15: if wp busy then 16: time ← readTimeElapsed() 17: done ← checkTaskCompleted() 18: max time = transactionManager() [Give a rough estimate the time required for current task(s)] 19: logData(wp cmd, max time, wp ID) 20: if task started 6= true and time ≥ 60 then 21: send Cmd(CMD.CIRCLE) 22: task started ← initiateTasks(wp ID) 23: if done is true and time ≤ max time then 24: send Cmd(CMD.NEXT WP) 25: adj alt ← adjustAltitude() [Based on ETX metric] 26: if adj alt and time ≤ max time then 27: send Cmd(CMD.ADJ ALT) 28: if time (max time + extension*15) then 29: if extension ≤ 10 and transaction busy() then 30: send Cmd(CMD.HOVER EXT, 15) 31: extension = extension + 1 32: else 33: send Cmd(CMD.NEXT WP) 34: if not running then 35: logData(wp cmd, max time, wp ID) 36: return [In case, of an exception]
In summary, this chapter discusses the extension of the network stack with the aerial-network protocol. It is shown how the network transaction is carried out with other nodes with the help of MANET, DTN protocols and its extensions such as with the use of ETX quality metric. In the mesh network, one mobile node along with other static nodes are used. The next Chapter 11 presents the reader with the concept of waypoint navigation, scenarios and the results.
108
Chapter 11
Waypoint Networking This chapter presents the application of the concepts discussed in this thesis. Tests are conducted outdoors with a number of static nodes and a mobile node. All nodes are part of the same mesh network. The static nodes are placed at a distance from each other such that each creates isolated regions of network. These nodes are placed at certain strategic locations as determined by the GPS coordinates. The multicopter’s flight plan is plotted on a Google map interface with these GPS coordinates, marked as waypoints. It flies to each of these waypoints, establishes a network connection with the node at this waypoint and carries out the required data transaction.
Figure 11.1: A mobile node (quadcopter) is used along with other static nodes in the MANET, during waypoint networking. The chapter starts out with an analysis of the node’s antenna orientation, Section 11.1. Tests are conducted with a mobile node that is made to hover above a static node, placed on the ground, to determine the correct antenna orientation. The change in orientation of the antenna affects the time to discover its neighbours. In Section 11.2, mission planning is discussed. Mission planning is the first step to be performed before waypoint navigation. The networking tests conducted during the mobile navigation of waypoints is presented in Section 11.3. The final section 11.4, discusses the results obtained.
11.1
ETX Measurements with antenna orientation
A classification of antennas can be based on: 109
• Frequency and size: Antennas used for HF (High frequency) are different from antennas used for VHF (Very high frequency) and antennas for microwave. Our interest lies in working in the microwave range especially 2.4 GHz range. At 2.4 GHz, the wavelength is found to be 12.5 cm. • Directivity: Antennas can be classified as omnidirectional or directional. Omnidirectional antennas radiate the same signal around the antenna in a 360◦ radiation pattern. The most popular omnidirectional antennas are the dipole or monopole. Directional antennas radiate in a specific area. The beam pattern of 120◦ , 60◦ or much narrower beam width are quite common. Directional antennas have the highest gain and therefore, are used for long distances. Table 11.1 lists the various antenna types in the two respective categories. Antenna types Omnidirectional Directional
Examples Dipole, Monopole, Collinear, Slotted waveguide Patch, Sectorial, Yagi, Biquad, Dish, Cantenna, Sectorial
Table 11.1: Various antenna types available. Usually, the wireless adapters can attach any antenna type. One of the requirements framed in this research is that the mobile node is able to hover and communicate with the static node placed below it, on the ground. The static node is placed at a waypoint that the mobile node flies to. This waypoint is based on the planned GPS coordinates. It can be understood that an omnidirectional antenna will prove more of a logical choice than a directional antenna. This enables the static node to be placed in the region around the waypoint, rather than at the exact GPS coordinates.
Antenna selection
Figure 11.2: A 4 dBi detachable wireless antenna with TP-Link WN722n wireless adapter. We use a detachable omnidirectional dipole antenna with a gain of 4dBi1 , with the TL-WN722N wireless adapter, Figure 7.15. The antenna with a higher gain is more effective in its radiation pattern. Every antenna designed raises power in the wanted direction and reduces power in unwanted directions. However, an antenna does not add additional power to the wireless adapter. This antenna can be rotated and adjusted in different directions to fit the various operation requirements. A much higher gain antenna may become detrimental to the system performance, since the mobile node must be able to have reception over a larger area. 1
For antennas, a common reference unit used is the dBi. It is the gain of an antenna with reference to a ISOTROPIC source. An Isotropic source is a perfect omnidirectional radiator and does not exist in nature.
110
Figure 11.3: The figure shows, (a) the radiation pattern of a simple omnidirectional antenna, (b) and (c) shows the 4 dBi antenna gain pattern from a vertical and horizontal plane of view.
(a) Antenna orientation vertically downwards
(b) A horizontal antenna orientation
Figure 11.4: Neighbour discovery tests performed with respect to antenna orientation. The tests are conducted between a static node placed on the ground and a mobile node hovering at a height of 5 meters. Figure 11.3(a) shows the radiation pattern with an omnidirectional antenna. Figure 11.3(b) and (c) shows the theoretical antenna pattern with a 4 dBi antenna gain. The antenna lobes in the top and bottom of the antenna are reduced as compared to the horizontal plane. 111
11.1.1
Tests with antenna orientation
Each node in the network should have the correct antenna orientation with respect to the target node. The orientation of the antenna as discussed, can adversely affect its transmission and reception range. Tests are conducted to determine how the antenna orientation affects the discovery of nodes and the estimation of the node’s link quality based on ETX metric. For this test, a static node is placed on the ground with a horizontal antenna orientation whereas, the mobile node is made to autonomously hover at a height of five meters. Figure 11.4 illustrates the two different antenna orientations tested on the mobile node and measurements made on this mobile node. A number of tests conducted convey consistently, the horizontal orientation of the antenna helps in a faster convergence to a link quality of approx. 1.8, in comparison to a vertical orientation. This can be attributed to the longer range with the omnidirectional antenna in a horizontal orientation and also verifies the theory of having a horizontal antenna orientation, see Figure 11.3.
11.2
Mission Planning
Before introducing the mission planning and waypoint navigation, we discuss the concept of hovering for data exchange, with an example. Figure 11.5, shows a mobile node hovering above a static node, placed on the ground. This scenario is similar to the one that is encountered during waypoint navigation and networking. The mobile node establishes an ad-hoc network connection and uses the Aerial-network protocol to initiate and complete the data transactions. The reader should note that this protocol can also be used without waypoint navigation by setting the NodeKind property in the XML configuration, please refer to Chapter 10.
Figure 11.5: An illustration of an indoor hovering, at Thales Nederland B.V. The mobile node exchanges data with the static node below. For outdoor navigation, some of the open-source platforms such as ArduPilot provide a GUI for planning waypoints. This GUI is called Mission Planner [7]. The Google maps interface is used by the GUI for mission planning. The waypoints can be plotted by marking points on the map, Figure 11.6. The points marked on the map are translated to a latitude and a longitude. The user can provide the altitude for each waypoint via the GUI. The (latitude, longitude and altitude) for each waypoint are then encapsulated into an object, along with other parameters and sent to the flight controller’s internal EEPROM memory via UART or telemetry. Static nodes are placed at waypoints marked Home and 3, respectively. The dotted circles 112
around waypoints Home and 3 indicate the presence of static nodes in that region (used for illustration purposes). In order to give the flight controller the knowledge of presence of a node at a waypoint, an identifier is assigned for those regions. The waypoints marked Home and 3 are sent to the flight controller, as additional parameters indicating presence of a node. This is done in order make sure that the aircraft does not keep searching for a node at each waypoint. The reader should note that waypoint 2, does not contain any static node. Thus, the aircraft does not assume a node’s presence at this waypoint.
Figure 11.6: Mission waypoint planning. Three waypoints are plotted on this map. The take off point is marked as Home.
11.3
Waypoint networking
The concept of waypoint networking is that the mobile node navigates autonomously to where the static nodes are placed. It then tries to establish connection and carry out the data transactions with the help of the various networking protocols described. The mobile node has no knowledge of which node is present where. It just knows that a node is present at a given waypoint and the task(s) for a node that require to be completed, if any. The static nodes only know their region ID’s, the waypoints where they are placed, marked as Home and 3. However, they do not know if and when a mobile node will arrive to initiate data transactions. Figure 11.7 shows one of the tested scenarios for waypoint networking. At waypoint Home, a static node (a laptop, marked ubuntu) is placed. Similarly, at waypoint 3, another static node (Raspberry Pi, marked pi1) is placed. We will call the mobile node as pi2, as it contains a Raspberry Pi node running networking algorithms. The distance between the two static node placements is approx. 40 meters. The power of the static nodes is reduced to 10 dBm, which limits the wireless range of the nodes sufficiently. This is done so that they do not see each other.
113
Tasks during the mission Table 11.2 lists the tasks performed during the mission. The size of the data file is mentioned in the last column. The size of data.jpg is already known, however the size of video file (generated in real-time during navigation) is unknown. A 30 second video footage with 15 fps with the Raspberry Pi’s camera is estimated to be approx. 11,500 KB. The time taken to transmit or receive a file is directly proportional to its size. A higher file size increases the total mission time. We try to keep the scenarios as simple as possible, in order to test the concept. Task Send data.jpg Send Video.mp4
Sender node ubuntu pi2
Target node pi1 ubuntu
Waypoint 2
Data size 172 KB ≈11,500 KB
Table 11.2: The list of tasks performed during the mission. The task defined by the static node ubuntu is given below. The target node is defined to be pi1, located at waypoint 3. It should be clear by now, that the two networks created by static node ubuntu and static node pi1, cannot see each other. The only way is to transport the data via another node that passes by. We use DTN epidemic routing on all nodes to spread the bundles across to other nodes in the vicinity. This increases the probability that the data eventually reaches its destination. pi1 data . jpg The task defined by the mobile node pi2 is given below. This task states that a video must be taken for 30 seconds at waypoint 2. The video footage obtained will be forwarded to the node ’ubuntu’, whenever it is visible in future. The name for the video, Video.mp4, is shown only for illustration. The name for the video is automatically generated through software and the video remains stored in the repository until it is delivered to its target node. 30 2 ubuntu 1. The multicopter takes off from waypoint Home. 2. Hovers in this region at a default height of 15 meters (defined during the mission waypoint planning). The mobile node has the knowledge that a node is placed at this waypoint. It tries to first establish a connection with the static node. If a connection is not established, the altitude is lowered by half (7.5 meters, in this case). The ETX metric (link quality) is continuously determined to notify the action to be taken for adjusting the altitude, in case the node is not found. If the node is still not found within a given duration, the CIRCLE mode is initiated (i.e. if above 5 meters), in which the mobile node traverses 114
around the waypoint region with a (4 meter radius) to determine the static node. After a given timeout, if a connection is still not established, the mobile node navigates the next mission waypoint. The CIRCLE mode is part of the open-source software algorithm that has been used in the flight controller [7]. For more information on working of the Aerial-network protocol, please consult Chapter 10. If the data transaction is successful, the data meant for node pi1 is received by the mobile node, through DTN’s epidemic routing. 3. Travel to waypoint 2, and take a video footage. 4. Travel to the next waypoint 3, and send the data (data.jpg) meant for node pi1, if available. 5. Return to the where it started from. When the mobile node returns to its home location, it forwards the video previously taken at waypoint 2 to node ubuntu. 6. The mobile node lands itself safely. More complicated scenarios can be generated by using XML configuration with more nodes in the network, please refer to Chapter 10.
Figure 11.7: The scenario tested during waypoint navigation. A total of three waypoints are planned.
11.4
Results
The Figure 11.8 shows the measurement of link quality (ETX metric) as determined by the mobile node. This is the result with the experiment of the waypoint navigation and networking, discussed in this chapter. The figure is sufficiently annotated for the reader to understand. The sudden disappearance of the ETX measurement in the figure, indicates the multicopter going out of range of the networking zone. The interpretation of the results are as follows: 1. The multicopter (mobile node) is started at time 0. At this time, the OLSR is triggered and takes time to bring down the ETX value. The mobile node takes off at the 13th second. There is a slight glitch in the ETX parameter since the mobile node flies upwards and worsens the link quality temporarily. The static node is already active and tries to
115
Figure 11.8: Measured link quality (ETX) during the waypoint network navigation. send the data.jpg file to the mobile node as soon as the network allows. The mobile node receives this file at approx. 25th second. 2. At waypoint 2, the video is triggered by the camera and the footage is taken as planned, for 30 seconds. 3. The mobile node navigates to waypoint 3 where it completes the transaction and transfers the file data.jpg, in a short duration. 4. The mobile node now travels back to the base, waypoint Home, where it is expected to transfer the video footage taken at waypoint 2. It gets interesting at approx. 110th second, where the node encounters a poor link quality. The mobile node descends down by reducing its altitude by half. It waits to gain a better link quality. It is seen that to transfer a video file from a height of 7.5 m, it took approx. 122 seconds to complete. The results present an objective analysis of the success of the transactions with the designed algorithms. The files are received by its respective nodes, shows the working concept of DTN with the application of mobile nodes in MANETs. The ETX measurements are carried out on the mobile node and gives us sufficient information on the behaviour during network navigation. The tests are conducted with a horizontal antenna orientation.
116
Chapter 12
Analysis of Interferences In this research, the multicopter integrates several on board wireless devices each serving a different purpose. All these devices, as per wireless regulations, require to operate in a narrow band of frequencies. The on-board wireless devices all being active at the same time, can be a potential cause of mutual interference or interference with surrounding wireless devices in the environment. The result of this interference can be dangerous and can lead to indeterministic navigation characteristics that is hard to debug and resolve. This chapter studies the operating frequency of each of these devices, discusses the interference problems faced and suggests methods incorporated to mitigate these interference effects.
12.1
Wireless devices on multicopter
Each of the devices listed below are present on the multicopter.
Figure 12.1: The four wireless devices used on our multicopter. Top left: TP-Link WiFi (2.4 GHz); top right: 3DR telemetry (900 MHz); bottom left: FlySky RC receiver (2.4 GHz); bottom right: u-blox GPS receiver (1.575 GHz). 1. RC receiver operates at 2.4 GHz for receiving (manual) control signals from the hand held user transmitter. The RC receiver also receives the command to switch to autonomous mode from manual control, and vice-versa. 2. WiFi wireless adapter runs at 2.4 GHz as per 802.11 b/g/n standards. This module is used for communication with other nodes in the mesh network (in ad-hoc mode).
117
3. Telemetry operates at 433 MHz as per EU standards. This device is used for long distance (upto 1 mile) directional communication between the GCS and the multicopter. The GCS is the software that runs on a laptop, tablet or mobile phone to stream real-time data from the multicopter and issues commands during flight. 4. GPS receiver operates at its carrier frequency of 1.575 GHz. GPS receivers are sensitive devices with received power of approx. 10−18 W. In general, it is a practice to use an RC receiver on all multicopters. The GPS is an accessory that assists in autonomous navigation. The telemetry is not mandatory, it is used to establish a two-way communication between the multicopter and GCS to keep track of the vehicle during navigation. The WiFi on the other hand, is used for networking. Figure 12.1 shows the four devices used on board. Each of these devices emit and/or receive electromagnetic (EM) waves in their designated frequencies. The powerful emissions from these devices can create electromagnetic interference and degrade performance of other sensitive wireless devices operating at nearby frequencies. The challenge is to study the possible interferences that can be created when using all these devices at the same time. Also, it is a good practice to narrow down on potential problems as much as possible before the actual flight.
12.2
Understanding power scale
All wireless devices operate around their center frequency having certain power. An interference occurs when different signals at same or nearby frequencies interference with each other. A high Signal-to-noise ratio (SNR) for a signal is desirable, to minimize this interference. It is essential to understand the power scale when studying wireless interferences. The power as we know is measured in Watt (W). When measuring radio frequency, or RF power, it is often easier to measure the power level as comparison between two levels. Decibel (dB) is the unit used to express relative differences in signal strength whereas, dBm or decibel-milliwatt is the power measured in decibels relative to 1 milliwatt (mW). The relation of dBm to watts is given by: Power in mW dBm = dB milliwatt = 10 x log10 1 mW The RF equipments including signal generators and spectrum analysers have calibrations in dBm or dBW. The power level measured for usual applications varies in the range of megawatts (106 watts or 100 dBm) for radar applications to attowatts (10−18 watts or approx. -130dBm), the received power in GPS receivers. The Table 12.1 summarizes the power level encountered in various applications we see from day to day life.
118
dBm level 100 dBm 80 dBm 60 dBm 30 dBm
Power 10 Megawatts 100 kilowatts 1 kilowatt 1 watt
20 dBm
100 milliwatts
0 dBm -20 dBm -30 dBm -60 dBm
1 milliwatt 10 microwatts 1 microwatt 1 nanowatt
-80 dBm
1 picowatt
-111 dBm
8 femtowatt
-127 dBm
127 attowatt
Encountered In Power used in radar transmissions. This can cause serious injury Typical transmission power of FM radio station (50-km radius) Combined radiated RF power of microwave oven elements Typical RF leakage from a microwave oven, (maximum) power radiated from an amateur RC transmitter Maximum radiated power for IEEE 802.11b/g wireless modules in the 2.4 GHz (e.g. WiFi wireless adapter) Bluetooth standard (Class 3) radio, 1 m range Observed maximum received signal power of wireless networks The Earth receives one nanowatt per square metre from galactic stars of defined magnitude Maximum radiation allowed by regulations is in the range of (-60 to -80 dBm) [38] Thermal noise floor for commercial GPS single channel signal bandwidth (2 MHz) Typical received signal power from a GPS satellite
Table 12.1: Power level in dBm and its applications. Source: [Wiki] reference, as on 20-Dec, ’13 Some considerations From the table above, it can be inferred that in the 2.4 GHz band we use two on board wireless devices. The RC transmitter radiates power upto 30 dBm whereas, the WiFi wireless adapter radiates power upto 20 dBm. The power radiated by an RC transmitter can be upto 10 times greater than that of the WiFi device. If both these devices were to operate in the same channel (or sub frequency within 2.4 GHz spectrum), the SNR of the WiFi signal would drop down considerably. The signal strength is also affected with distance. The reverse effect, i.e. WiFi affecting the transmitter’s signal can occur, when the multicopter’s distance results in a drop in received transmitter signal strength. The telemetry operates in the 900 MHz frequency band. As there are no other device on board to interfere at this frequency, this should not be a cause of concern. An interesting problem encountered during this research is the interference of the Raspberry Pi camera with the GPS receiver. This problem is dealt with in Section 12.3.2. In the following sections, we focus on the study of 2.4 GHz band devices and the 1.575 GHz band, where the GPS receiver operates.
12.3
Frequency bands
12.3.1
2.4 GHz spectrum
As per the 802.11 standard, the 2.4 GHz band uses radio frequencies in the range of 2.412 2.484 GHz. The standard splits up this band into a set of 13 unique channels numbered 1-14. Each of these channels are spaced 5 MHz apart in the 2.4 GHz range. Please refer to the section on channel selection in Chapter 6. The multicopter in this research, operates two devices in the same 2.4 GHz spectrum. One is the 119
WiFi wireless adapter operating on a designated channel as per our ad-hoc mode configuration. The other device operating in the same band, is the RC receiver that receives control signals from a remote hand held RC transmitter. Precaution must be taken against interference while operating these two devices together in a small enclosed space. In the initial stages, a low cost transmitter available locally was used for testing. While using both WiFi and RC receiver, resulted in intermittent reset of the hand held RC transmitter. The reason at first, was not apparent, but a close analysis revealed the problem being the interference between the two. Once the problem was clear that it occurred due to the use of both devices together on board, solution had to be found to mitigate this unwanted effect. To minimize the probability of interference on this band there are two possible options: • Choose a different channel on which WiFi module operates in order to avoid interference with the RC receiver. • Find a transmitter with suitable modulation scheme such that it minimizes the probability of interference. Selection of a suitable channel for the WiFi would in turn require to determine the channel the RC transmitter operates on. The radio controlled transmitters often operates on a wide band of spectrum. Attempt was made to change the WiFi channel used. However, this solution could not be relied upon as interference still occurred, although less frequently. Moreover, the transmitter that is used initially (not shown) had an internal transmitter module and lacked the external connector for testing the frequency via spectrum analyser. Another solution is to find an appropriate transmitter with a robust modulation scheme and incorporates techniques to avoid interference. The next section discusses this selection. Finding the right transmitter There are various transmitters available on the market nowadays for a similar price range. The RC systems operating in the 2.4 GHz spectrum work on a wide-band of radio spectrum with a minimum of 1 MHz channel spacing. This is in contrast to to traditional narrow-band RC systems, that operated between 27-72 MHz range with a 20 kHz channel spacing. In practice, the narrow band signal is relatively easy to jam or intercepted as compared to wider band signal. Multiple devices simultaneously operating in the same narrow-band will result in interference and cause glitches or lock-outs. Typically, the RC transmitters operating in the 2.4 GHz band use the Spread Spectrum(SS) technology as a modulation scheme. Spread spectrum is a form of wireless communication where the frequency of the transmitted signal is varied deliberately and/or the signal is spread out over a larger portion of the radio frequency spectrum than strictly necessary. This makes the signal more resistant to radio noise and interference. It takes up more space but this allows for redundancy in data transmission. Moreover, the interference is allowed to affect a portion of this spectrum while still succeeding in successful transmission. There are two variants of spread spectrum used for digital signal transmission over the airwaves, in different transmitters: • Direct Sequence Spread Spectrum (DSSS): In DSSS, the signal transmitted takes up more bandwidth that the information signal that modulates the carrier (or broadcast) frequency. Each DSSS channel bandwidth is approx. 22 MHz wide and the information is thus, spread across the entire bandwidth in this 2.4 GHz channel. This prevents interference from blocking out the entire signal. 120
The DSSS makes the transmitter use wide spread of frequencies to send data to the receiver. A DSSS system will not be affected adversely, when the strength of the WiFi interferes with it. It can be argued that the WiFi signal may only block a small portion of the signal being sent. At least, some of the signal from the transmitter will get through to deliver the control inputs to the receiver on board. • Frequency Hopping Spread Spectrum (FHSS): In An FHSS system involves the transmitter and receiver to constantly change their operating frequency within the allowed limits of the 2.4 GHz band [39]. FHSS radio systems work by constantly hopping between a number of frequencies thus, covering a whole range of channels within this band instead of having a fixed frequency. Clearly, this makes a FHSS system a difficult target for interference to hit. An FHSS based transmitter will make the right choice. Amongst the currently available 2.4 GHz spread spectrum systems, all use some form of DSSS, while others such as Spektrum/JR, Futaba FASST and FrSky DJ systems use other techniques to offer even greater protection from interference [39]. A better technology generally, also means an increased cost. The 9 Channel FlySky transmitter with FrSky DJT 2.4 Ghz module is carefully chosen for the use with the multicopter. This RC system offers a blend of DSSS and FHSS. It adds to the advantage that not only is the signal spread across the whole channel but also supports continuous hops from one channel to the other. Further, this system also supports a fail safe1 Figure 12.4 shows some tests performed with a spectrum analyser to study the wireless signal from the RC transmitter and the Raspberry Pi’s wireless adapter. In Figure 12.2a, the FrSky DJT 2.4 GHz module is presented. The 9 different PWM channels from the transmitter represent the information signal. This signal is modulated onto the 2.4 GHz carrier wave. For more information, please refer to Section 7.6 [Chp. 7]. Figures 12.2b and 12.2c shows the analysis with the spectrum analyser after connecting 2.4 GHz transmitter module via the connector. It can be seen that there are several peaks that emerge on the analyser. This is due to the frequency hop technique. The three peaks are seen together on the spectrum analyser as it is unable to keep up with the switching speed of frequencies of the RC transmitter. In practice, at any time instant, there is only one frequency hop that is initiated. The Figure 12.2d shows the 2.4 GHz signal from the wireless adapter connected to the Raspberry Pi. The analyser shows the ad-hoc device working around the assigned frequency of 2.457 GHz (channel 10). 1
A fail safe is a mechanism to take suitable action when exceptions occur. For example, when the multicopter flies beyond the range of RC transmitter signal, the receiver fail safe kicks in. In such a case, the multicopter can take relevant action such as return to origin using a GPS.
121
(a) The RC transmitter module. Modulates the (b) Testing the RC transmitter (module) signal 9 channel PWM signals onto a 2.4 GHz carrier. on a spectrum analyser.
(c) Test with the RC transmitter. Analyser shows the FHSS and DSSS in action.
(d) Test of 2.4 GHz WiFi signal.
Figure 12.2: Using a spectrum analyser to study the DSSS, FHSS of the 2.4 GHz transmitter and the 2.4 GHz WiFi signal from Raspberry Pi’s wireless adapter.
12.3.2
1.5 GHz spectrum
The satellites broadcast information on its two carrier frequencies, 1.57542 GHz and 1.2276 GHz. Only one of these is for the civilian use. The civilian carrier is 1575.42 MHz [40, Chp. 3]. A GPS receiver on earth, is used to receive signal from a number of satellites to determine its position on earth. At least three satellites are required to determine the position of the GPS receiver. The computation of a position with three satellite signals is termed as a 2D position fix (two dimensional determination of position). By receiving signals from four or more satellites, the GPS receiver is able to compute an absolute position in three dimensional space. A 3D position fix gives us the altitude above the earth’s surface, in addition to latitude and longitude. The greater the number of visible GPS satellites, the more accurate the position estimation will be. We use the u-blox GPS receiver on the multicopter. The Raspberry Pi’s camera and GPS receiver are installed on-board the multicopter. During autonomous hover, the multicopter relies on GPS for an accurate 3D position estimation. However, it was noticed that when the camera was started for a videoshoot, the multicopter started introducing bizarre behaviour and lead to several crashes, resulting in costly repairs. This problem was discovered by chance and for long, the source of this problem was not apparent as it used to happen at odd times. Determining source of the problem As the first step to narrow down the problem, the camera was triggered during manual control of the flight. It is noticed that the problem did not occur in such a case. Only in the case when 122
a hover is initiated (that uses GPS) and camera triggered during this duration, the unexpected behaviour resulted. This problem is not found in the literature and was discovered by chance. At this point, it was clear that there is an interference problem the GPS faces when using the camera. The following reasonings were made to find the source of the problem: 1. Disproportionate current draws: The camera and GPS both drew current from the same voltage regulator, that provides 3 A of current. This lead to the thought that this may minimize the current drawn by the GPS receiver, being the reason of the bizarre behaviour. After looking at the specifications of the Raspberry Pi camera, it is found that it draws 250 mA of current at 3.3 V, when triggered; specifications are found in [41]. The u-blox GPS draws upto 25 mA at 3.0 V. Thus, the assumption that the current drawn by the GPS is minimized may be incorrect. Further, measures were taken to supply current to both these devices using separate voltage regulators. It was noticed that there was no change in the behaviour and the problem reoccurred. Thus, further steps were needed to root out the cause of the problem. 2. Presence of interfering sources: Another possible reason for this behaviour is attributed to the presence of sources that emit power at frequencies used by the GPS carrier wave. However, this is difficult to confirm since this behaviour does not occur without the on-board camera. In the quest to find the source of interference, the data from the GPS is logged every second. Tests were conducted at Thales Nederland B.V. laboratory with the GPS and camera, without taking actual flight. When triggering the camera, a sudden drop of GPS satellite count resulted. This showed a visible indication of interference. Moreover, this phenomenon only occurred when the camera was oriented at a certain angle. Figure 12.3 shows the result from an actual flight where the data is logged. The sudden drop of GPS signal down to zero, around the 5th minute, resulted in sudden and bizarre flight maneuver; before triggering manual flight control to prevent further mishap. A sudden drop of GPS satellite count to zero is highly unlikely and unusual that can lead to bizarre consequences for a flying vehicle. This is a major cause of concern, especially when using GPS and camera together on board.
Figure 12.3: Data collected during actual flight. The graph shows sudden reduction of GPS satellite count at the time of camera trigger that resulted in a sudden bizarre flight behaviour. The jamming source is found to be the camera ribbon cable that acts as an antenna with a greater power near the GPS carrier frequency, overriding the GPS signal. It is also found that 123
the jamming signals are often caused by the harmonics of these spurious signals. Figure 12.4a shows the interference found at the GPS carrier frequency, when the camera is triggered. Figure 12.4b shows a study conducted with a spectrum analyser to determine a noise source present around the GPS frequency. This figure shows an example of a spurious signal emanating from the camera module. The frequency of this spurious signal is found to be at 1.4284 GHz. The power of this signal is at -48.19 dBm (i.e. -58.18 dBm plus 10 dBm of spectrum analyser attenuation). In contrast, the GPS receiver captures extremely weak signal in the order of -127 dBm (127 attowatt), please refer to Table 12.1. It is interesting to note that the power of these spurious signals is about 109 times greater than the signal GPS receives from satellites. The reader must take notice that there are other spurious signals that emanate around 1.575 GHz (not shown), that cause the actual interference with the GPS receiver.
(a) Jamming of GPS receiver signal by nearby noise sources.
(b) The camera introduces about -40 dBm of spurious signals that overpower the GPS receiver.
Figure 12.4: Using a spectrum analyser to study the interference due to the camera. Minimizing the interference With the technology available today, for a vehicle to navigate autonomously, has to rely on the GPS for position accuracy and for navigation of waypoints. The jamming of a GPS receiver with or without intention even for a fraction of second can cause trouble for the vehicle to keep up with its correct position. The jamming of GPS receivers with drones is not a well studied area and not much can be done in order to prevent it. There are two ways to mitigate this problem. One of these is to shield the camera cable with a suitable material forming a faraday cage. The other is to build an algorithm in software, whereby, if the number of visible satellites drops significantly lower than a threshold, the vehicle decides to land or keeps hovering until the GPS signal is restored.
124
(a) Camera ribbon cable acts as a half- (b) The source of interference is wave dipole antenna. RF field only for shielded by a special copper tape and illustration purposes. grounded.
Figure 12.5: Measures taken to minimize the interference created from the camera ribbon cable. 1. Shielding and cable orientation: Tests are conducted to determine the type of antenna the camera cable projects. It is found to act as a half-wave dipole antenna, see Figure 12.5a. This understanding indicates that the antenna can be placed in a certain orientation so as to minimize the interference with the GPS. Cable shielding is commonly used for signal and data cables. The design of cable shielding and grounding is an important factor for the reduction of electromagnetic interference. Figure 12.5b depicts the shielding of the camera cable, the determined source of interference, with a special copper tape. This shielding keeps the RF (Radio Frequency) from escaping the design. Further, the orientation of the camera with respect to GPS is chosen such that the camera cable is kept perpendicular to the GPS receiver antenna. Tests indicate that the intensity and power of the spurious signals have been reduced significantly to at least approx. -110 dBm. As per the specifications of u-blox GPS receiver found in [38], a u-blox 5/6 receiver can handle interference that is 25 dBm stronger, before suffering a degradation of GPS signal by half. In other words, the u-blox GPS receiver can filter out noise as long as the received signal is above approx. -100 dBm. Although, measures are taken to mitigate the interference effects after close analysis. Our conclusion is that the Raspberry Pi’s camera is the main cause of the interference. This leads to the fact that this camera has not passed through all stages of EMC compliance tests and use of the Raspberry Pi camera V.2 must be avoided in projects that may employ this during outdoor navigation, when using civilian GPS receivers. 2. GPS lapse software protection: As a safety precaution, a GPS protection mechanism is built in the source code. The algorithm is built on the idea that whenever the position of the multicopter exceeds beyond a defined radius, or when the acceleration exceeds a certain threshhold, the system detects this lapse and forces the multicopter to land at the immediate spot. Only the function for the lapse is presented in Algorithm 4. The function is computed each time the GPS position is updated. If a lapse in GPS position is determined, based on the result of this function, a relevant action such as to land is immediately initiated. The algorithm for GPS lapse protection is presented below.
125
Algorithm 4 GPS lapse Require: radius cm, max accel, time passed, dist cm, accel dist, curr gps, prevpos, now, prev time, GP S3DF IX, gps, prev gps, gps lapse, allok Ensure: gpslapse is set to false, prev time, gps, prev gps object are initialized, GPS3DFIX = 3, radius cm )in cm) and max accel (in sm2 ) are assigned a required value. 1: if gps.getstatus() ≤ GP S3DF IX then 2: gps lapse ← true [If there is no 3D fix] return now = get curr time(); 3: time passed ← now - prev time [Compute time since the last gps check] 4: curr gps.lat = gps.lat [Get current gps location] 5: curr gps.lat = gps.lon 6: dist cm = getdist cm(prev gps, curr gps) [Compute distance based on current estimate] 7: if dist cm ≤ radius cm then 8: allok ← true 9: else 10: accel dist = 12 * max accel * time passed2 [Find distance based on acceleration] 11: allok ← (accel dist ≤ max accel) 12: if allok then 13: prev time = now 14: prev gps.lat = gps.lat 15: prev gps.lon = gps.lon return allok
126
Chapter 13
Extended Flight Times The contemporary low-cost electric driven Micro Aerial Vehicles (MAVs) are limited by their flight times. This limitation prevents them being used in useful applications. The flight time is influenced by a lot of important details of the MAV and the flight conditions. The possible flight time is influenced by factors such as selection of the battery, electronic equipment, the mechanical design, motors and propellers. This chapter discusses the build and design of a lowcost quadcopter aircraft that can hover for an elongated periods of time and reach 82 minutes of continuous hover outdoors. We begin with the motivation for this design, in Section 13.1. In Section 13.2, the various factors that limit the flight time of the quadcopter is discussed. The component selection for this design is detailed in Section 13.3. Further, in Section 13.4, critical analysis of an unconventional method proposed to increase the flight time is discussed. The Lithium-ion as an alternative energy source is presented in Section 13.5. Finally, the flight time results and the efficiency of the system is given in Section 13.6.
13.1
Motivation
The main motivation of a new quadcopter design is the power analysis carried out in Chapter 9. It was shown that a medium-sized quadcopter such as the one used in this research that weighs approx 1.5 kg. It consumes 235 W of power for hover, with a nominal battery voltage of 11.1 V. This is the power required by most typical quadcopters. The flight times registered with small to medium quadcopter designs that weigh 1-2 kg, are anywhere from 6 to 18 minutes as per author’s experience. To achieve flight times beyond 20 minutes, by itself, is an aspect of research that is in high demand in commercial industry, as well as in the military. Effort is spent to analyse ways to reduce the power consumption for a quadcopter that weighs about 1.5 - 2 kg. The analysis is carried out by experimenting different components and energy source. With commercially available quadcopters, two organizations have recently caught customer attention. They have proposed increased flight times with their designs; the cost of these designs however, vary greatly. A list of these manufacturers are given below: • The turbo-ace-x830 from Turbo-Ace manufacturer, offers a flight time of 23-30 minutes and states it as having the industry’s longest flight times for the given price [42]. This quadcopter design costs $ 2,800.95. • The Microdrones, a company from Germany supplies its quadcopter aircraft targeted to the military and high-end consumers. They offer the md4-1000 quadcopter vehicle
127
that provides upto 88 minutes of flight. This platform costs £40, 000; a statement from Microdrones found in [43], is given below. Depending on attached payload, battery and environmental conditions like wind speeds and ambient temperature the system can achieve flight durations of up to 88 minutes. On the contrary, this research proposes a low-cost design analysis, targeted at improved flight times. The author addresses several crucial parameters that lead to an improved flight time in comparison to contemporary quadcopter designs. The vehicle used is an in-house development of the author and weighs about 2 kg.
13.2
Factors affecting flight time
There are four main influencing factors that when put together affect the flight time, for any multicopter aircraft design. These are the rotor swept area, energy density of power source, take-off weight of the aircraft and the total efficiency of the system. In this section, we address each of these factors one by one. 1. Rotor swept area: The swept area refers to the area of the circle created by the propeller, as it sweeps through the air. The diameter of the propeller directly influences the amount of air swept under it and thus, the power required by the system to produce this thrust. During hover, the propellers move large volumes of air in a downward direction. This pumping process uses lots of power and accelerates the air to relatively high velocities. The air flow pattern due to a propeller rotation is illustrated in Figure 13.1.
Figure 13.1: Illustrates the induced air velocity below the propeller plane. From [44], the equation of induced thrust power is given as: (m · g)1.5 P =√ 2·ρ·A
(13.1)
kg where, ρ is the density of air [1.25 m 2 ], A, is the rotor swept area (m2 ), m, is the mass of the vehicle (kg), g, is the acceleration due to gravity [9.81 sm2 ], (m · g), thrust developed by the rotor blade (N)
A direct inference from the equation above indicates that the induced power is directly proportional to the mass of the vehicle and inversely proportional to the area of swept
128
blade; considering acceleration due to gravity and density of air to be constant. A heavy quadcopter with smaller propellers need more power. To hover with a smaller amount of power, it is required to have larger propeller blade. A low mass of the quadcopter leads to reduced power required for hover. The derivation of (13.1) is based on Bernoulli’s principle of air flow and mass flow rate1 . The interested reader can refer to its derivation in [45, p.25]. 2. Energy density: Energy density is the amount of energy stored per unit volume or per unit mass. The mass of the battery (mbattery ), is related to the energy density (E) by its specific power J (Sp )2 of the battery ( kg ): E = mbattery · Sp
(13.2)
The total flight time is dependent on the energy density of the storage cell. The total flight time, T in terms of energy content of the storage cell (E) and power dissipated by the aircraft (P), is given by the relation:
T =
Storage type Carbon-zinc NiCad Lead-acid NiMH Alkaline long-life Lithium Polymer (LIPO) Lithium-ion Fuel cells Lithium Thionyl Chloride
E P
(13.3)
Cost/ Wh ($) 0.31 1.50 0.17 0.99
Energy density (Wh/kg) 36 39 41 95
0.19
110
0.24
70-120
0.47 2.25
128-250 500
1.16
700
Table 13.1: Classifications of available storage types in the industry. Source: [46], available 23-Dec-2013. Table 13.1 presents the popular electrochemical storage technologies in use today. In all state-of-the-art multicopter designs, LIPO (Lithium-Polymer) storage types are used, since they are able to deliver extremely high continuous currents at higher voltages typically required by a multicopter. Apart from LIPO cells, the fuel cells and Lithium-ion cells are especially interesting. The fuel cell is an upcoming technology. However, these are 1 2
Mass flow rate is the mass of air that passes down through the propeller plane, per unit time Also referred to as the power density, is the ratio of the power available from a battery to its volume
129
not considered in our study as they are not available for commercial sale. The available fuel cell kits puts them out of reach of the consumers due to their high price. Further, they are not feasible for high power applications such as a multicopter, that are power hungry. The Lithium Thionyl Chloride cells have the most energy density of the order of 700 Wh/kg, however are suitable for extremely low power applications that require less than 100 mA of continuous current. On the other hand, Li-ion cells used in electronic devices such as mobile phone and laptops, are considered in this thesis. They are not comparable to high current LIPO batteries, but do have greater energy density. They may be able to provide sufficient power for hovering if the individual cells are stacked up together and if the power requirements are low. All the other cell technologies, listed in the table are not considered as they have relatively less energy density. 3. Take-off weight: It is a known hovering aircraft design principle that the power required to hover is nonlinear with the weight of the aircraft. This principle is clearly depicted with the Power vs. Weight equation defined in [8]. The power P (in Watt (W)) required to develop a thrust (i.e. lift capacity) T, expressed in Newton (N) is given by: P ∝ ∼
√
T3
(13.4)
For the graph of this relation, please refer to Chapter 7, under LIPO selection criteria. It is clear that weight is one of the most crucial parameters that directly affects the hovering capability. In typical quadcopter designs, the study of power required to hover is often given less importance and focus is given more on reduction of weight. The motivation in this part of thesis is to understand the power requirements of a typical quadcopter design. The reduction of the power required to lift the aircraft will directly increase the time of hover. The power measurements done with the quadcopter that has been used throughout this research, registers a hover time of 14 minutes. It requires 235 W of power with a current consumption of 19 A at a registered battery voltage of 12.36 V. This is the minimum power required to hover at approx. 0.5 m. For more details, please refer to Chapter 9. The hover time and power required is typical of most quadcopter designs. The effect of take-off weight is explained by Equation (13.4). It is preferred to have a light structure, especially made with a carbon fibre or similar materials. A carbon fibre structure is light weight as compared to an aluminium structure, yet sturdy. A number of carbon fibre rods are used to construct the frame structure, for our build. 4. Total efficiency of the system: In practice, it is not possible to achieve close to 100% efficiency for a system. There are losses in the system caused by losses in the battery, electronics, motors and propellers. We add all the losses in one efficiency factor, for the complete system [44], given by: Tef f ective = η · T
(13.5)
Where, Tef f ective represents the achieved practical flight time, T is the theoretically estimated time and η is the efficiency factor that depends on the overall system.
130
The mass of the system can be split into mass of the structure itself and the mass of the battery. From (13.1), (13.2) and (13.3), we obtain the following relation: √ √ mbattery · Sp · 2 · ρ · A E E· 2·ρ·A T = = = P (g · (mstructure + mbattery ))1.5 (g · (mstructure + mbattery ))1.5
(13.6)
Now, we estimate the relation between effective flight time vs. theoretical flight time. Considering the nominal cell voltage for LIPO, Li-ion cells to be 3.7 V and substituting the value of kg m density of air [1.25 m 2 ], gravity [9.81 s2 ] in (13.5), results in: Tef f ective = 0.32 · η · [minutes]
√
capacity [mAh] mbattery 1.5 [gram] )
Nrotors · drotor · Ncells · ( mstructure [gram] +
(13.7)
The number of rotors (Nrotors , diameter of the rotors (drotor ), number of cells (Ncells ) and storage capacity have been introduced into the equation, please refer to [44]. The above equation is generic that applies equally well to helicopters and multirotors. In [44], the author has analysed different LIPO battery capacities to estimate the best possible capacity to be used with small-sized quadcopters. In this research, we take a step forward and analyse other energy sources that can be used on a quadcopter and its component selection. It is clear by analysing Equation 13.7 that, with a propeller having a large diameter, the best possible energy source, low weight of frame structure and efficient components (such a motors) will contribute to the flight time enormously.
13.3
Selection of components
The construction of the quadcopter and the components chosen for the build are discussed below. 1. Motors and propellers: The most important criteria to address is the selection of motors and propellers. (a) Selection of motors: When selecting motors, the following specifications are taken into consideration: • Kv rpm v : Kv refer to the rpm constant of a motor. It indicates the number of revolutions per second (rpm) that the motor will turn when 1 V (one volt) is applied and no load is attached. • Weight (g): The weight of the motor in grams. • Maximum voltage (V): The maximum voltage that can be applied across its ends. • Thrust efficiency (g/W): This is the amount of thrust produced for a unit of power. It is preferable to have a high value for this parameter. • Other parameters such as maximum current, diameter, number of windings, no load current, etc. are other parameters mentioned in the motor specifications. The rpm constant of the motor, Kv, is the most important of all. It relates the power output from a motor, or in other words the torque level of a motor. The Kv 131
is determined by the number of windings on the brushless DC motor’s armature and the strength of the magnets. A low Kv motor has more windings of thinner wire and carries more volts at less amps. It provides high torque and is one of the reason why such motors are used on RC planes. In small-to-medium sized quadcopters, high Kv motors are used. High Kv motors have less windings of thicker wire that carry more amps at low voltage and spin a smaller propeller at high speeds. With reference to Equation 13.7, to use a propeller with a larger diameter, we need to choose a low Kv motor. The motors on the quadcopter seen in the earlier chapters in this thesis, uses a 850 Kv motor. For our new build, we narrow down motors that offer a lower Kv suitable to large diameter propellers. For our analysis, the weight and thrust efficiency (g/W) of three low kV motors have been analysed. This is listed in Table 13.2. From the table, it is apparent that the 5010-14 DC motor model has a better thrust efficiency and lower weight as compared to the others, see Figure 13.2a. Brushless DC Motor HQMod A4008 620Kv HQMod A4008 530Kv 5010-14 360KV
Weight 112 g 108 g 99 g
Thrust efficiency (g/W) 11.2 (g/W) 10,0 (g/W) 12.1 (g/W)
Table 13.2: The motor model, weight of the motor and thrust efficiency (g/W) is listed. Tests are done with 2.0 A of current draw with a 15-inch prop. Please note that the values vary between manufacturers and may be inaccurate to some extent, [47], [48]
(a) 5010-14, 360 kV brushless DC motor used on the quadcopter.
(b) 17-inch props used on the quadcopter.
Figure 13.2: Illustrates the chosen 360 kV motors and propellers (not to scale). (b) Selection of propellers: The selection of propellers go in accordance with the type of motor selected. In the market, the usual propellers vary from 10-14 inches. Larger diameter propellers are not so common or widely used. For selection of the propeller, two criteria are important: i. Diameter: This is the tip-to-tip length of the propeller blade. ii. Pitch: The pitch is defined as the distance travelled by one single propeller rotation, in degrees.
132
The pitch of a prop has a direct relation to the power consumption and torque produced. A prop with low pitch number (such as 13 x 4, where 4 is the pitch), generates more torque. Therefore, the motors draw less current. A low pitch prop is suitable to our analysis, as one of our main requirements is reduction in power. On the other hand, a higher pitch number (such as 13 x 8) means a slower rotation, as it moves greater amount of air and uses more power, see see Figure 13.2b. At the time of purchase, the largest propeller available in the market was 17-inch propeller with a 4.4◦ of pitch. 2. Frame construction: Carbon fibre is a light weight material that is sturdy in operation. It is used for many quadcopter constructions and is not new. The frame construction involves placing together four carbon fibre rods each with a 12 mm diameter to form the structure. The center plate of the structure is printed using a 3D printer. The weight of the frame structure (without electronic components and batteries), is approx. 220 g.
Figure 13.3: After the integration of all components on the carbon fibre frame. 3. Remaining components: The other components such as ESCs used is 20 A, flashed with the Simon K firmware. The flight controller board, GPS, wires and cable are bought separately and are same as the one chosen for the primary quadcopter used at Thales Nederland B.V.
13.4
Power analysis
Power analysis is carried out on two different motor mount orientations. The idea is to analyse the power consumed in different orientations. 1. Figure 13.4a shows the contemporary design employed by contemporary multicopter designs. In this design, the motors lie above the plane of the frame. 2. Figure 13.4b, shows an unconventional design proposed by the author, where the motors are mounted in an inverted fashion, i.e. the motors lie below the plane of the frame. The power required for hovering is compared between the two designs in Figure 13.5. 133
(a) Normal motor orientation in contemporary designs.
(b) The motor facing downwards. This is an unconventional design that proposes to reduce the power consumption.
Figure 13.4: Illustrates the different tested motor mount orientations.
Figure 13.5: An unconventional design that reduces the power consumed for hover, due to reduction in air drag on the quadcopter frame.
Interpretation of results The results are very interesting due to the following reasons: 1. With all motors mounted inverted under the frame, the power required to reach the hovering state is reduced. This is a direct inference from the fact that the drag on the air frame is avoided when propellers are mounted below the air frame. This results in approx. 11% reduction in power. 2. With this design, the vibration on the frame is minimized. This is again, because the air drag on the frame due to the propeller is almost nullified. This statement in its practical implication is true however, is yet to be verified with vibration analysis.
134
13.5
Energy source
Two sources of energy are tested with this new design. One of them is the standard LIPO, 5000 mAh, 11.1 V battery, already used in this project. This LIPO pack can provide 55 Wh of energy. The other source of energy is the Li-ion cell. The motivation for the use of Li-ion instead of LIPO battery is that they provide a higher energy density and can provide sufficient current if connected together in series and parallel combination. There are various manufacturers of Li-ion cells and choosing the correct cell with the right specifications for our power requirement is essential. The Panasonic ncr-18650 PF, Li-ion cell provide 3,400 mAh of current at 3.7 V, nominal voltage. Figure 13.6 shows that when such Li-ion cells are connected together is a 5S-4P configuration, can provide upto 17 A of current at 14.8 V. This indicates that when these cells are soldered together into this configuration will provide 273.8 Wh of energy.
(a) ncr-18650 PF, 3400 mAh, 3.7 V, Li-ion cells.
(b) 5S4P (5-Series, 4-Parallel combination to give 17,000 mAh at 14.8 V.
Figure 13.6: Illustrates the Li-ion cells, when connected in 5S-4P configuration, supplies enormous power.
(a) The lithium cell 5S-4P pack, weighs 951 g. With 20 cells, each weighing 46 g.
(b) Quadcopter carrying the Li-ion cell pack.
Figure 13.7: Putting together the Li-ion pack to be used on the quadcopter.
135
13.6
Flight time results
In this section, we compare the theoretical results obtained with the application of Equation 13.7 discussed earlier in this chapter. The practical flight time obtained is compared with the theoretical results. This will help us compute the overall efficiency of the system of the new carbon fibre build with separate energy sources. Figure 13.8 shows one of the practical tests done with the new build outdoors.
Figure 13.8: An outdoor test flight. The flight is autonomous and locked in GPS mode. Note that the motors are mounted in an inverted fashion. • Configuration 1: – Carbon fibre build – Storage type: LIPO (Lithium-Polymer) – Nominal voltage: 11.1V – Battery current: 5000 mAh – Energy (in Watt-hours): 55 Wh – Weight of battery (420 g) – Weight of the system (including battery): 1530 g – Motors mounted inverted – The number of cells used are 3 – Calculated flight time (without efficiency): √ 4 · 431.8 * 3 * 5000 0.32 ∗ = 70min (1110 + 420)1.5 where, 431.8 is the diameter of the propeller (17-inch) in mm. Practical flight time: 35 minutes Efficiency: η = 35 : 70 => η = 0.50
136
(13.8)
• Configuration 2: – Storage type: Li-ion (Lithium-ion) – Nominal voltage: 14.8 V – Battery current: 17,000 mAh – Energy (in Watt-hours): ≈ 274 Wh – Weight of battery (951 g) – Weight of the system (including battery): 2061 g – Motors mounted inverted – Here, the number of cells used are 4, (4S-5P configuration) – Calculated flight time (without efficiency): √ 4 · 431.8 * 4 * 17,000 0.32 ∗ = 202min (1110 + 951)1.5
(13.9)
Practical flight time: 82 minutes Efficiency: η = 82 : 202 => η = 0.41
Interpretation of the results The two configurations presented above provide us with different flight time estimates. This is clearly seen due to the use of Li-ion cells. Both these tests are conducted in wind conditions of about 10 kmph. An indoor test flight will certainly provide with an improved estimate for η, and thus an increase in flight time. In reality, to achieve η close to 100% is not possible. However, improvements can be made to the system in the area of aerodynamics, selection of a suitable motor-propeller combination and better tuning of the control system. The equation 13.7 is found to be very useful for validating the results as well as coming up with your own design. The cost to build this system is approx. e 600 and provides flight time over 80 minutes, that is atleast four times greater in comparison to contemporary quadcopters for a similar weight range.
137
Chapter 14
Conclusions The work on this master thesis has been very interesting and many lessons have been learned along the way. In this chapter, the insights gained during the implementation and testing process are described as possible additions to near-future technological applications. The future of DTN with small-scale UAVs and extensions are also discussed, and some final conclusions are drawn.
Combining the technologies The time has come when terrestrial applications of DTN have started getting attention. DTN is a fast growing technology and especially interesting from a military standpoint, as it makes networks robust against temporary disruptions. It is interoperable with different existing communication technologies such as between satellites, planes, mobile phones, etc. can all use DTN irrespective of underlying implementation of other protocols. DTN can be used with or without wireless networking. With advanced security features added to routing in MANETs and lower layers, the use of DTN with ad-hoc routing becomes all the more useful and feasible. The use of medium-sized multirotor vehicles are preferred to traditional helicopters, as they are simplified in design, require less maintenance and offer a low cost solution. Furthermore, these multirotors have a smaller diameter for each individual rotors to equivalent helicopter rotor, allowing them to possess less kinetic energy during flight. This reduces the potential damage caused in an accident. Multirotor is the solution for maneuvering challenging environments and for safer interaction. Various organizations such as NASA, Google and Amazon amongst others are taking advantage of the multirotors for diverse applications. The applications include closed-circuit television capabilities to provide an eye in the sky to study activities below, nuclear sites surveillance, search and rescue operations, goods delivery and filming. Going beyond the prescribed applications with micro UAVs, also provide the opportunity to extend and improve the communications in a multihop ad-hoc network, as addressed by this thesis.
14.1
Summary of contributions
• Extension with DTN The IBR-DTN implementation of DTN provides a test bed to the user for testing the concept of store and forward. It implements robust bundle management in its architecture and supports transmission and reception of bundles as messages between two end points. 138
However, there are situations where multiple end points are involved, such as in military scenario and an algorithm is required to extend the existing use of basic end-to-end store and forward. Complications creep in when scenarios involve inter-message dependencies, multiple classes of tasks that need to be accomplished at different times. In this research, an algorithm and protocol have been devised and implemented on embedded systems addressing these scenarios. Prior to devising this concept, several additions have been made with IBR-DTN that improve the usability with applications. The additions address decoding of source information of the received bundle, timely bundle reception management and ability to send multiple individual files as a single package from source to destination. The algorithm is modular and object oriented and can be extended as required. • Aerial-network protocol This protocol complements the work done with the extension of DTN and existing work on MANETs. It enables management of data received, stored and/or forwarded to its future destination. Further, it is a protocol because it enables bidirectional communication between sockets of the end points before and after data exchange, to ensure fair knowledge of transaction of data. To fulfil the networking requirements for a given region, the multirotor autonomously alters its navigation behaviour from simple hovering to change in altitude based on the connection quality or circle around a given waypoint in an attempt to find a static node. To achieve this, requires a good coordination between the autonomous flying and the networking activities, which is addressed by the Aerial-network protocol. • Multirotor hover Several useful strategies have been shown to work to improve the multirotor hover to sub-meter accuracy, with GPS. The importance of vibration control, magnetic field interference, controller tuning and using multiple sensors for improved stability are discussed. • Flight times With the current technology, flight time of the multirotor is considered as the number one setback for applications requiring long duration flights. Many companies are looking towards the realization of greater duration flights. The flight time for aerial platforms have a non-linear relationship with its weight. It also depends on the energy source used and the aerodynamic efficiency of the flight. The contemporary multirotors with a few kilograms of payload hover for less than 20 minutes. To extend the flight times beyond this limit is by itself, a challenging research aspect. In addition to the contribution to this thesis, a new multirotor is hand designed with the aim to improve the flight times. The design focuses on three unique aspects, i.e. mechanical component selection, energy source selection and efficiency of aerodynamics to reduce the power required to hover. With this new design, flight times of over 80 minutes have been achieved with autonomous flight. The potential of this design can be enormous and leads us to explore applications such as execution of long duration networking tasks.
14.2
Insights and conclusions
• Insights 1. In a practical setup, there is a need to study the interferences caused in the network. The civilian drones use on-board wireless devices that operate at near-by frequencies, as per the wireless regulations. The GPS is very sensitive to interference and plays an important part in navigation. A close understanding of possible interferences is
139
required to avoid potential catastrophic scenarios, leading to a crash. 2. To improve flight time of an aerial vehicle, effort is often invested in reduction of its weight. This is an important aspect, however, selection of suitable components based on its power analysis will reap great benefits. The analysis of aerodynamic effects of your aerial vehicle will also improve its efficiency. 3. The ETX metric is extracted from OLSR, that represents the quality of the network. This, when used in conjunction with a mobile node, can help to alter the navigation characteristics to suit the networking requirements. This insight is found especially useful. • Conclusions 1. From the work presented in this thesis, it is found that DTN technology can be integrated with a UAV. The extensions proposed to the current DTN design makes it more flexible for use with mobile applications. 2. The Aerial-network protocol proposed and implemented in this thesis, successfully brings together the concepts of MANET and DTN. It enables the autonomous network transactions with a multirotor and alters its navigation behaviour based on studied network parameters such as link quality. The protocol is carefully designed to handle any given task, in a robust way. 3. The use of wireless networking with UAV requires the resolution of several interference problems. Some of the problems caused when using it with an aerial robot are analysed and measures are discussed to mitigate those effects. 4. It is determined that smarter multirotor designs are possible where the flight times can be significantly extended by addressing certain design considerations such as using different energy source, unconventional orientation for the motors and custom chosen components. A gain of atleast 4X times in flight times is noticed, to the contemporary multirotor designs available.
14.3
Future work
Wireless technology has already reached a mature state of development used by every one of us everyday. The DTN technology is about to mark the future of applications that wish to tolerate delayed networking needs or in extreme terrestrial environments where network infrastructure may not always be available. In future, every military personnel in movement can be seen to possess an ad-hoc node with DTN capability, for unscheduled discovery and peer-to-peer communication whenever encountering each other within their range. Currently, DTN is feasible on networks with large amounts of local storage and end-to-end bandwidth relative to expected traffic. This inefficiency is outweighed by the shortened delivery times taking maximum advantage of unscheduled forwarding opportunities. The development of efficient routing algorithms in DTN such as PRoPHET1 routing based on probability of node encounters and ORWAR2 that takes in account speed, direction of movement and radio range amongst others, is in research. The work in this thesis proposes extensions with DTN and an algorithm for aerial networking. This algorithm uses these extensions by interacting with an autonomous multirotor to pursue 1 2
Probabilistic Routing Protocol using History of Encounters and Transitivity Opportunistic DTN Routing with Window-aware Adaptive Replication
140
networking tasks. The algorithm is easily extendible and Quality-of-Service (Qos) extensions are possible. This implementation may be found useful for applications requiring the use of DTN technology. For example, an interesting work done in [12], on a swarm of UAVs interacting together using DTN, can benefit with this extension. With the rapid growth of small-sized aerial vehicles, its applications are in demand and awaiting FAA clearance. With integration of additional sensors, the multirotor will act to be more intelligent and able to perform tasks beyond our imagination. The future of swarm aerial robotics with DTN technology will be very interesting. MANET will need to be used for fully self configuring and secure solution to multi-hop forwarding data traffic. In the end, the practical work done on increasing flight times over contemporary multirotors and breaking that necessary boundary is achieved with this work. It points to us the importance of correct design and where our focus must lie if the goal is to improve flight times. The analysis done by testing an unconventional inverted motor placement is seen to improve the overall efficiency of the system further, by 11%. This concept may be used in future work to improve flight times further. The work done in this master thesis is a proof of concept that shows a promise of further development in the field of application specific multirotors.
141
Appendix A
Hardware and Software Details Hardware Components Table A.1 shows the details of the various sensors and controllers used on each of the OSP’s used for the multicopter platform. Description Dimension(mm) Weight(g) Processor Speed(MHz) Gyroscope Accelerometer Compass Barometer a
Paparazzi 51x25 10.8 STM32 F1a 60 MPU-6000 MPU-6000 HMC5843 MS5611
Openpilot 36x36 8.5 STM32 F1 72 ISZ/IDC-500 ADX330 HMC5843 BMP085
ArduPilot 66x40.5 23 ATmega2560 16 MPU-6000 MPU-6000 HMC5883L MS5611
Pixhawk 40x30.2 8 LPC2148 60 ISZ/IDC-500 SCA3100 HMC5843 BMP085
Mikrokopter 44.6x50 35 ATmega644 20 ADSRS610 LIS344ALH KMZ51 MPX4115A
The STM32 chips are grouped into related series that are based on the same 32-bit ARM processor core.
Table A.1: Main components used in OSP quadcopters. Citation: ([1],[18],[7],[17])
Sensors All the OSPs (Open Source Projects) listed in the table use the primary two sensors for attitude estimation 1 i.e. an accelerometer and a gyroscope in addition to a compass for heading and a barometric pressure sensor for height estimation. For the accelerometer, four different chips are used in the different OSPs. Three unique chips are used in case of the gyroscopes. Compass is used to estimate the drift of gyroscopes and barometer pressure sensor helps estimate the height of the copter. The details of the various components are discussed further in Chapter 7. Out of the various sensor systems used, ArduPilot and Paparazzi use MPU-6000 chip; contains integrated MEMS 3-axis accelerometer and MEMS 3-axis gyroscope integrated on a single chip, with a dimension of ≈ 3.36mm3 [1]. It is designed for low power, low cost and high performance requirements. Moreover, the chip also contains a Digital Motion Processor (DMP) that has 1
Attitude defines the body’s position or orientation in a 3-dimensional space, identified by pitch, roll and yaw parameters.
142
inherent cost advantages compared to discrete accelerometer and gyroscope solutions as in other OSPs. When using the internal sensor fusion processor of the MPU-6000, a significant amount of the main controller board’s capacity is freed for processing other needs. Further, it enables to take input from other sensors such as compass and barometer via I2 C bus, for sensor fusion, without intervention of the main controller board. For compass and barometer chips, most OSPs use similar chips.
Controller Board A controller board interacts with various sensors and hosts the microcontroller. The Ardupilot and Mikrokopter are based on Arduino and use the AVR 8-bit microcontroller whereas the others are based on ARM 32-bit microcontroller. AVR boards are suited for real-time operations but have relatively lesser processing power and memory as compared to its counterpart. With arduino based boards, it is easier to prototype, set up and comes with rich set of device drivers for sensors and actuators. If on-line image processing were a requirement, ARM based board would prove to be a better choice due to higher processing capability. However, an external interfaced board with AVR based board can be an option, otherwise. It would be interesting to note that as of late 2013, ArduPilot project is merged with Pixhawk project, that gives the versatility of Ardupilot’s OSP in addition to the processing capability of Pixhawk that supports real-time computer vision.
Software Features Table A.2 depicts the overall software configuration that can be set up for each of the OSPs. Functionality Attitude estimation Waypoint Navigation Computer vision GCS provided Airframe design
Paparazzi NCF X
Openpilot EKF ∆
ArduPilot NCF X
X
X X
X X
Pixhawk EKF
Mikrokopter LCF ∆
X X
Table A.2: OSP software possibilities. X: Supported libraries, ∆: Partially supported, Citation: [1]
Attitude Estimation Each of the OSP implements its own attitude estimation algorithm as seen from Table A.2. Due to the very nature of accelerometer that is susceptible to noise and gyroscope sensors that are susceptible to gradual drift due to integration over discrete time samples and due to temperature change, the sensor data from the individual sensors do not perfectly reflect the rigid body’s orientation (further explained in Chapter 8). In order to overcome the limitations imposed by individual sensor readings, the data from these sensors are mixed or merged together to minimize the errors to get close to the true attitude estimates for the orientation of the rigid body. Different implementations exist for attitude estimation such as using Extended Kalman Filter (EKF), Linear Complementary Filter (LCF) and Non-linear Complementary Filter (NCF) based on certain trade-off between them. Below, we give a very brief overview of the strategies involved; the interested reader is suggested to refer to the citations given alongside.
143
• Extended Kalman Filter (EKF): A Kalman filter is used for measurements observed over time, containing noise and other inaccuracies, and to predict values that tend to be closer to the true values of the measurements. It is based on weighted average filter of the predicted value and the measured value. The most weight is assigned to the value with the least uncertainty. This is a widely used filtering strategy in space and military technology. For the linear system, linear Kalman filter is applied and for the non-linear system, Extended Kalman Filter (EKF) is used. The EKF model, linearizes the non-linear models such that the traditional linear Kalman filter can be applied thereafter. However, it has been observed to be difficult to tune the filter and application of Kalman filter to non-linear systems can be difficult in practice. Kalman filters are responsive to vibrations but are computationally power hungry to be run on a dedicated microcontroller[49]. • Linear Complementary Filter (LCF): This strategy employs the use of low-pass filters to filter out high frequency noise from the accelerometer (such as during sudden movement or vibration) and a high-pass filter to filter out low frequency signals (such as drift from gyroscope). By combining these two filters, a reliable estimate comparable to an EKF can be obtained without the complications of a Kalman filter[50]. • Non-linear Complementary Filter (NCF): The name of this filter is due to the structural similarity with the linear complementary filter. This filter just like LCF, relies vastly on the gyroscope sensor for the rigid body’s orientation and uses the accelerometer vector to provide a better attitude estimate. In the Non-linear complementary filter, it makes use of a PI (Proportional-Integral) controller closed feedback loop between the measured attitude value and desired attitude value, to minimize the attitude error obtained. This results in a more accurate and smoothed attitude data. From the estimated vector that is obtained, the pitch, roll and yaw can be derived mathematically. Please refer to [51] and [34, p.3] for more details.
Controller Evaluation In [1], five quadcopters are built using different OSP’s namely, the Paparazzi, ArduPilot, Mikrokopter, MultiWii and KKMulticopter. Amongst these, Paparazzi, ArduPilot and MultiWii share the same controller model with a complementary filter. For qualitative evaluation, markers are mounted on the quadcopter to acquire ground-truth data 2 using Vicon Motion Capture System that offers milli-meter resolution of 3D spatial displacements, see Controller Evaluation in [1, p.43]. The desired angles are sent to the quadcopter by the user and the quadcopter attitude from the Vicon and transmitted signals are recorded simultaneously. The attitude tracking result is shown in FigureA.1. It is found that the ardupilot’s attitude response when tested with ground truth is found to be better than other state-of-the-art OSP controllers.
Ground Station Control (GCS) A well developed GCS is essential to study the vehicle’s behaviour via serial USB or wireless telemetry. It was found that Ardupilot and Openpilot have features such as script support for waypoint mission planning, google maps integration for waypoint navigation that can be 2
Ground truth: It refers to the process of gathering proper objective data for a test conducted.
144
Figure A.1: Attitude tracking response of a quadcopter. Ardupilot based controller is found to be more accurate than other OSP controllers, based on ground-truth. The delay between reference and measured signal is due to the communication delay, Reference: The desired angle, Roll, Theta: Measured attitude of the quadcopter by Vicon, Source:[1] extended by user and support on different Operating systems. Figure A.2 displays a screen shot taken from various GCS shown only for completeness.
Figure A.2: A screenshot of Ground station control available for different OSPs, (a) Paparazzi, (b) Openpilot, (c) Ardupilot, (d) Pixhawk, (e) Mikrokopter
145
Appendix B
Networking Principles OSI Model Overview In 1970s the International Standards Organization(ISO) developed an abstract description for network protocol design called Open Systems Interconnect(OSI). This started as an effort to standardize network communications between diverse applications and equipment, is a reference model that describes how protocols should interact with one another. The OSI is a seven layer model, in which each layer serves a unique purpose. The solutions offered by one layer do not conflict with other layers thus, limiting complications between the layers. The Internet protocol stack(TCP/IP), a five-layered model is an implementation of a computer networking protocol suite derived from the OSI model. Figure B.1 shows the sending and receiving systems, also called end points. In order to get data running from a device running application A to a device running application B, the data needs to descend the layers of the former and then ascend the layers of the latter(the layers are also called, the IPS or Internet Protocol Stack)[52]. The upper layers deal with application related issues and implemented in software. The lower layers carry out the transportation of data[53]. The data link and the physical layers are implemented in hardware and firmware level. The lowermost layer, the physical layer, is closest to the physical medium (such are ethernet cable, wireless medium) and places data on the medium. Each layer adds its own headers and trailers over the raw data at the sending side and these headers and trailers are stripped off at the receiving end by respective layers to retrieve the actual data. The functions of each layer and associated protocols prescribed within these layers are described. • Layer 7 - Application The application layer is at the highest level in the OSI hierarchy and is closest to the end user. The application layer offers services to support the user interfaces, email clients and file access. The file transfer mechanism between computers is an important function initiated at this level. Examples of protocols at this level are FTP, Telnet and HTTP amongst others. • Layer 6 - Presentation This layer is where application data is either packed during transmission or unpacked after reception. Since different computers use different formats, this layer manages the protocol conversions, encryption/decryption and compression based on a standard format[52]. Protocols at this layer are ASCII, EBCDIC, JPEG, etc.
146
Figure B.1: The OSI standard is followed for network communication across all vendors. • Layer 5 - Session In order for computer systems to communicate with one another reliably, the session layer opens, uses and closes the communication link using so called sessions. For instance, during a file transfer a check point may be inserted in its transmission, to keep track of the data transfer. In case of a disconnection, the file transfer may proceed from where it was interrupted. This is an important layer for E-commerce websites that work on dedicated user sessions [52, Pg.2]. Protocols used by this layer are SQL and RPC. • Layer 4 - Transport This layer provides a transparent transfer of data between the end systems. The data received from session layer is broken into data packets before handing it onto the network layer. At the destination, the data packets are combined back to their original state. The Request for retransmission occurs at this layer where packets that have been lost or damaged during transfer are resent. Two protocols that play a major role at this level are namely, UDP and TCP. The TCP is connection-oriented ; the end points need to establish a connection prior to transmission. It keeps track of the packet delivery order and resends a packet when failure occurs. On the other hand, UDP is a connectionless communication and does not guarantee packet delivery between end points. UDP is relatively faster for sending small amounts of data since no connection set up is required. • Layer 3 - Network The network layer deals with the switching and routing of packets from source to destination and provides the best path to do so. There are usually two ways in which packets are routed. Static routing, is where the route through the entire network is not changed, whereas dynamic routing changes the path for the packets in order to avoid bottlenecks
147
(i.e. due to network traffic). The routers work at this level, Figure B.1. Protocol examples at this level are the well know IP(Internet Protocol), ICMP, ARP. • Layer 2 - Data Link At the data link layer all data packets are encoded and decoded into bits. This layers is further divided into Media Access Control(MAC) and Logical Link Layer(LLC) layers. The former is responsible for moving data packets to and from one Network Interface Card(NIC) to another across the physical medium . The latter controls frame synchronization, flow control and error checking. • Layer 1 - Physical The physical layer is the lowermost layer of the OSI model and defines the physical and electrical characteristics of the network[52]. The bit stream is converted into an electrical or radio signal and provides the hardware means to send or receive these signal on a carrier medium. Examples of protocols at the physical layer are Fast Ethernet, RS232 and ATM protocols. It is important to note that most protocols in day to day use a slightly different version of OSI model. In TCP/IP mode of the Internet for example, uses a 5-layer model than a 7-layer model[52, Pg.1].
Lossy Links
Figure B.2: An experiment conducted when an obstacle is brought in between two nodes, sporadically. It can be seen the data rate is affected due to packet loss. Figure B.2 depicts the data rate and signal-to-noise ratio(SNR) during communication between two ad-hoc nodes. The circles marked in the figure, are instances when an object is brought in front of the node affecting its data rate. A similar effect is seen with a decrease in SNR (though not very apparent in the figure). A 3 dB drop in signal is equivalent to half the signal strength being lost.
148
Appendix C
Complete Network Configuration This appendix covers the installation and configuration for networking and is a follow up of Chapter 6. The Section C lists the various tools used for network analysis and troubleshooting. The set up of OLSR and IBR-DTN are explained in Section C and C along with the listing of their configuration files, respectively. This setup is common across systems (MIPS, ARM or x86 based) with any linux based operating system. The installation required on the Raspberry Pi is explained in Section C.
Networking tools 1. Eclipse platform: As all of the networking in this project is established on linux based systems, we use the Eclipse platform for programming in the C++ and Python environments (Python uses PyDev plugin on Eclipse). 2. Wicd Network Manager : A preferred tool to switch between ad-hoc mode and Infrastructure mode on your linux distribution. 3. Airmon-ng, Aircrack-ng: These two tools come in pair and allow to study all the other wireless devices in all channels in the vicinity, as seen by the current wireless chipset. In addition, it displays the MAC address, signal strengths, beacon information and other network parameters of interest. This is achieved by using the monitor mode on wireless interfaces. Further, they also indicate all the processes that interact with the (wireless) interface on a node (in our case WLAN). 4. Wireshark : Wireshark is a popular network protocol analyser used on Linux. The packet information between the various nodes in the network can easily be studied with it and comes in handy during network troubleshooting. 5. Win32diskimager : This tool is used as an SD card backup Image utility (v0.8-binary) on Windows 7 platform. 6. Ibrdtnd : Ibrdtn is the name of the group that has created a usable package using the ’Disruption Tolerant Networking’ concept. This is a daemon (process) that is run in the background on every node for node discovery and bundle exchange. The source can either be compiled or binaries can be used directly. It is however recommended to compile the latest source directly due to binary revision mismatch available for different linux distributions. 7. minicom: A tool to analyse serial data from the flight controller on ad-hoc nodes.
149
8. Python package: Install py-serial, a package on python to enable serial communication. The installation can be done directly on the Raspberry Pi via terminal. More information can be found in [54].
Ad-Hoc setup, step by step For wireless ad-hoc setup, we use two tools, ifconfig and iwconfig. • iwconfig: This facilitates the configuration of wireless devices using the Linux Wireless Extension. • ifconfig: This is a system administration utility in Unix-like operating systems. With the help of a command line interface such as a terminal, we can configure, control or query TCP/IP network interface parameters. Open the linux terminal and edit the following: sudo nano /etc/network/interfaces Please follow the below steps for ad-hoc network setup: 1. Append this file with: iface wlan0 inet static The other basic settings can be looked up from the table below to be appended following the above command. For advanced settings, please refer to [55]. Parameter address netmask wireless-channel wireless-essid wireless-mode wireless-ap
Notes Set the static IP address of your device here. E.g, 192.168.10.50 This tells the current node on what other IP addresses can it reach to. For reaching other nodes in any subnet, set it to 255.255.0.0 Set the channel you wish to be in, between channel 1-13 Set the network name of your device. E.g. ’mynetworkname’ To be in ad-hoc mode, set this to ad-hoc, without quotes This is the access point. Set it to any hex value such as F2:34:A1:A7:BD:CE Table C.1: Settings for ad-hoc network.
Note: Make sure the wireless-ap is manually edited. If it is not done manually, the device driver will set it to auto. This can seldom create problems leading to sudden broken connections. 2. Reboot your system, type: reboot 3. Attach your wireless adapter (Wi-Fi dongle). wlan* should be detected automatically. By default, wlan0 is detected. 4. Open the linux terminal and type: ifconfig. The user must be able to see the configuration with ifconfig for wlan0. Make sure to verify the broadcast address. It should be X.X.255.255, suggesting that it can see all other sub networks. For details pertaining to necessary steps to be taken while configuration such as terminating processes, please follow Chapter chp:adhoc parallelly.
150
5. With the linux terminal open, type: iwconfig. The user must be able to see the edited settings reflected for the device. Make sure the wireless channel and corresponding frequency are correct. 6. If the settings are done on multiple other devices, they should be able to ping each other. Open a terminal and type: ping [target-IP] If the ping is successful, a one-hop ad-hoc network has been successfully established. The next step is to install a MANET routing protocol such as OLSR used in this research. Following this, the installation of DTN is detailed.
OLSR setup OLSR is a daemon that discovers neighbouring nodes via single or double hops. It is an extension of the standard ad-hoc routing protocol. In addition, the user can enable plugins that are used to extend the OLSR functionalities. The backbone of OLSR is its configuration file (olsrd.conf), that is referred to when the OLSR daemon is executed. In this section we discuss the steps to install the OLSR and its plugin, either directly via binary or via source compilation on your local system.
Install via binary Installing the binary directly on your distribution is fairly straightforward. • Direct install (for the available version with your linux distribution): sudo apt-get install olsrd olsrd-plugins Note: There have been minor noticeable backward version incompatibilities as the older version on one node may not be compatible with a later version on another node. It may be suitable to make sure to have similar or closer version for all nodes used in the network. This is especially necessary if you are using different OS on different nodes. E.g. TP-Link router running OpenWrt and your PC running an Ubuntu linux distribution.
Install via source Please follow the below commands step by step, to install source code version and build it on your local distribution. This would install both olsrd and its plugins. Open a terminal in Ubuntu/ Raspbian: 1. mkdir /olsr src 2. cd olsr src 3. wget http://www.olsr.org/releases/0.6/olsrd-.tar.bz2 [E.g. version at the time of this writing was olsrd-0.6.6. Check Downloads page in [26], for your version number] 4. tar –strip 1 -xjf olsrd-.tar.bz2 5. rm olsrd-.tar.bz2 6. sudo apt-get install bison flex 7. sudo make build
151
Note: The cross compilation for Raspberry Pi is initially carried out, performed via Eclipse. Lately, the OLSR provides direct source code that can be built for ARM architectures, making it less time consuming.
Using OLSR The OLSR uses a configuration file to read the user parameters and uses these parameters during execution. • OLSR configuration file: This is usually located by default in /etc/olsrd/olsrd.conf. The user is allowed to set various parameters and tame it as per his needs. • OLSR daemon: The OLSR daemon can be run like this: root@pi1: $ sudo olsrd -f /etc/olsrd/olsrd.conf -d 1 The -d option specifies the level of debug, varies between 0 to 7. The olsrd configuration file is listed at the end of this appendix. Note: Administrative privileges may be required to run the commands. OLSR configuration file is found to be slightly different for OpenWRT dedicated to routers and for other systems. Thales already uses OpenWRT routers. Irrespective of this factor, the settings discussed are suited to all systems. Please compare and make suitable changes, as necessary.
IBR-DTN setup The IBR-DTN setup is similar to the OLSR, i.e. download via direct binaries or compiling the source code directly. There are some instructions and settings that the user requires to perform before successful installation. All instructions to download binary or compile source for different distributions are listed under [project-cm-2012-ibrdtn/wiki/download] in [56]. As of mid 2013, the instructions to compile the source code on ARM architectures is available through the same link.
Using IBR-DTN The IBR-DTN just like OLSR, uses a configuration file to read the user parameters and uses these parameters during execution. • IBR-DTN configuration file: This is usually located by default in /etc/ibrdtn/ibrdtnd.conf, if direct binaries are installed. If the package is compiled via source, this path can be different. The user is allowed to set various parameters and tame it as per his needs. • IBR-DTN daemon: The ibr-dtn daemon can be run like this: root@pi1: $ sudo /etc/init.d/ibrdtnd The process can be appended with the options such as start, stop and restart, before execution. Please use –help, for more information. • IBR-DTN tools: The tools used are DTNSend and DTNRecv. Their usage is already discussed under Chapter 5. The ibrdtn configuration file along with the script to run the daemon (minor tweaks are done to eliminate the time-synchronization dependency) are listed at the end of this chapter.
152
Note: Administrative privileges may be required to run the commands.
Raspberry Pi setup There are two installations performed on a Raspberry Pi. One of them is the installation of the OS and the other is used for the set up of the camera. Further, a real-time clock is optional (to use with DTN), interfaced with the Pi to enable it to keep track of the current time, even when Pi is powered off. 1. Make sure to find the right SD card for the OS setup. Some SD cards may not be compatible. Please refer to [41]. 2. The OS needs to be installed on an external SD card. The Raspbian is a linux distribution based on Debian platform and is considered stable. Please follow the instructions to install Raspbian OS on Raspberry PI. The detailed instructions are given under the wiki section of Raspberry Pi homepage, found in [41]. Raspberry pi camera setup: Please refer to the extensive details of camera setup and usage, available online in [41], under Raspberry Pi camera setup. 3. Real-time clock : The real-time clock is an external chip with its own battery (that can last upto two years without replacement). It keeps track of the current time even when Raspberry Pi is powered off. (a) Obtain the source code for the real-time clock from [57], extract the zip and copy the files to the Raspberry Pi’s SD card. (b) The self-explanatory pin-out diagram with the Raspberry Pi is given in Figure C.1.
Figure C.1: Real-time clock interfacing with the Raspberry Pi. (c) Compile the source by following these steps: 1. cc rtc-pi.c (This creates a file name a.out) 2. mv a.out rtc-pi (rename the file) 3. chmod +x rtc-pi (Give permissions) 4. Append sudo ./rtc-pi to the /etc/rc.local file. It starts the executable on boot up to read the latest time. To set the date and time on the real-time clock module, execute: sudo ./rtc-pi CCYYMMDDhhmmss (d) When using Raspberry Pi (v.2 board), the following modifications are done to rtc.c code, for using GPIO pin 27 (GPIO pin number has changed compared to earlier revision), found online in forums. #d e f i n e SCLK OUTPUT ∗ ( g p i o+GPIO SEL2 ) &= 0xFF1FFFFFL 153
#d e f i n e SCLK HIGH ∗ ( g p i o+GPIO SET) = 0 x08000000L #d e f i n e SCLK LOW ∗ ( g p i o+GPIO CLR) = 0 x08000000L (e) A pull up resistor may be required between DAT and VCC pins, see Figure C.1. A 10K resistor is suitable.
OLSR configuration This is the OLSR configuration file, as used on all (Raspberry Pi) nodes. The changed settings have been tabulated in Chapter 6. ################################################### # v0 . 6 . 6 − MODIFIED OLSR CONFIGURATION FILE , BY SHYAM BALASUBRAMANIAN, THALES NEDERLAND B .V ################################################### # # # o l s r . o r g OLSR daemon c o n f i g f i l e # # L i n e s s t a r t i n g with a # a r e d i s c a r d e d # # This f i l e was s h i p p e d with t h e d e b i a n o l s r d package # # # # #
This f i l e i s an example o f a t y p i c a l c o n f i g u r a t i o n f o r a mostly s t a t i c network ( r e g a r d i n g m o b i l i t y ) u s i n g t h e LQ e x t e n t i o n
# Debug l e v e l (0 −9) # I f s e t t o 0 t h e daemon r u n s i n t h e background DebugLevel
# # # # #
0
I n t e r f a c e s and t h e i r r u l e s Omitted o p t i o n s w i l l be s e t t o t h e default values . Multiple i n t e r f a c e s can be s p e c i f i e d i n t h e same b l o c k and m u l t i p l e b l o c k s can be s e t .
# ! !CHANGE THE INTERFACE LABEL( s ) TO MATCH YOUR INTERFACE( s ) ! ! # ( eg . wlan0 o r e t h 1 ) : # # t h i s i s ( i n most c a s e s ) t h e o n l y c o n f i g u r a t i o n you need t o change #I n t e r f a c e ” e t h 1 ” ” e t h 0 ” ” wlan0 ” ” wlan1 ” ” ath0 ” ” ath1 ” I n t e r f a c e ” wlan0 ” { # IPv4 b r o a d c a s t a d d r e s s t o u s e . The 154
# one u s e f u l l example would be 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 # I f not d e f i n e d t h e b r o a d c a s t a d d r e s s # e v e r y c a r d i s c o n f i g u r e d with i s used # Modify t h i s a c c o r d i n g l y f o r Raspberry Pi Ip4Broadcast 192.168.255.255 # IPv6 a d d r e s s s c o p e t o u s e . # Must be ’ s i t e −l o c a l ’ o r ’ g l o b a l ’ # Ip6AddrType
s i t e −l o c a l
# IPv6 m u l t i c a s t a d d r e s s t o u s e when # u s i n g s i t e −l o c a l a d d r e s s e s . # I f not d e f i n e d , f f 0 5 : : 1 5 i s used # Ip6MulticastSite
ff05 ::11
# IPv6 m u l t i c a s t a d d r e s s t o u s e when # using global addresses # I f not d e f i n e d , f f 0 e : : 1 i s used # Ip6MulticastGlobal
ff0e ::1
# Emission i n t e r v a l s . # I f not d e f i n e d , RFC p r o p o s e d v a l u e s w i l l # be used i n most c a s e s . # Hello i n t e r v a l in seconds ( f l o a t ) HelloInterval 0.2 # HELLO v a l i d i t y time HelloValidityTime
1.6
# TC i n t e r v a l i n s e c o n d s ( f l o a t ) TcInterval 2.0 # TC v a l i d i t y time TcValidityTime
256.0
# MID i n t e r v a l i n s e c o n d s ( f l o a t ) MidInterval 18.0 # MID v a l i d i t y time MidValidityTime
324.0
# HNA i n t e r v a l i n s e c o n d s ( f l o a t ) HnaInterval 18.0
155
# HNA v a l i d i t y time HnaValidityTime # # # # # # #
108.0
When m u l t i p l e l i n k s e x i s t between h o s t s t h e w e i g h t o f i n t e r f a c e i s used t o d e t e r m i n e t h e l i n k t o u s e . Normally t h e w e i g h t i s a u t o m a t i c a l l y c a l c u l a t e d by o l s r d based on t h e c h a r a c t e r i s t i c s o f t h e i n t e r f a c e , but h e r e you can s p e c i f y a f i x e d v a l u e . Ol s r d w i l l c h o o s e l i n k s with t h e l o w e s t v a l u e .
# Weight 0
# # # # # # # #
I f a c e r t a i n r o u t e s h o u l d be p r e f e r r e d o r i g n o r e d by t h e mesh , t h e Link Q u a l i t y v a l u e o f a node can be m u l t i p l i e d with a f a c t o r e n t e r e d h e r e . In t h e example t h e r o u t e u s i n g 1 9 2 . 1 6 8 . 0 . 1 would r a t h e r be i g n o r e d . A m u l t i p l i e r of 0.5 w i l l r e s u l t in a small ( bad ) L i n k Q u a l i t y v a l u e and a h i g h ( bad ) ETX v a l u e .
# LinkQualityMult 1 9 2 . 1 6 8 . 0 . 1 0 . 5 # This m u l t i p l i e r a p p l i e s t o a l l o t h e r nodes # LinkQualityMult d e f a u l t 0 . 8
} # F i s h e y e mechanism f o r TC m es sag es 0= o f f , 1=on LinkQualityFishEye 1
# i g n o r e t o p o l o g y i n f o r m a t i o n from nodes f u r t h e r than 3 hops away # # update t o p o l o g y i n f o r m a t i o n e v e r y 3 . 0 s e c o n d s # ( on s l o w e r embedded hardware with more than 100 nodes u s e something l i k e 9 s e c ) # COMMENT THIS FOR RASPBERRY PI Node # LinkQualityDijkstraLimit 3 3.0 # IP v e r s i o n t o u s e ( 4 o r 6 ) IpVersion
4
156
# C l e a r t h e s c r e e n each time t h e i n t e r n a l s t a t e c h a n g e s ClearScreen # # # #
yes
HNA IPv4 r o u t e s s y n ta x : n e t a d d r netmask Example I n t e r n e t gateway : 0.0.0.0 0.0.0.0
Hna4 { # I n t e r n e t gateway : # 0.0.0.0 0.0.0.0 # more e n t r i e s can be added : # 192.168.1.0 255.255.255.0 } # HNA IPv6 r o u t e s # s y n ta x : n e t a d d r p r e f i x # Example I n t e r n e t gateway : Hna6 { # I n t e r n e t gateway : # :: 0 # more e n t r i e s can be added : # f e c 0 : 2 2 0 0 : 1 0 6 : : 48 } # # # #
Should o l s r d keep on r u n n i n g even i f t h e r e a r e no i n t e r f a c e s a v a i l a b l e ? This i s a good i d e a f o r a PCMCIA/USB hotswap environment . ” y e s ” OR ”no”
AllowNoInt
yes
# TOS( type o f s e r v i c e ) v a l u e f o r # t h e IP h e a d e r o f c o n t r o l t r a f f i c . # I f not s e t i t w i l l d e f a u l t t o 16 #TosValue # # # #
16
The f i x e d w i l l i n g n e s s t o u s e (0 −7) I f not s e t w i l l i n g n e s s w i l l be c a l c u l a t e d d y n a m i c a l l y based on b a t t e r y / power s t a t u s i f such i n f o r m a t i o n i s a v a i l a b l e
Willingness
7
# Allow p r o c e s s e s l i k e t h e GUI f r o n t −end 157
# t o c o n n e c t t o t h e daemon . IpcConnect { # Determines how many s i m u l t a n e o u s l y # IPC c o n n e c t i o n s t h a t w i l l be a l l o w e d # S e t t i n g t h i s t o 0 d i s a b l e s IPC MaxConnections
0
# By d e f a u l t o n l y 1 2 7 . 0 . 0 . 1 i s a l l o w e d # t o c o n n e c t . Here a l l o w e d h o s t s can # be added Host #Host
127.0.0.1 10.0.0.5
# You can a l s o s p e c i f y e n t i r e net−r a n g e s # that are allowed to connect . Multiple # e n t r i e s are allowed #Net
192.168.1.0 255.255.255.0
} # # # # #
Wether t o u s e h y s t e r e s i s o r not H y s t e r e s i s adds more r o b u s t n e s s t o t h e l i n k s e n s i n g but d e l a y s n e i g h b o r r e g i s t r a t i o n . Used by d e f a u l t . ’ yes ’ o r ’ no ’ Do not u s e h y s t e r e s i s with ETX!
UseHysteresis # # # # # # # #
H y s t e r e s i s parameters Do not a l t e r t h e s e u n l e s s you know what you a r e d o i n g ! S e t t o auto by d e f a u l t . Allowed values are f l o a t i n g point values in the i n t e r v a l 0 ,1 THR LOW must always be l o w e r than THR HIGH .
#H y s t S c a l i n g #HystThrHigh #HystThrLow
# # # #
no
0.50 0.80 0.30
Link q u a l i t y l e v e l 0 = do not u s e l i n k q u a l i t y 1 = u s e l i n k q u a l i t y f o r MPR s e l e c t i o n 2 = u s e l i n k q u a l i t y f o r MPR s e l e c t i o n and r o u t i n g 158
# Defaults to 0 LinkQualityLevel
2
# Link q u a l i t y window s i z e # D e f a u l t s t o 10 #L i n k Q u a l i t y W i n S i z e
100
# Polling rate in seconds ( f l o a t ) . # Default value 0.05 sec Pollrate
# # # # # # # # #
TC redundancy S p e c i f i e s how much n e i g h b o r i n f o s h o u l d be s e n t i n TC me ssa ge s Possible values are : 0 − o n l y send MPR s e l e c t o r s 1 − send MPR s e l e c t o r s and MPRs 2 − send a l l n e i g h b o r s d e f a u l t s to 0
TcRedundancy
# # # # # # # #
2
MPR c o v e r a g e S p e c i f i e s how many MPRs a node s h o u l d t r y s e l e c t t o r e a c h e v e r y 2 hop n e i g h b o r Can be s e t t o any i n t e g e r >0 d e f a u l t s to 1
MprCoverage
# # # # # # #
0.05
1
Ol sr d p l u g i n s t o l o a d This must be t h e a b s o l u t e path t o t h e f i l e o r t h e l o a d e r w i l l u s e t h e f o l l o w i n g scheme : − Try t h e p a t h s i n t h e LD LIBRARY PATH environment v a r i a b l e . − The l i s t o f l i b r a r i e s cached i n / e t c / l d . s o . c a c h e − / l i b , f o l l o w e d by / u s r / l i b
# C o n f i g u r a t i o n examples f o r p l u g i n s : # s e e / u s r / s h a r e / doc / o l s r d −p l u g i n s / f o r some f o r documentation 159
LoadPlugin ” o l s r d t x t i n f o . s o . 0 . 1 ” { PlParam ” p o r t ” ”2008” PlParam ” a c c e p t ” ” 1 2 7 . 0 . 0 . 1 ” }
IBR-DTN configuration This is the IBR-DTN configuration file for user settings. The changed settings have been tabulated in Chapter 6. # IBR−DTN daemon ################################################### # v0 . 1 0 − MODIFIED IBR−DTN CONFIGURATION FILE , BY SHYAM BALASUBRAMANIAN, THALES NEDERLAND B .V ################################################### # # t h e l o c a l e i d o f t h e dtn node # d e f a u l t i s t h e hostname # #l o c a l u r i = dtn : / / node . dtn # # s p e c i f i e s an a d d i t i o n a l l o g f i l e # #l o g f i l e = / var / l o g / i b r d t n / i b r d t n . l o g l o g f i l e = /home/ p i / i b r d t n / i b r d t n . l o g # # timezone o f f s e t in hours # #t i m e z o n e = +1 # # Limit t h e b l o c k s i z e o f a l l b u n d l e s . # # The v a l u e a c c e p t s d i f f e r e n t m u l t i p l i e r s . # G = 1 ,000 ,000 ,000 bytes # M = 1 ,000 ,000 bytes # K = 1 ,000 bytes # #l i m i t b l o c k s i z e = 1 . 3G # # # # # # #
Limit t h e b l o c k s i z e o f f o r e i g n b u n d l e s . F o r e i g n b u n d l e s a r e not a d d r e s s from o r t o t h e l o c a l node . The v a l u e a c c e p t s d i f f e r e n t m u l t i p l i e r s . G = 1 ,000 ,000 ,000 bytes 160
# M = 1 ,000 ,000 bytes # K = 1 ,000 bytes # #l i m i t f o r e i g n b l o c k s i z e = 500M # # Limit t h e o f f s e t o f p r e d a t e d timestamps t o a max v a l u e . # Bundles with an i n v a l i d timestamp w i l l be r e j e c t e d . # #l i m i t p r e d a t e d t i m e s t a m p = 604800 # # Limit t h e max . l i f e t i m e o f a bundle . # Bundles with a l i f e t i m e g r e a t e r than t h i s v a l u e w i l l be r e j e c t e d . # #l i m i t l i f e t i m e = 604800 # l i m i t t h e numbers o f b u n d l e s i n t r a n s i t ( d e f a u l t : 5 ) #l i m i t b u n d l e s i n t r a n s i t = 5 # bind API t o a named s o c k e t i n s t e a d o f an i n t e r f a c e #a p i s o c k e t = /tmp/ i b r d t n . s o c k # d e f i n e t h e i n t e r f a c e f o r t h e API , c h o o s e any t o bind on a l l i n t e r f a c e s #a p i i n t e r f a c e = any # d e f i n e t h e p o r t f o r t h e API t o bind on #a p i p o r t = 4550 # # enable fragmentation support # ( default is disabled ) # #f r a g m e n t a t i o n = y e s # # i f f r a g m e n t a t i o n i s enabled , i t i s p o s s i b l e t o s p l i t up # b u n d l e s l a r g e r than a s p e c i f i c l i m i t i n t o f r a g m e n t s # # l i m i t p a y l o a d = 500K # # Record t r a f f i c i n a l l c o n v e r g e n c e l a y e r s # ( t h i s i m p l i e s a p e r f o r m a n c e drawback i f e n a b l e d ) # #s t a t s t r a f f i c = y e s ##################################### # storage configuration # ##################################### 161
# # d e f i n e a f o l d e r f o r temporary s t o r a g e o f b u n d l e s # i f t h i s i s not d e f i n e d b u n d l e s w i l l p r o c e s s e d i n memory # #b l o b p a t h = /tmp #b l o b p a t h = /home/ p i / i b r d t n / b l o b s / # # d e f i n e a f o l d e r f o r p e r s i s t e n t storage of bundles # i f t h i s i s not d e f i n e d b u n d l e s w i l l s t o r e d i n memory o n l y # #s t o r a g e p a t h = / var / s p o o l / i b r d t n / b u n d l e s s t o r a g e p a t h = /home/ p i / i b r d t n / b u n d l e s # # d e f i n e s t h e s t o r a g e module t o u s e # d e f a u l t i s ” s i m p l e ” u s i n g memory o r d i s k ( depending on s t o r a g e p a t h ) # s t o r a g e s t r a t e g y . i f c o m p i l e d with s q l i t e support , you c o u l d change # t h i s to s q l i t e to use a s q l database f o r bundles . # #s t o r a g e = d e f a u l t # # Limit t h e s i z e o f t h e s t o r a g e . # The v a l u e a c c e p t s d i f f e r e n t m u l t i p l i e r s . # G = 1 ,000 ,000 ,000 bytes # M = 1 ,000 ,000 bytes # K = 1 ,000 bytes # l i m i t s t o r a g e = 500M
##################################### # convergence layer c o n f i g u r a t i o n # ##################################### # # d i s c o v e r y o v e r UDP/ IP # # You can s p e c i f y an m u l t i c a s t a d d r e s s t o l i s t e n t o f o r d i s c o v e r y announcements . # I f no a d d r e s s i s s p e c i f i e d t h e m u l t i c a s t e q u i v a l e n t o f b r o a d c a s t i s used . # discovery address = ff02 ::142 224.0.0.142 # S p e c i f y t h e t i m e o u t . I f no f u r t h e r d i s c o v e r y announcement i s r e c e i v e d # f o r x s e c o n d s , t h e daemon assume t h a t t h e node has went away . d i s c o v e r y t i m e o u t = 10 # u s e s h o r t IPND b e a c o n s #d i s c o v e r y s h o r t = 0 162
# s p e c i f y t h e d i s c o v e r y mechanism t o u s e # 0 = DTN2 c o m p a t i b l e d i s c o v e r y # 1 = IPND v e r s i o n 0 # 2 = IPND v e r s i o n 1 ( d e f a u l t ) discovery version = 2 # To d i s a b l e d i s c o v e r y announcements , s e t t h i s o p t i o n t o z e r o . # ( d e f a u l t i s 1) # #d i s c o v e r y a n n o u n c e = 0 # Enable c r o s s l a y e r d i s c o v e r y # I f d i s a b l e d t h e daemon do not d i s t r i b u t e i t s own a d d r e s s e s v i a # IPND . I n s t e a d we e x c e p t t h a t t h e r e c e i v e r e x t r a c t t h i s i n f o r m a t i o n # u s i n g t h e s e n d e r IP a d d r e s s . # #d i s c o v e r y c r o s s l a y e r = y e s # # a l i s t ( s e p e r a t e d by s p a c e s ) o f names f o r c o n v e r g e n c e l a y e r i n s t a n c e s . # n e t i n t e r f a c e s = eth0 # # Try t o c o n n e c t t o o t h e r nodes each x s e c o n d s . # This o p t i o n k e e p s c o n n e c t i o n s up a l l t h e time . # #n e t a u t o c o n n e c t = 60 # # D e f i n e s t h e i n t e r f a c e with g l o b a l i n t e r n e t a c c e s s . With t h i s d e f i n i t i o n # t h e daemon can d e t e c t i n t e r n e t a c c e s s by i t s own and might assume s p e c i f i c # nodes a s a v a i l a b l e o r u n a v a i l a b l e depending on t h e i n t e r n e t s t a t e . # #n e t i n t e r n e t = e t h 0 # # c o n f i g u r a t i o n f o r a convergence # n e t l a n 0 t y p e = tcp # n e t l a n 0 i n t e r f a c e = eth0 # n e t l a n 0 p o r t = 4556 # # # c o n f i g u r a t i o n f o r a convergence # #n e t l a n 1 t y p e = udp # #n e t l a n 1 i n t e r f a c e = e t h 0 # #n e t l a n 1 p o r t = 4556 #
l a y e r named l a n 0 we want t o u s e TCP a s p r o t o c o l l i s t e n on i n t e r f a c e e t h 0 with p o r t 4556 ( d e f a u l t )
l a y e r named l a n 1 we want t o u s e UDP a s p r o t o c o l l i s t e n on i n t e r f a c e e t h 0 with p o r t 4556 ( d e f a u l t )
163
# # TCP t u n i n g o p t i o n s # # NODELAY o p t i o n i n TCP d i s a b l e s t h e n a g l e a l g o r i t h m , i f s e t t o y e s ( d e f a u l t ) . #t c p n o d e l a y = y e s # The b u n d l e s a r e s p l i t i n t o chunks w h i l e they a r e t r a n s m i t t e d o v e r TCP. This parameter d e f i n e s t h e s i z e o f t h e s e chunks ( 4 0 9 6 i s t h e default ). #t c p c h u n k s i z e = 4096 # The t i m e o u t f o r i d l e TCP c o n n e c t i o n i n s e c o n d s . 0 = d i s a b l e d #t c p i d l e t i m e o u t = 0
##################################### # P2P c o n f i g u r a t i o n # ##################################### # # D e f i n e t h e path o f t h e w p a s u p p l i c a n t c o n t r o l i n t e r f a c e # #p 2 p c t r l p a t h = / var / run / w p a s u p p l i c a n t / wlan1
##################################### # routing configuration # ##################################### # # routing strategy # # v a l u e s : d e f a u l t | e p i d e m i c | f l o o d i n g | p r o p h e t | none # # In t h e ” d e f a u l t ” t h e daemon o n l y d e l i v e r s b u n d l e s t o n e i g h b o r s and s t a t i c a v a i l a b l e nodes . The a l t e r n a t i v e module ” e p i d e m i c ” s p r e a d a l l b u n d l e s t o a l l a v a i l a b l e n e i g h b o r s . F l o o d i n g works l i k e epidemic , but do not send t h e own summary v e c t o r t o n e i g h b o r s . Prophet f o r w a r d s based on t h e p r o b a b i l i t y t o e n c o u n t e r o t h e r nodes ( s e e d r a f t −i r t f −dtnrg−prophet −09). routing = epidemic # # f o r w a r d b u n d l e s t o o t h e r nodes ( y e s /no ) # routing forwarding = yes # 164
# S c h e d u l i n g adds a s o r t e d bundle i n d e x t o t h e daemon i n s t a n c e which i s used # t o o r d e r t h e b u n d l e s u s i n g t h e p r i o r i t y d e f i n e d i n t h e S c h e d u l i n g B l o c k and # several other i n d ic a t o rs . # #s c h e d u l i n g = no # # s t a t i c routing rules # − a rule i s a regex pattern # − format i s # # r o u t e a l l b u n d l e s f o r ” dtn : / / ∗ . moon . dtn /∗” t o dtn : / / r o u t e r . dtn #r o u t e 1 = ˆ dtn : / / [ [ : a l p h a : ] ] . moon . dtn / [ [ : a l p h a : ] ] dtn : / / r o u t e r . dtn #r o u t e 1 = dtn : / / p i 1 . dtn ∗ dtn : / / p i 2 . dtn # # s t a t i c connections # f o r c o n f i g u r e s t a t i c c o n n e c t i o n s i t i s i m p o r t a n t t o b e g i n with ” s t a t i c 1 ” # and count up ( ” s t a t i c 2 ” , ” s t a t i c 3 ” , . . . ) # ### p r o p h e t c o n f i g u r a t i o n ### #p r o p h e t p e n c o u n t e r m a x = 0 . 7 #p r o p h e t p e n c o u n t e r f i r s t = 0 . 5 #p r o p h e t p f i r s t t h r e s h o l d = 0 . 1 #p r o p h e t b e t a = 0 . 9 #prophet gamma = 0 . 9 9 9 #p r o p h e t d e l t a = 0 . 0 1 #p r o p h e t t i m e u n i t = 1 #p r o p h e t i t y p = 300 #p r o p h e t n e x t e x c h a n g e t i m e o u t = 60 #p r o p h e t f o r w a r d i n g s t r a t e g y = GRTR #prophet gtmx nf max = 30 #s t r a t e g y
#a f f e c t s how s t r o n g t h e p r e d i c t a b i l i t y i s #i n c r e a s e d on an e n c o u n t e r #t h e p r e d i c t a b i l i t y o f a n e i g h b o r on t h e #f i r s t e n c o u n t e r #l o w e s t p r e d i c t a b i l i t y when n e i g h b o r s #p r e d i c t a b i l i t i e s a r e f o r g o t t e n #Weight o f t h e t r a n s i t i v e p r o p e r t y #Determines how q u i c k l y p r e d i c t a b i l i t i e s #age #(1− d e l t a ) i s t h e maximum p r e d i c t a b i l i t y #time u n i t i n s e c o n d s #t y p i c a l time i n t e r v a l between two node #e n c o u n t e r s #t i m e o u t how o f t e n handshakes s h o u l d be #e x e c u t e d #The f o r w a r d i n g s t r a t e g y used GRTR | GTMX #Maximum t i m e s t o f o r w a r d i n t h e GTMX
##################################### # bundle s e c u r i t y p r o t o c o l # ##################################### # # the l e v e l s p e c i f i e s the s e c u r i t y c o n s t r a i n s # # 0 = no c o n s t r a i n s ( d e f a u l t ) # 1 = accept only authenticated bundles 165
# 2 = accept only encrypted bundles # 4 = accept only signed bundles # # Combination i s a l l o w e d by adding v a l u e s # e . g . 5 = a c c e p t o n l y b u n d l e s which a r e s i g n e d AND a u t h e n t i c a t e d # #s e c u r i t y l e v e l = 0 # # bab d e f a u l t key # #s e c u r i t y b a b d e f a u l t k e y = / e t c / i b r d t n / b p s e c / d e f a u l t −bab−key . mac # # key path # #s e c u r i t y p a t h = / e t c / i b r d t n / b p s e c / k e y s # # TLS f o r TCP c o n v e r g e n c e l a y e r # A u t h e n t i c a t i o n and e n c r y p t i o n ( o p t i o n a l ) s u p p o r t f o r e v e r y # t c p c o n n e c t i o n between t h e daemons . # # c e r t i f i c a t e s i g n e d by t h e a u t h o r i t y ( p u b l i c key ) #s e c u r i t y c e r t i f i c a t e = / e t c / i b r d t n / t l s / l o c a l . c r t # l o c a l TLS key #s e c u r i t y k e y = / e t c / i b r d t n / t l s / l o c a l . key # path t o t r u s t e d c e r t i f i c a t e s #s e c u r i t y t r u s t e d c a p a t h = / e t c / i b r d t n / t l s / # s e t t o ’ yes ’ i f t c p c o n n e c t i o n s w i t h o u t TLS a r e not a l l o w e d #s e c u r i t y t l s r e q u i r e d = y e s # s e t t o ’ yes ’ t o d i s a b l e e n c r y p t i o n i n t h e TLS s t r e a m s #s e c u r i t y t l s d i s a b l e e n c r y p t i o n = y e s
##################################### # time s y n c h r o n i z a t i o n # ##################################### # # s e t t o y e s i f t h i s node i s c o n n e c t e d t o a h i g h p r e c i s i o n time r e f e r e n c e # l i k e GPS, DCF77 , NTP, e t c . # #t i m e r e f e r e n c e = y e s # 166
# s y n c h r o n i z e with n e i g h b o r s # #t i m e s y n c h r o n i z e = y e s # # announce time sync c a p a b i l i t i e s i n d i s c o v e r y m es sa ges # #t i m e d i s c o v e r y a n n o u n c e m e n t s = y e s # # Parameters f o r t h e QoT a g i n g p r o c e s s . # #t i m e s i g m a = 1 . 0 0 1 #t i m e p s i = 0 . 9 #t i m e s y n c l e v e l = 0 . 1 5 # # Adjust t h e c l o c k o f t h e h o s t on each sync # #t i m e s e t c l o c k = no
##################################### # DHTNameService s e t t i n g s # ##################################### # # Enable t h e DHT, i f i t was c o m p i l e d # D e f a u l t i s no # dht enabled = yes # # Set the # Default # I f Port # #d h t p o r t
udp port , t h e DHT s h o u l d working on i s 9999 i s 0 , a random Port w i l l be c h o s e n f o r each run = 9999
# # Here you can c h o o s e a s t a t i c DHT ID , which i s v e r y common # D e f a u l t i s none −> a random ID p e r run w i l l be g e n e r a t e d #d h t i d = # # Enables DHT on IPv4 s o c k e t # Default i s yes # #d h t e n a b l e i p v 4 = y e s
167
# # Enables DHT on IPv6 s o c k e t # Default i s yes # #d h t e n a b l e i p v 6 = y e s # # Bind t h e DHT t o a s p e c i f i c IPv4 Address # D e f a u l t i s t h e any d e v i c e # #d h t b i n d i p v 4 = 1 2 7 . 0 . 0 . 1 # # Bind t h e DHT t o a s p e c i f i c IPv6 Address # D e f a u l t i s t h e any d e v i c e # #d h t b i n d i p v 6 = : : 1 # # S p e c i f y t h e f i l e , where t h e DHT can s a v e a l l good nodes # f o r f a s t e r r e s t a r t on next s e s s i o n # D e f a u l t i s no f i l e , but i t s h o u l d be s e t # #d h t n o d e s f i l e = # # Enable DNS B o o t s t r a p p i n g f o r t h e DHT # #d h t b o o t s t r a p p i n g = y e s # # DNS B o o t s t r a p p i n g by g i v i n g domain names o f wellknown nodes #d h t b o o t s t r a p p i n g d o m a i n s = [ domain ] [ . . . ] # # Example : #d h t b o o t s t r a p p i n g d o m a i n s = dtndht . i b r . c s . tu−bs . de # # D e f a u l t i s an empty s t r i n g #d h t b o o t s t r a p p i n g d o m a i n s = # # IP B o o t s t r a p p i n g from wellknown IP ( and p o r t ) a d d r e s s e s o f nodes #d h t b o o t s t r a p p i n g i p s = [ i p [ p o r t ] ] ; [ i p [ p o r t ] ] ; . . . # # Example : #d h t b o o t s t r a p p i n g i p s = 1 9 2 . 1 6 8 . 0 . 1 ; 1 9 2 . 1 6 8 . 0 . 2 8 8 8 8 ; # # D e f a u l t i s an empty s t r i n g #d h t b o o t s t r a p p i n g i p s =
168
# # B l a c k l i s t s u p p o r t o f t h e DHT can be s w i t c h on and o f f # # Default i s yes #d h t b l a c k l i s t = y e s # # Announcing m y s e l f on t h e DHT # # Default i s yes #d h t s e l f a n n o u n c e = y e s # I f t h e r a t i n g o f an incoming i n f o r m a t i o n i s lower , i t w i l l be i g n o r e d # # Default i s 1 #d h t m i n r a t i n g = 1 # # Allow announcing n e i g h b o u r s # # Default i s yes #d h t a l l o w n e i g h b o u r a n n o u n c e m e n t = y e s # # Allow a l l n e i g h b o u r s announce them t o be n e i g h b o u r t o me # For p r i v a c y r e a s o n s , you c o u l d t u r n t h i s o f f # # Default i s yes #d h t a l l o w n e i g h b o u r s t o a n n o u n c e m e = y e s # # I g n o r i n g t h e n e i g h b o u r i n f o r m a t i o n s e n t by a node , found on t h e DHT # # D e f a u l t i s no #d h t i g n o r e n e i g h b o u r i n f o r m a t i o n s = no
IBR-DTN daemon script This is the script used to start the DTN daemon. The script has minor modifications to the original available. Due credit is given to the author Morgenroth, J of IBR-DTN. The script is located in /etc/init.d/ibrdtnd. The changed settings have been tabulated in Chapter 6. #!/ b i n / sh ### BEGIN INIT INFO # Provides : # Required−S t a r t : # Required−Stop : # D e f a u l t −S t a r t : # D e f a u l t −Stop : # Short−D e s c r i p t i o n :
ibrdtnd $ r e m o t e f s $network $ l o c a l f s $ r e m o t e f s $network $ l o c a l f s 2 3 4 5 0 1 6 IBR−DTN Daemon 169
# Description : IBR−DTN daemon bundle p r o t o c o l # s t a c k f o r d e l a y t o l e r a n t networks . ### END INIT INFO # Author : Johannes Morgenroth # PATH s h o u l d o n l y i n c l u d e / u s r /∗ i f i t r u n s a f t e r t h e mountnfs . sh s c r i p t PATH=/s b i n : / u s r / s b i n : / b i n : / u s r / b i n DESC=i b r d t n d # Introduce a short d e s c r i p t i o n here NAME=i b r d t n d # I n t r o d u c e t h e s h o r t s e r v e r ’ s name h e r e PNAME=dtnd # I n t r o d u c e t h e p r o c e s s name DAEMON=/u s r / s b i n / dtnd # Introduce the server ’ s l o c a t i o n here PIDFILE=/var / run / i b r d t n /$PNAME. p i d # Path where t h e p i d f i l e i s s t o r e d SCRIPTNAME=/ e t c / i n i t . d/$NAME # Name o f t h i s s c r i p t DAEMON ARGS=”−D −p $ {PIDFILE} −−b a d c l o c k ” # Arguments t o run t h e daemon with # E x i t i f t h e package i s not i n s t a l l e d [ −x $DAEMON ] | | e x i t 0 # Exit i f e x p l i c i t l y t o ld to [ ”$ENABLED” != ”0” ] | | e x i t 0 # Read c o n f i g u r a t i o n v a r i a b l e f i l e i f i t i s p r e s e n t [ −r / e t c / d e f a u l t /$NAME ] && . / e t c / d e f a u l t /$NAME # set quiet option i f requested [ −n ”$ {DAEMON OPTS}” ] && DAEMON ARGS=”${DAEMON ARGS} $ {DAEMON OPTS} − i wlan0 ” # set user i f s p e c i f i e d in defaults [ −n ”$ {DAEMON USER}” ] && DAEMON USER START ARGS=”−−c h u i d $ {DAEMON USER}” [ −n ”$ {DAEMON USER}” ] && DAEMON USER STOP ARGS=”−−u s e r $ {DAEMON USER}” # Load t h e VERBOSE s e t t i n g and o t h e r r c S v a r i a b l e s . / l i b / i n i t / v a r s . sh # D e f i n e LSB l o g ∗ f u n c t i o n s . # Depend on l s b −b a s e (>= 3.0 −6) t o e n s u r e t h a t t h i s f i l e i s p r e s e n t . . / l i b / l s b / i n i t −f u n c t i o n s # # Function t h a t s t a r t s t h e daemon/ s e r v i c e # do start () { # c r e a t e t h e PID d i r e c t o r y PIDDIR=‘ dirname ${PIDFILE } ‘ i f [ ! −d $ {PIDDIR} ] ; then mkdir −p $ {PIDDIR} chown $ {DAEMON USER} ${PIDDIR} chgrp ${DAEMON USER} ${PIDDIR} 170
fi echo ”\ n S t a r t e d i b r d t n now . . ” # Return # 0 i f daemon has been s t a r t e d # 1 i f daemon was a l r e a d y r u n n i n g # 2 i f daemon c o u l d not be s t a r t e d s t a r t −stop−daemon −−s t a r t −−q u i e t $ {DAEMON USER START ARGS} −−e x e c $DAEMON −−t e s t > / dev / n u l l \ | | return 1 s t a r t −stop−daemon −−s t a r t −−q u i e t $ {DAEMON USER START ARGS} −−e x e c $DAEMON −− \ $DAEMON ARGS \ | | return 2 echo ” I am h e r e . . ” # Add code here , i f n e c e s s a r y , t h a t w a i t s f o r t h e p r o c e s s t o be ready # t o h a n d l e r e q u e s t s from s e r v i c e s s t a r t e d s u b s e q u e n t l y which depend # on t h i s one . As a l a s t r e s o r t , s l e e p f o r some time . } # # Function t h a t s t o p s t h e daemon/ s e r v i c e # do stop () { # Return # 0 i f daemon has been s t o p p e d # 1 i f daemon was a l r e a d y s t o p p e d # 2 i f daemon c o u l d not be s t o p p e d # other i f a f a i l u r e occurred s t a r t −stop−daemon −−s t o p −−q u i e t −−r e t r y=TERM/30/KILL/5 −− p i d f i l e $PIDFILE −−name $PNAME ${DAEMON USER STOP ARGS} RETVAL=”$ ?” [ ”$RETVAL” = 2 ] && r e t u r n 2 s t a r t −stop−daemon −−s t o p −−q u i e t −−oknodo −−r e t r y =0/30/ KILL/5 −−e x e c $DAEMON $ {DAEMON USER STOP ARGS} [ ” $ ?” = 2 ] && r e t u r n 2 # Many daemons don ’ t d e l e t e t h e i r p i d f i l e s when they e x i t . rm −f $PIDFILE r e t u r n ”$RETVAL” } # # Function t h a t s e n d s a SIGHUP t o t h e daemon/ s e r v i c e # do reload () { # # I f t h e daemon can r e l o a d i t s c o n f i g u r a t i o n w i t h o u t # r e s t a r t i n g ( f o r example , when i t i s s e n t a SIGHUP) , 171
# then implement t h a t h e r e . # s t a r t −stop−daemon −−s t o p −−s i g n a l 1 −−q u i e t −− p i d f i l e $PIDFILE −−name $PNAME ${DAEMON USER STOP ARGS} return 0 }
c a s e ” $1 ” i n start ) [ ”$VERBOSE” != no ] && log daemon msg ” S t a r t i n g $DESC ” ”$NAME” do start RETVAL=$ ? i f [ ”$VERBOSE” != no ] ; then c a s e ”$RETVAL” i n 0 | 1 ) log end msg 0 ; ; 2) log end msg 1 ; ; esac fi ;; stop ) [ ”$VERBOSE” != no ] && log daemon msg ” S t o p p i n g $DESC” ”$NAME” do stop RETVAL=$ ? i f [ ”$VERBOSE” != no ] ; then c a s e ”$RETVAL” i n 0 | 1 ) log end msg 0 ; ; 2) log end msg 1 ; ; esac fi ;; status ) s t a t u s o f p r o c ”$DAEMON” ”$NAME” && e x i t 0 | | e x i t $ ? ;; reload ) log daemon msg ” R e l o a d i n g $DESC” ”$NAME” do reload log end msg $? ;; r e s t a r t | f o r c e −r e l o a d ) # # I f t h e ” r e l o a d ” o p t i o n i s implemented then remove t h e ’ f o r c e −r e l o a d ’ a # log daemon msg ” R e s t a r t i n g $DESC” ”$NAME” do stop c a s e ” $ ?” i n 0|1) do start c a s e ” $ ?” i n 0) log end msg 0 ; ; 172
esac ∗) esac ∗)
1 ) l o g e n d m s g 1 ; ; # Old p r o c e s s i s s t i l l r u n n i n g ∗) log end msg 1 ; ; # Failed to s t a r t ;;
# Failed to stop log end msg 1 ; ; ;;
echo ” Usage : $SCRIPTNAME { s t a r t | s t o p | s t a t u s | r e s t a r t | r e l o a d | f o r c e −r e l o a d } exit 3 ; ;
esac
173
Bibliography [1] I. Robotics and A. magazine 2012, “Quadrotor open source platform comparisons,” pp. 18–44, 2012. [Online]. Available: http://www.ieee-ras.org/publications/ram [2] A. Lopez, G. Hoekstra, and M. de Graaf, “Energy efficient algorithm and dtn implementations in manets (thales group),” 2013. [3] S. Ali and A. Ali, “Performance analysis of aodv, dsr and olsr in manet,” in Proceedings on Seventh International Conference on Wireless Systems, 2009, p. 34. [4] A. Tønnesen, “Impementing and extending the optimized link state routing protocol,” 2004. [5] W. Forrest and W. Associates, “Delay- and disruption-tolerant networks (dtns) tutorial,” 2012. [Online]. Available: www.dtnrg.org [6] S. Schildt, J. Morgenroth, W.-B. P¨ottner, and L. Wolf, “Ibr-dtn: A lightweight, modular and highly portable bundle protocol implementation,” Electronic Communications of the EASST, vol. 37, 2011. [7] Arducopter project, open-source hardware and software. [Online]. Available: //ardupilot.com/
http:
[8] J. Borenstein, “The hoverbot–an electrically powered flying robot,” Ann Arbor, vol. 1001, pp. 48 109–2110, 1992. [9] C. Blum and V. V. Hafner, “An autonomous flying robot for network robotics,” in Robotics; Proceedings of ROBOTIK 2012; 7th German Conference on, 2012, pp. 1–5. [10] D. Henkel and T. X. Brown, “On controlled node mobility in delay tolerant networks of unmanned aerial vehicles,” in International Symposium on Advance Radio Technolgoies (ISART), pp. 7–9. [11] C. Blum and V. V. Hafner, “Robust exploration strategies for a robot exploring a wireless network,” Electronic Communications of the EASST, vol. 56, 2013. [12] H. H. Choi, S. H. Nam, T. Shon, and M. Choi, “Information delivery scheme of micro uavs having limited communication range during tracking the moving target,” The Journal of Supercomputing, pp. 1–23, 2013. [13] D. Akerman, “Raspberry pi in the sky, available as on nov’ 2013.” [Online]. Available: http://www.raspberrypi.org/archives/tag/dave-akerman [14] J. Villbrandt, “The quadrotors coming of age,” Comm. Mag., vol. 12, no. 2, 2010. [15] D. Heimans, D. R. Carloni, M. de Graaf, and G. Hoekstra, “Using quadcopter camera images for event protection,” University of Twente - Robotics and Mechatronics, 2012.
174
[16] P. Brisset, M. Gorraz, P. Huard, and J. Tyler, “”the paparazzi solution”, sandestine, florida,” 2006. [17] Openpilot project, open-source hardware and software. [Online]. Available: //www.openpilot.org/
http:
[18] L. Meier, P. Tanskanen, F. Fraundorfer, and M. Pollefeys, “Pixhawk: A system for autonomous flight using onboard computer vision,” in Robotics and Automation (ICRA), 2011 IEEE International Conference on, 2011, pp. 2992–2997. [19] Pandaboard, low-cost single-board computer development platform by texas instruments. [Online]. Available: http://pandaboard.org/ [20] P. Sharma, A. Kalia, and J. Thakur, “Performance analysis of aodv, dsr and dsdv routing protocols in mobile ad-hoc network (manet),” Journal of Information Systems and Communication, vol. 3, no. 1, 2012. [21] J. Macker, “Mobile ad hoc networking (manet): Routing protocol performance issues and evaluation considerations (rfc2501),” 1999. [22] C. Perkins, E. Belding-Royer, S. Das et al., “Rfc 3561-ad hoc on-demand distance vector (aodv) routing,” Internet RFCs, pp. 1–38, 2003. [23] D. Vir, S. Agarwal, and S. Imam, “Power management in optimized link state routing (olsr) protocol.” [24] S. Rana and A. Kapil, “Defending against node misbehavior to discover secure route in olsr,” in Information Processing and Management. Springer, 2010, pp. 430–436. [25] M. Nishanthy, T. SenthilMurugan, and E. Kannan, “A novel rebroadcasting algorithm for manets.” [26] Optimized link state routing group. [Online]. Available: http://www.olsr.org [27] Y. Huang, S. Bhatti, and D. Parker, “Tuning olsr,” in Personal, Indoor and Mobile Radio Communications, 2006 IEEE 17th International Symposium on, 2006, pp. 1–5. [28] Xl-maxsonar- ez series, sonar sensor. [Online]. Available: http://www.maxbotix.com/ documents/XL-MaxSonar-EZ Datasheet.pdf [29] Gps methodology and its operation. [Online]. Available: aboutGPS/
http://www8.garmin.com/
[30] Simon k firware, flash instructions. [Online]. Available: https://github.com/sim-/tgy [31] T. Luukkonen, “Modelling and control of quadcopter,” Aalto University, Tech. Rep., aug 2011. [32] S. Balasubramanian, M. Cox, and L. Waeijen, “Design and implementation of a quadcopter with visual control, 5hc99 embedded visual control,” Technical University Eindhoven, Tech. Rep., Sept 2012. [33] S. B. et al, “Stabilization of a two-axis camera mount for a uav, 5l990 internship report,” Technical University Eindhoven, Tech. Rep., Mar 2013. [34] W. Premerlani and P. Bizard, “Direction cosine matrix imu: Theory,” DIY DRONE: USA, pp. 13–15, 2009.
175
[35] M. Orsag and S. Bogdan, “Influence of forward and descent flight on quadrotor dynamics,” 2012. [36] Model 092 barometric pressure sensor, available dated 20-dec-2013. [Online]. Available: http://s.campbellsci.com/documents/us/manuals/092.pdf/ [37] Ms5611- barometric pressure sensor datasheet, available dated 20-dec-2013. [Online]. Available: http://www.meas-spec.com/downloads/MS5611-01BA03.pdf [38] A. Thiel and M. Ammann, “Anti-jamming techniques in u-blox gps receivers,” Oct. 2009. [Online]. Available: http://www.u-blox.com/en/whitepapers.html [39] R. Pickholtz, D. Schilling, and L. Milstein, “Theory of spread-spectrum communications–a tutorial,” pp. 855–884, May 1982. [Online]. Available: http://ieeexplore.ieee.org/ [40] M. Kennedy et al., The global positioning system and GIS: an introduction. Wiley Online Library, 2002. [41] Rapsberry pi homepage, os installation and camera setup. [Online]. Available: http://www.raspberrypi.org/ [42] Turbo ace, world class multicopter specialists and multi-rotor drones, available 20-dec-2013. [Online]. Available: http://www.turboace.com/ [43] Microdrones, world class multicopter design specialists, available 20-dec-2013. [Online]. Available: http://www.microdrones.com [44] K.-P. Neitzke, “Rotary wing micro air vehicle endurance.” [45] S. R. Hall, K. Y. Yang, and K. C. Hall, “Helicopter rotor lift distributions for minimuminduced power loss,” Journal of aircraft, vol. 31, no. 4, pp. 837–845, 1994. [46] Battery-energy and their comparison, http://www.allaboutbatteries.com
available 23-dec-2013. [Online]. Available:
[47] Brushless dc motors specifications from lipoly, germany. available 25-dec-2013. [Online]. Available: http://www.lipoly.de [48] Brushless dc motors specifications from rctimer. available 26-dec-2013. [Online]. Available: http://www.rctimer.com [49] S. J. Julier and J. K. Uhlmann, “New extension of the kalman filter to nonlinear systems,” in AeroSense’97. International Society for Optics and Photonics, 1997, pp. 182–193. [50] R. Mahony, T. Hamel, and J.-M. Pflimlin, “Complementary filter design on the special orthogonal group so (3),” in Decision and Control, 2005 and 2005 European Control Conference. CDC-ECC’05. 44th IEEE Conference on. IEEE, 2005, pp. 1477–1484. [51] R. .Mahony, T. Hamel, and J.-M. Pflimlin, “Nonlinear complementary filters on the special orthogonal group,” in Automatic Control, IEEE Transactions on. IEEE, 2008, pp. 1203– 1218. [52] N. Briscoe, “Understanding the osi 7-layer model,” PC Network Advisor, vol. 120, no. 2, 2000. [53] M. Meyers, Mike Meyers’ CompTIA Network+ Certification Passport. McGraw-Hill, Inc., 2009.
176
[54] Python homepage, installables and instructions. [Online]. Available: http://www.python. org/ [55] Advanced settings for configuring wireless ad-hoc modes, iwconfig. [Online]. Available: http://www.linuxCommand.org [56] Ibr-dtn homepage, originators of the ibr-dtn bundle protocol implementation, installables and instructions. [Online]. Available: http://trac.ibr.cs.tu-bs.de/ [57] Raspberry pi real-time clock, source code. [Online]. Available: http://www.hobbytronics. co.uk/download/rtc-pi.zip
177
