Robot som interface mellem skakspil og computer

Transkript

1 Robot som interface mellem skakspil og computer Datateknik, gruppe 352

2

3 Datateknik 3. Semester Fredrik Bajers Vej 7 Telefon Titel: Robot som interface mellem skakbræt og computer Tema: Mikroprocessorsystemer Projektperiode: D3, efterårssemestret 2006 Projektgruppe: 352 Deltagere: Bjarke Freund-Hansen Christian Bräuner Sørensen Christian Lindequist Larsen Jakob Sloth Nielsen Karsten Fyhn Nielsen Rasmus Melchior Jacobsen Vejleder: Jan Helbo Oplagstal: 9 Sidetal: 6 inkl. appendiks Bilagsantal og art: 5 (ligger på vedlagt CD) Synopsis: Denne rapport beskriver udarbejdelsen af en prototype af en robot som interface mellem et skakbræt og en computer. Prototypen består af tre dele, en mikroprocessor (MSP430F49) indholdende software, en række elektriske kredsløb og en mekanisk del. Ud fra en analyse af den mekaniske del og skak generelt opstilles en række krav til softwaren, på mikroprocessoren, og elektronikken. Ud fra kravene udvikles elektronik, til styring af mekanikken, og software, på mikroprocessoren, til styring af elektronikken. I rapporten er der lagt vægt på opbygningen af softwaren på mikroprocessoren. Til opbygning af softwaren, anvendes metoden Struktureret Programudvikling. Hardwaren designes sammen med de drivermoduler, der skal styre disse. Det konkluderes, at det er lykkedes at opbygge en fungerende prototype, der er i stand til at udføre én spillers interaktion med et skakspil. Til sidst diskuteres de problemer, der har været under implementeringen, og mulige løsningsforslag opstilles. Desuden perspektiveres der på videreudvikling af prototypen. Afsluttet den: 20. december 2006 Rapportens indhold kan frit citeres, hvis der anvendes kildeangivelse.

4 Forord Dette projekt omhandler udarbejdelsen af en prototype af en robot som interface mellem et skakbræt og en computer, hvor robotten varetager den ene spillers interaktion med skakbrættet. Interaktion omfatter udførsel af træk og registrering af den anden spillers træk. Beregningen af træk og overvågning, af om skakreglerne opfyldes, foretages på computeren. Projektet omhandler herunder også opbygning af nødvendig hardware, samt programmering af software til MSP430F49 mikroprocessoren. Projektet er udarbejdet i efteråret 2006 på Aalborg Universitet. Niveauet for rapporten er 3. semesters studerende ved Datateknikretningen på Institut for Elektroniske Systemer. Kildehenvisninger er foretaget vha. Harvard metoden, og alle kildeoplysninger kan findes i litteraturlisten. Bilag til rapporten ligger på vedlagt cd. Hvert kapitel indeholder en kort indledning, hvor metoden, der er anvendt, er beskrevet. Kapitel indleder rapporten med bl.a. at beskrive udviklingen af robotter i underholdningsindustrien, og ender med at underbygge valget af projektemnet. Skak analyseres, i kapitel 2, i forhold til en implementation i en robot. Kapitlet afsluttes med en opsummering af nødvendigheder til en sådan implementation, og der afgrænses fra håndtering af en række skak-specifikke situationer. I kapitel 3 beskrives en opdeling i en mekanikdel og en software- og elektronikdel. Der analyseres på konklusionen fra kapitel 2 ift. en mekanisk løsning. Ud fra denne analyse opstilles en række overordnede krav til software- og elektronikdelen. De overordnede krav i kapitel 3 sammenfattes i kapitel 4 til en række funktionelle krav i kravspecifikationen, og den overordnede programfunktion beskrives. Herefter designes en accepttest, i kapitel 5, på baggrund af de funktionelle krav, og det beskrives specifikt, hvordan den skal udføres. Designet af prototypen beskrives i forhold til kravspecifikationen, i kapitel 6. Der foretages en opdeling i applikationslag, kerne og driverlag. Dernæst opdeles de enkelte lag i moduler, og hvert modul beskrives kort. I kapitel 7 og 8 beskrives designet af applikationslaget. Opdelingen af applikationslaget består af en generel del i kapitel 7 og algoritmer i kapitel 8. Designet er delt i to, da to forskellige designmetoder benyttes. Moduldesignet af henholdsvis modulerne i kernen og driverlaget beskrives i kapitel 9 og 0. I kapitel testes prototypen ift. accepttesten, og i kapitel 2 konkluderes projektet. Sidst, i kapitel 3, diskuteres problemerne fra konklusionen og der perspektiveres på prototypens videreudvikling. Bagerst i rapporten er appendiks A og B. I appendiks A findes et uddrag af FIDE s skakregler, samt kodekonventioner, der beskriver ekstra regler til syntaksen af softwarekoden. I appendiks B er der et generelt afsnit om MSP430F49 mikroprocessoren, der anvendes i projektet. Bagsiden er en fold-ud side, indeholdende de vigtigste figurer i rapporten. Denne kan med fordel anvendes under læsningen. God fornøjelse! Datateknikgruppe 352 3

5 FORORD Bjarke Freund-Hansen Christian B. Sørensen Christian L. Larsen Jakob S. Nielsen Karsten F. Nielsen Rasmus M. Jakobsen 4

6 Indhold Forord 3 Indhold 5 Indledning 7 2 Foranalyse af skak 8 2. Generel beskrivelse Specialtilfælde Status for spillet Fejlmuligheder Afgrænsning og sammenfatning Projektbeskrivelse 3 3. Mekanikdelen Software- og elektronikdelen Afgrænsning og sammenfatning Kravspecifikation 8 4. Generel beskrivelse Funktionelle krav Systembeskrivelse Design af acceptest Kravspecifikationstest Test af ydelse Overordnet softwaredesign Programdesign Procesdesign Moduldesign Moduldesign af applikationslag I Brætopstilling Logik Moduldesign af applikationslag II 4 8. Flytningsalgoritme Flytningsalgoritme - create path() Flytningsalgoritme - clear path() Skanningsalgoritme Skanningsalgoritme - weight distribution() Skanningsalgoritme - create spanningtree()

7 INDHOLD 9 Moduldesign af kerne 6 9. Displaystyring Feltstatus Flyt brik Flyt robothoved Kommunikation med PC Moduldesign af drivere Display Kalibreringssensor Elektromagnet Lyssensor RS Motorer Udførsel af accepttest 99. Testemner Sammenfatning Konklusion 03 3 Diskussion og perspektivering Diskussion Perspektivering Litteratur 06 Appendiks 07 A 07 A. Uddrag af FIDE s skakregler A.2 Kode stil B 09 B. MSP430F Bilag CD-ROM Bilag, Billeder Bilag 2, Datablade Bilag 3, Kildekode Bilag 4, Kredsløbsdiagrammer Bilag 5, PDF- og postscriptudgave af rapporten

8 Kapitel Indledning I dag er der stor udvikling indenfor robotindustrien. Dette gælder både indenfor erhvervslivet og privatlivet. I erhvervslivet benyttes robotter, der kan udføre tungt eller monotont arbejde. Deriblandt er lagerrobotter, der kan flytte paller rundt på et lager, og industrirengøringsrobotter, der f.eks. kan støvsuge eller vaske gulv. Der er et stort potentiale i industriverdenen for brug af robotter i den daglige produktion, et eksempel kunne være modulerbare robotter, der kan tilpasse sig skiftende arbejdsopgaver. Inden for privatlivet er der de seneste år kommet flere robotter, der kan udføre nogle af de daglige opgaver. Dette drejer sig bla. om robotter til støvsugning og plæneklipning, der begge er blevet populære blandt mange forbrugere. Der forskes stadig i, hvor i de private serviceområder robotter kan udnyttes. Dette drejer sig bla. om robotter til hjemmehjælp og lignende. Indenfor underholdningsindustrien er robotter også blevet populære. F.eks. Sony s mekaniske hund eller Lego s Mindstorm 2 sæt, der leveres med programmer, som gør det muligt for forbrugere, at bygge og styre robotter, uden de nødvendigvis skal have særlige kompentencer. Derudover er der firmaer, der producerer andre former for samlesæt eller robotkomponenter, så de forbrugere, der har tid og kompentencer til det, selv kan samle og programmere dem. Der er i dag også stor interesse indenfor computerspil over internettet, da man der kan spille mod venner eller fremmede overalt på Jorden, så længe de bare har en internetforbindelse. Dette drejer sig om stort set alle slags spil, eksempelvis rollespil, brætspil, actionspil, bilspil etc. Samtidig er det i dag populært, at lave interaktive spil. Et eksempel på dette kan være dansespil, hvor spilleren skal danse på en måtte, der registerer hvor spilleren sætter fødderne. Et andet eksempel kan være boksespil, hvor man skal bokse foran et videokamera, der kan genkende bevægelserne, og derved ramme modspilleren. Med inspiration i dette, er det valgt at udarbejde en prototype af en robot som interface mellem et skakbræt og en computer

9 Kapitel 2 Foranalyse af skak Skak minder på mange måder om andre brætspil, når det drejer sig om, hvordan brikkers position kan aflæses og hvordan de kan flyttes. Dog er der for hvert enkelt brætspil nogle elementer, som gør hvert enkelt spil unikt i forbindelse med implementering af en prototype af en robot som interface mellem et skakbræt og en computer, hvor robotten varetager den ene spillers interaktion med skakbrættet. I denne interaktion ligger, at robotten udfører træk ved at flytte brikkerne på brættet og aflæser spillerens træk. Fokus i dette kapitel er primært, hvordan skak kan implementeres i en prototype af en robot. Kapitlet indeholder derfor en beskrivelse af de elementer, som har indflydelse på, hvordan en robot behandler skak-spillet. Der tages udgangspunkt i et uddrag af FIDE s regler, som er vedlagt i appendiks A.. Opdelingen af beskrivelsen er således: Generel beskrivelse - beskriver de grundlæggende elementer i skak. Specialtilfælde - beskriver de specialregler som findes i skak. Status for spillet - beskriver de tilstande spillet kan være i. I de tre afsnit er der en kort introduktion til reglerne, hvorefter de vil blive relateret til en robot, hvor der vil indgå en spiller, som er personen, der skal spille mod robotten, og en modspiller, som er den spiller robotten repræsenterer. Der kan opstå forskellige fejl-situationer, som skal kunne håndteres af robotten. Disse beskrives og gennemgås i afsnit Generel beskrivelse I dette afsnit beskrives skakspillets forløb og skakbrikkernes egenskaber. Derudover konkluderes det på hvilke krav, disse stiller til udarbejdelse af en robot. 2.. Skakspillets forløb Skak spilles mellem to spillere, som skiftevis flytter brikker på skakbrættet. Spillet starter som på figur 2., hvor hver farve, hvid eller sort, er tilknyttet en spiller. Fédération Internationale des Échecs (World Chess Federation). 8

10 KAPITEL 2. FORANALYSE AF SKAK ÖÑ Ð Ò 8 ÓÔÓÔÓÔÓÔ 7 ¼ ¼ ¼ ¼ 6 ¼ ¼ ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ÈÇÈÇÈÇÈÇ 2 ËÆ ÉÂ ÅÊ a b c d e f g h Figur 2.: Startopstilling for skak. Det vælges hvilken spiller, der er hvid og starter spillet. Herefter forløber spillet ved, at spillerne skiftes til at foretage et træk. Hver type brik kan flyttes forskelligt, og hvis en brik flyttes til et felt, hvorpå en af modstanderens brikker står, bliver modstanderens brik slået og dennes plads på brættet overtages. Når en brik slås, skal denne fjernes fra brættet. Spillet afsluttes når spillet kommer i en af følgende tilstande: skakmat, remis eller pat. Disse beskrives i afsnit Skakbrikkerne Her følger en kort beskrivelse af hver type brik. Fælles for brikkerne, med undtagelse af springeren, er at de kun kan flytte på de beskrevne måder, så længe de mellemliggende felter er tomme. Bonde ( È Ô ) - Bonden kan flytte fremad til et felt umiddelbart foran den. Dog må bonden i første træk flytte to felter frem på den kolonne den står på, dog kun hvis begge felter er tomme. Hvis bonden skal slå en anden brik, skal denne være placeret diagonalt foran bonden. Tårn ( Ê Ö ) - Tårnet kan flytte til ethvert felt på den række eller kolonne den står på. Springer ( Æ Ò ) - Springeren kan flytte til et af de felter, den er nærmest på, men som ikke ligger på den række, kolonne eller diagonal, springeren står på. Dette kan ske, selvom der er mellemstående brikker. Dette betyder at denne brik, som den eneste, kan hoppe over andre brikker. Løber ( ) - Løberen kan flytte til ethvert felt på de diagonaler den står på. Dronning ( É Õ ) - Dronningen kan flytte til ethvert felt på den række, kolonne eller de diagonaler den står på. Konge ( Ã ) - Kongen kan flytte til ethvert tilstødende felt, dog ikke hvis trækket sætter kongen i skak 2. Dette giver anledning til, at robotten skal: 2 Tilstanden skak beskrives senere i afsnittet. 9

11 KAPITEL 2. FORANALYSE AF SKAK. fjerne en brik fra skakbrættet, såfremt denne brik er slået og 2. flytte en brik et givent antal felter fremad, bagud, til højre, til venstre, på begge diagonaler, samt nærmeste felt, som hverken er på række/kolonne med det felt, brikken skal flyttes fra. 2.2 Specialtilfælde Skak indeholder nogle specielle regler, som afhænger af, hvordan brikkerne står på brættet:. En passant - en bonde kan slå modstanderens bonde som vist på figur 2.2. Trækket er unikt, da man kan slå en brik, der ikke står på feltet, der flyttes til. 2. Rokade - kongen har mulighed for at udføre et specielt træk sammen med et af tårnene, som vist på figur 2.3. Der findes to rokadetyper; kongerokade, hvor kongen flytter mod det nærmeste tårn, og dronningerokade, hvor kongen flytter mod det fjerneste tårn. Der er tre krav for at en rokade kan finde sted. ) kongen og tårnet må ikke tidligere have været flyttet, 2) felterne mellem kongen og tårnet skal være fri, og 3) kongen må ikke være i skak, heller ikke over felterne hvor rokaden udføres. Trækket er unikt, da der skal flyttes to brikker i ét træk. 3. Bondeforvandling - Dette sker når bonden flytter til rækken længst fra dens udgangsposition. Hvis dette sker, skal spilleren udskifte bonden med enhver anden brik, undtagen en anden bonde eller en konge. () (2) (3) ¼ ¼ ¼ ¼ 8 ¼ ¼Ó¼ ¼ 7 ¼ ¼ ¼ ¼ 6 ¼ È ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ¼ ¼ ¼ ¼ 2 ¼ ¼ ¼ ¼ a b c d e f g h ¼ ¼ ¼ ¼ 8 ¼ ¼ ¼ ¼ 7 ¼ ¼ ¼ ¼ 6 ¼ ÈÓ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ¼ ¼ ¼ ¼ 2 ¼ ¼ ¼ ¼ a b c d e f g h ¼ ¼ ¼ ¼ 8 ¼ ¼ ¼ ¼ 7 ¼ ¼ È ¼ 6 ¼ ¼ ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ¼ ¼ ¼ ¼ 2 ¼ ¼ ¼ ¼ a b c d e f g h Figur 2.2: Eksempel på forløbet for en passant, hvor ikke relevante brikker er fjernet. () Opstilling inden sort spillers træk. (2) Sort brik flytter sin bonde. (3) Hvid har mulighed for at slå den sorte brik. () (2) (3) ¼ ¼ ¼ ¼ 8 ¼ ¼ ¼ ¼ 7 ¼ ¼ ¼ ¼ 6 ¼ ¼ ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ¼ ¼ ¼ ¼ 2 ¼ ¼Â¼ Ê a b c d e f g h ¼ ¼ ¼ ¼ 8 ¼ ¼ ¼ ¼ 7 ¼ ¼ ¼ ¼ 6 ¼ ¼ ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ¼ ¼ ¼ ¼ 2 ¼ ¼ ¼ÂÊ a b c d e f g h ¼ ¼ ¼ ¼ 8 ¼ ¼ ¼ ¼ 7 ¼ ¼ ¼ ¼ 6 ¼ ¼ ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ¼ ¼ ¼ ¼ 2 ¼ ¼ ʼ a b c d e f g h Figur 2.3: Eksempel på forløbet for en rokade (her kongerokade). () Opstilling efter sort har udført sit træk. (2) Kongen rykkes to felter. (3) Tårnet flyttes over på den modsatte side af kongen. Først nu er der udført et træk, og turen går videre til sort spiller. 0

12 KAPITEL 2. FORANALYSE AF SKAK Disse giver anledning til, at robotten skal kunne:. Vide om der er mulighed for at slå en bonde, når denne rykkes to felter frem i samme træk. Hvis spillerens bonde slås en passant af robotten, skal den fjernes fra skakbrættet. Dette er en smule anderledes end ved at slå en brik normalt, da spillerens bonde ikke står på feltet robotten angriber. Samtidig skal robotten vide, at hvis spilleren udfører en passant, så mister modspilleren sin bonde. 2. Udføre en rokade ved først at flytte kongen, for derefter at flytte tårnet. Det, der gør dette træk specielt for robotten, er, at den skal flytte to brikker i ét træk. Samtidig skal robotten kunne identificere, hvis spilleren udfører en rokade. Dette skal kunne gøres, uanset hvor de resterende brikker er placeret på skakbrættet udenfor rokade-området. 3. Udskifte en bonde med en anden brik, når denne flytter til rækken længst fra dens udgangsposition; enten ved at bytte brikken fysisk med reservebrikker, der er placeret udenfor spillepladen, eller ved at ændre bondens funktion, men stadig fysisk beholde bonden på det pågældende felt. Samtidig skal en robot også vide, at hvis modstanderens bonde flyttes til rækken længst fra dens udgangsposition, ændres funktionaliteten for brikken. 2.3 Status for spillet Der er fem forskellige tilstande spillet kan være i:. i spil - tilstanden, som spillet er i, hvis ingen af de nedenstående tilstande er aktiv, 2. skak - når en spillers konge bliver placeret i en situation, hvor modstanderens næste træk kan slå kongen, 3. remis - når ingen af spillerne har mulighed for at kunne sætte modstanderen i skak, uanset hvor længe spillet fortsætter, eller hvis den samme stilling optræder på brættet tre gange i træk, 4. skak-mat - det samme som skak, men hvor spilleren ikke har nogen mulighed for at forsvare eller flytte egen konge ud af situationen, 5. pat - når en spiller ikke har nogen mulighed for at udføre et træk, samtidig med at kongen ikke er truet. Dette giver kun anledning til et krav, om at vise spillets tilstand til spilleren, da robotten som interface ikke skal holde styr på skakregler. 2.4 Fejlmuligheder Dette afsnit beskriver de fejlmuligheder, der vil kunne opstå under et spil skak. Af fejlmuligheder kan bl.a. nævnes: fejltræk, flytning af andre brikker end de lovlige hvis spiller er skak, fjernelse af en brik, der ikke kan fjernes, ombytning af en brik, der ikke kan byttes, samt muligheden for at skakbrættet vil kunne blive forskudt ift. robotten, der skal udføre en modspillers træk. Alle fejlene opstår udelukkende pga. snyd eller uopmærksomhed fra spiller. De vil under et normalt spil skak blive observeret af modspiller, og det vil derfor også være nødvendigt for en robot at lave denne kontrol, for at undgå ulovlige træk. Den sidste fejlmulighed vil kunne undgås ved at lave en robust konstruktion af opstillingen, der vil mindske risikoen for at skakbrættet og robotten vil komme ud af synkronisering.

13 KAPITEL 2. FORANALYSE AF SKAK 2.5 Afgrænsning og sammenfatning Igennem analysen er der fundet krav, der lægger op til en robots udførsel af en modspillers funktion i skak. Der er i første omgang valgt at fokusere på en minimumsimplementation, hvor et spil skak forløber som beskrevet i afsnit 2.., hvilket indbefatter at robotten skal kunne:. flytte enhver brik, 2. fjerne enhver brik fra skakbrættet, 3. bestemme ethvert felts status mht. om der står en brik eller ej, hvilken farve en evt. brik har og hvad type det er, 4. udskifte en bondes funktion til en dronning ved bondeforvandling, 5. håndtere rokade, 6. håndtere en passant, 7. implementere de fem forskellige tilstande; skak, skak-mat, pat, remis og i spil. Hermed er der foretaget en afgrænsning fra følgende:. Implementering af de resterende regler i FIDE s regelsæt. Herunder lynskak, spil med skakur, turningshåndtering ol. 2. Håndtering af fejlsituationer, som er forårsaget af uopmærksomhed fra spiller. 3. Udskifte en bondes funktion til andet end en dronning i tilfælde af bondeforvandling. 2

14 Kapitel 3 Projektbeskrivelse Foranalysen leder op til implementering af en prototype af en robot som interface mellem et skakbræt og en computer. Da semestrets tema er mikroprocessersystemer, afgrænser projektet sig fra at analysere på den mekaniske del af robotten, og opstiller her et løsningsforslag for opbygningen af prototypen: Mekanikdelen - den mekaniske del af robotten, der udfører en modspillers skaktræk. Software- og elektronikdelen - styring af mekanikdelen vha. en mikroprocessor, dertilhørende designede hardware- og softwaremoduler, samt et interface til en PC, hvor modspillerens beslutninger tages. Komponenter i mekanikdelen, såsom motorer og kalibreringssensorer, der styres af softwareog elektronikdelen, opfattes som et interface, se figur 3.. De ikke-mekaniske komponenter, lyssensorer og elektromagnet, omfattes ligeledes af mekanikdelen. Software- og elektronikdelen Motorer Lyssensorer Kalibreringssensorer Elektromagnet Mekanikdelen Figur 3.: Opdelingen af mekanik, software- og elektronikdelen Til mekanikdelen bruges et færdigt udviklet løsningsforslag, som benyttes i prototypen. Løsningsforslaget til mekanikdelen findes i afsnit Mekanikdelen Dette afsnit beskriver mekanikdelen af robotten. Delene til denne kan genfindes på figurerne 3.2 og 3.3 og er markeret med et tal, f.eks. (). Da der er stillet Lego Mindstorm til rådighed til projektet, anvendes dette til opbygning af mekanikdelen. Modelrobotten er opbygget med et robothoved (), der kan kører på skinner (2) i et (x,y)-koordinatsystem under skakbrættet vha. motorer (3). Dette giver en robust og enkel konstruktion, samtidig med at det skjuler løsningen under skakbrættet, således at det ikke forstyrrer spillet. Det er muligt at nulstille robothovedet vha. to kalibreringssensorer (4) til en kendt position i koordinatsystemet. Derved kan robothovedet kalibreres. Under robothovedet er en lyssensor (5), som sammen med felter på hvid baggrund på overfladen under robothovedet (6), gør robothovedet i stand til at navigere rundt til bestemte positioner. Endnu en lyssensor (7) over robothovedet anvendes til at kende forskel på, om et 3

15 KAPITEL 3. PROJEKTBESKRIVELSE Figur 3.2: Mekanikdelen på skakrobotten. Figeren kan også findes på fold-ud siden bagerst i rapporten. felt er tomt eller optaget. I tilfælde af feltet er optaget, skal lyssensoren kunne se, om brikken er sort eller hvid. Robothovedet kan fastholde og flytte brikker vha. en elektromagnet på robothovedet (8) og en magnet i bunden af hver brik. En elektromagnet bruges, da dette giver mulighed for at tænde og slukke for magnetismen i elektromagneten. Motorerne (9) kan flytte elektromagneten og den øverste lyssensor, således at de begge kan placeres midt under et felt. Et display (0) fortæller spilleren hvilken status spillet er i: i spil, skak, skak-mat, remis eller pat. Desuden skal der vises relevante informationer, såsom hvis tur det er, hvilken brik der flyttes m.v. 3.2 Software- og elektronikdelen Som hardware til kørsel af robottens software anvendes en MSP430F49 Ultra Low Power Microcontroller opbygget med seriel forbindelse til en PC vha. RS232-protokollen. Denne serielle forbindelse implementeres vha. et interface, som MSP en stiller til rådighed. Dette interface bruges til at sende informationer løbende mellem PC og MSP. På PC siden af dette interface, findes to roller: Modspiller - Skal vælge sit træk på baggrund af spillerens træk, som beskrevet i indledningen til kapitel 2. Dommer - Kender skakreglerne, og dermed også alle lovlige træk. Rollerne vil i projektet blive slået sammen, og kaldt PC-stub. PC-stubben repræsenteres på PC-siden af en person. Denne person er derfor både modspiller og dommer i skakspillet. PCstubben er dermed ikke, det man normalt forbinder med en softwarestub. MSP ens forespørgsler og beskeder vil blot blive printet på PC en, og den person, der repræsenterer PC-stubben, vil så taste svaret ind i en terminal, der håndterer den serielle forbindelse på PC en. Ydermere skal PC-stubben overvåge spillets status, og give MSP en besked når spillet opnår en af tilstandene: skak, skak-mat, remis eller pat, se punkt 7 i afsnit

16 KAPITEL 3. PROJEKTBESKRIVELSE Figur 3.3: Robothovedet på skakrobotten. Figuren kan også findes på fold-ud siden bagerst i rapporten. Elektronikdelen omfatter de kredsløb, der skal designes og implementeres for at styre robotten, og det display, der skal vise spillets tilstand til spilleren. For at vise information til spilleren, herunder spillets tilstand og trækinformationer, er det nødvendigt at displayet kan vise ASCII karakterer. Sammenhængen mellem de enkelte dele kan ses på figur 3.4. Display Elektromagnet PC-stub MSP Lyssensor Motor Kalibreringssensor Figur 3.4: Sammenhængen mellem de enkelte dele af elektronikdelen. Skakspillet skal afvikles som beskrevet i afsnittet 2... Brikkerne skal stilles op på deres korrekte startposition af spilleren inden spillet startes, som også beskrives i 2... MSP ens opgave er ikke at beregne hvilket træk, der skal foretages, men hvordan det udføres. Valget af hvortil en brik skal flyttes vil ligge på PC en, og det er derfor kun selve flytningen, der beregnes i MSP en. MSP en skal desuden gemme informationer om, hvor på brættet der er brikker, hvilken farve de har og hvilken type de er. Hvordan MSP en skal flytte brikkerne kan dog blive problematisk, idet f.eks. springeren, se evt. afsnit 2., er i stand til at flytte fra et felt til et andet, uden at passere henover mellemliggende felter. Da der er magneter i alle brikker, kan man ikke trække en brik tæt forbi en anden brik, idet man risikerer at påvirke mere end én brik ad gangen. For at løse dette skal der designes og implementeres en flytningsalgoritme, der gør det muligt at flytte en vilkårlig brik til et hvilket som helst felt, se punkt i afsnit 2.5. Flytningsalgoritmen skal håndtere følgende to problemer: Imellem feltet man ønsker at flytte til, og startfeltet, er der brikker, som blokerer den mest direkte rute. Feltet, man ønsker at flytte sin brik til, er allerede optaget af en af modstanderens brikker. American Standard for Character Intercommunication Interface 5

17 KAPITEL 3. PROJEKTBESKRIVELSE () (2) ¼ ¼ ¼ ¼ 8 ¼ ¼ ¼ ¼ 7 ¼ ¼ ¼ Ô 6 ¼ ¼ ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ¼ ¼ ¼ 2 ¼ ¼ ¼ ¼ a b c d e f g h ¼ ¼ ¼ ¼ 8 ¼ ¼ ¼ ¼ 7 ¼ ¼ ¼ Ô 6 ¼ ¼ÓÔ ¼ 5 ¼ ¼ ¼ ¼ 4 ÈÇÈǼ ¼ 3 ¼ à ¼ 2 ¼ ¼ ¼ ¼ a b c d e f g h Figur 3.5: På figuren ses to afbildninger af en flytning med løber fra C2 til G6. På () ses problemet med flytning af en brik til et felt, der allerede er optaget af en af modstanderens brikker. På (2) ses problemet med brikker, der blokerer den mest direkte rute. Problemerne er visualiseret på figur 3.5. Flytningsalgoritme For at løse det første problem, skal flytningsalgoritmen være i stand til at beregne en sekvens af felttræk, med hvilke brikken flyttes fra startfeltet til slutfeltet uden andre brikkers position er ændret efter trækket. En sekvens betegner en mængde felter, hvor rækkefølgen af felterne er vigtig. Denne beregnes af flytningsalgoritmen udfra en tabel af felter. Felttræk defineres her som en vandret eller lodret bevægelse af robothovedet fra et felt til et nabofelt. Et træk er en sekvens af felttræk. En tabel betegner en mængde felter, hvor rækkefølgen af felter ikke er vigtig. Det andet problem løses ved først at anvende flytningsalgoritmen på den slåede brik og flytte denne til en position udenfor skakbrættet. Derefter anvendes algoritmen på den brik, der skal flyttes. Det defineres dermed, at en slået brik skal håndteres ved, at denne først flyttes til en position udenfor skakbrættets felter, hvorefter den skal fjernes af spiller. Dette skal vises som en besked på displayet. Da der vælges en algoritme, der er i stand til at flytte en brik fra et felt til et andet, betyder det ikke noget, for algoritmen, hvilken type brikken er. Specialtilfælde MSP en skal vide hvordan specialtilfælde, som en rokade, en passant og bondeforvandling skal udføres og hvordan en brik slås, se punkt 2, 4, 5 og 6 i afsnit 2.5. Skanningsalgoritme MSP en skal kunne skanne skakbrættet for at aflæse spillerens træk.inden spilleren løfter en brik, skal robotten skanne på alle de felter, hvor spilleren har brikker. Når spilleren løfter en brik og robotten registrerer dette, skal den forespørge PC-stubben, hvortil denne brik kan flyttes. Når den får svar på dette, skanner den kun på de felter, hvortil spilleren kan placere den pågældende brik. Felterne skannes indtil et felts status ændres, således robotten detekterer spillerens brik på et felt, der før var tomt, eller hvor der stod en af modspillerens brikker, se punkt 3 i afsnit 2.5. Robotten tager ikke højde for ulovlige træk. Der skal udvikles en skanningsalgoritme, der udregner en sekvens af træk, der bruges til at flytte robothovedet, når der skannes. Krav til udførsel Det defineres at skak-robotten maksimalt må tage fem sekunder per felttræk af robothovedet, da dette vælges som den lavest acceptable hastighed, robotten må have, under udførsel af et træk. Flytningsalgoritmen, hvormed robotten vælger udførslen af et træk, og skanningsalgoritmen, hvormed robotten vælger ruten til skanning af spillers træk, skal bygge på, at et træk eller flyt 6

18 KAPITEL 3. PROJEKTBESKRIVELSE af robothovedet skal foretages med mindst mulig bevægelse af robothovedet, da dette vil give den hurtigst mulige afvikling af robottens træk. 3.3 Afgrænsning og sammenfatning Dette afsnit har afgrænset projektet fra at omfatte en fuldstændig beskrivelse af den mekaniske del af prototypen. Mekanikdelen vil blive brugt som en færdig løsning, som implementeres i prototypen, med en opbygning som beskrevet i afsnit 3.. Desuden har afsnittet defineret, at det område projektet primært vil omhandle, er Software- og elektronikdelen. Derudover er nogle af de emner, der vil blive behandlet senere i rapporten, blevet introduceret Overordnede krav Dette leder os videre til Kravspecifikationen, der vil behandle de krav, der er lagt op til i dette kapitel. Disse er:. Prototypen skal afvikle skakspillet udfra den korrekte startopstilling. 2. MSP en skal forbindes serielt, gennem RS232 protokollen, vha. et interface, hvorigennem der kommunikeres med PC-stubben. 3. Prototypen skal have et display, der kan vise ASCII karaktere. 4. MSP en skal beregne, hvordan en given brik flyttes til et givet felt. 5. MSP en skal beregne, hvordan en tabel af felter kan skannes. 6. MSP en skal vide på hvilke felter, der står brikker, hvilken farve disse brikker har og hvilken type de er. 7. Prototypen skal kunne flytte en vilkårlig brik til et vilkårligt felt. 8. Prototypen skal flytte en slået brik til en position uden for skakbrættet. 9. Prototypen skal kunne detektere et felts status. 0. MSP en skal genkende rokader, en passant og bondeforvandling.. Prototypen må maksimalt tage fem sekunder om at udføre et felttræk af robothovedet. 2. Flytninger skal udføres med mindst mulig bevægelse af robothovedet. 7

19 Kapitel 4 Kravspecifikation Kravspecifikationen samler op på de overordnede krav, der er opstillet i projektbeskrivelsens sammenfatning, se afsnit Disse fordeles i programdele i afsnit 4., hvor der også er en beskrivelse af, hvordan de opdelte programdele fungerer. Når der refereres til de overordnede krav i afsnit 3.3., vil disse blive skrevet i kursiv. Et eksempel kunne være overordnet krav. Afsnittet giver anledning til at opstille funktionelle krav, se afsnit 4.2, der giver overblik over funktionaliteten i programmet, og som sørger for, at det færdige program kan testes gennem en accepttest, se kapitel 5. Metoder, der anvendes gennem kravspecifikationen, er: SPU er anvendt til inddelingen i afsnit. Dog er kun anvendt de emner der er relevante for dette projekt. SPU anvendes til opdeling af hovedfunktionaliteten til mindre funktionaliteter vha. topdown metoden. SPU anviser, at der kan bruges flow-diagrammer til denne opdeling, og hertil er der anvendt flowchart-teknikken baseret på [IBM, 969]. SPU anvendes til opbygningen af de funktionelle krav i afsnit 4.2. Mængden og dybden af valg, der er foretaget inden og i kravspecifikationen, afhænger af den kunde, prototypen udvikles til. I dette projekt er prototypens kunde projektgruppen selv, og det er derfor projektgruppen internt, der har valgt afgrænsningen. 4. Generel beskrivelse Funktionalitet Input/Output Start/Stop Spørgsmål Figur 4.: Symbolerne anvendt i flow-chart diagrammer. Dette afsnit beskriver hvorledes programmet afvikles. Først forklares det grundlæggende princip af afviklingen i afsnittet 4... Herefter udspecificeres de to hovedfunktionaliteter, som findes i programmet, i afsnit og Der anvendes flowchart diagrammer, hvor symbolerne, se figur 4., har følgende betydning: Funktionalitet - beskriver en funktionalitet, der udføres på et input og som giver et output. For hver funktionalitet, kan der findes et funktionelt krav under afsnittet 4.2. Dog ikke for spillers tur og modspillers tur, der specificeres i afsnit og

20 KAPITEL 4. KRAVSPECIFIKATION Input/Output - beskriver input og output til flowchart diagrammet. Både input og output sendes til og fra funktionaliteter der findes under afsnit 4.2. Input - input i form af spørgsmål eller beskeder til programmet fra PC-stubben eller brætopstilling. Output - output i form af spørgsmål eller beskeder til enten PC-stubben, brætopstilling eller display. Start/Stop - beskriver start/stop af sekvens. Spørgsmål - beskriver et spørgsmål, som stilles i programmet. 4.. Programmellets funktion Dette afsnit beskriver afviklingen af spil, herunder spillers og modspillers tur Afvikling af spil Start Forespørgsel om hvem der er hvid hos PC-stubben Vis modspillers tur på display Vis spillers tur på display Angiv hvid spiller på display Modspillers tur Spillers tur Er det spillers tur? Nej Spørg PC-stubben om tilstanden Spørg PC-stubben om tilstanden Ja Vis status på display Vis status på display Skal spillet fortsætte? Nej Skal spillet fortsætte? Nej Ja Ja Slut Figur 4.2: Spillets forløb. Forløbet for spillet ses på figur 4.2. Figuren er udviklet på baggrund af et skakspils forløb, som beskrevet i afsnit 2... Skak-robotten initialiseres før et spil kan påbegyndes. Dette sker ved at spilleren opstillee alle brikkerne i den korrekte startopstilling, jf. overordnet krav, og sikrer sig, at der er forbindelse mellem skak-robotten og PC en, jf. overordnet krav 2. Derefter forespørger skak-robotten PCstubben om hvem, der er hvid, jf. overordnet krav 2. Den spiller, der vælges til hvid, får første tur. Herefter afvikles spillet og der skiftes mellem spillers tur og modspillers tur, indtil en af følgende tilstande opnås: skak-mat, remis eller pat. Her stopper spillet, og der gives besked om tilstanden af spillet på displayet, jf. overordnet krav 3. Afviklingen af spillers og modspillers tur beskrives herefter. 9

21 KAPITEL 4. KRAVSPECIFIKATION Start Hent tabel over brætopstilling Forespørgsel om mulige træk hos PC-stubben Kør skanningsalgoritmen Kør skanningsalgoritmen Håndter specialtilfælde Flyt robothoved Flyt robothoved Opdater tabel over brætopstilling. Læs feltstatus Læs feltstatus Fortæl PC-stubben det foretagede træk Slut Er en løftet brik fundet? Nej Er en brik sat? Nej Ja Ja Figur 4.3: Forløbet for Spillers tur Spillers tur Forløbet for Spillers tur ses på figur 4.3. felt.. Henter en tabel over brætopstilling, jf. overordnet krav Skanningsalgoritmen beregner en sekvens af koordinater, udfra en tabel over spillers brikker, jf. overordnet krav 5 og Robothovedet flyttes til det næste koordinat i sekvensen fra skanningsalgoritmen, jf. overordnet krav. 4. Feltets status aflæses, jf. overordnet krav Hvis feltets status har ændret sig, fortsættes der til næste punkt, ellers fortsættes der fra punkt PC-stubben forespørges om, hvilke felter, den løftede brik kan placeres på, i form af en tabel over koordinater, jf. overordnet krav Skanningsalgoritmen permuterer tabellen af koordinater, jf. overordnet krav 5 og Robothovedet flyttes til det næste koordinat i tabellen fra skanningsalgoritmen, jf. overordnet krav. 9. Feltets status aflæses, jf. overordnet krav Hvis feltstatus er skiftet, dvs. brikken på feltet har skiftet farve, eller der er sat en brik på et tomt felt, så fortsættes til næste punkt, ellers fortsættes fra punkt 8.. Eventuelle specialtilfælde håndteres, jf. overordnet krav Tabellen over brætopstillingen opdateres med spillerens træk, og brætopstillingen gemmes, jf. overordnet krav Spillerens træk sendes til PC-stubben, jf. overordnet krav 2. En brætopstilling er en tabel over hele skakbrættet med informationer om hvilken brik, der står på hvert 20

22 KAPITEL 4. KRAVSPECIFIKATION Modspillers tur Start Forespørgsel om træk hos PC-stubben Er slutfeltet frit? Ja Nej Håndter slået brik Vis at brik skal fjernes på display Vis træk på display Håndter specialtilfælde Kør flytningsalgoritmen Flyt brik Hent tabel over brætopstilling Opdater tabel over brætopstilling Slut Figur 4.4: Forløbet for Modspillers tur. Forløbet for Modspillers tur ses på figur Skak-robotten modtager træk-information fra PC-stubben, jf. overordnet krav Vis trækinformation på display, jf. overordnet krav Henter en tabel over brætopstilling, jf. overordnet krav Hvis feltet, hvortil brikken skal flyttes, er optaget, fortsættes der til næste punkt. Ellers fortsættes der fra punkt Den slåede brik fjernes fra skakbrættet, jf. overordnet krav Det vises på display, at brikken nu kan fjernes af spiller. 7. Eventuelle specialtilfælde håndteres, jf. overordnet krav Skak-robotten beregner, vha. flytningsalgoritmen, hvordan brikken flyttes fra udgangspositionen til destinationen, jf. overordnet krav 4 og Skak-robotten udfører trækket, jf. overordnet krav 7 og. 0. Brætopstillingen opdateres. 4.2 Funktionelle krav Dette afsnit beskriver kravene til de funktionaliteter programmet skal have. Hver funktionalitet er beskrevet med: Formål - Formålet med det funktionelle krav og hvilke overordnede krav det opfylder. Funktionalitet - Kort beskrivelse af det funktionelle kravs funktion. Input - Det input det funktionelle krav tager. Output - Det funktionelle kravs output. Input eller output er dog udeladt, hvis der intet input eller output er. Når der refereres til en funktionalitet, er dens navn sat i kursiv. Et eksempel herpå er: se Skanningsalgoritme. 2

23 KAPITEL 4. KRAVSPECIFIKATION 4.2. Kommunikation med PC-stub Formål - At kunne udveksle information med PC-stubben, jf. overordnet krav 2. Funktionalitet - Kommunikation med PC-stub kan sende og modtage information til og fra PC-stubben gennem et serielt interface. Input - Den information der skal sendes til PC-stubben. Output - Den information der kommer fra PC-stubben Visning på display Formål - At vise en given tekst på displayet, jf. overordnet krav 3. Funktionalitet - Denne funktionalitet kan vise en given tekst på displayet. Input - Besked, der skal vises på displayet Brætopstilling Formål - At indeholde den aktuelle brætopstilling med informationer om, hvor der står brikker, hvilken farve de har og hvilken type de er, således at disse kan forespørges, jf. overordnet krav 6. Funktionalitet - Denne funktionalitet skal lagre informationer om hvert felt på et skakbræt, dvs. hvor brikkerne står, hvilken farve de har og hvilken type de er. Dette skal kunne forespørges og brætopstillingen skal kunne opdateres med nye træk. Input - Forespørgsel om feltinformationer eller besked om opdatering. Output - Besked om feltinformationer Skanningsalgoritme Formål - At beregne hvordan robothovedet skal flytte sig, for at skanne et antal givne felter med færrest mulige flytninger af robothovedet, på en nær optimal måde, jf. de overordnede krav 5 og 2. Funktionalitet - Når Skanningsalgoritme benyttes, får den et antal koordinater, der angiver de felter, der ønskes skannet. Den beregner så en rute for, hvordan dette kan gøres. Input - En tabel af felter. Output - En sekvens af felter Flytningsalgoritme Formål - At beregne en rute til at flytte en brik fra et felt til et andet, med færrest mulige flytninger af robothovedet, på en nær optimal måde, jf. overordnet krav 4 og 2. Funktionalitet - Når en brik skal flyttes fra et givet felt til et andet, skal Flytningsalgoritme beregne en rute for hvordan brikken skal flyttes. Hvis der står andre brikker i vejen for den rute brikken skal flyttes, skal algoritmen beregne, hvordan de flyttes. Input - Koordinatet til den brik man ønsker at flytte, samt koordinatet til det felt brikken skal flyttes til og brætopstillingen. Output - En sekvens af felter. 22

24 KAPITEL 4. KRAVSPECIFIKATION Flyt robothoved Formål - At flytte robothovedet til et givet koordinat, jf. overordnet krav. Funktionalitet - Flyt robothoved flytter vha. motorerne robothovedet til et givet koordinat. Den finder frem til dette ved brug af lyssensoren i bunden. Et felttræk må maksimalt tage fem sekunder for robothovedet. Input - Et koordinat, hvortil robothovedet ønskes flyttet Feltstatus Formål - At aflæse et felts status, dvs. om der står en sort eller hvid brik på feltet, eller om det er tomt, jf. overordnet krav 9. Funktionalitet - Ved hjælp af lyssensoren i toppen af robothovedet skal et felts status aflæses. Et felt kan have tre statusser: tomt, sort eller hvidt. Output - Tomt, sort eller hvidt Flyt brik Formål - At flytte en brik fra et givet felt til et andet, jf. overordnet krav 7. Funktionalitet - Flyt brik kan ved brug af elektromagneten og Flyt robothoved flytte en skakbrik fra et felt til et andet. Input - Koordinaterne til feltet, hvor brikken, der ønskes flyttet, står, samt koordinater til den nye position for brikken Håndter slået brik Formål - At håndtere en slået brik, jf. overordnet krav 8. Funktionalitet - Dette funktionelle krav skal fjerne en slået brik fra et felt og flytte brikken til en position uden for skakbrættet vha. det funktionelle krav Flyt robothoved. Input - Koordinaterne til det felt, hvor brikken, der ønskes fjernet, står Håndter specialtilfælde Formål - At håndtere specialtilfældene rokade, en passant og bondeforvandling, jf. overordnet krav 0. Funktionalitet - Håndter specialtilfælde kan genkende og håndtere specialtilfældene rokade, en passant og bondeforvandling. Input - Koordinaterne til feltet, hvor brikken, der ønskes flyttet, står, samt koordinater til den nye position for brikken. 4.3 Systembeskrivelse Software, til prototypen, udvikles til at køre på en MSP430F49 Ultra Low Power Microcontroller, som beskrevet i afsnit 3.2. Derfor er projektet afgrænset til brug af følgende teknologier: Systemarkitektur - 6 bit RISC 2 2 Reduced instruction set computer 23

25 KAPITEL 4. KRAVSPECIFIKATION Compiler - CDK4MSP 3 Programmeringssprog - ANSI 4 C Ydermere er der nogle begrænsninger i forhold til f.eks. hukommelse på mikroprocessoren, dette beskrives nærmere i appendiks B.. Appendiks A.2 beskriver en række regler for syntaksen og semantikken for kildekoden skrevet i dette projekt. 3 MSP430 Cross Development Kit, 4 American National Standards Institute 24

26 Kapitel 5 Design af acceptest Accepttesten er den test, der markerer afslutningen på udviklingsprocessen. I accepttesten skal det verificeres, at kravene fra kravspecifikationen er opfyldt. Accepttesten indeholder tests af den samlede prototype, og ikke de forskellige moduler prototypen er inddelt i. I stedet testes hvert modul enkeltvis, før de sættes sammen. De forskellige modultests specifikation er beskrevet under moduldesign kapitel 7, 8, 9 og 0. Dette kapitel indeholder designet af accepttesten, hvor kapitel indeholder udførslen. Til accepttesten anvendes følgende tests: Kravspecifikationstest - Verificerer, at samtlige programdele er implementeret, som kravene specificerer. Test af ydeevne - Tester hvorvidt programmet opfylder krav til ydelsen. Brugertest, sikkerhedstest, pålidelighedstest og fejlbehandlingstest gennemføres ikke, da der er tale om udvikling af en prototype. De kommende tests, vil have følgende opbygning: Testdesign - Beskriver overordnet hvordan testen er opbygget. Testimplementation - Beskriver detaljerne i opbygningen af testen, og forventet resultat af testen. Udførsel af test - Beskriver, punkt for punkt, hvordan testen udføres. 5. Kravspecifikationstest 5.. Test af kørsel af skak Denne test verificerer, at kørsel af et spil skak forløber korrekt, gennem testning af afvikling af spil, spillers tur og modspillers tur, jf. afsnit 4...For at teste om spillet forløber korrekt bliver flg. funktionaliteter testet:kommunikation med PC-stub, Visning på display, Brætopstilling, Flyt robothoved, Feltstatus og Flyt brik. Testdesign - Der startes et spil skak og det undersøges om kørslen af spillet forløber korrekt. Testimplementation - Et spil startes, og spiller sættes til hvid. Under spillet tjekkes det, om spillet forløber som forventet. Derefter gentages spillet, hvor modspiller sættes til hvid. Det forventes at testen køres igennem uden problemer. Udførsel af test - 25

27 KAPITEL 5. DESIGN AF ACCEPTEST. Et spil startes. 2. Hvid spiller vælges til spiller. 3. Tjek: På display står turen til spiller. 4. Tjek: Robotten begynder at scanne efter brik, der bliver flyttet. 5. Tjek: Det tager under fem sekunder at flytte robothovedet mellem to nabofelter. 6. Hvid - A2-A4. 7. Robotten skanner, til den finder frem til den tomme plads på A2. 8. Tjek: På PC-stubben at den løftede brik er den korrekte. 9. PC-stubben fortæller hvortil brikken kan flyttes. 0. Tjek: Robotten registrerer korrekt hvortil brikken er flyttet.. Tjek: PC-stubben skal indtaste hvilken tilstand spillet er i. 2. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil), se afsnit Tjek: Korrekt tilstand vises på displayet. 4. Tjek: På PC-stubben at Brætopstilling opdateres korrekt. 5. Tjek: På display står turen til modspiller. 6. Sort - A7-A6. 7. Tjek: Trækket vises korrekt på displayet. 8. Tjek: Robotten foretager det træk modspiller har sendt. 9. Tjek: PC-stubben skal indtaste hvilken tilstand spillet er i. 20. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil), se afsnit Tjek: Korrekt tilstand vises på displayet. 22. Tjek: På PC-stubben at Brætopstilling opdateres korrekt. 23. Tjek: På display står turen til spiller Test af korrekt spilstatus Testdesign - Der startes et spil skak, og brikkerne placeres som i Testimplementationen. Derefter udføres flytninger som beskrevet i Udførsel af test, og der kontrolleres for korrekt afslutning af spillet. I denne test tages der ikke højde for skakreglerne, da tilstandene styres af PC-stubben, og ikke afhænger af korrekt skak, skakmat eller remis. Testimplementation - For at teste de tilstande, der afslutter spillet, vil spillet genstartes flere gange gennem denne test. Når spillet genstartes, sættes brikkerne op til startopstillingen. I denne test tages der ikke højde for skakregler, der begrænser flytningsmulighederne. Det forventes at spilstatus opdateres som beskrevet i kravspecifikationen, jf. afsnit 4... Udførsel af test -. Der startes et spil. 2. Hvid spiller sættes til spiller. 3. Hvid - A2-A3. 4. PC-stubben vælger tilstanden skak. 5. Tjek: Displayet viser at robotten er skak. 6. Sort - A7-A6. 7. PC-stubben vælger tilstanden skak. 8. Tjek: Displayet viser at spiller er skak. 26

28 KAPITEL 5. DESIGN AF ACCEPTEST 9. Hvid - A3-A4. 0. PC-stubben vælger tilstanden skakmat.. Tjek: Displayet viser at spiller vinder. 2. Spillet genstartes. 3. Hvid spiller sættes til modspiller. 4. Sort - A7-A6. 5. PC-stubben vælger tilstanden skakmat. 6. Tjek: Displayet viser at robotten vinder. 7. Spillet genstartes. 8. Hvid spiller sættes til modspiller. 9. Sort - A7-A PC-stubben vælger tilstanden remis. 2. Tjek: Displayet viser at spillet endte uafgjort. 22. Spillet genstartes. 23. Hvid spiller sættes til spiller. 24. Hvid - A2-A PC-stubben vælger tilstanden remis. 26. Tjek: Displayet viser at spillet endte uafgjort Test af slået brik Denne test verificerer, at krav Håndter slået brik er opfyldt. Testdesign - Der startes et spil skak og trækkene udføres som beskrevet i Testimplementation. Testimplementation - Modspiller vælges til hvid, og der udføres træk fra startopstillingen, til skakbrikkerne er på positionerne, som vist i figur 5.. Derefter slås sort bonde på E5 ÖÑ Ð Ò 8 ÓÔÓÔ ÔÓÔ 7 ¼ ¼ ¼ ¼ 6 ¼ ¼Ó¼ ¼ 5 ¼ ¼Ç¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ÈÇÈ ÈÇÈÇ 2 ËÆ É ÅÊ a b c d e f g h Figur 5.: Opstilling af skakbræt med hvid bonde fra D4. Det forventes, at den sorte bonde flyttes udenfor brættet, og den hvide bonde flyttes til E5. Udførsel af test -. Der startes et spil skak. 2. Hvid spiller vælges til modspiller. 27

29 KAPITEL 5. DESIGN AF ACCEPTEST 3. Hvid - D2-D4. 4. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 5. Sort - E7-E5. 6. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 7. Hvid - E5-D4. 8. Tjek: - Sort bonde på E5 flyttes udenfor brættet og spiller bedes fjerne brikken på displayet. 9. Tjek: - Hvid bonde på D4 flyttes til E Test af håndtering af specialtilfælde Denne test verificerer at håndteringen af specialtilfælde foregår korrekt, som beskrevet i kravspecifikationen under Håndter specialtilfælde. Testdesign - Der startes et spil skak, og brikkerne placeres som i Testimplementationen. Derefter udføres flytninger som beskrevet i Udførsel af test, og der kontrolleres for: En passant, rokade og bondeforvandling. Testimplementation - I denne test vil spillet genstartes, for lettere at teste, om specialtilfælde håndteres korrekt. Hver gang spillet genstartes opstilles brikkerne til startopstillingen, og hvid sættes til spiller. I denne test tages der ikke højde for skakregler, der begrænser flytningsmulighederne. Det forventes at testen af de tre specialtilfælde forløber korrekt, som beskrevet i Håndter specialtilfælde. Udførsel af test -. Der startes et spil. 2. Hvid spiller sættes til spiller. 3. Der spilles indtil placeringen af brikker er som illustreret på figur 5.2. ÖÑ Ð Ò 8 Ó¼ÓÔÓÔÓÔ 7 ¼ ¼ ¼ ¼ 6 ¼ ¼ ¼Ç¼ 5 ¼Ó¼ ¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ÈÇÈÇÈÇ¼Ç 2 ËÆ É ÅÊ a b c d e f g h Figur 5.2: Opstilling af skakbræt 4. Hvid - C2-C4. 5. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 6. Sort - B4-C3. 7. Tjek: Hvid brik på C4 fjernes af robotten. 8. Tjek: Fjernelsen registreres korrekt som en passant på display. 9. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 0. Hvid - A2-A3. 28

30 KAPITEL 5. DESIGN AF ACCEPTEST. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 2. Sort - F7-F5. 3. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 4. Hvid - G5-F6. Sort brik på F5 fjernes af spiller. 5. Tjek: Fjernelsen registreres korrekt som en passant på display. 6. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 7. Spillet genstartes. 8. Hvid sættes til spiller. 9. Der spilles indtil placeringen af brikker er som illustreret på figur 5.3. Ö ¼ Ò 8 ÓÔÓÕÓÔÓÔ 7 ¼ ÒÓ ¼ 6 ¼ ¼ ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ÅÈ ¼ ¼ 3 ÈÇÈÄÈÇÈÇ 2 ˼ ¼Â ÅÊ a b c d e f g h Figur 5.3: Opstilling af skakbræt 20. Hvid - E-C. 2. Tjek: Der registreres korrekt rokade og displayet beder spiller flytte tårnet til D. 22. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 23. Sort - E8-C Tjek: Der registreres korrekt rokade og tårnet flyttes til D PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 26. Spillet genstartes. 27. Hvid sættes til spiller. 28. Der spilles indtil placeringen af brikker er som illustreret på figur 5.4. ÖÑ Ð ¼ 8 ÓÔÓÔÓÔ Ô 7 ¼ ¼ ¼ÑÔ 6 ¼ ¼ ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ ¼ ÆǼ 3 ÈÇÈÇÈÇ Ç 2 ËÆ É¼ Ê a b c d e f g h Figur 5.4: Opstilling af skakbræt 29. Hvid - E-G. 30. Tjek: Der registreres korrekt rokade og displayet beder spiller flytte tårnet til F. 29

31 KAPITEL 5. DESIGN AF ACCEPTEST 3. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 32. Sort - E8-G Tjek: Der registreres korrekt rokade og tårnet flyttes til F PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 35. Hvid - B2-B Tjek: Der registreres korrekt bondeforvandling og spiller bedes udskifte bonden. 37. PC-stubben vælger, at spillet ikke er i en speciel tilstand (i spil). 38. Sort - B7-B. 39. Tjek: Der registreres korrekt bondeforvandling på F og spiller bedes udskifte bonden. 5.2 Test af ydelse 5.2. Test af flytningsalgoritmen Denne test verificerer hvorvidt Flytningsalgoritme opfylder de krav, der blev opstillet i kravspecifikationen. Testdesign - Der startes et spil skak, og brikkerne placeres som beskrevet i Testimplementation. Derefter udføres flytninger som beskrevet i Udførsel af test, og der kontrolleres for, at flytningerne udføres korrekt og med færrest mulige flytninger af robothovedet. To opstillinger løbes igennem; en kongerokade, der skal være meget nær optimal, da rokade vurderes som et komplekst, men meget almindeligt, træk i skak, og et worst case eksempel, som beskrevet under Testimplementation. Testimplementation - I denne test tages der ikke højde for skakregler, da den udelukkende skal teste flytningsalgoritmen. Først testes flytningsalgoritmen i et worst case eksempel. Hvid spiller sættes til spiller, og der spilles fra startopstillingen til opstillingen på figur 5.5a opnås. Denne brætopstilling er valgt, da kompleksiteten vurderes større her, end hvad der opstår under et normalt spil skak. Det forventes at flytningsalgoritmen, flytter den specificerede brik til det valgte felt gennem en nær optimal sekvens. Den sekvens, der vurderes som nærest optimal, tager 33 flytninger af robothovedet, og kan ses på figur 5.5. En nær optimal sekvens defineres i dette eksempel, som en sekvens, der indeholder maksimalt 50% flere flytninger af robothovedet. I dette tilfælde betyder det, at sekvensen maksimalt må indeholde 200 flytninger af robothovedet. Derefter testes flytningsalgoritmen i en kongerokade. Udførsel af test foregår på samme måde, dog spilles der istedet til opstillingen på figur 5.6a opnås. Den sekvens, der vurderes som nærest optimal, tager 24 flytninger af robothovedet, og kan ses på figur 5.6. En nær optimal sekvens defineres i dette eksempel som en sekvens, der indeholder maksimalt 20% flere flytninger af robothovedet. I dette tilfælde betyder det at, sekvensen maksimalt må indeholde 29 flytninger af robothovedet. Udførsel af test -. Et spil startes. 2. Hvid spiller vælges til spiller. 3. Der spilles indtil placeringen af brikker er som illustreret på figur 5.5a. 4. Sort - A8-H8. 5. Tjek: Antallet af flytninger af robothovedet. 6. Et nyt spil startes. 30

32 KAPITEL 5. DESIGN AF ACCEPTEST a b c d e f g h a b c d e f g h a) b) a b c d e f g h a b c d e f g h c) d) Figur 5.5: Forløbet af den sekvens, der vurderes som nærest optimal. Det ønskede træk er A8-H8. Brikken, der skal flyttes er markeret med grøn. a) Udgangsposition: De røde pile viser, hvordan brikkerne flyttes væk fra stien. b) Brikken flyttes langs pilene fra A8 til H8. c) Oprydning: Pilene viser, hvordan brikkerne flyttes tilbage på plads. d) Skakbrættet efter udførsel af trækket. 7. Hvid spiller vælges til spiller. 8. Der spilles indtil placeringen af brikker er som illustreret på figur 5.6a. 9. Hvid - E-G. 0. Tjek: Antallet af flytninger af robothovedet Test af skanningsalgoritmen Denne test verificerer hvorvidt Skanningsalgoritme opfylder de krav, der blev opstillet i kravspecifikationen. Testdesign - Et skakspil startes, og der spilles indtil en bestemt opstilling af brikkerne er opnået. Derefter kaldes skanningsalgoritmen, og det kontrolleres, at de felter, brikken kan flyttes til, undersøges med færrest mulige flytninger af robothovedet. To opstillinger løbes igennem; startopstillingen, der skal være meget nær optimal, da denne vil opstå i et hvert spil skak, og et worst case eksempel, som beskrevet under Testimplementation. Testimplementation - Denne test verificerer Skanningsalgoritme. I denne test tages der ikke højde for skakregler, da den udelukkende skal teste skanningsalgoritmen. Først testes 3

33 KAPITEL 5. DESIGN AF ACCEPTEST a b c d e f g h a b c d e f g h a) b) a b c d e f g h a b c d e f g h c) d) a b c d e f g h e) Figur 5.6: Forløbet af den sekvens, der vurderes som nærest optimal. Det ønskede træk er en kongerokade E-G. Brikkerne, der skal flyttes, er markeret med grøn og blå. a-d) De røde pile viser, hvordan brikkerne flyttes. e) Skakbrættet efter udførsel af trækket. skanningsalgoritmen i et worst case eksempel. Hvid spiller sættes til spiller, og der spilles fra startopstillingen indtil en opstilling som på figur 5.7 opnås. Denne brætopstilling er valgt, da kompleksiteten vurderes større her, end hvad der opstår under et normalt spil skak. De sorte brikker er her ikke vist, da det er underordnet, hvor de står, da det kun er hvide brikker skal skannes. Den rute, der vurderes som den nærest optimale, tager 35 flytninger af robothovedet, og kan ses på figur 5.7. En nær optimal rute defineres i dette eksempel, som en rute, der indeholder maksimalt 50% flere flytninger af robothovedet. I dette tilfælde betyder det, at ruten maksimalt må indeholde 52 flytninger af robothovedet. Det forventes at skanningsalgoritmen dækker alle felter, som beskrevet i Udførsel af test punkt 4. Derefter testes skanningsalgoritmen i startopstillingen. Udførsel af test foregår på samme måde, dog i startopstillingen. Den rute, der vurderes som nærest optimal, tager 5 flytninger af robothovedet, og kan ses på figur 5.8. En nær optimal rute defineres i dette eksempel, som en rute, der indeholder maksimalt 0% flere flytninger flytninger af robothovedet. I dette tilfælde betyder det at, ruten maksimalt må indeholde 5 flytninger af robothovedet. Udførsel af test -. Et spil startes. 32

34 KAPITEL 5. DESIGN AF ACCEPTEST a b c d e f g h Figur 5.7: Worst case-opstilling til test af skanningsalgoritmen. Den rute, der vurderes som nærest optimal, er indtegnet med røde pile a b c d e f g h Figur 5.8: Opstilling til test af skanningsalgoritmen i startopstillingen. Den rute, der vurderes som nærest optimal, er indtegnet med røde pile. 2. Hvid spiller vælges til spiller. 3. Der spilles indtil placeringen af de hvide brikker er som illustreret på figur Tjek: Antallet af flytninger af robothovedet. 5. Testen gentages, men med startopstillingen illustreret på figur

35 Kapitel 6 Overordnet softwaredesign Dette kapitel beskriver designet af prototypen baseret på kravspecifikationen. Idet SPU ikke definerer en specifik metode til design, men derimod opstiller en række krav, vælges der en metode baseret på disse krav. Kravene, der ønskes opfyldt, er: Minimaliser grænseflader og optimaliser tætheden - Modulerne skal bruge så få informationskanaler som muligt. Dette betyder, at hvert enkelt modul skal designes til en bestemt opgave, og at andre moduler ikke kan tilgå et moduls interne variable. Testbarhed - Idet der ønskes test af hvert enkelt modul, inden disse integreres, skal hvert enkelt modul designes for testbarhed. Metoden, der benyttes i designet af programmet, er baseret på SPU. Designet opdeles i følgende dele:. Programdesign - Programmet skal ifølge SPU opdeles i processer, som er sekventielle programmer, der køres parallelt. I dette projekt er der reelt kun én proces, og derfor er en anden designmetode valgt. Metoden opdeler programmet i forskellige lag, som hver løfter abstraktionsniveauet i forhold til det underliggende lag. 2. Procesdesign - De forskellige funktionaliteter, fra afsnit 4.2, fordeles i moduler, efter hvilke funktionaliteter, der hænger sammen og kan udføres sekventielt. 3. Moduldesign - Design af de enkelte moduler. 6. Programdesign Dette afsnit opdeler programmet i lag, med hvert sit abstraktionsniveau, hvor det nederste lag er det mest hardwarenære. Lagene defineres ud fra deres interfaces til under- og overliggende lag. Lagenes grænseflader beskrives, og disse designes, så der er så få som muligt, i henhold til metoden valgt i starten af dette kapitel. Opbygningen af programmet, der skal konstrueres, er illustreret på figur 6., som indholdet af den grå ramme. Der er imidlertid også hardwaredelen med, idet den viser, hvilken kontekst programmet skal udvikles i. Applikationslag Det højeste abstraktionsniveau i programmet. Applikationslaget bruger de funktionaliteter, som kernen stiller til rådighed. 34

36 KAPITEL 6. OVERORDNET SOFTWAREDESIGN Applikationslag Kerne Drivere Hardware Figur 6.: Inddeling af hardwarenært programmel i programdele. Pilene illustrerer informationsflowet mellem programdelene. Kerne Fungerer som et interface til drivere og stiller de funktionaliteter fra kravspecifikationen, se afsnit 4.2, til rådighed, som applikationslaget bruger. Det er vigtigt at bemærke, at det, der i dette projekt betegnes som kernen, ikke svarer til kernen i f.eks. et operativsystem. Kernen i et operativsystem har andre opgaver, deriblandt realtids-styring, håndtering af flere processer etc. Opgaver som kernen i dette projekt ikke tager sig af. Drivere Denne programdel indeholder hardwarenære funktioner, der tager sig af styringen af hardware. Hardware Hardwaren skal her ses som programmets eksterne grænseflader. Grænsefladerne, der er beskrevet i projektbeskrivelsen i afsnit 3., er: Fem motorer, to kalibreringsssensorer, to lyssensorer, en elektromagnet, en serial-forbindelse og et display. 6.2 Procesdesign I dette afsnit bestemmes, ud fra opdelingen i det forrige afsnit, hvilke lag, og moduler, de enkelte funktionelle krav fra afsnit 4.2 skal ligge i. Desuden kædes funktionaliteterne sammen med hardwaren udfra projektbeskrivelsen, jf. kapitel 3. Efter funktionaliteterne er delt ud i lag og moduler, beskrives hvert modul kort. Modulernes grænseflader udspecificeres i design af modulerne. Modulerne bygger på, hvilke af de funktionelle krav, der ligger så tæt i funktionaliteter, at det er hensigtsmæssigt at placere dem i samme modul. Opdelingen i moduler kan findes på figur 6.2. Figuren illustrerer også modulernes inbyrdes kommunikation i form af funktionskald. Alle de funktionelle krav fra afsnit 4.2 kan genfindes i modulerne, der ses på figuren. 35

37 KAPITEL 6. OVERORDNET SOFTWAREDESIGN Brætopstilling Logik Flytningsalgoritme Skanningsalgoritme Applikationslag Displaystyring Feltstatus Flyt robothoved Flyt brik Kommunikation med PC-stub Kerne Display Lyssensor Kalibreringssensor Motor Magnet RS232 Drivere Display Lyssensor Kalibreringssensor Motor Magnet RS232 Hardware Figur 6.2: Oversigt over opdelingen i moduler. Pilene illustrerer funktionskald. Figuren kan også ses på fold-ud siden bagerst i rapporten. Det ses her, at applikationslagets eksterne grænseflade går gennem Logik og kun ned til kernen. Dette betyder, det kun er Logik, der kommunikerer med kernen, og at applikationslaget aldrig kommunikerer direkte med driverne. Kernen er dermed indført for at minimalisere grænsefladen mellem applikationslaget og driverne og for at stille funktionalitet til rådighed for applikationslaget på et højere niveau end driverne gør. I kernen kan de enkelte moduler kommunikere med de moduler i drivere, der er nødvendige for, at de kan udføre deres funktionalitet, i forhold til de funktionelle krav fra afsnit 4.2. Det er kun modulerne i driverlaget, der kan kommunikere sammen med den hardwareenhed, de skal styre Datastrukturer Der er behov for en række datastrukturer, for at kunne varetage spillets forløb, finde de rigtige sekvenser af flytninger/skanninger og for at kunne opdatere skakbrættet med udførte flytninger. Følgende datastrukturer benyttes: coord t - indeholder et absolut x-koordinat og et absolut y-koordinat af typen unsigned char. atomic move t - beskriver flytningen af en brik fra et felt til et nabofelt. Strukturen indeholder et absolut x-koordinat og et absolut y-koordinat af typen unsigned char på hver 3 bit, samt en retning af typen unsigned char på 2 bit. På denne måde repræsenteres et felttræk i én byte. sequence t - indeholder et array af typen atomic move t, samt antallet af elementer i arrayet, implementeret som en unsigned char. piece t - er en enum over alle 2 typer brikker og ingen brik. board t - er et 2-dimensionelt array med 8 8 elementer, svarende til størrelsen af skakbrættet, hvor hvert element er af typen piece t Pseudokode-konventioner I moduldesign benyttes pseudokode til at beskrive algoritmerne. Der benyttes de samme konventioner som beskrevet i [Cormen et al., 200], og derfor minder koden om Pascal. Dog vil arrays her begynde fra indeks 0 (i modsætning til ), da det er praktisk, når koden efterfølgende skal implementeres i programmeringssproget C. Her følger en kort beskrivelse af de vigtigste konventioner benyttet i pseudokode: 36

38 KAPITEL 6. OVERORDNET SOFTWAREDESIGN Arrays begynder fra indeks 0 og sidste element har indeks length(array)-. Dette afviger fra [Cormen et al., 200]. begin og end benyttes til at vise blokke i koden, f.eks. i forbindelse med løkker. Dette afviger fra [Cormen et al., 200]. Tildeler værdien på højresiden til variablen på venstresiden. nil Værdi, der repræsenterer ingenting. Tildeles nil til et array, tømmes array et. global Indikerer at variablen er global, og kan tilgås direkte fra alle funktioner i algoritmen. (Det behøver ikke nødvendigvis implementeres som sådan.) Dette er en tilføjelse ift. [Cormen et al., 200]. Der er desuden en række funktioner, som det her antages er til stede, og de beskrives nedenfor. Disse er tilføjelser i forhold til [Cormen et al., 200]. push(array, elem) - Indsætter elem i slutningen af array. push front(array, elem) - Indsætter elem i starten af array. pop(array) - Fjerner det sidste element fra slutningen af array Moduler Her følger en gennemgang af de moduler, lagene er opdelt i. Der anvendes en top-down metode, hvor der startes fra modulerne i applikationslaget, dernæst følger modulerne i kerne og til sidst drivermodulerne Applikationslag Logik Logik er hovedmodulet i programmet. Det er her selve afvikling af spil, spillers tur og modspillers tur fra afsnit 4.. afvikles. I Logik ligger også de to funktionelle krav Håndter slået brik og Håndter specialtilfælde. Logik er desuden den eneste kommunikationskanal mellem applikationslaget og kernen, hvilket stemmer overens med det indledende krav til design om at minimalisere grænsefladerne. Da Logik er hovedmodulet skal ingen af dets funktioner kunne kaldes fra andre moduler. Brætopstilling Modulet Brætopstilling indeholder informationer om, hvor på skakbrættet, der står brikker og hvilken type de er, jf. det funktionelle krav Brætopstilling. Disse informationer skal kunne forespørges og opdateres af Logik-modulet. Flytningsalgoritme Dette modul implementerer flytningsalgoritmen, jf. det funktionelle krav Flytningsalgoritme. Skanningsalgoritme Dette modul implementerer skanningsalgoritmen, jf. det funktionelle krav Skanningsalgoritme Kerne Displaystyring Dette modul indeholder styring af display, jf. det funktionelle krav Visning på display, og kalder driveren Display. Feltstatus Dette modul benytter driveren Lyssensor til at aflæse et felts information, jf. det funktionelle krav Feltstatus. 37

39 KAPITEL 6. OVERORDNET SOFTWAREDESIGN Flyt robothoved Dette modul gør det muligt at flytte robothovedet til et givet koordinat, jf. det funktionelle krav Flyt robothoved, ved hjælp af driverne Motor og Lyssensor. Flyt brik Dette modul gør det muligt at flytte en brik fra et koordinat til et andet, jf. det funktionelle krav Flyt brik, ved at udføre en sekvens beregnet af Flytningsalgoritme. Kommunikation med PC-stub Dette modul kalder driveren RS232, jf. det funktionelle krav Kommunikation med PC-stub, og abstraherer kommunikationen mellem applikationslag og driveren Drivere Display Dette modul får displayet til at vise tekststrenge, jf. det funktionelle krav Visning på display. Lyssensor Styringen af de to lyssensorer, en i toppen og en bunden, ligger i dette modul. Funktionerne heri bruges til at aflæse lyssensorernes værdi, jf. de funktionelle krav Flyt robothoved og Feltstatus. Kalibreringssensor Drivermodulet til kalibreringssensorne anvendes til at kalibrere robothovedet til en defineret position, jf. afsnit 3.. Dette benyttes til kalibrering ved fejlpositionering, og ved opstart. Motor Styrer de fem motorer, jf. det funktionelle krav Flyt robothoved. Motorerne på x- og y-aksen kan sættes i gang i to retninger, og stoppes. Derudover er der to motorer til at placere henholdsvis elektromagneten og top-lyssensoren, i den rette position, under feltet over robothovedet. Magnet Drivermodulet til elektromagneten skal tænde og slukke elektromagneten, jf. det funktionelle krav Flyt brik. RS232 Dette drivermodul står for lavniveau-håndtering af den serielle kommunikation mellem MSP en og PC-stubben. Modulet stiller funktioner til rådighed, der kan sende og modtage enkelte karakterer via den serielle forbindelse, jf. det funktionelle krav Kommunikation med PC-stub. 6.3 Moduldesign Modulerne er designet i 7, 8, 9 og 0. startende fra applikationslaget, gennem kerne til drivere. Der vil for hvert afsnit, være designet en modultest, som skal være opfyldt før modulerne integreres. Udførslen af disse er ikke taget med i rapporten. Applikationslag - Modulerne i applikationslaget er designet i kapitlerne 7 og 8, da metoderne der anvendes til opbygning af modulerne er forskellige. Logik og Brætopstilling designes i kapitel 7, og Flytnings- og Skanningsalgoritmerne designes i kapitel 8. Kerne - Modulerne i kernen designes i kapitel 9. Drivere - Drivermodulerne designes i kapitel 0. 38

40 Kapitel 7 Moduldesign af applikationslag I For hvert af de to moduler Logik og Brætopstilling, gennemgås følgende fire punkter: Interface - Modulets eksterne interface. Analyse - Indeholder en kort analyse, baseret på de opstillede krav i kravspecifikationen. Algoritmer - Indeholder en beskrivelse af de algoritmer, modulet benytter sig af. Modultest - Beskriver hvordan modulet testes. Hvis der ikke er behov for et af punkterne, udelades punktet. 7. Brætopstilling 7.. Interface Dette modul stiller følgende eksterne funktioner til rådighed: board t* app table board init(void) - Initialiserer brættet med brikkerne i startopstillingen. int app table get fieldinfo(coord t coord) - Returnerer feltinformationen for koordinatet coord. board t* app table get board(void) - Returnerer opstillingen på skakbrættet. int app table update fieldinfo(coord t coord, piece t piece) - Opdaterer feltinformationen for et felt. int app table perform sequence(board t b, sequence t* sequence) - Opdaterer et bræt med en sekvens af flytninger. void app table get board copy(board t* board cpy) - Henter en kopi af brættet, og gemmer det i board cpy. Ingen af disse funktioner er beskrevet nærmere, da implementationen er triviel Analyse Dette modul har til formål at opfylde det funktionelle krav Brætopstilling beskrevet i kravspecifikationen. Modulet skal indeholde den aktuelle brætopstilling med information om, hvor der står brikker, og hvilken farve og type de er.modulet skal desuden være i stand til at opdatere feltinformationerne. 39

41 KAPITEL 7. MODULDESIGN AF APPLIKATIONSLAG I 7..3 Modultest Der designes en test driver, der er i stand til at kalde app table board init(), og derefter app table get fieldstate(), for dermed at kontrollere at brættet initialiseres korrekt, og felterne har den korrekte feltinformation. Derudover skal driveren kalde app table update fieldstate() og app table perform sequence(), for at teste opdateringen af brættet. Opdateringen verificeres ved at kalde app table get board() og app table get board copy(). 7.2 Logik 7.2. Interface Dette modul stiller følgende eksterne funktioner til rådighed: int main() - Udførslen af programmet startes her. Derudover har modulet en del interne funktioner, deriblandt spillers tur og modspillers tur, jf. afsnit og afsnit Disse funktioner er gennemgået i detaljer i kravspecifikationen og er derfor ikke beskrevet nærmere Analyse Afviklingen af spillet sker i Logik, hvilket betyder programmet starter i dette modul. Logik varetager derfor alle nødvendige funktionaliteter, der kræves for at spille et spil skak ved at kalde andre moduler. Desuden skal prototypen være i stand til at genkende specialtilfælde, jf. det funktionelle krav Håndter specialtilfælde, og håndtere en slået brik, jf. det funktionelle krav Håndter slået brik Modultest Der er ikke designet en modultest til Logik, da dette modul testes som en del af accepttesten. 40

42 Kapitel 8 Moduldesign af applikationslag II Algoritmerne er beskrevet efter en metode baseret på [Cormen et al., 200] og [David, 2006]. Metoden består af følgende punkter:. Interface - Beskrivelse af det interface, som algoritmen skal stille til rådighed. 2. Analyse - Problemet, der ønskes løst, analyseres med det formål at få en bedre forståelse af problemets elementer. 3. Input/output - Input og output til og fra algoritmen beskrives, og hvis der er krav til input og begrænsninger ved output beskrives disse. 4. Beskrivelse - Problemet konkretiseres og algoritmen beskrives overordnet. Idéen bag algoritmen og dens virkemåde forklares, eventuelt ved hjælp af eksempler. Der forklares hvorfor algoritmen løser problemet, og der argumenteres for, at algoritmen er en god løsning til problemet. 5. Pseudokode - Algoritmen beskrives i pseudokode, og linjerne i pseudokoden beskrives efter hver funktionen. 6. Opsplitning - Hvis algoritmen indeholder delalgoritmer, inkluderes et opsplitningspunkt, hvor hver delalgoritme beskrives kort. Hver delalgoritme designes herunder som en ny algoritme (vha. samme metode), dog med undtagelse af punkt (interface) og 2 (analyse), da interfacet er fastlagt, og analysen foretaget. 8. Flytningsalgoritme 8.. Interface Dette modul stiller følgende ekstern funktion til rådighed: void app move algo(board t board,coord t src, coord t dest, sequence t* moves) - Beregner en sekvens af flytninger for at udføre trækket fra src til dest. I det følgende er designet af denne funktion beskrevet Analyse Som nævnt i projektbeskrivelsen er en af MSP ens opgaver at beregne, hvordan brikkerne skal flyttes rundt, for det er muligt at flytte en bestemt brik fra et sted til et andet. Dette kan blive en stor logistisk opgave, da robothovedet kun kan flytte i linjer parallelt med skakbrættets kanter, og da brikker ikke kan passere felter, hvor der står andre brikker. Som eksempel kan 4

43 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II situationen på figur 8. betragtes. Hvis løberen på C skal flyttes til F4, er det nødvendigt at flytte nogle af de øvrige brikker, før løberen kan passere. Efterfølgende skal de midlertidligt flyttede brikker flyttes tilbage igen. Ö Ð Ò 8 ÓÔÓÔÓÔÓÔ 7 ¼ Ò ¼ ¼ 6 ¼ ¼ ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ È ¼ ¼ 3 ÈÇÈ ÈÇÈÇ 2 ËÆ ÉÂ ÅÊ a b c d e f g h Figur 8.: Eksempel på brikker, der står i vejen for en flytning af løberen fra C til F4. Der er mange forskellige måder, denne flytning kan finde sted på. F.eks. kan man flytte løberen i lige linjer (C-C4 efterfulgt af C4-F4), og her er det nødvendigt først at flytte bonden på C2 (f.eks. til D2), før det kan lade sig gøre. Når løberen er flyttet, skal bonden flyttes tilbage. En anden mulighed ville være at flytte løberen i zigzag (C-C2, C2-D2, D2-D3, etc.), men denne situation kræver mere arbejde, da der er flere brikker, der står i vejen (bønderne på C2 og D3) Input/Output Input:. En given opstilling af brikker på et skakbræt. 2. En ønsket flytning af en enkelt brik, til et tomt felt. Output:. En gyldig sekvens af felttræk hvor det endelige resultat er den ønskede flytning. En sekvens af felttræk betegnes gyldig, hvis der hverken er ulovlige felttræk eller ligegyldige felttræk. Et ulovligt felttræk er et felttræk af en brik til et felt, hvor der allerede står en brik eller et felttræk af en brik til et felt udenfor brættet. Et ligegyldigt felttræk er et felttræk af en brik, der ikke eksisterer. Det ønskes ikke at finde den optimale løsning, men én korrekt løsning, som er en approksimation af den optimale Beskrivelse Selv når det er en approksimation af en optimal løsning, der ønskes fundet, er der mange kombinationer. Derfor vælges en algoritme, der består af tre skridt.. Der genereres en række mulige simple ruter for brikken, der skal flyttes. For hver af disse ruter kan der være brikker, der står i vejen, og som skal fjernes midlertidigt, så brikken kan passere. Den rute, hvor der står færrest brikker i vejen, gemmes som en sekvens af flytninger, der vil flytte brikken langs ruten uden hensyn til evt. brikker, der står i vejen. Denne sekvens benyttes i næste skridt. 2. Dette skridt vil beregne en sekvens af flytninger, som vil fjerne de brikker, der står i vejen, fra ruten. Der vil være flere mulige sekvenser, men de vil ikke nødvendigvis være lige gode, da nogle vil kræve flere flytninger end andre. 42

44 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II Den teoretiske kørselstid for algoritmen i værste tilfælde er lang, og hvis det ønskes at gennemsøge og vurdere alle mulige sekvenser, vil det muligvis i nogle situationer være hurtigere blot at benytte en allerede fundet, gyldig sekvens frem for at gennemsøge alle resterende kombinationsmuligheder for en bedre sekvens. Der tages ikke hensyn til dette, i stedet benyttes den bedste af de gyldige sekvenser, der er fundet til slut. 3. Dette skridt samler resultaterne fra de tidligere skridt til en samlet sekvens, der udfører hele trækket. Denne sekvens vil, i rækkefølge, bestå af: sekvensen til fjernelse af brikker på ruten (fra skridt 2), flytning af brikken langs ruten (fra skridt ), og baglæns udførsel af sekvensen til fjernelse af brikker (fra skridt 2). På denne måde vil den endelige sekvens først fjerne alle brikker, der står i vejen på den valgte rute, dernæst flyttes brikken langs stien, og til slut ryddes op ved at flytte de øvrige brikker tilbage på deres plads Pseudokode function move algo ( board, move) 2 begin 3 path seq create path (board, move ) ; 4 away seq clear path ( board, path seq ) ; 5 back seq revert sequence ( away seq ) ; 6 return away seq + path seq + back seq ; 7 end 8..6 Opsplitning Ovenstående pseudokode splitter løsningen af algoritmen op i tre forskellige delalgoritmer. De to første vil efterfølgende hver blive behandlet i et afsnit for sig. Kort kan opgaven for delalgoritmerne beskrives som: create path() har til opgave at generere en nær optimal, sammenhængende sekvens af felttræk, som resulterer i, at det ønskede træk bliver udført, uden at tage højde for at flytte brikker, der står i vejen. Dog skal den forsøge at minimere antallet af brikker, der står i vejen af den rute, den genererer, men uden at generere en omsonst rute. create path() beskrives i afsnit 8.2. clear path() skal lave en sekvens af felttræk, der flytter alle brikker væk fra den rute, som er genereret af create path(). Den skal tage højde for eventuelle brikker, der står i vejen, ved at fjerne dem fra stien. Denne sekvens ønskes ligeledes så nær optimal som muligt. To vigtige krav er, at delalgoritmen ikke flytter på den brik, der skal flyttes i trækket, og at den ikke placerer en brik på det felt, brikken skal flytte til. clear path() beskrives i afsnit 8.3. revert sequence() skal vende en sekvens modsat, så første felttræk i stedet bliver det sidste modsatte felttræk. Hvis f.eks. det første feltræk er brikken på A3 til højre (til B3), skal det sidste felttræk være B3 til venstre. revert sequence() beskrives ikke nærmere. 8.2 Flytningsalgoritme - create path() 8.2. Input/Output Input: En opstilling af skakbrikker. Et skaktræk, f.eks. A til C3. Output: En sekvens af felttræk der beskriver flytningen af brikken langs den beregnede sti, som tager hensyn til antallet af optagede felter i ruten. 43

45 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II Beskrivelse Problemet kan opstilles som et ønske om at finde den minimale rute gennem en orienteret graf, hvis de mulige retninger i hvert felt begrænses til kun at omfatte de to, der leder tættere på slutfeltet. Hvis det f.eks. ønskes at flytte en brik fra D3 til F6, og algoritmen, efter nogle flytninger, er nået til feltet E4, vil mulige retninger være F4 (til højre) og E5 (fremad). Retningerne E3 (bagud) og D4 (til venstre) er ikke gyldige, da de leder væk fra slutfeltet. En rute, der opfylder disse kriterier, benævnes en direkte rute. a b a2 c b2 a3 c2 b3 c3 Figur 8.2: Orienteret graf for træk fra A til C3, med begrænsede retninger. På figur 8.2 kan det ses, hvordan den orienterede graf for et ønsket træk fra A til C3 ser ud. I den orienterede graf peger retningen for forbindelserne peger nedad, se figur 8.2. Ved at lægge vægte som henholdsvis 0 og, på forbindelserne i grafen, afhængig af, om der står en brik på det felt forbindelsen peger på, kan problemet løses ved at benytte en generel algoritme til at finde den korteste rute i en orienteret graf. Yderligere kan løsningen forenkles, da den fremkommende graf aldrig vil indeholde cykler; alle ruter vil altid ende i slutfeltet og der eksisterer ingen negative vægte. ¼ ¼ ¼ ¼ 8 ¼ ¼ ¼ ¼ 7 ¼ ¼ ¼ ¼ 6 ¼ ¼ ¼ ¼ 5 ¼ ¼ ¼ ¼ 4 ¼ ¼ ¼ ¼ 3 ÔÓ¼ ¼ ¼ 2 ¼ ¼ ¼ ¼ a b c d e f g h Figur 8.3: Opstilling før trækket A-C3. Som eksempel tages udgangspunkt i trækket fra A til C3, og opstilling som i figur 8.3. Det ønskes at finde en direkte rute for flytning af løberen på A til C3, hvor færrest mulige felter, med andre brikker på, passeres. Derved bliver den orienterede graf med vægte, som vist på figur

46 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II a 0 b a2 0 c b2 a c2 b3 0 0 c3 Figur 8.4: Orienteret graf for trækket fra A til C3 med vægte. Den mest komplicerede graf forekommer, hvis der vælges et træk fra ét hjørne af skakbrættet til det modsatte hjørne. Antallet af mulige veje til slutfeltet kan vises ved at tegne en graf med alle 64 felter, og skrive antallet af mulige veje til hvert enkelt felt, startende fra toppen. Hvert felt har et bestemt antal mulige veje, hvor det antal veje, et felt har, er summen af de veje, de felter, der peger på det, har. Det er skrevet ud i figur 8.5, og det ses, at der er 3352 mulige kombinationer i den værst mulige situation. Med højest 3352 muligheder er det realistisk at søge dem alle igennem, for at finde den kortest vægtede rute. Generelt er der meget færre muligheder, der skal søges igennem, da skaktræk som regel er kortere. Da grafen er en såkaldt vægtet, ikke-cyklisk og orienteret graf, benyttes en algoritme til at finde korteste rute i sådan en type graf fra [Cormen et al., 200]. Algoritmen er modificeret i forhold til den originale udgave, da forbindelserne og vægtene i den graf, der forekommer i dette projekt er i et meget bestemt mønster, og derfor nemt kan udregnes løbende, og fordi grafen nemt kan løbes igennem topologisk 2. På figur 8.6 ses to eksempler på hvordan grafen kan gøres topologisk. Den første metode, A, er mest logisk set fra den originale graf, mens den anden metode, B, giver mest mening set fra de faktiske koordinater på skakbrættet. Da det ønskede træk modtages i koordinater i forhold til et skakbræt, benyttes metode B. Metode B fremkommer ved at løbe punkterne, som svarer til skakfelterne, igennem, i den orden de er på skakbrættet, i kolonner og derunder i rækker. De to retninger løbes igennem enten negativt eller positivt, afhængig af om henholdsvis x- og y-koordinatet for destinationen er mindre eller større end udgangspositionen. Dvs. hvis et ønsket træk er fra koordinat F4 til C6, løbes der positivt i talretningen og derunder negativt i bogstavsretningen. Som det ses på figur 8.7, er der ingen forbindelser fra den ene række eller kolonne til den forrige, derfor vil ordenen være topologisk ved gennemløb af talretningen og derunder bogstavsretningen, men også ved gennemløb af bogstavsretningen og derunder talretningen. Et punkt kan maksimalt have to nabopunkter, og det eneste punkt, som ikke har nogle nabopunkter, er det sidste punkt. Som det ses af figur 8.7 har alle punkter, der ikke har samme x eller y koordinat som destinationsfeltet, to nabopunkter. Ydermere er nabopunkterne, pr. definition, beliggende i retning af destinationsfeltet. På engelsk: directed acyclic graph (DAG) 2 En topologisk, sorteret, orienteret og ikke-cyklisk graf betegnes her som en topologisk graf. En topologisk graf er en graf, hvor alle punkterne er placeret på en vandret linje, og hvor alle forbindelser går fra venstre mod højre. Se A og B på figur

47 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II x Figur 8.5: Antal mulige veje at komme til hver punkt i et træk fra A til H8. Hvert tal repræsenterer et punkt i grafen (et felt på skakbrættet), og peger på de to punkter (tal) umiddelbart under (til venstre og til højre). Vægtene til nabopunkterne findes løbende, og defineres som 2, hvis nabopunktet er et kantpunkt, som, hvis der står en brik på nabopunktet og 0, hvis der ikke står en brik på nabopunktet. På denne måde findes den sti fra udgangspunktet til destinationspunktet med færrest mulige brikker på. Dog med undtagelse af kantpunkterne, hvor det foretrækkes at benytte et felt, der er optaget af en brik. Kantpunkterne vil dog blive benyttet, hvis det er den eneste mulige rute, f.eks. ved et træk fra A til A6. Kantpunkterne nedprioriteres, da algoritmen til at flytte brikker væk, kan løbe ind i problemer på kantfelterne. Algoritmen er dermed forsimplet til ikke at skulle sortere grafen topologisk først, men kan løbe den igennem i henholdsvis den ene retning (f.eks. -3), og derunder den anden retning (f.eks. A-C), og samtidig finde og udregne vægte til nabopunkterne Pseudokode function create path ( board, move) 2 begin 3 global d ; 4 global pi n i l ; 5 d [ move. src. x ] [ move. src. y ] 0; 6 7 if move. src. x < move. dst. x then 8 xdir ; 9 else if move. src. x = move. dst. x then 0 xdir 0; else 2 xdir ; 3 4 if move. src. y < move. dst. y then 5 ydir ; 6 else if move. src. y = move. dst. y then 7 ydir 0; 46

48 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II a A) a 0 b a2 c b2 0 b a2 0 c b2 a a3 c2 b3 c c2 0 0 b3 0 B) 0 0 a a2 a3 b b2 0 0 c3 b3 0 0 c c2 c3 0 Figur 8.6: Konvertering af tidligere eksempel til topologisk orienteret graf. 8 else 9 ydir ; 20 2 for x move. src. x to move. dst. x do 22 begin 23 for y move. src. y to move. dst. y do 24 begin 25 if x!= move. dst. x then 26 begin 27 if [ x + xdir, y ] i s an edge then 28 weig ht 2; 29 else if piece on board [ x + xdir, y ] 30 weig ht ; 3 else 32 weig ht 0; 33 relax ( [ x, y ], [ x + xdir, y ], weight ) ; 34 end 35 if y!= move. dst. y then 36 begin 37 if [ x, y + ydir ] i s an edge then 38 weig ht 2; 39 else if piece on board [ x, y + ydir ] 40 weig ht ; 4 else 42 weig ht 0; 43 relax ( [ x, y ], [ x, y + ydir ], weight ) ; 44 end 45 end 46 end res n i l ; 49 u move. dst ; 50 while u!= move. src do 47

49 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II f4 8 e4 f5 7 6 d4 e5 f6 5 4 c4 d5 e6 3 2 c5 d6 a b c d e f g h c6 Figur 8.7: Graf for trækket F4 til C6, vist i form af en graf og på skakbrættet. 5 begin 52 nu pi [ u ] ; 53 push front ( res, (nu, direction of u from nu ) ) ; 54 u nu ; 55 end return res ; 58 end Ovenstående funktion er en implementation af algoritmen til at finde den korteste rute fra et punkt til alle punkter i en orienteret ikke-cyklisk graf fra [Cormen et al., 200]. Linje 3 til 5 initialiserer arrayene d og pi. d er et array indeholdende en værdi for den korteste rute til et givet punkt i grafen der er fundet. Alle elementerne i arrayet initialiseres til, da der i starten ikke kendes nogle ruter til de forskellige punkter, dog lige med undtagelse af udgangspunktet, som initialiseres til 0, da afstanden til denne er 0. pi indeholder for hvert punkt, A, i grafen et koordinat. Dette koordinat skal ende med at pege på det punkt, B, af de punkter B, C, D, etc., der peger på punktet, A, og som har den korteste rute til punktet A. Linje 7 til 9 initialiserer variablene xdir og ydir med enten -, 0 eller afhængig af om der flyttes i den positive, negative retning, eller ikke flyttes, på x- og y-akserne. Linje 2 til 46 implementerer selve algoritmen. De to for-løkker sørger for at løbe alle punkterne igennem i en topologisk rækkefølge, som tidligere beskrevet, og gør det derved unødvendigt at sortere grafen topologisk på forhånd. Da der kun er to mulige retninger i et givet punkt, tjekkes det, om grænsen for hvor langt der skal flyttes på en given akse er nået, ved hjælp af xdir og ydir. Hvis denne grænse ikke er nået, antages det, at der befinder sig et punkt, og et felt på skakbrættet, i denne retning. relax() kaldes derpå, som foreskrevet i den originale algoritme (DAG algoritmen fra [Cormen et al., 200]). relax() kaldes med tre parametre, den første er det nuværende felt, den næste er et felt som det nuværende felt peger på, og den sidste er vægten for forbindelsen mellem netop disse felter. Vægten bestemmes til enten 0, eller 2, og afhænger, som tidligere beskrevet, af, om der står en brik, på det felt, der peges på. Til slut, i linje 48 til 55, løbes arrayet pi igennem fra destinationsfeltet til udgangspunktet, og en resultatsekvens (res) opbygges af den korteste vægtede rute. I linje 57 returneres denne sekvens. function relax ( pkt, pkt2, weight ) 48

50 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II 2 begin 3 if d [ pkt2 ] > d [ pkt ] + weight then 4 begin 5 d [ pkt2 ] d [ pkt ] + weight ; 6 pi [ pkt2 ] pkt ; 7 end 8 end Ovenstående er en direkte implementering af relax algoritmen fra [Cormen et al., 200], dog med undtagelse af vægten, som beskrives direkte. Hvis den korteste kendte rute til punktet pkt2 er større end ruten til pkt plus vægten mellem pkt og pkt2, er ruten gennem pkt en hurtigere rute til pkt2. I dette tilfælde erstattes den korteste kendte rute til pkt2, med den fundne kortere rute. Ligeledes opdateres arrayet pi med koordinatet til pkt som den korteste vej til punktet pkt Flytningsalgoritme - clear path() 8.3. Input/Output Input:. En given opstilling af brikker på et skakbræt. 2. En ønsket flytning af en enkelt brik, til et tomt felt. Dette definerer også den sti, brikken skal følge, og som skal ryddes. Output:. En gyldig sekvens af felttræk, som flytter alle brikker, der står i vejen, væk fra stien Beskrivelse Denne algoritme er delt op i to funktioner, som kan løse forskellige dele af problemet, og som tilsammen giver det ønskede resultat. Det ønskes at rydde en bestemt sti for brikker, og det vil den overordnede funktion i algoritmen, clear path(), tage sig af. Undervejs vil det være nødvendigt at fjerne de enkelte brikker, der står i vejen, fra stien, og den anden funktion i algoritmen, clear field(), vil netop være i stand til dette. I eksemplet i figur 8.8, ønskes det at flytte løberen fra C til F4. I figuren er stien repræsenteret ved den røde pil, og det ses, at der står to brikker i vejen a b c d e f g h Figur 8.8: Eksempel på inputtet til clear path(). Den røde pil angiver stien, som løberen skal følge. 49

51 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II Algoritmens overordnede funktion, clear path(), gennemløber alle felterne i stien, undtagen det første, hvor brikken, der skal flyttes, står på, og det sidste, hvor brikken skal flyttes til. I eksemplet vil det sige felterne: C2, D2, D3, E3 og E4. Feltet F4 er ikke en del af stien, da retningen af stien på E4 afgør, hvor stien ender. For hvert felt vil funktionen clear field() blive kaldt. Det er denne funktion, der beregner, hvordan en eventuel brik skal fjernes fra stien, og den beskrives senere i dette afsnit. For at undgå, at clear field() i sidste ende placerer brikker på den del af stien, der allerede er ryddet, eller på det endelige destinationsfelt, føres der løbende regnskab med felter, hvor brikkerne, der skal fjernes, ikke må flyttes hen. Ved initialisering sættes start- og destinationsfelterne, C og F4 i eksemplet, til såkaldte don t move -felter. Don t move-felter vil aldrig blive undersøgt af clear field(). Startfeltet må ikke undersøges, da det er her den brik, der skal flyttes, står. Destinationsfeltet må ikke undersøges, da det skal være muligt at udføre den endelige sekvens, der fjerner brikkerne fra stien, baglæns, vha. revert sequence(). Hvis sekvensen undervejs benytter destinationsfeltet, vil der opstå kollisioner, da der nu står en brik på det felt. I eksemplet vil brikken fra C blive flyttet til F4, efter at brikkerne er fjernet fra stien jf. afsnit Det er enkelt at gennemløbe stiens felter, som det skal ske i clear path(), når det kan antages, at clear field() er i stand til at fjerne brikkerne undervejs. Samtidig holdes clear field() simpel, da den kun skal beskæftige sig med at fjerne en enkelt brik af gangen og gemme sekvensen af felttræk, der udfører dette. clear path() Resultatet af funktionen er en samlet sekvens af felttræk, der fjerner alle brikker, der står i vejen, fra stien. Der ses et øjeblik bort fra, hvordan brikkerne rent faktisk bliver fjernet fra stien, da det er den opgave, clear field() tager sig af. Forløbet af funktionen er:. Start- og destinationsfelterne markeres som don t move-felter. 2. Stiens resterende felter gennemløbes fra start til slut. (a) Hvis feltet ikke er ledigt, vil clear field() blive kaldt, for at finde den bedste sekvens til at fjerne brikken på netop det felt i stien. Dernæst opdateres funktionens midlertidige bræt med sekvensen fra clear field(), så udgangspunktet for næste iteration er korrekt; dvs. at brikken er fjernet fra feltet på stien, før det næste felt behandles. Desuden tilføjes sekvensen fra clear field(), til den samlede sekvens, der i sidste ende vil rydde hele stien. (b) Feltet bliver tilføjet til listen over don t move-felter. På denne måde vil der aldrig blive flyttet brikker ind på den del af stien, der allerede er ryddet. I figur 8.9 ses, hvordan forløbet af clear path() vil være i eksemplet, når der ses bort fra detaljerne i clear field(). Den faktiske placering af brikkerne kan afvige, men dette er underordnet i forhold til forståelsen af clear path(). I figur 8.9a ses udgangspunktet, hvor start- og destinationsfelterne er markerede som don t move-felter (sort). I figur b, c og d gennemløbes resten af stien, og efterhånden tilføjes felterne til listen over don t move-felter. På figur b ses et eksempel på, hvordan clear field() kunne vælge at fjerne brikken på C2. De berørte brikker er markeret med grøn, og sekvensen, der flytter brikkerne kunne f.eks. være C3 fremad, C2 fremad. På figur c er der ingen brikker på stiens næste felt, D2, og derfor markeres det blot som et don t move-felt. På figur d fjernes brikken fra D3 med sekvensen D3 fremad. Resten af felterne på stien er ledige, og derfor afslutter løkken, når den har gennemløbet dem. Den endelige sekvens vil i dette tilfælde være kombinationen af sekvenserne fra clear field(), det vil sige C3 fremad, C2 fremad, D3 fremad, som fjerner alle brikker, der står i vejen, fra stien. Dette leder op til beskrivelsen af algoritmens anden funktion, clear field(). clear field() Denne funktions opgave, er som beskrevet, at finde en sekvens af felttræk, der sørger for, at et felt på stien bliver ledigt. Da der ofte ikke findes et ledigt nabofelt til den 50

52 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II a b c d e f g h a b c d e f g h a) b) a b c d e f g h a b c d e f g h c) d) Figur 8.9: Eksempel på et forløb af clear path(). Den røde pil angiver stien, løberen skal følge. De sorte felter er markeret som don t move -felter, mens brikker markeret med grøn er flyttet af clear field() på det viste skridt. brik, der skal fjernes fra stien, skal funktionen skrives som en rekursiv funktion, der kalder sig selv i det tilfælde, at det er nødvendigt først at fjerne en brik fra et nabofelt. På denne måde gennemsøger funktionen en træstruktur for at finde gyldige sekvenser, der tømmer det felt, funktionen har fået som parameter. Da der i et spil skak maksimalt er 32 brikker vil funktionen aldrig kunne kalde sig selv mere end 30 gange 3. Når clear field() kaldes, er forløbet som følger:. Det undersøges, i hvilke retninger brikken, der skal fjernes, kan flyttes. Som udgangspunkt kan brikken bevæges i lodrette og vandrette linjer på brættet. Dog må brikken aldrig flyttes ud af brættet eller tilbage på et don t move-felt, så disse retninger vil blive ekskluderet fra listen over retninger, brikken kan flyttes i. 2. Funktionen løber gennem de mulige retninger en af gangen i rækkefølgen: fremad, venstre, højre og bagud. 4 For hver retning testes det, om feltet i retningen er ledigt. (a) Hvis feltet i en retning er ledigt, er der fundet en mulig løsning, da brikken blot kan flyttes hen på det tomme felt. Sekvensen, der er opbygget i de tidligere kald til clear field() kombineret med felttrækket hen på det ledige felt, sammenlignes med 3 clear field() bliver aldrig kaldt for den brik, der skal flyttes langs stien, og det første kald til funktionen foretages af clear path(). Dermed er der maksimalt 30 brikker tilbage, som funktionen kan kalde sig selv for. 4 Dette er muligvis ikke den mest optimale rækkefølge, men det er vigtigt, at rækkefølgen er veldefineret. 5

53 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II den hidtil bedste sekvens. Hvis den nye er bedre, gemmes den. Dernæst returnerer funktionen. (b) Hvis feltet i en retning ikke er ledigt, kalder funktionen sig selv med nabofeltet i retningen som parameter, så det felt tømmes. Inden funktionen kalder sig selv, vil det felt der skal tømmes, desuden blive tilføjet til listen over don t move-felter, således at det rekursive kald til funktionen ikke forsøger at flytte brikken tilbage til det felt, den blev kaldt fra. I princippet foretager clear field() en depth-first search 5 i træstrukturen, hvor samtlige mulige kombinationsmuligheder testes. Dette er sandsynligvis ikke den mest optimale fremgangsmåde; breadth-first search 6 kunne muligvis give et bedre resultat hurtigere. Men da algoritmen skal køre på en MSP med begrænset hukommelse, er det ikke muligt at benytte breadth-first search a b c d e f g h a b c d e f g h a) b) a b c d e f g h a b c d e f g h c) d) a b c d e f g h e) Figur 8.0: Eksempel på et forløb af clear field(), hvor brikken på C2 skal fjernes. De sorte felter er markeret som don t move -felter, mens det felt, clear field() arbejder på, er markeret med grøn. Den lille røde pil angiver, i hvilken retning nabofelterne gennemsøges. For at illustrere, hvordan clear field() virker, vil detaljerne i skridt b i figur 8.9, hvor brikken på C2 fjernes, blive gennemgået. Ved starten af skridtet kaldes clear field() med feltet C2 som parameter af clear path(). Denne situation er illustreret i figur 8.0. Som tidligere er don t movefelterne markeret med sort i figuren, og det felt, som clear field() er i færd med at tømme, 5 Depth-first search gennemsøger træet i dybden, før der søges i bredden. 6 Breadth-first search gennemsøger træet på tværs, og dernæst i dybden. 52

54 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II er markeret med grøn. Den lille røde pil angiver, i hvilken retning clear field() gennemsøger nabofelterne. Her følger en gennemgang af de forskellige stadier i figur 8.0: a) clear field() er kaldt på feltet C2, og funktionen markerer først dette felt som don t movefelt og undersøger i hvilke retninger, det er muligt at flytte brikken. I rækkefølge er retningerne fremad, venstre og højre mulige. Bagud er et don t move-felt, og det er derfor ikke muligt at flytte brikken i den retning. Retningerne afprøves en ad gangen, og der startes med fremad. Der står en brik på feltet fremad, så clear field() gemmer felttrækket C2 fremad i sekvensen, og kalder dernæst sig selv på feltet C3. b) clear field() er kaldt på feltet C3, og situationen er næsten den samme som før. De mulige retninger er fremad, venstre og højre, da bagud blev markeret som don t move-felt af den kaldende funktion. Denne gang er der imidlertid ingen brik på feltet fremad, som gennemsøges først. Derfor kan felttrækket C3 fremad umiddelbart tilføjes til sekvensen, og dermed er der fundet en mulig sekvens, der fjerner brikken på C2. Denne sekvens, C3 fremad, C2 fremad, sammenlignes med den hidtil bedste sekvens, men da der ikke er en tidligere sekvens, vil denne blive gemt som den bedste, og funktionen returnerer til den kaldende funktion. c) Nu vil den tidligere clear field(), der blev kaldt på feltet C2, fortsætte sin gennemsøgning af nabofelterne, efter at den har fjernet sit tidligere felttræk, C2 fremad, fra sekvensen. Den næste retning er venstre, så felttrækket C2 venstre vil blive tilføjet sekvensen, og clear path() vil blive kaldt på feltet B2. d) På feltet B2 er de mulige retninger i rækkefølge: fremad, venstre og bagud. Fremad bliver testet først, og i den retning er et ledigt felt. Derfor tilføjes felttrækket B2 fremad til sekvensen, og den samlede sekvens B2 fremad, C2 venstre sammenlignes med den hidtil bedste sekvens. Da denne sekvens ikke er kortere (begge er på to felttræk), ignoreres den blot, og funktionen returnerer. e) Tilbage i det oprindelige kald til clear field() fjernes felttrækket C2 venstre igen, og som den sidste mulige retning testes højre. Der er et ledigt felt i den retning, og derfor tilføjes felttrækket til sekvensen. Denne sekvens er kortere end den hidtil bedste, da den kun består af ét felttræk, og derfor vil den blive gemt. Herefter returnerer funktion til clear path(), der nu vil kende den korteste sekvens, der fjerner brikken fra C2. Resultatet af kaldet til clear path() på feltet C2 er altså sekvensen C2 højre. Og det er denne sekvens, der anvendes i den færdige sekvens til at flytte netop brikken på C2 væk fra feltet. Denne sekvens resulterer i, at brikken flyttes hen på det næste felt i stien, men det er ikke et problem, da clear path() netop vil kalde clear field() på dette felt efterfølgende Pseudokode function clear path ( board, path seq ) 2 begin 3 d e s t i n a t i o n field g e t d e s tination f i e l d ( path seq [ length ( path ) ] ) ; 4 push (dont move, path seq [ 0 ] ) ; 5 push (dont move, d e s t i n a t i o n field ) ; 6 for i to length ( path seq ) do 7 begin 8 if path seq [ i ] i s not empty do 9 begin 0 global best sequence n i l ; c l e a r f i e l d ( board, path seq [ i ], dont move, n i l ) ; 2 apply sequence ( board, revert sequence ( best sequence ) ) ; 53

55 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II 3 push( result sequence, revert sequence ( best sequence ) ) ; 4 end 5 push( dont move, path seq [ i ] ) ; 6 end 7 return result sequence ; 8 end Funktionen clear path() kaldes med to parametre: board, som indeholder status for brikkerne på skak-brættet, og path seq, som specificerer den sti, der skal fjernes brikker fra. I linje 3 beregnes, hvilket felt, brikken skal ende på. Dette er nødvendigt, da path seq s sidste element kun indeholder flytningen hen på destinationsfeltet. I linje 4-5 tilføjes start- og destinationsfelterne til dont move array et, så disse felter aldrig bliver berørt af clear field(). Dernæst følger løkken, som løber felterne på stien igennem et for et for at fjerne eventuelle brikker, der står i vejen (linje 6-6). På linje 8 checkes om feltet er ledigt. Hvis ikke feltet er ledigt, udføres linjerne 0-3. På linje 0 introduceres den globale variable best sequence, som løbende opdateres med den bedste sekvens til at fjerne brikken på det aktuelle felt. best sequence initialiseres til nil, da der endnu ikke er fundet en gyldig sekvens. clear field() bliver kaldt for at finde den bedste sekvens til fjernelse af brikken på det aktuelle felt. clear field() vil gemme den bedste sekvens den finder i best sequence. Efterfølgende kaldes funktionen apply sequence() (linje 2), som modificerer skakbrættet ved at udføre den fundne sekvens, således brættet er klar til næste kald til clear field(). I linje 3 tilføjes den bedste fundne sekvens til result sequence. Bemærk kaldene til revert sequence() i linje 2 og 3. Disse kald skyldes, at clear field() opbygger sekvensen baglæns, og derfor skal sekvensen udføres og gemmes i modsat rækkefølge. I linje 5 i slutningen af løkken tilføjes det behandlede felt til dont move-felterne. function c l e a r f i e l d ( board, field, dont move, build sequence ) 2 begin 3 push (dont move, f i e l d ) ; 4 p o s s i b l e d i re c tions a l l directions except : 5 ( f i e l d s beyond the border of the board, 6 directions towards dont move f i e l d s ) ; 7 for each direction in p o s si b l e d i rections do 8 begin 9 d e s t i n a t i o n f i e l d g e t d e s t i n a t i o n f i e l d (( field, direction ) ) ; 0 if d e s t i n a t i o n field i s empty then begin 2 push( build sequence, move towards d e s t i n a t i o n f i e l d ) ; 3 s a v e i f b e s t ( build sequence ) ; 4 return ; 5 end 6 else 7 begin 8 push( build sequence, move towards d e s t i n a t i o n f i e l d ) ; 9 c l e a r f i e l d ( board, d e s tination field, dont move, build sequence ) ; 20 pop( build sequence ) ; 2 end 22 end 23 return ; 24 end Funktionen clear field() bliver kaldt med følgende parametre: board - Indeholder status for brikkerne på skak-brættet. field - Specificerer hvilket felt, der skal tømmes. 54

56 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II dont move - Array, der indeholder don t move-felterne. build sequence - Den opbyggede sekvens fra den kaldende funktion. På linje 3 tilføjes feltet, der skal tømmes, til listen over don t move-felter. I linjerne 4-6, opbygges en liste over mulige retninger, brikken kan flyttes i. Linje 7-22 indeholder en løkke, der løber hver af de mulige retninger igennem. På linje 9 afgøres koordinaterne til destinationsfeltet, dvs. nabofeltet i den aktuelle retning. I linje 0 checkes det, om destinationsfeltet er ledigt. Er dette tilfældet, er der fundet en mulig løsning, og linjerne 2-4 udføres. I linje 2 tilføjes felttrækket i den aktuelle retning til den opbyggede sekvens. I linje 3 kaldes funktionen save if best(), som gemmer sekvensen, hvis den er bedre end den hidtil bedste funde sekvens til fjernelse af brikken. Dernæst returnerer funktionen (linje 4), da gennemsøgning i de resterende retning ikke kan resultere i en kortere sekvens. Er destinationsfeltet ikke ledigt, udføres linjerne På linje 8 tilføjes felttrækket i den aktuelle retning til den opbyggede sekvens. I linje 9 kalder funktionen sig selv for at fjerne brikken på destinationsfeltet. I linje 20 fjernes felttrækket i den aktuelle retning igen, så det ikke forstyrrer i næste iteration. Når alle mulige retninger er gennemløbet, returnerer funktionen (linje 23). 8.4 Skanningsalgoritme 8.4. Interface Dette modul stiller følgende ekstern funktion til rådighed. void app scan algo(coord t *moves, int number of moves, coord t current pos) - Kaldes med et array af typen coord t, og dermed de felter, der skal skannes. Funktionen permuterer arrayet, med rækkefølgen til hvordan felterne skal skannes. Denne funktion vil herefter blive beskrevet Analyse Skanningsalgoritmen skal, som beskrevet i kravspecifikationen, finde en nær optimal rute til skanning af en række punkter. Punkterne kan ligge vilkårligt på skakbrættet, dog kan robothovedet kun bevæge sig lodret og vandret. Dette betyder, at det ikke er muligt at betragte skrå flytninger som rette linjer, men derimod som vandrette og lodrette flytninger. Betragtes flytningen A-C4 er afstanden ikke kvadratroden af summen af den vandrette og lodrette flytning, (x 2 x ) + (y 2 y ). Derimod vil flytningen inkludere en flytning vandret, og en flytning lodret. Den samlede flytning er derfor summen af både den vandrette og den lodrette flytning, (x 2 x ) + (y 2 y ). Flytningen A-C4 er derfor en flytning over fem felter, se figur 8.. Der søges en algoritme, der besøger alle felter, og denne skal være nær optimal. Dette stiller krav til, at hvert felt kun må besøges én gang. En algoritme, der opfylder disse krav, kan være en algoritme, der løser TSP 7. TSP beskæftiger sig med problemet, hvor en salgsperson skal rejse til en række byer. Alle byer skal besøges, og når samtlige byer er besøgt, skal ruten gå tilbage til startbyen. Problemet er derfor, at finde en optimal rute til at besøge alle byer én gang, hvor der anvendes den korteste rute samlet set. Til dette benyttes et spanning-tree, der opbygges afhængigt af vægte, der beskriver afstanden mellem hvert punkt. Løbes alle punkter igennem, således den samlede sum af vægte er mindst, er ruten fundet. Opbygningen af et spanning-tree er som vist på figur 8.2, og beskrives som: 7 Travelling Salesman Problem 55

57 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II A B C A B C Figur 8.: Problematikken ved skrå flytninger. () (2) A D E G A D E G C B F C B F H H Figur 8.2: (): Et sæt punkter, alle med forskellige koordinater. (2): Der konstrueres et spanning-tree med start i punktet A, som resulterer i opbygningen på ABCHDEFG. Vægten mellem punkterne er illustreret i form af afstanden herimellem. Første punkt i punkt-sættet er udgangspunktet for træet, og er i eksemplet punktet A. Det beregnes hvilket punkt, der er tættest på spanning-tree et, der indtil videre kun består af A. Punktet, der er tættest på, er B, og dette tilføjes til spanning-tree et. Det beregnes, hvilket af de resterende punkter, der er tættest på spanning-tree et, i eksemplet C, og dette tilføjes. Udvidelsen fortsætter, og den endelige rækkefølge for opbygningen af spanning-tree et er: ABCHDEFG Input/Output Input:. Et usorteret sæt af koordinater til de felter, der skal skannes. 2. Den nuværende position af robothovedet. 3. Antallet af felter. Output:. Et array af koordinater, der er sorteret i den rækkefølge koordinaterne skal skannes i Beskrivelse En metode til løsning af TSP kræver en række forskellige skridt:. Der tildeles positive vægte mellem alle punkter, bestemt af afstanden mellem hver brik, se figur

58 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II 2. Et minimalt spanning-tree skabes med udgangspunkt i det første koordinat i inputtet, således alle punkter besøges. Med et minimalt spanning-tree menes, at der skabes et træ, hvor forbindelserne mellem punkterne er dannet ud fra den mindste sum af vægte, se figur 8.2. Da der skal bruges en rute i form af koordinater, som robothovedet skal navigere efter, dannes dette ud fra grenene i spanning-tree et. Dette giver en rute, i form af koordinater, som robothovedet kan anvende. 3. Det punkt, der skal startes ved i denne rute, bestemmes ud fra den nuværende position af robothovedet, så det punkt, der er nærmest robothovedet, vil være startpunktet Pseudokode function scan algo ( nodes, current position ) 2 begin 3 weight weight distribution ( nodes ) ; 4 movement create spanningtree ( nodes, weight ) ; 5 start index calc startindex (movement, current position ) ; 6 return (movement, start index ) ; 7 end Opsplitning Pseudokoden splitter algoritmen op i tre delalgoritmer. De tre funktioner weight distribution(), create spanningtree() samt calc startindex() beskrives overordnet i det følgende afsnit. weight distribution() kaldes med koordinaterne, skanningsalgoritmen skal sortere, og der tildeles vægte i en matrix mellem samtlige punkter. create spanningtree() beregner ud fra vægt-matricen et spanning-tree, indeholdende samtlige punkter. Beregningerne sker ved at gennemløbe vægt-matricen, og finde den node der ligger tættest på (0,0). Denne gemmes, og vægt-matricen gennemløbes fortsat, men nu med det mål at finde den node, der ligger tættest på det allerede opbyggede spanning-tree, som består af den første node. Spanning-tree et udbygges node for node på samme måde, ved at finde node en med lavest vægt ift. det nuværende spanning-tree, og tilføje denne til spanning-tree et. Dette giver et spanning-tree, der skal løbes igennem, for at finde den rute, robothoved skal køre. calc startindex() beregner, hvilket af koordinaterne i det permuterede array, der er placeret tættest på robothovedets nuværende position. Robothovedet kan dermed starte med at skanne på positionen tættest på dets nuværende position. Funktionen opfattes som triviel, og beskrives ikke nærmere. 8.5 Skanningsalgoritme - weight distribution() 8.5. Input/Output Input: Koordinaterne hvorimellem der skal beregnes vægte. Output: En matrice indeholdende samtlige vægte mellem hvert koordinat Beskrivelse De forskellige ruter mellem alle punkter tildeles vægte, bestemt af afstanden mellem punkterne. Det er krævet, at alle punkter kan opnåes fra alle punkter, og at der er vægte mellem alle punkter. 57

59 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II Hvis der eksempelvis er tre punkter; a, b og c, vil matricen se ud på følgende måde: nil ab ac ba nil bc ca cb nil Første kolonne og række er vægte fra punktet a, anden kolonne og række er vægte fra punktet b og tredje kolonne og række er vægte fra punktet c. Eksempelvis er værdien i krydset mellem første række og anden søjle, vægten mellem punkterne a og b, givet ved afstanden. Vægten ab og ba er ens, idet det er den absolutte afstand mellem punkterne, og matricen er dermed symmetrisk omkring diagonalen. Alle vægte i diagonalen er udefineret, da funktionen til opbygning af spanning-tree et, create spanningtree() aldrig skal udbygge til et punkt, der allerede findes i spanning-tree et. Afstanden aa, bb og cc er alle afstande, som ikke er relevante, og sættes til nil. Et eksempel på sammenhængen mellem vægte og matricen kan ses på figur 8.3. D 2 5 A B A B C D A nil 3 2 B nil 4 5 C 3 4 nil 6 D nil 6 3 C 4 Figur 8.3: Sammenhæng i vægte mellem punkter (afstanden) og vægt-matricen Pseudokode function weight distribution ( nodes ) 2 begin 3 for i 0 to lenght ( nodes ) do 4 begin 5 for j 0 to lenght ( nodes ) do 6 begin 7 if i j then 8 weight [ i ] [ j ] distance ( nodes [ i ], nodes [ j ] ) ; 9 else 0 weight [ i ] [ j ] n i l ; end 2 end 3 return weight ; 4 end De to løkker løber igennem alle givne punkter, og matricen fyldes ud med de beregnede afstande. 8.6 Skanningsalgoritme - create spanningtree() 8.6. Input/Output Input: 58

60 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II Koordinater hvorimellem der skal opbygges en rute vha. et spanning-tree. Vægtmatricen der er bestemt af weight distribution(). Output: Et permuteret sæt af koordinater i et array, dannet ud fra spanning-tree et Beskrivelse Fremstillingen af spanning-tree et foregår ved, at gennemløbe vægt-matricen én gang, for hvert nyt punkt, der skal tilføjes til det permuterede array. Antallet af rækker, der undersøges i matricen forøges, efterhånden som flere punkter tilføjes til spanning-tree et. Dette skyldes, at der, for hvert nyt punkt, der tilføjes til spanning-tree et, er en ny mulighed for at forgrene træet. I stedet for at konstruere et spanning-tree og traversere dette, er det valgt at tilføje punkterne i den rækkefølge, spanning-tree et opbygges i. Hver gang et nyt punkt skal tilføjes til spanningtree et søges først fra det punkt, der netop er blevet tilføjet, derefter fra det punkt, der blev tilføjet før det, etc. Dette er vurderet til at give en nær optimal løsning. Et eksempel på en rute til skanning af en række koordinater kan ses på figur a b c d e f g h Figur 8.4: Punkter, som de bliver tilføjet til spanning-tree et. Tallene angiver, hvilket indeks hvert punkt har i inputtet til funktionen. De røde pile angiver rækkefølgen af punkterne i outputtet. I dette eksempel skal robothovedet foretage 26 felttræk Pseudokode function create spanningtree ( nodes, weight ) 2 begin 3 S [ length ( nodes ) ] 0; 4 movement [ 0 ] nodes [ 0 ] ; 5 S [ 0 ] ; 6 indices [ 0 ] 0; 7 8 for i to length ( nodes ) do 9 begin 0 closest weight ; for y i to 0 do 2 begin 3 for x 0 to length ( nodes ) do 4 begin 5 if S [ x ] = 0 then 6 begin 59

61 KAPITEL 8. MODULDESIGN AF APPLIKATIONSLAG II 7 if weight [ indices [ y ] ] [ x ] < closest weight then 8 begin 9 closest weight weight [ indices [ y ] ] [ x ] ; 20 closest node x ; 2 end 22 end 23 end 24 end 25 S [ closest node ] ; 26 indices [ i ] closest node ; 27 movement[ i ] nodes [ closest node ] ; 28 end 29 return movement; 30 end ) S movement 2) S movement 3) S movement 4) S movement A: B: C: D: : : 2: 3: C A: B: C: D: 0 0 0: : 2: 3: C A A: B: C: D: 0 0: : 2: 3: C A B A: B: C: D: 0: : 2: 3: C A B D Figur 8.5: Indholdet af S og tree imens de udfyldes, hvor root er C. Pseudokoden beskrives sammen med figur 8.5, en delfigur af gangen, hvor der er taget udgangspunkt i vægt-matricen på figur I linje 3-6 initialiseres de to arrays S og movement, hvor S indeholder en oversigt af de felter, der er med i spanning-tree et, og hvor movement indeholder de tilføjede koordinater i spanning-tree et. I figuren er create spanningtree() kaldt med C som det første element i array et, og de to arrays er udfyldt. Arrayet indices bruges til at holde styr på rækkefølgen for, hvornår punkterne blev tilføjet. Dette bruges til at løbe punkterne igennem, således at det punkt, robothovedet står i, har højest prioritet. 2. Alle rækker, for punkter, der er tilføjet til træet, (midterste løkke linje ) og kolonner (inderste løkke linje 3) i vægt-matricen køres igennem for hvert nyt punkt, der skal tilføjes i movement (yderste løkke linje 8). Bemærk at rækkerne i matricen køres igennem fra det punkt, der sidst blev tilføjet, og derefter det andet sidste punkt, der blev tilføjet, osv. Vægten, der testes med, nulstilles for hver gang, der skal findes et nyt punkt i spanningtree et, til (linje 0), da det sikrer, at alle punkter findes og tilføjes til movement. Det første punkt er allerede fundet, da det altid er det første element i nodes, så der startes i den yderste løkke med index. Den midterste løkke (linje ) giver, at det kun er de rækker i vægt-matricen, som allerede er med i spanning-tree et, der har mulighed for at udvide træet. Kriteriet (linje 3) i den inderste løkke sørger for, der kun undersøges på felter i vægt-matrice-kolonnerne, der ikke allerede er med i spanning-tree et. I figuren er rækken C gennemløbet, da det er det eneste punkt, der er indeholdt i array indices, og punktet med den laveste afstand findes til at være A. 3. Der fortsættes, men denne gang er der to punkter, som er i stand til at udvide spanningtree et, A og C. Kriteriet på linje 3 gør, at der ikke må undersøges vægte for de punkter, A og C, der allerede er inkluderet i spanning-tree et. Den laveste vægt, der findes, tilhører punktet B. Denne tilføjes til movement, samtidig med at S opdateres. 4. Løkkerne fortsætter indtil alle punkter er inkluderet i spanning-tree et. På figuren er der ikke flere punkter, og det permuterede array i form af movement er konstrueret. 60

62 Kapitel 9 Moduldesign af kerne Dette kapitel har til formål at beskrive moduldesignet af kernen. Kernen er den del, der fungerer som et interface mellem driverne og applikationslaget. Kernen stiller funktioner til rådighed for applikationslaget, og dirigerer funktionskald videre til driverne. F.eks. kan en funktion i kernen kaldes, hvis en brik skal flyttes fra et felt til et andet. Funktionen i kernen kaldes med koordinaterne til start- og slutfelt, og sender derefter kald videre til henholdsvis driverne Lyssensor og Motor, således at robothovedet under brættet flyttes til det korrekte koordinat. Desuden vil kernen sende kald til driveren Magnet, således magneten bliver tændt, og brikken følger med robothovedet rundt. Dette støtter principperne i information hiding ved at sikre, at grænsefladerne minimeres, og at tætheden optimeres. Designet af hvert modul indeholder følgende punkter, såfremt de er fundet relevante: Interface - Indeholder en beskrivelse af det interface, modulet stiller til rådighed. Analyse - Indeholder en kort analyse baseret på kravene stillet i kravspecifikationen. Algoritmer - Indeholder en beskrivelse af de algoritmer, modulet benytter sig af. Modultest - Beskriver, hvordan modulet testes. 9. Displaystyring 9.. Interface Dette modul stiller følgende eksterne funktioner til rådighed. void ker display init(void) - Initialiserer modulet. void ker display(char* message) - Skriver en tekststreng på displayet. Disse funktioner vil blive gennemgået i det følgende Analyse Displaystyring i kerne skal være i stand til at initialisere driveren Display og sende en tekststreng på 6 karakterer til driveren. Der findes fire linjer med hver 6 karakterer på det benyttede display. Da der er fire linjer til rådighed, benyttes tre linjer til historik. Dette betyder, at displayet først vil skrive på den første linje, fra toppen, derefter den anden etc. Når den nederste linje opnåes, og en ny besked kommer, slettes den øverste linje, og de resterende linjer rykkes op. Dermed kan den nye besked indsættes på den nederste linje. 6

63 KAPITEL 9. MODULDESIGN AF KERNE Når Displaystyring er initialiseret, kan ker display() kaldes, hvor parameteren til funktionen er den besked, der skal vises på displayet. Når ker display() kaldes i kerne, skal dri display print(), i driveren Display, kaldes fire gange. Først skal beskeden, der er på anden linje, skrives på første linje. Derefter skal tredje linje skrives på anden linje. På samme måde flyttes fjerde linje til tredje. Efter de tre øverste linjer er opdateret, skal den nederste linje opdateres med den besked, ker display() kaldes med. For at styre historikken benyttes et array på 4 7 karakterer. På displayet er der kun plads til 6, men hver linje, skal ende med en 0-karaktere, således at linjerne kan skelnes fra hinanden Algoritmer ker display init() initialiserer driveren Display, og sørger for at al historik slettes. Dette gøres ved at indsætte mellemrumskarakterer på alle pladser på displayet, dvs. på 64 pladser i array et. Eneste undtagelse er nulkarakteren på sidste plads i hver linje. Funktionen, der skal kaldes for hver gang, der skal skrives til displayet, og dermed også skal holde styr på historikken, er ker display(), hvis implementation ser ud som følger: void ker display (char message ) 2 { 3 int i = 0, message length =0; 4 5 i = 0; 6 while ( message [ i++]!= \0 ) 7 message length++; 8 9 if ( message length > 6) 0 message length = 6; 2 for ( i = 0; i < 4; i++) 3 memcpy(&display mem [ i 7], &display mem [ ( i 7)+7], 7); 4 5 memset(&display mem [ 5],, 6); 6 memcpy(&display mem [ 5], message, message length ) ; 7 display mem [ DISPLAY SIZE ] = \0 ; 8 9 for ( i = 0; i < 4; i++) 20 d r i d i s p l a y p r i n t(&display mem [ i 7], i ) ; 2 } Det første der sker, er at bestemme længden af den besked, der skal skrives, og sikrer, at den ikke overskrider 6 karakterer, foruden nulkarakteren. Dernæst rykkes de tre nederste linjer én linje op, den nederste linje fyldes med mellemrumskarakterer, og beskeden sættes ind. Til sidst indsættes en nulkarakter på sidste plads i historikken. Resultatet skrives ud på displayet Modultest Modultesten for Displaystyring skal først initialisere modulet og derefter udskrive beskederne i tabel 9. i rækkefølge. Beskederne skal udskrives korrekt, bortset fra tredje linje, der så kun skal printes til og med 6. karakter. Mellem udskrift af hver besked skal der være en pause, således det kan verificeres, at alle beskeder udskrives korrekt. 62

64 KAPITEL 9. MODULDESIGN AF KERNE Test line.? =:;.- What happens when the line is over 6 characters? Test line 4. Test line 5. Tabel 9.: Modultest af Displaystyring i kernen. 9.2 Feltstatus 9.2. Interface Dette modul stiller følgende eksterne funktioner til rådighed: int ker fieldstate(void) - Kalder driveren Lyssensor, for at identificere feltstatus for feltet robothovedet er placeret under. Der kan returneres enten sort, hvid eller ingen brik. void ker fieldstate calibrate(void) - Flytter robothovedet og foretager lysmålinger definerede steder for at kalibrere lysværdierne for sort, hvid og ingen brik. Funktionerne vil blive analyseret i det følgende Analyse ker fieldstate() skal kunne kalde driveren Lyssensor med funktionen dri light top value(), der returnerer et heltal svarende til den aktuelle lysværdi. Feltstatus skal analysere dette, og konstatere, hvorvidt der er en hvid, sort eller ingen brik, på det undersøgte felt. Denne status returneres til den kaldende funktion. Værdierne, der skiller mellem hvid, sort eller ingen brik kalibreres vha. ker fieldstate calibrate() ud fra de farver, brikkerne har i bunden. Dette sker ved at skanne felterne ved startopstillingen, og der skannes tre felter uden brikker, tre felter med hvide brikker og tre felter med sorte brikker Modultest Der designes to stubbe, der simulerer modulerne Logik og Lyssensor. Logik-stubben skal kunne kalde ker get fieldstate(). Lyssensor-stubben, skal kunne returnere et heltal, svarende til funktionen dri light bottom value(). På denne måde kontrolleres det, om modulet er i stand til at undersøge feltinformationen for et felt korrekt. 9.3 Flyt brik 9.3. Interface Dette modul stiller følgende ekstern funktion til rådighed: int ker move piece(sequence t* sequence) - Kalder driverne Motor og Magnet for at flytte en brik fra et start- til et destinationsfelt. Funktionen analyseres følgende Analyse Flyt brik i kerne skal kunne flytte en brik fra èt koordinat til et andet. Funktionen ker move piece() kaldes fra Logik og skal styre udførslen af den sekvens, der gives som parameter. Parameteren er af typen sequence t, og indeholder et array, der indeholder følgende oplysninger i hvert element: 63

65 KAPITEL 9. MODULDESIGN AF KERNE Et absolut koordinat hvorfra en flytning af en brik starter. En retning fra det absolutte koordinat, hvorfra en brik skal flyttes. Funktionaliteten i ker move piece() er: ker head goto xy() i kernemodulet Flyt robothoved kaldes med det et absolutte koordinat fra sekvensen. Dette sker med elektromagneten slukket, og robothovedet er klar til at flytte en brik fra det angivne koordinat. Retningen, svarende til koordinatet i sekvensen, konverteres til et absolut koordinat, som ligger maksimalt et felttræk fra robothovedets nuværende position. ker head goto xy() kaldes igen, med det beregnede absolutte koordinat, svarende til retningen. Dette felttræk udføres med elektromagneten tændt, og brikken flyttes. Dette skaber en iterativ udførsel af sekvensen, et felttræk af gangen, hvor styringen er i dette modul Modultest Der designes to stubbe, der simulerer Logik og Flyt robothoved. Logik-stubben skal kunne kalde move piece(). Flyt robothoved skal kunne visualisere outputtet af den iterative løkke fra i Flyt brik, således det kontrolleres, hvorvidt sekvensen udføres korrekt. 9.4 Flyt robothoved 9.4. Interface Dette modul stiller følgende eksterne funktioner til rådighed: void ker head init(void) - Initialiserer Flyt robothoved. void ker head goto 0x0(void) - Går til den absolutte position (0,0), ved at anvende kalibreringssensorerne. void ker head goto xy(coord t coord, int magnet enable, int last piece move) - Flytter robothovedet til et bestemt koordinat. void ker head absolute pos(coord t *current position) - Returnerer robothovedets nuværende position. void ker head taken piece(void) - Fjerner en slået brik fra brættet Analyse Modulet skal være i stand til at flytte robothovedet fra et felt til et andet. Modulet kaldes med funktionen ker head goto xy() fra enten Logik eller Flyt brik, og flytter robothovedet fra et absolut koordinat til et andet. Dette gøres ved at beregne forskellen mellem den nuværende absolutte position, som ligger i modulet, med koordinatet, der gives som argument. Der navigeres efter mønstret under robothovedet ved at anvende dri light bottom value() til at sample lysværdier. Argumentet magnet enable indikerer, hvorvidt magneten skal være tændt eller slukket under flytningen. Dette er nødvendigt at vide, hvis robotten, under flytningen af robothovedet, finder ud af, den er kørt forkert. Sker dette, skal der foretages en kalibrering af robothovedets position. Det kan detekteres, hvis robotten kører skævt eller forkert, ved at analysere lysværdierne fra den nederste lyssensor, da mønstret under robothovedet er kodet således, at en forkert position af 64

66 KAPITEL 9. MODULDESIGN AF KERNE robothovedet resulterer i en lysværdi i et forkert område. Når dette opdages, kalibreres robothovedets position automatisk ved at benytte kalibreringssensorerne. Ved initialisering sættes de callback-funktioner driveren, til kalibreringssensorerne, stiller til rådighed til at kalde funktioner i motordriveren, således at motorerne stoppes. Dvs. når kalibreringssensoren i x-retningen trykkes, kaldes funktionen i motordriveren til at stoppe x-motoren, og når y-sensoren trykkes, kaldes funktionen i motordriveren til at stoppe y-motoren. Kalibreringen foregår ved, at status for motorerne og elektromagneten gemmes. Herefter slukkes elektromagneten, og motorerne sættes til at køre i negativ x- og y-retning mod koordinatet (0,0) på skakbrættet, vha. ker head goto 0x0(). Der fortsættes længere ud end (0,0) i samme retning, indtil begge kalibreringssensorer er ramt af robothovedet. Dernæst flyttes robothovedet til koordinatet (0,0) vha. motorerne ved at aflæse mønstret under robothovedet. Endelig flyttes robothovedet tilbage til det absolutte koordinat, hvor robotten kalibreringen blev startet. Motorerne og elektromagneten gives de tidligere indstillinger, så den opgave, robotten var i færd med at udføre, kan genoptages. ker head goto 0x0() er en ekstern funktion, der stilles til rådighed for applikationslaget, da den også kaldes til nulstilling af robothovedet ved opstart af programmet. ker head taken piece() er en nødvendig funktion, da x- og y-elementerne i datastrukturen board t kun kan indeholde værdierne 0 til 7 (3 bit), jf. afsnit Dette giver ikke mulighed for at flytte en brik ud fra brættet, da der ikke er plads til et koordinat udenfor brættet i datastrukturen. Derfor indføres det, at hvis en brik skal fjernes fra brættet, navigeres til et koordinat i siden af brættet, i form af et felt i kolonne H på skakbrættet. Derfra fjernes brikken ud fra brættet, hvor brikken afleveres, og der vendes tilbage til brættet på samme position. Dette forhindrer en udvidelse af board t Modultest Der designes to stubbe, der simulerer Logik og driveren Motor. Logik-stubben skal være i stand til at kalde ker head goto xy(). Motor-stubben skal være i stand til at visualisere outputtet fra ker head goto xy(), hvori det kontrolleres, hvorvidt bevægelsen er udført korrekt. Det samme gentages for de resterende funktioner. 9.5 Kommunikation med PC 9.5. Interface Dette modul stiller følgende eksterne funktioner til rådighed: void ker compc init(void) - Initialiserer Kommunikation med PC-stub. int ker compc read(char* dst, size t size) - Kalder driveren RS232 for at modtage en besked fra PC-stubben. Funktionen returnerer først, når der modtages en hel linje afsluttet med Carriage Return, eller hvis der ikke er mere plads i bufferen. Funktionen ker compc read() vil blive beskrevet nærmere i det følgende Analyse Dette modul implementerer det funktionelle krav Kommunikation med PC-stub. For at at gøre det enkelt for Logik at kommunikere med PC-stubben, vil dette modul abstrahere adgangen til RS232-driveren ved at stille en funktion til rådighed, der kan læse hele tekststrenge fra RS232- forbindelsen. Der kan ligeledes skrives hele tekststrenge. Til dette benyttes standard-funktionen En callback-funktion er en funktion der typisk gives til et underliggende lag, således at det underliggende lag kan kalde en funktionen i det overliggende lag. 65

67 KAPITEL 9. MODULDESIGN AF KERNE printf(), som internt kalder RS232-driverens s putchar(). printf() ligger i den benyttede compilers standardbibliotek, og kræver, at putchar() er implementeret. Derfor implementeres putchar() i driver-modulet. Funktionen ker compc read() gemmer den næste linje, der modtages fra RS232-forbindelsen, i bufferen dst. Parameteren size specificerer størrelsen på bufferen, således det kan undgås at skrive ud over bufferens længde. Funktionen returnerer først, når enten, der er modtaget en hel linje, dvs. en række karakterer efterfulgt af Carriage Return, eller hvis bufferen bliver fyldt. Den returnerede streng afsluttes altid med 0-karakteren, og den vil ikke indeholde linjeskiftet. RS232-driverens dri rs232 getchar() benyttes internt til at hente den næste karakter Algoritmer int ker compc read (char dst, s i z e t s i z e ) 2 { 3 int index = 0; 4 int ch = dri rs232 getchar ( ) ; 5 while ( index < ( size ) && ch!= \r ) 6 { 7 switch (ch ) 8 { 9 case \b : if ( index > 0) index ; break ; 0 default : dst [ index++] = ch ; } 2 ch = dri rs232 getchar ( ) ; 3 } 4 dst [ index ] = \0 ; 5 return index ; 6 } Modultest Der er skrevet en test-driver, som inititaliserer driveren RS232 og derefter blot sender alle linjer, der modtages via RS232-forbindelsen vha. ker compc read(), retur vha. printf(). Til at teste, benyttes en tilsluttet PC med en terminal-emulator, som f.eks. MiniCOM

68 Kapitel 0 Moduldesign af drivere Dette kapitel indeholder analyse, design og test af den hardware og software, der benyttes af, og indgår i, hvert drivermodul. Drivernes opgave er at stille den eksterne hardwares funktionalitet til rådighed for programmets øvrige moduler. Hardwaren til nogle drivermoduler består til dels af eksisterende komponenter, såsom motorer og lyssensorer. Disse komponenter analyseres, og der designes interfaces, så MSP en kan benytte komponenterne. Der er desuden detaljerede beskrivelser af de funktioner på MSP en, der benyttes i de forskellige moduler. De funktionaliteter i MSP en, der opfattes som generelle og ikke er beskrevet her, kan findes i appendiks B.. Hver af de følgende afsnit indeholder moduldesignet for ét drivermodul.afsnittene er opdelt i 7 underafsnit:. Design af interface til kernen - Her specificeres det software-interface, som driveren stiller til rådighed for kernen. 2. Analyse af anvendt hardware - Hvis et drivermodul benytter eksisterende komponenter, såsom motorer og lyssensorer, der stiller særlige krav til den omkringliggende hardware, vil der i dette afsnit være en analyse af komponenterne. Dette kunne f.eks. være krav til strømforsyning og tid etc. 3. Analyse af løsning - Nogle drivermoduler har mere end én oplagt løsning til design af hardware og software, og derfor analyseres de forskellige løsningsmuligheder. På baggrund af analysen vælges en løsning. Dermed vides det, hvilke af MSP ens funktionaliteter, der benyttes i drivermodulet. Dette afsnit vil desuden opstille de krav, der efterfølgende skal opfyldes i design af hardware og driver. Disse krav vil bl.a. omfatte brug af porte på MSP en. 4. Beskrivelse af benyttet MSP-funktionalitet - Såfremt drivermodulet benytter funktionaliteter i MSP en, der ikke opfattes som generelle, er disse funktioner beskrevet detaljeret i dette afsnit. Ellers henvises der til appendiks B.. 5. Design af hardware - Her designes drivermodulets hardware, så det opfylder de krav, der er opstillet. Hardwaren gør at MSP en kan benytte evt. eksisterende komponenter vha. de specificerede porte. 6. Design af driver - Her designes softwaren, der skal styre hardwaren, så det opfylder de opstillede krav og sætter de øvrige moduler i stand til at benytte hardwaren. 7. Modultest - Her opstilles tests af det designede hardware og software. 67

69 KAPITEL 0. MODULDESIGN AF DRIVERE 0. Display Informationer, der skal gives løbende til spilleren, vises på et display. For at opfylde kravet Visning på display, stilles der krav til, hvilke karakterer, der skal kunne vises på et display. Der findes LCD -display s, der kan vise ASCII-karakterer, og et sådant er anvendt, da det opfylder det opstillede krav. Se markering (0) på Figur 3.2, der kan findes som fold-ud side bagerst i rapporten. 0.. Design af interface til kernen Denne driver stiller følgende eksterne funtioner til rådighed for kernen: void dri display init(void) - Initialiserer displayet. void dri display print(char* message, int line) - Viser en tekststreng på displayet på den specificerede linje. Da implementationen af de eksterne funktioner i modulet opfattes som triviel, analyseres de ikke. Derimod analyseres nogle af modulets interne funktioner, da disse er mere komplekse Analyse af display Der benyttes et Powertip PC604-A LCD som display. Afsnittet vil bygge på databladet for denne, jf. [Powertip, 2006]. PC604-A displayet har ASCII-tabellen integreret, hvilket gør det let at udskrive karakterer fra dette. Displayet kan vise fire linjer med 6 karakterer på hver. Displayet styres gennem en integreret controller chip. Det er chippen, der styrer displayets initialisering, indstillinger og hukommelse. Selve LCD-displayet er blot en slaveenhed. Der kan både skrives til, og læses fra, displayet. Læsning bliver benyttet til at aflæse et busy-flag, der fortæller, om controller chippen har en igangværende instruktion, og dermed ikke kan tilgås. Pintildeling Displayet har 4 pins. Deres funktion er: Forsyningsspænding - Displayet forsynes med 5V, selvom controller chippen på displayet kan fungere ved 3,3V. Dette skyldes, at displayet kræver minimum 3,9V for at vise karakterer. Kontrast - Kontrasten justeres med en analog spænding i intervallet mellem 0V og 5V. For at kunne finjustere kontrasten, anvendes et potentiometer, der styrer den spænding, der går ind på kontrastpin en. Register Select - Et af displayets kontrolpins. Er RS lav, fortolker controller chippen de data, der modtages, som instruktioner. Er RS høj, fortolkes dataene som karakterer i ASCII-tabellen. RS initialiseres til lav. Read/Write - Et af displayets kontrolpins. Er RW lav, sættes displayets datapins til input, dvs. displayet kan modtage instruktioner og karakterer fra MSP en. Er RW høj, sættes displayets datapins til output, dvs. displayet kan sende beskeder til MSP en. RW initialiseres til høj og ændres kun, når der sendes instruktioner eller karaktere til displayet. Enable - Et af displayets kontrolpins. Enable bruges som et signal til controller chippen om, at nu skal displayets datapins aflæses. Denne er som standard lav og sættes kun høj, når der er valide data tilgængelige på datapins ene. Liquid Crystal Display 68

70 KAPITEL 0. MODULDESIGN AF DRIVERE Datapin 0 til 7 - De otte datapins på displayet. Displayet understøtter 4 og 8 bits overførsel. Der bruges 8-bit dataoverførsel, da en ASCII-karakter derved kan sendes i en dataoverførsel. Instruktioner og karakterer Displayet styres med instruktioner. Disse skal sendes ved at udføre følgende sekvens:. Read/Write sættes lav. 2. Den instruktion, der ønskes sendt, sættes på datapins ene. 3. Enable sættes høj. 4. Enable sættes lav. 5. Read/Write sættes høj. Pseudokode, for hvordan instruktioner sendes, kan ses i afsnit Når displayet startes op, skal det initialiseres med en bestemt sekvens af instruktioner. For at dette sker korrekt, skal der gå en bestemt tid mellem hver instruktion sendes. Busy flaget kan ikke anvendes til dette, da det også skal initialiseres. Korrekt initialisering foretages ved at 5ms 4.ms 00us 40us 40us 40us 40us.64ms POWER ON 0x38 0x38 0x38 0x38 0x06 0x0C 0x0 Næste instruktion Initialisering slut Figur 0.: Korrekt initialiseringssekvens for LCD-displayet. Tiderne er minimumstider. Den første instruktion skal sendes fire gange for at nulstille displayet. [Powertip, 2006] sende hexkoderne som vist i figur 0., der giver sekvensen: Function set - 0x38 - Fortæller displayet, der skal anvendes 8-bits datalængde, og at der bruges 4 linjer. Entry mode set - 0x06 - Sætter markøren til at gå mod højre efter hver karakter er printet. Display on/off - 0x0C - Tænder displayet og gør markøren usynlig. Clear display - 0x0 - Tømmer karakterhukommelsen og placerer markøren i øverste, venstre hjørne. Busy flaget betegnes i databladet som en instruktion, men er meget forskellig fra de andre instruktioner. Når busy flaget skal aflæses, skal kontrolpins ene sættes op til dette, og derefter bruges datapin 7 som busy flag. Sekvensen for aflæsning af busyflaget er:. Register Select sættes lav, og Enable sættes høj. 2. Busy flaget kan nu aflæses på datapin 7. Hvis der aflæses en høj spænding på pin et, er flaget sat. 3. Enable sættes lav og Register Select sættes høj. Denne sekvens gentages, indtil flaget ikke længere er sat. Pseudokoden for implementeringen af aflæsning af busy flaget kan ses i afsnit Det er muligt at styre, hvor på displayet en tekst skal skrives. Dette gøres ved at angive en position i form af en adresse. Denne sendes som instruktion til displayet. Adresserne for de 64 karakterer på displayet kan ses på figur 0.2. Når det ønskes at sende ASCII-karaktere til displayet, foregår det på næsten samme måde som med instruktioner. Eneste forskel er at Register Select skal sættes høj. Sekvensen er dermed: 69

71 KAPITEL 0. MODULDESIGN AF DRIVERE Figur 0.2: Adresserne for de 64 karakterer på displayet. [Powertip, 2006] Funktion Port Pin RS P RW P3. 29 E P DB0 P DB P2. 2 DB2 P DB3 P DB4 P DB5 P DB6 P DB7 P Tabel 0.: Porttildeling for display.. Register Select sættes høj, og Read/Write sættes lav. 2. Den karakter, der ønskes sendt, sættes på datapins ene. 3. Enable sættes høj. 4. Enable sættes lav. 5. Register Select sættes lav, og Read/Write sættes høj Analyse af løsning Displayet bruges til at vise beskeder for spilleren. Dette gøres ved, at driveren modtager tekststrenge på højst 6 ASCII-karakterer fra Displaystyring i kernen. Displayet er tilsluttet MSP en, som beskrevet i tabel 0.. Dog kan displayet ikke tilsluttes direkte, da displayet kræver, at alle signaler har samme spænding som forsyningsspændingen på 5V. MSP en opererer ved 3,3V, derfor skal spændingen ændres på alle signaler, der sendes mellem MSP en og displayet. Dette løses i næste afsnit Design af hardware Til ændring af spændingsstyrken mellem MSP en og displayet anvendes IC en SN74LVCC4245A, der er en bidirektionel spændingsomformer. De følgende informationer for denne stammer fra databladet, jf. [Texas Instruments, 996]. Den bidirektionelle spændingsfortolker har to 8-bits busser, A og B. Disse kan ses på figur

72 KAPITEL 0. MODULDESIGN AF DRIVERE Figur 0.3: IC ens pins. [Texas Instruments, 996] IC en translaterer signaler på A-siden til signaler på B-siden, med den spænding, som B- siden forsynes med. Ligeledes translateres signaler fra B-siden til A-siden med den forsyningsspænding som A-siden forsynes med. Relevante pins for beskrivelsen af IC ens funktion gennemgås i det følgende: V cca - Forsyningsspændingen på A-siden af IC en. Denne forsynes med 5V, og er den side, der forbindes med displayet. V ccb - Forsyningsspændingen på B-siden af IC en. Denne forsynes med 3,3V, og er den side, der forbindes med MSP en. DIR - Retningen for konverteringen af signalerne. Ved lav konverteres signalerne fra B- siden til signaler på A-siden, og modsat for høj. OE - OE står for Output Enable. Den er inverteret, hvilket vil sige at er OE lav, omformer IC en signalerne, som specificeret af DIR. Er den høj svarer det til at forbindelsen mellem IC ens to busser er afbrudt. A-A8 - Den venstre databus. Modtager og sender signaler på 5V. B-B8 - Den højre databus. Modtager og sender signaler på 3,3V. Måden, IC en fungerer på, kan ses i det logiske diagram på figur 0.4. De to forbindelser, der går ned mod de andre syv kanaler, styrer kommunikationen mellem A- og B-bussen. Kommunikationsvejen styres af to tri-states på hver kanal mellem de to databusser. Tri-statesene styres af, om OE er lav, samt hvilken spænding, der er på DIR. På grund af antallet af signaler er det nødvendigt med to IC er af denne type, en til displayets datapins og en til dets kontrolpins. De to IC er, samt displayet og potentiometeret kan ses på diagrammet i figur Design af driver Ud over de eksterne funktioner, er der designet tre interne funktioner: void instr(char cmd) - Sender en kommando, cmd, til displayet. void putc(char c) - Sender en ASCII-karakter, c, til displayet. void busy(void) - Læser busy flaget og returnerer, når dette ikke er sat. 7

73 KAPITEL 0. MODULDESIGN AF DRIVERE Figur 0.4: Logiske diagram for IC en [Texas Instruments, 996]. busy() er den eneste funktion, der aflæser fra displayet. Den er designet ved at bruge timingdiagrammet for læsning fra displayet, jf. [Powertip, 2006]. function dri display busy ( void ) 2 begin 3 repeat 4 begin 5 P3OUT. 0 ; 6 delay (375 ns ) ; 7 busy P2IN. 0 ; 8 P3OUT. 0 0; 9 delay (25 ns ) ; 0 end until busy = 0; 2 end Her køres en løkke så længe busy flaget er sat. I løkken sættes Enable høj, hvorefter busy flaget læses. Derefter sættes Enable lav igen, og løkken kontrollerer om busy flaget var sat. For at sende instruktioner til displayet, anvendes instr(), der ligeledes implementeres ud fra timingdiagrammet i databladet, jf. [Powertip, 2006]. function i n s tr (cmd) 2 begin 3 P3OUT. 0; 4 P2OUT cmd; 5 P3OUT. 0 ; 6 delay (250 ns ) ; 7 P3OUT. 0 0; 8 P3OUT. ; 9 end I denne funktion sættes RW først lav, hvorefter instruktionen sendes ud på datapins ene på MSP en Herefter sættes Enable høj, der ventes, og det sættes tilbage. Derefter sættes RW høj. Forløbet for afsendelse af ASCII karakterer er næsten det samme, og gennemgås ikke nærmere Modultest For at teste driveren til displayet skal der skrives en teststub, der først initialiserer driveren. Derefter skal teststubben kalde funktionen dri display print() fire gange, så displayet viser teksten på tabel

74 KAPITEL 0. MODULDESIGN AF DRIVERE 3,3V SN74LVCC4245-A LCD DB7 DB6 DB5 DB4 DB3 DB2 DB DB0 E R/W RS Vee Vdd GND VccA 2 DIR 3 A 4 A2 5 A3 6 A4 7 A5 8 A6 9 A7 0 A8 GND 2 GND VccB NC OE B B2 B3 B4 B5 B6 B7 B8 GND VccA 2 DIR 3 A 4 A2 5 A3 6 A4 7 A5 8 A6 9 A7 0 A8 GND 2 GND SN74LVCC4245-A VccB NC OE B B2 B3 B4 B5 B6 B7 B8 GND P2.7 P2.6 P2.5 P2.4 P2.3 P2.2 P2. P2.0 P3.0 P3. P k 5V 0V Figur 0.5: Diagram for hardwaren til displayet. Det forventes at displayet viser tabellens karakterer korrekt. 0.2 Kalibreringssensor Lego Mindstorm stiller berøringssensorer til rådighed, og to sådanne benyttes på robotten til at kalibrere positionen af robothovedet. Se markering (4) på Figur 3.2, der kan findes som fold-ud side bagerst i rapporten Design af interface til kernen Denne driver stiller følgende funtioner til rådighed for kernen: void dri button init(void) - Initialiserer MSP en til at modtage interrupt på portene anvendt af kalibreringssensorerne. Linje Tekststreng Display init 2 AaBbCcDdEeFfGgHh ?!=.: Tabel 0.2: Modultest af display. 73

75 KAPITEL 0. MODULDESIGN AF DRIVERE Funktion Port Pin Interruptpin X P. 3 Interruptpin Y P.2 4 Tabel 0.3: Porttildeling for kalibreringssensorne. void dri button set flags(void) - Opdaterer de variable, der kontrollerer, om en kalibreringssensor er blevet trykket. Dette skal gøres for hver gang det ønskes at kalibrere. int dri button x was pressed(void) - Returnerer, om kalibreringssensoren på x-aksen er trykket. int dri button y was pressed(void) - Returnerer, om kalibreringssensoren på y-aksen er trykket. int dri button xy was pressed(void) - Returnerer, om begge kalibreringssensorer er trykket. Hvis dette er tilfældet, er robothovedet i en kendt position. void dri button cb x(void (*cb)(void)) - Modtager adressen til callback-funktionen, der skal kaldes når interruptet for x-kalibreringssensoren aktiveres. void dri button cb y(void (*cb)(void)) - Modtager adressen til callback-funktionen, der skal kaldes når interruptet for y-kalibreringssensoren aktiveres Analyse af Lego berøringssensor Lego s berøringssensor fungerer næsten på samme måde som et ringetryk, dog kan berøringssensoren måle, hvor hårdt der bliver trykket på den. Når der ikke trykkes på sensoren, er den afbrudt. Trykkes der på sensoren, afhængigt af hvor hårdt der trykkes, skabes der forbindelse gennem en modstand, der varierer mellem ca. kω og 200kΩ. Den mindste modstand er når sensoren er trykket helt ind. Dette er fundet ved at måle på berøringssensoren med et multimeter. Til robotten anvendes berøringssensorerne som ringetryk, da det er tilstrækkeligt at vide, at der bliver trykket, og ikke hvor hårdt Analyse af løsning For at kalibrere robothovedet skal motorerne i x- og y-retningen startes, så robothovedet køres til en bestemt position. Motorerne skal stoppe ved interrupts, når robothovedet kommer til den position, hvor kalibreringssensorerne trykkes. Dette giver, at der til hver af kalibreringssensorene skal bruges en port på MSP en, der understøtter interrupts. Derfor er fordelingen af porte til kalibreringssensorne som i tabel 0.3. Det vil ikke være hensigsmæssigt med en løsning, der ikke benytter interrupts, da et tryk på en af kalibreringssensorerne kan være meget kortvarigt, hvilket f.eks. fjerner muligheden for at polle på porten hvorpå sensorerne er placeret. Derfor benyttes den ovenstående løsning Beskrivelse af benyttet MSP-funktionalitet Til den valgte løsning bruges portinterrupts på MSP en. MSP en kan give interrupts på port og 2. På hver af portene er der otte interruptpins. For at benytte portinterrupts på en pin, skal dette aktiveres for det enkelte pin. Når interruptet kaldes, sker det for hele porten, og det kontrolleres, hvilken pin interruptet er kommet fra. Dette betyder, for at benytte portinterrupts på P. og P.2, jf. tabel 0.3, skal der aktiveres interrupts for disse. Dette gøres vha. følgende C-kode: 74

76 KAPITEL 0. MODULDESIGN AF DRIVERE PIE = BIT BIT2 ; 2 PIES &= (BIT BIT2 ) ; 3 PIFG &= (BIT BIT2 ) ; Linje to i koden sætter Low/High edge, så der sker interrupts, når inputtet på en af portene går fra lav til høj. Den sidste linje nulstiller interruptflagene for P. og P.2, disse flag skal nulstilles, hver gang der har været et interrupt, for nye interrupts kan opstå på på den pågældende pin Design af hardware Det ønskes, at kalibreringssensorerne kan lave interrupts, når de trykkes. Et design af hardwaren for at gøre dette, kan ses på figur 0.6. I diagrammet er der seks pins, der er forbundet på flg. måde: Sensor X - To pins er forbundet til kalibreringssensoren, der giver interupt på MSP en i x-retningen. Interrupt X - Forbundet til P. på MSP en, og modtager interrupt fra Sensor X. Sensor Y - Den anden kalibreringssensor, er forbundet med to pins, der giver interrupt til MSP en i y-retningen. Interrupt Y - Forbundet til P.2 på MSP en, og modtager interrupt fra Sensor Y. Interrupt X Sensor X +3.3V R2 R Interrupt Y Sensor Y Figur 0.6: Design af hardwaren til kalibreringssensorerne. Modstandene R og R2 er pull-down-modstande, der gør, at når kalibreringssensorerne er afbrudt, er interrupt X og interrupt Y forbundet til stel. Når robothovedet rammer en af kalibreringssensorerne, vil denne blive trykket næsten helt ind pga. den hastighed robothovedet har, når det kører mod sensorerne. Da der i kalibreringssensorerne er en modstand på ca. kω, når den er trykket helt ind, benyttes 00kΩ modstande til R og R2. Dette gør, at når en kalibreringssensor er trykket ind, vil der være en spændingsdeling mellem modstanden i kalibreringssensoren og pull-down-modstanden, der giver flg. spænding til MSP en: v MSP = 00 3, 3 3, 27V 0 Dette er tæt på 3,3V, og vil på MSP en opfattes som logisk høj. 75

77 KAPITEL 0. MODULDESIGN AF DRIVERE Design af driver Driveren til kalibreringssensorerne skal udføre interrupts, når en af sensorerne er blevet trykket. Initialisering af interrupts for P. og P.2, foregår i funktionen dri button init() og gøres som beskrevet i koden i afsnit Derudover skal modulet kunne kende forskel på, hvilken kalibreringssensor der er blevet trykket. For at stoppe motorerne skal driveren have adresser til to funktioner, der kan stoppe motorerne, når der trykkes på en kalibreringssensor. I modulet er det dri button cb x() og dri button cb y(), der sætter callback-funktioners adresser. Derudover skal der være en funktion, der kaldes, når der kommer interrupts fra en af kalibreringssensorerne. Pseudokoden er som følger: global x pressed ; 2 global y pressed ; 3 4 interrupt button pressed () 5 begin 6 if x button pressed () then 7 begin 8 x pressed ; 9 cb x handler ( ) ; 0 PIF. 0; end 2 if y button pressed () then 3 begin 4 y pressed ; 5 cb y handler ( ) ; 6 PIF.2 0; 7 end 8 end Designet med callback-funktionerne sikrer, at der ikke foretages direkte funktionskald fra driveren til kernen. Dette sikrer, at funktionaliteten for, hvad der skal ske, når kalibreringsinterruptet aktiveres, ligger i kernen. Funktionerne dri button x was pressed(), dri button y was pressed() og dri button xy was pressed(), skal returnere, hvis kalibreringssensoren for enten X, Y eller begge er trykket Modultest For at denne modultest kan udføres, skal den serielle kommunikation til PC-stubben virke. Til kalibreringssensorerne skal der skrives en teststub, der initialiserer driveren. Derefter skal funktionerne dri button x cb() og dri buton y cb() kaldes med to pointere til to funktioner i stubben, der udskriver til PC-stubben, at der er trykket på en kalibreringssensor, samt om det er den ene eller anden kalibreringssensor. Derudover skal stubben have en funktion, der ved tryk på en kalibreringssensor, undersøger, om først den ene kalibreringssensor er trykket, derefter den anden, og til sidst om begge kalibreringssensorerne er trykket. Modulet testes ved, at der først trykkes på den ene kalibreringsensor. Det forventes, at der på PC-stubben står, at der er trykket på den pågældende kalibreringssensor. Derefter trykkes på den anden kalibreringssensor, og det forventes, at der på PC-stubben nu står, at den anden kalibreringssensor er blevet trykket. Samtidig skal der stå, at begge kalibreringsensorer har været trykket. 76

78 KAPITEL 0. MODULDESIGN AF DRIVERE 0.3 Elektromagnet I toppen af robothovedet er monteret en elektromagnet. Denne bruges når en skakbrik skal trækkes hen over brættet. Se markering (8) på Figur 3.2, der kan findes som fold-ud side bagerst i rapporten Design af interface til Kerne Denne driver skal være i stand til at tænde og slukke for elektromagneten. Modulet indeholder derfor følgende eksterne funktioner: void dri mag init(void) - Initialiserer Magnet-modulet. void dri mag enable(int enable) - Starter magneten, når den kaldes med parameteren, og slukker den, når den kaldes med 0 Funktionerne vil blive analyseret i det følgende Analyse af Elektromagnet Elektromagneten, der benyttes, skal have en forsyningsspænding på 2V. Ved måling på magneten er følgende karakteristika fundet: Ved 2V bruger elektromagneten ca. 200 ma. Elektromagneten har en indre modstand på ca. 60 Ω Design af hardware På figur 0.7 ses et diagram over hardwaren til styring af elektromagneten. Da elektromag- 68 Ohm 8V Elektro magnet MSP 68 Ohm,3k Ohm 3 2 BC337 Figur 0.7: Design af hardwaren til magneten. neten skal have 2V, og der til projektet er udleveret to spændingsforsyninger på 9V, er det nødvendigt, at seriekoble forsyningerne. Ved at gøre dette, opnås en spænding på 8V. Derefter 77

79 KAPITEL 0. MODULDESIGN AF DRIVERE sørger en spændingsdeling af de 8V for, at magneten får de nødvendige 2V. Da elektromagneten har en indre modstand på 60Ω, kan det beregnes hvilken modstand, der skal laves en spændingsdeling med. 60Ω 8V R modstand = = 30Ω 2V Dette betyder, at en spændingsdeling mellem elektromagneten, der har en indre modstand på 60Ω og en modstand på 30Ω, vil virke. På denne måde vil der være et spændingsfald på 6V over modstanden. Derfor vil den strøm, der afsættes i modstanden være i modstand = 6V 30Ω = 0, 2A, og effekten P modstand = 6V 0, 2A =, 2W. Da de effektmodstande, der benyttes, kun kan klare W, er det nødvendigt, at parallelkoble to modstande, på hver 60Ω. Da det udvalg af effektmodstande, der er tilgængelige i projektudviklingsfasen er begrænset, er 60Ω effektmodstande ikke til rådighed. Derfor benyttes 2 modstande på 68Ω i stedet. Dette resulterer i, at der over elektromagneten ligger en spænding på U magnet = 60Ω 8V, 5V 94Ω Dette er ikke en særlig elegant løsning til at opnå 2V fra 8V, da der bliver afsat en stor spildeffekt i modstandene. Da MSP en skal kunne tænde og slukke elektromagneten, skal en kontakt, der kan åbne og lukke for 8V ved hjælp af 3,3V, bruges. Til dette er valgt en NPN transistor, der kan holde til en strøm på op til 500mA. Da der benyttes en transistor, skal der være en modstand mellem MSP en og transistoren. Dette kan ses på figur 0.7. Den anvendte transistor har en H FE værdi mellem Det ønskes, elektromagneten skal have 200mA, derfor skal strømmen på transistorens base ben være 200mA 00 = 2mA. Det er valgt at regne med H FE værdien på 00, da dette giver den mindste strøm, transistoren skal have, for at åbne for 200mA. For at få denne 3,3V 0,7V 2mA strøm, anvendes en modstand på =, 3kΩ mellem MSP en og transistoren. Dioden, der sidder over elektromagneten, sikrer, at den strøm, der løber i elektromagneten, når transistoren afbryder, ikke tvinges gennem transistoren, men derimod løber gennem dioden i stedet. Dette er nødvendigt for at undgå støj, der kan forstyrre de øvrige kredsløb, da elektromagneten er en spole, og derfor vil forsøge at bevare strømmen gennem sig. Dioden, der sidder mellem MSP en og transistoren, forhindrer, at støj fra kredsløbet løber tilbage i MSP en Design af driver Driveren initialiseres ved kalde funktionen dri mag init(), der sætter porten til output, og sætter værdien lav på porten. Driveren til elektromagneten skal være i stand til at tænde og slukke magneten. Dette gøres vha. void dri mag enable(int enable), der kan kaldes fra kernen med enten 0, eller, afhængigt af om magneten skal være tændt eller slukket Modultest I denne test skal der udvikles en programstub, der først initialiserer moduler og dernæst kalder funktionen dri mag enable() med parameteren. Det verificeres, at der er den korrekte spænding over magneten ved brug af et multimeter. Derefter kaldes samme funktion med parameteren 0, og det verificeres ligeledes, at der ingen spænding ligger over magneten. 0.4 Lyssensor På robothovedet sidder to lyssensorer, herefter sensor, se markering (5) og (7) på Figur 3.2, der kan findes som fold-ud side bagerst i rapporten. De anvendes til at bestemme: om robothovedet er over et felt, og 78

80 KAPITEL 0. MODULDESIGN AF DRIVERE hvilken brik, der er placeret på det givne felt. Begge funktionaliteter anvender samme hardwaretype, og driveren designes derfor som en generel driver for dem begge. Lego Mindstorm stiller en lyssensor til rådighed, og denne anvendes Design af interface til Kerne De eksterne funktioner driveren skal stille til rådighed for kernen, er: void dri light init(void) - Initialiserer Lyssensor-modulet. int dri light bottom value(void) - Returnerer et decimal heltal svarende til lysværdien for lyssensoren i bunden af robothovedet. Denne skal bruges til at identificere, om robothovedet er placeret over et felt. int dri light top value(void) - Returnerer et decimal heltal svarende til lysværdien for lyssensoren i toppen af robothovedet. Denne skal bruges til at bestemme et felts status, jf Disse funktioner vil blive gennemgået i det følgende Analyse af lego lyssensor Alle værdier og målinger, der er foretaget i dette afsnit, afhænger af det omkringliggende kredsløb. Dette er designet i afsnit 0.4.5, og diagrammet kan findes på figur 0.3. Sensoren fungerer anderledes end almindelige lysfølsomme dioder, og analysen af denne tager udgangspunkt i [Barello, 2004], hvor der er fundet inspiration til princippet for, hvordan sensoren fungerer. Sensoren er sluttet til resten af kredsløbet vha. to ledninger, hvilket gør, at tilførsel af strøm og aflæsning af lysværdi ikke kan foregå samtidigt. Dette er illustreret på måleopstillingen A) 9V B) 9V Sensor Sensor Oscilloskob/ Samplingben på MSP Oscilloskob/ Samplingben på MSP Figur 0.8: Måleopstilling for analysering af lyssensor. i figur 0.8. I delfigur A er der 9V over sensoren, og den oplades. Idet kontakten afbrydes, stiger spændingen hvor der måles, da spændingen falder over sensoren. Kurven der dannes, er illustreret i figur 0.9. Forløbet kan beskrives således: Sensoren oplades med en spænding på 9V over en given tid. På figuren stopper denne opladning ved tiderne og 4. Lysværdien aflæses som den spænding, der står over en indre kondensator i lyssensoren i intervallet -2 for mørkest, og 4-5 for lysest. Kondensatoren aflader, og værdien, der aflæses, er udefineret. Lyssensoren kan herefter genoplades. 79

81 KAPITEL 0. MODULDESIGN AF DRIVERE Figur 0.9: Afladningen af en Lego lyssensor målt på samplingspunkterne illustreret i figur 0.8, hvor den højre delfigur er en forstørret version af den venstre. Det øverste signal er en mørk måling, hvor spændingen over lyssensoren er højest, ved det nederste signal er den lyseste måling, hvor spændingen over lyssensoren er lavest. Det ses, at tiden, hvor der skal tages en sampling, er begrænset, på figuren illustreret som det vandrette stykke -2 og 4-5. Den maksimale tid skal bestemmes for den mørkeste værdi, idet tiden -2 her er kortest. Kredsløb internt i en Lego lyssensor Kredsløbet internt i sensoren er komplekst, men en simplificeret udgave kan findes på figur 0.0, hvor selve lys-logikken er udeladt (lysfølsom diode og dertilhørende kontrollogik). Alligevel kan sensorens output beskrives, som på figur 0.9, når den monteres i det omkringliggende kredsløb, skitseret i figur 0.8. Forsyning Forsyning 2 D D3 D5 D6 Lys-logik 2 3 U 5 B 4 C E Q Sampling Sampling 2 R R3 D5 D6 Lys-logik 2 3 U 5 B 4 C E Q D2 D4 R2 R4 C C Figur 0.0: Simplificeret diagram over en Lego lyssensor. Til venstre ses det faktiske kredsløb, hvor der forsynes. Når forsyningen fjernes opstår situationen til højre, hvor dioderne skifter funktion, da samplingen foregår på de samme ben. Inspireret af [Barello, 2004]. Idéen er som følger i opladnings stadiet (indtil tiderne og 4 på figur 0.9): Kredsløbet tilkobles 9V, uafhængigt af polaritet. Dioderne D-D6 fungerer som polvender, og sikrer, at kondensatoren C altid lades op, og at der gemmes en spændingsforskel over collector/emitter benene på transistoren Q. Dette stadie er konstant, indtil der skiftes til sampling stadiet. Når der skiftes til samplings stadiet, er forløbet: Forsyningsspændingen afkobles, og der ligger 9V over C. Lys-logikken giver input til operationsforstærkeren U, som sender en strøm til basen på Q svarende til spændingsforskellen på plus- og minus benet på U. Da U forsynes fra C, afhænger spændingen over C af strømforbruget i U. 80

82 KAPITEL 0. MODULDESIGN AF DRIVERE Lys-logikken kontrollerer, hvor lang tid U bruger strøm, dermed aflader C. Tilbagekoblingen over U gør det muligt at stoppe afladningen af C, hvormed den afmålte lysværdi kan aflæses som spændingen over C. På dette tidspunkt kan lysværdien aflæses (tiderne -2 og 4-5). Værdien, som måles på udgangspins ene, er halvdelen af spændingen over C, da dioderne har ændret funktionalitet fra dioder til store modstande på ca. MΩ stykket. Kredsløbet er efter kort tid udefineret, når U ikke får dens minimale spændingsforsyning (tiderne 2-3 og 5-6). Ved forsøg er der fundet værdier, som er relevante for at benytte sensoren. Disse er:. Opladningstid - tiden det tager at oplade kondensatoren. 2. Klargøringstid - tiden det tager for operationsforstærkeren at aflade kondensatoren til den spænding, der skal måles. 3. Sampletid - periodelængden hvor en god sampling kan foretages. 4. Højeste spænding - spænding, når den lyseste værdi aflæses. 5. Laveste spænding - spænding, når den mørkeste værdi aflæses. Værdierne er bestemt i tabel 0.4, og tiderne er maksimumstider, for at den angivne spændingsforskel eksisterer. Formindskes tiderne yderligere, fungerer sensoren ikke korrekt. Tidsværdierne Opladningstid max. 40µs Klargøringstid max. 20µs Sampletid min. 80µs Højeste spænding 2V Laveste spænding V Tabel 0.4: Målte værdier for Lego lyssensor. vises på skitsen i figur 0.. Spændingsforskellen mellem lysest og mørkest er V, hvilket giver Spændingsforsyning ophører Sensor holder spænding - her skal aflæses Sensor begynder afladning Stadiet herefter er udefineret 40us 20us 80us Figur 0.: Tidsforløb over målte værdier fra tabel 0.4. et fint spændingsspektrum til de funktioner, hver lyssensor skal udføre Analyse af løsning Der er tre forskellige måder, hvorpå lysværdierne kan registreres på MSP en; Software-scan, Timerstyret software-scan og Timerstyret auto-scan vha. PWM 2. Disse gennemgås i de følgende tre afsnit. 2 Pulse Width Modulation 8

83 KAPITEL 0. MODULDESIGN AF DRIVERE Fælles for de tre er, at der anvendes en kontrolpin på MSP en, der styrer hvornår lyssensoren skal forsynes. To andre pins anvendes til sampling af de analoge værdier vha. ADC 3, et til hver lyssensor. ADC konverteringen i MSP en understøtter en angivelse af referencespændingen for analog sampling. Til dette anvendes en nedre grænse på V, se mere i afsnit Den nedre grænse gives til MSP en i form af Vref-. Fordelingen af porte kan ses i tabel 0.5. Funktion Port Pin Kontrol P.7/TA 9 Analog sampling af bund P6./A0 60 Analog sampling af top P6.2/A 6 Referencespænding Vref- Tabel 0.5: Porttildeling for Lyssensor modulet. Funktionerne, som skal returnere lysværdier, ligner meget hinanden, og pseudokoden for løsningsforslagene tager derfor kun udgangspunkt i dri light bottom value(), men kan udvides til også at indeholde dri light top value(). Initialiseringsfunktioner er udeladt i analysen, da det kun er grundprincippet for metoderne, der beskrives Software-scan Dette er den letteste måde til at indhente lys-værdien. Princippet er, at funktionerne fra interfacet implementeres med hele funktionaliteten; spænding på kontrolpin, pauser og sampling. Dette giver en funktionalitet, som beskrevet i følgende pseudokode. function dri light bottom value () 2 begin 3 POUT. 7 ; 4 delay (40 us ) ; 5 POUT. 7 0; 6 delay (20 us ) ; 7 return do adc ( ) ; 8 end Lyssensoren tændes, der holdes pause, hvorefter den slukkes. Herefter skal der ventes tiden indtil det bedste samplingstidspunkt findes. Nu tages samplingen vha. do adc(), og talværdien returneres. Fordele: Simpel implementering. Ulemper: Pauserne er ikke pålidelige, da der kan komme interrupt midt i funktionen. Der ligger pauser i funktionen, og derfor tager det et stykke tid, før der returneres til det kaldende modul. CPU en belastes unødvendigt, da samplingen kaldes fra software. [Gaede, 2002] 3 Analog-to-Digital Conversion 82

84 KAPITEL 0. MODULDESIGN AF DRIVERE Timerstyret software-scan vha. interrupt Ved at anvende denne metode, elimineres to af ulemperne ved den simple metode. Ideen er, at håndtering af tiden for spænding på kontrolpin, pauser og sampling skal foregå sideløbende med forespørgslerne på lysværdier. Funktionaliteten er beskrevet i følgende pseudokode. global bottom value ; 2 3 function dri light bottom value () 4 begin 5 return bottom value ; 6 end 7 8 interrupt timer interrupt () 9 begin 0 case TIME of begin 2 40us : 3 POUT. 7 0; break ; 4 20us : 5 bottom value do adc ( ) ; break ; 6 00us : 7 POUT. 7 ; break ; 8 end 9 end Metoden benytter en global variabel, der indeholder værdien af den sidste nye sampling, og som kan aflæses vha. dri light bottom value(). Der kan ikke aflæses direkte fra registret, hvor værdien fra samplingen ligger, da der kan være en sampling igang. I interruptet styres, afhængigt af tidspunktet, hvorpå interruptet er kaldt, hvilken af følgende handlinger, der skal køres: Sluk lys, foretag AD konvertering eller tænd lys. Fordele: Pauserne mellem forsyning til kontrolpin og sampling kan kontrolleres præcist. Funktionerne, som stilles til rådighed i interfacet, returnerer hurtigt, da de ikke indeholder pauser. Ulemper: Hovedprogrammet afbrydes hver gang der sker et interrupt, hvilket sker ofte. CPU en belastes unødvendigt, da samplingen kaldes fra software [Gaede, 2002] Timerstyret auto-scan vha. PWM Auto-scan er en avanceret udgave af forrige metode, hvor der ikke anvendes interrupt til styringen af kontrolpin og sampling. I stedet anvendes PWM funktionaliteten i timeren til at styre dels udgangspændingen på kontrolpin en, dels samplingstidspunktet for ADC. Pseudokoden er ikke interessant, da det meste af funktionaliteten ligger i initialiseringen af ADC- og timermodulerne. Detajlerne herom kan findes i afsnit Dette gør løsningen interessant, da modulerne ikke belaster CPU en, da de, for CPU en, er perifere enheder. Dvs. programmet ikke bliver afbrudt, hver gang lysværdier samples. Når kernen ønsker en lysværdi, hentes denne direkte fra registret, hvor samplingsværdien ligger, dog med en indledende kontrol af, om der er en sampling i gang. 83

85 KAPITEL 0. MODULDESIGN AF DRIVERE Fordele: Pauserne mellem forsyning til kontrolpin og sampling kan kontrolleres præcist. Funktionerne, som stilles til rådighed for interfacet, returnerer hurtigt, da de ikke indeholder pause. Der anvendes ikke CPU ressourcer til styringen af kontrolpin og sampling [Gaede, 2002]. Hovedprogrammet afbrydes ikke af interrupt, når sampling foretages. Ulemper: Kompliceret implementering ift. foregående metoder Valg af løsning På baggrund af analysen af de tre metoder, er metoden Timerstyret auto-scan vha. PWM valgt. Den valgte løsning stiller følgende hardware og softwarekrav mht. til funktionalitet:. Der skal designes en spændingsdeling, som forsyner Vref- på MSP en med V konstant. 2. Forsyningsspændingen til lyssensorerne skal kontrolleres vha. en kontrolpin på MSP en. 3. Lysværdien for hver lyssensor skal kunne identificeres på MSP en vha. ADC. Én lyssensor pr. pin. 4. PWM skal, vha. en timer, styre ADC og forsyningsspændingen til lyssensoren. 5. Timeren skal kunne håndtere tre tidssammenligninger, hvor handlingerne kontrolpin høj, kontrolpin lav og sampling for både bund og top sensor håndteres. Der er én ADC mulighed i MSP en, ADC2, som anvendes. Timerstyring kan foregå vha. enten Timer A eller Timer B. Timer A har PWM funktionalitet, samtidig med at den har tre sammenligningsregistre, hvor forskellig funktionalitet kan håndteres, og derfor vælges denne Beskrivelse af benyttet MSP-funktionalitet Valget af løsning giver anledning til at beskrive ADC2 samt Timer A. De beskrives i forhold til løsningens anvendelse af komponenterne Timer A og PWM Timer A er en 6-bit tæller, med fire tællemetoder. Disse er: Stop mode - timeren er stoppet. Up mode - timeren tæller gentagne gange fra 0 til værdien af registreret TACCR0. Continous mode - timeren tæller gentagne gange fra 0 til 0xFFFF. Up/down mode - timeren tæller gentagne gange fra 0 til indholdet i TACCR0 og tilbage til 0. Der anvendes Up mode, som beskrives vha. figur 0.2A. Princippet er, at registeret TAC- CR0 bestemmer hvor højt, der skal tælles. Der kan tælles til maksimalt 0xFFFF, deraf de 6-bit, som beregnes udfra den anvendte clock og clock-dividering. Dette sker ved periode = clock Tx clock divider, 84

86 KAPITEL 0. MODULDESIGN AF DRIVERE A) T2 - Pause inden tænd lys (00us) T - Pause inden sampling (20us) T0 - Pause inden sluk lys (40us) TACCR0 TACCR2 TACCR B) Kontrolben Sampling Figur 0.2: Anvendelse af Timer A i Up mode (A), sammen med pulsdiagram for konfiguration af PWM (B). der giver perioderne, bestemt udfra Tx (illustreret vha. T0, T og T2), som anvendes i registrene. Til bestemmelse af hvilken funktionalitet, der skal ligge på de tre sammenligningsregistre TACCR0, TACCR og TACCR2, anvendes PWM. PWM er en modulering af signalet i timeren til enten overførsel af information til andre perifere enheder eller styring af porte. PWM kan konfigureres til forskellige output-modes. Der kan anvendes Set/Reset, som giver en høj værdi, når tiden i TACCRx nås, og nulstilles ved TACCR0. Det giver en pulsplan som i figur 0.2B. Anvendelsen af pulserne varierer, afhængigt af om den skal anvendes til kontrolbenet, eller til styring af ADC samplingen. Når pulsen skal findes på en udgangspin, som den skal for kontrolpin en, skal denne pin sættes til sin alternative funktion. Når pulsen skal anvendes til at trigge andre funktioner, som eks. analog sampling, skal det respektive modul konfigureres til at modtage pulsen. ADC2 Princippet for en AD konvertering er, at få repræsenteret analoge værdier digitalt. ADC2 komponenten i MSP en har en 2 bit repræsentation af den analoge værdi, hvilket betyder, at spændingen mellem den nedre og øvre referencespænding udtrykkes med en opløsning på 0xFFF. Den digitale repræsentation må derfor have inddelingen inddeling = v ref+ v ref 2 2. Dette giver mulighed for en lille inddeling, og derfor nøjagtig, digital repræsentation. I tabel 0.4, er det anvist, at lyssensoren kan fungere ved høj hastighed. I den forbindelse er det interessant, hvor lang tid det tager at udføre én analog sample. Dette bestemmes vha. følgende fremgangsmåde: Sample & hold - Der kigges på det analoge signal i en periode, som er givet ved et antal clockpulse fra ADC2CLK 4, som kører med en frekvens på mellem 3,6 og 6,3Mhz afhængigt af temperatur [Texas Instruments, 2000]. Minimum er 6 pulse, hvilket giver, med den laveste frekvens, at denne proces tager 4 En intern clock i ADC2 komponenten. 6 4, 44µs. 3, 6Mhz 85

87 KAPITEL 0. MODULDESIGN AF DRIVERE Konvertering - Beregningen sker vha. mindre og mindre inddelinger af spændingen, som er gemt, og der udføres altid det samme antal inddelinger. Dette tager altid 3 clockpulse fra ADC2CLK at beregne, hvilket giver 3 3, 6µs. 3, 6Mhz I alt tager en AD konvertering 4, , 6 = 8, 05µs. AD konverteringen er dermed hurtigere end den mulige samplingstid for lyssensoren. Der findes fire forskellige metoder til sampling af analoge værdier vha. ADC2. Metoden, der anvendes, er Sequence-of-channels, single-conversion, hvilket giver mulighed for at foretage AD konvertering for begge lyssensorer. Samtidig ønskes kun en enkelt sampling af hver analoge værdi, som timeren bestemmer hvornår finder sted. ADC2 understøtter, at Timer A, vha. PWM, kan trigge hvornår en sampling foretages. Dette giver, ved sampling på to pins, at der vil blive foretaget en sampling på en pin ved den første opadgående flanke på PWM signalet, og næste sampling vil først blive foretaget på næste opadgående flanke fra PWM signalet. ADC2 understøtter desuden, at flere samples kan tages umiddelbart efter hinanden, hvor der kun trigges en gang af timeren. Til dette benyttes Multiple Samle and Convert (MSC) Design af hardware I afsnit er der stillet tre krav til hardwarens design. Disse giver anledning til et hardwaredesign som på figur 0.3. Når strømmen ind på base benene, på Q og Q2, er 0A, løber der Sample bund +9V Kontrolben R5 2 J C B E Q R7 Sensor bund R9 R0 Vref- Sample top R6 2 J2 B C Q2 R8 Sensor top E Figur 0.3: Diagram over hardware til håndtering af Lego lyssensor. ingen strøm fra collectoren til emitteren, hvilket er det samme som ikke at oplade lyssensoren. Når lyssensoren skal forsynes, skal der løbe strøm gennem Q og Q2. For at give mulighed for fuld gennemgang, anvendes samme princip som i afsnit Hver lyssensor bruger ca. 25mA, og strømmen ind på base benene er derfor 25mA 0 = 0, ma, da H FE = 0 for den anvendte BC547 transistor. Baserne skal derfor forsynes med ca. 0,22mA hver. På denne måde anvendes transistorerne som kontakter, som kan give et spændingsfald over lyssensoren på 9V. Spændingen fra MSP en er 3,3V, og der er 0,7V over base/emitter benene. Dermed kan R5, og R6, som har samme størrelse, dimensioneres således 3, 3V 0, 7V = R 5 0, 22mA R 0kΩ. Jumperne J og J2 bruges til at afbryde en af lyssensorerne, hvilket er anvendt under udviklingsforløbet. R7 og R8 er dimensioneret ved at eksperimentere, da de har indflydelse på 86

88 KAPITEL 0. MODULDESIGN AF DRIVERE afladningen af kondensatoren i de respektive lyssensorer. Ved at anvende 00kΩ s modstande, er spændingerne, som føres ind i MSP en, på et niveau, der aldrig kommer over det maksimale spændingsniveau på 3,3V. Spændingsdelingen, der dannes vha. R9 og R0, anvendes til den V forsyning, som MSP en anvender som Vref-. Hvis R0 bestemmes til 0kΩ, kan R9 bestemmes til 0k 0k + R 9 = R 9 80, 6kΩ. Denne form for spændingsdeling vil ikke give en stabil spænding, men er tilstrækkelig stabil i prototype-sammenhæng Design af driver I afsnit er der stillet to krav til softwaren-design, og vha. af Timer A og ADC2 komponenterne kan disse opfyldes. Driveren til lyssensoren skal kontrollere hardwaren vha. PWM på kontrolpin en, samtidig med at PWM anvendes til at håndtere ADC2. Først gennemgås hvordan ADC2 komponenten konfigureres, hvorefter det gennemgås, hvorledes Timer A konfigureres. Inputtet kommer fra de anviste porte i tabel 0.5. Disse skal Figur 0.4: Block diagram over ADC2. De røde streger illustrerer den valgte konfiguration. [Texas Instruments, 2004] konfigureres til deres alternative funktion, og INCHx konfigureres til at anvende disse porte. Den nedre og øvre referencespænding konfigureres ved at sætte flagene REFON, REF2 5V, S- REF0 og SREF2. Dette giver et spændingsområde mellem V og 2,5V, hvilket stemmer overens med den laveste og højeste spænding målt i tabel 0.4. ADC2DIVx konfigureres til at dividere med 8, da det giver de mest nøjagtige værdier, når ADC2OSC anvendes. I afsnit er den maksimale sampletid bestemt, men med en dividering på. Det approksimeres derfor, at den absolut maksimale sampletid må være 80µs, 87

89 KAPITEL 0. MODULDESIGN AF DRIVERE hvilket er den tid lyssensoren minimum holder samplingsværdien, som vist i tabel 0.4. ADC2 understøtter, at der tages flere efterfølgende samples, men dette kan ikke anvendes, da det kræver en forlængelse af tiden, hvor lyssensoren skal holde lysværdi-spændingen. Samplingen trigges af Timer A ved konfiguration af SHSx, hvor signalet fortsætter igennem Sample Timer, som styrer, hvornår der skal lagres analoge værdier, og hvornår der skal konverteres. Ved en puls, samples top-sensoren, og ved næste samples bund-sensoren. Ved 3. puls samples top-sensoren osv. Dette giver anledning til følgende implementation af initialiseringsfunktionen for ADC2. void adc2 init (void ) 2 { 3 P6SEL = BIT BIT2 ; 4 5 ADC2CTL0 = ADC2ON; 6 7 ADC2CTL0 = REFON; 8 ADC2CTL0 = REF2 5V; 9 0 ADC2CTL = ADC2DIV 7; ADC2CTL = CONSEQ ; 2 ADC2CTL = SHP; 3 ADC2CTL = SHS ; 4 5 ADC2MCTL0 = SREF 5 ; 6 ADC2MCTL0 = INCH ; 7 ADC2MCTL = SREF 5 ; 8 ADC2MCTL = INCH 2 ; 9 20 ADC2CTL0 = ENC; 2 ADC2CTL0 = ADC2SC; 22 } Funktionerne dri light bottom value() og dri light top value() skal hente værdierne fra ADC2MEMx registrene. Dog skal der kontrolleres for, om der finder en sampling sted. Dette giver anledning til følgende implementation. int dri light bottom value (void ) 2 { 3 while (ADC2CTL0 & ADC2BUSY) ; 4 return ADC2MEM0; 5 } 6 7 int d r i l i g h t top v alue (void ) 8 { 9 while (ADC2CTL0 & ADC2BUSY) ; 0 return ADC2MEM; } Timer A kan konfigureres vha. block diagrammet på figur 0.5, hvor den grundlæggende konfiguration ligger i den øverste del. Her konfigureres clocken vha. TASSELx og IDx, og Up mode vha. MCx. Når timeren når en værdi, der ligger i en af sammenligningsregistrene TACCR0, TACCR og TACCR2, udføres den nedre del af figuren. Denne del skal konfigureres ens, da der til alle funktioner, timeren skal udføre, anvendes PWM. Når komparatoren har sammenlignet værdien i TACCRx med timerens værdi, og de er ens, gives et signal til PWMdelen af timeren. Denne del starter med en Output Unit, som styrer hvilket signal, der gives 88

90 KAPITEL 0. MODULDESIGN AF DRIVERE Figur 0.5: Block diagram over Timer A. De røde streger illustrerer den valgte konfiguration. De tre sammenligningsregistre anvendes på samme måde vha. P- WM, som styres af logikken efter comparatoren. [Texas Instruments, 2004] videre. Det er her OUTMODx konfigureres til Set/Reset mode. Signalet fortsætter, fra Output Unit til en D-latch, som holder outputværdien på Q indtil næste puls. Figur 0. sammen med tabel 0.4 giver mulighed for at bestemme værdierne, der skal anvendes i sammenligningsregistrene. Dette giver anledning til følgende implementation af initialiseringsfunktionen for Timer A. int timer a i n i t (void ) 2 { 3 unsigned int p0, p, p2 ; 4 5 TACTL = TASSEL SMCLK; 6 TACTL = ID DIV8 ; 7 TACTL = MC UPTO CCR0; 8 9 TACCTL = OUTMOD SET RESET; 0 PSEL = BIT7; 2 PDIR = BIT7; 3 TACCTL2 = OUTMOD SET RESET; 4 5 if ( calc period(&p0, )) 6 return ; 7 if ( calc period(&p, )) 8 return ; 9 if ( calc period(&p2, )) 20 return ; 89

91 KAPITEL 0. MODULDESIGN AF DRIVERE 2 22 TACCR0 = p0 ; 23 TACCR = p ; 24 TACCR2 = p2 ; return 0; 27 } Modultest Testen af drivermodulet og hardwaren foretages ved at analysere spændingerne på samplingpins ene. Til dette anvendes et oscilloskop, og et output fra testen kan findes i figur 0.6. Her Figur 0.6: Målte spændinger for mørk påvirkning af lyssensor (øverst), og lys påvirkning (nederst). Frekvensen følger tiderne anvist i tabel 0.4. Inddelingen på den lodrette akse er V. ses det, at spændingerne ligger fint inden for intervallet på V og 2,5V. Decimal talværdierne, som aflæses på MSP en, er for mørkest ca. 430, og for lysest ca. 3000, hvilket giver en god mulighed for at skelne mellem farver med lyssensoren. 0.5 RS232 For at robotten kan kommunikere med PC-stubben, benyttes en seriel forbindelse via RS232. Indbygget i MSP en er to USART s 5, som er perifere enheder, der gør det enkelt at benytte serialkommunikation via RS232-protokollen. Kort fortalt håndterer en USART afsendelse og modtagelse af data via en seriel forbindelse. Når et program skriver i et bestemt register på MSP en, vil USART en begynde at transmittere den skrevne byte serielt via et pin på MSP en. Samtidig vil USART en i baggrunden modtage evt. serielle data på en anden pin, og omforme de modtagne data til en byte, som gemmes i et register. MSP en kan sættes op til at kalde et interrupt ved endt afsendelse eller modtagelse af en byte. Dette afsnit har til formål at designe den hardware og software, der gør serialkommunikation tilgængeligt for de øvrige moduler i programmet. 5 Universal Synchronous/Asynchronous Receive/Transmit 90

92 KAPITEL 0. MODULDESIGN AF DRIVERE 0.5. Design af interface til kernen Følgende funktioner skal stilles til rådighed for kernen: void dri rs232 init(int baud rate) - Initialiserer drivermodulet med den angivne baud-rate. char dri rs232 getchar(void) - Modtager den næste karakter fra den serielle forbindelse, og returnerer denne. Hvis der ikke er en karakter, der kan læses, venter funktionen indtil den næste kommer, og den returneres. Funktionen dri rs232 getchar() vil blive gennemgået i det følgende. Funktionen putchar() kan også betragtes som en ekstern funktion i modulet, men denne funktion er ikke direkte en del af interfacet til kernen, da den blot benyttes af printf() som tidligere beskrevet Analyse af løsning I det følgende vil to løsningsmuligheder blive analyseret. De to løsningsmuligheder har betegnelserne unbuffered og buffered. Funktionen dri rs232 getchar() benævnes kort getchar(), mens den interne funktion putchar() faktisk har dette navn, da printf() i compilerens standardbiblioteket afhænger af en funktion med dette navn Unbuffered Den simpleste måde at implementere putchar() og getchar() vil være blot at læse og skrive direkte til og fra USART ens transmit- og receive-registre, således at data afsendes i samme øjeblik putchar() kaldes, og sidst ankomne data aflæses, når getchar() kaldes. Denne fremgangsmåde har dog nogle indlysende problemer. F.eks. skal putchar() som minimum sikre sig, at afsendelse af evt. tidligere data er færdig, før den sender igen ved at overskrive registret. I ventetiden vil CPU en ikke kunne køre andre dele af programmet. getchar() skal på samme måde sikre sig, at de modtagne data er klar til at blive læst, og også i denne ventetid kan andre dele af programmet ikke køres. Denne metode kaldes også unbuffered, da der ikke benyttes en buffer til afsendte og modtagne data. Fordele: Simpel at implementere. Lavt hukommelsesforbrug. Ulemper: Det risikeres, at modtagne data mistes. Kan ikke køre andre programdele samtidig med afsendelse og modtagelse af data Buffered En anden og smartere metode er at benytte buffere og interrupts til afsendelse og modtagelse af data. Her benytter putchar() og getchar() ring-buffere til at gemme sendte og modtagne data, så der ikke mistes noget undervejs. Samtidig benyttes interrupts, der kaldes, når afsendelse og modtagelse af en byte er færdig, således at programmet ikke låser, når funktionerne kaldes. Kald til putchar() vil blot tilføje karakteren til den interne sende-buffer. Hver gang interrupten, der køres, når en byte er afsendt, kaldes, bliver den næste karakter i bufferen afsendt og fjernet fra bufferen igen. Hvis sende-bufferen er tom, når putchar() kaldes, skal karakteren afsendes direkte, da der i den situation ikke vil komme en interrupt. Hvis putchar() efterfølgende kaldes, inden den første karakter er afsendt, vil karaktererne tilføjes til bufferen, og de bliver automatisk sendt en af gangen, når den forrige karakter er afsendt og interrupten bliver kaldt. 9

93 KAPITEL 0. MODULDESIGN AF DRIVERE På denne måde kan programmet køre videre uden at skulle vente på, at alle data er fuldstændig afsendt. Ligeledes vil kald til getchar() blot returnere den første karakter i modtage-bufferen og fjerne den fra bufferen. Hvis bufferen er tom, vil funktionen blokere, indtil der er data, der kan modtages. Interrupten, der kaldes, når en byte er modtaget, vil blot gemme den modtagne karakter i modtage-bufferen, så den kan hentes med getchar(). Selvom denne løsning vil sikre, at man i de fleste situationer ikke mister data, er det stadig ikke helt sikkert. Det skyldes at størrelsen på ring-bufferne er begrænset, og hvis der modtages mere data, end der er plads til i modtage-bufferen, hurtigere end programmet læser dataene, vil der stadig kunne mistes data. Det samme gør sig gældende, hvis programmet skriver data til sende-bufferen, hurtigere end der kan sendes. Men dette undgås ved, at putchar() vil vente indtil der igen er plads i bufferen. Fordele: Låser ikke programmets udførsel ved afsendelse og modtagelse af data. God sikkerhed for, at modtagne data ikke mistes. Ulemper: Stiller større krav til implementationen. Har større hukommelsesforbrug end ved unbuffered Valg af løsning På denne baggrund er det, i dette projekt, valgt at benytte buffered serial-kommunikation, da det er vigtigt ikke at miste information, der modtages fra PC-stubben. Dette kræver brugen af en USART i MSP en, hvor USART0 er valgt, samt dennes transmit- og receive-pins. I tabel 0.6 ses hvilke pins på MSP en, der benyttes til serial-kommunikationen. En beskrivelse af USART0 følger i næste afsnit. Funktion Port Pin TX (transmit) P3.4/UTXD0 32 RX (receive) P3.5/URXD0 33 Tabel 0.6: Porttildeling for drivermodulet til serial-kommunikation. Der benyttes desuden interrupts, der kaldes, når USART0 har modtaget og afsendt data Beskrivelse af benyttet MSP-funktionalitet Valget af løsning giver anledning til at beskrive anvendelsen af USART0. Beskrivelsen fokuserer på den specifikke anvendelse af funktionaliteten i projektet. Seriel kommunikation og USART0 Det følgende er baseret på [Texas Instruments, 2004]. Ved seriel kommunikation sendes en enkelt bit af gangen, sekventielt over en bus. I MSP en kan op til to USARTs benyttes til seriel kommunikation. Det giver mulighed for både at modtage og sende data til og fra MSP en til andet hardware. Der sendes og modtages data, på to forskellige pins på MSP en, og der kan derfor både sendes og modtages data samtidigt. Til den kommunikation, der benyttes i dette projekt, benyttes den ene USART i asynkron tilstand (UART). I asynkron tilstand er følgende konfigurationsmuligheder til stede: 92

94 KAPITEL 0. MODULDESIGN AF DRIVERE Op til otte data-bit, medmindre paritets-bit 6 vælges. Hvis paritets-bit vælges, er kun syv data-bit tilgængelige og den sidste bit kan både sættes til lige og ulige paritet. Uafhængige transmit- og recieve-shift-registre, samt seperate transmit- og recieve-buffers. Når der afsendes en byte fra MSP en, flyttes denne til transmit-bufferen, hvorfra det flyttes til transmit-shift-registret, hvor hver bit sendes en af gangen. Modsat er forløbet når der modtages. Mulighed for valg mellem et eller to stopbit. Programmerbar baud-rate. Status-flag til bl.a. fejl-detektering. Uafhængige interrupts til transmit og recieve. Figur 0.7: Tidsforløbet ved transmission af en byte over en seriel bus. På figur 0.7 ses hvordan en overførsel kan finde sted. Signalet er som standard høj, og transmissionen starter ved, at en start-bit sendes. Start-bitten er altid lav, og den nedafgående flanke i begyndelsen af start-bitten signalerer således starten på transmissionen. Herefter kan en overførsel finde sted på op til syv eller otte databit afhængigt af om paritet anvendes. Til slut sættes signalet igen højt ved hjælp af en stop-bit. Når to enheder kommunikerer via en seriel forbindelse skal de selvfølgelig være enige om, hvordan kommunikationen foregår. Til kommunikation med PC-stubben sættes USART0 og den anvendte terminal-emulator MiniCOM op på følgende måde: Baud-rate på data-bit. Ingen paritet. stop-bit. Interrupts ved både transmit og receive. For at opnå den rigtige timing er det vigtigt, at MSP en overholder baud-raten præcist. Derfor benyttes den eksterne krystal, XT2, som genererer en clock på 7,3728 MHz, til at time USART en Design af hardware Selvom MSP en indeholder en USART, der kan benyttes til serial-kommunikation, skal der noget eksternt hardware til, før forbindelsen overholder RS232-standarden. MSP en forsynes med 3,3V, og derfor er det også denne spænding, den sender og forventer på transmit- og 6 En paritets-bit kan anvendes til at verificere transmitteret data. 93

95 KAPITEL 0. MODULDESIGN AF DRIVERE receive-pins ene. Imidlertid benyttes helt andre spændinger i RS232-standarden. De gyldige spændinger kan ses i tabel 0.7. Niveau Transmit (V) Receive (V) Space (0) Mark () Udefineret Tabel 0.7: Gyldige spændinger i RS232-standarden. Space og Mark er de to tilstande, en leder kan have, og de repræsenterer hhv. logisk 0 og. [Bies, 2004] Til at foretage konverteringen af spændingerne mellem MSP en og RS232-forbindelsen findes en række IC er. Her er valgt at benytte en MAX3232, som indeholder to kanaler til serielkommunikation, hvoraf kun den ene benyttes. Denne IC kan forsynes med 3,3V som MSP en og den opbygger selv de højere spændinger, som RS232 kræver, vha. en række kondensatorer. På figur 0.8 er vist, hvordan MAX3232 er koblet til MSP en og RS232-forbindelsen. +3.3V MSP TX 0,uF C VCC C+ C2+ MAX C- C2- CMOS ,uF 5 4 C2 C5 0,uF RS232 TX MSP RX RS232 RX 9 6 V- V+ GND C4 0,uF C3 0,uF Figur 0.8: Kredsløbsdiagram for interfacet mellem MSP og RS232. Kredsløbet er baseret på en typisk applikation i [Maxim, 2003]. MSP TX på diagrammet forbindes til port P3.4/UTXD0 (pin 32) på MSP en, og MSP RX forbindes til port P3.5/URXD0 (pin 33), jf. tabel 0.6. Spændingerne på disse pins vil ligge indenfor MSP ens gyldige område, dvs. 0-3,3V. På diagrammets modsatte side ses RS232 TX og RS232 RX, som udgør RS232- forbindelsen. MAX3232 godtager op til ±25V på RS232 RX-pin en, og sender op til ±3.2V på RS232 TX-pin en. [Maxim, 2003] Design af driver Dette drivermodul har to eksterne funktioner: dri rs232 init() og dri rs232 getchar(). Yderligere indgår der i modulet en række interne datastrukturer, variable og funktioner, hvoraf de vigtigste beskrives i det følgende. Funktionerne er bl.a. putchar() og de interrupt-funktioner, der kaldes, når USART en er færdig med at sende og modtage. Driverens design er baseret på [IAR Systems, 999]. Datastrukturer Sende- og modtage-bufferne implementeres som ring-buffere. Hver ring-buffer indeholder dels et array på en fast størrelse, som tilpasses for at opnå tilstrækkelig sikkerhed for, at der ikke mistes 94

96 KAPITEL 0. MODULDESIGN AF DRIVERE modtagne data. Array et benævnes buffer, og desuden indeholder hver ring-buffer følgende oplysninger: write index - det næste index, der skal skrives på i bufferen. read index - det næste index, der skal læses fra i bufferen. char count - antallet af karakterer i bufferen. buffer empty - flag, der indikerer, om bufferen er tom (benyttes til synkronisering). Variable Følgende variable indgår internt i modulet: rx buffer - Ring-buffer til modtagne data. tx buffer - Ring-buffer til data, der skal transmitteres. Funktioner void putchar ( int c ) 2 { 3 tx buffer. buffer [ tx buffer. write index++] = c ; 4 tx buffer. write index = tx buffer. write index % BUFFER SIZE; 5 tx buffer. char count++; 6 7 if ( tx buffer. buffer empty &&! ( IFG & UTXIFG0)) 8 { 9 tx buffer. buffer empty = 0; 0 U0TXBUF = tx buffer. buffer [ tx buffer. read index ++]; tx buffer. read index = tx buffer. read index % BUFFER SIZE; 2 tx buffer. char count ; 3 } 4 } Linje 3-5 i putchar() tilføjer karakteren til transmit-bufferen. I linje 7 tjekkes, om bufferen er tom og at USART en ikke er ved at transmittere. Er det tilfældet skal karakteren skrives direkte til TX-registret, så USART en starter overførslen, og dette sker i linje 9-2. Hvis putchar() kaldes igen, inden USART en har transmitteret den første karakter, vil karakteren blot blive gemt i bufferen, og den bliver automatisk sendt, når transmit-interruptet kaldes. interrupt (UART0TX VECTOR) uart0 tx (void) 2 { 3 if ( tx buffer. char count ) 4 { 5 U0TXBUF = tx buffer. buffer [ tx buffer. read index ++]; 6 tx buffer. read index = tx buffer. read index % BUFFER SIZE; 7 tx buffer. char count ; 8 } 9 else 0 tx buffer. buffer empty = ; } uart0 tx() er funktionen, der kaldes, når USART en har transmitteret en byte. Funktionen undersøger, om der er yderligere data i bufferen, der skal sendes. Er det tilfældet, sendes næste byte, som efterfølgende slettes fra bufferen (linje 5-7). Ellers sættes buffer empty-flaget for transmit-bufferen, så putchar() ved, at den skal sende næste karakter direkte. 95

97 KAPITEL 0. MODULDESIGN AF DRIVERE Samme princip gælder for modtagelse. Her er rollerne blot byttet om, så uart0 rx() (interruptfunktionen, der kaldes efter modtagelse) skriver modtagne data til receive-bufferen. Og getchar() læser karaktererne fra receive-bufferen. Hvis der ikke er data i receive-bufferen, vil getchar() blokere, indtil der modtages data. Koden for de resterende funktioner er ikke inkluderet, da den i grove træk minder om de ovenstående Modultest Der skreves en test-driver, som inititaliserer driveren og derefter blot sender alle karakterer, der modtages via RS232-forbindelsen, retur. Til at teste, benyttes en tilsluttet PC med en terminal-emulator, f.eks. MiniCOM. 0.6 Motorer I mekanikdelen anvendes fem Lego DC elektromotorer. Numrene der henvises til, kan findes på Figur 3.2, der kan findes som fold-ud side bagerst i rapporten. Der anvendes to motorer til at navigere robothovedet i x-retningen. (3) Der anvendes en motor til at navigere robothovedet i y-retningen. (3) Der anvendes to motorer til den del af robothovedet, hvorpå elektromagneten og toplyssensoren er monteret, således at de to kan placeres under samme felt på brættet. (9) Denne benævnes u-retningen. De tre retninger benævnes henholdsvis x-motoren, y-motoren og u-motoren Design af interface til kernen Denne driver stiller følgende funktioner til rådighed for kernen: void dri engine init(void) - Initialiserer modulet. void dri engine start x(int direction) - Starter motoren på x-aksen i positiv retning, hvis direction er positiv, ellers i negativ retning. void dri engine start y(int direction) - Starter motoren på y-aksen i positiv retning, hvis direction er positiv, ellers i negativ retning. void dri engine stop x(void) - Stopper motoren på x-aksen. void dri engine stop y(void) - Stopper motoren på y-aksen. void dri engine set magnet(void) - Sætter magneten i position under feltet. void dri engine set light(void) - Sætter top-lyssensoren i position under feltet. Disse funktioner beskrives i det følgende Analyse af DC elektromotor De anvendte elektromotorer er fra Lego Robotics Invention System.5, og er af typen 7427, de benævnes herefter som Lego motorer. Lego motorerne er 9V DC elektromotorer Analyse af løsning Hver motor styres af to pins på MSP en, se evt. logikken vist i tabel 0.9. Det skal være muligt at køre fremad, tilbage og stoppe de fem motorer i begge retninger, og det skal være muligt med 3.3V digital logik. Ligeledes skal det være muligt at stoppe motorerne, for at sikre, at robothovedet stoppes på den ønskede placering. Portene, hvorpå hardwaren er koblet til MSP en, kan findes i tabel

98 KAPITEL 0. MODULDESIGN AF DRIVERE L L2 Resultat 0 Fremad 0 Bagud 0 0 Stands Stands Figur 0.9: Logik for styring af én Lego motor. L og L2 er to digitale output fra MSP en, og dermed også input til det kredsløb, der skal oversætte spændingerne til 9V. Funktion Port Pin Motor X P Motor X2 P4. 37 Motor Y P Motor Y2 P Motor U P Motor U2 P4.5 4 Tabel 0.8: Porttildeling for motormodul Design af hardware For at styre en motor, som beskrevet i afsnit 0.6.3, benyttes en L298 [STMicroelectronics, 2000] (Dual full-bridge driver). Én L298 kan styre to motorer, derfor benyttes to L298 ere, som derved giver mulighed for at styre fem individuelle motorer. En DC elektromotor indeholder én eller flere spoler, og derfor vil strømmen igennem den altid være kontinuerlig. Dette kan give problemer, da det kan resultere i, at motoren tager omdrejninger efter, der ikke længere er spænding over den. L298 afhjælper dette problem, da den kan koble motoren til stel, når den skal stoppes. Derved bliver kurven, for afladning af motoren så stejl, at motoren ikke tager ekstra omdrejninger. 9V 3.3V L298 U L298 U SENSE A 2 OUT SENSE A 2 OUT 3 OUT 2 Vs OUT 2 Vs 4 3 LX 5 IN EN A 6 2 LU 5 IN EN A 6 2 JY LX2 7 IN2 GND 8 LU2 7 IN2 GND LOGIC Vs EN B IN 3 IN LY LY2 JV JX 9 LOGIC Vs EN B IN 3 IN LV LV2 JU 3 3 OUT 3 OUT OUT 3 OUT SENSE B 2 5 SENSE B 3 MY MX MV MU 00uF 00uF Figur 0.20: Diagram for motorstyring. Kredsløbet til styring af motorerne er vist på figur LX og LX2 er de to input til styring af x-motoren, LY og LY2 er for y-motoren, osv. Der er fire jumperpins, JX, JY, JU og JV. Ved at kortslutte enten pin og pin 2 eller pin 2 og pin 3, på jumperpinsene, kan hver 97

99 KAPITEL 0. MODULDESIGN AF DRIVERE motor enables eller disables. MX, MY, MU og MV er de fem motorer som kredsløbet kan kontrollere. L298 erne er derudover tilsluttet som beskrevet i [STMicroelectronics, 2000] under Bidirectional DC Motor Control Design af driver Designet er ikke beskrevet, da det opfattes som trivielt Modultest Modultest af motorer foretages ved at kalde dri engine init(), der initialiserer motordriveren. For hver af x-, y- og u-motorerne, startes de i den ene retning, derefter den anden retning og sidst stoppes de. Det tjekkes, at motorerne kører som forventet. Sidst køres dri engine set magnet() og dri engine set light(), og det tjekkes at henholdsvis magneten og lyssensoren sættes i den rette position. 98

100 Kapitel Udførsel af accepttest Dette kapitel indeholder udførslen af de opstillede tests, designet i kapitel 5. Udførslen beskrives i samme rækkefølge, hvor der under hver test er beskrevet: Formål - Beskriver formålet med testen. Udførsel og resultater af test - Beskriver udførslen af test, og resultaterne. Testkonklusion - Konkluderer på de enkelte tests. I slutningen af kapitlet, afsnit.2, er en kort sammenfatning af testens resultater.. Testemner.. Test af kørsel af skak Formål - Denne test verificerer, at et spil skak forløber korrekt, jf. afsnit 5... Udførsel og resultater af test - Testen udføres, som beskrevet i Udførsel af test, i afsnit 5... Ved udførsel af alle tjeks, opførte prototypen sig som forventet. Testkonklusion - Prototypen følger afviklingen af spil, som beskrevet i afsnit 5... Det beskræftes, at de funktionelle krav: Kommunikation med PC-stub, Visning på display, Brætopstilling, Flyt robothoved, Feltstatus og Flyt brik, er opfyldt...2 Test af korrekt spilstatus Formål - Denne test viser at spilstatus opdateres korrekt, jf. afsnit Udførsel og resultater af test - Testen udføres, som beskrevet i Udførsel af test, i afsnit Testen viser, at prototypen er i stand til at skifte tilstand som forventet, jf Testkonklusion - Prototypen kan skifte tilstand, som beskrevet i afsnit Test af slået brik Formål - Denne test verificerer, at håndteringen af slået brik forløber korrekt, jf. afsnit Udførsel og resultater af test - Testen udføres, som beskrevet i Udførsel af test, jf. afsnit Testen viser, at prototypen kan slå en brik for modspilleren, og flytte denne udenfor brættet og derefter bede spilleren om at fjerne brikken. Testkonklusion - Prototypen er i stand til at håndtere en slået brik, som beskrevet i det funktionelle krav Håndter slået brik 99

101 KAPITEL. UDFØRSEL AF ACCEPTTEST..4 Test af håndtering af specialtilfælde Formål - Testen viser, at robotten kan håndtere specialtilfælde, jf. afsnit Udførsel og resultater af test - Testen udføres som beskrevet i Udførsel af test, jf. afsnit Testen viser at prototypen korrekt registrerer, og håndterer, en passant, rokade og bondeforvandling for både spiller og modspiller. Dog kunne prototypen ikke fjerne den hvide brik på C4 korrekt. Brikken blev flyttet til H4, men ikke udenfor skakbrættet. Problemet skyldes, at elektromagneten ikke fik fat i brikken. Testkonklusion - Prototypen er i stand til at håndtere specialtilfældene rokade, en passant og bondeforvandling, som beskrevet i det funktionelle krav Håndter specialtilfælde. Dog fandt testen et andet problem, idet elektromagneten kan have problemer med at føre brikker over skak-brættet...5 Test af flytningsalgoritmen Formål - Testen viser, hvorvidt flytningsalgoritmen finder en nær optimal rute, jf. afsnit Udførsel og resultater af test - Testen udføres som beskrevet i Udførsel af test, i afsnit Robotten udfører begge træk nær optimalt. På figur. ses, hvordan flytningen i worst case eksemplet finder sted, og på figur.3 ses, hvordan flytningen i en rokade finder sted. Testkonklusion - Flytningsalgoritmen opfylder det funktionelle krav Flytningsalgoritme, da den kan udregne en rute for at flytte en brik fra et felt til et andet, med en nær optimal rute...6 Test af skanningsalgoritmen Formål - Testen verificerer, at skanningsalgoritmen fungerer korrekt, jf. afsnit Udførsel og resultater af test - Testen udføres som beskrevet i Udførsel af test, jf. afsnit Skanningsalgoritmen opfylder det funktionelle krav Skanningsalgoritme, da den kan udregne en rute for at skanne et antal brikker, med en nær optimal rute. På figur.4 ses, hvordan skanningen forløb under testen i worst case, og på figur.2 ses, hvordan flytningen i en rokade finder sted. Testkonklusion - Skanningsalgoritmen opfylder det funktionelle krav Skanningsalgoritme, da den beregnede rute for hvordan robothovedet skal flytte sig, for at skanne et antal givne felter med færrest mulige bevægelser af robothovedet, er nær optimal..2 Sammenfatning Accepttesten er hovedsageligt bestået, dog med en undtagelse. Prototypen er i stand til at afvikle et skakspil, som beskrevet i afsnit 4.., og opfylder alle de funktionelle krav fra kravspecifikationen. I Test af slået brik blev den slåede brik håndteret korrekt, men under testen af specialtilfælde fejlede håndtering af slået brik. Dette skyldes at elektromagneten ikke kunne få fat på magneten under brikken. Brikken har enten været for tung, eller afstanden mellem brættet og elektromagneten for stor. Dette problem vil blive taget op igen i konklusionen på rapporten i kapitel 2 og diskuteret i kapitel 3. 00

102 KAPITEL. UDFØRSEL AF ACCEPTTEST a b c d e f g h a b c d e f g h a) b) a b c d e f g h a b c d e f g h c) d) Figur.: Forløbet i test af flytningsalgoritmen. Det ønskede træk er A8-H8. Brikken, der skal flyttes er markeret med grøn. a) Udgangsposition: De røde pile viser, hvordan brikkerne flyttes væk fra stien. b) Brikken flyttes langs pilen fra A8 til H8. c) Oprydning: Pilene viser, hvordan brikkerne flyttes tilbage på plads. d) Skakbrættet efter udførsel af trækket. Denne flytning udføres med 79 flytninger af robothovedet a b c d e f g h Figur.2: Forløbet for skanning i test af skanningsalgoritmen i startopstillingen. Dette forløb resulterer i 5 flytninger af robothovedet. 0

103 KAPITEL. UDFØRSEL AF ACCEPTTEST a b c d e f g h a b c d e f g h a) b) a b c d e f g h a b c d e f g h c) d) a b c d e f g h e) Figur.3: Forløbet i test af flytningsalgoritmen i en rokade. Det ønskede træk er E-G. Brikkerne, der skal flyttes er markeret med grøn og blå. a-d) De røde pile viser, hvordan brikkerne flyttes. e) Skakbrættet efter udførsel af trækket. Denne flytning udføres med 24 flytninger af robothovedet a b c d e f g h Figur.4: Forløbet for skanning i test af skanningsalgoritmen. De røde pile viser, hvilken rækkefølge, punkterne skannes i. Dette forløb resulterer i 45 flytninger af robothovedet. 02

104 Kapitel 2 Konklusion Denne rapport omhandler udviklingen af en prototype af en robot som interface mellem et skakbræt og en computer. I første og andet kapitel er spillet skak analyseret og prototypens hardwareopstilling gennemgået. De krav, skak og hardwareopstillingen stiller til prototypen, opstilles i slutningen af projektbeskrivelsen. I kravspecifikationen nedbrydes spillet skak i funktionaliteter ud fra kravene fra projektbeskrivelsen. Dette fører til en række funktionelle krav, prototypen skal opfylde. Der designes en accepttest, der sikrer, at de funktionelle krav opfyldes. I design kapitlet opdeles programmet i tre lag, hvor funktionaliteterne fra kravspecifikationen fordeles i: applikationslaget, kernen og drivere. Funktionaliteterne samles i moduler og specificeres i procesdesign. De efterfølgende kapitler beskriver designet af de tre lag. Først brydes programmets overordnede funktionaliteter i applikationslaget ned. Der analyseres på de algoritmer, der anvendes i prototypen, og på de funktionaliteter, dette lag skal have. I moduldesignet af kernen brydes programmets funktionaliteter yderligere ned, indtil det er muligt, i moduldesignet af drivere, at designe drivere til hardwarekomponenterne fra projektbeskrivelsen. I moduldesignet af drivere drages hardwaren ind og analyseres. Efter implementeringen af prototypen er accepttesten udført og alle tests er bestået. Prototypen har igennem tests vist, at den kan afvikle et spil skak, som specificeret i flowchartsene i kravspecifikationen. Den kan håndtere specialtilfælde og fjerne slåede brikker. Dog opstod der fejl ved håndtering af slået brik i en af testene. Både skannings- og flytningsalgoritmen bestod accepttesten og er nær optimale, efter definitionerne i hver test. Dermed konkluderes det, at opbygningen af prototypen er implementeret korrekt, ift. kravspecifikationen. Af problemer ved implementeringen af prototypen kan nævnes: Afstanden mellem brættet og robothovedet, samt brikkernes vægt, har stor indflydelse på elektromagneten og lyssensorens effektivitet. Bliver afstanden for stor, er differensen i lyssensorens målinger mellem sort, hvid og ingen brik for små, så lyssensoren ikke altid registrerer korrekt feltstatus. Bliver afstanden for lille, trækker robothovedet rundt på brikker, selvom elektromagneten ikke er tændt. Dette skyldes at jernet i elektromagneten tiltrækkes af magneterne i brikkerne. Belysningen omkring robotten har stor betydning for de lysværdier, robotten registrerer med begge lyssensorer. De problemer, der er opstået under implementeringen, diskuteres i det næste kapitel, hvorefter der perspektiveres over videreudviklingen af prototypen. 03

105 Kapitel 3 Diskussion og perspektivering Dette kapitel diskuterer problemerne fundet i konklusionen og foreslår løsninger, og der perspektiveres på videreudvikling af prototypen. 3. Diskussion I dette afsnit opstilles løsningsforslag til problemerne fra konklusionen: Brættets afstand til elektromagnet. Lysværdier ændrer sig afhængigt af belysning. Brættets afstand til elektromagnet Da elektromagneten kun skal trække rundt med brikker, når den er tændt, kan vægten af brikkerne forøges. Dog kun så meget, at elektromagneten stadig kan flytte med dem. For at sikre, at der er den optimale afstand mellem brættet og elektromagneten, kan en analyse foretages, hvor vægten af brikkerne, og afstanden mellem bræt og magnet varieres. Analysen skal afdække tre grænser: Hvornår den øverste lyssensors grænseværdier begynder at overlappe, hvornår robothovedet begynder at kunne flytte brikker med slukket elektromagnet, og hvornår robothovedet ikke længere kan flytte brikker med tændt elektromagnet. Ud fra denne analyse, kan det bestemmes, hvad afstanden mellem bræt og elektromagnet skal være, og hvad brikkerne skal veje. Alternativt kunne en kraftigere elektromagnet anvendes sammen med jernkerner i brikkerne. Lysværdier ændrer sig afhængigt af belysning Da den øverste lyssensor peger op under skakbrættet, afhænger lysværdierne, der aflæses, når der ikke står en brik, af belysningen i rummet. Hvis skakbrættet påvirkes af ekstern lyskilde, kan lysværdierne variere meget, alt efter, hvor på brættet der aflæses, at der ikke står en brik. Det medfører, at målingerne, der bestemmer, at der ikke er en brik, nemt kan overlappe med de målinger, der identificerer de hvide og sorte brikker. En alternativ løsning vil være ikke at registrere farveværdier over feltet, men benytte en anden, og mere sikker, måde at bestemme, hvilken farve brikken på feltet har, eller bestemme nøjagtig hvilken brik det er. Dette kunne f.eks. gøres ved hjælp af en sort/hvid kodet dot-matrix under brikkerne, og en aflæser til disse på robothovedet. 04

106 KAPITEL 3. DISKUSSION OG PERSPEKTIVERING 3.2 Perspektivering Gennem projektforløbet opstod ideer til udvidelser af prototypen, samt ideer til andre områder, hvor prototypen, med få modifikationer, kan anvendes. Et af perspektiverne er, at skakrobotten kan kommunikere med nogle af de eksisterende computerskakspil, hvilket vil muliggøre, at spille skak mod en computer. Der vil også være mulighed for at spille mod andre skakspillere over internettet, der enten spiller skak på en computer, eller spiller med en lignende robot. Dette kan evt. bruges i forbindelse med skakturneringer, så skakspillerne kan sidde hjemme og deltage, i stedet for at rejse til turneringerne. En anden forbedring vil være, hvis spil kan gemmes på skakrobotten, eller en computer, så tidligere spil kan genoptages. Dette vil også forbedre robotten i tilfælde af strømafbrydelse, da igangværende skakspil gemmes i prototypens RAM, og derfor går tabt, når strømmen bliver taget fra robotten. Sammen med dette, vil det være en fordel, hvis robotten selv kan stille skakbrikkerne op på deres korrekte positioner, så der ikke sker fejl ved opstilling fra spillerens side. Skak minder på mange måder om andre brætspil, f.eks. dam, stratego, mølle, etc. Det vil være muligt, med få modifikationer af robotten og dele af softwaren, at spille nogle af disse andre spil med robotten. I tilfælde af markedsføring af robotten vil dette naturligvis være en fordel, da dette vil give en større målgruppe. 05

107 Litteratur [Barello, 2004] Barello, L. (2004). Lego sensor page. projects/lego/. [Bies, 2004] Bies, L. (2004). Fundamentals of rs-232 serial communications. lammertbies.nl/comm/info/rs-232 specs.html. [Cormen et al., 200] Cormen, T. H., Leiserson, C. E., Rivest, R. L., and Stein, C. (200). Introduction to Algorithms. The MIT Press, 2st edition. [David, 2006] David, A. (2006). Algorithms and architecture - lecture. On the web. http: // adavid/teaching/aa/aa-06/course.html#lecture. [Gaede, 2002] Gaede, R. K. (2002). Msp430 advanced technical conference. On the web. http: // gaede/cpe42/manuals/ atc workshop.pdf. [IAR Systems, 999] IAR Systems (999). Serial interface driver with circular buffer for the msp series. IAR Application Note [IBM, 969] IBM (969). IBM Data Processing Techniques - Flowcharting Techniques. [Maxim, 2003] Maxim (2003). Max3232 datablad. [Powertip, 2006] Powertip (2006). Pc604-a datablad. product/pcseries/pc0604-a.pdf. [STMicroelectronics, 2000] STMicroelectronics (2000). L298 - dual full-bridge driver. [Tanenbaum, 2006] Tanenbaum, A. S. (2006). Structured Computer Organization. Prentice Hall, 5th edition. [Texas Instruments, 996] Texas Instruments (996). Sn74lvcc4245a datablad. sjjmicro.com/docs/sn74lvcc4245aseries.pdf. [Texas Instruments, 2000] Texas Instruments (2000). Msp430f49 datablad. [Texas Instruments, 2004] Texas Instruments (2004). Msp430xxx family user s guide. 06

108 Appendiks A A. Uddrag af FIDE s skakregler Et parti skak er et spil mellem to modstandere, som skiftevis flytter brikker på et kvadratisk bræt, kaldet et skakbræt. Spilleren med de hvide brikker starter partiet. Målet for begge spillere er at sætte modstanderens konge under angreb på en sådan måde, at modstanderen ikke kan foretage et lovligt træk, der forhindrer, at kongen slås ved det efterfølgende træk. Den spiller, der opnår dette, siges at have sat sin modstander skakmat og derved vundet partiet. Hvis stillingen er, at ingen af spillerne på nogen mulig måde kan sætte skakmat, er partiet remis, hvilket vil sige uafgjort. Ingen brik kan flyttes til et felt, der er besat af en brik af samme farve. Hvis en brik flyttes til et felt, der er besat af en af modstanderens brikker, bliver modstanderes brik slået og fjernes fra skakbrættet, som en del af det samme træk. En brik siges at angribe et felt, hvis brikken kan flyttes til dette felt ifølge reglerne for den pågældende brik. Dronningen flytter til ethvert felt på den række, linie eller diagonal, som den står på. Tårnet flytter til ethvert felt på den række eller linie, som den står på. Løberen flytter til ethvert felt på de diagonaler, som den står på. Når dronningen, tårnet eller løberen flyttes, kan brikken ikke flyttes over nogen brik, som står i vejen. Springeren flytter til et af de felter, som er nærmest det, den står på, men ikke på den samme linie, række eller diagonal. Den passerer ikke direkte over noget mellemliggende felt. Bonden flytter fremad til et ubesat felt umiddelbart foran den på den samme linie. I dens første træk må bonden flyttes to felter frem ad sin linie, forudsat at begge felter er ubesatte, Bonden kan slå andre brikker ved at flytte til et felt besat af en af modstanderens brikker, som er diagonalt foran den på en tilstødende linie. En bonde, der angriber et felt, som er passeret af en af modstanderens bønder, idet denne i ét træk er flyttet to felter frem fra sit udgangsfelt, kan slå denne modstanderens bonde, som om den kun var flyttet ét felt frem. Dette slag må kun ske i trækket umiddelbart efter at muligheden er opstået; slaget kaldes for en passant. Når en bonde når rækken fjernest fra sit udgangsfelt, skal den som en del af trækket udskiftes med en dronning, tårn, løber eller springer af samme farve. Spillerens valg er ikke begrænset til brikker, som er blevet slået tidligere. Kongen kan flytte på to forskellige måder: Til ethvert tilstødende felt, som ikke er angrebet af en eller flere af modstanderens brikker, eller Rokade. Sidstenævnte er et træk med kongen og et af tårnene af samme farve på den samme række, der tæller som et enkelt træk med kongen og udføres som følger: Kongen flyttes fra sit udgangsfelt to felter hen imod tårnet; derefter flyttes dette tårn over kongen til det felt som kongen lige har passeret. Rokaden er ulovlig, hvis kongen allerede har været flyttet, eller med et tårn, som allerede har været flyttet. 07

109 APPENDIKS A. Rokaden er midlertidigt forhindret, hvis feltet, som kongen står på, eller som den skal krydse, eller som den skal flyttes til, er angrebet af en eller flere af modstanderens brikker, eller hvis der er nogen brik mellem kongen og det tårn, som der skal rokere med. Kongen siges at være i skak hvis den er under angreb af en eller flere af modstanderens brikker, også selvom disse brikker ikke selv kan flyttes. En spiller må ikke udføre et træk, der sætter, eller efterlader, hans konge i skak. Partiet er remis, når spilleren i trækket ikke har noget lovligt træk, og hans konge ikke står i skak. Partiet siges at ende med pat. Dette afslutter straks partiet. Partiet kan blive remis, hvis den samme stilling er ved at opstå, eller er opstået, på brættet tre gange. Partiet kan blive remis, hvis de sidste 50 træk af hver spiller er udført uden at nogen bonde er flyttet, og uden at nogen brik er slået. A.2 Kode stil Følgende er regler for formatet af c-koden tilhørende dette projekt: Den maksimale linjelængde er 00 tegn. Indrykning er et enkelt tabulator-tegn, repræsenteret ved 4 tegns indrykning. Der benyttes logisk indrykning og ikke indrykning til en bestemt kolonne, dvs. aldrig mere end én indrykning af gangen. Tuborg-parenteser står altid på en linje for sig selv. Kode skrives generelt på den mest læsbare måde. Alle funktioner og (globale) variable i en given c-fil der ikke skal være tilgængelige fra andre filer, erklæres med nøgleordet static. Kommentarer, variabelnavne, osv. skrives på engelsk. Kommentarer skrives i doxygen format og som hele sætninger, dvs. med stort startbogstav, punktum til sidst mv. En c-kodefil med endelsen.c. 08

110 Appendiks B B. MSP430F49 B.. Indledning I dette kapitel, refererer MSP430 til MSP430F49, og det følgende er baseret på [Texas Instruments, 2004]. MSP430 vil i dette afsnit blive beskrevet generelt, idet de specifikke elementer er bliver gennemgået i moduldesign af drivere, kapitel 0. B..2 Generel beskrivelse MSP430 er en mikroprocessor, bestående af en række dele, sammensat i en Von Neumannstruktur, med de to busser MAB og MDB 2, se figur B.. Ifølge Von Neumann, består opdelingen af fire forskellige dele: En kontrol-enhed, en aritmetisk logisk enhed, hukommelse og input/output til den aritmetisk logiske enhed, jf. afsnit B..3. MSP430 er opbygget efter denne ide, dog med flere perifere enheder. I MSP en er kontrolenheden og ALU en samlet i CPU en, og forbindelserne til Memory er samlet i en databus, se figur B.2. Figur B.: Von Neumann-arkitekturen i sin oprindelige udformning fra 945. I moderne maskiner er kontrolenheden og ALU en samlet i en CPU. Input/output var dengang brugerens interaktion med enheden. [Tanenbaum, 2006] Ud over at der findes de almindelige komponenter fra Von Neumann-arkitekturen, findes der flere perifere enheder i MSP430. MSP, Mixed Signal Processor, hvilket betyder, at den er i stand til at sende og modtage signaler af forskellig art. Dette kommer f.eks. til udtryk i muligheden Memory adress bus 2 Memory data bus 09

111 APPENDIKS B. for både at benytte analogt, såvel som digitalt input/output. En af de store fordele ved netop denne MSP-model, er, at den har flash-rom, så den kan programmeres flere gange, og ikke mister programmet, når strømmen slukkes. Da den kan flashes er det enkelt at lægge et program ind på MSP en, og da det ikke tager lang tid, er det desuden nemt at afprøve ændringer i kode, f.eks. ved debugging. MSP430 indeholder følgende komponenter: Figur B.2: Overordnet struktur. [Texas Instruments, 2004] 6-bit RISC CPU med 27 kerneinstruktioner. 64 kb hukommelse. 2-bit ADC med en samplingsfrekvens op til 200 khz. 2x USART til ekstern kommunikation. 6 I/O porte med hver 8 pins som kan konfigureres individuelt. Mulighed for ekstern interrupt på port og 2. Disse kan ses på figur B.2. MSP430 er således bygget på et simpelt princip, men er meget anvendelig i mange henseender, pga. den store alsidighed i de perifere enheder. B..3 Funktionalitet CPU CPU en i MSP430 består af tre hoveddele: En kontrol-enhed. En aritmetisk logisk enhed, ALU. Interne CPU registre. Disse er skitseret på B.3, og ud fra denne opdeling, kan det ses, at CPU en er baseret på Von Neumann-strukturen. CPU en indeholder derfor omtrent de samme komponenter som i en CPU i en standard PC. Databussen i MSP en er givet ved forbindelsen imellem de perifere enheder. 0

112 APPENDIKS B. Figur B.3: CPU-struktur. [Tanenbaum, 2006] Kontrol-enheden Kontrol-enheden, er den del, der bestemmer hvad der skal ske inden i CPU en. Enheden indeholder otte forskellige trin, som bliver kørt i ring konstant. De otte trin er følgende:. Den næste instruktion, ind i et instruktionsregister. 2. Derefter ændres PC en 3 til den instruktion der netop er hentet ind. PC en kan derfor opfattes som en pointer, der bestemmer hvilken instruktion i programmet, der skal udføres. 3. Derefter vil den instruktion, PC en lige er skiftet til, blive bestemt. 4. Hvis instruktionen omfatter data i memory, skal dets adresse fastslås. 5. Efter adressen på data ene er blevet bestemt, skal disse data hentes ind i de interne CPU-registre. 6. Den instruktion, der nu peges på af PC en, udføres. 7. Efter instruktionen er blevet udført, skal det bearbejdede data gemmes. 8. Afslutningsvis går den tilbage til trin, og hele proceduren gentages. Disse otte trin køres igen og igen, og det er på denne måde CPU en bearbejder instruktionerne. Kontrol-enheden indeholder instruktionerne for, hvad der skal ske, men er ikke i stand til at udføre dem selv. Selve udførslen af instruktionerne ligger i ALU en, hvor dataene hentes, regnes på og placeres i registre. Aritmetisk logisk enhed (ALU) er den enhed, der laver beregningerne i CPU en. Den kan tage input fra flere registre, bearbejde disse, og derefter fylde outputtet over i et nyt register. Eksempelvis kunne den tage input A og B fra to forskellige registre, og derefter fylde et nyt register med summen af dette input. ALU en bestemmer ikke hvilken instruktion, der skal ske, eller hvilke registre den henter input fra. Den fungerer derfor som en form for slaveenhed for kontrol-enheden, der udfører en række instruktioner.

113 APPENDIKS B. Figur B.4: Aritmetisk logisk enhed. [Tanenbaum, 2006] Interne CPU registre Der findes 6 forskellige registre i CPU en, jf. figur B.5. Dog kan der kun lagres data i 2 af disse, idet de resterende fire benyttes til prædefinerede funktioner.. Det første register benyttes til PC en. Det er ved hjælp af denne, kontrol-enheden er i stand til at finde ud af hvilken instruktion, der skal udføres. 2. Det andet register indeholder en stack-pointer. Stack-pointeren, benyttes til håndtering af hukommelsen under programmets udførsel. 3. Det tredje register er et status register. Status registret bruges blandt andet til at give en hardware status for CPU en. F.eks. indeholder registret oplysninger op, hvorvidt den sidste operationen, der er foretaget, har givet resultatet 0, og hvorvidt CPU en er tændt eller slukket. 4. Det sidste af de fire prædefinerede registre, er en konstant-generator. Konstant-generatoren er en optimering, og registret indeholder flere af de konstanter, der ofte bruges. Det faktum, at den indeholder mange prædefinerede konstanter gør, at instruktioner kan gøres kortere. B..4 Hukommelsen De 64kB hukommelse er inddelt i dele. 60 kb flashrom. 2 kb ram. 2 kb til de perifere moduler. På figur B.6 ses et skematisk overblik over hukommelsen. De forskellige inddelinger vil herefter blive forklaret. Interne CPU registre De 6 første adresser er sat til de interne CPU registre. Disse er tidligere beskrevet i afsnit B Program Counter 2

114 APPENDIKS B. Figur B.5: Interne CPU-registre. [Texas Instruments, 2004] Perifere moduler Hvis der ønskes implementering af ekstra perifere moduler, er der 2kB plads til disse. Adresserne fra 0x00 til 0xFF er reserveret til 6-bit perifere moduler. For at tilgå disse, anvendes wordinstruktioner. Disse anvendes af bl.a. ADC2. Adresserne fra 0x0 til 0xFF er reserveret til 8-bit perifere moduler. Disse kan tilgås ved hjælp af byte-instruktioner. Disse anvendes af bl.a. porte. RAM RAM, Random Access Memory, er lokaliseret fra adresse 0x200. Hvor RAM-adresserne slutter, afhænger af hvor meget ram, der er tilgængeligt. På MSP430 er der 2kB ram. Dog kan man afsætte en del af flash ROM, til ekstra RAM-lager, hvis dette findes nødvendigt. Flash ROM Hvor adresserne på flash ROM starter afhænger af, hvor meget flash ROM, der er tilgængeligt. Den sidste adresse til flash ROM er 0xFFFF, hvor de sidste 6 adresser er reserveret til interruptvektorer. Interrupt vektorerne er sorteret således, den interrupt med den højeste prioritet ligger på den højeste adresse, 0xFFFE. 3