Development of a Dynamic Positioning

System for the ReVolt Model Ship

Henrik Alfheim
Kjetil Muggerud

Master of Science in Cybernetics and Robotics

Submission date: June 2017
Supervisor: Morten Breivik, ITK
Co-supervisor: Edmund Førland Brekke, ITK
Egil Eide, IET
Øystein Engelhardtsen, DNV GL
Norwegian University of Science and Technology
Department of Engineering Cybernetics
Preface
This thesis is the concluding part of the authors’ 2-year Masters degree in Cybernetics and
Robotics, graduating from the Norwegian University of Science and Technology (NTNU)
in June 2017.
Autonomous Surface Vehicles is chosen as a topic based on personal interests and its
increasing relevance for use in transportation, surveillance and so forth. We find our work
highly relevant and hope that our contribution on creating a platform on which autonomous
systems can be implemented and tested, will help the industry move forward.
We would like to thank our academic supervisors, Morten Breivik, Egil Eide and Edmund
Førland Brekke, for all the help and support throughout the thesis. The knowledgeable
discussions throughout the process have motivated continuous learning and given valuable
perspectives to our research. Our gratitude also goes to Øystein Engelhardtsen and Hans
Anton Tvete at DNV GL for the opportunity to work on ReVolt in this thesis.
Furthermore, we want to thank Andreas Lindahl Flåten and Erik Wilthil for knowledgeable
inputs on programming and Kalman Filter. We would also like to thank Stefano Bertelli at
NTNU, who assisted on practical matters of the research and in making the experimental
tests of ReVolt possible.
A special thanks goes out to both our partners and family, for their patience and valuable
inputs. This has been a great thesis to work on, where we have learned a lot and withstood
the long days required to complete the experimental tests. We are ready and motivated for
whatever lies ahead, and hope that the future users of ReVolt find working with ReVolt as
inspiring as we have.

Trondheim, June 2017 Henrik Lemcke Alfheim

Kjetil Muggerud

i
Abstract
Autonomous surface vehicles are still in the early stages of development, and show great
potential. These vessels can be used in different scientific and commercial operations,
outperforming manned vessels in safety, endurance and cost efficiency.
A Dynamic Positioning (DP) control system has been developed for, and implemented on,
a scale model of DNV GLs concept ship ReVolt. This model-scale ship, called ReVolt, is
used as a test platform for an autonomous ferry, as well as an early test platform for sensors
and control systems for autonomous vessels. As a result, this thesis primarily focus’ on
the functionality and implementation of the components and control system required to
achieve DP capabilities on ReVolt.
A DP control system has been developed, consisting of a 3-Degree of Freedom reference
filter and a Proportional-Integral-Derivative (PID) controller with a model-based feedfor-
ward from the reference. DNV GL’s thrust allocation has been implemented and an Error-
state Kalman Filter is developed. The DP control system is implemented on ReVolt’s
onboard computer, which runs the Robot Operating System (ROS) on top of a Linux shell.
The control system has furthermore been simulated in MATLAB to develop and test its
functionality.
Extensive field tests has been completed, where the main objective was to achieve station
keeping and low-speed maneuvering capabilities on ReVolt. Different setups in the thrust
allocation and controller have been assessed to determine the best overall setup for Re-
Volt. In addition, the control system has been applied to a docking scenario to asses its
applicability in docking.

iii
Sammendrag
Autonome overflatefartøy er fremdeles på et tidlig utviklingsstadium, men har et stort
potensiale. Disse kjøretøyene kan bli brukt i ulike forskning og kommersielle operasjoner,
som vil utkonkurerer bemannede kjøretøy p sikkerhet, utholdenhet og kostnads effek-
tivitet.
Et dynamisk posisjons (DP) kontrollsystem har blitt utviklet for, og implementert på, en
skalamodell av DNV GLs konseptskip ReVolt. Dette skalamodellskipet, fra nå av kalt
ReVolt, er brukt som en testplattform for en autonom ferge og er i tillegg en tidlig testplat-
tform for sensorer og kontrollsystemer tiltenkt autonome fartøy. Som et resultat av dette
fokuserer oppgaven hovedsakelig på funksjonalitet og implementering av komponenter og
algoritmer nødvendig for å oppnå DP funksjonaliteter på ReVolt.
Et DP kontrollsystem har blitt utviklet, bestående av et referansefilter i tre frihetsgrader og
en Proporsjonal-Integrasjon-Derivasjon (PID) kontroller med en modellbasert foroverkobling
fra referansen. DNV GLs trust allokering har blitt implementert og et Kalman Filter
er utviklet. DP kontrollsystemet er implementert på ReVolts kjørecomputer, som kjører
Robot Operating System (ROS) oppå operativsystemet Linux. Kontrollsystemet har videre
blitt simulert i MATLAB for å bevise dets funksjonalitet.
Omfattende felttester har blitt utført, hvor hovedformålet var å oppnå stasjonær posisjoner-
ing og lavhastighets manøvreringsevner på ReVolt. Ulik konfigurering av trust allokerin-
gen og kontrolleren er utprvd for å fastslå konfigurasjonen som gir best ytelse for ReVolt.
Kontrollsystemet har videre blitt anvendt på et dokkingscenario for å vurdere dets anven-
delighet for dokking.

v
Table of Contents

Preface i

Abstract iii

Sammendrag v

Table of Contents x

List of Figures xv

List of Tables xvii

List of Algorithms xix

List of Abbreviations xxi

Nomenclature xxiv

1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation: Autonomous Ferry . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Extension of Previous Work . . . . . . . . . . . . . . . . . . . 3
1.3 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Theoretical Background 7
2.1 Reference Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Transformation Between ECEF and NED Frames . . . . . . . . 10
2.1.2 Transformation Between BODY and NED Frames . . . . . . . . 10
2.2 The 3-DOF Ship Maneuvering Model . . . . . . . . . . . . . . . . . . . 10

vii
Table of Contents

2.3 Global Navigation Satellite System . . . . . . . . . . . . . . . . . . . . 12

3 Guidance System 13
3.1 Reference Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Tuning the Reference Filter . . . . . . . . . . . . . . . . . . . . 14
3.1.2 Reference Saturation . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3 Discretization . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.4 Rotate Shortest Path . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Control System 21
4.1 Dynamic Positioning Controller . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1 Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.2 Saturating Elements . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3 Tuning the Controller . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.4 Yaw Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Thrust Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.2 Thruster Force . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3 Thrust Configuration Matrix . . . . . . . . . . . . . . . . . . . 28
4.2.4 Unconstrained and Constrained Solution . . . . . . . . . . . . . 29

5 Navigation System 31
5.1 Error-State Kalman Filter . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.1 Quaternions and Euler Angles . . . . . . . . . . . . . . . . . . 32
5.1.2 True-State Kinematics . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.3 Nominal and Error-State Kinematics . . . . . . . . . . . . . . . 35
5.1.4 Discrete Nominal and Error State . . . . . . . . . . . . . . . . . 36
5.1.5 Jacobians and Perturbation Matrices . . . . . . . . . . . . . . . 36
5.1.6 Observation of Error State . . . . . . . . . . . . . . . . . . . . 37
5.1.7 Discretization . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.8 Pseudocode ESKF . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Wild Point Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 Lever-Arm Compensation . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4 Overall Navigation System . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Experimental Platform 43
6.1 ReVolt’s Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2 Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.3.1 Xsens-MTI-G-710 . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.3.2 Hemisphere Vector VS330 . . . . . . . . . . . . . . . . . . . . 47
6.4 Light Beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.5 Onboard Computer and Microcontrollers . . . . . . . . . . . . . . . . . 49

7 Embedded Computerized Control 51

7.1 Hardware Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

viii
 Table of Contents

7.2 Software Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.2.1 Robot Operating System . . . . . . . . . . . . . . . . . . . . . 52
7.2.2 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . 53
7.2.3 Software Structure . . . . . . . . . . . . . . . . . . . . . . . . 54
7.2.4 Thrust Allocation . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3.1 Xsens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3.2 Hemisphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.4 Logging System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8 Modelling the ReVolt Model Ship 61

8.1 Center of Gravity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.2 Mathematical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.2.1 Inertia Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.2.2 Coriolis-Centripetal Matrix . . . . . . . . . . . . . . . . . . . . 65
8.2.3 Damping Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.3 Bollard Pull Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

9 Simulation Results 69
9.1 Test Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.2 Reference Filter Parameters . . . . . . . . . . . . . . . . . . . . . . . . 71
9.3 PID Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.5 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

10 Experimental Results 77
10.1 Observer Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.1.1 Offline Performance . . . . . . . . . . . . . . . . . . . . . . . . 77
10.1.2 Online Performance . . . . . . . . . . . . . . . . . . . . . . . . 85
10.2 Pose and Velocity Measurements . . . . . . . . . . . . . . . . . . . . . 88
10.3 Test Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10.4.1 Reference Filter Parameters . . . . . . . . . . . . . . . . . . . . 89
10.4.2 Tuning Thrust Allocation . . . . . . . . . . . . . . . . . . . . . 90
10.4.3 Controller Gains . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.4.4 Lever-Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.5 4-Corner Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
10.5.1 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . 92
10.5.2 Unconstrained vs. Constrained . . . . . . . . . . . . . . . . . . 93
10.5.3 Rotation vs. Static . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.5.4 PID-FF vs. Tuned PID-FF . . . . . . . . . . . . . . . . . . . . 104
10.5.5 PID vs. Tuned PID-FF . . . . . . . . . . . . . . . . . . . . . . 109
10.6 Application to Docking . . . . . . . . . . . . . . . . . . . . . . . . . . 114

11 Discussion 117
11.1 Dynamic Positioning System . . . . . . . . . . . . . . . . . . . . . . . 118

ix
Table of Contents

11.2 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

11.3 Station Keeping and Low-Speed Maneuvering . . . . . . . . . . . . . . 118
11.4 Docking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.5 Practical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 121
11.5.1 ”Behind the Scenes” Work . . . . . . . . . . . . . . . . . . . . 121
11.5.2 Threshold for Field Tests . . . . . . . . . . . . . . . . . . . . . 121

12 Conclusion and Future Work 123

12.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
12.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Bibliography 126

Appendices 131

A Media Coverage 133

B ReVolt Wiring Schematic 135

C Introduction to ROS 137

D ROS Graphs 145

E Relevant Output From WADAM Simulations 151

F Instructions for Users of ReVolt 153

x
List of Figures

1.1 Rolls-Royce and Kongsberg Maritime’s flagship projects. . . . . . . . . 2

1.2 Cable ferries operational in Norway. . . . . . . . . . . . . . . . . . . . 2
1.3 Map of the planned route for the autonomous ferry. Courtesy of Egil Eide. 3
1.4 Conceptual image of the autonomous ferry in Trondheim, seen from Vestre
Kanalkai. Courtesy of Svein Aanond Aanondsen, NTNU. . . . . . . . . 4

2.1 The different reference frames. Blue is ECEF, green is NED, orange is
BODY and yellow is latitude and longitude. . . . . . . . . . . . . . . . 8
2.2 Degrees of Freedom of a vessel. The numbers correspond to those in
Table 2.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Block diagram of the DP system with the guidance system highlighted in
blue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Block diagram of a 1-DOF reference filter. . . . . . . . . . . . . . . . . 14
3.3 Block diagram of the reference filter with the ”carrot function” imple-
mented. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Relationship between reference, output, saturated input and input of the
reference filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Desired velocity and acceleration from the reference filter. . . . . . . . . 19

4.1 Block diagram of the DP system with the control system highlighted in
blue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 A vessel using a dynamic positioning control system must use its thrusters
actively to counteract the environmental forces it is subjected too. Cour-
tesy of Kongsberg Maritime. . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Thruster model and thrust region for a tunnel thruster and an azimuth
thruster. The figure is adapted from Wit (2009). . . . . . . . . . . . . . . 27
4.4 The thruster configuration for ReVolt introduced in Chapter 6, decom-
posed along the body x- and y-axis. . . . . . . . . . . . . . . . . . . . . 29

xi
List of Figures

5.1 Block diagram of the DP system with the navigation system highlighted
in blue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Wild points were recorded as far away as the Equator and Eastern Europe,
while performing tests in Trondheim, Norway. . . . . . . . . . . . . . . 41
5.3 Block diagram detailing the navigation system. . . . . . . . . . . . . . . 42

6.1 The model-scale ship ReVolt under way at Havnebasseng VI in Trondheim. 43

6.2 An illustration of the concept ship, ReVolt. Courtesy of DNV GL. . . . . 44
6.3 Main components and their placements on the ReVolt model. Adapted
from STT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.4 Detailed overview of the thruster setups and their components. Adapted
from STT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.5 The Xsens-MTI-G-710 GNSS and IMU unit, mounted inside ReVolt. . . 47
6.6 Hemisphere mounted in ReVolt and the Radio link connected. . . . . . . 48
6.7 Close up of the stern boat tower. From the left: Light beacon, Wi-Fi
antenna, GNSS antenna, Wi-Fi antenna, radio link antenna. . . . . . . . 49

7.1 How the hardware is connected in ReVolt. . . . . . . . . . . . . . . . . 52

7.2 The Graphical User Interface programmed for the operators of ReVolt. . 53
7.3 Choosing the operating mode of ReVolt using the laptop. . . . . . . . . . 54
7.4 Block diagram of the nodes used for manual control and which program-
ming language is used to program them. . . . . . . . . . . . . . . . . . 54
7.5 Block diagram of the nodes used for manual thrust allocation control and
which programming language is used to program them. . . . . . . . . . 55
7.6 Block diagram of the nodes in the DP controller and which programming
language is used to program them. . . . . . . . . . . . . . . . . . . . . . 55
7.7 Communication flow between ROS and the optimization solver. . . . . . 57
7.8 Plot of the manual run in Nanotec’s software NanoPro of the PD2-N41
stepper motors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.1 Center of Gravity on ReVolt. . . . . . . . . . . . . . . . . . . . . . . . . 61

8.2 The dimensions of ReVolt, indicating the Center of Gravity and the thrusters
placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.3 Weighing ReVolt using a crane and a digital scale. . . . . . . . . . . . . 64
8.4 Measured and interpolated thrust force Fi for different inputs. . . . . . . 67
8.5 ReVolt’s available thrust for all directions with F1max = F2max = 25,
F3max = 14 and F3min = −6.1 . . . . . . . . . . . . . . . . . . . . . . 67
8.6 Kjetil performing a bollard pull test with a luggage scale. Photo by Egil
Eide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

9.1 Simulation created in Simuliunk. . . . . . . . . . . . . . . . . . . . . . 69

9.2 The 4-corner box test. . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.3 Simulation of the 4-corner box test with CyberShip II. . . . . . . . . . . 73
9.4 Reference, desired and actual pose of CyberShip II. . . . . . . . . . . . 74
9.5 Desired and actual velocity of CyberShip II. . . . . . . . . . . . . . . . 74

xii
 List of Figures

9.6 Desired thrust and thruster angle from the thrust allocation. The spikes in
α1,2 at t=40s is due to wrapping around 180◦ . . . . . . . . . . . . . . . 75
9.7 Controller output, divided into PID, feedforward and total control effort. 75

10.1 Mounting of Seapath and Xsens IMUs on Telemetron. . . . . . . . . . . 78

10.2 Stationary vessel measurements showing drift in Xsens position and mount-
ing difference between Vector and Seapath antennas. . . . . . . . . . . 78
10.3 Estimated positions in NED compared to the Vector and Seapath. The
error between the Seapath measurements and Xsens measurements are
scaled down with a factor of 10 for comparability between the Xsens and
Vector measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.4 Estimated orientation compared to the Xsens, Vector’s GNSS-compass
and Seapath. Notice that the Xsens with AHRS enabled, fails to find true
north and is therefore prone to a slowly varying bias. . . . . . . . . . . . 81
10.5 Body velocity estimate comparisons. Xsens velocity is rotated from NED
using Seapath orientation. . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.6 The estimated IMU biases, where a is the acceleration and ω is the angu-
lar rate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
10.7 An extract of the orientation estimates comparison data, from t=35-55s.
Xsens’ estimate of ψ is excluded in bottom left plot as it’s offset is too big. 83
10.8 An extract of the body velocity estimates comparison data, from t=35-
55s. Xsens’ velocity is rotated from NED using Seapath angles, making
the measurements more precise, rather than using the Xsens angle where
yaw is not North referenced. . . . . . . . . . . . . . . . . . . . . . . . . 84
10.9 An extract of the estimated positions in NED compared to the Vector and
Seapath, from t=35-55s. . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.10 Online ESKF performance during a 4-corner box maneuver. Est is esti-
mated, Vec is measurements from the Vector. . . . . . . . . . . . . . . . 86
10.11 Online ESKF performance during a 4-corner box maneuver. Est is esti-
mated, Xse and Vec is measurements from the Xsens and Vector respec-
tively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.12 Online ESKF performance during a 4-corner box maneuver. Est is esti-
mated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.13 Online ESKF performance during a 4-corner box maneuver. Est is esti-
mated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.14 Comparison of vessel velocity estimated by the Xsens or computed by
derivation of the position. The velocities are rotated to BODY using the
yaw measurements from the Hemisphere Vector VS330. . . . . . . . . . 88
10.15 The test area at Havnebasseng III. Adapted from Gulesider® Kart. . . . . 90
10.16 All vessel trajectories for static bow thruster with no constraints on ∆α
in the thrust allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
10.17 All vessel trajectories for static bow thruster with constraints on ∆α in
the thrust allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
10.18 Performance metrics - static bow thruster with no constraints on ∆α in
the thrust allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

xiii
List of Figures

10.19 Comparison of the two best vessel trajectories with unconstrained and
constrained ∆α in the thrust allocation. . . . . . . . . . . . . . . . . . 96
10.20 Comparison of the two best vessel trajectories over time using uncon-
strained and constrained ∆α in the thrust allocation. . . . . . . . . . . . 96
10.21 Comparison of the velocity for the two best vessel trajectories with un-
constrained and constrained ∆α in the thrust allocation. . . . . . . . . . 97
10.22 Comparison of the thrust allocation for the two best vessel trajectories
with unconstrained and constrained ∆α in the thrust allocation. . . . . . 97
10.23 Comparison of the controller output for the two best vessel trajectories
with unconstrained and constrained ∆α in the thrust allocation. . . . . . 98
10.24 All vessel trajectories with rotating bow thruster α˙3 6= 0◦ . . . . . . . . . 100
10.25 All vessel trajectories with static bow thruster α3 = 90◦ . . . . . . . . . . 100
10.26 Performance metrics - Rotating bow thruster α˙3 6= 0 vs static bow thruster
α3 = 90◦ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
10.27 Comparison of the two best vessel trajectories with rotating bow thruster
α˙3 6= 0 vs static bow thruster α3 = 90◦ . . . . . . . . . . . . . . . . . . 101
10.28 Comparison of the two best vessel trajectories over time using rotating
bow thruster α˙3 6= 0 vs static bow thruster α3 = 90◦ . . . . . . . . . . . 102
10.29 Comparison of the velocity for the two best vessel trajectories with rotat-
ing bow thruster α˙3 6= 0 vs static bow thruster α3 = 90◦ . . . . . . . . . 102
10.30 Comparison of the thrust allocation of the two best vessel trajectories
with rotating bow thruster α˙3 6= 0 vs static bow thruster α3 = 90◦ . . . . 103
10.31 Comparison of the controller output for the two best vessel trajectories
with rotating bow thruster α˙3 6= 0 vs static bow thruster α3 = 90◦ . . . . 103
10.32 All vessel trajectories for PID with original feedforward. . . . . . . . . . 105
10.33 All vessel trajectories for PID with tuned feedforward. . . . . . . . . . . 105
10.34 Performance metrics - PID with original feedforward and tuned feedfor-
ward. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
10.35 Comparison of the two best vessel trajectories with PID with original
feedforward and tuned feedforward. . . . . . . . . . . . . . . . . . . . . 106
10.36 Comparison of the two best vessel trajectories over time using PID with
original feedforward and tuned feedforward. . . . . . . . . . . . . . . . 107
10.37 Comparison of the velocity for the two best vessel trajectories with PID
with original feedforward and tuned feedforward. . . . . . . . . . . . . 107
10.38 Comparison of the controller output for two best vessel trajectories with
PID with original feedforward and tuned feedforward. . . . . . . . . . . 108
10.39 Performance metrics - PID vs PID with tuned feedforward. . . . . . . . 110
10.40 Comparison of the two best vessel trajectories with PID and PID with
tuned feedforward. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.41 Comparison of the two best vessel trajectories over time using PID and
PID with tuned feedforward. . . . . . . . . . . . . . . . . . . . . . . . . 111
10.42 Comparison of the velocity for the two best vessel trajectories with PID
and PID with tuned feedforward. . . . . . . . . . . . . . . . . . . . . . 111
10.43 Comparison of the thrust allocation for the two best vessel trajectories
with PID and PID with tuned feedforward. . . . . . . . . . . . . . . . . 112

xiv
 List of Figures

10.44 Comparison of the controller output for the two best vessel trajectories
with PID and PID with tuned feedforward. . . . . . . . . . . . . . . . . 113
10.45 Position and heading of ReVolt when performing a docking maneuver. . 114
10.46 Velocity of ReVolt when performing a docking maneuver. Slight oscilla-
tions occur due disturbances and imperfect controller tuning. . . . . . . 115

11.1 ReVolt in sunset at Trondheim harbour 17 November 2016. . . . . . . . 117

11.2 The best 4-corner box maneuver achieved by ReVolt. The outline has the
same dimensions as ReVolt. . . . . . . . . . . . . . . . . . . . . . . . . 119
11.3 Enhanced portion of the North-West corner of the 4-corner box maneu-
ver, with the Center of Gravity of marked. The outline has the same
dimensions as ReVolt. . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

A.1 Henrik and Kjetil operating ReVolt while being filmed by the German
TV-channel ZDF. Courtesy of Trondheim Havn . . . . . . . . . . . . . . 133

D.1 A simple ROS graph showing the sharing of information between two
nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
D.2 ROS graph showing the system structure of the entire system on ReVolt. 146
D.3 ROS graph showing the system structure of the necessary elements to
control ReVolt in dynamic positioning mode. . . . . . . . . . . . . . . 147
D.4 ROS graph showing the system structure of the necessary elements to
control ReVolt in manual thrust allocation mode. . . . . . . . . . . . . 148
D.5 ROS graph showing the system structure of the necessary elements to
control ReVolt in heading controller mode. . . . . . . . . . . . . . . . . 149
D.6 ROS graph showing the system structure of the necessary elements to
control ReVolt in manual mode. . . . . . . . . . . . . . . . . . . . . . 150

xv
List of Tables

2.1 The notation for marine vessels adopted from SNAME (1950). . . . . . . 9

5.1 Error-State Kalman Filter overview, where ⊕ and are the generic com-
position to respectively add and subtract. (Solà, 2017) . . . . . . . . . . . 33

6.1 Basic stats for the model ship ReVolt. . . . . . . . . . . . . . . . . . . . 44

6.2 Xsens specifications (Xsens, 2016). . . . . . . . . . . . . . . . . . . . . 47
6.3 Specifications on the Hemisphere RTK GNSS (Hemisphere, 2017). . . . . 48
6.4 Signal logic for the light beacon. . . . . . . . . . . . . . . . . . . . . . . 49

7.1 Thrust allocation parameters. . . . . . . . . . . . . . . . . . . . . . . . . 56

7.2 The sampling rate of the two GNSSs and the IMU. . . . . . . . . . . . . 58

8.1 Breakdown of the different weights in the experiment. All units are in kg. 63

10.1 The test scenarios and in which order they were tested. . . . . . . . . . . 92

xvii
List of Algorithms

3.1 Algorithm to rotate the shortest way between two heading angles. . . . . 18
4.1 Saturating element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Pseudocode for wrapping of the yaw. . . . . . . . . . . . . . . . . . . . . 26
5.1 Pseudocode for the Error-State Kalman Filter. . . . . . . . . . . . . . . . 39

xix
List of Abbreviations

AHRS Attitude Heading Reference System

ARPA Automatic Radar Plotting Aid

BODY Body-fixed

CG Center of Gravity
CO Center of Origin
CSV Comma-Separated Values

DOF Degree of Freedom

DP Dynamic Positioning

ECEF Earth-Centered-Earth-Fixed
EGNOS European Geostationary Navigation Overlay Ser-
vice
EOL End-of-Life
ESC Electronic Speed Controller
ESKF Error-State Kalman Filter

GNSS Global Navigation Satellite System

GPS Global Positioning System
GUI Graphical User Interface

HIL Hardware In the Loop

I/O Input/Output
IADC Integral of Absolute Differentiated Control

xxi
List of Abbreviations

IAE Integrated Absolute Error

IMU Inertial Measurement Unit
INS Inertial Navigation System
IP Internet Protocol

LIDAR Light Detection and Ranging

LLA Longitude-Latitude-Altitude
LOS Line of Sight
LPP Length Between Perpendiculars
LQR Linear Quadratic Regulator

NED North-East-Down
NMEA National Marine Electronics Association
NTNU Norwegian University of Science and Technology

OBC Onboard Computer

PID Proportional-Integral-Derivative
PWM Pulse Width Modulation

ROS Robot Operating System

RTK Real-Time Kinematic

SBAS Satellite-Based Augmentation System

STT Stadt Towing Tank

TA Thrust Allocation
TCP Transmission Control Protocol

USB Universal Serial Bus

WADAM Wave Analysis by Diffraction and Morison

xxii
Nomenclature

{B} Denotation of the value being a bias signal

{N} Denotation of the value being a noise signal
{b} Denotation of the Body-fixed frame
{d} Denotation of the value being a desired signal from the reference filter
{e} Denotation of the Earth-Centered-Earth-Fixed frame
{g} Denotation of the Geodetic Longitude-Latitude-Altitude frame
{n} Denotation of the North-East-Down frame
{ref} Denotation of the value being a reference signal from the operator
η Position and orientation vector
ν Linear and angular velocity vector
τ Forces and moments vector
p Position vector
Θ Vector of Euler angles
v Linear velocity vector
ω Angular velocity vector
f Force vector
m Moment vector
N, E, D North, East, Down position in the North-East-Down frame
x, y, z Body-fixed position in the x, y, z direction
φ, θ, ψ Euler angle about the x, y and z axis

xxiii
Nomenclature

u, v, w Body-fixed linear velocity in the x, y and z direction

p, q, r Body-fixed angular velocity about the x, y and z axis
X, Y, Z Body-fixed force in the x, y and z direction
K, M, N Body-fixed moment about the x, y and z axis
l, µ Longitude and Latitude
M Inertia Matrix
MRB Rigid-body Inertia Matrix
MA Added Mass Matrix
C Coriolis-Centripetal Matrix
CRB Rigid-body Coriolis-Centripetal Matrix
CA Added Mass Coriolis-Centripetal Matrix
D Damping Matrix
DL Linear Damping Matrix
Dn Non-linear Damping Matrix
∆ Relative damping ratio matrix
Ω Natural frequency matrix
KP ,KD ,KD Controller gains for the Proportional-Integral-Derivative controller
F Thrust force vector
Fi Thrust force for thruster i
α Thruster angle vector
αi Thruster angle for thruster i
lxi ,lyi Distance from the Center of Gravity to thruster i in the x and y direction
q Quaternion vector, where q = [qw , q v ]T = [qw , qx , qy , qz ]T
∆t Variable time step
I Identity matrix
R Rotation matrix
S(x) Skew matrix of a vector x
h Fixed time step
n Degrees of Freedom
s(x), c(x) Sine and cosine of x

xxiv
Chapter 1
Introduction

This chapter provides background and motivation for the work on this thesis, a problem
description and the thesis’ relevance to the local community. The authors contributions are
described as well as an outline for this report.

1.1 Background

During the past century automation has revolutionized numerous industries by replacing
manual labor with automated machinery, and in recent years automation has entered our
homes in the form of lawn mowers, vacuum cleaners or even the house itself. A shift from
automated systems, which specialize on one task, to autonomous systems, which is capable
of self governing complex tasks without human interaction, has emerged. Examples of
autonomous systems are Google’s self driving cars and the Mars rover Curiosity.
The automation of ships began back in the early 1900’s when the American entrepreneur
Elmer Sperry’s gyrocompass invention made it possible to get a reliable measurement of
the ships’ heading (Breivik, 2010). A few years later, in 1922, the Russian-born electrical
engineer Nicolas Minorsky wrote a paper with a theoretical analysis of the Proportional-
Integral-Derivative (PID) controller for autopilots in ships. Simultaneously Sperry con-
ducted field trials with his so-called gyropilot, popularly termed ”Metal Mike” which
proved to be a success. Although unaware of each other, Sperry and Minorsky laid the
foundation for the successful application of ship autopilots in the following years.
The next major advances in control-related ship technology came in the 1960’s and 70’s
with computer based bridge control, power management systems, Automatic Radar Plot-
ting Aid (ARPA) and Dynamic Positioning (DP). Norway having the fourth largest trad-
ing fleet and a booming offshore industry at the time, played a key role in many of these
advances. This has resulted in an advanced Norwegian ship automation industry, with

1
Chapter 1. Introduction

(a) Stella. Courtesy of Rolls-Royce. (b) Yara Birkeland. Courtesy of Yara.

Figure 1.1: Rolls-Royce and Kongsberg Maritime’s flagship projects.

companies such as Rolls-Royce and Kongsberg Maritime being key technology suppliers
within the ship market.
Inspired by Google’s self driving cars, the industry now focus on taking the next leap.
Currently, both Rolls-Royce and Kongsberg Maritime, through respectively Stella and
Yara Birkeland, are working towards being the first company to develop an autonomous
ship for industrial use. Stella is a double ended ferry that will have additional equipment
installed for autonomous testing purposes (Rolls-Royce, 2016), and Yara Birkeland pro-
claimed to be the first fully electric and autonomous container ship (Yara, 2017). Both
ships are shown in Figure 1.1.

1.2 Motivation: Autonomous Ferry

There are many cities built around rivers which have small islands in the city center. To
ease the access for pedestrians, a small autonomous passenger ferry can be advantageous
compared to bridges, both due to costs and navigability for other vessels. There are cur-
rently several cable driven ferries in Norway, a few shown in Figure 1.2, which potentially
can be replaced by autonomous versions.

(a) Cable ferry Nesøya - Brønnøya, Norway. (b) Cable ferry Espevær - Bømlo, Norway.

Figure 1.2: Cable ferries operational in Norway.

In Trondheim, the possibility of building a footbridge from Ravnkloa to Fosenkaia is con-

sidered. However this would create an obstacle for the boat traffic in the river and impair
the maritime and cultural values the river represents for Trondheim. As a result of this, the
idea of an autonomous ferry to cross the river was brought to life. This ferry will travel
between Ravnkloa and Venstre Kanalkai, as shown in Figure 1.3 (Stensvold, 2016).

2
 1.2 Motivation: Autonomous Ferry

Figure 1.3: Map of the planned route for the autonomous ferry. Courtesy of Egil Eide.

The idea is that the ferry will be operational for most of the day and be a ”ferry on de-
mand”. The stretch across the river is about 95 meters and the ferry will only sail across
the river when there are passengers on board or it has been ”demanded” by a passenger on
the other side. The ferry is planned to have up to 12 passengers, including bikes, and be
designed to accommodate wheelchairs and prams, see Figure 1.4. The ferry is planned to
be operational by 2019, having gone through three phases of design and testing. The first
of these three phases includes the development and testing of a control system and sensors
on the experimental platform ReVolt.

1.2.1 Extension of Previous Work

During the summer 2016 the authors worked on interfacing an Onboard Computer (OBC)
with actuators and sensors on the model ship ReVolt. Manual control and a rudimentary
heading controller, using a Inertial Navigation System (INS), was achieved. The work
continued into a joint project during the fall 2016, which resulted in the acquirement of
an additional Global Navigation Satellite System (GNSS) and implementation of a simple
DP control system (Alfheim and Muggerud, 2016). Furthermore, during field tests Re-
Volt achieved station keeping abilities. This could however be improved and extended to
include maneuvering which is one of the objectives of this thesis.

3
Chapter 1. Introduction

Figure 1.4: Conceptual image of the autonomous ferry in Trondheim, seen from Vestre Kanalkai.
Courtesy of Svein Aanond Aanondsen, NTNU.

1.3 Problem Description

This thesis considers the problem ”Development of a Dynamic Positioning System for the
ReVolt Model Ship”. This work includes:
• Improve the current DP system for the model ship ReVolt, including reference filter,
thruster allocation, motion controller and observer.
• A simulation of the DP system, using CyberShip II as a ship model, for proof of
concept.
• Improve the system architecture of the system on ReVolt to allow for a easier user
experience.
• Perform experimental sea trials to obtain results and test the DP system of ReVolt.

1.4 Contributions

The thesis has generated a lot of media attention around the autonomous ferry project and
unmanned vessels in general. A summary of all the media coverage created by this thesis
is found in Appendix A.
The main contributions are listed below:
• Improvement of the reference filter to include a saturating element.
• Creation of a 3-Degree of Freedom (DOF) mathematical model of ReVolt to improve
the motion controller with a model-based reference feedforward term.
• Improvement of the thrust allocation to include the dynamics of thrusters.

4
 1.5 Outline

• Development of a simulation using the ship model of CyberShip II in MATLAB to

verify that each part of the DP system works as expected.
• Implementation of the improved DP system on the OBC in ReVolt. This included
translating MATLAB code into Python and adding the necessary code to make the
algorithms work together in another environment.
• Assessment of weaknesses and strengths of the navigational sensors used in the
observer onboard ReVolt.
• Develop the software structure and a Graphical User Interface (GUI) to make it
easier to operate ReVolt.
• Execution of numerous experiments in Trondheim harbour to assess the perfor-
mance of the improved control system of ReVolt, where station keeping and low-
speed maneuvering was achieved.
• Participation in a live demonstration of unmanned surface and sub-surface vehicles
at the Norwegian University of Science and Technology (NTNU) Ocean Week on
the 3rd May 2017.
• Suggestion of future work which can be done with ReVolt on its path to becoming
an autonomous vessel.

1.5 Outline
The report is organized in the following manner:
• Chapter 2 is an introduction of the background theory which is used throughout the
report.
• Chapter 3 goes through the theory for the guidance system which is used in the DP
system.
• Chapter 4 goes through the theory for the control system, more specifically the mo-
tion controller and the thrust allocation.
• Chapter 5 introduces the navigation system, which includes a Kalman Filter, wild
point filter and lever arm compensation.
• Chapter 6 describes the sensors and actuators on the experimental platform ReVolt.
• Chapter 7 describes how the components and system structure is implemented.
• Chapter 8 describes the creation of the mathematical model of ReVolt.
• Chapter 9 describes the result from the simulation of the DP system.
• Chapter 10 describes the performance of the observer and the experimental results
of sea-trials with ReVolt.
• Chapter 11 and 12 are a discussion and conclusion of the thesis as a whole.

5
Chapter 2
Theoretical Background

The theoretical background needed in this report is covered in this chapter.

2.1 Reference Frames

The kinematic relationship for a vessel can be described in various reference frames. The
most common frames used for terrestrial navigation include a global system, a local geo-
graphic system and lastly a system fixed to the vessel itself.
The frames, as seen Figure 2.1, are:
• ECEF Earth-Centered-Earth-Fixed (ECEF) frame is a Cartesian coordinate system
which rotates around the Earth’s spin axis. A fixed point on the Earth’s surface can
be represented by a fixed set of coordinates denoted {e}, Pe = (xe , ye , ze )T . ECEF
can also be represented as a geodetic coordinate frame Longitude-Latitude-Altitude
(LLA), which is widely used in GNSS-based navigation. It characterizes a coordi-
nate point near the Earth’s surface with longitude, latitude and altitude denoted by
{g}, Pg = (l, µ, h)T
• NED The local North-East-Down (NED) frame is defined relative to the Earth’s ref-
erence ellipsoid. The z-axis points downward perpendicular to the tangent plane,
and the x-axis points towards the true north. This makes it intuitive for local navi-
gation and is denoted by {n}, Pn = (xn , yn , zn )T
• BODY The Body-fixed (BODY) frame is moving and rotating with the vehicle,
where usually the x-axis points in the forward direction, the y-axis to the right and
the z-axis downward. Denoted by {b}, Pb = (xb , yb , zb )T
The following notation will be used to describe position, linear velocities and angular
velocities (Fossen, 2011):

7
Chapter 2. Theoretical Background

Zecef
N orth

N ED plane

East
Xbody

P rimeM eridian Zbody

Down
ybody

µ Yecef

Xecef

Figure 2.1: The different reference frames. Blue is ECEF, green is NED, orange is BODY and
yellow is latitude and longitude.

e
vb/n = linear velocity of the point ob with respect to {n} expressed in {e}
ω bn/e = angular velocity of {n} with respect to {e} expressed in {b}
fbn = force with line of action through the point ob expressed in {n}
mbn = moment about the point ob expressed in {n}
pnn/b = distance from {n} to {b} expressed in {n}
Θnb = Euler angles between {n} and {b}

For a marine craft moving in 6-DOF, six independent coordinates are needed to describe
position and orientation. The notation of forces and motion in Table 2.1 are adopted from
SNAME (1950). The elements in Table 2.1 can be written in vectors according to:

" #
v bb/n
 n 
f bb
 
p
η = b/n , ν= , τ = (2.1)
Θnb ω bb/n mbb

where

8
 2.1 Reference Frames

Forces and Linear and Positions and

DOF
moments angular velocities Euler angles
1 motion in the x direction (surge) X u x
2 motion in the y direction (sway) Y v y
3 motion in the z direction (heave) Z w z
4 rotation about the x axis (roll) K p φ
5 rotation about the y axis (pitch) M q θ
6 rotation about the z axis (yaw) N r ψ

Table 2.1: The notation for marine vessels adopted from SNAME (1950).

Top 1 3 Stern
Starboard Side 5

2
Figure 2.2: Degrees of Freedom of a vessel. The numbers correspond to those in Table 2.1.

   
N φ
NED position pnb/n =  E  ∈ R3 Attitude Θnb =  θ  ∈ S3
D ψ
   
u p
Body-fixed Body-fixed
v bb/n =  v  ∈ R3 ω bb/n =  q  ∈ R3
linear velocity angular velocities
w r
  
X K
Body-fixed Body-fixed
f bb =  Y  ∈ R3 mbb = M  ∈ R3
force moment
Z N

9
Chapter 2. Theoretical Background

2.1.1 Transformation Between ECEF and NED Frames

The rotation from ECEF to NED is stated in Vik (2014) and is is represented by the fol-
lowing matrix:
 
−c(l)s(µ) −s(l) −c(l)c(µ)
Rne (Θen ) = −s(l)s(µ) c(l) −s(l)c(µ) (2.2)
c(µ) 0 −s(µ)
where s = sin, c = cos, l is longitude and µ is latitude.

2.1.2 Transformation Between BODY and NED Frames

The rotation from BODY to NED is stated in Vik (2014) and is is represented by the
following matrix:
 
c(ψ)c(θ) −s(ψ)c(φ) + c(ψ)s(θ)s(φ) s(ψ)s(φ) + c(ψ)s(θ)c(φ)
Rbn (Θ) = s(ψ)c(θ) c(ψ)c(φ) + s(ψ)s(θ)s(φ) −c(ψ)s(φ) + s(ψ)s(θ)c(φ)
−s(θ) c(θ)s(φ) c(θ)c(φ)
(2.3)
where s = sin and c = cos.
The transformation from NED to BODY is given by
Rbn (Θ)T = Rnb (Θ) (2.4)

2.2 The 3-DOF Ship Maneuvering Model

A ship’s full maneuvering model contains 6-DOF differential equations of motion. These
are referred to as surge, sway and heave for the ship’s position, and roll, pitch and yaw
for the orientation of the ship, see Table 2.1. Since the scope of this thesis is to maneuver
a vessel in the horizontal plane, the model can be simplified. For a ship one can assume
small amplitudes in roll and pitch, φ = θ ≈ 0, and since the ship is floating, heave is also
discarded z ≈ 0.
From Fossen (2011), the 3-DOF marine craft equations of motion is written as:

η̇ = R(ψ)ν (2.5)
M ν̇ + C(ν)ν + D(ν)ν = τ thruster + τ environmental (2.6)

where rotation is performed about the z-axis with the matrix

 
cos ψ − sin ψ 0
R(ψ) =  sin ψ cos ψ 0 (2.7)
0 0 1

10
 2.2 The 3-DOF Ship Maneuvering Model

In the rest of the thesis, the simplified notation of R is used to represent the rotation matrix
from BODY to NED.
M in (2.6) is the inertia matrix, which is the sum of rigid-body inertia matrix M RB and
hydrodynamic added mass M A .

   
m 0 0 −Xu̇ 0 0
M = M RB + M A = 0 m mxg  +  0 −Yv̇ −Yṙ  (2.8)
0 mxg Iz 0 −Yṙ −Nv̇

where m is rigid-body mass, xg is the distance from Center of Origin (CO) to Center of
Gravity (CG) and Iz is the moment of inertia about the Zb axis.
Further, C(ν) in (2.6) consists of Coriolis and Centripetal terms which occurs due to
rotation of the vessel about the NED frame:

C(ν) = C RB (ν) + C A (ν) (2.9)

where

 
0 0 −m(xg r + v)
C RB (ν) =  0 0 mu  (2.10a)
m(xg r + v) −mu 0
 
0 0 Yv̇ v + Yṙ r
C A (ν) =  0 0 −Xu̇ u  (2.10b)
−Yv̇ v − Yṙ r Xu̇ u 0

D(ν) consists of the damping forces which usually are modelled as a sum of constants
and some velocity dependent terms (Fossen, 2011):

 
−Xu 0 0
D(ν) = D L + D n (ν) =  0 −Yv −Yr  +
0 −Nv −Nr
  (2.11)
X|u|u |u| 0 0
 0 −Y|v|v |v| − Y|r|v |r| −Y|v|r |v| − Y|r|r |r| 
0 −N|v|v |v| − N|r|v |r| −N|v|r |v| − N|r|r |r|

For a vessel operating around zero speed, it is reasonable to assume that linear damping
D L will dominate over D n (ν).

11
Chapter 2. Theoretical Background

2.3 Global Navigation Satellite System

A Global Navigation Satellite System (GNSS) is a positioning system based on satellites.
By the use of four or more satellites it is possible to acquire the 3D position of the receiver
in the ECEF frame and transform it into more understandable Latitude and Longitude
coordinates.
There are different GNSS to choose from, the most known being the Global Positioning
System (GPS). GPS was created by the United States of America in 1993 and originally
developed for military purposes (Vik, 2014). In later years, GPS has been opened for
civilian use and is now used in many applications.
A conventional GNSS receiver uses pseudo-random codes, transmitted from the satel-
lites, to determine the range to the satellites. By knowing the position of the satellites
and these ranges, the receiver is able to compute a position. The accuracy is usually in
the area of a few meters, but this can be improved using GNSS augmentation systems,
like Satellite-Based Augmentation System (SBAS) or Differential GNSS like Real-Time
Kinematic (RTK).
SBAS is a network of geostationary satellites which transmits correction data. The SBAS
system which primarily covers Europe is called European Geostationary Navigation Over-
lay Service (EGNOS). To get a higher accuracy, RTK GNSS can be used. The receiver
uses the signal from a RTK GNSS base station, with a known location, to correct the po-
sition of the receiver. This can give an accuracy in the range of a few centimeters. For an
in-depth explanation of how GNSS and augmentation systems works, see Vik (2014).
There are several error sources for GNSS receivers. A possible error source for marine
surface vessels is multipath interference, which occurs when the device receives reflected
signals in addition to the direct Line of Sight (LOS) signal. These interference signals are
generally reflected from the ground/sea, buildings or trees. Therefore, by mounting the
antennas further away from the sea, it will help mitigate the interference from multipath
(Parkinson, 1996).
The National Marine Electronics Association (NMEA), has developed a standard message
structure for communication between GNSS and other hardware. This standard makes it
easy to mix and match software and hardware, and for software developers life is made
easier as they can create software for many different GNSS receivers and not only one. A
common NMEA standard is NMEA 0183, which has several NMEA sentences containing
different information.

12
Chapter 3
Guidance System

This chapter describes the design of a guidance system which can be part of a DP system,
see Figure 3.1. This involves a position and attitude reference filter, saturation of the
desired velocity and discretization of the reference filter.

Waves,
wind and
ocean
currents

η ref η d , ν d , ν̇ d τ u η
Reference Thrust Ship
Controller Sensors
filter Allocation

η estimated
ν estimated

Observer
η estimated
Guidance System Control System
Navigation System

Figure 3.1: Block diagram of the DP system with the guidance system highlighted in blue.

3.1 Reference Filter

A reference filter is used to generate a suitable trajectory which the vessel can follow. For
big changes in setpoint, the controller will act on a big error which in most cases will lead
to a sudden huge demand in control effort. This may then generate unwanted behavior
from the vessel. In order to generate a suitable trajectory for position and attitude, a third

13
Chapter 3. Guidance System

order linear reference filter has been chosen. The reference filter is defined as stated in
Fossen (2011):

...
η d + (2∆ + I)Ωη̈ d + (2∆ + I)Ω2 η̇ d + Ω3 η d = Ω3 η ref (3.1)
3
where η d ∈ R is the desired pose, given in the NED frame. The input to the filter is
η ref ∈ R3 and is given in the NED frame. The output, η d and the input, η ref are given
by:    
Nd Nref
η d =  Ed  η ref =  Eref  (3.2)
ψd ψref

The diagonal matrix ∆ > 0, contains the relative damping ratios, ζi , i = 1, 2, 3, and
Ω > 0 is a diagonal matrix with the the natural frequencies, ωi , i = 1, 2, 3.
The continuous equation for the reference filter in (3.1) can be written in the state-space
form

ẋ = Ax + Bu (3.3)

as
      
η̇ d 0 I 0 ηd 0
 η̈ d  =  0 0 I  η̇ d  +  0  η nref (3.4)
...
ηd −Ω3 −(2∆ + I)Ω2 −(2∆ + I)Ω η̈ d Ω3
...
The desired jerk, η , acceleration, η̈ and velocities,η̇ are all given in the NED frame. A
block diagram of the reference filter is shown in Figure 3.2.

η ref R η̈ d R η̇ d R ηd
ωn ωn2
− −
−

2ζωn

2
ωn

Figure 3.2: Block diagram of a 1-DOF reference filter.

3.1.1 Tuning the Reference Filter

The reference filter must be tuned not to exceed the velocity and acceleration values ob-
tainable by the vessel as well as any limits set by the user.

14
 3.1 Reference Filter

An experimental study on how passenger comfort is related to a vehicles’ longitudinal di-

rection was conducted by The University of Texas at Austin for the Department of Trans-
portation in Washington D.C. (Hoberock, 1976). The goal of the study was to determine
which acceleration and jerk that would make the ride comfortable for passengers. Even
though the study could not decisively conclude with any precise values for acceptable
acceleration and jerk, it did indicate a range of values which are suitable. Acceleration
should be in the range 0.11 − 0.15g or 1.08 − 1.47m/s2 . The study also concluded that a
jerk less than 0.30g/s would be acceptable for most passengers.
In the reference filter there are two parameters which can be used to tune the filter. These
two values are the ∆ ∈ R3×1 and Ω ∈ R3×1 . ∆ is the damping ratio and determines how
stiff the system is. An overshoot is not desirable when the reference filter will be used for
movements close to obstacles like other ships or a dock. Since it is not desirable with an
overshoot in any of the 3-DOF, the system has been tuned to be critically damped:
   
ζN 1
∆ =  ζE  = 1 (3.5)
ζψ 1

Ω is the ”natural frequency” of the filter or rather the convergence parameter. This deter-
mines how quickly the filter reacts and converges to the input.

3.1.2 Reference Saturation

A disadvantage of the linear reference filter is that it will only yield a suitable response for
a fixed setpoint, while the response for a different setpoint will give a different behavior.
This behavior may not be obtainable by the vessel. In order to assure that the filter always
generates a suitable and obtainable trajectory, amplitude gain scheduling of the tuning
parameters (Fossen, 2011) can be used or the input of the reference filter can be saturated.
A saturation of the input, η ref , has been created. If the input is larger than a set max value,
the input will be saturated and moved along, ahead of the states of the filter, until it reaches
the actual or final input value. This function can be seen as holding a carrot on a stick in
front of a donkey, where the carrot is the reference point and the donkey is the filter state.
The maximum distance the input should be ahead of the ship, in the NED frame, is dif-
ferent depending on the desired heading of the ship. When the ship’s desired heading is
due north the reference, or carrot, can be place further away in the north direction, than
when the ship is pointing due east. This is because the ship can achieve a higher surge
speed than sway speed. The difference between the reference filter state and the final input
is rotated into the BODY frame and saturated to the desired maximum distances, before
being rotated back to the NED frame.
With this reference saturation, (3.1) is modified to include this feature.
...
η d + (2∆ + I)Ωη̈ d + (2∆ + I)Ω2 η̇ d + Ω3 η d = Ω3 η input (3.6)

15
Chapter 3. Guidance System

where η input = η d + R(ψd )(sat(R(ψd )T (η ref − η d ))) and sat() is the saturation func-
tion. A diagram of the reference filter including the input saturation can be seen in Figure
3.3.

η ref + η sat + η input ηd

Reference
R(ψd )T Saturation R(ψd )
− + filter
ηd ηd

Figure 3.3: Block diagram of the reference filter with the ”carrot function” implemented.

Figure 3.4 shows how the input to the filter is saturated. The saturated reference is given
by
η sat = R(ψd )(sat(R(ψd )T (η ref − η d ))) (3.7)

In Figure 3.5, the desired velocity η̇ d and acceleration η̈ d is shown. The velocity and
acceleration limits to which the reference filter was tuned to in this example were:

νub = 0.5m/s − νub = 0.2m/s ± νvb = 0.1m/s ± νrb = 3◦ /s (3.8)

◦
ν̇ub = 0.25m/s 2
− ν̇ub = 0.1m/s 2
± ν̇vb = 0.05m/s 2
± ν̇rb = 1.5 /s 2
(3.9)

Based on the velocity and acceleration limits given in (3.8) and (3.9) the following satura-
tion limits were used:

xbmax = 2.25 − xbmax = 1 b

± ymax = 0.5 b
± ψmax = 15◦ (3.10)

which were set with the following tuning parameters:

       
ζN 1 ωn,N 0.6
∆ =  ζE  = 1 , Ω =  ωn,E  = 0.6 (3.11)
ζpsi 1 ωn,ψ 0.6

3.1.3 Discretization

By using the numerical integration scheme Euler’s method as given in Egeland and Grav-
dahl (2002), the discrete equation of (3.6) becomes

x(k + 1) = x(k) + h(Ax(k) + Bη input ) (3.12)

which is shown to be stable if

|R(hλ)| = |1 + hλ| ≤ 1 (3.13)

16
 3.1 Reference Filter

4
ηref,N
2
N [m]

ηd,N
ηsat,N
0 ηinput,N

-2
0 50 100 150 200 250 300
2
ηref,E
E [m]

ηd,E
0 ηsat,E
ηinput,E

-2
0 50 100 150 200 250 300
50
ηref,ψ
ψ[deg]

ηd,ψ
0 ηsat,ψ
ηinput,ψ

-50
0 50 100 150 200 250 300
Time [s]

Figure 3.4: Relationship between reference, output, saturated input and input of the reference filter.

17
 Chapter 3. Guidance System

where R(hλ) is the stability function, h the timestep and λ are the eigenvalues of the
system. In other words, Euler’s method is stable if hλ is inside a circle with a radius of
one around the point (-1,0).
Since the reference filter will only have real eigenvalues, see Section 3.1.1, this method
will be stable if
2
h≤− (3.14)
λ

3.1.4 Rotate Shortest Path

When computing a desired heading for the ship, the reference filter has to find the shortest
way to the heading reference and not rotate more than necessary. The reference filter works
in the area of ψ = ±180◦ and when rotating from 179◦ to -179◦ the reference filter should
rotate the ship across the 180◦ mark, not all the way across the 0◦ mark. The problem has
been solved with the code given in Algorithm 3.1.
1 %Find remainder of difference between ref and des
2 psi_temp=mod((psi_ref-psi_d),360)
3

4 % Add 360 and find remainder

5 psi_shortest=mod(psi_temp+360,360);
6

7 %Find the shortest way to rotate

8 if (psi_shortest > 180)
9 psi_shortest = psi_shortest - 360;
10 end
Algorithm 3.1: Algorithm to rotate the shortest way between two heading angles.

18
 3.1 Reference Filter

0.3 0.1
νd,u ν̇d,u

0.2
0.05

u̇ [m/s2 ]
u [m/s]

0.1

0
0

-0.1 -0.05
0 100 200 300 0 100 200 300
Time [s] Time [s]

0.1 0.03
νd,v ν̇d,v
0.02
0.05
0.01
v̇ [m/s2 ]
v [m/s]

0 0

-0.01
-0.05
-0.02

-0.1 -0.03
0 100 200 300 0 100 200 300
Time [s] Time [s]

4 1.5
νd,r ν̇d,r
1
2
0.5
ṙ [deg/s2 ]
r [deg/s]

0 0

-0.5
-2
-1

-4 -1.5
0 100 200 300 0 100 200 300
Time [s] Time [s]

Figure 3.5: Desired velocity and acceleration from the reference filter.

19
Chapter 4
Control System

The control system forms the brain of the whole DP system. Here all the information
comes together and the control signals are calculated before being passed on to the actu-
ators. Figure 4.1 shows the control part of the DP system. Data of the vessel’s pose and
desired pose are fed into the controller, from which the controller calculates a desired con-
trol force. The thrust allocation then sets up the actuators in such a way that the desired
control force is obtained. In this chapter, a motion controller with a feedforward from the
reference and thrust allocation are presented.

Waves,
wind and
ocean
currents

η ref η d , ν d , ν̇ d τ u η
Reference Thrust Ship
Controller Sensors
filter Allocation

η estimated
ν estimated

Observer
η estimated
Guidance System Control System
Navigation System

Figure 4.1: Block diagram of the DP system with the control system highlighted in blue.

21
Chapter 4. Control System

4.1 Dynamic Positioning Controller

Dynamic positioning (DP) started out as an exotic control technology for geological sam-
pling in deep waters during the 1960s, and was shortly after introduced to the offshore
petroleum industry (Breivik et al., 2015). The technology became more advanced, espe-
cially with use of Kalman filter in DP, which was introduced in the late 1970s. Since then,
DP has developed from a scientific technology to an industrial technology, and is today
used in mass-marked applications such as the offshore petroleum industry. The DP sys-
tems are most commonly used to keep the vessel at a fixed heading and position, but can
also be used to maneuver the vessel precisely over short or longer distances.

Figure 4.2: A vessel using a dynamic positioning control system must use its thrusters actively to
counteract the environmental forces it is subjected too. Courtesy of Kongsberg Maritime.

There are several types of controllers that can be used for DP. These range from sim-
ple to advanced with a PID controller being a robust and industry standard used in many
applications, the Linear Quadratic Regulator (LQR) which is based on a mathematical
model of the vessel, to the more exotic controllers such as adaptive backstepping con-
troller (Sørensen et al., 2016). As there is no verified existing mathematical model of the
experimental vessel ReVolt, see Chapter 6, the PID controller is a solid choice. A feedfor-
ward term utilizing a vessel model obtained from simulations, should assist the controller
with setpoint changes.

4.1.1 Control Algorithm

The overall control algorithm will consist of a PID feedback term and a reference feedfor-
ward term. This gives the following overall controller.

τ = τF F + τP ID (4.1)

22
 4.1 Dynamic Positioning Controller

Feedforward

In the controller, a model-based reference feedforward will be used, based on the model
in (2.6), restated here in (4.2).

M ν̇ + C(ν)ν + D(ν)ν = τ thruster + τ environmental (4.2)

The model-based feedforward part of the control law is designed to feed the dynamics of
the vessel forward, based on the model. This will give the vessel faster reactions according
to the vessel dynamics. Therefore the feedforward term becomes:

τ F F = M ν̇d + C(ν)ν d + D(ν)ν d (4.3)

where ν d ∈ Rn and ν̇d ∈ Rn denotes the desired velocities and accelerations in the
BODY frame, respectively.
When implementing the feedforward term in a practical system, C(ν d ), D(ν d ) and ν̇ d
have been used instead of C(ν), D(ν) and ν̇. This is because the desired setpoints are a
much more stable signal than the system states signal. If the state signal becomes corrupted
or is estimated incorrectly, the entire system can become unstable. The feedforward term
then becomes as follows:

τ F F = M ν̇d + C(ν d )ν d + D(ν d )ν d (4.4)

PID

Since the vessel is prone to environmental disturbances and there are modelling errors in
the mathematical model of the vessel, a feedback term is added to the controller. The
PID controller tries to minimize the error between a system’s desired setpoint, xd , and the
system’s state x, to zero. This error is given by

e(t) = x(t) − xd (t) (4.5)

The desired setpoint is determined by the user of the system, whilst the actual state of the
system is measured by sensors or estimated By considering the error, the algorithm will
compute a control command τP ID (t) using a weighted sum

Z t
de(t)
τP ID (t) = −KP e(t) − KI e(τ )dτ − KD (4.6)
0 dt

where KP > 0, KI > 0 and KD > 0 are the proportional, integral and derivative param-
eters respectively. A PID controller is easy to implement as it only relies on the measured

23
Chapter 4. Control System

states of the system and does not require any knowledge of the vessels dynamics. To im-
plement the PID controller on a computer, the equation has been discretized using implicit
Euler method, giving the following equation

i
X 1
τP ID (k) = −KP e(k) − KI e(i)h − KD (e(k) − e(k − 1)) (4.7)
i=0
h

where h is the time between each execution of the controller algorithm, called timestep.
When using a PID controller in a DP control system, it is common that the desired set-
point is in 3-DOF. This can be achieved by using matrices in the controller equation. By
changing the state x to η b ∈ R3 in (4.7), where
 
x
ηb =  y  (4.8)
ψ

the control law becomes the following:

i
X 1
τ P ID (k) = −KP η berror (k) − KI η berror (i)h − KD ν error (k) (4.9)
i=0
h

where

η berror = η b − η bd (4.10)
ν error = ν − ν d (4.11)

Rotation to BODY

In the controller given in (4.1), the pose error, η error , desired linear and angular velocities
and accelerations, are input in the NED frame and need to be expressed in the BODY
frame. This is solved by using the rotation matrix RT given in (2.4).

η berror = RT η nerror (4.12)

νd = RT η̇ nd (4.13)
ν̇ d = RT η̈ nd + S(ω)RT η̇ nd (4.14)

where ω = [0, 0, r]T since the controller is in 3-DOF.

24
 4.1 Dynamic Positioning Controller

4.1.2 Saturating Elements

The ship has a maximum amount of thrust which each propeller can produce, therefore
the controller should not output a larger wanted force than the ship can handle. Saturating
elements are placed in the controller to limit the output value if the controller computes a
too large wanted force.
The maximum thrust matrix is given by:
 
τX,max
τ max =  τY,max  (4.15)
τN,max

The saturating elements have been implemented according to


sgn(x)xmax if |x| ≥ xmax
sat(x) = (4.16)
x else

The saturating limit τi ≤ τ i,max , i = 1, 2, 3 is set to reflect the physical limitations of the
ship. The saturating elements have been realized using the pseudocode given in Algorithm
4.1.
1 % Output Saturation
2 for i = 1:3
3 if abs(tau(i))>tau_max(i)
4 tau(i) = sign(tau(i))*tau_max(i);
5 end
6 end
Algorithm 4.1: Saturating element.

4.1.3 Tuning the Controller

To tune a PID controller, techniques such as pole placement or manual tuning can be used.
Pole placement is useful if a mathematical model of the system is available (Fossen, 2011),
and manual tuning can be used if the physical system or a simulation is available.
When tuning the controller manually, the operator needs to think physically about what
the gains mean for the system. With the error and velocity as defined in (4.11), the units
become

 N

  N 
  N 
N m m2 m/s
N  N   N 
τ P ID  N  , KP  m , KI  m 2 , K D  m/s  (4.17)
Nm Nm Nm
Nm deg deg 2
deg/s

25
 Chapter 4. Control System

A frequently used method of tuning the PID is increasing the proportional gain until os-
cillations around the setpoint is achieved. Then adding derivative gain functioning as
dampening to remove the oscillations. Lastly adding integral action removes the constant
offset. As a rule of thumb, the controller gains should have the following relationships:

KP
KD > KP , KI < KP , KI ≈
10

4.1.4 Yaw Wrapping

Since the rest of the DP system uses a yaw measurement between ±180◦ , the yaw angle in
the controller has to stay between ±180◦ if the vessel is to behave optimally. By keeping
the measured heading between ±180◦ , the vessel will never need to rotate more than 180◦
and the controller will receive the shortest path to the desired heading. This yaw wrapping
is performed on the measured heading angle of the ship before it is used in the controller.
The yaw wrapping is implemented as described by the pseudocode in Algorithm 4.2.
1 %Wrap measured yaw within +/- pi(180 deg)
2 yaw = modulo(yaw,360) %return the remainder of yaw/360
3 if yaw > 180: % If yaw is larger than 180, subtract 360
4 yaw = yaw - 360
5

6 elseif yaw < -180: % If yaw is smaller than 180, add 360
7 yaw = yaw + 360
Algorithm 4.2: Pseudocode for wrapping of the yaw.

4.2 Thrust Allocation

Actuators can exert forces and moments on the ship and are used by the DP system to
control the ship pose. How well the DP system’s commanded forces are realized depends
greatly on each actuator and their position on the vessel relative to CG as well as the Thrust
Allocation (TA)’s ability to handle the thruster’s dynamics.

4.2.1 Actuators

The most common actuators for a vessel using rotating propellers are:
Tunnel thrusters which can generate transverse thrust and are usually positioned at the
bow and stern of the ship where they will produce the most moment. The angle
of which they produce thrust is given as α and with its maximum obtainable
thrust, Tmax the thrust region becomes a line as in Figure 4.3b. Tunnel thrusters
are mostly used for low-speed navigation.

26
 4.2 Thrust Allocation

Azimuth thrusters can be used for both steering and propulsion purposes. They can
rotate 360◦ and can therefore generate thrust in any direction. The thrust region
for an azimuth thruster is seen in Figure 4.3d.

Main propellers and rudders are designed to be very efficient in certain conditions. They
are mostly used as the main propulsion for a ship, but are also commonly used
in DP systems.

There are also other actuators for example fins which are used to stabilize roll motions, or
water jet propulsion devices which can exert forces a lot like a main propeller with rudder.

(a) Tunnel thruster model. (b) Schematic thrust region for tunnel
thruster.

(c) Azimuth thruster model. (d) Schematic thrust region for an az-
imuth thruster.

Figure 4.3: Thruster model and thrust region for a tunnel thruster and an azimuth thruster. The
figure is adapted from Wit (2009).

27
Chapter 4. Control System

4.2.2 Thruster Force

The relationship between the propeller thrust F and the shaft speed n is given by (Sørensen,
2013)

F = sign(n)KT ρD4 n2 (4.18)

where D is the propeller diameter and ρ is the water density. The thrust coefficient KT > 0
is usually found by performing a bollard pull test where the force applied to the vessel by
the propeller is measured. In some cases, n is not the input to the thruster, thus a simplified
model using the control input is written as a linear model (Fossen, 2011)

F = Ku (4.19)

where F ∈ Rn is the generated force by the thrusters, K ∈ Rr×r (r = number of thrusters)

is the new force coefficient and u ∈ Rr is the control input to the thruster. The force
exerted from the thruster can then be measured at different control inputs, and by using
linear regression, the force coefficients are found.

4.2.3 Thrust Configuration Matrix

To find the forces and moments the thrusters exert on the vessel τ ∈ Rn , a thrust config-
uration matrix is set up. For this, the CG is assumed to be known and defined, as well as
every thruster’s position with respect to this point. The forces and moments applied to the
vessel is now defined by

τ = T (α)F (4.20)

where α ∈ Rr is a vector of azimuth angles and T (α) ∈ Rn×r is the thrust configuration
matrix. By inserting (4.19), (4.20) becomes

τ = T (α)Ku (4.21)

For a 3-DOF system and with the thruster geometry presented in Figure 4.4, the dimen-
sions become: τ ∈ R3 , u ∈ R3 and T (α) ∈ R3×3 . The thrust configuration matrix for

28
 4.2 Thrust Allocation

each thruster is written as

 
c(α1 )
T (α1 ) =  s(α2 )  (4.22a)
lx1 s(α1 )
 
c(α2 )
T (α2 ) =  s(α2 )  (4.22b)
ly2 c(α2 − lx2 s(α2 )
 
c(α3 )
T (α3 ) =  s(α3 )  (4.22c)
ly3 c(α3 − lx3 s(α3 )
(4.22d)

which combined gives

 
c(α1 ) c(α2 ) c(α3 )
T (α) =  s(α1 ) s(α2 ) s(α3 )  (4.23)
lx1 s(α1 ) ly2 c(α2 ) − lx2 s(α2 ) ly3 c(α3 ) − lx3 s(α3 )

The control input and azimuth angles are now

 T  T
u = u1 u2 u3 α = α1 α2 α3 (4.24)

lx1
lx3

ly1 Fx1
α1
Fy1 F1 CG Fx 3 xb
α3
Fx2
ly2 α2 Fy3
Fy2 F2 F3

lx2
yb

Figure 4.4: The thruster configuration for ReVolt introduced in Chapter 6, decomposed along the
body x- and y-axis.

4.2.4 Unconstrained and Constrained Solution

Computation of the control input u and α given a wanted τ , is a model-based optimization

problem. In its most advanced form, it will handle constraints such as rotatable thrusters,
rate saturations, pods wake influence and max thrust saturation.

29
Chapter 4. Control System

Unconstrained

One solution to avoid this advanced mathematical problem is by setting the thrusters at a
fixed angle. This results in the thruster configuration matrix T (α) = T . Now u is found
using the pseudo inverse

u = K −1 T T (T T T )−1 τ (4.25)

This method is unconstrained and will not consider saturations which will result in unob-
tainable commanded control inputs. Fossen (2011) suggest an extended thrust configura-
tion matrix which will allow for rotatable thrusters. It will however still be unconstrained
and not consider thruster dynamics, which will result in command inputs the thrusters can
not achieve.

Constrained

To obtain a realistic thrust allocation which handles saturations and thruster dynamics, the
optimization problem can be set up according to Fossen (2011) as

J = min sT Qs + ∆αT Ω∆α



subject to
T (α)F − s = τ
F min ≤ F ≤ F max (4.26)
∆F min ≤ ∆F ≤ ∆F max
αmin ≤ α ≤ αmax
∆αmin ≤ ∆α ≤ ∆αmax

shere s is a slack variable allowing the solution to lie within the thrust regions and not
specifically on the boundary. Further, ∆F is the maximum force the thrusters can apply
and ∆α is the max angular rate for the thrusters.
As T (α) is nonlinear, this optimization problem is nonconvex (Nocedal and Wright,
2006), and requires a significant amount of computations at each timestep. There are
several ways to decrease the computation power needed, see Wit (2009).
For this thesis, DNV GL has supplied their thrust allocation which is described imple-
mented in Section 7.2.4.

30
Chapter 5
Navigation System

Waves,
wind and
ocean
currents

η ref η d , ν d , ν̇ d τ u η
Reference Thrust Ship
Controller Sensors
filter Allocation

η estimated
ν estimated

Observer
η estimated
Guidance System Control System
Navigation System

Figure 5.1: Block diagram of the DP system with the navigation system highlighted in blue.

Conventional DP systems are implemented with a navigation system, see Figure 5.1, which
usually includes a state estimator (observer) for processing of sensor and navigation data.
The quality of the data is checked as well as wild points removed. The data is then pro-
cessed in a state estimator to filter noise and reconstruct unmeasured states. The most
famous state estimator algorithm is the Kalman filter introduced in the 1960’s (Brown and
Hwang, 2012). Since then several observers based on passivity has been developed, see
Grip et al. (2015). The chosen filter in this section is the Error-State Kalman Filter (ESKF).

This chapter provides an introduction to the Error-state Kalman Filter, a method to handle
GNSS wild points and how to transfer GNSS measurements to a joint sensor frame.

31
Chapter 5. Navigation System

5.1 Error-State Kalman Filter

The idea is to integrate accelerometer and gyrometer readings from an Inertial Measure-
ment Unit (IMU) to obtain position, orientation and velocity, hereby called navigation
state. Numerical integration of IMU readings leads to drift in the navigation state, which
needs to be handled by fusing the information with absolute position readings from a
GNSS. In the Kalman filter paradigm, there are two main strategies for approaching this.
A total state filter calculates and corrects the navigational state from sensor measurements.
The Error-State Kalman Filter (ESKF) uses the IMU as the reference navigation system
and has aiding sensors such as a GNSS to estimate the error in the navigational state. These
errors are then fed back into the navigational state. Arguments for choosing an ESKF:
• Since the error is estimated, the slower dynamical error model of the IMU is used
as opposed to the faster dynamics of the vehicle model.
• Integration of the IMU data can be run at high frequencies independent of the
Kalman filter.
• With a loss of GNSS measurements, the navigation state will continuously be inte-
grated leading to what is called dead reckoning.
• Absolute position sensors can be added in a modular fashion.
The ESKF in this thesis is based on Sola’s ESKF, (Solà, 2017) as Sola presents the material
in a comprehensive way.
The idea behind the ESKF is to have a nominal state and an error state. The nominal
state follows a nonlinear differential equation, while the error state is small, thus linearly
integrable and suited for Gaussian filtering. The nominal state x will consist of integrated
high-frequency IMU data um , not taking into account noise terms w and other unmodeled
imperfections. This will cause it to accumulate errors and the ESKF will estimate these
errors in the error state. The noise and perturbations incorporated in the nominal state will
be added into the error state. In parallel with integration of the nominal state, the ESKF
propagates the error state’s covariance until it receives a correction measurement from for
example a GPS. The correction measurement makes the error state observable, although
at a slower rate than the integration of the IMU data. After the correction measurement,
the error state’s mean is subtracted from the nominal-state, reset to zero, and covariance
matrix updated. An overview of the states and equations used in the ESKF is presented in
Table 5.1.

5.1.1 Quaternions and Euler Angles

In this chapter, the orientation of the vessel is given as a four parameter quaternion vector
q which has the advantage of being singularity free (Fossen, 2011). The representation of
quaternions is adapted from Solà (2017) and is stated as

32
 5.1 Error-State Kalman Filter

Process noise Qk = QT
k >0
Measurement noise Vk =VTk >0

True state xt,k+1 = ft (xt,k , uk , wk )

Nominal state xk+1 = f (xk , uk )
Error state δxk+1 = fδ (F xk , δxk , um,k , i) = Fx (xk , um,k ) ·
δxk + Fi · i
State observation y k = h(xt,k ) + V

Initial state x(0) = x0

Initial error state ˆ
δx(0) =0
Initial error state covariance P (0) = P 0

∂f
Transition matrix Fx = ∂δx xk ,um,k
Perturbation Jacobian Fi = ∂f
∂i xk ,um,k
∂h ∂h ∂xt
Observation Jacobian H k = ∂δx xk
= ∂x t xk ∂δx xk

Error covariance propagation P k = F x P k−1 F T

x + F i QF i
T

Kalman gain matrix Kk = P kHT T

k (H k P k H k + V )
−1

Error state estimate update ˆ

δxk = K k (y k − h(xt ))
Error covariance update P k = (I − K k H k )P k (I − K k H k )T + K k V K T
k

Injection of observed error ˆk

xk+1 = xk ⊕ δx
True error δxk+1 = g(δxk ) = δxk ˆk
δx
ESKF reset ˆ k+1 = 0
δx
∂g
Reset Jacobian Gk = ∂δx
ˆ
δxk
Error covariance reset P k = Gk P k Gk

Table 5.1: Error-State Kalman Filter overview, where ⊕ and are the generic composition to
respectively add and subtract. (Solà, 2017)

33
Chapter 5. Navigation System

 
  qw
qw  qx 
q= =  (5.1)
qv  qy 
qz

The error dynamics are represented with Euler angles δθ as the error is small thus avoids
the singularities.

5.1.2 True-State Kinematics

The kinematic equations for the true state xt where {t} denotes true are

ṗt = vt (5.2a)
1
q̇t = qt ⊗ ω t (5.2b)
2
v̇t = at (5.2c)
ȧBt = aw (5.2d)
ω̇ Bt = ω w (5.2e)

where ⊗ is the quaternion-product. The true acceleration at and angular rate ω t are mea-
sured by an IMU. These sensor measurements are in the BODY frame and are prone to
bias and noise, denoted {B} and {N }. The measurements, denoted {m}, is then stated as

a m = RT
t (a t − gt ) + a Bt + a N (5.3)
ω m = ω t + ω Bt + ω N (5.4)
T
where RT T

t = R(q t ) and g = 0 0 g is the gravity vector. For more advanced
gravity models, see Pavlis et al. (2012). Further, the kinematic system can be written to
use the IMU measurements

ṗt = vt (5.5a)
1
q̇t = qt ⊗ (ω m − ω Bt − ω N ) (5.5b)
2
v̇t = Rt (am − aBt − aN ) + gt (5.5c)
ȧBt = aw (5.5d)
ω̇ Bt = ω w (5.5e)
(5.5f)

34
 5.1 Error-State Kalman Filter

The kinematic system can then be written on state space form using state vector x, input
vector u, and perturbation vector w defined as
 
p
 q     
  am − aN aw
 v 
xt =  u= w= (5.6)

 aB  ωm − ωN ωw
ωB

5.1.3 Nominal and Error-State Kinematics

The nominal-state kinematics is modeled without noise as

ṗ = v (5.7a)
1
q̇ = q ⊗ (ω m − ω B ) (5.7b)
2
v̇ = R(am − aB ) + g (5.7c)
ȧB = 0 (5.7d)
ω̇ B = 0 (5.7e)
(5.7f)

in short ẋ = fc (x, u).

The linearized error-state kinematics are trivially obtained for position and both biases as
these are derived from linear equations. The kinematics for quaternions and velocity are
non-trivial, and detailed derivations can be found in Solà (2017). The error state δ ẋ =
fδc (δx, u, w) is then written as

δ ṗ = δv (5.8a)
δ θ̇ = − (ω m − ωB ) × δθ − δωB − ω N (5.8b)
δ v̇ = −R (am − aB ) × δθ − RδaB − RaN (5.8c)
δ ȧB = aw (5.8d)
δ ω̇ B = ω w (5.8e)
(5.8f)

35
Chapter 5. Navigation System

5.1.4 Discrete Nominal and Error State

The dynamics have to be discretized, which may be done using the forward Euler method.
With this, the nominal state becomes

1
pk+1 = pk + vk ∆t + (R(am − aB,k ) + g)∆t2 (5.9a)
2
qk+1 = qk ⊗ qk ((ω m − ω B,k )∆t) (5.9b)
vk+1 = vk + (R(am − aB,k ) + g)∆t (5.9c)
aB,k+1 = aB,k (5.9d)
ω B,k+1 = ω B,k (5.9e)
(5.9f)

and the error state becomes

δpk+1 = δp + δv∆t (5.10a)

T
δθ k+1 = R ((ω m − ω B,k )∆t) δθ − δω B,k ∆t + θ i (5.10b)
δvk+1 = δvk + (−RS (am − aB,k ) δθ − RδaB,k )∆t + vi (5.10c)
δaB,k+1 = δaB,k + ai (5.10d)
δω B,k+1 = δω B,k + ω i (5.10e)
(5.10f)

The vectors θ i , vi , ai and ω i are random impulses affecting orientation, velocity and bias
estimates. These are modeled as white Gaussian processes with mean zero and covari-
ance obtained from integrating the covariances of the continuous time noise processes
aN , ω N , aw and ω w over the timestep ∆t, as

2
Θi = σω N
∆t2 I [rad2 ] (5.11a)
Vi= σa2N ∆t2 I 2
[m /s ] 2
(5.11b)
2
Ωi = σω w
∆t2 I 2
[rad /s ] 2
(5.11c)
Ai = σa2w ∆t2 I 2
[m /s ] 4
(5.11d)

5.1.5 Jacobians and Perturbation Matrices

Summed up, the nominal state vector x, error state vector δx, the input vector um and the
perturbations vector i are stated as

36
 5.1 Error-State Kalman Filter

   
p δp  
 q   δq    θi
    am  vi 
 v ,
x=  δv  ,
δx =  um = , i= (5.12)
  
 aB   δaB  ωm  ai 
ωi
ωB δω B

The error-state system is then

δxk+1 = fδ (xk , δxk , um,k , i) = Fx (xk , um,k )δxk + F i i (5.13)

From Table 5.1, the ESKF prediction step is given as

P k = F x P k−1 F T T
x + F i Qk F i (5.14)

where Fx and Fi are the Jacobians of fδ with respect to the error and perturbation vectors,
and Qk is the covariance matrix of the perturbation impulses i stated

 
Θi 0 0 0
0 Vi 0 0
Qk = 
0
 (5.15)
0 Ωi 0
0 0 0 Ai

5.1.6 Observation of Error State

The measurements available are position p and ψ from respectively the GPS and GPS
compass in the form
y k = h(xt,k ) + v k (5.16)

where v k is white noise processes and V k is the covariance matrix of the measurement
noise. Since the filter is estimating the error state, the Jacobian matrix H needs to be
defined with respect to the error state δx. To ease the computation, H is split up to
represent the measurement with respect to the true state, and the true state with respect to
the error state as follows

∂h ∂h ∂xt
H= = = Hx Xδ x (5.17)
∂δx x
∂xt x
∂δx x

where Xδx is found in Solà (2017) to be

37
Chapter 5. Navigation System

 
  −qx −qy −qz
I3 0 0
1 qw −qz qy 
Xδx =0 Qδθ 0 , Qδθ =   (5.18)
2  qz qw −qx 
0 0 I9
−qy qx qw

Furthermore, Hx is found by calculating the Jacobian of the measurement vector with

 T
respect to the true state. Now with h = p ψ this becomes

 
p
∂ "
∂p
#
ψ ∂xt
= ∂ψ
x
(5.19)
∂xt x
∂xt x

where the partial derivative of the position p, with respect to the true state xt , is

∂p  
= I3 04 03 03 03 (5.20)
∂xt x

Further, the angles in xt are in quaternions, which means some manipulation is needed
before ψ can be used. Since the rotation matrices of the two representations are equal
(Vik, 2014)

R(Θ) = R(q) (5.21)

the relationship between ψ and quaternions (Solà, 2017) are found to be

2
ψ = atan2(2(qx qy + qw qz ), qw + qx2 − qy2 − qz2 ) (5.22)
By having    
w1 2(qx qy + qw qz )
w= = 2 (5.23)
w2 qw + qx2 − qy2 − qz2
we then use the chain rule to find

∂ψ ∂ψ ∂w
= (5.24)
∂q ∂w ∂q
which is split up and derivated in 3 parts
∂ψ 1  
= 2
w2 w1 (5.25a)
∂w w1 + w2
∂w1  
= 2 qz qy qx qw (5.25b)
∂q
∂w2  
= 2 qw qx −qy −qz (5.25c)
∂q

38
 5.1 Error-State Kalman Filter

∂ψ
Notice that ∂w is the derivative of the atan2 function atan2(w1 , w2 ). We can now write
Hx as
 
∂h I3 0 0 0 0 ∂ψ
= ∂ψ , ∈ R1×4 (5.26)
∂xt 0 ∂q 0 0 0 ∂q

With these measurements the measurement noise matrix V k is

 
Γ 0
Vk = (5.27)
0 Π

where Γ is the covariance of the position measurements and Π is the covariance of the
heading measurements from the GPS compass.

5.1.7 Discretization

The two different ways used to discretize the linearized error-state kinematics (5.8) are the
ordinary Euler (5.10) and the use of exact discretization (Van Loan, 1978). The latter gives
better computational stability (Moler and Loan, 2003), but requires the exponential of the
state transition matrix. The exponential of a matrix A is

eA (5.28)
which is approximated in Python, using the library Scipy, and in MATLAB .

5.1.8 Pseudocode ESKF

The ESKF can be implemented with the pseudocode found in Algorithm 5.1.
1 % Process noise Q
2 rAcc = sigmaAccˆ2 * eye(3)
3 qBAccMat = sigmaAccBiasˆ2/TAccBias * eye(3)
4 rGyro = sigmaAccˆ2 * eye(3)
5 qBGyroMat = sigmaGyroBiasˆ2/TGyroBias * eye(3)
6 qMatCont = blkdiag(rAcc,rGyro,qBAccMat,qBGyroMat)
7 % Measurement noise
8 rGps = sigmaGpsˆ2 * eye(3)
9 rCompass = sigmaCompassˆ2 * eye(3)
10 V = blkdiag(rGps,rCompass) %V: Measurement noise
11 % Initialization of states
12 x(0) = x_init; P(0) = P_init
13 for measurement u %[IMU data, Measurement data]
14 % Integration of nominal state x
15 deltaT = currentTime-prevTime

39
 Chapter 5. Navigation System

16 x_k+1 = x_k + deltaT * f_ns(x_k, u_k)

17 x <- q <- q/norm(q) % Normalization
18 % Do ESKF if measurement in u
19 if Measurement data
20 deltaT = currentTime-prevMeasurementTime
21 % Perturbation Jacobian
22 qI = discretize(qMatCont,deltaT) % Discretize Q
23 qMat = fI*qI*fI’
24 % Transition Jacobian
25 fCont = f(x,u) % StateSpace of f(x,u)
26 fX = discretize(fCont,deltaT)
27 % Measurement Jacobian
28 Hx = parthpartx(Mea)
29 Hdx = partXpartdx(x)
30 H = Hx*Hdx %
31 % Innovation
32 innov = [ Mea_GPS - x(1:3)
33 angularDifference(psi(x(4:7)) - Mea_Compass)]
34 % Kalman
35 P = fX*prevP*fX’ + qMat% Covariance propogation
36 K = P*H’*inv(H*P*H’+V) % KalmanGain
37 P = (I-K*H)*P*(I-K*H)’ + K*V*K’ %ErrorCovariance
38 dxHat = K*innov %Error-state calculation
39 x_k+1 = x_k+1 + f(dxHat) % Injection of error-state
40 x_k+1 <- q <- q/norm(q) % normalization
41 G = partgpartdx(dxHat) % Reset Jacobian
42 P = G*P*G % NewErrorCovariance
43 prevP = P % Save CovarianceMatrix
44 end
45 end
Algorithm 5.1: Pseudocode for the Error-State Kalman Filter.

5.2 Wild Point Filter

When measuring position using a GNSS, the measurements can suddenly jump a great
distance for one or more measurements and then jump back again. These wild points
may occur when the GNSS acquires a new satellite, when it experiences interference from
effects such as back scattering or when it looses a satellite. A wild point can be several
hundred miles away and this can cause unexpected behavior in the system. Such wild
points can be seen in Figure 5.2.
These wild points need to be removed and a filter has been created according to the fol-
lowing criteria:

40
 5.2 Wild Point Filter

Figure 5.2: Wild points were recorded as far away as the Equator and Eastern Europe, while per-
forming tests in Trondheim, Norway.

1. Compare the current position measurement with the previous approved measure-
ment.

2. If a measurement is more than one meter away from the last measurement, this
measurement is not approved.

3. If more than 20 measurements are not approved, the last measurement is approved
anyways.

4. The initial position of the filter will be the median of the first 20 measurements.

The first criteria ensures that the filter does not approve a position if it is close to a wild
point. This could happen if there for example are two wild points which occur after each
other. The third criteria ensures that if there is a legit jump in position or if the filter is
incorrectly initialized, the filter will be ”forced” to accept the new position measurement.

41
Chapter 5. Navigation System

5.3 Lever-Arm Compensation

Since a GNSS antenna is not mounted in the same place as the IMU, forces measured by
the IMU at the antenna position will not be accurate. It is therefore important to transform
all the measurements to a common frame using lever-arm compensation. CG is often
used as this common point, since CG does not move when the ship rotates (Vik, 2014).
With a NED position measurement pn1 and a lever-arm ∆pb the compensated position pn0
becomes:

pn0 = pn1 + Rnb (Θ)∆pb (5.29)

5.4 Overall Navigation System

The ESKF, wild point filter and lever arm compensation make out the navigation system.
The GNSS measurements are checked for wild points, before being transformed to the
NED frame. These coordinates are lever-arm compensated and then used by the ESKF.
See Figure 5.3 for a block diagram of detailing the navigation system.

IMU

Lever-arm
Wild LLA to compen- Kalman
GNSS point filter NED sation for filter
GNSS

Figure 5.3: Block diagram detailing the navigation system.

42
Chapter 6
Experimental Platform

This chapter introduces the model ship ReVolt, it’s background, and the components in-
stalled.

Figure 6.1: The model-scale ship ReVolt under way at Havnebasseng VI in Trondheim.

Some basic stats for the model ship ReVolt are found in Table 6.1.

43
Chapter 6. Experimental Platform

Length 3m Draft 0.23m

Width 0.72m Battery Voltage 12V
Weight 257kg Max engine power 360W
Top speed 2 knots Battery capacity 900Wh

Table 6.1: Basic stats for the model ship ReVolt.

6.1 ReVolt’s Background

The ReVolt is a concept ship which is designed by the international certification body
and classification society, DNV GL in 2014 (DNV GL, 2015). The ship is designed to
be an environmentally friendly solution, suitable for short sea shipping along the coast of
Norway. The ReVolt is designed to be an unmanned vessel, giving it a futuristic look. The
ship is designed and optimized for low energy demand which makes it optimal at speeds
about 6 knots. The ReVolt’s propulsion system is fully electric with two pods in the stern
and an retractable azimuth thruster in the bow (DNV GL, 2015).

Figure 6.2: An illustration of the concept ship, ReVolt. Courtesy of DNV GL.

In 2014, DNV GL had a 1:20 scale model of the ship made by Stadt Towing Tank (STT),
with the same thruster configuration as the concept ship. To avoid confusion, the model of
the ReVolt is in the rest of the thesis referred to as just ReVolt.

6.2 Actuators

The actuators on ReVolt are mainly comprised of three thrusters, a bow thruster and two
identical podded azimuth thrusters in the stern. These are comprised of several compo-
nents found in Figure 6.4.

44
 6.2 Actuators

10 2
11
5
3 7
12 8
3 6
1 4
9
2
No. Name No. Name
1 Arduino Mega 2 ESC - AC Robbe Roxxy
3 Stern Thruster 4 Batteries
5 Tank-720 PC 6 Xsens MTI-G-710
7 Arduino Uno 8 Bow Thruster
9 ESC - DC Robbe Roxxy 10 Spektrum AR400 RC Receiver
11 Satel Radio Link 12 Hemisphere Vector VS330

Figure 6.3: Main components and their placements on the ReVolt model. Adapted from STT.

Azimuth Stern Thruster

The two identical stern thrusters consists of an AC-motor to drive the propeller which are
powered by an Electronic Speed Controller (ESC) rated at 40A, see no. 3 in Figure 6.3.
The pod is rotated by a stepper motor via a belt system, allowing for indefinite rotation of
the stern thrusters. The stepper motors are of the type Nanotec PD2-N41 motors which
have an RS485 interface. The stepper motors use an encoder to ensure closed-loop position
control, which is tuned and set up via the manufacturer’s program called NanoPro.

Retractable Azimuth Bow Thruster

The bow thruster consists of a DC-motor to rotate the propeller which is powered by an
ESC rated at 35A, see no. 8 in Figure 6.3. The propeller house is rotated by a servo
motor, which is not capable of rotating more than ±270◦ . A linear actuator is mounted
to a construction that holds the DC-motor and servo enabling the propeller house to be
lowered or retracted in and out of the vessels hull.

45
Chapter 6. Experimental Platform

1 Bow Thruster 6
4
5
2

8
Stern Thruster
3 7

Number Name Role

1 DC-Motor Rotate the propeller.
2 Linear Actuator Retract/lower the propeller house.
3 Propeller House Houses propeller that creates thrust when rotated.
4 Servo Rotate propeller house to get desired thrust direction.
5 AC-Motor Rotate the propeller.
6 Slip Ring Allows transmission of power from stationary to rotating structure.
7 Propeller Rotates to create thrust.
8 Stepper Motor Rotate propeller to get desired thrust direction.

Figure 6.4: Detailed overview of the thruster setups and their components. Adapted from STT.

6.3 Sensors

ReVolt has two navigational sensors and two auxiliary sensors. The auxiliary sensors
consists of a water sensor and battery sensor omitted from this thesis. The two navigational
sensors are presented below.

6.3.1 Xsens-MTI-G-710

The Xsens is an INS with a GNSS and IMU, see no. 6 in Figure 6.3. Xsens states:
”The MTi-G-710 GNSS/INS is a GNSS-aided, IMU-enhanced GNSS/INS” (Xsens, 2016)
It provides position measurements in ECEF and also measures accelerations and angular
velocity in the BODY frame. It also has an Attitude Heading Reference System (AHRS),
which fuses the previous mentioned measurements to estimate its heading and velocity in
NED. The Xsens is mounted in the roof of ReVolt, as close as possible to the CG. With
SBAS corrections, the Xsens is able to provide a position measurement down to ±2m. The
orientation measurements have an accuracy of ±0.3◦ , ±0.3◦ and ±1.0◦ in roll, pitch and
yaw, respectively.

46
 6.3 Sensors

Figure 6.5: The Xsens-MTI-G-710 GNSS and IMU unit, mounted inside ReVolt.

Stats Description
GNSS Update rate 4Hz IMU update rate 2000Hz
GPS codes L1 Roll accuracy 0.3◦
Horizontal accuracy 2.5m Pitch accuracy 0.3◦
Horizontal accuracy (with SBAS) 2.0m Yaw accuracy 1.0◦
Vertical accuracy 5.0m Velocity accuracy(@30m/s) 0.05m/s

Table 6.2: Xsens specifications (Xsens, 2016).

6.3.2 Hemisphere Vector VS330

The Vector VS330, see no. 11 in Figure 6.3, is a dual antenna GNSS receiver, able to
measure ReVolt’s position and heading. Using the two antennas, the Vector measures the
heading which is stabilized with an internal gyro. This is called a GNSS-compass. It also
supports different correction data, such as SBAS and RTK, improving the accuracy and
precision of the position measurements. A variety of outputs are supported, including the
standard NMEA 0183 protocol used in this thesis. The mounted GNSS is shown in Figure
6.6a, with the antennas mounted on ReVolt’s boat towers to minimize multipathing. The
antennas are mounted with the forward antenna as the primary and a baseline of 2.05m.
With RTK correction data, the Vector VS330 is able to provide accurate heading and po-
sition measurement down to ±0.2◦ and ±1cm.

Satel Radio Link

The Satel radio link, see no. 12 in Figure 6.3, feeds RTK correction data, received from a
local GNSS base station, to the Vector VS330 via a RS232 interface. Figure 6.6b shows
the Satel radio link installed in ReVolt with the antenna mounted on the stern boat tower.
The base station sends correction data using the following data:

47
Chapter 6. Experimental Platform

Stats Description
GNSS Update rate 20Hz Heading accuracy 0.05◦
GPS codes L1,L2
Horizontal accuracy 0.30m Vertical accuracy 0.60m
Horizontal accuracy (with SBAS) 0.30m Vertical accuracy (with SBAS) 0.60m
Horizontal accuracy (with RTK) 0.01m Vertical accuracy (with RTK) 0.02cm

Table 6.3: Specifications on the Hemisphere RTK GNSS (Hemisphere, 2017).

Protocol: RTCM3 Frequency: 441.00MHz Baud rate: 19200

(a) Hemisphere mounted in ReVolt. (b) Radio link for the RTK GNSS.

Figure 6.6: Hemisphere mounted in ReVolt and the Radio link connected.

6.4 Light Beacon

A light beacon has been implemented on ReVolt as a visual aid for the operators of ReVolt.
The light beacon has three lights; red, yellow and green, as shown in Figure 6.7. If the wa-
ter sensor fitted to ReVolt is triggered, the red light will shine. The yellow light will shine
continuously when ReVolt is being manually controlled, and blink at a constant rate when
ReVolt is in an automatic mode. The green light blinks at constant rate when the system is
operating normally. The signal logic is summarized in Table 6.4. The light beacon is not
intended as maritime navigational lights, only as a visual aid for the operators.

48
 6.5 Onboard Computer and Microcontrollers

Light Status Description

Red Constant Water sensor triggered
Yellow Blink DP, heading control or manual thrust allocation
Yellow Constant Manual mode
Green Blink System OK
Green Constant System error

Table 6.4: Signal logic for the light beacon.

Figure 6.7: Close up of the stern boat tower. From the left: Light beacon, Wi-Fi antenna, GNSS
antenna, Wi-Fi antenna, radio link antenna.

6.5 Onboard Computer and Microcontrollers

The Onboard Computer (OBC) in ReVolt is a Tank-720, see no. 5 in Figure 6.3, which is
a fanless, robust, embedded computer running Linux Ubuntu, hereby called the OBC. On
the OBC, a program called Robot Operating System (ROS) is installed, which is a open
source ”operating system” providing low level device control, message passing and more.
ROS is further described in Section 7.2.1.
For analog Input/Output (I/O)s there are two microcontrollers, an Arduino Mega and an
Arduino Uno, see no. 1 and 7 in Figure 6.3. These handle low level communication
signals such as Pulse Width Modulation (PWM) signals to the ESC and servomotor, and
radio receiver, no 2, 9 and 10 in Figure 6.3.

49
Chapter 7
Embedded Computerized Control

It is important to create a good computerized control platform and hence create a solid
foundation for the control algorithms and other code to reside. The embedded OBC, Ar-
duinos and other surrounding hardware make up the hardware framework, while the code
and its structure make up the software environment.
The rest of this chapter will address how the hardware is connected and interfaced with
the OBC. The structure of the software environment is also described.

7.1 Hardware Framework

The physical components described in Chapter 6 have all been connected to the OBC
using either Universal Serial Bus (USB) or RS232, depending on which was available as
standard on the component. Figure 7.1 shows how the components are connected to the
OBC.
The wiring on ReVolt is documented in the wiring schematic found in Appendix B.

7.2 Software Environment

The software environment in ReVolt consists of a variety of software. As stated in Section

6.5, the OBC runs the operating system Linux Ubuntu with the software framework ROS
on top. Installed on the OBC is
• Linux Ubuntu 14.04 LTS
• ROS Indigo Igloo

51
Chapter 7. Embedded Computerized Control

USB

USB Arduino Mega

RS232 Arduino Uno
Watersensor ESC Onboard WiFi WiFi Laptop
USB RS232 RS485 Servo ESC
Lightbeacon AC- Computer
Xsens Hemisphere Steppers LinAcc DC-
motor
motor

Sensors and actuators Main computer Laptop

Onboard User

Figure 7.1: How the hardware is connected in ReVolt.

• Python 2.7
• Java 1.7.0 121
The ROS distribution has an End-of-Life (EOL) date set to April 2019 (Marguedas, 2017).
The main programming language used in this thesis is Python, which is widely used when
developing and testing new systems. This is due to the fact that Python is designed for code
readability and easy implementation. Python features a variety of libraries extensively
used throughout this thesis, with useful features such as matrix operations and numerical
solvers. However, Python is known to have a huge overhead implying that the code is not
as efficient as other languages, but computation power is not an issue for this thesis. The
nodes for the two Arduinos are programmed in Arduino’s own C++ based language, in
conjunction with a ROS library called rosserial. This handles the communication between
the Arduinos and the OBC.

7.2.1 Robot Operating System

The entire control system is created on a software framework called Robot Operating
System (ROS), which is a collection of open-source software libraries. These provide an
operating system-like functionality and can be used to create a very modular system, using
nodes. These nodes are executable files which are written in C++, Python or Lisp, with
support for more programming languages being added.
The roscore is the main hub of the system, functioning as a registration service for other
nodes. It keeps track of all nodes and messages published and subscribed to, such that
nodes can communicate with each other. The messages in ROS are called topics and
these are sent and received by nodes using a Transmission Control Protocol (TCP)/Internet
Protocol (IP)-based message transport, called TCPROS. Nodes publish and subscribe to
topics, as they are not addressed to a specific node. Nodes written in different languages

52
 7.2 Software Environment

can communicate using topics as long as the structure of the data in the topic is known for
both nodes. A short introduction to using ROS is found in Appendix C.

7.2.2 Graphical User Interface

The GUI, as seen in Figure 7.2, is developed using the rqt library and parameter server in
ROS. This is made in order to ease the configuration of parameters for both the PID con-
troller and reference filter during the field tests. The GUI also incorporates easy switching
between the different operating modes, as seen in Figure 7.3. The GUI is accessed using a
laptop connected to the OBC on ReVolt through Wi-Fi.

Figure 7.2: The Graphical User Interface programmed for the operators of ReVolt.

53
Chapter 7. Embedded Computerized Control

7.2.3 Software Structure

There are four operating modes which can be used to control ReVolt:

• Manual control

• Heading controller

• Manual thrust allocation

• Dynamic positioning

where the heading controller mode is omitted from this thesis.

Figure 7.3: Choosing the operating mode of ReVolt using the laptop.

Manual Mode

The manual mode gives the user direct control of the stern thrusters, where their rotations
are limited to ±45◦ . The bow thruster can also be controlled, as well as lowered and
retracted into the hull. This is the default mode of ReVolt at launch and is used when
performing basic checks of ReVolt. As there are no controllers related to the manual
mode, it only maps the messages from the RC Remote into viable messages and is passed
on to the thrusters. An overview is seen in Figure 7.4. If there is a problem or it is desired,
it is possible for the operator to flip a switch on the remote control and ReVolt will revert
to a safe mode with the same capabilities as the manual mode.

Remote
Control Arduinos (C++) Ship /
RC Remote
(Python) Stepper Driver (Python) Actuators

Figure 7.4: Block diagram of the nodes used for manual control and which programming language
is used to program them.

54
 7.2 Software Environment

Manual Thrust Allocation Mode

Figure 7.5 shows the structure of the manual thrust allocation mode, which utilizes all
three thrusters with the bow thruster fixed at 90 degrees. Here the user demands a force
relative to BODY for which the thrust allocation calculates a control input. This consists
of a desired throttle and angle for each thruster, which is applied to the actuators. This
mode is used for testing and tuning the thrust allocation, as described in Section 10.4.2.

Solver
Optimization
Param.
Solver (Java)
(Java)

Remote Thrust
Control Allocation Arduinos (C++) Ship /
RC Remote
(Python) (Python) Stepper Driver (Python) Actuators

Figure 7.5: Block diagram of the nodes used for manual thrust allocation control and which pro-
gramming language is used to program them.

DP Controller Mode

The DP mode is the most advanced mode involving the full DP system, seen in Figure 7.6.
The mode utilizes feedback control as explained in Chapter 4 where the user, via a laptop,
inputs a setpoint in 3-DOF through the parameter server. The reference filter feeds the PID
with a realistic trajectory coinciding with the users input. The controller rate is set to 5Hz
which should sufficiently handle the slow dynamics of ReVolt.

Xsens
PID Param. Optimization Solver Param.
Xsens Driver
(Python) Solver (Java) (Java)
(Python)

Reference Reference Thrust η, ν

PID Arduinos (C++) Ship / Observer
Param. Filter Allocation
(Python) Stepper Driver (Python) Actuators (Python)
(Python) (Python) (Python)

Hemisphere
η, ν Hemisphere Driver
(Python)

Figure 7.6: Block diagram of the nodes in the DP controller and which programming language is
used to program them.

More detailed representations of the system structure for the different control modes can
be found in Appendix D.

55
Chapter 7. Embedded Computerized Control

7.2.4 Thrust Allocation

The Thrust Allocation from DNV GL is written in Java. It is optimization based, much like
the problem in (4.26). It punishes big steps in control inputs while seeking the optimum
inputs to attain desired control force. The initialization parameters are listed in Table 7.1.

Parameter Value Description

numThr 3 Number of thrusters
tMax {25, 25, 14} Max thrust
tMin {−25, −25, −6.1} Minimum thrust
setFixedAngles {0.0, 0.0, PI/2} Angle for fixed thrusters
setFixedAngleEnables {f alse, f alse, true} Enables fixed thrusters if
value true
Position {Position(−1.65, −0.15) Geometry of thrusters in
Position(−1.65, 0.15) (lx,ly)
Position(1.15, 0.0)}
setRateLimitDirections {PI/6, PI/6, PI/36} Radians per step ∆α
setRateLimitDirections {10.0, 10.0, 4.0} Newton per step ∆f

Table 7.1: Thrust allocation parameters.

Implementation

A decent way to implement the thrust allocation in ROS is by having a Python script
send and receive messages to the Java class. This is done with a open source library
called PY 4 J which essentially enables sending messages between Python and Java classes.
The ROS node sends an array with wanted control force τ which the Gateway server
implemented in PY 4 J forwards to the Java instance. The thrust allocation then returns a
vector of corresponding forces and angles for each thruster. The ROS node then translates
the forces into a suitable control input u. This is illustrated in Figure 7.7.

Rotation Rate Constraint Identification

The parameter to limit the rotation rate, ∆α in Section 4.2.4, of the stern steppers are
obtained from running the PD2-n41 steppers using the included software. By setting the
steppers to rotate 180◦ , the planned trajectory is presented in the manufacturers software.
The trajectory is presented in Figure 7.8.

The acceleration phase and deceleration phase are equal, which implies that for bigger
changes in angle, the rotation rate will be larger than for small changes in angle. By
calculating the rotation rate for a 180◦ change in angle and for only the acceleration and
deceleration phase, we get

56
 7.2 Software Environment

Initialize
T (α) Optimization
fmin/max Solver (Java)
∆αmin/max

τ F,α

Gateway
Server
(PY 4 J)

τ F,α

τ ROS-node u, α Ship /
Controller (Python) Actuators

Figure 7.7: Communication flow between ROS and the optimization solver.

Figure 7.8: Plot of the manual run in Nanotec’s software NanoPro of the PD2-N41 stepper motors.

180◦
180◦ : r= = 206◦ /s (7.1)
0.871s
7◦
7◦ : r= = 108◦ /s (7.2)
0.064s

where r is the rotation rate of the steppers and the 7◦ indicates the change in angle for the
acceleration and deceleration part only. A compromise between the two rates are chosen
at 150◦ /s or 5π
6 , which translates to

5π
∆α = h = π/6, h = 0.2s (7.3)
6
where h is the inverse of the controller rate.

57
Chapter 7. Embedded Computerized Control

7.3 Sensors
The two navigational sensors, the Xsens IMU/GNSS and Hemisphere GNSS, have both
been setup and drivers have been implemented such that the data can be received from
them. The sampling rate of the sensors have been set such that they will work optimally
for the Kalman filter. The sampling rate which are set on the sensors can be found in Table
7.2.

Sampling rate [Hz] Xsens IMU Xsens GNSS Hemisphere GNSS

Maximum 2000 4 20
Set 100 4 20

Table 7.2: The sampling rate of the two GNSSs and the IMU.

7.3.1 Xsens

To communicate with the Xsens in ROS, a third-party driver (Arunvydhya, 2017) was
modified and used on ReVolt. This driver provides all the measurements wanted from the
Xsens. The following measurements are provided by the Xsens:
• Orientation data: roll, pitch and yaw.
• Linear accelerations: surge acceleration, sway acceleration and heave acceleration.
• Angular velocities: roll, pitch and yaw rate.
• Position data: Latitude, longitude and altitude.
• Linear velocities: north, east and down velocity by combining GNSS and IMU to
estimate velocity.
By default the Xsens is oriented to be mounted with the bottom facing down towards the
Earth center. In ReVolt however, the Xsens is mounted in the ”roof” with the bottom facing
up. Therefore the sensor output of the Xsens is rotated, in the Xsens setup, such that the
measurements are correct with this new orientation. Therefore, using the provided Xsens
software, the orientation is rotated by 180◦ around the x-axis.

7.3.2 Hemisphere

The Hemisphere driver, written during the Fall 2016, was prone to parsing errors, and not
utilizing check sums and efficient serial port read functionalities. Therefore, a third party
NMEA driver (Perko, 2017), is acquired and implemented into the ROS environment. The
driver is modified to include parsing for all NMEA sentences used in this thesis, consisting
of
• GPGGA - Latitude and Longitude, as well as altitude and location accuracy data.

58
 7.4 Logging System

• GPHDT - Heading data.

• GPVTG - Velocity and course data.
A part of the location accuracy information found in the GPGGA message, indicates
whether or not the GNSS is receiving RTK correction data. This information is useful
to determine the quality of the position data which is being received when undertaking
experiments.

7.4 Logging System

When developing a new system, having the ability to log data and being able analyze this
at a later time is of great importance. Some of the greatest benefits of having a logging
system are:
• The user is able to analyze the performance of the system.
• The user can ”replay” a particular scenario which may arise during testing.
• Errors and bugs in the code can be analyzed.
To log data on ReVolt, the logging system which is a part of ROS has been used previously.
This system records all the data into ROSbags, which have to be properly shut down in
order to save the data. If the system looses power or the power is cut manually, it is very
likely that the recordings will be corrupt and useless.
Therefore a new system to log data on ReVolt has been created. This system is written
in Python and writes data directly to a Comma-Separated Values (CSV) file. For each
timestep, the CSV file belonging to the data is opened, written too, saved and closed. If
the system looses power the file is already saved and no data, other than the last signal,
will be lost.
Every time data is written to a log file, the time is also recorded. The time stamp which is
used has a resolution of 1 nano second, making the analysis of the data easier. Previously
there was a problem with the time stamps only having a resolution of 0.01 seconds and
this caused difficulties when analyzing the timestep of the system.
The two different ways of logging data have their pros and cons, which are listed below:
• ROSbag
– Pro: Can easily replay logs in ROS
– Con: File becomes corrupt if the system is shutdown improperly
• CSV-log
– Pro: Logs will not become corrupt upon improper shutdown
– Con: Logging of time stamps are not extensively tested and verified

59
Chapter 8
Modelling the ReVolt Model Ship

This chapter describes the modeling of ReVolt according to the mathematical model in
Section 2.2 and how the necessary parameters were found.

8.1 Center of Gravity

To find the CG for ReVolt, a crane was used to lift ReVolt using two straps placed close
together. The straps were placed close together to create a small surface area which lifted
ReVolt, such that it could balance on the straps. The total length of ReVolt, or Length
Between Perpendiculars (LPP) is 3 meters. Through trial and error it was found that
ReVolt could balance on the straps when they were placed at 155cm from the stern. The
experiment was performed when ReVolt was fully loaded with weights. The CG for ReVolt
with weights is therefore at 155cm from the stern. See Figure 8.1.

155cm 145cm

CO/CG

Figure 8.1: Center of Gravity on ReVolt.

61
Chapter 8. Modelling the ReVolt Model Ship

3.00 m

0.21 m
0.43 m
0.72 m

0.15 m 1.12 m CG 1.08 m 0.37 m

0.15 m
0.43 m

0.21 m

2.20 m

Figure 8.2: The dimensions of ReVolt, indicating the Center of Gravity and the thrusters placement.

8.2 Mathematical Model

For the mathematical model of ReVolt, the model and assumptions described in Section
2.2 has been used. With help from DNV GL, the added mass matrix M A given in (2.8)
and the linear damping matrix (D L ) given in (2.11) were found through Wave Analysis by
Diffraction and Morison (WADAM) simulations. The non-linear damping matrix (D(ν))
was not possible to attain from the computations and have been emitted from the model.
The linear damping term will dominate over the non-linear term, therefore this should not
be a problem. The relevant raw results can be found in Appendix E. The results from the
computations are non-dimensional and need to be dimensionalized by multiplying the cor-
rect factors into the matrix values. The following values were used for the non-dimensional
factors:
ρ = 1025kg/V g = 9.807m/s2 LP P = 3m (8.1)

where ρ is the density of sea water and g is gravity.

8.2.1 Inertia Matrix

The inertia matrix consists of the rigid-body inertia and the added mass. It is given by:

M = M RB + M A (8.2)

In order to find the rigid-body inertia matrix, ReVolt’s weight and moment of inertia are
required.

Mass

A crane and digital scale was used to find the total mass of ReVolt, see Figure 8.3. The
scale showed a weight of 167 kg, but at the time of the experiment the Hemisphere GNSS

62
 8.2 Mathematical Model

was not onboard. After adding the weight of the Hemisphere GNSS and subtracting the
weight of the weighing equipment and two misplaced 5kg weights onboard, the total mass
of ReVolt with out weights onboard, was
mReVolt = 157kg (8.3)

See Table 8.1 for a breakdown of the weights in the experiment .

Measured weight 167

Straps -2
Planks -1
GNSS and Satel 3
Weights -10
ReVolt 157 kg

Table 8.1: Breakdown of the different weights in the experiment. All units are in kg.

With 100 kg of weights added to ReVolt, the total mass becomes

matotal = mReVolt + mweights = 257kg (8.4)

In ReVolt there are five rods where the weights can be mounted. These rods are separated
along the x-axis of the ship and the weights are placed in such a manner that the trim of
ReVolt is close to level. During the sea trails the weights were distributed as follows:
(Bow) 5 - 6 - 5 - 2 - 2 (Stern)
where the numbers indicate the number of 5 kg weights which were added to each rod.

Moment of Inertia

To find the rigid-body inertia matrix (M RB ), the moment of inertia about the Zb axis (IZ )
is required. The volume moment of inertia (VIZ ) and volume (vol) was computed using a
3D computer model of the scale-model ship ReVolt and the program Rhino 5. The volume
and VIZ were found to be:
vol = 0.268m3 VIZ = 0.310m5 (8.5)

The mass moment of inertia then becomes:

masstotal 257
Iz = V IZ = 0.310 = 297.597kgm2 (8.6)
vol 0.268

Rigid Body Inertia Matrix

With the mass of ReVolt, the moment of inertia and the CG being the same as the center
of origin, and therefore the distance from the CO to the CG, xg = 0, the rigid-body inertia
matrix becomes:

63
Chapter 8. Modelling the ReVolt Model Ship

   
m 0 0 257 0 0
M RB = 0 m mxg  =  0 257 0  (8.7)
0 mxg Iz 0 0 298

Figure 8.3: Weighing ReVolt using a crane and a digital scale.

64
 8.2 Mathematical Model

Added Mass Matrix

The added mass matrix is given from the WADAM simulations:

 
−Xu̇ 0 0
MA =  0 −Yv̇ −Yṙ 
0 −Yṙ −Nv̇
 
0.0253 · ρ · vol 0 0
= 0 0.1802 · ρ · vol 0.0085 · ρ · vol · LP P 
0 0.0085 · ρ · vol · LP P 0.0099 · ρ · vol · LP P 2
 
6.930 0 0
= 0 49.440 7.007  (8.8)
0 7.028 24.556

Total Inertia Matrix

With M RB and M A the total inertia matrix becomes:

 
263.93 0 0
M = M RB + M A =  0 306.44 7.00  (8.9)
0 7.03 322.15

8.2.2 Coriolis-Centripetal Matrix

The Coriolis-Centripetal matrix C(ν) given in (2.9) is restated below:

 
0 0 −m(xg r + v)
C(ν) = C RB (ν) + C A (ν) =  0 0 mu +
m(xg r + v) −mu 0
  (8.10)
0 0 Yv̇ v + Yṙ r
 0 0 −Xu̇ u 
−Yv̇ v − Yṙ r Xu̇ u 0

By using the values from the inertia matrix in Section 8.2.1, values for the Coriolis-
centripetal matrix is found.
 
0 0 −257v
C RB (ν) =  0 0 257u  (8.11)
257v −257u 0
 
0 0 −49.44v − 7.00r
C A (ν) =  0 0 6.93u  (8.12)
49.44v + 7r −6.93u 0

65
Chapter 8. Modelling the ReVolt Model Ship

 
0 0 −207.56v + 7.00r
C(ν) = C RB (ν) + C A (ν) =  0 0 250.07u 
207.56v − 7.00r −250.07u 0
(8.13)

8.2.3 Damping Matrix

The linear damping matrix given by the WADAM simulations is

 
−Xu 0 0
D= 0 −Yv −Yr 
0 −Nv −Nr
0.102 · ρ · vol · LPg P
 
0 0 √
g
= 0 1.212 · LP√P 0.056 · ρ · vol · √g · LP P 
0 0.056 · ρ · vol · g · LP P 0.0601 · ρ · vol · g · LP P
 
50.66 0 0
= 0 601.45 83.05  (8.14)
0 83.10 268.17

8.3 Bollard Pull Tests

As the propellers used on ReVolt are custom made, there are no available data on the force
they generate at certain revolutions. As as solution to this, a crude bollard pull test was
conducted in calm sea. It was conducted by having a rope tied to the boat in one end and
a digital luggage weight on the other end, as seen in Figure 8.6. Each type of thrusters
were mapped at different inputs and curve fitting techniques were used to find a suitable
constant.
From Figure 8.4, the experimental data with the curve fitted model is plotted. The model
used is
Fi = Ki |ui |ui (8.15)

Notice that due to the bow thruster’s propeller being asymmetrical, it does not produce the
same thrust in both directions as opposed to the stern thrusters. The constants are

K1± = K2± = 2.7e − 3 K3− = 6.172e − 4 K3+ = 1.518e − 3 (8.16)

where the subscript of Ki denotes the thruster number, given in Figure 4.4. With these
values implemented in the thrust allocation, a map of available thrust for each angle can
be seen in Figure 8.5.

66
 8.3 Bollard Pull Tests

Figure 8.4: Measured and interpolated thrust force Fi for different inputs.

Bow
-30 30

-60 60

Port side Starboard

0[N] 20[N] 40[N] 60[N]

-120 120

-160 160
Stern

Figure 8.5: ReVolt’s available thrust for all directions with F1max = F2max = 25, F3max = 14 and
F3min = −6.1

67
Chapter 8. Modelling the ReVolt Model Ship

Figure 8.6: Kjetil performing a bollard pull test with a luggage scale. Photo by Egil Eide.

68
Chapter 9
Simulation Results

eta_ned_d eta_ned_d
eta_ref eta_ref eta_dot_d eta_dot_d eta_ship
eta_ddot_d eta_ddot_d tau tau U U
4-corner box test eta_ship nu_ship
Reference filter
nu_ship Thrust Alloccation Ship
Controller

Figure 9.1: Simulation created in Simuliunk.

In order to assure that the new updates to the ReVolt software and algorithms will work as
expected, a full closed loop simulation of the system has been created in MATLAB. The
simulation has been made with the possibility to add a disturbance to mimic a force due to
current. The specific algorithms tested are:

• Reference filter

• PID motion controller with feedforward

• DNV GL’s thrust allocation

The observer is not implemented in this simulation.

Since there is no verified mathematical model of ReVolt, a model for CyberShip II is

adapted from Skjetne et al. (2004) and used in the simulations. The dynamics of CyberShip
II is kept the same, but with modified thruster setup to mimic ReVolt’s three rotatable
azimuth thrusters.

69
Chapter 9. Simulation Results

9.1 Test Scenario

To test the DP system, a 4-corner test used during the AMOS research cruise 2016 (Skjetne
et al., 2017), has been adopted. This is shown in Figure 9.2. The 4-corner box test ensures
that all motions of the vessel are tested and it is practical during real life experiments
because the vessel returns to the initial position and heading, ready for another test.

3,4 Sway motion 2

Surge and sway motion Surge motion

5 Coupled motion all DOFs 1

motion

Figure 9.2: The 4-corner box test.

The test starts with the vessel pointing north at heading 0◦ and then the following reference
changes are commanded:

1. Change position x meters due north. This test surge motion ahead.

2. Change position x meters due west. This test sway motion to port.

3. Change heading 45◦ counterclockwise. This test yaw motion.

4. Change position x meters due south. This test a coupled sway and surge motion to
port and astern, respectively.

5. Change position x meters due east and change heading 45◦ clockwise. This test a
coupled surge, sway and yaw motion.

70
 9.2 Reference Filter Parameters

9.2 Reference Filter Parameters

For the simulations, the sampling rate is set to 5 Hz, since this is a compromise between a
fast, yet precise simulation. With a sampling time of h = 0.2s it is possible to compute the
maximum values for the natural frequency of the reference filter, while keeping the filter
stable as described in Section 3.1.3.
From (3.14), the smallest eigenvalue of the system must be
2
h≤−
λ
2
λ≥−
h
2
λ≥−
0.2
λ ≥ −10 (9.1)

With (9.1) it can be shown that the largest natural frequency ω for the reference filter must
be
ωi,largest ≤ 10 (9.2)
Therefore the natural frequency matrix Ω > 0 will be
 
0 < ωn,N ≤ 10
Ω =  0 < ωn,E ≤ 10  (9.3)
0 < ωn,ψ ≤ 10

The velocity and acceleration limits for which the reference filter is tuned according to are:

νub = 0.5m/s − νub = 0.2m/s ± νvb = 0.1m/s ± νrb = 3deg/s (9.4)

ν̇ub = 0.1m/s 2
− ν̇ub = 0.05m/s 2
± ν̇vb = 0.05m/s 2
± ν̇rb 2
= 1.5deg/s (9.5)

The saturation limits in the reference filter are set conservatively to ensure that the vessel
will be able to comfortably follow the desired acceleration and velocity. The saturation
limits refer to the distance which the ”carrot” is ahead of the vessel. Based on the velocity
and acceleration limits given in (9.4) and (9.5) as well, the following saturation limits are
used:
xbmax = 1 − xbmax = 0.5 ± ymax b
= 0.3 ± ψmax b
= 15◦ (9.6)

This resulted in the following tuning parameters:

       
ζN 1 ωn,N 0.6
∆ =  ζE  = 1 , Ω =  ωn,E  = 0.6 (9.7)
ζpsi 1 ωn,ψ 0.6

71
Chapter 9. Simulation Results

9.3 PID Parameters

For CyberShip II, the maximum thrust which the ship’s thrusters can supply in each direc-
tion is:    
τX,max 8
τ max =  τY,max  = 1 (9.8)
τN,max 2

Using the tuning method as described in Section 4.1.3, the following controller gains are
obtained and used for the rest of the simulations:
   
Kp,surge 0 0 10 0 0
Kp =  0 Kp,sway 0 =0 9 0 (9.9)
0 0 Kp,yaw 0 0 12
   
Ki,surge 0 0 1 0 0
Ki =  0 Ki,sway 0  = 0 1 0 (9.10)
0 0 Ki,yaw 0 0 1
   
Kd,surge 0 0 90 0 0
Kd =  0 Kd,sway 0  =  0 60 0  (9.11)
0 0 Kd,yaw 0 0 25

9.4 Results
The aim of the simulation is to show that the control algorithms work as expected and is
able to control CyberShip II around the 4-corner box test. The distances in the 4-corner
box test is set to 2 meters. CyberShip II is setup with a fixed bow thruster at 90◦ and
unconstrained rotation rates of the two stern thrusters. Both the reference feedforward
and feedback elements of the controller are in use. A constant disturbance is added to the
simulation in order to see that the feedback part of the controller is working correctly. The
constant disturbance is set to
   
N orth 1.5
w= = (9.12)
East 0

The disturbance values are in [N ] and indicate a disturbance coming from the North.
Figure 9.3 shows how CyberShip II follows the desired path for the 4-corner box test,
from a starting position of η = [0, 0, 0]T . With the constant environmental disturbance
(9.12), there are small errors in the pose of the vessel. Further in Figure 9.4, the vessel
tracks the desired trajectories, outputted by the reference filter, with high accuracy. This
can be confirmed in Figure 9.5 where the vessel tracks the desired velocities, with almost
no deviations. CyberShip II is able to track the reference filter output as a consequence of
the filter being tuned conservatively to the vessel’s motion capabilities.
The output from the thrust allocation as seen in Figure 9.6, shows that the control input u to
the thrusters, is never utilized above 50%. This means that the vessel could have handled

72
 9.5 Concluding Remarks

2.5

2
Desired
CyberShip II
1.5
North [m]
1

0.5

-0.5
-3.5 -3 -2.5 -2 -1.5 -1 -0.5 0 0.5 1 1.5
East [m]
0
ψ [deg]

-20

-40

0 50 100 150 200 250 300

Time [s]

Figure 9.3: Simulation of the 4-corner box test with CyberShip II.

higher accelerations and speeds. A interesting observation is that the thrust allocation
prefers to rotate the thrusters instead of reversing the thrust. This can be due to many
propellers being designed to be most efficient in one direction, which the thrust allocation
tries to adhere. The bow thruster being fixed means that the thrust allocation is forced to
reverse the thruster to obtain a force in the opposite direction.
Figure 9.7 shows the total output of the controller, as well as the feedfoward and feedback
elements. The control effort from the feedforward part is larger than the feedback part,
indicating that the model in the feedforward is a accurate model, which is expected as
it is the same as the model simulated. The feedback only has to counter minor position
and heading error due to the environmental disturbances applied to the system. The high
frequent noise in τP ID is due to simulation jitter (Kyckelhahn and Forbus, 2004), which
are tiny oscillations around setpoint. This however has no effect on the results of the
simulation.

9.5 Concluding Remarks

From the results obtained in the simulation, it is clear that each part of the control system
stated in the beginning of this chapter, are functioning properly. In the simulations, Cyber-
Ship II is able to accurately perform the 4-corner box test with a constant disturbance. The
critical parts in field tests is be the accuracy of the mathematical model obtained in order
to have a good feedforward, tuning and the effect of disturbances on the vessel.

73
Chapter 9. Simulation Results

Reference
N [m] 1 Desired
CyberShip II

0
0 50 100 150 200 250 300
0
E [m]

-1

-2
0 50 100 150 200 250 300
0
ψ [deg]

-20

-40
0 50 100 150 200 250 300
Time [s]

Figure 9.4: Reference, desired and actual pose of CyberShip II.

0.2
Desired
u [m/s]

CyberShip II
0.1

0 50 100 150 200 250 300

0.05
v [m/s]

-0.05
0 50 100 150 200 250 300

0.05
r [deg/s]

-0.05
0 50 100 150 200 250 300
Time [s]

Figure 9.5: Desired and actual velocity of CyberShip II.

74
 9.5 Concluding Remarks

40 CyberShip II
100

α1 [deg]
u1 [%]
0
20
-100
0
0 100 200 300 0 100 200 300

40
100

α2 [deg]
u2 [%]

0
20
-100
0
0 100 200 300 0 100 200 300
92
50

α3 [deg]
u3 [%]

0 90

-50
88
0 100 200 300 0 100 200 300
Time [s] Time [s]

Figure 9.6: Desired thrust and thruster angle from the thrust allocation. The spikes in α1,2 at t=40s
is due to wrapping around 180◦ .

1.5 CyberShip IIN 0.1

τT ot [Nm]

1
τT ot [N]

0.5 0
0
-0.5 -0.1 CyberShip IIX

0 100 200 300 0 100 200 300

1
0.05
τF F [Nm]
τF F [N]

0.5
0
0
-0.05
-0.5
0 100 200 300 0 100 200 300

0.6 0.05
τP ID [Nm]
τP ID [N]

0.4
0.2 0
0
-0.05
-0.2
0 100 200 300 0 100 200 300
Time [s] Time [s]

Figure 9.7: Controller output, divided into PID, feedforward and total control effort.

75
Chapter 10
Experimental Results

In this chapter, the results from the offline and online ESKF tests are presented as well as
the results from the final DP tests.

10.1 Observer Performance

The ESKF is developed and tested in MATLAB before it is implemented on ReVolt. This
is referred to as offline and online performance.

10.1.1 Offline Performance

The offline tests, with experimental data, are performed to see how the ESKF performs
in a known software environment, MATLAB. This makes it easier to debug and analyze
the ESKF. In conjunction with another experimental test, performed by PhD students at
NTNU, the Xsens was brought to log experimental data for the ESKF. The test was con-
ducted on the 6th April 2017, with Maritime Robotics’ vessel Telemetron. Onboard there
is an identical Vector VS330 to the one used in ReVolt (Section 6.3.2) without RTK cor-
rections and Kongsberg’s Seapath. The Seapath is a series of high grade heading, attitude
and positioning sensors which provide high accuracy measurements (Kongsberg, 2016).
The Seapath will serve as a reference for the offline results.
The IMUs of Xsens and Seapath are mounted next to each other, seen in Figure 10.1, and
further assumed to be in the same frame. Due to a setting in the parser for the Vector,
GNSS data was not published if the quality of the data dropped below a certain threshold.
These dropouts occur often and last up to 12 seconds, which unintentionally leads to dead
reckoning gaps.

77
Chapter 10. Experimental Results

Figure 10.1: Mounting of Seapath and Xsens IMUs on Telemetron.

The antennas are not mounted in the same place, as is evident from the stationary mea-
surements shown in Figure 10.2. Furthermore, the position measurements from the Xsens
are inaccurate and have a low precision, seen by the measurements slowly drifting. The
Seapath and Vector have about the same precision with only a lever-arm between them.

Figure 10.2: Stationary vessel measurements showing drift in Xsens position and mounting differ-
ence between Vector and Seapath antennas.

Estimate Quantification

To quantify the estimates, the error ē is defined as

v
u 3
uX
ē = t e2 ,i ei = xi − yi (10.1)
i=1

78
 10.1 Observer Performance

where xi are elements of for example position estimates from the ESKF or Xsens, and yi
is the Seapath position vector.

Noise and Bias

The following parameters for the process noise Qk and measurement noise V k are used

 2
0.3 I 0 0 0

π 2
 0 (0.4 180 ) I 0 0 
Qk =  π
15 180  (10.2)
 0 0 3600 I 0 
π
15 180
0 0 0 3600 I
 2 
1 I 0
Vk = (10.3)
0 0.42

Initialization

The ESKF is initialized using the navigation state of the Seapath and biases are set to zero.
The ESKF use acceleration and angular rate measurements from the Xsens, and combines
these with the position and heading angle measurements from the Vector.

Lever-Arm Compensation

The mounting of the Seapath IMU and Xsens IMU are assumed identical, see Figure 10.1,
whereas the antenna for the Vector is lever-arm compensated using the method in Section
5.3 with

 
0.315
∆pb = 0.9525 (10.4)
2.07

Offline Results

In Figure 10.3, the ESKF seems stable and capable of utilizing the IMU to calculate new
position estimates when dead reckoning, thus increasing the standard deviation σ. The
error in estimated position, relative to the Seapath, are within reasonable range as they
both have SBAS corrections which leaves them with an accuracy around ±0.5m. The
slow dynamics in error are related to the difference in the Down direction, where the
Vector measurements do not coincide with the Seapath. The fast dynamics in the error are
due to dead reckoning, where the estimate drifts in wait for a measurement which, when
received, is corrected.

79
Chapter 10. Experimental Results

Figure 10.3: Estimated positions in NED compared to the Vector and Seapath. The error between
the Seapath measurements and Xsens measurements are scaled down with a factor of 10 for compa-
rability between the Xsens and Vector measurements.

In the orientation estimates seen in Figure 10.4, the standard deviation σ, represented as a
grey shadow, is seen clearly for roll and pitch. These are prominent right after dead reck-
oning, which is expected as there has not been any position measurements for a small time
period. This is because change in position is used to confirm whether or not a measured
acceleration, in a given direction, is caused by movement or gravity. Overall, the dead
reckoning of angles, especially yaw, are estimated with good precision.
For the velocity estimates seen in Figure 10.5, the errors are relatively small during con-
tinuous GPS measurements for example around t=150 seconds. During dead reckoning
the error increases rapidly.
The bias estimates seen in Figure 10.6 looks to converge rapidly for acceleration measure-
ments. The initial guess of the gravity, set in the ESKF, is corrected by the bias estimation.
This is clearly visible in the z-axis of the acceleration, as this bias converges to -0.25. The
standard deviation for the gyro rates in pitch and roll are around 10 times higher than for
yaw. This is to be expected as yaw is updated by measurements from the Vector, while roll
and pitch are estimated only.

80
 10.1 Observer Performance

Figure 10.4: Estimated orientation compared to the Xsens, Vector’s GNSS-compass and Seapath.
Notice that the Xsens with AHRS enabled, fails to find true north and is therefore prone to a slowly
varying bias.

Figure 10.5: Body velocity estimate comparisons. Xsens velocity is rotated from NED using Seap-
ath orientation.

81
Chapter 10. Experimental Results

Figure 10.6: The estimated IMU biases, where a is the acceleration and ω is the angular rate.

82
 10.1 Observer Performance

Offline Results - Excerpt

With a focus on what happens between t=35-55 seconds, it is seen from Figure 10.7 that
the boat turns slowly to starboard followed by turning to port. The plot also show that
there is a loss of GPS data between roughly t=42-52 seconds. This immediately causes the
velocity to drift (Figure 10.8) which in turn, causes the position estimate to drift (Figure
10.9). When the first GPS measurement is received after dead reckoning, the correction in
position causes the velocity estimates to compensate by inducing a relatively high speed
in surge and sway. This also disrupts the orientation estimates in roll and pitch due to the
use of orientation in the determination of the acceleration direction.

Figure 10.7: An extract of the orientation estimates comparison data, from t=35-55s. Xsens’ esti-
mate of ψ is excluded in bottom left plot as it’s offset is too big.

83
Chapter 10. Experimental Results

Figure 10.8: An extract of the body velocity estimates comparison data, from t=35-55s. Xsens’
velocity is rotated from NED using Seapath angles, making the measurements more precise, rather
than using the Xsens angle where yaw is not North referenced.

Figure 10.9: An extract of the estimated positions in NED compared to the Vector and Seapath,
from t=35-55s.

84
 10.1 Observer Performance

10.1.2 Online Performance

The implementation of the ESKF was prone to stability issues at the final test, which was
solved later. ”Online” thus means that the data recorded from the test, is played back in
real time. Compared to offline in the previous section where the data was traversed until
completion without any time limits, this tests implemented code on ReVolt, which will
have a limited time for each iteration.

Online: Noise and Bias Parameters

The following parameters for the process noise Qk and measurement noise V k are used

 2
0.3 I 0 0 0

π 2
 0 (0.4 180 ) I 0 0 
Qk =  π
15 180  (10.5)
 0 0 3600 I 0 
π
15 180
0 0 0 3600 I
2
 
0.05 I 0
Vk = (10.6)
0 0.42

Online Results

The ESKFs position estimates seen in Figure 10.10, follows the measurements from the
Vector smoothly. Also, with the GNSS measurements set to a precision of ±5cm, the
standard deviation settles below 3.5cm. The Down measurements and estimates are prone
to a high frequent disturbance which is likely due to errors in the GNSS measurements.
This is also reflected in the bias for the accelerometer az trying to compensate for this.
The heading estimate ψ seen in Figure 10.11, is smooth and follows the measurements
from the Vector. The roll φ and pitch θ, which has no absolute measurements, are very
plausible and are close to the Xsens’ estimates. The deviations is likely due to the more
advanced gravity model used in the Xsens than the one used in the ESKF. The velocities
seen in Figure 10.12 coincides with the position plots. For the biases seen in Figure 10.13,
the biases in angular rate converge rapidly to a stationary value. However, the acceleration
biases ax and ay does not, which is most likely because the horizontal accelerometer
biases are not observable without large rotations, in roll and pitch, to initialize the biases
(Du et al., 2017).
This test reveals that the matrix exponential discretization mentioned in 5.1.7 is fast enough
to be used in real time. This means that the ESKF can be implemented and used as an
observer on ReVolt.

85
Chapter 10. Experimental Results

Figure 10.10: Online ESKF performance during a 4-corner box maneuver. Est is estimated, Vec is
measurements from the Vector.

Figure 10.11: Online ESKF performance during a 4-corner box maneuver. Est is estimated, Xse
and Vec is measurements from the Xsens and Vector respectively.

86
 10.1 Observer Performance

Figure 10.12: Online ESKF performance during a 4-corner box maneuver. Est is estimated.

Figure 10.13: Online ESKF performance during a 4-corner box maneuver. Est is estimated.

87
Chapter 10. Experimental Results

10.2 Pose and Velocity Measurements

Since the Kalman Filter was not stable when implemented on ReVolt, the pose and velocity
measurements used in the controller were taken from the Vector VS330.
The Xsens’ velocity estimates were incorrect and therefore the velocities are obtained from
low-pass differencing the pose data from the Vector. Low-pass differencing means that the
difference between two position measurements is taken and passed through a low-pass
filter to get smooth velocity measurements. Figure 10.14 shows the velocity data from
the low-pass differencing and Xsens estimates as ReVolt is performing a 4-corner box
maneuver.

0.4 Low-pass differencing

Xsens
u [m/s]

0.2

-0.2
50 100 150 200 250

0.2
v [m/s]

-0.2

50 100 150 200 250

5
r [deg/s]

-5

50 100 150 200 250

Time [s]

Figure 10.14: Comparison of vessel velocity estimated by the Xsens or computed by derivation of
the position. The velocities are rotated to BODY using the yaw measurements from the Hemisphere
Vector VS330.

With the Hemisphere’s dual antennas, RTK corrections and a low-pass filter, the velocity
measurements are smooth and behave as expected when performing a 4-corner box test.
The Xsens provides a noisy surge speed estimate, with an unexpected positive surge speed
at t=190s. The Xsens also provides positive measurements of sway speed around t=140s

88
 10.3 Test Area

which does not occur with the other measurement, nor was this observed during the test.
The yaw rate from the Hemisphere and Xsens are very similar, but the low-passed Vector
measurements provide a more smooth signal which is easier for the controller to use. The
yaw rates are similar which is to be expected as this is a direct measurement from the gyro
and this implies that the differencing is adequate.
The Xsens provides good roll and pitch measurements, seen in Figure 10.4. The deviations
are small, with the pitch measurements deviating the most. This is however negligible and
can be caused by how the Xsens is installed. The yaw measurement in addition to not
being north referenced, drifts as time progresses. To estimate the heading, such a system
needs a north seeking IMU able to differentiate the measurement of the Earth’s angular
velocity from other effects (Vik, 2014). The yaw measurements from the Hemisphere are
obtained from differentiating the two antenna’s relative position compared to north, thus
providing a good heading measurement. The position measurements of the Xsens are, as
seen in Figure 10.2, not as precise as the Vector VS330.

10.3 Test Area

Trondheimsfjorden was declared as a test site for autonomous ships on the 30 September
2016 (Meland, 2016). The sea state in the fjord is however too rough for ReVolt, therefore
test sites at Dorabassenget and Havnebasseng III was devised in agreement with Trond-
heim Havn, where the final tests were performed in the latter, as marked in Figure 10.15.
The test site was subject to slight wind from north-east and presumably no current. The
experiments were performed in accordance with the guidelines for ReVolt which include
safe operations, pre- and post operation procedures, as well as checklists for launch and
recovery. The guidelines can be found in Appendix F.

10.4 Parameters

Before beginning with the 4-corner box tests, the reference filter, thrust allocation and PID
controller were tuned. These values were kept the same for all the tests in this chapter.

10.4.1 Reference Filter Parameters

The reference filter parameters were, as in the simulations, set conservatively for ReVolt
to easily follow the desired trajectory from the reference filter. The reference filter could
have been more aggressive, making ReVolt move faster, but this was not the purpose. The
following saturation limits were used:

xmax = 1.5 − xmax = 1.0 ymax = 0.6 − ymax = 0.5 ± ψmax = 35◦ (10.7)

89
Chapter 10. Experimental Results

Test Area

Figure 10.15: The test area at Havnebasseng III. Adapted from Gulesider® Kart.

This resulted in the following tuning parameters:

       
ζN 1 ωn,N 0.6
∆ =  ζE  = 1 , Ω =  ωn,E  = 0.6 (10.8)
ζpsi 1 ωn,ψ 0.6

10.4.2 Tuning Thrust Allocation

When requesting forces from the thrust allocation, unwanted moments will be induced due
to the ship’s hull. This is caused by fact that the water’s point of attack on the hull, not
being the same as CG. By moving CG forwards or backwards, the moments of the thrust
allocation can cancel out the induced moments. In practice, this is done by moving each
thruster’s position in the thrust allocation in the longitudinal direction lxi .
The thrust allocation was tuned as follows:
Request ± force in sway motion
if ± yaw motion
move CG in ∓ direction
if ∓ yaw motion
CG in ± direction
Which gave the results:

90
 10.4 Parameters

(lx1 , ly1 ) = (−1.12 − 0.53, −0.15) = (−1.65, −0.15)

(lx2 , ly2 ) = (−1.12 − 0.53, 0.15) = (−1.65, 0.15)
(lx3 , ly3 ) = (1.12 + 0.03, 0) = (1.15, 0)

Notice that these are not the same as the measured distances, found in Figure 8.2.

10.4.3 Controller Gains

The saturation limits in the controller are set according to the maximum thrust the ship’s
thrusters can supply, found in Figure 8.5. Since the maximum thrust is different for ±sway
and ±yaw rotation, a compromise was made and a suitable value has been chosen. The
saturation limits are:
   
τX,max 50
τ max =  τY,max  = 20 (10.9)
τN,max 32

The controller was manually tuned directly on the physical system during the experiments,
using the method described in Section 4.1.3.

The following controller gains were obtained:

   
Kp,surge 0 0 25 0 0
Kp =  0 Kp,sway 0  =  0 25 0  (10.10)
0 0 Kp,yaw 0 0 30
   
Ki,surge 0 0 0.3 0 0
Ki =  0 Ki,sway 0  =  0 0.3 0  (10.11)
0 0 Ki,yaw 0 0 0.3
   
Kd,surge 0 0 75 0 0
Kd =  0 Kd,sway 0  =  0 75 0  (10.12)
0 0 Kd,yaw 0 0 50

10.4.4 Lever-Arm

For ReVolt, the lever-arm is:

 
−0.81
∆pb =  0  (10.13)
−0.2

91
Chapter 10. Experimental Results

10.5 4-Corner Test

To fully test the DP control system and capabilities of ReVolt, a series of tests were per-
formed on the 3rd, 4th and 5th of May 2017. During the tests, on all days, there was a
slight north-east breeze and no significant current. The 4-corner box test as described in
Section 9.1 was used for all tests, as this makes comparing the performance of the different
scenarios easier. The plan for the test procedure is shown in Table 10.1.

Scenario Thruster rotation rates Bow thruster rotation Controller

1 Unconstrained
Static
2 Constrained
No FF
3 Rotating
4 Analyze scenario 1 Static
and 2, proceed with
5 the best scenario. Analyze scenario 3 and 4, proceed No FF
6 with the best scenario. With FF

Table 10.1: The test scenarios and in which order they were tested.

The different scenarios were tested at least two times, in order to determine the repeatabil-
ity of the scenario.
During testing it was found that the model of ReVolt might not be accurate, due to ReVolt’s
behavior with the feedforward activated. An on-site adjustment to the feedforward element
of the controller was made and the tuned feedforward is also compared to the original
feedforward. This is described in more detail in Section 10.5.4.

10.5.1 Performance Metrics

To compare controller performance, the errors in position and heading are normalized
between 0 and 1, where it is assumed that the greatest errors are 5m and 50◦ in north/east
position and heading, respectively.

p(t) pd (t) ψ ψd
p̄(t) = , p̄d (t) = , ψ̄ = , ψ̄d = (10.14)
5 5 50 50

These normalized values are then integrated over time. The equation for calculating the
Integrated Absolute Error (IAE) is given as

Z t
IAE(t) = |ē(σ)|dσ (10.15)
0

92
 10.5 4-Corner Test

where ē(t) is the error at time t and is defined as

q
ē(t) = (p̄(t) − p̄d (t))2 + (ψ̄(t) − ψ¯d (t))2 ) (10.16)

The Integral of Absolute Differentiated Control (IADC) adapted from Eriksen and Breivik
(2017), and is used to assess each scenarios wear and tear on the actuators. The change
in actuator input is integrated to to get the accumulated difference in actuator input over
time. The modified IADC is then given as

Z t
IADC(t) = |ū|(σ) + |ᾱ|(σ)dσ (10.17)
0
where ū and ᾱ is the normalized difference in actuator input at a given time and is defined
as

ū(t) − ū(t − h) u
ū(t) = , ū = (10.18)
h 100
α(t) − α(t − h) α
ᾱ(t) = , ᾱ = ◦ (10.19)
h 90

10.5.2 Unconstrained vs. Constrained

The purpose of this test is to compare the performance of Revolt with and without con-
straints on the thruster rotation rates in the thrust allocation. More specifically, the only
change is whether the stern thrusters rotation rate is constrained or not. The maximum
thruster rotation rate for the two stern thrusters was set to ∆α1,2 = 30◦ according to
Section 7.2.4. The test was performed with a static bow thruster, set at 90◦ , and without
feedforward.
Figure 10.16 and Figure 10.17, show the 4-corner box tests performed with unconstrained
thruster rotation and constrain thruster rotation, respectively. It can be seen that in both
cases the vessel trajectories are similar, indicating that the tests are repeatable. Figure
10.18 shows the performance metrics of all the trajectories in this test. From this it is
seen that the total error is similar in both setups, but the change in control output is larger
with the unconstrained setup as expected since the thrust allocation is unconstrained. To
compare these two setups, the best trajectory of both tests are chosen.
Figures 10.19 and 10.20 show the desired- and vessel-trajectory from the two setups. In
the first, surge motion the unconstrained thrust allocation overshoots more than the con-
strained. This is due to the thrust allocation, with unconstrained rotation rates, rotating
the thrusters faster than physically achievable, see Figure 10.22, and applying thrust. This
causes thrust in unwanted directions, resulting in velocities in sway, as seen in Figure 10.21
at t=40s. This also causes the PID to compensate which is seen as oscillations in Figure
10.23. During the coupled surge-sway motion, from point 4 to 5 in the box maneuver, the
unconstrained setup surprisingly performs better.

93
Chapter 10. Experimental Results

The unconstrained setup seems to tracks the desired trajectory better as shown by the IAE
in Figure 10.18. However, the constrained suffers less from big errors and roll motions,
due to rapid change of the thruster angles. The effect of these roll motions can be seen as
oscillations in the control effort and sway speed of the unconstrained setup. Also it can
clearly be seen that the IADC for the unconstrained setup is higher. This is not favourable
as this causes extra wear and tear unnecessarily on the actuators. It is therefore decided to
go forward with the constrained setup.

4
Desired
1
Uncon
North [m]

3 2
Uncon

-7 -6 -5 -4 -3 -2 -1 0 1 2
East [m]
0
ψ [deg]

-20

-40

50 100 150 200 250

Time [s]

Figure 10.16: All vessel trajectories for static bow thruster with no constraints on ∆α in the thrust
allocation.

94
 10.5 4-Corner Test

North [m] Desired

3 1
Con
2
Con
3
2 Con

-7 -6 -5 -4 -3 -2 -1 0 1 2
East [m]
0
ψ [deg]

-20
-40

50 100 150 200 250

Time [s]

Figure 10.17: All vessel trajectories for static bow thruster with constraints on ∆α in the thrust
allocation.

Figure 10.18: Performance metrics - static bow thruster with no constraints on ∆α in the thrust
allocation.

95
Chapter 10. Experimental Results

4
Desired
Uncon
North [m]

3 Con

-7 -6 -5 -4 -3 -2 -1 0 1 2
East [m]
0
ψ [deg]

-20

-40

50 100 150 200 250

Time [s]

Figure 10.19: Comparison of the two best vessel trajectories with unconstrained and constrained
∆α in the thrust allocation.

4 Reference
N [m]

Desired
2 Uncon
Con
0
50 100 150 200 250

0
E [m]

-2

-4

50 100 150 200 250

0
ψ [deg]

-20

-40

50 100 150 200 250

Time [s]

Figure 10.20: Comparison of the two best vessel trajectories over time using unconstrained and
constrained ∆α in the thrust allocation.

96
 10.5 4-Corner Test

0.3 Desired
Uncon

u [m/s]
0.2
Con
0.1
0
-0.1
0 50 100 150 200 250

0.2
0.1
v [m/s]

0
-0.1

0 50 100 150 200 250

10
r [deg/s]

5
0
-5

0 50 100 150 200 250

Time [s]

Figure 10.21: Comparison of the velocity for the two best vessel trajectories with unconstrained and
constrained ∆α in the thrust allocation.

Uncon 100
50
α1 [deg]

Con
u1 [%]

0
-100
0
50 100 150 200 250 50 100 150 200 250

60
100
α2 [deg]
u2 [%]

40
0
20
-100
0
50 100 150 200 250 50 100 150 200 250
92
50
α3 [deg]
u3 [%]

0 90
-50
88
50 100 150 200 250 50 100 150 200 250
Time [s] Time [s]

Figure 10.22: Comparison of the thrust allocation for the two best vessel trajectories with uncon-
strained and constrained ∆α in the thrust allocation.

97
Chapter 10. Experimental Results

20 UnconX
τP ID [N]

10 ConX

0
-10

50 100 150 200 250

20
UnconY
τP ID [N]

10 ConY
0
-10

50 100 150 200 250

10
UnconN
τP ID [Nm]

5 ConN

0
-5
50 100 150 200 250
Time [s]

Figure 10.23: Comparison of the controller output for the two best vessel trajectories with uncon-
strained and constrained ∆α in the thrust allocation.

98
 10.5 4-Corner Test

10.5.3 Rotation vs. Static

The purpose of this test is to compare whether or not allowing the bow thruster to rotate
will improve the performance of Revolt. The maximum thruster rotation rate for the bow
thruster was set to ∆α3 = π/36. All the tests were performed with constrained thruster
rotation rates and using only the PID controller. The only change is whether the bow
thruster rotates or is static.
Figures 10.24 and Figure 10.25 show the 4-corner box tests performed with the bow
thruster rotating and being static, respectively. From the rotating thruster plot, it is seen
that there are some differences in the trajectories. This is presumably caused by envi-
ronmental disturbances. In the case of the static bow thruster, the vessel trajectories are
similar, again indicating that the tests are repeatable. From the performance metrics in
Figure 10.26, the IADCs are similar, however the IAEs for rotating bow thruster suffers
more. The two best trajectories from each setup, are further compared.
Figures 10.27 and 10.28 show the desired- and vessel-trajectory from the two setups. The
setup with the rotating bow thruster has a larger overshoot with every setpoint change of
the box maneuver, compared to the setup with the static bow thruster. The reason for this
can be seen in figures 10.30 and 10.31 where the controller wants a desired force, and
the thrust allocation prioritizes to turn the bow thruster instead of reversing thrust which
is faster. This also induces roll motions similar to those with the unconstrained setup,
mentioned in Section 10.5.2. This propagates into the controller, the demanded thrust and
the velocities in Figure 10.29, weakening the performance. It is therefore decided to go
forward with the static bow thruster setup.

99
Chapter 10. Experimental Results

4
Desired
1
Rot
North [m]

2
3 Rot

-8 -7 -6 -5 -4 -3 -2 -1 0 1 2
East [m]
0
ψ [deg]

-20
-40

50 100 150 200 250

Time [s]

Figure 10.24: All vessel trajectories with rotating bow thruster α˙3 6= 0◦ .

4
North [m]

Desired
3 1
Stat
2
Stat
3
2 Stat

-7 -6 -5 -4 -3 -2 -1 0 1 2
East [m]
0
ψ [deg]

-20
-40

50 100 150 200 250

Time [s]

Figure 10.25: All vessel trajectories with static bow thruster α3 = 90◦ .

100
 10.5 4-Corner Test

Figure 10.26: Performance metrics - Rotating bow thruster α˙3 6= 0 vs static bow thruster α3 = 90◦ .

4
North [m]

Desired
2
Rot
Stat
1

-8 -7 -6 -5 -4 -3 -2 -1 0 1 2
East [m]
0
ψ [deg]

-20
-40

50 100 150 200 250

Time [s]

Figure 10.27: Comparison of the two best vessel trajectories with rotating bow thruster α˙3 6= 0 vs
static bow thruster α3 = 90◦ .

101
Chapter 10. Experimental Results

4 Reference

N [m]
Desired
2 Rot
Stat
0
50 100 150 200 250

0
E [m]

-2

-4

50 100 150 200 250

0
ψ [deg]

-20

-40

50 100 150 200 250

Time [s]

Figure 10.28: Comparison of the two best vessel trajectories over time using rotating bow thruster
α˙3 6= 0 vs static bow thruster α3 = 90◦ .

0.3 Desired
Rot
u [m/s]

0.2
Stat
0.1
0
-0.1
0 50 100 150 200 250

0.2
0.1
v [m/s]

0
-0.1

0 50 100 150 200 250

5
r [deg/s]

-5

0 50 100 150 200 250

Time [s]

Figure 10.29: Comparison of the velocity for the two best vessel trajectories with rotating bow
thruster α˙3 6= 0 vs static bow thruster α3 = 90◦ .

102
 10.5 4-Corner Test

Rot 100
50

α1 [deg]
Stat

u1 [%]
0
-100
0
50 100 150 200 250 50 100 150 200 250

60
100

α2 [deg]
u2 [%]

40
0
20
-100
0
50 100 150 200 250 50 100 150 200 250

50 100

α3 [deg]
u3 [%]

0 0
-50 -100

50 100 150 200 250 50 100 150 200 250

Time [s] Time [s]

Figure 10.30: Comparison of the thrust allocation of the two best vessel trajectories with rotating
bow thruster α˙3 6= 0 vs static bow thruster α3 = 90◦ .

20
τP ID [N]

0
RotX
-20 StatX

50 100 150 200 250

20
RotY
10
τP ID [N]

StatY
0
-10

50 100 150 200 250

RotN
τP ID [Nm]

5
StatN
0
-5
-10
50 100 150 200 250
Time [s]

Figure 10.31: Comparison of the controller output for the two best vessel trajectories with rotating
bow thruster α˙3 6= 0 vs static bow thruster α3 = 90◦ .

103
Chapter 10. Experimental Results

10.5.4 PID-FF vs. Tuned PID-FF

From Figure 10.32, it is obvious that the mathematical model of ReVolt used in the feed-
forward part of the controller is inaccurate. It was therefore decided to limit the control
effort created by the feedforward term, by multiplying a constant KF F,i , with each of the
elements in the feedforward control effort vector τ F F . The tuned control effort is:
   
KF F,1 τF F,X 1.0 · τF F,X
τFF =  KF F,2 τF F,Y  = 0.05 · τF F,Y  (10.20)
KF F,3 τF F,N 0.2 · τF F,N

The purpose of this test is to compare the tuned feedforward with the original feedforward.
All the tests were performed with constrained thruster rotation rates and with a static bow
thruster rotated to 90◦ .
Figure 10.33 shows the 4-corner box tests performed with the tuned feedforward. One
trajectory differs greatly from the two other, caused by a wave from west. From the per-
formance metrics in Figure 10.34, the IAE for the tuned feedforward is obviously lower
than the original and has a slightly lower IADC, which is mainly due to a smaller overshoot
to correct for.
Figures 10.35 and 10.36 show the desired- and vessel-trajectory from the two setups. The
setup with the original feedforward tracks the desired path poorly and has large overshoots
in position and heading. This is also the case for the velocities in Figure 10.37. The
controller reaches its saturation limit for force in sway and heading as seen in Figure
10.38. The tuned feedforward is chosen for further use.

104
 10.5 4-Corner Test

6 Desired
1
FF
5 2
FF
3
FF
4
North [m]
3

-1

-8 -6 -4 -2 0 2 4
East [m]
20
0
ψ [deg]

-20
-40
-60
-80
50 100 150 200 250
Time [s]

Figure 10.32: All vessel trajectories for PID with original feedforward.

3
North [m]

Desired
1
FFT uned
2
FFT uned
2 3
FFT uned

-7 -6 -5 -4 -3 -2 -1 0 1 2
East [m]
0
ψ [deg]

-20
-40

50 100 150 200 250

Time [s]

Figure 10.33: All vessel trajectories for PID with tuned feedforward.

105
Chapter 10. Experimental Results

Figure 10.34: Performance metrics - PID with original feedforward and tuned feedforward.

6 Desired
FFT uned
5 FF

4
North [m]

-1
-8 -6 -4 -2 0 2 4
East [m]
20
0
ψ [deg]

-20
-40
-60
-80
50 100 150 200 250
Time [s]

Figure 10.35: Comparison of the two best vessel trajectories with PID with original feedforward
and tuned feedforward.

106
 10.5 4-Corner Test

6 Reference
Desired
4

N [m]
FFT uned
2 FF

50 100 150 200 250

2
0
E [m]

-2
-4
-6
50 100 150 200 250

20
0
ψ [deg]

-20
-40
-60
-80
50 100 150 200 250
Time [s]

Figure 10.36: Comparison of the two best vessel trajectories over time using PID with original
feedforward and tuned feedforward.

0.4
Desired
FFT uned
0.2
u [m/s]

FF
0

-0.2
0 50 100 150 200 250

0.4
0.2
v [m/s]

0
-0.2
-0.4
0 50 100 150 200 250

10
r [deg/s]

-10

0 50 100 150 200 250

Time [s]

Figure 10.37: Comparison of the velocity for the two best vessel trajectories with PID with original
feedforward and tuned feedforward.

107
Chapter 10. Experimental Results

20
40
10
20

τT ot [Nm]
τT ot [N]

0
0
-10
-20
-20
FFT unedN
-40 FFN
-30
50 100 150 200 250 50 100 150 200 250

40
FFT unedX
FFT unedY
50 FFX
FFY 20
τF F [Nm]
τF F [N]

0 0

-50 -20

50 100 150 200 250 50 100 150 200 250

60

40 20

20
τP ID [Nm]
τP ID [N]

10
0

-20 0

-40
-10
-60

50 100 150 200 250 50 100 150 200 250

Time [s] Time [s]

Figure 10.38: Comparison of the controller output for two best vessel trajectories with PID with
original feedforward and tuned feedforward.

108
 10.5 4-Corner Test

10.5.5 PID vs. Tuned PID-FF

The purpose of this test is to determine whether the PID controller with or without feed-
forward performs better. This test will have constrained thruster rotation rates, a static bow
thruster set at 90◦ and a tuned feedforward as these setups proved to be best.
The performance metrics of the trajectories from the constrained PID run in Figure 10.17
and the tuned feedforward run in Figure 10.33, are shown in Figure 10.39. The IAE is
slightly larger with the feedforward, whereas the IADC similar for the two setups. The
two best trajectories from each setup are further compared.
ReVolt is able to track the desired trajectory in the pure surge and sway motions fairly well
with both setups, as seen in figures 10.40 and 10.41. However, the feedforward makes
ReVolt respond faster, since the desired trajectory is passed forward in the controller. This
rapid response does, however, cause ReVolt to have larger overshoots in pose and velocity
which can be seen in Figure 10.42. Both setups are struggling with the coupled surge-
sway motion, which is especially evident from the vessel’s poor ability to track the desired
velocities for this motion. The PID controller performs better at this motion. The expected
result from using the feedforward is for the PID part to contribute less to the total control
effort. However, this is not the case in Figure 10.44. The PID controller needs to work
more with the feedforward active to correct for the errors caused, which propagates into
the thrust allocation. This is seen in Figure 10.43.
The setup with no feedforward is concluded to be the best. It has a smaller pose error, fol-
lows the desired trajectory and velocity better, is easier on the actuators and does not satu-
rate the controller. The benefits of the feedforward did not compensate for the drawbacks
caused by using an inaccurate model. The importance of having a correct feedforward
model cannot be stressed enough. This will otherwise introduce errors into the system.

109
Chapter 10. Experimental Results

Figure 10.39: Performance metrics - PID vs PID with tuned feedforward.

4
Desired
FFT uned
North [m]

3 PID

-7 -6 -5 -4 -3 -2 -1 0 1 2
East [m]
0
ψ [deg]

-20
-40

50 100 150 200 250

Time [s]

Figure 10.40: Comparison of the two best vessel trajectories with PID and PID with tuned feedfor-
ward.

110
 10.5 4-Corner Test

4 Reference

N [m]
Desired
2 FFT uned
PID
0
50 100 150 200 250

0
E [m]

-2

-4

50 100 150 200 250

0
ψ [deg]

-20

-40

50 100 150 200 250

Time [s]

Figure 10.41: Comparison of the two best vessel trajectories over time using PID and PID with
tuned feedforward.

0.4
Desired
FFT uned
u [m/s]

0.2 PID

0 50 100 150 200 250

0.2
v [m/s]

-0.2
0 50 100 150 200 250

10
r [deg/s]

-10
0 50 100 150 200 250
Time [s]

Figure 10.42: Comparison of the velocity for the two best vessel trajectories with PID and PID with
tuned feedforward.

111
Chapter 10. Experimental Results

80 FFT uned 100

α1 [deg]
60 PID
u1 [%]

40 0
20 -100
0
50 100 150 200 250 50 100 150 200 250

80
100
α2 [deg]

60
u2 [%]

40 0
20
-100
0
50 100 150 200 250 50 100 150 200 250
92
50
α3 [deg]
u3 [%]

0 90
-50
88
50 100 150 200 250 50 100 150 200 250
Time [s] Time [s]

Figure 10.43: Comparison of the thrust allocation for the two best vessel trajectories with PID and
PID with tuned feedforward.

112
 10.5 4-Corner Test

50 10
40

30 5

τT ot [Nm]
20
τT ot [N]

0
10

0
-5
-10 FFT unedN
PIDN
-20 -10
50 100 150 200 250 50 100 150 200 250

40
FFT unedX
30 FFT unedY
5
PIDX
20 PIDY
τF F [Nm]
τF F [N]

10 0

-10 -5

50 100 150 200 250 50 100 150 200 250

20
5
10
τP ID [Nm]
τP ID [N]

0 0

-10
-5
-20
-10
50 100 150 200 250 50 100 150 200 250
Time [s] Time [s]

Figure 10.44: Comparison of the controller output for the two best vessel trajectories with PID and
PID with tuned feedforward.

113
Chapter 10. Experimental Results

10.6 Application to Docking

To get an idea if this control system could be applied to docking an autonomous ferry,
such a test was performed. The test consisted of setting the position reference of ReVolt
close to a berth with fenders. ReVolt performed the maneuver with no interference from
the operators. Figure 10.45 shows the position and heading of ReVolt in this attempt, as
well as the position of the berth. The maneuver was a coupled surge-sway motion, with a
desired heading of -40◦ . This is as mentioned previously, seemingly the hardest maneuver
for ReVolt, which may have impaired the results, as opposed to having a pure sway motion.
The sway speed was too high as ReVolt approached the berth, seen in Figure 10.46, which
caused ReVolt to lightly bounce of the fenders before it came to a stop alongside the berth.
The surge and sway speed was less than 0.15m/s as ReVolt made contact with the fenders,
which would result in a deceleration unpleasant for passengers. However, by spreading
the impact force on several fenders, it would not cause damage to the vehicle itself.

0
Desired
ReVolt
Berth
-1

-2
North [m]

-3

-4

-5
-9 -8 -7 -6 -5 -4 -3 -2 -1 0
East [m]
-20
ψ [deg]

-40

-60
0 10 20 30 40 50 60 70 80 90 100
Time [s]

Figure 10.45: Position and heading of ReVolt when performing a docking maneuver.

114
 10.6 Application to Docking

Desired
0.2
u [m/s]

ReVolt
0.1
0

0 10 20 30 40 50 60 70 80 90

0.1
v [m/s]

-0.1

-0.2
0 10 20 30 40 50 60 70 80 90

4
r [deg/s]

2
0
-2

0 10 20 30 40 50 60 70 80 90
Time [s]

Figure 10.46: Velocity of ReVolt when performing a docking maneuver. Slight oscillations occur
due disturbances and imperfect controller tuning.

115
Chapter 11
Discussion

This chapter includes a discussion of the choices made in this thesis, the experimental
results and some remarks regarding the execution of the project.

Figure 11.1: ReVolt in sunset at Trondheim harbour 17 November 2016.

117
Chapter 11. Discussion

11.1 Dynamic Positioning System

A reference filter was chosen as the guidance system due to its simplicity and its easy
implementation. The thought was for ReVolt to perform simple maneuvers and imple-
ment more advanced guidance with path following at a later time. The reference filter
became more complex than first intended as saturating the output of the filter in Fossen
(2011), caused the acceleration, velocity and position to become inconsistent. Therefore a
saturation of the input was developed to get consistent position, velocity and acceleration
trajectories.
As this thesis’ goal was station keeping and low-speed maneuvering of ReVolt, a PID with
feedforward was proposed. The PID controller is simple yet robust, which is crucial for an
unmanned vessel. Adding the model-based feedforward gives some of the advantages of
more advanced controllers which potentially can improve the maneuvering capabilities of
ReVolt. In the case of an inaccurate model, it can simply be removed, leaving a functioning
control system in the form of a PID controller.
Since this thesis is in association with DNV GL, they made their thrust allocation algorithm
available to us. The implementation was not straight forward as it was written in a different
programming language than used in ReVolt. Nonetheless, a big portion time was saved as
opposed to developing one from scratch. The need to implement a bow thruster with non-
symmetrical thrust characteristics was unexpected. This had to be dealt with in the thrust
allocation as well as the reference filter, which increased the complexity of the DP system.
An accurate measurement of ReVolt’s navigation state, pose and velocity, was desired for
the PID controller. An observer based on ESKF was chosen due to its dead reckoning abil-
ities and the possibility to add position measurements from other source than a GNSS. This
is relevant in ReVolt’s future as more navigational sensors are planned to be implemented.

11.2 Simulations

The different parts of the DP system was implemented and tested in MATLAB. However,
this should have been done directly in ROS. This would test the actual implemented system
and could prove helpful in finding bugs before experimental tests are conducted. This will
save time as well as algorithms will not need to be implemented twice, which again will
save more time.

11.3 Station Keeping and Low-Speed Maneuvering

One of the goals in Chapter 1 was for ReVolt to achieve DP and low-speed maneuvering.
The optimal setup for this was found after several executions of the 4-corner box test with
different setups. The best result, as seen in Figure 11.2, was achieved with constrained
thrust allocation, a static bow thruster and no feedforward due to an inaccurate model.

118
 11.3 Station Keeping and Low-Speed Maneuvering

ReVolt was able to follow the desired trajectory, with a maximal error of 0.3m in north,
0.5m in east and 6.5◦ in heading. These errors occurred during the coupled surge-sway
motion from point 4 to 5 in the 4-corner box test. This coupled maneuver is in itself
difficult for ReVolt, but also since the bow thruster produces the least amount of thrust in
negative sway. Setting the bow thruster the opposite direction to -90◦ could have yielded
a better result for that maneuver, but impaired the coupled movement in positive sway
direction.

4
North [m]

-1

-8 -7 -6 -5 -4 -3 -2 -1 0 1 2
East [m]

Figure 11.2: The best 4-corner box maneuver achieved by ReVolt. The outline has the same dimen-
sions as ReVolt.

Due to an inaccurate model, the feedforward did not live up to its potential. A quick
solution during the sea trial, was to limit the control effort from the feedforward. A better
result was obtained, but with more time, tuning the model’s added mass and dampening
matrices could have given better results. It is evident from box plots such as Figure 11.2
that the center of rotation is not the same as CG. When ReVolt rotates during step 3 to 4
in the 4-corner box maneuver, it is seen in Figure 11.3 that its position curves upwards
indicating that the center of rotation is in front of CG.
The ESKF did show promising results in the offline as well as the ”online” tests. Fur-
ther experiments with the implemented ESKF are desired to see if the acceleration biases
stabilize by for example conducting a roll and pitch motion upon initialization. Also, a
gravity state could be added in the ESKF to prevent initial errors in gravity which are now
compensated for in the accelerometer biases. This can cause instability of the ESKF when
exposed to roll motions, as the gravity component will be rotated to the horizontal plane
and induce sway velocity.
Finally, using the estimates from the ESKF in conjunction with the controller and a feed-

119
Chapter 11. Discussion

6.5

5.5
North [m]

4.5

3.5
-6.5 -6 -5.5 -5 -4.5 -4 -3.5 -3
East [m]

Figure 11.3: Enhanced portion of the North-West corner of the 4-corner box maneuver, with the
Center of Gravity of marked. The outline has the same dimensions as ReVolt.

forward with an accurate model, is desirable to see if it improves the control performance
of ReVolt.

11.4 Docking

ReVolt was set to dock with its port side towards a berth with fenders. This allowed
for a experimental docking scenario not much unlike the autonomous ferry. This was a
improvised test leading to a coupled surge-sway motion towards the berth. As mentioned
previously, this is seemingly the hardest maneuver for ReVolt which may have impaired
the results.

However, the vessel managed decently and with the following small changes to the DP
system, the results could have been improved:

• Changing the reference parameters, for a more conservative desired trajectory.

• Setting the last setpoint closer/onto the berth, such that the thrusters keep the vessel
pushed toward the berth.

For an autonomous ferry, the results may be adequate if a system is built in order to guide
and moor the vessel, as well as extra sensors to provide close quarter navigation.

120
 11.5 Practical Considerations

11.5 Practical Considerations

During this thesis there are particularly two practical considerations which stand out.

11.5.1 ”Behind the Scenes” Work

This thesis has been a very practical thesis with a lot of hands on work. Therefore a lot
of work ”behind the scenes”, which has no value being mentioned in this thesis, is omit-
ted. This includes for example all the hours spent debugging, overcoming implementation
problems and converting experimental data to be used in MATLAB. It also includes the
time spent debugging the RTK system as well as moving and installing it closer to the
harbor, for better coverage at the test sites. Also omitted from the report is working with
the in-house workshop at NTNU to create a mounting bracket for the Xsens, and improve
the boat trolley to accommodate for easier launch of ReVolt.

11.5.2 Threshold for Field Tests

Everything done in this thesis has revolved around prototyping a DP control system for
ReVolt and getting it to work. The only way to verify that the DP system works as expected
is to perform field tests on land and sea. With ReVolt being 3 meters long, weighing a total
of 257kg including weights and with the other necessary equipment, the work before and
after every sea trial has been significant. Each sea trial has required good planning and
coordination with NTNU’s transportation service and finding a support vessel for ReVolt.
This had to be planned several days in advance. With each sea trial being a big operation,
the threshold for field tests has been high and it has been crucial that each sea trial has
yielded good results. It has been essential being two candidates collaborating, due to the
size of the thesis and the size of ReVolt.

121
Chapter 12
Conclusion and Future Work

The main objective of this thesis was to develop a DP control system to achieve accurate
and precise low-speed navigation using an IMU and GNSS with RTK corrections as navi-
gational sensors. Section 12.1 presents the conclusion for this thesis and Section 12.2 lists
potential future work on ReVolt.

12.1 Conclusion
The control system of the model ship ReVolt has been immensely improved, simulated,
implemented and tested with experimental sea trials. ReVolt is now able follow a desired
trajectory using a GNSS with RTK corrections and an IMU as navigational sensors.
Additionally, a mathematical model of ReVolt has been proposed. This model is based
on physical measurements of ReVolt and simulations of the hull in WADAM, and the
model is used in the feedforward part of the controller, utilizing changes in the reference.
However, due to modeling errors, the feedforward did not improve the control performance
of ReVolt.
ReVolt is able to achieve station keeping and low-speed maneuvering capabilities, with
the best setup being a constrained thrust allocation, a static bow thruster at 90◦ and with
the PID controller. ReVolt is able to follow the desired trajectory, with a maximal error
of 0.3m in north, 0.5m in east and 6.5◦ in heading. The maximal errors occur during the
coupled surge-sway motion, which is especially challenging for ReVolt to perform.
An observer consisting of an ESKF has been proposed for ReVolt, and gives promising
results in offline and ”online” tests. However when implemented on ReVolt, it has issues
with bias estimation. More tests were desired, but not possible due to limited time. Addi-
tionally, some prominent weaknesses and strengths of the navigational sensors on ReVolt,
were revealed.

123
Chapter 12. Conclusion and Future Work

12.2 Future Work

This is an extensive thesis with great potential for improvements and future work. Follow-
ing are some ideas for further work on ReVolt.

Improving the Error-state Kalman Filter

As the ESKF did not function properly, additional tests should be performed to test its
stability. Looking into adding a gravity state, or implementing a more advanced gravity
model to remove initial errors in gravity, can help improve the ESKF. If the navigation
sensor package on ReVolt is extended, with for example a Light Detection and Ranging
(LIDAR), can be added in a modular fashion to aid the ESKF during GNSS loss.

Implement a simulator in ROS

A simple simulator should be implemented in ROS for thorough Hardware In the Loop
(HIL)-testing of the implemented system before real life experiments are conducted.

Mathematical model

As the mathematical model used is incorrectly, experimentally identifying these would

render the feedforward useful, and probably improve the performance of ReVolt during
maneuvering. Such a tests are planned conducted at the end of this thesis by by DNV GL
at Marintek in Trondheim.

Waypoint tracking and path following

With a functioning DP control system, the guidance system should be expanded to in-
clude waypoint tracking and path following capabilities. This will enable ReVolt to more
efficiently navigate a predefined route.

Sensor implementation

ReVolt is equipped with sensors to precisely understand its current location, but it has no
ability to sense the surrounding environment. Additional sensors, such as a LIDAR, cam-
era and radar, should be considered for ReVolt to increase its awareness of the environment
and to aid in navigation. These sensors would need to be fused with the existing sensors
in order to obtain the whole picture.

124
 12.2 Future Work

Docking

Further studies should be conducted to assess the existing control system’s capabilities to
perform docking maneuvers. It is expected that docking can be improved with only minor
changes.

Collision avoidance

With an expansion of navigational and environmental sensors to detect obstacles, imple-

mentation of collision avoidance capabilities can be added to ReVolt.

125
Bibliography

Alfheim, H. L. and Muggerud, K. (2016). Dynamic positioning of the revolt model-scale

ship. Project thesis.

Arunvydhya (2017). Xsens mti ros node. http://github.com/xsens/xsens mti ros node.
Last Accessed: 3 March 2017.

Breivik, M. (2010). Topics in Guided Motion Control of Marine Vehicles. PhD thesis,
Norwegian University of Science and Technology, Trondheim, Norway.

Breivik, M., Kvaal, S., and Østby, P. (2015). From Eureka to K-Pos: Dynamic Positioning
as a Highly Successful and Important Marine Control Technology. IFAC-PapersOnLine,
48 (16):313 – 323. 10th IFAC Conference on Manoeuvring and Control of Marine Craft
MCMC 2015.

Brown, R. G. and Hwang, P. Y. C. (2012). Introduction to Random Signals and Applied

Kalman Filtering: With MATLAB Exercises and Solutions. John Wiley & Sons, Inc.

DNV GL (2015). ReVolt main report. Technical Report 2015-0170, Rev.1, DNV GL,
Høvik, Norway.

Du, S., Sun, W., and Gao, Y. (2017). Improving observability of an inertial system by
rotary motions of an imu. Sensors, 17(4):698.

Egeland, O. and Gravdahl, J. T. (2002). Modeling and Simulation for Automatic Control.
Marine Cybernetics Trondheim, Norway.

Eriksen, B.-O. H. and Breivik, M. (2017). Modeling, Identification and Control of High-
Speed ASVs: Theory and Experiments, pages 407–431. Springer International Publish-
ing, Cham.

Fossen, T. I. (2011). Handbook of Marine Craft Hydrodynamics and Motion Control. John
Wiley & Sons.

Grip, H. F., Fossen, T. I., Johansen, T. A., and Saberi, A. (2015). Globally exponentially

127
Bibliography

stable attitude and gyro bias estimation with application to GNSS/INS integration. Au-
tomatica, 51:158–166.
Hemisphere (2017). Vector VS330 GNSS Receiver Datasheet. Hemisphere.
Hoberock, L. (1976). A survey of longitudinal acceleration comfort studies in ground
transportation vehicles. Research Report 40, The University of Texas at Austin, Austin,
Texas.
Kongsberg (2016). Kongsberg Seatex Seapath 330+ Datasheet. Kongsberg Seatex.
Kyckelhahn, B. A. and Forbus, K. D. (2004). Jit-
ter in self-explanatory simulation. Northwestern University.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.497.706&rank=1.
Marguedas (2017). ROS distributions. http://wiki.ros.org/Distributions. Last Accessed:
23 May 2017.
Meland, S. I. (2016). Først i verden med testområde for ubemannede fartøyer.
http://www.adressa.no/nyheter/sortrondelag/2016/09/30/F%C3%B8rst-i-verden-med-
testomr%C3%A5de-for-ubemannede-fart%C3%B8yer-13572359.ece. Last Accessed:
01 December 2016.
Moler, C. and Loan, C. V. (2003). Nineteen dubious ways to compute the exponential of a
matrix, twenty-five years later.
Nocedal, J. and Wright, S. J. (2006). Numerical Optimization. Springer, New York, 2nd
edition.
Parkinson, B. W. (1996). Progress in astronautics and aeronautics: Global positioning
system: Theory and applications, volume 2. AIAA.
Pavlis, N. K., Holmes, S. A., Kenyon, S. C., and Factor, J. K. (2012). The development
and evaluation of the earth gravitational model 2008 (egm2008). Journal of Geophysical
Research: Solid Earth, 117(B4).
Perko, E. (2017). Nmea navsat driver. http://wiki.ros.org/nmea navsat driver. Last Ac-
cessed: 1 April 2017.
Rolls-Royce (2016). Rolls-Royce unveils a vision of the future of remote and autonomous
shipping. http://www.rolls-royce.com/media/press-releases/yr-2016/pr-12-04-2016-rr-
unveils-a-vision-of-future-of-remote-and-autonomus-shipping.aspx. Last Accessed: 06
December 2016.
Skjetne, R., Smogeli, . N., and Fossen, T. I. (2004). A Nonlinear Ship Manoeuvering
Model: Identification and adaptive control with experiments for a model ship. Modeling,
Identification and Control, 25(1):3–27.
Skjetne, R., Sørensen, M. E. N., Breivik, M., Sørensen, A. J., Brodtkorb, A. H., Værnø,
S. A. T., Kjerstad, Ø. K., Vinje, B. O., and Calabrò, V. (2017). AMOS DP research
cruise 2016: Academic full-scale testing of experimental dynamic positioning control

128
 Bibliography

algorithms onboard R/V gunnerus. In Proceedings of OMAE, Trondheim, Norway, June

2017.
SNAME (1950). Nomenclature for treating the motion of a submerged body through a
fluid. Technical report, The Society of Naval Architects and Marine Engineers.
Solà, J. (2017). Quaternion Kinematics for the Error-State Kalman Fil-
ter. Technical report, Institutde Robtica i Informtica Industrial. Available:
http://www.iri.upc.edu/people/jsola/JoanSola/objectes/notes/kinematics.pdf.
Sørensen, A. J. (2013). Marine control systems propulsion and motion control of ships
and ocean structures. Norwegian University of Science and Technology, Trondheim,
Norway. Lecture Notes.
Sørensen, M. E. N., Bjørne, E. S., and Breivik, M. (2016). Performance comparison of
backstepping-based adaptive controllers for marine surface vessels. In Control Applica-
tions (CCA), 2016 IEEE Conference on, pages 891–897. IEEE.
Stensvold, T. (2016). Verdens frste frerlse passasjerferge kan g over en kanal i Trond-
heim. https://www.tu.no/artikler/verdens-forste-forerlose-passasjerferge-kan-ga-over-
en-kanal-i-trondheim/363790.
Van Loan, C. (1978). Computing integrals involving the matrix exponential. IEEE trans-
actions on automatic control, 23(3):395–404.
Vik, B. (2014). Integrated Satellite and Inertial Navigation Systems. Booklet, Norwegian
University of Science and Technology, Trondheim, Norway.
Wit, C. D. (2009). Optimal thrust allocation methods for dynamic positioning of ships.
Master’s thesis, Delft University of Technology, Delft, the Netherlands.
Xsens (2016). Mti User Manual - Mti 10 Series and MTi 100-Series. Xsens Technologies
B.V.
Yara (2017). YARA and KONGSBERG enter into partnership to build world’s first au-
tonomous and zero emissions ship. yara.com/media/press releases. Last Accessed: 14
May 2017.

129
Appendices

131
Appendix A
Media Coverage

Since the start of the academic project with ReVolt in the fall of 2016, there has been a
lot of media attention related to the project. The purpose of these media appearances have
been to promote the concept of unmanned ships and show the public how far technology
has come in this field. The different articles and movies related to ReVolt due to this master
thesis are listed below.

Figure A.1: Henrik and Kjetil operating ReVolt while being filmed by the German TV-channel ZDF.
Courtesy of Trondheim Havn

Articles and videos:

• Article about the concept ship ReVolt and how the scale model ship will be tested in

133
Appendix A. Media Coverage

Trondheim (15.11.2016): www.trondheimhavn.no/nyhet/tester-forerlose-

skip-i-nyhavna-1216.aspx
• Article about the first sea trials with ReVolt in Trondheim (21.11.2016):
www.trondheimhavn.no/nyhet/tester-trondheims-forste-
forerlose-ferge-1221.aspx
• Video report by Der Spiegel about ReVolt (20.01.2017): video.spiegel.de/
flash/33/54/1734533_1024x576_H264_HQ.mp4
• Video about the specialization project during the fall created by Kindergarden Media
for NTNU, and filmed by Henrik Alfheim and Kjetil Muggerud (06.02.2017): www.
youtube.com/watch?v=AyFkOfD1II8
• Article about the filming day with the German news channel ZDF (16.03.2017):
trondheimhavn.no/nyhet/norsk-skipsteknologi-pa-tysk-tv-
1248.aspx
• German TV-channel 3-Sat (16.03.2017): www.3sat.de/mediathek/?mode=
play&obj=65614
• German TV-channel ZDF (20.03.2017): www.zdf.de/nachrichten/
heute-plus/videos/autonome-schiffe-100.html
• Article about unmanned ships and ReVolt in SHZ (04.04.2017):
www.shz.de/deutschland-welt/netzwelt/der-kapitaen-
verlaesst-das-fahrende-schiff-id16511641.html
• Article about unmanned ships in the German newspaper Sächsische Zeitung
(04.04.2017): www.sz-online.de/nachrichten/autonome-
schifffahrt-rueckt-naeher-3652317.html
• News segment about NTNU Ocean Week on NRK’s local news (03.05.2017):
tv.nrk.no/serie/distriktsnyheter-midtnytt/DKTL98050317/
03-05-2017#t=1m1s
• Article about unmanned maritime transport in Universitetsavisa (03.05.2017):
www.universitetsavisa.no/forskning/2017/05/03/Tror-
p%C3%A5-automatisert-maritim-transport-66069.ece
• Article about NTNU Ocean Week in Teknisk Ukeblad (04.05.2017):
www.tu.no/artikler/her-er-kongsbergs-to-nyeste-
autonome-bater/382484
• Article about ReVolt and NTNU Ocean Week in Adressa (04.05.2017):
www.adressa.no/pluss/okonomi/2017/05/04/B%C3%A5ten-
styres-fra-land-14676736.ece

134
Appendix B
ReVolt Wiring Schematic

135
 ReVolt Wiring schematic
Date: 01.06.2017

UNO
ARDUINO
- +

USB DC INPUT

ROS PC
K1 20A -
30A 230V AC

K1 K2 K3

K2 50A -
30A 230V AC
K1 - Bow
K2 - Port
K3 - Starboard

K3 10A -
30A 230V AC

R2=3kΩ
R1=4.3kΩ

R2=3kΩ
R1=4.3kΩ
RC-RECIEVER

POWER
Appendix C
Introduction to ROS

137
Introduction to ROS
1 Introduction
This introduction to Robot Operating System (ROS), written by Henrik Lemcke Alfheim and Kjetil
Muggerud, as a guide to those starting with ROS. It is recommended to go through the tutorial at
http://wiki.ros.org/ROS/Tutorials for a more in-depth insight to ROS.

Figure 1 - Simple ROS network

2 Basics 101: (assuming ROS is correctly installed)

1. Create a “workspace”
user@computer:~/$ mkdir –p ~/workspace/src
user@computer:~/$ cd workspace/src
user@computer:~/workspace/src/catkin_init_workspace
user@computer:~/workspace/src/$ cd ..
user@computer:~/workspace/catkin_make

The above commands do the following:

- Make a directory
- Move into workspace/src
- Initiate the workspace
- Step back to workspace/
- Build

You will now have a workspace with essentially nothing in it. It is now necessary to source
this workspace with:
user@computer:~/workspace/ source devel/setup.bash
2. Creating a package:
user@computer:~/workspace/src/ catkin_create_pkg example std_msgs rospy roscc

An example package is now created that also depends on other packages:

std_msgs: is a package containing many different structs for sending and receiving “topics”
rospy: makes the package able to understand Python language
roscc: makes the package able to understand C++ language

These dependencies can be edited in the CMakelists.txt and package.xml file.

3. Now let us create a node example in Python.

First we create a publisher node that publishes the topic chatter

File location: workspace/src/example/talker.py

#!/usr/bin/env python
# license removed for brevity
import rospy
from std_msgs.msg import String

def talker():
pub = rospy.Publisher('chatter', String, queue_size=10)
rospy.init_node('talker', anonymous=True)
rate = rospy.Rate(10) # 10hz
while not rospy.is_shutdown():
hello_str = "hello world %s" % rospy.get_time()
rospy.loginfo(hello_str)
pub.publish(hello_str)
rate.sleep()

if __name__ == '__main__':
try:
talker()
except rospy.ROSInterruptException:
pass
Then we create a listener node that runs a function every time it picks up data on the topic
chatter.

File location: workspace/src/example/listener.py

#!/usr/bin/env python
import rospy
from std_msgs.msg import String

def callback(data):
rospy.loginfo(rospy.get_caller_id() + "I heard %s", data.data)

def listener():

# In ROS, nodes are uniquely named. If two nodes with the same
# node are launched, the previous one is kicked off. The
# anonymous=True flag means that rospy will choose a unique
# name for our 'listener' node so that multiple listeners can
 # run simultaneously.
rospy.init_node('listener', anonymous=True)

rospy.Subscriber("chatter", String, callback)

# spin() simply keeps python from exiting until this node is stop
ped
rospy.spin()

if __name__ == '__main__':
listener()

4. Then we build this workspace by running catkin_make from the bottom of the workspace
directory and starting roscore:

user@computer:~/workspace/$catkin_make
user@computer:~/workspace/$ roscore

Open two new terminals, source devel/setup.bash inside your workspace and run both
nodes like this:

user@computer:~/workspace/$ rosrun example publisher.py

and
user@computer:~/workspace/$ rosrun example listener.py

5. Open a new terminal and try out these handy commands:

Command Info

Rosnode list Lists all active nodes

Rostopic list Lists all initiated topics

Rostopic echo “topic” Outputs data on the specified “topic”

Rostopic pub topic msg_type args Manually writes to the specified topic
example rostopic pub chatter std_msgs/String -
- Hello

6. Launching both nodes from a launch file. First press Ctrl-C in all three windows to shutdown
roscore, and both example nodes.
7. Writing a launch file

File location: workspace/src/tutorial.launch

<launch>

<node name=’’listener’’ pkg=’’example’’ type=’’listener.py’’>

<node name=’’publisher’’ pkg=’’example’’ type=’’publisher.py’’>

</launch>

user@computer:~/workspace/src/$ roslaunch tutorial.launch

This will start roscore and the two nodes in one command.

8. Recording or “bagging”

To bag, make a new directory anywhere suited to store the bag files, and run the command
“rosbag record –a” which will record everything.

user@computer:~/workspace/bags/$ rosbag record -a

To play them use:

Rosbag play “name.bag”

9. Some different graphical user interfaces that are handy for plotting and viewing ROS
messages

rqt_plot
rqt_console
rqt_bag
3 ROS on ReVolt
Operating system ROS version Password

Embedded computer Ubuntu 14.04 LTS Indigo ******

Laptop Ubuntu 14.04 LTS Indigo ******

3.1 General information

 The workspace is named revolt and is located in the user directory: /home/ros/revolt
 The workspace setup.bash file is automatically sourced in .bashrc (/home/ros/.bashrc)
 The launch file is located in /src/revolt.launch and will launch everything needed to run
the ReVolt
o It is automatically launched from roscore_startup at bootup (comment to stop
this )
o The bootup script can be found at /usr/locan/bin/roscore_startup
 For debugging and finding errors, it’s recommended to not start the launch, but run each
node individually with rosrun as this will show errors and log information.

3.1.1 Roscore_startup
Roscore_startup is a script that is run at start up, it is located at /etc/init.d

Source /opt/ros/indigo/setup.bash
Source /home/ros/revolt/devel/setup.bash

export ROS_WORKSPACE=/home/ros/revolt
export ROS_IP=10.0.0.1
export ROS_MASTER_URI=http://10.0.0.1:11311

(cd /home/ros/revolt && source devel/setup.sh) #Might not be needed

(cd /home/ros/revolt && catkin_make) #Builds the workspace

(cd /home/ros/revolt && catkin_make actuators_firmware_stern-upload) #upload Arduino code
(cd /home/ros/revolt && catkin_make actuators_firmware_bow-upload) #upload Arduino code

(cd /home/ros/revolt/src && roslaunch revolt.launch) #launces the launch file

 This file is run at bootup

o It will source the installed directories where ROS is installed
o Setting the right IP addresses (see section Error! Reference source not found. )
o Builds the workspace
o Upload code to Arduinos
o Execute launch file
3.2 Adding custom messages
In the package custom_msgs you can easily add new type of custom messages.
Look in /home/revolt/src/custom_msgs/msg/threeFloats.msg
float64 setpoint
float64 state
float64 error

It consists of three float64 types named setpoint, state and error.

This message needs to be built so we have to tell ROS to add this message. This is done in the
CMakeLists.txt for this package, located at /home/revolt/src/custom_msgs/CMakeLists.txt
## Generate messages in the ‘msg’ folder
Add_message_files(
FILES
…
###### ADDED CUSTOM msgs ####
podAngle.msg
threeFloats.msg
)

When adding new messages, build the workspace with the command catkin_make from workspace
folder (in this case /revolt ).

New packages needs to depend on the custom_msgs package in order to use these messages.
This is done by adding dependencies in the /workspace/src/package/ (CMakelists and package.xml)

File location: /revolt/src/actuators/CMakeLists.txt

Find_package( catkin RQUIRED COMPONENTS
roscpp
rospy
…
custom_msgs # added dependency on custom_msgs package
)

File location: /revolt/src/actuators/package.xml

<build_depend>…..</build_depend>
<build_depend>custom_msgs</build_depend> #added build dependency on custom_msgs
<run_depend>……..</run_depend>
<run_depend>custom_msgs</run_depend> # added run dependency on custom_msgs

Now the message can be imported in any Python or C++ script.

In Python:
from custom_msgs import threeFloats
Appendix D
ROS Graphs

A ROS graph is a graphical representation of the system’s software structure which is

generated in ROS. The representation includes which nodes are active and indicate which
topics are being sent between these nodes. Figure D.1 shows a simple example of infor-
mation sharing between two nodes. The node named /ns/node1, which is a part of the
namespace ns, subscribes to the topic /topic2 and publishes the topic /ns/topic1. /topic2 is
published by the node /node2, which is not a part of a name space. /node2 subscribes to
the topic /ns/topic1.

Figure D.1: A simple ROS graph showing the sharing of information between two nodes.

The same visualization of namespaces, nodes and topics is used in the ROS graphs.

145
Appendix D. ROS Graphs

Figure D.2: ROS graph showing the system structure of the entire system on ReVolt.

146
 Appendix D ROS Graphs

Figure D.3: ROS graph showing the system structure of the necessary elements to control ReVolt in
dynamic positioning mode.

147
Appendix D. ROS Graphs

Figure D.4: ROS graph showing the system structure of the necessary elements to control ReVolt in
manual thrust allocation mode.

148
 Appendix D ROS Graphs

Figure D.5: ROS graph showing the system structure of the necessary elements to control ReVolt in
heading controller mode.

149
Appendix D. ROS Graphs

Figure D.6: ROS graph showing the system structure of the necessary elements to control ReVolt in
manual mode.

150
Appendix E
Relevant Output From WADAM
Simulations

Below is the relevant data from WADAM simulations of ReVolt’s hull. This is the raw data
used in the added mass matrix and the linear damping matrix. The values in the matrices
are dimensionless and the dimensionalizing factors are found in the top of the document.

151
 Appendix E. Relevant Output From WADAM Simulations

1 4 . 1 EXPLANATION OF THE RESULTS

2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3
4
5 NON−DIMENSIONAL DEFINITIONS :
6 −−−−−−−−−−−−−−−−−−−−−−−−−−−− I=1−3 I=1−3 I=4−6 I=4−6
7 J=1−3 J=4−6 J=1−3 J=4−6
8
9 ADDED MASS MATRIX NON−DIMENSIONALIZED BY: RO*VOL, RO*VOL* L RO*VOL* L * L
10 DAMPING MATRIX NON−DIMENSIONALIZED BY: RO*VOL*SQRT (G / L ) RO*VOL*SQRT (G* L ) RO*VOL* L *SQRT (G* L )
11
12
13
14 NON−DIMENSIONALIZING FACTORS :
15 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−
16
17 THE OUTPUT I S NON−DIMENSIONALIZED USING −
18
19 RO = DENSITY OF THE FLUID
20 G = ACCELERATION OF GRAVITY
21 L = CHARACTERISTIC LENGTH, AS GIVEN IN THE INPUT
22 VOL = DISPLACED VOLUME OF BODY 1 (COMBINED MORISON AND PANEL MODEL)
23 RO = 0 . 1 0 2 5 E+04
24 G = 0 . 9 8 0 7 E+01
25 VOL = 0 . 2 2 7 0 E+04
26 L = 0 . 6 0 0 0 E+03
27
28
29 INDICES :
30 −−−−−−−−
31
32 1 INDICATES SURGE AND X−COMPONENT OF FORCE
33 2 INDICATES SWAY AND Y−COMPONENT OF FORCE
34 3 INDICATES HEAVE AND Z−COMPONENT OF FORCE
35 4 INDICATES ROLL AND ROLL MOMENT
36 5 INDICATES PITCH AND PITCH MOMENT
37 6 INDICATES YAW AND YAW MOMENT
38
39
40 ADDED MASS MATRIX
41 −−−−−−−−−−−−−−−−−
42 1 2 3 4 5 6
43
44 1 2 . 5 2 5 3 E−02 0 . 0 0 0 0 E+00 4 . 3 7 1 4 E−02 0 . 0 0 0 0 E+00 3 . 0 5 2 0 E−02 0 . 0 0 0 0 E+00
45 2 0 . 0 0 0 0 E+00 1 . 8 0 1 6 E−01 0 . 0 0 0 0 E+00 −9.0145E−03 0 . 0 0 0 0 E+00 8 . 5 1 1 4 E−03
46 3 4 . 3 2 2 5 E−02 0 . 0 0 0 0 E+00 1 . 1 0 4 6 E+00 0 . 0 0 0 0 E+00 4 . 2 3 2 3 E−02 0 . 0 0 0 0 E+00
47 4 0 . 0 0 0 0 E+00 −9.0228E−03 0 . 0 0 0 0 E+00 7 . 3 7 1 6 E−04 0 . 0 0 0 0 E+00 6 . 2 7 2 6 E−04
48 5 3 . 0 5 5 0 E−02 0 . 0 0 0 0 E+00 4 . 2 9 7 9 E−02 0 . 0 0 0 0 E+00 5 . 0 9 9 5 E−02 0 . 0 0 0 0 E+00
49 6 0 . 0 0 0 0 E+00 8 . 5 3 6 7 E−03 0 . 0 0 0 0 E+00 6 . 2 6 3 3 E−04 0 . 0 0 0 0 E+00 9 . 9 4 0 8 E−03
50
51
52
53 TOTAL DAMPING MATRIX
54 −−−−−−−−−−−−−−−−−−−−
55 1 2 3 4 5 6
56
57 1 1 . 0 2 1 0 E−01 0 . 0 0 0 0 E+00 2 . 1 2 2 9 E−02 0 . 0 0 0 0 E+00 8 . 7 1 9 0 E−02 0 . 0 0 0 0 E+00
58 2 0 . 0 0 0 0 E+00 1 . 2 1 2 2 E+00 0 . 0 0 0 0 E+00 −4.4273E−02 0 . 0 0 0 0 E+00 5 . 5 7 9 3 E−02
59 3 1 . 9 3 1 5 E−02 0 . 0 0 0 0 E+00 1 . 3 3 8 0 E+00 0 . 0 0 0 0 E+00 1 . 1 5 0 8 E−01 0 . 0 0 0 0 E+00
60 4 0 . 0 0 0 0 E+00 −4.4312E−02 0 . 0 0 0 0 E+00 2 . 9 1 6 3 E−03 0 . 0 0 0 0 E+00 1 . 8 7 5 6 E−03
61 5 8 . 6 9 6 3 E−02 0 . 0 0 0 0 E+00 1 . 1 8 5 6 E−01 0 . 0 0 0 0 E+00 1 . 0 0 6 6 E−01 0 . 0 0 0 0 E+00
62 6 0 . 0 0 0 0 E+00 5 . 5 8 2 5 E−02 0 . 0 0 0 0 E+00 1 . 8 8 1 1 E−03 0 . 0 0 0 0 E+00 6 . 0 0 5 3 E−02

152
Appendix F
Instructions for Users of ReVolt

153
Institutt for teknisk kybernetikk, NTNU 20.05.2017

Instructions for users of ReVolt, ITK, NTNU

General
1. All users must read and use ReVolt in accordance with the contract between NTNU and DNVGL1
2. Only persons with permission from NTNUs contact person1, are allowed to access or use ReVolt
and its equipment.
3. The model ship ReVolt is DNVGLs property and is lent to NTNU for educational and research
purposes. Any other use must be approved by DNVGL.
4. Equipment and documentation that is taken out of ReVolt shall be used and stored in a secure
way such that unauthorized access is prevented.
5. Documentation of equipment and any source code shall be treated as classified unless it is clear
that it is open.

Familiarization of risks and equipment

6. All users shall be familiar with the risks of operating ReVolt (i.e. rotating equipment).
7. All users shall be familiar with the User Manual for ReVolt.

Before operation
8. Scope of work and plan for missions (objectives, location, resources, etc.) shall be documented
and used as a basis for risk assessment and risk mitigation.
9. Mission Risk Analysis of the operation with the ReVolt system has to be conducted. The external
factors (such as weather, boat traffic, population, and infrastructure) has to be taken into
account.
10. A full system check of hardware
1. Batteries.
2. Sensors.
3. Actuators.
4. Emergency Stop switch.

During operation
11. Life vests must be worn at all times while working close to and on the water.
12. Checklist for sea-launch
1. Inspect the hull for any damage, inside and outside. Check around the azimuth thrusters
for any damage.
2. Turn on the controller, with the throttle in the neutral position.
3. Turn on all the circuit breakers
4. Check that the system and actuators operate as expected.
5. Check that the front azimuth is in the up position.
6. Close all hatches.
7. Attach a guide rope.
8. Roll the trailer into the water, unhook the boat and pull the trailer back on land while still
keeping ReVolt safe.
9. Place the weights into the boat (Recommended for stability). Check for leaks.

1
UTLÅNSAVTALE – REVOLT MODELLBÅT v4

Rev. 1.3
Institutt for teknisk kybernetikk, NTNU 20.05.2017

10. Check again if the system operates as expected, before setting off.

13. Checklist for sea-recovery

1. Remove weights from the boat.
2. Ensure azimuth is retracted into the hull.
3. Roll the trailer fully into the water and guide revolt onto the trailer. Attach the hook and
pull the trailer with ReVolt out of the water.
4. End operations (logging, etc.) and turn off the circuit breakers.
5. Document any damage/water-intrusion.

After operation
14. ReVolt and its equipment must be thoroughly rinsed with fresh water after use to avoid
corrosion.
15. Reporting of incidents and accidents in NTNU’s HSE system, and other reporting as required.
16. Report any damage to your professor/project-manager.
17. Maintenance of ReVolt if needed.

Rev. 1.3