Projektaktivitet 3

Projektaktivitet 3

Dato: 17. december 2009
Varighed: 7 timer
Deltagere: Annette, Rasmus og Samuel

Mål

GyroSensorkoden er klar til at blive brugt i forbindelse med at robotten skal holdes oprejst, så der skal laves et projekt hvor der kan reguleres ud fra værdier fra GyroSensorkoden. Dette skal efterfølgende kombinereres med bluetoothkoden, hvor regulering og bluetooth hver bliver en selvstændig tråd. Arbejdet med at få robotten til at balancere påbegyndes muligvis.

Baggrundsinfo
PID er et lukket sløjfe reguleringssystem. PID controlleren beregner en fejlværdi mellem den målte værdi (procesvariablen) og en ønsket værdi (set point) og ud fra det prøver den at regulere. Se yderligere om PID regulering her: PID regulering.

Fremgangsmåde

Segway med gyrosensorkoden

Udgangspunktet for at få robotten til at balancere bliver klassen Segway fra øvelse 4 [3.1]. Segway er den klasse som håndterer selve PID reguleringen. Den blev brugt i forsøg på at få robotten til at balancere vha. lyssensorer, så den skrives om til at bruge GyroSensor klassen i stedet for.

Segway klassen arver fra Thread Klassen og i constructoren til Segway oprettes en instans af GyroSensor klassen. En anden metode i Segway er getBalancePos() som sørger for at kalibrere offset ved at kalde calibrateOffset() metoden på GyroSensor. Efterfølgende aflæses setPoint vinklen som er udgangspunkt for reguleringen af robotten. run() metoden indeholder koden til reguleringen, som vil være på baggrund af værdier fra GyroSensor klassens getAngle() metode.

Reguleringen vil blive beskrevet senere. Derudover består projektet af DataLogger klassen så vi har mulighed for at analysere opsamlet data under arbejdet med PID kontrollen. Testen udføres fra BalanceTest klassen.

Bluetoothdelen

SegWayPCGUI klassen, viser et grafisk interface på PC'en, hvor der kan skrives værdier ind for P, I og D, som kan sendes individuelt. Den opretter forbindelse til NXT enhedens BluetoothThread klasse (som skal være startet først). Værdierne der bliver sendt fra PC'en er 4 cifrede, så der laves en omregning i BluetoothThread klassen, der kan indstilles individuelt for P, I eller D, alt efter hvor store eller små tal der skal bruges.

Når der modtages en værdi i BluetoothThread, kalder den den passende set-metode i SegWay klassen, så værdierne kan bruges. Værdierne starter alle på 0, når enheden startes. Kraften til motoren i SegWay, er normaliseret mellem 55 og 100, hvilket vil sige at den bevæger sig selvom P, I og D er 0. Derfor sættes en if sætning ind, der sætter motor power til 0, hvis P er 0. Så begynder robotten først at køre, når den får en P værdi tilsendt.

Resultater

Segway med gyrosensorkoden

Det har ikke voldt problemer at implementere PID reguleringskoden fra øvelse 4 i en test med vores egen GyroSensor klasse og DataLogger klassen.

Bluetooth delen

Arbejdet med undersøgelserne af gyroskopet er foregået vha. USB kablet på en anden NXTenhed end den der er brugt til arbejdet med Bluetooth kommunikationen. Det viser sig nu at der er problemer med Bluetooth kommunikationen på NXT’en hvor gyroskopet er blevet undersøgt, så vi har besluttet at bruge den, hvor vi ved Bluetooth virker.

Her viser det sig dog at der sker noget interessant med driften, for den er her langt mindre selvom vi kun skifter NXT og ikke selve sensoren. En anden ting der også undrer os er at offset er ændret fra før 596 til nu ca. 591. Så vidt vi har kunnet forstå skyldes drift hardwaren i selve sensoren, men denne opdagelse tyder på at også hardwaren i NXT'en har indflydelse.

Vi har ikke tid til at undersøge dette nærmere, men vi har en formodning om at det kan være A/D konverteren eller måske batteriniveauet der spiller ind.

Den samlede kode med GyroSensor, regulering og Bluetooth kan ses i [3.2] Samlet kode.

Konklusion

Samlingen af koden er gået fint, så vi er nu klar til at finde værdier for PID reguleringen. Bluetooth kommunikationen er implementeret så vi kan sende værdier til robotten. Det gør det nemmere fordi vi så ikke skal ændre i koden, compile og downloade til robotten, hver gang vi ændrer en af P, I, D værdierne.

Vores oplevelse med at det har betydning hvilken NXT der bruges og ikke kun hvilken sensor der bruges undrer os stadigvæk, men vi har valgt at lade det ligge.

I næste projektaktivitet skal interfacet på PC'en bruges til at tune PID konstanterne.

Referencer
[3.1] Øvelse 4: Øvelse 4.
[3.2] Samlet kode: Endelig-Kode

PID regulering

PID Algoritmen og Lukket-sløjfe-styring

Lukket-sløjfe-styring og feedback

Lukket-sløjfe-styring eller automatisk styring, er en kontrol teknik som er baseret på såkaldt negativ tilbagekobling ( feedback).

Et velkendt eksempel på ukontrolleret, positiv feedback findes hos elektronisk udstyr, der kan begynde at hyle. Det sker i højttalersystemet, hvis lyden fra højttaleren når mikrofonen, hvor den bliver forstærket af systemet og returnerer dertil med endnu større styrke. Ved et enkelt gennemløb af sløjfen er denne virkning ikke til at høre, men den bliver alvorlig, når signalet passerer gennem systemet igen og igen.

Lukket-sløjfe-styring består grundlæggende af 3 elementer, Controller, system (plant) og Sensor, som konstant prøver at give et ønsket system output ud fra en givet reference.

Figur 1

Sensoren måler system output (også kaldet procesvariablen) og fejlen (Measured error) beregnes ved at trække den målte værdi fra referencen (negativ feedback). Controlleren beregner så et nyt system output som sendes til systemet, som så reagerer på det og loopet begynder forfra.


PID regulering
I vores projekt bruger vi en PID (proportional–integral–derivative) regulerings algoritme til at styre vores lukkede sløjfe, dvs. som controller (se figur 1). PID regulering er en form for kontrolalgoritme der er meget udbredt inden for industrien og som benyttes lukket-sløjfe-styringer. PID-algoritmen er baseret på 3 parametre, proportional (Kp), integral (Ki) og differential (Kd).

Figur 2

PID algoritmen ser ud som vist på figur 2. I forhold til figur 1 svarer "input" til "system input" og "error" til "measured error".

Projektaktivitet 2

Projektaktivitet 2

Dato: 11. december 2009
Varighed: 7 timer
Deltagere: Annette, Rasmus og Samuel

Mål

Færdiggøre undersøgelser af gyroskopet og lave et grafisk program til PC'en, der kan sende parametre til NXT enheden løbende over Bluetooth.

Fremgangsmåde
GUI program til Bluetooth kommunikation.
Da problemerne med kommunikation mellem PC og NXT blev løst i sidste projektaktivitet, er det nu kun nødvendigt at bestemme formatet af kommunikationen og lave den grafiske brugergrænseflade.

Undersøgelse af gyroskop
Gyrosensor
Til undersøgelserne af gyroskopet laves et LeJOS NXJ projekt som indeholder tre klasser, en testklasse, en GyroSensor klasse og en DataLogger klasse. Testklassen varierer afhængigt af om vi ønsker at læse fx vinkelhastighed eller vinkel, DataLogger klassen er skrevet af Ole Caprani, og opretter en .txt fil, hvortil man kan skrive integers.

GyroSensor klassen
Lejos har en GyroSensor klasse under lejos.nxt.addon som i constructoren tilknytter en medsendt port til sensoren, og i hvilken mode den skal fungere. Når sensoren holdes fast i en stilling returnerer den værdier der i vores tilfælde ligger på omkring 596, det er sensorens offset og kan sættes i GyroSensor klassen.
readValue() metoden i GyroSensor klassen læser den rå værdi fra porten (A/D converteren) med ADSensorport.readRawValue() metoden og som tidligere beskrevet returneres en værdi fra sensoren der svarer til grader/sekund. I readValue() metoden fratrækkes offset værdien så vinklen har nul som udgangspunkt.

getAngle metoden
Det er dog ikke vinkelhastigheden vi har brug for til vores projekt hvor robotten selv skal kunne balancere. Her har vi brug for en angivelse af position i stedet for. Derfor må vi tilføje en metode getAngle() der returnerer vinklen beregnet ud fra vinkelhastigheden. Beregningen udføres som vist i Figur 2.1.

Figur 2.1

Implementationen er som vist i Figur 2.2. Det er nødvendigt at kende tiden, så derfor kaldes metoden System.currentTimeMillis() som returnerer tiden i millisekunder siden NXT'en blev startet. Derefter beregnes dt som er den nye tid minus den gamle og efterfølgende beregnes den nuværende vinkel ud fra den gamle vinkel, sensorværdien og dt.

Figur 2.2

Nu er vi klar til at lave nogle forskellige undersøgelser, som først vil dreje sig om at finde ud af hvordan sensoren måler vinklen, og efterfølgende vil det dreje sig om drift, som vi ved er et problem med sensoren.

Undersøgelse 1: Vinkel
Den første undersøgelse skal vise om sensoren fungerer, som beskrevet af HiTechnic og om den tilføjede metode getAngle() returnerer vinklen som den skal. Det gælder altså her om at få en fornemmelse af hvordan sensoren fungerer. Offset angives i koden til at være 596.

Undersøgelse 2: Vinkelhastighed
Vinkelhastigheden undersøges, ved at bruge GyroSensor klassen med offset sat til 0. Sensoren fastgøres i en opstilling som vist på Figur 2.3 så den ikke bevæger sig. Værdierne fra sensoren burde så være stabile, men vil sandsynligvis stå at skifte lidt (drift).

Figur 2.3

Værdierne fra sensoren opsamles i en datafil der efterfølgende overføres til en PC og undersøges i Mathcad.


Undersøgelse 3: Vinkel
For at undersøge vinklen sættes offset til 596 da det er ca. der NXT’ens offset ligger. Det er den samme opstilling der bruges for at holde sensoren stille. Her bruges vores egen getAngle() metode til at returnere vinklen og igen burde værdierne være stabile fordi sensoren ikke bevæger sig. Værdierne opsamles også her i en datafil der undersøges i Mathcad.


Undersøgelse 4: Kompensation for drift
Da det ikke er et dyrt gyroskop må vi forvente at der kan forekomme drift. Det kommer til udtryk ved at der returneres en vinkelhastighed fra A/D konverteren selvom sensoren ikke bevæger sig. Offset ændrer sig altså en smule, som vi også så i undersøgelse 2. For at finde et nøjagtigt offset har vi derfor lavet en kalibreringsmetode, i klassen gyroSensor, som kaldes for at kalibrere offset. Metoden kalder readRawValue() metoden et antal gange og tager et gennemsnit af det antal samples den tager. For at få et mere nøjagtigt resultat bruger vi double-præcision.

Beregningen af offsettet sker ved at vi tager 50000 samples og tager gennemsnittet af disse samples. Dette gøres reelt to gange i træk.

Til at finde ud af om kompensationen har den ønskede virkning bruges den samme opstilling som i de to foregående undersøgelser. Ved hjælp af getAngle() metoden hentes værdier for vinklen som skrives til en datafil. Forventningen er så at driften vil være stærkt reduceret i forhold til de tidligere målinger.

Resultater

GUI program til Bluetooth kommunikation.
Overførsel af data:
Kommunikationen mellem PC og bluetooth enhed, foregår ved at der bliver sendt en stream af data. Der kan sendes bytes, Integers, Chars og andre typer, men der kan kun læses én ad gangen hos modtageren. Samtidig kan der kun sendes via én stream ad gangen, så alt data skal overføres via denne ene stream.
Da der skal sendes 3 forskellige parametre på vilkårlige tidspunkter, skal det besluttes hvordan disse data skal sendes og opfattes. Værdierne der skal modtages, skal i sidste ende være doubles, altså kommatal, som NXT'en bruger som parametre i sin PID kontrol. Der kan ikke sendes doubles over streamen, da der kun kan læses "enkelte tegn" i den anden ende.

For at kunne kende forskel på de forskellige parametre der sendes, sendes data som chars. Hvis der skal sendes en P parameter, sendes der et lille p, efterfulgt af de tal der er parametren: "p001". Dette betyder at der sendes 4 chars, for at få et tal på 3 tegn.

For at forstå de tegn der sendes over streamen, skal modtageren laves rigtigt. Da der i et tidligere SegWay projekt blev brugt PID regulering, med double værdier, bruges denne type også her. I det tidligere projekt, havde parametrene 2 decimaler, hvilket er grunden til at der i dette program sendes 3 chars.
Når Nxt programmet modtager de 4 chars fra PC programmet, tjekker den det første tegn og ser om det er et p, i eller d. Hvis ikke det er en af de tre, prøver den det næste tegn.
Hvis det er et af de tre tegn, sætter den de næste 3 chars i streamen, sammen til en string. Denne string bliver omfortolket til en integer. Denne integer bliver så lavet om til en double, og kommaet rykkes 2 pladser til venstre. For eksempel bliver strengen 001 til tallet 1 og strengen 101 til tallet 101. Derefter ganges dette tal med 0.01, så det i stedet bliver til et kommatal som følgende eksempler: (String - Int - Double)
(001 - 1 - 0.01), (101 - 101 - 1.01) og (021 - 21- 0.21).
Fordi der tjekkes på om det første tegn er p, i eller d, gemmes dette tal i den respektive variabel, som programmet så bruger til PID regulering.

Den grafiske brugergrænseflade:
Interfacet der skal bruges til at sende PID parametrene til NXT'en er ikke særligt kompleks. Der er 3 knapper, med tilsværende tekstfelter hvori tallene der skal sendes, skrives ind. Der laves også et større tekstområde, hvor der udskrives feedback på, om der sker fejl og om parametrene faktisk bliver sendt.


Den grafiske del er lavet ud fra et simpelt eksempel om JButtons i java, som er tilpasset til ovenstående formål. Derefter bliver der oprettet en instans af det program der står for kommunikationen med bluetooth enheden, "BTconnector" (som er indeholdt i samme fil). Hver gang der trykkes på en knap, tager programmet strengen i det tilhørende tekstfelt (og sætter hhv. p, i eller d foran) og sender videre til BTconnectoren. Derefter sendes strengen over den oprettede bluetooth forbindelse, som BTconnector sørger for at oprette.

Undersøgelse af gyroskop
Undersøgelse 1: Vinkel
Når sensoren holdes i en fast lodret position returneres en vinkel på 0 grader og når den vippes med uret returneres en positiv værdi for vinklen og mod uret en negativ værdi for vinklen. Selve udlæsningerne af vinklen ser også ud til at passe godt med det forventede, hvis udgangspunktet er at sensoren er i lodret position og den bliver roteret med uret til vandret position (efter øjemål) udlæses en værdi på 45 grader. Hvis man roterer videre med uret til lodret på hovedet udlæses 90 grader. Tilsvarende ser udlæsningerne ud til at passe hvis den roteres mod uret


Undersøgelse 2: Vinkelhastighed
Der er opsamlet værdier for vinkelhastigheden for sensoren når den er stationær og værdierne er plottet ind i grafer der kan ses i [2.1]. Der er lavet målinger over tre gange og de viser alle at vinkelhastigheden varierer mellem 694 og 696 og ved enkelte målinger helt ned til 593 og op til 598. Målingerne viser altså at der returneres en vinkelhastighed selvom sensoren er fikseret og derfor ikke bevæger sig. Testkoden kan ses under [2.2] VelocityDriftTest projektet.


Undersøgelse 3: Vinkel
Der er opsamlet værdier for vinklen af sensoren når sensoren er stationær og værdierne er plottet ind i grafer i [2.1]. Også her er der lavet målinger tre gange og de viser at ved et offset på 296, sker driften i negativ retning. Det er varierende hvor hurtigt det går, men det er en ret voldsom drift. Testkoden kan ses under [2.3] AngleDriftTest projektet.

Undersøgelse 4: Kompensation for drift
Der er lavet tre målinger på vinklen når der kompenseres for drift, en grafisk fremstilling kan ses i Mathcad dokumentet i [2.1]. Med offset kalibreret til 596.032426458401 fås en negativ drift, på to grader i løbet af lidt mere end 20000 samples hvilket er en stor forbedring hvis man sammenligner med målingerne hvor der ikke kompenseres.
Med offset kalibreret til 595.99829648078 fås en positiv drift på to grader i løbet af lidt mindre end 20000 samples. Den sidste kalibrering er på 595.976274831896 og giver en positiv drift på seks grader i løbet af lidt mindre end 20000 samples, men det er også en noget lavere offset værdi så det er forventet. Det rigtige offset må ligge mellem 596.032426458401 og 595.99829648078, da det ene giver negativ drift og det andet giver positiv drift. Testkoden kan ses under [2.4] DriftCompensation projektet.

Konklusion

Undersøgelserne af gyroskopet er afsluttet. Der er ret voldsom drift, men der kan kompenseres for det i en sådan grad, at vi håber at det ikke bliver et problem i det videre arbejde.

Vi synes vi har et godt udgangspunkt til at få robotten til at balancere nu hvor vi kan beregne en vinkel ud fra den målte vinkelhastighed fra sensoren og vi kan sende værdier vha. Bluetooth mellem en PC og NXT'en.

I projektaktivitet 3 skal GyroSensor klassen og bluetooth klassen kombineres i et program og vi begynder muligvis at kigge på PID reguleringen.

Referencer
Java eksempel GUI er bygget over: ButtonDemo.java
BTconnector uden GUI: BTconnector.java
Samlet GUI program: SegWayPcGUI.java (Indeholder også BTconnector)
BT klient program på Nxt: BluetoothUnit.java
[2.1] Drift Test: Drift.pdf
[2.2] VelocityDrift projektet: VelocityDrift.rar
[2.3] AngleDrift projektet: AngleDrift.rar
[2.4] DriftCompensation projektet: DriftCompensation.rar

Projektaktivitet 1

Projektaktivitet 1

Dato: 4. december 2009
Varighed: 7 timer
Deltagere: Annette, Rasmus og Samuel

Mål
At undersøge gyroskopet og få bluetooth kommunikation til at fungere mellem PC og NXT.


Fremgangsmåde

Bluetooth kommunikationen
En af de første ting der skulle laves i projektet, var at få kommunikation mellem PC og NXT til at virke. Det skal bruges i flere sammenhænge, blandt andet til at opdatere parametre til PID regulering løbende. Derfor blev der afprøvet programmer fra tidligere studerendes projekter.

Undersøgelse af gyroskop
Med baggrund i materialet fra NXT om gyrosensoren laves undersøgelser af hvordan den fungerer. Dette indebærer blandt andet:

• Hvilke værdier fås fra porten?
• Hvor stor er nøjagtigheden?
• Drift.
• Hvordan skal softwaren tilpasses?

Resultater

Bluetooth kommunikationen
Problemer

Compile: Det første problem var at finde ud af hvordan programmerne skulle compiles. Modtagerprogrammet der skulle kører på NXT’en gav sig selv, da det bare skulle køre som normalt. Programmet på PC’en var der dog tvivl om.
Efter at have søgt på nettet og set hvad andre tidligere grupper havde gjort, var konklusionen at den skulle compiles som et almindelig java program, dog med en classpath til pccomm.jar filen i lejos mappen.
Dette virkede dog ikke, da compileren stadigvæk ikke kunne forstå syntaksen for bluetooth kommunikation i javafilen. Flere søgninger på nettet viste andre jar filer der skulle med, og i stedet for at skrive dem hver gang noget skulle compiles, blev de skrevet ind i miljøvariablerne i windows:

CLASSPATH
C:\Program Files\leJOS NXJ\pccomms\lib\pccomm.jar;C:\Program Files\leJOS NXJ\pccomms\3rdparty\libbluecove.jar; bluecove-gpl.jar

Dette gjorde at filen blev compilet uden fejl, men det viste sig senere at det ikke var en permanent løsning. (Se Kørsel på PC nedenfor).

Kørsel på PC: Efter det var lykkedes at få compilet filerne rigtigt, var næste problem at få kørt PC programmet. Da PC filen skulle compiles som et normal java program (Compile delen), var det også logisk at den skulle køres på denne måde. Problemet var dog, at der kom en ”noClassDefFoundError”, der sagde at filen ikke blev fundet.

C:\Program Files\leJOS NXJ\pcsamples\BTSend>java BTSend
Exception in thread "main" java.lang.NoClassDefFoundError: BTSend
Caused by: java.lang.ClassNotFoundException: BTSend
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Could not find the main class: BTSend. Program will exit.

Dette blev løst ved at tilføje stien til den mappe hvor filen lå, til classpathen:
java -classpath "C:\Program Files\leJOS NXJ\pcsamples\BTSend" BTSend

Dette løste problemet, og programmet udskrev den første linje som den skulle, inden den gik i gang med Bluetooth forbindelsen. Her kom den næste fejl dog:

C:\Program Files\leJOS NXJ\pcsamples\BTSend>java -classpath "C:\Program Files\le
JOS NXJ\pcsamples\BTSend" BTSend
Exception in thread "main" java.lang.NoClassDefFoundError: lejos/pc/comm/NXTConnector at BTSend.main(BTSend.java:27)
Caused by: java.lang.ClassNotFoundException: lejos.pc.comm.NXTConnector
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 1 more

Dette blev efterfulgt af en lang serie af søgninger på nettet, som ikke umiddelbart gav resultat. Dog var der nogle der benyttede kommandoerne nxjpcc til at compile de programmer der skulle bruges på PC’en med, og nxjpc til at køre dem. Hvis man bruger windows, kommer disse kommandoer fra to .bat filer som ligger i leJOS NXJ\bin. Disse filer følger ikke med i lejos 0.8, som vi bruger eller tidligere versioner, men i 8.5. Disse filer blev hentet ind og afprøvet.
Nxjpcc virkede fint og compilede, men der kom stadig fejl efter nxjpc. Da disse bat filer selv opsætter classpath og andet der skal bruges, var det ikke længere nødvendigt selv at have defineret classpath. Den classpath der var blevet sat under computerens miljøvariabler, blev slettet, da der var mistanke om at den var skyld i fejlen. Ganske rigtigt. Da miljøvariablen CLASSPATH blev slettet, og kommandoen nxjpc BTSend blev kørt, kom følgende output:

C:\Program Files\leJOS NXJ\pcsamples\BTSend>nxjpc BTSend
BlueCove version 2.1.0 on winsock
Failed to connect to any NXT *
BlueCove stack shutdown completed

* Det skal bemærkes, at der ikke var nogle enheder at forbinde til, så det var helt rigtigt at den ikke kunne få forbindelse.

Konklusion - ”Det gode råd”
Hvis andre windowsbrugere har problemer med at compile og køre Bluetooth programmer til kommunikation mellem PC og NXT, er der en simpel løsning til Lejos 0.8 og tidligere:
Lad være med selv at sætte classpaths!

Hvis der benyttes Lejos 8.0 eller ældre, mangler der kun 2 filer, nxjpcc.bat og nxjc.bat, som skal ligge under …\leJOS NXJ\bin.
Når disse filer er lagt ind, lukkes alle cmd vinduer der skal benytte filerne (ellers er det ikke sikkert at de finder filerne) og de åbnes igen.
Derefter bruges kommandoen nxjpcc til at compile PC filerne, og nxjpc til at køre dem.

Undersøgelse af gyrosensoren

Der skal udføres videre undersøgelser af gyrosensoren, så det hele vil blive beskrevet samlet i projektaktivitet 2.

Konklusion
Efter stort besvær kom bluetooth kommunikationen mellem PC og NXT til at virke. I næste projektaktivitet skal det gøres færdigt med et interface og der skal laves en protokol til at sende dataværdierne. De første undersøgelser af gyrosensoren blev også påbegyndt og vil fortsætte i projektaktivitet 2.

Referencer
Download af nxjpcc og nxjpc filerne: Nxj-pc-compile.rar
Kildekode til Bluetooth Sample fra Lejos: BTSend
Tidligere studerendes projekt: Marvin

Øvelse 11

End course project

Dato: 3. december 2009
Varighed: 4 timer
Deltagere: Annette, Rasmus og Samuel

Mål
At beskrive forskellige end course projects vi synes kunne være interessante og vælge det vi har lyst til at lave.

Plan
Vi vil starte med at kigge på listen over forslag til projekter og tilføje vores egne forslag. Efterfølgende vælger vi de mest interessante ud som vi diskuterer og overvejer forskellige løsningsmodeller til i gruppen. Når vi har nogle gode udgangspunkter vil vi tage en snak med Ole Caprani og derefter vælge ud fra den feed back vi får.


Projektoplæg/valg

Segway på Alishan Train Track

Formål:
Formålet med projektet er at bygge en robot der balancerer på to hjul. Den skal kunne køre op og ned ad Alishan train track banen som vi brugte i lektion 6 til robot race. Dette indebærer først og fremmest at få den til balancere – både når den står på et vandret underlag, men også når den skal køre op og ned ad bakke. Desuden skal vælges en metode for at få den til at blive på banen og den skal kunne dreje og vende.

Problemstillinger:
- At få robotten til at balancere - både på vandret underlag og på skråt underlag. Her er der mulighed for at bruge fx gyroskop eller tiltmåler.
- Navigation på banen. Her er der mulighed for fx at bruge lyssensorer, kompas eller tachocounter.

Hardware:
- NXT
- 2 motorer
- Gyroskop
- Tiltmåler
- Lyssensorer
- Kompas
- Tachocounter (i motor)

First LEGO league

Formål:
Formålet med dette projekt er at gennemføre First LEGO Legue banen for 2009 med 400 points hvilket svare til maksimum point. Desuden er det et mål at undgå en sekventiel tilgang til problemet.

Problemstillinger:
- Det er en svær bane med mange forskellige forhindringer. Dette gør det svært hvis ikke man laver en sekventiel styring af robotten.

Hardware:
- NXT
- 2 motorer
- Kompas
- Ultralydssensor

Cave Res-Q

Formål:
Fere robotter navigerer igennem en ”hule”, labyrint eller bane. De skal kortlægge omgivelserne/ruten og på samme tid lokalisere personer og sende informationerne tilbage til en PC, så det bliver plottet ind på et kort. De skal snakke sammen så de dækker så stort et område som muligt, men stadigvæk ikke bliver væk fra hinanden.

Problemstillinger:
- Kortlægning af område.
- Identifikationen af en person.
- Kommunikation.
- Undgå at robotterne klumper sig sammen, men samtidig operere som en flok der kan dække et større område. Dette skal gøres ved kommunikation robotterne imellem.

Hardware:
- NXT
- 2 motorer
- Tachocounter (i motor)
- Kompas
- Bluetooth kommunikation
- Ultralydssensor

Valg
Det er tre gode projekter hver med sine spændende elementer. Vi har valgt at lave projektet med en Segway på Alishan train track banen fordi vi gerne ville vende tilbage til en Segway og det giver nogle interessante udfordringer at få den til at køre på banen fordi det kræver at den også kan holde sig oprejst på skrå overflader og det kræver at den ikke bare kan stå stille og holde sig oprejst, men at den kan navigere rundt.

Yderligere om Segway på Alishan train track
Vi har taget et valg allerede nu med hensyn til hvordan robotten skal balancere. I første omgang vil vi undersøge gyroskopet for det skulle være nok til at få robotten til at balancere og vi har det til rådighed.
For at få et overblik over hvad hvilke opgaver der er i dette projekt ses nedenfor en liste som skal danne udgangspunkt for arbejdsforløbet. Efterhånden som vi bliver klogere på hvad der kræves vil listen blive opdateret.

- Bygge robot.
- Undersøge hvordan gyroskopet virker.
- Undersøge og vælge reguleringsteknik.
- Lave et interface fra PC så det er nemt at ændre parametre i reguleringen.
- Få robotten til at balancere.
- Få robotten til køre frem mens den balancerer.
- Få robotten til at dreje mens den balancerer.
- Få robotten til at balancere mens den kører op ad bakke.
- Få robotten til at balancere mens den kører ned ad bakke.
- Undersøge hvilke muligheder der er for at navigere på banen (streg, tachocounter, kompas) og vælge.


Konklusion
Vi har valgt projektet Segway på Alishan train track fordi det bliver et spændende projekt med nogle gode problemstillinger. De to alternative projekter er beskrevet og det valgte projekt er beskrevet i yderligere detaljer så vi har et første overblik over arbejdsopgaverne og ved hvad vi skal gå i gang med først. Den første projektaktivitet skal være at bygge robotten og undersøge gyroskopet.