Opsummering af projektet

Idéen om TroNXT:

Vi havde fra start et ønske om at lave et spil, der kunne være sjovt at spille som menneske mod en computerstyret spiller. Vi kendte begge to Tron og kunne se en passende mængde udfordringer i at lave spillet.

Tanken var fra starten, at spillet skal være lige for alle, således at alle spillere (mennesker eller computere) har adgang til den samme grundlæggende robot.

Processen:

Vores prioriteter lå klar fra starten, og udviklingen af dem fulgte rækkefølgen.

1. Bluetooth skal virke

2. Tusch kan aflæses

3. Robotten kan styres via PC

4. Robotten kan styres af NXT

Da Bluetooth-adgang var den største risiko ved vores projekt, valgte vi at starte med at få dette til at virke. Med udgangspunkt i LeJOS-guides og Google-søgninger gik vi igang med at få hul igennem mellem PC og NXT. Det tog rigtigt lang tid, først i starten af projektet og senere halvvejs igennem projektet, hvor alting igen brokkede sig... Det var ærgelig tid at bruge, men nødvendigt for projektet. For at spare tid på Bluetooth-bøvl valgte vi at bruge Python på PC-klienten i stedet for LeJOS-PC, da vi ikke kunne få Java-Bluetooth til at virke, og ikke ville bruge mere tid på at bøvle med det.

Som næste skridt gik vi igang med at designe robotten og den tilhørende software. Dette blev gjort "bottom-up", dvs. vi startede med en simpel robot, der kunne styres fra PC og registrere linier. Dette blev implementeret som en TronBike med en BTControlledPlayer og en WallDetector. Derefter tilføjede vi en Bumper og senere byggede vi tuschen på. Vi var begge spændte på, om lyssensoren kunne se forskel på en hvid tavle med/uden tuschstreg, men med en ny tusch viste det sig, at der var en forskel på ca. 2. Udsvingene henover den hvide tavle var ca. 0, så tuschstregerne kunne godt registreres.

Da alt dette virkede i tilstrækkelig grad, tilføjede vi endnu en WallDetector som computerspillerne kunne bruge til at registrere linier.

Byggevejledningen til den endelige robot kan findes her:

http://tronxt.googlecode.com/svn/trunk/doc/instructions/Building%20Instructions%20[TronBot].html

I svn-historien ligger der et par ældre udgaver, disse kan ses ved checkout af de relevante revisioner.

I den sidste del af forløbet valgte vi at dele arbejdet mere op imellem os, således at pepe udviklede PC-delen, mens rfogh udviklede computerstyringen af robotterne.

Udbytte:

I løbet af projektet har vi arbejdet dybdegående med flere af emnerne fra kurset. Her kan bl.a. nævnes kommunikation, hvor vi har fået Bluetooth-forbindelser til at virke i praksis, samt udviklet en simpel protokol til kommunikation mellem PC og NXT. Vi har også arbejdet med sensorer og aktuatorer som en helt naturlig del af vores robot, hvor vi også har brugt reaktive strategier til at styre den med, da Tron-spillet lægger op til en "bang-bang"-implementation.

Derudover har den ene af vores computerspillere brugt en simpel form for navigation/map-building, hvor den hele tiden forsøger at holde øje med motorernes omdrejninger (tacho count) for at kunne bestemme sin egen placering på banen.

Perspektivering:

Hvis projektet skulle fortsætte, ville den første oplagte ting at kigge på være, om man kunne få robotten til mere præcist at dreje 90 grader. De to robotter drejer ikke lige skarpt med den samme konfiguration, hvilket til dels ødelægger spillet og i hvert fald de forudsætninger, vi bygger spillet på.

En anden forbedring kunne være at bygge en afstandssensor på robotten, eller tolke Bumper-input som signal til at dreje i stedet for signal til at tabe. På den måde vil computerspillerne have en større sandsynlighed for at opdage andre robotter og dreje i tide.

Som en sidste forbedring kan nævnes robotdesign. En perfekt løsning vil have både lyssensor og tusch placeret på midten, samtidig med robotten skal være saml og med lavt tyngdepunkt. Alle disse kriterier kan ikke blive opfyldt på en gang, men der kan nok findes et bedre kompromis end vores nuværende robot.

En feature, der ville kunne tilføje en ekstra dimension til spillet, er muligheden for at indføre highscores. Dette kunne gøres ved at måle fx tid eller tachocount pr. spil. På den måde kan menneskespillere konkurrere på tværs af spil, samtidig med, at highscore kan bruges til at vurdere forskellige computerspilleres kvalitet.

Computerspillerne kan ligeledes forbedres/gøres mere intelligente. Dette kan ske ved fx map-building, hvor computerspilleren til stadighed opdaterer et kort over banen, og forsøger at indføre nye streger, når den opdager dem.

En anden mulighed ville være at indføre en subsumption-arkitektur til at forene de to eksisterende computerspillere, således at den midter-søgende computerspiller er aktiv, når robotten er tæt på kanten af pladen, mens den mere tilfældige computerspiller er aktiv, når robotten er nær midten af pladen.

Konklusion

Det er lykkedes os at lave et brugbart Tron-spil, hvor vi har udviklet en AI, som en menneskespiller kan tabe til. Tron-spillet er lavet på så simpel en måde, at alle kan være med.

Til trods for større og mindre udfordringer mener vi derfor at have opfyldt målet med projektet.

The Final Countdown

Fremmødte

pepe og rfogh (11-16)

Formål

Forbedre eksisterende dokumentation, samt lette opsætning af spillet (forbedringer af PC-programmet).

Forsøg

rfogh tilføjede vores seneste opdateringer af robotterne til LDD.

pepe forsøgte at skære ned på opstartstiden ved at gemme fundne bluetooth devices. Det er dog stadig work in progress...

Forløsning

Dokumentationen skal jo laves, omend programmering er sjovere...

Intelligens gjort kunstig

Fremmødte

pepe og rfogh

18/1: 9.30 - 18

19/1: 10 - 18

Formål

Formålet med dagens arbejde var at skrive en bedre computerspiller, samt at styre rammerne omkring spillet: Hvem taber/vinder, hvornår starter vi (samtidigt), og hvordan man starter et nyt spil uden at skulle rekonfigurere robotterne.

Fremgangsmåde

rfogh startede med at bygge en ekstra lyssensor på robotterne, lige bag kofangeren, så robotten har en chance for at reagere inden den "rigtigt" støder ind i muren. Derefter afprøvede han den simple computerspiller, der tidligere var skrevet, som blot drejede tilfældigt hver gang den stødte ind i noget. Derefter blev der eksperimenteret yderligere med andre computerspillere, hvilket er nærmere beskrevet under forsøg.

pepe koncentrerede sig om at forbedre vores Python-program til PC'en. Der blev udformet en simpel protokol til at kommunikere mellem NXT og PC. Meningen er, at alle NXT'er skal forbindes til PC'en, så de alle kan melde ind at de er døde og en vinder kan udpeges.

Forsøg

Forsøgene med computerspillerne mundede ud i følgende:

De tilfældige drej fungerede godt på den måde, at man ikke kan forudsige bevægelserne, andet end at den fortsætter fremad indtil næste mur. På den måde er det svært som modspiller at udregne computerens næste træk. Problemet med denne meget simple computerspiller er dog, at den meget hurtigt kommer til at stå og dreje rundt i et hjørne uden egentligt at komme nogen vegne.

Næste forsøg med en computerspiller gik andre veje. Her prøvede vi at lave en robot, der drejer mod midten af banen, når den støder på en væg. Den drejer altid kun én gang (90 grader), men altid sådan at den søger mod midten af banen. På den måde vil robotten ikke blive ved med at køre ind i et af hjørnerne. Problemet her kan dog være, at robotten i stedet fanger sig selv på midten af banen. Tanken er dog her, at det gerne skulle tage så lang tid, at robotten kan blive den sidste tilbageværende spiller, og dermed vinde. Et andet problem med denne tilgang er, at robottens bevægelser er meget forudsigelige. Hvis en modstander ved, at robotten bruger denne algoritme er det forholdsvist nemt at udregne dens kørsel, og dermed få en taktisk fordel.

En tredje udgave tog igen udgangspunkt i tilfældighed, i en forbedret udgave af den første computerspiller.

Vi startede med en sandsynlighed S på 0,5 for at den drejer til venstre, ellers højre. Hvis den drejer til venstre, tælles S ned med 0,25, og ellers op med 0,25. På den måde kan robotten ikke komme til at dreje en hel omgang om sig selv, men vil manøvrere frem i den fra starten givne retning (ved anvendelse af rigelige mængder statistik).

For at ændre på denne "hovedretning" lader vi robotten dreje i en tilfældig retning engang imellem, uden at tælle på S. Derved får robotten angivet en ny hovedretning, som den så vil følge. På den måde håber vi robotten kan køre banen rundt uden at male sig selv op i et hjørne...

pepe prøvede at få forbindelse til flere NXT'er på en gang. Dette kræver flere Bluetooth-forbindelser på én gang, som vi har valgt at styre med flere tråde, én pr. forbindelse.

Det blev lavet med standard Python-tråde, der fungerer på samme måde som Java-tråde.

Programmet starter med at lave en søgning efter Bluetooth-forbindelser i området, hvorefter man vælger, hvilke der er modstandere, og hvilken der er brugerstyret.

Forløsning

Projektet er nu i version 1.0, da vi sagtens kan aflevere det vi har nu og være stolte af det. Der er selvfølgelig stadig mange ting, der kan forbedres, men spillet er absolut spilbart.

Blandt ønskerne til fremtidige versioner er:

Bedre computerspiller. I første omgang kunne man forsøge at kombinere de to eksisterende spillere, til en robot, der kører tilfældigt, men med større sandsynlighed for at søge mod midten.

Nemmere opsætning, fx. at mere kan styres fra PC'en (ex. valg af om robot er computer- eller menneskestyret, hurtigere søgning efter bluetooth, osv.)

Highscore, fx. baseret på tacho count eller tid. Dermed ville de, der kører længst få bedste scores.

Ombygning af robot, så både lyssensor og pen er placeret så tæt på midten som muligt.

Forstyr ikke mine cirkler

Fremmødte

pepe og rfogh (10 - 17 )

Formål

Formålet med dagen er at rette op på en større mangel på tron biken: der er ikke nogen tush til at lave streger med.

Fremgangsmåde

Rfogh byggede efter nogen diskussion om placeringen en rig til at holde en whiteboard marker af mærket edding 360 fast bag på robotten. Imens gik det op for pepe ved en mini demonstration at robotten "døede" hvis underlaget var hvidt, en fejl i koden idet der var byttet om på om hvidt var en stor værdi eller lille. (Absolut genskin (hvidt) er maksimal værdi)

Pepe gik i gang med at undersøge hvor følsom lyssensoren er for streger.

Rfogh undersøgte rotationen, idet vi forsøger at gøre navigationen så grundlæggende og simpel som mulig, og da vi tidligere har haft dårlige erfaringer med navigatoren der følger med lejos, blev det besluttet at gennemføre forsøg til at bestemme den korrekte rotation for at opnå 90°.

­

Forsøg

Da Kim Steen kom forbi for at se hvad vi havde blev den ene robot sat til at køre rundt på gulvet i Zuse bygningen. Da den kørte ind på det hvide lærred til at følge en linje "døede" den. Dette blev fulgt op af forsøg på banen, der viste at robotten havde det bedst på den sorte linje, da dette er forkert blev det rettet.

Der blev lavet forsøg med at måle den reflekterede intensitet når robotterne kørte over forskellige streger. Dette blev gjort ved at lave flere streger efter hinanden af varierende kvalitet og herefter lade robotten køre hen over stregerne til den dør. Et helt rent whiteboard og en ny tush, enten i sort eller blå virker. Ved forsøg med en ældre tush, skulle der flere streger oven i hinanden til før robotten registrerede at den var kørt over stregen

Det var forholdsvis tydeligt at rotationen ikke var på 90° efter at have forsøgt med tush på. Efter beregninger ud fra de givne resultater blev der tilpasset ud fra empiriske forsøg. Resultatet kan ses i testvideoen og på billederne.

Forløsning

Det er lykkedes os at nå til første mål, nemlig at have to spillerstyrede robotter der kan konkurrere mod hinanden. Placeringen af tushen kunne muligvis have været mere optimal, men den virker og det er muligt for andre robotter at "se" stregen. Rotationen er endnu ikke helt korrekt, det interessante er at det som det kan ses er forskelligt for de to robotter, det er derfor muligt at der skal laves individuelle indstillinger for robotterne.

Hvad var det lige vi lavede igen?

Fremmødte

pepe og rfogh (9:00 - 16:00 )

Formål

Dagens øvelse går ud på at finde ud af hvor langt vi er kommet og følge op på det der er sket, samt udstikke retningslinjer for den fremtidige udvikling efter eksamenerne.

Forløb

Da dette var første arbejdsgang efter nytår og eksamenerne var det nødvendigt at starte med at se om det der er blevet lavet uden hardware også virkede. Det gjorde det naturligvis ikke, men efter lidt smårettelser kom det meste til at virke.

Pepe lagde ud med at sikre at den nye måde at starte python GUIen op på virkede. Det er nu muligt at starte op med enten navn eller adresse eller helt uden noget, hvis der ikke gives nogen indikation af hvad der skal forbindes til scannes området for bluetooth enheder og disse præsenteres for brugeren så denne kan vælge den NXT der skal forbindes til.

I forbindelse med debuggingen af denne funktionalitet blev der frisket op på hvordan koden var opbygget. Her var det især brugbart at kigge på det UML klassediagram der blev lavet mellem jul og nytår og som kan hentes på projektets hjemmeside på google code. (.dia version)

Rfogh  startede med at sikre en ekstra NXT og opbygge en modstander robot. Dette gjorde ham i stand til at forbedre byggevejledningen der ligeledes kan findes på google code(samme sted som ovenstående link)

Efter frokost blev det besluttet at rfogh skulle lægge arbejdet i at gøre det muligt at vælge hvilken NXT man vil forbinde til, da det ikke er muligt at få NXTerne til at forbinde automatisk altid. Samtidig blev det besluttet at pepe gik i gang med at dokumentere dagens arbejde.

Forsøg

Dagens forsøg har hovedsagligt handlet om at få forbindelse til robotterne, så det er muligt at styre dem. Python GUIen blev testet, men sendte ikke idet bluetooth api'et ikke giver meddelelse om hvorvidt forbindelsen var vellykket eller ej. Da denne fejl blev rettet virkede kommunikationen, men robotten starter med at dø, hvorefter et nyt spil kan begynde.

Forsøget med at få forbindelse fra java var baseret på at bruge lejos' scan metode, denne gav lige som de andre forsøg med Java programmerne der følger med lejos kun den første NXT der er blevet forbundet til systemet. Da dette var rfoghs private NXT og denne ikke var til stede i dag, er det ikke lykkedes at lave en java GUI der kan forbinde til en vilkårlig NXT.

Forløsning

Vi er kommet i gang efter ferien og har påbegyndt opbygningen af systemet. Da Python implementeringen af styre programmet virker og Java versionen af samme ikke gør vil vi, med mindre rfogh finder en løsning inden næste gang (i morgen kl.9, planlagt), holde os til Python GUIen.

Den interne konkurrence

Forbrugt tid

Tirsdag d. 29/12 - 2009 fra kl. 9.30 til 17.30

Fremmødte

pepe og rfogh

Formål

Formålet med i dag er at lave en GUI der kan bruges i spillet, og som kan forbinde via bluetooth.

Fremgangsmåde

Pepe havde tidligere lavet et proof of concept program i Python for at vise det var muligt at sende beskeder til nxt bricken fra python.

Rfogh mente det bedste ville være hvis GUIen kunne være i Java, noget pepe ikke var enig i.

Dagen gik derfor med en lille konkurrence: hvilket programmeringssprog er bedst?

Efter en hel del konkurrence hvor pepe først fik forbindelse og data og rfogh først fik piletasterne til at fungere endte vi med to programmer: et i python og et i Java der til forveksling er ens.

synergieffetkten i dette var at programmet på NXT blokken efterhånden fik en ret god struktur, og er ganske gennemtestet.

Protokollen for transmission til klodsen er baseret på enkeltkarakterer og er som følger:

Karakter	Betydning
s	Start
l	Drej til venstre
r	Drej til højre
q	afslut

Denne protokol er tilstrækkelig til at styre biken, men ikke nok til at sende meddelelser om hvorvidt biken er "død" eller "vinder".

Af yderligere synergieffekter kan nævnes at vi nu har et ant script der kompilerer og uploader hele projektet, samt starter Java Guien.

Lego inde - sne ude

Forbrugt tid

Torsdag d. 17/12 - 2009 fra 10 til 13

Fremmødte

pepe og rfogh

Formål

Kom videre med projektet

Forløb

Kodemæssigt blev der tilføjet to nye klasser: WallDetector og Bumper.

Begge klasser bruges til at finde ud af hvornår robotten skal spille død, bumper for at mærke om robotten støder ind i noget, og WallDetector for at se om den er kørt ind over en andens streg.

Sammen med Driver og Player klasserne, danner disse to grundlag for basisrobotten, det der kommer herovenpå er enten en menneske drevet klasse eller en robot drevet klasse.

Konstruktionsmæssigt er robotten blevet udbygget, og blevet dokumenteret i Legos "Lego Digital Designer".

Al begyndelse er svær

Fremmødte

pepe og rfogh

Forbrugt tid

Fredag d. 11/12 fra kl. 9 til 15

Formål

Formålet med dagens arbejde er at få påbegyndt konstruktionen af Lego robotterne, både i hard- og software.

Fremgangsmåde

rfogh anbefalede at vi oprettede et google code projekt, dette har vi således gjort. Det ligger på http://code.google.com/p/tronxt/, dette har den fordel at der er svn, så vi begge kan kode på projektet.

pepe, der jo er ingeniøren gik i gang med at kode og rfogh der jo er datalog gik i gang med at konstruere.

Fremgangsmåden blev valgt til at være en "bottoms up" metode således blev der dannet et grundlag af kode Driver klassen, og et grundlag af robot, spillerens robot.

Det dannede kode kan ses på google code siden og robotten kan ses til demonstrationen.

Forløsning

Robotterne blev påbegyndt og kodegrundlaget blev dannet.

Major Tom to Ground Control

Fremmødte

Paul M. Bendixen (pepe)

Rune L. Fogh (rfogh)

Forbrugt tid

Fredag d. 4 December fra ca. kl. 9 til 16

Formål

Få hul igennem til NXT klodsen, så det er muligt at styre den fra en pc

Forløb

Fremgangsmåden var ca. den samme som dagen før, prøve sig frem og læse diverse tutorials på nettet.

Følgende blev der fundet ud af:

Det er nemt at forbinde NXTen til en mobiltelefon. Pepe aktiverede bluetooth, og initierede Bluetooth forbindelsen fra NXT klodsen, efter indtastning af koden var de to enheder tilsluttede.

Det er muligt at lave en forbindelse mellem to computere og pinge dem ved hjælp af programmet l2ping.

Da man skal bruge adressen til klodsen ret meget kan det være fordelagtigt at gemme den i en variabel, i vores tilfælde export Odin=00:16:53:04:00:1C

Når lejos er sat op bunder det hele i om bluez er sat ordentligt op (idet vi begge bruger linux)

Forsøg

For at få forbindelse blev det forsøgt som før bare at bruge nxj -r -b Program og som før fejlede dette også (se On the nigttrain posten)

I en guide til at få gang i bluetooth kommunikation på gentoo fandtes stort set hele opsætningen. Desværre fejlede det her at få lavet en l2ping til klodsen, i beskrivelsen.

For at få forbindelse mellem enhederne er det nødvendigt at bruge hcitool cc $Odin, dette giver dog desværre også en fejl.

Der er i den førnævnte guide beskrevet at bluez 3.x ikke længere bruger en pin_helper setting, dette er cluet til at få forbindelse.

I en bugreport fandt pepe ud af at den passkey-agent der normalt følger med bluez-util skal installeres seperat (ved hjælp af test-programs flaget i gentoo)

Dette program blev efter installation opstartet og der blev igen forsøgt at oprette forbindelse fra NXTen, dette lykkedes heller ikke, hele validerings proceduren forløb fint, men NXT klodsen gav fejlmeddelesen UNSUCCESFULL når det var afsluttet.

Dog kunne passkey-agent programmet fremvise at den MAC adresse NXT klodsen har, bad om at forbinde.

Efter et kig på /var/log/syslog gik det op for pepe at passkey-agent afmelder sig når det lukkes, derfor må det skulle køre når man forsøger at oprette forbindelse.

Fremgangsmåden er altså:

1. Start bluetooth devicet (/etc/init.d/bluetooth start)
2. start passkey-agenten (passkey-agent --default XXXX hvor XXXX er koden)
3. start forbindelsen med hcitool (hcitool cc $Odin)
4. anvend NXJ programpakken som normalt (nxj -b -d $Odin Program)

For at bekræfte at forbindelsen fungerer som den skal blev sample programmet BTRecieve lagt på NXTen og BTSend blev kørt på computeren.

Dette gav en farligt masse data, hvilket også er formålet. Det er dog stadig ikke lykkedes at få hul igennem ved at bruge nxjbrowse eller nxjcontrol.

Forløsning

For en gangs skyld er forløsning det helt rigtige ord: Vi har fået hul igennem og ved at finde ud af hvordan systemet virker, fået lavet en grundig beskrivelse.

Vi mangler dog stadig at få hul igennem på rfoghs maskine, der har haft problemer med at anvende bluecove biblioteket. Desuden er det endnu ikke lykkedes for rfogh at få hul igennem med de grafiske værktøjer han benytter.

Ground Control to Major Tom

Fremmødte:

Pepe og rfogh

Varighed: 2 timer

Formål:

Vi skal have bluetooth til at virke, så vi kan styre vores NXT fra computeren, mobilen eller lignende.

Fremgangsmåde:

Vi trawler nettet for mulige løsninger, tutorials og eksempelkode, der kan hjælpe os på vej.

Forsøg:

Vi har tidligere brugt rigtig mange forsøg på at få det til at virke, og også denne gang har vi forsøgt meget.

Forløsning:

Der kom ingen forløsning i denne omgang. Vi vender stærkt tilbage i morgen!

The end of time, part one

Tid

Fredag d. 20 /11 2009 2 timer

Torsdag d. 26/11 2009 4 timer

Her

Pepe og Rfogh

Emne

Dagens opgave er at finde ud af hvilket projekt der skal arbejdes med i resten af kurset.

Emneforslag

Lav en robot med en reptilhjerne. Den skal være i stand til at klare sig i et ukendt miljø og finde vej uden om forhindringer. Derudover skal den være udstyret med evnen til at finde ud af om den skal, når den har fundet noget:

1. flygte
   
2. spise det
3. parre sig med det

For at kunne finde rundt i omgivelserne skal der laves afstands sensorer, der skal kunne flyttes så de afgør størrelsen og beskaffenheden af objekterne.

Denne model vil også kunne benytte de subsumption og lignende teknikker vi har arbejdet med tidligere.

Pinball Flipper er sjovt, og lego er sjovt. Udfordringen i dette projekt er at lave nok sensorer til at det bliver sjovt, hertil kunne man bruge en I2C til parallelport kreds, på denne måde kan der skaffes 7x8 ekstra tryksensorer, nogle af disse kunne eventuelt bruges til  bumpers. 

Tron I 1982 udgav Disney en film om en programmør der bliver suget ind i en computer og skal kæmpe mod det onde "master control program", en af de mest berømte dele af filmen er lightcycle ræsene. Formålet med dette projekt er at lave to typer robotter, en spiller og en (eller flere) modstandere. Lightcyclerne kører rundt på et underlag der kan tegnes på og trækker en sort (eller anden farvet) tushpen efter sig. Hvis en lightcycle krydser en streg går de i stykker (står stille) Det er kun muligt at bevæge sig i 90 graders vinkler, robotterne skal derfor være med lavt tyngdepunkt og bygget til at dreje skarpt på stedet.

Nomineringen

Ud fra et ønske om at projektet skal være sjovt både for os og andre og lærerigt har vi valgt at arbejde videre på Tron.