1 titelblad synopsis - aslak...

Robot til autonom husovervågning Gruppe DE3-3-e08

1

1 Titelblad

P3-projekt:

Robot til autonom husovervågning

Gruppe:

DE3-3-e08

Vejleder:

Mikael Svenstrup

Udarbejdet af:

_____________________________

Henrik Bayer Nielsen

_____________________________

Jonas Benjamin Hansen

_____________________________

Johnny Johnson Sada

Synopsis Denne rapport omhandler et

autonomt robotsystem bygget op

omkring microcontrolleren MSP430

fra Texas Instruments.

Rapporten består af tre dele:

MSP430 teori

Implementering

Robottests

Rapporten fremviser arbejdet med

opbygning af en autonom robot,

som det er lykkedes projektgruppen

at få til at køre både autonomt og

manuelt.

_____________________________

Glen Thane Seested

_____________________________

Abdiladif Ahmed Hassan


2

2 Forord

Denne rapport er udarbejdet i forbindelse med P3 projektperioden i efteråret

2008 med afslutning i januar 2009. Projektets tema er microprocessorbaserede.

I forbindelse med projektet er der blevet fremstillet et produkt i form af en

autonom robot. I rapporten vil denne fremstå som eksempel på anvendelse af

elektronik og datateknik i forbindelse med microprocessorbaserede systemer.

I rapporten er først opstillet en problemstilling og en kravspecifikation. Disse er

efterfulgt af et teoriafsnit omhandlende microcontrolleren MSP430 fra Texas

Instruments.

Teoriafsnittet har til formål at skabe en forståelse af hvordan en microcontroller

arbejder. Formålet er her at danne grundlag for forståelse af implementeringen

af en microcontroller, der beskrives i de efterfølgende rapportafsnit.

Gennemgang af implementeringen er opdelt i to hovedafsnit. Det første en

beskrivelse af hardwaredelen til projektets autonome robot. Her beskrives de

komponenter der er anvendt for at få robotten til at køre. Der er desuden

vedlagt relevante sider fra databladene som bilag bagerst i rapporten. Det

andet afsnit omhandler softwaredelen af robotten, som består af et C program

indeholdende adskillige filer.

Der er desuden foretaget en række tests på robotten som er dokumenteret i

rapporten, afsnit 10.

Rapporten afsluttes med en konklusion.

Kildehenvisninger, bilag og appendiks er at finde bagerst i rapporten.

På den vedlagte CD-ROM er følgende at finde:

Fulde udgaver af datablade for alle anvendte komponenter.

Programkoden for MSP-programmet

Programkoden for terminal-programmet

Video af alle system test

Rapporten i .pdf-udgave


3

Kildehenvisninger

Der henvises til kilder ved brug af tal i klammer således: [##]. Står tallet ved

siden af en overskrift til et afsnit, er afsnittet baseret på kilden, dvs. kilden er

anvendt ekstensivt for at skrive afsnittet. Står kilderne inde i selve teksten,

betyder det at der kun er brugt en lille del af kilden, f.eks. en påstand.

Ved bøger henvises kilden i klammer med efterfølgende sidetal: [##,sidetal]

Store dele af rapporten er desuden baseret på to tekster fra Texas Instruments.

Disse er:

MSP430x1xx Family User’s guide (SLAU049F) [1]

Datablad for MSP430x13x, MSP430x14x (SLAS272D) [2]


4

3 Indholdsfortegnelse

1 Titelblad ..................................................................................................... 1

2 Forord ........................................................................................................ 2

3 Indholdsfortegnelse ................................................................................... 4

4 Indledning .................................................................................................. 6

5 Problemstilling ........................................................................................... 8

6 Kravspecifikation ........................................................................................ 9

7 Design af system ...................................................................................... 10

8 MSP430 .................................................................................................... 12

8.1 Introduktion ...................................................................................... 12

8.2 CPU Registre ...................................................................................... 14

8.3 Digital I/O .......................................................................................... 17

8.4 Interrupt ............................................................................................ 18

8.5 PWM ................................................................................................. 20

8.6 Clock .................................................................................................. 21

8.7 ADC ................................................................................................... 22

8.8 Timere ............................................................................................... 27

8.9 Seriel kommunikation (USART/UART) ................................................ 27

9 Implementering ....................................................................................... 31

9.1 Dimensionering af robotten ............................................................... 31

9.2 Hardwareopbygning .......................................................................... 33

9.2.1 Takometer .................................................................................. 33

9.2.2 Motorstyring............................................................................... 34

9.2.3 Afstandssensor ........................................................................... 36

9.3 Beregningshastigheder ...................................................................... 38

9.3.1 Takometer .................................................................................. 38

9.3.2 MSP ............................................................................................ 39


5

9.4 Softwareopbygning ............................................................................ 41

9.4.1 Programmets opbygning ............................................................. 41

9.4.2 Motorstyring ............................................................................... 46

9.4.3 Encoder ...................................................................................... 50

9.4.4 PWM........................................................................................... 53

9.4.5 Sensor ......................................................................................... 54

9.4.6 Serial ........................................................................................... 55

9.4.7 Terminal ..................................................................................... 56

10 Test af robot ............................................................................................. 58

10.1 Test af afstandssensor .................................................................... 58

10.1.1 Specificering af test ..................................................................... 58

10.1.2 Test og konklusion ...................................................................... 58

10.2 Test af motorer .............................................................................. 59

10.2.1 Specificering af motortest ........................................................... 59

10.2.2 Test ............................................................................................. 60

10.2.3 Delkonklusion ............................................................................. 61

10.3 Test af system ................................................................................ 61

10.3.1 Specificering og konklusion ......................................................... 62

11 Konklusion................................................................................................ 66

12 Litteraturliste ........................................................................................... 68

13 Appendiks ................................................................................................ 70

13.1 Schmitt Trigger ............................................................................... 70


6

4 Indledning

Embeddede autonome robotsystemer er et felt med mange potentialer med

anvendelser inden for adskillige arbejdsområder. Autonom overvågning,

kortlægning og orientering er af interesse inden for et væld af områder.

Indledende vil disse områder kort blive gennemgået.

I hjemmet er autonome robotter ved at vinde indpas i form af eksempelvis

automatiske støvsugere og græsslåmaskiner, der selv navigerer rundt. Som

eksempel indenfor overvågning kan nævnes stationære automatiserede

kameraer der følger bevægelse. Derved kan der sikres gode billeder af

Indbrudstyve eller røvere.

Autonome robotter kan også anvendes til detektion af landminer og

sprængstoffer i krigszoner, hvor arbejdsmiljøet er meget risikofyldt.

Halvautonome robotsystemer kan også anvendes til maritim kortlægning og

landmåling. Indenfor vanddybdemåling og maritim forskning kan menneskers

tilgængelighed til havbunden være et problem. I sådanne tilfælde kan der

anvendes en AUV, et automatisk undersøisk fartøj. Som eksempel kan nævnes

det norske HUGIN projekt ved Kongsberg Maritime, der både anvendes civilt til

forskning og militært til detektion af undervandsminer. [3]

Militært anvendes ubemandede luftfartøjer kaldet UAV’ere. Det amerikanske

firma General Atomics fremstiller Predator-dronen, der bl.a. bruges af det

amerikanske luftvåben i Mellemøsten. Droner anvendes til overvågning og

kortlægning samt præcisionsangreb på bygninger. [4]

Derudover anvendes autonome robotter især til rumfart. Komplekse systemer

til navigation og meget andet bruges i satellitter og rumfartøjer.

Men ses der nærmere på autonom husovervågning, så kan dette også finde

forskellige anvendelser. Til overvågning af huse kan det f.eks. antages at en

indsatsstyrke ville danne sig et overblik over hvordan et specifikt hus ser ud


7

inden i. Til dette kan der anvendes en lille autonom robot for hvilken det er

muligt at navigere rundt i lokalerne i huset.

Det kunne også være, at flere autonome robotter med påsatte kameraer,

rutinemæssigt kan overvåge lokaler i et hus. Disse ville kunne overvåge et større

område end stationære overvågningskameraer, hvorved antallet af

overvågningsenheder kunne reduceres. Dette kan være hensigtsmæssigt i

større bygninger, hvor det er muligt for robotterne at sende et trådløst video-

feed til en overvågningscentral.

Denne rapport vil begrænse sig til autonom husovervågning og kun den

autonome robots færden i lokaler. Selve kameraovervågningen tages ikke i

betragtning i denne rapport.


8

5 Problemstilling

Ud fra et projektoplæg er følgende problemformulering blevet lavet:

Hvordan opbygges og implementeres en robot til autonom husovervågning?

Projektafgrænsning

Fra et givent projektoplæg er det blevet valgt at arbejde med en autonom

robot. På grundlag oplægget skal der laves et selvstændigt projekt.

Det er målet at fremstille en robotprototype, dvs. et eksempel på hvordan en

robot kunne opbygges. Et færdigt produkt er ikke målet, og robotten bygges

derfor op af LEGO, da dette er mere tilgivende for eventuelle ændringer i

konstruktionen. Det skal understreges at fokus er sat på

microprocessorsystemer, og at det er dette rapporten omhandler. Der skal

anvendes en programmerbar enhed så som en microcontroller til styring af

robotten.

Desuden skal der bruges motorer til hvilke der skal opbygges et

motorstyringskredsløb.

For at gøre robotten autonom, skal den desuden have inputs fra op til flere

sensorer.


9

6 Kravspecifikation

Ud fra projektafgrænsningen er de primære krav for projektet blevet opstillet,

en kombination af hardware og software der skal gøre robotten i stand til at

navigere sig rundt i et lokale samt opmåle det. For at dette kan realiseres

indenfor projektets tidsrammer har vi opstillet følgende krav:

Krav til lokalet:

• Gulvet skal være jævnt

• For at undgå meget komplekst arbejde med sensorer skal hjørnerne i

lokalet være retvinklede. Ydermere er det et sådant område robotten

skal designes til.

• For at undgå komplikationer med manøvrering lokalet mindst være 2

gange 2 meter i areal, men ikke nødvendigvis kvadratisk.

Krav til hardware:

• Robotten skal kunne køre frem og tilbage, samt rotere både til venstre

og til højre.

• Robotten skal, ved hjælp af afstandssensorer, kunne registrere samt

undvige eventuelle forhindringer.

• Ved hjælp af sensorer skal robotten kunne fastlægge, samt eventuelt

visualisere dens tilbagelagte rute.

• Det er et krav at ovenstående skal realiseres sammen med brugen af en

microcontroller.

Krav til embedded software:

• Den embeddede software skal kunne modtage samt bearbejde

informationer fra de forskellige sensorer.

• Den embeddede software skal ydermere ved hjælp af sensorernes

output navigere robotten uden om forhindringer.

Krav til terminal software:

• Det skal være muligt at styre robotten manuelt. Derudover skal der være

mulighed for at skifte mellem autonom og manuel styring.


10

7 Design af system

For at kunne opfylde kravspecifikationen, udarbejdes der et system. Dette

system indeholder:

• Robot

• Terminal

• Microcontroller

• Motor

• Sensor

• Distancemåler

Selve robotten laves i LEGO. Dette skyldes både den lette tilgængelighed, samt

at eventuelle ændringer i konstruktionen kan foretages uden unødvendig ekstra

arbejde. Dette ville ikke være muligt hvis robotten eksempelvis skulle laves af

metal. Samtidig vil robottens vægt også blive holdt nede, hvilket giver mindre

belastning på de anvendte motorer. Dimensioneringen af robotten er beskrevet

senere i Afsnit 9.1

For at kunne styre robotten skal der i systemet også være en terminal. Til denne

benyttes en computer, der ved hjælp af seriel forbindelse til microcontrolleren,

kan sende og modtage data til og fra microcontrolleren.

Selve microcontrolleren i systemet er af typen MSP430F149. Fra starten af

projektet blev denne stillet til rådighed, og da denne microcontroller indeholder

de perifære enheder der skal benyttes udover de eksterne enheder nævnt i

dette kapitel, har der ikke været grundlag for en udskiftning af denne.

Robotten har samtidig brug for en form for fremdrift. Til dette anvendes to

motorer. Robotten er udstyret med to baghjul, hvorpå de to motorer er

tilsluttet. Ved tilslutning af en H-bro, kan motorerne selvstændigt styre

robotten, og der er derfor ikke brug for nogen drejemekanisme. For at robotten

skal kunne navigere rundt i lokalet er det nødvendigt med sensorer til at

opfange væggene. Hertil anvendes to analoge afstandssensorer, der er placeret

på robottens front samt højre side. Afstandssensorerne der anvendes, Sharp

GP2D12, kan opfange forhindringer såsom vægge i en afstand af 10-80 cm,

hvilket til dette system ses som tilstrækkeligt.


11

For at robotten kan køre rundt i et lokale med retvinklede hjørner, skal den

kunne dreje præcis 90˚. Hertil kan der eksempelvis benyttes et såkaldt kompas,

der får robotten til at dreje et antal grader i forhold til dets egen position. Men

da det tilgængelige kompas nemt bliver påvirket af elektromagnetisk støj fra

motorerne eller anden ekstern kilde, ses dette ikke som en pålidelig løsning.

Derfor anvendes der i stedet to takometre der i sammenhæng med

microcontrolleren fungerer som encodere, der herved benyttes til at aflæse de

to baghjuls tilbagelagte distance. Dette gør det efterfølgende muligt at få

robotten til at dreje 90˚, ved at lade robotten køre indtil de to hjul har

tilbagelagt en distance der passer med en rotation på 90˚.

Dette resulterer i et design af system som kan ses på Figur 1.

Figur 1 Diagram over det komplette system til opfyldelse af

kravspecifikationen.


12

8 MSP430

Denne del af rapporten omhandler MSP430F149, særligt de i projektet

anvendte perifære enheder. Gennem rapporten vil disse enheder blive kaldt

peripherals, som er deres engelske navn.

8.1 Introduktion

[5]

I projektet arbejdes der med en microcontroller fra Texas-instrument af typen

MSP430F149, microcontrolleren er kendt for sin gode balance mellem

strømforbrug kontra ydelse. MSP’en forsynes med en spænding på mellem 1,8-

3,6 V. Dette spændingsområde er også dens outputspænding.

Microcontrolleren har 64 ben, hvor 48 af dem kan bruges som I/O ben

(input/output), desuden kan de fleste I/O ben sættes til enten at være I/O ben

eller til at være en peripheral enhed. De andre ben bruges til andre funktioner

så som analog og digital forsyning, input og output til eksterne krystaloscillator

og mere. Figur 2 viser MSP430F194’erens tilslutningsben.

Figur 2: Microcontrollerens ben og dens tilslutningsmuligheder [2]


13

Microcontrolleren er bygget på Von Neumann arkitekturen, som er bygget op

af:

• Hukommelse

• CPU - Central Processing Unit, bestående af

– Aritmetisk enhed

– Kontrolenhed

• Input

• Output

Hukommelsen er det separate datalager, hvor informationer som computeren

ikke arbejder med gemmes væk i. Den arbejder begge veje med CPU’en ved

hjælp af de to databus, Memory data bus (MDB) og Memory Adressing data bus

(ADB).

CPU’en består af to dele, en aritmetisk enhed, der laver alle de matematiske

beregninger, og en kontrol enhed der styrer adresserne i hukommelsen på de

data der skal bruges eller gemmes. Figur 3 illustrerer princippet for en Von

Neumann maskine.

Figur 3: Det indre af en Von Neuman Maskine [6]


14

8.2 CPU Registre

[1][7][8]

En RISC CPU har indbygget

højhastighedshukommelse

kaldet registre, hvor der lagres

værdier (bits) indtil de skal

bruges. Ydermere har CPU’en

har en aritmetisk logisk enhed

(ALU) der udfører beregninger

på de lagrede værdier. Endelig

er der i CPU’en en

kontrolenhed, der styrer alle

microcontrollerens

operationer. Blokdiagrammet

over CPU’ens registre er

illustreret på Figur 4.

Microcontrolleren MSP430F149

har 16 filregistre med plads til

16 bits hver.

I MSP430F149 er der fire

special purpose registre (R0-R3)

til særlige funktioner og 12

general purpose registre (R4-

R15) til lagring af bits. Her

følger en beskrivelse af special

purpose registrene.

Figur 4 CPU blokdiagram. Her ses de 16 registre samt

ALUen der kan give forskellige outputs. [1]


15

R0 – Program Counter (PC)

Dette register holder altid øje med den næste instruktion der skal udføres. Dvs.

den instruktion der kommer efter den igangværende instruktion.

R1 – Stack Pointer (SP)

I et tilfælde hvor CPU’en har mere end én opgave den skal udføre, bruges Stack

Pointeren. En CPU har en RAM-stack som den kan gemme igangværende

instruktioner i. Her er vist et eksempel.

1: CPU’en arbejder på en instruktion Opg. (1).

2: CPU’en får en ny instruktion Opg. (2) ind, og sætter Opg. (1) over i stacken.

3: CPU’en får endnu en ny instruktion Opg. (3) ind, og sætter Opg. (2) over i

stacken.

4: CPU’en er færdig med Opg. (3) og går tilbage til at arbejde på Opg. (2). Det

ses her at instruktionerne hentes fra stacken på en sådan måde, at den

instruktion der kom sidst ind kommer først ud. Dette kaldes LIFO.

Figur 5 Eksempel på CPU-arbejde. Trinvis gennemgang er beskrevet ovenfor.


16

R2 – Status Register (SR)

Dette register bruges til flere ting, bl.a. til at markere beregninger i ALU’en. I

forbindelse med CPU’ens beregninger bruges fire bits; Zero (Z), Carry (C),

Overflow (V) og Negative (N) bits. Giver ALU’en f.eks. et negativt resultat, bliver

dette markeret af N-bitet hvilket kan indvirke på en forudbestemt måde i et

stykke software.

Herunder ses Status Registrets bits.

R2 og R3 - Constant Generatorer (CG1 og CG2)

Constant Generatorerne CG1 i R2 og CG2 i R3 har seks af de mest almindelige

konstanter lagret, således at de er let tilgængelige hvis de anvendes i et

program.

Figur 6 Status Register bits [1]


17

8.3 Digital I/O

[1]

Den MSP430 der benyttes i projektet har seks I/O porte, P1-P6, hvor hver af

disse har otte ben. Hver port har nogle registre der benyttes til at konfigurere

de enkelte ben. De i alt 48 ben kan enten bruges som digital I/O, eller en

peripheral der er forskellig fra ben til ben. Eksempelvis kan benene på port 6

bruges som analog-digital convertere, ADC.

Registret der styrer dette, hedder PxSEL hvor x er den anvendte port. Hvis en bit

er sat til 1, vil det tilhørende ben fungere som den peripheral der kan findes i

databladet, hvorimod hvis biten er sat til 0, vil benet fungere som digital I/O.

Afhængig af hvilken funktion der benyttes på et ben, vil der være forskellige

registre til at konfigurere dette. Hvis et ben er sat til en speciel egenskab, vil

funktionen og opsætningen af benet kunne bestemmes i nogle tilhørende

registre. Hvis benet derimod er sat til digital I/O, altså PxSEL er sat til 0, findes

der andre registre til at styre funktionen af benet.

Tabel 1: Registre til digital I/O på P1 og P2. [1]

Tabel 2: Registre til digital I/O på P3 til P6 [1]


18

Som det kan ses ud fra tabellerne ovenfor er portene P1 og P2 lidt anderledes,

da de har interrupt egenskaber, hvilket portene P3-P6 ikke har. PxIN registret er

et read only register, hvilket betyder at det kun er muligt at aflæse fra registret,

hvorimod alle de andre registre også har mulighed for at blive ændret på,

read/write register.

PxIN reflekterer det signal der er på det efterspurgte ben, hvor 1 betyder at

indgangen er høj, og 0 betyder at den er lav. Med PxOUT registret er det muligt

at ændre et bens output ved at ændre den tilhørende bit, 1 for højt output og 0

for lavt output. PxDIR registret bruges til at bestemme om et ben skal være

output eller input, 1 for output og 0 for input. Disse registre er ens for alle

portene, men som nævnt tidligere har port 1 og 2 også interrupt egenskaber, og

dermed også yderligere 3 registre til at kontrollere dette.

PxIFG, også kaldet interrupt flag, bliver sat til 1 når et interrupt har fundet sted.

Samtidig skal PxIFG sættes lav igen efter interruptet er udført, da programmet

ellers ville blive hængende ude i interrupt koden. PxIES er til at bestemme om

interrupt flaget skal sættes på dens nedadgående- eller opadgående flanke. For

at interruptet kan fungere skal det dog også enables på det bestemte ben, dette

gøres ved at sætte den tilhørende bit til høj i registret PxIE, der står for

interrupt enable. Når PxIFG samt PxIE er sat vil interruptet altså blive udført.

8.4 Interrupt

[9]

Et interrupt er et asynkront signal fra hardware eller software der indikerer et

behov for eksekveringstid, hvilket betyder at interrupts medfører asynkrone

spring i kode eksekveringen, mens eksempelvis funtionskald medfører synkrone

spring, bestemt af brugeren.

Et interrupt vil altså på et hvilket som helst tidspunkt i kodeeksekveringen, være

i stand til at bremse den nuværende eksekvering, og i stedet påbegynde

eksekveringen i den kode der er tilsluttet interruptet. Herefter vil program-

counteren igen går tilbage til det sted den befandt sig før interruptet. Dette er

illustreret på Figur 7.


19

Figur 7: Viser hvorledes en interrupt service rutine, ISR, opfører sig [9]

Ved flere interrupts på samme tid vil microcontrolleren selv prioritere

interruptsne, og dernæst eksekvere dem i rækkefølgen bestemt af

prioriteringen.

MSP430, der benyttes i dette projekt, understøtter 3 forskellige slags interrupt,

system reset, non-maskable og maskable:

• System reset bruges til nulstilling af systemet og kaldes automatisk ved

systemopstart.

• Non-maskable interrupts aktiveres eksempelvis ved oscillator fejl eller

ved forkert tilgang til flash-hukommelsen

• Maskable interrupts bliver aktiveret af eksterne enheder såsom timere,

digital I/O, ADC, PWM, seriel osv.


20

8.5 PWM

Pulsbreddemodulering, på engelsk pulse-width modulation (PWM), benyttes til

at styre mængden af effekt der sendes til en enhed. Pulsbreddemodulering er

et digitalt periodisk signal vis pulsbredde moduleres. Herved varieres det

gennemsnitlige output for perioden. Variationen af outputtet er afhængig af

signalets duty cycle �, der kan skrives som:

periode

on

T

TD =

Hvor �� er den del af perioden � hvor signalet er højt og �� blot er hele

perioden �

Gennemsnitsværdien for et pulsbreddemoduleret signal er givet ved formlen:

∫=T

dttvT

v0

)(1

Hvor �� er spændingen som funktion af tiden �, der over én periode kan

skrives som:

( )

≤≤⋅

⋅≤≤=

TtTDv

TDtvtv

L

H

,

0,

Herved bliver gennemsnitsværdien �:

( )( ) LH

LHTD T

TDLH vDvD

T

vDTvTDdtvdtv

Tv −+⋅=

−+⋅⋅=

+= ∫ ∫

⋅

⋅1

11

0

Formlen ovenfor kan simplificeres endnu mere, da det ofte ved

pulsbreddemodulerede signaler er således, at � � 0 og herved fås:

HvDv ⋅=


21

Gennemsnitsværdien kan herefter benyttes til for eksempel at bestemme

robottens motorkraft. Hvis PWM signalet er indstillet således at

gennemsnitsspændingen bliver 50 % af den maksimale spænding, vil robotten

samtidig kun køre med 50 % motorkraft.

8.6 Clock

[1]

MSP430F149 er udstyret med tre forskellige clockmoduler. Clockmodulerne

bruges til at styre hvilken frekvens der skal bruges og hvordan clockfrekvensen

skal genereres. Ved brug af tre forskellige clockmoduler, er det muligt for

brugeren selv at bestemme den mest optimale balance mellem regnekraft og

strømforbrug.

De tre forskellige clockmoduler er følgende:

LFXTCLK:

Kan både bruges som lav- og højfrekvens oscillator

XT2CLK:

Bruges som højfrekvent oscillator (7.3728 MHz)

DCOCLK:

Bruges som en intern digitalstyret oscillator. (default ~725 KHz)

XT2CLK er også det der kaldes en ekstern clock, da den ikke sidder på selve

microcontrolleren. Clocken er et krystal der kan oscillere en frekvens på op til 8

MHz. DCOCLK er microcontrollerens interne clock.

De tre clockmoduler bruges til at generere tre forskellige clocksignaler: ACLK

(auxiliary clock), MCLK(master clock) og SMCLK (Sub-Main clock). ACLK kommer

fra LFXT1CLK. MCLK og SMCLK er softwareafhængige, og ved brug af disse er

det muligt at vælge hvilke clockmoduler der skal bruges.

Der kan vælges imellem LFXT1CLK, XT2CLK eller DCOCLK. Disse clocksignaler kan

alle divideres med 1,2,4 eller 8 for at mindske clockcyklussen.


22

8.7 ADC

[1]

MSP430F149 har en indbygget 12-bit ADC vis diagram kan ses på Figur 8.

Microcontrolleren giver mulighed for selv at definere hvilket interval der skal

måles i, hvilket kan gøres ved hjælp af den nedre og øvre grænse, hhv. VR- og

VR+. De udgør et område der bliver opdelt i 4095 intervaller. Den nedre grænse

kan stilles til GND eller til en ekstern kilde. Den øvre grænse kan defineres

gennem microcontrolleren til at være 1.5V-, 2.5V-, 3.3V forsyningsspænding

eller til at komme fra en ekstern spændingsreference.

Figur 8: Diagram over ADC12 [1]


23

VR+ defineres med de to bits SREF1 og SREF0 og via disse to bits kan det

defineres om VR+ skal komme fra den indbyggede spændingsregulator. Mens VR-

kan defineres via SREF2 som sættes til enten GND eller en ekstern reference.

INCHx-blokken er en 4-bit multiplexer som bestemmer hvilken port ADC’en skal

sample på. De første otte eksterne indgange på microcontrolleren sidder på

pins 59-61 og 2-6. Alt dette gemmes i ADC12MCTLx-registret og når

konverteringen er færdig bliver det gemt i hukommelsesregistret ADC12MEMx.

Det er en 16-bit register og resultatet er på 12-bit. Når alt dette gemmes i

MCTLx er konverteringen færdig og det bliver tilsvarende gemt i ADC12MEMx-

registret hvor x er konfigurations- og hukommelseselementet. Der er i alt 16

elementer.

ADC12 modulet bruger følgende formel til resultaterne hvor det digitale output

NADC bliver:

−+

−

−

−×=

RR

Rin

ADCVV

VVN 4095

De kontrolregistre der skal bruges til at styre konverteringen er ADC12CTL0,

ADC12CTL1 og ADC12MCTLx.

ADC12 Kontrolregistre ADC12CTL0

ADC12CTL0 og ADC12CTL1 er kontrolregistre, der bestemmer hvorledes

konverteringen skal ske.

Figur 9: ADC12CTL0 kontrolregistret [1]


24

I dette projekt anvendes funktionerne: SHTOx, ADC12ON, og ENC. Disse vil nu

blive beskrevet.

SHT0x: Sample-and-hold time. Disse bits definerer antallet af perioder på

ADC12CLK i sampleperioden for registrene ADC12MEM0 til og med

ADC12MEM7.

SHTx bits ADC12CLK

cyklus

0000 4

0001 8

0010 16

0011 32

0100 64

0101 96

0110 128

0111 192

1000 256

1001 384

1010 512

1011 768

1100 1024

1101 1024

1110 1024

1111 1024 Tabel 3 ADC12CLK cyklus for SHT0x og SHT1x

ADC12ON. ADC12ON er funktioner for tænd/sluk

0� ADC12 slået fra

1� ADC12 slået til

ENC: Enable Conversion.

0� ADC12 slået fra

1� ADC12 slået til


25

ADC12 Kontrolregistre ADC12CTL1

Figur 10 ADC12CTL1 kontrol registret [1]

I dette registrer bruges funktionerne SHP og CPMSEQ_3.

SHP: Sample-and-hold pulse mode. Denne bit bestemmer om sample-and-hold

signalet skal køre direkte til 12 bit SAR eller om den skal have bestemt puls.

0� 12 bit SAR anvendes.

1� anvend bestemt puls.

CPMSEQx: bestemmer hvilken rækkefølge konverteringen skal ske i

Værdi af CPMSEQx bits betydning

00 Enkelt kanal, enkelt konvertering

01 Forløb af kanaler

10 Gentagende enkelte kanaler

11 Gentagende forløb af enkelte kanaler Tabel 4: AdC12CTL1 for CPMSEQx

Memory Kontrolregistre ADC12MCLx

Der findes 16 memory kontrolregistre. Resultatet af konverteringen af de 12 bit

gemmes i hvert sit register. Siden ADC12 er en 12 bit konvertering, vil de sidste

fire bit (bit 12-15) altid være nul.


26

Figur 11 ADC12MCTLx memory kontrol registret [1]

INCHx: Input Channel Select. Disse bits bestemmer hvilke indgange der benyttes

til ADC12 modulet. Tabel 5 viser bit-kombinationerne.

input Betydning

0000 A0

0001 A1

0010 A2

0011 A3

0100 A4

0101 A5

0110 A6

0111 A7

1000 VeREF+

1001 VREF_/VeREF_

1010 Temperature diode

1011 (AVcc – Avss)/2




1111 (AVcc – Avss)/2 Tabel 5: Valg af indgangsben


27

8.8 Timere

[10]

Der er tre timere i den MSP der benyttes i projektet.

• Watchdog timer

• Timer A

• Timer B

Watchdog timeren, WDT, bruges hovedsagligt til at genstarte systemet ved

eventuelle systemfejl. Watchdog timerens funktion er at efterspørge et signal

fra microcontrolleren om, hvorvidt den stadig fungerer som den skal, hvis

watchdog timeren ikke får dette signal indenfor et vist tidsinterval vil watchdog

timeren gå ind og genstarte systemet automatisk. Derfor er det nødvendigt at

opsætte softwaren til microcontrolleren således at den regelmæssigt sender et

signal ind til watchdog timerens kontrolregister, også kaldet WDTCTL.

Timer A er en synkron 16-bit timer/counter der her kan benyttes til for

eksempel at generere et PWM-signal, og det samme er gældende for Timer B.

8.9 Seriel kommunikation (USART/UART)

[11,694-701]

Til seriel kommunikation mellem hardware og MSP430 anvendes

microcontrollerens USART peripheral i UART tilstand. Standarden for de serielle

kabler der anvendes til kommunikationen hedder RS232.

UTX-benet og URX-benet på MSP430 er forbundet til et USB-seriel UART

interface, således at MSP430 kan sættes til en PC med et USB-kabel.

Asynkron seriel kommunikation foregår ved at der sendes logiske 1ere og 0ere

mellem enheder. Ved brug af UART sendes der bits på følgende måde: Først

sendes et lavt ’0’ start bit for at markere begyndelsen. Derefter sendes

databitene, eller ordet, med LSB først. Så sendes et valgfrit paritetsbit der

undersøger for fejl. Til sidst sendes et ’1’ stop bit for at markere slutningen af

ordet. Et eksempel er vist på Figur 12.


28

Hastigheden hvormed bits sendes mellem to enheder kaldes baud rate.

Hastighed mellem start bit og stop bit kaldes timerperioden. Tages Figur 12 som

eksempel, ses det at der kræves 11 bits for at sende en character. Hvis det

antages at der sendes 10 characters per sekund, så sendes der i alt 110

bits/sekund. Baud raten vil her være 110 bits/sekund. [13,324-325] Baud rates

ligger mellem 2400-115.200 bits/sekund. Denne værdi skal beregnes på

baggrund af en clockfrekvens. Se evt. Afsnit 8.6 for flere detaljer om clock i

MSP430.

Ved asynkron seriel kommunikation sendes data mellem enheder efter lokale

clocks, dvs. hver enhed har sin egen clock at styre efter. En start bit signalerer til

den clock hos modtagerenheden at der skal sendes en bit-række til den, og at

modtageren skal være klar til at modtage. Et stop bit signalerer bit-rækkens

slutning. Clocks er designet til at sende og/eller modtage med 16, 32 elle 64

gange baud rate. Et eksempel på udregning af perioden mellem afsending og

modtagelse er vist herunder. [11,699]

baud960016

KHz 6,153

rate baud

BRCLK N ≈==

N er bitperioden, BRCLK er en kendt krystalfrekvens og baud raten er som sagt

antal bits der sendes.

Baud rate må ikke forveksles med hvor mange data bits der overføres pr.

sekund. I eksemplet På Figur 12 overføres der 80 data bits pr. sekund, hvilket

Figur 12 Eksempel på seriel datatransmission. Se teksten herunder om hastighed for forklaring [12]


29

ikke er det samme som baud raten. Baud raten i eksemplet ovenfor er 110 bits

pr. sekund.

USART registre

Følgende afsnit er en oversigt over relevante bit-registre i USART0 der er

anvendt til seriel kommunikation.

Figur 13 viser USART kontrolregistret med otte bits.

Af disse bits anvendes 7, 5 og 2 i projektet og er derfor af interesse:

PENA: Parity Enable. Denne bit bestemmer om paritetskontrol er slået til eller

fra.

’0’ � kontrolbit slået fra

’1’ � kontrolbit slået til

SPB: Stop bit select. Denne bits tilstand bestemmer om der er et eller to stop

bits efter en række bits. Receiverdelen af dette register checker altid for et stop

bit, uanset indstillingen her.

’0’ � et stop bit.

’1’ � to stop bits.

SYNC: Synchronous mode enable. Denne bit bestemmer tilstanden for seriel

kommunikation.

‘0’ � UART-tilstand

‘1’ � SPI-tilstand

Figur 14 viser USART Transmit kontrolregistret, også med otte bits.

Figur 13 UxCTL USART Kontrol Registre [1]

Figur 14: UxTCTL, USART Transmit Control Register [1]


30

Her anvendes bits 4 og 5:

SSELx: Source Select. Disse bits vælger hvilken baud rate clock der anvendes i

baud rate generatoren.

’00’ � UCLKI

’01’ � ACLK

’10’ � SMCLK

’11’ � SMCLK

Figur 15 viser Module Enable Register 1

Dette register har to bits af interesse, 6 og 7.

UTXE0+: USART0 transmit enable. Denne bit bruges til at slå transmit modulet til

eller fra.

’0’ � modulet er slået fra

’1’ � modulet er slået til

URXE0+: USART0 receive enable. Denne bit bruges til at slå receive modulet til

eller fra.

’0’ � modulet er slået fra

’1’ � modulet er slået til

Figur 15 ME1, Module Enable Register 1 [1]


31

9 Implementering

Denne del af rapporten omhandler implementering af hard- og software, dvs.

hvorledes disse er anvendt til at opbygge en autonom robot. Et detaljeret

blokdiagram for robotten kan ses i Bilag 1.

9.1 Dimensionering af robotten

Robotten er bygget op af LEGO med en længde på 30 cm og en bredde på 33

cm. Robotten har fire hjul, hvor to motorer driver baghjulene. På robottens

forhjul er der påsat klisterbånd, da dette nedsætter friktionen og derved gør det

lette for robotten til at dreje. Hjulene der er anvendt til robotten har en

diameter på 6.3 cm og en omkreds på 19.8 cm. Dette finder anvendelse til

motorstyringen, hvis software er beskrevet i Afsnit 9.4.2.

Figur 16 LEGO hjul anvendt til robot

Forrest på robotten sidder to sensorer der får robotten til at styre udenom

forhindringer. Der sidder en sensor foran og en sensro på højre side. To

takometre der i sammenhænge med microcontrolleren fungerer som encodere

er sat på robotten ved siden af motorerne således at de kan tælle tilbagelagt

distance.


32

Robotten er konstrueret således at den også kan bære det relativt tunge

batteri, der vejer 1,3 kg.. Figur 17 og Figur 18 er billeder af robotten. Figuren af

robotten er vejledende, da målestoksforholdet ikke passer med den egentlige

robot.

Figur 18 Robotten set fra højre side

Figur 17 Robotten set fra oven


33

9.2 Hardwareopbygning

De følgende afsnit giver en beskrivelse af den hardware der er blevet anvendt

for at bygge det fysiske system. For flere tekniske detaljer om komponenterne

henvises der til databladene i bilagene og databladene på den vedlagte CD.

9.2.1 Takometer

Distanceaflæsning af robotten bruges til at kunne aflæse hvor langt robotten

har kørt. Til distanceaflæsning er der anvendt to hulskiver fra en Microsoft

Intelli Mouse og to optiske sensorer med fototransistor output, disse er af

typen TCUT1200. De to optiske sensorer indeholder begge en infrarød diode og

to fototransistorer. De to hulskiver er monteret direkte på de to bagerste hjul,

og kan dermed måle den tilbagelagte distance vha. microcontrolleren.

Figur 19: Tv. ses hvordan den optiske sensor er tilkoblet hulhjulet [14]. Th. ses kredsløbdiagrammet for

takometret

Det fungerer ved at en infrarød lysdiode udsender infrarødt lys ud på hulskiven,

når lyset rammer igennem hullet i hulskiven, sendes lyset videre til en

fototransistor, fototransistoren detekterer lyset og åbner for 5v forsyningen og

sender den videre til Schmitt Triggeren, signalet til Schmitt Triggeren inverteres,

så hvis Schmitt Triggeren modtager et logisk 1, sender den et logisk 0 ud til

MSP’en.

Hulskiven har 18 huller og koblet til hjulet med en 1 til 1 gearing, det vil sige når

hjulet har drejet en omgang, fås der 18 pulser. Disse sendes ind til


34

microcontrolleren, der kan udregne den tilbagelagte distance for hjulet, når

robotten skal rotere.

9.2.2 Motorstyring

Robottens to motorer er 9 volts DC LEGO-motorer af typen 71427. Motoren

består af forskellige komponenter. En magnet sætter motoren i gang når der

føres spænding over den. Positiv spænding får motoren til at køre frem, mens

negativ spænding vender polariteten og får motoren til at køre baglæns. [11,

673-676]

Den anvendte IC til motorstyring hedder L298. Den kaldes også H-bro, da

kredsløbet har form som et stort H. En H-bro kan styre én motor der kan køre

både frem og tilbage. L298 har to H-broer, således at den kan styre to motorer.

Se evt. diagrammet i siderne fra databladet der er vedlagt som Bilag 6.

Figur 20 er en del af blokdiagrammet over det kredsløb der er opbygget til

robotten. En tegning af hele kredsløbet er vedlagt som Bilag 1. Tabel 6 er en

sandhedstabel for inputtene A og B i bufferne 1 og 2 i L298. Tabellen viser hvad

der sker i H-broen, når inputtene er høje og lave. En tilsvarende tabel for

inputtene C og D i bufferne 3 og 4 er siderne fra databladet der kan ses i Bilag 6.


35

Input Input Funktion

A=H; B=L Fremad

Ven=H A=L; B=H Bagud

A=B Brems

Ven=L A=X; B=X Friløb Tabel 6 Sandhedstabel for H-bro (Inputs A og B)

Der er sat dioder ind i kredsløbet for at beskytte det. Hvis dioderne ikke var i

kredsløbet, kunne andre komponenter tage skade af den ’flyback voltage’ der

opstår når motorerne sættes til at stoppe. Derudover er der to kondensatorer i

kredsløbet. Disse har til formål at skabe forsinkelse og forhindre at begge

udgange 1 og 2 er høje på samme tid. Det ses i sandhedstabellen at motoren

stopper, når A=B.

Figur 20 Kredsløbsdiagram over

H-bro


36

9.2.3 Afstandssensor

[15]

En af de ting robotten skal kunne er at navigere rundt i et rum, og den skal

kunne måle afstand for ikke at køre ind i væggene.

Til afstandsmålingen anvendes to sensorer på fronten og højre side af robotten.

Disse sensorer er infrarøde analoge afstandsmålere af typen Sharp GP2D12. De

har den egenskab, at de kan opfange objekter uden nogen indflydelse fra

hvilken farve det reflekterende objekt har. Figur 21 viser et blokdiagram over

GP2D12 sensoren.

Ifølge sensorens datablad kan GP2D12 måle objekter indenfor en afstand af

10cm til 80cm og giver et spændingsfald i intervallet mellem 0.4V og 2.6V.

Databladet kan ses i Bilag 7. Figur 22 er en graf fra databladet, der viser hvordan

karakteristikken for GP2D12 er.

Figur 21 Blokdiagram for SHARP sensor [13]


37

Afstandsmåleren GP2D12 er en færdigbygget enhed, der er forbundet til

microcontrollerens ADC som er beskrevet i afsnit 8.7. GP2D12 har 3 pins: en

GND, Vcc og Vo. Hvor Vo outputsignalet er forbundet direkte på

microcontrollerens ADC på port 6.0, der svarer til pin 59. Se Figur 23. Ligeledes

er en anden sensor sat til microcontrollerens port 6.1, pin 60.

Figur 23 Forbindelsen mellem GP2D12 og MSP’en

Figur 22 Databladets karakteristik for SHARP sensor, som

viser spænding pr. cm [15]


38

9.3 Beregningshastigheder

For at kunne bruge de forskellige elementer til projektet, som takometre og

microcontrolleren, er det nødvendigt at se om enhederne er hurtige nok til at

følge med, når robotten kører, og se om en eventuelt tophastighed på robotten

skal justeres ned. Dette gennemgås i følgende afsnit.

9.3.1 Takometer

For at kunne bestemme den maksimale hastighed robotten må køre, er det

nødvendigt at kigge på de forskellige komponenter som elektronikken

indeholder. Takometret indeholder tre komponenter der kan begrænse

hastigheden på robotten: optisk sensor, Schmitt Trigger og buffer.

Den optiske sensor med fototransistor output er af typen TCUT1200. Ifølge

databladet har sensoren et maksimalt propagation delay på 150 sµ . Databladet

kan ses i Bilag 4.

Schmitt Triggeren er af typen MC74HCT14A. denne komponent har i værste fald

et propagation delay på 32ns. Databladet for Schmitt Triggeren kan ses i Bilag 5.

Bufferen er af typen 74HCT541N og har et propagation delay på 12 ns.

Databladet ligger på vedlagte CD.

Ud fra betragtningerne af komponenterne, fremkommer det at den optiske

sensor med fototransistoroutput, er den langsomste enhed. Deraf kan det

udregnes hvor mange pulser i sekundet den kan klare. Hulhjulet der er tilkoblet

takometeret, er på 18 huller, og derfor kan den maksimale rotation pr. hjul

skrives:

37,370rotation hjulets

15018rotation hjulets

1

=

=⋅

c

sµ

Det fremkommer af resultatet, at den maksimale rotation/sekund for

takometeret er 370 omdrejninger pr. sekund. Den maksimale hastighed for

robotten kan nu udregnes


39

]/[ 7,263

][1000

][3600

100

][8,19][370

][1000

][3600hjulet af ][370

tkmedtophastigh

m

scmrpsedtophastigh

m

somkredsenrpsedtophastigh

=

⋅⋅=

⋅⋅=

c

c

Ud fra resultatet er der fundet frem til, at elektronikken kan håndtere robotten

med en tophastighed på op til 263,7 km/t. Det kan ses af resultatet og

konkluderes, at hardwaren ikke er nogen begrænsning for robotten

9.3.2 MSP

For at kunne undersøge om MSP430F149 kan følge med til at trække de

interrupts der kommer fra takometrene, er det nødvendigt at kigge nærmere på

MSP’en. Der er tilsluttet to takometre, og hvert takometer giver 18 inputs pr.

omgang. Dette betyder at MSP’en modtager 182 ⋅ inputs for hver gang hjulene

på robotten har kørt en omgang. I projektet bruges DCOCLK til at foretage disse

beregninger. Denne kører med en clockcyklus, som er målt til at være på 767

kHz, hvilket betyder at den kan foretage 767.000 instruktioner pr. sekund.

Dette betyder at en instruktion tager

sµ3,1767000

1=

I MSP430x1xx Family User’s Guide kan det læses, at et interrupt bruger fem

clockcyklusser foruden interruptkoden.

Desuden er robotten målt til en topfart på 1 km/t, dette er lig med 0.28 m/s.

Hermed kan det udregnes hvor mange interrupts den får pr. sekund:

rps

hjuletsomkredshjulets

edtophastigh

42,10,197

0,28

sekund pr.er omdrejning

=

=−

c


40

Hjulets omdrejninger pr. sekund ⋅ 18 huller = interrupt pr. sekund

sekund

interrupts56,251842,1 =⋅

Da der haves 2 takometre, ganges dette med 2

sekund

interrupts12,51256,25 =⋅

Desuden er det nødvendigt at vide hvor mange instruktioner pr. sek.

programmet tager. Dette findes ved at se på krydskompileringen til assembler:

Figur 24: Viser de otte assembler instruktioner c-koden foretager.

Koden tager otte assembler instruktioner pr. takometer for hver gang den

tæller en op, dvs. den tager 16 instruktioner i alt og hvert interrupt tager fem

instruktioner. Herved får vi i alt en maksimal belastning på 26 instruktioner.

Ud fra det ovenstående kan den samlede belastning af MSP’en for takometrene

beregnes:

%173,0%100767000

1nerinstruktio26

sekund

interrupt12,51 =⋅⋅⋅

Ergo kan det ud fra ovenstående konkluderes at MSP’en bruger maksimalt

0,173 % af dens kapacitet på at beregne inputs fra de to takometre, hvilket

betyder at MSP’en kan håndtere alle inputs fra takometrene.


41

9.4 Softwareopbygning

I dette afsnit vil robottens software opbygning blive beskrevet. Der vil blive set

på programkoden i de funktioner der anvendes, hvorfor de anvendes og

hvordan de initialiseres. Til at give et overblik på hvordan programkoden skal

fungere er der lavet flowcharts. Hoveddelen af programmeringen er i sproget C,

med en undtagelse af terminalprogrammet, som er i C#.

9.4.1 Programmets opbygning

Robottens program består af en stor main() funktion der kalder andre

delfunktioner så som PWM, motor og seriel kommunikation.

Selve main programmet indeholder tre hoveddele:

- Første del kalder de initierende funktioner

- Anden del der styrer manuel kørsel

- Tredje del der styrer den autonome styring

Det flowchart der er opstillet for hele funktionen er vedlagt som Bilag 3.

Figur 25 Programkode for første del af main


42

Manuel kørsel

I manuel tilstand skal robotten kunne styres efter behov. Inden selve softwaren

blev lavet er der tegnet et flowchart over hvordan robotten skal køre.

Flowchartet er vist på Figur 26.

Figur 26 Flowchart for manuel styring

Robotten er i manuel styring så længe autorun er slået fra. Derefter kan den

styres gennem en terminal. Robotten kan så, ud fra de data som den modtager,

bestemme hvilken retning den skal køre i, hvis den f.eks. drejer til højre vil den

forblive med det, indtil den afbrydes af en anden instruktion. Hvor hurtig den

kører er fastsat via PWM, hvilket i dette tilfælde er 75 %. Den vil forblive i

manuel tilstand indtil den har modtaget et ’A’ fra terminal programmet,

derefter slår den over til autorun eller autonom kørsel som det også hedder.


43

Main koden for den manuelle styring ses her på Figur 27.

Figur 27 Programkode for manuel styring


44

Autonom kørsel

Udover manuel styring skal robotten også kunne køre autonomt. Dette gøres

ved hjælp af nogle funktioner. Idéen i dette går ud på at robotten skal finde en

væg, og derefter reagere på forskellige måder med hensyn til hvilken af

sensorerne der har registeret væggen. Der er opstillet et flowchart over de

forskellige situationer der kan forekomme, og hvordan den vil reagere på dem.

Figur 28 viser flowchartet.

Begin

Forward

Front Sensor

Right SensorTurn Left Turn Right

True

True

False

False

STOP

If it receive ’M’

False

Enable Manuel

ModeTrue

Figur 28 Flowchart for autonom kørsel

Som det kan ses ud fra det opstillede flowchart vil robotten undersøge om den

har modtaget et ’M’. Hvis dette er tilfældet slår den over på manuel kørsel og

her vil den blive indtil den har modtaget et ’A’. Hvis den derimod ikke modtager

et ’M’ kører robotten fremad indtil den møder en væg, hvorefter den drejer 90˚

til højre.

Herefter kører robotten softwaremæssigt tilbage i løkken og ser endnu engang

efter om den modtager et ’M’. Hvis dette ikke er tilfældet fortsætter den lige

ud, og hvis der denne gang er vægge både foran og til højre for robotten, så vil


45

den dreje 90˚ til venstre. Den vil så forsætte i denne rutine indtil den har

modtaget et ’M’.

Selve main programmet for den autonome styring kan ses på Figur 29:

Programkoden viser at, når autorun == 1 så er autonom kørsel slået til.

Manuel kontrol bliver enabled når autorun == 0 hvilket svaret til at UORXBUF

modtager et ’M’.

PWM_signal (3072,3072); svarer til at motorerne kører med 75 % duty cycle,

hvilket genererer en hastighed på 75 % af dens maksimale hastighed.

ADC12MEM0 < 0x400; gør, at hvis der ikke er en væg foran robotten indenfor

40cm vil funktionen Motorstyring(2,2); og PWM_signal (3072,3072) få robotten

til at køre lige ud.

Figur 29 Programkode for autonom kørsel


46

Hvis sætningen ADC12MEM0 == 0x400 er sand, undersøger den herefter om

der er en væg indenfor 40cm til højre for robotten vha. sætningen

ADC12MEM1 > 0x26c. Hvis der er en væg, så drejer den 90˚ til venstre vha.

funktionen rotate_90_left();

Hvis der derimod ikke er en væg til højre for robotten inden for 40cm, drejer

den 90˚ til højre vha. rotate_90_right();

Hvis robotten i et tilfælde drejer mere end beregnet og kommer skævt ind på

væggen vil programkoden ikke korrigere for det, men den vil fortsætte sin

skæve kørsel til et punkt hvor sensorerne ikke registrerer væggen og dermed vil

den køre ind i væggen. I så fald er det dog muligt a stoppe robotten vha.

terminalprogrammet.

9.4.2 Motorstyring

Til at styre robotten er det nødvendigt med en motorstyring, da robotten i

projektet kun kan dreje ved hjælp af en differens mellem de to motorer.

Motorstyringen består af et stykke software der i sammenhæng med den

anvendte H-bro kan styre de to motorers retning. Softwaren til motorstyringen

bruges til at sætte H-broens 4 indgange (2 per motor) høje eller lave, alt efter

hvilken retning robotten skal køre i. Til dette skal microcontrolleren først

initialiseres, hvilket funktionen Motor_Init gør, herefter kan den generelle

motorstyring anvendes, samt de to funktioner Rotate_90_left og

Rotate_90_right. På Figur 30 ses et flowchart for hvordan selve motorstyrings

funktionen er opbygget:


47

Figur 30: Flowchart for funktionen Motorstyring(int, int)

Som nævnt ovenfor skal microcontrolleren dog først initialiseres inden selve

motorstyringen kan fungere. Dette gøres ved nedenstående kode af funktionen

Motor_Init:

Figur 31: Programkoden for funktionen Motor_Init()

Da motorstyringen blot består i at sætte nogle ben høj/lav, er initialiseringen

deraf også simpel. Som det kan ses ud fra koden er det blot en opsætning af

P1.4/5/6/7 som output samt I/O.

Herefter kan robottens retning styres, ved hjælp af funktionen motorstyring.

Herunder er et lille uddrag af koden fra motorstyringen.


48

Figur 32: Lille del af programkoden for funktionen Motorstyring(int, int)

Som det kan ses ud fra koden bliver de enkelte ben blot sat høje eller lave, alt

efter hvilken retning robotten skal køre i. Hvis robotten for eksempel skal køre

bagud, bliver benene ligeledes sat således at de igennem H-broen får begge

motorer til at køre bagud. Hvis robotten derimod skal dreje til højre, vil venstre

motor blive sat til at motorbremse, imens højre motor sættes til at køre bagud.

For at robotten kan opfylde kravet om at kunne køre rundt i et retvinklet rum,

er det også nødvendigt med en funktion der får robotten til at dreje 90˚ til både

højre og venstre. Hertil benyttes motorstyringsfunktionen i sammenhæng med

de encodere der sidder på robotten.


49

Figur 33: Flowchart for funktionen rotate_90_left()

Som det kan ses ud fra flowchartet vil en variabel kaldet right_encoder blive

undersøgt, og imens denne er mindre eller lig med variablen left_encoder + 32

vil robotten dreje til venstre ved hjælp af motorstyringsfunktionen. Når

right_encoder er større end left_encoder + 32 vil den stoppe.

For at få robotten til at dreje præcis 90˚ benyttes de to encodere til at aflæse

hvor meget robotten har drejet. Antallet af interrupts, fra encoderne, der skal

til for at robotten har drejet 90˚ kan beregnes ud fra robottens akselafstand

samt dets hjuls omkreds. Ved rotate_90_left er den venstre motor bremset,

imens den højre motor kører fremad. Derfor kan afstanden som det højre hjul

skal køre beregnes med formlen:

cm56,344

222=

⋅⋅ π

Hvor de 22 er robottens akselafstand.

De encodere der anvendes laver 18 interrupts på en omgang, derfor kan

antallet af interrupts for 90˚, når hjulets omkreds er 6,3 cm, skrives som:

( )interrupts43,31

183,6

558,34=

⋅π

Dette tal gør at robotten ikke vil komme til at dreje præcis 90˚, da funktionen

kun kan regne med hele tal, og der derfor vil være en fejlmargen på cirka +-0,5


50

interrupts, eller cirka 1,5˚. For at mindske denne difference kunne

akselafstanden på robotten ændres, men da fejlen ikke er større ses dette ikke

nødsaget. Selve koden for funktionen kan ses herunder på Figur 34:

Figur 34: Programkoden for funktionen rotate_90_left()

Heraf ses det at funktionen for rotate_90_left skrives som en while løkke der

kører indtil right_encoder er 32 højere end left_encoder, og robotten har drejet

cirka 90˚. I denne løkke sættes robotten til at dreje til venstre med et PWM

signal på 75 %, da periodelængden er 4096. Til sidst vil den ved hjælp af

motorstyringsfunktionen stoppe robotten. Det samme vil gøre sig gældende for

rotate_90_right hvor det bare er den venstre encoder der tælles på i stedet.

9.4.3 Encoder

For at kunne kontrollere de to asynkrone signaler som takometrene kommer

med, skal der bruges maskable interrupts, som er en indbygget funktion

microcontrolleren har. Denne funktion aktiveres ved at skrive _BIS_SR(GIE). De

eneste to porte der understøtter interrupts på MSP430F149 er port 1 og port 2.

Desuden skal der bruges en interrupt service rutine der hele tiden tjekker for

interrupts, til dette har microcontrolleren en funktion der hedder

PORT2_VECTOR. På figur 35 ses et flowchart for den program-fil der anvendes

til at styre encoderne på MSP’en:


51

Start

P2IFG=01

PORT2_VECTOR

left_encoder++

right_encoder++

No

Yes

P2IFG=02

Yes

No

Figur 35: Viser flowchart diagram over encoder.

Den første funktion er PORT2_VECTOR, i denne funktion tjekker den først om

ben et er højt på P2IFG, hvis den er høj, adderes der en til variablen

left_encoder, herefter går den ned og tjekker ben to på P2IFG, hvis denne er høj

adderes der også en på variablen right_encoder og sådan bliver den ved, ud fra

dette flowchart er programkoden skrevet.

Figur 36: Programkode for Encoder_Init()


52

Først vil programkoden for initialiseringen af koden for encoderen gennemgås.

Her sættes maskable interrupts til at være aktiveret. Derefter sættes P2.0 og

P2.1 til at være input porte. Herefter sættes port 2.0 og port 2.1 til at være I/O

ben. Dernæst cleares interruptflag. Den sidste linie aktiverer interrupt på P2.0

og P2.1. Efter alt initialiseringen for encoderne er PORT2_VECTOR koden

skrevet. Denne ser således ud:

Figur 37: Viser PORT2_VECTOR funktionen

#Pragma er nogle direktiver der fortæller hvordan microcontrolleren skal

behandle forskellige funktioner. I dette tilfælde skal den behandle funktionen

som en interrupt vektor rutine, og denne er så lig med PORT2_VECTOR.

Herefter defineres interrupt funktionen EncoderHit. Inde i denne funktion er

der to if-sætninger. Den ene sætning gør at når det første bit på port 2 er højt,

adderes der én på variablen left_encoder. Den anden gør at når det andet bit på

port 2 er højt, så adderes der en på variablen right_encoder, som tidligere

beskrevet under flowchartet for encoderen.


53

9.4.4 PWM

For at kunne kontrollere robottens hastighed, anvendes timer A til at generere

et PWM signal. Microcontrolleren har nogle ben der specifikt kan benyttes til

dette, da de har tilhørende PWM-registre. For at kunne opsætte

microcontrolleren til at generere dette PWM-signal er det nødvendigt med en

program-fil, der både initialiserer microcontrolleren til at anvende PWM, samt

til senere hen at kunne variere robottens hastighed efter behov. Til dette

anvendes funktionerne PWM_Init og PWM_Signal.

Den første funktion, PWM_Init() er, som dets navn hentyder, en initialisering af

microcontrolleren til at generere et PWM-signal.

Figur 38: Program-koden for funktionen PWM_Init()

Som det kan ses ud fra koden, bliver microcontrollerens ben, P1.2 og P1.3, sat

til output. Grunden til dette er at de, udover at fungere som almindelig digital

I/O ben, også kan anvendes som Timer A ben. Herefter bliver periodelængden

på PWM-signalet defineret ved at skrive til microcontrollerens timer A register

CCR0. Dernæst bliver Timer A’s capture/compare kontrol register for TA1/2 sat,

samt resat med kommandoen OUTMOD_7. Den sidste kommando vælger

submasterclocken til at styre Timer A, samt sætter timeren til at køre i up mode,

hvilket vil sige at den tæller op til og med værdien for CCR0, i dette tilfælde

4096.

Efter microcontrolleren er initialiseret kan robottens hastighed ændres ved

hjælp af funktionen PWM_Signal.


54

Figur 39: Program-koden for funktionen PWM_Signal(int, int)

Funktionen har den simple egenskab at kunne ændre de to udganges Ton, og

herved regulere robottens hastighed. Registrene CCR1 og CCR2 sættes i

programmets main til 3072, hvilket er tre fjerdedele af PWM signalets periode

som blev defineret i funktionen PWM_Init. Dette vil få robotten til køre med en

hastighed på 75 % af dens maksimale hastighed.

9.4.5 Sensor

[1]

Der er monteret to analoge afstandssensorer på fronten og højre side af

robotten. Ved hjælp af microcontrollerens 12 bit ADC, konverteres signalerne

fra afstandssensorerne til digitale signaler.

Figur 40: Program-koden for funktionen Sensor_Init

Initialiseringskoden til afstandsmåleren starter med at tænde og opsætte

P6.0/1 til ADC. Når ADC’en er startet laver den gentagende konverteringer.

Først sættes kontrolregisteret ADC12CTL0 til at være lig med sampletilstanden

SHT0_2 som bestemmer antallet af perioder. For at få en automatisk

konvertering som sker hurtigst muligt benyttes multiple sample konvertering

(MSC).


55

Kontrolregistret ADC12CTL1 sættes til at være lig med SHP og CPMSEQ_3 som

bestemmer samplings- og konverteringsrækkefølgen. I dette tilfælde vil den

gentage konverteringer af en række kanaler.

Memory kontrolregisteret ADCMCTL0 og ADCMCTL1 sættes henholdsvis til

INCH_0 og INCH_1, disse funktioner bestemmer hvilke indgange der skal

benyttes(A0 og A1).

Kontrolregisteret ADC12CT0 bliver OR’et med ENC hvilket aktiverer

konverteringen. Pin 6.0 og 6.1 vælges til at være de ben der bruges til

opsætning af ADC’en.

9.4.6 Serial

Til kommunikation mellem PC og microcontroller er microcontrollerens USART

peripheral blevet anvendt. Specifikt er USART0 registrene blevet anvendt. Dette

program styrer den serielle kommunikation ved at definere baud rate, indstille

USART enheden og sende data til PC gennem pin 3.4.

Følgende kode er til initialiseringen af seriel kommunikation mellem MSP430 og

PC.

Figur 41 Program-kode for funktionen Serial_Init()

U0BR0 og U0BR1 er baud rate control registre. Disse bestemmer selv sagt baud

raten.

I programmet kan det ses at U0CTL registret er sat til 0x50 i hextal. Dette sætter

U0CTL registrets bits til logiske 1ere og 0ere. Dette gør bl.a. følgende:


56

PENA bit er sat til 0, dvs. at check af paritetsbit er slået fra.

CHAR bit er sat til 1, dvs. at character-længden er 8 bits.

SYNC bit er sat til 0, dvs. at USART interfacet er sat til UART tilstand. Dette gøres

for at kunne sende data til det RS232 interface der anvendes.

I programmet ses det endvidere at U0TCTL registre er sat til 0x30 i hextal. Dette

vælger baud rate source clocken til at være SMCLK.

Registret U0MCTL er sat til 0x00 i hextal. Dette deaktiverer modulationen for

BRCLK, der ellers mindsker baud rate fejlen.

Kommandoen ME1 |= 0xC0; åbner for USART transmit/receive således at der

kan sendes fra microcontrollerens USART peripheral. Til projektets robot er

microcontrollerens transmit porten ikke blevet anvendt til den serielle

kommunikation. Dette program er en standardopsætning hvor både URXE0 og

UTXE0 er slået til, men som sagt anvendes sidstnævnte ikke her.

Kommandoen P3SEL |= 0x30; sætter pin 4.5 og pin 3.5 på microcontrolleren til

at fungere som hhv. transmit og receive til seriel-USB interfacet der sidder

mellem PC og microcontroller.

Kommandoen P3DIR |= 0x10; sætter pin 3.4 til at være output.

9.4.7 Terminal

For at kunne kommunikere med robotten, er der blevet udarbejdet et terminal-

program. Denne terminal, der består af en Windows applikation med tilhørende

brugergrænseflade, gør brugeren i stand til at styre robotten, samt skifte fra

manuel- til autonom styring. Terminalen er bevidst holdt simpel, da dens formål

i dette projekt blot er at fungere som en styreenhed til robotten, ved opstart og

eventuelle fejl i dens autonome kørsel.

Terminalen er opbygget således at den, efter et input fra brugeren, sender et

signal til robotten via en seriel forbindelse. Dette gøres meget simpelt ved først

at åbne for den serielle port, for dernæst at kunne skrive til den, og til sidst

lukkes der igen for den serielle port, da det ellers ikke vil være muligt for


57

terminalen senere hen at kommunikere med robotten. På figur 42 herunder ses

funktionen for fremad knappen på terminalen:

Figur 42: programkoden for fremad-knappen

Som det også kan ses ud fra koden bliver den serielle port åbnet, hvorefter der

skrives et ’F’ for derefter at lukke denne serielle port igen. Microcontrolleren vil

så, alt efter hvilket bogstav den modtager fra terminalen, reagere derpå.

Samtlige funktioner i terminalen er opbygget ligeledes, blot med et andet

bogstav.

Terminalens brugergrænseflade kan ses herunder:

Figur 43 Terminalens brugergrænseflade


58

10 Test af robot

I følgende afsnit genemgås tre tests. Disse er foretaget på afstandssensorerne,

LEGO motorerne og til sidst hele systemet. Forsøgene er foretaget for at have

egne testdata, før implementering af afstandssensorer og motorer. For at have

dokumentation for robottens funktioner, er der desuden lavet videooptagelser

af robotten.

10.1 Test af afstandssensor

For at kunne programmere microcontrolleren til at reagere på

afstandssensorernes signaler er det nødvendigt at undersøge hvorvidt de

outputs der er opgivet i databladet stemmer overens med de afstandssensorer

der anvendes.

10.1.1 Specificering af test

For at teste de Sharp GP2D12 afstandssensorer der benyttes til robotten, laves

der en undersøgelse af afstandssensorernes output. Testen er en

sammenligning mellem det output som er specificeret i databladet og det

faktiske output fra sensorerne. Dette gøres for senere at kunne tage højde for

de eventuelle fejlmarginer, når afstandssensoren skal anvendes sammen med

microcontrolleren. Denne test vil blive udøvet på begge de afstandssensorer

der bruges til robotten.

Testen vil blive udført ved en hvid væg som refleksionsobjekt.

10.1.2 Test og konklusion

Som sagt i specificeringen er det blevet testet om hvorvidt de to

afstandssensorer faktisk har samme faktiske output som det der er anført i

databladet. Herunder på Figur 44 ses en graf over databladets teoretiske ouput

samt de to afstandssensorers testede output:


59

Figur 44: Diagram over afstandssensor output – 1. aksen viser længde i cm, 2. aksen viser volt.

Ud fra denne test kan det ses, at afstandssensorernes output stort set er

identisk med outputtene der er opgivet i databladet. Derfor kan databladets

tabel benyttes til eventuelle beregninger omkring afstandssensorerne.

10.2 Test af motorer

For at kunne implementere motorerne så de kan anvendes på robotten, har det

været nødvendigt at foretage tests af disse. Da de eneste data der kunne findes

til LEGO motoren ikke var fra fabrikanten selv, har det været nødvendigt selv at

måle på motorerne.

10.2.1 Specificering af motortest

For at teste de to LEGO motorer af typen 71427 der benyttes til robotten, er der

fundet en kilde [16] hvor der er foretaget målinger på denne type motor, og

disse vil blive anvendt til sammenligning af tests på de anvendte motorer til

robotten. Dette gøres for at der senere kan tages højde for de eventuelle

fejlmarginer, når motorerne skal anvendes sammen med microcontrolleren.

Denne test vil blive lavet på begge motorer der bruges til robotten.

0

0,5

1

1,5

2

2,5

3

0 20 40 60 80 100 120

Front sensor

Side sensor

Teoretisk sensor


60

10.2.2 Test

For at teste motorerne blev følgende testopstilling som vist på Figur 44 lavet:

Figur 45: viser testopstillingen af motorerne tilsluttet til encoderne. [14][17]

Motorerne var tilsluttet med henholdsvis 5V, 7V, 9V og 12V og encoderen var

tilsluttet MSP’en og talte de interrupts der var på et minut. Interruptsne

divideredes med 18 (huller i hjulet) og heraf fås hvor mange omdrejninger

motoren drejer pr. minut (rpm). Følgende tabel er heraf fremkommet:

Spænding (V) Højre interrupt Højre RPM Venstre

interrupt

Venstre RPM

5 3 479 193 3 474 193

7 4 841 269 4 942 275

9 6 269 348 6 372 354

12 8 403 467 8 622 479 Tabel 7: Viser testen på motorerne og dens resultater

Tabellen viser forsøgsresultaterne for begge motor, Højre interrupt, er antal

interrupt den højre motor giver på et minut, for at finde rpm divideres dette tal

med 18. Det samme er gjort for venstre motor. Testen er lavet uden belastning

på motorerne, og der antages at motorerne vil rotere i samme hastighed under

belastning.


61

10.2.3 Delkonklusion

I specifikationen blev det testet hvorvidt de to motorer har samme faktiske

rpm, som den anvendte kildes motor. Kildens rpm/v karakteristik er aflæst af

grafen på kildens hjemmeside [16]. På Figur 46 ses en graf der viser LEGO

motorernes rpm/V:

Figur 46: Lineære karakteristikker for henholdsvis højre motor, venstre motor og kildens motor,

spændingen er hen ad x-aksen og rpm er op ad y-aksen.

Ud fra denne test kan det ses at motorkarakteristikkerne ligger meget tæt op ad

hinanden, og det kan derfor konkluderes at motorernes ydeevne er stort set

identisk.

10.3 Test af system

Systemet er testet på en række forskellige måder, for at se om systemet

reagerer som det skal. Disse tests er test af rotation af robotten, test af terminal

og den manuelle styring og til sidst en test af den autonome kørsel.

0

2

4

6

8

10

12

14

0 100 200 300 400 500 600

Højre motor

Venstre motor

Kildens


62

10.3.1 Specificering og konklusion

Følgende afsnit er beskrivelser af tests foretaget på robotten, med henblik på at

undersøge hvordan den manøvrere. Første test omhandler 90o drejning, anden

test omhandler manuel styring og tredje test omhandler autonom kørsel.

Specificering af test 1

Det er blevet testet om robotten kan dreje 90o, både til højre og til venstre.

Testen udføres 10 gange, for at undersøge om der er nogle afvigelser. Robotten

skal sættes på gulvet og der tegnes en kridtstreg der flugter med robottens hjul.

Derefter skal robotten sættes til at dreje 90o

til højre. Efter robotten har drejet,

tegnes en lige kridtstreg der skal flugte med hjulet. Denne test udføres 10

gange. Hernæst skal robotten efter samme princip sættes til at dreje 90o

til

venstre. Denne test udføres også 10 gange. Nedenunder ses testopstillingen af

testen:

Figur 47: Testopstillingen af Test 1


63

Konklusion på test 1.

Robotten drejede ikke nøjagtig 90o. Det var lidt tilfældigt om den drejede

nøjagtig 90o eller om der var en afvigelse på et par grader. Tabel 8 viser

testresultaterne.

Forsøgs nr. Drejning til højre målt i grader Drejning til venstre målt i grader

1 91 o

89 o

2 90 o

83 o

3 94 o

91 o

4 92 o

93 o

5 91 o

88 o

6 91 o

92 o

7 98 o

88 o

8 92 o

87 o

9 89 o

86 o

10 90 o

86 o

Tabel 8: viser antal grader robotten drejede ved de 10 test der blev lavet, hvor robotten er sat til

henholdsvis at dreje til højre og til venstre.

Grunden til at robotten ikke nøjagtig drejede 90o kan skyldes flere ting. For det

første er der kun 18 huller i hjulet og encoderne er sat til at skulle dreje indtil

den får 32 interrupts, for at dreje 90o. Dette er ikke det helt nøjagtige tal for at

dreje 90o, i stedet er det nøjagtige tal 31,429 interrupts. Denne afvigelse vil i alt

blive:

Hjulets rotering ved 32 interrupts - hjulets rotering ved 31,429 interrupts

35,2 cm - 34,6 cm = 0,6 cm

For at omregne dette til grader, vides der at en grad ved de 31,429 interrupts er

lig:

384,090

558,34=

o

cm


64

Og da afvigelsen i cm var lig 0,6 cm, kan afvigelsen i grader findes ved:

o

o

cm56,1

384,0

6,0=

Så ved hver gang robotten drejer 90o, vil den i stedet dreje 91,56

o.

For det andet kan afvigelsen skyldes at når robotten drejer, accelerer det

roterende hjul for hurtigt. Hjulet spinder altså rundt hvorved der bliver talt en

masse interrupts, og derved fås en tilfældig unøjagtighed. Denne tilfældige

unøjagtighed kan igen opstå når robotten skal bremse, da hjulet kan skride ved

bremsning.

Den tredje grund til afvigelsen kan være en fejl i konstruktionen af robotten.

Venstre hjul er sat til at bremset når robotten drejer til venstre, men hjulet

drejer rundt af uforklarlige årsager, hvilket også er med til at tilføje

unøjagtigheder i målingen. Der er forsøgt at skifte motorerne, skifte

motorinputtene fra H-broen, bytte rundt på ledningerne på motorerne, justere

PWM signalet op og ned på motorerne. Intet af disse forsøg har afhjulpet

problemet. Det eneste der har hjulpet er at programkoden er skrevet sådan der

skal være en interruptforskel på 32 interrupts, dette er med til at afhjælpe på

problemet.

På den vedlagte CD er en videofilm af testen.

Specificering af test 2.

Den manuelle styring skal testes ved at sende de forskellige

styringskommandoer til robotten. Inden testen foretages, skal der laves en

rækkefølge, som robotten skal styres efter. Rækkefølgen er som følger:

Robotten skal først dreje til venstre, så til højre, så ligeud og til sidst bagud.


Den manuelle styring via terminalen fungerede godt, og robotten gjorde

præcist hvad den blev bedt om. Robotten reagerede hurtigt og præcist ved

navigationen. Den eneste ulempe der var ved navigationen, var at når den

udførte autonom kørsel, og i gang med at rotere, var der et sekunds forsinkelse,

før den ville gå over til manuel styring. Det er fordi robotten kører i et loop. En

demonstration af manuel styring er desuden at finde på den vedlagte CD.


65

Specificering af test 3.

Den autonome kørsel skal testes på en 2,44 X 2,24m bane. Her skal det testes

om robotten kører, som den er blevet programmeret til. Robotten skal først

stilles vinkelret på den forudgående mur inde i midten af banen, således at

ingen af sensorerne registrerer noget ved start. Her bliver robotten sat til

autonom kørsel, hvor den skal følge muren til venstre. Dernæst skal robotten

testes ved at rykke den til højre i banen, således at den højre sensor registrerer

en mur. Herved skal robotten dreje til venstre, når den møder den forudgående

mur og derefter følge muren.


Robottens autonome kørsel fungerede. Når robottens frontsensor registrerede

en mur, drejede robotten altid til højre, som den skulle. Når både frontsensoren

og sidesensoren registrerede en mur på samme tid, drejede robotten til

venstre, hvilket den også var konstrueret til. Den eneste unøjagtighed ved

denne test, er som før nævnt når robotten skal dreje 90o

. Det kan også ses på

videoen at den ikke drejer nøjagtig 90o. Der forefindes en video på CD’en hvor

begge autonome kørsler kan ses.


66

11 Konklusion

Ud fra problemformuleringen: Hvordan opbygges og implementeres en robot

til autonom husovervågning? er det blevet forsøgt at opbygge en robot der kan

manøvrere i et normalt indendørsmiljø.

I dette afsnit konkluderes rapporten og projektet ud fra kravspecifikationen.

Det vil her blive opsummeret, hvor vidt målene for kravspecifikationen for

produktet, dvs. robotten, er nået i løbet af projektperioden. Derudover

sammenfattes det foretagende tests der er udført på og i forbindelse med

produktet.

Hardware

Kravene for hardwaredelen var at få robotten til køre frem og tilbage samt dreje

til højre og til venstre. Derudover skulle robotten vha. afstandssensorer kunne

manøvrere uden om forhindringer. Endeligt skulle robotten kunne kortlægge en

tilbagelagt distance. Alle tre ting skulle anvendes sammen med brug af en

microcontroller.

For at opfylde de basale krav om at få robotten til fysisk at køre frem, tilbage, til

højre og til venstre er der anvendt en kontrolkreds til motorstyring der kan

udføre disse fire handlinger. En individuel afprøvning af motorerne sammen

med kontrolkredsen blev udført med tilfredsstillende resultater. Herefter blev

motorerne og kontrolkredsen monteret på robotten, som da kunne drives vha.

de to elementer. Dette krav ses derfor som opfyldt med succes.

Der var opstillet et krav om automatisk navigation af robotten. Dette blev bl.a.

lavet med SHARP afstandssensorerne. I første forsøg anvendtes én sensor

monteret skråt foran på robotten, og endeligt to sensorer der blev påsat som

beskrevet i implementeringsdelen af denne rapport. I samspil med

microcontrolleren er det muligt for robotten at undvige vægge indenfor 40 cm.

Dette krav anses derfor også som opfyldt med succes.


67

Software

Vores tredje krav om optegning af tilbagelagt distance er ikke opfyldt. Det er

ikke lykkedes at lave software til kortlægning, da kendskabet til

programmeringssproget C# ikke eksisterede. Det var hensigten at lave et

program der kunne visualisere, dvs. optegne, en tilbagelagt rute, men dette er

som sagt ikke lykkedes.

Kravene for den embeddede software på microcontrolleren var, at det skulle

kunne modtage signaler fra sensorer monteret på robotten, og vha. dem styre

robotten udenom forhindringer.

For at imødekomme kravet om robottens undvigelse af forhindringer er der

skrevet en række C-programmer. Disse er lagt over i microcontrolleren fra en

PC, og er desuden at finde på den vedlagte CD-ROM. Softwaren fungerer i

samspil med sensorer og kontrolkreds til at styre robotten.

Udover den embeddede software på microcontrolleren, er der lavet et

terminalprogram der kan bruges til at styre robotten manuelt. Dette program

virker, og derfor ses dette softwaremæssige mål også som nået.

Konklusion

Med denne rapport er projektgruppens arbejde med opbygning af en robot

styret af en microcontroller blevet fremvist. Undtaget visualisering af ruten ses

kravspecifikationen som opfyldt. Undervejs er de enkelte dele af robotten

blevet testet, for at sikre at de fungerede som helhed når de blev sat sammen.


68

12 Litteraturliste

[1]:

http://www.control.aau.dk/~bisgaard/teaching/d3/sai/sai-litterature/users-

guide.pdf

[2]:

http://www.control.aau.dk/~bisgaard/teaching/d3/sai/sai-

litterature/datablad.pdf

[3]:

http://www.km.kongsberg.com/KS/WEB/NOKBG0240.nsf/AllWeb/B3F87A63D8

E419E5C1256A68004E946C?OpenDocument

[4]:

http://en.wikipedia.org/wiki/MQ-1_Predator

[5]:

http://www.grydeske.dk/rapport.pdf

[6]:

http://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Von_Neumann

_architecture.svg/200px-Von_Neumann_architecture.svg.png

[7]:

http://eleceng.dit.ie/frank/msp430/microcontrollers.pdf

[8]:

http://eleceng.dit.ie/frank/msp430/msp430.pdf

[9]:

http://www.control.aau.dk/~bisgaard/teaching/d3/sai/mm7/mm7.pdf

[10]:

http://www.control.aau.dk/~ms/teaching/d3/sai/mm12/mm12.pdf


69

[11]:

James K. Peckol: Emdedded Systems, A Contemporary Design Tool

ISBN 978-0-471-72180-2

[12]:

http://www.samson.de/pdf_en/l153en.pdf

[13]:

Roger L. Tokheim: Digital Principles 3. Udgave

ISBN 0-07-065050-0

[14]:

http://www.suc-tech.com/techonolgy/e11.gif

[15]:

http://www.alldatasheet.com/datasheet-pdf/pdf/84019/SHARP/GP2D12.html

[16]:

http://www.philohome.com/motors/motorcomp.htm

[17]:

http://www.mapageweb.umontreal.ca/cousined/lego/3-

Physics/Motors/images/imageDK2.JPG

[18]:

Torben Wridt: Digital Teknik, 2002


70

13 Appendiks

13.1 Schmitt Trigger

Schmitt Triggeren anvendes i projektet til at sortere et støjfyldt signal til et

pænt og skarpt signal. Den fungerer ved at skifte mellem enten VHigh og VLow,

hvilket i digitalteknik betyder at skifte mellem 0 og 1.

Figur 48: Viser hvordan et støjfyldt signal kommer ind i Schmitt Triggeren og kommer ud som et pænt

signal [18,474]

MSP’ens I/O ben har indbygget Schmitt Trigger, men disse bruges ikke, da vi

først skal have signalet buffet ned til 3.3 V, før signalet kan føres ind i MSPen og

disse buffere forstærker bare signalet og giver en masse høje og lave signaler. I

stedet anvendes Schmitt Triggeren af typen MC74HCT14A i kredsløbet.

1 titelblad synopsis - aslak...

Documents