Universidade de Aveiro Departamento deEletrónica, Telecomunicações e Informática 2019
Rafael Alexandre
Santos Almeida
Gestor remoto de experiências com nó móvel em
infraestrutura de testes para redes sem fios
Remote experiment manager with mobile node in
test infrastructure for wireless networks
Universidade de Aveiro Departamento deEletrónica, Telecomunicações e Informática 2019
Rafael Alexandre
Santos Almeida
Gestor remoto de experiências com nó móvel em
infraestrutura de testes para redes sem fios
Remote experiment manager with mobile node in
test infrastructure for wireless networks
Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia de Eletrónica e Telecomunicações, realizada sob a orientação científica do Doutor Daniel Nunes Corujo , Investigador Doutorado do Departamento Eletrónica, Telecomunicações e Informática da Universidade de Aveiro.
o júri / the jury
presidente / president Atílio Manuel da Silva Gameiro
Professor Associado, Universidade de Aveiro
vogais / examiners committee Daniel Nunes Corujo
Investigador Doutorado do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro (orientador)
Bruno Miguel de Oliveira Sousa
Professor Auxiliar do Departamento de Engenharia Informática da Faculdade de Ciências e Tecnologia da Universidade de Coimbra(arguente)
agradecimentos Primeiro quero agradecer à minha familia que sempre me apoiou nos melhores e piores momentos. De seguida quero agradecer aos meus amigos que sempre me acompanharam ao longo da minha passagem pela vida académica e sempre me apoiaram e estiveram presentes, sem eles não teria alcançado este momento. Quero também agradecer às pessoas que passaram por mim neste capítulo da minha vida e que sem elas não teria conseguido alcançar o que alcancei.Quero também agradecer ao Miguel Lacerda e ao Paulo Gonçalves pela disponibilidade e ajuda que me deram durante estes meses.
Por fim e não menos importante, quero agradecer aos meus orientadores, professor Dr. Daniel Corujo e professor Dr. Rui Aguiar por toda a ajuda e disponibilidade que prestaram ao longo deste projeto. Esta dissertação foi realizada no âmbito do projeto de investigação PTDC/EEI-TEL/30685/2017 “5G-CONTACT - 5G CONtext-Aware Communications optimization” financiado pela FCT/MEC, e foi desenvolvida com o apoio do Instituto de Telecomunicações
Palavras-chave Rede de teste, AMazING, Nós, robô.
Resumo No Instituto de telecomunicações da Universidade de Aveiro existe uma rede de testes implementada no telhado do edifício 1. Esta rede de teste, chamada AMazING (Advanced Mobile wireless Network playGround) é constituída por 24 nós fixos mais um nó móvel que se move num robô sobre um carril. Esta rede de teste, para além de testar cenários mais tradicionais permite também testar cenários de mobilidade.
Esta dissertação de mestrado foca-se no desenvolvimento de um sistema que permita a criação de experiencias relacionadas com o robô, permitindo o seu controlo e posterior recolha e processamento dos dados. A implementação inclui ferramentas de desenvolvimento web, como Flask e Django, REST, modelagem 3D e sistemas embarcados.
Keywords Testbed, REST, AMazING, Network, nodes, Robot.
Abstract At Instituto de telecomunicações of Universidade de Aveiro was implemented a testbed in the rooftop of building 1. This testbed, called AMazING (Advanced Mobile wireless Network playGround) is composed of 24 fixed nodes and 1 mobile node that moves in a robot in a rail. This testbed apart from more traditional tests allows to testing mobility scenarios.
This master thesis focus on the development of a platform that allows the creation of experiments related to the robot, allowing its control and subsequent data collecting and processing. The implementation includes tools such as web frameworks, like Django and Flask, REST, 3D modeling and embedded systems.
Table of contents
Table of contents i
List of figures v
List of tables vii
List of acronyms ix
1 Introduction 1
1.1 Motivation . . . 1
1.2 Objectives . . . 2
1.3 Dissertation structure . . . 3
2 State of the Art 5 2.1 Wireless Testbeds . . . 5 2.1.1 AMazING . . . 6 2.1.2 w-iLab.t . . . 7 2.1.3 NITOS . . . 7 2.1.4 5G-VINO . . . 8 2.1.5 WiBed . . . 9 2.1.6 BOWL . . . 10 2.1.7 Roofnet . . . 11 2.1.7.1 ORBIT . . . 11 2.1.8 Testbeds overviews . . . 13 2.2 Device Control . . . 14 2.2.1 Internet of Things . . . 14 2.2.2 Web of Things . . . 15
2.2.3 Embedded Systems . . . 16
2.2.3.1 Raspberry pi . . . 16
2.2.3.2 Arduino . . . 17
2.3 Communication Protocols for platform interaction . . . 18
2.3.1 MQTT . . . 18 2.3.2 DDS . . . 19 2.3.3 XMPP . . . 20 2.3.4 AMQP . . . 20 2.3.5 CoAP . . . 21 2.3.6 REST . . . 21
2.3.6.1 Interfaces in Testbeds with REST . . . 23
2.4 Web design frameworks . . . 25
2.4.1 Django . . . 25 2.4.2 Flask . . . 26 3 Implementation 27 3.1 Starting Point . . . 27 3.2 Architecture Overview . . . 30 3.3 Web Server . . . 32 3.3.1 Frontend . . . 32 3.3.1.1 Interface . . . 32 3.3.1.2 Communication . . . 38 3.3.2 Backend . . . 39 3.4 Base Station . . . 40
3.4.1 Robot RESTfull Server . . . 40
3.4.2 Robot Manager module . . . 41
3.4.3 Robot communication module . . . 43
3.5 Communication . . . 46
3.6 Hardware . . . 48
3.6.1 Hardware System Problems . . . 48
3.7 3D modeling . . . 48
3.7.1 Base Station . . . 49
3.7.2 Robot structures . . . 50
4 Results 53 4.1 Position tests . . . 54 4.2 Velocity tests . . . 55 4.3 Acceleration tests . . . 57 4.4 Experience tests . . . 59 4.5 Stop tests . . . 60 4.6 Temperature tests . . . 61 4.7 Usability Tests . . . 62 5 Conclusion 65 5.1 Future Work . . . 66 References 67
List of figures
2.1 Advance Mobile wireless playGrouNd (AMazING) physical architecture[2]. 6
2.2 AMazING node[2]. . . 7
2.3 NITOS LTE Testbed Architecture;[11]. . . 8
2.4 indor/outdor testbeds and COST Long Term Evolution (LTE) macro-cell [10]. 9 2.5 WiBed architecture [12]. . . 10
2.6 A map of Roofnet. Each dot represents a wireless node, [15]. . . 11
2.7 ORBIT model of experiment [16]. . . 12
2.8 Orbit Architecture [16]. . . 13
2.9 projected Internet of Things (IoT) devises growth [19]. . . 14
2.10 IoT conections (Bilions)[20]. . . 15
2.11 Rasbperry pi General Purpose Input/Output (GPIO) schematic [22]. . . . 16
2.12 MQTT communications. . . 18 2.13 DDS Architecture. . . 19 2.14 DDS communication architecture [27]. . . 19 2.15 AMQP architecture [31]. . . 20 2.16 Rest request/response. . . 22 2.17 loT-LAB Infrastructure[34]. . . 23
2.18 Django web application architecture. . . 25
3.1 Robot and rail. . . 27
3.2 Robot schematics. . . 28
3.3 Robot control and communication boards. . . 28
3.4 AMazING architecture. . . 30
3.5 Deployment Diagram. . . 31
3.6 Use case. . . 33
3.8 Home page. . . 34
3.9 Login page. . . 34
3.10 Experiment page. . . 35
3.11 Example of an experiment. . . 35
3.12 Alert window for excessive velocity. . . 36
3.13 The page where the user can have access to the experiment data. . . 36
3.14 Example of data view. . . 37
3.15 Admin interface page. . . 37
3.16 Log file. . . 38
3.17 Backend architecture. . . 39
3.18 URL example with endpoints and parameters. . . 41
3.19 Manager logic. . . 42 3.20 Median. . . 43 3.21 It referential 1. . . 44 3.22 It referential 2. . . 44 3.23 Position grid. . . 46 3.24 Interaction diagram. . . 47
3.25 Base Station (BS) case view. . . 49
3.26 BS open view(left) and full assembled(right). . . 49
3.27 BS GPS support. . . 50
3.28 Robot electronic case. . . 50
3.29 Robot antenna supports. . . 51
3.30 ventilation duct. . . 51
4.1 Readings from 1h. . . 54
4.2 Velocity read from robot vs GPS. . . 55
4.3 Average between the GPS and robot velocity. . . 56
4.4 Graphics of multiple measures for different velocities. . . 57
4.5 Graphics average value with pattern deviation bars. . . 58
4.6 Data from a experiment. . . 59
4.7 Stop distance for different velocities. . . 60
4.8 Temperature variations during 1h. . . 61
4.9 Responses for the experiment maker . . . 62
4.10 Responses for the Admin interface. . . 63
List of tables
2.1 Testbeds overview. . . 13
3.1 Table component. . . 28
3.2 Table boards component. . . 29
3.3 Used pins and respective GPIOs. . . 29
4.1 Experiment GPS vs Robot measure. . . 55
4.2 Experiment instructions. . . 59
List of acronyms
5G-VINO 5G Virtual Infrastructure provisioning over NITOS testbed AMazING Advance Mobile wireless playGrouNd
AMQP Advance Message Queuing Protocol BOWL Berlin Open Wireless Lab Network
BS Base Station
CoAP Constrained Application Protocol CPU central processing unit
DDS Data Distribution Service FPGA Field-programmable gate array
GDS Global Data Space
GPIO General Purpose Input/Output GPU graphics processing unit
HTML HyperText Markup Language HTTP Hypertext Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure IoT Internet of Things
IT Institute of Telecommunications JSON JavaScript Object Notation
LTE Long Term Evolution
MQTT Message Queuing Telemetry Transport
MVC Model-View-Control
NITOS Network Implementation Testbed using Open Source platforms PoE Power over Ethernet
QoS Quality of Service
REST REpresentational State Transfer SFC Service Function Chaining
SoC system on a chip
SPI Serial Peripheral Interface TUB Technische Universitat Berlin
UART Universal asynchronous receiver/transmitter UMTS Universal Mobile Telecommunications System UPC Universitat Politècnica de Catalunya
URL Uniform Resource Locator UTH University of Thessaly
WoT Web of Things
Chapter 1
Introduction
1.1
Motivation
The capacity of information transmission from one point to another is one of the innovation motors of humanity. Starting at the first words spoken by a hominid, we have been pulling the limits of distance, quality and quantity of information transmitted, considering devices such as the telegraph, the telephone and today satellite telecommunications, allowing to send messages to every point of the globe. One of the biggest technology foundations from the last century was the evolution from wired connections to wireless connections.
Nowadays, wireless technology has become essential to our modern society, being present in sectors such agriculture, industry, transportation or medicine. The world is becoming more connected, with concepts like smart Homes, smart cities, industry 4.0, automated cars and 5G becoming a reality at a fast pace. This has caused increased pressure in wireless technology in recent years.
Due to this pressure, simulation tools, experimental networks, and emulation tools have become essential to researchers to validate and develop new technologies. The simulation method has been widely used in the research community in the last years [1]. This method is based on mathematical models that mimic a real environment, allowing a low cost and flexible implementation to the researchers. Meanwhile, the systems have become more complex each day, making the acquired data less trustworthy at the eyes of the research community [2]. Another approach is emulation, which is a hybrid method based on hardware and software technologies. It can simulate the network behavior using real components combined with simulated ones, all running in a laboratory environment [3].
CHAPTER 1. INTRODUCTION
This option offers a degree of realism and replicability when making experiments, but in certain situations, it can’t recreate the real world.
Simulation and emulation present tightly controlled test environments to run repeatable tests, but losing scale and realism [4]. The last approach is the use of experimental networks(testbeds), which allows to achieve a high level of realism[5]. Testbeds try to create a bridge between the simulation and the real implementation. They have the capacity of remote configuration and monitoring. These testbeds bring some problems, such as high development and maintenance cost and operating difficulties. Another problem in this approach is the difficulty in reusing this structure for experiments from other users, resulting in falling into disuse and becoming a waste of resources and money.
This dissertation focuses on the improvement of an existing testbed, developing a new element that will increase the range of possible experiments.
1.2
Objectives
The objective of this dissertation is to develop a system capable of deploying experiments and collecting data from a robot moving on the rooftop of the IT building. The system should have a user-friendly web interface, capable of displaying and downloading the experiment data. The system needs to have an authentification mechanism. For creating an experiment the user needs to be capable of setting parameters like velocity, time and direction. Is also required to have an admin interface capable of managing the system. This system will be implemented in the AMazING testbed.
CHAPTER 1. INTRODUCTION
1.3
Dissertation structure
In order to familiarize the reader with the technologies and platforms, it was described in Chapter 2 some of the state of art testbeds, some resource exchange protocols, and the technologies used in this dissertation. This chapter presents to the reader the necessary background for the chapters that follow.
In Chapter 3, the reader is contextualized about the moving robot. Chapter 3 also explains the solution adopted, it shows the used methods and the system architecture. In this chapter is also discussed in detail all the components of the system. In this chapter is also described the hardware interventions and 3D designed parts needed for the robot.
Chapter 4 shows and discusses the obtained results.
Chapter 2
State of the Art
This chapter will discuss some existing testbeds, as well as the main technologies that were used in this dissertation, along with potential alternatives to them.
2.1
Wireless Testbeds
Testbeds became a major tool for the development of new network technologies. Until now, most experimental research work has been run above software simulations, due to complications of conducting real experimentations.
It is extremely difficult to conduct an experiment and have reproducibility in real wireless environments, apart from the high cost of running such a test, because of equipment and human resources cost. For this reason, simulation tools have been widely used to deploy such studies in a controlled way with far less effort. Nevertheless, with increasingly complex systems, the research community has questioned in recent years the accuracy of such simulations, based on models of the wireless reality [2]. This drove to an increased interest in using testbeds where wireless studies could be carried under more realistic – but still controllable - conditions. Such testbeds establish an intermediate step within simulations/emulations and a full-scale prototype [2]. The goal of such testbeds is to give the means for the research community to validate their concepts and theories in an environment that better equals a real scenario. Network testbeds are designed to offer environments to researchers and practitioners in which experimental systems, configurations, and protocols can be carefully tested and evaluated [6].
Network testbeds in current use can be differentiated by their particular systems, level of control and "realism" that they offer to users [6]. Currently, multiple wireless testbeds
CHAPTER 2. STATE OF THE ART
exist around the world, capable of conducting experiments such as NITOS, the University of Thessaly (UTH) testbed or the ORBIT from Rutgers University. In the next section, those and other testbeds will be described more closely, along with their strengths and weaknesses.
2.1.1
AMazING
AMazING is a testbed deployed in the rooftop of the Institute of Telecommunications (IT) at Aveiro. It consist of 24 exterior fixed nodes covering an area of over 1200 m2, being
the nodes spawn with 8m between each neighbor [2]. Figure 2.1 shows the implemented grid and server architectures.
Figure 2.1: AMazING physical architecture[2].
This testbed possesses a Monitoring function that provides statistics about the node operation, such as memory consumption, CPU load, temperature and fan speed. Apart from the Monitoring function, the system also has a Scheduling function that triggers actions at specific time events [2].
Figure 2.2 shows one of the existing nodes. These nodes operating system is loaded remotely using tools such as PXE.
CHAPTER 2. STATE OF THE ART
Figure 2.2: AMazING node[2].
This testbed differentiates itself by offering the option of having a mobile node that allows the user to create new scenarios closer to the real world, such as transportation. This mobile node is supported by a robot that moves around in a fixed rail at the rooftop of IT.
This was the platform that was used as the base for the work presented in this dissertation.
2.1.2
w-iLab.t
The w-iLab.t is a large-scale generic wireless experimentation facility belonging to thr CREW project [7]. This testbed consists of more than 260 wireless nodes and was installed at two different locations, each wireless node has multiple built-in wireless technologies, such as IEEE 802.15.4, Wi-Fi a/b/g(/n), and on some devices Bluetooth [7] as well. W-iLab.t gives access to software defined radio platforms and also uses them to characterize the wireless environment during an experiment [7].
w-iLAt.t enable experiment design, scheduling, collecting and processing of the experiment data in a user-friendly way [7].
2.1.3
NITOS
Network Implementation Testbed using Open Source platforms (NITOS) is a wireless testbed with 50 outdoor nodes (WiFI-enabled), created by UTH [8]. NITOS can be accessed remotely and publicly to researchers that want to experiment. It requires registration and being accepted by the testbed administrators [8].
CHAPTER 2. STATE OF THE ART
outdoor and indoor testbed, an OpenFlow testbed, a WiMAX testbed, a LTE testbed, a 3G testbed with femtocells, a Software Defined Radio testbed, a Wireless Sensor Network Testbed (Fixed positions (building-scale), and scenarios such as Mobile bikes (city-scale) or Rural areas (agricultural deployment))[9].
NITlab built up a reservation and control software to be used in NITOS, called NITOS Scheduler. It has a web application dedicated to testbed users[8]. In the Scheduler’s backend, there are two important functions: the Scheduler’s interaction with the Extensible Message and Presence Protocol (XMPP) framework used in OMF and the spectrum slicing framework [8]. The NITOS scheduler allows resource slicing of the testbed and is in charge of resource reservation, thus allowing parallel experimentation of multiple users [9].
NITOS testbed is one of the biggest single-site open experimental facilities in Europe, allowing users to take advantage of highly programmable equipment [10]. Figure 2.3 shows the NITOS architecture, showing the devices server connections.
Figure 2.3: NITOS LTE Testbed Architecture;[11].
2.1.4
5G-VINO
5G Virtual Infrastructure provisioning over NITOS testbed (5G-VINO) is a testbed build over NITOS testbed,located in UTH. 5G-VINO will allow the evaluation of multiple vertical 5G applications, such as wireless eHealth critical applications, cloud based Virtual/Augmented reality applications, smart city and wireless home entertainment [10].
CHAPTER 2. STATE OF THE ART
Its exists in three different localizations of the testbed in the city of Volos, Greece, being possible to combine each other to create a rich experiment environment [10]. Figure 2.4 shows the inside and outside nodes.
Figure 2.4: indor/outdor testbeds and COST LTE macro-cell [10].
5G-VINO is composed by over 100 nodes equipped with IEEE 802.11 a/b/g/e/n/ac compatible equipment, highly programmable LTE macrocells, multiple femtocells, open source LTE equipment, WiMAX base stations, OpenFlow hardware switches, Field-programmable gate array (FPGA) boards and multiple WSN clusters [10].
This testbed can deploy large types of experiments relevant in 5G, including Mobile Edge Computing, with services being deployed at the edge the wireless network and reduced latency to access of content, experiments measure the impact of different transport solutions for the functional split of the base station stack, end-to-end system virtualization and orchestration, as well as Service Function Chaining (SFC) [10].
2.1.5
WiBed
WiBed is a platform for implementing and managing testbeds for experiments based on mesh networks built on top of COTS IEEE802.11 routers [12]. WiBed testbed is composed of 20 exterior nodes that have been deployed over two buildings of Universitat Politècnica de Catalunya (UPC) [12].
In figure 2.5, it is observable that the testbed nodes form a mesh network with access to an external server accessible through one or more gateway nodes[12]. The testbed management system adopted a server-client model with the testbed controller being the exclusive way of external interaction with the testbed [12]. The WiBed controller works as a web server (implemented with Flask framework) with a REST API endpoint for node management but also a web interface and a REST API for interaction with the users[12].
CHAPTER 2. STATE OF THE ART
Figure 2.5: WiBed architecture [12].
2.1.6
BOWL
The Berlin Open Wireless Lab Network (BOWL) project at Technische Universitat Berlin (TUB) provides an outdoor WiFi network which can be used for Internet access as well as a testbed for wireless research. It has a network with over 40 outdoor nodes which allows experimentation and grant Internet access at the same time[13].
The outdoor network is composed of over 60 nodes powered by Power over Ethernet (PoE), deployed in the roof of multiple building in TUB [13].The systems are built using three different architectures, namely ARM, MIPS, and x86, supporting multiple IEEE 802.11 a/b/c/g/n radio interfaces [12] and wired Ethernet interfaces. Each node runs OpenWTR, which can manage the whole configuration of the operating system[13].
The central controller uses a web-based front-end application to configure a database which can be pushed to the nodes by an end user and that configuration is applied in the first boot through an auto-configuration mechanism [13].
CHAPTER 2. STATE OF THE ART
2.1.7
Roofnet
Roofnet is composed of over 40 nodes spread in the rooftops of the city of Cambridge, covering an area of a few square kilometers [14]. Each individual node consists of a single 802.11b radio, an omni-directional antenna and a computer running a special software [15]. In figure 2.6 is observable a map of the testbed.
Figure 2.6: A map of Roofnet. Each dot represents a wireless node, [15].
Users can connect their computers to the Ethernet port on their local node to obtain access to the Internet [15] and that user with a separate wired Internet connection should be capable to share that connection with other users easily [14]. The Roofnet software, which is based on the Click Modular Router keeps state about each TCP flow and forwards traffic to the gateway node which had the best route when the flow was initiated [15]. 2.1.7.1 ORBIT
ORBIT is a experimental network, created by WINLAB, Rutgers University, composed by two different testbeds.
The first is an indoor network consisting of 400 nodes arranged in a 20 by 20 grid separated by about 1 meter between neighboring nodes [16]. Every node is built on a conventional PC platform with multiple wireless and wired network interfaces [16]. The lab-based wireless network emulator was built using a new approach comprising of a large
CHAPTER 2. STATE OF THE ART
2-dimensional array of static 802.11x radio nodes, which can be dynamically interconnected into network topologies for wireless network tests with the capacity of reproducibility for quantitative evaluation of several new protocols [17].
The second testbed was deployed with similar nodes in an area of approximately 1.5 square miles [16]. Some of these nodes have been deployed on campus buses to provide mobility with fixed routes and a fixed schedule [16]. The second testbed also carries a programmable Universal Mobile Telecommunications System (UMTS) base station with individual network interfaces on a subset of mobile and stationary nodes [16]. The system also has various devices capable measuring traffic and interference across a significant portion of the electromagnetic spectrum [16].
Figure 2.7: ORBIT model of experiment [16].
Figure 2.7 shows an overview of the services available in the testbed. In figure 2.8, the different elements of the grid testbed and the numerous networks connecting it are displayed. The “Data” port can be only used for experiments [16]. All control traffic, such as communication within the Node Handler and all its Node Agents, as well as measurements, use the Control port [16]. At the same time, the Control port gets up at boot time with an IP indicating its location in the grid [16].
CHAPTER 2. STATE OF THE ART
Figure 2.8: Orbit Architecture [16].
2.1.8
Testbeds overviews
The following table (2.1) summarizes the main characteristics of the analyzed testbeds of the previous subsections, regarding the number of nodes, interface availability, testbed placement localization and operational status.
Number of Nodes Interface Inside/outside Localization Still Operating
w-iLab.t 260 Yes I Zwijnaarde, Belgium Yes
NITOS 50 indoor + 50 outdoor Yes I/O University of Thessaly, Greece No
5G-VINO +100 Yes I/O University of Thessaly, Greece Yes
WiBed 260 Yes O Universitat Politècnica de Catalunya Yes
BOWL 40 Yes O Technische Unirversitat Berlin, Germany No
Roofnet 40 No O MIT, USA No
ORBIT 400 x 2 Yes O Rutgers University, USA Yes
AMazING 24 fixed + 1 mobile Yes O Instituto de Telecomunicações, Portugal Yes
CHAPTER 2. STATE OF THE ART
2.2
Device Control
In the development of new generation testbeds, a set of technologies have become widely used. Technologies such as machine-to-machine (M2M), IoT, and Web of Things (WoT) have become major methodologies in the development of new state of the art testbeds and systems where it is necessary to connect physical elements to the Internet.
This section will discuss these methodologies and real-life examples of its use.
2.2.1
Internet of Things
To date, the large majority of the Internet’s global connections are devices used directly by humans, such as computers and mobile handsets [18]. In a not distant future, every object can be connected [18]. Things can interchange information by themselves and the number of devices connected to the Internet will be much larger than the number of humans, thus becoming the minority of generators and receivers of traffic [18].
Figure 2.9: projected IoT devises growth [19].
In figure 2.9 and 2.10, it is possible to observe the forecast growth in the upcoming years, passing from 5.6 billion in 2016 to 18.1 in 2022, a growth exceeding 300%.
CHAPTER 2. STATE OF THE ART
Figure 2.10: IoT conections (Bilions)[20].
Nowadays, this concept is being implemented in a wide range of applications. Example are buildings ( controlling features such as temperature, illumination, and domestic appliances such as boilers, ovens, washing machines, etc.), in agriculture (monitoring the well-being of crops and animals), urban areas (monitoring parking, trash, illumination, traffic, public water use, etc), health ( monitoring health, such as heartbeat and sugar levels, detecting falls and air poisoning), monitoring elderly people with degenerative diseases, etc. being limited by the human imagination.
2.2.2
Web of Things
IoT essentially fall upon linking everything to the Internet by giving it an IP address, making it possible for those devices to exchange data more easily with each other, but without any guarantee of the significance of data received.
WoT has brought into IoT Web protocols such as Hypertext Transfer Protocol (HTTP), which is a standardized way to transfer files, such as images or text, in one way that all machines in the wed could recognize.
An example of real-life implementation of this methodology happened in Japan. In 11 March 2011, after the nuclear leakage accident at Fukushima Dai-ichi Nuclear Plant caused by a tsunami, population and academics started to have concerns about radiation levels [21]. A Japan Geigermap was then been created by combining the Google Map web service and Geiger counter readings [21].
In the development of the AMazING testbed, the WoT methodology has had a major impact, being essential to the interconnection of the robot and the web service, allowing them to exchange data and instructions.
CHAPTER 2. STATE OF THE ART
2.2.3
Embedded Systems
Embedded systems are composed of a computer system with a specific function within a bigger machine or system, often with real-time computing integrated. They are a very versatile technology, adapting easily to several situations.
Embedded systems are the ideal solution to interconnect several systems such as multiple sensors, web servers, and control systems. Because of that, it was chosen for the task at hand. Nowadays, two widely used board are the Raspberry Pi1 and Arduino2.
2.2.3.1 Raspberry pi
Raspberry Pi is a one board computer series, created by the Raspberry Pi Foundation, in the United Kingdom. Multiple models were developed with a common architecture, a Broadcom system on a chip (SoC) with an integrated ARM-compatible central processing unit (CPU), an on-chip network board and on-chip graphics processing unit (GPU), USB ports and an HDMI port.
This board is well known by being versatile, low-cost and easy to program and use. It has a set of GPIO ( figure 2.11), creating a broad range of possible options, such as connecting sensors, communication boards, motors, etc. These GPIOs can be instantiated as digital inputs or outputs, being some reserved for particular functions, such as Universal asynchronous receiver/transmitter (UART).
Figure 2.11: Rasbperry pi GPIO schematic [22].
This board is able to run an operating system based on Linux, that allows to operate the raspberry pi as a computer and make it host servers and management tools, that enable to schedule and process data coming from external sources.
1https://www.raspberrypi.org/ 2https://www.arduino.cc/
CHAPTER 2. STATE OF THE ART
2.2.3.2 Arduino
Arduino boards represent another option for prototyping available in the market. Just as Raspberry Pi, it has multiple models with different specifications for different objectives. This board is a low-cost and versatile option for embedded systems.
Different from Raspberry Pi, Arduino boards have apart from digital GPIOS, analog ports, that allow a large range of options when choosing peripheral components, but on the other hand, Arduino doesn’t have an operating system.
CHAPTER 2. STATE OF THE ART
2.3
Communication Protocols for platform interaction
This section collects a set of message exchange protocols used in the testbeds referred in chapter 2.1 or widely used in the market.
2.3.1
MQTT
Message Queuing Telemetry Transport (MQTT) is a light message protocol used in sensor and small mobile devices, optimized for untrusted TCP/IP networks or with high latency [23]. MQTT is considered a M2M connectivity protocol [23]. It is helpful for connections with isolated locations where a reduced code footprint is needed and/or network bandwidth is at a premium. [23].
This protocol enables the implementation in severely restricted hardware, in limited bandwidth and high latency systems [24]. Its flexibility allows to support multiple scenarios for devices and services in IoT.
Figure 2.12: MQTT communications.
In figure 2.12, client A requests a connection with the server (broker) using the method "Connect". Once the request is accepted it will send a "Connack" as an acknowledgement of connection. Requesting a message is performed through the method "Subscribe" and the download/upload is executed using the method "Publish". To finish the connection the client uses the method "Disconnect".
CHAPTER 2. STATE OF THE ART
2.3.2
DDS
Data Distribution Service (DDS) is an object management group (OMG) data-centric middleware model for real-time M2M communication that employs a broker-less architecture [25].This method relies on multicasting to give various quality of service (QoS) guarantees and reliability control abilities even in scenarios that require massive fan-outs [25].
Figure 2.13: DDS Architecture.
Figure 2.13 represents the architecture of a DDS system, where data writers publish the data to the Global Data Space (GDS) and those are obtained by the subscribers. A key characteristic of the DDS architecture is that information consumers and producers are decoupled in space (providers and consumers don’t need to be directly connected), in platform (providers and consumers can be developed in different languages, operating systems, and hardware architectures ), and in time (is not necessary simultaneous end-point availability) [26].
Designed as a networking middleware to bypass the disadvantages of centralized publish-subscribe architecture, DDS is a TCP-based protocol that emphasizes decentralized nodes of clients and allows them to identify themselves as subscribers/publishers through a localization server [27].
CHAPTER 2. STATE OF THE ART
Figure 2.14 shows the behavior of the DDS communication, DDS node self-discovery through a network and exchange data anonymously based on topics.
2.3.3
XMPP
XMPP is a set of open XML technologies for real-time communication created by the Jabber open-source community and formalized by the IETF, continuously extended through the standards process of the XMPP Standards Foundation data[28]. XMPP supports presence,instant messaging, structured conversation,multi-party chat, lightweight middleware, content syndication, voice and video calls, and generalized routing of XML data [29].
Protocol stacks are available for major programming languages and device platforms including Android, iOS, Java and JavaScript [30].
2.3.4
AMQP
Advance Message Queuing Protocol (AMQP) is a publish/subscribe protocol similar to MQTT, where AMQP has the advantage of storing data and then forward it, and this feature ensures reliability used at network disruptions[31].
Figure 2.15: AMQP architecture [31].
Figure 2.15 shows the publish/subscribe components and the division broker into two part exchange and queue.
Queues are based on pre-defined tasks and condition and it’s basically sending that message to subscribers who request that data [31].
CHAPTER 2. STATE OF THE ART
2.3.5
CoAP
Constrained Application Protocol (CoAP) is an alternative for communication rather than HTTP, used for low power and low memory embedded systems, being a UDP based RESTful protocol [27]. It employs a request/reply structure with low overhead and low degree of optional Quality of Service (QoS) [27]. It is intended for constrained networks with low overhead and lower footprint [31]. CoAP fundamentally supports a peer-to-peer method of communication but can be extended to support one-to-many functions via the use of IP multicast [27].
2.3.6
REST
REpresentational State Transfer (REST) is a set of policies that define how Web standards, such as HTTP and Uniform Resource Locator (URL),should be used[32].
The basic concept of REST everything is modeled as a “resource”, or HTTP resources, with a URL [21]. REST is designed based on truly understanding HTTP protocol. In REST, HTTP is a state transfer protocol different from a data transport protocol, but not only can uniquely find a resource but also notify us how to operate the resource. REST mandates that a request and response are performed through the following four HTTP operations [33]:
• GET, using it to obtain the resource without changing it. • POST, using it to create a new resource.
• PUT, using it to update the resource with the desired data, or create it at the defined
URL in case it doesn’t initially exists.
• DELETE, using it to to delete a resource.
Figure 2.16 shows how the request/response operations works. When the Client requests a GET, it receives the requested resource without removing it from the Server. In case the user makes a POST request, it will create a resource directory for it. In the case of a PUT request, the resource will be added on the existing repository. At last, when a DELETE request is made, the resource will be discarded.
CHAPTER 2. STATE OF THE ART
CHAPTER 2. STATE OF THE ART
2.3.6.1 Interfaces in Testbeds with REST
Since REST protocol was the chosen for AMazING, in this section is referred testbeds that use it. FIT IoT-LAB and SmartSantander are two working testbeds using REST as a resource exchange protocol.
2.3.6.1.1 FIT loT-LAB
FIT loT-LAB testbed, an open testbed formed of 2728 low-power wireless nodes and 117 mobile robots accessible for experimenting with large scale wireless loT technologies, extending from low-level protocols to advanced Internet services [34].In figure 2.17 is noticeable that resources sharing is built in REST.
Figure 2.17: loT-LAB Infrastructure[34].
2.3.6.1.2 SmartSantander
Another important large-scale IoT testbed is SmartSantander, consisting of nearly 20,000 nodes placed in different cities across Europe [35].
The SmartSantander project mainly targets the creation of a European experimental test facility for the experimentation and research of architectures, services, key enabling technologies and applications for the IoT at the smart city subject [36].
At the portal server level, they use REST for the resource component and REST interface for querying and retrieval of IoT resources based on a user’s set of criteria [36].
The use of REST makes it possible for exchange data between client and server side. An example of that is HyperCat, which introduces standard specifications to allow servers
CHAPTER 2. STATE OF THE ART
to expose JavaScript Object Notation (JSON)-based hypermedia catalogs as collections of URLs. Thus, IoT clients can explore data available on servers applying RESTful methods on Hyper Text Transfer Protocol Secure (HTTPS) and JSON formats [35].
2.3.6.1.3 REST and the AMAzING
The choice of REST was due to multiple reasons. It has high flexibility, agility, and is convenient since it is a straightforward protocol capable of being extended to any server/client architecture, due to its HTTP/HTTPS protocols support.
The use of URLs allows standardized access to the server resources, making the transport and storage of data less complex. In addition, it is extremely scalable, easily adding new functions to the system. Another crucial factor is its popularity between web developers and companies, such as Alphabet(Google), Facebook and Twitter.
CHAPTER 2. STATE OF THE ART
2.4
Web design frameworks
In this section, the two python web frameworks used in this dissertation will be presented. Django and Flask are two very popular web frameworks in the market.
2.4.1
Django
Django is an open-source web frame used to develop web applications. It is based in the Model-View-Control (MVC). MVC is a software methodology that split the data representation from the user interaction. Each Django application is composed of one or more apps, each app is similar to a module that can be added or removed without compromising the system. Normally an app is constituted by three base files, those are "models.py","views.py" and "urls.py".
"Models.py" holds the database description represented by a class. This class is called a model and using it allows to get, add or delete resources from the database. The "views.py" is where the page logic is built. It is possible to render HyperText Markup Language (HTML) from the backend. At last the "urls.py" file is responsible for linking the URL to the corresponding views.py function.
CHAPTER 2. STATE OF THE ART
Django manages to build an application from backend up to frontend. To connect both parts Django has a mechanism called channels. Channels extend Django abilities beyond HTTP - to handle WebSockets, IoT protocols, chat protocols, and more [37]. To take use of the channel’s properties it is necessary to add a new file to the app, called "consumers.py". This allows creating an abstraction making them less complex to use. In this file it is possible to use mechanisms like REST. In figure 2.18 it is shown a typical architecture for a Django web application
Django allows to install open-source apps in a simple manner, for example, user authentication, that allows to build in an easy way an authentication system for the application. Django uses Jinja2 as a template engine.
Django is most appropriate for complex systems. It has tools like Django Admin and Django templates. These tools allow an easier and more controlled management of the web application and the creation of HTML pages in a simpler and faster way. Because of these advantages, it was chosen to build the web application.
2.4.2
Flask
Flask is a microframework which does not require special tools or libraries. Flask is flexible and easy to use because it provides a simple model for the development of web applications. Flask has two base methods, the WSGI WerkZeug, and Jinja2.
WSGI WerkZeug is a library specific for WSGI apps. This has the capacity of the basic implementation of the methodology WSGI for request, responses, cookies, HTTP, URL routing, and cache management. Jinja2 is a template engine, that allows the use of marks to render templates.
Flask was used in this dissertation on BS as a RESTful server. The choice was due to the fact that it is the best solution for lightweight applications. Flask has a minimalist design, that allows greater velocity and uses less CPU processing power than Django. These characteristics make it the best option to use in a limited resource environment, such as a Raspberry Pi.
Chapter 3
Implementation
3.1
Starting Point
On the rooftop of the IT at Aveiro a wireless testbed called AMazING was previously implemented. This testbed is composed by 24 wireless nodes (figure 2.2) and a mobile node built in a robot (figure 3.1a) that moves in a rail constructed at IT’s rooftop (figure 3.1b).
(a) robo (b) rail
Figure 3.1: Robot and rail.
Figure 3.2 shows the robot schematics and table 3.1 it’s components. The robot is constituted by a motor built-in a wheel (1). The robot contains a control board responsible for communication, control, and localization (2). It is powered up by five 12V batteries (4), all this in a metal frame with support wheels (3) to fix the system to the rail. The motor is capable of achieving close to 30km/h when working unmounted from the rail.
CHAPTER 3. IMPLEMENTATION
Figure 3.2: Robot schematics.
Number Component 1 Wheel and motor 2 Electronic box 3 Fixation wheel
4 Battery
Table 3.1: Table component.
This robot holds a control board, figure 3.3a. This board holds control and communication mechanisms. The BS communication board, figure 3.3b, is responsible for the communications between the BS and the robot. Table 3.2 shows each different component.
(a) Robot board (b) BS communication board
CHAPTER 3. IMPLEMENTATION Number Component 1 Arduino 2 Bluetooth module 3 GPS module 4 RF module 5 Bluetooth module 6 GPS module 7 UART-USB Converter 8 RF module
Table 3.2: Table boards component.
The communication between the robot and the BS is carried by the RF module, which works at the frequency of 443M Hz. The GPS high precision coordinates are obtained using the BS GPS and the robot GPS, working in the RTK mode, the communication between both is done by the Bluetooth module. This position is sent to BS by the RF module. For this dissertation, the pins shown in table 3.3 were used.
pin GPIO 1 3V3 21 GPIO9 19 GPIO10 23 GPIO11 25 Ground 12 GPIO18
CHAPTER 3. IMPLEMENTATION
3.2
Architecture Overview
The figure 3.4 shows a representation of the control system implemented over the AMazING platform that was developed for the purpose of this dissertation. It shows the connections between all blocks. The user uses the Web Application inside the web server module to interact remotely with the BS. Inside the BS, the Restful server module receives this information and will process it in a way that can be read by the robot manager module. The next step has the robot manager creating a file that will contain the instructions for the current experiment, such as velocity, direction, user and experiment name. This file will be used in the last module of the BS, robot communication, which will send the velocity and directions to the communication board that the robot should execute. It will also receive the incoming data from the board and store it in a new file, containing the velocity, direction, battery voltage and it’s position. The file will be saved in the user folder, and its name will be the experiment name. Every time a new experiment is requested the robot manager module will register the user name, start and stop time in the log file from that day. When the user requests the experiment data, the restful server module will fetch the relevant file and send it back to the web server. The user log can only be requested by an admin.
CHAPTER 3. IMPLEMENTATION
The communication between the robot and the web server is mediated by a BS that communicates with the arduino present in the robot, using a radio antenna and Serial Peripheral Interface (SPI). To connect with the web server, the BS uses an Ethernet port with the protocol REST (Figure 3.5).
Figure 3.5: Deployment Diagram.
To develop this system, a modular architecture was used where multiple blocks with different functions are interconnected. In figure 3.4 it is observable the different blocks of the system. This is divided into two principal blocks, the Web server block where the web server contains the user interface and the BS block where the data is stored and processed. This block also accommodates the robot manager.
The web server block contains a single module called Web Application, that will run on a virtual machine located in a remote server. This application was implemented with Django web frame, being composed by a frontend, which was built with javascript and HTML. It also features a backend, programmed in python. This block is also responsible for the interaction between the system and the user, getting the experiment parameters, it’s corresponding data and system status. For the communication between the Base station and the web server the REST Protocol was chosen.
CHAPTER 3. IMPLEMENTATION
The other main block, BS, is divided in 3 modules:
• Restful Server module is responsible for the communication between the web
application and the base station (Raspberry PI). It was implemented with a REST API. This module’s task is to receive instructions and send the data requests from the user. This block is built upon Flask.
• The Robot Manager module will manage the current status of the robot. It saves on
the Raspberry PI memory a file with the current experiment specifications, such as the velocity, direction, user and experience name.
• Robot communication is responsible for the communication to the robot, it sends
the instructions created by the robot manager module and receives and process the incoming data, storing it in the RPI’s memory, where it will be available for the Restful Server module to send it to the Web Server.
3.3
Web Server
3.3.1
Frontend
3.3.1.1 Interface
In order for an user to have an easy way to create and manage experiements and also to access results, a web interface was created with Django Web frame tools.
For this, a client-server architecture was implemented. The frontend of this application was built with HTML, CSS, javascript and Bootstrap, while the backend was built using Python language. The connection between the client side (frontend) and server side (backend) was made with Django Channels. This choice allows the application to handle websockets, which means that it is possible to interconnect the backend and frontend via a full duplex channel.
The figure 3.6 shows the user case diagram of the interface. The user’s first interaction with the system starts in the Home page, where he can choose 3 different functions. He can get the data from a previous experiment, create a new one or, if the user has admin privileges, he can access to the AMazING admin panel.
CHAPTER 3. IMPLEMENTATION
Figure 3.6: Use case.
In figure 3.7, it can be observed an activity diagram with the options that the user has. After the user logs in, he has access to at least 2 options. He can either choose to go to the "experiment panel" or "get data panel". On the former option, the user is able to create a new experiment, by filling in the required fields (experiment name, velocity, time, and direction). On the latter, the user can find all the data from his previous experiments or he can collect and visualize the data from a specific experiment (speed and position over time). After requesting the data, the user has the option to download them. If he has admin privileges the access to the "Admin Control Panel" is also unlocked.
Figure 3.7: Activity Diagram.
Figure 3.8 shows the "Home panel", from here the user can go to other panels. The "Make Experiment " option, shown in Figure 3.10, the "get experiment data " option,
CHAPTER 3. IMPLEMENTATION
shown in Figure 3.13 or in case that the user is an admin it will show a hidden page called "admin interface",shown in Figure 3.15. To have access to any of these pages it is needed to be logged, for that a special page with this function exists, Figure 3.9.
Figure 3.8: Home page.
Figure 3.9: Login page.
The page where the user can develop an experiment, is shown in figure 3.10. For creating an experiment the user needs to give it a name and then start to fill the table with the parameters, such as velocity, time and direction. To start the experiment the user should submit and then the instructions will be sent to the BS by the system.
CHAPTER 3. IMPLEMENTATION
the table that will be sent to the BS with all the desired parameters. In case the same parameter is not valid, an alert window like the one shown in figure 3.12 will appear, in this case, a message indicating that the velocity was above the limit.
CCW and CW mean counter-clockwise and clockwise respectively, this will define the direction that the robot will move.
Figure 3.10: Experiment page.
CHAPTER 3. IMPLEMENTATION
Figure 3.12: Alert window for excessive velocity.
The data from the experiment can be visualized on this page, shown in figure 3.13. By inserting the title of the experiment the user has access to velocity graphs and direction as well as the number of laps and velocity and time for a chosen position in a rail. In figure 3.14 it is observable the data from an experiment.
Figure 3.13: The page where the user can have access to the experiment data.
To deploy the graphs it was used the JavaScript library chart.js, which allowed to create the graphics present in figure 3.14.
CHAPTER 3. IMPLEMENTATION
Figure 3.14: Example of data view.
Figure 3.14 shows the graph of one experiment, the blue line represents the velocity at each moment and the red line represents the direction (0-CCW and 1-CW). In this figure is also show the table with the passes and the time of that pass for a chosen position, as well as the number of laps that the robot has made.
In this page, figure 3.15, the user can make direct control of the robot and get the log of the system, this allows to manage the system and make tests.
CHAPTER 3. IMPLEMENTATION
Figure 3.16 shows the log file from day 17-12-2018. In this log it is observable the user that used the system and the beginning time of each experiment and the end of it. This file is obtained in the Admin interface (figure 3.15) by clicking on "Get Log".
In this case it is possible to see that the user "itboss" used the robot for multiple experiments from 9h43m until 9h49m and after that the user "raalmeida" used it from 10h01m until 10h23m, with intervals where no one used such as between 10h15m and 10h23m. These files allow the system admin to know who used the robot at a specific time.
Figure 3.16: Log file.
3.3.1.2 Communication
To handle communications with the backend WebSockets were used. This technology allows to interchange data with the backend and managing the connection. Websocket is capable of providing full-duplex communication, it has a persistent connection and allows real-time communication. Because of these reasons, it was chosen for this task.
All the interface elements, such as the battery, robot states and every page that exchanges data with BS, has it’s own WebSocket address, creating multiple communication channels to be handled by the backend.
CHAPTER 3. IMPLEMENTATION
3.3.2
Backend
The backend of the web server was built with the Django web framework, using Python. Figure 3.17 presents the architecture from where the main module links the app’s face and experiment. The Backend is responsible for the call of HTML pages. The "Views" files are responsible for rendering the HTML files.
Figure 3.17: Backend architecture.
The communication between the frontend and backend was implemented using Django Channels. This has made the handle of the WebSockets simpler.
To handle WebSockets requests, it was created the "consumers" file. This file manages the connection/disconnection and the message exchange between the backend and frontend. The "consumers" file is also responsible for the reception/transmission of messages to the BS.
Algorithm 1 shows how the system handles the request from the frontend. It is observable how the system makes a GET request and sending of the data received from that request to frontend.When a connection is started, the system has to accept it(function connect(self)).
CHAPTER 3. IMPLEMENTATION c l a s s Consumer_example ( WebsocketConsumer ) : def c o n n e c t ( s e l f ) : async_to_sync ( . . . ) ( . . . ) s e l f . a c c e p t ( ) def d i s c o n n e c t ( s e l f , c l o s e _ c o d e ) : async_to_sync ( . . . ) ( . . . ) def r e c e i v e ( s e l f , t e x t _ d a t a ) : u r l = ’ h t t p : / / a m a z i n g p a n e l . av . i t . pt / e n d p o i n t ’ t e x t R e c e i v e d = r e q u e s t s . g e t ( u r l ) async_to_sync ( s e l f . s e n d ( t e x t R e c e i v e d ) )
Algorithm 1: Consumer example.
The backend is also in charge of the authentication process. For that, it was used the Django authentification mechanism, allowing to create total access to selected users(admins) and reduced access for normal users.
3.4
Base Station
3.4.1
Robot RESTfull Server
This module is responsible for the communication between the web app and the BS. For that, it was implemented a RESTful application server to manage the HTTP operations. The API was developed with Python Flask, using algorithm 2, that implements the Flask RESTful library, that allows managing the HTTP requests using endpoints and parameters, as shown in figure 3.18.
Using those operations, the system can receive and process requests from the web app, it can get the experiment data file, list of experiments associated to the user, battery and BS status and log files.
CHAPTER 3. IMPLEMENTATION
Figure 3.18: URL example with endpoints and parameters.
from f l a s k _ r e s t f u l import Resource , Api , r e q p a r s e app=F l a s k (__name__) a p i=Api ( app ) c l a s s className ( R e s o u r c e ) : def g e t ( s e l f ) : g e t p a r a m e t e r s o p e r a t i o n o f g e t return j s o n f i l e def p o s t ( s e l f ) : o p e r a t i o n o f p o s t return j s o n f i l e def put ( s e l f ) : o p e r a t i o n o f put return j s o n f i l e def d e l e t e ( s e l f ) : o p e r a t i o n o f d e l e t e a p i . a d d _ r e s o u r c e ( className , ’ / e n d p o i n t c l a s s ’ ) Algorithm 2: REST API.
This module also formats the packets that are readable by the Robot Manager module and saves them in a JSON file. The REST server runs over Apache 21.
3.4.2
Robot Manager module
To schedule the new experiment with packets that arrive at the system it was necessary to create a way to manage those packets. To that, it was developed the algorithm illustrated in figure 3.19.
CHAPTER 3. IMPLEMENTATION
Figure 3.19: Manager logic.
The system receives experience packet (A), which is constituted by instruction packets, each one of those elements, the experience description (Dn), holds the experiment information, such as velocity, direction, experiment title and user name, the start time(Tin) and the stop time(Tsn). Process 1 assigned that element to three predefined queues (B). This queue using FIFO (first in, first out) logic, removes the first element of each queue (2) and using the Ti and Ts as limits of the interval (C). In case the current time lies in the interval [Ti, Ts [, the element D for that interval will be saved (3) in the file exp.json(D). This one is used by the Robot communication module. When Tc is greater than this, the next elements in the queue are used and restart the cycle.
In case of the queues being empty, it will be written in the exp.json instructions for the Robot communication to send velocity 0 and don’t save any incoming data from the robot, except battery voltage.
This module, apart from managing and processing incoming packets, is responsible for updating or creating the User Log, which saves the experiment user name, start and end time.
CHAPTER 3. IMPLEMENTATION
3.4.3
Robot communication module
This module is responsible for the communication between the robot and the BS, as well as processing some experiment data, such as position and battery state. It is divided into two main tasks, transmit instructions and receive experiment data.
This module transfers instructions four times per second. It reads the instructions to send from a JSON file created by the manager module. From that, it saves the user and experience title in memory and using the RF692 libraries it loads the buffer of the radio
module with the desired velocity and direction.
The receiver block reads from the buffer every time it receives data, then processes that data. Data, as velocity and direction, doesn’t receive any processing, but the GPS and battery data it is processed.
For the battery data, because of reading errors, the value has very high and low peaks. To solve that a median filter was implemented. The reason for choosing a median filter instead of an average filter was because high range peaks existed, one big or small value causes a significant error. But by using the median method, these extreme values don’t affect as much as in the average filter, this way the reading error is reduced considerably. Figure 3.20 shows array 1, which contains the battery values by arriving order. Taking those values and making an average it gets the value of 55.44V. But if a median filter is used instead, after organizing the values as in array 2, it was obtained the battery voltage of 61V. Comparing with the previous value, the last one has a much smaller error.
Figure 3.20: Median.
Another data that needs to be processed are the GPS coordinates. The robot sends only the decimal digits separated in different blocks, for that it was necessary to concatenate in longitude and latitude values. After that it was required to transform these values in
CHAPTER 3. IMPLEMENTATION
positions from a predefined notation, for that it was developed the algorithm 3. Using the fact that the four corners of the building are aligned with the four cardinal points, it was possible to overlap a trigonometric circle. Each quadrant has received a letter, as shown in figure 3.21.
Figure 3.21: It referential 1.
Using the coordinates from the middle of the building as the center of the circle and taking a position of the robot was possible to calculate α, the angle between the xx axis and the straight line that intercepts the center and the robot. For calculating α the equation 3.1 was used.
α = arctan (robotlg − centerlg)
(robotlat − centerlat) (3.1)
CHAPTER 3. IMPLEMENTATION
This algorithm takes the coordinates and using a Cartesian coordinate system, as shown in figure 3.22, centered in the middle of IT1, calculate the angle applying the notation. This algorithm uses a range of if’s and for’s to discover where the robot is ant then grant it a letter and a number, for example, A2.
def g e t P o s I d ( n l a t , n l g ) : c e n t e r l a t =40.634172 c e n t e r l g = −8.660015 npos=N #numer o f p o i n t
d i v=i n t ( npos / 4 ) #number o f p o i n t p e r s i d e i f a n g l e i s in q u a d r a n t I : pos="A" f o r i in range ( d i v ) : i f i n c r e m e n t e d a n g l e b i g g e r than c o o r d i n a t e s a n g l e : c r e a t e a S t r i n g w i t h A+i e l i f a n g l e i s in q u a d r a n t I I : pos="B" f o r i in range ( d i v ) : i f i n c r e m e n t e d a n g l e b i g g e r than c o o r d i n a t e s a n g l e : c r e a t e a S t r i n g w i t h B+i e l i f a n g l e i s in q u a d r a n t I I I : pos="C" f o r i in range ( d i v ) : i f i n c r e m e n t e d a n g l e b i g g e r than c o o r d i n a t e s a n g l e : c r e a t e a S t r i n g w i t h C+i e l i f a n g l e i s in q u a d r a n t IV : pos="D" f o r i in range ( d i v ) : i f i n c r e m e n t e d a n g l e b i g g e r than c o o r d i n a t e s a n g l e : c r e a t e a S t r i n g w i t h D+i return S t r i n g
CHAPTER 3. IMPLEMENTATION
Figure 3.23: Position grid.
Figure 3.23 shows the grid arrangement that was used in this dissertation. The side within the north(N) and the east(E) side is nominated as "A", between the east and south(S) as "B", between south and west(W) as "C" and within the west and north as "D".
3.5
Communication
As mentioned above, the communication between the two main blocks of the system (Base station and Web Server) is obtained through an Internet connection using REST. For that, both blocks had dedicated systems.
In the Base Station Block it was developed a RESTful API responsible for the managing of HTTP requests. At the web server block it was created consumers capable of request resources and process the responses.
CHAPTER 3. IMPLEMENTATION
Figure 3.24: Interaction diagram.
Figure 3.24 shows the interaction diagram of the communications between the web app and RESTful server. When the web server makes a request GET of ".../bat", the RESTful server will return the battery voltage. Case the web server request a GET with parameters, such as ".../data?arg1&arg2", the RESTful server returns the resource associated to those parameters. If the web server makes a POST, the RESTful server does not make a return.
CHAPTER 3. IMPLEMENTATION
3.6
Hardware
The AMazING platform is composed of two hardware elements, the BS and the Robot. The BS is formed by a Raspberry PI and a communication board. This board holds a Radio module, a GPS module, a Bluetooth module, and a USB-UART converter. The Radio module works with a frequency of 433MHz. It is responsible for the SPI communication between the BS and the robot. The GPS module working in the static module is responsible for the high accuracy mode, for that it uses the Bluetooth to connect with the robot GPS. The USB-UART converter is used to power up the GPS and configure it. The robot has a board formed by an Arduino, a GPS module, a radio module, and a Bluetooth module.
3.6.1
Hardware System Problems
At the start, the robot has multiple problems with the cables. Some were damaged and a significant number were redundant, creating a complex system hard to repair and maintain. To resolve this problem, the wiring work was remade. Using a multimeter to read the tension at the wire terminals and with the help of the manufacturer datasheets, the cables were indentificated. After knowing the functions of the cables it was possible to remake some connections and remove the unused ones.
Another problem that occurred was the ground from the voltage regulator. This lane was broken and caused a critical failing of the GPS and Bluetooth. The PCB was repaired and a new GPS (NS-HP-GL-10s : GPS/GLONASS RTK Receiver) and Bluetooth (RN41XVU-I/RM) modules were bought. This new modules were configured to work with the existing system.
3.7
3D modeling
Due to the lack of hardware protection against the environment or support structure to the system antennas it was necessary to create ways to resolve these problems. So to develop solutions, it was used a 3D modulation software (SolidWorks3) to create the following physical structures.
CHAPTER 3. IMPLEMENTATION
3.7.1
Base Station
For the BS it was necessary to design a case that allows protecting the communication board and the Raspberry PI board. This case should also contain a ventilation system that cools down the boards.
In order to solve these conditions it was created the case shown in figures 3.25 and 3.26. This box allows easy access to the board ports and has a ventilation system. The ventilation system divides the air flux in 2 paths, one directed for the SSD card and the other for the Raspberry PI CPU. Apart from this, the case has antenna holders for the radio and Bluetooth, these holders are visible in the right of the figure 3.26. An additional support for the GPS was created as well (figure 3.27). This has a movable axle that allows obtaining the best GPS cover angle.
Figure 3.25: BS case view.
CHAPTER 3. IMPLEMENTATION
Figure 3.27: BS GPS support.
3.7.2
Robot structures
To protect the control/communication board it has been created another case (figure 3.28). This one protects the board from external interference’s and holds the board to the robot’s structure.
Besides this, it was required to create a system to fix the three antennas, the solution found was creating a branch with adapted slots to each antenna( figure 3.29), the GPS slot has a mobile axis like the one from BS.
CHAPTER 3. IMPLEMENTATION
Figure 3.29: Robot antenna supports.
3.8
Temperature control
After some time it was noticed that the raspberry pi was getting a temperature over 80oC with the case opened, and 84.3oC with the case closed, being the room temperature
21oC. The max recommended temperature was 85 C and the recommended temperature
45oC. Being the measured temperature less than 1oC from limit it was necessary to develop
a cooling system for bringing the CPU temperature close to 45oC. The solution used heat
sinks and a cooling fan, allowing it to obtain values close 48.3oC, only 3.3oC over the
recommended temperature. Another element with a tendency to overheat was the SSD card, using the same fan, with a particular ventilation duct (figure 3.30) that divert some of the air flux created by the fan to the SSD card, this way the card can be force cooled.
Chapter 4
Results
In this chapter, it will be shown and discussed the results obtained from different types of measurements. These tests were carried out to measure the different characteristic addressed in this dissertation.
Multiple tests were performed with the aim of observing the behavior of the robot. Velocity, acceleration, and stopping distance tests were performed to observe the robot behavior. A position test was used to see me GPS trend through time and the experience test to observe the response when an experiment request was made.
Tests were also performed to observe the temperature of the BS and the User-Interface interaction.
