aansturing van een schaakrobot op basis van...
TRANSCRIPT
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
5. Referentiepositie
6. Verzetten van stukken
7. Referentiepositie
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.
2.2 Elektromagneet 15
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.
2.2 Elektromagneet 16
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
2.2 Elektromagneet 17
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.
2.2 Elektromagneet 18
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
invoer- en 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 invoer- en
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 invoer- en 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.
3.2 Schaakborddetectie 33
(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
3.2 Schaakborddetectie 34
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
3.2 Schaakborddetectie 35
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
3.2 Schaakborddetectie 36
(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
3.3 Bewegingsdetectie 38
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
3.3 Bewegingsdetectie 39
(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.
3.3 Bewegingsdetectie 40
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.
3.5 Schaakspecifieke zetten 44
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.
3.5 Schaakspecifieke zetten 45
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
3.5 Schaakspecifieke zetten 46
(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
3.5 Schaakspecifieke zetten 47
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.
3.5 Schaakspecifieke zetten 48
(a) Uitgangspositie rokeren
(b) Korte rokade
(c) Lange rokade
Figuur 3.12: Rokeren
3.5 Schaakspecifieke zetten 49
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.
3.5 Schaakspecifieke zetten 50
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