Autopilot Prototype

Autopilot Prototype
H E N R I K F L O R I N

Examensarbete
Stockholm, Sverige 2010

Autopilot Prototype

H E N R I K F L O R I N

Bachelors Thesis in Computer Science (15 ECTS credits)
at the School of Computer Science and Engineering
Royal Institute of Technology year 2010
Supervisor at CSC was Patric Jenfelt
Examiner was Stefan Arnborg

TRITA-CSC-E 2010:181
ISRN-KTH/CSC/E--10/181--SE
ISSN-1653-5715

Royal Institute of Technology
School of Computer Science and Communication

KTH CSC
SE-100 44 Stockholm, Sweden

URL: www.kth.se/csc

Abstract
Autopilot prototype
The main goal of this project is to get a better understanding of how an autopilot for a recreational boat is created
and how it could be developed further. More specifically the project aims at answering two questions,
1. Can a basic autopilot be created with a standard eight-bit microcontroller?
2. How can the autopilot that is created during the project be further developed?
The autopilot was created by using an Arduino Mega board together with a H-bridge, a rudder feedback unit and
a solid-state digital compass. The software was created using C++.
The design of the software was centred around two controllers, one taking in the current and desired heading and
outputting the desired rudder position while the other handled the actual rudder positioning. The first controller
was created using a P-controller while the other used a simpler approach. The software also included means of
altering the overall sensitivity of the autopilot and a user interface containing an LCD display and four buttons.
The project concluded that a basic autopilot could be created using the specified hardware and methods
described in detail in this document. An important fact that led to the chosen design was that it made the
autopilot robust and independent of the design and behaviour of the boat.
Further development of the autopilot can be done by for example using a larger full colour display, adding
support for GPS signals, removing the need for the rudder feedback unit and adding auto-tuning capabilities.

Prototyp av autopilot
Det huvudsakliga mlet med detta projekt r att f en bttre frstelse fr hur en autopilot fr en fritidsbtgare
skapas och hur den kan utvecklas vidare. Mer specifikt mnar projektet till att besvara tv frgor,
1. Kan en grundlggande autopilot skapas med en standard tta bitars processor?
2. Hur kan autopiloten som skapas under projektet utvecklas ytterligare?
Autopiloten skapades med hjlp av ett Arduino Mega kort tillsammans med en H-brygga, en rodergivare samt en
solid-state digitalkompass. Programvaran skapades i C++.
Utformningen av programvaran var centrerad kring tv regulatorer, en tog in den aktuella och nskade kursen
och gav ifrn sig en nskad roderposition medan den andra sktte sjlva roderpositioneringen. Den frsta
regulatorn skapades med hjlp av en P-regulator medan den andra anvnds enklare metoder. Programvaran
inkluderade ven funktionalitet fr att frndra den totala knsligheten av autopilot och ett anvndargrnssnitt
innehllandes en LCD-display och fyra knappar.
Projektet kom fram till att en grundlggande autopilot skulle kunna skapas med den angivna hrdvaran och
metoder som beskrivs i detalj i detta dokument. Ett viktigt faktum som ledde till den valda konstruktionen var att
det gjorde autopiloten mer robust och oberoende av design och beteende av bten.
Vidareutveckling av autopilot kan gras genom att t.ex. anvnda en strre frgskrm, lgga till std fr GPS-
signaler, ta bort behovet av roder givaren samt att ge autopiloten mjlighet att stlla in sina parametrar
automatiskt.

Tableofcontents
1Introduction...................................................................................................................................1
1.1Background................................................................................................................................................................ 1
1.1.1FlotecMarinAB................................................................................................................................................ 1
1.2.Purposeandscope................................................................................................................................................. 1
1.3Delimitations............................................................................................................................................................. 2
1.4Definitions,acronymsandabbreviations..................................................................................................... 3
1.5Literatureoverview................................................................................................................................................ 3
1.6Overviewofthedocument .................................................................................................................................. 4
2Method.............................................................................................................................................5
2.1Planning....................................................................................................................................................................... 5
2.2Production.................................................................................................................................................................. 5
2.3EvaluationphaseandPresentation................................................................................................................. 5
3Theory..............................................................................................................................................6
3.1Automaticcontrolengineering.......................................................................................................................... 6
3.1.1PIDcontroller.................................................................................................................................................... 7
3.2Motorcontrol ............................................................................................................................................................ 8
3.3TheNMEA0183protocol .................................................................................................................................... 9
4Design............................................................................................................................................ 10
4.1Autopilotfunctionality....................................................................................................................................... 10
4.2Software.................................................................................................................................................................... 11
5Implementation......................................................................................................................... 12
5.1Hardware ................................................................................................................................................................. 12
5.1.1Wireconnection............................................................................................................................................ 13
5.2Software.................................................................................................................................................................... 14
5.2.1Headingcontroller....................................................................................................................................... 14
5.2.2Ruddercontrollers....................................................................................................................................... 16
5.2.3Headingdata................................................................................................................................................... 17
5.2.4Userinterface................................................................................................................................................. 18
5.3Tuning ....................................................................................................................................................................... 19
6Conclusionanddiscussion..................................................................................................... 21
Sourcereference........................................................................................................................... 23
AppendixA-Timeplan .............................................................................................................. 24
AppendixBCompleteclassdiagram................................................................................... 26

Autopilot prototype - Bachelors degree
Henrik Florin
1
1 Introduction
1.1Background
The use of autonomous systems has constantly been growing both in industries and in the every day life. This
type of technology is today used in everything between a childrens toy to the industrial robot that creates them.
The main goal of an autonomous system is to relieve the need of constant human intervention, meaning that the
system should be able to manage its task on its own without constant human interaction. When it comes to a
childs toy this could be the task of moving around a room without hitting the walls while an industrial robot
may have to assemble a certain product without doing any errors or hitting other equipment situated nearby. In
general autonomous systems exists in many shapes and forms but their use have become a must in the society.
Within the marine industry autonomous systems are used both to produce equipment and to monitor them. One
example is to produce and monitor steering equipment for boats. There is a distinct difference between
mechanization and automation. A steering system for a boat will help the user to steer the boat by relieving some
of the muscular requirements of steering the boat (mechanization). On the other hand an autonomous system,
like an autopilot, would steer the boat in a predetermined direction or even to a predetermined location.
When it comes to autopilots created for use in the marine business then the bare minimum of what it should be
able to do is to steer the boat in question in a predetermined direction. This is often done be using sensors like
compasses, GPS-units and rudder feedback units. If an autopilot can accomplish this task then technically it
could be sold and used in a smaller boat. Most autopilots today provide the user with more functionality than just
steering towards a predetermined direction. A small list can be seen below.
The user can manually steer the rudder / motor of the boat using the autopilots interface.
The user can connect a GPS and steer towards a specific position.
The user can connect a plotter providing the user with a graphical representation of the sea chart and
steer through a list of predetermined points on that map.
Todays autopilots have the capability of performing the above-mentioned tasks but lack the reliability of doing
so. An autopilot could fail at some point and when it comes to risking human life then most would agree that
some monitoring of the system would be best. In other words, todays autopilots can perform the task of steering
a boat but can in general not be left solely responsible for this task. It is therefore mostly used as an aid to the
captain of the boat and not to replace him or her completely.
Autopilots are also in constant development and new features are created. One of the most resent developments
is that many autopilots are considering taking away the rudder feedback unit for smaller boats. This is a feature
that can be seen in newer autopilots. Other functionality that is sometimes included in the autopilot is
information of wind in order to construct specific functionality for sailboats.
1.1.1FlotecMarinAB
Flotec Marin is small Swedish company that specializes in hydraulic steering systems and autopilots for both
private smaller boats as well as bigger commercial ships. The company is the main distributer of several brands
of hydraulic steering and autopilot in the Nordic region and is constantly striving towards improving their
products in collaboration with manufacturers. As the main distributor of their product the company has a vital
part in the further development of their products.
Their customers today consists mainly of private people and companies working with recreational boats. The
store is located at Sdermalm in Stockholm and the company has three employees.
1.2.Purposeandscope
The main goal of this project is to get a better understanding of how an autopilot for a recreational boat is created
and how it could be developed further.
More specifically a prototype of an autopilot with at least the minimum requirement mentioned in section 1.3
will be created during the project. The system will be tested both in a lab environment and in real life, if
possible, and ideas for further development will be discussed.

Henrik Florin
2
There are two main questions that should be answered during the project:
1. Can a basic autopilot be created with a standard eight-bit microcontroller?
2. How can the autopilot that is created during the project be further developed?
1.3Delimitations
The limits of the project will mainly be centred on the hardware that will be available and the time limits of the
project. A more detailed description of the projects goal can be found here.
1. Creating a functional prototype of an autopilot for recreational boats.
The autopilot should be able to take in information from a NMEA compass and parse out
information of the current heading.
The autopilot should be able to take in information from a rudder feedback unit regarding the
position of the motor / rudder and interpret it in a correct way.
The autopilot should be able to set the motor / rudder in a specific angle within some error
margin.
The autopilot should be able to make the boat steer in a predetermined direction within some
error margin.
The autopilot should have some sort of interface towards the end user letting the user control
the autopilot.
2. Testing of the autopilot.
Each item in part 1 must be tested separately in the lab as much as possible.
The system will be tested as a whole in the lab.
If possible then the prototype will be tested in a real world environment, meaning a real boat.
3. Discussion of further development.
After the test phase of the project then further development of autopilots will be discussed.
This will lead to some conclusions regarding what would be the best course of action in further
development.
Table 1 lists the main hardware that was chosen during the implementation of the system.
Table 1: Hardware that is used to construct the autopilot.
Name Amount
Approximate
price (kr / item)
Description
Arduino
MEGA
1 520
Arduino is an organisation that strives to make hardware
and software that makes it easier to construct an embedded
system. It has a large community of people that helps and
share their knowledge and achievements. The Arduino
MEGA is their largest microcontroller chip. More
information can be found at
http://arduino.cc/en/Main/ArduinoBoardMega.
Simple H 1 590
H-bridge constructed by the American company Robot
Power. The product is designed to be able to withstand a
current up to 20 A.
ECS1 1 1 550
An NMEA based compass constructed by Elproma
Instruments in Holland. The compass is said to send the
data sentences needed in the project at a adequate rate (from
once every second to ten times per second depending on the
type).
LCD 4 *
20
1 150
An LCD that has 4 rows and 20 columns giving it a total of
4 * 20 = 80 characters that can be displayed at ones.
R1396W
button
4 27 A push button with embedded white light.
ML-40+ 1 10 000 Hydraulic steering unit including hydraulic pump.
Remaining
hardware
1 400
Includes all connections (wires and brackets), screws, lead
etc.
Henrik Florin
3
1.4Definitions,acronymsandabbreviations
Table 2 provides definitions, acronyms and abbreviations that are used in this report.
Table 2: Definitions, acronyms and abbreviation used in this report.
NMEA 0183
NMEA stands for the National Marine Electronics Association, which is an
organisation that strives towards a standard for all marine electronic
communication. The NMEA 0183 is one of its standards for serial
communication in a marine environment. This will be further described in
chapter 4.
PID
A controller that strives to keep a measurement at a given value by
manipulating some output. Further discussed in chapter 4.
ASCII
A standardized way of encoding characters in binary form. For example the
character a is 0110 0001 in binary code.
RS-232 Is an electrical standard for a serial databus.
Baud rate
The rate at which signals are sent from a sender to a receiver. One baud
represents that one signal element is sent per second.
Stop bit
In serial communication one byte is sent at a time. This means that 8 bits are
sent after each other to form one byte (character). One can chose to add one or
several stop bits after each byte that is sent in order to separate the bytes.
Parity
A character takes up 7 bits of an byte when sent through serial
communication. The last bit can act as a parity bit adding a 1 or a 0 to the
byte. This is done to ensure that the number of ones or zeros always is odd or
even. This fact can later on be used to perform simple error detecting.
Handshaking
Can be done before the communication of two devises. The rules at which the
communication will be performed are then agreed upon.

1.5Literatureoverview
Most facts are either taken from organisations operating in this field or academic literature. For example the
references to the PID controller are all taken from the academic world while when talking about motor control
most facts are taken from organisations and resources that take a more practical approach in describing the
methods.
Since the NMEA protocol is not open the author chose to take in several references to all data that was used and
comparing them to the actual behaviour of the NMEA compass that was used. This was mainly done in order to
save cost and time but also to construct the autopilot to foremost work with the NMEA compass that was
chosen.
Henrik Florin
4
Below is a short description of the literature that was used during this project.
Table 3: Short description of the reference used in the document.
Bennett Peter, 2008, The NMEA
FAQ Version 6.6
Gives information about the NMEA-0183 protocol and its
sentences.
Barr Michael, 2001, "Pulse Width
Modulation"
Article published by Netrino and other organisations aimed
at spreading information about embedded systems. This
article handles information about pulse width modulation.
Cooper Douglas J., 2008,
Practical Process Control, Proven
Methods and Best Practices for
Automatic PID Control
Douglas J. Cooper is a Professor at the University of
Connecticut. This is one of his books published on the
internet handling PID controllers. The book takes a more
practical approach with more information on setting up a
PID controller and tuning it.
Elproma, 2010a, Electric
compass sensor ECS1
Elproma is a company selling solid-state digital compass
among other things. The information found here is mainly
used in order to understand how the compass sends out its
signals.
Elproma, 2010b, Compass
inverter
Information gained from direct contact with the company.
Engineering Knowledge, 2007,
DC Motor Control and
Interfacing
An organisation aimed at spreading the knowledge of how to
work with embedded systems and more. This article handles
the basics about how to handle DC motors with PWM.
Flotec Marin AB, 2010,
AP47/AP47R Autopilot
Information of how one of the autopilots sold by Flotec
Marin AB (job initiator) works. Pictures from this reference
have been used in this report. The autopilot is manufactured
by TMQ.
Glad Torkel, 2007, Reglerteknik,
grundlggande teori
Student literature teaching the basics of automated control.
Much of the book handles PID controllers and takes a more
theoretical and mathematical approach.
National Marine Electronics
Association, 2008, NMEA 0183
Standard
Organisations responsible for the maintenance of the NMEA
protocols.
TMQ, 2009, AP46Pulsing
TMQ is a manufacturer of autopilots situated in Australia.
This documentation gives information of their way to handle
the PWM pulsing to the motor controlling the rudder
position. The information is gained through direct contact
with the company.
Raymond Eric S., 2010, NMEA
Revealed
Gives information about the NMEA-0183 protocol and its
sentences.

1.6Overviewofthedocument
The document starts by describing the workflow that was used during the project. The document continues by
describing the theory behind the autopilot (chapter 3 to 5) after which it starts describing the actual behaviour of
the autopilot. Chapter 7 describes the methods at with the functionalities and behaviours of the autopilot was
created ending with a description of the tuning of the system. The report ends with the conclusions drawn after
the project.
Further information on the time-plan and a full class diagram can be found in Appendix A and B respectively.
Henrik Florin
5
2 Method
The project contains several sub goals that need to be met in order to complete it. The handling of these sub
goals or phases of the project are illustrated and described in figure 1.

Figure 1: Graphical illustration of the workflow within the project.
2.1Planning
This phase contains all the work of gathering information and plan for the rest of the project. The information
gathered here would mainly be information of the hardware and software that will be used during the project and
focus will be put on getting all the information needed to start the next phases. The end result of this phase will
be the project plan containing a detailed plan for the rest of the time.
2.2Production
The production phase contains four sub phases that are repeated until all the goals of the project are met. During
the time of the project the prototype can be seen as a working progress with constant need of upgrading and
testing. This is what the Production phase is for.
Table 4: The different phases in the project are explained.
Hardware phase
This phase contains all the mounting, soldering, wiring and ordering of
hardware that is needed to complete the project. Technical information of
the hardware used should also be gathered here.
Software phase
The software phase contains the creation of the software needed to control
the hardware used for the prototype. Each part of the prototype will need a
corresponding software library that controls it. These libraries together
with some automatic control will in the end build up the actual autopilot.
Testing phase
Each part of the prototype will be tested individually and as a whole in
order to see how well they perform the tasks that they are created for.
Testing data will both be used for fine-tuning each parameter in the
autopilot and as a base for discussion in the next phase.
Theory phase
The theoretical phase contains a more in depth exploration of the subject
focusing on finding literature and papers relevant to the project.
2.3EvaluationphaseandPresentation
During the previous phases and after the prototype has been built the analytical phase will start. This phase
contains an analysis of individual parts as well as the system as a whole and will support the conclusions drawn
during the project.
In the end of the project a presentation phase containing both oral and written presentation of the work done will
be concluded.
Planning Reporting Production Hardware
Software
Testing
Theory
Henrik Florin
6
3 Theory
This chapter describes the theory which the implementation is formed around. There are three main sections in
this chapter. The first talks about automatic control engineering and is focused on PID controllers. PID
controllers are commonly used within the industry to steer and control equipment. The naval industry is no
exception. A PID controller will be implemented in order to steer the boat in the desired direction.
The second section goes into pulse width modulation. In order to steer the boat one needs some way of
controlling the motor that pushes the rudder back and forth. One could either accomplish this by using
specifically designed hardware for this task or one could use pulse width modulation and the digital ports already
found on the processor board. The later solution is both cheaper and easier.
The last section of the chapter describes the NMEA 0183 protocol, which is used by the compass used for the
autopilot. NMEA is a standard within the naval industry that most, if not all, electrical devises uses for
communication purposes. The section concentrates on describing the three sentences within the NMEA 0183
protocol used by the particular compass used for the autopilot. The implementation of the autopilot needs to be
able to parse out the current heading from these three sentences.
3.1Automaticcontrolengineering
Within the practice of automatic control engineering one often uses a controller in order to monitor and affect the
operational conditions of a dynamic system. A normal controller has at least an input value and an output value.
The input value can be seen as the information that the regulator gets at each step and the output can be seen as
the reaction that the regulator calculates after getting that input. Normally one separates controllers into one of
two groups. The first group of controllers aim at following the input value by regulating the output. In this case
the input is constantly moving. The other group of controllers, and the type of controller that will be used in this
project, aims at maintaining a desired value. The desired value (setpoint) is given to the controller together with
the current value (input) and the output is the calculated response.
A classic example of a system using a controller is a normal thermostat in a house that regulates the heating
system of the house in order to regulate the temperature. In this system the thermostat is the actual controller,
which takes a temperature reading as an input and outputs the needed response from the houses heating system.
The setpoint is then the desired temperature in the house. At each point in time the controller can come across
one of three scenarios,
The temperature in the house is to low. The controller signals the heating system of the house to warm
up the air in the house more. The actual increase in power that the heating system uses is calculated
by the controller and depends on how far the actual temperature is from the wanted temperature.
The temperature of the house is too high. The controller signals the heating system of the house to
produce less heat or to turn off depending of how the system works. The actual decrease in heat
produced is calculated in the same way as when the house temperature was too low.
The temperature is at the right level and the controller gives the heating system the same command as
before. This means that no change in the output of the heating system is needed.
This means that the rate at which the temperature in the house is changed is dependent on the difference between
the current and the wanted temperature in the house. If the difference is high then the controller will increase or
decrease the temperature fast and vice verse.
Henrik Florin
7
An illustration of the system can be seen below.

Figure 2: Illustration of the flow of information to and from a radiator
controlling the temperature inside a house.
This is the basic concept of a controller that in theory does not seam to be that complicated. The challenge comes
when trying to fit a controller into a dynamic system. A dynamic system is a system that acts differently
dependent on its settings and the surrounding environment. The thermostat may need to order the heating system
to produce more heat if the surrounding air is moist then if it was dry to reach the same temperature for example.
The heating system might also need more energy to heat the house one degree if the current temperature is at 25
instead of 20 degrees Celsius. This fact puts additional demands on how the controller performs its calculations.
The controlled system can either be closed or open looped. In a closed loop system the input depends on the
output signal. In the case of a thermostat the input depends on the output in the way that the temperature in the
house is dependent on the output of the heating system. In this type of system one needs less understanding of
the systems dynamic behaviour. In the meaning of the thermostat then one only needs to know that the house
will get hotter if we give a higher output to the heating system and colder if the output is lower. An open system
on the other hand is more dependent on the controller having a good understanding on dynamic behaviour.
Many different solutions exist to this problem but one of the far most commonly used in the industry today is the
PID controller. (Cooper Douglas J., 2008)
3.1.1PIDcontroller
All reference to setpoint, input- and output-values will in this section refer back to the installation shown in
figure 3. The PID controller calculates the error in each time step by taking the input value minus the setpoint
value. The error is then used in three separate sections that are then combined to form the actual output. Each
section takes different aspect of the systems behaviour into account. The output is a weighted sum of the
individual terms. In other words, the weights control how much the output is dependent on the specific
behaviour that the respective terms take into account. The different terms are listed in table 5. (Glad Torkel,
2007)
Table 5: Description of the three parts of a PID controller (Glad
Torkel, 2007).
Section Name Description
P Proportional
The proportional part takes the error and calculates a proportional
output. The growth in the output is both proportional and linear to the
error in the input.
I Integral
The integral part of the controller is proportional to the integral of the
error. The integral will be growing as long as the error is positive and
diminish when the error is negative.
D Derivative
The derivative part takes the current direction of the error into
account. Its output depends on if the current error is growing or
diminishing.
The mathematical formula that is used to calculate the output differs between implementation but the one that
will be used in this project can be seen below.
Input
temperature
power to heating
system
Output
Setpoint
Desired
temperature
Henrik Florin
8

Output = K
p
e(t) +K
i
e()d
0
t
+K
d
d
dt
e(t)

K
p
, K
i
and K
d
is the constant mentioned earlier.
One can choose to reject one or two parts of the PID controller by setting their constants to zero. A common
approach is to start with a simple P-controller and then gradually adding the two other parts if needed. Table 6
describes the main pros and cons of some forms of the PID controller.
Table 6: Pros and cons of different PID constellations (Cooper
Douglas J., 2008).
PID Pros Cons
P
A simple controller to implement that
gives a direct response given an error.
May not be able to remove the error. This
is the case for example, in systems where
one needs a non-zero control signal to stay
at the setpoint value. The system is said to
have an offset from the setpoint.
PI
The integral part of the controller can
eliminate the offset of the simple P
controller.
A high integral part tends to over shoot the
setpoint and oscillate.
PID
The derivative part of the PID controller
can compensate for the oscillation of the
PI controller and thereby give a smother
and faster convergence to the setpoint.
The more constants that need to be tuned,
the harder tuning becomes. Tuning the
constants in a PID controller can be hard.
3.2Motorcontrol
A motor controller is a system that controls the speed or position of a motor. A common type of motor that is
being controlled is a normal DC motor. This type of motor is controlled both by the voltage and the current
given to it. The voltage taken in by the DC motor is an analogue signal dictating how fast it should go while the
current controls the torque of the motor. A normal constellation is to connect the DC motor to a H-bridge that is
steered by the system, for example an Arduino board. In that way the motor is draining power directly from the
power supply and can be controlled by the output from the circuit board. The speed is then controlled by the
output and the torque is limited by the maximum current out from the power supply. (Engineering Knowledge,
2007)
The analogue input of voltage posses a problem when using a digital output on a circuit board to control the
motor. A digital output can only output either high (normally 5 V or 3.3 V) or low (0 V). One therefore needs
some way to translate the digital output from a circuit board to an analogue signal to the motor. One way of
solving this problem is to use pulse width modulation (PWM). This method sends out a digital signal to the DC
motor in the form of a squared wave, meaning that the signal is high for a short time and then low for a short
time. One cycle is seen from the time that the signal is high to the time it is low. The cycle is repeated at a
certain frequency. If the frequency is high enough then the motor will not have adequate time to react to the
changes in voltage and will see an analogue input having the average voltage of the signal. Controlling the
amount of time that the signal is high respectively low, often called duty cycle, can then control the voltage seen
by the motor. Figure 3 shows three different wave signals (pwm signals) that would give the motor three
different voltages.
Proportional Integral Derivative
Henrik Florin
9

Figure 3: Three different PWM signals that would give the motor a
voltage of 10 %, 50 % and 90 % of the digital high voltage (Barr
Michael, 2001).
If the high signal of the digital output were 5 V then the voltage seen by the motor when using the three
examples above would be 0.5 V, 2.5 V and 4.5 V respectively. (Barr Michael, 2001 and Engineering
Knowledge, 2007)
3.3TheNMEA0183protocol
The National Marine Electronics Association is an organisation that is responsible for maintaining several
communication protocols that are used in marine environments. One of these protocols is the NMEA 0183
protocol, which describes how one sender can communicate with one or several listeners through serial
communication. The protocol contains many different sentences that are sent as printable ASCII characters
through a RS-232 electrical interface. The signals through the serial communication are sent with the following
settings.
Table 7: Electrical interface used by the NMEA 0183 protocol
(National Marine Electronics Association, 2008).
Baud rate 4800
Number of data bits 8
Stop bits 1
Parity None
Handshake None

An important aspect of the NMEA 0183 protocol is that it is a one-way communication. This means that if two
units are to communicate with each other, sending and receiving information, then the electrical interface used
for the communication has to be doubled. Meaning that each unit has to have one electrical interface for
receiving information and one for sending it. (National Marine Electronics Association, 2008)
The NMEA 0183 protocol is not an open source document, however much of its sentences has been reverse
engineered and can be found on the Internet. Below is a selection of the three sentences that will be used during
this project. The sentences are taken from (Institute of Computer Science Poznan University of Technology,
2001). In order to make sure that the sentences are correct they are cross-referenced with several other sources.
Two of these sources are (Bennett Peter, 2008) and (Raymond Eric S., 2010).
Henrik Florin
10

Figure 4: Figure describing the three NEMA 0183 sentences that will be
used in the project (Institute of Computer Science Poznan University of
Technology, 2001).
As can be seen above, each sentence ends with two ASCII characters representing a checksum. This checksum is
calculated by doing a bit-by-bit XOR calculation of all the characters between $ and *. The checksum is used
in order to eliminate faults in the sentence due to communication errors or disturbances.
In addition to the characters for each sentence that can be seen in figure 2 all sentences all end with a clear
character (<CR>) and a line-feed character (<LF>) in ASCII code.
4 Design
4.1Autopilotfunctionality
Most autopilots today have two main modes, manual and auto. The TMQ AP46 autopilot sold by Flotec Marin
AB is an example of this and inspiration has been taken from this autopilot when designing the prototype. The
prototype of the autopilot will therefore also be designed with these two main modes.
Each of the main modes has a specific set of functionalities attached to it. The user is able to toggle between the
two modes by pushing the AUTO button. Regardless of which mode the autopilot is in the user always has
access to the settings by pressing the MODE button. The settings menu can therefore be seen as a submenu that
is easily accessed by pushing the MODE button. When the autopilot is first turned on it is entered in manual
mode and the autopilot does not correct the course in any way. The user is able to manually steer the rudder by
pushing one of two arrow keys.
The second mode that the autopilot can enter is the auto mode. When first entered in this mode the autopilot
takes the current heading as the wanted heading and starts correcting the course in order to maintain that course.
The user can correct the course by pushing the arrow keys. Each push changes the wanted course by one degree.
The user can also change the rudder ratio and the overall sensitivity of the autopilot by pushing down on the
MODE button. A number between 1 and 10 represents the rudder ratio and a higher number gives a larger rudder
angle for a given error in course. The overall sensitivity is a number between 0 and 20 which in turn represent
the amount of degrees off course that is acceptable. The autopilot will not correct the course if the error in the
course in under the set overall sensitivity. A rough diagram of the autopilots functionalities can be seen in figure
5.
Henrik Florin
11

Figure 5: State machine diagram of the autopilot.
4.2Software
The software that was developed is centred on two cascaded controllers. The first controller takes in the desired
and current heading and outputs a response for the rudder. The second controller takes in the outputted response
from the first controller and the current position of the rudder from the rudder feedback unit and outputs an
action for the motor. The action could be to move or stop the rudder. The second controller also has to regulate
the speed of the moving rudder. See picture 6.

Figure 6: Illustration of the two cascading controllers that the autopilot
is centred around.

Henrik Florin
12
5 Implementation
5.1Hardware
The hardware used in the project was chosen to match the functional requirements of the autopilot. Below is a
list of the hardware and why they were chosen.
Table 8: Reason why the hardware used in the project was chosen.
Hardware Reason for choice
Arduino MEGA
The Arduino Mega was chosen for its serial, digital and analogue
input capabilities. It has the capability to send and receive serial
data through one of three serial ports. Each serial port has a buffer
attached to it and the receiving of data is handled in hardware by
continually writing data to the buffer. The handling of receiving
data from the compass does not have to be handled in software.

The analogue port is used for input from the rudder feedback unit
and the digital outputs are used for handling buttons, lamps, LCD
output and does also have the ability to output pwm signals to steer
the H bridge. The Arduino Mega has extra digital ports in contrast
to other Arduino boards which was needed in order to connect all
other parts.

The Arduino itself was chosen for its easy to use libraries and its
rich online community.
Simple H
The H bridge has a maximum load of 20 A that can be raised to 25
A with a cooling fan. This is adequate for driving the ML-40+.
ECS1
The compass that was chosen has the ability to send out the heading
signal ten times per second, which is a common requirement for
many other autopilots. The compass is a solid-state digital compass
containing rate gyros, which compensates the output for pitch and
roll. This means that the outputted heading is less prune to errors
from pitch and roll.
LCD 4 * 20
The display that was used was a compromise between using a real
coloured graphical display and simpler 7 segment led displays. The
7 segment led displays was found to be able to show too little
information at a time and the fully graphical display was though to
take up too much time during development. The 4 * 20 character
LCD display was thought to have adequate room to show the
information that the user needed in order to use the autopilot.
R1396W button
The buttons was chosen for their ease of mounting and integrated
light.
ML-40+
(drive unit)
The ML-40+ is one of the products that is sold by Flotec Marin AB
and has the advantage of having both a hydraulic cylinder and
motor in one unit. This means that working with oils was not
necessary during the project.
Rudder feedback
unit (RFU)
The rudder feedback unit is the piece of hardware that sends
information on the current rudder position to the system. The unit is
physically connected to the ML-40+ and sends the information
throw an analog signal (between 0 and 5 V).

All hardware except for the ML-40+ was mounted on a board made of acrylic glass. As much as possible of the
wires were mounted on the back and put through holes in the board to be attached to the hardware. The board
was also given four legs in order to give it some height from the table. This minimized the risk of accidental
short- circuits in the system. Connections to the compass and the 12 V current from the power supply was also
mounted on the top of the board for convenience.
Henrik Florin
13

Figure 7: Picture of the autopilot on the acrylic glass.
5.1.1Wireconnection

Figure 8: Wiring scheme for the autopilot.
The H-bridge (motor controller) that controls the rudder needs two separate pwm outputs in order to work, one
to drive the rudder to the right and one to the left. The pwm outputs may not send a driving signal to both wires
at the same time, meaning that if the motor drives the rudder to the left the wire controlling if the motor drives to
the right must be set to output 0 and vice verse.

Henrik Florin
14
5.2Software
The software was developed in C++ which is an object oriented programming language. Each part of the system,
for example the two controllers described in chapter 6, was therefore constructed as a class or library. A
complete class diagram of the system can be seen in figure 8. The PID and the Rudderhandler classes represent
the heading controller and the rudder controller. All settings of the autopilot and information of current status are
stored within the Settings class. A more detailed class diagram can be found in Appendix A.

Figure 9: Class diagram of the system.
All Arduino based programmes have a main loop that the Arduino board goes runs over and over until the power
is turned off. Most libraries in the autopilot have an update function that is called once every time the Arduino
board goes over this loop. This function makes the necessary updates and changes that the specific class is made
for.
5.2.1Headingcontroller
The heading controller is a PID controller described in section 4.1. The PID controller takes the current heading
as the Input and the desired heading as the Setpoint. A desired rudder position is then calculated and outputted.
Since the NMEA compass outputs a new heading ten times per second then the PID controller should also follow
this frequency in its calculations. A timer interrupt is used in order for the system to call the PID controller to
calculate a new value at 10 Hz. The timer interrupt that is used on the Arduino board is the TimerThree that can
be found on the Arduino Playground at <http://www.arduino.cc/playground/Code/Timer1> (20 August 2010).
This library has the functionality to set up a timer interrupt that takes affect at regular intervals. In practice the
library has a flaw that results in the user having to test his or her way through its parameters in order to reach the
desired frequency. This is due to the fact that the library itself does not take into account the time it takes to call
the interrupt function and return to the original position in the program. The library does also not take into
account the time taken by the function inside the interrupt. This means that the user has to calibrate the librarys
parameters in order to reach the desired frequency but when this is done the interrupts will occur at adequate
regular intervals. The error at whish the interrupts were fired when using 100 ms intervals were found to have an
error of +/- 2.5 ms.
Henrik Florin
15
The PID controller that is used is made by Brett Beauregard and can be found on the Arduino Playground at
<http://www.arduino.cc/playground/Code/PIDLibrary> (20 August 2010). A front-end for the PID regulator
showing the Input, Setpoint and the Output at each time step was also used for tuning the system.
The integral and derivative parts of the PID controller have to be approximated from the data that is collected
(sampled). For the integral part, simply adding the current error value to the former ones does this. Hence, the
integral part is very dependent on the time at which the data is sampled and the errors are calculated. If the data
is sampling at even time intervals then the error in the integral calculations will be small while if the sampling is
done at sporadic time intervals then the integral part will have a lot of error in it. The same goes for the
derivative part of the PID controller. In other words the accuracy of the approximations to the integral and
derivative parts of the PID controller are highly dependent on the time interval at which one samples the data.
This dependency for the integral part is illustrated in figure 10.

Figure 10: Illustrates why the integral part of the PID controller is
dependent on even time intervals. The black line illustrates the error of
the Input. Blue triangles illustrate a system with even time intervals
and red dots illustrate a system with sporadic time intervals. Dotted
lines are the calculated integral parts for the two different systems.
The values in the graph are fictive and only intended for explanatory
purposes.
The difference between the two systems in figure 10 is clear which means that the special care taken to ensure
even calls to the PID controller is defendable.
The error that is calculated by the PID controller represent how far the current heading is from the wanted
heading. The output from the PID controller can be seen as the action that the boat should take in order to get
closer to the wanted heading. Both the wanted heading and the current heading are represented by a value
between 0 and 359.9 in degrees. Special attention needs to be taken when the closest way to the desired heading
is to go from the maximum to the minimum heading that is when going from 359.9 to 0 degrees. For example, if
one has a wanted heading of 10 degrees and the current heading is 300 degrees then one wants the PID controller
to calculate an error of 70 degrees and not of 290 degrees. Both error calculations would result in a correction of
the boat that would eventually lead to a correct heading but the later result would result in the boat making a
unnecessarily large turn possibly resulting in a side trip. This is not a desired action and special care is taken to
ensure that this does not happen.
Henrik Florin
16
The PID controller that is being used is also dependent on the current setting of the overall sensitivity. If the
sensitivity is set to something over 0 then all errors under the set sensitivity calculated by the heading controller
will be set to zero. A good example is when the boat is travelling in wavy waters constantly going up and down.
The course of the boat will then constantly change around one value. Say that the boats course will increase 5
degrees when going up on a wave and decrease with 5 degrees when going down. In a situation like this it is not
desirable to correct the course for an error that is less than 5 degrees since the error will correct itself. The
overall sensitivity of the autopilot can be seen as an excepted error in course and is illustrated in figure 11. In the
figure a larger distance from the centre means a larger heading error. One can think of this as if the boat is
constantly going further and further to the sides until the autopilot corrects its course. The correction will take
place at the lines and until then the boat will have an increasing heading error.

Figure 11: Overall sensitivity. Higher sensitivity (lower value in the
settings) will give the behaviour at the top of the image making the
autopilot correct the course of the boat for smaller errors and therefore
more frequently (Flotec Marin AB, 2010).
5.2.2Ruddercontrollers
Initially two PID controllers were used, one for the heading and one for the rudder. The problem with this
approach is that the second PID controller would output a value corresponding to the direction and speed that the
rudder should be driven to. In an Arduino platform this speed is normally a number somewhere between 0 and
255. At high speeds the motor controlling the rudder will work fine and drive the rudder in the direction decided
by the second PID. However, the motor has a limit on how slow it can drive the rudder back and forth. Values or
rather pwm frequencies below that limit will cause the motor to stand still. This means that if one only use a P-
regulator then one would get an offset as described in section 4.1. This can be handled by using an integral and a
derivative part in the PID. However the outcome of testing such a system has shown that it is hard to reach
adequate congregational speeds through tuning the PID controllers constant. Speculations has also existed that
such a system would be much more dependent on the physical aspects of the boat, meaning that the constants of
the PID controller will depend much on for example the inertia of the rudder and the boats behaviour at sea.
Instead of using two PID controllers one PID controller was used for the heading data and a simpler rudder
controller was used. The rudder controller is called ones every loop of the program. Each time it is called upon it
will decide what to do with the rudder. The rudder controller can come upon the following situations.
The rudder is at its desired position within a margin of error (deadband) and the movement of the
rudder is stopped.
The rudder is far from the desired position and the rudder is moved towards the goal position at full
speed.
The rudder is close to the desired position and the rudder is moved towards the goal position in half
speed marked as pulsing drive in figure 8.
The rudder is also checked for the following situations at all times. These situations have higher priority then the
ones described above and if any conflicts between the two arise then the response described below will be in
affect.
If the rudder is at one of its physical limits then it will be stopped from moving any further.
If the rudder movement is changed from one direction to the other then a brief stop is made before the
change. This is done in order to let the hydraulic motor in the ML-40+ to settle before changing in
direction.
All the situations described in this chapter are illustrated in figure 12.
!"#$%&'()*+,-$./01(#2)./3456!78
Med denna parameter kan man korrigera autopilotens knslighet Ir kursndringar genom att ndra
rodrets respons (engelska benmningar YAW, SEA eller WEATHER). D.v.s. denna parameter
deIinierar hur stort kursIelet kan vara innan autopiloten Irsker kompensera. Ett lgt vrde, dvs
hg knslighet, hller bten p en s rak kurs som mjligt men kan vid speciellt hrt vder gra att
autopiloten arbetar kontinuerligt vilket ger hg strmIrbrukning och ondigt slitage p styrningen.
Ett Ir hgt vrde kan gr att bten tillts att avvika allt Ir mycket Irn den nskade kursen innan
autopiloten korrigerar kursen. Som de engelska beteckningarna antyder kan man behva ka vrdet
vid hrt vder, dvs nr bten kastas Iram och tillbaka av vgorna Ir att I autopiloten att inte
kompensera Ir minsta Iel i kursen.
Hg knslighet, lgt vrde instllt.
Lg knslighet, hgt vrde instllt.
Fr att n instllningen Ir knslighet trycks knappen MODE. Displayen kommer att visa S **
och den Irinstllda knsligheten visas som ett tal mellan 1 och 10. Frn Iabriken r detta vrde
instllt p 5.
Notera: Fr lg instllning kan orsaka att motorn till styrningen r konstant aktiv. Denna parameter
kan d behva kas tills autopiloten Ir ett lugnare uppIrande och inte kompenserar hela tiden. Fr
att korrekt stlla in denna parameter stll den Irst p 1 och ka den sedan tills autopiloten styr
bten p ett lugnt stt utan allt Ir stora kursIel. Vid hrt vder ka vid behov vrdet tillIlligt.
!"#%$.)/9+(&$*/01(#2)./3456!78
Genom att trycka p MODE tills displayen visar rodrets position som ett numeriskt tal Ir antingen
styr- eller babord.
1. Nr rodret r i sin centrala position kommer displayen att visa 00.
2. Nr rodret har en position Ir babord kurs kommer displayen vissa Pt**.
3. Nr rodret har en position Ir styrbord kurs kommer displayen visa St**.
Fr att avsluta visningen av roderpositionen trycks antingen MODE eller AUTO ned en gng.
!"#$%:$,%'()(+(,2%8/01(#2)./3456!78
RoderbegrnsningsIunktionen i AP47R Irhindrar motorn i hydraulpumpen, att driva rodret till dess
Iysiska stopp (maximala vinkling). Dessa begrnsningar r Iabriksinstllda och behver oItast inte
ndras p. Om ndringar nd visar sig ndvndiga kan dessa begrnsningar stllas via displayen
enligt Iljande procedur:
1. Stll in rodret p nskad max vinkling t babord.
2. Vlj SET PORT LIMIT genom att trycka p knappen MODE upprepade gnger tills
13
Flotec Marin 2010
Rev 2
Henrik Florin
17

Figure 12: Illustration of all the situations that the rudder controller
can come upon (TMQ, 2009).
5.2.3Headingdata
The compass that is used to receive the heading data is an Elproma sensor ECS1. It is a solid-state electronic
compass containing rate gyros, meaning that it will be less prune to send heading errors due to pitch and roll
(marked as tilt in user manuals). The compass updates the heading ten times per second and sends it out through
a serial communication protocol, in this case NMEA 0183. A more specific list of properties can be seen in table
9.
Table 9: Property of the Elproma sensor ECS1 (Elproma, 2010a).
Serial protocol NMEA 0183
Update rate 10 times / second
Resolution 0.1
Tilt
compensation
Up to 35
Output error max 2
Output change
with tilt
max 2
Repeatability 1
HDT 10 Hz
HDG 1 Hz
Signals and
frequency
HDM 1 Hz

Henrik Florin
18
In reality the compass has been found to send out the three different NMEA 0183 signals that were described in
chapter 3. Each of the signals is sent with a specific frequency and all sentences contain the heading information.
This means that while the compass only updates the heading 10 times per second it also sends out its current
heading 12 times per second in total. In order to save computational time the autopilot only parses the HDT
message, which will give it a new heading ten times per second. The risk of taking in all sentences is that the
additional two sentences each second can be sending an old heading that is not updated just for them. The
information that one gets from parsing these sentences can therefore be of no additional use.
When using the compass from Elproma one needs to invert all signals coming from the compass before reading
them. This can be done in software but since the Arduino board puts all signals in a buffer that is then read then
it is simpler to invert the signals electronically. An electrical scheme of how this is done is provided in figure 13.

Figure 13: Connection scheme for the Elproma sensor ECS1.
Connections are made in order to invert all data and the Arduino board
is marked as uC. The blue cable (marked in the figure with Blue) is
the signal cable from the compass (Elproma, 2010b).
The NMEA parser is called upon once at each loop of the program at which time it is updated with the latest
characters received by the Arduino board from the compass. The parsing and updating of current heading is then
only performed when a complete sentence is found. All messages from the compass are also checked by
processing the checksum at the end of the sentence.
5.2.4Userinterface
The software controlling the user interface constitutes of two parts, a button handler and a LCD handler. The
goal of the button handler is to check if the user has pressed any buttons and then calls the right function in the
rest of the system to reflect the users wishes. The button handler manages this by having an update function that
is called upon ones ever loop of the program. The update function checks the state of all four buttons and
compares them to the previously found state. If the state of one button goes from being pressed to being up then
the button is marked as pressed by the user and the corresponding action is initiated. This procedure is used in
order for the system to only mark a button to be pressed once every time the user pushes a button. The arrow
buttons are also checked if they are being pressed during a longer time. This is done in order to be able to
perform the power steer action when in manual mode. Figure 14 illustrates how the four buttons are set up on
the prototype board.

Figure 14: Illustration of the button configuration on the prototype
board.
Henrik Florin
19
The LCD of the autopilot has two main views. The first view is the main view that is shown at start-up and
during normal conduct. This view shows the user information of current heading, current rudder angle, current
mode, and is the autopilot is set to auto mode a course to steer is also shown. The design of the user interface can
be seen in the picture below.

Figure 15: Picture of the main view of the LCD on the autopilot.
As can be seen in figure 15 the main view constitutes of tree parts. The upper left corner contains information of
the current mode and the course to steer (CTS). The upper right corner shows the current heading with double
sized numbers and the lower part of the LCD displays the current rudder angle by displaying bars that
correspond to the rudder position. If the rudder is at its centre position then two half-filled bars are shown.
The second view is the settings view. This view has only a heading that describes which setting that is being
viewed and a corresponding value for that setting. The settings are changed by using two of the buttons and are
immediately changed when the user steps through the values. There exists several settings view handling several
different settings that can be stepped through by pushing the mode button.
All details on the screen are constantly checked for updates and only the parts of the screen that contains old
values will be updated. This was done to minimize flickering in the display. Flickering was seen to appear if
everything was constantly updated at each loop of the program.
5.3Tuning
Although the tuning of the system was not one of the main goals of the project a basic tuning was done during
the project in order to evaluate the autopilots overall capacity to perform its duties.
The specific setup of cascaded controllers means that the heading controller does not produce any offset
discussed in chapter 4.1. This means that a normal P-controller should be enough in theory. A simple heading
simulator was created in order to test this theory in the lab. The heading simulator changes the current heading
that is inputted in the heading controller by linearly augmenting or decreasing it in accordance with the current
rudder position. In order to get a more revealing result on how the autopilot reacts then the sensitivity was set to
zero during the tests. Below are the result for a couple of different values for the P constant of the controller.
Some results with a full PID controller are also shown in figure 16.
Henrik Florin
20

Figure 16: The first four figures plot the behaviour of the autopilot
when using a P controller as the heading controller. The P coefficient
is set to 6, 7, 8 and 15 respectively. The last figure plots the behaviour
when using a PI controller with P = 6 and I = 1. The upper area of
each of the figures indicates the Setpoint and the Input of the PID
controller over time.

As can be seen in figure 16 one can construct a fairly good autopilot using a simple P controller in the lab using
the above mentioned heading simulator. It can also be seen that if the P controller is given a too high P
coefficient then the behaviour of the autopilot will tend to start oscillate around the desired heading. It is
therefore clear that in order to get an optimal result one needs to put more effort into tuning the coefficient of the
Henrik Florin
21
P controller. The last figure shows the behaviour of a PI controller, which in this case never reaches the desired
heading. It should however be said that no effort has been put into tuning a PI or PID controller.
Although the autopilot behaves in a satisfactory manner when testing in the lab the behaviour in reality could be
different. In reality were the heading does not act completely linearly according to the rudder position then the
approach with just a P controller might not be adequate. Further investigation into the mater has not been
possible during this project and will be left for future projects.
6 Conclusion and discussion
This project set out to answer the two fundamental questions listed below.
Can a basic autopilot be created with a standard eight-bit microcontroller?
When looking at the prototype that has been created during the project and comparing it with the functionalities
that was listed in chapter 1.3 one can clearly see that all functionalities have been realized. The Arduino Mega
board both has adequate computational power and programming memory for running the basic autopilot. One
can even say that the Arduino board leaves place for further development. An example of this is the fact that the
programmable memory in the board was only used up to approximately 15 percent.
The approximate hardware cost of producing the prototype in this project can be calculated to approximately
1800 sek. It is important to understand that this cost is for producing the prototype and not a complete product. If
the product were to enter a real production then one would have to create a custom made PCB and spend time on
producing a casing for the autopilot. If the custom made PCB were to be produced at high volumes then the cost
of that hardware would be significantly less then the cost during this project. The casing would have a high
initial cost due to development costs but the production of larger volumes would also be rather cheap. These
costs do not include costs for development of the software and testing of the system.
This project aimed at looking at the complexity of a basic autopilot by creating a prototype. During the project
many different ideas were though up and discussed but in the end the approach that has been discussed in this
document was chosen for its robustness and easy implementation. One very important property of this approach
is that it will be independent of the configuration of the boat. This means that one does not need to tune the core
of the autopilot to the boat on which it is used. The tuning of the system was also made easier due to the fact that
a simple P controller could be used. However this fact has not been tested in reality and the complexity of tuning
the system could potentially be higher in real life. In the authors mind more time needs to be spent on tuning and
testing in order to optimize the system. However optimizing the system has not been one of the main goals of
this project it clearly shows that a basic autopilot can be created using the hardware listed in section 1.2 by using
the approach discussed above.
How can the autopilot that is created during the project be further developed?
One thing that is included in many autopilots today and that needs to be included in the autopilot created during
this project in order to go further towards production is the functionality of taking in signals from a GPS unit.
This functionality includes the ability of steering through waypoints from a plotter and correcting course after
cross-track-error from the GPS unit. It would not be hard to add this functionality to the current autopilot. One
approach is to let the cross-track-error add a small correction in course depending on its magnitude, hence letting
the autopilot steer towards the right path. However handling cross-track-error through GPS units has been
something that is outside the scope of the project. Letting the autopilot steer through waypoints is a mater of
updating the wanted course after getting the information from the plotter.
Instead of taking in the current rudder position one could simulate the rudder by mathematical calculations. This
would eliminate the use of a physical rudder feedback unit, lessening the burden when installing the system and
taking away the cost of the rudder feedback unit.
During this project a simple LCD was chosen for its simplicity and capacity to show all the necessary parts of
the user interface to the user. However one could greatly benefit from using a larger graphical display either in
black and white or in full colour. In doing so one could create a more intuitive and informing user interface that
would greatly increase the workflow in handling the autopilot. The software part needed to support a fully
graphical display would be significant. All parts of the display must be constantly checked for updates as was
done with the simple LCD used in this project. The difference when using a bigger graphical display would be
Henrik Florin
22
that the information that needs to be constantly checked would be much bigger and that all different display
options needs to be created stored and handled by the PCB.
An optional future development of the autopilot is to incorporate some type of self-tuning ability. This means
that the autopilot would be able to tune its parameters automatically after the boat that it steers. Hence, it would
make the autopilot fit the boat better given time. This option is rather new to the market of autopilots and would
demand some ingenuity.
The three first features for the further development of the autopilot should not be that difficult to implement in a
standard eight-bit micro controller like the Arduino Mega. The Arduino Mega both has the memory and the
processing power needed for these features. The last feature talks about auto tuning, which could mean a lot of
different things. One could for example have three different sets of tuning parameters that can be interchanged
by the autopilot. This approach should also be small enough to be implemented in an Arduino Mega board. If
one, on the other hand, wants a full neural network to be tuning the system then the memory and processing
power of the chosen board would probably not be enough.
Henrik Florin
23
Source reference
Bennett Peter, 2008, The NMEA FAQ Version 6.6,
<http://vancouver-webpages.com/peter/nmeafaq.txt>, (9 August 2010)
Barr Michael, 2001, "Pulse Width Modulation", Embedded Systems Programming, September 2001
also at
Barr Michael, 2001, Introduction to Pulse Width Modulation (PWM),
<http://www.netrino.com/Embedded-Systems/How-To/PWM-Pulse-Width-Modulation>, (24
August 2010)
Cooper Douglas J., 2008, Practical Process Control, Proven Methods and Best Practices for Automatic PID
Control, < http://www.controlguru.com/pages/table.html>, (13 August 2010)
Elproma, 2010a, Electric compass sensor ECS1,
<http://www.elproma.com/compass/Media/ECS1_SENSOR.pdf>, (18 August 2010)
Elproma, 2010b, Compass inverter,
Figure received by direct contact with the company (25 June 2010)
Engineering Knowledge, 2007, DC Motor Control and Interfacing,
<http://engknowledge.com/dc_motor_control_interfacing.aspx>, (24 August 2010)
Flotec Marin AB, 2010, AP47/AP47R Autopilot,
<http://www.flotecmarin.se/pdf/AP47SS23manualSV2010Rev3.pdf>, (24 August 2010)
Glad Torkel, 2007, Reglerteknik, grundlggande teori,
Studentlitteratur, Lund, Sweden, ISBN: 978-91-44-02275-8
Institute of Computer Science Poznan University of Technology, 2001, The NMEA 0183 Protocol,
<http://www.cs.put.poznan.pl/wswitala/download/pdf/NMEAdescription.pdf>, (9 August 2010)
National Marine Electronics Association, 2008, NMEA 0183 Standard,
<http://www.nmea.org/content/nmea_standards/nmea_083_v_400.asp>, (9 August 2010)
TMQ, 2009, AP46Pulsing,
Figure received by direct contact with the company (12 July 2009)
Raymond Eric S., 2010, NMEA Revealed,
<http://gpsd.berlios.de/NMEA.txt>, (9 August 2010)
Henrik Florin
24
Appendix A - Time plan
Time plan in descending order.

1) Planning 6d
1.1) Initial documentation and planning 6d
1.2) DEADLINE: Hand-in of initial documentation
1.3) Information 5d
1.3.1) Information of the Arduino platform 1d
1.3.2) Information of hardware being used 1d
1.3.3) Order hardware 1d
1.3.4) Information of NMEA 0183 1d
1.3.5) Information of PID 3d
1.3.6) Information of Real Time OS - ArduinOS 3d
1.4) Plan electrical connections 1d
2) Hardware 6d
2.1) Create test board 3d
2.2) Mount electrical components on testboard 3d
2.3) Soldering 4d
2.3.1) Cable connectors 1d
2.3.2) LCD 1d
2.3.3) Buttons 1d
2.3.4) Compass 1d
3) Basic functionality testing 5d
3.1) Test LCD 1d
3.2) Test Buttons 1d
3.3) Test Compass 1d
3.4) Test rudder feedback unit 1d
3.5) Test driving unit 1d
4) DEADLINE: All hardware is received and functional
5) Software developement 15d
5.1) Create basic GUI - RFU indicator, direction, AUTO
indicator
4d
5.2) Create NMEA parser 2d
5.3) Integrate the compass into the autopilot 1d
5.4) Integrate the RFU into the autopilot 1d
5.5) DEADLINE: Basic GUI done and functional
5.6) Implement motor library and integrate into
autopilot
1d
5.7) Implement PID regulator 1d
5.8) Rudder PID 3d
5.8.1) Integrating rother PID 1d
5.8.2) Calibration and testing of rudder PID 2d
5.9) Steering PID 3d
5.9.1) Integrating Steering PID 1d
5.9.2) Callibration steering PID 2d
5.10) DEADLINE: Basic software for autopilot done
5.11) Create GUI menu for settings 1d
5.12) Fine tuning of parameters and GUI 1d
6) DEADLINE: Prototype ready for testing
7) Testing 5d
7.1) Real world testing 5d
7.2) Fine tuning 5d
8) Reports 15d
8.1) Final report 15d
8.2) Presentation 2d
9) Teory 18d
9.1) Search for more theoretical information 18d
10) Project done
Task Duration
Planning
Henrik Florin Initial documentation and planning
Henrik Florin; Flotec Marin AB; Patric Jensfeldt; Examiner
Information
Henrik Florin Information of the
Henrik Florin Information of har
Flotec Marin AB Order hardware
Henrik Florin Information of NM
Henrik Florin Information of PID
Henrik Florin Information of Real Time OS - ArduinOS
Henrik Florin Plan electrical con
Hardware
Kjell Gravyr; Henrik Florin Create test board
Henrik Florin Mount electrical components on testboard
Soldering
Henrik Florin Cable connectors
Henrik Florin LCD
Henrik Florin Buttons
Henrik Florin Compass
Basic functionality testing
Henrik Florin Test LCD
Henrik Florin Test Buttons
Henrik Florin Test Compass
Henrik Florin Test rudder feedb
Henrik Florin Test driving unit
Flotec Marin AB; Henrik Florin
Software developement
Henrik Florin Create basic GUI - RFU indicator, direction, AUTO indicator
Henrik Florin Create NMEA parser
Henrik Florin Integrate the com
Henrik Florin Integrate the RFU
Henrik Florin
Henrik Florin Implement motor
Henrik Florin Implement PID reg
Rudder PID
Henrik Florin Integrating rother
Henrik Florin Calibration and testing of rudder PID
Steering PID
Henrik Florin Integrating Steerin
Henrik Florin Callibration steering PID
Henrik Florin
Henrik Florin Create GUI menu f
Henrik Florin Fine tuning of par
Henrik Florin
Testing
Flotec Marin AB Real world testing
Henrik Florin Fine tuning
Reports
Henrik Florin Final report
Henrik Florin Presentation
Teory
Henrik Florin Search for more theoretical information
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10 Day 11 Day 12 Day 13 Day 14 Day 15 Day 16 Day 17 Day 18 Day 19 Day 20 Day 21 Day 22 Day 23 Day 24 Day 25 Day 26 Day 27 Day 28 Day 29 Day 30 Day 31 Day 32 Day 33 Day 34 Day 35 Day 36 Day 37 Day 38 Day 39 Day 40 Day 41 Day 42 Day 43 Day 44 Day 45 Day 46 Day 47 Day 48 Day 49
1) Planning 6d
1.3) Information 5d
2) Hardware 6d
2.3) Soldering 4d
2.3.2) LCD 1d
2.3.3) Buttons 1d
2.3.4) Compass 1d
3.1) Test LCD 1d
indicator
4d
autopilot
1d
5.8) Rudder PID 3d
7) Testing 5d
7.2) Fine tuning 5d
8) Reports 15d
9) Teory 18d
10) Project done
Task Duration
Planning
Information
Hardware
Soldering
Henrik Florin LCD
Henrik Florin
Rudder PID
Steering PID
Henrik Florin
Henrik Florin
Testing
Reports
Teory
1) Planning 6d
1.3) Information 5d
2) Hardware 6d
2.3) Soldering 4d
2.3.2) LCD 1d
2.3.3) Buttons 1d
2.3.4) Compass 1d
3.1) Test LCD 1d
indicator
4d
autopilot
1d
5.8) Rudder PID 3d
7) Testing 5d
7.2) Fine tuning 5d
8) Reports 15d
9) Teory 18d
10) Project done
Task Duration
Planning
Information
Hardware
Soldering
Henrik Florin LCD
Henrik Florin
Rudder PID
Steering PID
Henrik Florin
Henrik Florin
Testing
Reports
Teory
1) Planning 6d
1.3) Information 5d
2) Hardware 6d
2.3) Soldering 4d
2.3.2) LCD 1d
2.3.3) Buttons 1d
2.3.4) Compass 1d
3.1) Test LCD 1d
indicator
4d
autopilot
1d
5.8) Rudder PID 3d
7) Testing 5d
7.2) Fine tuning 5d
8) Reports 15d
9) Teory 18d
10) Project done
Task Duration
Planning
Information
Hardware
Soldering
Henrik Florin LCD
Henrik Florin
Rudder PID
Steering PID
Henrik Florin
Henrik Florin
Testing
Reports
Teory
Henrik Florin
25

Followed by report and presentation.
1) Planning 6d
1.3) Information 5d
2) Hardware 6d
2.3) Soldering 4d
2.3.2) LCD 1d
2.3.3) Buttons 1d
2.3.4) Compass 1d
3.1) Test LCD 1d
indicator
4d
autopilot
1d
5.8) Rudder PID 3d
7) Testing 5d
7.2) Fine tuning 5d
8) Reports 15d
9) Teory 18d
10) Project done
Task Duration
Planning
Information
Hardware
Soldering
Henrik Florin LCD
Henrik Florin
Rudder PID
Steering PID
Henrik Florin
Henrik Florin
Testing
Reports
Teory
1) Planning 6d
1.3) Information 5d
2) Hardware 6d
2.3) Soldering 4d
2.3.2) LCD 1d
2.3.3) Buttons 1d
2.3.4) Compass 1d
3.1) Test LCD 1d
indicator
4d
autopilot
1d
5.8) Rudder PID 3d
7) Testing 5d
7.2) Fine tuning 5d
8) Reports 15d
9) Teory 18d
10) Project done
Task Duration
Planning
Information
Hardware
Soldering
Henrik Florin LCD
Henrik Florin
Rudder PID
Steering PID
Henrik Florin
Henrik Florin
Testing
Reports
Teory
Henrik Florin
26
Appendix B Complete class diagram

TRITA-CSC-E 2010:181
ISRN-KTH/CSC/E--10/181-SE
ISSN-1653-5715

www.kth.se

Autopilot Prototype

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Autopilot Prototype

Uploaded by

Copyright:

Available Formats

Autopilot Prototype

You might also like