Titel: Automatisk katapult. Synopsis: Tema: Mikroprocessorsystemer. Projektperiode: P3, efterrårssemesteret Projektgruppe: 350

Transkript

1

2

3 Det Ingeniør-, Natur- og Sundhedsvidenskabelige Fakultet Institut for Elektroniske Systemer Frederik Bajers Vej 7 Telefon: Titel: Automatisk katapult Tema: Mikroprocessorsystemer Projektperiode: P3, efterrårssemesteret 2009 Projektgruppe: 350 Deltagere: Martin Sloth Dam Hans-Jacob Sørensen Enemark Daniel Grønkjær Jensen Lars Møller Mikkelsen Vejleder: Morten Bisgaard Oplagstal: 6 Sidetal: 199 Bilagsantal og art: 16 appendiks samt CD Synopsis: Som svar på projektoplægget Automatisk Katapult er der i dette projekt udviklet en computerstyret pan-tilt enhed opbygget i LEGO R, kaldet Automated Lego Cannon. Selve kanonen og affyringsenheden er specialkonstrueret i teflon. Computerstyringen er opbygget omkring en M- SP430F149 microcontroller, hvortil der er udviklet hardware drivere til affyringsmekanismen, RS-232 og DC motorer, opbygget på hvert sit veroboard. Der er desuden udviklet en strømforsyningsenhed til de opbyggede moduler. Dette system med pantilt enhed og computerstyring, er fjernstyret via RS- 232 protokollen fra en pc. Softwaren på microcontrolleren er skrevet i C og den grafiske brugerflade på pc en med underliggende software er udviklet i C++. Et webkamera er benyttet til at markere et ønsket mål, og bruges til automatisk styring af robotten. Ved hjælp af en afstandssensor kan systemet selv måle afstanden til målet og indstille løbets vinkel, så det kan ramme målet. Systemet har både manuel og automatisk kontrol. Automated Lego Cannon fungerer efter kravspecifikationen, dog med præcisions problemer pga. konstruktionsmaterialet og sensorunøjagtighed. Afsluttet den 17/ Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.

4

5 The Faculties of Engineering, Science and Medicine Department of Electronic Systems Frederik Bajers Vej 7 Phone: Title: Autonomous Catapult Theme: Programming embedded systems Project period: P3, fall semester 2009 Project group: 350 Group members: Martin Sloth Dam Hans-Jacob Sørensen Enemark Daniel Grønkjær Jensen Lars Møller Mikkelsen Supervisor: Morten Bisgaard Number of copies: 6 Number of pages: 199 Appended documents: 16 appendix and CD- ROM Finished 17/ Synopsis: To answer the project proposal Automatic catapult there has in this project been developed a computer controlled pan-tilt unit built in LEGO R, called Automated Lego Cannon. The barrel and trigger-unit is custom made from teflon, and the computercontrol is made to interface with a M- SP430F149 microcontroller. There has been constructed hardware drivers for the trigger mechanism, RS-232 and DC motors, built on each veroboard. A custom power supply unit has been made to supply power to these modules. This system with pan-tilt unit and computercontrol, is remote controlled via the RS-232 protocol from a PC. The embedded software is written in C and the graphical user interface for the PC, with underlying software, is developed in C++. A web-cam is used to mark the wanted target, and is used to automatic control of the robot. By means of a range sensor the system is able to measure the distance to the target and set the vertical angle of the barrel, to make it hit the target. The system is both automatic and manual controlled. Automated Lego Cannon works according to the requirements though precision problems has been encountered because of construction materials and inaccuracies of the range sensor. This report must not be published or reproduced without permission from the project group.

6

7 Forord Rapporten er opdelt ved x.y.z, hvor x angiver kapitelnummer, y angiver sektion og z angiver undersektion. Ved referencer til figure og tabeller, angives x.y, hvor x angiver kapitlet, og y figurnummer i det givne kapitel. Litteratur referencer er vist med [x], hvor x henviser til et reference i litteraturlisten. Hvis ét helt afsnit er baseret på én kilde, er denne kilde angivet først i afsnittet. Referencer vil ellers være placeret umiddelbart efter det referedede. På den vedlagte CD findes bl.a. kildekode, dokumentation og testskema. Når der henvises til CDen, benyttes følgende syntaks: mappe/fil eller [CD mappe/fil] der angiver placering ift. roden af CDen. Til rapporten hører der en række appendiks. Dette er materiale udarbejdet i forbindelse med rapporten, men anses for at være supplerende materialer til rapporten. Martin Sloth Dam Hans-Jacob Sørensen Enemark Daniel Grønkjær Jensen Lars Møller Mikkelsen

8

9 Indholdsfortegnelse 1 Indledning Initierende Problem Projektets omfang Foranalyse Funktioner: Brugerinteraktion Scenarie Ballistisk bane Målet Baggrundsviden MSP430 microcontroller Seriel forbindelse Motorer Kravspecifikation Indledning Generel Beskrivelse Specifikke krav Præcision af kanonen Eksterne Grænsefladekrav Systemets Ydelse Kvalitetsfaktorer Accepttestspecifikation Platform Krav og Designovervejelser Illustrationer Mål på platformen Gear Kanonløbet Test Korrektion af krav Systemdesign 58 1

10 INDHOLDSFORTEGNELSE 6.1 Hardware - Robot Hardware - Kontrolstation Software Interface mellem moduler Parallel afvikling Hardware Design Motordriver Motor feedback Initialisering af motorer Afstandssensor Serieldriver Trigger Power Supply Unit Hardware konklusion Hardware Implementering Modul implementering Motordriver Power Supply Unit Serielmodul Trigger Modul integration - Støj filtrering Hardware overblik Hardware Test Test af motordriver Test af Power Supply Unit Test af serielmodul Test af triggerdriver Software Design Bestemmelser fra hardware Motorregulering CR - Cannon rotation CA - Cannon angle CP - Communication protocol VTM - Visual target marking GUI - Graphical user interface Modul detection Software Implementering Generel opbygning af software på microcontroller Motorregulering CR - Cannon rotation CA - Cannon angle VTM - Visual Target Marking GUI - Graphical User Interface Perifiel opsætning Klasse/funktionsliste

11 INDHOLDSFORTEGNELSE 12 Software Test Test af motorregulering Test af intervalrotation Test af hardwarens påvirkning på software Test af Visual Target Marking (VTM) Test af afstandssensor Accepttest Resultater fra Accepttest Konklusion Perspektivering A Hardwarekomponent: NXT motor 154 B Hardwarekomponent: Afstandssensor 157 C Motor encoder 159 D Hardware modul interfaces 163 E 25 leder kabel - Main Cable 167 F Portforbindelser på MSP G CP statuskoder 171 H Test af platform 172 I Test af motordriver 176 J Test af PSU 182 K Test af serielmodul 184 L Test af trigger 186 M Test af afstandssensorer 188 N Test af kanon 191 O Test af VTM 192 P Accepttest 194 3

12 Kapitel 1 Indledning Denne rapport er resultatet af et projekt udarbejdet af en gruppe på Internetteknologier & Computersystemer 3. semester, hvor temaet ifølge studieordningen er Microprocessorsystemer. Formål: De studerende skal opnå forståelse for konstruktion af mindre computersystemer baseret på grundlæggende digitale komponenter, samt metoder til udvikling af dertil hørende system- og applikationsprogrammel[1]. Projektforslaget[2] tager udgangspunkt i en MSP430F149 microcontroller. Der vil derfor blive udviklet et system med denne controller i centrum, samt tilhørende software og hardware. Dette projekt er udarbejdet på baggrund af et projektforslag omhandlende en automatisk kanon. Denne kanon skal automatisk kunne tilpasse sin affyringskraft og -retning og ramme et mål, som bliver udpeget ved hjælp af et kamera fra en klient PC. 1.1 Initierende Problem Projektet tager udgangspunkt i projektforslaget Automatisk katapult. Forslaget beskriver en automatisk kanon/katapult, hvor ideen er, at en pan-tilt enhed skal kunne styres fra en PC ud fra visuelt input fra et webcam. Ideen er så, at man fra PC en skal kunne klikke på det objekt, som skal rammes af kanonen/katapulten, hvorefter systemet automatisk rammer dette objekt vha. forskellige sensorer og matematiske algoritmer. Denne opbygning ligger desuden op til, at der kan udvikles et system, som kan ramme et bevægende mål. Robotten 1 henvender sig til militæret, hvor hurtige og præcise våben er kritiske. Da militær våben har dødbringende kraft, er det vigtig der ikke sker menneskelige fejl. Et våbensystem skal derfor fungere automatisk, med kun udvælgelse af mål foretaget af menneskelig styring. En automatisk kanon/katapult, skal altså fungere fuldautomatisk, når først et målobjekt er specificeret. Dette bringer os til det initierende problem: Hvordan designes og implementeres et automatisk kanon/katapult system, der kan ramme et specificeret mål identificeret via et webcam? 1 Definition: Hele den fysiske enhed: Platform, microcontroller og software 4

13 KAPITEL 1. INDLEDNING 1.2 Projektets omfang [2]I dette projekt skal der arbejdes med: Opbygge en pan-tilt enhed f.eks. med RC servoer eller LEGO motorer Opbygge en katapult platform MSP430F149 microcontrolleren benyttes som hardware platform. Der skal laves hardware og software interface til sensorer og aktuatorer (Sensorer kunne f.eks.. være Sharp IR eller en ultralyds afstandsmåler.) Der skal laves software/matematik til at beregne skydevinkler og styre katapulten Der skal laves et kommunikationsinterface til den PC, der skal styre katapulten. Der skal laves manuel målsøgning på PC med input fra webcam. Figur 1.1: Skitse af det initierende problem På figur 1.1 er systemets dele skitseret. 5

14 Kapitel 2 Foranalyse I dette kapitel vil det initierende problem blive analyseret. Herunder vil anvendelses scenarier bliver gennemgået for at identificere nødvendige funktioner i systemet. 2.1 Funktioner: Følgende funktioner implementeres i systemet: Afstandssensor til automatisk målsøgning. Automatisk rotation om lodret akse af platform ved manuel 1 målsøgning. Kanonens tilt. Indstilling af kanonens vinkel i forhold til vandret. Variabel affyringskraft. Webcam til visuel målsøgning. Manuel rotation om lodret akse, til brug hvis det ønskede mål ikke er i webcamets synsfelt. 2.2 Brugerinteraktion Figur 2.1 er et use case diagram af, hvordan brugeren interagerer med systemet via kontrolstationen, som interagerer videre med MSP en. 1 Det ønskede mål findes manuelt på klient-pc ens skærm 6

15 KAPITEL 2. FORANALYSE Figur 2.1: Use case: Brugerinteraktion Usecase Vælge mål Se log Vælg operationsmode Handling Bruger - Vælger mål på billede fra webcam via museklik System - Undersøger om det markerede objekt kan isoleres fra billedet - Hvis det kan isoleres - - Markér objektet med en rød firkant - - Beregn relativ vinkel til objekt og roterer tårnet - - Hent afstand til objektet - - Hvis objektet er inden for rækkevidde Kald funktion til at indstille løbet - - Ellers informer bruger om at objektet er out of range - Ellers fortæl bruger at objektet ikke kunne isoleres Bruger - Ser på log området i GUI System - Opdaterer løbende logbeskeder fra systemet Bruger - Vælger operationsmode: Adjust Only/Adjust & Shoot/Manual Control System - Gemmer operationsmode - Hvis mål er valgt og operationsmode!= Manual Control - - Indstiller tårn og løb til at ramme målet - - Hvis operationsmode = Adjust & Shoot Send affyringskommando - Ellers hvis operationsmode = Manual Control - - Vis sigtekorn, Aktuel afstand til målpunkt 7

16 KAPITEL 2. FORANALYSE Styr motorer manuelt Manuel affyring Overfør billededata Overfør data Bruger - Trykker på piltaster System - Hvis systemet er ved at autoindstille, afbryd det - Hvis piletast = venstre eller højre - - Roterer tårnet mod venstre/højre - Ellers hvis piletast = op eller ned - - Bevæg løbet op/ned Bruger - Trykker på enter System - Hvis systemet er ved at autoindstille, afbryd det - Send affyringskommando Webcam - Overfører ét billede System - Gemmer billedet midlertidig og viser i GUI MSP430F149 - Sender data eller modtager data System - Hvis MSP430F149 vil sende data til systemet - - Genkend data og reager herpå. Mulig data: Statusbesked, afstandssensor, motorhastighed - Hvis systemet vil sende data til MSP430F Pak data og send. Mulig data: Motorkontrol, affyring, afstandssensor Tabel 2.1: Use case beskrivelse (Kontrolstation) Figur 2.2 er et use case diagram af, hvordan der bliver interageret med MSP en. Controlleren får input fra kontrolstationen, som den bearbejder og handler ud fra. Figur 2.2: Use case: MSP430F149 8

17 KAPITEL 2. FORANALYSE Usecase Overfør data Drej X grader Modtag afstand Skyd Handling Kontrolstation - Sender data eller modtager data System - Hvis MSP430F149 vil sende data til kontrolstationen - - Pak data og send. Muligt data: Statusbesked, afstandssensor, motorhastighed - Hvis kontrolstation vil sende data til MSP430F Genkend data og reager herpå. Mulig data: Motorkontrol, affyring, afstandssensor System - Generer signal for motorkontrol indtil - - Feedback fra motor er nået til X grader Motor - Roter ved hjælp af motorkontrol signalet Afstandssensor - Sender signal om afstand System - Konverter signal - Hvis det skal sendes til kontrolstation - - Send til kontrolstation System - Generer signal for affyring Aftrækker - Reagerer og affyrer projektil Tabel 2.2: Use case beskrivelse (MSP430) 2.3 Scenarie Opstillingen for scenarierne er, at der er en kontrolstation, hvorpå der er et brugerinterface. Brugerinterfacet giver mulighed for manuelt at bevæge hele platformen. Det giver brugeren mulighed for at identificere sit mål via webcamet. Kontrolstationen er forbundet til robotten, som efter at brugeren har identificeret sit mål, vil udfører ordren. Der vil i denne rapport blive arbejdet med en prototype, da der ikke er mulighed for at udvikle et fullscale-system. Nedenstående er nogle forskellige scenarieforløb, som har til formål, at give et foreløbigt overblik over systemet. Generelle forudsætninger for at systemet vil fungerer: Bruger-interfacet installeret/kørende på kontrolstation. Forbindelse mellem kontrolstation og robot. Scenarie 1 Brugeren vælger et mål på kontrolstation: 1. Bruger vælger mål på GUI vha. mus og klik på skærmbillede. 2. Målet centreres automatisk på skærmbilledet (Platformen drejer). 9

18 KAPITEL 2. FORANALYSE 3. Målet bliver valideret af robotten. 4. Kanon- vinkel/højde justeres vha. algoritme og kanonen affyres. 5. Robot sender input om veludført affyring til kontrolstation. Scenarie 2 Brugeren vælger et mål på kontrolstation, men målet er ude for rækkevidde: 1. Bruger vælger mål på GUI vha. mus og klik på skærmbillede. 2. Målet centreres automatisk på skærmbilledet (Platformen drejer). 3. Målet bliver valideret af robotten. 4. Robotten sender fejlmelding til kontrolstation om at målet er ude for kanonens rækkevidde. 2.4 Ballistisk bane Et projektil affyret fra en kanon vil følge en kasteparabel, også kaldet det skrå kast. Det er derfor nødvendig, at finde en række formler, der beskriver projektilets bane efter det er affyret fra kanonen. Det antages, at det affyrede projektil er en ensformig kugle. Vindmodstanden medregnes ikke da den regnes for at være ubetydelig i denne sammenhæng. Vindmodstanden kan beskrives ved følgende formel: F d = 1 2 ρ v2 A D (2.1) Hvor F d er den modsatrettede kraft (vindmodstanden), ρ er densiteten af luften, v er hastigheden, A er tværsnitarealet af legemet i forhold til retningen og D er en koefficient, som afhænger af legemets form og materiale[3]. Da der vil blive arbejdet med en prototype i dette projekt, vil alle scenarier foregå indendørs og ved lave hastigheder. Hastigheden (v) er i formel 2.1 den mest betydende koefficient, da den er i anden potens, og som nævnt før, vil der blive arbejdet ved lave hastigheder og derfor vil man kunne se bort fra vindmodstanden i denne sammenhæng, da denne vil være lille og/eller gående mod nul. Først findes den påvirkning tyngdekraften har på kuglen. I det følgende vil vektorer blive markeret således: a. Figur 2.3: Ballistisk bane for projekttil 10

19 KAPITEL 2. FORANALYSE Figur 2.3 viser de krafter, der påvirker projektilet og α er affyringsvinklen. F ty er tyngdekraften (F ty = m g), men da dette er en beskrivelse af bevægelsen og ikke kraften, medregnes massen m ikke videre. Vektor a er accelerationen af projektilet. [ 0 a(t) = g ] (2.2) Hvor g = Tyngdeacceleration [m/s 2 ] t = Tidsvariable [s] Det antages, at udgangshastigheden er konstant, så der derfor ikke skal regnes med nogen acceleration på udgangshastigheden. Accelerationen fra tyngdekraften kan integreres mht. t for at finde dens bidrag til hastigheden. [ 0 g ] dt = [ 0 g t ] Dette skal fratrækkes V 0 da de er modsatrettede. [ ] V0 cos(α) V 0 = V 0 sin(α) [ ] [ V (t) = V 0 0 = g t V 0 cos(α) V 0 sin(α) g t ] (2.3) Hvor V 0 = Begyndelses hastighed [m/s] α = Affyringsvinkel [Radianer]. Retningsvektoren kan bestemmes via den integrerede hastighedsvektor [ r(t) = V 0 cos(α) V 0 sin(α) g t ] [ dt = V 0 cos(α) t V 0 sin(α) t 1 2 g t2 ] (2.4) Der laves en enhedsanalyse for at validere formlens gyldighed. Y aksen undersøges i r(t) Det ses at retningsvektoren angives i meter, hvilket var ønsket. m s s m s 2 s2 = m (2.5) 11

20 KAPITEL 2. FORANALYSE Rækkeviden x max findes ved at sætte y (t max ) = 0 0 = V 0 sin(α) t 1/2 g t g t2 = V 0 sin(α) t g t 2 = 2 V 0 sin(α) t g t 2 = 2 V 0 sin(α) t t = 2 V 0 sin(α) g t max = 2 V 0 sin(α) g (2.6) Rækkevidden bliver derfor x max (t max ) = V 0 cos (α) 2 V 0 sin (α) g = 2 V 0 2 cos (α) sin (α) g = V 0 2 sin(2α) g (2.7) Det ses således, at rækkevidden afhænger af 2 variabler: Udgangshastigheden (V 0 ) og affyringsvinkel α Det antages at kanonen skal ramme målet direkte på, derfor skal vinklen være så lav som mulig. Derfor sættes V 0 til sit maksimum, og vinklen bestemmes. Udgangshastigheden kan derfor regnes som en konstant. Det er derved ikke nødvendigt at have variabel affyringskraft, da en variabel vinkel kan styre rækkevidden. x max = V 0 2 sin (2α) g x max g 2 = sin (2α) V ( 0 ) xmax g arcsin 2 = 2 α V ( 0 ) 1 2 arcsin xmax g = α (2.8) V 0 2 Formel 2.8 kan bruges til at beregne vinklen kanonen skal stå i, for at have en rækkevide på x max med en udgangshastighed på V 0. I figur 2.4 ses en simulering af formel 2.4. Det antages at kanonen kan affyre med 5 m/s. Banen er som forventet. 12

21 KAPITEL 2. FORANALYSE Figur 2.4: Simuleret kuglebane med 5 m/s og 45 grader udgangsvinkel. [CD Matlab/kuglebane.m] I figur 2.5 ses en graf over hvilken hældning løbet skal have, for at nå en vis afstand, med en konstant udgangshastighed. Der benyttes formel 2.7. Figur 2.5: Hældning ift. afstand vha. formel 2.7. [CD Matlab/vinkel afstand.m] 13

22 KAPITEL 2. FORANALYSE Det ses tydeligt, at maksimum rækkevidde fås ved 45 grader, og der findes 2 vinkler, hvor hver afstand kan nås. Der skal derfor tages højde for dette i designfasen. 2.5 Målet I dette afsnit vil der blive opstillet nogle definitioner til det mål som kanonen skal skyde efter. 1. Målet skal være en plade med dimensionerne 20x20cm. 2. Målet skal være placeret i samme højde som kanonen. 3. Målet skal være i en farve som skiller sig ud fra baggrunden. 4. Målet skal minimum være placeret 30cm fra afstandscensoren på kanonen. 5. Målet må maksimum være placeret 250cm fra afstandscensoren på kanonen (se figur 2.4). 6. Målet skal være placeret lodret på underlaget. På figur 2.6 ses en illustration af målet som specificeret. (a) Målet forfra Figur 2.6: Målet (b) Målet fra siden Dimensionerne af målet medfører, at afstandssensoren maksimum må placeres i en højde på 20cm, da den ellers ville pege over målet. Afstanden til målet og dets dimensioner, medfører desuden, at der kan opstilles krav til en maksimal vinkel som kanonen må pege forkert. På figur 2.7 ses en oversigt over afstande mellem afstandsmåler og målet. 14

23 KAPITEL 2. FORANALYSE Figur 2.7: Afstandssensor og målobjekt set fra oven V er vinklen, der tillades at kanonen må afvige i forhold til at pege direkte mod centrum af målet. En beregning af V kan ses i formel 2.9. V = arctan( 10cm 250cm ) π 180 V = 180 arctan( 1 25 ) π V = 2.29grader (2.9) Da 250cm er den maksimale afstand mellem målobjektet og afstandssensoren, er V = 2.29 grader den maksimale vinkel, der kan tillades som fejl. Ved beregning af V ved en mindre afstand end 250cm, ville V kun blive større. Dermed er en vinkel på 2.29 grader den største fejl der kan tillades. 15

24 Kapitel 3 Baggrundsviden I dette kapitel vil den nødvendige baggrundsviden for projektet blive gennemgået. Dette omfatter kort introduktion, samt beskrivelse af udvalgte perifere enheder på MSP430F149 microcontrolleren, RS-232 standarden og motorers virkemåde. 3.1 MSP430 microcontroller Da der skal arbejdes med en MSP430 microcontroller, vil denne kort blive gennemgået. Dette vil blive udarbejdet ud fra MSP430x1xx Family: User s Guide [4]. Det vil også vil være MSP430x1xx Family: User s Guide yderligere information om MSP430 kan findes. Det er kun de dele der er relevante for projektets udførsel, der vil blive gennemgået. Den præcise hardwaremæssige ombygning af f.eks. ALU, vil ikke blive gennemgået Generelt om MSP430 MSP430 består af en 16-bit RISC (Reduced Instruction Set Computer) processor, perifer enheder og en clock enhed. MSP430 er opbygget ud fra von-neumann princippet, hvilket vil sige, at den bruger sammen adresserum til instruktioner og data. Arkitekturen af MSP430 er illustreret i figur

25 KAPITEL 3. BAGGRUNDSVIDEN Figur 3.1: Arkitektur, MSP430F149 - Kilde: MSP430x1xx Family User s Guide - Figure 1 1. MSP430 Architecture Stack En stack bruges som et lager til data. Stack arbejder efter princippet Last In, First Out (LIFO), hvilket kan forklares ved, at man forestiller sig en stak tallerkener, som stables oven på hinanden, hvor den sidste tallerken der bliver lagt på stakken, bliver den første der tages af den igen. Når denne operation ønskes udført på en datastack, bruges kommandoerne PUSH og POP til henholdsvis at ligge på stacken og tage af stacken. Stacken er placeret i RAM delen af hukommelsen, som på MSP en er fra adresse 0x200 til 0x999, og der arbejdes altid nedad i hukommelsen Porte [5][4]I den givne microcontroller - MSP430F149 - er der flere tilgangsmuligheder. Disse består af seks 8-bit porte, der alle kan virke som digitale I/O med schmitt-trigger funktionalitet i indgangslogikken. Dette hjælper med til at definere inputniveauerne så de bliver tolket rigtigt, hvis der er støj på indgangssignalet. Hver indgang kan sættes op individuelt til, hvilken funktionalitet den skal have. De alternative funktioner vælges dermed individuelt med følgende muligheder: (se figur 3.2) Port 1 Her ligger hovedparten af timer A s funktioner, se afsnit 3.1.5, med 3 capture indgange og 2x3 compare udgange. Det er også muligt at tilføre timer A et eksternt clock signal eller tage SMCLK (submasterclock) signalet ud. Port 2 Resten af timer A funktionerne ligger på port 2. Der er mulighed for at sammenligne to indgange for at se hvornår de er ens, og sende et signal til timeren derfra. Det er også her, der kan tilsluttes en ekstern modstand (R osc ) hvis der benyttes RC-oscillator. Port 2 kan også levere den digitale forsyningsspænding ud (DV ss ) og clock en fra ADC en (ADC12CLK). Port 3 Denne port indeholder den ene af to kommunikationsporte til seriel kommunikation (USART0). Der er her mulighed for følgende 3 protokoller: USART (både synkront og asynkront, se afsnit 3.1.8), SPI og I 2 C. Disse er alle understøttet i hardware. P3.6 - P3.7 hører til den anden kommunikationsport (USART1). 17

26 KAPITEL 3. BAGGRUNDSVIDEN Port 4 Her ligger timer B s funktioner med capture indgang på P4.0 - P4.6. Sat i outputmode giver disse ben mulighed for at levere PWM-signal. P4.7 kan levere et eksternt clock signal til timer B. Port 5 P5.0 - P5.3 er resten af USART1. P5.4 - P5.6 kan levere de interne clock signaler ud. Et indgangssignal på P5.7 sætter PWM-udgangene til høj-impedans. Port 6 Alle indgange på denne port er til ADC input. ADC en kan sample 8 forskellige signaler her. Figur 3.2: I/O på MSP430F Interrupts Interrupt er et asynkront signal, som kan komme fra enten hardware eller software, der giver besked om, at der er en handling, som skal udføres med det samme. Kommer der flere interrupts på samme tid, bliver de udført efter deres priotering. Figur 3.3 illustrerer et interrupt. 18

27 KAPITEL 3. BAGGRUNDSVIDEN Figur 3.3: Interrupt Når et interrupt kommer bliver den nuværende adresse på eksekvering og eventuelle indstillinger gemt på stacken vha. Program Counter (PC) og Status Register (SR). Efter interrupt bliver disse genskabt, og MSP en vil fortsætte som før. MSP430F149 har 3 forskellige typer interrupts, som er følgende Non-maskable interrupts kan forekomme hvis der f.eks. sker en fejl i flashen, hvis man skriver uden for hukommelsesområdet eller en oscilliator fejl. Maskable interrupts er de interrupts der bruges af systemet ved normal drift. Disse kan sættes enten af softwaren i de respektive registre eller ved hardwaren sætter registrene. I dette projekt vil interrupt fra P1, P2, TimerA, TimerB, Watchdog, ADC og UARTx blive aktuelle at arbejde med. System reset er til at resette CPU en. Dette interrupt er monteret til ben 58, og aktiveres når denne går lav. Når dette interrupt kaldes, vil MSP en resette perifere enheder og starte eksekvering af koden fra et bestemt sted. Som nævnt tidligere, har hver interrupt en prioritering. Det betyder at hvis der kommer flere interrupts samtidig, vil det interrupt med højeste prioritet blive udført først. Køsystemet fungere ved at når der er et interrupt, sættes et bit i deres respektive registre. Disse fjernes efter udførsel af interruptet og først når alle interrupt flag er væk, fortsætter systemet med sin normale eksekvering. Prioriteringen af interrupts kan ses af tabel 3.1 Interrupt flag Type Prioritet Benyttende enheder WDTIFG, KEYV Reset 15 Opstart, reset og watchdog NMIIFG, OFIFG, ACCV- (Non)maskable 14 NMI, osciliator, access violation IFG TBCCRO0, CCIFG Maskable 13 TimerB TBCCR1-6, CCIFG1-6 TB- Maskable 12 TimerB IFG CAIFG Maskable 11 Comperator A WDTIFG Maskable 10 Watchdog timer URXIFG0 Maskable 9 USART0 receive UTXIFG0 Maskable 8 USART0 transmit ADC12 Maskable 7 ADC 12 TACCR0, CCIFG Maskable 6 TimerA TACCR1, CCIFG, TAC- Maskable 5 Timer A CR2, CCIFG2, TAIFG P1IFG.0-7 Maskable 4 I/O Port 1 19

28 KAPITEL 3. BAGGRUNDSVIDEN URXIFG1 Maskable 3 USART1 recieve UTXIFG1 Maskable 2 USART1 transmit P2IFG.0-7 Maskable 1 I/O Port 2 Tabel 3.1: Interrupts på MSP430F149 [CD Datablade/MSP430F149-datablad.pdf ] Timere MSP en har to 16-bit timere: Timer A og Timer B. Den har desuden en speciel counter kaldet Watchdog timeren. Timer A og Timer B består af et tælle register, en clock frekvens og et output/input ben. Timerne kan bruges til, at henholdsvis; Tælle events, hvor den tæller impulser. Tage tid, hvilket kan bruges til f.eks. stopur eller, at måle en frekvens. Periodisk timing, som f.eks. kan bruges til at genere PWM signaler. Timer A (og timer B) er 16-bit tællere, der med en kendt clock kan tælle op til en kendt værdi. Hvordan den fortsætter efter at være nået til den kendte værdi, kan forudbestemmes til 3 forskellige måder: Up-mode Tælleren tæller op til den forudbestemte værdi, hvorefter den resetter og starter forfra. Der sættes et interruptflag (TACCR0 CCIFG) når den tæller til den forudbestemte værdi og et andet interruptflag (TAIFG), når den tæller til nul og starter forfra. Continuous-mode Tælleren tæller op til max-værdien (0xFFFFh), hvorefter den starter forfra. Hver gang den starter forfra sættes TAIFG interruptflaget. Up/Down-mode Tælleren tæller op til en forudbestemt værdi, hvorefter den tæller nedad til nul. Efter nul er nået starter den forfra med at tælle op. Et interruptflag (TACCR0 CCIFG) sættes, når den skifter fra at tælle op til at tælle ned. Et andet interruptflag (TAIFG) sættes når den skifter fra at tælle ned til at tælle op. Output enheden Hver capture/compare enhed har en output enhed, der har forskellige måder hvorpå den kan reagere på tælleren. Ud over OUT-mode, hvor udgangen ændres af software, sammenligner alle mode s timerværdien med to registre (TACCRx, TACCR0) og handler derefter. En indstilling - Toggle/Reset - skifter tilstanden på udgangen, når timer-tælleren når TACCRx og reset er udgangen, når timer-tælleren når TACCR0. En anden indstilling - Reset/Set - reset er udgangen, når timer-tælleren når TACCRx og set er udgangen når timer-tælleren når TACCR0. Disse indstillinger kan, i en uafhængig kombination med de før beskrevne tællerindstillinger, blandt andet bruges til at generere PWM-signaler på udgangen, se afsnit Watchdog timer Watchdog timeren er lidt speciel, da den egner sig bedre til interval interrupts. Timer A og timer B har clockdividere med 1, 2, 4 og 8, hvor watchdog timeren har 32768, 8192, 512 og 64. Denne har dog ikke et tælleregistrer, men interrupter istedet hver gang den bliver trigget. Intervallet kan sættes op mellem 1 Hz og 11kHz. Watchdogs hovedfunktion er dog, som navnet antyder, at agere vagthund. Den har mulighed for at resette systemet, hvis det ikke er blevet sparket inden for det sidste stykke tid. Dette kaldes kicking the dog. Denne timer kan altså også bruges som sikkerhed i et embedded system, og genstarte systemet i tilfælde af crash. 20

29 KAPITEL 3. BAGGRUNDSVIDEN Pulse Width Modulation - PWM En måde at udnytte timerne på, er til at generere PWM-signaler, der eksempelvis kan bruges til at bestemme hastigheden på en DC-motor eller lysstyrken i en lysdiode. PWM-signalet er et firkantsignal med fast frekvens, hvor den tid den er høj varieres. Dette kaldes for dutycycle. Dutycyclen angives i procent af hele perioden, og et signal med en dutycycle på 50% vil således være høj i halvdelen af periodetiden. Figur 3.4: PWM-signal med de referencesignaler, der ligger til grund for PWM-signalet. Kilde: Som det ses på figur 3.4, kan et PWM-signal genereres ved at sammenligne et savtak-signal (blå) med et variabelt signal (grøn) i en komperator. Udgangssignalet ændrer niveau hver gang disse to signaler passerer hinanden. Savtaksignalet sættes fast på en frekvens, og det variable signal bestemmer således den ønskede duty-cycle på PWM-signalet. I figur 3.4 er brugt en sinuskurve for at vise forskellige dutycycle. På MSP430F149 microcontrolleren kan dette PWM-signal leveres af timer B, hvor det dannes på ovenstående måde. Resulterende spænding af PWM Den resulterende spænding som PWM-signalet genererer over tid sendt igennem et lavpasfilter (f.eks. en motor) er bestemt af følgende udtryk[6]: ȳ = 1 T T 0 f(t)dt. (3.1) Hvor ȳ = Den resulterende spænding. T = Periodetiden. f(t) = pwm-signalet. 21

30 KAPITEL 3. BAGGRUNDSVIDEN Da f(t) er lig y max for 0 < t < D T og y min for D T < t < T sættes dette ind i ligning 3.1 (D er dutycycle i %, y max er lig V cc og y min er lig V ss ), hvilket reduceres til følgende: ȳ = 1 T ( DT 0 ) T y max dt + y min dt DT (3.2) = D T y max + T (1 D) y min T (3.3) = D y max + (1 D) y min (3.4) Da y min = 0, forsvinder det sidste led og den resulterende spænding bliver således: ȳ = D y max (3.5) AD converter MSP en har indbygget en ADC (Analog to Digital Converter). ADC en i MSP en er af typen Successive- Approximation, som har en opløsning på 12 bit. ADC en fungerer ud fra metoden sample and hold, hvilket vil sige at kredsløbet holder det analoge signal stille i en kort periode, mens det konverteres til et digitalt signal. ADC en laver mellem reference spændingen ref til +ref 2 N trappetrin, hvor ADC en finder trappetrinet den målte spænding er på. Det kan ses ud fra formlen og grafen nedenstående. n = (V in V ref ) (2 N 1) V +ref V ref (3.6) Hvor n = den konverterede kode V in = input spænding V +ref = manuelt sat reference værdi V ref = manuelt sat reference værdi N = bitopløsning i ADC en 22

31 KAPITEL 3. BAGGRUNDSVIDEN Figur 3.5: ADC inddeling I MSP430F149 er N = 12 og reference værdier ref og +ref kan sættes til 0V, 1,5V, 2,5V, 3,3V og et selvvalgt spændingsinput. At ADC en finder et trappetrin, betyder også at der er en upræcished. Derfor jo bedre opløsning, jo større præcision. Dog afhænger alt ikke af opløsningen. Samplingstiden er også vigtig, hvis der måles på et meget varierende signal. Efter Nyquist Shannon sampling theorem[7], skal der minimum samples dobbelt så hurtig som frekvensen af signalet for at kunne genskabe signalet. ADC en på MSP430 sampler mellem 3.7 Mhz og 6.7 Mhz [5], hvilket intet signal i dette projekt vil nærme sig UART For at få kunne kommunikere direkte med microcontrolleren, benyttes seriel kommunikation som omtalt i afsnit 3.2. Til denne type kommunikation sættes microcontrollerens serielport op til at benytte UART-standarden (Universal Asynchronous Recieve/Transmit). Dette er et hardware modul på microcontrolleren, der benytter RS-232 protokollen til seriel kommunikation. I takt med, at RS-232 er en asynkron protokol, foregår timingen ved at enhederne i begge ender er enige om, hvordan kommunikationen skal sættes op. Dette gælder både overførselshastighed og format på de datapakker, der skal sendes. Det er denne enhed, der kan benyttes til seriel kommunikation. Se mere om seriel kommunikation i afsnit Seriel forbindelse I dette afsnit vil teorien bag en seriel forbindelse (RS-232 standarden) blive gennemgået. Dette omfatter, hvorledes data overføres, hvordan enhederne er forbundet samt, hvordan kommunikationen kan håndtere fejl. 23

32 KAPITEL 3. BAGGRUNDSVIDEN Seriel og parallel forbindelse [8] Der findes 2 forskellige typer af dataoverførsel: seriel og parallel. Ved seriel dataoverførsel overføres ét bit ad gangen, ved henholdsvis høj og lav spænding. Eksempler herpå er USB, Ethernet og RS-232. Ved parallel forbindelse, overføres der flere bit af gangen, f.eks. vil en forbindelse med 8 ledere, kunne overføre én byte af gangen. Eksempler herpå: PCMCIA og IDE. Selvom den parallelle forbindelse i teorien vil være hurtigere, benyttes seriel forbindelse oftere. Ved parallel kan der opstå problemer, med de mange ledere der er flettet sammen i ledningen, som kan skabe forstyrrelser for hinanden (crosstalk). Et andet problem er, at alle ledere skal være synkroniseret, hvilket vil sige at alle (f.eks.) 8 ben, skal præcis samtidig levere enten høj eller lav. Ved seriel forbindelse er man ude over problemerne med forstyrrelser, da der kun er én leder og derfor ikke kan skabes forstyrrelse, og mindre synkroniserings problemer. Det er derfor vi ser nyere forbindelses standarder i dag oftest benytter en seriel forbindelse RS-232 standarden [9]RS-232 er en standard for digital datakommunikation på lag 1 ift. OSI modellen, altså det fysiske lag. Standarden fastsætter: Karakteristikker for det elektriske signal, inkluderende spænding, rate og timing. Interface såsom stiktyper og deres benforbindelser Funktion af hvert kredsløb etableres mellem DCE 1 og DTE 2 via interfacet Standarden fastslår logiske 1 og 0 for data transmission til at være +/ volt. Signalspænding på +/-5 V, +/-10 V, +/-12 V og +/-15 V benyttes oftest, iht. det apparat forbindelsen kører på. Benet Common ground (G), er den fælles ground på 0 V. For data transmission ledninger (TxD, RxD) er det logiske 1 defineret som en negativ spænding, hvor det logiske 0 er defineret som positiv. På kontrol signaler (DTR, DSR, RTS, CTS, DCD, RI) er dette omvendt. Her er +3 til +15 V et udtryk for det logiske 1, altså at det er aktivt. Kontrolsignaler benyttes til at styre forbindelsen, sådan at DCE eller DTE s buffer ikke bliver overfyldt. Mere om dette under afsnit Figur 3.6: Eksempel på dataoverførsel efter RS Kilde: mike/serial/serial.html 1 Data circuit-terminating equipment, f.eks. modem 2 Data terminal equipment, f.eks. computer 24

33 KAPITEL 3. BAGGRUNDSVIDEN På figur 3.6 ses et eksempel på en overførsel efter RS-232. Der overføres én byte af gangen, altså 8 bit, plus minimum 2 kontrolbit. Standarden understøtter også 7 bit overførsel. Når der skal sendes en byte, sendes først et logisk 0 (positiv spænding), og derefter overføres 8/7 bit. Efterfølgende kan der sendes et paritets bit, som er en checksum af overførslen. Paritets bittet fortæller om der er et lige eller et ulige antal logiske 1-taller i byten der overføres. Værdien af paritetsbittet afhænger af, om der vælges even eller odd paritet. Ved even paritet er paritetbitten 0 hvis der er et lige antal logiske 1-taller og omvendt. Efter paritetbitten kommer et stopbit med værdi 1. Denne state holdes indtil næste overførsel, hvor værdien vil gå til 0.[10] Baudrate [10] RS-232 standarden understøtter både asynkron og synkron bus for forbindelsen. Synkron bus er når der leveres en clockfrekvens igennem forbindelsen, som overførslen synkroniseres efter. Asynkron er hvor der aftales en clock på forhånd af forbindelse, og på den måde ved både DCE og DTE, hvilken rate signalet sendes med. Denne aftale kaldes for baudrate, som er et udtryk for pulse pr. sekund. En baudrate på 9600 baud vil altså betyde 9600 pulse/sekund. Baudraten bliver derved et udtryk for hastighed for overførslen. Eksempler på baudrate er: 300, 600, 1200, 2400, 4800, 9600, osv DB9 stik [9] RS-232 standarden definere desuden interfacet mellem DCE og DTE. Den mest brugte er DB9 stikket, også kendt som COM-port. Standarden definerer også benforbindelser for DB25, men dette stik benyttes stort set ikke mere. I figur 3.7 ses ben forbindelserne for DB9. Figur 3.7: DB9 ben forbindelser - Kilde: Benene TD, RD og G er de vigtigste ben. TD (også kaldet TxD) bruges til at sende data (transmit), og RD (også kaldet RxD) bruges til modtage data. DCE s TD ben er altså forbundet til DTE s RD ben og omvendt. G er common ground, og bruges til at skabe en fælles referencepunkt. De andre ben er til kontrolsignaler, og bliver gennemgået under

34 KAPITEL 3. BAGGRUNDSVIDEN Signal type Abbr Dir DB9 Common ground G - 5 Transmitted data TxD Out 3 Received data RxD In 2 Data Terminal Ready DTR Out 4 Data Set Ready DSR In 6 Request To Send RTS Out 7 Clear To Send CTS In 8 Carrier Detect DCD In 1 Ring Indicator RI In 9 Tabel 3.4: Oversigt over DB9-stikket Kontrolsignaler [9] Standarden understøtter også en række kontrolsignaler. Dette bruges til at DCE og DTE kan spørge/ fortælle hinanden om de er klar til at sende/modtage data. Kontrolsignalerne omfatter: DCD - Data carrier detect Bruges ved modem, til at fortælle DTE at der er en udbyder tilgængelig. DTR - Data terminal ready Sættes af DTE til at fortælle at DTE er klar til at blive forbundet til. Dette kan f.eks. vække et modem. DSR - Data set ready Sættes af DCE for at fortælle DTE at DCE er klar til at modtage kommandoer. RTS - Request to send DTE kan sætte dette ben til logisk 0 for at fortælle DCE at forberede sig på at modtage data. En del af handshake. CTS - Clear to send Sættes af DCE som svar på RTS for at fortælle DTE at den er klar til at modtage data. En del af handshake. RI - Ringing indicator Bruges ved modem, til at fortælle DTE at der er et indkommende opkald Et eksempel på kontrolsignaler: 1. DTE sætter data terminal ready (DTR) og DCE sætter data set ready (DSR) 2. DTE sætter request to send (RTS) 3. DCE sætter clear to send (CTS) Konklusion RS-232 er defineret for at blive brugt til et modem, hvor DTE (computeren) bestemmer alt, hvilket tydelig fremgår af kontrolsignalerne. Kontrolsignalerne kan dog bruges på en anden måde i nærværende projekt, kontrolsignalerne kan bruges til at fortælle status på både DCE og DTE samt resette MSP en. Mere om dette i design af CP, se afsnit

35 KAPITEL 3. BAGGRUNDSVIDEN 3.3 Motorer I det følgende gennemgås princippet i en el-motor og 3 forskellige måder at implementere en elmotor på. [3]I en elmotor udnyttes den elektromotoriske kraft, der virker på en strømførende leder til at skubbe det roterende element rundt. Strømmen (I) gennem en leder, med længden (l), udsat for den magnetiske flux med styrken (B), giver anledningen til en kraft F på lederen udtrykt ved følgende: F = I l B (3.7) Figur 3.8: Kraft på en strømførende leder[11] DC-motor Det er den elektromotoriske kraft der får en DC-motor til at dreje rundt. Statoren (den faste del yderst) leverer magnetfeltet, som rotoren i midten påvirkes af, og roterer. Da magnetfeltets størrelse (som udgangspunkt) og længden af lederen er konstant, afhænger kraften på rotoren af strømmen gennem lederne på rotoren. Retningen af kraften, og dermed rotationsretningen, afhænger følgeligt at strømmens retning. Figur 3.9: Princippet i en DC-motor[11] På figur 3.9 ses magnetfeltlinjerne fra statoren (øverst/nederst), der går gennem rotoren inderst med lederne (+) og ( ). Da magnetfeltet B ligger vinkelret på lederen med længden l resultere krydsproduktet i en kraft F, der ligger vinkelret på begge, hvilket i DC-motoren skubber rotoren rundt. Alt efter strømretning roterer den enten den ene eller den anden vej. 27

36 KAPITEL 3. BAGGRUNDSVIDEN Step-motor I en step-motor har rotoren ingen vindinger, og da rotoren er lavet af jern, eller lignende materiale, vil den stille sig i hvad position, der end er aktiv i statoren. Figur 3.10: 30 stepmotor[11] Som det ses af figur 3.10 er rotoren linet op med fase A, der er tændt. Tændes fase B vil rotoren blive trukket om og sætte sig ud for den. Rotoren har nu drejet 1 step (her lig med 30 ) På den måde kan rotoren steppes rundt ved tænde polerne sekventielt. Polerne er delt i 3 grupper, hvor hver tredje er pol er i samme gruppe. Vinklen mellem polerne bestemmer størrelsen af det enkelte step, der kan være helt ned til 1,8. Følgelig er der tilsvarende flere poler Servo Servo-motorer er designet til hurtig acceleration og deceleration.[11]. Servoen er en enhed bestående af en motor samt en reguleringsløkke, som placerer aksen i en bestemt position. Dette leveres i en samlet enhed og kaldes for en servo. Dette er vist på figur Figur 3.11: Reguleringsløkke med servomotor[11] Motorens vinkel bliver målt, og resulterer i en given spænding. Denne spænding bliver sammenlignet med en referencespænding, der er et udtryk for den ønskede vinkel på motoren. Forskellen bliver forstærket og resultere i rotation på motoren, indtil denne står i den ønskede vinkel. 28

37 KAPITEL 3. BAGGRUNDSVIDEN Hele denne enhed kaldes en servo, hvoraf motoren er en integreret del Motorkonklusion Alle 3 motortyper vil i princippet kunne indgå i dette projekt. Forskellen ligger i det elektroniske interface til motoren. DC motor DC-motoren kræver relativt simpelt interface med en H-bro 3 til at drive den rundt fra en microcontroller. For at lave præcis positionering kræver det dog et feedback, som skal fortælle hvor motoren står til alle tider. Step motoren For at benytte step-motoren behøves intet positionsfeedback, da den kun drejer det antal step, den får besked på. Idet den indeholder 3 faser, der skal aktiveres relativt til hinanden, kræver den et noget mere avanceret interface men intet feedback-kredsløb. Servo Da en servo leveres som en færdig enhed, kræver en sådan ikke andet end et niveau-tilpasset PWM-signal 4 fra en microcontroller. Servoen skal som alle andre motorer tilpasses den givne situation - løft og indstilling af kanonløbet. En servo har heller ikke mulighed for at køre kontinueret, og vil derfor kræve en op-gearing for at kunne blive brugt til rotationen. Dette vil tilgengæld kræve en stor og stærk motor. 3 En H-bro er 4 transistorer koblet med motorens spole som bindeledet i et stort H. Dette giver mulighed for fuld kontrol over strømmen gennem motoren, både retning og størrelse, fra et digitalt kredsløb 4 PWM: PulseWidth Modulation. Et firkant-signal med fast frekvens, men variabel on-tid (duty-cycle). 29

38 Kapitel 4 Kravspecifikation 4.1 Indledning Denne kravspecifikation er udarbejdet for hele systemet, som kaldes Automated Lego Cannon (ALC). Kapitel 4 er udarbejdet efter Håndbog i Struktureret Program-Udvikling (SPU) [12], hvor kravspecifikationen er inspireret af SPU s vejledning i disciplin og styring af udviklingsfasen Formål I projektet skal der udvikles en pan-tilt enhed påmonteret en kanon styret af en microcontroller. Målet udvælges via en PC Læsevejledning Kravspecifikationen er skrevet på teknisk dansk, nogle ord er dog bevaret på engelsk for at bevare betydningen. Kravspecifikationen er bygget op i henhold til SPU håndbogens model, dog med få ændringer således at den er tilpasset projektet. I det efterfølgende opstilles krav til kanonens funktionalitet og generelle ydeevne. Der udledes fortrinsvist krav fra de enkelte scenarier i foranalysen. Den resterende del fremkommer som kvalificerede antagelser. 4.2 Generel Beskrivelse I dette afsnit vil systemet blive beskrevet i sin helhed. 30

39 KAPITEL 4. KRAVSPECIFIKATION Systembeskrivelse Systemet er en automatisk kanon. Målet, som kanonen skal ramme, skal udpeges af en bruger på en kontrolstation 1, via et interface med et kamera-feed. Derefter skal kanonen automatisk kunne tjekke, om målet er indenfor kanonens rækkevidde og tilpasse løbets retning og hældning, således at målet rammes. Efter en affyring, skal kanonen melde tilbage til kontrolstationen, om affyringen var udført succesfuldt eller ej. Systemets hovedfunktioner er: Figur 4.1: Systemet som helhed Figur 4.1 giver et overblik over systemet med dets enkelte blokke, og kommunikationsvejene mellem dem. Som vist sluttes webcam direkte til kontrolstationen, hvor brugen af dette implementeres i PCsoftware. Webcam benyttes, som ovenfor nævnt, som sigtemiddel i brugerprogrammet Systemets funktion Funktionen af ALC er at få udstukket et mål fra brugeren, hvorefter den selv retter kanonløbet ind på målet og skyder efter målet Systemets begrænsninger Der vil blive følgende begrænsninger på systemet: Affyringskraften bliver konstant. Det blev fastslået i ligning Definition: Den PC, hvorfra robotten styres med brugerinput. 31

40 KAPITEL 4. KRAVSPECIFIKATION Der vil blive en maksimum afstand til målet. Det blev fastslået i ligning 2.7 Målet skal være i samme højde som kanonen. Begrænsningen er der, da afstandssensoren ikke vil blive monteret med en tilt, hvilket ikke gør det muligt at ramme i andre højder. Målet skal være stationært. Begrænsningen er der, da det vil være meget softwarekrævende, at arbejde med 3D målsøgning. Hvis målet bevægede sig, skulle der bruges en mere konstant aflæsning af afstand og bevægelse, hvilket falder uden for projektets hovedformål Systemets fremtid ALC vil blive forberedt for følgende forbedringer, som kan implementeres i eventuelle fremtidige versioner: En funktion kan sættes på affyringsmekanismen for at give mulighed for, at ændre på affyringskraften, så skudvidden kan ændres, uden at ændre på kanonløbets vinkel i forhold til vandret. Dette vil tilføre endnu en variabel i beregningen af projektilets bane, samt en driver til denne mekanisme. Afstandssensoren kan gøres tiltbar, så den kan måle afstanden til objekter (mål), der er placeret højere eller lavere end selve ALC. Dette vil tilføre endnu en parameter i beregningen af projektilets bane, og endnu en driver. 2 kameraer til målsøgning vil give mulighed for at følge og ramme et mål i bevægelse, i 3D. Der skal bruges 2 kameraer til dette for at få dybden i billedet og dermed bevægelsen. Dette er nødvendigt for at kunne forudsige i hvilken retning målet bevæger sig, ud fra en bevægelses vektor som laves ud fra førliggende bevægelser af målet Krav til udviklingsforløb Der stilles følgende krav til udviklingsforløbet: Udvikles efter modificeret SPU-model [12] Alle filer skal encodes med Unicode (UTF-8). Funktionerne må ikke overstige en længde på 100 linjer kode. En kode linje må ikke overstige en længde på 100 tegn. Pseudokode syntaks bliver som illustreret i Algoritme 1, hvilket vil være i overensstemmelse med [13]. Syntaksen for koden skal være som illustreret i Kode 4.1. Systemet programmeres i C og C++. Kommentarer udfærdiges i Doxygen-standard, således programdokumentation kan genereres. Der skal foretages reviews ved milepæle iht. tidsplanen. Kommentarer, funktionsnavne, klasser og variabelnavne skrives alle på engelsk, for nemmere programmering og forbindelse mellem rapport og kode. Grafik under designfasen, samt pseudokoder udfærdiges ligeledes på engelsk. 32

41 KAPITEL 4. KRAVSPECIFIKATION Algoritme 1 Pseudokode eksempel if i maxval then i 0 else if i + k maxval then i i + k end if end if 1 # i n c l u d e <s t d i o. h> 2 # d e f i n d e EVER ; ; 3 4 void main ( void ) { 5 i n t i = 1 ; 6 i f ( i > 0) { 7 / Never e n d i n g loop / 8 f o r (EVER) ; 9 } 10 } Kodeeksempel 4.1: Kode eksempel Leverance Systemet vil blive leveret i form af en CD-ROM, hvorpå software, kildekode, dokumentation og den kompilerede software vil ligge på. Der vil ligeledes leveres hardware, som består af en platform med kanonen på, som er forbundet til microcontrolleren (MSP430f149) Forudsætninger Følgende forudsætninger stilles til afviklingsmiljøet: Hardware 1GHz processor 512 MB RAM 40GB harddisk RS-232 serielport, min BAUD (COMport) 1024x768(px) skærmopløsning Software POSIX Tabel 4.1: Forudsætninger til kontrolstation 4.3 Specifikke krav Definitioner Følgende definitioner gør sig gældende i de specifikke krav. 33

42 KAPITEL 4. KRAVSPECIFIKATION Grader Alle vinkler benævnes med grader, og er defineret ud fra, at en fuld rotation er på 360 grader. Webcam-feed opencv IplImage datastruktur 2. Opløsning i 640x480 pixel. 3-kanals farvebillede i B- GR 3 format. Skal arbejde mellem 1-5 FPS (Frame per second) Funktionelle krav I følgende afsnit vil de funktionelle krav til ALC blive defineret. For hver funktion vil der blive defineret et navn, samt en forkortelse. Denne forkortelse vil blive brugt i de efterfølgende kapitler. Forklaring til primære og sekundære krav Ved alle funktionelle krav, der her følger, er der angivet nogle primære og sekundære krav. De primære skal ses som værende de krav, som er absolut nødvendige for at systemet kan fungere, hvor de sekundære er krav, som ikke implementeres i denne omgang, men systemet gøres klar til, at disse kan designes og implementeres senere. Alle krav benævnes Kx.y, hvor x er nummeret på tabel med krav, og y er nummeret på det enkelte krav i hver tabel Graphical user interface (GUI) GUI har til formål at være brugergrænsefladen for brugeren. Det er igennem denne, at brugeren skal have mulighed for at ændre på kanonens indstillinger, samt at udvælge mål. GUI en er placeret på kontrolstationen (se afsnit 2.2). Primære krav K1.1 Loggen 4 skal opdateres automatisk minimum 1 gang i sekundet K1.2 Webcam-feed fra robotten skal vises i 5 FPS Sekundære krav (Ingen sekundære krav) Tabel 4.2: Krav for GUI Input Brugerens input Funktion Skal være kontrolstationen for hele systemet. Det er fra denne, at der skal angives, hvad der skal rammes, hvordan systemet skal fungere, kommunikere med robotten, samt modtage meddelelser fra robotten. Ouput Der er intet output Visual target marking (VTM) Visual target marking har til formål at markere og følge målobjektet. Primære krav Sekundære krav 2 Denne datastuktur anvendes, da opencv tilbyder et stor spektrum af billedbehandlingsfunktioner 3 BGR eller RGB er en forkortelse for et farveskema, hvor rød, grøn og blå er de primære farver. De tre farver kan kombineres for på den måde at skabe andre farver. 4 Loggen skal vise feedback fra systemet, se tabel

43 KAPITEL 4. KRAVSPECIFIKATION K2.1 Bearbejde 5 billeder hvert sekund, K2.3 Følge et bevægelig mål, der bevæger beregning skal altså ske på <= 0.2 sekund sig <= 2 m/s. Tabel 4.3: Krav for VTM Input Brugerens klik på webcam-feed i GUI Funktion Identificere det objekt der er blevet klikket på, via Computer Vision teknologier. Objektet skal klassificeres, således at det kan følges når kameraet bevæges. Objektet markeres visuelt med en rød firkant, hvis objektet følges korrekt. Ud fra placeringen af objektet beregnes den relative vinkel til objektet, og vinklen returneres. Output Relativ vinkel til objekt. Sendes til CR (se afsnit ) Cannon rotation (CR) Cannon rotation har til formål at rotere hele robotplatformen, eller nærmere bestemt, kanontårnet. Dette sker via input fra kontrolstationen. Primære krav Sekundære krav K3.1 Rotere med en præcision på 1 grad (Ingen sekundære krav) (= π 180 radianer) K3.2 Bevægelse af kanontårnet må ikke blive generet af ledninger ved rotation på 360 grader. K3.3 Der skal ske en timeout, hvis der i 3 sekunder ikke roteres K3.4 Kunne foretage en fuld rotation (360 grader) på 30 sekunder Tabel 4.4: Krav for Cannon rotation Input X grader at roterer. Funktionen aktiveres fra kontrolstationen via grafisk brugergrænseflade Funktion Roterer tårnet X grader. Der skal være feedback på rotationen, således at det sikres at der roteres X grader. Den skal være i stand til at rotere med en præcision på 1 grad. Output True/false, henholdsvis hvis det lykkedes eller hvis det fejlede. Mulige fejl kan være en timeout i rotationen eller ingen forbindelse til microcontroller Cannon angle (CA) Cannon angle har til formål at beregne vinklen på kanonløbet, ud fra afstandsmåling til målobjektet og formel 2.8. Skal foregå på hardware platformen, MSP430. Primære krav Sekundære krav 35

44 KAPITEL 4. KRAVSPECIFIKATION K4.1 Kunne beregne kanonløbets vinkel til (Ingen sekundære krav) nærmeste heltal i enheden grader. K4.2 Tilte løbet i intervallet 0-45 grader ift. vandret K4.3 Indstille løbet med en præcision på 1 grad (= π 180 radianer) K4.4 Måle afstanden til målobjektet vha. afstandsmåleren med en præcision på 2 cm. K4.5 Timeout, hvis ingen bevægelse i 3 sekunder. K4.6 Kunne udregne vinklen på 0.5 sekund. K4.7 Kunne indstille sig til ønsket vinkel på 10 sekunder. K4.8 Lave afstandsmåling på 0.5 sekund. Tabel 4.5: Krav for CA Input Start signal Funktion Måler afstanden til målobjektet via afstandsmåleren, beregner vinklen for at ramme objektet, og indstiller løbet til denne vinkel. Hvis systemet kører i Adjust&Shoot mode, skal den aktivere trigger systemet. Output True/false, henholdsvis hvis det lykkedes eller hvis det fejlede. Mulige fejl kan være en timeout i bevægelsen eller at objektet er for langt væk Trigger system (TS) Trigger system har til formål at aktivere affyringssystemet. Dets primære mål er, at aktivere affyringsmekanismen hurtigt, og uden at betydeligt påvirke selve affyringen, samt at sikre at skuddene er så ens som muligt. Primære krav Sekundære krav K5.1 Kunne affyre projektilet på under 1 K5.4 Automatisk kunne genlade kanonen sekund fra trigger tidspunktet K5.2 Ikke påvirke skuddets præcision med mere end 2% ift. skud uden trigger system. K5.3 Affyre 95% af gangene. Tabel 4.6: Krav for TS Input Start signal Funktion Affyrer kanonen på under 1 sekund fra start signalet. 36

45 KAPITEL 4. KRAVSPECIFIKATION Output True/false, henholdsvis hvis det lykkedes eller hvis det fejlede. Mulig fejl kan være at kanonen sidder fast Communication protocol (CP) Communication protocol har til formål at kommunikere mellem MSP en og kontrolstationen. Der skal defineres en standard for alle de forskellige datatyper der kan overføres. Primære krav Sekundære krav K6.1 Kunne håndtere hvis svartiden fra modtager er 10 sekunder (Ingen sekundære krav) K6.2 Kunne håndtere variabel længde af overførsel K6.3 Skal kunne validere modtaget data K6.4 Afsender må ikke overflow bufferen på modtageren Tabel 4.7: Krav for CP Input Data til overførsel Funktion Formaterer og indsætter data i foruddefineret protokol og afsender til modtageren (afhænger af afsender). Modtageren udpakker dataen og reagerer herpå. Protokollen skal kunne håndtere variabel længde af overførsel. Output Data overført fra afsender til modtager Platform Platformen er den fysiske enhed, der udgør selve kanonen. Det er denne, som skal bevæge sig vha. motorer reagere på de input, der kommer fra microcontrolleren (Se figur 4.1). Primære krav Sekundære krav K7.1 Kanontårnet skal kunne rotere 360 (Ingen sekundære krav) grader om sig selv K7.2 Kanontårnet skal kunne bære og rotere med en vægt på 1000 gram K7.3 Kanonløbet skal kunne løfte med en kraft på Nm 5 K7.4 Kanonen skal kunne skyde med en minimum hastighed på 5 m/s. Følgende krav er også relateret til Platformen: K3.1, K3.2, K3.4, K4.2, K4.3, K4.4 og K4.7 Tabel 4.8: Krav for Platform Nm svarer til at løfte 180 gram i en arm på 15 cm 37

46 KAPITEL 4. KRAVSPECIFIKATION Input Ingen input Funktion Platformen skal have nogle fysiske funktionaliteter, som f.eks. rotation af tårn og tilt af kanonløbet, som styres af motorene. Desuden skal platformen have en vis robusthed, således at den kan bære en vægt på 1000 gram. Output Ingen output 4.4 Præcision af kanonen Det er nødvendigt at opstille krav om, hvor præcist kanonen skal ramme, for overordnet at kunne sige noget om, hvordan systemet virker som en helhed. Da der i afsnit 2.5 blev opstillet mål for afstande til og dimensioner af målet, som kanonen skal skyde efter, er det muligt at opstille en ligning for succesraten for skuddene. For at skuddet klassificeres som en succes, skal det således ramme indenfor målet. Denne ligning vil danne fundamentet for kravene om præcisionen af skuddene. Det besluttes nu at kanonen ved skud mod et mål med afstand på 0.5m skal have en succesrate på 97%, og ved 2.5m en succesrate på 90%. Disse værdier er på figur 4.2 plottet i et koordinatsystem og der er tegnet en kurve imellem dem. Figur 4.2: Kurve over succesrate På figur 4.3 ses et udsnit af kurven fra figur 4.2, som bruges til at beregne, hvor kurven rammer succesrate-aksen. 38

47 KAPITEL 4. KRAVSPECIFIKATION Figur 4.3: Udsnit af kurve over succesrate Der beregnes i ligning 4.1 hvor kurven rammer på succesrate-aksen + 90% = 8.75 (4.1) I ligning 4.2 regnes der frem til stigningskvotienten i succesrateligningen, ved at indsætte afstand = 0.5m, og succesrate = 97%. a [afstand] = Succesrate a = 97 a = 3.5 (4.2) Nu kan den endelige ligning opstilles, som beskriver kravet for succesraten af skuddet ved afstanden X X 100 = Succesrate (4.3) Kravet er dermed at præcisionen af skuddene, ved den aktuelle afstand til målet, skal i et koordinatsystem ligge på eller over linjen beskrevet af ligning Eksterne Grænsefladekrav I dette afsnit vil de eksterne krav blive gennemgået Krav til brugergrænseflade Systemets brugergrænseflade er: Kontrolstationen. Brugeren har, som defineret i afsnit 2.2, adgang til en kontrolstation, hvorfra et mål kan udpeges som kanonen skal ramme. Dermed er det et krav, at brugeren kan anvende Ubuntu på bruger niveau, da interface et udvikles til at køre under dette system Krav til hardwaregrænseflade Da der i dette projekt udvikles et lukket system, skal det ikke interageres med andet eksternt hardware, og der er derfor ikke nogle eksterne hardwaregrænseflader, ud over strømforsyning. 39

48 KAPITEL 4. KRAVSPECIFIKATION Krav til softwaregrænseflade Af eksterne softwaregrænseflader benyttes der nogle forskellige programbiblioteker, for at lette udviklingen af systemet. Programbiblioteker Der skal benyttes følgende foruddefinerede software biblioteker: opencv Open Computer Vision. Et programbibliotek som giver adgang til avancerede billedbehandlings funktioner. Qt GUI bibliotek til C Krav til kommunikationsgrænseflade Da der i dette projekt udvikles et lukket system, skal det derfor ikke kommunikere med noget andet, og der er derfor ingen eksterne kommunikationsgrænseflader. 4.6 Systemets Ydelse Her vil blive stillet krav til systemets ydelse indenfor responstid på input, output og lignende. Desuden vil der blive stillet krav til softwarets størrelse, da noget af det skal implementeres på en microcontroller. Ydelseskravene er opdelt i MSP og software herpå og Software på kontrolstation. MSP og software herpå: Ved manuel rotation af kanonen via piletasterne, skal kanonen begynde at rotere under 1 sekund, efter indtastning Ved automatisk rotation via klik med musen, skal kanonen begynde at rotere under 1 sekund, efter klikket Cannon rotation skal kunne indstille løbet i den ønskede retning på under 10 sekunder Projektilet skal affyres indenfor 1 sekund af triggertidspunktet Software på kontrolstation: Ved klik på et punkt på billedet fra kamera feed et, skal punktet inden 1 sekund markeres med en firkant Visual target making skal kunne udføre beregninger på billedet på under 0.2 sekund 4.7 Kvalitetsfaktorer I dette afsnit vil de vigtigste kvalitetsfaktorer for systemet blive fremhævet under de forskellige kategorier. Da dette er et studieprojekt, og der ikke er nogen kunde som skal aftage det endelige produkt, er det derfor udviklerne der er nået frem til kvalitetsfaktorerne. 40

49 KAPITEL 4. KRAVSPECIFIKATION Pålidelighed Systemet skal kunne udføre 3 på hinanden efterfølgende skud, mod forskellige mål, uden at have systemstop. Vedligeholdelsesvenlighed Det skal være muligt at udskifte et hardwaremodul, f.eks. at udskifte et defekt kamera med et nyt, uden at koden skal omskrives. Alt kode skal være veldokumenteret vha. Doxygen dokumentation (fra afsnit 4.2.5). Integritet Da produktet kun skal fungere lokalt, og dermed ikke over netværk, kræves det ikke at der er nogen form for sikkerhed omkring data. 4.8 Accepttestspecifikation For at teste at alle krav og kvalitetsfaktorer overholdes, skal der opstilles en accepttestspecifikation for disse. Kvalitetstestfaktorer Stress- og Volumentest: Da systemet udvikles til at fungere indendørs, vil der ikke være nogen påvirkninger i form af vind, vejr eller temperature. Stress- og volumentesten er derfor kun rettet mod test af mange input på kort tid. Da eneste ydre input til systemet kommer fra brugeren (se afsnit 4.5), skal brugeren på kontrolstationen sende en masse forskellige manuel styrings kommandoer og få robotten til at rotere fra side til side. 1. Brugeren bruger piltasterne, og skifter hvert sekund mellem højre og venstre tast. Kanontårnet skal rotere skiftevis fra side til side, uden at få fejl. Test af ydeevne og Pålidelighed: Systemets ydeevne skal testes ved at teste om alle svartider er som specificeret i afsnit 4.3 Specifikke Krav, og i afsnit 4.6 Systemets Ydelse. Desuden testes pålideligheden ved at lade systemet udføre 3 på hinanden følgende skud (fra afsnit 4.7): 1. Platformen skal påbegynde rotering under 1 sekund efter klik med musen på et decentralt punkt på billedet 2. Platformen skal påbegynde rotering under 1 sekund efter tryk på en af piletasterne (højre/ venstre) 3. Ved et klik på et vilkårligt sted på billedet i interfacet, må der maksimum gå 10 sekunder før platformen har roteret og centreret punktet 4. Efter endt rotation skal indstillingen af kanonens tilt påbegyndes på under 0.5 sekund. 5. Ved manuel affyring skal projektilet affyres efter maksimum 1 sekund efter klik på Shoot-knappen. 6. Kanonen skal affyre mod mål på 3 forskellige afstande, uden at blive nulstillet. Fejlbehandlingstest: Da systemet består af flere forskellige hardware komponenter og en platform, skal software en kunne håndtere at en eller flere af disse ikke fungerer som ventet, og vise en fejlmelding i interfacet på kontrolstationen: 41

50 KAPITEL 4. KRAVSPECIFIKATION 1. Hvis platformen bliver instrueret til at rotere, og den ikke gør det, skal der efter 3 sekunder komme en fejlmeddelelse. 2. Hvis målet er udenfor rækkevidde af kanonen, skal der komme en fejlmeddelelse. 3. Hvis platformen når sin yderposition i panorering, skal den stoppe og der skal kommer en fejlmeddelelse. Testscenarier For at dokumentere at Kvalitetsfaktorerne og krav til Præcision af kanonen bliver testet, opstilles der en blackbox-test vha. nogle testscenarier og en test af præcisionen af kanonen. Scenarierne er udformet således at der testes for alle mulige input til systemet. Disse scenarier er opstillet i tabel 4.9. Disse scenarier vil desuden også dokumentere at funktionerne som brugeren ser, der er angivet i Use case (se 2.2) er implementeret. I tabel 4.9 er tider for udførelse udeladt for at gøre scenarierne mere overskuelige. For en mere detaljeret gennemgang af testen og scenarierne, henvises der til kapitel 13 Accepttest. 42 Nr. Scenarie Kvalitetsfaktorer 1 Brugeren vælger Adjust Only i interfacet, og der klikkes på et mål på billedet, som er indenfor rækkevidde af kanonen. Når platformen har indstillet sig klikkes der på Shoot. Kanonen affyrer projektilet hen mod målet og der kommer en melding om, at skuddet blev afviklet med succes. 2 Brugeren vælger Adjust Only i interfacet, og der klikkes på et mål på billedet, som er udenfor rækkevidde af kanonen. Platformen indstiller sig, men finder ud af at målet er ugyldigt, der kommer en besked om dette på interfacet. 3 Brugeren vælger Adjust & Shoot i interfacet, og der klikkes på et mål på billedet, som er indenfor rækkevidde af kanonen. Platformen indstiller sig og affyrer projektilet hen mod målet. 4 Brugeren vælger Adjust & Shoot i interfacet, og der klikkes på et mål på billedet, som er udenfor rækkevidde af kanonen. Platformen indstiller sig, men finder ud af at målet er ugyldigt, der kommer en besked om dette på interfacet. 5a 5b Brugeren anvender Manual Control og trykker på højre piletast, og holder den nede, for at dreje kanonen til højre. Når kanonen når sin horisontale yderstilling til højre, stopper kanonen sin rotation og en fejlmeddelelse om dette vises på interfacet. Brugeren anvender Manual Control og trykker på venstre piletast, og holder den nede, for at dreje kanonen til venstre. Når kanonen når sin horisontale yderstilling til venstre, stopper kanonen sin rotation og en fejlmeddelelse om dette vises på interfacet. 6 Brugeren vælger Adjust & Shoot i interfacet, og der klikkes på et mål på billedet, som er indenfor rækkevidde af kanonen. Platformen indstiller sig og affyrer projektilet hen mod målet. Målet flyttes til ny afstand, og proceduren gentages 3 gange. Test af ydeevne og Pålidelighed nr 1, 3, 4, 5 Fejlbehandlingstest nr 2, Test af ydeevne og Pålidelighed nr 1, 3 Test af ydeevne og Pålidelighed nr 1, 3, 4 Fejlbehandlingstest nr 2, Test af ydeevne og Pålidelighed nr 1, 3 Fejlbehandlingstest nr 3, Test af ydeevne og Pålidelighed nr 2 Fejlbehandlingstest nr 3, Test af ydeevne og Pålidelighed nr 2 Test af ydeevne og Pålidelighed nr 6

51 KAPITEL 4. KRAVSPECIFIKATION 7a Brugeren anvender Manual Control og trykker først på højre piletast, og derefter venstre piletast 20 gange. Trykkene skal komme hvert sekund. Platformen skal skiftevis dreje med og mod uret og skal skifte retning indenfor et sekund af hvert tryk. 7b Brugeren anvender Manual Control og trykker først på højre piletast og pil op, og derefter venstre piletast og pil ned 20 gange. Trykkene skal komme hvert sekund. Platformen skal skiftevis dreje med uret og tilte op, og mod uret og tilte ned. Skiftet i retning og tilt skal komme indenfor et sekund af hvert tryk. 8 Brugeren anvender Manual Control og indstiller kanonen således at sigtekornet peger på målobjektet. Derefter indstilles kanonløbet så skudlængden ca passer med afstanden til målet, og kanonen affyres. Tabel 4.9: Accepttest Scenarier Stress- og Volumentest nr 1, Test af ydeevne og Pålidelighed nr 1 Stress- og Volumentest nr 1, Test af ydeevne og Pålidelighed nr 1 Test af ydeevne og Pålidelighed nr 2, 5 Succeskriterierne for scenarierne opstillet i tabel 4.9 er, at de udfolder sig som angivet i det enkelte scenarie. Dermed er det i scenarie 1, 3, 6 og 8 ikke et krav at skuddet skal ramme målet, men blot at projektilet skal affyres. Test af præcision: Brugeren vælger Adjust only i interfacet, og der klikkes på et mål på billedet, som er placeret med afstand X meter væk fra kanonen. Kanonen skal indstille sig via panorering og tilt for at kunne ramme målet, hvilket betyder, at kanonen ikke må pege mod målet når testen går igang. Platformen indstiller sig og affyrer projektilet mod målet. Testen udføres ved afstande på med 0.5m mellemrum startende fra kortest mulige afstand til målet. Ved hver afstand skal der foretages 20 skud, som antages at være et repræsentativt antal for kanonens præcision. Resultatet af hvert skud er om skuddet ramte målet, altså ja eller nej. Succesprocenten af skuddene, som ramte målet, plottes i et koordinatsystem og sammenlignes med den linje som ligning 4.3, der er angivet i afsnit 4.4 Præcision af kanonen, beskriver. Succeskriteriet er dermed, at de plottede værdier skal være linjen angivet af ligning

52 Kapitel 5 Platform I dette kapitel vil krav til platformen og overvejelser til konstruktionen af denne blive dokumenteret. Desuden vil platformen blive illustreret i 3D grafik. Ydermere vil gearingen til panorerings- og tiltfunktionerne også blive dokumenteret. Til sidst vil der blive opstillet test af platformens egenskaber. 5.1 Krav og Designovervejelser I tabel 5.1 vil der blive henvist til krav vedrørende platformen. Hvis ikke andet er angivet er alle disse krav fra afsnit 4.3 Specifikke Krav. Krav Hvordan kravet opfyldes K3.1 Præcisionen på rotationen skal være på mindst 1 grad, hvilket kan løses ved at lave en gearing, så tårnet roterer langsommere end den ville, hvis motoren sad direkte på. K3.2 Rotationen må ikke hindres af ledninger mellem det roterene tårn og bunden af platformen. Dette kan lettest løses software-mæssigt. Tænkt på den måde, at der på softwaresiden holdes styr på hvor langt den er roteret til den ene side, og derfor kan sige hvornår der skal drejes den anden vej rundt for at nå den ønskede retning uden at ledningerne vil blive for korte. K3.4 Tårnet skal kunne rotere 360 grader på under 30 sekunder. Dette afhænger af gearingen i forhold til motorens hastighed, så denne skal tilpasses herefter. K4.2 Kanonløbet skal sidde på tårnet, og skal kunne tilte i intervallet 0 til 45 grader i forhold til vandret. Dette gør konstruktionen lettere at lave, da det er begrænset til dette interval. K4.3 Kanonens tilt skal kunne indstilles med mindst 1 grads nøjagtighed. Som ved rotationen kan dette løses med gearing mellem motor og kanonløbet for at sætte hastigheden ned og dermed præcisionen op. K4.7 Kanonløbet skal kunne indstille sig på under 10 sekunder. Dette kan løses ved at tilpasse gearingen så den kan nå det på under 10 sekunder. K7.1 Platformen skal have en del, som kan rotere 360 grader. Dette kan løses ved at designe platformen, som en 2-delt konstruktion med en overdel (et tårn), og en underdel (en base). K7.2 Hele platformen skal være så stabilt bygget, at den kan bære og rotere et tårn med en vægt på 1000g. Dette kan løses ved at centrere vægten af tårnet over monteringspunktet, samt at bygge hele platformen af et stabilt materiale. 44

53 KAPITEL 5. PLATFORM K7.3 Kanonen skal kunne løfte med en kraft på Nm, hvilket svarer til at løfte et legeme med en masse på 180 gram, holdt i en arm på 15cm. K7.4 Kanonen skal kunne skyde med en minimum hastighed på 5 m/s. Dette kan løses ved at optimere affyringsmekanismen, så den er kraftig nok til at kunne skyde kuglen afsted med denne hastighed. Fra afsnit 1.2 Der skal monteres et webcam og en afstandsmåler på tårnet. Afstandssensoren, skal måle afstanden til målet, som så skal bruges til beregning af vinklen på kanonløbet. Denne afstandssensor skal monteres, således at den måler i samme retning som kanonløbet og webcam et peger. Webcam et skal således også monteres på tårnet således at det peger samme retning som kanonløbet. Tabel 5.1: Designovervejelser ved platformen På figur 5.1 og 5.2 ses en foreløbig skitse af platformen, som specificeret i tabel 5.1. Figur 5.1: Skitse af platformen set fra oven 45

54 KAPITEL 5. PLATFORM Figur 5.2: Skitse af platformen set fra siden Valg af materialer: For let at kunne konstruere en funktionel platform, som i tilfælde af fejlkonstruktion eller fejl i designet let kan ombygges, er det valgt at bruge LEGO som byggemateriale. Desuden er valget af motorer faldet på en DC-motor, da denne kræver et simpelt interface, dog med en reguleringsløkke (se afsnit Motorer - Konklusion). Mere specifikt er valget faldet på en LEGO NXT motor, da denne har indbygget rotations-feedback (Se data sheet i appendiks A) og da LEGO selv bruger den, er den dermed samtidig lettere at implementere i LEGO konstruktionen. 5.2 Illustrationer På figur 5.3(a) og figur 5.3(b) ses to 3D illustrationer af platformen, som den er bygget. Illustrationerne er fremstillet i LEGO Digital Designer ( For yderligere granskning af modellen, henvises der til Legodigitaldesigner/platform.lxf (filen åbnes med LEGO Digital Designer). 46

55 KAPITEL 5. PLATFORM (a) 3D illustration af platformen (1) (b) 3D illustration af platformen (2) Figur 5.3: 3D illustrationer af platformen 47

56 KAPITEL 5. PLATFORM 5.3 Mål på platformen I dette afsnit er mål på platformen angivet, og ud fra disse mål beregnes kuglens startpunkt, da dette ændrer sig når kanonløbet tiltes. Figur 5.4: Mål på platformen På figur 5.4 er de nødvendige mål på platformen, til beregning af kuglens startpunkt, angivet. Figur 5.5: Illustration af kuglens startpunkt Figur 5.5 illustrerer hvordan kuglens startpunkt ændrer sig, når kanonløbet tiltes fra at stå i vandret position til en tilt på 45 grader. Der tages udgangspunkt i tiltens rotationspunkt, som det fremgår af figur 5.6. Dermed ændres kuglens startpunkt i x-aksen med x 0 og i y-aksen med y 0. 48

57 KAPITEL 5. PLATFORM Figur 5.6: Kuglens startpunkt i et koordinatsystem Nu kan der opstilles formler for x 0 og for y 0 som funktioner af α. Dette gøres ved at lave det fra rektangulære til polærer koordinater, da dette er nemmere at arbejde med i denne sammehæng. Der bruges følgende standard formler til omregning fra rektangulære til polærer koordinator: x = r cos(θ) y = r sin(θ) θ = arctan( y x ) r = x 2 + y 2 (5.1) Nu findes de værdierne, som er målt på platformen figur 5.4, som skal bruges til at opstille de endelige formler for x 0 (α) og y 0 (α). x platform = 11.2cm y platform = 3.3cm b platform = 15.3cm (5.2) (5.3) De endelige formler x 0 (α) og y 0 (α) opstilles nu: x 0 (α) = y 0 (α) = ( x platform2 + y platform2 cos arctan ( x platform2 + y platform2 sin arctan ( yplatform x platform ( yplatform x platform ) ) + α ) ) + α + b platform Som nævnt ovenstående bruges x platform og y platform, som de konstante mål angivet på figur 5.4, i formlerne for x 0 (α) og y 0 (α). Desuden lægges b platform til formlen for y 0 (α), også angivet på figur 49

58 KAPITEL 5. PLATFORM 5.4, som er den konstante højde på tiltens rotationspunkt. For at lave et udtryk for rækkevidden, som gjort i ligning 2.6 i afsnit 2.4, men hvor kuglens startpunkt også er medregnet som funktion af den vinkel kanonløbet står i (α), sættes y (t max ) = y 0 (α) og t max findes. y 0 (α) = V 0 sin(α) t 1/2 g t 2 t max = V 0 sin(α) + V 2 0 sin(α)2 + 2 g y 0 (α) g (5.4) Rækkeviden bliver derfor her x max (t max ) = V 0 cos(α) V0 sin(α) + V0 2 sin(α)2 + 2 g y 0 (α) g ( V 0 cos(α) V 0 sin(α) + ) V0 2 sin(α)2 + 2 g y 0 (α) = g (5.5) Hertil skal x 0 (α) lægges til for at få den endelige formel: x max = x 0 (α) + ( V 0 cos(α) V 0 sin(α) + ) V0 2 sin(α)2 + 2 g y 0 (α) g (5.6) Nu beregnes rækkevidden (x max ) med x 0 (α) og y 0 (α) værdierne medregnet, ved at indsætte starthastigheden på kuglen (V 0 ) og vinklen på kanonløbet (α). Sættes hastigheden til 5 m s og α til 0 og 45 grader, fås kurverne i figur

59 KAPITEL 5. PLATFORM Figur 5.7: Kuglens startpunkt i et koordinatsystem [CD Matlab/korrigeretkuglebane.m] Af figur 5.7 fremgår det, hvordan kuglens startpunkt ændrer sig ift. kanonløbets tilt. 5.4 Gear På figur 5.8 ses en illustration af gearingen mellem mo- Gearingen ved rotation af platformen: toren og rotationen. Figur 5.8: 3D illustration af rotationens gearing De røde tal er antallet af tænder på tandhjulet, og de blå streger er hvor tandhjulene er forbundet med kæde 1. Heraf fås det at gearingen er: 1 kæden er en standard LEGO kæde 51

60 KAPITEL 5. PLATFORM = 4 63 Ratio = (5.7) (5.8) Gearingen ved tilt af kanonløbet: På figur 5.9 ses en illustration af gearingen mellem motoren og tilten. Det er valgt at implementere tilten med en gearing for at forøge præcisionen. Figur 5.9: 3D illustration af tiltens gearing De røde tal er antallet af tænder på tandhjulet. Der behøves ikke at tages højde for slør i gearingen, da vægten af kanonløbet konstant vil holde gearingen i spænd. Heraf fås det at gearingen er: = 1 9 Ratio = 1 9 (5.9) (5.10) 5.5 Kanonløbet Kanonløbet bliver specialfremstillet til dette projekt. Løbet er et teflon rør, lukket i den ene ende, og med en rille i siden, som fungerer som en glidebane for ladegrebet. 52

61 KAPITEL 5. PLATFORM (a) Kanonløbet (ikke ladt) (b) Kanonløbet (ladt) Figur 5.10: Kanonløbet med trigger monteret På figur 5.10(a) ses et billede af kanonen, hvor den ikke er ladt, og på figur 5.10(b) er et billede af kanonen, hvor den er ladt. Den sorte klods, som holder løbet fast, monteres på LEGO et. Oven på den sorte klods sidder triggeren, som her er det eneste der kan styres elektronisk, og via software (se afsnit 7.6 om trigger). Inde i løbet er en fjeder, som sættes i spænd når ladegrebet trækkes tilbage og skubbes i hak. Ladegrebet sidder i en rund klods, som skubber kuglen frem, når triggeren aktiveres. Da der i dette projekt er fokus på software og elektronisk hardware, vil der ikke blive gjort mere ud af kanonen, hverken design eller implementeringsmæssigt. 5.6 Test I tabel 5.2 er opstillet en oversigt over hvordan det enkelte krav til platformen skal testes. Se desuden appendiks H for en mere detaljeret gennemgang af testspecifikationen. Testsoftware: For at kunne teste alle kravene til platformen, er det nødvendigt at kunne styre motorene. Til denne test anvendes små programmer (placeret på Platformtest/Mindstorms-programmer/ ), som er lavet i LEGO MINDSTORMS Edu NXT 2. 2 LEGO MINDSTORMS Edu NXT er program som følger med LEGO MINDSTORMS sættet som standard 53

62 KAPITEL 5. PLATFORM Test Krav Hvordan kravet testes 1 K3.1 Rotationsmotoren sættes, vha. motorstyringssoftwaren, til at dreje 13 grader (1 = 4 63 X = X, men da motoren kun kan operere i hele grader sættes X = 13), hvilket også beviser at den kan indstilles til under 1 grad. 2 K3.2 Der skal monteres en 30cm ledning fra tårnet (punkt a) til basen (punkt b), af platformen. Punkt a og punkt b skal fra udgangspunktet være placeret lige over hinanden. Nu skal tårnet kunne rotere 181 grader den ene vej og derefter 362 grader den anden vej. På den måde dokumenteres det at tårnet kan pege i alle 360 grader, uden at blive forhindret af ledninger. For at tårnet kan dreje 181 grader skal motoren dreje 2851 grader (181 = 4 63 X = X rundes op til 2851), og for at tårnet kan dreje 362 grader skal motoren dreje 5702 grader (362 = 4 63 X = X rundes op til 5702). 3 K3.4, Rotationsmotoren sættes, vha. motorstyringssoftwaren, til at dreje 5670 grader K7.1 (360 = 4 63 X 5670 = X). Der skal tages tid fra start af rotation til den stopper, hvor den målte tid skal være under 30 sekunder. 4 K4.2 Kanonløbet indstilles til at stå i vandret udgangspunkt. Derefter sættes tiltmotoren, vha. motorstyringssoftwaren, til at dreje 410 grader (45 = 1 9 X 405 = X), hvilket beviser at den kan operere i et interval, som er større end 0 til 45 grader. 5 K4.3 Kanonløbet indstilles til at stå i vandret udgangspunkt. Derefter sættes tiltmotoren, vha. motorstyringssoftwaren, til at dreje 8 grader (1 = 1 9 X 9 = X), hvilket også beviser at den kan indstilles til under 1 grad. 6 K4.7 Kanonløbet indstilles til at stå i vandret udgangspunkt. Derefter sættes tiltmotoren, vha. motorstyringssoftwaren, til at dreje 405 grader (45 = 1 9 X 405 = X). Der skal tages tid fra start af tilt til den stopper, hvor den målte tid ikke må være over 10 sekunder. Dette viser at den kan indstille sig til hvilken som helst vinkel indenfor 45 grader på under 10 sekunder. 7 K7.2 Der monteres en vægtklods på tårnet, således at det har en samlet vægt på minimum 1000g. Rotationsmotoren sættes, vha. motorstyringssoftwaren, til at dreje 5670 grader (360 = 4 63 X 5670 = X). 8 K7.3 Der skal monteres en arm hvor kanonløbet skal være, med en længde på 15cm. For enden af armen skal der monteres en vægtklods som vejer 180g. Ved testens start skal armen være vandret. Tiltmotoren sættes nu til at dreje 405 grader (45 = 1 9 X 405 = X). 9 K7.4 Længden af skuddet kan beregnes med formel 5.6 ved at indsætte α = 45, x = 0.112m, y = 0.033m og V 0 = 5m/s. Derved fås 0.056m + 5 m s cos(45 ) (5 m s sin(45 )+ (5 m s )2 sin(45 ) m s 0.256m) m s = 2.839m. For at teste at kanonen kan skyde med en minimumshastighed på 5 m/s, indstilles kanonløbet til en vinkel på 45 grader, og affyres et repræsentativt antal gange. Hvis afstanden fra kuglens startpunkt til nedslagspunktet gennemsnitsligt er større end 2.54m, så skyder kanonen med en hastighed som er højere end 5 m/s. Tabel 5.2: Test af krav til platformen Resultat af testen I tabel 5.3 er udfaldet af hver test dokumenteret. Test Udfaldet af testen Godkendt / Ikke godkendt 1 Tårnet roterer mindre end 1 grad og stopper. Godkendt 54

63 KAPITEL 5. PLATFORM 2 Tårnet roterer uhindret 181 grader med uret, stopper, og Godkendt roterer 362 grader den anden vej og stopper. Ledningen blev ikke spændt ud på noget tidspunkt. 3 Tårnet roterer 360 grader og stopper på sekunder. Godkendt 4 Kanonløbet tilter over 45 grader og stopper. Godkendt 5 Kanonløbet tilter mindre end 1 grad og stopper. Godkendt 6 Kanonløbet tilter 45 grader og stopper på 1.19 sekunder. Godkendt 7 Tårnet roterer 360 grader og stopper. Godkendt 8 Armen tilter 45 grader og stopper. Godkendt 9 Kanonløbet tilter 45 grader, og kanonen affyres 98 gange. Godkendt Kuglen lander i gennemsnit 3.93m væk. Gennemsnitshastigheden udregnes vha. ligning 5.6 til 5.97 m s, se afsnit Tabel 5.3: Resultat af test af platform Test af kanonløbet (Platform test 9) Til beregning af V 0 for hvert skud bruges ligning 5.6, hvor α = 45 og x max er længden af det enkelte skud. Skuddene er plottet i figur 5.11 (se filen Platformtest/kanontestdata.xls for testdata). Figur 5.11: Skudene plottet i en graf [CD Matlab/distance.m] Ud fra målingerne, er det muligt at finde en gennemsnitsafstand af skudene. Gennemsnittet er 3.93 m. Det ønskes nu at bestemme udgangshastigheden, men da ligning 5.6 er for kompliceret, til at kunne 55

64 KAPITEL 5. PLATFORM udlede V 0 analytisk, løses den numerisk, vha. en Divide & Conquer metode: Bisektion metode 3. Af matlab scriptet er det fundet at udgangshastigheden er: V 0 = 5.97 m s (5.11) Ved at indsætte V 0 fundet vha. bisektion metoden i ligning 5.6 beregnes x max til 3.93m. Figur 5.7 fra afsnit 5.3, opdateres nu med denne nye udgangshastighed. Dette plot kan ses i figur Figur 5.12: Kuglens startpunkt i et koordinatsystem med V 0 = 5.97m/s [CD Matlab/korrigeretkuglebane.m]. 5.7 Korrektion af krav Når hastigheden af skuddet kendes, og dermed kanonens maksimale og minimale skudafstand, er tilpasning af enkelte krav og tilhørende test nødvendig. 3 Udregning af bisektions metode: Platformtest/velocitycalc.m 56

65 KAPITEL 5. PLATFORM Tilpasning af Præcision af kanonen Den mindste afstand kanonen kan skyde, ved kanonløbet indstillet i 0 grader, er 1.3m, og ved 45 grader er afstanden 3.9m (se afsnit 5.6). Ved at indsætte disse afstande som X i ligning 4.3, fås succesraterne i ligning = 94.2% = 85.1% (5.12) Tilpasning af definition af målet Med ændring af rækkevidden af skuddet til mellem 1.3m og 3.9m, ændres vinklen som kanonen må afvige også, i forhold til at pege direkte mod midten af målet. I ligning 2.9 fra afsnit 2.5, blev vinklen udregnet til 2.29 grader. Med den nye rækkevidde udregnes vinklen i ligning V = arctan( 10cm 390cm ) π 180 V = 180 arctan( 1 39 ) π V = 1.47grader (5.13) 57

66 Kapitel 6 Systemdesign I dette kapitel vil design af systemet 1 som helhed blive gennemgået. Med udgangspunkt i platform, kapitel 5, kravspecifkation, kapitel 4, og foranalysen, kapitel 2, vil der blive udfærdiget et overordnet design, der følger disses specifikationer. Med udgangspunkt i figur 4.1, af afsnit 4.2.1, vil der nu blive opstillet et mere specifikt blokdiagram over systemets dele. Figurerne er vejledende, og skal efter designfasen revurderes, således de valgte metoder fremgår. Der tages derfor forbehold for ændringer. 6.1 Hardware - Robot 1 Definition: Systemet defineres som værende både robot og kontrolstation med tilhørende software 58

67 KAPITEL 6. SYSTEMDESIGN Figur 6.1: Foreløbig Hardware-blokdiagram - Robot Af figur 6.1, ses de fysiske komponenter samt de elektroniske kredse, der er nødvendig for at opfylde systemets krav. Der indgår 3 analoge/digital sensorer: afstandsmåler og 2 encodere til motorerne. Disse skal henholdsvis bruges til at måle afstanden til objektet, samt feedback fra motorerne. Se kapitel 5 for mere information. Følgende elektroniske kredse skal fremstilles under hardware: Seriel port Der skal fremstilles en kommunikationskreds benyttende RS232 standarden. Trigger system Trigger systemet skal kunne lave et 3.3V signal fra MSP en om, således at det kan aktivere triggeren. Motor #1 & #2 Der skal fremstilles en motordriver, der kan fungere sammen med et signal fra MSP430 samt NXT motorerne. Vcc spænding Der skal findes og vælges en strømkilde, der kan levere en høj nok spænding samt levere den nødvendige strøm. Regulatorer Der skal fremstilles en række regulatorer, der kan nedsætte spændingen til henholdsvis motorstyring, MSP430 og sensorerne. Analoge drivere Der skal udvikles drivere, der kan omsætte signalet fra afstandsmåleren og encoderne til noget MSP430 eren kan forstå. Interface board Der skal fremstilles et interfaceboard, hvor de enkelte komponenter kan tilsluttes M- SP430 eren på en enkel måde. 59

68 KAPITEL 6. SYSTEMDESIGN 6.2 Hardware - Kontrolstation Figur 6.2: Foreløbig Hardware-blokdiagram - Kontrolstation Der benyttes en almindelig PC som kontrolstation, med dertilhørende komponenter som grafikkort, mus/tastatur og en seriel port. Der skal desuden tilsluttes et webcam via USB interfacet. Der vil ikke blive lagt mere vægt på den hardware mæssige opbygning på kontrolstationen end dette. 6.3 Software Det følgende diagram viser en overordnet flow i softwaren. Der benyttes syntaksen Functional flow block diagram [14], hvilket er vist på figur 6.3. Figur 6.3: Syntaks Functional flow block diagram Med udgangspunkt i de specifikke krav af afsnit 4.3 samt scenarier af afsnit 2.3, kan følgende figur opstilles. 60

69 KAPITEL 6. SYSTEMDESIGN Figur 6.4: Overordnet software flow Af figur 6.4 ses sammenhængen mellem systemets forskellige funktioner, samt en liste over de software moduler der skal laves. F(x.y) Navn Beskrivelse Kontrolstation 1.1 GUI Graphical User Interface har til formål at være interaktionspunkt for brugeren, samt kommunikere med microcontrolleren, MSP CP Communication Protocol (kontrolstation) er det software, der skal stå for kommunikationen mellem kontrolstation og robot. Der skal opstilles nogle faste regler for kommunikationen (en protocol), og der skal laves et simpelt interface til disse. 1.3 VTM Visual Target Marking, er sigte systemet. Dette skal kunne følge et objekt via webcam, mens kanonen roterer. Den skal altså stå for den visuelle del af systemet. Robot 2.1 CP Communication Protocol (robot), skal have samme protocol som F(1.1), og reagere på de inputs den får. 2.2 CR Cannon Rotation skal rotere kanontårnet X grader og sikre at dette sker. Den skal altså bruge feedback fra encoderen. 2.3 CA Cannon Angle, skal indstille kanonløbet Y grader, og sikre dette sker udfra sit feedback fra encoderen 2.4 TS Trigger System skal affyre kanonen når robotten er klar til dette. Tabel 6.1: Software moduler - Disse moduler er yderligere beskrevet i afsnit

70 KAPITEL 6. SYSTEMDESIGN State diagram Af figur 6.4 ses flowet mellem de forskellige software moduler over systemet som helhed. Der vil nu blive defineret nogle state diagrammer for henholdsvis robotten og kontrolstationen. State diagrammer bruges til at undersøge hvilke state systemet kan være i, og om der er nogle steder hvor der ville kunne opstå deadlock. Figur 6.5: State diagram - Robot Figur 6.6: State diagram - Kontrolstation Som det ses af figur 6.5 og 6.6 vil softwaren på både robot og kontrolstation være i ventende tilstand, indtil der kommer input fra henholdsvis kontrolstation og bruger. 6.4 Interface mellem moduler For at systemet kan fungere som en helhed, skal der defineres nogle interfaces mellem de enkelte moduler. Det er relevant at påpege, at der lægges vægt på, at alt kommunikation mellem modulerne, foregår 62

71 KAPITEL 6. SYSTEMDESIGN i softwaren. F.eks. vil de to motorer ikke kunne snakke sammen via noget elektronik, men kun via softwaren. Interfaces for moduler vil derfor kun blive defineret for software. Dog vil der godt kunne opstå kommunikation på hardware inde i moduler. Figur 6.7: Interface mellem moduler I figur 6.7 ses de interfaces, der er nødvendige mellem modulerne. Bemærk, at dette ikke er den endelig definition af modulerne, men kun de funktioner som er tilgængelige fra andre moduler. De enkelte moduler er fri til at implementere andre interne funktioner, så længe disse offentlige er tilgængelige og følger interfacets specifikationer. 6.5 Parallel afvikling Når det endelig system kører, vil der være flere ting der kører samtidig. Men samtidig er systemet afhængig af svar fra andre dele af systemet, og derfor skal der foretages en sekvens analyse af systemet. Dette er for at sikre der ikke opstår deadlocks, hvor begge systemer venter på hinanden og aldrig kommer videre. Der vil her blive lavet et sekvens diagram for systemets mest automatiseret funktion. Det er ved denne funktion systemets dele kommer til at snakke mest sammen. Denne sekvens er angivet på figur

72 KAPITEL 6. SYSTEMDESIGN Figur 6.8: Sekvens diagram Som det ses af figur 6.8 foregår indstillingen og affyring sekventiel, men på forskellige dele af systemet. Der vil derfor ikke være nogle punkter hvor MSP430 f.eks. står og spørger kontrolstationen om information, men kontrolstationen står og venter på specifik svar fra MSP430. Som det ses, er det nødvendig med 2 tråde i kontrolstationens software. Kontrolstationen skal være istand til at opdatere sit webcamfeed kontinueret samtidig med at den skal vente på svar fra MSP430. Der er derfor behov for 2 tråde på kontrolstationen. 64

73 Kapitel 7 Hardware Design I dette kapitel vil designet af hardwaren i projektet, blive gennemgået, og dokumenteret. For yderligere information om hardwaren henvises der til appendiks A til F. 7.1 Motordriver Som tidligere nævnt benyttes der NXT motorer. Disse motorer bruger 9VDC for at operere ved deres mest effektive moment. MSP430 eren leverer dog kun 3.3V og maks 25 ma kombineret for alle udgange[5]. Der skal derfor laves en H-bro, der kan leverer 9VDC og 500mA (1A peak) til hver motor. En H-bro giver mulighed for i gennem en microcontroller at styre retning og størrelsen af en strøm, som er større end den strøm som microcontrolleren kan levere. Udover at kan afbryde og forbinde strømkilden, har den også mulighed for at skifte retning. Figur 7.1: Diagram for H-bro - Kilde: h-bridge-fundamentals/3 65

74 KAPITEL 7. HARDWARE DESIGN På figur 7.1 er der monteret 4 dioder. Dette er for at sikre der ikke løber strøm tilbage i kredsløbet når motoren løber fri. Da motoren også kan fungere som en generator (som sker når motoren coaster), er det vigtigt at sikre denne strøm ikke løber tilbage igennem H-broen og resten af systemet. En H-bro fungere ved, at der sidder 4 FET som bruges til at åbne for en spænding V+. Når der bliver sendt signal til H-bro (ofte i form af PWM), åbnes Q1 og Q4, og der bliver derved skabt et kredsløb igennem motoren med 9V på venstre side. Åbnes Q2 og Q3 derimod, vil der blive skabt et modsat kredsløb, denne gang med 9V på højre side. På denne måde er det muligt at styre retningen på motoren. Da hastigheden bestemmes af spændingen over motoren kan denne styres af PWM-signalet bestemt ved ligning 3.5 som omtalt i afsnit Der vælges en L298 Dual full bridge driver som H-bro. Denne håndtere op til maks 50V som Vcc og 2A, samt der er indbygget 2 H-broer i den samme IC. Det er derfor et godt valg til dette projekt, da der skal bruges 2 motorer. Denne IC har også en enable funktion (EnA og EnB) til at styre H-broen, ved Enx = L, forbruger H-broen næsten ingen strøm. Figur 7.2: L298 diagram [CD Datablade/L298.pdf ] Styring af retning For at styre retningen, skal der laves et digital kredsløb som kan styre In1 og In2 på L298 IC en. Output ift. input kan ses af tabel 7.1. Yderligere information om L298 input kan ses på Datablade/L298.pdf. Input Rotation EnA = H In1 = H; In2 = L Fremad In1 = L; In2 = H Baglæns In1 = In2 Hurtig motorstop EnA = L In1 = X; In2 = X Ingen rotation Tabel 7.1: Input/output for L298 66

75 KAPITEL 7. HARDWARE DESIGN Af tabel 7.1 ses at der skal laves et logisk kredsløb, som er høj på enten In1 eller In2, men ikke samtidig. Dette kan opskrives som følgende boolske udtryk In1 = Dir PWM (7.1) In2 = Dir PWM (7.2) Der skal altså være 2 input til motorstyrings kredsen: Retning (Dir) og hastighed (PWM). Output er så In1 og In2 som fungerer som input til L298 H-bro. Ligning 7.1 og 7.2 kan implementeres med 2 AND gates med en inverter på én indgang på den ene. Men da det skal implementeres via færdige IC er, skal der vælges nogle kredse til dette. Da der skal bruges 2 uafhængige motorstyringer, vil der være brug for 4 AND gates med inverter på 2. Sådan en kreds er ikke en standard kreds, og der vælges derfor at implementere med 4 AND og 2 NAND gates. NAND gates bruges som invertere, ved at kortslutte dens 2 indgange til samme signal, dette vil derved svare til en NOT gate. HEF4081B og HCF4011B er to IC er der har henholdsvis 4 NAND og 4 AND gates. Figur 7.3: Implementering af ligning 7.1 og 7.2 Interface til MSP HEF40x1B er CMOS logik, og har en LOW-input spænding på maximum 1.5V og en HIGH-input spænding på 3.5V. Det betyder at det ikke kan interfaces direkte med MSP430F149 som har en LOW-output spænding på 0V og HIGH-output spænding på 3.3V. For at skabe interface herimellem, skal signalet fra MSP en føres igennem en TTL/CMOS IC. Denne har en LOW-input spænding på 0.8V og HIGH-input spænding på 2.0V. Dette er altså kompatiable med MSP ens 0 og 3.3V. Til at skabe dette interface bruges en 74HCT08 (se datablad Datablade/74HCT08.pdf ), dette er en TTL/CMOS 4 AND gate. Ved at koble to indgange på samme AND gate sammen, fåes en buffer som kan agere interface. Beslutning om at benytte et interface er truffet efter implementering. Motordriveren fungerede, men grundet disse spændingsforskelle på 3.3V og 3.5V i henholdsvis MSP en og HEF40x1B IC erne, er det nødvendigt at indsætte et interface for at validere driveren. HEF4081B og 74HCT08 er ikke pin-kompatiable og derfor placeres en 74HCT08 IC ved siden af motordriveren, som fungerer som interface mellem motordriveren og MSP en. Det er kun signaler til HEF40x1B IC erne som kræver dette interface, signaler direkte til L298 H-bro har en HIGH-input voltage på 2.3V og kan derfor fungere direkte med MSP ens signaler. Figur 7.4: Interface mellem MSP og motordriver. [CD Datablade/MSP430F149-datablad.pdf ], [CD Datablade/74HCT08.pdf ] [CD Datablade/HEF family specs.pdf ] 67

76 KAPITEL 7. HARDWARE DESIGN Strømforbrug Ifølge appendiks A er NXT-motorenhedens strømforbrug 500 ma ved en belastning på 15 Ncm (se figur A.2). Dette gælder uanset om spændingen er på 7.2 VDC eller 9 VDC. TTL-logikken har ifølge Datablade/HCF4011.pdf en max-rating på 200 mw, der ved 5 volt giver en maks strøm på 40 ma. Med to TTL-kredse implementeret i motordriveren giver det 80 ma. I følge databladet på H-broen - Datablade/L298.pdf - har logikken i H-bros IC en et max strømforbrug (I ss ) på 36 ma. Konklusion Der benyttes en L298 full dual bridge driver Der skal benyttes 3 output fra MSP430: PWM signal, retning (H/L) og enable (H/L) Retningsstyring implementeres via 2x1 NAND gate og 2x2 AND gates. Systemenhed Spænding [VDC] Strøm [ma] DC-motorer (H-bro) 9 max 1000 TTL-logik Motor feedback Feedback fra NXT motorerne kommer fra deres indbyggede rotations encoder, hvilket gør det muligt at bestemme position og hastighed. Disse motorer benytter en quadrature encoder, som generere 2 firkantssignaler. Opløsningen er 2 grader pr. periode pr. udgang, hvilken vil sige at hver gang der kommer en rising- eller falling edge har motoren roteret 1 grad. Der er 2 udgangssignaler fra encoderen, som kan bruges til at bestemme retningen af motoren. Dette gøres ved at se hvilket signal, der først generere en risingedge. De to signaler er 90 grader faseforskudt, og derved er det muligt at få en opløsning på 0,5 grader hvis der er detekteret på både falling- og risingedge på begge signaler. Se figur 7.5[15]. Figur 7.5: Encoder output Af krav K3.1, kommer at kanonen skal roterer med en præcision på 1 grad, samt krav K4.3, at løbet skal indstille sig med en præcision på 1 grad, skal der bestemmes hvorledes encoder signalet skal behandles for at opfylde disse krav. Af afsnit 5.4 Gear under kapitlet om platform, ses at der er gearing mellem motorerne og den enhed der skal indstille sig med den givne præcision. Rotationen har et forhold på 4/63, hvilket vil sige, at en præcision på motoren på 15,75 grader ville være nok. Løbet har en gearing på 1/9, så her er en præcision på 9 grader tilstrækkelig. Der er derfor kun behov for en opløsning af encodersignalet på 1 grads præcision, og derfor vælges der kun at benytte én udgang fra encoderen. Derved benyttes også kun ét input på MSP en. Kun at benytte ét signal, vil også halvere mængden af signaler systemet skal overvåge. 68

77 KAPITEL 7. HARDWARE DESIGN Der er 2 måder at tilslutte encodersignalet til MSP430 eren, enten direkte som input 1 eller igennem en ekstern hardware tæller kreds 2. For at vælge hvilken der er bedst, skal der ses noget yderligere på signalets hastighed og spænding. Test af signal fra encoder Af appendiks C ses at signalet fra encoderen, vil svinge mellem 200 Hz (3.5V) og 500 Hz (9V). Af testen ses det, at signalfrekvensen bevæger sig inden for et område, hvor det er muligt at tilslutte direkte input med interrupt på MSP430. Da MSP430F149 har en 125-ns instruction cycle time, og det antages der skal laves 38 instruktioner ved hver signal (se appendiks C), tager dette ns = 4750ns, og da frekvensen maksimalt kan blive 500 Hz, og der detekteres på både falling og rising edge, er der et tidsoverskud på 1s (1000Hz 4750ns) = 995,25ms pr. sekund. Det er altså muligt at implementere encodersignalet som input direkte i systemet, samtidig med systemet kan lave andre beregninger, som f.eks. regulering af motorerne. Da det ønskes at registrere hastighed samt position, kan der benyttes en timer på MSP430 eren. Ved at sætte denne til capture mode, er det muligt at beregne tiden siden sidste signal, og derved hastighed. Encoderen tilsluttes derfor en input port til en timer i capture mode. En anden mulighed ville være at bruge en input interrupt port. Hvor der aktiveres en interrupt når der sker en niveau-ændring på en indgang. Den pågældende Interrupt Service Routine skulle så lægge 1 til en global variabel, der skulle testes på efterfølgende, dette gør det dog mere besværlig at beregne hastigheden af motoren. Interrupt test For at teste om systemet kan bære at få 1000 interrupts i sekundet, foretages en simpel test på MSP430F149 eren. Testen starter watchdog timeren op med en frekvens på 900 Hz (det nærmeste den kan komme 1000 Hz), og i hver interrupt tælles der til 16 hvilket giver cirka 100 cycles. Ved at lave noget kode som tæller til 4095 i main løkken, og flipper et output hver gang den har talt, er det muligt at tælle hvor hurtig den tæller til Ved først at tage en måling med scope, hvor interrupt er disabled, og dernæst, hvor interrupt enabled, kan man ved at finde forskellen i frekvens, se hvor meget tid der går med interrupt rutinen, og hvor meget tid med main løkken. Koden til testen kan ses af Encodertest/interrupttest.c. Følgende målinger blev taget: Målt frekvens uden interrupt Målt frekvens med interrupt 180 Hz 177,9 Hz Ud fra frekvensen, kan det nu beregnes hvor stor brøkdel af tiden MSP en bruger på interrupts. Frekvensen ganges med to, da udgangen toogles ved hver optælning. ( ,9) = % (7.3) ms 1.1% = 11ms Det er altså bevist, at ved en interrupt frekvens på 900 Hz og cirka 100 cycles i interrupt service routinen (ISR), bruges 11 ms af hvert sekund på at servicere interruptet. Skaleres dette til de 1000 Hz og de 38 cycles som antaget i forrige afsnit, er resultatet accepttabelt. Der foregår altså flere beregninger i ISR end der skal bruges, og her bruges der kun 11 ms på ISR. Det vil altså være muligt, at benytte encodersignalet direkte som interrupt på MSP430F149, samtidig med at resten af systemet kan arbejde normalt. 1 Direkte input forståes enten en interrupt port på MSP en, eller capturemode på en timer 2 Ekstern kreds der sender ét interruptsignal når X antal encoder signaler er talt (7.4) 69

78 KAPITEL 7. HARDWARE DESIGN Konklusion Encoder signalet tilsluttes en input port til en timer med capture mode. Der benyttes kun ét encoder output 7.3 Initialisering af motorer Det ønskes at motorerne kan indstille henholdsvis kanontårnet og løbet i en bestemt position. Før dette kan lade sig gøre, er det nødt til at kende deres nuværende position, og bevæge sig forskellen. Der skal derfor findes en måde hvorpå en position 0 kan findes. Kanontårnet Da kanontårnet kan dreje 360 grader om sig selv, og dens mål altid kan angives relativ til dens nuværende position, skal der til kanontårnet benyttes en relativ vinkel. Dertil kommer at tårnet skal have et punkt på rotationen på 360 grader, der kan defineres til nulpunktet. Dette nulpunktet skal bruges til at holde styr på hvor langt tårnet har drejet, og dermed til at sikre at ledningens længde ikke bliver et problem ved kontinuert rotation. Dette nulpunkt kan markeres på forskellige måder, men for enkelhedens skyld vælges der at bruge en trykknap, som aktiveres hver gang et bestemt punkt på tårnet passerer den. Der skal derfor monteres en trykknap, som tårnet kan røre. Der vælges en NXT Touch Sensor som trykknap. Denne aktiveres af lav kraft påvirkning, og kan nemt implementeres i LEGO platformen. Interface Til denne løsning skal der bruges 1 interrupt input. Tårnet kan derved sættes til at rotere indtil der opstår interrupt fra kontakten. Systemet ved således at positionen er 0 når kontakten røres. Denne position vil så kunne blive brugt til fremtidig reference, og derved kan den også vide hvornår ledningen ikke kan nå længere. Kanonløbet For kanonløbet er det vigtigt at kende vinklen til vandret, da denne har indflydelse på dens kuglebane. Der skal derfor laves en initialiserings rutine der fastlægger løbets position. Dette kan gøres på forskellige måder: 1. Montere et accelerometer på løbet, som fortæller vinklen 2. Montorer en trykknap i en bestemt vinkel, og regne vinklen ud fra dette punkt i softwaren. 3. Monterer et potentiometer der leverer vinklen analogt. Igen for enkelhedens skyld, vælges der at benytte en trykknap. Denne er nemmere at implementere i hardware, billigere og kræver mindre software, da et accelerometer enten skulle have en seriel eller analog indgang, som skulle konverteres, og potentiometeret skulle bruge en ADC konvertering. Der skal derfor monteres en trykknap, som kanonløbet kan aktivere. Næste spørgsmål er nu i hvilken vinkel trykknappen skal monteres. Operationsområdet for kanonen skal derfor bestemmes, for at finde en position hvor den ikke vil være til gene eller vil kunne skabe fejl. Kanonen skal kunne skyde mellem 1.3m og 3.9m, og via figur 5.12, kan det bestemmes at operationsområdet af løbet derved bliver 0-45 grader. Trykknappen skal altså ikke ligge inden for dette område. I afsnit 5.6 Test af platform, vises at der er lidt slør i kanonløbet. Ved vandret (0 grader), vil tyngdekraften dog trække i løbet, og derved sørge for sløret er i sit yderpunkt. Og da løbet aldrig vil 70

79 KAPITEL 7. HARDWARE DESIGN bevæge sig over 45 grader, vil der altid være træk i løbet i den samme retning som ved 0 grader. Et optimalt initialiseringspunkt for løbet vil derfor være ved 0 grader. Her vælges også en NXT Touch Sensor som trykknap. Da denne kan aktiveres af lav kraftpåvirkning, bevirker den derved ikke løbet betydeligt. Interface Til denne løsning skal der bruges 1 interrupt input. Løbet kan derved sættes til at bevæge sig med sænkende vinkel indtil der opstår interrupt fra kontakten. Positionen er derved sat til 0 grader. Konklusion Der benyttes en trykknap for at bestemme løbets startposition Der benyttes en trykknap til at lokalisere kanontårnets nulpunkt Trykknap til kanonløbet placeres således, at den er aktiveret når løbet er i 0 grader (vandret) Trykknap til kanontårnet placeres således, at tårnet uhindret kan dreje 360 grader den ene vej, men ikke den anden vej Der benyttes en NXT Touch Sensor til begge løsninger NXT-Touch Sensor NXT-touch sensoren diagram vil her blive gennemgået. Figur 7.6: LEGO NXT Touch Sensor. Kilde: lego-mindstorms-nxt-touch-sensor-2.html På figur 7.7 ses et diagram over elektroniken i sensoren. Som det fremgår er det et forholdsvist simpelt interface, som kræves af sensoren. Den skal have et input på 3.3V, på port 1, og så skal der detekteres på port 2. Når der bliver trykket på kontakten på sensoren kortsluttes forbindelsen, og der kommer output på port 2. 71

80 KAPITEL 7. HARDWARE DESIGN Figur 7.7: Touch Sensor Diagram 7.4 Afstandssensor For at kunne opfylde krav K4.4 fra afsnit om at måle afstanden til et givet mål med 2 cm præcision ønskes en afstandssensor installeret på det roterende tårn på platformen. Denne skal måle afstanden til et punkt inden for en relativ smal vinkel, så den kun måler afstanden til det ønskede objekt og ikke det rundt om. Til formålet benyttes SHARPs IR afstandssensor - GP2Y0A700K, se appendiks B. Denne påmonteres lige under kameraet og kan derfra måle afstanden til det kameraet tager billeder af. Figur 7.8: Vout som udtryk for den målte afstand. [CD Datablade/R302-GP2Y0A700K0F-2.pdf ] Denne afstandssensor udsender en analog spænding, der er et udtryk for den målte afstand. Som det ses af Figur 7.8 kan denne spænding variere mellem 0.5V og 3.0V, hvilket har betydning for opsætningen af den analoge til digitale converter i microcontrolleren. Figur 7.8 viser også at V out stiger hurtigt fra 0 cm til 100cm for derefter at falde ikke-liniært. Dvs. med det samme spændingsniveau kan den vise to afstandsmålinger. Dette gør at den kun kan bruges til at måle afstande større end 100cm hvis den skal 72

81 KAPITEL 7. HARDWARE DESIGN give et entydigt resultat. Dette output niveau på maks 3VDC betyder at den analoge udgang fra afstandsmåleren kan sluttes direkte til microcontrolleren uden spændingstilpasning. Som det fremgår af IR-sensorens datablad Datablade/R302-GP2Y0A700K0F-2.pdf har den dog behov for sin egen strømforsyning, der kan levere minimum 400mA ved 5VDC Korte afstande Til at måle afstanden til objekter tættere på end 100 cm, der er minimum for afstandssensoren GP2Y0- A700K, tilføjes endnu en afstandssensor nemlig GP2Y0A02YK, der er en lillebror til GP2Y0A700K. Denne mindre afstandssensor fungere på samme måde som den store, men er effektiv indenfor afstande mellem 20 cm og 150 cm, se Datablade/GP2Y0A02YK.pdf, hvor den store er mellem 100 cm og 550 cm. Dette overlap i måleområde giver mulighed for at dobbelttjekke målinger på afstande mellem 100 cm og 150 cm. Området omkring 100 cm er især kritisk, da outputtet for den store sensor i dette område peaker og bliver lavere med kortere afstande. Se Figur 7.8. Figur 7.9: Vout fra lille sensor i forhold til målt afstand. [CD Datablade/GP2Y0A02YK.pdf ] Som det ses af outputtet fra den lille sensor - Figur giver den et 1-til-1 output i området omkring 100 cm, hvilket gør dette output brugbart ved afstande kortere end 110 cm. Ved at tilføje denne mindre afstandssensor kan ved kombinere output fra 2 afstandssensorer måles afstande i et område mellem 20 cm og 550cm. 7.5 Serieldriver Da der skal være mulighed for kommunikation mellem kontrolstationen og robotten, skal der udvikles en driver, som kan håndtere denne kommunikation. Der vælges seriel kommunikation, da det, som nævnt i afsnit 3.2, har færre forstyrrelser og der er kun 1 signalvej at holde styr på, hvilket gør det nemmere at arbejde med frem for en parallekommunikation. En serielport på en PC leverer ± 6V efter RS- 232 standarden, men MSP430F149 benytter TTL logik. Der skal derfor laves et interface mellem disse to signaler. Der vil i dette tilfælde blive brugt en Maxim MAX3232, som det kan ses på nedenstående figur 7.10, kan bruges som dette interface mellem RS-232 og TTL. 73

82 KAPITEL 7. HARDWARE DESIGN Figur 7.10: Max3232 diagram - Kilde: [CD Datablade/MAX3232.pdf ] Der bruges 5 kondensatorer til at lave en energi oplagring, kaldet charge pump. Det er vha. netop denne teknik, at der kan ændres på spændingsniveauerne. Valget af maxkreds blev gjort på baggrund af forelæsning i Datamaters arkitekturer og programmering kursusgang 6, hvor der var introduktion af serielkommunikation. 7.6 Trigger Til dette projekt er der blevet specialfremstillet en kanon der aktiveres ved at en spole oplades. Denne trigger funktion, fungerer ved at en metalstang er placeret i centrum af en spole, og når spolen oplades dannes der et magnetfelt, som flytter metalstangen fremad. Den holdes i nul-position af en fjeder. For at affyre projektilet, skal denne spole altså oplades således metalstangen skubber til ladegrebet og projektilet affyres. Det er den spole der er monteret på kanonen, der skal laves et hardware interface til. Den givne spole er målt til at have en selv induktion på 103mH og en ohmsk værdi på 130Ω. For at spolen har nok kraft til at affyre kanonen, skal der være en spændingsforskel over den på 24V. Der skal derfor designes noget hardware, der kan levere 24V meget hurtigt. Dette gøres ved at bruge et relæ til at styre op- og afladning af en kondensator. Den oplades gennem en modstand til 24V for derefter at blive forbundet til spolen i parallel, således at kondensatoren aflades gennem spolen. Relæet virker derved som kontakt som vist i figur

83 KAPITEL 7. HARDWARE DESIGN Aktivering af magnetfelt Den korte energipuls, der skal drive spolen, genereres ved at oplade en kondensator til en 24V, for derefter at lade den aflade gennem spolen. Dette stilles op i figur Figur 7.11: Princippet i triggeren Kontakten er NC (Normally Closed) mellem kondensatoren og spolen. På denne måde bruger kredsløbet ikke strøm fra V cc når triggeren ikke er i brug. Når kontakten flippes over til anden position oplades kondensatoren til V cc. Den aflades således gennem spolen når kontakten slippes igen. Opladning af kondensatoren Der vælges en kondensator på 1000 µf for at give tilstrækkelig energi til at flytte hammeren i spolen. For at kunne opfylde krav K5.1, der siger at projektilet skal kunne affyres på under 1 sekund, skal kondensatoren oplades på mindre end et halvt sekund. Op- og afladningen af kondensatoren gennem en modstand følger ligning 7.5[16]. x(t) = K 1 + K 2 e t τ (7.5) Hvor x(t) = strøm- eller spændingsresultat τ = tidskonstant R C Som det ses af figur 7.2 på side 295 i Basic Engineering Circuit Analysis[16] aflades kondensatoren med 63.2% hver gang, der er gået en tidskonstant τ. Dette er også gældende for opladning, hvilket vil sige at efter 5τ er forskellen på spændingen over kondensatoren og V max mindre end 1%. Da både opog afladning af kondensatoren skal ske på under 1 sekund totalt set skal 5 τ være mindre end 1 2 sekund. Med kondensatoren på 1000µF regnes en max. modstandsværdi ud som følger. Først τ: 5 τ < 500ms (7.6) τ < 100ms 75

84 KAPITEL 7. HARDWARE DESIGN Dette giver en modstandsværdi på: R C < 100ms (7.7) R 1000µF < 100ms R < 100ms 1000µF R < 100Ω Der vælges følgelig en modstand på 80Ω. Det resulterende kredsløb se i figur Figur 7.12: Triggerkredsløbet ved opladning af kondensatoren. Afladning af kondensatoren Når relæet slippes igen og kontakten flippes over så der er forbindelse til spolen kommer kredsløbet til at se ud som på figur Modstanden på 130Ω er spolens ohmske modstand. Ud fra dette kredsløb, udledes udtrykket for spændingen over spolen som en spændingsdeling mellem kondensatoren og spolen. Ligning 7.8 giver dette udtryk i Laplace domænet. Figur 7.13: Triggerkredsløbet ved afladning af kondensatoren og dermed affyring. V L (s) = V cc s R + sl R + sl + 1 sc (7.8) Hvor V L (s) = Spændingen over spolen V cc = Kondensatorens startspænding R = Spolens ohmske modstand L = Spolens selvinduktion C = Kondensatorens kapacitet 76

85 KAPITEL 7. HARDWARE DESIGN Overført til tidsdomænet med en inverse Laplace transformation fås ligning 7.9 V L (t) = V cc (A + B) (7.9) ( ) A = e RL 1 2L cos LC RL 2L t B = RL ( ) 2 2L 1 1 LC ( ) e RL 2L t sin 1 RL RL 2 LC t 2L 2L Ligning 7.9 beskriver afladeforløbet, som er plottet på figur Målt op- og afladningsforløb Via en testopstilling med kondensator, modstand og spole, er målingen i figur 7.14 og figur 7.14 foretaget. Plottet i figur 7.14 viser spænding over kondensatoren, og figur 7.15 spændingen over spolen. Som det ses af figur 7.14 og figur 7.15 er kondensatoren opladet til tæt på 24V efter: 5 τ = 0.650s Som figur 7.14 og 7.15 viser gør dette sig også gældende ved afladning. Udregningen er et udtryk for den ideelle situation. Figur 7.14: Opladning og afladning af kondensator i triggerdriver [CD Trigger/triggergraph.m]. 77

86 KAPITEL 7. HARDWARE DESIGN Figur 7.15: Opladning og afladning af kondensator i triggerdriver [CD Trigger/measurements.CSV]. Ligningen for afladningen er lagt ind på dette plot, der viser at teorien passer med virkeligheden. Det ses at de teoretiske udregninger passer med de praktiske målinger. Designet kan nu implementeres. Dog skal der først udledes en metode til at styre relæet fra MSP en Interface til MSP430 Opladningen af kondensatoren og afladning gennem spolen, skal styres af et relæ som fungere som kontakt i figur 7.11 Figur 7.16: Relæets funktion [CD Datablade/19RELAY 36.pdf ] Skiftes kontakten i figur 7.11 ud med relæet i 7.16 sluttes kondensatoren til ben 11 af relæet og spolen til ben 12. V cc sluttes til ben 14. Den valgte spole er påtrykt værdien 24VDC, hvilket giver den krævede spænding på spolen og dermed V cc på diagrammet på figur Relæet skal drives af signal fra microcontrolleren, der giver 3.3V ud som et høj signal. Dette signal leverer maks. 2 ma ud, hvilket ikke er nok til at trække relæet, der er målt til at bruge 70 ma for at slutte kontakten. Der skal derfor laves en forstærker til signalet fra microcontrolleren. Denne forstærker er inspireret af en application report fra Texas Instruments Interfacing the 3-V MSP430 to 5-V Circuits Datablade/MSPinterface.pdf. 78

87 KAPITEL 7. HARDWARE DESIGN Figur 7.17: Interface til MSP430 [CD Datablade/MSPinterface.pdf ] Kredsløbet, der skal forbinde triggeren med microcontrolleren, ses på figur Går microcontrolleren høj på udgangen åbnes transistoren og der kan løbe strøm gennem relæets kontaktspole, hvilket trækker relæet on. Værdien af basismodstanden R b beregnes med følgende formel taget fra ovennævnte application report: R B < R relay h fe (V ) OH(min) V BE(on) (7.10) (1 + p) V sys (max) R B < 8095Ω Hvor R B = Basismodstand R relay = Ohmsk modstand af relæet (Målt: 70Ω) h fe = Transistorens strømforstærkning (Aflæst på datablad 3 : 370) V OH(min) = Minimum spænding for logisk 1 (2.7V 4 ) V BE(on) = Basis-emitter spænding ved transistor on (Aflæst på datablad 5 ) p = Tolerance i modstanden (± 10%) V sys (max) = Max spænding på ekstern system (5VDC ± 10%) Der vælges følgelig en modstand på 8KΩ 7.7 Power Supply Unit For at få strøm til de forskellige enheder i systemet ved forskellige spændinger kræves der en strømforsyningsenhed, eller Power Supply Unit (PSU), der kan levere de forskellige spændinger. Denne vil nu blive gennemgået. Dimensionering Før et design af PSU kan foregå skal kravene listes til den, hvilket sker ud fra en worst-case vurdering af strømforbruget af de enkelte systemenheder. Der kigges på Absolute Maximum ratings fra de enkelte datablade, hvilket er gennemgået ved design af de enkelte enheder. RS-232 og trigger modulernes strømforbrug er målt manuelt til det nævnte i tabel 7.4. Strømforbruget for microcontrolleren og afstandssensoren er direkte fra databladet, da disse moduler ikke kræver yderligere design af projektgruppen. 79

88 KAPITEL 7. HARDWARE DESIGN Systemenhed Spænding [VDC] I max [ma] DC-motorer (H-bro) (afsnit 7.1) TTL-logik (motordriver) Afstandssensor 5 50 RS-232 interface MSP430F Trigger solenoid Trigger styring 5 70 Tabel 7.4: Strømforbrug af de enkelte elementer i systemet Strømforbruget til MSP430F149 er beregnet ud fra en formel fra databladet Datablade/MSP430F149-datablad.pdf : I tot = I AM f (7.11) Hvor I tot = total strømforbrug [ma] I AM = Strømforbrug i Active Mode ved 1 MHz (0.560[mA]) f = krystalfrekvens (7.3728[MHz]) 24.0 V 24 ma W 9.0 V 1000 ma W 5.0 V 246 ma W 3.3 V 24 ma W Total W Tabel 7.5: Total effektforbrug fordelt på spændinger Med disse krav til dimensioneringen kan et endeligt kredsløb designes. Til de ønskede spændinger, 9V, 5V og 3.3V, findes der en række standard regulatorer, som kan levere disse spændinger. Serien LM78xx har 2 regulatorer der kan bruges i dette projekt, LM7809 og LM7805, se databladet: Datablade/78xx.pdf. Der findes desuden en 3.3V regulator kaldet LM1086, som kan levere 3.3V, se databladet Datablade/LM1086.pdf. Da V in er 24V og den højeste regulerede spænding, som skal bruges af ALC, er 9V, vil der være et stort spændingsfald over LM7809 (9V) regulatoren. Da det kaskade kobles, vil alt strøm som bruges på 9V, 5V og 3.3V skulle gå igennem 9V regulatoren, som samtidig skulle regulere ned fra 24V. Der opstår derfor stort effekttab i 9V regulatoren, som afsættes i form af varme. For at fordele effekttabet, benyttes en 15V regulator (LM7815) før 9V regulatoren. På denne måde vil der være et spændingsfald på 9V fra 24V til 15V og 6V spændingsfald over 9V regulatoren regulatoren kan levere 1.5A og da 9V, 5V og 3.3V har et samlet maksimum strømforbrug på 1.27A (se tabel 7.5), vil denne regulator kunne levere den strøm, der er brug for. LM78xx serien kræver 2.5VDC over udgangsspændingen som indgangsspænding og LM1086 kræver 5V som indgangsspænding. Det betyder at regulatorne kan kaskadekobles som følgende: 24V LM V LM7809 9V LM7805 5V LM V Dette kan designes som vist på figur

89 KAPITEL 7. HARDWARE DESIGN Figur 7.18: Diagram over PSU Kondensatorerne bruges til at mindske rippel på spændingerne, når disse belastes. På den måde sikres en mere stabil spænding ud af PSU en. Lysdioden skal indikere om der er strøm på modulet. For at begrænse strømmen gennem lysdioden er der sat en modstand i serie med lysdioden. Konklusion For at kunne levere den nødvendige strøm til de enkelte dele af systemet, ud fra de indsamlede data om maksimalt strømforbrug, vælges komponenter således, at PSU en maksimalt kan give følgende spændinger og strømme: Spænding [V] Strøm [A] Effekt [W] Note [17] Datablade/78xx.pdf Datablade/78xx.pdf Datablade/LM1086.pdf V cc tages direkte fra en ekstern strømforsyning, der skal kunne levere den ønskede strøm og spænding. 7.8 Hardware konklusion Efter endt hardware design, kan det foreløbige hardware blokdiagram, se figur 6.1 under systemdesign, nu opdateres. Figur 7.19 viser den endelig hardware opsætning. 81

90 KAPITEL 7. HARDWARE DESIGN Figur 7.19: Hardware-blokdiagram - Robot De ændringer der er foretaget fra det foreløbige design vil nu kort blive gennemgået: Motorfeedback Motorfeedback er blevet udskiftet med encodersignaler fra NXT motorerne og overføres digitalt i stedet for analogt, som først antaget. I første udkast var planen at benytte et potentiometer og en lysgaffel 6, men dette er nu udskiftet med digitale encodere. Afstandsmålere Der er fjernet drivere for afstandsmålerne, da de returnere en spænding mellem 0V og 3V3 og derfor kan sættes direkte som input på MSP en Touch sensore Der er tilføjet touchsensorer til at initialisere rotationen og løbet. Disse har begge en driver bestående af en pull-down modstand. Encoderfilter Encodersignalet gennemgår et filter inden signalet sendes digital til MSP en. Dette er for at fjerne støj fra MainCable. Motordriver Der benyttes kun én motordriver, men med mulighed for at styre to motorer 24V regulator Der benyttes 24V til triggerdriveren i stedet for samme spænding som motorerne, som angivet i første udkast. Dette betyder at alle andre regulatorer skal regulere ned fra 24V 6 Elektronisk komponent, hvor en infrarød lysdiode lyser på en photo-transistor, således er det muligt at registrere når denne lysstråle bliver afbrudt. 82

91 Kapitel 8 Hardware Implementering I dette kapitel vil hardware implementeringen blive gennemgået. Alt implementering foretages i 2 trin: Først på bread-board, hvor enheden testes, og dernæst en mere holdbar implementation på veroboard. De enkelte dele, gennemgået herunder, vil blive implementeret som enkeltstående moduler, og vil kunne tilsluttes det endelige system via ét stik. Dette medfører enklere modultest og implementering. Robotten vil blive tilsluttet via ét enkelt kabel hvor alle forbindelser er i, dette defineres som MC (MainCable). 8.1 Modul implementering Alle hardware dele fremstilles som moduler. For yderligere at bruge modultankegangen iht. software, monteres der også en moduldetector på hvert modul. Hvert modul får således et C in og et C out ben. På modulet er disse kortsluttet, således MSP en kan udsende et høj signal på C in og når den får et høj signal tilbage fra C out er modulet detekteret. På denne måde vil softwaren være istand til at sende fejl hvis enkelte moduler ikke er tilgængelig, samt der vil være mulighed for senere at implementere et fejlsøgningssystem på de enkelte moduler. Hvert modul får også monteret en lysdiode for at vise at der er strøm på det enkelte modul. Lysdioderen monteres efter følgende diagram: Figur 8.1: Implementering af diode Udregningen af modstand: modstand = V cc 2V 20mA (8.1) Hvor V cc er spændingen dioden tilsluttes. Ligningen forudsætter brug af en LG2640 diode. Se Datablade/LG2640 diode.pdf. 83

92 KAPITEL 8. HARDWARE IMPLEMENTERING 8.2 Motordriver Motordriveren kan nu implementeres med følgende komponenter: 1 L298 Dual Full bridge driver Datablade/L298.pdf 1 HCF4011 IC (NAND gates) Datablade/HCF4011.pdf 1 HEF4081 IC (AND gates) Datablade/HEF4081.pdf 2 100nF kondensator 8 12V dioder 1 LG2640 Grøn lysdiode Datablade/LG2640 diode.pdf Ω modstand Dette er forbundet i figur 8.2 Figur 8.2: Implementering af motordriver 84

93 KAPITEL 8. HARDWARE IMPLEMENTERING Diagrammet i figur 8.2 skal nu overføres til veroboard. Her er der monteret interface stik. Interfacet er gennemgået i appendiks D. Implementering på veroboard ses af figur 8.3. Der monteres også moduldetector samt lysdiode iht. modulimplementeringen. Figur 8.3: Implementering af motordriver på veroboard 8.3 Power Supply Unit Power Supply unit (PSU) implementeres med følgende komponenter: 1 LM spændingsregulator 15VDC Datablade/78xx.pdf 1 LM spændingsregulator 9VDC Datablade/78xx.pdf 1 LM spændingsregulator 5VDC Datablade/78xx.pdf 1 LM spændingsregulator 3.3VDC Datablade/LM1086.pdf 3 220nF kondensator 2 10uF elektrolytkondensator 1 LG2640 Grøn lysdiode Datablade/LG2640 diode.pdf 1 60 Ω modstand 1 køleplade til TO-220 hus Monteres på LM

94 KAPITEL 8. HARDWARE IMPLEMENTERING Disse komponenter monteres på veroboard som vist på Figur 8.4 i henhold til modulimplementering. Figur 8.4: Monteringsoversigt over PSU på veroboard. (Grå farver er på undersiden af boardet.) Dette modul sættes i microcontrollerboardet med det viste stik til højre på Figur 8.4. Stikket beskrives i Appendiks D. 8.4 Serielmodul Serielmodulet implementeres med følgende komponenter: 2 Maxim max3232 Datablade/MAX3232.pdf nF kondensator 1 LG2640 Grøn lysdiode Datablade/LG2640 diode.pdf Ω modstand Dette er forbundet i figur

95 KAPITEL 8. HARDWARE IMPLEMENTERING Figur 8.5: Implementering af serielmodul Diagrammet i figur 8.5 skal nu overføres til veroboard. Her er der monteret interface stik. Interfacet er gennemgået i appendiks D. Implementering på veroboard ses af figur 8.6. Der monteres også moduldetector samt lysdiode iht. modulimplementeringen. 87

96 KAPITEL 8. HARDWARE IMPLEMENTERING Figur 8.6: Monteringsoversigt over serielmodul på veroboard. 8.5 Trigger Triggeren implementeres med følgende komponenter: k Ω modstand 1 BC547B transistor Datablade/BC547.pdf 1 Finder V relæ Datablade/19RELAY 36.pdf µf 25V kondensator diode Dette er forbundet i figur

97 KAPITEL 8. HARDWARE IMPLEMENTERING Figur 8.7: diagram over triggerkreds Diagrammet i figur 8.7 skal nu overføres til veroboard. På denne udgave er der monteret interface stikket. Interfacet er gennemgået i appendiks D. Implementering på veroboard ses af figur 8.8. Figur 8.8: Monteringsoversigt over trigger på veroboard. 89

98 KAPITEL 8. HARDWARE IMPLEMENTERING 8.6 Modul integration - Støj filtrering Efter de enkelte moduler er blevet implementeret, skal de nu integreres. Det vælges at samle alle moduler på MSP boardet, og overføre alle signaler i ét fladkabel hen til platformen. Dette giver mulighed for at forbinde hele robotten, med et stik. Det er derved også muligt at placere driverkredsene og MSP430 eren et andet fysisk sted end platformen. Beskrivelse af fladkablet er angivet i appendiks E. Der opstår dog nogle problemer når mange ledninger med forskellige signaler bliver placeret tæt ved hinanden; der forekommer støj. Det er derfor vigtigt at indsætte nogle filtre eller kondensatorer, der kan filtrere denne uønskede støj. Det er især encodersignalet, som det er kritisk at der ikke er så meget støj på, og der skal derfor undersøges om denne støj er forstyrrende, og hvis den er, hvordan det filtreres væk. I de nedenstående afsnit vil støjfiltrering derfor blive gennemgået Encoder signaler Ved måling af encodersignalet efter integration, viste der sig støj på signalet. Se figur 8.9. Støjen resulterede i en masse vilkårlige interrupts og systemet ville ikke kunne fungere. Der kunne sågar opstå støj på et encodersignal, som ikke var aktivt, som således genererede interrupts. Støjen skulle derfor fjernes. Ved forsøg med forskellige kondensatore, faldt valget på en 10 nf kondensator. Denne kunne fjerne det uønskede støj, og efterlade et pænt encodersignal. Se figur Der er derfor monteret en 10 nf kondensator i enden af MainCable før det når MSP en. Figur 8.9: Støj på encodersignal uden kondensator 90

99 KAPITEL 8. HARDWARE IMPLEMENTERING Figur 8.10: Støj på encodersignal med 10nF kondensator Touch Sensor For at MSP en kan få et tydeligt signal fra touch sensoren, når denne bliver aktiveret, sættes der en pull down modstand på mellem output signalet og ground. Pull down modstanden gør, at når kontakten ikke sluttes, trækkes udgangen til ground, og dermed ikke står og svinger. Dette sikrer et tydeligt signal på udgangen. Implementeringen af dette er vist i figur Figur 8.11: Touch Sensor med pull down modstand på udgangen En pull-down modstand fungerer ved, at den kan fjerne den støj, som er i systemet, når kontakten er afbrudt. Det gøres ved at indsætte en modstand, som går til jord. Når kontakten er brudt løber der ingen strøm, men der kan stadigvæk være noget spænding i form af støj, men hvis der er indsat en modstand, som går til jord, og der ingen strøm løber i systemet, skal spændingsfaldet over modstanden være 0, og derfor skal spændingen være den samme på begge sider af modstanden. I figur 8.11 er R2 en pull down modstand, som gør at der ikke er støj i systemet, når kontakten er afbrudt. 8.7 Hardware overblik Figur 8.12 viser et overblik over hardwaren, som den er implementeret rent fysisk. 91

100 KAPITEL 8. HARDWARE IMPLEMENTERING Figur 8.12: Overblik over hardware Figur 8.13 viser hvordan de enkelte drivere er placeret på MSP boardet. Figur 8.13: Overblik over hardware på MSP board. 1: MSP430F149. 2: Motordriver. 3: Serielmodul. 4: Main Cable. 5: Trigger. 6: PSU. 7: Ekstern strømforsyning. 8: USB. Med alle hardwaremodulerne implementeret, kan der nu udføres test på alle modulerne. 92

101 Kapitel 9 Hardware Test I dette kapitel vil hardwaren fra kapitel 8 blive testet for om de opfylder de krav, som er blevet stillet til dem i kapitel 4. Testene vil blive opstillet i appendix J til O, og der vil blive taget de vigtigste information op i rapporten, sådan at det fremgår fra afsnittene i det kapitel om hardwaren er godkendt eller ikke godkendt. 9.1 Test af motordriver I dette afsnit vil testen af motordriveren blive gennemgået. Testene med input og forventet output er opstillet i appendiks I Test af motordriver. I afsnit I i appendiks I er resultaterne fra testen af motordriveren dokumenteret. Som det fremgår af tabelerne I.8, I.9, I.10, I.11 og I.12, er motordriveren testet og har bestået alle testene. Konklusion Motordrivermodulet er hermed godkendt og fungere som det skal. 9.2 Test af Power Supply Unit I det følgende testes om PSU en kan levere de ønskede spændinger ved de givne belastninger. Disse er listet i tabel

102 KAPITEL 9. HARDWARE TEST Ben nr. Ønsket output Målt output 1 24V - 24mA 23.8V - 250mA - Godkendt 3 9V mA 8.8V - 500mA - Godkendt* 5 5V - 246mA 4.8V - 240mA - Godkendt** 6 3V3-24mA 3.27V - 32mA - Godkendt Tabel 9.1: Resultat af PSU test. * = Det høje strømkrav på 1000mA er sat for at kunne levere en kontinuerlig strøm, som motorerne trækker ved kontinuerlig belastning på 15Ncm[18]. En simpel test har vist at NXT motorerne maksimalt trækker 640mA totalt set, hvilket kun sker momentant. Dette er dog testet ved en hastighed, der ikke benyttes under drift. Drifthastigheden er noget lavere. Derfor godkendt. ** = Kravet er sat ud fra absolut maksimum ratings. Normal driftsbetingelser er noget lavere og derfor godkendt. Konklusion PSU en er godkendt i test med få bemærkninger. Størst bekymring er belastningen af 9V forsyningen. Dette vil dog ikke blive noget problem, da der er en indbygget reguleringssløjfe i systemet: Hvis 9V regulatoren overbelastes af motorerne lukker den ned for udgangsspændingen, der er indgangsspænding til 5V regulatoren. Denne lukker så også ned, så der ikke kommer forsyning til motordriver logikken, der styrer H-broen, hvilket lukker ned for motorerne, så det stopper for belastningen af 9V forsyningen. Systemet kan derved genoprette sig selv, og da MSP en kører på sin egen strømforsyning, vil systemet fortsætte som intet var hændt. 9.3 Test af serielmodul I dette afsnit vil serielmodulet blive testet. Testene med input og forventet output er opstillet i appendiks K. Serielmodulet blev testet ved at sende nogle forskellige inputs ind, og have et forventet output og på den måde undersøge om det forventede output stemmer overens med det reele output. Som nævnt ovenfor er tabellen opstillet i appendiks K tabel K.1 og K.2. Af tabel 9.2 og 9.3 ses et uddrag af testen. CMOS/TTL Seriel Godkendt:, ikke godkendt: Ben 2 Ben 12 Ben 4 Ben 13 Ben 6 Ben 16 Tabel 9.2: Test af seriel driver - Uddrag 1 Seriel CMOS/TTL Godkendt:, ikke godkendt: Ben 11 Ben 1 Ben 14 Ben 3 Ben 15 Ben 5 Tabel 9.3: Test af seriel driver - Uddrag 2 Konklusion Serielmodulet er hermed godkendt og fungere som den skal. 94

103 KAPITEL 9. HARDWARE TEST 9.4 Test af triggerdriver I dette afsnit vil triggerdriveren blive testet. Testene med input og forventet output er opstillet i appendiks L. Triggerdriveren vil blive testet efter testopstilling, som kan ses i appendix L.1. Der vil i denne opstilling blive sendt nogle forudbestemt spændninger ind, og på den måde oplade kondensatoren på triggerdriver, og igen aflade kondensatoren og få hammeren til at slå i spolen. Som det fremgår af tabel L.2 var en 100 % succes. Der blev ligeledes lavet nogle målinger på op- og afladningstiderne, som kan ses i figur L.2, hvor det kan ses at opladningstiden blev 268 ms og afladningstiden blev 609 ms. Disse målte tider stemmer udemærket overens med de udregnede tider fra afsnit Konklusion godkendt. Triggerdriveren er hermed godkendt og fungere som den skal, da samtlige test blev 95

104 Kapitel 10 Software Design I dette kapitel vil software design for systemets moduler blive gennemgået. Dette omfatter algoritmer, matematiske beregninger og valg af metoder. Yderligere bliver der brugt Unified Modeling Language (UML)[19], som er et meget anvendt standardiseret modelleringssprog inden for softwareudvikling. UML indeholder en række grafiske notationsteknikker til at skabe abstrakte modeller af specifikke systemer Bestemmelser fra hardware I denne sektion vil bestemmelser fra hardware designet, som er nødvendige for software designet, blive specificeret. Motor A er defineret som motoren der roterer kanontårnet Motor B er defineret som motoren der bevæger kanonløbet Gearing A er gearingen for motor A til kanontårnet er 4 63 Gearing B er gearingen for motor B til løbet er 1 9 Portforbindelser på alle portforbindelser til MSP en er defineret i appendiks F Sensor A er tryksensoren til rotations grænse Sensor B er tryksensoren til løbets grænse Retning på motorer er defineret til, at 0 = frem, 1 = tilbage. Se figur

105 KAPITEL 10. SOFTWARE DESIGN Figur 10.1: NXT motor - Retnings defination 10.2 Motorregulering [20][21][22] Da der nu er fastsat en hardware måde at styre motoren, samt få feedback, skal der nu bestemmes en metode til at regulere motorerne på i softwaren. Når man arbejder med hardware er der mange variabler, som skal tages højde for, såsom støj, belastning etc. Der skal derfor laves en dynamisk regulering, som kan tage højde for og justere for disse variabler. Der ønskes en hurtig og præcis justering af positionen. Hvis der sættes fuld spænding på motoren, og den kører indtil den når sin ønskede position, og derefter afbryder strømmen, ville den overskyde sit mål pga. forsinkelser, og moment opbygget i platformen. Der skal derfor være en regulering, der tilpasser hastigheden, sådan at positionen nåes præcist og hurtigt. Der ønskes derfor en positionsregulering ved begge motorer, og da belastningen på motorerne varierer konstant, ønskes der også en hastighedsregulering. Der ønskes altså en kaskade koblet regulering, med en indre hastighedsregulering. Dette kan illustreres som: Figur 10.2: Motorregulering af position og hastighed Reguleringstyper En regulering fungerer ved at et system konstant overvåges, og reagerer ud fra afvigelsen fra det forventede. Et godt eksempel er vandstanden på et vandværk. Vandværket vil gerne opnå vandhøjde på f.eks. 1 meter, men med varierende forbrug fra husstande koblet til vandværket, er det ikke muligt at have en konstant tilførsel af vand. Tilførslen skal derfor reguleres ud fra den aktuelle vandstand, og den ønskede. I den følgende forklaring benyttes dette eksempel på vandstand for at forklare forskellige reguleringstyper. Alle nedenstående eksempler benytter samme overføringsfunktion i simuleringen, samt samme stepfunktion. 97

106 KAPITEL 10. SOFTWARE DESIGN Reguleringen opdeles i 3 dele: Proportional, integral og differential regulering. Disse kan kombineres efter ønske, alt efter hvilket system der skal reguleres på. Disse kombinationer kaldes PI-, PD- og PID regulering. En proportional regulering fungerer ved at se på størrelsen af fejlen e, og gange denne med en faktor K p for at foretage en ændring. Det vil sige, at hvis vandstanden f.eks. er 0.1 meter under det ønskede, ændres vandtilførslen f.eks. 0.3 m 3 /s. Problemet er, at der kan opstå steady-state fejl, hvor vandstanden aldrig når den ønskede. Der er altså et offset fra den egentlige vandstand og den ønskede. En sådan regulering kan ses i figur u(t) = K p e(t) (10.1) Hvor e(t) = Afvigelse mellem det aktuelle og det ønskede K p = Proportional reguleringskonstant Figur 10.3: Eksempel på P-regulator En proportional-integral regulering er en udvidelse af P-regulatoren. I-reguleringen er et integral led, som opsummerer fejlen over tid. Det vil sige at, hvis der opstår steady-state i off-settet, vil fejlsummen blive ved med at stige i I-leddet, og på den måde regulere sig ind til det ønskede. u(t) = K p e(t) + K p K i t 0 e(τ)dτ (10.2) 98

107 KAPITEL 10. SOFTWARE DESIGN Hvor e(t) = Afvigelse mellem det aktuelle og det ønskede K p = Proportional reguleringskonstant K i = Integrale led reguleringskonstant t = Tidsvariabel Figur 10.4: Eksempel på PI-regulator En proportional-differential regulering er en udvidelse af P-regulatoren. D-leddet står for differential delen i reguleringen. Denne del kan stå for hurtige reguleringskorrigeringer, og er god til at dæmpe oversving. de(t) u(t) = K p e(t) + K p K d (10.3) dt Hvor e(t) = Afvigelse mellem det aktuelle og det ønskede K p = Proportional reguleringskonstant K d = Differentiale led reguleringskonstant t = Tidsvariabel 99

108 KAPITEL 10. SOFTWARE DESIGN Figur 10.5: Eksempel på PD-regulator En PID-regulering er en samling af alle led. Denne inkluderer derved både opsummering af fejl over tid, men også hurtig reaktion på ændringer. Stabiliteten kan derfor være bedre end i en PI-regulator, dog kan den være følsom overfor støj. u(t) = K p e(t) + K p K i t 0 e(τ)dτ + K p K d de(t) dt (10.4) Hvor e(t) = Afvigelse mellem det aktuelle og det ønskede K p = Proportional reguleringskonstant K d = Differentiale led reguleringskonstant K i = Integrale led reguleringskonstant t = Tidsvariabel 100

109 KAPITEL 10. SOFTWARE DESIGN Figur 10.6: Eksempel på PID-regulator Valg af regulering Da der er varierende modstand i platformen, og der kan ske pludselig ændring i modstanden, benyttes der en PID-regulator til positionsregulering. Denne regulator regulerer spændingen på motoren ud fra fejlen, samt den korrigerer for vedvarende fejl via I-leddet. Vedvarende fejl kan opstå i rotationen hvis den er tæt på målet, og den ønskede hastighed nærmer sig nul. Evt. pludselige ændringer varetages af D-ledet. Til hastighedsregulatoren vælges en P-regulator med dødområde på motoren fjernet. Det er på den måde ikke nødvendig at have et I- eller D-led i hastighedsregulatoren CR - Cannon rotation Kanon rotationen vil som specificeret i afsnit 10.2 benytte en PID-regulering. Dette giver mulighed for stor præcision samt der vil automatisk blive implementeret en bremsefunktion der aftager hastigheden gradvist. Dette medfører også, at platformen ikke ryster sig selv i stykker med pludselig opbremsninger. Følgende problemstillinger skal vurderes i CR: 1. Platformen har et rotationsområde på grader. Den har altså nogle yderpunkter pga. ledninger til tårnet, og software skal sikre, at den bliver inden for dette område 2. Omsætning af PID-regulator fra matematik til software Interval rotation Som nævnt ovenstående i punkt 1, skal der findes en løsning på, at der er en begrænsning på rotationen. For at løse det skal man kende en udgangsposition på tårnet, da det ellers ikke vil være muligt at vide om ledningen vil blive for kort i forhold til, hvad der ønskes roteret. Det løses ved at montere en touch 101

110 KAPITEL 10. SOFTWARE DESIGN sensor i yderpunktet for ledningens rækkevidde. Så for at kende en udgangsposition, skal tårnet rotere med uret indtil touch sensoren aktiveres. Ved at gøre dette ved man at tårnet kan rotere 360 grader mod uret. Når der så kendes en nuværende position, og der kommer et input om hvor meget tårnet ønskes roteret, skal algoritmen 10.7 gennemløbes, hvor der bestemmes, hvilken retningen tårnet skal rotere for at komme til den ønskede position. Retningen mod uret bestemmes til at være negative grader, og med uret er positive grader. Figur 10.7: Flowchart over interval rotation PID-regulator Den matematiske model for en PID-regulator benytter kontinuert tid. Men i software er det kun muligt at regne i diskret tid. Dette betyder at reguleringen kun kan ske med en fast samplerate. I figur 10.8 er vist en simpel regulator der er implementeret i software, og benytter diskret tid. For at opnå en tilnærmelse af den kontinuerte beskrivelse, skal samplingen vælges ift. systemet. Figur 10.8: Diskret tid regulering eksempel. [23] 102

111 KAPITEL 10. SOFTWARE DESIGN Hvor P = Ønsket position u = Spænding til motor [V] y = Aktuel position e = Fejl mellem y og P k = Sample index T s = Sampletid Valg af samplingstid NXT-motorernes encodere returnerer et firkantssignal med 1 grads opløsning, og softwaren skal reagere på hver kant i dette signal. En oplagt mulighed for hastighedsreguleringen er derfor, at lave en sample for hvert encodersignal. Dette vil dog resultere i, at reguleringen vil blive event baseret, og derved vil samplingstiden variere alt efter hastigheden på motoren. Det betyder kort sagt, at hastighedsreguleringen styrer sin egen samplingstid når den styrer hastigheden, hvilket er svært at analysere matematisk. Event baseret regulering vil dog godt kunne benyttes i dette projekt, da der ikke laves en dybdegående analyse og simulering af reguleringen. Ved et større teoretisk projekt ville denne implementeringsform skabe en del problemer, men dette ses bort fra i nærværende projekt. Den eventbaserede regulering har desværre den ulempe, at der ikke foregår nogen sampling hvis motoren holder stille. Der skal derfor findes en metode til at kick-starte motoren, før reguleringen sætter ind. Det betyder desuden også, at hvis motoren fuldstændig blokeres, vil motorreguleringen ikke kunne komme igang igen. Til positionsstyringen skal der benyttes en intervaltimer, der med en given frekvens kan regulere positionen. Efter Nyquist Shannon sampling theorem[7], bør samplingen være dobbelt så høj som frekvensresponsen på motoren, men da denne ikke kendes, kan der kun gættes på en værdi. Da motoren kan rotere med 14 rad/s, vil en samplingsfrekvens på 32 Hz (som Watchdog timeren simpelt kan opsættes til) give minimum 2 samples pr. radian. Denne samplingsfrekvens vil være acceptabel til positions reguleringen. Da det er en kaskadekoblet regulering som benyttes, er det vigtigt at den indre regulering kører oftere end den ydre, hastighedsreguleringen skal derfor køre med > 32 Hz. Motoren kan minimum køre 1,5 rad/s (se figur 11.2), ved hvilken der er den laveste samplerate. Ved denne hastighed sampler hastighedsreguleringen ved 1,5 180 π 85deg/s = 85Hz. Hastighedsreguleringen sampler altså minimum 2,65 gange hurtigere end positionsreguleringen. Konklusion: Positionsreguleringen skal sample ved 32 Hz, og hastighedsreguleringen skal være event baseret, og sample på hvert encodersignal. Dette giver minimum en samplerate på 85 Hz. Diskret implementering De matematiske ligninger, som defineret i afsnit 10.2, skal nu omsættes til en numerisk løsning, altså skiftes fra kontinuert til diskret tid. Proportional-leddet kræver ikke nogen større omskrivning da denne ikke afhænger af tidligere samples. Den bibeholdes derfor som den er. K p e(t) Integral-leddet afhænger af alle tidligere samples. I kontinuert tid fungerer den ved at tage arealet under en kurve, men i diskret tid er der ikke mulighed for at kende samtlige målepunkter. Dette implementeres istedet ved at tage målingen, og dividere med tiden siden sidste sidste måling. På denne måde fås arealet under kurven tilnærmet via søjler. Integral-leddet skal derfor omskrives til en summering af alle tidligere fejl, divideret med sampletiden. K p 1 K i h t e(τ) (10.5) τ=0 103

112 KAPITEL 10. SOFTWARE DESIGN eller omsat til nemmere implementering: e i = e i + e(t) (10.6) K p ei K i h Differential-leddet beskriver ændringen i kurven. En numerisk metode til at gøre dette på, er vha. Backward euler metoden[24]. Denne metode bygger på at trække sidste måling fra den nuværende, og dividere med tiden siden sidste måling. På denne måde fåes en hældning mellem de to punkter. Der vil derefter blive indsat to samples i koordinatsystemet, som derved beskriver ændringen. Differential-leddet kan derfor skrives som: y y(t) y(t h) (t) h K p y (t) K d (10.7) 10.4 CA - Cannon angle Indstillingen af løbet vil også benytte en PID-regulator til at indstille sig præcist, hvilket er essentielt for robottens præcision. Designet af regulatoren vil blive udført som angivet i afsnit Følgende problemstillinger skal vurderes i dette afsnit: 1. Initialisering af løbet 2. Læsning og beregning af afstand til mål 3. Beregning af vinkel på løbet ift. afstand) Initialisering af løbet For at initialisere løbet benyttes en touchsensor, som er placeret sådan, at når løbet kører ned ad og løbet når vandret position (0 grader), aktiveres touchsensoren og løbet stoppes. Dette gøres som det første for løbet ved opstart, og på den måde kendes udgangspositionen for løbet altid Brug af afstandssensor I det følgende beskrives, hvordan afstandssensorernes analoge output oversættes til en afstandsværdi Tolkning af output fra afstandssensor Da den analoge værdi ikke er proportional med den målte afstand, skal der bestemmes et tilnærmet udtryk for den målte afstand, som en funktion af output-værdien fra den analoge til digitale converter. Da output kan variere mellem de enkelte sensorer i en produktion, blev der foretaget en test med nærværende afstandssensorer, hvor output blev registreret fra 5 målinger ved varierende afstande, fra 5cm til 500cm med 5 cm interval. Første testserie ses af figur M.2 og figur M.3 i appendiks M, hvilket viser en stor spredning i output fra hver afstandssensor. For at tage højde for denne spredning i outputtet, 104

113 KAPITEL 10. SOFTWARE DESIGN blev der implementeret en algoritme på microcontrolleren, der tog 5 målinger, sorterede den højeste og laveste værdi fra, hvorefter gennemsnittet blev taget af de resterende - se figur Bemærk dog, at i testserien blev værdien ikke transformeret til en afstand, her var det gennemsnits ADC 1 værdien der blev returneret. For at udjævne testresultaterne yderligere, blev algoritmen, i figur 10.10, også implementeret i et matlab script til behandling af de resulterende data. De 25 målinger blev således sorteret og beregnet, til én værdi for den specifikke afstand. Resultatet af denne videre behandling af data ses på figur Turkise punkter er fratrukket et offset på den mindste x-værdi i datasættet. Dette muliggør en bedre approksimation af funktionsudtrykkene, som datapunkterne følger. Grafen for disse approksimationer ses på figur Figur 10.9: Plot fra curvefitting session i Matlab [CD Afstandssensor/curvefitting1.cfit] baseret på følgende Matlab script [CD Afstandssensor/rfdata.m]. RL = Langdistance afstandssensor, RS = kortdistance afstandssensor Disse to approksimationer resulterer i følgende funktionsudtryk. S 1 = f(a 1 ) = e ( a1) e ( a1) + 15 (10.8) S 2 = f(a 2 ) = 1870 a (10.9) Hvor S 1 = Afstand målt med lille sensor a 1 = ADC output fra lille sensor S 2 = Afstand målt med stor sensor a 2 = ADC output fra stor sensor 1 Analog til Digital Converter 105

114 KAPITEL 10. SOFTWARE DESIGN Ligning 10.8 og 10.9 skal implementeres i en funktion på microcontrolleren, der henter værdier fra ADC en og returnere den målte afstand i cm. Der skal hentes 5 værdier fra hver afstandssensor med et interval, der passer med, at der er lavet en ny måling i den pågældende afstandssensor. Som det ses af figur M.3 og M.2, er der en stor spredning på disse målinger, og der skal derfor sorteres i de 5 målte værdier. Dette gøres ved at fjerne den største og mindst værdi, hvorefter gennemsnittet tages af de resterende, se figur Denne værdi omsættes til cm vha. ligning 10.8 for værdien fra den lille sensor, og ligning 10.9 for den store sensor. Figur 10.10: Algoritme til sortering og gennemsnitstagning af indkomne ADC-værdier Afstandsalgoritme Da der bruges 2 afstandssensorer med et overlap i intervallet 1m-1.5m, skal der konstrueres en algoritme, der vælger den sensor der resulterer i den rigtige afstand. På figur ses de to afstandssensorer i samme graf. 106

115 KAPITEL 10. SOFTWARE DESIGN Figur 10.11: Samlet output fra RS og RL (skitse). Område A er det område algoritmen skal tage særlig højde for. I området 1.5-3V ved den store sensor vil ligning 10.9 altid give over 100cm, men faktisk kan målet være placeret under 100cm fra sensoren. Dette betyder, at den lille afstandssensor skal bruges til at vurdere, hvilken afstand der er den rigtige. Dette er designet i Den lille sensor har samme problem med afstande under 20 cm, men det antages at der aldrig vil være noget placeret under 20cm fra sensorne. Figur 10.12: Algoritme til aflæsning og vurdering af måledata. RL: Rangesensor Long. RS: Rangesensor Short 107

116 KAPITEL 10. SOFTWARE DESIGN Denne algoritme kan nu implementeres i programkode til microcontrolleren Beregning af vinkel Beregningen af hvilken vinkel kanonløbet skal indstilles i, for at kuglen rammer i den ønskede afstand, gøres ved brug af ligningen for x max opstillet i afsnit 5.3: ( ) V 0 cos(α) V 0 sin(α) + V 02 sin(α) g y 0 (α) x max = x 0 (α) + (10.10) g Hvor: ( ( ) ) yplatform x 0 (α) = x platform2 + y platform2 cos arctan + α Hvor: y 0 (α) = ( x platform2 + y platform2 sin arctan x platform = 11.2cm y platform = 3.3cm b platform = 15.3cm x platform ( yplatform x platform ) + α ) + b platform For at udregningen kan laves skal α isoleres. Men da ligningen er for kompliceret til at α kunne udledes analytisk, laves der istedet en opslagstabel. Hvert opslag er for afstanden ved hver tiltvinkel af kanonløbet. Den tilhørende søgefunktion tager derved en afstand som input, og leverer en vinkel til kanonløbet som output. Denne tabel gør, at der ikke skal foretages en større beregning ved hver afstand, og gør derved præcisionen af beregningen mere præcis samt der opnåes højere hastighed. Opslagstabellen vælges at blive implementeret som et binært søgetræ, hvor roden er den midterste afstand, højrebørn er større afstande, og venstrebørn er mindre afstande. Valget er faldet på et binært søgetræ, for at implementere en mere kompliceret algoritme på MSP en, i dette projekt. Pga. præcisionen på afstandssensoren, er det valgt at lave en opdeling af afstandene på 5cm. Den mindste afstand sættes til 1.3m og den største til 3.95m, og dermed er den midterste afstand 2.6m. Dette er illustreret i figur 10.13, hvor hver node i træet er afstanden (øverste kasse), og output af hver node er vinklen (α/nederste kasse) som kanonløbet skal indstilles i, for at skyde den tilhørende afstand. Når der skal søges i træet bruges en præcision på 2.5cm, hvilket betyder at afstanden der søges efter må afvige med 2.5cm. 108

117 KAPITEL 10. SOFTWARE DESIGN Figur 10.13: Binært søgetræ (toppen) Kompleksiteten af søgningen i søgetræet bestemmes ved store o notation (O(f(n))). Antallet af noder i træet er 54. Kompleksiteten, og derved højden, af træet kan nu beregnes ved at tage log 2 (n) hvor n=54. log 2 (54) = 5.75 (10.11) Højden af træet er dermed i værste tilfælde 6. Kompleksiteten er dermed: O(n) = log 2 (n) (10.12) 10.5 CP - Communication protocol I dette afsnit vil kommunikationsprotokollen mellem robotten og kontrolstationen blive gennemgået. Da det er muligt at definere alt den data, der kan overføres mellem kontrolstationen og robotten, er det muligt at holde protokoldatastørrelsen nede på 5 byte. Strukturen for dataen bliver som vist i figur Figur 10.14: Kommunikations protocol struktur Ved at benytte ét felt som kommando, giver det basis for 255 forskellige kommandoer. Dette kan forøges til 511, hvis der yderligere skelnes mellem afsendere. 255 kommandoer er dog mere end nok til dette projekt, så der skelnes ikke mellem afsendere. For at gøre protokollen simpel, bliver Cmd et bogstav startende fra A og løbende opad. Protokollen kan nu defineres i tabel Under retning betyder K = kontrolstation, og R = robot. Funktion Retning Cmd Data Beskrivelse Roter X grader K R A Integer (0-720) Roterer tårnet (X-360) grader 109

118 KAPITEL 10. SOFTWARE DESIGN Roteret X grader K R B - Fortæller tårnet er færdig med roterer Start rotation i X retning K R C Integer (0-1) Starter rotation i X retning. (0 = højre, 1 = venstre) Stop rotation K R D - Stopper rotation Rotationsgrænse nået K R E - Tårnet er nået til sin rotationsgrænse Indstil løb i X grader K R F Integer (0-50) Indstiller tårnet i X grader Løb nået X grader K R G - Løbet er færdig med at indstille sig Start løb indstil i X retning K R H Integer (0-1) Starter bevægelse af løbet i X retning. (1 = op, 0 = ned) Stop løb indstilling K R I - Stopper løbets bevægelse Løb nået grænse K R J - Løbet nået sin grænse Hent afstand K R K Integer(0-2) Hent afstandssensordata. (0 = vælg afstandssensor automatisk, 1 = kort distance, 2 = lang distance) Returner afstand K R L Integer(30-550) Returner afstand fra Cmd K. Enhed: cm. Indstil løb automatisk K R M Integer(0-1) Indstil løbet vha. afstandssensor. Hvis data: 1 = skyd, 0 = kun indstilling Løb indstillet K R N - Løbet er indstillet automatisk Affyr projektil K R O - Affyrer projektil Projektil affyret K R P - Projektilet er affyret Send statusbesked K R Q Integer(0-99) Forhåndsaftalt beskedid som kan udveksles Reset system K R R - Resetter motorerne til 0 Tabel 10.1: Kommunikations protocol Se appendiks G for beskrivelse af statusbeskeder til Cmd = Q Kontrolsignaler Til kommunikationsprotokollen skal der benyttes 4 kontrolsignaler: RS-232 navn Status Betydning DTR (Data terminal ready) DSR (Data set ready) RTS (Request to send) CTS (Clear to send) H L H L H L H L Kontrolstation oppe og køre, klar til at kommunikere Kontrolstation ikke klar Robot oppe og klar til at kommunikere Robot ikke klar Resetter softwaren på robotten. Fungere som MSP reset knap Ingen handling Robot klar til at modtage data. Robot ikke klar til at modtage data. Så længe denne er sat, vil kontrolstationen opfatte robotten som værende optaget Tabel 10.2: Betydning af kontrolsignaler 110

119 KAPITEL 10. SOFTWARE DESIGN Ved hjælp af disse kontrolsignaler, er det muligt at sætte MSP en i low-power mode indtil DTR sættes høj. På den måde spares strøm indtil kontrolstationen går online. Desuden giver det mulighed for en nødstop via RTS flaget. Ved at koble denne direkte til RST/NMI benet på MSP en, vil RST = H resulterer i MSP en resettes. Det er altså muligt at genstarte systemet fra kontrolstationen hvis softwaren på robotten har sat sig fast. CTS flaget kan bruges som status indikator for robotten, og sikre der ikke sendes kommandoer den ikke er klar til at håndtere. I nærværende system, hvor handlinger skal ske i det øjeblik de forespørges, er der ikke behov for en buffer af kommandoer. Det betyder at hvis robotten er optaget, skal evt. kommandoer ikke sendes når der er overskud. De skal istedet ignoreres Opsætning af forbindelse Forbindelsen mellem robot og kontrolstationen vil blive opsat til at benytte opsætningen defineret i tabel Opsætning Værdi Baudrate baud Parity None Databit 8 Stop bit 1 Tabel 10.3: Opsætning af seriel forbindelse Software på MSP Til implementering af CP softwaren på MSP en benyttes den færdige kode til implementering af scanf og printf skrevet af Mortin Bisgaard til kurset DAP. Dette kode skriver og læser fra/til UART ens buffere ved implementering af putchar() og getchar() som benyttes af standard biblioteket. Der vil derfor ikke blive lagt mere vægt på udviklingen af seriel softwaren på MSP en Softwaren på kontrolstationen På kontrolstationen skal der udvikles en klasse, som kan skrive og læse til en seriel port. Softwaren skal udvikles som en klasse, da det på denne måde ville kunne styre flere serielle porte, ved at oprette flere instance af denne klasse. Klassen designes som følger på figur Der skal desuden varetages, at når klassen nedlægges, genskabes de oprindelig indstillinger på porten, for ikke at skabe problemer for andre programmer på computeren. 111

120 KAPITEL 10. SOFTWARE DESIGN Figur 10.15: Seriel classe struktur 10.6 VTM - Visual target marking VTM modulet skal kunne markere og følge et objekt i et webcamfeed. Dette er målsøgningsprogrammelet i systemet, og er således den del, der skal styre de andre moduler når systemet kører i Adjust & shoot mode. Følgende problemstillinger skal vurderes: 1. Hvorledes modulet kan parallelafvikles med andre moduler. Dette varetages dog kun under implementering. 2. Hvordan markeres og følges et mål når tårnet rotere. Dette er altså object tracking. 3. Softwaren skal kunne beregne, hvor meget tårnet skal rotere for at pege på et markeret objekt Objekt tracking Til målsøgningen skal der bruges et object tracking system. Der benyttes i dette projekt nogle simple metoder, da computer vision er et stort område for sig. Objekt trackingen vil derfor benytte sig af simple metoder såsom gennemsnitsfarver, dimensioner og placering i billedet. Den måde et objekt bliver markeret, er ved at brugeren klikker med musen på det punkt i billedet objektet findes. Der skal derfor findes en metode, som kan finde omridset af objektet for på den måde, at lave nogle beregner på dimensioner og farver. Til dette er valgt at benytte en simpel edge detection teknik. Denne teknik går ud på at difference billedet i henholdsvis x og y retning, med udgangspunkt i det markeret punkt. En markant ændring i farve vil blive markeret som kant, og derved slut på objektet. Se figur på eksempel på differentiation af billede. 112

121 KAPITEL 10. SOFTWARE DESIGN Figur 10.16: Differentiering af billede For at gøre beregningen hurtigere, kan billedet omsættes fra et 3 kanals RGB billede til 1 kanal sort/hvid. Det er således kun én farvekanal der skal differentieres. Da brugeren markerer et vilkårligt punkt i objektet, er det vigtigt at denne edge-detection funktion, som vist i figur 10.16, går ud til minimum 4 sider fra markeringspunktet. Ved at gå i -x, x, -y og y retning, kan der findes en rektangel omkring objektet. Markeringen vil dog kun være tilnærmet, da algoritmen på denne måde kun kan markere rektangler, der har vandrette og lodrette sider. Ønskes et mere præcist omrids, skal der benyttes mere end 4 søgninger ud fra markeringspunktet. (a) Centreret markeringspunkt (b) Decentral markeringspunkt (c) Decentral markeringspunkt Figur 10.17: Forskellige markeringer med 4 retnings edge-detection. Alle er acceptable til formålet. I figur ses forskellige markeringer af et ovalt objekt. Det røde kryds markerer markeringspunktet foretaget af brugeren. Som det ses bliver objektet markeret tilfredsstillende i alle tilfælde. Der ønskes dog, at objektet bliver optimal markeret som i figur (a), samt at objektet kan følges ved små bevægelser. Dette kan løses ved at finde centrum af den markerede boks, og bruge dette centrum til næste markeringsiteration i algoritmen. På denne måde vil algoritmen bevæge sig mod en optimal markering, samt den vil kunne følge små bevægelser. Ved større bevægelser skal der regnes på objektets bevægelser, og fremskrive markeringspunktet med dette data. Dette tages dog ikke med i dette projekt. Efter objektet (målet) er markeret, skal kanonen ramme det. Før den kan gøre dette, skal den rotere, så den peger på objektet. Dette gøres ved at finde den relative vinkel til objektet ift. kameraet, og rotere tårnet efter dette. Forudsat at rotationen er præcis, vil markeringspunktet kunne flyttes ind til midten 113

122 KAPITEL 10. SOFTWARE DESIGN af billedet i X koordinatet til næste søgning, og her vil objektet blive fundet igen. Hvis der sker en fejl under rotationen, skal der være en funktion, der kan finde objektet igen. Denne funktion er gennemgået i afsnit Den færdige algoritme for markeringen med rotation kan nu skitseres, og fremgår af figur Bemærk nogle funktioner i algoritmen først gennemgåes i følgende afsnit. Figur 10.18: Flowchart for VTM. Bemærk funktionen markeret med * bliver gennemgået i afsnit og ** i afsnit Rotation ift. markeret objekt For at kunne beregne, hvor mange grader kanontårnet skal rotere for at centrere objektet i målsøgningen, skal synsvinklen på kameraet bestemmes. Ved at kende synsvinklen, objekt position i billedet, samt størrelse på billedet, vil det være muligt at beregne hvor meget kanontårnet skal rotere. For at beregne synsvinklen, skal der kendes A og B i nedenstående figur 10.19, der er lavet ud fra en testopstilling af kameraet og en flade. 114

123 KAPITEL 10. SOFTWARE DESIGN Figur 10.19: Opstilling til udregning af vinkel Synsvinkel (V) kan nu bestemmes V = 2 arctan ( 1 ) 2 A B (10.13) V = 0.861[rad] = Hvor V = Synsvinkel [radianer] A = Bredden af synsfeltet = 71.5 cm B = Afstand fra linse til flade = 77.8 cm Da synsvinklen nu kendes i grader og afstanden i centimeter ønskes det omregnet til pixels. Dette gøres vha. at tage et udsnit af figur 10.19, hvor fladen kendes i centimeter og pixel, og ud fra denne information udregnes afstanden a og vinklen V/2 i pixels. Det gøres ved at opstille en ligning for afstanden til den flade kameraet ser. Figur 10.20: Udregning af vinkel i pixel 115

124 KAPITEL 10. SOFTWARE DESIGN a = P t 2 tan ( ) (10.14) V 2 Hvor P t = Total antal pixel i bredde = 640px a = Afstand til flade Da a afhænger af synsvinklen og pixelbredden, bliver dette en konstant. Det er således ligegyldigt at der opstår forskellige dybder i billedet. Vinklen til objektet kan nu beregnes ud fra figur ( ) P R = arctan a (10.15) Hvor P = Pixel fra centrum af billede R = Relativ vinkel til objekt Udtrykket for a indsættes nu i R, og udtrykket for R reduceres R = arctan P P t arctan B tan@ A B! 1 C A ( ) A P = arctan P t B (10.16) Ved illustration af ligningen med R som variabel i pixel, fåes en kurve der nærmer sig en linæer funktion. For at spare beregningstid i programmet, ønskes denne linæere tilnærmelse bestemt. En ligning for en linæer funktion kan udledes, da udgangspunkt er i origo, ved at tage Y/X i et punkt, og derved få hældning. Ved at vælge dette punkt i det område der antages at blive brugt mest i ALC, vil man få en funktion som ligger tæt på virkeligheden. Dette punkt vælges til P = 250. Altså 250 pixels fra centrum af billedet. ( arctan Udtrykt som en lineær funktion bliver det 250 ) A 250 P t B = (10.17) f(x) = x (10.18) 116

125 KAPITEL 10. SOFTWARE DESIGN Hvor x = Afstand fra centrum af billede [px] Figur 10.21: Lineær tilnærmelse af ligning [CD VTM/CRgraf.m] Af figur ses, at den lineære tilnærmelse følger udtrykket for R tilfredsstillende. Det ønskes dog at vide, hvilken afvigelse det egentligt vil resultere i. Denne afvigelse bør være under 1 grad af krav K3.1. e = R f(x) (10.19) Hvor e = Afvigelse mellem R og f(x) [rad] 117

126 KAPITEL 10. SOFTWARE DESIGN Figur 10.22: Afvigelse mellem ligning og [CD VTM/CRgraf.m] Af figur ses at worst-case afvigelse vil være 0.01 radian (0.63 grader). Dette er altså en acceptabel tilnærmelse. Det ønskes dog også bestemt hvad average-case afvigelsen er. Dette gøres ved at tage gennemsnit afvigelsen i intervallet pixel. e a = R f(x) 320 e a = (10.20) Hvor e a = Gennemsnitlig afvigelse [rad] Den gennemsnitslige afvigelse er altså kun radianer (0.229 grader). Den lineære tilnærmelse er derfor acceptabel. Ligning bruges altså som udtryk for relativ vinkel til objekt i webcamfeed Robusthed af algoritme Algoritmen, forklaret i afsnit , forudsætter, at tårnet rotere meget præcist hver gang, for at den ikke mister markeringen af objektet. Som gennemgået i afsnit vil der også blive brugt en tilnærmet funktion for rotationen, og derved endnu en upræcished. Det er derfor vigtigt, at algoritmen gøres mere robust og kan finde ud af at håndtere situationer hvor rotationen over- eller underroterer. En måde dette kunne designes på, var i tilfælde af at objektet ikke blev fundet det sted det burde være, søges hele billedet igennem, for et objekt af samme dimension og farve. Dette vil dog ikke være optimal, da det kan antages, at objektet vil være placeret omkring X-midteraksen og meget tæt på det kendte Y-koordinat (da tårnet kun roterer i X retning ift. billedet). Det vil derfor være muligt at optimere søgningen til at søge inde for et rektangel omkring det punkt, hvor objektet burde være. For at optimere søgningen 118

127 KAPITEL 10. SOFTWARE DESIGN yderligere, og for ikke at skulle søge samtlige koordinater igennem, kan dette rektangel inddeles i et grid af punkter, hvorfra der søges efter objektet. Disse punkter defineres ud fra størrelsen på det oprindelige objekt, målt da brugeren foretog markeringen. Ved at placere disse punkter med denne afstand imellem sig, vil der være stor chance for, at objektet findes igen, uden at samtlige punkter skal bearbejdes. Se figur Hvis objektet findes igen i dette grid, skal punktet der fandt objektet nu kopieres over som værende det nye markeringspunkt, og den oprindelige algoritme kan tage over igen. Denne algoritmen vil fremover blive henvist til som VTM trytofind algoritmen. Figur 10.23: Algoritme to forbedring af robusthed af VTM algoritme (VTM trytofind) Algoritme 2 Pseudokode for VTM trytofind gridstart.x searchp oint.x searchp oint.startw idth 3; gridstart.y searchp oint.y searchp oint.startheight 2; gridend.x searchp oint.x + searchp oint.startw idth 3; gridend.y searchp oint.y + searchp oint.startheight 2; for x = gridstart.x to gridend.x step searchp oint.startw idth/2 do for y = gridstart.y to gridend.y step searchp oint.startheight/2 do tmpm arkp oint = markobject(x,y) if abs(tmpm arkp oint.width searchp oint.width) < threshold then if abs(tmpm arkp oint.height searchp oint.height) < threshold then if abs(tmpm arkp oint.startcolor searchp oint.startcolor) < threshold2 then searchp oint = tmpm arkp oint return true end if end if end if end for end for return false 119

128 KAPITEL 10. SOFTWARE DESIGN 10.7 GUI - Graphical user interface Den grafiske brugerflade er den brugerflade brugeren interagerer med. Designet og udviklingen af denne ligger dog uden for projektets overordnet mål, og vil derfor ikke blive gennemgået i rapporten. Det skal dog nævnes, at GUI en vil blive implementeret på Qt Framework, som er et c++ framework der nemt giver mulighed for tråde, tastatur interaktion, timere osv. Det bliver altså på denne måde muligt, at få en række standardfunktioner ind, som er nødvendige for udførslen af projektet, men som ikke er relevant at lave selv. Dokumentationen af Qt Framework kan findes på GUI en vil ikke blive dokumenteret yderligere. For mere information, se implementeringen Kildekode/ 10.8 Modul detection De enkelte hardwaremoduler har en moduldetektor funktion, som gør det muligt for softwaren, at se om modulet er tilgængeligt. I systemet findes der 4 moduldetektorer: Motordriver, serialdriver, triggerdriver og forbindelse til platformen. Da fejlbeskeder bliver sendt til kontrolstationen via seriel forbindelse, er det ikke muligt at sende en fejlbesked om serialdriveren når det er denne, der sender beskeden. Det vil derfor blive lavet således, at lysdioden på MSP430 boardet blinker med 5Hz, for at symbolisere denne fejl. Hvis de andre moduler ikke er tilgængelige vil der blive sendt en fejlbesked, som specificeret i appendiks G. Systemet skal således også være i stand til at reagere på at modulet ikke findes, og lade være med at starte enheder som dette modul bruger. 120

129 Kapitel 11 Software Implementering I dette kapitel vil væsentlige dele fra software implementeringen bliver gennemgået. Af pladsmæssige årsager er det ikke alle dele, der vil blive gennemgået her. Den resterende implementering kan ses af den doxygen genererede dokumentation, som er at finde på Doc/ Generel opbygning af software på microcontroller Som angivet under systemdesign, se figur 6.5, skal softwaren på MSP en polle på den serielle forbindelse, imens den venter på kommandoer fra kontrolstationen. Inden dette kan ske, skal der dog ske en initialisering af diverse hardware funktioner. Dette sker som det første i main() funktionen og bliver kun udført én gang. Initialiseringen omfatter: Stoppe watchdog timeren Aktivere XT2 clock source Opsætte timera Opsætning af encoder input porte Modul detection af motordriver, serieldriver, maincable og trigger. Opsætte timerb (forudsat motordriver er tilgængelig) Opsætte seriel forbindelse (forudsat serieldriver er tilgængelig) Opbygge binære søgetræ i heapen Aktiver generelle interrupt Initialisere motorer Efter initialiseringsfasen, køres polle funktionen. Denne implementeres via en switch, hvor de enkelte kommandoer er angivet som cases heri. I kodeeksempel 11.1 ses starten på polle funktionen i main(). 121

130 KAPITEL 11. SOFTWARE IMPLEMENTERING while ( 1 ) { s c a n f ( %s, command ) ; switch ( command [ 0 ] ) { 5 case A : / / Automated r o t a t i o n c a n c e l R o t a t e ( ) ; command [ 1 ] = 4 8 ; command [ 2 ] = 4 8 ; command [ 3 ] = 4 8 ; 10 d a t a V a r 1 = command [1] 100+ command [2] 10+ command [ 3 ] ; d a t a V a r 1 = 360; r o t a t e ( d a t a V a r 1 ) ; 15 break ; case C : / / Manual r o t a t i o n c a n c e l R o t a t e ( ) ; i f ( command [ 1 ] == 0x31 ) { 20 s e t S p e e d ( 1, 12, FORWARD) ; } e l s e { s e t S p e e d ( 1, 12, BACKWARD) ; }.... Kodeeksempel 11.1: Main funktion på MSP Omdannelse fra ASCII til integer Som det ses af kodeeksempel 11.1 linje 7-9, trækkes der 48 fra den modtaget kommando på index 1-3. Dette er fordi den data der overføres over CP, overføres i ASCII. For at konvertere ASCII tal til integer tal, skal der trækkes 48 fra, da tallet 0 har plads 48 i ASCII tabellen. Se For at samle vinklen til en variabel efterfølgende, ganges første index med 100 og næste med 10. Disse tal ligges sammen, og den endelige vinkel findes. Iht. CP er vinklen tillagt et offset på 360, så det fratrækkes på linje 12. datavar1 kan nu variere mellem -360 og 360 grader Motorregulering Dette afsnit omhandler generelle vurderinger for implementeringen af motorreguleringen. Det behandlede gælder altså både for CR og CA Hardware-software grænseflade af motorkontrol Ideen i motorreguleringen er, at den skal fungere som grænseflade mellem hardware og software. Reguleringen skal altså varetage fysiske variabler, som kan opstå under bevægelsen, og afskære resten af softwaren for disse uregelmæssigheder. Begge motorer styres af PWM signaler generet af timerb, som er opsat som følger. En mere tekstuel beskrivelse kan ses under afsnit / / Uddrag a f pwm. c void PWM init ( f l o a t f r e q ) { TBCCR0= ( 1 / f r e q ) (XT2 / 8. 0 ) ; / / load p e r i o d r e g i s t e r / / l o a d s i n d e p e n d e n t l y, 16 b i t c o u n t e r / / SMCLK, d i v. by 8, up mode / / Timer B i n t e r r u p t e n a b l e TBIE TBCTL = TBSSEL1 + ID1 + ID0 + MC0 + TBIE ; 122

131 KAPITEL 11. SOFTWARE IMPLEMENTERING TBCCR1=0x0 ; / / load d u t y c y c l e r e g i s t e r TBCCR2=0x0 ; } P4SEL =0 x06 ; / / s e l e c t P4. 1 and P4. 2 f o r PWM o u t p u t P4DIR =0 x06 ; / / s e l e c t P4. 1 and P4. 2 f o r o u t p u t m o t o r I n i t ( ) ; / / Uddrag a f m o t o r c o n t r o l. c void m o t o r I n i t ( ) { / / S e t P4. 3 P6 up as o u t p u t ( d i r and e n a b l e ) and s e t a l l high P4DIR = BIT3+BIT4+BIT5+BIT6 ; P4OUT = BIT3+BIT4+BIT5+BIT6 ; / / S e t P2. 0 and P2. 1 as i n p u t f o r c o n t a c t A and B. Enable i n t e r r u p t on low t o high P2DIR &= BIT0+BIT1 ; P2IE = BIT0+BIT1 ; P2IES &= BIT0+BIT1 ; / / S e t Watchdog t i m e r t o t i m e r i n t e r v a l w i t h ACLK c l o c k (32768 Hz ) and d i v i d e r 512 > 64 Hz WDTCTL = WDTPW+WDTTMSEL+WDTSSEL+WDTIS1 ; / / Enable watchdog i n t e r r u p t IE1 = WDTIE ; } Kodeeksempel 11.2: Opsætning af timerb I kodeeksempel 11.2 ses hvordan timerb samt kontrolsignaler til motorerne er opsat. Den egentlige kontrol af motoren sker via portene P4.3-P4.6 og dutycyclen, som styres via TBCCR1 og 2. Denne kontrol sker i motorset() funktionen. Prototypen til denne er vist i kodeeksempel Der er altså mulighed for at styre retning og hastighed. void m o t o r Set ( i n t motor, f l o a t duty, D i r e c t i o n d i r ) ; Kodeeksempel 11.3: Prototype til motorset() Beregne hastighed på motor TimerA bruges til at behandle encodersignalet. Capture/compare 1 og 2 er opsat til at reagere på interrupt på både falling og rising edge på signalet. Det betyder at der kommer et interrupt med en opløsning på én grad. TimerA og dens capture/compare enheder er opsat som vist i kodeeksempel / / Uddrag a f t i mera. c TACTL = TASSEL0 + ID0 + MC1 + TAIE ; / / S e t t i mera t o ACLK, S e t i n p u t d i v i d e r t o 2, S e t mode = c o n t i n o u n e s, e n a b l e i n t e r r u p t TACCR0 = 0xFFFF ; / / Uddrag a f encoder. c TACCTL1 = CM1 + CM0 + CAP + CCIE ; TACCTL2 = CM1 + CM0 + CAP + CCIE ; Kodeeksempel 11.4: Opsætning af timera til encodersignaler TimerA er opsat til at bruge ACLK, som har en frekvens på Hz. Det er denne frekvens der skal bruges til at beregne hastigheden af motoren. Som det ses af figur 8.10 af afsnit 8.6.1, har firkantsignalet ikke en dutycycle på 50%. Hastigheden kan derved ikke findes mellem en rising og en falling edge, men skal være mellem to rising eller to falling edge. Det betyder at tiden skal divideres med 2, for at få et clocksignal for én grad. Det betyder dog også at sampletiden halveres, men da minimum sampleraten stadig holder sig over positionssampleraten, er det acceptabelt. Antal clock signaler mellem hvert 123

132 KAPITEL 11. SOFTWARE IMPLEMENTERING encodersignal, findes ved at tage forskellen på det forrige encodersignal, og det som har trigget den aktuelle interrupt. Det ønskes nu at omsætte disse clock signaler til en hastighed for motoren. I følgende udledning er antal clock signaler angivet som CLK. v = 1 CLK ACLK π 180 = π ACLK 180 CLK (11.1) Hvor v = Hastighed [rad/s] ACLK = Clock frekvens for ACLK [Hz] CLK = Antal clock siden sidste encoder signal I ligning 11.1 omregnes frekvensen til grad/s, og herefter omregnes til rad/s. Da ACLK er kendt (32768 Hz), kan udtrykket nu forkortes, så der indgår så få regneoperationer som muligt. Dette er for at øge hastigheden for udregningen på MSP en. ACLK divideres med 2, da timera er opsat til inputdivider = 2. k er en konstant, og kan udregnes til. ACLK = 32768Hz 2 π ACLK 180 CLK = 4096 π 45 k = CLK = k 1 CLK = v (11.2) Ligning 11.2 kan nu bruges til at omsætte clock signaler til hastigheden for motoren Implementering af PID og P regulator I dette afsnit ses den endelige implementering af positions- og hastighedsregulatoren. I kodeeksempel 11.5 ses positionsreguleringen, der kører med en frekvens på 32 Hz. Denne funktion sørger for at regulere den ønskede hastighed, som motoren skal køre med. Den skriver til en global variabel, som hastighedsregulatoren bruger som sit reference punkt. / / I n i t i a l i z e v a r i a b l e s f l o a t v ; i n t e, a n g l e ; 5 / / Get c u r r e n t a n g l e o f e n g i n e B a n g l e = g e t A n g l e ( 2 ) ; / / C a l c u l a t e d i f f e r e n c e between wanted and a c t u a l e = t i l t P o s D e s t 9 a n g l e ; / / I f e r r o r i s < 4. 5 s t o p t h e e n g i n e. To a c c o u n t f o r p l a y i n g e a r i n g i f ( e <= 4. 5 && e >= 4.5) { stopmotor ( 2 ) ; return ; } / / I f t h e motor i s r u n n i n g a t f u l l speed, t h e e n g i n e i s s a t u r a t e d. 15 i f ( t i l t S a t u r a t i o n == 0) t i l t I n t e g r a l += e ; 20 / / C a l c u l a t e v e l o c i t y w i t h PID r e g u l a t o r v = ( f l o a t ) (MB KP e ) +(MB KI ) t i l t I n t e g r a l +MB KD ( ) ( ( f l o a t ) ( angle AngleOld2 ) ) ; / / Check i f e n g i n e w i l l be s a t u r a t e d. 124

133 KAPITEL 11. SOFTWARE IMPLEMENTERING i f ( v > 14 v < 14) { t i l t S a t u r a t i o n = 1 ; } e l s e { 25 t i l t S a t u r a t i o n = 0 ; } motordestspeed [ 1 ] = v ; / / Save c u r r e n t a n g l e f o r n e x t sample 30 AngleOld2 = a n g l e ; Kodeeksempel 11.5: Positions regulering (CA) Integrator anti-windup På linje 15 og 16 i kodeeksempel 11.5 udføres integrator anti-windup. Dette er for at sikre at integralleddet ikke stiger voldsomt, og når integralleddet så er nødvendig, har mulighed for at lave sine justeringer. Dette gøres ved at se hvornår motoren er mættet (saturated). Det kan ske at reguleringen ønsker motoren skal køre over sin maksimale hastighed, men da dette ikke er fysisk muligt, kører motoren istedet ved sin maksimale hastighed. I dette tilfælde opsummeres integralleddet ikke, da en kæmpe fejl (som er resultatet af den store hastighed), ville gøre integralledet ubrugeligt når motoren ikke længere er mættet. Det er altså kun når motoren kører under 14 rad/s integralledet summeres. På figur 11.1 er forsøgt illustreret hvornår anti-windup benyttes. (a) Med anti-windup (b) Uden anti-windup Figur 11.1: Skitse af anti-windup. Rød linje er mæthed af motoren, som funktion af fejlen. Blå linje er positionen af motoren. Grøn linje er integratorleddets størrelse. Sort linje er fejlen mellem det ønskede og det faktiske 125

134 KAPITEL 11. SOFTWARE IMPLEMENTERING Hastighedsregulering I kodeeksempel 11.6 ses implementering af hastighedsreguleringen. Denne regulering køres for hvert encodersignal, men den egentlige regulering bliver kun udført hver anden gang, pga. dutycyclen på encodersignalet ikke er 50%. / / Note : c u r D i r S c a l e i s 1 og 1 a c c o r d i n g t o d i r e c t i o n o f r o t a t i o n. / / Check i f motor i s r u n n i n g and o n l y r e g u l a t e e v e r y o t h e r t i m e i f ( regurun2 == 1 && motorrunning [ 1 ] == 1) { / / Save t h e c l o c k s s i n c e l a s t r e g u l a t i o n motorspeed [ 1 ]. speedold = motorspeed [ 1 ]. speed ; motorspeed [ 1 ]. speed = TACCR2 ; / / C a l c u l a t e c u r r e n t v e l o c i t y a c c o r d i n g t o f o r m u l a r i n r e p o r t / / M u l t i p l y by 100 f o r f i x p o i n t f l o a t f i x f l o a t u ; f l o a t tmp = / ( f l o a t ) ( ( motorspeed [ 1 ]. speed motorspeed [ 1 ]. speedold ) / 2 ) ; f l o a t c u r Vel = tmp / ; c u r Vel = c u r D i r S c a l e ; / / C a l c u l a t e how much d u t y c y c l e s h o u l d change f l o a t dutychange = MB HKP ( motordestspeed [1] c u r Vel ) ; / / Add t o c u r r e n c t d u t y c y c l e u = d u t y C y c l e [ 1 ] c u r D i r S c a l e +dutychange ; / / Send new d u t y c y c l e t o e n g i n e. i f ( u > 1) { m o t o r Set ( 2, 1,DUTY) ; } e l s e i f ( u < 1) { m o t o r Set ( 2, 1,DUTY) ; } e l s e { m o t o r Set ( 2, u,duty) ; } regurun2 = 0 ; } e l s e { regurun2 = 1 ; } Kodeeksempel 11.6: Hastighedsregulering (CA) 11.3 CR - Cannon rotation I dette afsnit vil implementeringen af CR blive gennemgået Interval rotation I det følgende afsnit ses den endelig implementering af algoritmen Interval rotation, som designet i afsnit I kode eksempel 11.7 ses hele algoritmen implementeret. void r o t a t e ( i n t newpos ) { / / R e s e t r o t a t i o n r e g u l a t i o n. r o t a t e I n t e g r a l = 0 ; / / Finds c u r r e n t p o s i t i o n o f tower by u s i n g g e t A n g l e. / / Angle i s m u l t i p l i e d by 1 / ( 4 / 6 3 ) t o a c c o u n t f o r g e a r i n g between e n g i n e and r o t a t i o n. i n t c u r r e n t P o s = ( i n t ) ( ( f l o a t ) ( g e t A n g l e ( 1 ) ( f l o a t ) ) ) ; i n t temp ; / / Finds a b s o l u t e d e s t i n a t i o n p o s i t i o n f o r tower a c c o r d i n g t o a l g o r i t m i n r e p o r t. 126

135 KAPITEL 11. SOFTWARE IMPLEMENTERING } i f (0 <= newpos+ c u r r e n t P o s && newpos+ c u r r e n t P o s <= 360) { r o t a t e P o s D e s t = newpos+ c u r r e n t P o s ; } e l s e { i f (360 < c u r r e n t P o s +newpos ) { temp = newpos 360; r o t a t e P o s D e s t = temp+ c u r r e n t P o s ; } e l s e i f (0 > c u r r e n t P o s +newpos ) { temp = newpos + 360; r o t a t e P o s D e s t = temp+ c u r r e n t P o s ; } } / / J u s t f o r k i c k s t a r t i n g t h e r e g u l a t i o n. s e t S p e e d ( 1, 3,FORWARD) ; Kodeeksempel 11.7: Interval rotations algoritme Funktionen venter på et input fra kommunikation. Det undersøges om inputtet er en gyldig handling, uden at der ændres på det. Hvis handlingen ikke er mulig uden ændringer, udregnes der er en vinkel, som gør det ønskede input muligt Bestemmelse af motor dødszone Da platformen yder en del modstand, er rotationen ikke linæer ift. spændingen over motoren. Dette giver en dødzone, hvor motoren ikke kan overvinde modstanden, og der altså ikke sker rotation. Det ønskes, at spænding og rotationshastigheden er linæer, så der skal laves en skalering af spændingen således at dette kan sikres. For at lave denne skalering skal der foretages en test af rotationen, og finde det punkt, hvor motoren netop kan overvinde modstanden i platformen. Testen er udfærdiget ved at alle dutycycle fra 1% til 100% afprøves og frekvensen på encodersignalet måles. Efterfølgende kan frekvensen omregnes til rad/s da 1 periode = 2 grader. Der blev foretaget målinger i samme interval i rotationen ved alle dutycycler for at sikre konsistens. Af CR/deadzone.csv ses resultatet af målingerne. Af figur 11.2 ses målingerne plottet i en graf. Det ses, at fra 30% dutycycle begynder platformen at rotere, og stiger tilnærmelsesvist linæert til sin tophastighed. Ved at skalere måledataen med u = 0.7 u fåes den grønne linje. Den røde linje er en polyfitted kurve af den grønne linje, og vil altså være en funktion for hastighed afhængig af dutycycle. 127

136 KAPITEL 11. SOFTWARE IMPLEMENTERING Figur 11.2: Dødzone målinger samt korrigering. [CD CR/resolvedeadzone.m] og [CD CR/deadzone.csv] Konklusion Dutycyclen skal skaleres med u = 0.7 u (11.3) for at fjerne dødzonen på rotationen Løsning på slør i gearene I rotationen opstår der en del slør pga. LEGOens udformning. Der er omkring 30 graders slør i gearene (på motorens side), hvilket betyder at belastningen på motoren i de 30 grader når der skiftes retning, ikke er linæer ift. når tårnet faktisk flytter sig. Det betyder, at der opstår svingninger frem og tilbage i slør området når reguleringen nærmer sig sit mål. For at kompensere for dette, vælges det at indbygge en tilladt fejlmargin i reguleringen. Denne vil være mindre end den ønskede præcision. Da tårnet skal have en præcision på 1 grad af krav K3.1, og da tårnet har en gearing på 4 63 = 15.75, vil den tilladte fejlmargin være < CA - Cannon angle I dette afsnit vil nogle af de væsentlige implementeringsdetaljer for CA blive gennemgået. Denne implementering knytter sig tæt op af motorreguleringens implementeringen, som er gennemgået i afsnit

137 KAPITEL 11. SOFTWARE IMPLEMENTERING Implementering af afstandssensor I det efterfølgende beskrives implementeringen af algoritmen, der er illustreret grafisk i figur Denne algoritmen søger at give systemet en mere konsistent aflæsning af afstanden til et mål, end det afstandssensorerne kan give. Afstandssensorernes output har vist sig - under test - at variere en hel del, se figur M.2 og M.3. Derfor benyttes omtalte algoritme til at sortere og udjævne de indkomne data Indhentning af analog værdi fra afstandssensor I kodeeksempel uddrag af funktionen void getrange() - vises hvorledes, der hentes 5 målinger fra afstandssensorerne og disse sættes ind på deres plads i arrayene val1[] og val2[]. 1 while ( x < 5) { 2 d e l a y ( 4 5 ) ; 3 4 ADC12CTL0 = ADC12SC ; / / s t a r t sampling 5 while (ADC12CTL1&0x01 ) ; / / c o n v e r s i o n i n p r o g r e s s 6 7 v a l 1 [ x ] = ADC12MEM0; / / g e t analog v a l u e from ADC r e g i s t e r => S h o r t range measurement 8 v a l 2 [ x ] = ADC12MEM1; / / g e t analog v a l u e from ADC r e g i s t e r => Long range measurement 9 10 i n s e r t ( x, val1, v a l 2 ) ; 11 x ++; 12 } Kodeeksempel 11.8: Konvertering af analoge værdier fra afstandssensorerne Først i denne while-løkke i linie 2 i kodeeksempel 11.8 ventes der 45ms for at være sikker på at der er lavet en ny måling i afstandssensorerne - se databladene Datablade/R302-GP2Y0A700K0F-2.pdf og Datablade/GP2Y0A02YK.pdf. ADC en er sat op til at konvertere en sekvens af input, hvilket der ventes på bliver overstået i linie 5 efter den er startet i linie 4. Linie 7 og 8 henter resultaterne fra de netop overståede konverteringer over i et array, hvor de bliver sat ind på bagerste plads, bestemt af variablen x. Til sidst bliver funktionen insert(x, val1, val2) kaldt for at sætte de nye værdier ind på deres rigtige plads i array ene val1[] og val2[]. Således bliver de 5 målinger sorteret i numerisk rækkefølge med den største værdi først Filtrering af målinger I det næste gennemgås indsættelsesalgoritmen, der sørger for at de hentede værdier fra afstandssensorerne bliver sorteret i numerisk rækkefølge med den største først med henblik på at filtrere i målingerne. 1 2 void i n s e r t ( i n t x, unsigned i n t v a l 1 [ ], unsigned i n t v a l 2 [ ] ) { 3 i n t i ; 4 unsigned i n t temp ; 5 6 f o r ( i = x ; i > 0 ; i ){ 7 8 i f ( v a l 1 [ i ] > v a l 1 [ i 1]){ 9 temp = v a l 1 [ i ] ; 10 v a l 1 [ i ] = v a l 1 [ i 1]; 11 v a l 1 [ i 1] = temp ; 12 } i f ( v a l 2 [ i ] > v a l 2 [ i 1]){ 129

138 KAPITEL 11. SOFTWARE IMPLEMENTERING 15 temp = v a l 2 [ i ] ; 16 v a l 2 [ i ] = v a l 2 [ i 1]; 17 v a l 2 [ i 1] = temp ; 18 } 19 } 20 } Kodeeksempel 11.9: Sortering af ADC-værdier i numerisk rækkefølge Kodeeksempel 11.9 modtager følgende parametre: int x Et heltal, der fortæller hvor mange værdier, der er i de arrays, der ønskes behandlet. unsigned int val1 Pointer til et array med værdier fra den lille afstandssensor. unsigned int val2 Pointer til et array med værdier fra den store afstandssensor. I linie 5 i kodeeksempel 11.9 initialiseret en for-løkke, der køres igennem så mange gange, der er elementer i de enkelte arrays. Der vil altid være lige mange elementer i de to arrays. I løkken startes der bagfra, hvor det nye element er sat ind og der testes om det er større end det element, der ligger lige foran. Er det det, byttes de om. Sådan køres begge arrays igennem 1 gang, hvilket resultere i et sorteret array, idet denne funktion kaldes hver gang, der er indsat 1 ny værdi i de pågældende arrays Omregning af ADC-værdi til cm Den sidste behandling af de indkomne ADC-værdier er at gennemsnittet tages af de 3 midterste værdier og resten smides væk. Hvorefter denne gennemsnitlige værdi omregnes til centimeter vha. funktionsudtrykkene i ligning 10.8 og 10.9 fra afsnit f o r ( i = 1 ; i < 4 ; i ++){ 2 ( r a n g e + 0) += v a l 1 [ i ] ; 3 ( r a n g e + 1) += v a l 2 [ i ] ; 4 } 5 6 ( r a n g e + 0) /= 3 ; 7 ( r a n g e + 1) /= 3 ; 8 9 unsigned i n t a l p h a 0 = ( r a n g e + 0) ; 10 unsigned i n t a l p h a 1 = ( r a n g e + 1) ; f l o a t temp = ( exp ( ( ( f l o a t ) a l p h a 0 ) ) exp ( ( ( f l o a t ) a l p h a 0 ) ) ) +15; ( r a n g e + 0) = ( unsigned i n t ) temp ; 15 ( r a n g e + 1) = (1870 pow ( ( double ) alpha1, ( double ) 0.133) 629.8) ; / / Add o f f s e t from cannon t o d i s t a n c e s e n s o r 18 ( r a n g e +0) += ; 19 ( r a n g e +1) += ; Kodeeksempel 11.10: Omregning af gennemsnitsværdi til cm Linierne 1 til 7 i kodeeksempel lægger gennemsnittet af de 3 midterste ADC-værdier over i det array, der benyttes som de gældende afstandsværdier i det efterfølgende. Værdien fra den lille afstandssensor i range[0] og værdien fra den store afstandssensor i range[1]. I linierne 12 og 15 benyttes funktionsudtrykkene i ligning 10.8 og 10.9 til omregning af ADC-værdien til gældende afstandsværdier i cm. Til slut tillægges et offset for at få den reelle afstand fra kuglens startpunkt til målet. Kuglen, der skal affyres, ligger 18.7 cm bag afstandssensoren. 130

139 KAPITEL 11. SOFTWARE IMPLEMENTERING Optimal afstandsværdi Efter at have brugt to afstandssensorer til at måle afstanden til målet skal der nu vurderes på de to målinger, idet systemet kun skal bruge 1 værdi. Dette gøres med en implementering af algoritmen illustreret på figur Idet de to afstandssensorer hver har et afstandsinterval, indenfor hvilket de giver den mest præcise måling, skal der vurderes hvilket resultat, der skal bruges af systemet. Dette implementeres med simple If-else sætninger, der kan ses i vedlagte doxygen output Doc/robot/index.html. Afstanden til det valgte mål er nu fundet og kan bruges af ALC Implementering af søgetræ (opslagstabel) Det binære søgetræ implementeres således, at det indlæses ved hver initialisering af MSP en. Søgetræet oprettes på den måde at der kun tilføjes noder til bunden af træet, og der kan altså ikke tilføjes noder højere oppe. Metoden der anvendes er Tree-Insert(T,z), som angivet i bogen Introduction To Algorithms [25]. Noderne bliver dog kun oprettet med pointere til de underliggende børn og ikke til overliggende forældre, da der ikke skal slettes eller ændres i træet når det først er oprettet. Men da dataen, som skal implementeres i træet, er listet efter den mindste først, stigende og den største til sidst, er det nødvendigt at sortere dem så de kommer til at stå rigtigt. Ellers ville noderne blive tilføjet i én lang række. I det tilfælde ville træet ikke være balanceret, og ville dermed ikke virke optimalt. Der ville istedet opnåes en kompleksitet på n, istedet for log 2 (n) et balanceret binært søgetræ har. Sorteringen er dog et arbejde, som kun skal udføres en gang inden koden implementeres, da det er de samme data der skal være på de samme pladser i søgetræet hver gang. Denne sortering foretages ved en simpel algoritme (se kodeeksempel 11.11): 1 f (A, s t a r t, s l u t ) { 2 n= s l u t s t a r t ; 3 f (A, s t a r t, ( n / 2 ) 1) ; 4 add (A( n / 2 ) ) ; 5 f (A, ( n / 2 ) +1, s l u t ) ; 6 } Kodeeksempel 11.11: Søgetræ opbygnings algoritme Denne algoritme sørger for, at den midterste afstand ligger først, derefter den midterste afstand af den nederste halvdel af afstandene, derefter den midterste afstand af den øverste halvdel af afstandene, osv.. Ved at sortere afstandene på denne måde, bliver søgetræet velbalanceret når dataen bliver hentet ind. Højden af træet bliver dermed 6, som, i værste tilfælde, er det største antal noder der skal søges igennem for at finde den ønskede node. Koden til at tilføje noder ses i kodeeksempel void addnode ( b s t r e e n o d e r o o t, f l o a t l e n g t h, i n t a n g l e ) { 2 b s t r e e n o d e node = NULL; 3 node = ( b s t r e e n o d e ) m a l l o c ( s i z e o f ( b s t r e e n o d e ) ) ; 4 ( node ). l e n g t h = l e n g t h ; 5 ( node ). a n g l e = a n g l e ; 6 ( node ). l e f t = NULL; 7 ( node ). r i g h t = NULL; 8 i n s e r t N o d e ( r o o t, node ) ; 9 } Kodeeksempel 11.12: addnode Når der bliver tilføjet en node bliver der oprettet to pointere; en til højrebarnet og en til venstrebarnet. Disse pointere sættes til NULL for insert og søge algoritmen kan fungere. 131

140 KAPITEL 11. SOFTWARE IMPLEMENTERING Når der skal søges i søgetræet bruges funktionen int searchtree(float), som tager en afstand i decimaltal som input, og giver den tilhørende vinkel i heltal som output. I tilfælde af, at afstanden ikke er inden for kanonens rækkevidde, altså at afstanden ikke er angivet i søgetræet, returneres -1 (se kodeeksempler og 11.14). Det skal dog ikke være den eksakte afstand, der findes i søgetræet, idet afstandene er angivet i 5cm intervaller, og den søgte afstand må derfor afvige med 2.5cm. 1 i n t s e a r c h t r e e ( f l o a t q ) { 2 i n t a l p h a = 1; 3 b s t r e e n o d e node = NULL; 4 node = s e a r c h ( r o o t, q ) ; 5 i f ( node!= NULL) { 6 a l p h a = ( node ). a n g l e ; 7 } e l s e { 8 a l p h a = 1; 9 } 10 return ( a l p h a ) ; 11 } Kodeeksempel 11.13: Searchtree 1 b s t r e e n o d e s e a r c h ( b s t r e e n o d e x, f l o a t q ) { 2 i f ( x == NULL ( q >= ( x ). l e n g t h STEPPRECISION && q < ( x ). l e n g t h + STEPPRECISION ) ) { 3 return x ; 4 } 5 i f ( q < ( x ). l e n g t h ) { 6 return s e a r c h ( l e f t ( x ), q ) ; 7 } e l s e { 8 return s e a r c h ( r i g h t ( x ), q ) ; 9 } 10 } Kodeeksempel 11.14: searchtree underfunktion 11.5 VTM - Visual Target Marking Visual target marking implementeres på kontrolstationen, og bygges op i OOP (objekt orienteret programmering). Nedenstående uddrag af kode er derfor implementeret i en klasse kaldet cvisueltargetmarking. Den fuldstændige klasse opbygning kan ses på figur Nedenstående kode er implementeringen af den højre del af figur Det er altså dette kode, som finder kanterne på det markerede objekt og returnere dimensionen og placering af objektet til hovedalgoritmen i VTM. 1 /... / 2 void c V i s u e l T a r g e t M a r k i n g : : markobject ( s t r u c t MarkedObjectCoor o b j e c t, I p l I m a g e img ) { 3 4 / / Get t h e t h r e s h o l d from HUI 5 i n t t h r e s h o l d = MainWindow : : GUI >g e t T h r e s h o l d V a l u e ( ) ; 6 / / Find t h e p o i n t s f o r x, x, y, y edges 7 CvPoint XL = f i n d E d g e ( img, c v P o i n t ( 1,0), o b j e c t >s e a r c h P o i n t, t h r e s h o l d ) ; 8 CvPoint XR = f i n d E d g e ( img, c v P o i n t ( 1, 0 ), o b j e c t >s e a r c h P o i n t, t h r e s h o l d ) ; 9 CvPoint YT = f i n d E d g e ( img, c v P o i n t (0, 1), o b j e c t >s e a r c h P o i n t, t h r e s h o l d ) ; 10 CvPoint YB = f i n d E d g e ( img, c v P o i n t ( 0, 1 ), o b j e c t >s e a r c h P o i n t, t h r e s h o l d ) ; / / C a l c u l a t e and save t h e p o i n t and d i m e n s i o n o f t h e o b j e c t 13 o b j e c t >p o i n t. x = XL. x ; 14 o b j e c t >p o i n t. y = YT. y ; 15 o b j e c t >h e i g h t = YB. y YT. y ; 16 o b j e c t >width = XR. x XL. x ; 132

141 KAPITEL 11. SOFTWARE IMPLEMENTERING } 19 /... / 20 CvPoint c V i s u e l T a r g e t M a r k i n g : : f i n d E d g e ( I p l I m a g e img, CvPoint d i r e c t i o n, CvPoint s t a r t P o i n t, i n t t h r e s h o l d ) { 21 / / I n i t i a l i s e 2 c o l o r o b j e c t s 22 C v S c a l a r s ; 23 C v S c a l a r s2 ; 24 / / check i f s t a r t p o i n t i s i n s i d e image c o n t a i n e r, i f i t i s, g e t t h e c o l o r o f t h e s t a r t P o i n t 25 i f ( s t a r t P o i n t. x > 0 && s t a r t P o i n t. x < ( img ) >width && s t a r t P o i n t. y > 0 && s t a r t P o i n t. y < ( img ) >h e i g h t ) { 26 s2=cvget2d ( img, s t a r t P o i n t. y, s t a r t P o i n t. x ) ; 27 } / / Run t h r u t h e image u n t i l i t reached t h e b o rder o f t h e image 30 while ( s t a r t P o i n t. x > 1 && s t a r t P o i n t. y > 1 && s t a r t P o i n t. x < ( img ) >width 1 && s t a r t P o i n t. y < ( img ) >h e i g h t 1) { 31 / / Move t h e s t a r t p o i n t i n d i r e c t i o n 32 s t a r t P o i n t. x += d i r e c t i o n. x ; 33 s t a r t P o i n t. y += d i r e c t i o n. y ; 34 / / Get t h e c o l o r o f t h i s new p o i n t 35 s=cvget2d ( img, s t a r t P o i n t. y, s t a r t P o i n t. x ) ; 36 / / I f t h e d i f f e r e n c e o f c o l o r i n n e w p o i n t and s t a r t p o i n t i s over t h r e s h o l d, break t h e w h i l e 37 i f ( abs ( s. v a l [0] s2. v a l [ 0 ] ) > t h r e s h o l d ) { 38 break ; 39 } 40 } 41 return s t a r t P o i n t ; 42 } Kodeeksempel 11.15: Edge detection (classe: cvisueltargetmarking) 11.6 GUI - Graphical User Interface I dette afsnit vil GUI en kort blive gennemgået. GUI en er opbygget i Qt Creators grafiske brugerinterface. 133

142 KAPITEL 11. SOFTWARE IMPLEMENTERING Figur 11.3: GUI skærmbillede I følgende liste vil GUI ens funktioner bliver gennemgået. Nedenstående numre henviser til de røde numre i figur Shoot knappen har samme funktion som Enter tasten, den sender signal til robotten om at skyde 2. Ved mode er det muligt at vælge om kanonen skal skyde så snart den har indstillet sig eller om brugeren manuelt skal trykke Shoot 3. Reset knappen resetter robotten, og tilten og rotationen i nulpunkterne 4. Threshold er indstillingen for VTM. Det er denne værdi farveintensiteten skal overskride før en kant markeres i billedet. Kan bruges til at kalibrere VTM modulet 5. Denne fortæller vinklen på løbet. Det er en direkte aflæsning af skydebaren (8). 6. Denne fortæller afstanden til objektet sidst der blev foretaget en måling. Markeres Pol range, vil systemet i jævne intervaller aflæse afstanden og opdaterer i dette felt. Ved tryk på K opdateres afstanden. 7. I systembeskeder vil beskeder fra robotten komme frem. Nyeste nederst. 8. Denne skyder bruges til manuelt at indstille løbet i en ønsket vinkel. Når skyderen trækkes med musen vises den valgte vinkel i (4). Når musen slippes, sendes vinklen til robotten 134

143 KAPITEL 11. SOFTWARE IMPLEMENTERING 9. Denne skyder bruges til manuel rotation af tårnet. Det er muligt at vælge mellem -360 til 360 grader. Denne aktiveres ved at trykke på tasten T 10. (a) I dette område vil webcam feedet, samt resultatet af VTM modulet, bliver vist. (b) viser beskeden, som vises hvis webcamet ikke er tilgængeligt. 11. I menubaren er der mulighed for at lukke programmet (under file) og mulighed for at se information om hvem der har lavet programmet (About). 12. Denne lampe indikerer om robotten er (a) available (grøn) eller (b) busy (rød). 13. Denne meddelse vises midt på GUI en hvis MSP en ikke er tilgængelig. 14. Denne meddelse vises hvis nødstop funktionen aktiveres. Følgende taster kan anvendes i interfacet: R Reset motorer til position 0 Q Software reset. Denne knap sætter kontrolsignalet RTS lav, og trækker derved ben 58 (Reset) på M- SP en lav. Den genererer altså en system reset, og på denne måde er det muligt at resette MSP en samt implementere et nødstop. T Send rotation position K Mål afstand manuel og vis i GUI ESC Nødstop. Denne funktion holder ben 58 (Reset) på MSP en lav indtil den bliver sluppet med tastetryk på Q. Ved klik på ESC stopper ALT software eksekvering på MSP en og alt stopper. M Automatisk justering af løbet ift. målet. ENTER Affyr kanonen 11.7 Perifiel opsætning I dette afsnit gennemgåes de perifere enheder, som benyttes af ALC på robotten, samt deres opsætning. 135

144 KAPITEL 11. SOFTWARE IMPLEMENTERING Enhed Benyttes til Opsætning TimerA Timer A (TACCR1 og TACCR2) Der benyttes ACLK clock signal med en benyttes til encodersignalerne og divider på 2. Count mode er continuous og bruges derved til at måle hastighed på motorerne. interrupt enabled. Denne indstilling giver en periodisk interrupt på 0,25 Hz. Det er dog ikke dette interrupt som er ønsket, men at kende tiden mellem 2 encodersignaler, TimerB Watchdog timer ADC12 TimerB benyttes til at generere PWM signal til motor A og motor B. TBC- CR0 bruges til at angive frekvensen på signalet, og TBCCR1 og TBCCR2 er henholdvis dutycycle for motor A og motor B. Watchdog timeren bruges til en periodisk interrupt til positionsreguleringen. ADC en bruges til at behandle inputtet fra afstandssensorerne. USART0 USART0 benyttes til den serielle forbindelse til kontrolstationen. derfor kan frekvensen sættes relativ lav. Der benyttes SMCLK clock signal med en divider på 8. Count mode er up, og tæller derved op til TBCCR0 og starter forfra. Interrupt enabled. TBCCR1 og TBCCR2 opsættes til compare mode med toogle/set output mode. Interrupt enabled. Opsættes som timerinterval i stedet for watchdog mode. Benytter ACLK clock signal med en clock divider på 512, giver en periodisk interrupt på 64 Hz. Opsættes til Multiple sample and conversion og reference generator slåes fra. Der benyttes Sample-and-hold pulse-mode og den interne clock signal på ADC en benyttes med en clock divider på 8. Der benyttes conversion mode Sequence-ofchannels, for at ADC en sampler én gang på hver afstandssensor hver gang Start conversion er flipped. USART0 opsættes til ikke at bruge paritets tjek, 8 databit og 1 stopbit. Opsættes til at bruge baudrate med SMCLK clock signalet som input. Der benyttes ikke modulation, da kan opnåes uden SM- CLK bruges. Transmit og receive enables. P3.4 og P3.5 opsættes til at benytte sin perifere enhed og P3.4 sættes som udgang. P3.4 er Tx. Interrupt enables på Rx Tabel 11.1: Opsætning af perifereenheder 11.8 Klasse/funktionsliste I figur 11.4 ses en grafisk opstilling af funktionerne i ALC på robotdelen, opdelt efter hvilken c-fil de er placeret i. Den fuldstænding beskrivelse af hver funktion er gjort i kildekoden, som kan findes på Kildekode/robot/. Se desuden doxygen dokumentation af koden Doc/kontrolstation/index.html 136

145 KAPITEL 11. SOFTWARE IMPLEMENTERING Figur 11.4: Funktions diagram I figur 11.5 ses en grafisk opstilling af klasserne, som er implementeret på kontrolstationen. 137

146 KAPITEL 11. SOFTWARE IMPLEMENTERING Figur 11.5: Klasse diagram Motor kontrol funktioner Størstedelen af softwaren på MSP en omhandler styring og regulering af motorerne. I dette afsnit vil de forskellige styringsfunktioner bliver uddybet, og deres indbyrdes sammenhæng blive redegjort for. Interfacet til motorstyringen ligger flere steder, alt efter hvilke dele af reguleringen, der ønskes at bruge. Det er muligt at køre udelukkende på dutycycle, udelukkende på hastighed, eller med positionsregulering, hvor hastighedsreguleringen benyttes som en indre sløjfe. I nedenstående tabel gennemgåes interface funktionerne. Ved nogle interface findes alias funktioner. Forskellen er her om det styrer tilten eller rotationen. 138

147 KAPITEL 11. SOFTWARE IMPLEMENTERING Funktionsnavn Beskrivelse Afhængig af rotate(); tilt(); Disse funktioner bruges som interface til at placere motoren i en bestemt position benyttende setspeed(); motorset(); både positions- og hastighedsreguleringen setspeed(); Denne funktion bruges til at aktivere hastighedsreguleringen motorset(); til at køre med en bestemt hastighed. Benyttes dette interface slåes positionsreguleringen fra. Denne funktion bruges til manuel kontrol af robotten. motorset(); Denne funktion er den funktion der ligger - nærmest hardware. Dette interface giver mulighed for at styre spændingen på motoren, hvor altså begge reguleringer er slået fra. Denne giver ligeledes også mulighed for at stoppe motoren. Dog vil dette ikke have effekt hvis en regulering kører, da denne bare ville tage over med det samme igen. cancelrotate(); Disse funktioner bruges til at stoppe positionsreguleringen. - canceltilt(); De modsvarer altså rotate(); og tilt();. stopmotor(); Dette interfaces bruges til at stoppe hastighedsreguleringen. - Den modsvarer altså setspeed(); Tabel 11.2: Motor kontrol funktioner. Funktioner skrevet med kursiv er funktioner, som ikke direkte bliver kaldt, men deres interface i form af variabler benyttes Af tabel 11.2 ses det, at der findes mange forskellige måder, at styre motorerne på robotten på. Det vigtige i styringen er, at der benyttes det modsvarende interface til at stoppe motoren ift. det, der blev brugt til at starte den med. 139

148 Kapitel 12 Software Test I dette afsnit vil enkelte test af softwaren blive dokumenteret. Af tidsmæssige årsager er det ikke alle test af software i projektet der vil blive dokumenteret. De dele som bliver dokumenteret i dette afsnit er test af motorregulering, test af interval rotation, og test af hardwarens påvirkning på software Test af motorregulering Denne test vil dokumentere at motorreguleringen fungerer som designet i afsnit Der monteres en gradcirkel på platformen, således at det kan aflæses fysisk, hvor langt tårnet roterer. I testen vil tårnet blive sat til at rotere nogle forskellige gradtal, hvor succeskriteriet er, at tårnet stopper ved det angivne gradtal, og ikke coaster. For at testen skal leve op til kravene fra afsnit , skal tårnet stoppe indenfor 1 grad af det angivne gradtal. I tabel 12.1 er der opstillet en række scenarier, hvor tårnet skal dreje i x antal grader, og derefter stoppe. I nogle tilfælde skal tårnet også rotere frem og tilbage. Ved start af hver test skal tårnet indstilles i nærheden af nulpunktet. Det er ikke vitalt at den står præcist på nulpunktet ved start, idet gradtallet tårnet skal dreje er relativt i forhold til startpunktet for testen. Gradtal tårnet skal rotere Startpunkt Gradtal tårnet Afvigelse Godkendt/ikke stopper på godkendt Ikke godkendt Ikke godkendt Ikke godkendt Ikke godkendt Ikke godkendt Ikke godkendt Ikke godkendt Ikke godkendt 300, og undervejs skal der ydes modstand på tårnets rotation, uden at den hakker over Ikke godkendt 140

149 KAPITEL 12. SOFTWARE TEST Der tilføjes en vægt på 500 gram på kanontårnet, og der roteres Godkendt Tabel 12.1: Test af motorregulering Af tabel 12.1 fremgår det at det kun er en af testene der har en afvigelse på under 1 grad. Forklaringen på de andre afvigelser, er at der er noget slør i gearingen og i NXT motoren. Den afvigelse der er i testene er dermed acceptabel. Hvis afvigelsen skulle fjernes, skulle der bruges en anden slags tandhjul og motor. Konklusion Det konkluderes dermed at motorreguleringen består testen, dog med en note om, at den ikke lever helt op til alle krave fra afsnit pga. slør. Det er dog værd at bemærke at afvigelsen kun er på 2 grader i mange af tilfældende Test af intervalrotation I dette afsnit vil der blive opstillet og udført en test af intervalrotationsalgoritmen, som er blevet implementeret i afsnit Testtabellen er bygget op omkring 7 input for startposition, hvor langt kanontårnet skal rotere og i hvilken retning, angivet med + og. De 7 input er valgt igennem whitebox testprincippet, og sikre alle dele af algortimen afprøves. Nr. Start Rotation Forventet rotation Forventet ny Faktisk Resultat pos. [ ] cmd [ ] [ ] pos. [ ] ny pos. [ ] Godkendt Godkendt Godkendt Godkendt Godkendt Godkendt Godkendt Tabel 12.2: Test af intervalrotation Konklusion Som det fremgår af tabel 12.2 fungerer intervalrotationsalgortimen efter hensigten, og er hermed godkendt. Afvigelser mellem den forventede og faktiske position skyldes upræcished fra motorreguleringen - ikke fra intervalrotationsalgoritmen Test af hardwarens påvirkning på software Denne test skal vise om softwaren kan operere sammen med hardwaren uden at hardwaren forstyrrer softwaren via f.eks. støj. Til denne test skal alt hardwaren være implementeret og tilsluttet. 141

150 KAPITEL 12. SOFTWARE TEST I tabel 12.3 er der opstillet en række situationer, hvor kanonen sættes til at udføre en handling, og under denne handling, aktiveres en anden hardwaredel, som så ikke skal forstyrre den oprindelige handling. Ved hver test starter rotationen i nulpunktet, og tilten starter omkring 0 grader. Handling Forventet udfald Faktisk udfald Godkendt/ikke godkendt Kanontårnet skal rotere 100, og der trykkes på tounchsensoren til tilten flere gange under rotationen Kanontårnet skal rotere 100, og der trykkes i interfacet på Skyd flere gange under rotationen Kanonløbet skal tilte +45, og der trykkes på touchsensoren på rotationen flere gange under tilten Kanonløbet skal tilte +45, og der trykkes i interfacet på Skyd flere gange under tilten Tårnets rotation sker uhindret og stopper ca. ved startpunkt Tårnets rotation sker uhindret, og stopper ca ved startpunkt Kanonløbets tilt sker uhindret, og stopper ca ved 45 Kanonløbets tilt sker uhindret Startpunkt: 13, Slutpunkt: 115 Godkendt Startpunkt: 10, Slutpunkt: 190 Ikke godkendt Startpunkt: 0, Slutpunkt: 45 Godkendt Startpunkt: 0, Slutpunkt: 74 Ikke godkendt Tabel 12.3: Test af hardwarens påvirkning på software Af testen i tabel 12.3 er det tydeligt at rotationen og tilten ikke bliver mærkbart forstyrret af at der bliver trykket på touchsensorerne. Til gengæld bliver de meget forstyrret når der bliver trykket på Skyd. Dette skyldes støj fra ledningerne som triggeren trækker. Hver gang der bliver trykket på skyd bliver der trukket en pludselig, forholdsvis stor strøm igennem ledningerne, som ligger i nærheden af ledningerne med encodersignal fra motorerne, og derved støjer på disse. Dette afspejler sig i at MSP en ikke registrerer alle encodersignalerne, og derfor tror at motoren har drejet kortere end den egentligt har. Derved drejer motoren indtil MSP en har fået de encodersignaler den skal have for det stykke. Men situationen, hvor der bliver skudt mange gange efter hinanden, og kanontårnet roterer eller kanonløbet tilter, vil ikke forekomme i almindeligt brug. Dette skyldes at kanonen ikke er semiautomatisk, og derved ikke kan genlades så hurtigt. Desuden kan kanonløbet ikke indstille sig så hurtigt at der kan skydes imens tårnet roterer, således at det kan ramme et udpeget mål. Skulle systemet laves mere robust, således at tryk på skyd knappen ikke forstyrrer encodersignalet, kunne det meste af støjen fjernes ved at afskærme kablerne fra kablerne med encodersignalerne. Konklusion Det konkluderes dermed at softwaren på ALC, ved almindeligt brug, ikke bliver påvirket af input fra hardwarekomponenter. Testen vurderes derfor som bestået Test af Visual Target Marking (VTM) Det følgende afsnit er et uddrag af test af Visual Target Marking. Hele testen kan ses i appendiks O. Der er opstillet 6 scenarier, som har til formål at dække de scenarier, som VTM skal kunne klare. 142

151 KAPITEL 12. SOFTWARE TEST Scenarie Udfald Godkendt - ikke godkendt 1 VTM/Test/vtm s1 1.png Godkendt. VTM/Test/vtm s1 2.png 2 VTM/Test/vtm s2 1.png Godkendt. VTM/Test/vtm s2 2.png 3 VTM/Test/vtm s3 1.png Godkendt. VTM/Test/vtm s3 2.png 4 VTM/Test/vtm s4 1.png Godkendt. VTM/Test/vtm s4 2.png 5 VTM/Test/vtm s5 1.png Godkendt. VTM/Test/vtm s5 2.png 6 VTM/Test/vtm s6 1.png Godkendt. VTM/Test/vtm s6 2.png Tabel 12.4: Test af VTM Konklusion Visual Target Marking er hermed godkendt og fungerer som den skal Test af afstandssensor I test af afstandssensor softwaren tages 5 målinger ved en række forskellige afstande. Derefter tages gennemsnittet af de målte afstande og der evalueres på afvigelsen fra den reelle afstand. Kanonen opstilles med min 4 meters frit udsyn foran den. Målet, i form af en 40x40 cm plade, placeres lodret 1.3 meter foran kanonen, og målet flyttes efter 5 målinger videre til næste afstand, osv.. Reel afstand Test1 Test2 Test3 Test4 Test5 Gennemsnit Afvigelse 130cm 175cm 171cm 169cm 173cm 182cm 174cm 44cm 150cm 185cm 168cm 185cm 190cm 185cm 182.6cm 32.6cm 200cm 212cm 203cm 207cm 208cm 201cm 206.2cm 6.2cm 250cm 245cm 244cm 243cm 238cm 267cm 247.4cm -2.6cm 300cm 337cm 345cm 315cm 344cm 332cm 334.6cm 34.6cm 350cm 335cm 341cm 350cm 305cm 302cm 326.6cm -23.4cm 390cm 350cm 306cm 343cm 346cm 316cm 332.2cm -57.8cm Tabel 12.5: Data fra test af afstandssensor Som det fremgår af kolonnen med afvigelser i tabel 12.5, lever afstandssensoren ikke op til krav K4.4 fra afsnit Det er dog værd at bemærke, at den er forholdsvis præcis ved afstande fra 2 meter til 2.5 meter. Konklusion Det konkluderes på baggrund af denne test, at afstandssensoren ikke lever op til kravene, opstillet i afsnit 4. Dette kan eventuelt løses ved at implementere en anden type afstandssensor, som f.eks. laser, som er mere præcis. Men grundet det sene tidspunkt i projektet, er der ikke tid til at implementere en anden sensor. 143

152 Kapitel 13 Accepttest I dette afsnit vil accepttesten blive udført og dokumenteret, ud fra afsnit 4.8. For en præciseret testspecifikation se appendiks P Resultater fra Accepttest Følgende er resultater af scenarier i accepttesten, udført som opstillet i appendiks P. For en demonstration af ALC, og hvordan testen er opstillet, se videoklip, vedlagt på CD Accepttest/accepttest samlet.avi. Videoklippet viser hvordan kanonen bevæger sig, som følge af input fra brugeren Noter til udførelse af Accepttesten Da kuglen triller ud af løbet når det står i vandret, placeres kuglen først i løbet når tilten er færdig med at indstille sig. Ved scenarier hvor Adjust & Shoot anvendes, udføres skuddet først uden kugle, og efter kanonen er affyret uden noget, lades den igen og affyres med kugle, uden at nulstille løbet. Før hver test køres en software reset på MSP en, dog med undtagelse af scenarie 6, hvor der ikke resettes mellem hvert skud mod de 3 afstande Scenarie 1 Udfald: Kanonen indstillede sig, og affyrer når der trykkes på Shoot. Konklusion: Testen er godkendt Scenarie 2 Udfald: Kanonen indstillede sig og fandt ud af, at målet var Out of range. Konklusion: Testen er godkendt. Dog med bemærkning om upræcisheden i afstandssensoren 144

153 KAPITEL 13. ACCEPTTEST Scenarie 3 Udfald: Kanonen indstillede sig og skød mod målet. Konklusion: Testen er godkendt Scenarie 4 Udfald: Kanonen indstillede sig og fandt ud af, at målet var Out of range. Konklusion: Testen er godkendt Scenarie 5a Udfald: Kanonen drejede med uret til den ikke kunne dreje længere, og der kom en meddelelse om dette på interfacet. Konklusion: Testen er godkendt Scenarie 5b Udfald: Kanonen drejede mod uret til den ikke kunne dreje længere, og der kom en meddelelse om dette på interfacet. Konklusion: Testen er godkendt Scenarie 6 Udfald: Kanonen indstillede sig og skød mod målet. Udfaldet af skuddene er indtastet i tabel Afstand Test 1 Test 2 Test 3 Test 4 til mål 1.5m no no r no 2.5m no nh no no 3.5m j j nh nv Tabel 13.1: Udfald af scenarie 6 om skuddet ramte eller ej. j=ja, n=nej, o=over, h=til højre, v=til venstre, r=out of range Konklusion: Da det kun var en gang, hvor afstandssensoren ikke kunne måle afstanden, er testen er godkendt Scenarie 7a Udfald: Kanonen drejede skiftevis med og mod uret, og reagerede på under et sekund efter hvert tryk. Konklusion: Testen er godkendt. 145

154 KAPITEL 13. ACCEPTTEST Scenarie 7b Udfald: Kanonen drejede skiftevis med uret og tiltede op, og mod uret og tiltede ned, og reagerede på under et sekund fra hvert tryk. Lysene på driverne på MSP en begyndte at gå lidt ned i lysstyrke ved skift, efter de første 13 skift, men der var ingen indvirkning funktionaliteten. Konklusion: Testen er godkendt, men ved længere stresstest, vil de enkelte hardware drivere lukke ned, men softwaren vil køre videre Scenarie 8 Udfald: Kanonen bliver indstillet så målet er centreret, og tilten bliver indstillet ved øjemål, og kanonen bliver affyret mod målet. Konklusion: Testen er godkendt Test af præcision Udfald: Kanonen indstiller sig, bliver ladt, og affyres i hver test, med undtagelse af enkelte test, hvor afstandssensoren måler afstanden forkert. Udfaldet af skuddene er indtastet i tabel Afstand til mål m no no r j j r j nh r r r r nh no j nh r r nv j 2m nv j j j j j nv j j j nv nv no j nv j no nv nv no 2.5m nh nv nv nv j nv no no nv no j no nv nv nv nv nv nv nv nv 3m nv j j nv nv nv nv nv nv nv nv nv nv nv nv nv nh no j nv 3.5m j j j nh nh j j j j nh nh j j nh nv nv nv j j j Tabel 13.2: Skema med udfaldet af testen noteret. j=ja, n=nej, o=over, h=til højre, v=til venstre, r=out of range I tabel 13.3 er resultaterne fra tabel 13.2 optalt og succesraten er udregnet. I kolonnen Afvigelse er afvigelsen fra succesraten, udregnet fra ligning 4.3 fra afsnittet Præcision af kanon, udregnet. Afstand til mål Antal ja Antal nej og Out of range Succesrate Afvigelse 1.5m % -68.5% 2m % % 2.5m % -80% 3m % % 3.5m % -26.5% Tabel 13.3: Udfald af test af præcision, om skuddet ramte eller ej. j=ja, n=nej, o=over, h=til højre, v=til venstre, r=out of range I figur 13.1 ses resultatet af testen indsat i graf sammen med kravet om præcision. 146

155 KAPITEL 13. ACCEPTTEST Figur 13.1: Præcisions resultat af ALC [CD Accepttest/precision.m] Konklusion Testen viser, at der er nogle fejlkilder ved affyring af kanonen. Den største fejlkilde er selve kanonløbet, som, pga. uregelmæssigheder i fjederen og ujævnheder i kanonløbet, ikke affyrer kuglen i samme retning hver gang. En anden fejlkilde er afstandssensoren, som ikke måler præcist nok. En fejlkilde kan også være at kameraet ikke peger helt præcist fremad, og derved ikke i samme retning som løbet. Konklusionen på testen er derfor, at kanonen overordnet ikke lever op til kravet om præcision af kanonen opstillet i afsnit