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!

Panik før lukketid

Fremmødte

Pepe og Rfogh

Forbrugt tid

Påbegyndt kl. 12 afsluttet 14:48 -- 2 timer 3 kvarter.

Formål

Formålet med denne øvelse er at afprøve Arbitrator klassen for at udforske betinget adfærd.

Forventet Fremgangsmåde

Følgende spørgsmål er blevet stillet i opgaven:

• Press the touch sensor and keep it pressed. What happens ? Explain.
• Both DriveForward and DetectWall have a method takeControl that are called in the Arbitrator. Investigate the source code for the Arbitrator and figure out if takeControl of DriveForward is called when the triggering condition of DetectWall is true.
• Implement a third behavior, Exit. This behavior should react to the ESCAPE button and call System.Exit(0) if ESCAPE is pressed. Exit should be the highest priority behavior. Try to press ESCAPE both when DriveForward is active and when DetectWall is active. Is the Exit behavior activated immediately ?
• What if the parameter to Sound.pause(20) is changed to 2000 ? Explain. 
  To avoid the pause in the takeControl method of DetectWall a local thread in DetectWall could be implemented that sample the ultrasonic sensor every 20 msec and stores the result in a variable distance accessible to takeControl. Try that. For some behaviors the triggering condition depends on sensors sampled with a constant sample interval. E.g. a behavior that remembers sensor readings e.g. to sum a running average. Therefore, it might be a good idea to have a local thread to do the continous sampling. 
  
• Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning.
• Try to implement the behavior DetectWall so it can be interrupted and started again e.g. if the touch sensor is pressed again while turning.
  

Forsøg

Første forsøg, at få lagt bumperCar programmet i NXTen virkede fint, da vi benyttede Tribot modellen fra sidst var touch- og afstands sensoren allerede monteret, dog skulle portene rettes.

Når bilen kører frit kører den ret fremad. Når bumperen rammer noget bakker bilen ca. 5 cm og drejer omkring 30 grader mod venstre for at finde et frit område.

Hvis bumperen holdes trykket, gentages proceduren indtil trykket lettes.

 Det står at læse ud fra JavaDoc'en (fundet i koden) at takeControl ikke bliver kaldt med mindre der ikke er andre der er aktive (herunder også detectWall)

For at implementere exit metoden blev en klasse Exit tilføjet der implements Behavior hvor det eneste interessante er at takeControl kontrollerer ESCAPE for tryk og har action(){System.exit(0);}

Da DetectWall bruger blokerende kald er det nødvendigt at vente til den er færdig før det er muligt at få den ønskede funktionalitet ud af ESCAPE trykket.

Sound.pause() venter det givne antal millisekunder før der sker noget nyt. Da dette også er en blokkerende handling ødelægger en forøgelse fra 20 til 2000 indtrykket af realtid. Pausen gør at der opstår standsninger mellem alle bevægelser robotten gør og gør robotten ude af stand til at detektere vægge den skulle være kørt ind i.

For at gøre det muligt at afbryde også når der bakkes, er bakke kaldene blevet lavet med et ikke blokkerende kald, og _suppress variablen læses og vurderes sammen med hjulenes bevægelse om handlingen skal afbrydes.

Der er implementeret en tråd i DetectWall til at måle afstanden. Denne skrives ud til en variabel i DetectWall klassen. Denne læses også i takeControl funktionen, og hvis den er under 25 undviges der.

Rent trådsikkerhedsmæssigt er dette også forsvarligt, da det kun er en enkelt variabel der ændres vil takeControl enten læse den nye eller den gamle værdi.

Bevægelsen baglæns blev implementeret ved at øge den afstand de enkelte hjul i forvejen kører. Ved at forøge begge med samme værdi kører tribotten bagud i længere tid inden den drejer.

Forløsning

Arbitrator klassen åbner op for betinget adfærd, dog ikke i større grad end det subsumption vi tidligere har behandlet. 

Den største forskel i de to er måden det kodes op på. Begge bruger tråde og begge kan afbryde "laverestående" tråde. 

Hvis vi havde mere tid kunne forskellen dog have været implementeret idet det er muligt med arbitratoren at lade de enkelte tråde returnere værdier i stedet for sandt eller falsk.

Det at der er en arbiter giver mulighed for at prioritere efter motivation frem for efter prioritet, en mulighed der ikke er til stede i den tidligere model, hvor hvad der sker kun afgøres af mere eller mindre frivillig afgivelse af kontrollen til en anden der er højere eller lavere i hierarkiet.

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.

Fremmødte

rfogh og pepe. Varighed 3 timer.

Formål

Formålet med dagens øvelser er at undersøge en robots mulighed for map-building og muligheden for at give en robot et overordnet retningsmål, men samtidig bevare egenskaber som at undgå påkørsler osv.

Forløb

Vi byggede en udvidet udgave af TriBot - standard-robotten fra LEGO. Vi vurderede at denne robot ville være god til øvelserne, da meget af vægten ligger på de to kørehjul og der derfor burde være mindre slack i forbindelse med hjulspin under igangsætning og drejning. Denne robot blev brugt til alle vores forsøg.

Efter at have udført forsøg med TriBot som beskrevet nedenfor, erstattede vi ultralydssensoren med en kompassensor og udførte forsøg med at navigere efter kompas.

Forsøg

Første forsøg var at implementere det fra kapitel 12 udleverede kode, dette gik dog ikke helt efter forskriften.

Der viste sig at være problemer med at dreje, for at klarlægge hvordan blev et mere stiliseret forsøg opstillet:

Robotten skal ud fra tachocounteren finde frem til [X,Y] punkterne [0,0], [0,100],[100,100],[100,0] og [0,0].

Den ønskede og faktiske rute kan ses i figuren.

Som det ses, fulgte robotten ikke den ønskede rute. Den første halvdel af ruten var korrekt, men efter et kort holdt i (100,100) fortsatte robotten i samme retning i stedet for at dreje. Den kørte 100cm mere, drejede 90grader og kørte 200cm, hvorefter den mente at være i (0,0).

Det tyder altså meget på, at der er fejl i SimpleNavigator-klassen og ikke i vores brug af den.

Vi undersøgte det yderligere ved at lade robotten følge en bane, der blev kodet som vist på dette billede:

Robotten kørte dog som vist på videoen:

Som man kan se, er det meget svært at gætte, at det er den ønskede sti, der følges...

Efter på det nærmeste at have opgivet SimpleNavigator prøvede vi i stedet for TachoPilot at bruge CompassPilot efter samme otte-kantede rute som beskrevet ovenfor.

Igen ses det, at ruterne er næsten ens, men dog overhovedet ikke som vi har forestillet os det.

Forløsning

Det er svært at konkludere noget på disse to forsøg, da det ser ud som om SimpleNavigator er fejlbehæftet, eller vi bruger klassen forkert. Da dokumentationen er meget mangelfuld er det svært at afgøre, hvilken en af delene der er tilfældet. Vi kan dog konstatere, at robotten fx. kørte ligeud på tidspunkter, hvor den burde dreje, så det er ikke blot et spørgsmål om tilretning af konstanter.

Darwin i en datamat

Fremmødte

Pepe og rfogh, 3 timer

Formål

Formålet med dagens øvelsesgang er at påbegynde en robot der kan bygges kompetencer ovenpå. Robotten skal kunne finde rundt på gulvet i Zuse bygningen, holde sig væk fra at støde ind i ting og spille en lille melodi med jævne mellemrum.

Robottens miljø er egentlig dynamisk, idet der også er andre studerende og robotter i lokalet, men i praksis er det ret statisk idet hverken dataloger eller ingeniører flytter sig ret meget.

Forløb

For at finde ud af hvordan systemet fungerer blev den udleverede kode kompileret og uploadet.

Da vores robot var lavet med "omvendte" motorer blev det nødvendigt at ændre på måden Car klassen virker.

Robotten består af to lys sensorer, en afstandssensor, og en lydsensor, der er to motorer som er eneste tilføjede aktuatorer. Der er selvfølgelig den indbyggede højttaler der anvendes til at spille melodien.

Efter afprøvningen af den udleverede kode (og rettelse så den passer til robotten) blev der implementeret en FollowLight klasse. Denne klasse bygger på Behavior og sender robotten i en bestemt retning hvis der er mere lys i en retning end i en anden indenfor en tærskelværdi.

Prioriteringen af trådene blev:

1. Random Walk
   
2. Follow light
3. Avoid Front
4. Play Sound

Grunden til at follow light ligger lavere end Avoid Front, er at det er vigtigere for den at lade være med at støde ind i ting, desuden er det at følge lyset fornuftigt på et højere plan end bare at rende tilfældigt rundt, og der er endnu mere fornuft i at lade være med at støde ind i ting.

Forsøg

Forsøgene der er gjort med den oprindelige kode begrænsede sig til at få den til at køre den rigtige vej, og eksperimentere med hvor tæt den skulle på genstande for at begynde at bakke.

Eksperimenterne med den lys følgende kode viste at en tærskel værdi på 5 (en forskel i procent på 5) var god til at lave en afbalancering mellem at finde lyset og lade random walk stadig være en del af dens funktion.

Eksperimentet stillede et meget filosofisk spørgsmål: Hvad gør en robot når den har fundet og opnået sin mening med livet?

I vores tilfælde viste det sig at svaret var at synge en lille sang og danse lidt.

Når der findes lys nærmer den sig denne kilde, indtil der er lige meget lys på begge sider. Når der er lige meget lys på begge sider vælger robotten en tilfældig retning at bevæge sig i, hvis der bliver stor forskel mellem værdierne på lyssensoren rettes der op og hvis den kommer for tæt på noget afviges der.

Når robotten rammer døren i Zuse bygningen har den opnået det den er lavet til: Find lyset uden at støde ind i noget. Derfor kører den frem mod lyset til den kommer for tæt på døren hvor den flytter sig fra, hvilket gør den kommer for langt fra døren/lyset. Dette ligner en lille dans, hvilket forstærkes af den lyd den spiller, der kunne minde om en sang.

Forløsning

Behavior modellen gør det nemt at programmere nxt'en med en måde at opføre sig.

Som det muligvis er bemærket bliver robotten meget mere beskrevet ud fra psykologiske termer, idet det nu er muligt at beskrive mål og "ønsker" for robotten.