Desenvolvimento de uma arquitetura de navegação para um veículo autónomo de superfície.

(1)

F

ACULDADE DE

E

NGENHARIA DA

U

NIVERSIDADE DO

P

ORTO

Development of a Navigation

Architecture for an Autonomous

Surface Vehicle

Rui Manuel Monteiro Marques

INTEGRATEDMASTER’S DEGREE IN ELECTRICAL ANDCOMPUTERSENGINEERING

Supervisor: Professor Andry Maykol Pinto Co-supervisor: Professor Nuno Alexandre Cruz

(2)

c

(3)

Abstract

The use of autonomous vehicles has been growing over the last few years, giving way to their adoption to perform errands otherwise carried out by humans, sometimes with some risk attached. Autonomous surface and underwater vehicles are known to perform these kind of tasks, with appli-cations in surveillance, underwater structures inspection, oceanographic and atmospheric studies. There has been an equivalent evolution regarding navigation systems and sensors used. Navi-gation algorithms have gotten more complex in order to cope with every environmental conditions that the vehicle will have to endure when executing its mission.

This dissertation describes the development of a navigation architecture and its constituents, explaining the details concerning each one, arranging them from the higher levels, where the mission is configured, to the levels where the vehicle’s trajectory is controlled and the localization system are situated. Also, some tests are described. These were made to assess the performance of said navigation architecture under diverse circumstances using a simulation software, recreating waves and wind effects to make the testing conditions as close to reality as possible, studying their influence in the effectiveness of the trajectory control algorithm.

In light of the obtained results, it was concluded that the implemented architecture worked as expected, being able to control the trajectory in a satisfactory way and deliver the vehicle to each point of interest, regardless of the surrounding environment.

(4)

(5)

Acknowledgements

The accomplishment of ending this dissertation has a special meaning to me because it culmi-nates the past five years of studies, presenting itself as a test to my autonomy and preparing me to face the challenges that may arise in my professional life. Despite this, I recognize that none of this could be achieved without the help of the people mentioned in the following paragraphs.

First of all, I would like to express my gratitude to my supervisors, Professors Andry Pinto and Nuno Cruz, for granting me this opportunity, for their dedication and help given throughout the developed work, as well as for the patience and motivation words provided in order to push me to achieve my objectives. I want to thank the CRAS staff, highlighting Alexandra Nunes and Rita Gaspar, for their support and assistance in several parts of this dissertation, giving emphasis to their teachings in an early phase.

I can’t thank my parents enough for everything they’ve done, for their effort in providing for me throughout these years and supporting me in all the lowest points of my academic life. I hope one day I can pay you back! To my siblings, for believing in me and for the constant amusing environment created by them.

Lastly, I would like to thank my friends, mainly the ones who accompanied me through this dissertation, for all the jokes around it, support words and mutual help given. To the rest, thank you for all the good times created for me to occasionally clear my head and be able to find another way to tackle a problem. A massive thank you!

Rui Marques

(6)

“Just because you’re trash doesn’t mean you can’t to do great things. It’s called garbage can, not garbage cannot!”

Oscar the Grouch

(7)

List of Figures

2.1 Sesamo ASV (left) and MARES AUV (right). Adapted from [1] and [2]. . . 7

2.2 Types of AUV Navigation. Adapted from [3]. . . 8

2.3 Acoustic navigation methods: (a) SBL; (b) USBL and (c) LBL. Adapted from [3]. 10 2.4 (a) Sidescan; (b) Multibeam; (c) Forward-looking; (d) MSIS and (e) Syntethic aperture. Adapted from [3]. . . 11

3.1 General overview of ROS nodes and topics. . . 13

3.2 Figure representing the roll, pitch and yaw axes. . . 14

3.3 Adopted architecture . . . 15

3.4 QGroundControl window with home position defined in Leixões (up) and with a mission built (down). . . 16

3.5 Example of the definition of a waypoint in QGroundControl. . . 17

3.6 Structure of MISSION_COUNT (up) and MISSION_REQUEST (down) MAVLink messages. Extracted from [4]. . . 17

3.7 Structue of MISSION_ITEM MAVLink message, extracted from [4] (left) and communication between mission planning and executor nodes (right). . . 18

3.8 Fluxogram picturing the mission executor. . . 19

3.9 Nodes and topics visualization regarding the localization skill. Extracted from RQT. 20 3.10 State machine of the maneuvering control skill. . . 20

3.11 Example showing how the euclidean distance is calculated. . . 21

3.12 Example showing how to calculate the angular difference. . . 21

3.13 Sub-states within the MOVE state. . . 23

3.14 Sub-states within STATION KEEPING and their interaction with WAIT TIME. . 24

4.1 ASV at the origin point in Gazebo. . . 26

4.2 Mission waypoints layout in QGroundControl. . . 26

4.3 Mission path (blue) and trajectory taken by the ASV (red). . . 27

4.4 Mission path (blue) and trajectory taken by the ASV (red) with the waves plugin. 28 4.5 Mission path (blue) and trajectory taken by the ASV (red) with the wind plugin. . 29

4.6 Mission path (blue) and trajectory taken by the ASV (red) with the waves and wind plugins. . . 30

(10)

(11)

List of Tables

4.1 Mission waypoint parameters used in simulation. . . 27

(12)

(13)

Abreviations and Symbols

ASV Autonomous Surface Vehicle AUV Autonomous Underwater Vehicle FLS Forward-Looking Sonar

GPS Global Positioning System HUD Head Up Display

IMU Inertial Measurement Unit LBL Long Baseline

MARES Modular Autonomous Robot for Environment Sampling MSIS Mechanical Scanned Imaging Sensor

ROS Robot Operating System SBL Short Baseline

SLAM Simultaneous Location And Mapping TOF Time Of Flight

UAV Unmanned Aerial Vehicle UTM Universal Transverse Mercator USBL Ultrashort Baseline

WGS World Geodetic System

(14)

(15)

Chapter 1

Introduction

1.1 Context

Nowadays, there has been an increase in the usage of autonomous vehicles. They are becoming more and more part of our lives, as they can liberate us from some tasks that can be difficult to perform by humans or even ease other chores.

This dissertation arises with the growing industry of rovers, AUVs and ASVs mainly the ones used in aquatic environments. These have to, sometimes, be able to function under water, and endure the harsh conditions that can occur at any moment. Despite this, they have to perform the mission that was assigned to them, always monitoring and diminishing any deviations that can happen by taking action. In many cases, the missions take a good amount of time to perform, which increases the chance of any fatality. Sometimes, the control doesn’t work as well as expected, or simply the conditions are too extreme, which can result in the loss of the vehicle, should it be impossible to retrieve it.

1.2 Motivation

Autonomous vehicles are known to make a lot of tasks, commonly performed by humans, easier to carry on. They can execute these tasks by themselves, which allows the removal of the human operator involved, saving operation costs and large amounts of time, depending on the mission. The fact that many of these vehicles are built with a purpose of scalability also add up to the point, because it makes it easier to mount sensors and tools that are not related to the navigation field, but are used over the course of the mission to, for example, take readings of the environment, resulting in a cutback in the amount of equipment to be dragged along to the area of interest. One of the core key points to ensure the autonomy of the vehicle is its navigation. The vehicle has to be able to, based on the data provided by its sensors, get around the surrounding environment on its own. Once a reliable navigation system is engineered, it opens a wide range of applications for an autonomous vehicle to be used in.

(16)

2 Introduction

One example of these applications is the monitoring of water to assess its quality. In such application, an ASV is usually chosen and equipped with a sampling mechanism to store water onboard, to be analyzed later in laboratories. Sometimes, the water composition can be acquired in situ, by fitting the required sensors on board, backing up the idea of these vehicles’ scalability.

This dissertation has its spotlight on the development of an architecture to allow for an accurate navigation, since the mission is first planned using a ground control software and monitored, all the way to the lower levels, where the maneuvering control takes place and the interface with the hardware is established.

1.3 Objectives

Over the course of this dissertation it is aimed to achieve a functional robotized vessel that re-ceives a mission, processes it step by step, and executes it autonomously, resorting to the designed architecture while trying to please the reasons mentioned in the previous section. Bearing in mind the described problem, the following objectives have been laid down:

• Comparative analysis of mission planning and management architectures;

• Identification of available tools and their analysis in terms of likelihood of being used or suffer some alterations;

• Proposal and implementation of a mission planning, management and execution architecture for an ASV;

• Implementation of a waypoint navigation algorithm for an ASV;

• Identification of simulation tools that allow the replication of adverse conditions to test the navigation control in diverse scenarios;

• Testing and validation in a controlled simulated environment.

1.4 Structure of the document

This document is divided in five chapters, each containing sections. The present chapter gives the reader an idea of the context this dissertation is inserted in, as well as the motivation that leads to the urge to develop this theme and the principal objectives that are laid down.

The second chapter is dedicated to presenting the state of the art, the literature review of what was and is being done regarding autonomous vehicles, such as UAV’s, ASV’s and AUV’s, and concerning navigation techniques and commonly used sensors.

Chapter 3 is directed at the developed architecture, decomposing it from its higher to lower levels, explaining what happens at each level with each algorithm. A few tools that were used are also presented.

(17)

1.4 Structure of the document 3

Chapter 4 presents the discussion of the results and the outcome of what was explained in the third chapter, using a simulator to recreate the ASV in a controlled environment.

Finally, chapter 5 gives a conclusion on what was made throughout this dissertation and sug-gestions of objectives to be added in the future.

(18)

(19)

Chapter 2

Literature review

In this chapter the aim is to give the reader an overview of navigation architectures and systems used in autonomous vehicles and the wide range of applications these vehicles can be used for. Moreover, a review of works related to this dissertation’s subject is done throughout the following sections with aiming at giving the reader an insight of which technologies are or can be used in this area. Also, academic works from other universities or institutes regarding the problem described in this dissertation, with the objective of emphasizing that this theme is of great importance and, as such, is studied on a regular basis. This chapter is divided in the following sections:

• Autonomous vehicles; • Navigation techniques;

2.1 Autonomous vehicles

In recent years there has been a rapid growth of autonomous vehicles, due to the lowering of hardware costs and appearance of numerous open-source software that can match or even outrun commercial solutions that are already available. This has motivated investigators to try and achieve more ambitious goals and develop new autonomous vehicles for applications such as surveillance [5], underwater structures inspection, oceanographic and atmospheric studies [6][7]. This grants advantages, such as the removal of the human operator from dangerous environments [8], shifting it to the role of a supervisor [9][10].

The following sections clarify how these vehicles can be used in their applications, more specifically the water sampling procedure, as it is a recurrent appearance in academic works. 2.1.1 UAVs

The growing evolution of Unmanned Aerial Vehicles (UAVs) has awaken the interest of inves-tigators, who started to develop technologies with the purpose of helping exploration and retrieving useful data using these [11], with some application in water sampling tasks, as they are agile and can arrive at the collection point relatively fast. In order to provide reliable samples, the UAV has

(20)

6 Literature review

to be as still as possible during the operation. That requires a very precise control of the flying platform, as acknowledged by [12], because of the close interaction with the environment, which urges the need for a range of very accurate sensors. Though the work of [13] is not related with water sampling, [14] acknowledged that certain parts of it could be of interest in the development of a similar UAV with the purpose of collecting water samples. [14] considered the possibility of using an Aquacopter but ended up discarding this idea because of its capabilities of landing on water, which meant that the water sampling mechanism would have to be sealed, and that would make swapping the batteries and sampling vials difficult and not very efficient. Moreover, the usage of these devices is limited to operations in small areas, mainly due to low autonomy. 2.1.2 ASVs and AUVs

Other autonomous vehicles that can be used are either Autonomous Surface Vehicles (ASVs) or Autonomous Underwater Vehicles (AUVs), which can both be used for operations in high seas or large lakes, unlike their aerial counterparts. These, however can be very expensive to purchase, as mentioned by [15], who developed a solution named Project Alba to provide a low-cost platform, built and controlled with open-source technology and software. It was developed bearing in mind that it was to be adjusted to researchers’ specific needs and therefore could not take the form of a standard commercial AUV, but a simple version of one with the fundamental tools required, as it is very frequent that the scientists do not depend on all of the high capabilities made available by the commercial AUV. The sampling method used is based on standard commercial syringes, which grants two advantages right from the start: it keeps the containers sterile, since the syringes come straight from the shelves, and it is of easy and cheap replacement. In [16], an ASV is presented that was designed to monitor water resources, which are susceptible to contamination of noxious cyanobacteria. Though it only provides in situ measurements, its custom made winch and accurate location given by the global positioning system (GPS), without the need of static stations, are interesting concepts for the development of a water sampling counterpart system, since several data from the same location is needed in order to form a credible research. Another related work consists in an ASV designed to work under extreme conditions, as in [1]. As it is mentioned there, marine scientists were involved in the definition of specifications and the design of the surface vessel and sampling system, to better satisfy scientific requirements. It was intended that the samples should not be altered by the process which resulted in strong constraints for the materials used in the samplers and the ASV’s hydrodynamic design. Also, due to the environment where it would be tested, Terra Nova Bay (Antarctica), it was critical that some components, such as the sampling and stocking systems, were thermally isolated.

Commercial AUVs, available in the market, can be adapted and used as platforms. The prob-lem with these is that they use proprietary subsystems and architectures, making it difficult to integrate new devices, such as sensors. Moreover, they are built with only one sole purpose, and if they are required to execute a different operation, they have to be redesigned. To fix this, [2] built a modular AUV called Modular Autonomous Robot for Environment Sampling, or MARES for short, a robust torpedo shaped underwater vehicle that, unlike similar-sized systems, is able to

(21)

2.2 Navigation techniques 7

control horizontal and vertical motion independently. This proves to be particularly useful because it allows the AUV to be motionless in the water column and minimizes the impact on the process of collecting water.

Figure 2.1: Sesamo ASV (left) and MARES AUV (right). Adapted from [1] and [2].

The system that most resembles the one treated throughout this dissertation was designed considering how difficult it is to collect water samples in depth by small-sized ASVs [17], mainly because of dimensions and weight constraints. Its concept was to allow for a sampling probe to be lowered up to 130 meters in depth, taking measurements along the water column and collecting up to 3 water samples at predefined depths. The sampled water would then be conducted through channels inside the ASV to sensors lodged in it or to containers which stored the water to be transferred to laboratories afterwards.

2.2 Navigation techniques

Navigation is a fundamental part of autonomous vehicles, since accurate localization and nav-igation are essential to guarantee the reliability of the data that was acquired during a mission. According to [3], there is a difference between navigation and localization accuracy. The former consists in quantifying the precision with which the autonomous vehicle goes from one point to another, and the latter evaluates how well it locates itself within a map.

In order to navigate, most surface vehicles depend on technologies such as global position-ing and radio communications. However, underwater, due to the lack of structures and overall undersea environment, high frequency signals suffer rapid attenuation and can only reach short distances. That is why, in this particular case, [3] acknowledged that acoustic sensors are the most indicated. Though they can still suffer from some limitations, such as the variability of the speed of sound, due to fluctuating temperature and salinity, small bandwidth and low data rate, which constrains the amount of data to transmit.

Fortunately, as autonomous vehicles evolved, so did research in navigation and localization, causing older technologies like the long baseline (LBL) and ultrashort baseline (USBL) to be discarded, as they required predeployed and localized infrastructure, and replaced by dynamic

(22)

8 Literature review

multiagent systems and simultaneous location and mapping (SLAM) techniques, which provide more accurate navigation with less cost.

2.2.1 Navigation techniques

Still in [3], navigation techniques were divided in three main clusters: dead reckoning and inertial, acoustic transponders and modems, and geophysical, as showed in figure below.

Figure 2.2: Types of AUV Navigation. Adapted from [3].

2.2.1.1 Dead reckoning and inertial navigation

Dead reckoning is one of the most obvious and established method that relies on the vehicle’s velocity which, once integrated in time, manages to extract an estimation of the autonomous ve-hicle’s new position. The velocity components can be acquired using a compass and water speed sensors. Unfortunately, dead reckoning is susceptible to providing poor position estimations, as there are external factors that can influence the measurement of the autonomous vehicle’s velocity, such as water currents [18].

Inertial navigation system’s principle of operation is much alike dead reckoning, but it mea-sures the vehicle’s acceleration instead, and integrates it twice in time to provide an estimation of the new position. Measurements can be extracted from accelerometers and gyroscopes. How-ever, it was acknowledged that initialization of these systems can be difficult and not worthy to implement in small sized AUVs, as they are expensive and power consuming [18].

(23)

The problem with relying solely in one of these systems is that they can suffer from drifts in position estimation that increase without bound with the distance travelled. These will depend on the intensity of ocean currents, the vehicle’s speed and overall quality of the onboard sensors [18]. Such drifts can be corrected through forcing the autonomous vehicle to surface every once in a while and using radio and satellite navigation to fix the position. Of course, this would depend on the application of the autonomous vehicle and quality of the dead reckoning/inertial navigation [18].

2.2.1.2 Acoustic navigation

The need for using acoustic signals instead of electromagnetic ones exists due to rapid atten-uation of the latter in the aquatic environment, whereas acoustic propagate very well. In acoustic navigation, the autonomous vehicle estimates its position using techniques based on measuring the time of flight (TOF) of signals emitted from acoustic beacons or modems. According to [3], the current methods in use are:

• Short baseline (SBL): In SBL, the vehicle calculates its position through triangulation, us-ing beacons that are placed in opposite ends of a supportus-ing ship. It requires, once again, dragging along a vessel, whose length has a very important role in the positional accuracy, as it determines the size of the baseline [3].

• Ultrashort baseline (USBL): In USBL navigation, the position is estimated by measuring the arrival time difference, or the phase difference, between pings by beacons that are placed very closely in a support vessel [18]. Downsides of this method include the range limitation [3] and the need for a support vessel, which can turn out very expensive.

• Long baseline (LBL): LBL navigation relies on the previous deployment of equally spaced beacons, which will receive and respond to pings from the autonomous vehicle. Based on the two-way travel time of the pings between the vehicle and each beacon, the vehicle estimates its position [18]. The need for the deployment of beacons presents itself as the major limitation of LBL, as it requires time and monetary resources to set up the network [3].

• Single fixed beacon: This technique came to mitigate the LBL’s need for time and cost to install infrastructure by using only one beacon and simulating the baseline by propagating the ranges forward in time until the next update is received [3]. Bear in mind that the trajectory of the vehicle plays an important role whilst estimating the position.

• Acoustic modems: This last technique follows the advances in the field of acoustic com-munications, as it allows simultaneous communication and ranging. It eliminates the need for beacons to be deployed, as they can now be in movement and report their location to the autonomous vehicle, which will bound its position to a sphere centered on the beacon

(24)

10 Literature review

Figure 2.3: Acoustic navigation methods: (a) SBL; (b) USBL and (c) LBL. Adapted from [3].

[3]. Acoustic beacons also allow communication between vehicles, which can help localize each other.

2.2.1.3 Geophysical

Although there has been some advances in acoustic communications, which allowed the de-velopment of some of the methods previously described, the usage of beacons is still impracti-cal. Should there exist an accurate map of the environment with geophysical parameters such as bathymetry, magnetic field or gravitational anomaly where the autonomous vehicle will operate, it can estimate its position based on comparing data from sensors with the map information [18]. Geophysical navigation can be divided in the following categories:

• Magnetic: This method’s principle is to use magnetic field maps for navigation, associating a magnetic signature to each landmark. That way, the autonomous vehicle can locate itself by measuring gravitational anomalies and comparing to the known signatures. There hasn’t been much investigation regarding it.

• Optical: Optical navigation consists in using a camera to capture images of the seabed and match them in order to navigate [3]. It requires the definition of some landmarks that will become points of reference for the autonomous vehicle to navigate. The performance is greatly conditioned by the reduced range of cameras in aquatic environment due to lack of light at that is verified at certain depths.

• Sonar: Sonar based imaging and ranging of the ocean floor has been around for a long time, making it a well studied technology and, therefore, fairly robust. Sonars applied can be one of two types: imaging sonars or ranging sonars.

Imaging sonars comprise sensors like the sidescan sonar, forward-looking and mechanical scanned image sonar (MSIS).

Sidescan sonar records the reflected signals form the seabed to generate slices as the au-tonomous vehicle advances. When the slices are put together, they form a depiction of the seabed, where darker areas represent protuberant objects and lighter ones represent smooth surfaces [3].

(25)

Forward-looking sonars (FLS) rely on a multibeam emission principle and have the pri-mary objective of mapping vertical structures, which is why they are commonly used in autonomous vehicles with application in underwater structure inspection [3].

Unlike FLS, MSIS requires a single beam that is rotated through the desired viewing angle. However, this takes time to complete and therefore its update rate is slow [3].

This approach enables high resolution imaging, as it manages to create a large virtual array by discarding a large static array of transducers and using the sensor’s along-track displace-ment instead [3].

Figure 2.4: (a) Sidescan; (b) Multibeam; (c) Forward-looking; (d) MSIS and (e) Syntethic aper-ture. Adapted from [3].

In the field of ranging sonars, the most used is the multibeam sensor. Arrays of transducers are placed along the structure of the autonomous vehicle, which receives at different times the signals that bounced from the seabed at different angles. These signals are processed and provide a bathymetric map of the environment [3].

(26)

(27)

Chapter 3

Methodology

Throughout the next pages a walkthrough of the developed work will be done, explaining the theory behind the implemented solution that was used to solve the problem in hands. Also, the tools used to make this possible will be presented.

3.1 Tools

3.1.1 ROS

The Robot Operating System was the basic tool for the evolution of this dissertation. ROS comprises a set of software libraries used to build robotic applications and, as one of the core principles, allows an easy connection between software developed by different groups of investi-gators, a feature that was very useful to link the layers of the navigation architecture, as it will be explained ahead.

Figure 3.1: General overview of ROS nodes and topics.

The functioning of ROS consists in a group of nodes communicating with each other through messages, called topics. In this context, a ROS node is a process used to perform computation. The topics are exchanged based on a Publisher-Subscriber pattern where the sender, the so called Publisher, doesn’t specify who to send its message, but instead makes the message available to all, leaving up to each Subscriber to choose if it wants to listen to the message. These characteristics of ROS are particularly useful to this work because they allow its division to sets of nodes coding a specific part of the navigation architecture, that communicate between them through topics.

(28)

14 Methodology

3.1.2 MAVLink protocol

The Micro Air Vehicle Link (MAVLink) is a communication protocol used in small unmanned vehicles. As the name implies, it is directed mainly at aerial vehicles but can also be applied to maritime ones. This tool is of interest for the development of this thesis because of its wide range of message that allow the exchange of reliable information between a ground control station and those vehicles, as well as between the subsystems within. These messages can be used to report the vehicle’s current position, orientation and velocity back to the ground control station to be seen in an HUD, enabling the operator to monitor the mission in real time. Other messages are directed at fault detection as they allow checking the status of the sensors on board of the vehicle. Also, this protocol [19] is what enables the streaming of the waypoints defined in mission planning to the vehicle.

3.2 Architecture layout

In order to achieve a proper functioning solution, the problem had to be split into very well defined small parts, making each one easier to understand and code. These portions were de-fined according to an architecture designed a priori, and put together to work using ROS and MAVLink, which have their advantages when regarding communication between nodes. Before digging deeper into the description of the architecture, there are some concepts that are relevant to point out.

Figure 3.2: Figure representing the roll, pitch and yaw axes.

As the figure3.2depicts, a vessel can suffer rotations in various ways. It can rotate around an axis defined from bow to stern, called roll, around another transverse to the structure, the pitch

(29)

3.2 Architecture layout 15

axis, and around a vertical axis. The latter is known as the yaw axis, and it is the one the angular velocities described ahead are applied around.

Like it was said above, it is very important to organize, right from the start, how to solve the problem. The following architecture was adopted, since it delineates each level in a way that is simple to interpret what is supposed to happen in it, hence making it easier to develop algorithms for each stage.

Figure 3.3: Adopted architecture

Starting from the top, the Mission level was designed to be in charge of defining the mission to be performed by the ASV. In order to do deal with the whole mission planning, the open-source software QGroundControl is used. Though it is mainly used for path planning of aerial autonomous vehicles, it proved itself to be just as useful as a ground control station when regarding the usage of ASV’s. Its simplicity in building a mission, sending it to the vehicle and the ability to monitor the vehicle’s status, as well as the integration with MAVLink were major factors that led to the adoption of this ground control software.

(30)

16 Methodology

Figure 3.4: QGroundControl window with home position defined in Leixões (up) and with a mission built (down).

While in this software, the mission can be constructed by pinpointing target points that end up building a path to be followed by the ASV. These points, commonly known as waypoints, are drawn directly in satellite images, as well as the home position, the point from which the ASV will start its mission. When identifying the waypoints on the map, the fields regarding latitude and longitude are automatically filled with the geographic coordinates of the waypoint, as seen in figure3.4 (down). Each waypoint has a series of parameters storing the information concerning the geographic position, hold time and orientation:

• Param1: The first parameter (Param1) is filled automatically since it represents the identi-fication of the waypoint, a value that is incremented with each newly designated waypoint, as long as the AutoContinue box is checked;

• Param2: represents the hold time, in seconds, upon arriving at the waypoint;

• Param3: Param3 is used as a boolean, being its purpose to flag whether or not the ASV should take the orientation desired in Param4. Bear in mind that, should this parameter not exist, the ASV would assume its target yaw at each waypoint would always be 0 radians; • Param4: Target heading, in radians, at the waypoint.

(31)

• Latitude: geographic coordinate specifying the North-South position of the waypoint; • Longitude: geographic coordinate specifying the East-West position of the waypoint; • Altitude: height of the waypoint, irrelevant for an ASV.

Figure 3.5: Example of the definition of a waypoint in QGroundControl.

Once the mission is built completely, it is sent to the vehicle. This is done via a ROS node that communicates directly with QGroundControl. This node is in stand by until it receives a MIS-SION_COUNT mavlink message sent from the ground control software. This message’s purpose is to report the number of waypoints that compose the mission. Upon receiving it, that number is decoded from the message (count) and used to trigger the end of a cycle of requests sent to the ground control software.

Figure 3.6: Structure of MISSION_COUNT (up) and MISSION_REQUEST (down) MAVLink messages. Extracted from [4].

The MISSION_REQUEST message is used for these requests, asking the mission planning software for more information regarding each waypoint. Sequential messages with an incremented by one value in the seq field, the waypoint identification number, with each request until it reaches the total number of waypoints.

(32)

18 Methodology

The ground control station then responds via sequential MISSION_ITEM messages, carrying the parameters respective to each waypoint, as defined previously. This information is stored in a vector of waypoints, pushing back a new element with each received MISSION_ITEM message. This vector of waypoints is later included in the assembly of a WaypointList type message that is published through a ROS topic.

Figure 3.7: Structue of MISSION_ITEM MAVLink message, extracted from [4] (left) and com-munication between mission planning and executor nodes (right).

The WaypointList message is then submitted to some processing. The processing has to be done because the geographic coordinates are defined according to the WSG 84 coordinate system (latitude and longitude), which makes no sense when using short distances (around 10 meters between waypoints). The World Geodetic System (WGS) is a standard to express a position on the Earth and is used in areas such as cartography and satellite navigation (GPS). The WSG 84 coordinates are converted to UTM using a ROS node that subscribes to the topic containing the waypoints, converting them one by one. The Universal Transverse Mercator (UTM) system is used to represent the surface of the Earth in a simpler, 2D Cartesian frame where y is North and xis East, discarding the altitude. Another topic is then published, this time containing waypoints with the geographic coordinates in the UTM system.

The Mission Executor processes the planned mission. A breakdown of the mission is done, once it has been received from the mission planning. A ROS node was coded to receive the mission, subscribing to topic described previously with the waypoints coordinates already in the UTM system. Additionally, since it communicates directly with the navigation control module, this node has the purpose of telling the ASV when the mission is active. To do so, it sends a simple message featuring a boolean value as true at the same time it feeds the first target point to the navigation controller. Then, it waits for a return message announcing that the ASV has reached its destination, a message that triggers the dispatch of another waypoint from the mission executor. This is done recursively until all waypoints have been sent and confirmed to have been reached by

(33)

Figure 3.8: Fluxogram picturing the mission executor.

the ASV, by which time the flag that was used to start the mission is set as false, announcing the end of the mission.

Each time a waypoint is sent, a task is started that calls out skills to locate the vehicle and con-trol its trajectory to the target. This is where most of the work is done, where the localization and maneuvering control skills take place to guarantee that the ASV reaches its target with accuracy.

3.2.1 Localization module

This skill’s purpose is to handle the problem of knowing where the vehicle is at each given moment. It relies on the data provided by two sensors, GPS and IMU, to accurately determinate the vehicle’s position and orientation, respectively. The localization node subscribes to two dis-tinct topics containing GPS and IMU raw data, putting them together to construct a message that encloses odometry data.

The data regarding the vehicle’s position in the odometry message is provided by the GPS sensor and has to be, once again, converted from WSG 84 to UTM, for a matter of conformity, to be used in the calculations ahead. This data, is then fed to the steering control skill, over a new published ROS topic, the geonav_utm as shown in figure3.9.

(34)

20 Methodology

Figure 3.9: Nodes and topics visualization regarding the localization skill. Extracted from RQT.

3.2.2 Maneuvering control skill

This is the element that, upon receiving a message containing a target point, has the job of controlling the vehicle’s velocity and orientation until it fulfills its trajectory to the waypoint. The node’s structure was built using a state machine, depicted in figure3.10, where the distance left and angular difference between the path direction and the ASV’s direction are constantly calculated and used, not only as transitions between states, but also to take part in the determination of the linear and angular velocities that the vehicle should take.

Figure 3.10: State machine of the maneuvering control skill.

In order to obtain the distance to target the Euclidean Distance is used. It translates the straight line distance between two points in space and is determined, in a 2D environment, as follows:

d= q

(x2− x1)2+ (y2− y1)2 (3.1)

This is one of the reasons why both target position and current position coordinates are con-verted to the UTM system, so that the distance between them is expressed in meters. Note that

(35)

Figure 3.11: Example showing how the euclidean distance is calculated.

the x and y axes represent the East and North axes, respectively, used to express coordinates in the UTM frame.

The orientation that the ASV should take to face the waypoint is calculated the following way:

Figure 3.12: Example showing how to calculate the angular difference.

α = atan2 y2− y1 x2− x1

(3.2)

θ = α − β (3.3)

Where α designates the angle of the waypoint and β represents the direction that the ASV is facing. In order to calculate the angular velocity that the ASV should assume, given by θ , its current orientation is subtracted to the angle obtained by equation3.2, except when dealing with the final rotation of the vehicle. In this stage, since it controls the yaw of the vehicle at the point

(36)

22 Methodology

of interest, the ASV’s current orientation is directly subtracted to the target orientation declared in Param4of the waypoint structure.

For the vehicle to move, the values of the linear and angular velocities have to be sent to it. The Twist message stores values of the linear velocities, in x, y and z axes, as well as the angular velocities around these axes. The ones that are relevant are the x component of the linear velocity and the z component of the angular velocity. The x component is the relevant one because the frame rotates along with the vehicle, forcing the x axis to always be parallel to the vehicle’s orientation. Since the ASV in question possesses two thrusters, a Drive type of message is used to differ the values sent to the left and right thrusters, based on the linear and angular components of the Twist message as well as the distance betweem thrusters (width).

vle f t= vx− ωz∗ width 2 (3.4) vright= vx+ ωz∗ width 2 (3.5)

The state machine used to implement the steering skill is represented in figure3.10. Although it is not visible, there is a transition that affects every state, which forces it back the to INIT state, in case the mission flag turns to false, announcing the end of the mission. This flag can also be used to stop the mission prematurely, in case there are any malfunctions that can jeopardize the integrity of the vehicle or anything around it. All these states have influence in the way the linear and angular velocities are calculated. The velocities are adjusted using a function that, in a way, takes the current state as an input to determine whether it should increase or decrease the values of the linear and angular velocities.

• INIT: The INIT state is the most simple one. This state represents the full stop stage, where the ASV is waiting for a flag announcing the start of the mission. While in this stage, both linear and angular velocities are zero. Once it receives the message to start the mission, the state STOP comes in.

• STOP: The STOP state also regulates the velocities to zero while waiting for a waypoint to be fed in order to start the navigation. Upon receiving it, the next state is NEW WAYPOINT. • NEW WAYPOINT: NEW WAYPOINT is used only as a temporary state, jumping directly to the ROTATE state and sending a flag announcing the ASV started its navigation to the waypoint.

• ROTATE: For the ASV to navigate to the waypoint successfully, it first needs to gain some orientation towards its target. That’s what the ROTATE state is for, calculating the angular velocity needed, using equations3.2and3.3. The transition to the next state occurs when the current yaw of the vehicle matches, with some tolerance, the direction of the waypoint. • MOVE: The next state is the MOVE stage. This is split into three sub-states, representing

(37)

Figure 3.13: Sub-states within the MOVE state.

As the name implies, the ACCEL phase follows the ROTATION state and deals with making the ASV gain some linear velocity, while still applying some corrections in its orientation. The acceleration phase was defined to take place during the first four meters of the distance to reach the target. Once they are completed, the ASV can reach its maximum speed in the CRUISE phase, until it reaches the last three meters of the path to the target, entering the APPROX phase. In this last phase, the linear velocity was chosen to be low, to maximize maneuverability and make the vehicle arrive with precision within the defined tolerance, which is one meter radius from the waypoint itself. The next state is chosen based on the information contained in the waypoint’s parameters. If it is desired that the ASV should assume a specific yaw, by setting Param3 to 1, the next state is FINAL ROTATION. If no orientation is defined and a waiting time is declared instead, with Param2, the next state is WAIT TIME.

• FINISH: In the most simple case, if none of the above parameters is layed out, the next state is FINISH, which is, like NEW WAYPOINT, a mere temporary state, turning the velocities to zero when the ASV reaches its destination.

• FINAL ROTATION: Should the Param3 be 1, flagging a wanted yaw, the state machine enters FINAL ROTATION. This state’s operation is much like the one described in RO-TATION, differing in the way it calculates the angular velocity, since it exclusively uses equation 3.3, only this time the current yaw subtracts to the value carried in the Param4 field. This is done until the vehicle’s orientation matches the target yaw, with due tolerance. Once again, depending on Param2, the state machine decides whether to move to FINISH state or to WAIT TIME.

• WAIT TIME: The WAIT TIME state’s objective is to hold the vehicle’s position during the time requested by Param2. It starts counting the time from the moment it enters the state from the first time. Since the vehicle is subjected to effects of waves and wind, it can suffer position and orientation drifts. To minimize those effects the WAIT TIME state is always monitoring the distance to waypoint and current yaw.

• STATION KEEPING: Should the previous values differ from their targets, the state ma-chine takes the STATION KEEPING state to correct these drifts. The corrections can occur

(38)

24 Methodology

both in postion and orientation, which is why the STATION KEEPING state is split into sub-states, that are not represented in3.10for visual appealing reasons. Sub-states

STA-Figure 3.14: Sub-states within STATION KEEPING and their interaction with WAIT TIME. TION KEEPING ANGULAR and STATION KEEPING LINEAR modes of operation are very similar to the states that control the initial rotation and movement toward the waypoint, respectively, only on smaller scaled velocities, since their only purpose is to keep the vehicle in place. The same happens with STATION KEEPING YAW, which reincarnates the FINAL ROTATION state but, once again, with lower velocities. At any point of these corrections, if the time counter exceeds the value in Param2, the next state in order is FINISH, although not for long, like it was said above, as it paves the way for the SEND FEEDBACK state. • SEND FEEDBACK: As it is expected, the SEND FEEDBACK state’s purpose is to

an-nounce that the ASV has completed its trip to the point of interest before the state machine returns back to STOP. The message is directed at the mission controller that acknowledges it and sends a new waypoint, should there be any.

(39)

Chapter 4

Results and discussion

This section intends to present the results of the work developed throughout this thesis and evaluate the performance of the assembled algorithms in their task of navigating the ASV towards its goal positions, whether in ideal conditions or in under diverse circumstances such as windy weather and waves that can stray the vehicle away from its normal path.

4.1 Gazebo simulation software

In order for the testing to take place during the development of the algorithms, having a simu-lation environment was fundamental as it would be very time and resource consuming to move the physical ASV every time there was a need for testing any changes to the algorithms. One of the most important tools used throughout the thesis was the Gazebo simulation environment [20]. An open-source simulator that can reproduce populations of robots in simulated surroundings with a robust physics engine and high quality graphics. Gazebo allows the visualization of a virtual depiction of the robotic platform in a simulated environment.

In order to make these simulations as realistic as possible, Gazebo allows the integration of plugins to replicate waves and wind effects that the ASV would be subjected to in the real world, calibrating their intensity by changing parameters in the respective source files. It also allows the spawning of models like buoys, retrieved from online libraries, that can be used in the development of obstacle avoidance algorithms, for example.

It is worth mentioning that the world frame used in the simulator is in the UTM system in a North East Up configuration. In figure4.1the red axis is East and the green one is North.

(40)

26 Results and discussion

Figure 4.1: ASV at the origin point in Gazebo.

4.2 Performance of the navigation controller

In order to properly assess the performance of the control system, a series of tests were made both in ideal and unfavourable conditions, using the simulator. Four tests were performed, each one featuring different conditions. The first one took place to evaluate the navigation algorithm’s behaviour in ideal circumstances. The rest were carried out using the previously described plugins to cause waves, wind and waves plus wind, in each simulation. In all, the origin of the virtual world was chosen to be in Leixões port, with latitude 41.19oand longitude -8.69o. The mission, built in QGroundControl, contains waypoints around the home position, as defined in table4.1.

(41)

4.2 Performance of the navigation controller 27

Waypoint 1 Waypoint 2 Waypoint 3 Waypoint 4

Param1 1 2 3 4 Param2 10 10 10 10 Param3 0 0 0 0 Param4 0 0 0 0 Latitude 41.1900036 41.1899011 41.1897640 41.1896520 Longitude -8.6899905 -8.6901679 -8.6904039 -8.6904134 Altitude 0 0 0 0

Waypoint 5 Waypoint 6 Waypoint 7 Waypoint 8

Param1 5 6 7 8 Param2 10 0 0 40 Param3 0 0 0 1 Param4 0 0 0 1.5708 Latitude 41.1896460 41.1898045 41.1898093 41.1896472 Longitude -8.6899905 -8.6901679 -8.6904039 -8.6904134 Altitude 0 0 0 0

Table 4.1: Mission waypoint parameters used in simulation.

4.2.1 Simulation with ideal conditions

The first test to take place assumed perfect conditions in the simulated environment. This means a flat water surface and no wind whatsoever to influence the trajectory of the ASV.

(42)

As seen in figure4.3, the trajectory taken by the ASV (red) to each point is very close to the goal trajectory (blue), with some exceptions when starting the movement to another waypoint. These happen because of the tolerance given to the angular difference during the ROTATE state described in the previous chapter which leaves the ASV not directly facing the next waypoint and consequently fixing it during the MOVE state. This test served as a benchmark of the performance of the navigation algorithm to the next simulations, that took into account the wind and wave effects.

4.2.2 Simulations with adverse conditions

Testing the ASV’s navigation system under different circumstances was required to properly come to a conclusion about its performance. Therefore, three simulations were done, differing in what could interfere with the vehicle’s trajectory. For the first one, the plugin to simulate waves was used, tinkering with the amplitude and direction they should assume, as well as their frequency.

Figure 4.4: Mission path (blue) and trajectory taken by the ASV (red) with the waves plugin.

The outcome was not so different from the trajectory in ideal circumstances, except in the portions comprehended between the home position and the first waypoint and between the fifth and sixth waypoints, where it can be observed that the ASV took a wider trajectory comparing to the first simulation, though not as wide as the simulation with the wind plugin.

(43)

4.2 Performance of the navigation controller 29

For this last simulation, the plugin was calibrated to generate wind blowing in a North/Northwest direction, which caused the position drifts at each waypoint visible in figure4.5. The most protu-berant happened at the home position because of the time it took from the model to be spawning in the simulator to it receiving the task to navigate to the first waypoint. The ASV took measure to keep itself within the distance tolerance for the time defined in Param2, rotating and thrusting forwards to try to keep the position. The biggest drifts, excluding the latter, happened during the largest ROTATION iterations. For example, when traveling to Waypoint 4, the vehicle maintained a near Southwest heading. Upon arriving within the distance tolerance, the thrusters were shut down, and the hold time (Param2) started counting. Meanwhile, the wind effect pushed the ve-hicle out of the tolerance area, forcing it to assume a heading contrary to the direction the wind is blowing. The ASV faced South/Southeast and activated the thrusters in order to return to the position. Once the time exceeded Param2, the ROTATION state came in, being the time it took for it to make the ASV face the next waypoint enough to cause the drift near the bottom of figure 4.5.

Figure 4.5: Mission path (blue) and trajectory taken by the ASV (red) with the wind plugin.

Bearing in mind the results from the simulation with the waves effect, it would be expected that the outcome of a test featuring waves and plugin wouldn’t be much different from the previous simulation, where only the wind effect was considered. Figure4.6depicts the trajectory taken by the ASV with both plugins used in the previous two simulations. In this last experiment, it is seen that the drifts have a minuscule increment in the negative direction of the longitude, due to the small but existing wave effects.

(44)

Figure 4.6: Mission path (blue) and trajectory taken by the ASV (red) with the waves and wind plugins.

4.3 Discussion of the obtained results

Upon concluding the simulations it is fair to say that the navigation algorithm performed rela-tively well. As it can be seen in figures4.3to4.6, the controller executed its functions well enough to keep the ASV within the planned trajectory and get to every waypoint, not only in a environment pooling all the conditions for a perfect navigation, but also in situations where there are factors to negatively influence its performance, such as the waves and wind simulated to obtain these results. Despite all this, the simulations made to analyze the behaviour of the controller, when the ASV is confronted with waves, figures4.4and4.6, fall short of expectations, since the outcomes are not so different from their waveless counterparts, figures4.3and4.5, in terms of position deviatons.

(45)

Chapter 5

Conclusions and future work

5.1 Conclusion

Upon concluding this thesis, it was acknowledged that autonomous vehicles are a concept in evolution and are researched by many investigators with the objective of improving the lifestyle or even substitute humans in some of their responsibilities. It was recognized that there is a large amount of academic works to adapt or construct low scaled autonomous vehicles to be used in a whole variety of operations, as long as they provide the required sensors and actuators to do the job. For the topic at hands, a study of sensors that are currently used in aquatic environment navigation was made.

In this dissertation, a navigation architecture was developed with the intent of integrating it in an autonomous surface vehicle. A series of objectives were laid down, right from the start, and completed so that said architecture granted the ability of, once requested to execute a mission, the ASV to travel autonomously following the concept of navigation using waypoints.

In the end, it was possible to use the ground control software QGroundControl to build a mis-sion, pinpointing waypoints in a map and configuring their parameters. Communication between the software and the mission executor algorithm was established using MAVLink, enabling the re-ception of a list of waypoints. The mission executor managed to interpret the mission with success and transmit each waypoint to the trajectory controller, whose performance can be seen in the results section.

At the present stage of this work, the obtained results showed that the written algorithms, mainly the one handling the control of the ASV’s trajectory, managed to fulfill their assignments with satisfying results, either facing favourable conditions or a harsh environment with a strong wind blowing.

Along with what was asserted, this dissertation provided an introduction to ROS’s mode of op-eration and its advantages when put to practise in projects of this scope, as well as the recognition of Gazebo, not only as a powerful simulator to complete some tests, but also its ease of integration with ROS.

(46)

32 Conclusions and future work

5.2 Future work

Looking back, the essential objectives proposed in this dissertation were achieved, though with some difficulties along the way which resulted in some adjustments to the initially delineated ambitions. That aside, a project like this has always room for improvement. In light of what was said, the following efforts can be made to enhance what was done:

• refine the developed algorithms in a way to improve their performance in every environmen-tal circumstances;

(47)

References

[1] M. Caccia, R. Bono, G. Bruzzone, G. Bruzzone, E. Spirandelli, G. Veruggio, A. Stortini, and G. Capodaglio, “Sampling Sea Surfaces with SESAMO: an autonomous craft for the study of sea-air interactions,” IEEE Robotics & Automation Magazine, vol. 12, pp. 95 – 105, Sep 2005.

[2] N. A. Cruz and A. C. Matos, “The MARES AUV, a Modular Autonomous Robot for Envi-ronment Sampling,” in OCEANS 2008, pp. 1–6, Sept 2008.

[3] L. Paull, S. Saeedi, M. Seto, and H. Li, “Auv navigation and localization: A review,” IEEE Journal of Oceanic Engineering, vol. 39, pp. 131–149, Jan 2014.

[4] MAVLINK Common Message Set [Online]. Available: http://mavlink.org/messages/common. [5] G. Zhou and S. Reichle, “UAV-based multi-sensor data fusion processing,” International

Journal of Image and Data Fusion, vol. 1, no. 3, pp. 283–291, 2010.

[6] P. McGuillivary, J. B. de Sousa, and R. Martins, “Connecting the dots. Networking Maritime Fleets of Autonomous Systems for Science and Surveillance,” Marine Technology Reporter, p. 32–38, 2012.

[7] J. Fortuna, F. Ferreira, R. Gomes, S. Ferreira, and J. Sousa, “Using low cost open source UAVs for marine wild life monitoring - Field Report,” IFAC Proceedings Volumes, vol. 46, no. 30, pp. 291 – 295, 2013.

[8] S. Ferreira, G. Carvalho, F. Ferreira, and J. Sousa, “Assessing the capacity of man-portable UAVs for network access point localization, using RSSI link data,” in 2014 International Conference on Unmanned Aircraft Systems (ICUAS), pp. 355–364, May 2014.

[9] A. Ryan, M. Zennaro, A. Howell, R. Sengupta, and J. K. Hedrick, “An overview of emerging results in cooperative UAV control,” in 2004 43rd IEEE Conference on Decision and Control (CDC) (IEEE Cat. No.04CH37601), vol. 1, pp. 602–607, Dec 2004.

[10] D. Pascarella, S. Venticinque, and R. Aversa, “Agent-Based Design for UAV Mission Plan-ning,” in 2013 Eighth International Conference on P2P, Parallel, Grid, Cloud and Internet Computing, pp. 76–83, Oct 2013.

[11] M. Ribeiro, A. S. Ferreira, P. Gonçalves, J. Galante, and J. B. de Sousa, “Quadcopter plat-forms for water sampling and sensor deployment,” in OCEANS 2016 MTS/IEEE Monterey, pp. 1–5, Sept 2016.

[12] M. Schwarzbach, M. Laiacker, M. Mulero-Pázmány, and K. Kondak, “Remote water sam-pling using flying robots,” in 2014 International Conference on Unmanned Aircraft Systems (ICUAS), pp. 72–76, May 2014.

(48)

34 REFERENCES

[13] A. Goktogan, S. Sukkarieh, M. Bryson, J. Randle, T. Lupton, and C. Hung, “A Rotary-wing Unmanned Air Vehicle for Aquatic Weed Surveillance and Management,” Journal of Intelligent & Robotic Systems, vol. 57, pp. 467–484, Jan 2010.

[14] J.-P. Ore, S. Elbaum, A. Burgin, and C. Detweiler, “Autonomous Aerial Water Sampling,” Journal of Field Robotics, vol. 32, pp. 1095–1113, Dec 2015.

[15] J. Busquets, D. Proserpio, F. J. Martin, and J. V. Busquets, “Low-cost AUV Alba13 as multi-sensor platform with water sampler capabilities, for application in multi-agent ocean research applications,” in 2014 Oceans - St. John’s, pp. 1–8, Sept 2014.

[16] G. Hitz, F. Pomerleau, M. E. Garneau, C. Pradalier, T. Posch, J. Pernthaler, and R. Y. Sieg-wart, “Autonomous Inland Water Monitoring: Design and Application of a Surface Vessel,” IEEE Robotics Automation Magazine, vol. 19, pp. 62–72, Mar 2012.

[17] F. Fornai, F. Bartaloni, G. Ferri, A. Manzi, F. Ciuchi, and C. Laschi, “An autonomous water monitoring and sampling system for small-sized ASV operations,” in 2012 Oceans, pp. 1–6, Oct 2012.

[18] J. J. Leonard, A. A. Bennett, C. M. Smith, H. Jacob, and S. Feder, “Autonomous Underwater Vehicle Navigation,” MIT Marine Robotics Laboratory Technical Memorandum, 1998. [19] MAVLink Developer Guide [Online]. Available: https://mavlink.io/en/.