autopilot i havstrømmer - hvlhome.hib.no/ai/elektro/2016/bo16e-29.pdfdenne rapporten er skrevet i...

AUTOPILOT I HAVSTRØMMER

Andreas Kaldestad Fjellhaugen, Alex Tran, Mathias Angelvik, Tommy Værøy

13HEAU

1. juni 2016

Dokumentkontroll

Rapportens tittel:

Autopilot i havstrømmer Dato/Versjon

01.06.16/v0.14 Rapportnummer:

Forfatter(e):

Andreas Kaldestad Fjellhaugen, Alex Tran, Mathias Angelvik, Tommy Værøy

Studieretning: 13HEAU

Antall sider m/vedlegg

62 Høgskolens veileder:

Kjell Eivind Frøysa - [email protected] Gradering: Ingen

Eventuelle Merknader:

Oppdragsgiver: Offshore Sensing AS

Oppdragsgivers referanse:

Oppdragsgivers kontaktperson(er) (inklusiv kontaktinformasjon): David Peddie – [email protected]

Revisjon Dato Status Utført av

v.0.10 31.01.16 Fullført forstudierapport Andreas Fjellhaugen

v.0.20 24.02.16 Lagt til beskrivelse av simulator Mathias Angelvik

v.0.40 03.03.16 Lagt til Appendiks B Tommy Værøy

v.0.60 13.05.16 Lagt til kapittel 5. Testing Alex Tran

v.0.90 27.05.16 Fullført første utkast Alle

v.1.00 01.06.16 Fullført prosjektrapporten Alle

Autopilot i havstrømmer

Rev: v1.00 3(62) 01.06.16

Forord Denne rapporten er skrevet i forbindelse med vår avsluttende bacheloroppgave i automatiserings-

teknikk ved Høgskolen i Bergen. Oppgaven er gitt av Offshore Sensing AS og omhandler utvikling av

en styringsalgoritme ment for en selvstyrt seilbøye, samt konstruksjon av et fysisk modellfartøy for

bruk til testing og demonstrasjon av algoritmen i virkelige omgivelser.

Gruppen vil først og fremst takke Offshore Sensing AS med David Peddie i spissen for en spennende,

utfordrende og lærerik oppgave, og for den hjelp og støtte de har bidratt med gjennom prosjektets

gang. Det har til tider vært både morsomt og frustrerende, men mest av alt har det vært en

berikende prosess som alle medlemmene av gruppen er svært fornøyde med å ha fått ta del i.

Videre ønsker vi å uttrykke vår takknemlighet til Høgskolen i Bergen for å ha latt oss ta i bruk deres

automatiseringslaboratorium som arbeidslokale, samt den hjelp og støtte de har bidratt med når det

gjelder anskaffelse av komponenter og materialer som har vært nødvendige for gjennomførelsen av

oppgaven.

Gruppen syntes også det er på sin plass med en ekstra takk til en av høgskolens avdelingsingeniører

Lars Ekroll for hans hjelp og bidrag i forbindelse med testkjøring av båtmotor og medfølgende

regulator, anskaffelse av kritiske komponenter som vannpumpe og slanger når nøden inntraff, og sist

men ikke minst; for hans gode humør og muntre vesen uansett hvilke problemer eller spørsmål han

konfronteres med.

En siste takk går til vår veileder Kjell Eivind Frøysa for gode dialoger og oppfølging i løpet av

oppgavens gjennomførelse.

Vi ønsker til slutt å uttrykke at vi setter stor pris på alle som har hjulpet til med prosjektet, uavhengig

av i hvilken grad de har bidratt. Gruppemedlemmene vil også takke hverandre for et vel gjennomført

prosjekt, og ønske hverandre lykke til med alle fremtidige bestrebelser, hva enn det måtte være.


Rev: v1.00 4(62) 01.06.16

Sammendrag Målet for oppgaven er å få fremstilt en autonom styringsalgoritme som skal kunne tas i bruk til å

styre en seilbøye; et lite ubemannet sjøfartøy. Algoritmen skal kunne styre fartøyet til en bestemt

måldestinasjon angitt ved Global Positioning System (GPS) -koordinater gjennom varierende

havstrømmer ved hjelp av en GPS-mottaker som til enhver tid kan hente ut fartøyets nåværende

posisjon. For å oppnå dette er oppgaven inndelt i to separate stadier: utvikling og testing. Første steg

består av å utvikle en robust og effektiv algoritme, for deretter i andre steg å teste algoritmen i den

virkelige verden ved å implementere den på et selvkonstruert modellfartøy.

I samhandling med oppdragsgiver ble det i starten av prosjektet besluttet å først utvikle et

simulatorprogram med evne til å simulere bevegelsen til et sjøfartøy i vann med og uten

havstrømmer, og med dette tidlig få konstruert en solid plattform for effektiv algoritmeutvikling og

teoretisk testing der raske tilbakemeldinger og stort rom for eksperimentering ville kunne legge et

godt grunnlag for oppnåelse av oppgavens kravspesifikasjon.

Første stadium av prosjektet ble iverksatt i begynnelsen av februar måned da gruppen gikk i gang

med bygging av simulatorprogram og utvikling av algoritmer. På dette stadiet bestod arbeidet

utelukkende av programmering og teoretiske formuleringer av potensielle styringsalgoritmer. Når

denne delen av prosjektet var fullført i henhold til oppdragsgivers krav ble det igangsatt arbeid med å

få konstruert styringssystemet til den fysiske modellen. Systemet består i hovedsak av en Raspberry

Pi mikro-PC tilkoblet en GPS-mottaker som ved hjelp av en egnet algoritme skal kunne styre

modellfartøyets ror via en servomotor, samt et radiofrekvens (RF) –kontrollert manuelt

overstyringssystem. I begynnelsen av denne fasen gikk det mye tid med til feilsøking på, og utforsking

av, den grunnleggende funksjonaliteten innebygget i de overnevnte elektroniske komponentene,

men også til oversettelse av algoritmen som ble funnet å være best egnet for oppgaven fra simulator

til virkelig system. I hovedsak var utfordringene i denne fasen tilknyttet mestring av Raspberry Pi-

enheten og dens interaksjon med servomotoren.

Siste steg på veien mot komplettering av prosjektet bestod av å bedrive testing av det fysiske

styresystemet samt finjustering av den valgte styringsalgoritmen, parallelt med ferdigstilling av

modellfartøyet. Prosjektet kulminerte i et sett fullskala tester av den komplette fysiske modellen i

vann. Referer til kapittel 5 for detaljerte beskrivelser og resultater av all gjennomført testing.

Etter å ha konkludert den praktiske delen av prosjektet og analysert resultatene av all gjennomført

testing, mener gruppens medlemmer at det ferdige produktet oppfyller alle punktene oppsatt i

oppgavens kravspesifikasjon med ett forbehold; den utviklede algoritmen inneholder ingen logikk

som oppfatter forandringer i eventuelle vannstrømmer og endrer dens oppførsel deretter. Dette er

funksjonalitet som ut ifra kravspesifikasjonen kan tolkes som å ha vært ønskelig å få implementert,

men som i løpet av prosjektets gang ble lagt mindre vekt på i samtaler med oppdragsgiver og har

derfor som en konsekvens av tidshensyn ikke har blitt inkludert i den endelige løsningen. Algoritmen

vil likevel basert på sin grunnleggende styringslogikk automatisk korrigere endringer i fartøyets kurs

som følge av havstrømmer, så lenge styrken på disse ikke overgår fartøyets fremdriftshastighet.

Ytterlige begrensninger knyttet til løsningen omfatter hovedsakelig fysiske restriksjoner knyttet til

modellfartøyet, men disse kan ikke sies å bestride oppgavens kravspesifikasjon på noen nevneverdig

måte.


Rev: v1.00 5(62) 01.06.16

1 Innhold Dokumentkontroll ................................................................................................................................... 2

Forord ...................................................................................................................................................... 3

Sammendrag ........................................................................................................................................... 4

1 Innledning ........................................................................................................................................ 9

1.1 Oppdragsgiver ......................................................................................................................... 9

1.2 Problemstilling ......................................................................................................................... 9

1.2.1 Bedriftens hensikt med å arbeide med problemstillingen .......................................... 9

1.3 Hovedidé for løsningsforslag ................................................................................................... 9

2 Kravspesifikasjon ........................................................................................................................... 10

3 Analyse av problemet .................................................................................................................... 11

3.1 Utforming av mulige løsninger .............................................................................................. 11

3.1.1 Løsningsalternativ 1 ................................................................................................... 11

3.1.2 Løsningsalternativ 2 ................................................................................................... 11

3.1.3 Vurderinger i forhold til verktøy og HW/SW komponenter ...................................... 11

3.2 Konklusjon ............................................................................................................................. 12

4 Realisering av valgt løsning ........................................................................................................... 13

4.1 Programvare .......................................................................................................................... 13

4.1.1 Utviklingsløp .............................................................................................................. 13

4.1.2 Simulatoren ............................................................................................................... 14

4.1.3 Algoritmene ............................................................................................................... 18

4.1.4 Raspberry Pi styringsmodul ....................................................................................... 20

4.1.5 Øvrig programvare og utviklingsverktøy ................................................................... 21

4.2 Fysisk system og maskinvare ................................................................................................. 22

4.2.1 Modellfartøy .............................................................................................................. 23

4.2.2 Raspberry Pi ............................................................................................................... 24

4.2.3 GPS ............................................................................................................................. 25

4.2.4 Servomotor ................................................................................................................ 25

4.2.5 Radiokontroll ............................................................................................................. 26

4.2.6 Vannpumpe ............................................................................................................... 27

4.2.7 Batteri/Strømforsyninger .......................................................................................... 27

5 Testing ........................................................................................................................................... 28


Rev: v1.00 6(62) 01.06.16

5.1 Simulering på PC .................................................................................................................... 28

5.1.1 Hensikt ....................................................................................................................... 28

5.1.2 Gjennomføring .......................................................................................................... 28

5.1.3 Resultat ...................................................................................................................... 28

5.1.4 Konklusjon ................................................................................................................. 29

5.2 Testing av individuelle elektroniske komponenter ............................................................... 29

5.2.1 Hensikt ....................................................................................................................... 29

5.2.2 Gjennomføring .......................................................................................................... 29

5.2.3 Resultat ...................................................................................................................... 30

5.2.4 Konklusjon ................................................................................................................. 30

5.3 Testing av styresystem på land uten bruk av GPS ................................................................. 30

5.3.1 Formål ........................................................................................................................ 30

5.3.2 Gjennomføring .......................................................................................................... 30

5.3.3 Resultat ...................................................................................................................... 31

5.3.4 Konklusjon ................................................................................................................. 31

5.4 Testing av styresystem på land med bruk av GPS ................................................................. 31

5.4.1 Formål ........................................................................................................................ 31

5.4.2 Gjennomføring .......................................................................................................... 31

5.4.3 Resultat ...................................................................................................................... 31

5.4.4 Konklusjon ................................................................................................................. 33

5.5 Testing av fremdrift og manøvrering i bølgebasseng ............................................................ 33

5.5.1 Formål ........................................................................................................................ 33

5.5.2 Gjennomføring .......................................................................................................... 33

5.5.3 Resultat ...................................................................................................................... 33

5.5.4 Konklusjon ................................................................................................................. 34

5.6 Testing av komplett system på vann i virkelige omgivelser .................................................. 34

5.6.1 Formål ........................................................................................................................ 34

5.6.2 Gjennomføring .......................................................................................................... 34

5.6.3 Resultat ...................................................................................................................... 34

5.6.4 Konklusjon ................................................................................................................. 35

6 Diskusjon ....................................................................................................................................... 36

6.1 Kostnadsanslag ...................................................................................................................... 36

6.2 Fremdriftsplan ....................................................................................................................... 37

6.3 Tekniske løsninger ................................................................................................................. 37


Rev: v1.00 7(62) 01.06.16

6.3.1 Simulator ................................................................................................................... 37

6.3.2 Raspberry Pi ............................................................................................................... 37

6.3.3 Python ....................................................................................................................... 38

6.3.4 Modellfartøy .............................................................................................................. 38

6.4 Risikoliste ............................................................................................................................... 38

6.5 Oppsummering ...................................................................................................................... 38

7 Konklusjon ..................................................................................................................................... 40

Appendiks A Litteraturliste ............................................................................................................. 41

Appendiks B Forkortelser og ordforklaringer ................................................................................. 42

Appendiks C Prosjektledelse og styring .......................................................................................... 43

C.1 Prosjektorganisasjon ............................................................................................................. 43

C.2 Prosjektform .......................................................................................................................... 44

C.3 Fremdriftsplan ....................................................................................................................... 45

C.4 Risikoliste ............................................................................................................................... 46

Appendiks D Brukerdokumentasjon ............................................................................................... 47

D.1 Brukerdokumentasjon ........................................................................................................... 47

D.2 Drifts- og vedlikeholdsdokumentasjon ................................................................................. 49

Appendiks E Øvrige diagrammer .................................................................................................... 56

E.1 Kretsskjema 1 ........................................................................................................................ 56

E.2 Kretsskjema 2 ........................................................................................................................ 57

E.3 Kjølesystem ........................................................................................................................... 57

Appendiks F Kildekode ................................................................................................................... 58


Rev: v1.00 8(62) 01.06.16

2 Figurliste Figur 4.1-1: Skjermbilde av simulatorens grafiske brukergrensesnitt ................................................... 14

Figur 4.1-2: Simulatorens definerte akseretninger og modifiserte enhetssirkel .................................. 16

Figur 4.1-3: Navigasjonssirkelen ............................................................................................................ 19

Figur 4.2-1: Det fysiske systemet .......................................................................................................... 23

Figur 4.2-2: Raspberry Pi 2 Model B (Hentet fra www.raspberrypi.org)............................................... 24

Figur 4.2-4: Microstack L80 GPS (Hentet fra www.element14.com) .................................................... 25

Figur 4.2-5: Hitec HS-325HB (Hentet fra http://hitecrcd.com) ............................................................. 25

Figur 4.2-6: Spektrum MR3000 (Hentet fra www.spektrum.com) ....................................................... 26

Figur 4.2-7: Spektrum DX3E (Hentet fra http://horizonhobby.co.uk) .................................................. 26

Figur 4.2-8: Vannpumpe til kjølesystem ................................................................................................ 27

Figur 4.2-9: Batteripakker ...................................................................................................................... 27

Figur 5.4-1: Logging fra en mislykket test ............................................................................................. 32

Figur 5.4-2: Logging fra en vellykket test .............................................................................................. 32

Figur 5.6-1: Logging fra fullskala test i Solheimsvannet.. ...................................................................... 35

Figur 6.5-1: Initiell fremdriftsplan ......................................................................................................... 45

Figur 6.5-2: Revidert fremdriftsplan april .............................................................................................. 45

Figur 6.5-3: Revidert fremdriftsplan mai og juni ................................................................................... 45

Figur 6.5-4: Simulasjonseksempel ......................................................................................................... 47

Figur 6.5-5: Simuleringsfunksjoner 1 ..................................................................................................... 48

Figur 6.5-6: Simuleringsfunksjoner 2 ..................................................................................................... 49

Figur 6.5-7: Raspberry Pi innganger ...................................................................................................... 50

Figur 6.5-8: Raspberry Pi skrivebord ..................................................................................................... 50

Figur 6.5-9: Raspberry Pi terminal ......................................................................................................... 51

Figur 6.5-10: Programmappe ................................................................................................................ 51

Figur 6.5-11: Batteritilkobling ................................................................................................................ 52

Figur 6.5-12: Feste av styrestang til servomotor ................................................................................... 53

Figur 6.5-13: Feste av styrestang til overstyringsror ............................................................................. 53

Figur 6.5-14: Oversiktsbilde over oppkobling av overstyringsror ......................................................... 54

Figur 6.5-15: Riktig posisjon for styrestang feste på overstyringsrorets servomotor ........................... 54

Figur 6.5-16: Skrue til lokk på modellbåt............................................................................................... 55

Figur 6.5-17: Kretsskjema 1 ................................................................................................................... 56

Figur 6.5-18: Kretsskjema 2 ................................................................................................................... 57

Figur 6.5-19: Kjølesystem ...................................................................................................................... 57

3 Tabelliste Tabell 1: Utgiftsoversikt......................................................................................................................... 36

Tabell 2: Forkortelser og ordforklaringer .............................................................................................. 43


Rev: v1.00 9(62) 01.06.16

1 Innledning

1.1 Oppdragsgiver Offshore Sensing ble etablert i 2014, er lokalisert på Fantoft og er et datterselskap til

forskningsinstituttet Christian Michelsen Research AS (CMR). Bedriften har per dags dato to faste

ansatte. Offshore Sensing har som mål å utvikle, produsere og selge seilbøyer med ulike

applikasjoner tilgjengelig. Teknologien har vært under utvikling på CMR siden 2005 og kommersielle

produkt er nå tilgjengelig.

Seilbøyene som er utviklet av Offshore Sensing gir kundene mulighet til å foreta en rekke målinger

ved lokasjoner som kan være svært kostbare og lite tilgjengelige, slik at det kan være både vanskelig

og dyrt å sende ordinære skip til disse områdene.

1.2 Problemstilling Gruppen fikk i oppgave av oppdragsgiver å lage en styringsalgoritme til en selvstyrt seilbøye som skal

klare å kjøre til en gitt destinasjon på ca. 1 knop, samt kunne finne den raskeste ruten til

destinasjonen. Ved ankomst skal den kunne holde seg i bevegelse i området rundt dette punktet helt

til den blir kommandert til å kjøre til en annen destinasjon. Seilbøyen skal brukes til å gjøre ulike

målinger ved den gitte destinasjonen, men dette er ikke en del av oppgaven.

1.2.1 Bedriftens hensikt med å arbeide med problemstillingen

Bedriftens hensikt med å arbeide med problemstillingen er å få videreutviklet og forbedret sin

styringsalgoritme for seilbøyer som opererer i farvann der det kan være sterke vind- og

vannstrømmer. Dette er for at deres seilbøyer skal komme seg fram til en destinasjon raskest mulig

for å gjøre nødvendige målinger for deres kunder.

1.3 Hovedidé for løsningsforslag Hovedidéen for løsningen er å utvikle en styringsalgoritme som skal kunne implementeres i

seilbøyene som et integrert system, og som autonomt kan styre seilbøyen til et gitt område basert på

GPS-koordinater. Algoritmen skal ta hensyn til hav- og, om mulig, vindstrømmer for å finne den

raskeste og mest effektive ruten til sin gitte destinasjon, og deretter holde fartøyet i dette området

til en ny destinasjon blir spesifisert.

Ved hjelp av datasimulering vil algoritmen først utvikles og testes i ett program laget spesifikt for

denne oppgaven. Etter nøye testing og kalibrering av algoritmen vil det bli laget en fysisk testmodell

for å teste ut algoritmen i praksis før den kan overføres til arbeidsgivers fartøyer. Denne farkosten vil

bli konstruert av oppdragsgiver i deres verksted ved CMR.


Rev: v1.00 10(62) 01.06.16

2 Kravspesifikasjon Oppgavens kravspesifikasjon kan deles inn i to deler; en for selve algoritmen, og en for det fysiske

modellfartøyet som skal brukes til å demonstrere algoritmens funksjonalitet.

Algoritmen som skal produseres skal ta hensyn til følgende krav:

Algoritmens oppgave er, ved hjelp av å kontrollere roret til et fartøy, å sørge for at fartøyet

når frem til et gitt mål angitt ved et sett GPS-koordinater.

Alle fartøyets handlinger skal styres av den samme sentrale algoritmen. Det vil si at den må

være utformet på en måte som gjør at den fungerer både når fartøyet er på vei mot en ny

destinasjon, og når det skal holde seg i området rundt den gitte destinasjonen etter det er

kommet frem.

Algoritmen må være robust og ha utvetydig definert oppførsel i alle prospektive scenarioer.

Algoritmens funksjonalitet og oppførsel må kunne defineres fullstendig uten avhengighet til

ytre ressurser eller kalkulasjoner som ikke er direkte utvinnbare fra en kombinasjon av

fartøyets og målets GPS-koordinater.

Algoritmen må kunne ta hensyn til uregelmessigheter i eventuelle vannstrømmer og

automatisk gjøre justeringer slik at fartøyet når sin destinasjon på mest mulig effektiv måte.

Algoritmen må være utformet og dokumentert på en måte som gjør at den lett kan

adapteres fra modellen til det virkelige fartøyet etter prosjektets konklusjon.

Den fysiske modellen må designes med hensyn til følgende krav:

Modellens destinasjon og nåværende posisjon skal beskrives kun ved hjelp av GPS. Kompass

kan ikke tas i bruk da de virkelige seilbøyenes operasjonsområde kan strekke seg til områder

som befinner seg så langt nord at kompass ikke vil være pålitelig nok for bøyenes formål.

Modellen må være flytedyktig og stabil nok til å holde seg opprett selv i urolig sjø med

strømmer opp mot en knop.

Modellen må være stor nok til å romme de elektriske og mekaniske komponentene som

trengs for å realisere algoritmens oppførsel gjennom modellens styresystem, og samtidig

sørge for at disse er isolert fra omgivelsene på en trygg måte.

Modellen må kunne operere autonomt og kunne navigere seg rundt for egen maskin. Det vil

si at den må inneholde motorstyrt propell og ror, samt en sentral styringsenhet som kan

kontrollere disse.

Modellen skal implementere en manuell overstyring som raskt og enkelt skal kunne tas i bruk

ved nødstilfeller eller når det er behov for å få fartøyet på land igjen.


Rev: v1.00 11(62) 01.06.16

3 Analyse av problemet

3.1 Utforming av mulige løsninger Det vil i alle tilfeller bli nødvendig å produsere et modellfartøy for å demonstrere funksjonaliteten til

algoritmen. Algoritmen i seg selv vil bli realisert som et program skrevet av gruppens medlemmer og

implementert på den sentrale styringsenheten til modellen. Hvilket programmeringsspråk som blir

valgt vil avhenge av hvilken plattform som ender opp med å bli brukt, men det er nærliggende å anta

at C, C++ eller C# er gode kandidater. Strukturen og syntaksen til disse språkene er veldig like, så

hvilket språk som endes opp med å brukes vil ikke påvirke oppbyggingen av selve algoritmen

nevneverdig.

Hovedforskjellene i utforming av de mulige løsningene kommer i hovedsak fra hvordan gruppen

ønsker å takle utformingen og sammensetningen av den fysiske modellen. Det er viktig at modellen

innehar de riktige egenskapene for at prosjektet skal bli gjennomførbart i henhold til

kravspesifikasjonene og oppgavens målsetning.

3.1.1 Løsningsalternativ 1

Gruppen går til innkjøp av en radiostyrt båt i passende størrelse. Båten modifiseres så med de

komponentene som trengs for å oppfylle kravspesifikasjonene oppgitt for oppgaven; i hovedsak en

mikrokontroller eller mikro-PC og en GPS sender/mottaker. Ved valg av denne løsningen vil en del av

komponentene allerede være på plass og koblet sammen «out of the box», men det gir mindre

fleksibilitet i utformingen. Ekstra komponenter som må skaffes utenom inkluderer GPS og

styringsenhet (PC eller mikrokontroller).

3.1.2 Løsningsalternativ 2

Gruppen lager modellen fra bunnen av med hjelp fra oppdragsgiver. Skroget lages i isopor og kan

utformes på en måte som sikrer maksimal stabilitet og plassutnyttelse. Alle komponenter må da

kjøpes inn separat og kobles sammen av gruppen, noe som medfører mer arbeid introduserer et

større potensiale for feil. Det må da kjøpes inn passende motor med propell og ror, samt batterier og

forskjellige ledninger, i tillegg til de to hovedkomponentene nevnt i alternativ 1.

3.1.3 Vurderinger i forhold til verktøy og HW/SW komponenter

For å få koden/algoritmen til å styre motor og ror på båten trengs en mikrokontroller eller en mikro-

pc. Gruppen vurderer produkter som faller innunder begge alternativene. Blant disse er de fremste

kandidatene Raspberry Pi som er en mikro-pc og Arduino/Genuino som er en mikrokontroller.

Fordelene med Raspberry Pi er at den kan kjøre operativsystemet Linux, man kan velge

programmeringsspråk og flere prosesser kan kjøre samtidig. Arduino/Genuino har et fast

programmeringsspråk og kan bare kjøre en prosess om gangen. Fordelene med mikrokontrolleren er

at den er billigere og lettere å bruke.

Etter ytterligere oppveiing av alternativene og samtaler med oppdragsgiver har gruppen besluttet at

det beste alternativet med hensyn til oppgavens krav er mikro-PC-en Raspberry Pi. Ved å velge denne


Rev: v1.00 12(62) 01.06.16

typen mikro-PC åpnes det opp et større omfang av valgmuligheter både med hensyn til utvalg av

støttekomponenter, tilgjengelige brukerveiledninger på internett og programvareutvikling, blant

annet muligheten for å velge mellom et stort utvalg programmeringsspråk.

For å utvikle algoritmen vurderer gruppen flere ulike verktøy. Programmeringsspråkene C, C++ og C#

er noen av de mest aktuelle kandidatene da dette er verktøy som alle gruppens medlemmer kjenner

godt og har mye erfaring med. LabView er et annet verktøy som vurderes, men siden ingen av

gruppemedlemmene har nevneverdig erfaring med dette programmet eller dens

programmeringsverktøy er C, C++ eller C# tryggere alternativer. I tillegg vurderes programmerings-

og simuleringsprogrammet MATLAB, men også her mangler gruppen tilstrekkelig erfaring til å gjøre

dette til et trygt valg. I lys av disse vurderingene har gruppen besluttet å bruke

programmeringsspråket C# til å utvikle algoritmen.

En annen vurdering gruppen må ta stilling til er om det skal kjøpes inn en radiostyrt båt eller om det

skal bygges en båt fra grunnen av ved bruk av isopor. Fordelene med å kjøpe en ferdig båt er at man

slipper å bruke tid på å bygge selve båten og man slipper også å montere motor, propell og ror.

Fordelene med å bygge båten fra grunnen av er at man i større grad kan bestemme hvilke

egenskaper båten skal ha. I dette prosjektet er det viktig at båten har de rette egenskapene til å

oppfylle kravene fremmet i oppgavens kravspesifikasjon. Den må være stabil og stor nok til å få plass

til alle komponentene. Sammen med oppdragsgiver mener gruppen at det beste alternativet vil være

å lage båten fra grunnen av.

3.2 Konklusjon Etter å ha ettertrykkelig vurdert flere underliggende faktorer som gjennomførbarhet, læringsutbytte

og samsvar med kravspesifikasjonen, har gruppen i dialog med oppdragsgiver kommet frem til at det

beste alternativet vil være for gruppen å lage et modellfartøy fra bunnen av. Dette gir størst grad av

frihet og fleksibilitet når det kommer til design og utforming, og vil forsikre at modellen vil inneha de

egenskapene som må til for at prosjektet skal kunne bli en suksess. Hva styringsenheten angår er det

blitt bestemt å gå for en mikro-PC da det gir høy grad av fleksibilitet med tanke på valg av

programvare og andre kritiske faktorer.


Rev: v1.00 13(62) 01.06.16

4 Realisering av valgt løsning I delkapittel 3.2 «Konklusjon» valgte gruppen i dialog med oppdragsgiver å prøve å realisere

løsningsalternativ 2: å lage en modellbåt fra bunnen av. Til programvare- og algoritmeutvikling er

programmeringsspråkene C# og Python benyttet, og de integrerte utviklingsverktøyene Microsoft

Visual Studio 2013 (VS2013) og Python 3 IDLE tatt i bruk for utvikling på henholdsvis PC og Raspberry

Pi. I dette kapitlet inndeles realiseringen av programvaren og den fysiske modellen i to separate

delkapitler for å gi en så klar og konsis gjengivelse av prosessen som mulig.

4.1 Programvare

4.1.1 Utviklingsløp

I løpet av den første uken etter at forprosjektet var ferdigstilt og innlevert hadde gruppen et møte

med oppdragsgiver for å diskutere forskjellige muligheter for hvordan oppgaven skulle angripes. I

dette møtet ble av oppdragsgiver stipulert at før arbeidet med konstruksjon og utvikling det fysiske

systemet kunne begynne, var det nødvendig å utføre datasimulering og virtuell testing av foreslåtte

styringsalgoritmer for at gruppen bedre skulle forstå problemstillingen og dermed ha et bedre

utgangspunkt for utførelsen av resten av prosjektet.

Som respons til dette ble det innad i gruppen kommet til enighet om at den mest lærerike og givende

måten å takle denne nye utfordringen var å skrive et komplett simulatorprogram fra bunnen av. Til å

utvikle dette programmet valgte gruppen å benytte seg av VS2013 og C# i og med at det er den

plattformen alle gruppemedlemmene har mest erfaring med og bredest kjennskap til.

Arbeidet med å utvikle den nødvendige programvaren tiltrådde i begynnelsen av februar måned,

rundt en uke etter at forprøven var levert, og involverte i første omgang utvikling av

simulatorprogrammet. Underveis i denne prosessen ble arbeidet med å få i gang algoritme-

utviklingen initiert, og deretter fortsatte disse to aktivitetene parallelt frem til simulatorens

ferdigstilling i begynnelsen av mars måned.

Ved slutten av simulatorens utviklingsløp, samt etter dens fullførelse ble det utført grundig testing av

de aktuelle styringsalgoritmene for finne den beste kandidaten å ta med videre i prosjektet. Denne

prosessen står beskrevet mer detaljert i kapittel 5.

Når gruppemedlemmene i samtaler med oppdragsgiver kom til enighet over hvilken algoritme som

oppførte seg mest lovende og dermed ble valgt ut som hovedkandidat til å implementeres på den

fysiske modellen, ble det gått til innkjøp av Raspberry Pi og GPS-modul, noe som igangsatt den siste

fasen av utviklingsløpet hva prosjektets programvare angår.

I denne siste fasen av utviklingsløpet ble det all hovedsak fokusert på få bygget styringsprogrammet

som kjører på Raspberry Pi-enheten og suksessfullt implementere den utvalgte algoritmen i

programmet. På bakgrunn av det utviklingsløpet som er beskrevet i denne seksjonen vil det være

rimelig å dele prosjektets programvareutvikling inn i tre separate deler, selv om det inngår en viss

overlapping mellom disse delene med hensyn på tidsrammene for utviklingen. I seksjonene under vil

hver av disse beskrives og utredes i større detalj.


Rev: v1.00 14(62) 01.06.16

4.1.2 Simulatoren

Simulatorprogrammet er utviklet av gruppen fra bunnen av og representerer den første av de store

milepælene i prosjektet. Programmet simulerer bevegelsen til et sjøfartøy med konstant fremdrift og

ett sentralt ror i vann med og uten vannstrømmer av varierende styrke og retning. Fartøyets

bevegelse bestemmes av en styringsalgoritme som kontrollerer rorets vinkel basert på kalkulasjoner

av forskjellige målbare parametere som fart, avstand og retning i forhold til et gitt punkt som

representerer fartøyets måldestinasjon. Hensikten med programmet er å muliggjøre utforming og

testing forskjellige autonome styringsalgoritmer for et slikt fartøy på en mest mulig effektiv måte,

samt å kunne observere hvordan disse oppfører seg under varierende forhold. Målet med dette er å

kunne utarbeide en så god som mulig styringsalgoritme for videre bruk i prosjektet, samt å kunne ha

den klar for implementasjon på det fysiske systemet så tidlig som mulig.

Programmet har et oversiktlig og intuitivt brukergrensesnitt som gjengitt på figuren under. For

detaljert brukerdokumentasjon og instrukser på hvordan simulatoren opereres, referer til rapportens

appendiks D.1.

Figur 4.1-1: Skjermbilde av simulatorens grafiske brukergrensesnitt

4.1.2.1 Simulatorens oppbygning

Simulatoren er realisert ved å ta i bruk Microsoft sitt .NET Framework. Dette er et komplett

utviklingsrammeverk laget av Microsoft som unifiserer utvikling mot alle plattformer forbundet med

Microsoft og Windows. Simulatoren er skrevet fra bunnen av som et Windows Presentation

Foundation (WPF) prosjekt i Microsoft Visual Studio 2013. WPF er et av .NET rammeverkets kraftigste

og mest fleksible system for utvikling av programmer som gjør bruk av et grafisk brukergrensesnitt. I

et WPF prosjekt beskrives programmets logikk og oppførsel ved hjelp av C# kode, mens det grafiske

brukergrensesnittet blir definert ved hjelp av Extensible Application Markup Language (XAML), et

deklarativt markeringsspråk basert på Extensible Markup Language (XML). Denne seksjonen vil i all

hovedsak begrense seg til å beskrive simulatorens programlogikk og oppførsel, og vil ikke gå i detalj


Rev: v1.00 15(62) 01.06.16

på hvordan brukergrensesnittet er laget da dette ikke fremstår som relevant for forståelsen av

hverken algoritmene eller simulatorens funksjonalitet.

Simulatorens programlogikk er delt inn i tre logisk (men ikke nødvendigvis visuelt) separate deler

som satt sammen utformer simulatorens programmatiske oppbygning i sin helhet. Disse delene

beskrives nærmere i punktene under.

4.1.2.1.1 Simuleringsmotoren

Dette er selve grunnpilaren i programlogikken. All ytterlig funksjonalitet i programmet avhenger av

denne, og dens utvikling framstod som den første virkelig store utfordringen i den tidlige fasen av

prosjektet. Simuleringsmotoren drives av et virtuelt tidsur som kontinuerlig sender ut et signal med

et bestemt intervall. Lengden på dette intervallet bestemmer farten på simuleringen, da

variabeloppdateringer og beregninger kun blir gjennomført når det kommer et nytt «tikk» fra dette

tidsuret. Disse operasjonene utføres i hovedsak av en funksjon (med flere mindre hjelpefunksjoner)

som ved hjelp av matematiske beregninger flytter et punkt i et to-dimensjonalt koordinatsystem

basert på en enkelt input-verdi. Input-verdien er et desimaltall begrenset til verdier mellom -35,0 og

+35,0 og representerer rorvinkelen til et tiltenkt sjøfartøy (hvor en verdi på null angir at roret er i

nøytral posisjon, 35 er maks utslag mot venstre og -35 er maks utslag mot høyre). Punktet som flyttes

representerer midtpunktet til sjøfartøyet og brukes som ankerpunkt for fartøyets visuelle gjengivelse

i det grafiske brukergrensesnittet.

For å beregne fartøyets/punktets bevegelsesbane i koordinatsystemet brukes en parametrisering av

dens x- og y-koordinater som tar utgangspunkt i polarkoordinater, men med visse modifikasjoner

som tar hensyn til en justering i koordinatsystemets orientering og en alternativ definisjon av

nullpunkt og retning av rotasjon om enhetssirkelen. Koordinatsystemet er definert med positiv x-

retning mot høyre som vanlig, men med positiv y-retning nedover, altså invertert i forhold til det

klassiske xy-koordinatsystemet. Dette er gjort av hensyn til hvordan objekter gjengis visuelt av de

verktøyene som er tilgjengelig for grafisk presentasjon i en WPF-applikasjon. I tillegg defineres null

grader rett oppover i aksesystemet (negativ y-retning), og positiv økning av vinkelstørrelse i forhold

til null foregår ved bevegelse rundt enhetssirkelen med klokken i stedet for mot klokken. Denne

modifiseringen er gjort for å gjøre det så enkelt som mulig å implementere algoritmer basert på den

mest utbredte formen for sjønavigasjon, der vinkler regnes som økende med klokkeretningen og null

grader alltid peker i retning nord.


Rev: v1.00 16(62) 01.06.16

Figur 4.1-2: Simulatorens definerte akseretninger og modifiserte enhetssirkel

Punktet kan i utgangspunktet kun bevege seg i sirkelbaner der svingradiusen er gitt som en funksjon

av rorvinkelen. Dette tillater likevel bevegelse langs en rett linje dersom rorvinkelen er null, da en slik

bane kan regnes som en sirkelbane med uendelig stor svingradius. En bevegelsene fra et

punkt (𝑥0, 𝑦0) til et nytt punkt (𝑥, 𝑦) beskrives av følgende likningssett:

𝑥 = 𝑥0 ± 𝑣 ∙ sin 𝜃

𝑦 = 𝑦0 − 𝑣 ∙ cos 𝜃

der 𝑣 representerer fartøyets fart (som matematisk sett er det samme som buelengden til

sirkelbanen fra (𝑥0, 𝑦0) til (𝑥, 𝑦)) og 𝜃 representerer en vinkel hvis verdi er summen av kvotienten til

fart dividert på svingradius akkumulert for hver bevegelse siden sist gang rorvinkelen forandret

fortegn. Bevegelse i x-retning vil bli addert eller subtrahert avhengig om rorvinkelen er positiv eller

negativ.

I tillegg til den overnevnte sirkelbevegelsen kan punktet forskyves lineært i x- og y-retning for å

muliggjøre simulering av uniforme vannstrømmer som vil kunne påvirke det tenkte fartøyet. Den

komplette formen for de grunnleggende bevegelsesbanelikningene blir da:

𝑥 = 𝑥0 ± 𝑣 ∙ sin 𝜃 + 𝑥𝑠𝑡𝑟ø𝑚

𝑦 = 𝑦0 − 𝑣 ∙ cos 𝜃 + 𝑦𝑠𝑡𝑟ø𝑚

hvor 𝑥𝑠𝑡𝑟ø𝑚 og 𝑦𝑠𝑡𝑟ø𝑚 representerer vannstrømmens fart i henholdsvis x- og y-retning.


Rev: v1.00 17(62) 01.06.16

Disse likningene omfatter kjernen av simuleringsmotoren, men de er kun én del det sammensatte

systemet den består av. For å studere simulatormotoren i større detalj, referer til simulatorens

kildekode.

4.1.2.1.2 Generell logikk og håndtering av brukerinput

Hovedparten av denne delen av programlogikken består av funksjoner som tolker input fra bruker og

utfører de nødvendige operasjoner slik de er spesifisert. Disse funksjonene kalles «Event Handlers»

og kalles automatisk av det underliggende rammeverket når det oppstår spesifikke hendelser. En

hendelse i denne konteksten representerer en forhåndsdefinert input fra bruker, og hver definerte

hendelse er koblet til en spesifikk Event Handler. Generelt sett håndterer disse funksjonene justering

av verdien til de forskjellige simulerings-parameterne, men også direkte utskiftning av hvilken

algoritme som utføres under simuleringen. For å kunne skifte ut hvilke algoritmer som eksekveres

mens programmet kjører benyttes en avansert funksjonalitet i C# språket kalt delegater. En delegat

opererer som en peker til en eller flere funksjoner, og ved å skifte ut hvilken funksjon som pekes på

av en gitt delegat kan den samme delegaten brukes til å kalle en rekke forskjellige funksjoner i løpet

av sin livstid. De resterende funksjonene i denne blokken utfører forskjellige vedlikeholdsoppgaver

som oppdatering av variabler og generering av nye målkoordinater, samt annen generell

støttefunksjonalitet.

4.1.2.1.3 Styringsalgoritmer

Denne delen består av algoritmene som skal testes ved hjelp av simulatoren. Hver algoritme

defineres som en egen funksjon og legges til i en delegatliste (se forrige avsnitt for en forklaring av

delegater i C#). På denne måten er det enkelt å legge til nye algoritmer for testing, samt skifte ut

hvilken algoritme som er aktiv til enhver tid. Algoritmene må realiseres i gyldig C#-kode men står

ellers fritt til å defineres etter ønske og behov, og kan med fordel gjøre bruk av en stor del av de

støttefunksjonene som er kategorisert under punkt 4.1.2.1.2.

4.1.2.2 Simulatorens funksjonalitet

Simulatoren har et grafisk brukergrensesnitt som vist på figuren over. Ved hjelp av dette

grensesnittet kan en bruker styre simulatoren og justere et antall forskjellige innstillinger for å

påvirke både de simulerte forholdene og selve simuleringsparameterne. Brukergrensesnittet er delt

inn i to deler: et virtuelt lerret der selve simuleringen gjengis og animeres visuelt, og et panel der

bruker kan styre simuleringen og justere diverse parametere. I dette panelet vises også forskjellige

relevante data avhengig av hvilken algoritme som er valgt.

Det simulerte fartøyets faktiske posisjon og bevegelsesretning representeres på lerretet av et grønt

pentagon der den spisse enden peker i retning av fartøyets nåværende kjøreretning.

Måldestinasjonen representeres av en rød sirkel, og kan flyttes til en ny tilfeldig generert posisjon

innenfor lerretets grenser med et knappetrykk.

Programmet er utstyrt med verktøy som lar bruker simulere usikkerhet i fartøyets posisjonssystem,

og dersom dette benyttes vil en mindre opak versjon av fartøyet som representerer dens målte


Rev: v1.00 18(62) 01.06.16

posisjon kunne vises på lerretet. Det er også bygget inn muligheter for simulering av havstrømmer

med justerbar retning og styrke, der strømmens retning visualiseres av en retningsindikator i nedre

høyre hjørne på lerretet.

Simulatoren kan kjøres i to forskjellige modi: algoritme og manuell. Så lenge simulatoren står i

algoritmemodus benyttes den valgte styringsalgoritmen til å kontrollere fartøyets rorvinkel, mens i

manuell modus kan bruker justere rorvinkelen fritt. Uavhengig av hvilken modus som er valgt kan

bruker justere fartøyets fart, svingradius og styrken til havstrømmene i x- og y-retning, samt pause,

omstarte og resette animasjonen (dersom algoritmemodus er valgt, gjelder dette også den

underliggende simuleringen). Dersom algoritme-modus er valgt åpnes det i tillegg opp for å la bruker

velge mellom forskjellige algoritmer mens simuleringen kjører, samt justere simulasjonshastighet,

simulert måleusikkerhet og intervallet mellom hver gang den valgte algoritmen eksekveres.

4.1.3 Algoritmene

I dialog med oppdragsgiver kom gruppen i løpet av algoritmeutviklingsfasen frem til tre forskjellige

algoritmer som utpekte seg som hovedkandidater for implementasjon i det endelige systemet.

Kriteriene brukt til å vurdere potensielle kandidatalgoritmer under seleksjonsprosessen består av

følgende punkter opplistet i rekkefølge fra høyeste til laveste prioritet:

1. I hvilken grad den gitte algoritmen oppfyller kravene angitt i kravspesifikasjonen.

2. Antatt effektivitet i forhold til ressursbruk ved kjøring av gitt algoritme som programkode.

3. Vanskelighetsgrad assosiert med oversettelse av algoritme til eksekverbar programkode.

Gitt prosesseringskraften som kan ytes av dagens datamaskiner, samt fleksibiliteten og

funksjonalitetsbredden tilbudt av moderne programmeringsspråk, fremstod aldri punkt 2 og 3 som

nevneverdig relevant i forhold til valg av kandidatalgoritmer. De representerer likevel kriterier som er

viktig å ta hensyn til, og som kunne hatt mye å si dersom oppnåelse av ønsket oppførsel var avhengig

av utførelse av tunge matematiske operasjoner, eller krevde store mengder ressurser i form av

dataminne eller parallell prosesseringskapasitet.

De tre kandidatalgoritmene som ble kommet frem til i løpet av utviklingsprosessen vil bli beskrevet i

de følgene tre seksjonene.

4.1.3.1 Algoritme 1 – Avstand til målet

Denne algoritmen ble først foreslått av oppdragsgiver ved prosjektets begynnelse, allerede før

forstudieprosjektet var ferdigstilt og baserer seg på et veldig simpelt premiss. Algoritmen utføres ved

å foreta en kalkulasjon av avstanden fra fartøyets posisjon til dens destinasjon, informert av to sett

med koordinater som representerer disse punktene. I denne algoritmen vil roret alltid være rotert

enten mot styrbord eller babord i en fast vinkel, og dersom verdien til den nyeste kalkulerte

avstanden er større enn den forrige, vil roret skifte posisjon. Så lenge den nyeste kalkulerte

avstanden er mindre eller like stor som den forrige, forblir roret i samme posisjon. I teorien skal

algoritmen da alltid holde fartøyet på en kurs som fører den nærmere målet enn før.


Rev: v1.00 19(62) 01.06.16

4.1.3.2 Algoritme 2 – Fart mot målet

Dette er en algoritme som konseptuelt sett har mange likheter med algoritme 1, og som også først

ble foreslått av oppdragsgiver. I denne algoritmen er det derimot fartøyets fart i retning av målet

som er den kritiske faktoren. Fartøyets hastighet kalkuleres som en vektor bestående av to

komponenter; distansen fartøyet dekker i henholdsvis x- (øst/vest) og y- (nord/sør) retning mellom

hver gang dens gjeldende posisjon oppdateres. Skalarverdien av komponenten til hastighetsvektoren

som peker i samme retning som en vektor 𝑟 utstrakt fra fartøyets posisjon til målets posisjon

representerer fartøyets fart i målets retning. Denne verdien kan kalkuleres ved å utføre en

skalarprojeksjon av fartøyets hastighetsvektor �⃗� på overnevnte vektor 𝑟. Til dette benyttes følgende

formel:

𝑓 = �⃗� ∙ 𝑟

‖𝑟‖

der 𝑓 representerer skalarprojeksjonen av �⃗� på 𝑟.

Ved å ta i bruk samme prinsipp som i algoritme 1, baserer denne algoritmen seg på å utføre

kalkulasjoner av fartøyets fart mot målet og sjekke dens sist kalkulerte verdi mot den forrige. Dersom

den nyeste verdien er mindre enn den forrige, noe som vil si at en mindre komponent av fartøyets

hastighet er rettet mot målet enn før, vil rorets posisjon skiftes slik at fartøyet svinger i motsatt

retning. Dersom farten mot målet er blitt større enn før, eller holder seg på samme verdi, blir ingen

handlinger utført og fartøyet fortsetter langs samme sirkelbane.

4.1.3.3 Algoritme 3 – Heading + Bearing

Den tredje kandidatalgoritmen ble unnfanget og utviklet i sin helhet internt i gruppen og gjør bruk av

to velkjente og utbredte konsepter innen sjønavigasjon: Heading og Bearing. Et fartøys Heading

representerer dens bevegelsesretning som en vinkel gitt i forhold til nord presentert i grader. Bearing

representerer retningen til en vektor med opprinnelse i fartøyets posisjon og som strekker seg til en

gitt destinasjon. En Heading eller Bearing med verdiene 0, 90, 180 og 270 grader henviser til

retningen av henholdsvis nord, øst, sør og vest uansett hvor en befinner seg på jordens overflate.

Figur 4.1-3: Navigasjonssirkelen


Rev: v1.00 20(62) 01.06.16

Algoritme 3 opererer ved å kalkulere fartøyets Heading og Bearing, samt differansen mellom disse

verdiene for deretter å utføre en bestemt handling basert på resultatet av disse kalkulasjonene.

For å kalkulere Heading benyttes koordinatene til fartøyets nåværende posisjon som angitt av en

GPS-mottaker, samt koordinatene fra forrige måling som parametere. Dette gir kun en

approksimasjon av den egentlige Headingen, hvis nøyaktighet avhenger av tidsavstanden mellom de

to målingene, der hyppigere målinger tilsvarer en mer nøyaktig approksimering, samt feilmarginen i

målingene foretatt av GPS-systemet. Kalkulering av Bearing foregår matematisk identisk som for

Heading, men tar i stedet for koordinatene til fartøyets forrige målte posisjon i bruk det gitte målets

posisjonskoordinater som sitt andre sin andre parameter. For denne kalkulasjonen avhenger

nøyaktigheten kun av usikkerheten til GPS-målingene.

Når algoritmen har kommet frem til verdier for fartøyets Heading og Bearing, justerer den fartøyets

rorvinkel basert på en kombinasjon av disse verdiene, samt differansen mellom dem. Den eksakte

logikken som legges til grunn for algoritmens oppførsel kan studeres i styringsmodulens kildekode

som ligger vedlagt under rapportens Appendiks F, men den grunnleggende idéen kan beskrives ved

at dersom Bearing ligger til høyre for Heading på navigasjonssirkelen vil fartøyet svinge til høyre,

mens dersom det motsatte er tilfelle vil den naturlig nok svinge mot venstre. Siden graden av

forskjell mellom faktisk bevegelsesretning (Heading) og ønsket bevegelsesretning (Bearing) er gitt

som en del av algoritmens kalkulasjoner, støtter algoritme 3 som den eneste av kandidatalgoritmene

dynamisk justering av rorvinkel basert på denne differansen.

4.1.4 Raspberry Pi styringsmodul

Styringsmodulen som er implementert på Raspberry Pi-enheten kontrollerer, via en servomotor,

hovedroret til modellfartøyet basert på GPS-koordinater hentet ut fra GPS-modulen og oppfører seg

som «hjernen» til det fysiske systemet. Modulen består av et Python-skript, det vil si et program der

kildekoden eksekveres sekvensielt fra topp til bunn, og er skrevet med Python 3.4, den nyeste

versjonen av Python-programmeringsspråket. Programmets sekvensielle natur gjør at kildekoden

fremstår som ukomplisert og lett å følge hvis en er kjent med Python-syntaksen.

På et tidlig tidspunkt i modulens utviklingsfase ble det eksperimentert med å skrive koden i Java

grunnet enkelte av gruppemedlemmenes høyere nivå av familiaritet med dette

programmeringsspråket. Grunnen til at valget i hovedsak stod mellom Java og Python bunnet ut i

problemene gruppen opplevde med å få Raspberry Pi-enheten koblet til internett i løpet av de første

ukene etter at den ble anskaffet, da operativsystemet kun kom utstyrt med utviklingsmiljøer rettet

mot disse to språkene. Til slutt falt valget på Python takket vært et brukervennlig og lett tilgjengelig

kodebibliotek rettet mot kommunikasjon med, og manipulasjon av, GPS-modulen.

I motsetning til simulatoren er ikke styringsmodulen utstyrt med noen form for grensesnitt, hverken

grafisk eller ikke, som lar bruker foreta justeringer av programmet mens det kjører. Av denne

grunnen må all innstilling av variabler som målkoordinater og lengden på intervallet mellom hver

algoritme-eksekvering gjøres direkte i kildekoden før skriptet kjøres. Brukerdokumentasjon angående

bruk og justering av styringsmodulen finnes i appendiks D.1.


Rev: v1.00 21(62) 01.06.16

Programmet kommuniserer med GPS-enheten ved hjelp av ferdigbygde funksjoner definert i et

kodebibliotek som automatisk installeres sammen med GPS-modulens drivere. Når disse funksjonene

kalles returnerer de hver sin liste som alle inneholder en kombinasjon av mer eller mindre relevante

data fra GPS-modulen. Programmet sorterer ut de interessante verdiene, i dette tilfellet lengde- og

breddegrader angitt på desimalform, og lagrer dem i relevante variabler i kildekoden. Deretter

kalkuleres systemets Heading og Bearing, som til slutt brukes til å bestemme hvilken vei fartøyet skal

svinge etter førstkommende gjennomkjøring av algoritmen.

For å styre den tilkoblede servomotoren, og som en konsekvens, roret og til slutt selve fartøyet, gjør

modulen bruk et annet kodebibliotek som lar det simulere et Pulse Width Modulation (PWM) signal

på den utgangen som er koblet til servomotorens PWM-inngang. Ved å generere et virtuelt PWM-

signal med en frekvens på 100 Hz og variere pulsvidden fra 10 til 20 prosent (ved 100 Hz tilsvarer

dette pulsvidder fra 1 til 2 ms) vil utslaget på servomotoren ha et spenn på rundt 60 grader.

Programmet implementerer grunnleggende feilhåndtering og vil kjøre i en kontinuerlig sløyfe helt til

det enten får beskjed av bruker om å avslutte eller det oppstår en kritisk feil som ikke er tatt høyde

for under modulens utvikling og derfor ikke blir håndtert av programkoden.

4.1.5 Øvrig programvare og utviklingsverktøy

Det er i løpet av prosjektets gang tatt i bruk et antall ferdigutviklede data- og

programmeringsverktøy, samt kommersielt tilgjengelige programmer for utførelse av forskjellige

prosjektrelevante oppgaver. I denne seksjonen finnes beskrivelser av de viktigste og mest brukte av

disse programvarene.

4.1.5.1 Microsoft Visual Studio 2013

VS2013 er et såkalt integrert utviklingsmiljø fra Microsoft som kan brukes til å utvikle programvare

for en rekke forskjellige plattformer og som støtter et stort antall forskjellige programmeringsspråk.

Det egner seg likevel best til utvikling rettet mot Microsofts .NET Framework og de plattformene som

er assosiert med dette rammeverket. At det er et Integrert utviklingsmiljø betyr at programmet i

tillegg til å kompilere kode til eksekverbar programvare, også inkluderer en mengde ekstra

funksjonalitet og verktøy som hjelper brukeren og gjør kodeopplevelsen mer strømlinjeformet og

effektiv. VS2013 er et programmeringsverktøy som alle gruppemedlemmene har ekstensiv erfaring

med og derfor velegnet til bruk i prosjektet.

4.1.5.2 Python 3 IDLE

Python 3 IDLE er et integrert utviklingsmiljø for skriving og kompilering av Python 3 programvare.

Sammenlignet med Visual Studio er det relativt fatting på funksjonalitet, men det har likevel nok

verktøy til å gjøre utviklingsprosessen betydelig lettere i forhold til bruk av en vanlig teksteditor til å

skrive koden i. Programmets relative simplisitet i forhold til andre tyngre programvarer av samme

type gjør det lettere for en ny bruker å mestre, og hvis brukeren ikke skal skrive veldig lang og

komplisert kode er den kanskje til og med være et bedre valg enn en mer kompleks konkurrerende

programvare. Python 3 IDLE ble tatt i bruk av gruppen under utviklingen av styringsmodulen på


Rev: v1.00 22(62) 01.06.16

Raspberry Pi-enheten ettersom det kom pre-installert på maskinen sammen med operativsystemet.

Ingen av gruppemedlemmene hadde erfaring med programmet fra før, det fremstod som

uproblematisk for samtlige medlemmer å sette seg inn i det på kort tid.

4.1.5.3 Google Earth

I hovedparten av testene som involverer bruk av GPS-modulen har det vært nødvendig å kunne

plotte en liste med koordinater over et kart for å lettere kunne analysere de respektive

testresultatene. I disse tilfellene har Google Earth vist seg å være et uvurderlig verktøy og en stor

hjelp i å akselerere prosjektets fremgang. Programvaren er i utgangspunktet en virtuell modell av

jordkloden med nøyaktige kart og satellittfotografier og har innebygget funksjonalitet som lar

brukeren effektivt plotte store mengder GPS-koordinater ved hjelp av å lagre dataene som en

Keyhole Markup Language (KML) fil og åpne den i programmet. Ved å ta i bruk Google Earth har

gruppen drastisk økt sin evne til å prosessere og analysere test-data, og dermed lettere kunnet

utføre de systemmodifikasjoner som har vært nødvendige for prosjektets fremgang.

Styringsmodulen logger all mottatt GPS-aktivitet til .txt-filer ferdig formatert med hensyn til den

formateringen Google Earth krever for å kunne lese filene korrekt. Innholdet i .txt-filene må likevel

først kopieres til Microsoft Excel og lagres som en .csv-fil før dataene til slutt kan konverteres til KML-

formatet via en nettside [1].

4.2 Fysisk system og maskinvare Det fysiske systemet er sammensatt av flere undersystemer som omfatter styring via algoritme,

fremdrift og manuell overstyring via en radiokontroller. Systemet består av en 1,5 meter lang

modellbåt modifisert med en rekke elektroniske og mekaniske komponenter for å sørge for at den

svarer til kravspesifikasjonen.

De viktigste og dyreste av de elektroniske maskinvarekomponentene som er tatt i bruk av det fysiske

systemet er kjøpt inn fra via oppdragsgiver fra den norske grenen av den internasjonale internett-

baserte elektronikkleverandøren Premier Farnell. Komponenter av nevneverdig betydning som er

kjøpt inn gjennom Farnell består av følgende:

1 stykk Raspberry Pi 2 Model B mikro-PC.

1 stykk Microstack L80 GPS modul for Raspberry Pi.

1 stykk MEA GPS-S antenne

Det er også kjøpt inn komponenter til bruk for fremdrift av fartøyet i form av en radiokontrollert (RC)

modellbåt som inneholder motor med fremdriftslinje og et ror koblet til en servomotor. I tillegg har

både oppdragsgiver og høgskolen bidratt med en del utstyr som en servomotor, en DX3E

radiokontroll, en vannpumpe til å drive båtens kjølesystem og en Spektrum MR3000 radiofrekvens

(RF) sender. Systemet gjør også bruk av 3 separate AA- batteripakker som hver yter 6 V, et 7,2 V

batteri og et 5 V oppladbart batteri med solceller for å generere nok strøm til å gjøre bruk av

systemets fulle kapasitet.

De forskjellige komponentene og deres funksjon beskrives nærmere i de neste underkapitlene.


Rev: v1.00 23(62) 01.06.16

Figur 4.2-1: Det fysiske systemet

4.2.1 Modellfartøy

Modellfartøyet har et skrog bestående av en spesiell type vannresistent isopor, og er utformet med

dimensjonene 150,0 cm, 40,0 cm og 10,0 cm for henholdsvis lengde, bredde og høyde. Bruken av

dette materialet gir båten særdeles god flyteevne, mens den strømlinjeformede utformingen sørger

for at den glir gjennom vannet med minimal motstand. Langs undersiden av båten er det montert en

aluminiumskjøl en meter i lengde som stikker litt over 25 cm vertikalt ned i vannet og sørger for å gi

fartøyet økt stabilitet og manøvreringsevne ved sterke vind- og vannstrømmer. Overstyringsroret er

festet akterut av aluminiumskjølen og måler 8,0 cm i lengde og 22,5 cm i høyde. Roret er kalibrert til

å kunne svinge tretti grader i både babord og styrbord retning og kontrolleres via en aksling som går

vertikalt gjennom hele skroget og den radiostyrte modellbåten på akter. På enden av denne

akslingen er det festet en liten arm som dreies av en styrestang. Lengden på styrestangen er 51 cm

og den strekker seg helt til broen, hvor servomotoren befinner seg.

Broen befinner seg midtskips og er inneholdt i en oppbevaringsboks av plast limt fast til dekket.

Oppbevaringsboksen er blitt brukt for å kunne verne mot vannsprut miljøhasarder. Akterut for

skroget er det limt fast en mindre modellbåt med innebygget styring og fremdrift. Innholdet i

modellbåten består av motor med fremdriftslinje, regulator, propell, ror tilkoblet en servomotor og

vannpumpe for kjøling av motorlager og regulator. I tillegg har det blitt installert batteri til både

motor og vannpumpe. Roret har dimensjonene 10,0 cm i høyde og 5,5 cm i lengde og regnes som

systemets hovedror selv om det er mindre enn overstyringsroret, i og med at er dette roret som

kontrolleres av algoritmen og derfor er ansvarlig for systemets autonome navigasjon. Fra broen til

modellbåten går det to kabler, en for styring av algoritmeroret og en annen for styring av motor.


Rev: v1.00 24(62) 01.06.16

Kablene er pakket inn i krympestrømper av plast og teipet i endene for å beskyttes mot potensielle

skader fra miljøet.

4.2.2 Raspberry Pi

Figur 4.2-2: Raspberry Pi 2 Model B (Hentet fra www.raspberrypi.org)

Raspberry Pi 2 Model B er valgt som systemets sentrale prosesseringsenhet. Dette er en liten

datamaskin bygget på et enkelt kretskort som blant annet inneholder 36 programmerbare General-

purpose Input/Output (GPIO) koblingspinner, en Ethernetport og fire USB-innganger. Datamaskinen

kjører operativsystemet Raspbian som er en avgrening av Debian, et utbredt operativsystem basert

på Linux. Ved mottakelse av datamaskinen var det nødvendig å installere, oppdatere og konfigurere

systemet for å gjøre det kapabelt til å utføre de nødvendige oppgavene et slikt prosjekt krever. Det

ble kjørt en test som beskrevet i kapittel 5.2 for å verifisere at systemet fungerte, samt luke ut og

reparere eventuelle feil. Raspberry Pi krever en liten ekstern lagringsplass i form av et mikro Secure

Digital (SD) kort, og et slikt kort med 4 GB lagringsplass er tatt i bruk til dette formålet.

Med denne datamaskinen har gruppen ved hjelp av programmeringsspråket Python, et språk som

har god støtte på denne plattformen i form av både integrerte utviklingsmiljøer og ferdiglagde

kodebiblioteker, kunnet oversette, implementere og teste algoritmen i virkelige omgivelser.

Signaloverføring fra Raspberry Pi til servomotor, samt avlesning av datastrøm fra GPS-mottaker

muliggjøres ved å benytte de forskjellige GPIO koblingspinnene inneholdt på kretskortet. Et

koblingsskjema av det fysiske styringssystemets oppsett finnes under Appendiks E.

http://www.raspberrypi.org/


Rev: v1.00 25(62) 01.06.16

4.2.3 GPS

Figur 4.2-3: Microstack L80 GPS (Hentet fra www.element14.com)

GPS-mottakeren som er valgt ut er en Microstack Add-On Board L80 GPS, et produkt som er støttet

av Raspberry Pi. Den har en lav Time to First Fix (TTFF), det vil si tiden mottakeren bruker for å kunne

kalkulere sin første posisjon. GPS-mottakeren er en liten komponent med lav vekt som trekker

relativt lite strøm og spenning, har en høy oppdateringsrate og en innebygget buffer som har

mulighet til å lagre all data mottatt i løpet av en sesjon. En ekstra, kraftigere antenne ble kjøpt inn for

å lettere kunne få signal. Av mottakerens 12 koblingspinner er det kun fire som er nødvendig å ta i

bruk for avlesing av data [2]. To av disse går med til strømtilførsel (3,3 V og jord) og de to andre til

dataoverføring. Kommunikasjon mellom GPS-mottakeren og Raspberry Pi foregår serielt, med

forskjellige inn- og utganger for å motta og sende data. På Raspberry Pi-enheten sin side brukes to

dedikerte GPIO-koblingspinner. GPS-mottakeren har i tillegg en Pulse Per Second (PPS) utgang som

kan tas i bruk dersom det er behov for veldig nøyaktig timing- og synkroniseringsfunksjonalitet, men

dette har ikke vært ansett som nødvendig for utførelsen av prosjektet.

4.2.4 Servomotor

Figur 4.2-4: Hitec HS-325HB (Hentet fra http://hitecrcd.com)

Servomotoren som styrer overstyringsroret er en 3-pols elektromotor fra selskapet Hitec som kan

kjøres ved å supplere fra 4,8 til 6,0 V, noe som vil gi en rotasjonshastighet fra henholdsvis 0,19 til

0,15 sekunder per 60 grader [3]. Servomotoren styres ved hjelp av et PWM-signal der posisjonen til

svingarmen er avhengig av pulsbredden til signalet. Den eksakte pulsoppdateringsraten som benyttes

er ikke kjent, men de fleste av Hitec sine servomotorer ønsker en oppdateringsrate på 200 Hz der en

pulsbredde på 1,5 ms vil sette svingarmen i senterposisjon [4].

http://www.element14.com/

http://hitecrcd.com/


Rev: v1.00 26(62) 01.06.16

4.2.5 Radiokontroll

For å kunne overstyre modellfartøyet er det tatt i bruk et Digital Spectrum Modulation (DSM)

radiosystem som består av en RF-kontroller og -mottaker som kommuniserer over 2.4Ghz-

frekvensbåndet. Systemet er kapabelt til å utføre enveis radiokommunikasjon mellom et sett noder

og er produsert av det amerikanske selskapet Spektrum.

4.2.5.1 Spektrum MR3000

Figur 4.2-5: Spektrum MR3000 (Hentet fra www.spektrum.com)

Denne komponenten er en 3-kanals radiobølgemottaker som kan styre pådrag, styring og

kontrollering av en tilleggskomponent. Det er bare behov for styring og pådrag så kun to av de tre

kanalene er tatt i bruk. Styringen blir brukt for manøvrering av overstyringsroret og pådrag for

fremdriften av modellfartøyet. Enheten ble valgt fordi den er godt egnet for maritime forhold,

kompatibel med fjernstyringskontroll-enheten og fordi tilkoblingen til servomotoren og

fremdriftsmotoren er simpel. Mottakeren mottar radiofrekvente-signaler fra kontrollen og sender

videre signalene som elektriske pulser ved ulike bredder avhengig av pådrag og styring (PWM-

signaler). Enheten har et spenningsforsyningskrav på mellom 3,5 og 9,6 V [5], noe som hentes i fra en

batteripakke på 6 V.

4.2.5.2 Spektrum DX3E

Figur 4.2-6: Spektrum DX3E (Hentet fra http://horizonhobby.co.uk)

Fjernstyringskontrollen har et 3-kanals sendersystem som brukes til å sende signaler for styring og

pådrag til modellfartøyet. Hjulet på kontrollen brukes til å manøvrere styringen, mens spaken brukes

til å styre pådraget. Den har også et justerbart tuning-system hvor sensitiviteten til alle tre kanalene

kan justeres i begge retninger, samt ekstra justeringsmuligheter for senterposisjonen til styringen og

http://www.spektrum.com/

http://horizonhobby.co.uk/


Rev: v1.00 27(62) 01.06.16

nullposisjonen for spaken som kontrollerer pådraget. Kontrollen drives av fire stykk AA-batterier som

kan settes inn i bunnen av håndtaket [6].

4.2.6 Vannpumpe

For å oppnå tilstrekkelig kjøling av motorens regulator og lager er det installert en enkel vannpumpe

med innebygget kjøleribbe. Pumpen er en enkel vannpumpe som drives av en batteripakke på 6 V, og

er koblet til i enden av sløyfen etter motorlager og regulator. Den henter opp vann til systemet via et

rør som stikker ned gjennom vannoverflaten like bak propellen. En skjematisk oversikt over

kjølesystemet finnes i Appendiks E.3.

Figur 4.2-7: Vannpumpe til kjølesystem

4.2.7 Batteri/Strømforsyninger

Det er blitt anskaffet forskjellige batterier for å forsyne de ulike komponentene som trenger

strømforsyning. Raspberry Pi trenger en strømforsyning som leverer minimum 700 mA og 5 V, og det

er derfor blitt gått til innkjøpt av en oppladbar batteripakke med innebygget solcellepanel fra

Biltema. Servomotorene og vannpumpen trenger også strømforsyning, så til disse blir det kjøpt inn to

stk. batteriholdere fra Clas Ohlson der det blir satt inn fire stk. AA batterier i hver holder. Det er bare

kjøpt inn to batteriholdere da gruppen allerede var i besittelse av en batteriholder anskaffet av

oppdragsgiver. Motoren som styrer fremdriften til modellfartøyet bruker et 7,2 V Nikkel-Kadmium

(NiCd) batteri med en kapasitet på opptil 1800 mAh. Dette ble innkjøpt samtidig som RC båten på

butikken Radiostyrt Modellhobby.

Figur 4.2-8: Batteripakker


Rev: v1.00 28(62) 01.06.16

5 Testing Testene er oppdelt i følgende underkapitler, hvor stadig flere komponenter tas med i testene:

Simulering på pc

Testing av individuelle elektroniske komponenter

Testing av styresystem på land uten bruk av GPS

Testing av styresystem på land med bruk av GPS

Testing av fremdrift og manøvrering i bølgebasseng

Testing av komplett system på vann i virkelige omgivelser

5.1 Simulering på PC

5.1.1 Hensikt

Å simulere forskjellige algoritmeforslag og se hvordan de oppfører seg i henhold til

kravspesifikasjonen for å kunne finne den algoritmen som best egner seg til fullskala testing.

5.1.2 Gjennomføring

Hver av de tre kandidatalgoritmene ble kjørt gjennom en serie tester utført i simulatoren gruppen

bygget. Videre ble det introdusert utestående faktorer som havstrømmer og usikkerhet i fartøyets

egen posisjon i økende grad etter hvert i testingen. Simulatoren genererer automatisk et start- og

målpunkt, og algoritmene ble bedømt etter hvor effektivt og pålitelig de navigerte fartøyet frem til

målpunktet. Det ble tatt høyde for å kjøre flere simuleringer med samme faktorer for å få et større

og mer nøyaktig oversiktsbilde av resultatene. Interessante resultater som gruppen var på utkikk

etter inkluderer blant annet hvordan algoritmene styrer fartøyet, fra ingen utestående faktorer til og

med sterke utestående faktorer.

5.1.3 Resultat

De to første algoritmene (fart-mot-målet og avstand-til-målet) presterte ikke tilstrekkelig i henhold til

kriteriene lagt til grunn av kravspesifikasjonen. De dro seg lengre vekk fra destinasjonen i en

slangeformet bevegelse grunnet en grunnleggende svakhet i disse algoritmenes underliggende

logikk. Problemet viste seg å være at når fartøyet svinger vekk fra målet og dermed måler en større

avstand (algoritme 1) eller mindre fart (algoritme 2) i retning av målet, har det ikke tid til å bevege

seg langt nok tilbake mot målet før neste avstands- eller fartsmåling blir foretatt. Denne målingen vil

igjen vise større avstand/lavere fart mot målet enn den forrige, og fartøyet vil svinge i motsatt

retning. Dette gjør at fartøyet ender opp med å gå i en uendelig sløyfe der det navigerer seg lengre

og lengre vekk fra målet.

I motsetning til disse algoritmene fremstod algoritme 3 som en god og kvalifisert kandidat i henhold

til kravspesifikasjonen. Den virket veldig robust og så ut til å håndtere vannstrømmene relativt bra.

Vannstrømmene gjorde naturligvis fartøyet tregere, men det fant likevel tilbake til riktig kurs relativt

hurtig.


Rev: v1.00 29(62) 01.06.16

5.1.4 Konklusjon

Gruppen konkluderte etter endt testing at algoritme 3 (Heading + Bearing) var den algoritmen som

oppnådde den mest komplette oppfyllelsen av kravspesifikasjonen, og som derfor ble valgt til å

videre implementeres i det fysiske modellfartøyet.

5.2 Testing av individuelle elektroniske komponenter

5.2.1 Hensikt

Formålet med å utføre testing av komponentene hver for seg var å identifisere eventuelle feil tidligst

mulig og dermed på et tidlig stadium kunne finne løsninger for å forhindre at feil ville forplante seg

og påvirke testresultatene videre i prosjektet.


Gjennomføringsplanen bestod i å koble opp individuelle komponenter som vist på koblingsskjema i

Appendiks E.1 for så å separere komponentene ut i egne kretser og slik at de kunne testes hver for

seg. Etter dette var planen å koble hele systemet sammen igjen og teste komponentene en gang til

hver for seg, men denne gang mens de fremdeles var tilkoblet den fullstendige kretsen.

1. Den børsteløse motoren og regulatoren som fulgte med modellbåten kunne ifølge

leverandør være ødelagt. Det medfulgte derfor en ny børstemotor i prisen som en potensiell

erstatning for den innebygde børsteløste motoren og regulatoren dersom en av

komponentene skulle vise seg å være defekte. Motoren og regulatoren ble testet med en

spenningsregulator stilt på 9 V og en servotester.

2. Overstyringsroret og motoren ble testet ved bruk av radiokontroll. Fjernstyringskontrollen

DX3E ble brukt til å sende radiosignaler til radiobølgemottakeren MR3000. Videre ble det

med radiobølgemottakeren sendt et pulssignal til både regulatoren som regulerer motoren,

samt servomotoren som styrer overstyringsroret for å sjekke om disse komponentene

oppførte seg som forventet.

3. Hovedroret ble testet ved å generere PWM-signaler med varierende pulslengde fra en av

utgangene på Raspberry Pi-enheten og sende disse til servomotoren som kontrollerer

hovedroret via en av kanalene på radiobølgemottakeren. Gruppemedlemmene observerte så

oppførselen til roret som følge av de forskjellige signalene.

4. Testen av GPS-mottakeren ble utført ved å installere den nødvendige programvaren og

deretter prøve å oppnå en akseptabel signalkvalitet tilstrekkelig til å få en nøyaktig posisjon

under uthenting av data.

5. Vannpumpen ble testet ved å bruke en regulerbar spenningskilde for å undersøke hvilken

spenning og strøm vannpumpen vil trekke for å skape en akseptabel vanngjennomstrømning.

6. Testing av batteriene ble delt opp i fem separate tester siden hvert batteri supplerer

spenning til forskjellige komponenter. De fem deltestene ble inndelt som følger:


Rev: v1.00 30(62) 01.06.16

6.1 Batteri til motorregulator og servomotor til hovedror.

6.2 Batteri til motor.

6.3 Batteri til vannpumpe.

6.4 Batteri med solcelle til Raspberry Pi.

6.5 Batteri til overstyringsror.

5.2.3 Resultat

Testenes resultat etter nummereringen:

1. Den børsteløse motoren med regulator var ikke defekt.

2. Det ble oppnådd kontakt mellom radiokontrolleren og radiobølgemottakeren. Det resulterte

i at overstyringsroret beveget seg og fremdriftslinjen roterte slik som ønsket.

3. Servomotoren mottok pulssignalet fra Raspberry Pi og beveget seg slik som ønsket.

4. Det viste seg vanskelig å oppnå en akseptabel signalkvalitet, det ble derfor gjort et innkjøp av

en ekstra antenne. Ved hjelp av denne antennen fikk GPS-mottakeren en akseptabel

signalkvalitet.

5. Vannpumpen hadde en tilstrekkelig vanngjennomstrømning ved en spenning på 6 V og en

strøm på 0,8 A.

6. Resultatet for de forskjellige batteriene:

6.1 Kapasiteten på batteriet var formålstjenlig





5.2.4 Konklusjon

Etter denne omfattede testen ble det konkludert at det ikke finnes betydelige feil og mangler som

kan forplante seg videre i prosjektet på komponentene som ble brukt.

5.3 Testing av styresystem på land uten bruk av GPS

5.3.1 Formål

Formålet med denne testen var å identifisere eventuelle feil med styringen av servomotoren og/eller

feil i logikken til algoritmen.


Raspberry Pi og servomotor ble koblet sammen og en bestemt destinasjon hardkodet inn i

algoritmen. I stedet for å lese av data fra GPS-mottakeren ble det for enkelheten og effektivitets


Rev: v1.00 31(62) 01.06.16

skyld benyttet manuell innskriving av verdier for Heading og Bearing. Dette ble tatt høyde for ved å

redigere algoritmen slik at den spurte bruker om å skrive inn en valgt Heading og Bearing ved hver

gjennomkjøring av programsløyfen.

5.3.3 Resultat

Servomotoren ble styrt som forventet ut i fra hvilke Heading og Bearing som ble valgt.

5.3.4 Konklusjon

Testen var vellykket. Styringen av servomotoren og logikken til algoritmen fungerer som den skal.

5.4 Testing av styresystem på land med bruk av GPS

5.4.1 Formål

Formålet med testen var å teste nøyaktigheten til GPS-mottakeren, mottakeren sin tidsbruk for

uthenting av GPS-koordinater og reaksjonen av servomotoren ved hjelp av kontinuerlig utregning av

Heading og Bearing.


Alle testene ble utført på fotballbanen til HiB Kronstad og startet med å gi det implementerte

programmet en forhåndsbestemt destinasjon som ble plassert i sentrum av banen. Deretter ble

programmet kjørt fra forskjellige startpunkter mens gruppen beveget på kryss og tvers av banen. Det

ble også testet med skarpe og uventede svinger for å se hvor lang tid det tok for servomotoren å

reagere. Det ble justert på tidsintervall mellom målingene for hver test, for kontrollering av

datainnhenting.

For å kunne ha en oversikt over alle GPS-koordinatene mottakerne hadde, ble de logget på en

ekstern .txt-fil. GPS-koordinatene ble deretter lagt inn på Google Earth, og gruppen kunne da

observere og analysere bevegelsesmønsteret.

5.4.3 Resultat

Flertallet av testene var mislykket, da det så ut som om GPS-mottakeren avleste ukorrekte GPS-

koordinater. I tillegg så stien ufullstendig ut, og til tider manglet svært mange GPS-koordinater. Dette

var et problem som gruppen brukte mye tid på å analysere, og i lengre tid hadde vanskeligheter med

å komme til bunns i. Det ble mistenkt at den var en systemfeil i GPS-mottakeren, og at den ikke

hadde kapasitet og evne til å lese inn mange koordinater på en sesjon. På figuren under er det

gjengitt resultatet fra en av testene:


Rev: v1.00 32(62) 01.06.16

Figur 5.4-1: Logging fra en mislykket test.

Etter en undersøkelse av alle testene fant gruppen et mønster som kunne forklare problemene

assosiert med GPS-mottakeren. Det viste seg at den innebygde funksjonen fra mottakerens

medfølgende kodebibliotek som gruppen hadde tatt i bruk for uthenting av GPS-koordinater besitter

en uforutsett svakhet. GPS-mottakeren mottar oppdatert informasjon om sin posisjon fra nettverket

ca. en gang i sekundet. Disse dataene lagres i en buffer som opererer på en First-In-First-Out (FIFO)

basis. Det vil si at dersom det ikke hentes ut data fra denne bufferen like fort som den fylles opp, vil

det bli dannet en oppbygning av data der de mest oppdaterte dataene ligger bakerst, og de dataene

som til enhver tid hentes ut ikke representerer enhetens posisjon i sanntid [7]. Siden det kun ble

hentet ut data fra bufferen med visse intervaller medførte dette at innhenting av GPS-koordinater

ble unøyaktig og ikke fungerte etter hensikten. Løsningen på dette problemet ble å bruke denne

funksjonen oftere enn hvert sekund, og på denne måten forsikre at den dataen som til enhver tid blir

innhentet representerer enhetens faktiske nåværende posisjon. Samtidig ble det lagt inn en

tidsforsinkelse for når en innhenting skulle bli logget. Figuren under viser resultatet av en slik test.

Figur 5.4-2: Logging fra en vellykket test.


Rev: v1.00 33(62) 01.06.16

5.4.4 Konklusjon

Med disse testene kan det konkluderes med at de absolutt var nødvendig for videre arbeid. Gruppen

fikk også et større innblikk på hvordan GPS-mottakeren opererer, og hvordan datauthenting skulle

kontrolleres etter ønsket hensikt.

5.5 Testing av fremdrift og manøvrering i bølgebasseng

5.5.1 Formål

Å studere oppførselen til modellfartøyet i vann. Testen ble utviklet for å gi et resultat på om

modellfartøyet innehar den ønskede flyteevnen og de manøvreringsegenskapene som er

nødvendige, herav svingradius for hovedror og overstyringsrorets oppførsel.


Testen ble gjennomført i bølgebassenget ved høgskolens marinlaboratorium. Etter å først ha plassert

modellfartøyet i bassenget uten noen ekstrakomponenter montert, ble oppbevaringsboksen som nå

fungerer som fartøyets bro plassert på dekket for å finne en egnet plass der hele modellfartøyet lå

stabilt i vannet. Bølgebassenget er 50 meter langt, noe som gav mer enn nok rom for

eksperimentering angående systemets fremdrift. Bassenget er relativt smalt (omtrent 2,5 meter)

men har akkurat nok bredde til at det tillot gruppen å teste styresystemet for å få en indikasjon på

hvordan svingradius for hoved- og overstyringsror fortonte seg. Det ble også sett på forholdet

mellom hoved- og overstyringsror da det er viktig at hver av disse komponentene kan utføre sine

gitte oppgaver uten å forstyrre for eller ødelegge funksjonaliteten til det andre. Det vil si at

hovedroret ikke må være så stort at overstyringsroret ikke har mulighet til å overstyre det, samtidig

som det må være stort nok til å gi en akseptabel svingradius under normale operasjonsforhold.

5.5.3 Resultat

Modellfartøyet lå stabilt i vannet med og uten oppbevaringsboksen, og fremdriften fartøyet

fremviste når det med fjernkontrollen ble gitt et pådrag på rundt 10 % av maks fremstod som

tilstrekkelig med tanke på kravspesifikasjonen. Det viste seg imidlertid at trykkforskjellen mellom

inngangen og utgangen til kjølesløyfen som kjøler bakre motorlager og regulatoren ikke var høy nok

til å oppnå sirkulasjon av vann gjennom systemet. Det ble derfor besluttet å gå til anskaffelse av

vannpumpe og montere denne i enden av sløyfen slik at tilfredsstillende sirkulasjon kunne oppnås.

Testing av denne pumpen står beskrevet i kapittel 5.2.2, punkt 5.

Roret som kom med modellbåten har dimensjonene 75 mm x 25 mm. Når gruppen observerte

modellfartøyet bevege seg fremover der en testalgoritme som svinger hovedroret mellom 30⁰

babord og 30⁰ styrbord ble benyttet, viste det seg at svingradiusen produsert ikke var god nok. Det

ble av den grunn fabrikkert et nytt ror med dimensjonene 75 mm x 95 mm som deretter ble festet til

det gamle hovedroret. Når gruppen senere kjørte samme test på nytt viste det modifiserte

hovedroret god manøvreringsevne, men overstyringsrorets manøvreringsevne ble observert å være

drastisk redusert. Dimensjonene på det fabrikkerte roret ble derfor redusert til 75 mm x 60 mm og

testen utført på nytt. Resultatet av testen av det neddimensjonerte hovedroret viste at det nå


Rev: v1.00 34(62) 01.06.16

besitter en akseptabel svingradius, og at det samtidig tillater overstyringsroret å utføre sine oppgaver

på et tilfredsstillende nivå.

5.5.4 Konklusjon

Det viste seg at plassering av oppbevaringsboksen ikke hadde noe å si med tanke på modellfartøyets

stabilitet. Fremdriften til modellfartøyet er tilstrekkelig og pådraget kan økes ganske kraftig dersom

det vil være ønskelig. Vannpumpen ble testet i kapittel 5.2.2, punkt 5 og klarte å skape en god

vanngjennomstrømning i kjølesystemet som kjøler motorlager og regulator. Hovedroret ble

modifisert til dimensjonene 75 mm x 60 mm og har som følge av dette oppnådd en akseptabel

svingradius uten å komme i for stor konflikt med overstyringsroret.

5.6 Testing av komplett system på vann i virkelige omgivelser

5.6.1 Formål

Som prosjektets siste og mest avgjørende test var formålet med denne testen å se om det ferdigstilte

modellfartøyet fungerer og om det beveger seg mot et gitt mål samt holder seg i nærheten av dette

målet etter at det har kommet frem.


Alle komponenter ble koblet og installert på modellfartøyet. Det var planlagt å gjennomføre en test i

Tveitevannet og en i Solheimsvannet som ligger henholdsvis sør og vest vis-a-vis høgskolen. Målet ble

under hver av disse testene satt med GPS-koordinater til et punkt godt ute i de respektive vannene

for å gi fartøyet som mye rom til å manøvrere som mulig. Modellfartøyet ble satt ut i hvert vann med

retning bort fra målet før fremdrift ble satt i gang ved bruk av radiokontrolleren. Gruppen observerte

deretter hvordan modellfartøyet beveget seg uten interferens fra overstyringen frem til testen ble

bedømt fullført og fartøyet ble styrt tilbake til land igjen ved hjelp av overstyringsroret.

5.6.3 Resultat

Modellfartøyet fant i den siste testen raskt og effektivt frem til målet og holdt seg deretter i

nærheten frem til gruppen avsluttet testen. Overstyringsroret fungerte tilstrekkelig, men når

hovedroret stod i motsatt retning av overstyringsroret ble svingradiusen såpass stor at det ble mer

effektivt å heller jobbe med hovedroret og foreta en 360 graders sving for å oppnå den ønskede

kursen og deretter holde den ved å bruke overstyringsroret til å kansellere effekten av hovedroret.

På figuren under gjengis en oversikt over den plottede stien fra denne testen. Til høyre vises kun

banen fartøyet har fulgt under selve testen, mens til venstre vises også veien fartøyet har tatt som

følge av overstyringen ved testens ende.


Rev: v1.00 35(62) 01.06.16

Figur 5.6-1: Logging fra fullskala test i Solheimsvannet.

5.6.4 Konklusjon

Denne testen var suksessfull og modellfartøyet virket som det skulle. Overstyringsroret fungerte ikke

optimalt, men godt nok til at modellfartøyet kunne bli styrt til land igjen. Grunnen til at det ble

observert en til tider dårligere effekt ved bruk av overstyringsroret i de virkelige vannene i forhold til i

bassenget, kan skyldes strømninger i vannet eller andre uberegnelige faktorer som presenterer seg i

ukontrollerte omgivelser.


Rev: v1.00 36(62) 01.06.16

6 Diskusjon I forstudierapporten ble det antatt at det ville bli en del arbeid med oppsett av datamaskin og

oppgavene den skal utføre. Det var planlagt at arbeidet med å konstruere en modellbåt for testing

ville foregå i regi av bedriften i deres lokaler ved CMR. Ansvarsfordelingen som ble utdelt innad i

gruppen under forstudiet har fungert ganske bra, og gruppen har både samarbeidet godt og

overlappet hverandre der det har vært usikkerhet med tanke på fremgang. Det ble også satt opp et

kostnadsanslag og en fremdriftsplan i forstudierapporten.

6.1 Kostnadsanslag Forprosjektet budsjetterte projiserte utgifter til anslagsvis 1658 kroner. Utgiftene som vist i tabellen

under er i løpet av prosjektet summert til 2329,95 kroner. Summen har blitt overskredet med 671,95

kroner, eller tilnærmet 40,5 prosent.

Varenavn: Pris:

Overgangskabel 45

Batteriholder x2 59,8

Batterikontakt x2 49,8

Batteri 12-pk x 2 159,8

Servokabler 56

Oppbevaringsboks x2 131,8

USB-forlenger 99,9

Solcelle batteri 299

Universallim 54,9

Strips-3 sett 59,9

Båt /m motor og propell 600

Raspberry Pi 2 modell B 312,85

GPS-mottaker 182,43

GPS-antenne 218,77

Totalt 2329,95

Tabell 1: Utgiftsoversikt

Ror og motor var budsjettert til 999 kroner, men denne utgiftsposten har havnet på 600 kroner.

Hardware komponenter, som ikke var budsjettert i forstudierapporten har gitt utgifter på 1013,05

kroner. Resterende utgifter som kabler, batterier med tilbehør, lim og strips havnet på 716,90

kroner. Det har vært en del ekstra utgifter som følge av valg av løsning og ekstrautgiftene denne har

medført for å få en stabil og driftssikker farkost å kunne teste algoritmeforslaget på. Et

kostnadsanslag for en slik oppgave vil være vanskelig å treffe hundre prosent på, da kostnadene i

bunn og grunn er relativt lave for en slik type oppgave. En oppgave som utviklet nye kostnader basert

på mangler og nødvendigheter for å få en driftssikker farkost med et stabilt system.


Rev: v1.00 37(62) 01.06.16

6.2 Fremdriftsplan Fremdriftsplanen som var utredet i et Gant-diagram i forstudierapporten har ikke stemt så godt.

Prosjektet har ligget litt på etterskudd med de forskjellige milepælene og arbeid har blitt forskjøvet

frem i tid. I etterpåklokskap hadde det vært en fordel og utredet en fremdriftsplanen basert på mer

dialog med oppdragsgiver om milepæler for de forskjellige hoveddelene i prosjektet. Gruppen har

laget oppdaterte fremdriftsplaner etter hvert som arbeid har blitt forskjøvet frem i tid.

6.3 Tekniske løsninger I løpet av prosjektets gang ble gruppen nødt til å foreta en rekke valg angående hvilke potensielle

tekniske løsninger som ville være mest ønskelig å implementere. I dette underkapittelet blir det

reflektert over validiteten til disse valgene og hvilke konsekvenser de har hatt på prosjektets

ferdigstilling.

6.3.1 Simulator

Simulatoren er skrevet i C#, et språk gruppen har god erfaring. Arbeidsmengden forbundet med

utvikling av simulatoren viste seg å være vanskelig å fordele blant fire personer, noe som resulterte i

en mindre effektiv arbeidsfordeling den første måneden av prosjektet. Det hadde vært fordelaktig

om innkjøp av hardware komponenter var betenkt nært parallelt med arbeidet på simulatoren, slik at

arbeidskraften kunne utnyttet sitt fulle potensial.

Valget av en slik løsning viste seg i lengden å ha uventede positive innvirkninger på gruppens evne til

å effektivt imøtekomme fremtidige forespørsler fra oppdragsgiver om mer detaljert simuleringsdata

og gjorde det relativt enkelt å utvide simulatorens funksjonalitet der det ble ansett som nødvendig.

6.3.2 Raspberry Pi

Raspberry Pi ble valgt som datamaskin. Operativsystemet til Raspberry Pi er Linuxbasert, noe

gruppen ikke har hatt noen erfaring med før. Installering og oppsett av systemet tok lengre tid enn

antatt og gav et uforutsett høyt antall utfordringer, hovedsakelig med å få systemet oppdatert og

klart til bruk. Den største utfordringen med å få systemet oppdatert var å opprette trådløs

kommunikasjon med eduroam, den internasjonale roaming-tjenesten Høgskolen i Bergen benytter

for å dele tilgang til internett med studentene. Undersøkelser på internett gav en del artikler på

hvordan systemet kunne settes opp for støtte til eduroam, men det oppstod problemer å få kjørt

mellomliggende- og root-sertifikat i systemet. Dette ble løst ved å dele internett fra en mobiltelefon

til systemet ved hjelp av instruksjoner fra Raspberry Pi sine samfunnssider på internett [8]. Det

krevdes en mengde oppdateringer, drivere og kodebibliotek som manglet i systemet for å kunne

implementere de nødvendige komponentene som styring og GPS-logging, men også en mulighet for

overvåkning av systemet ved å sette opp eksternt skrivebord på en bærbar PC. Det har kort summert

vært tid- og ressurskrevende arbeid å få satt opp selve systemet klart til bruk.


Rev: v1.00 38(62) 01.06.16

6.3.3 Python

Programmeringsspråket som selve algoritmen kjøres på i Linux er Python 3. Python er et

programmeringsspråk gruppen ikke har jobbet med før, men som baserer seg på objektorientering,

et programmeringsparadigme alle gruppemedlemmene er godt kjent med. Python har likheter med

C#, men krevde fortsatt en del tid av gruppemedlemmene til å lese og sette seg inn i språket for å få

implementert inn algoritmen slik at den ble riktig.

6.3.4 Modellfartøy

Selve skroget med innkjøpt fremdrift ble montert ved CMR sine lokaler i regi av oppdragsgiver.

Montering av resterende deler ble utført av gruppen i automatiseringslaboratoriet ved Høgskolen i

Bergen. Under første prøvekjøring av båten ble det oppdaget at kjølesystemet for motorlager og

regulator ikke oppnådde høy nok trykkdifferanse til å suge vann inn i systemet, noe som gjorde at det

oppstod fare for varmegang i kritiske komponenter. Med hjelp fra en av avdelingsingeniørene ved

høgskolen fikk gruppen gått til anskaffelse av en vannpumpe med innebygget kjøleribbe med nok

kraft til å skape en mer enn god nok vanngjennomstrømning i kjølesystemet. Båten endte opp med å

bli ferdigstilt mye senere enn den originale fremdriftsplanen tilsa, da konstruksjonen viste seg å være

en større utfordring enn tidligere antatt.

6.4 Risikoliste Hendelsene som har inntruffet i løpet av prosjektperioden er milepæl ikke oppnådd i tide (RI-2) og

problem med GPS-mottaker (RI-11). Milepæl ikke oppnådd i tide er allerede nevnt tidligere i

diskusjonen. Den vesentlige grunnen for at denne risikoen inntraff var for lite arbeid delt på flere

personer som resulterte i dårlig effektivitet i helheten av prosjektet, kort sagt burde flere av

segmentene i prosjektet blitt arbeidet på parallelt. Resultatet av hendelsen var at det oppstod et

kortere tidsrom for fullføring av de senere milepælene i prosjektet. Problemene som oppstod med

GPS-mottakeren omhandlet signalkvalitet og henting av data fra mottakeren. Det viste seg umulig å

få et sterkt signal innendørs og det ble derfor kjøpt inn en kraftig ekstra antenne. Selv med en

akseptabel signalkvalitet og en vellykket installasjon av enheten ville ikke oversiktsbildet vise noen

data. Gruppens løsning på dette problemet var å undersøke og finne metoder egnet til oppgaven fra

et av Python kodebibliotek. Det at hendelsen inntraff resulterte i et bredere tidsrom for programvare

produksjon. En hendelse som nesten inntraff var for sen ferdigstilling av modellbåt (RI-11).

Modellbåten ble ferdigstilt i løpet av siste uken og sluttesten ble utført få dager før prosjektet skulle

avsluttes. Om hendelsen hadde inntruffet ville ikke sluttesten blitt fullført noe som ville resultert i en

manglende sluttkonklusjon.

6.5 Oppsummering Det ble relativ kort tid til å fullføre sluttester, analysere resultater av testene og dra en

sluttkonklusjon med tanke på prosjektlengden. Det hadde vært en fordel for arbeidsfordelingen om

arbeidet med simulatoren og Raspberry Pi hadde startet noenlunde likt. Å utvikle simulatoren var en


Rev: v1.00 39(62) 01.06.16

oppgave som ikke krevde alle gruppemedlemmenes samlede innsats, da arbeidet fort kan bli

uoversiktlig og lite effektivt når flere personer skal redigere og bygge videre på hverandres kode i

samme prosjekt. Det ville vært mer effektivt om arbeid ble fordelt slik at to studenter arbeidet med

simulatoren og to studenter startet med installasjon og konfigurering av Raspberry Pi.

Arbeidsmengden var stor nok til å bli utført parallelt og milepælene ville høyt sannsynlig blitt fulgt

bedre. Hadde tidsfristene satt for de forskjellige delene av prosjektet blitt innfridd med ferdige

segmenter tidligere ville konstruering av modellbåt kunne startet i midten av april. Lengden på

tidsrommet satt av til testing ville blitt fulgt og det ville vært bedre tid til å fullføre sluttester,

analysere, komme med sluttkonklusjon og ferdigstille rapporten.


Rev: v1.00 40(62) 01.06.16

7 Konklusjon Oppgavens mål har vært å utvikle en styringsalgoritme for en seilbøye som navigerer til et gitt punkt

kun ved hjelp av GPS. Oppgaven er oppdelt i en simulert og en praktisk del. I den simulerte delen av

oppgaven, har målet vært å finne frem til den algoritmen som egner seg best i forhold til

kravspesifikasjonene. I den praktiske delen av oppgaven har gruppen oppnådd målet om å kjøre en

fullskalatest av algoritmen ved å konstruere en modellbåt og la denne styres av den valgte

algoritmen fra den simulerte delen.

Den simulerte delen av prosjektet har gått ut på å lage en simulator for å kunne simulere de ulike

algoritmene som gruppen ønsket og teste. Simulatoren var den første oppgaven gruppen løste.

Simulatoren er brukervennlig og robust og har kjørt testen som beskrevet i kapittel 5.2. Resultatet av

alle simuleringene med de forskjellige algoritmene fortalte gruppen hvilken algoritme som vil egne

seg i den praktiske delen av oppgaven. Algoritmen som egnet seg best var gruppens eget

algoritmeforslag, at navigering vil skje med å se på forholdet mellom modellbåtens Heading og

Bearing. Dette forholdet forklarer modellbåtens bevegelse i forhold til målet.

Under den praktiske delen av prosjektet har en modellbåt blitt konstruert og maskinvare installert

slik kapittel 4.2 beskriver. Modellbåten har gjennomgått de relevante testene beskrevet i kapittel 5.

Ut ifra de observerte resultatene fra den siste testen har gruppen konkludert med at algoritmevalget

basert på simuleringsresultatene fungerte godt i praksis.

Oppgavens konklusjon er at gruppens algoritmevalg har oppnådd tilfredsstillende resultater gjennom

både simulering og praktisk testing. Algoritme 3, som gjør bruk av Heading og Bearing, har oppfylt

punktene i kravspesifikasjonen med ett forbehold angående dens evne til å gjøre justeringer i

respons til påvirkning av fartøyet fra eventuelle havstrømmer. Algoritmen vil som en bivirkning av

dens grunnleggende logiske oppførsel automatisk korrigere for kursendringer grunnet havstrømmer,

men inneholder ingen ekstra logikk som er spesielt dedikert til dette formålet. Dersom seilbøyens

Heading og Bearing sammenfaller vil ikke algoritmen kalkulere noen kursendring før havstrømmen

drar den enten til babord eller styrbord.

Totalt sett er det gruppens mening at oppgaven er blitt fullført på en tilstrekkelig tilfredsstillende

måte med hensyn til kravspesifikasjonen.


Rev: v1.00 41(62) 01.06.16

Appendiks A Litteraturliste

[1] Bill Clark. (2016). Excel to KML – Display Excel files on Google Earth. Tilgjengelig:

https://www.earthpoint.us/ExcelToKml.aspx

[2] OpenLX SP Ltd. (2014). Microstack™ GPS Getting Started. Tilgjengelig:

http://www.microstack.org.uk/assets/gps/FormattedGPSgettingstarted.pdf

[3] Hitec. (2016). HS-325HB Standard Ball Bearing Servo.

http://hitecrcd.com/products/servos/sport-servos/analog-sport-servos/hs-325hb-standard-

ball-Bearing-servo/product

[4] Ron Lund. (2015) Servo frequency and center pulse width information. Tilgjengelig:

http://www.ronlund.com/rcheli/HELP_SERVO_PULSE.html

[5] Horizon Hobby Inc. (2010). MR3000 Marine 2.4GHz 3-Channel Receiver. Tilgjengelig:

http://www.spektrumrc.com/ProdInfo/Files/SPMMR3000-MANUAL.pdf

[6] Horizon Hobby Inc. (2010). DX3E TRANSMITTER. Tilgjengelig:

http://www.spektrumrc.com/ProdInfo/Files/SPM3160_EN.pdf

[7] synthesizerpatel. (2011). Python GPS Module: Reading latest GPS Data. Tilgjengelig:

http://stackoverflow.com/questions/6146131/python-gps-module-reading-latest-gps-data

[8] Raspberry Pi Foundation. (2014). SETTING WIFI UP VIA THE COMMAND LINE. Tilgjengelig:

https://www.Raspberrypi.org/documentation/configuration/wireless/wireless-cli.md

https://www.earthpoint.us/ExcelToKml.aspx

http://www.microstack.org.uk/assets/gps/FormattedGPSgettingstarted.pdf

http://hitecrcd.com/products/servos/sport-servos/analog-sport-servos/hs-325hb-standard-ball-bearing-servo/product

http://hitecrcd.com/products/servos/sport-servos/analog-sport-servos/hs-325hb-standard-ball-bearing-servo/product

http://www.ronlund.com/rcheli/HELP_SERVO_PULSE.html

http://www.spektrumrc.com/ProdInfo/Files/SPMMR3000-MANUAL.pdf

http://www.spektrumrc.com/ProdInfo/Files/SPM3160_EN.pdf

http://stackoverflow.com/questions/6146131/python-gps-module-reading-latest-gps-data

https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md


Rev: v1.00 42(62) 01.06.16

Appendiks B Forkortelser og ordforklaringer

Ord: Forklaring:

Akterut Bakerst i skipet

Arduino/Genuino Arduino er populær og brukervennlig mikrokontroller laget for det kommersielle markedet i USA. Genuino er merkenavnet som brukes for produktet i Europa, men begge kortene er identiske elektroteknisk sett.

Bearing Retningsvektoren fra et fartøy til en gitt destinasjon. Angis som en vinkel målt i antall grader i forhold til nord.

Buffer En midlertidig lagringsplass i en datamaskin: en del som holder minnet midlertidig inntil CPU justerer den og sender den til en annen del av maskinen.

C Et kraftig og fleksibelt programmeringsspråk utviklet ved Bell Labs på 1970-tallet.

C++ Programmeringsspråk som bygger direkte på C, men som også inkluderer muligheten for objektorientert utvikling.

C# Et objektorientert programmeringsspråk utviklet av Microsoft i år 2000. Basert på blant annet C++.

Christian Michelsen Research (CMR) Et forskningsinstitutt i Bergen hvor prosjektets oppdragersgiver Offshore Sensing AS har sine kontorer og verksted.

CSV-fil Et filformat for lagring av tabellarisk data hvor linjene i tekstfilen representerer radene i en tabell.

Delegat (i kontekst av C#) En delegat opererer som en peker til en eller flere funksjoner, og ved å skifte ut hvilken funksjon som pekes på av en gitt delegat kan den samme delegaten brukes til å kalle en rekke forskjellige funksjoner i løpet av sin livstid.

Digital Spectrum Modulation (DSM) En type teknologi for radiofrekvensbasert kommunikasjon.

Eduroam En internasjonal roaming-tjeneste som spesialiserer seg på å tilby sikker internett-tilgang til utdanningsinstitusjoner.

Ethernet En type datanettverksteknologi ofte brukt i sammenheng med fysisk oppkobling mot internett eller i lokale nettverk.

Extensible Application Markup Language (XAML)

Et deklarativt markeringsspråk basert på Extensible Markup Language (XML).

Extensible Markup Language (XML) Et universelt og utvidbart markeringsspråk.

First-In-First-Out (FIFO) En metode for organisering av data der den første datapakken som sendes inn i køen også er den første som blir hentet ut.

Gant-diagram En type søylediagram som illustrerer et prosjekts tidsplan.

Global Positioning System (GPS) Et navigasjonssystem som lar en bruker bestemme sin eksakte posisjon på jordkloden hvor som helst i verden.

General-Purpose Input/Output (GPIO) Koblingspinner på en integrert krets hvis oppførsel kan programmeres direkte av en bruker.

Heading Referer til gjeldende bevegelsesretningen et fartøy. Angis som en vinkel målt i antall grader i forhold til nord.

High Definition Multimedia Interface (HDMI)

En protokoll som definerer en standard for overføring av høyoppløselig video og lyd mellom to kompatible enheter.

Keyhole Markup Language (KML)-fil KML er et XML-basert markeringsspråk. .kml er et filformat for lagring av geografiske koordinater som kan åpnes i Google Earth, Google Maps og andre programmer.

Knop Farten til en internasjonal nautisk mil (1852 meter) per time

LabView Et dataprogram som kan brukes til å designe og programmere virtuelle elektriske kretser.

MATLAB Et kraftig dataverktøy hvis funksjonalitet inkluderer programmering og matematisk simulering.

Microsoft Visual Studio 2013 (VS2013) Et integrert utviklingsmiljø laget av Microsoft som er spesialisert


Rev: v1.00 43(62) 01.06.16

for utvikling av programvare mot Microsoft sitt .NET rammeverk.

Mikrokontroller Programmerbar prosessor som benyttes i elektroniske kontroll- og målesystemer.

Mikro-PC En datamaskin av liten størrelse, ofte bestående av kun ett kretskort.

Nikkel-Kadmium (NiCd) batteri En type ladbart elektrisk batteri bygget opp av celler med en spenning på 1,2 V.

Pentagon Sammenhengende geometrisk figur bestående av fem sider.

Pulse Per Second (PPS) Beskriver en type elektrisk signal som består av korte pulser med en bestemt frekvens og bølgelengde. Typisk brukt som klokkesignal i teknologi som krever presis timing.

Pulse Width Modulation (PWM) En type modulasjon av et elektrisk signal der varierende lengde av pulsen som sendes er den kritiske faktoren.

Python Et objektorientert programmeringsspråk med høy grad av portabilitet som gjør bruk av en veldig minimalistisk syntaks.

Radiokontrollert (RC) Engelsk forkortelse for Radio Controlled. Betegner at noe kan kontrolleres ved hjelp av radiobølger.

Radiofrekvens (RF) Elektromagnetiske bølger i frekvensområdet 3 kHz – 300 GHz.

Sanntidssystem Et system med strenge krav til reaksjons- og responstid.

SD-kort SD-kort(Secure Digital) er en type digitalt minnekort.

Time To First Fix (TTFF) Måling av tiden som kreves av en GPS mottaker til å oppnå kontakt med satellittnettverket og få mottatt navigasjonsdata.

TXT-fil Et filformat for lagring av klartekst.

Universal Serial Bus (USB) En protokoll som definerer en standard for overføring av informasjon og elektrisk kraft mellom datamaskiner og andre elektroniske apparater.

Tabell 2: Forkortelser og ordforklaringer

Appendiks C Prosjektledelse og styring

C.1 Prosjektorganisasjon Arbeidet i gruppen er valgt jevnt fordelt på alle medlemmer der to enkelt par har hovedansvar for de

store delene av prosjektet.

De store delene og utfordringene gruppen ser i oppgaven er programmering og montering av

komponenter. Gruppen har også valgt en leder, en regnskapsansvarlig og en kontaktansvarlig for

kontakt med oppdragsgiver.

Ansvarlig for de forskjellige delene er:

- Gruppeleder: Andreas

- Regnskapsansvarlig: Alex

- Kontaktansvarlig: Mathias

- Programmering: Mathias og Tommy

- Montering av komponenter: Andreas og Alex

Medlemmene vil samarbeide med alt av arbeid, inkludert rapportskriving, utvikling og testing, men

ha ett hovedansvar for de store delene av prosjektet.


Rev: v1.00 44(62) 01.06.16

C.2 Prosjektform Gruppen har tatt utgangspunkt i en iterativ prosjektmodell. Begrunnelsen for dette valget er at

prosjektet er delt inn i faser.

Hovedoppgaven i prosjektet bestod i utvikling av en styringsalgoritme som tar hensyn til vind, bølger

og havstrømmer kun ved hjelp av informasjon fra en GPS som skal styre en seilbøye.

Prosjektet er delt opp i tre forskjellige faser som hver har egendefinerte tidsplaner, design,

implementering av algoritmer, samt testing og verifikasjon.

Prosjektets tre hovedfaser:

Skrive simuleringsprogram og designe algoritmer

Konstruere en fysisk testmodell og medfølgende styringssystem

Testing og utbedring av fysisk system

Under første fase ble det laget et program for simulering av bevegelsene til et fartøy i sjø med og

uten strømninger. Testing i denne fasen gikk i hovedsak ut på å utforske hvordan ulike algoritmer

reagerer på forskjellige verdier for parametere som vind, bølger og havstrømmer. Ut i fra disse

testene observerte gruppen hvilke algoritmer som hadde størst potensial for implementering videre i

prosjektet.

I andre fase var hovedfokus rettet mot å konstruere det fysiske styresystemet og implementere den

algoritmen som i fase én ble besluttet å være best egnet til dette systemet. Arbeidet i denne fasen

innebar fremdeles en god del programvareutvikling og -justering, men også fysisk kobling og bygging.

Tredje og siste fase bestod av testing av den fysiske modellen. Den testfasen ble videre delt opp i to

hoveddeler: tørrtesting av selve styringssystemet på land, og til slutt fullskala testing av den

komplette modellen på vann. I tørrtestingen inngikk det mange forskjellige småtester av de

individuelle maskinvarekomponentene samt implementering og justering av en eller flere algoritmer.

Vanntestingen endte som kulminasjonen av prosjektet og fungerte som en såkalt «proof of concept»

for algoritmen.


Rev: v1.00 45(62) 01.06.16

C.3 Fremdriftsplan

C.3.1 Initiell fremdriftsplan

Figur 6.5-1: Initiell fremdriftsplan

C.3.2 Revidert fremdriftsplan april

Figur 6.5-2: Revidert fremdriftsplan april

C.3.3 Revidert fremdriftsplan mai og juni

Figur 6.5-3: Revidert fremdriftsplan mai og juni


Rev: v1.00 46(62) 01.06.16

C.4 Risikoliste

ID Hendelse Sannsynlighet Konsekvens Risiko Tiltak

RI-1

Prosjekt blir ikke fullført

Lav Oppgaven blir ikke bestått.

Høy God planlegging. Tilstrekkelig tid til forskjellige faser av prosjektet.

RI-2

Milepæl ikke oppnådd i tide

Høy Arbeid fortsetter ut i neste periode. Mulig forsinkelse av prosjekt.

Middels Sette av god nok tid til alle faser. Arbeide ekstra. God parallellisering av oppgaver.

RI-3

Stort fravær Lav På etterskudd med Arbeidet.

Høy Sterkt lederskap. Fast arbeidstid.

RI-4

Konflikt i gruppen

Middels Dårlig arbeidsmiljø. Liten effektivitet.

Høy Teambuilding. Løse konflikter før de blir et problem.

RI-5

Enkeltpersoner melder seg ut

Lav På etterskudd med arbeidet.

Høy Fornuftig arbeids- og ansvarsinndeling.

RI-6

Modellbåt blir ikke konstruert i tide

Lav Manglende hoved- test av algoritme.

Høy God kommunikasjon med bedrift.

RI-7

Modellbåt mangler fremdrift

Lav Umulig å fullføre testing av modellbåt.

Høy Finne egnet fremdrift tidlig.

RI-8

Vannskader på komponenter

Lav Tidstap, pengetap og ekstraarbeid

Høy Vannsikker boks for skjøre komponenter.

RI-9

Problemer med å løse programmerings- utfordringer

Middels Tidstap for å løyse problemet.

Middels Ekstra arbeid med koding. Spørre om hjelp utenfor gruppen.

RI-10

Tap av data/kildekode

Lav Kode må skrives på nytt. All testing som avhenger av tapt kode/data må utsettes.

Høy Gode rutiner for datasikring og sikkerhets- kopiering.

RI-11

Problem med GPS

Middels Algoritmen kan ikke implementeres i sin fulle form. Test på vann vil bli vanskelig.

Høy Grundig feilsøking. Gjennomgang av datablad og annen dokumentasjon.


Rev: v1.00 47(62) 01.06.16

Appendiks D Brukerdokumentasjon Dette appendikset inneholder brukerdokumentasjon for simulatoren samt driftsdokumentasjon for

de fysiske komponentene inneholdt i modellfartøyet.

D.1 Brukerdokumentasjon Herunder følger informasjon og forklaringer angående simulatorens brukergrensesnitt.

Dokumentasjon angående det fysiske systemet går under drifts- og vedlikeholdsdokumentasjon og er

beskrevet i Appendiks D.2.

Figur 6.5-4: Simulasjonseksempel

Figuren over viser et utsnitt fra den seksjonen av simulatorens grafiske brukergrensesnitt som

presenterer en animert visuell gjengivelse av selve simuleringen for brukeren. Forklaring til de

nummererte elementene følger.

1. Representasjon av fartøyets faktiske posisjon og bevegelsesretning.

2. Retningsvektor fra fartøyets posisjon til dens måldestinasjon.

3. Fartøyets måldestinasjon.

4. Representasjon av fartøyets målte posisjon og bevegelsesretning (vises kun dersom

måleusikkerhet i posisjonssystemet er aktivert).

5. Retningsvektor fra fartøyets målte posisjon til måldestinasjonen.


Rev: v1.00 48(62) 01.06.16

Figur 6.5-5: Simuleringsfunksjoner 1

Forklaringer til funksjonene presentert på simulatorens kontrollpanel:

1. «Start» og «Pause» -knappene brukes til å henholdsvis starte og stoppe simuleringen og som

konsekvens, animasjonen som presenteres i brukergrensesnittet.

«Reset» -knappen stopper simuleringen og tilbakestiller fartøyet til sin originale posisjon og

retningsvektor.

«New Target» -knappen genererer en ny måldestinasjon ved en tilfeldig valgt posisjon.

2. Gir bruker valg mellom å kjøre simuleringen i algoritme- eller manuell-modus. I manuell-

modus kobles den valgte algoritmen ut, og bruker kan selv justere fartøyets rorvinkel.

3. Aktiverer/deaktiverer visuell gjengivelse av retningsvektor fra fartøyet til måldestinasjonen.

4. Aktiverer/deaktiverer visuell gjengivelse av fartøyets målte posisjon og bevegelsesretning.

5. I manuell-modus: Lar bruker sette verdien til rorvinkelen i grader, fra minimum -35,0⁰ til

maksimum +35,0⁰.

I algoritme-modus: Viser den verdien til rorvinkelen i grader.

6. Kontrollerer fartøyets fart. Verdien som settes i feltet blir multiplisert med fartøyets

standardfart (farten er dimensjonsløs og relateres ikke til noen referanser fra virkeligheten

da fysikken i simuleringen ikke er avansert nok til å ta høyde for forandring i oppførsel

avhengig av fart).

7. Denne kontrollen justerer intervallet mellom hver gang algoritmen utføres så lenge

simuleringen er aktiv. Mer presist vil det si at verdien som settes i feltet spesifiserer hvor

mange «tikk» fra det virtuelle tidsuret som driver simuleringen som skal passere mellom hver

gang funksjonen som definerer den valgte algoritmen kalles av systemet.

8. Kontroll for justering av fartøyets svingradius. Verdien i feltet multipliseres med en standard

svingradius som programmet regner ut basert på den gjeldende rorvinkelen.


Rev: v1.00 49(62) 01.06.16

9. Usikkert i fartøyets målte posisjon kan justeres

ved hjelp av denne kontrollen. Verdien som settes

for usikkerheten multipliseres med den standard

usikkerheten som er definert i koden.

10. Kontrollerer hastigheten på selve simuleringen,

altså hvor lang tid det går mellom hver gang

simuleringsmotoren oppdateres. Standard

oppdateringsrate er satt til 20 Hz, og verdien som

settes av kontrollen multipliseres med denne.

11. Presenterer relevante data til bruker avhengig av

hvilken algoritme som er valgt.

12. Kontroll for styring av simulerte havstrømmer.

Verdien som settes i de to feltene angir farten til

strømmen i henholdsvis x- og y-retning (y-retning

er invertert i forhold til et standard

koordinatsystem) og har en skalering som er

nøyaktig proporsjonal med skaleringen til verdien

som representerer fartøyets fart. Det vil si at

dersom strømmen i positiv x-retning er satt til

samme verdi som farten til fartøyet i negativ x-

retning ved et gitt tidspunkt, kansellerer de hverandre ut fullstendig.

13. Inneholder en liste over de algoritmene som er mulig å simulere og gir bruker mulighet til å

velge hvilken av algoritmene som skal eksekveres. Bytte av algoritme kan utføres uavhengig

av om simuleringen er i aktiv eller stoppet tilstand.

D.2 Drifts- og vedlikeholdsdokumentasjon For at det fysiske systemet skal fungere korrekt må programvaren og maskinvaren innstilles og

aktiveres på riktig måte. Først bør Raspberry Pi-enheten slås på og GPS-mottakeren aktiveres.

Deretter kan styringsprogrammet åpnes, men det bør ikke startes før resten av systemet er montert

og aktivert.

D.2.1 Raspberry Pi og L80 GPS

Raspberry Pi-enheten slås på ved å plugge inn en kabel fra enhetens mikro-Universal Serial Bus (USB)

port til en 5 V spenningskilde. Når systemet skal tas i bruk forsynes spenningen fra en oppladbar

batteripakke med innebygget solcellepanel. Denne batteripakken kan lades enten via USB tilkobling

eller ved å la den stå i et opplyst område over lengre tid. Når Raspberry Pi-enheten slås på vil den

starte opp og logge inn automatisk, og dersom den er koblet til en monitor vil det presenteres en

skrivebordsbakgrunn med startmeny for bruker. Tilkobling til monitor utføres ved hjelp av High

Definition Multimedia Interface (HDMI) via HDMI-porten direkte til høyre for enhetens strømtilførsel.

De to portene kan ses på figuren under merket 1 (strømtilførsel) og 2 (HDMI-port).

Figur 6.5-6: Simuleringsfunksjoner 2


Rev: v1.00 50(62) 01.06.16

Figur 6.5-7: Raspberry Pi innganger

For å få tilgang til disse portene må hele styringsenheten fjernes fra beskyttelsesboksen den normalt

befinner seg i midt på fartøyets dekk. Se seksjon D.2.3 for instruksjoner angående fjerning av den

mekaniske koblingen som hindrer dette.

Figur 6.5-8: Raspberry Pi skrivebord

For å aktivere GPS-mottakeren må kommandovinduet åpnes ved å klikke på datamaskin-ikonet på

oppgavelinjen merket med «1» på skjermbildet over. Videre må det skrives inn følgende kommando

inn via kommandolinjen:


Rev: v1.00 51(62) 01.06.16

Figur 6.5-9: Raspberry Pi terminal

Kommandoen kan aksesseres ved å trykke piltast-opp på tastaturet gjentatte ganger til kommandoen

dukker opp i vinduet. Kommandoen utføres ved å trykke på Enter-tasten mens kommandovinduet er

aktivt. Etter dette er utført vil GPS-modulen være aktiv, men det kan ta flere minutter før den får et

signal. (Et rødt lys vil blinke på GPS-mottakeren når den har fått signal.)

Ved å klikke på «algoritme1.py» -ikonet på skrivebordet (merket «2» på skrivebordskjermbildet) vil

selve styringsprogrammet åpnes slik at det er klart for eksekvering. På dette tidspunktet vil neste

steg være å klargjøre de fysiske koblingene på fartøyet.

For å starte programmet trykk F5-tasten på tastaturet mens «algoritme1.py» -vinduet er aktivt.

Programmet skriver til 3 forskjellige loggfiler mens det kjører. Disse kan aksesseres etter endt kjøring

ved å klikke på «TommyMappe» -ikonet på skrivebordet, og deretter åpne mappen kalt «Logs».

For å avslutte kjøring av programmet, trykk Ctrl + C på tastaturet.

Figur 6.5-10: Programmappe


Rev: v1.00 52(62) 01.06.16

D.2.2 Elektriske komponenter og koblinger

For at systemet skal kunne være i operativ tilstand er det fire punkter som må tilkobles en

spenningskilde. De fire punktene vises i figuren under.

Figur 6.5-11: Batteritilkobling

Den gule firkanten helt til venstre på figuren viser koblingen mellom et 7,2 V NiCd batteri og motoren

som driver fartøyets fremdrift. Dette batteriet er oppladbart og kommer med en medfølgende lader.

De tre øvrige spenningskildene er identiske 6 V batteripakker som består av fire 1,5 V AA-batterier

koblet i serie.

NB! Merk den røde firkanten. Dette er batterikoblingen til vannpumpen som driver kjølesystemet.

Pumpen starter så snart batteriet kobles til, og bør derfor ikke kobles sammen før båten er enten i

vannet, eller rett før den legges på vann.

For å sørge for en lengst mulig levetid bør alle strøm/spenningskilder kobles ut når systemet ikke er i

bruk.

D.2.3 Mekaniske koblinger

Systemet har en vital mekanisk kobling bestående av en metallstang som forbinder den

algoritmestyrte servomotoren med fartøyets overstyringsror. Denne koblingen må fjernes for å få

tilgang til Raspberry Pi-enhetens HDMI port, noe som er nødvendig for å få tilgang til dens grafiske

brukergrensesnitt og utføre systemets oppstartsprosedyrer som beskrevet i seksjon D.2.1.

Første steg i denne prosessen består av å løsne svingarmen til styringsenhetens servomotor med en

skrutrekker som vist på figuren under.


Rev: v1.00 53(62) 01.06.16

Figur 6.5-12: Feste av styrestang til servomotor

Andre steg består av å løsne styrestangen i andre enden ved å presse ned på den enden av stangen

som stikker opp gjennom et lite hull i svingarmen til overstyringsroret.

Figur 6.5-13: Feste av styrestang til overstyringsror


Rev: v1.00 54(62) 01.06.16

Når styrestangen er løsnet fra overstyringsroret kan den fjernes fullstendig ved å dras gjennom hullet

i beskyttelsesboksen i retningen indikert på figuren under.

Figur 6.5-14: Oversiktsbilde over oppkobling av overstyringsror

For å feste styrestangen igjen reverseres prosessen. I så tilfelle er det viktig å passe på at den enden

av styrestangen som festes til overstyringsroret er presset så langt opp som mulig for å forhindre at

styrestangen løsner under aktiv bruk av systemet. For å sikre at overstyringsroret holder en mest

mulig nøytral midtstilling når det ikke er i bruk bør det også passes på at svingarmen til servomotoren

monteres slik at den står i ytterste mulige posisjon (se figur under).

Figur 6.5-15: Riktig posisjon for styrestang feste på overstyringsrorets servomotor


Rev: v1.00 55(62) 01.06.16

Før fartøyet sjøsettes er det viktig at lokket til RC-båten sitter skikkelig og er skrudd godt igjen ved

punktet indikert på figuren under for å unngå vannlekkasje inn til sensitive elektriske komponenter.

Figur 6.5-16: Skrue til lokk på modellbåt


Rev: v1.00 56(62) 01.06.16

Appendiks E Øvrige diagrammer

E.1 Kretsskjema 1

Figur 6.5-17: Kretsskjema 1

Denne kretsen viser den visuelle elektriske koblingen av regulatoren, motoren, vannpumpe og

servomotoren i den fjernstyrte modellbåten. Disse komponentene får strømforsyning fra separate

spenningskilder. Regulatoren, servomotoren og vannpumpe henter strøm fra tre batteripakker på

6V, og motor får strøm fra NiCd-batteriet på 7,2V. Kommandoene blir sendt fra RF-mottakeren til

komponentene som PWM-signal, og dette skal styre pådraget til motoren og styringen til

servomotoren.


Rev: v1.00 57(62) 01.06.16

E.2 Kretsskjema 2

Figur 6.5-18: Kretsskjema 2

Ovenfor kan man se den elektriske koblingen mellom Raspberry Pi og servomotoren. To GPIO-

utganger er brukt for å kunne styre servomotoren og indikere om det er et aktivt program eller ikke.

LED-lyset er brukt for indikasjonen, der den skal lyse når et program er aktivt og slås av når det er

inaktivt. Motstandene er i grunnen brukt for sikkerhet og beskyttelse av komponenter. Motstanden

mellom servomotor og Raspberry Pi skal kunne verne mot for sterk strøm inn mot Raspberry Pi, og

den andre motstanden er brukt for å verne LED lyset for å gå i stykker.

E.3 Kjølesystem

Figur 6.5-19: Kjølesystem

Dette systemet viser hvordan fartøyets vannkjølingssystem er bygget opp. Motor og regulator er

avhengig av vannkjøling for å unngå at systemet overopphetes ved kontinuerlig bruk over lengre

perioder. Det ble fort funnet ut det innebygde avkjølingssystem i den fjernstyrte modellbåten ikke

fikk nok vann ved den lave farten til seilbøyen. Dette problemet løser vannpumpen, som skal pumpe

vann igjennom systemet uavhengig av farten til seilbøyen.


Rev: v1.00 58(62) 01.06.16

Appendiks F Kildekode Følgende kildekode er skrevet I Python 3, implementert på en Raspberry Pi og representerer

styringsmodulen i sin helhet.

1. #File name: algoritme1.py 2. 3. # ----- Imports ----- # 4. import microstacknode.hardware.gps.l80gps # GPS library 5. import RPi.GPIO as pins # grants access to software PWM

6. import math 7. import time 8. import os.path 9. 10. # ----- Function definitions ----- # 11. 12. # Creates a new logfile if one with the same name already exists 13. def createNewIfExists(file): 14. listFile = list(file) 15. while (os.path.exists(folderPath + file)): 16. listFile[6] = str(int(listFile[6]) + 1) 17. file = "".join(listFile) 18. return folderPath + file 19. 20. # Converts the raw UTC time string to correct time zone and more readable format 21. def convertToLocal(time): 22. timeString = str(time) 23. listString = list(timeString) 24. 25. # Adds 2 to the number occupying the 2nd slot in the list 26. listString[1] = str(int(listString[1]) + 2) 27. tempString = "".join(listString) 28. 29. return "[" + tempString[:2] + ":" + tempString[2:-4] + ":" + tempString[4:-2] 30. + "]" 31. 32. # Writes GPS data to file in Google Earth-ready format 33. def writeToFile(file, lat, long, time): 34. file.write(str(lat)) 35. file.write(",") 36. file.write(str(long)) 37. file.write(",") 38. file.write(time) 39. file.write(",,196,0.5,line-180,yellow,aqua\n") 40. 41. # Returns the angle of the straight line between two points 42. def getAngle(lat1, long1, lat2, long2): 43. x1 = math.radians(lat1) 44. x2 = math.radians(lat2) 45. y1 = math.radians(long1) 46. y2 = math.radians(long2) 47. 48. deltaY = y2 - y1 49. X = math.cos(x2)*math.sin(deltaY) 50. Y = math.cos(x1)*math.sin(x2) - math.sin(x1)*math.cos(x2)*math.cos(deltaY) 51. 52. angle = math.degrees(math.atan2(X, Y)) 53. 54. if (angle < 0): 55. return 360 + angle 56. else: 57. return angle 58. 59. # Returns the difference in degrees between Heading and Bearing


Rev: v1.00 59(62) 01.06.16

60. def getDifference(Heading, Bearing): 61. if (Bearing <= Heading): 62. difference = Heading - Bearing 63. if (difference > 180.0): 64. difference = (360.0 - difference) * -1 65. else: 66. difference = Bearing - Heading 67. if (difference > 180.0): 68. difference = (360.0 - difference) 69. else: 70. difference *= -1 71. return difference 72. 73. # Turns rudder 30 degrees right 74. def turnRightFixed(): 75. pwm.ChangeDutyCycle(20) 76. time.sleep(0.5) 77. pwm.ChangeDutyCycle(0) 78. 79. # Turns rudder to the right based on the difference between Heading and Bearing 80. def turnRightVar(difference): 81. difference = abs(difference) 82. dutyCycle = 15 - 5 * (difference / 180.0) 83. pwm.ChangeDutyCycle(dutyCycle) 84. print("Duty cycle: ", dutyCycle) 85. time.sleep(1) 86. pwm.ChangeDutyCycle(0) 87. 88. # Turns rudder 30 degrees left 89. def turnLeftFixed(): 90. pwm.ChangeDutyCycle(12) 91. time.sleep(0.5) 92. pwm.ChangeDutyCycle(0) 93. 94. # Turns rudder to the right based on the difference between Heading and Bearing 95. def turnLeftVar(difference): 96. difference = abs(difference) 97. dutyCycle = 15 + 5 * (difference / 180.0) 98. pwm.ChangeDutyCycle(dutyCycle) 99. print("Duty cycle: ", dutyCycle) 100. time.sleep(1) 101. pwm.ChangeDutyCycle(0) 102. 103. # ----- Main program loop ----- # 104. 105. try: 106. # Set target coordinates 107. targetLat = 60.369293 108. targetLong = 5.346652 109. 110. # Initialize variables 111. currentLat = 0.0 # Current latitude in decimal degrees 112. currentLong = 0.0 # Current longitude in decimal degrees 113. currentTime = 0.0 # Current time in Norway (GMT + 1) 114. prevLat = 0.0 # Latitude at last known position 115. prevLong = 0.0 # Longitude at last known position 116. counter = 1 # Counts secs since last run through algorithm 117. interval = 10 # The interval between each run though algorithm

118. gpsFileName1 = "gpsLog0.txt" # Name of Coordinate + time log file 119. gpsFileName2 = "gpxLog0.txt" # Name of Coordinates only file 120. infoFileName = "infLog0.txt" # Name of infodump file 121. folderPath = "/home/pi/Desktop/Tommymappe/Logs/" 122. 123. # Configure GPIO pins 124. pins.setmode(pins.BOARD)


Rev: v1.00 60(62) 01.06.16

125. pins.setup(33, pins.OUT) 126. pins.setup(11, pins.OUT) 127. pins.output(11, 1) # Turn LED lamp ON to indicate that the program is running

128. 129. # Set servo motor to start/neutral position 130. pwm = pins.PWM(33,100) 131. pwm.start(15) # 15% duty cycle 132. time.sleep(0.5) 133. pwm.ChangeDutyCycle(0) 134. 135. # Create GPS object from which gps data will be read 136. gps = microstacknode.hardware.gps.l80gps.L80GPS() 137. 138. # Try to get latest gps data 139. try: 140. dict = gps.get_gprmc() 141. 142. currentLat = dict['latitude'] 143. currentLong = dict['longitude'] 144. print(convertToLocal(dict['utc'])) 145. 146. # Catch known exceptions to prevent program from exiting 147. # if the GPS loses fix intermittently 148. except microstacknode.hardware.gps.l80gps.DataInvalidError as ex: 149. print("DataInvalidError: ", ex, " Program continuing") 150. except microstacknode.hardware.gps.l80gps.NMEAPacketNotFoundError as ex: 151. print("NMEAPacketNotFoundError: ", ex, " Program continuing") 152. 153. # Print startup info to screen 154. print("Latitude: ", currentLat) 155. print("Longitude: ", currentLong) 156. print("Starting loop") 157. 158. time.sleep(1) 159. 160. # Open log files for writing 161. gpsTxtFile = open(createNewIfExists(gpsFileName1), "w") 162. gpsNoClockTxtFile = open(createNewIfExists(gpsFileName2), "w") 163. infoTxtFile = open(createNewIfExists(infoFileName), "w") 164. 165. # Loops continuously until interrupted by KeyboadInterrupt 166. # or another unspecified exception 167. while(1): 168. try: 169. dict = gps.get_gprmc() 170. 171. if(counter % interval == 0): 172. prevLat = currentLat 173. prevLong = currentLong 174. 175. currentLat = dict['latitude'] 176. currentLong = dict['longitude'] 177. currentTime = convertToLocal(dict['utc']) 178. 179. # Write current coordinates to file in Google Earth-ready format 180. writeToFile(gpsTxtFile, currentLat, currentLong, currentTime) 181. writeToFile(gpsNoClockTxtFile, currentLat, currentLong, "") 182. 183. except microstacknode.hardware.gps.l80gps.DataInvalidError as ex: 184. print("DataInvalidError: ", ex, " Program continuing") 185. except microstacknode.hardware.gps.l80gps.NMEAPacketNotFoundError as ex: 186. print("NMEAPacketNotFoundError: ", ex, " Program continuing") 187. except ValueError as ex: 188. print("ValueError: ", ex, "Program continuing.") 189.


Rev: v1.00 61(62) 01.06.16

190. # Runs through the actual algorithm at set intervals 191. if(counter % interval == 0): 192. # reset counter 193. counter = 0 194. print("Performing algorithm! Current time is ", currentTime) 195. infoTxtFile.write("Performing algorithm! Current time is " 196. + str(currentTime) + "\n") 197. 198. ##Heading = float(input("Heading: ")) 199. ##Bearing = float(input("Bearing: ")) 200. 201. # Update current Heading and Bearing 202. Heading = getAngle(prevLat, prevLong, currentLat, currentLong) 203. Bearing = getAngle(currentLat, currentLong, targetLat, targetLong) 204. 205. # Get the difference between current Heading and Bearing 206. angleDifference = getDifference(Heading, Bearing) 207. 208. # Print relevant data for review, comment/uncomment as needed 209. ##print("CurrentLat: %f\nCurrentLong: %f" % (currentLat, currentLong)) 210. ##print("PrevLat: %f\nPrevLong: %f" % (prevLat, prevLong)) 211. print("Heading: ", Heading, "\nBearing: ", Bearing) 212. ##print("Difference: ", angleDifference) 213. infoTxtFile.write("Heading: " + str(Heading) + "\nBearing: " 214. + str(Bearing) + "\n") 215. 216. # Boat goes straight ahead 217. if(math.floor(Heading) == math.floor(Bearing)): 218. pwm.ChangeDutyCycle(15) 219. time.sleep(0.5) 220. pwm.ChangeDutyCycle(0) 221. ##print('Duty cycle: 15\nrettfram') 222. elif(Heading >= 0.0 and Heading < 180.0): 223. if(Bearing > Heading and Bearing < (Heading + 180.0)): 224. ##turnRightVar(angleDifference) 225. turnRightFixed() 226. print('turnRight') 227. infoTxtFile.write("turnRight" + "\n") 228. else: 229. ##turnLeftVar(angleDifference) 230. turnLeftFixed() 231. print('turnLeft') 232. infoTxtFile.write("turnLeft" + "\n") 233. #boat has Heading between 180 and 359.9 234. else: 235. if(Bearing < Heading and Bearing > (Heading - 180.0)): 236. ##turnLeftVar(angleDifference) 237. turnLeftFixed() 238. print('turnLeft') 239. infoTxtFile.write("turnLeft" + "\n") 240. else: 241. ##turnRightVar(angleDifference) 242. turnRightFixed() 243. print('turnRight') 244. infoTxtFile.write("turnRight" + "\n") 245. time.sleep(0.5) 246. # If algorithm is not performed, wait specified interval 247. else: 248. time.sleep(0.5) 249. 250. counter = counter + 1 251. 252. # Press Ctrl + C to throw a KeyboadInterrupt exception and safely stop the program 253. except KeyboardInterrupt: 254. pwm.ChangeDutyCycle(15) 255. time.sleep(0.5)


Rev: v1.00 62(62) 01.06.16

256. pwm.ChangeDutyCycle(0) 257. pwm.stop() 258. 259. pins.output(11,0) # turn LED lamp off 260. pins.cleanup() 261. gpsTxtFile.close() 262. gpsNoClockTxtFile.close() 263. infoTxtFile.close() 264. 265. print("Program stopped: Keyboard interrupt") 266. 267. # Any exceptions not already handled will cause program to exit safely 268. except Exception as ex: 269. pwm.ChangeDutyCycle(15) 270. time.sleep(0.5) 271. pwm.ChangeDutyCycle(0) 272. pwm.stop() 273. 274. pins.output(11,0) # turn LED lamp off 275. pins.cleanup() 276. gpsTxtFile.close() 277. gpsNoClockTxtFile.close() 278. infoTxtFile.close() 279. 280. print(("Program stopped: Exception of type {0}: ".format(type(ex).__name__)), ex

)

autopilot i havstrømmer - hvlhome.hib.no/ai/elektro/2016/bo16e-29.pdfdenne rapporten er skrevet i...

Documents