Projekt - Endelig konklusion

Dato:
26-01-2010

Antal timer:
3 timer

Deltagende personer:
Kim Munk Petersen, Andreas Koefoed-Hansen og Tim Rasmussen

Opsummering:
I starten af projektforløbet lavede vi en liste af prioriteter over hvad vi ville nå. Vi har forsøgt at følge listen som en slags arbejdsplan igennem hele projektperioden. Listen er som følgende:

1. Balancere vha. PID kontroller.
2. Køre frem og tilbage evt. styret via Bluetooth.
3. Dreje
4. Follow the line
5. Undgå objekter.
6. Navigation vha. kompas.

Det første punkt viste sig at tage en del længere tid end forventet og vi havde en del problemer med at få noget brugbart information fra sensoren pga. drift [1]. Efter en del søgen på nettet for at finde en løsning fandt vi frem til et projekt der mindende om vores. Steven Witzand havde som en del af hans speciale bygget en GELway robot der kunne balancere vha. en gyroskopsensor[2]. Ved at bruge noget af hans kode fik vi robotten til at balancere nogenlunde og efter en del ændringer i koden blev resultatet tilfredsstillende. En af de ting vi ændrede på var værdierne på PID controlleren der bliver brugt til at få robotten til at balancere, det viste sig dog at vi ikke kunne indstille parameterene bedre end de forvejen var [3].

Næste punkt var at få Bluetooth kommunikation op at køre. Det viste sig ikke at være det store problem da Kim tidligere i kurset havde arbejdet med dette [4]. Et at de mindre problemer vi havde med Bluetooth var at den ene NXT-brick ikke kunne kommunikere med computeren. Kim havde heldigvis en anden, fra hans tidligere gruppe, som vi vidste virkede[5]. Inputs til robotten bliver sat og læst vha. en bitmask således at der kan sendes flere input af gangen, fx kør frem + drej til højre. Bluetooth kontrollen blev implementeret som en behavior som bygger på en subsumption struktur der blandt anden kan håndtere prioriteter af behaviors.

Det tredje punkt var at få robotten til at dreje. Dette var ikke det store problem da det bare handlede om at give mindre power til motoren i den retning man ville.

Punkt 4 og 5 blev byttet om så vi først implementerede en AvoidFront behavior[5] og derefter en LineFollower behavior[6]. Det viste sig ikke at være det store problem og det var ret let at implementere disse som behaviors da vi havde nogle erfaringer med disse i forbindelse med øvelser tidligere i kurset[7][8].

Det sidste punkt med navigation vha. et kompas, fik vi ikke tid til at implementere. Det at gøre det muligt for Legwayen at navigere vha. et kompas er i sig selv et helt projekt. Vi ved fra da vi selv arbejde med kompas og fra gruppen der har arbejdet med det hvor svært det har været at få robotten til at vide hvor den er. Derfor var dette mål også meget urealistisk.

Linket herunder peger på en side med videoer der viser hvad vores Legway er i stand til. De blev alle filmet dagen inden præsentationen.
http://www.cs.au.dk/~tiras/filer/LEGO/embed.html

Udbytte:
I forbindelse med projektforløbet har vi arbejdet med mange af de teknikker blev gennemgået i løbet af kurset.
Blandt andet fik vi brugt et løbende gennemsnit til at hele tiden at re-kalibrere offsettet i gyroskopklassen.
I forbindelse med at robotten skulle kunne balancere fik vi også et bedre indblink i hvordan en PID controller virker. Vi havde dog tidligere arbejdet lidt med denne da vi skulle lave en robot der kunne balancere vha. en lyssensor. I løbet af dette projekt vi fik mere mulighed for at gå  mere i dybden med PID controlleren.
Efter at robotten balancerede og vi ville udbygge funktionaliteten fik vi gjort brug af en behavior-based arkitektur da vi arbejde med leJOS subsumption framework. Dette var lige til da vi også tidligere i kurset havde arbejdet med denne type arkitektur.
En sidste ting er at vi har fået nogle erfaringer med kommunikation vha. Bluetooth. Selvom der var lidt problemer i starten lærte vi af dem og fik rettet dem samtidigt med at vi lærte mere om hvordan kommunikation foregår.

Perspektivering:
Hvad ville vi ændre eller udbygge med hvis vi havde haft mere tid til projektet, eller skulle arbejde på et lignende projekt i fremtiden?.

Størstedelen af vores overvejelser i løbet af projektet har omhandlet hvordan vi kunne komme driften på gyrosensoren til livs. Efter at vi indså at der var meget drift, overvejede vi om vi skulle benytte andre typer sensorer som fx en tiltsensor/accelerometer. En kombination af tilt -og gyrosensorer (sensor fusion) kunne nok havde været en god løsning da dette er måden hvorpå en Segway håndtere driften fra gyrosensorerne[9][10].
En anden ting der kunne været afprøvet var at sætte to gyrosensorer på robotten der monteret modsat af hinanden. Ideen er at sensorerne muligvis ville drifte hver sin vej og at man derved kunne finde en gennemsnitsværdi der lå tæt på den reelle værdi.

Som beskrevet tidligere har vi fra starten af benyttet dele af koden fra en BalanceController der er fundet på nettet. En af de ting vi ville prioritere hørt i en anden sammenhæng ville være at bygge denne fra bunden af og selv lave de beregninger der indgår, som fx vægtningen af sensorinput.

Konklusion
Fra starten af projektforløbet, opstillede vi en række mål vi ønskede for projektet. Et enkelt af disse mål
var meget optimistisk og blev derfor heller ikke en del af projektet. Ud over det ene mål, er alle mål blevet opfyldt. Grunden til at vi nåede alle vores mål skyldes det kode vi fandt på nettet[11]. Lige som den anden gruppe der også arbejdede med Legway, så har vi også haft lige så store problemer med at løse problemet omkring gyroskopsensorens drift. Vi var så heldige at vi fandt noget kode på nettet der bygger på et tidligere års Lego projekt. Efter at have arbejdet ud fra den fundne kode og gjort brug af nogle af de samme principper valgte vi at anvende dele af den fundne kode. Grunden til dette var en prioritetssag. Enten valgte vi at arbejde videre med drift problemet eller også valgte vi at gøre brug af noget kode og dermed få robotten til at balancere så vi kunne arbejde videre med at nå vores mål. Vi har arbejdet meget bevist på hele tiden at se om vi kunne lave vores egen kode, hvilket resultere i at vi kun bruger koden til at styre motorerne, principperne til at få Legwayen til at køre frem og tilbage samt de beregnede værdier til PID controlleren. Alt funktionalitet rundt om har vi selv udviklet. Ligeledes har vi modificeret og tilføjet nye ændringer til deres kode. Vi gør brug af deres balancecontroller, men i teorien kunne vi lige så godt have lavet vores egen og bruge deres værdier, eftersom vi allerede har lavet vores egen tidligere i kurset. For ikke at bruge unødig tid på noget der egentligt ikke giver nogen ændring, valgte vi blot at bruge deres.

Som tidligere nævnt så har det været et prioritets spørgsmål hvor vi skulle vælge at bruge vores tid og vi er glade for det valg vi tog. Det har givet os muligheder for at stifte bekendtskab med og overveje forskellige former for styring af behavior, Bluetooth og PID controller. Hvis vi havde haft længere tid til projektet, så ville vores først prioritet være at lave vores egen balancecontroller og motorcontroller, således vi ikke gjorde brug af andet end vores egent kode.

Referencer:

1. Projekt Blog 1: http://legolab09.blogspot.com/2009/12/projekt-uge-1.htm
   
2. Projekt Blog 2: http://legolab09.blogspot.com/2009/12/projekt-2.html
   
3. Projekt Blog 3: http://legolab09.blogspot.com/2010/01/projekt-2.html
   
4. Kim og Martins blog: http://gayalsfaboulousrobots.blogspot.com/2009/10/robot-race.html
   
5. Projekt Blog 4: http://legolab09.blogspot.com/2010/01/projekt-4.html
   
6. Projekt Blog 7: http://legolab09.blogspot.com/2010/01/projekt-7.html
   
7. NXT Programming, Lesson 8, http://legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson8.dir/Lesson.html
   
8. NXT Programming, Lesson 9, # http://legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson9.dir/Lesson.html
9. http://findit-fixit.sensorsmag.com/archive/index.php/t-839.html
   
10. http://www3.ntu.edu.sg/home/mffyap/web/docs/Selfbalancingscooter.pdf
    
11. The Java source code for the GELway, http://gelway.googlecode.com/files/GELway%20Java%20Code.rar