Aansturing van een schaakrobot op basis van...

Faculteit Toegepaste Wetenschappen

Vakgroep Elektronica en Informatiesystemen

Voorzitter: Prof. dr. ir. J. VAN CAMPENHOUT

Aansturing van een schaakrobot

op basis van bewegingsdetectie

door

Bruno ANNICQ

Promotor: Prof. dr. ir. K. DE BOSSCHERE

Scriptiebegeleiders: Lic. A. GEORGES, Dr. ir. M. RONSSE

Scriptie ingediend tot het behalen van de academische graad van

burgerlijk ingenieur in de computerwetenschappen

Academiejaar 2002–2003

Woord vooraf

Graag zou ik iedereen willen bedanken die heeft bijgedragen tot de verwezenlijking van

deze scriptie. Speciale dank gaat uit naar mijn promotor, Prof. dr. ir.K. De Bosschere.

Ook mijn thesisbegeleiders, lic. A. Georges en dr. ir. M. Ronsse, wil ik vermelden

voor hun uistekende begeleiding, hun interesse en de vlotte hulp bij de vele praktische

problemen.

Daarnaast wil ik mijn familie bedanken voor hun begrip en onvoorwaardelijke steun.

Bruno Annicq, 1 juni 2003

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen

van de scriptie te kopieren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met

betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van

resultaten uit deze scriptie.”

Bruno Annicq, 1 juni 2003

Aansturing van schaakrobotop basis van bewegingsdetectie

door

Bruno ANNICQ

Scriptie ingediend tot het behalen van de academische graad vanburgerlijk ingenieur in de computerwetenschappen

Academiejaar 2002–2003

Promotor: Prof. dr. ir. K. DE BOSSCHEREScriptiebegeleiders: Lic. A. GEORGES, Dr. ir. M. RONSSE

Faculteit Toegepaste WetenschappenUniversiteit Gent

Vakgroep Elektronica en InformatiesystemenVoorzitter: Prof. dr. ir. J. VAN CAMPENHOUT

Samenvatting

Het doel van deze scriptie bestaat erin een schaakrobot te maken die een menselijke spelertoelaat tegen een computer te spelen gebruik makend van een gewoon schaakbord.

Een camera filmt het schaakbord en zendt die beelden naar een computer. De computeranalyseert die beeldenstroom en detecteert hierin de zetten van de speler. Die zettenworden ingevoerd in een bestaand schaakprogramma dat de tegenzet berekent. Eenmaaldie tegenzet gekend is, wordt een robotarm aangestuurd die op het schaakbord de correctestukken gaat verplaatsen.

Het is bedoeling dat de speler zo weinig mogelijk merkt dat hij tegen een computer speelten dat zijn interactie met de computer zo beperkt mogelijk blijft.

Trefwoorden

java, chess, motion detection, robot.

INHOUDSOPGAVE i

Inhoudsopgave

1 Probleemstelling 1

1.1 Opdracht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Robotarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2 Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.3 Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.4 Schaakbord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Componenten 7

2.1 Robotarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Situatieschets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Aansturen van de robotarm . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 Resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Elektromagneet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Grijper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 Magneet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Schaakbord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.1 Grootte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2 Schaakstukken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4.1 Vaste tegenover Bewegende Camera . . . . . . . . . . . . . . . . . . 20

2.4.2 Herkenning van de individuele schaakstukken . . . . . . . . . . . . 23

2.5 Programma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

INHOUDSOPGAVE ii

2.5.1 Schaakprogramma . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5.2 Inpassen van GNU Chess . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5.3 Schaakbordtoestand . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5.4 Gebruikersinterface . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Algoritmen voor beeldverwerking 30

3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.1 Beeldverwerking in Java . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Schaakborddetectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.1 Eerste methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.2 Tweede methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3 Bewegingsdetectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4 Patroonherkenning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.5 Schaakspecifieke zetten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.5.1 Promotie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.5.2 En passant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.5.3 Rokade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 Programmastructuur 51

4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 ProcessController . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.1 GNUChessProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.2 GNUChessInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2.3 GNUChessOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2.4 GNUChessError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2.5 StreamUpdater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3 RobotController . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.4 CyclopsStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.5 ChessRobot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.6 Schaakbord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.7 ChessColumn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

INHOUDSOPGAVE iii

4.8 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.9 Aanpassingen aan bestaande klassen . . . . . . . . . . . . . . . . . . . . . 56

4.9.1 Robot.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.9.2 PidLoop.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Prestatiemeting 58

6 Besluit 60

6.1 Realisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.2 Toekomst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

A UML 63

B CDROM 65

Bibliografie 66

Lijst van Figuren 69

PROBLEEMSTELLING 1

Hoofdstuk 1

Probleemstelling

Deze scriptie vormt een zijsprong van het onderzoek aan de vakgroep ELIS. Het is de be-

doeling om een aantal componenten die het gevolg zijn van vroegere eindwerken samen te

brengen en die om te vormen tot een werkende schaakrobot. Concreet moet een robotarm

aangestuurd worden op basis van beelden die een camera van een schaakbord filmt.

Dit jaar lopen er twee parallelle scripties die de robotarm aansturen op basis van

beelden die door de camera genomen worden. In tegenstelling tot de andere thesis (zie [6]),

is het hier niet de bedoeling om de camera te verplaatsen met de robotarm, maar om de

robotarm te laten bewegen op basis van wat de camera ziet, namelijk de zetten die een

menselijke speler op een schaakbord uitvoert. Een computer past een aantal algoritmen

toe op die beelden om de zetten eruit te distilleren, en berekent dan met behulp van

een bestaand schaakprogramma de tegenzetten. Op basis van die tegenzetten stuurt de

computer een robotarm aan die de gevraagde stukken op het schaakbord verzet.

Als eindresultaat zal dit tot een schaakrobot leiden die kan werken met een normaal

schaakbord en met normale schaakstukken. De menselijke speler moet er enkel voor zorgen

dat het schaakbord zich in het gezichtsveld van de camera bevindt en dat het binnen het

bereik van de arm staat. De speler voelt dan minder dat hij tegen een computer speelt,

dan dat bij klassieke elektronische schaakborden het geval is.

1.1 Opdracht 2

1.1 Opdracht

Deze thesis bouwt voort op een aantal scripties van voorgaande jaren. Er zijn 4 compo-

nenten die tot een samenwerkend geheel omgevormd moeten worden:

1. Robotarm

2. Camera

3. Computer

4. Schaakbord

1.1.1 Robotarm

De vakgroep Elis is al geruime tijd in het bezit van een zogenaamde Scorbot ER III van

1985 (Figuur 1.1). Deze robotarm met vijf vrijheidsgraden wordt aangestuurd met be-

hulp van een USB interface [5]. De code om de robot aan te sturen was oorspronkelijk in

Modula-2 geschreven maar werd omgezet naar Java [7, 8, 9]. De aansturing van de robot

biedt heel wat functionaliteiten en voor de meeste bewegingen zijn er specifieke routines

voorzien. Zo kan niet alleen elk gewricht afzonderlijk aangestuurd worden, maar kan men

hierbij ook specifieren dat het laatste scharnier (pols of grijper) in een horizontale of verti-

cale positie moet blijven. Bovendien kunnen die routines niet alleen gewrichtscoordinaten

gebruiken, maar ook Cartesiaanse ruimtecoordinaten en cilindercoordinaten [2]. De aans-

turingscode zorgt voor de interne aansturing van de verschillende gewrichten van de ro-

botarm zodat die, wat deze scriptie betreft, niet meer is dan een zwarte doos die als invoer

Cartesiaanse coordinaten neemt en als resultaat de beweging van de robotarm verzorgt.

Op het laatste scharnier van de robotarm was vroeger een grijper bevestigd die open en

dicht kon om voorwerpen (bijvoorbeeld een cola-blikje) vast te nemen. Die grijper bleek

bij het begin van dit academiejaar niet meer te werken en er moest dus gezocht worden

naar een nieuwe manier om met de robotarm voorwerpen (of in dit geval schaakstukken)

te verplaatsen.

1.1 Opdracht 3

Figuur 1.1: Scorbot Jeroom (1985)

1.1.2 Camera

De camera is een Sony DFW-VL500 (Figuur 1.2). De camera is met behulp van Firewire

verbonden met een PC. Dit betekent dat de kwaliteit van de beeldenstroom heel goed is

omdat Firewire een veel grotere bandbreedte aanbiedt (tot 400Mbps) dan bijvoorbeeld de

USB connectie die de meeste webcams gebruiken (USB 1.1 gaat maar tot 1.1Mbps).

Er bestaat al aansturingscode voor de camera die in Java geschreven is en die de

beeldenstroom aanbiedt aan alle geınteresseerde PC’s op het netwerk. De zoom en focus

van de camera zijn volledig regelbaar via het programma. Voor deze thesis is het voor-

gaande grotendeels overbodig. Eenmaal de camera in een goede positie staat en die het

schaakbord kan filmen, is er geen nood meer aan een verandering van de cameratoestand.

Een tweede Java programma laat toe een verbinding te maken met de PC die de beelden

van de camera ontvangt en biedt de beelden in een formaat aan dat klaar is voor verdere

verwerking.

1.1 Opdracht 4

Figuur 1.2: Close-up van de camera

1.1.3 Computer

De robot en de camera zijn met dezelfde PC verbonden en aangezien het de beelden van

de camera zijn die bepalen wat de robotarm juist doet, gebeurt de verwerking van de

beelden en de aansturing van de robotarm op dezelfde PC. De PC in kwestie (knuth)

bevat een Pentium 2 processor met een kloksnelheid van 350 MHz en een geheugen van

256 MB.

Naast de aansturing van de camera en de robot moet de computer ook zorgen voor de

berekening van de tegenzet. Er zijn talloze goede schaakprogramma’s op internet te vinden

dus is het zeker niet de bedoeling dat er een nieuw schaakprogramma geschreven wordt.

De uiteindelijke schaakrobot zal de gevonden zet na bewegingsdetectie moeten invoeren

in een bestaand schaakprogramma, de uitvoer gebruiken als tegenzet en de robotarm die

zet laten uitvoeren.

1.1.4 Schaakbord

De keuze van het schaakbord is volledig willekeurig. Hoe minder limieten waaraan het

schaakbord uiteindelijk moet voldoen, hoe beter. De stukken van het schaakbord zijn

1.2 Vereisten 5

vrij te kiezen, maar er werd mij gesuggereerd om in eerste instantie gebruik te maken van

platte schaakstukken en voor de individuele identificatie eventueel met een soort teken op

de bovenkant te werken.

Heel belangrijk is wel dat de robotarm er op een bepaalde manier in slaagt om de

stukken op het schaakbord te verplaatsen. Dit betekent dat de robotarm de schaak-

stukken ofwel moet kunnen grijpen, ofwel op een andere manier moet kunnen vastnemen

(bijvoorbeeld met een elektromagneet). Dit geldt voor alle stukken op het schaakbord

want de robot moet zowel wit als zwart kunnen spelen en zal bij het slaan1 van een stuk

van zijn tegenstander dat stuk van het bord moeten verwijderen voor hij zijn eigen zet

kan doen.

1.2 Vereisten

De uiteindelijke robot moet aan een aantal eisen voldoen. Het eindresultaat is een

schaakrobot waarbij een menselijke speler een normaal2 schaakspel opstelt in het gezichtsveld

van de camera. Het spel wordt met normale schaakstukken gespeeld, terwijl de computer

met behulp van de robotarm de rol van de tegenspeler vervult.

Dit resultaat zal niet in een keer gehaald worden, maar in een aantal stappen. Concreet

wordt in deze scriptie naar het volgende doel gestreefd:

• De robotarm moet op basis van een computer gegenereerde schaakzet aangestuurd

kunnen worden.

• De menselijke speler moet zo weinig mogelijk merken dat hij tegen een computer

speelt, en dus moeten de voorwaarden waaraan het schaakspel moet voldoen zo

minimaal mogelijk gehouden worden. Er mag wel met eenvoudigere stukken gewerkt

worden.

1Slaan is de officiele term (bij schaken of dammen) voor het verwijderen van een stuk van het bord

door een bepaalde zet.2Geen elektronisch schaakbord dat bijvoorbeeld met bepaalde sensoren is uitgerust.

1.2 Vereisten 6

• Als programmeertaal wordt liefst met Java gewerkt want de te gebruiken compo-

nenten zijn meestal reeds via Java aanstuurbaar.

• De tegenzet van de computer moet in een aanvaardbare tijdspanne gebeuren, zodat

de speler het gevoel heeft dat er echt een spel gespeeld wordt.

De factor die voor de meeste problemen zal zorgen is het feit een van de schaakspelers

een mens is. De computer doet precies wat we hem vragen, elke keer opnieuw, zonder

aarzelen, zonder onverwachte dingen, zonder fouten, maar de mens is onvoorspelbaar. De

ene keer denkt hij 10 minuten na voor een zet, de andere keer een half uur. De ene keer

verplaatst hij zijn pion een beetje teveel naar links, de andere keer teveel naar rechts. De

ene keer is hij direct tevreden met zijn zet, de andere keer verzet hij drie stukken voor hij

zich bedenkt en uiteindelijk toch terug gaat naar zijn eerste idee. De uitdaging bestaat

erin om de afwijkingen die inherent zijn aan de onvoorspelbaarheid van de menselijke

tegenstander zoveel mogelijk te neutraliseren door een robuust systeem te creeren dat

daarvan zo weinig mogelijk hinder ondervindt.

COMPONENTEN 7

Hoofdstuk 2

Componenten

Dit hoofdstuk behandelt stuk voor stuk de verschillende componenten die deel uitmaken

van het eindresultaat van dit eindwerk. De keuzes die onderweg gemaakt zijn en de

overwonnen hindernissen worden hier uit de doeken gedaan en gemotiveerd.

De schaakrobot bestaat uit 4 componenten die opgedeeld kunnen worden in 5 verschil-

lende onderdelen:

1. Robotarm

2. Elektromagneet

3. Schaakbord

4. Camera

5. Programma

2.1 Robotarm

De robotarm is de link tussen het programma en de buitenwereld. De menselijke speler

ziet de robot als zijn tegenspeler en het is de robot die de computercode omzet in de

fysieke schaakzet.

2.1 Robotarm 8

2.1.1 Situatieschets

De robot is een zogenaamde Scorbot ER III uit 1985 (zie paragraaf 1.1.1), en er zijn al

heel wat eindwerken geweest (zie [5, 8, 9, 2, 7]) die zich bezighielden met het aansturen

van die robot. Voor deze scriptie was vooral het resultaat van [9] belangrijk omdat die

de aansturing vanuit een Java omgeving mogelijk gemaakt heeft. Het hoofddoel was daar

wel het waretijdsaspect. Daardoor is de achterliggende code complex en redelijk ontoe-

gankelijk omdat er op heel veel plaatsen opofferingen gedaan zijn om het waretijdsaspect

te waarborgen. Zo wordt een opdracht naar de robotarm doorgestuurd met behulp van

een aantal buffers. De betekenis van die opdracht wordt voor de menselijke gebruiker des

te moeilijker te ontcijferen naarmate men zich dieper in die bufferstructuur bevindt. De

leesbaarheid en onderhoudbaarheid van de code was duidelijk niet de prioriteit. Hiernaast

zijn er een aantal problemen met de uiteindelijke werking van de robot. Die problemen

moeten zeker aangekaart worden, gezien hun invloed op het verloop van dit eindwerk.

Een van de eerste problemen waarmee ik in contact kwam, was de manier waarop het

aansturingsprogramma een overflow behandelt. Als men een draaiing meegeeft aan het

laatste gewricht (de pols), moet men die rotatie in radialen opgeven, niet in graden. Als

er toch graden gebruikt worden, ontdekt de robot wel dat er overflow is opgetreden, maar

voert hij een (andere) beweging uit waarbij de snelheidsbeperkingen uitgezet worden en

de beweging zo snel en agressief gebeurt dat die dikwijls voor de robot zelf destructief

eindigt. Zo is bij het testen van de aansturing een sensor afgebroken die de robot nodig

heeft om zijn startpositie te vinden.

Figuur 2.1 geeft de uitvoer naar de console weer die gegenereerd werd tijdens het

uitvoeren van enkele bewegingen van de robotarm. We zien dat ook bij het opgeven van

een negatieve draaiingshoek (Lijn 5) een overflow optreedt. De eerste beweging die uit-

gevoerd wordt (Lijn 2), gebeurt correct, Maar bij de tweede beweging (Lijn 5) is duidelijk

te zien dat de snelheid met een factor zestig opgedreven is (Lijn 6), en dat de overflow

inderdaad gedetecteerd wordt (Lijn 8). De uitvoering van dit korte programma moest

kort na het optreden van de overflow onderbroken worden om te voorkomen dat de robot

zichzelf beschadigde.

2.1 Robotarm 9

1 Running demo2 MoveRobot To XYZ: 200.0 0.0 80.0 RotateGripper Angle: 3.14159273 speed 2014 speed 2015 MoveRobot To XYZ: 380.0 0.0 80.0 RotateGripper Angle: -0.06 speed 124907 speed 98298 OVERFLOW joint nr59 speed 4635

10 speed 348511 OVERFLOW joint nr5

Figuur 2.1: Behandeling van overflow door de robot

Daarnaast verloopt de communicatie tussen robot en computer nog niet optimaal. De

eerste keer dat de robot aangezet wordt en een beweging moet uitvoeren is er meestal

geen probleem. Maar de tweede keer mislukt het dikwijls en het loont de moeite om

tussen elke start de robot volledig uit te schakelen en de USB connectie tussen robot en

computer opnieuw te initialiseren.

Deze problemen zijn niet onoverkomelijk maar bleken toch hinderlijk voor de vooruit-

gang van deze scriptie omdat ze niet gedocumenteerd zijn en telkens naar een oplossing

gezocht moest worden.

2.1.2 Aansturen van de robotarm

Eenmaal ik de aansturing onder de knie had, en de robotbewegingen voorspelbaar en

betrouwbaar waren, kon ik beginnen met de robotarm te gebruiken om stukken van een

schaakbord te verplaatsen. Hierbij kwamen een aantal andere problemen aan het licht.

De robotarm is eigenlijk redelijk groot in vergelijking met het schaakbord, en er is toch

een zekere precisie vereist om de kleine schaakstukken te verplaatsen. Het bleek echter

vlug dat de robot helemaal niet zo precies was als men zou verwachten. De robot heeft

nogal wat last van geheugeneffecten. Dit betekent dat de nieuwe stand afhangt van de

positie van waaruit de beweging vertrok. Dit is vooral het gevolg van een gebrekkige

mechanische precisie. De gebruikte tandwielen en aandrijfriemen laten een kleine speling

2.1 Robotarm 10

Figuur 2.2: Horizontale en Verticale positie van het grijperscharnier

toe die in vergelijking met de grootte van de robotarm het vermelden niet waard zijn,

maar die wel naar boven komen bij het verplaatsen van de kleine schaakstukken. Zolang

de bewegingen groot zijn, is dit bijna niet waarneembaar, maar voor beweging tussen

enkele vakjes van het schaakbord zijn die verschillen vlug merkbaar. In paragraaf 2.4

bespreken we het effect hiervan op de camerapositie.

Ik heb het geheugeneffect in sterke mate kunnen minimaliseren door de robotarm voor

elke beweging naar een bepaald referentiepunt te brengen en alle bewegingen vanuit dit

referentiepunt te laten gebeuren. Het geheugeneffect is daardoor niet verminderd, maar

het effect zal altijd hetzelfde zijn omdat de bewegingen telkens vanuit hetzelfde punt

vertrekken. De plaats van dit referentiepunt is zo gekozen dat de robotarm ongeveer

midden boven het schaakbord staat omdat de taak van de robot er in de eerste plaats in

bestaat om de stukken op het schaakbord te verplaatsen.

In paragraaf 1.1.1 werd al vermeld dat de robot aangestuurd kan worden met be-

hulp van Cartesiaanse ruimtecoordinaten. Bovendien zijn er routines voorzien die het

laatste gewricht (de pols of grijper) tijdens de beweging horizontaal of verticaal houden.

Aangezien het schaakbord op de grondplaat van de robot staat, is het ideaal dat de

grijper steeds in verticale positie staat (Fig. 2.2 en voor de aansturing wordt er in deze

scriptie dus enkel gebruik gemaakt van de MoveGripperVertical opdracht. Die aan-

vaardt coordinaten in verschillende vormen. Naast de draaiing per gewricht kunnen ook

cilindrische of sferische coordinaten opgegeven worden. Ik maak enkel gebruik van Carte-

2.1 Robotarm 11

Figuur 2.3: Cartesiaanse aansturing robot. Beweging ligt niet in een vlak.

siaanse ruimtecoordinaten omdat die de eenvoudigste beschrijving van een vierkant (het

schaakbord) toelaten. De manier waarop de robot naar deze coordinaten beweegt wordt

volledig bepaald door de aansturingscode en speelt voor deze scriptie geen rol.

Na het testen van de robot kwamen echter een paar nieuwe problemen naar boven.

Blijkbaar doet de robot niet helemaal wat er van hem verwacht wordt. Zo zal hij, indien

dezelfde hoogtecoordinaat meegegeven wordt, toch op een andere hoogte uitkomen naarge-

lang het punt dichter of verder van zijn basis ligt. Het einde van de robotarm beweegt

zich dus niet in een vlak zoals het zou moeten. Ik heb dit probleem opgelost door bij het

doorgeven van mijn coordinaten eerst een correctie uit te voeren op de hoogtecoordinaat.

Uit de gemeten deviatie (Fig. 2.3) blijkt dat we de robotarm aan de verste rand van het

schaakbord 18 eenheden lager moeten sturen dan aan de rand dichtst bij de basis. Het

schaakbord neemt ongeveer 180 verticale eenheden1 in beslag en als we per lengteeenheid

dat we van de rand dichtst bij de basis van de robot verwijderd zijn, de hoogte van de

robotaansturing corrigeren met 0.1 eenheden keer de afstand van de rand, zal de robot

op de gewenste plaats uitkomen. Deze correctie wordt uitgevoerd op de hoogtecoorinaat

net voor de aansturingsopdracht van de robot opgeroepen wordt;

De robot is gemonteerd op een basisplaat die een patroon bevat waarvan men zou

1De verticale eenheid die door de robot gebruikt wordt, komt ongeveer overeen met 1 cm in werkelijk-

heid.

2.1 Robotarm 12

Figuur 2.4: Robotcoordinaten van de hoekpunten van het schaakbord.

denken dat het overeenkomt met de assen van robotbeweging. Maar hier werd proef-

ondervindelijk gevonden dat de beweging weer niet overeenkomt met de verwachtingen.

Zoals op figuur 2.4 te zien is, vormen de coordinaten van de hoekpunten van het schaak-

bord geen vierkant maar een trapezium. Ook hier moet die afwijking gecompenseerd

worden voor de coordinaten aan de robot doorgestuurd worden.

Als laatste opmerking tonen we in figuur 2.5 dat de reikwijdte van de robotarm beperkt

is en dus de grootte van het schaakbord limiteert.

2.1.3 Resultaat

De aansturing van de robotarm gebeurt in volgende stappen:

1. Initialisatie

2. Startpositie

2.1 Robotarm 13

Figuur 2.5: Bereik van de robotarm.

3. Referentiepositie

4. Camerapositie


6. Verzetten van stukken


8. Camerapositie

9. ...

De robotarm moet eerst steeds naar zijn startpositie (home-position) gebracht worden

omdat na het opstarten van de robot de computer de stand van de robot niet kent. Nadat

de robot in zijn home-positie staat, wordt de robot naar zijn referentiepositie gestuurd

om de geheugeneffecten te minimaliseren (zie paragraaf 2.1.2). Daarna beweegt de arm

zich zodanig dat de camera loodrecht boven het schaakbord staat en dat de camera het

hele schaakbord in beeld heeft.

Bij het uitvoeren van de tegenzet van de computer beweegt de robotarm zich opnieuw

eerst naar de referentiepositie vanwaaruit hij dan vertrekt om de verschillende stukken te

2.2 Elektromagneet 14

verplaatsen. Na de zet gaat hij via de referentiepositie terug naar de camerapositie om

de volgende zet te filmen.

Voor al deze bewegingen wordt de MoveGripperVertical opdracht met aangepaste

(zie paragraaf 2.1.2) Cartesiaanse ruimtecoordinaten gebruikt.

2.2 Elektromagneet

2.2.1 Grijper

De robotarm had vroeger een grijper op zijn laatste gewricht. Die functioneerde echter

niet meer bij aanvang van deze scriptie. Maar zelfs indien de grijper nog te redden

was, zou ik voor een andere oplossing kiezen. De belangrijkste reden hiervoor is dat de

grijper gemaakt was om blikjes en andere, relatief grote voorwerpen op te pakken. De

schaakbordstukken zouden te klein zijn voor de grote klauwen van de grijper. En zelfs

indien we de grijper met fijnere eindpunten kunnen uitrusten, zijn er nog een aantal niet te

overkomen problemen. Een ervan is dat de beweging van de arm niet precies genoeg is om

te garanderen dat we telkens juist midden boven het gevraagd vakje van het schaakbord

uitkomen. Anderzijds kunnen we ook niet van de menselijke tegenspeler verwachten dat

hij zijn stukje altijd precies in het midden van het vak zal plaatsen zodat we waarschijnlijk

dikwijls naast het stukje zouden grijpen.

Het voordeel van de grijper is natuurlijk dat we met gewone schaakstukjes zouden

kunnen werken, omdat er minder speciale eisen gesteld worden aan de stukjes dan bij

een elektromagneet het geval is. Een magneet vereist een platte metalen bovenkant die

vormherkeninning vanuit bovenaanzicht op het schaakbord heel wat moeilijker maakt. Bij

een magneet kunnen we bovendien niet echt voorspellen waar het stuk juist zal komen te

hangen onderaan de magneet. De grijper daarentegen kan een stuk maar op een manier

vastnemen.


Figuur 2.6: Magneet plus extensie op laatste scharnier.

2.2.2 Magneet

Ik heb gekozen om de stukjes in het kader van deze scriptie met behulp van een elektro-

magneet te verplaatsen. Dit heeft zowel positieve als negatieve kanten. Het grote voordeel

is dat de plaats van zowel het stuk als de magneet zelf niet meer zo belangrijk is. Zelfs

als het stuk niet juist in het midden van het vak staat, of indien de magneet niet midden

boven het vakje terecht komt, zal de elektromagneet nog in staat zijn het stuk correct

te verplaatsen naar zijn bestemming. Wat de schaakstukjes betreft heeft dit helaas wel

een aantal belangrijke beperkingen. Het gebruik van gewone schaakstukjes mogen we

direct vergeten want de stukjes moeten allemaal een platte, metalen bovenkant hebben.

Bovendien moeten ze liefst allemaal even hoog zijn. Indien de identiteit van de stukjes

gekend is (en dit is zo, zie paragraaf 2.5) vormt dit geen probleem. Dan kan de robotarm

bij zijn beweging rekening houden met het soort stuk en de hoogte varieren afhankelijk

van die soort.


Figuur 2.7: Interfacekaarten robot en magneet.

Monteren

De elektromagneet moest wel nog gemonteerd worden op de robotarm en dit hebben we op

de volgende manier gedaan. Op het gewricht van de grijper hebben we een L-vormig stuk

in aluminium geplaatst waaraan we op het einde de spoel hebben bevestigd (Fig. 2.6).

Het gebruik van deze extensie heeft tot gevolg dat het bereik van de robotarm met een

tiental centimeter in elke richting is uitgebreid. De magneet wordt aangestuurd aan de

hand van een ongebruikte LED op de USB-interfacekaart die de robot met de computer

verbindt (LED 1 in figuur 2.7). De stand van de LED bepaalt of er al dan niet stroom

loopt naar de magneet. De magneet heeft zelf ook een kleine interfacekaart (met als extra

controle LED 2) die aan de hand van de stand van LED 1 de correcte hoeveelheid stroom

naar de magneet stuurt. Zetten we LED 1 aan, dan gaat LED 2 uit en loopt er stroom

door de magneet zodat hij een stuk kan opnemen. Staat LED 1 uit, gebeurt net het

omgekeerde. Een van de draden van die spoel hebben we vastgesoldeerd met de kern

van de spoel zodat de elektrische geleider aan de bovenkant van de spoel vastgemaakt kan

worden en op die manier minder in de weg zit (Fig. 2.8). Het andere uiteinde van de spoel

is rechtstreeks verbonden met de draad naar de USB-interface. De huidige Javacode van

de robotarm werd aangepast zodat we de magneet met behulp van de al bestaande grijper

procedures kunnen aansturen. Hiervoor werden opdrachten die de grijper doen opengaan


Figuur 2.8: Close-up van de spoel van de elektromagneet.

omgevormd zodat ze nu de magneet aanzetten. Omgekeerd zal bij het sluiten van de

grijper de opdracht omgevormd worden tot het uitschakelen van de elektromagneet.

Extensie

Door het plaatsen van de magneet op een extensie moet er ook een omzetting gebeuren zo-

dat optimaal gebruik gemaakt wordt van de extra reikwijdte. Ik heb een nieuwe procedure

geschreven die gebruikt wordt om de robot een bepaalde beweging te laten uitvoeren, die

de nieuwe aangepaste cordinaten berekent, rekening houdend met de extensie, en die de

grijper automatisch de juiste rotatie meegeeft. De omrekening gebeurt als volgt (Fig. 2.9).

De hoek θ en de nieuwe X en Y coordinaten kunnen als volgt berekend worden.

θ = arctan−Y

X

X = X − L cos θ

Y = Y − L sin θ

Hierbij stelt L de offset voor die het het verlengstuk introduceert.


Figuur 2.9: In rekening brengen van verlengstuk bij beweging robot.

Aangezien het schaakbord altijd ver genoeg van de basis van de robot staat, heb ik

het enkel nodig geacht om de extensie als verlenging2 te gebruiken (θ altijd groter dan π2).

Opmerking

Vooraleer een beweging doorgestuurd wordt moet de robot zoals vermeld in paragraaf 2.1.3

altijd eerst naar zijn startpositie gaan. Op bepaalde kritieke plaatsen zijn sensoren gemon-

teerd die detecteren wanneer de robot in een bepaalde stand staat. Zo kan de computer

de stand van de robotgewrichten detecteren. Het laatste gewricht (de pols of grijper)

beweegt steeds in een bepaalde richting tot de sensor geactiveerd wordt en de draaiing

gekend is. Dit zorgt voor een probleem aangezien de grijper altijd in dezelfde richting

draait en de draden naar de spoel het gevaar lopen rond de extensie gewikkeld te raken en

tussen de tandwielen van de robotarm terecht te komen. Dit kan in zekere mate beperkt

worden door te zorgen dat de grijper bij het initialiseren nooit een volledige ronde moet

draaien. Dit betekent dat de grijper bij het bewegen naar de startpositie een negatieve

2Dicht bij de basis van de robotarm zou de extensie de arm moeten verkorten door meer dan π2 graden

gedraaid te zijn en dus X ≥ X.

2.3 Schaakbord 19

rotatie3 heeft.

2.3 Schaakbord

Het schaakbord is de centrale component waar rond alles draait. De menselijke speler

voert er zijn zet op uit, de camera filmt het gebeuren en analyseert de beweging, en de

robotarm verplaatst de nodige stukken voor de tegenzet van de computer. Het is via deze

component dat de interactie met de menselijke tegenspeler plaats heeft. Het schaakbord

speelt dus een heel bepalende rol in het uiteindelijke gevoel van de speler.

2.3.1 Grootte

De grootte van het schaakbord wordt bepaald door twee factoren die ik niet in de hand

heb. Ten eerste is er, zoals hierboven vermeld, het beperkte bereik van de robotarm. Zelfs

zonder de extensie waaraan de elektromagneet vastzit zou dit een bord van 24 × 24 cm

moeten toelaten. Het bord dat in mijn experimenten gebruikt wordt is echter maar

20 × 20 cm. Dit komt omdat in dit geval de camera de meest beperkende factor is. De

camera staat relatief dicht bij het bord en moet helemaal uitgezoomd worden om het

volledige schaakbord in beeld te kunnen brengen.

2.3.2 Schaakstukken

Het feit dat gebruik gemaakt wordt van een elektromagneet zorgt ervoor dat de schaak-

stukken aan heel wat eisen moeten voldoen. Zo moet hun bovenkant uit metaal bestaan

en bovendien zo plat mogelijk zijn. Omdat ik nergens stukjes vond die klein genoeg waren,

heb ik er zelf nieuwe gemaakt door een lange dunne ronde staaf in gelijke stukken te zagen.

Ik heb ze geschilderd en op de bovenkant telkens een zo groot mogelijke sluitring geplakt

zodat de magneet ze gemakkelijk kan verplaatsen. Dit betekent wel dat de stukken elke

3negatieve rotatie: −π2 < θ < 0

2.4 Camera 20

Figuur 2.10: Schaakstukken.

vorm van individualiteit verloren hebben en er dus allemaal hetzelfde uitzien (Fig. 2.10).

Bovenaan het stuk staat wel een teken (lettercode) zodat de speler op het schaakbord kan

zien welke stukken waar staan, maar de computer kan daar geen gebruik van maken (zie

paragraaf 2.4.2).

Een probleem dat onmiskenbaar gekoppeld is met schaken is dat de stukken in 50

procent van de gevallen op hun eigen kleur staan (zwart op zwart en wit op wit). Dit

betekent dat er weinig verschil is tussen het stuk en zijn onmiddellijke omgeving. Beweg-

ingsdetectie is dus niet zo vanzelfsprekend omdat het niet duidelijk is of er op die plaats al

dan niet een stuk stond. Hier halen we dan weer voordeel uit de platte metalen bovenkant

want de stukken zijn dan beter te onderscheiden van hun achtergrond, of ze nu zwart zijn

of wit. De opening in het midden van de sluitring is ook geschilderd in de kleur van het

stuk zodat de witte en zwarte stukken ook in het bovenaanzicht van elkaar verschillen.

2.4 Camera

2.4.1 Vaste tegenover Bewegende Camera

Zoals te zien is op figuur 1.2 maak ik gebruik van de Sony Camera die op de onderarm van

de robot bevestigd is. De camera is op een voet gemonteerd die zodanig gekozen is dat de

2.4 Camera 21

Figuur 2.11: Beeld van schaakbord met vervorming van de rand duidelijk zichtbaar.

camera loodrecht boven het schaakbord kan bewogen worden en dus een vervormingsvrij4

beeld van het schaakbord kan nemen.

De voordelen van de vast gemonteerde camera zijn veelvoudig. Ten eerste kan de ca-

mera verder van het schaakbord gemonteerd worden zodat de de grootte van het schaak-

bord bepaald wordt door de robotarm en niet meer door de camera. Bovendien moet

de camera nu maximaal uitgezoomd worden om het hele schaakbord in beeld te krijgen.

Dit zorgt voor de tonvormige vervorming van het beeld, duidelijk te zien aan de randen

van het schaakbord waar de rechten gekromd zijn (Fig. 2.11). Die vervorming treedt niet

meer op als de camera niet volledig uitgezoomd is.

Als tweede voordeel kijkt een vaste camera steeds naar dezelfde plaats, en is het enige

verschil tussen twee opeenvolgende beelden het stuk dat verplaatst is (indien er een zet

opgetreden is). De beperkte mechanische precisie van de robotarm zorgt ervoor dat telkens

de robotarm een beweging uitgevoerd heeft, de camera in een iets andere positie staat. Het

beeld voor en na de beweging zal teveel verschillen om er het bewegingsdetectiealgoritme

op los te laten, en bovendien staat het schaakbord misschien niet meer op dezelfde plaats

4Indien de camera schuin neerkijkt krijgt het schaakbord een trapeziumvorm in het beeld en moeten

er eerst transformaties op het beeld toegepast worden voordat het voor verdere verwerking bruikbaar is.

2.4 Camera 22

in het beeld. Er moet een extra stap ingevoerd worden die in het nieuwe, licht verschoven

beeld opnieuw op zoek gaat naar de juiste positie van het schaakbord. Dan kan het ene

beeld verschoven worden zodat de schaakborden in de twee beelden op dezelfde plaats

komen te liggen. Dit gebeurt door voor elke zet twee unieke patronen van het schaakbord

op te slaan, en in het beeld na de beweging op zoek te gaan naar die patronen (in

spiraalvorm). Voor een precieze uitleg van dit algoritme zie paragraaf 3.4.

Een probleem met deze oplossing is dat dit alleen werkt als het tweede beeld enkel een

translatie is van het eerste beeld. Indien er echter ook een kleine rotatie opgetreden is,

kan dit algoritme een probleem hebben om het schaakbord terug te vinden. De afstand

tussen de camera en de robot zal ook varieren, maar het effect hiervan is bijna niet te

zien in de verschillende beelden. Hiermee wordt geen rekening gehouden. Dit alles speelt

uitsluitend een rol indien we de uitvoering van de computerzet willen controleren. Tijdens

de zet van de speler blijft de robotarm en dus ook de camera steeds in dezelfde positie

staan. Het is alleen bij het uitvoeren van de tegenzet dat de robotarm een beweging moet

uitvoeren vooraleer hij terugkeert naar de camerapositie.

Het feit dat we niet meer kunnen uitzoomen beperkt naast de grootte van het schaak-

bord ook in sterke mate de plaats. Idealiter kan men eerst heel sterk uitzoomen om een

overzichtsbeeld te hebben. Hierin kan men het schaakbord zoeken. Dan zoomt men in

op het gevonden schaakbord. Aangezien het kleinste schaakbord dat ik kon vinden maar

net in het beeld past, moet dit schaakbord altijd op een vaste positie geplaatst worden

zodat het bord zeker helemaal in het beeld kan. Dit zorgt er langs de andere kant wel

voor dat het schaakbord altijd op dezelfde plaats staat, en dat de robotcoordinaten die

de arm naar de de verschillende vakken van het schaakbord bewegen vooraf gekend zijn.

De reden waarom toch voor de bewegende camera op de robotarm gekozen werd, is

dat de andere camera (AXIS webcam) op het ogenblik dat ik de hem nodig had, niet naar

behoren werkte. De Sony camera is bevestigd op de robotarm omdat dit een vereiste was

voor een andere scriptie dit jaar die parallel liep aan deze scriptie (zie [6]).

2.4 Camera 23

Figuur 2.12: Nuttige oppervlakte schaakstuk in beeldpunten.

2.4.2 Herkenning van de individuele schaakstukken

In het begin van deze scriptie was het voorzien om niet alleen de beweging van de schaak-

stukken te detecteren, maar ook de stukken zelf te kunnen herkennen. Dit betekent dat de

computer ook middenin een schaakspel, wanneer de stukken al overal op het bord staan,

kan beginnen meespelen. Bovendien zijn er een aantal zetten zoals bijvoorbeeld promotie

(zie paragraaf 3.5.1), die gemakkelijkst op te lossen zijn indien elk stuk door de computer

kan herkend worden. Dit heb ik evenwel niet geımplementeerd.

De hoofdreden hiervoor is dat het technisch niet echt haalbaar was (Fig. 2.12). De

camera schiet beeldjes aan een resolutie van 320 op 240 beeldpunten. De kleinste afstand

is de verticale, met 240 beeldpunten. Het schaakbord dat helemaal in het beeld moet

passen bevat 8 vakken in elke richting. Tellen we hierbij omwille van de onder- en boven-

rand twee vakken bij, dan komen we verticaal aan 10 vakjes van elk 24 beeldpunten. Als

het schaakstuk ongeveer een half vak breed is, nemen de stukken op het beeld 12 verticale

beeldpunten in. Aangezien de camera recht boven het schaakbord staat, kunnen we enkel

de bovenkant van de schaakstukken gebruiken. De overblijvende nuttig bruikbare opper-

vlakte van een schaakstuk in een beeld komt overeen met amper 10 op 10 beeldpunten

wat gezien de beeldkwaliteit van de camera te weinig is om een betrouwbare herkenning

op toe te passen. De patroonherkenner (zie paragraaf 3.4) zou hiervoor nochtans relatief

2.5 Programma 24

gemakkelijk gebruikt kunnen worden. Bij de start van het schaakspel kunnen we namelijk

een foto maken van de bovenkant van elk stuk en later kunnen we dit vergelijken met de

bovenkant van het stuk dat we willen identificeren. Natuurlijk zullen we de rotatie van

de stukken hier wel in rekening moeten brengen, wat heel wat rekenkracht zal vergen.

Er waren nog een aantal andere ideeen die ik uiteindelijk niet gebruikt heb. De camera

kan theoretisch beelden maken in een resolutie van 640 op 480 beeldpunten. Dit zou

echter te belastend zijn voor de nu al overbelaste PC (zie paragraaf 5). De beste manier

om het meeste uit de beperkte oppervlakte van een stuk in de beelden te halen, is met

kleuren te werken. Er zijn zes verschillende stukken. Het is niet nodig om onderscheid te

maken tussen stukken van dezelfde soort. Door zes zo verschillend mogelijke kleuren te

nemen, zou het misschien wel mogelijk zijn om de stukken van elkaar te onderscheiden.

De bestaande klasse die de beelden van de camera via een buffer aan mijn programma

presenteert, geeft de beeldjes standaard in zwart/wit door. Dit zou aangepast kunnen

worden, maar zou opnieuw de PC zwaarder belasten. Een laatste idee volgt uit het feit

dat de de camera kan bewegen. Misschien kan die niet verder uitzoomen, maar hij zou wel

kunnen inzoomen op de individuele stukjes en zo het aantal beeldpunten per stukje sterk

opdrijven. Dit is praktisch niet haalbaar omdat de robotarm niet flexibel genoeg is om de

camera loodrecht boven elk schaakstuk te brengen. De camera kan wel gedraaid worden,

maar dan worden de stukken onder verschillende hoeken bekeken naar gelang hun plaats.

Dit vermoeilijkt sterk de herkenning van een patroon. Aangezien het uiteindelijk bleek

dat stukherkenning slechts in een aantal heel specifieke gevallen nodig was, heb ik het niet

de moeite waard geacht om een van bovenstaande ideeen te implementeren, maar heb ik

die specifieke problemen op andere manieren opgelost (zie paragraaf 3.5).

2.5 Programma

Als laatste component blijft enkel nog het centrale zenuwcentrum over. Het is vanuit

het programma op knuth (de PC die met de robot en de camera verbonden is) dat alles

aangestuurd wordt. De computer berekent de tegenzet met behulp van een schaakpro-

2.5 Programma 25

gramma, verwerkt de beelden van de camera en stuurt de robotarm aan om de zet uit te

voeren.

2.5.1 Schaakprogramma

Aangezien het niet de bedoeling was dat ik een nieuw schaakprogramma schreef, ben ik op

zoek gegaan op internet. Hier kwam een naam dikwijls naar boven, namelijk GNU Chess.

Dit is de zogenaamde schaakmotor die achter de schermen het grootste werk doet bij veel

gebruikte grafische schaakprogramma’s zoals WinBoard en XBoard. Het is ontwikkeld

door de Free Software Foundation en is volledig geschreven in C. Dit zorgde meteen voor

de eerste moeilijkheid. Hoe communiceren we vanuit Java met dit C programma?

GNU Chess wordt al door vele andere programma’s gebruikt als schaakmotor, dus de

invoer en uitvoer is volledig gestandaardiseerd. Door gebruik te maken van de xboard

optie bij het opstarten van GNU Chess wordt de output naar de console beperkt tot het

essentiele en worden de zetten in algebraısch formaat uitgezet. Dit betekent dat elke

beweging in maximaal 5 karakters wordt weergegeven. Meestal zijn er maar vier nodig:

kolom en rij van de start gevolgd door kolom en rij van de bestemming. Het vijfde karakter

dient in geval van promotie om weer te geven naar welk karakter gepromoveerd wordt.

Elke schaakbeweging moet dus voldoen aan onderstaande reguliere expressie.

[a-h][1-8][a-h][1-8][rnbqeRNBQE]?

Zie figuur 2.13 voor een kort voorbeeld van een GNU Chess sessie. De rode tekstregels

stellen de invoer voor die ik aan GNU Chess gegeven heb.

2.5.2 Inpassen van GNU Chess

De broncode van GNU Chess is vrij beschikbaar op internet, maar aangezien het in de

programmeertaal C geschreven is, heb ik geen gebruik gemaakt van de broncode maar

2.5 Programma 26

/gnuchess xboardChessb2b41. b2b41. ... e7e5My move is: e7e5d2d32. d2d32. ... f8b4My move is: f8b4b1b3Illegal move: b1b3b1c33. b1c33. ... b4c3My move is: b4c3exit

Figuur 2.13: Korte GNU Chess sessie

werk ik met het uitvoerbare programma. GNU Chess wordt als proces binnen het pro-

gramma opgestart, en de interactie verloopt via drie draden. Een voor invoer naar het

proces toe, en twee voor uitvoer van het proces (normale- en erroruitvoer). Zoals in

figuur 2.13 te zien is, zorgt elke invoer van GNU Chess voor een welbepaalde uitvoer. De

invoeren uitvoerdraden gebruiken een object (IONotificationObject) om een correcte

synchronisatie te verzekeren. Zo zal de invoerdraad altijd wachten met verdere verwerking

van eventuele andere invoer tot de uitvoerdraad via dit object signaliseert dat de uitvoer

correct behandeld is (Fig. 2.14).

Het hoofdprogramma bestaat dus uit 4 draden (het gnuchess proces, en de invoeren

twee uitvoerdraden) die naast elkaar lopen, en van waaruit de verschillende algoritmes

aangeroepen worden.

2.5.3 Schaakbordtoestand

Voor de goede werking van het bewegingsdetectiealgoritme is het belangrijk dat de si-

tuatie van het schaakbord niet alleen intern in GNU Chess gekend is. Daarom be-

vat het programma ook een klasse die de situatie van het schaakbord bijhoudt. Alle

2.5 Programma 27

Figuur 2.14: Dradenstructuur

2.5 Programma 28

Figuur 2.15: Grafische gebruikersinterface

(goedgekeurde) zetten worden na verwerking of aanvaarding door GNU Chess ook aan

deze klasse doorgegeven zodat op elk moment de situatie van het spel gekend is. Ook zijn

er een aantal speciale schaakzetten die het noodzakelijk maken de huidige toestand van

het schaakbord te kennen (oa. en passant en rokeren, zie paragraaf 3.5).

Dit maakt het mogelijk dat de gebruiker op het scherm een schematische weergave van

het spel te zien krijgt. Hij kan dus visueel controleren of de computer zijn zetten correct

aan het volgen is.

2.5.4 Gebruikersinterface

Zoals u kunt zien in figuur 2.15 bestaat de gebruikersinterface hoofdzakelijk uit 3 beelden

met de schaakbordsituatie. Links staat het beeld dat we bijhouden om te gebruiken in

het bewegingsdetectiealgoritme. Dit beeld wordt vergeleken met het beeld dat op dat

moment in het midden getoond wordt. Daar tonen we immers het beeld dat de camera

aan het doorsturen is. Hiervoor heb ik een vijfde draad voorzien (naast de GNU Chess

proces draad en de invoeren twee uitvoerdraden). Deze draad (StreamUpdater) roept

2.5 Programma 29

elke halve seconde een procedure op die het meest recente beeld van de camera inlaadt.

Links onderaan wordt een historiek van de zetten afgebeeld, en midden onderaan

toont een statusvenster wat de computer op dat moment aan het uitvoeren is. In de

voorbeeldfiguur heeft hij juist een zet van de speler gedetecteerd, en is GNU Chess nu

bezig de tegenzet te berekenen. Tijdens deze operatie kan de speler de Einde zet toets

niet indrukken, vandaar dat die toets op het moment van de screenshot niet aanklikbaar

was.

ALGORITMEN VOOR BEELDVERWERKING 30

Hoofdstuk 3

Algoritmen voor beeldverwerking

3.1 Inleiding

In dit hoofdstuk bespreek ik de verschillende algoritmes die gebruikt worden om de beelden

die de camera van het schaakbord filmt, te analyseren. Eerst en vooral behandelen we

het schaakborddetectiealgoritme dat op zoek gaat naar de positie van het schaakbord in

een beeld. Vervolgens bespreken we het bewegingsdetectiealgoritme dat zetten detecteert.

Daarnaast beschrijven we het patroonherkenningsalgoritme en de algoritmen die de uit-

zonderlijke schaakzetten verwerken.

3.1.1 Beeldverwerking in Java

De schaakrobot is geprogrammeerd in Java omdat de meeste1 verschillende componen-

ten al gebruik maakten van Java. Zo kan gemakkelijk gecommuniceerd worden met de

componenten en kan de bestaande code gebruikt worden. Javaprogramma’s hebben de

laatste jaren veel aan populariteit gewonnen maar ze staan nog altijd niet synoniem met

snelheid. De schaakrobot moet echter interactie met een gebruiker toelaten dus moeten

1GNU Chess is in C geprogrammeerd

3.1 Inleiding 31

ook de verschillende beeldverwerkingsroutines redelijk snel kunnen gebeuren. Zie hoofd-

stuk 5 voor een vergelijking van de snelheid van de algoritmen in Java op verschillende

systemen.

De eerste versies van Java hadden enkele grafische functies in het AWT pakket, maar

die waren beperkt tot de basisfunctionaliteit zoals bijvoorbeeld foto’s afbeelden op HTML

pagina’s. Met behulp van een beperkt aantal primitieven konden lijnen en andere vormen

getekend worden. Een klein aantal bestandsformaten (onder andere JPEG en GIF) kon

ingelezen en afgebeeld worden.

Dit bleek vlug onvoldoende, en daarom werd de Java 2D API in het leven geroepen.

Dit is een extensie op het voorgaande AWT pakket. Het heeft echter heel wat meer

mogelijkheden, zoals complexere primitieven, herschalingen, enkele effecten en lettertype-

definities.

Java Advanced Imaging (JAI) bouwt voort op Java 2D, maar laat complexe grafische

operaties toe in de gekende Java omgeving. Veel van de functies die men enkel in een

professioneel grafisch programma verwacht, zoals frequentie operaties, vindt men terug in

de JAI omgeving. Belangrijker voor deze thesis is dat vele routines geoptimaliseerd zijn

om gebruik te maken van de laatste hardware-extensies, zoals MMX op Intel systemen.

Het grote nadeel van JAI is dat het niet standaard bij de Java runtime geleverd wordt.

Het pakket is wel gewoon van de Sun site af te halen, maar moet door de gebruiker zelf

geınstalleerd worden.

Ik heb ervoor gekozen om voor de benodigde grafische bewerkingen zoveel mogelijk

JAI te gebruiken. Zo zal het programma mee evolueren met de optimalisaties die in

JAI aangebracht worden en steeds optimaal gebruik kunnen maken van de nieuwste tech-

nologieen (MMX, SSE, 3DNow!, ...). Bij het testen van de snelheid van de verschillende

algoritmen (zie hoofdstuk 5) blijkt dat knuth redelijk traag is in de uitvoer van de JAI

operaties, maar dat een moderner systeem dezelfde algoritmes meer dan tien keer zo snel

uitvoert.

3.2 Schaakborddetectie 32

3.2 Schaakborddetectie

Dit algoritme is het eerste dat aangeroepen wordt na het opstarten van het programma.

Snelheid is hier niet de belangrijkste factor aangezien het maar een keer gebruikt wordt,

namelijk in de opstartfase.

Dit algoritme berekent de linkerboven- en rechteronderhoek van een schaakbord in een

beeld. Het gaat ervan uit dat het schaakbord evenwijdig met de randen van het beeld

staat. Een kleine afwijking mag, maar de detectie zal dan minder nauwkeurig zijn. Ik

heb dit probleem op twee manieren aangepakt.

3.2.1 Eerste methode

Zie figuur 3.1 voor een grafische illustratie van een aantal stappen. Met behulp van de JAI

gradientmagnitude-operatie die gebruik maakt van zogenaamde randversterkende Sobel

operatoren, wordt naar de randen in dit beeld gezocht. Door het grote contrast tussen de

zwarte en witte vakken van een schaakbord geeft dit zeer duidelijke randen als resultaat.

Eerst wordt met behulp van een medianfilter de eenzame ruispieken2 uit het beeld

gefilterd. Dit beeld wordt dan via de threshold-operatie omgezet naar een binair beeld

(Fig. 3.1(b)). Concreet worden alle beeldpunten tot een bepaalde helderheid afgebeeld op

volledig zwart, en alle beeldpunten vanaf die helderheid op volledig wit. In het resulterende

beeld blijven er dan maar twee kleuren over: zwart en wit. In dit binair beeld wordt met

behulp van de Hough transformatie [10] gezocht naar de horizontale en verticale lijnen

die minstens over de helft van het beeld lopen (Fig. 3.1(c)). Zo worden echter niet alleen

de lijnen van het schaakbordpatroon gevonden, maar ook de randen van het schaakbord

en eventuele andere lijnen in het beeld. Omdat we weten dat we op zoek zijn naar een

schaakbordpatroon, zoeken we de verschillende afstanden tussen de gevonden rechten

onderling. Van de gevonden afstanden wordt de meest voorkomende waarde genomen

omdat het schaakbord in het beeld voor de meeste rechten zorgt. Die gekozen afstand

2Eenzame pixels zijn punten in het beeld die heel sterk verschillen van hun achtergrond. Ze zijn

willekeurig verdeeld in het beeld en zijn een gevolg van impulspieken van ruis.


(a) Startbeeld (b) Binair beeld na gradientmagnitude, me-

dianfilter en threshold operaties

(c) Overgebleven rechten na Hough trans-

formatie

(d) Beeld na Houghtransformatie en selectie

van schaakbordvierkanten.

Figuur 3.1: Schaakborddetectie Eerste Methode


1 public boolean findchessboard(int[] pixels) {2 JAI("medianfilter");3 JAI("threshold");4 for (alle pixels) {5 if (pixel == zwart) {6 while (horizontaal pixel zwart)7 while (verticaal pixel zwart)8 Zoek vierkant dat hierin past;9 }

10 }11 for (alle gevonden vierkanten)12 bewaar enkel diegene die zijde > 12 en < 24;13 if (genoeg gevonden vierkanten) {14 if (som alle vierkanten != vierkant)15 verleng korte zijde tot vierkant;16 return true;17 } else18 return false;19 }

Figuur 3.2: Schaakborddetectie pseudoalgoritme

komt dan overeen met de breedte en hoogte van een schaakvak. Vervolgens duiden we

alle vierkanten aan die de gevonden afstand als hoogte en breedte hebben (Fig. 3.1(d)).

De vierkanten samen die zowel horizontaal als verticaal aangeduid zijn, vormen samen

het schaakbord en geven ons het gewenste resultaat: de plaats van het schaakbord in het

beeld.

Problemen

Het algoritme is zeer gevoelig voor extra randen of lijnen in het beeld die op dezelfde

afstand als de breedte van een schaakvakje van andere randen of lijnen liggen. Bovendien

zijn er naast de manuele berekeningen op de pixels, drie verschillende JAI operaties nodig.

Dit maakt dat het algoritme bijna 50% trager is dan het uiteindelijk geımplementeerde

algoritme.

3.2.2 Tweede methode

De tweede oplossing is deze die in het uiteindelijke programma gebruikt wordt (zie


Figuur 3.3: Detectie van zwart vierkant in beeld.

pseudoalgoritme in figuur 3.2). Ze maakt geen gebruik van de randen in het beeld, maar

segmenteert het beeld op basis van de textuur van de vakjes van het schaakbord. In een

vakje zit meer informatie dan alleen de randen, want het hele vakje bestaat uit dezelfde

kleur. Door gebruik te maken van die informatie kan het schaakbord in minder stappen

gevonden worden en is er minder gevaar voor storende factoren.

Het algoritme verloopt als volgt (Fig. 3.4). Het startbeeld (Fig. 3.4(a) wordt eerst

gefilterd met behulp van een medianfilter om de eenzame pixels te verwijderen.

Hierna wordt een threshold-operatie toegepast (Fig. 3.4(b). Hier worden alle beeld-

punten met een helderheid tussen een bepaald minimum en maximum afgebeeld op een

constante waarde. In dit geval worden alle zwarte en donker grijze punten tot een bepaalde

grenswaarde afgebeeld op volledig zwarte punten. Na deze operatie zullen de donkere

vierkanten van het schaakbord in het beeld uniform zwart zijn.

In de volgende stap worden de zwarte vierkanten gedetecteerd. Door vanaf elk zwart

beeldpunt de grootste mogelijk rechthoek te doen groeien die enkel zwarte pixels bevat

en van die rechthoeken alleen de vierkante en bijna vierkante te nemen die een zekere

grootte hebben (maximaal 24 beeldpunten hoog, minimaal 12: zie Fig. 2.12), vinden we

de zwarte vakken van het schaakvierkant. Dit gaat als volgt (Fig. 3.3). We scannen

het beeld horizontaal lijn per lijn tot we een zwart beeldpunt vinden. Eenmaal een zwart

beeldpunt gevonden, gaan we horizontaal op zoek op dezelfde lijn tot waar de beeldpunten

zwart zijn. Voor elk horizontaal punt kijken we verticaal tot hoever de pixels zwart zijn.

Op die manier vinden we zowel naar rechts als naar onder de grootste rechthoek die enkel


(a) Startbeeld (b) Startbeeld na medianfilter en threshold

operaties

(c) Aanduiding van gevonden zwarte

vierkanten

(d) Schematische weergave van gevonden

schaakbord in beeld

Figuur 3.4: Schaakborddetectie Tweede Methode

3.3 Bewegingsdetectie 37

zwarte punten bevat. De onderzochte punten worden aangeduid zodat ze geen deel meer

kunnen zijn van eventuele andere vierkanten. Het algoritme is in werkelijkheid wel een

klein beetje aangepast omdat de randen nooit perfecte rechten zijn. Dit is opgelost door

altijd op een bepaalde afstand (bijvoorbeeld 3 pixels) van de randen te blijven.

Zoals op figuur 3.4(c) te zien is, bekomen we op die manier de vierkanten waar geen

schaakstukken op staan. Bovenstaand algoritme geeft ons de juiste breedte van het schaak-

bord en de hoogte kunnen we gemakkelijk terugvinden omdat we weten dat een schaak-

bord steeds vierkant is. We weten namelijk dat de gevonden vierkanten middenin het

schaakbord liggen, want we voeren het algoritme uit met de stukken in hun beginsitu-

atie. De eigenlijke hoogte vinden we dan door de gemeten hoogte van de vierkanten

symmetrisch aan te passen met het verschil van de hoogte en breedte.

In figuur 3.4(d) is bovenop het startbeeld een schematisch schaakbord geplaatst in de

positie die we met dit algoritme berekend hebben. Het algoritme heeft het schaakbord in

het beeld gevonden.

Opmerking

Het is voldoende om aan elke rand (boven, onder, links en rechts) van het schaakbord een

zwart vierkant te detecteren om die rand correct terug te vinden. Het algoritme is dus

redelijk robuust, want niet alle vierkanten moeten gedetecteerd worden om het schaakbord

te vinden. Dit betekent wel dat als de schaakstukken niet in hun beginpositie staan, de

positie van het schaakbord niet altijd gedetecteerd kan worden met dit algoritme, want

dan zijn de vrije schaakvakken niet noodzakelijk symmetrisch en weten we niet in welke

richting we de gevonden rechthoek moeten uitbreiden om het schaakbord te bekomen.

3.3 Bewegingsdetectie

Het bewegingsdetectiealgoritme vergelijkt twee beelden om een eventuele schaakzet te

detecteren. Het algoritme wordt aangeroepen wanneer de speler aangeeft dat hij klaar


1 public String detectmovement(BufferedImage image1, BufferedImage image2, int side) {2 // Image1 - Image23 JAI.add(image1);4 JAI.add(image2);5 A = JAI("subtract");6

7 // Image2 - Image18 JAI.add(image2);9 JAI.add(image1);

10 B = JAI("subtract");11

12 for (A en B) {13 for (64 vierkanten van schaakbord) {14 JAI("crop");15 JAI("mean");16 }17 }18 for (gevonden means)19 zoek 2 grootste;20

21 if (means > threshold)22 if (vakA bezet)23 if (vakB niet bezet)24 zet van A naar B;25 if (vakB bezet)26 if (A aan zet)27 zet van A naar B;28 else29 zet van B naar A;30 else31 zet van B naar A;32 return schaakzet;33 else34 return "";35 }

Figuur 3.5: Bewegingsdetectie pseudoalgoritme


(a) Beeld voor zet (b) Beeld na zet

(c) Aanduiding van gevonden zwarte

vierkanten

(d) Schematische weergave van gevonden

schaakbord in beeld

Figuur 3.6: Bewegingsdetectie algoritme

is met zijn zet. Bovendien zal het ook aangeroepen worden na een computerzet om te

controleren of de robot het stuk verplaatst heeft en of het naar de juiste plaats verzet is.

Dit is het enige algoritme dat moet opgeroepen worden om een zet van de speler te

analyseren. GNU Chess verwerkt de uitvoer en berekent de tegenzet van de computer.

Het algoritme werkt als volgt (Fig. 3.6 en Fig. reffig:psalgbd). Vertrekkende van twee

beelden, het beeld voor (Fig. 3.6(a)) en het beeld na de zet (Fig. 3.6(b)), wordt eerst

het beeld voor de zet beeldpunt per beeldpunt afgetrokken van het beeld na de zet. Dit

gebeurt via de JAI-operatie subtract. Dezelfde operatie wordt nog eens herhaald3 in de

3Dit is nodig omdat aftrekken van beeldpunten een verschillend resultaat geeft naargelang het beeld

dat als eerste term gebruikt wordt. Een lichtere pixel min een donkere pixel geeft een niet meer zo lichte

pixel, maar omgekeerd, een donkere pixel min een lichte pixel geeft een zwarte pixel.


andere richting: het beeld na de zet wordt afgetrokken van het beeld voor de zet. In de

twee resulterende beelden wordt dan voor elk vakje van het schaakbord met behulp van

de mean-operatie van JAI de gemiddelde waarde van de beeldpunten in dit vak berekend.

Op figuren 3.6(c) en 3.6(d) is het resultaat van de subtract aangeduid. De gele vierkanten

geven aan van welke gebieden de gemiddelden berekend werden. De JAI-operatie crop

wordt gebruikt om de verschillende deelgebieden te selecteren. Binnen alle berekende

gemiddelden worden dan de twee maximale waarden gezocht. Dit wordt beschouwd als

basis voor de beweging.

In figuur 3.6 zal dus beweging gevonden worden tussen het vak op de vierde rij in de

vierde kolom en het vak op de tweede rij, vierde kolom. Aangezien de toestand van het

schaakbord gekend is, vinden we dat er voor de zet een stuk stond op het vakje van de

tweede rij, dus omgezet in algebraısche schaaknotatie, wordt de beweging als d2d4 aan

GNU Chess doorgegeven.

Als er een stuk van de tegenstander geslagen wordt, zal er ook beweging zijn in het

vak waar het stuk van de speler dat van de tegenspeler vervangt. De stukken zullen ten

eerste nooit precies op dezelfde plaats staan en ten tweede zijn de witte en zwarte stukken

verschillend (ook in bovenaanzicht). De opening in het midden van de metalen sluitring

bovenaan het stuk is immers in dezelfde kleur geschilderd als het stuk zelf.

Problemen

Het algoritme werkt het best als er behalve de uitgevoerde zet geen andere beweging in

het beeld is opgetreden. Een beweging van meerdere stukken kan voor problemen zorgen.

Zo kan het beeld na de beweging van de robotarm verschoven zijn. Daarom wordt er voor

elke bewegingsdetectie gezocht naar het schaakbord in het tweede beeld (met behulp van

patroonherkenning, zie paragraaf 3.4) zodat een eventuele verschuiving gecorrigeerd kan

worden.

3.4 Patroonherkenning 41

1 public void updateChessBoardPos(PlanarImage psrc) {2 for (pattern1 en pattern2) {3 start vanaf plaats in vorig beeld;4 while (pattern niet gevonden)5 neem stuk van huidig beeld gelijk pattern (JAI("crop"));6 maak verschil tussen stuk en pattern (JAI("subtract"));7 zoek gemiddelde waarde van verschil (JAI("mean"));8 kijk of patroon op huidige plaats (mean klein genoeg);9 if (pattern gevonden)

10 sla nieuwe positie schaakbord op;11 }12 }

Figuur 3.7: Patroonherkenning pseudoalgoritme

(a) Gebruikte patronen in beeld voor zet (b) Spiraalvormige zoektocht naar patronen

in beeld na zet

Figuur 3.8: Patroonherkenningsalgoritme

3.4 Patroonherkenning

Het patroonherkenningsalgoritme wordt gebruikt om de translatie tussen twee beelden

onderling ongedaan te maken. Deze translatie is, zoals hierboven beschreven, het gevolg

van de beperkte mechanische precisie van de robotarm. Na de beweging van de arm zal

het beeld na de zet net iets verschoven zijn ten opzichte van het beeld voor de zet. Deze

beweging bestaat voor het grootste deel uit een gewone verschuiving. Door in het eerste

beeld twee patronen te kiezen, bijvoorbeeld een letter of cijfer die aan de rand van het

schaakbord staat, en in het tweede beeld op zoek te gaan naar de plaats van dezelfde

patronen, kan de eventueel opgetreden translatie ongedaan gemaakt worden.

Concreet gebeurt dit als volgt (zie pseudoalgoritme 3.7). In de eerste stap worden

3.4 Patroonherkenning 42

in het laatst gebruikte beeld twee patronen gekozen (Fig. 3.8(a)). In het beeld waarin

de verschuiving is opgetreden wordt dan gezocht naar diezelfde patronen. Er wordt in

de vorm van een spiraal gezocht (Fig. 3.8(b)). We verwachten het patroon op dezelfde

plaats te vinden in het nieuwe beeld als in het vorige beeld, en we beginnen dus met een

stuk uit het beeld te knippen (crop) dat zou moeten overeenkomen met het patroon. We

vergelijken het patroon en het stuk van het huidige beeld door de beelden van elkaar af te

trekken (subtact) en te kijken hoeveel ze van elkaar verschillen (met behulp van mean).

Indien het verschil te groot is, herhalen we de operatie voor alle punten rond het huidige

punt. Dit blijven we doen tot we het patroon terugvinden of tot we alle beeldpunten van

het beeld onderzocht hebben. Eenmaal het patroon gevonden, updaten we de positie van

het schaakbord en houden we bij in welke mate het beeld verschoven is.

Voor we aan de bewegingsdetectie beginnen, gaan we dan eerst kijken of de beelden

verschoven zijn. Indien dit het geval is, verschuiven (JAI-translate-operatie) we eerst

een van de beelden zodat de schaakborden in de twee beelden op dezelfde plaats staan.

Zo kan de bewegingsdetectie correct gebeuren.

Door de invoer van dit patroonherkenningsalgoritme kennen we na de bewegingen

van de robotarm telkens de precieze positie van het schaakbord in het beeld. Dit zal

de kwaliteit van het bewegingsdetectiealgoritme zeker ten goede komen, want die maakt

gebruik van de plaats van het schaakbord in het beeld om beweging te detecteren door de

pixelwaarde uit te middelen over de verschillende schaakvakjes. Er is hier wel een zekere

veiligheidsmarge ingebouwd, maar hoe beter de echte plaats van het schaakbord gekend

is, hoe juister het resultaat zal zijn.

Probleem Een probleem met dit algoritme is dat niet alleen verschuiving kan optreden

tussen de twee te vergelijken beelden, maar ook een kleine rotatie. Deze rotatie is gewoon-

lijk echter te klein om de extra berekeningstijd te verantwoorden die nodig zou zijn om in

elk beeldpunt het patroon ook te roteren en om te kijken of het geroteerde patroon niet

teruggevonden kan worden op de huidige plaats.

3.5 Schaakspecifieke zetten 43

Figuur 3.9: Bewegingsdetectie van promotiestukken.

3.5 Schaakspecifieke zetten

Met een schaakspel zijn een aantal specifieke zetten verbonden die elk een speciale be-

handeling vereisen. In volgende onderdelen worden die speciale schaakzetten een voor een

behandeld.

3.5.1 Promotie

Promotie komt voor in een schaakspel wanneer een speler met zijn pion aan de andere

kant van het schaakbord komt. Dit gebeurt dus wanneer een witte pion naar de achtste

rij wordt verzet of een zwarte pion naar de eerste rij. De speler moet dan in dezelfde

beurt een stuk kiezen waarmee hij zijn pion mag vervangen. Concreet mag hij zijn pion

dus inruilen voor een koningin, een paard, een loper of een toren. Hierbij maakt het niet

uit of die stukken nog op het schaakbord staan of niet. Op deze manier kan de speler

bijvoorbeeld twee (of meer) koninginnen terzelfder tijd op het bord hebben.

Promotie is enkel mogelijk indien een pion van de voorlaatste rij naar de laatste rij

verplaatst wordt. Er moet dus enkel gezocht worden naar promotie indien een witte pion

van rij 7 naar 8, of een zwarte pion van rij 2 naar rij 1 verplaatst wordt. In de algebraısche

notatie komt dan een vijfde karakter dat weergeeft naar welk stuk gepromoveerd werd.


Detectie spelerzet

Stukherkenning Met behulp van stukherkenning kan dit probleem gemakkelijk opgelost

worden. Als elk stuk een welbepaalde unieke bovenkant heeft, kan de computer na een

promotiezet van de speler uitvinden door welk stuk de pion vervangen wordt. Het pro-

bleem is hiermee echter nog niet helemaal opgelost. Aangezien er maar een koningin

van elk kleur in het spel zit, wordt er bij een promotie naar een tweede koningin dikwi-

jls gebruik gemaakt van een omgekeerde toren of worden twee pionnen op hetzelfde vak

geplaatst om de rol van tweede koningin te spelen. Met simpele stukherkenning zou dit

probleem niet direct opgelost zijn, want de computer kan niet weten wat die omgekeerde

toren voorstelt. Een eerste oplossing hiervoor is dat de speler de pion vervangt en dan

aangeeft op de computer naar wat hij gepromoveerd heeft. Dit betekent echter dat het

niet meer nodig is om de stukken te identificeren als de speler toch aangeeft naar welk

stuk hij promoveert. Voor de bewegingsdetectie moeten de stukken immers niet herkend

worden. Een andere mogelijkheid is het voorzien van meerdere stukken van elke soort,

zoals bijvoorbeeld 3 koninginnen en 4 lopers.

Bewegingsdetectie buiten het schaakbord Ik heb de herkenning van individuele

stukken niet ingevoerd, en moest dus het detecteren van een promotiezet op een andere

manier behandelen. We zorgen ervoor dat de stukken van de speler die niet op het bord

staan, een vaste plaats hebben die ook in het beeld van de camera vallen. Dit is mogelijk

omdat het toch steeds de robotarm is die bij het slaan het stuk van de tegenspeler eerst van

het bord moet plaatsen vooraleer hij zijn eigen stuk kan verplaatsen. De computer bepaalt

dus de plaats van de stukken van de menselijke tegenspeler. We kunnen die stukken steeds

op een welbepaalde plaats zetten. Op de onderste rij rechts naast het schaakbord zetten

we bijvoorbeeld altijd de koningin(nen) en op de voorlaatste rij de lopers. Als we ervoor

zorgen dat die plaatsen ook in het gezichtsveld van de camera vallen, kunnen wij het

bewegingsdetectiealgoritme aanpassen (Fig. 3.9) zodat bij een eventuele promotie ook op

die plaatsen naar beweging wordt gezocht. De computer kan daarmee uitzoeken naar welk

stuk de speler promoveert.


Er blijft hier wel een groot probleem. Als de speler promoveert naar een stuk dat

hij nog steeds op het schaakbord heeft staan (bijvoorbeeld een tweede koningin), zal de

speciale plaats leeg zijn en kan er daar geen beweging gedetecteerd worden. Dus ook hier

moeten we in extra stukken voorzien waarmee we begint de speciale plaatsen opvullen

voor het spel. Dit hoeft in de huidige situatie geen probleem te zijn, want alle stukken

zijn identiek en een aantal extra stukken is geen probleem. Er treedt nog een probleem op

als de speler wil promoveren naar een derde koningin. Ook dan zal er geen stuk meer staan

op de speciale plaats en kan de computer daar geen beweging detecteren. Als oplossing

hiervoor kunnen we de speler vragen om na promotie het speciale vak zelf opnieuw in te

vullen met een ander stuk. Maar dit geval treedt zo zelden op dat het me niet de moeite

lijkt om hier veel rekening mee te houden.

De computer moet wel bijhouden hoeveel stukken van een bepaalde soort hij al geslaan

heeft, zodat de robotarm de twee koninginnen niet op elkaar zet, maar bijvoorbeeld naast

elkaar op dezelfde rij.

Aansturing robotarm

Bij promotie geeft GNU Chess een vijfde karakter in zijn uitvoer zodat het testen op de

aanwezigheid van dit karakter al voldoende is om promotie te detecteren. Indien dit zo

is, moet de robot na de zet uitgevoerd te hebben de pion vervangen door het opgegeven

stuk. Aangezien alle stukken identiek zijn, moet het stuk fysiek niet vervangen worden

maar volstaat het de speler mee te delen dat er promotie is opgetreden. De grafische

gebruikersinterface kan de speler aangeven naar welk stuk er gepromoveerd is.

3.5.2 En passant

De en passant-zet speelt zich af tussen twee pionnen (Fig. 3.10). Als de witte speler zijn

pion in de eerste zet van die pion twee rijen vooruit plaatst (Fig. 3.10(a)), maar de zwarte

speler heeft een pion die de witte pion zou kunnen slaan indien de witte pion maar een rij


(a) Zet (b) En passant mo-

gelijk

(c) Tegenzet uitgevo-

erd

Figuur 3.10: En passant

vooruit gaat, mag de zwarte speler doen alsof wit maar een stap verplaatst is en dus schuin

vooruit gaan (Fig. 3.10(b)) en de witte pion van het spelbord verwijderen (Fig. 3.10(c)).

Detectie spelerzet

Het bovenstaande bewegingsdetectiealgortime kan perfect toegepast worden na deze zet,

maar er zijn nu drie plaatsen waar beweging plaatsgevonden heeft. De plaats waar de

zwarte pion stond (b4) en de plaats naar waar de zwarte pion beweegt (b3), maar ook

de plaats waar de witte pion stond (a4). Het algoritme kan hieruit drie mogelijke zetten

afleiden. Eerst en vooral de voor de hand liggende correcte zet b4a3 (omgekeerd kan niet

want beweging kan enkel van het vak waar stuk op stond naar het lege vak). Het zal echter

ook b4a4 kunnen vinden waarbij zwart de witte pion zijwaarts slaat. Omgekeerd kan niet,

want zwart is aan zet dus het slaan kan maar in een richting. Als laatste mogelijkheid

is er a4a3 waarbij de witte pion een stap achteruit zet. Opnieuw kan dit maar in een

richting omdat er een vak bezet is en een ander niet.

Van de drie bovenvermelde zetten (zie ook Fig. 3.11) is er maar een legale zet. En

dat is b4a3. De twee andere zijn onmogelijk. Men mag niet zijwaarts slaan met een pion

of een pion achteruit zetten. Het volstaat dus om na de bewegingsdetectie, indien de

beweging met pionnen gebeurt, op zoek te gaan naar deze twee illegale bewegingen en


Figuur 3.11: Bewegingsdetectie van promotiestukken.

deze om te zetten in een legale beweging.

Welke zet gedetecteerd zal worden, hangt af van de kleur van het vakje. Een beweging

op een zwart vak zorgt voor een grotere afdruk in het verschilbeeld (Fig. 3.6(c) en 3.6(d))en

dus een hogere gemiddelde pixelwaarde dan een beweging in een wit vak. Het bewegings-

detectiealgoritme gaat op zoek naar de plaatsen met de hoogste gemiddelde waarden en

zal dus de beweging van het stuk op het zwarte vak detecteren.

Aansturing robotarm

Een en passant-beweging ziet er op het eerste zicht hetzelfde uit als een normale zet

waarin een pion een ander stuk slaat, namelijk een schuine voorwaartse beweging, maar

heeft wel als verschil dat er geen stuk van de tegenspeler staat in het vakje waar de pion

naar beweegt. Het volstaat dus om bij elke schuine pionbeweging te checken of er wel

een stuk geslaan wordt. Indien niet, treedt er en passant op en moet de robotarm eerst

de pion van de tegenspeler van het bord verwijderen. Zijn pion kan maar op een plaats

staan, namelijk op dezelfde rij als vanwaar de zet vertrekt en op dezelfde kolom als waar

de zet eindigt.


(a) Uitgangspositie rokeren

(b) Korte rokade

(c) Lange rokade

Figuur 3.12: Rokeren


3.5.3 Rokade

De rokade is misschien wel de meest gekende speciale schaakzet (Fig. 3.12). In deze zet

worden zowel de koning als een toren verplaatst. Er bestaan twee varianten, de korte en de

lange rokade, afhankelijk van de kant waarheen de koning beweegt (Fig. 3.12(b) en 3.12(c)).

Er zijn een aantal voorwaarden verbonden aan het feit of men al dan niet mag rokeren.

Zo mag de koning of de toren nog niet verplaatst zijn, en mag men niet rokeren als de

koning langs een vak moet passeren waarin hij schaak komt te staan. Ik test niet of aan

deze voorwaarden voldaan is, omdat dit zou betekenen dat niet alleen de huidige toestand

van het schaakbord bijgehouden moet worden, maar ook de geschiedenis van het spel.

Detectie spelerzet

Een rokade van de speler detecteren met bovenstaand bewegingsdetectiealgoritme zou

betekenen dat er een beweging kan gevonden worden tussen vier verschillende vakjes.

Aangezien de toren veel meer bewegingen kan uitvoeren dan een pion, volstaat het hier

niet om de illegale zetten te detecteren en die om te vormen tot legale zetten. Er moet

hier omgekeerd gewerkt worden. Een mogelijke rokade wordt gedetecteerd voor het be-

wegingsdetectiealgoritme de zetten uit het beeld haalt. Eerst detecteren we of rokade

al dan niet mogelijk is. Zoals ik hierboven vermeld heb, kan ik niet kijken of aan alle

voorwaarden voldaan is. Daarom werk ik met versoepelde eisen. Ik zoek in de eerste

plaatst of de toren en de koning nog op hun beginplaats staan, waarna ik controleer of

de weg tussen hen vrij is. Indien er rokade kan optreden ga ik eerst gericht op zoek naar

beweging in die toren- en koningsvakken waar rokade mogelijk is. Als er daar beweging

gevonden wordt, weet ik dat er rokade opgetreden is, en kan de juiste zet aan GNU Chess

doorgeven worden.

Er is wel een probleem indien de speler rokeert terwijl hij eigenlijk niet mag. Het

algoritme zal de rokade detecteren en doorgeven aan GNU Chess, maar die zal de zet

verwerpen en een illegal move bericht teruggeven. Het is dan aan de gebruiker om de zet

ongedaan te maken en een andere zet uit te voeren.


Aansturing robotarm bij tegenzet

Een rokade zal steeds bestaan uit een schijnbaar illegale zet voor de koning. Afhankelijk

of het een korte of lange rokade is, wordt de koning twee of drie vakjes op dezelfde rij

verplaatst. Dit kan enkel op de eerste of laatste rij van het bord. Dit is gemakkelijk

te detecteren en de enkelvoudige beweging wordt dan omgevormd tot twee verschillende

bewegingen: eerst wordt de toren verplaatst, dan wordt de koning op de gevraagde plaats

gezet.

PROGRAMMASTRUCTUUR 51

Hoofdstuk 4

Programmastructuur

4.1 Inleiding

Het programma dat de schaakrobot controleert is zoals eerder vermeld volledig in Java

geschreven. Hiervoor heb ik handig gebruik kunnen maken van de bestaande Javacode

van de verschillende componenten.

De robot kan via Javamethoden aangestuurd worden. Voor de Sony camera wordt

gebruik gemaakt van de RGBStream klasse die de beelden van de camera via een socket

aanbiedt aan zowel de lokale PC als elke PC via een netwerk verbonden met knuth.

Het schaakprogramma GNU Chess is in C geschreven en we starten het binnen het

programma op als proces zoals in paragraaf 2.5.2 uitgelegd is.

Concreet zijn er 7 klassen:

• ProcessController

• RobotController

• CyclopsStream

• ChessRobot

4.2 ProcessController 52

• SchaakBord

• ChessColumn

• Constants

In volgende delen wordt elke klasse afzonderlijk behandeld en worden hun belangrijkste

methoden beschreven. Zie appendix A voor een UML-schema. In figuur 2.14 wordt het

verloop van het programma geıllustreerd.

4.2 ProcessController

Deze klasse vormt de hoofdklasse van het programma. Hierin wordt het GNU Chess-

proces gestart, wordt de uitvoer van dit proces verwerkt, en wordt de invoer gegenereerd

en aan het proces aangeboden.

Zoals vermeld in paragraaf 2.14 bestaat deze klasse uit vijf draden die naast elkaar

lopen (Fig. 2.14).

1. GNUChessProcess

2. GNUChessInput

3. GNUChessOuput

4. GNUChessError

5. StreamUpdater

4.2.1 GNUChessProcess

Deze draad start het GNU Chess proces op en biedt een interface naar de invoer en uitvoer

(zowel standaard als error) van dit proces.

4.2 ProcessController 53

4.2.2 GNUChessInput

In deze draad wordt bij het opstarten van het programma na bevestiging door de gebruiker,

het schaakbord in het beeld gedetecteerd. Vervolgens wordt hier na elke zet van de speler

het bewegingsdetectie algoritme opgeroepen. De gevonden beweging wordt doorgegeven

aan het GNU Chess-proces. Er wordt gewacht via het IONotificationObject object

tot GNU Chess uitvoer gegeven heeft, ofwel in de vorm van een tegenzet, ofwel in de

vorm van een bericht dat een illegale zet is opgetreden. Door op een knop te drukken

geeft de gebruiker via de grafische interface weer wanneer hij klaar is met zijn zet. Via

het EMNotificationObject object wordt aangegeven wanneer het bewegingsdetectieal-

gorimte opgeroepen moet worden. In figuur 2.14 wordt het verloop van de verschillende

draden en de berichtgeving tussen de draden geıllustreerd.

4.2.3 GNUChessOutput

Hier wordt de uitvoer geınterpreteerd die GNU Chess genereert, ofwel door de tegenzet

door te geven aan de klassen die de robot aansturen en die de toestand van het schaakbord

bijhouden, ofwel door bij een illegale zet de gebruiker in te lichten en de eventueel al gedane

veranderingen ongedaan te maken.

4.2.4 GNUChessError

Deze draad bevat geen functionaliteit maar moet voorzien zijn, want indien GNU Chess

eventueel toch erroruitvoer zou genereren zal het proces vastlopen als de buffer van de

uitvoer vol zit en die nooit geleegd wordt. De uitvoer wordt daarom uit de buffer gehaald

en naar de console geschreven, maar wordt verder genegeerd door het programma.

4.3 RobotController 54

4.2.5 StreamUpdater

Deze draad staat eigenlijk los van het GNU Chess proces, maar zorgt ervoor dat op

regelmatige tijdstippen (elke halve seconde) een beeld van de camera genomen wordt en

de grafische interface bijgewerkt wordt met dit nieuwe beeld.

4.3 RobotController

Deze klasse bevat routines om de robot aan te sturen. Hij bevat de aangepaste metho-

den die rekening houden met de extensie waarop de magneet zit (zie paragraaf 2.2.2).

Bovendien bevat hij de kleine aanpassingen die nodig zijn om de afwijkingen die de robot

vertoont te corrigeren (zie paragraaf 2.1.2).

De coordinaten van het schaakbord zijn momenteel vast gecodeerd in het programma

zodat de rijen en kolommen van een schaakvak volstaan om de robot naar de juiste plaats

te sturen. De movePiece methode neemt als input een cijfer voor de kolom en rij vanwaar

het stuk verplaatst moet worden en een derde en vierde cijfer voor de kolom en rij van

de bestemming. Er wordt automatisch gezorgd dat de robotarm op de correcte hoogte

komt te staan en dat de magneet aangezet wordt als het stuk vastgenomen moet worden.

Als een stuk naast het schaakbord moet worden gezet, zal dit ook gedetecteerd worden1

en wordt de hoogte automatisch aangepast zodat de arm wat dichter bij de basisplaat

van de robot komt en de stukjes daar kan neerzetten (na het slaan van een stuk van de

speler). De hoogtes die de robotarm gebruikt om een stuk op te pakken, en om het stuk

te verplaatsen zijn ook vast gecodeerd in het programma.

4.4 CyclopsStream

Deze klasse verzorgt de grafische interface en zal de beeldenstroom van de camera ont-

vangen. Intern worden twee beelden in het geheugen gehouden. Het ene beeld dient als

1Als de meegeven kolom of rij niet binnen de 8 rijen en kolommen van het schaakbord ligt.

4.5 ChessRobot 55

basisbeeld dat wordt vergeleken met het andere, meest recente beeld van de camera om

bewegingsdetectie toe te passen. Het is deze klasse die de algoritmen oproept met de

beelden waarop ze toegepast moeten worden.

4.5 ChessRobot

De ChessRobot klasse is de klasse die de eigenlijke functionaliteit bevat. Deze klasse

bevat alle algoritmen die in hoofdstuk 3 beschreven zijn.

In deze klasse wordt de robot aangesproken met behulp van de methoden van de

RobotController klasse.

De klasse bevat een element van de SchaakBord klasse waarin de huidige toestand van

het schaakbord bijhouden wordt.

De klasse behandelt de zetten die GNU Chess genereert en roept de methoden op die

de robot aansturen en die de toestand van het schaakbord bijwerken. Bij het slaan van

een stuk moet het stuk van de tegenstander van het bord genomen worden en naar een

bepaalde plaats naast het schaakbord gebracht worden. Ook speciale schaakbewegingen

moeten hier behandeld worden, want ze vereisen extra bewegingen. Bij een rokade moet

ook de toren verplaatst worden en bij een en passant zet moet de pion van de tegenspeler

van het schaakbord gehaald worden. Promotie vraagt geen fysieke beweging dus moet er

niets speciaals gebeuren (zie paragraaf 3.5.1).

4.6 Schaakbord

Deze klasse bevat de positie van de stukken op het schaakbord en een aantal methoden

die de verschillende speciale schaakzetten onderscheppen.

4.7 ChessColumn 56

4.7 ChessColumn

Met behulp van deze klasse kunnen de letters die gebruikt worden om de kolommen van

een schaakbord aan te duiden, gemakkelijk omgezet worden in een cijfer en omgekeerd.

4.8 Constants

Deze interface bevat alle constanten die in de bovenstaande klassen gebruikt worden.

Deze centralisatie zorgt ervoor dat veranderingen van de vast gecodeerde waarden vlot

kan verlopen en dat ze vlot te overzien zijn.

4.9 Aanpassingen aan bestaande klassen

Het vervangen van de grijper door een elektromagneet vereiste enkele aanpassingen in de

robotcode.

4.9.1 Robot.java

Twee nieuwe procedures toegevoegd die de LED op de interfacekaart aansturen (LED 1 op

Fig. 2.7). Zoals beschreven in paragraaf 2.2.2 wordt met die LED de magneet aangestuurd.

4.9.2 PidLoop.java

Volgende code werd toegevoegd aan de myPid() methode:

if (requestvalue[5] > 0.0f) {

myrobot.ledOff();

}

4.9 Aanpassingen aan bestaande klassen 57

else {

if (requestvalue[5] < 0.0f)

myrobot.ledOn();

}

We zetten de beweging van het laatste gewricht om in het aan- of afzetten van de

elektromagneet. Dat gewricht stelt het openen en sluiten van de grijper voor. Als de

grijper opengezet wordt, krijgt de aansturing een positieve waarde mee. We gebruiken

dit gegeven om de LED aan te sturen en de elektromagneet aan te zetten. Omgekeerd

hebben we een negatieve waarde bij het sluiten van de grijper die we omzetten in het

afzetten van de elektromagneet.

PRESTATIEMETING 58

Hoofdstuk 5

Prestatiemeting

In tabel 5.1 heb ik de uitvoeringstijden van de verschillende algoritmes vergeleken op

twee verschillende systemen. De eerste kolom bevat de uitvoeringstijd in seconden op een

hedendaags Pentium 4 aan 2.53 GHz. Deze computer is niet verbonden met de robot of de

camera, maar maakt gebruik van een reeks beelden die met de camera opgenomen zijn. De

aansturing van de robot kan hier niet gebeuren, en is dus niet van toepassing. De tweede

PC (knuth) is de eigenlijke PC die zowel met de camera als met de robot verbonden is.

Knuth bevat een iets oudere Pentium 2 aan 350 MHz. Een eerste belangrijke opmerking

bij de tabel is dat GNU Chess altijd ongeveer 5 seconden rekent aan zijn tegenzet. Op een

trager systeem zal hij minder zetten kunnen simuleren, en de kwaliteit van de tegenzet

zal minder goed zijn, maar de rekentijd wordt overal dezelfde gehouden. Vergelijken we

de uitvoeringstijden van de twee systemen, dan zie we dat knuth meer dan een factor tien

trager is dan de Pentium 4. Dit heeft vooral te maken met de JAI-operaties. De Pentium 4

is in staat om met behulp van SSE (naast MMX) de beeldverwerkingsalgoritmes duidelijk

sneller uit te voeren.

Voor het evalueren van de zet van de speler is het enkel noodzakelijk om bewegingsde-

tectie uit te voeren. Dit duurt net iets langer dan GNU Chess nodig heeft voor de tegenzet

op knuth, maar de Pentium 4 heeft het in een halve seconde geklaard. Op de snellere PC

duurt het berekenen en uitvoeren van de tegenzet 30% langer dan de tijd die GNU Chess

PRESTATIEMETING 59

Knuth

P4 2.54 GHz P2 350 MHz

Schaakborddetectie 1.3 15

Zet (Bewegingsdetectie) 0.5 6.0

Tegenzet 6.5 49

GNU Chess 5.0 5.1

Robotaansturing 35.9

Patroonherkenning 0.5 2.0

Bewegingsdetectie 0.5 8.0

Tabel 5.1: Prestatievergelijking voor verschillende CPU’s (in seconden)

nodig heeft om de tegenzet te bereken. Op knuth duurt dit bijna 140% langer zonder de

tijd mee te rekenen die de robot nodig heeft om de stukken te verplaatsen. Die neemt op

zich bijna 73% van de tijd voor de tegenzet in beslag. Een snellere processor zal hier niet

veel helpen want de snelheid van de robotbeweging wordt bepaald door de robotmotoren.

Bovenstaande tijden zijn bovendien uitvoeringstijden van enkelvoudige bewegingen. Als

de robot twee stukken moet verplaatsen, bijvoorbeeld omdat een stuk geslagen wordt, kan

die beweging gemakkelijk tot bijna twee keer zo lang duren.

Ook het patroonherkenningsalgoritme is sterk variabel. Als het patroon snel teruggevon-

den wordt in het beeld zal het algoritme vlug eindigen, maar is het beeld wat meer ver-

schoven, dan kan die tijd vlug sterk oplopen.

Besluit De robotarm bepaalt sterk de maximale snelheid van de uitvoering. Mede door

het gebruik van JAI zijn de algoritmen heel schaalbaar en kan de uitvoeringstijd sterk

gereduceerd worden door met een recentere CPU te werken. De berekeningstijd van GNU

Chess is onafhankelijk van het onderliggende systeem.

BESLUIT 60

Hoofdstuk 6

Besluit

Jeroom kan schaken! Een menselijke speler kan met een schaakbord zonder speciale

sensoren een schaakspel spelen tegen de computer. Die volgt het spel met een camera en

verplaatst de stukken met behulp van de robotarm Jeroom.

6.1 Realisatie

Volgende punten zijn gerealiseerd:

• De robotarm is uitgerust met een elektromagneet waarmee hij de stukken kan

verzetten.

• Het programma kan de robotarm aansturen en de schaakstukken verplaatsen.

• De computer kan met behulp van een camera het spel meevolgen en de zetten van

de speler detecteren.

• Een bestaand schaakprogramma (GNU Chess) is geıntegreerd in het programma.

Dit programma verwerkt de zetten van de speler en genereert de tegenzetten. Het

schaakprogramma kan gemakkelijk vervangen worden door een ander.

6.2 Toekomst 61

• Het gebruikte schaakbord is volledig standaard, zonder speciale sensoren of eigen-

schappen.

• De platte, ronde schaakstukken hebben een metalen bovenkant zodat ze door de

elektromagneet verplaatst kunnen worden.

• Het programma is volledig in Java geschreven.

• De uitvoeringstijd is aanvaardbaar. Op een hedendaagse PC neemt het berekenen

van de tegenzet het grootste deel (75%) van de tijd1 in beslag.

6.2 Toekomst

Het opheffen van een aantal technische beperkingen zou een aantal verbeteringen mogelijk

maken. De meest beperkende factor is de robotarm die eigenlijk te groot en niet precies

genoeg is om de kleine schaakstukken betrouwbaar te verplaatsen. Bovendien neemt de

verplaatsing van het stuk met de robotarm minstens 70% van de tijd van de tegenzetten

in beslag.

Het gebruik van een grijper in de plaats van een elektromagneet zou het mogelijk

maken om met gewone schaakstukken te werken. Zolang een elektromagneet gebruikt

wordt om de stukken te verplaatsen, zullen die altijd een metalen bovenkant moeten

hebben. Dit beınvloedt sterk de indruk die de mensen hebben van de schaakrobot omdat

dit betekent dat de stukken sterk verschillen van normale schaakstukken. Bovendien zijn

de stukken op die manier moeilijk van elkaar te onderscheiden.

Een nieuwe processor met een hogere snelheid zou de uitvoeringstijd van de beeldver-

werkingsalgoritmen gevoelig doen afnemen en eventueel extra beeldverwerking mogelijk

maken. Zo zou de resolutie van de camerabeelden eventueel verdubbeld kunnen wor-

den wat stukherkenning of misschien zelfs vormherkenning mogelijk zou maken. Ook het

gebruik van kleuren zou een aantal nieuwe toepassingen toelaten.

1Uitvoeringstijd van de verwerkingsalgoritmen. Robotaansturing telt niet mee.

6.2 Toekomst 62

Het gebruik van een vast gemonteerde camera of het vergroten van de afstand tussen de

camera en het schaakbord zou een aantal problemen vereenvoudigen. De grootte van het

schaakbord wordt nu bepaald door de camera. Indien de robotarm de beperkende factor

wordt, kan een dubbel zo groot2 schaakbord gebruikt worden. Bij een groter schaakbord

zou de beperkte nauwkeurigheid van de robotarm minder relevant zijn.

Bovenstaande verbeteringen zijn echter vooral cosmetisch van aard en veranderen

weinig aan de werking van de schaakrobot. De functionaliteit van de huidige schaakrobot

is quasi volledig.

2Dankzij de extensie waarop de robotarm gemonteerd is.

UML 63

Bijlage A

UML

In Figuur A.1 is een vereenvoudigd UML-schema van het programma te zien. Enkel de

belangrijkste methoden zijn weergegeven om het geheel overzichtelijk te houden.

UML 64

Figuur A.1: Vereenvoudigd UML-schema

CDROM 65

Bijlage B

CDROM

Bijgevoegd vindt u een CDROM met:

• de volledige broncode

• JavaDoc-documentatie

• Filmfragmenten van de robot in actie. Een fragment toont de eerste twee zetten

en tegenzetten van een schaakspel. Het andere toont de robot die een zet uitvoert

waarbij een stuk geslagen wordt: eerst wordt het stuk van de speler aan de kant

gezet; vervolgens wordt het stuk van de computer verplaatst.

• 3dsmax model van de schaakrobot. De schaal van de robotarm is correct en de

mogelijke bewegingen realistisch. De stand van de robotarm wordt met behulp van

schuifbalken geregeld.

BIBLIOGRAFIE 66

Bibliografie

[1] http://java.sun.com/docs.

[2] R. Blomme, Parallellisme in software voor sensorgestuurde robots, master’s thesis,

Universiteit Gent, Laboratorium voor Elektronica en Meettechniek, 1988.

[3] M. Campione, K. Walrath, and A. Huml, The Java Tutorial, Third Edition.

A Short Course On The Basics, Addison-Wesley, Boston, 2001.

[4] C. H. Chen, L. F. Pau, and P. S. P. Wang, Handbook of Pattern Recognition

& Computer Vision, World Scientific, Singapore, 1999.

[5] T. Christiaens and F. Merchant, Ontwerp van een usb-interface voor een robot-

controller, master’s thesis, Universiteit Gent, Vakroep Elektronica en Informatiesys-

temen, 2001.

[6] T. De Coninck and D. Van Den Bremt, Automatisch volgen van bewegende

objecten, master’s thesis, Universiteit Gent, Vakgroep Elektronica en Informatiesys-

temen, 2003.

[7] G. De Paepe, Robotcontrole op een gedistribueerde multiprocessor, master’s thesis,

Universiteit Gent, Laboratorium voor Elektronica en Meettechniek, 1990.

[8] G. De Vocht and N. Vercammen, Real-time robotsturing in java, master’s thesis,

Universiteit Gent, Vakgroep Elektronica en Informatiesystemen, 2001.

[9] K. Venstermans, Realtime robotaansturing in java, master’s thesis, Universiteit

Gent, Vakgroep Elektronica en Informatiesystemen, 2002.

BIBLIOGRAFIE 67

[10] A. R. Weeks, Fundamentals of Electronic Image Processing, IEEE Press, New York,

1996.

LIJST VAN FIGUREN 68

Lijst van figuren

1.1 Scorbot Jeroom (1985) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Close-up van de camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Behandeling van overflow door de robot . . . . . . . . . . . . . . . . . . . . 9

2.2 Horizontale en Verticale positie van het grijperscharnier . . . . . . . . . . . 10

2.3 Cartesiaanse aansturing robot. Beweging ligt niet in een vlak. . . . . . . . 11

2.4 Robotcoordinaten van de hoekpunten van het schaakbord. . . . . . . . . . 12

2.5 Bereik van de robotarm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Magneet plus extensie op laatste scharnier. . . . . . . . . . . . . . . . . . . 15

2.7 Interfacekaarten robot en magneet. . . . . . . . . . . . . . . . . . . . . . . 16

2.8 Close-up van de spoel van de elektromagneet. . . . . . . . . . . . . . . . . 17

2.9 In rekening brengen van verlengstuk bij beweging robot. . . . . . . . . . . 18

2.10 Schaakstukken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.11 Beeld van schaakbord met vervorming van de rand duidelijk zichtbaar. . . 21

2.12 Nuttige oppervlakte schaakstuk in beeldpunten. . . . . . . . . . . . . . . . 23

2.13 Korte GNU Chess sessie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

LIJST VAN FIGUREN 69

2.14 Dradenstructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.15 Grafische gebruikersinterface . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Schaakborddetectie Eerste Methode . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Schaakborddetectie pseudoalgoritme . . . . . . . . . . . . . . . . . . . . . 34

3.3 Detectie van zwart vierkant in beeld. . . . . . . . . . . . . . . . . . . . . . 35

3.4 Schaakborddetectie Tweede Methode . . . . . . . . . . . . . . . . . . . . . 36

3.5 Bewegingsdetectie pseudoalgoritme . . . . . . . . . . . . . . . . . . . . . . 38

3.6 Bewegingsdetectie algoritme . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.7 Patroonherkenning pseudoalgoritme . . . . . . . . . . . . . . . . . . . . . . 41

3.8 Patroonherkenningsalgoritme . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.9 Bewegingsdetectie van promotiestukken. . . . . . . . . . . . . . . . . . . . 43

3.10 En passant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.11 Bewegingsdetectie van promotiestukken. . . . . . . . . . . . . . . . . . . . 47

3.12 Rokeren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

A.1 Vereenvoudigd UML-schema . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Aansturing van een schaakrobot op basis van...

Documents

Transcript of Aansturing van een schaakrobot op basis van...