autopilot report final - kth · described in detail in this document. an important fact that led to...

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

Bachelor’s 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 målet med detta projekt är att få en bättre förståelse för hur en autopilot för en fritidsbåtägare skapas och hur den kan utvecklas vidare. Mer specifikt ämnar projektet till att besvara två frågor,

1. Kan en grundläggande autopilot skapas med en standard åtta bitars processor? 2. Hur kan autopiloten som skapas under projektet utvecklas ytterligare?

Autopiloten skapades med hjälp 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 ifrån sig en önskad roderposition medan den andra skötte själva roderpositioneringen. Den första regulatorn skapades med hjälp av en P-regulator medan den andra används enklare metoder. Programvaran inkluderade även funktionalitet för att förändra den totala känsligheten av autopilot och ett användargränssnitt innehållandes en LCD-display och fyra knappar.

Projektet kom fram till att en grundläggande autopilot skulle kunna skapas med den angivna hårdvaran 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 båten.

Vidareutveckling av autopilot kan göras genom att t.ex. använda en större färgskärm, lägga till stöd för GPS-signaler, ta bort behovet av roder givaren samt att ge autopiloten möjlighet att ställa in sina parametrar automatiskt.

Table of contents

1 Introduction...................................................................................................................................1 1.1 Background................................................................................................................................................................1 1.1.1 Flotec Marin AB................................................................................................................................................1

1.2. Purpose and scope .................................................................................................................................................1 1.3 Delimitations .............................................................................................................................................................2 1.4 Definitions, acronyms and abbreviations .....................................................................................................3 1.5 Literature overview................................................................................................................................................3 1.6 Overview of the document ..................................................................................................................................4

2 Method.............................................................................................................................................5 2.1 Planning.......................................................................................................................................................................5 2.2 Production..................................................................................................................................................................5 2.3 Evaluation phase and Presentation.................................................................................................................5

3 Theory..............................................................................................................................................6 3.1 Automatic control engineering..........................................................................................................................6 3.1.1 PID controller....................................................................................................................................................7

3.2 Motor control ............................................................................................................................................................8 3.3 The NMEA 0183 protocol ....................................................................................................................................9

4 Design............................................................................................................................................ 10 4.1 Autopilot functionality ....................................................................................................................................... 10 4.2 Software.................................................................................................................................................................... 11

5 Implementation......................................................................................................................... 12 5.1 Hardware ................................................................................................................................................................. 12 5.1.1 Wire connection............................................................................................................................................ 13

5.2 Software.................................................................................................................................................................... 14 5.2.1 Heading controller ....................................................................................................................................... 14 5.2.2 Rudder controllers....................................................................................................................................... 16 5.2.3 Heading data................................................................................................................................................... 17 5.2.4 User interface................................................................................................................................................. 18

5.3 Tuning ....................................................................................................................................................................... 19 6 Conclusion and discussion..................................................................................................... 21 Source reference........................................................................................................................... 23 Appendix A - Time plan .............................................................................................................. 24 Appendix B – Complete class diagram................................................................................... 26

Autopilot prototype - Bachelor’s degree Henrik Florin

1

1 Introduction 1.1 Background

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 children’s 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 child’s 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.

Today’s 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, today’s 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.1 Flotec Marin AB 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 Södermalm in Stockholm and the company has three employees.

1.2. Purpose and scope

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.


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.3 Delimitations

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.


3

1.4 Definitions, acronyms and abbreviations

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.5 Literature overview

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.


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, grundläggande 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.6 Overview of the document

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.


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.1 Planning

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.2 Production

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.3 Evaluation phase and Presentation

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 ReportingProductionHardware

Software

Testing

Theory


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.1 Automatic control engineering

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.


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.1 PID controller 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


8

€

Output = Kp ⋅ e(t) +Ki ⋅ e(τ)dτ0

t

∫ +Kdddte(t)

Kp, Ki and Kd 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.2 Motor control

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


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.3 The NMEA 0183 protocol

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).


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.1 Autopilot functionality

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.


11

Figure 5: State machine diagram of the autopilot.

4.2 Software

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.


12

5 Implementation 5.1 Hardware

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.


13

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

5.1.1 Wire connection

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.


14

5.2 Software

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.1 Heading controller 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 library’s 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.


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.


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.2 Rudder controllers 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

!"#$#"%%&$'&(&)"*"($+&%$)&%$+,((-."(&$&/*,'-0,*"%1$+2%10-.3"*$45($+/(12%#(-%.&($."%,)$&**$2%#(&$(,#("*1 $ ("1',%1 $ 6"%."01+& $ 7"%2)%-%.&( $89:; $ <=9$ "00"( $:=9>?=@AB $CBDB1B $ #"%%& $ '&(&)"*"($#"4-%-"(&($3/($1*,(*$+/(14"0"*$+&%$D&(&$-%%&%$&/*,'-0,*"%$45(15+"($+,)'"%1"(&B$=**$0E.*$D2(#";$#D1$35.$+2%10-.3"*;$3E00"($7E*"%$$'E$"%$1E$(&+$+/(1$1,)$)5F0-.*$)"%$+&%$D-#$1'"G-"00*$3E(*$D2#"($.5(&$&**$&/*,'-0,*"%$&(7"*&($+,%*-%/"(0-.*$D-0+"*$."($35.$1*(5)45(7(/+%-%.$,G3$,%5#-.*$10-*&."$'E$1*H(%-%."%B$=**$45($35.*$D2(#"$+&%$.5($&**$7E*"%$*-00E*1$&**$&DD-+&$&00*$45($)HG+"*$4(E%$#"%$5%1+&#"$+/(1"%$-%%&% $&/*,'-0,*"%$+,((-."(&($+/(1"%B$<,)$#"$"%."01+&$7"*"G+%-%.&(%&$&%*H#"($+&%$)&%$7"35D&$5+&$D2(#"*$D-#$3E(*$D2#"(;$#D1$%2($7E*"%$+&1*&1$4(&)$,G3$*-007&+&$&D$DE.,(%&$45($&**$4E$&/*,'-0,*"%$&** $-%*"$+,)'"%1"(&$45($)-%1*&$4"0$-$+/(1"%B

!"#$%&'()*#+,-.$)/#-$0&12,$*'(-&))-3$

4/#$%&'()*#+,-.$+"#-$0&12,$*'(-&))-3

I5($&**$%E$-%1*200%-%."%$45($+2%10-.3"*$*(HG+1$+%&''"%$J!KC=JB$C-1'0&H"%$+,))"($&**$D-1&$J<$LLJ$,G3$#"%$45(-%1*200#&$+2%10-.3"*"%$D-1&1$1,)$"**$*&0$)"00&%$M$,G3$MNB$I(E%$4&7(-+"%$2($#"**&$D2(#"$-%1*200*$'E$OB$

P,*"(&Q$I5($0E.$-%1*200%-%.$+&%$,(1&+&$&**$),*,(%$*-00$1*H(%-%."%$2($+,%1*&%*$&+*-DB$C"%%&$'&(&)"*"($+&%$#E$7"35D&$5+&1$*-001$&/*,'-0,*"%$4E($"**$0/.%&("$/''45(&%#"$,G3$-%*"$+,)'"%1"(&($3"0&$*-#"%B$I5($&**$+,(("+*$1*200&$-%$#"%%&$'&(&)"*"($1*200$#"%$45(1*$'E$M$,G3$5+&$#"%$1"#&%$*-001$&/*,'-0,*"%$1*H( $7E*"%$'E$"**$0/.%*$12**$/*&%$&00*$45($1*,(&$+/(14"0B$R-#$3E(*$D2#"($5+&$D-#$7"3,D$D2(#"*$*-004200-.*B

!"#%$.)/9+(&$*/01(#2)./3456!78

S"%,)$&**$*(HG+&$'E$!KC=$*-001$#-1'0&H"%$D-1&($(,#("*1$',1-*-,%$1,)$"**$%/)"(-1+*$*&0$45($&%*-%."%$1*H(T$"00"($7&7,(#B$

MB P2($(,#("*$2($-$1-%$G"%*(&0&$',1-*-,%$+,))"($#-1'0&H"%$&**$D-1&$J$NNJB$

UB P2($(,#("*$3&($"%$',1-*-,%$45($7&7,(#$+/(1$+,))"($#-1'0&H"%$D-11&$JV*LLJB$

WB P2($(,#("*$3&($"%$',1-*-,%$45($1*H(7,(#$+/(1$+,))"($#-1'0&H"%$D-1&$J<*LLJB$

I5($&**$&D10/*&$D-1%-%."%$&D$(,#"(',1-*-,%"%$*(HG+1$&%*-%."%$!KC=$"00"($9X>K$%"#$"%$.E%.B$

!"#$%:$,%'()(+(,2%8/01(#2)./3456!78

@,#"(7".(2%1%-%.14/%+*-,%"%$-$9VYZ@$45(3-%#(&($),*,(%$-$3H#(&/0'/)'"%;$&**$#(-D&$(,#("*$*-00$#"11$4H1-1+&$1*,''$6)&[-)&0&$D-%+0-%.AB$C"11&$7".(2%1%-%.&($2($4&7(-+1-%1*200#&$,G3$7"35D"($,4*&1*$-%*"$2%#(&1$'EB$K)$2%#(-%.&($2%#E$D-1&($1-.$%5#D2%#-.&$+&%$#"11&$7".(2%1%-%.&($1*200&1$D-&$#-1'0&H"%$"%0-.*$450F&%#"$'(,G"#/(Q$

MB <*200$-%$(,#("*$'E$5%1+&#$)&[$D-%+0-%.$E*$7&7,(#B$

UB R20F $ <=> $ VK@>$\]!]> $ ."%,) $ &** $ *(HG+& $ 'E $ +%&''"% $!KC= $ /''("'&#" $ .E%."( $ *-001$

MW^$I0,*"G$!&(-%$UNMN

@"D$U


17

Figure 12: Illustration of all the situations that the rudder controller can come upon (TMQ, 2009).

5.2.3 Heading data 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


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.4 User interface 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.


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.3 Tuning

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.


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


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


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.


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, grundläggande 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)


24

Appendix A - Time plan Time plan in descending order.

1) Planning 6d

1.1) Initial documentation and planning 6d1.2) DEADLINE: Hand-in of initial documentation1.3) Information 5d

1.3.1) Information of the Arduino platform 1d1.3.2) Information of hardware being used 1d1.3.3) Order hardware 1d1.3.4) Information of NMEA 0183 1d1.3.5) Information of PID 3d1.3.6) Information of Real Time OS - ArduinOS 3d

1.4) Plan electrical connections 1d2) Hardware 6d

2.1) Create test board 3d2.2) Mount electrical components on testboard 3d2.3) Soldering 4d

2.3.1) Cable connectors 1d2.3.2) LCD 1d2.3.3) Buttons 1d2.3.4) Compass 1d

3) Basic functionality testing 5d

3.1) Test LCD 1d3.2) Test Buttons 1d3.3) Test Compass 1d3.4) Test rudder feedback unit 1d3.5) Test driving unit 1d

4) DEADLINE: All hardware is received and functional5) Software developement 15d

5.1) Create basic GUI - RFU indicator, direction, AUTO indicator

4d

5.2) Create NMEA parser 2d5.3) Integrate the compass into the autopilot 1d5.4) Integrate the RFU into the autopilot 1d5.5) DEADLINE: Basic GUI done and functional5.6) Implement motor library and integrate into

autopilot1d

5.7) Implement PID regulator 1d5.8) Rudder PID 3d

5.8.1) Integrating rother PID 1d5.8.2) Calibration and testing of rudder PID 2d

5.9) Steering PID 3d

5.9.1) Integrating Steering PID 1d5.9.2) Callibration steering PID 2d

5.10) DEADLINE: Basic software for autopilot done5.11) Create GUI menu for settings 1d5.12) Fine tuning of parameters and GUI 1d

6) DEADLINE: Prototype ready for testing7) Testing 5d

7.1) Real world testing 5d7.2) Fine tuning 5d

8) Reports 15d

8.1) Final report 15d8.2) Presentation 2d

9) Teory 18d

9.1) Search for more theoretical information 18d10) Project done

Task DurationPlanning

Henrik FlorinInitial documentation and planningHenrik Florin; Flotec Marin AB; Patric Jensfeldt; Examiner

Information

Henrik FlorinInformation of the…Henrik FlorinInformation of har…

Flotec Marin ABOrder hardwareHenrik FlorinInformation of NM…

Henrik FlorinInformation of PIDHenrik FlorinInformation of Real Time OS - ArduinOSHenrik FlorinPlan electrical con…

Hardware

Kjell Gravyr; Henrik FlorinCreate test boardHenrik FlorinMount electrical components on testboard

Soldering

Henrik FlorinCable connectorsHenrik FlorinLCD

Henrik FlorinButtonsHenrik FlorinCompass

Basic functionality testing

Henrik FlorinTest LCDHenrik FlorinTest Buttons

Henrik FlorinTest CompassHenrik FlorinTest rudder feedb…

Henrik FlorinTest driving unitFlotec Marin AB; Henrik Florin

Software developement

Henrik FlorinCreate basic GUI - RFU indicator, direction, AUTO indicator

Henrik FlorinCreate NMEA parserHenrik FlorinIntegrate the com…Henrik FlorinIntegrate the RFU …Henrik Florin

Henrik FlorinImplement motor …

Henrik FlorinImplement PID reg…

Rudder PID

Henrik FlorinIntegrating rother …Henrik FlorinCalibration and testing of rudder PID

Steering PID

Henrik FlorinIntegrating Steerin…Henrik FlorinCallibration steering PIDHenrik Florin

Henrik FlorinCreate GUI menu f…Henrik FlorinFine tuning of par…Henrik Florin

Testing

Flotec Marin ABReal world testingHenrik FlorinFine tuning

Reports

Henrik FlorinFinal reportHenrik FlorinPresentation

Teory

Henrik FlorinSearch for more theoretical informationHenrik Florin; Flotec Marin AB; Patric Jensfeldt; Examiner

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










4d


autopilot1d








8) Reports 15d


9) Teory 18d




Information




Hardware


Soldering












Rudder PID


Steering PID



Testing


Reports


Teory



1) Planning 6d










4d


autopilot1d








8) Reports 15d


9) Teory 18d




Information




Hardware


Soldering












Rudder PID


Steering PID



Testing


Reports


Teory



1) Planning 6d










4d


autopilot1d








8) Reports 15d


9) Teory 18d




Information




Hardware


Soldering












Rudder PID


Steering PID



Testing


Reports


Teory




25

Followed by report and presentation.

1) Planning 6d










4d


autopilot1d








8) Reports 15d


9) Teory 18d




Information




Hardware


Soldering












Rudder PID


Steering PID



Testing


Reports


Teory



1) Planning 6d










4d


autopilot1d








8) Reports 15d


9) Teory 18d




Information




Hardware


Soldering












Rudder PID


Steering PID



Testing


Reports


Teory




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 report final - kth · described in detail in this document. an important fact that led to...

Documents