End Course Project Planning

Date: 8/5 2014
Duration of Exercise: 3 timer
Group Members Participating:
Henrik Jørgensen
Michael Schiønning
William Thorsen

Mål

Målet med denne øvelsesgang er, i enighed, at nå frem til had vores End Course Project skal være.

Plan

Planen for denne uge er:

• Finde en række potentielle projekter
• Udvælge hvilket projekt vi vil arbejde videre med 
• Påbegynde blogindlæg

Fremgangsmåde

Efter en indledende diskussion nåede vi frem til tre kandidater til vores End Course Project

Robot Balancing On A Ball

Den første idé er en robot der kan balancere på en bold, samt holde balancen selvom der puffes let til enten bolden eller robotten. 

Hardware

• 1 NXT unit 
• 3 motorer til hjulene
• 2 Hitechnic Gyro Sensors til at stabilisere robotten 
• 1 bold til at balancere robotten på 
• 3 omnidirektionelle hjul 

Software

• Behaviour alt efter hvilken tilstand robotten er i (Altså, hvilke motorer der skal aktiveres for at robotten ikke falder ned fra bolden) 
• PID til at kunne finjustere motorerne 

Den sværeste del af opgaven ville være at kunne kalibrere PID'erne til de tre motorer og derved sørge for at de reagerer korrekt når robottens balance forstyrres og derved korrigerer sin placering på bolden. 

Det endelige resultat vil derfor være en robot der kan balancere, uden assistance, på en bold og vil opretholde balancen selvom man skubber let til enten robotten eller bolden. 

WRO 2014

En robot der kan finde og scanne de ni solpaneler på banen. Såfremt robotten registrerer ogle defekte paneler skal de udskiftes med nye paneler fra et lager på banen. 

Hardware

• 1 NXT unit
• 3 Lyssensorer. To til at kunne følge banen (á la LineFollower) og en tredje til at registrere om de solpaneler robotten kører henover er defekte eller ej. 
• 2 motorer til hjulene
• 1 motor til en løftemekanisme, der skal bruges til at fragte de defekte paneler væk og erstattes med de nye fra et lager 

Software

• Softwarearkitekturen til denne opgave er behaviour-based. Robotten checker alle solpanelerne og i det øjeblik den finder en defekt skifter vi opførsel og skal udskifte det givne panel. Efterfølgende fortsættes den oprindelige behaviour og vi checker de resterende solpaneler.

Det absolut sværeste ved denne opgave er at kunne designe en robot, der kan navigere banen uden at støde ind i solpanelerne, samt at designe selve navigeringen. Problemet ligger i, at vi ikke har en fritliggende linje, som vi let kan følge og at robotten skal være i stand til at kunne vende tilbage til det defekte panels plads med erstatningen. 

Til slutpræsentationen skal vi have en robot der som minimum kan scanne de ni paneler og bringe et defekt panel med sig tilbage til basen/lageret.    

Navigating LEGO Road Elements

Til denne opgave skal NXT'en først navigere en opsat bane og efterfølgende danne sig et "roadmap" så den kan find den korteste rute fra et punkt A til B på banen. 

Hardware

• 1 NXT unit
• Mindst 3 lyssensorer. Den første placeres centralt og kan via en LineFollower navigere banen. De resterende to sensorer placeres på hver sin side af robotten så vi kan registrere mulige fodgængerovergange. Gør vi dette skal det noteres at der er muligheder for dele af kortet vi ikke har besøgt og vi skal vende tilbage til det.

Software

• Sekventiel softwarearkitektur med dynamisk tilgang
• Første sekvens indebærer at robotten kører en rute á la LineFollower
• Når robotten er vendt tilbage til sit udgangspunkt, checker vi om vi har passeret nogle fodgængerovergange, hvilket er lig med potentielle sving. NXT'en returnerer til det punkt og mapper den sidste del af banen
• Til sidst er det "blot" et spørgsmål om at kunne udregne den korteste rute fra A til B og omsætte den udregning til en kørselsvejledning. 

Den sværeste del af opgaven ville først og fremmest være at kunne mappe banen og skelne imellem den grå og hvide farve på vejen når vi skal bearbejde fodgængerovergangene. 

Til slut skal robotten kunne mappe en hel bane og efterfølgende kunne finde frem til den korteste vej imellem to specifikke punkter på banen. 

Konklusion

Vi har valgt at arbejde med balancerobotten. Dette er fordi at det først og fremmest er en anderledes opgave i forhold til de to andre opgaver der omhandler pathfinding. Selve robotten er ikke det mest udspekulerede design og derved kan fokus hurtigt flyttes over til softwarearbejdet med kalibreringen. En anden god ting ved dette projekt er, at det hverken er bøvlet at teste eller sætte op til den endelige præsentation. Det eneste der er brug for er robotten samt en bold. 

Embedded Systems Lesson 10

Date: 1/5 2014
Duration of Exercise: 3½ time
Group Members Participating: 
Henrik Jørgensen
Michael Schiønning
William Thorsen

Mål

Målet med denne øvelsesgang er at gennemføre øvelserne til denne uges ugeseddel Motivation-Based Behavior Selection in Agents

Plan

Planen for denne uge er:

• Bygge en robot til øvelserne
• Udføre opgaverne på ugesedlen  
• Påbegynde blogindlæg 

Fremgangsmåde

Til  BumperCar-opgaven skulle vi igen arbejde med leJOSs Arbitrator- og Behaviorklasser. Vi havde allerede fra sidste uge påbegyndt basen af robotten og kunne nu nøjes med at påmontere den ultrasoniske sensor og bumperen vha en touch-sensor. Nedenstående ses et billede af vores BumperCar.

Til øvelserne tog vi udgangspunkt i den udleverede BumperCar.java fil og skulle gøre os en række observationer omkring klassen og derved robottens opførsel. Til at starte med kørte vi et "dry" testrun og kunne konstatere at robotten kørte fremad indtil enten den ultrasoniske sensor registrerede en forhindring. Det samme gjaldt touch-sensoren. Al brugt kode kan findes til sidst i rapporten. 

Så snart en af de to sensorer blev aktiveret ville robotten aktivere behavior'en "DetectWall" og  stoppe, bakke og dreje en smule til den ene side før den fortsætter med at køre fremad igen. Vi satte et elastik rundt omkring vores bumper og derved blev DetectWall hele tiden aktiveret og robotten blev altså ved med at bakke og efterfølgende dreje ad nauseum. 

Adfærden Exit, som reagerer på Escape-knappen og kalder System.Exit(0), er implementeret som en klasse efter samme princip som DriveForward og DetectWall. Exit-adfærden er sat til sidst i adfærdslisten og derved får den den højeste prioritet. 

Efterfølgende prøvede vi at teste vores Escape-knap når robotten bevægede sig rundt. Så snart knappen trykkes stoppede programmet øjblikkeligt såfremt DriveForward havde prioritet. Var det tilfældet at DetectWall var under opsejling ville den først færdiggøre sin bakken og korrigering af ruten før robotten stoppede. 

I både DetectWall og DriveForward har vi metoden takeControl der kaldes i Arbitrator. Vi skulle finde ud af om, at DriveForward's takeControl metode også kaldes når vores triggering condition for DetectWall opfyldes. Som det fremgår ud fra kodestykket neden under fra Arbitrator klassen. Her kan vi set at den starter fra den højestre prioritet og checker hvorvidt takeControl() returnerer true. Er det ikke tilfældet checker vi den næsthøjeste prioritet osv. Dvs i vores tilfælde bliver takeControl() i DriveForward ikke kaldet, hvis DetectWalls takeControl() returnerer true. 

             maxPriority = -1; highest = -1;
          for (int i = 0; i < behavior.length; i++)
          {
           int priority = behavior[i].takeControl();
                 if (priority > maxPriority ) 
                 {
                    highest = i;
                    maxPriority = priority;
                 }
          }

Ydermere skulle DetectWall sættes til at bakke i 1 sec før den begyndte at dreje og efterfølgende bevæge sig fremad. Dette kan ses ud fra følgende kodestump 

    Motor.A.backward();
    Motor.C.backward();
    int now = (int)System.currentTimeMillis();
    while (!_suppressed && ((int)System.currentTimeMillis()< now + 1000))

Sumo-robot

Til sumorobotten gik vi ud fra den opgivene kode, hvor vi implementerede flere behaviors for at gøre robotten til en bedre sumorobot. Da vi kom ldit sent i gang med sumo-delen af opgaven (og derved ikke nåede at være med til selve konkurrencen) sad vi til sidst og biksede lidt med en rimelig simpel tilgang til sumorobotten. Derved har vi ikke en video eller et billede af robotten. Den er i bund og grund det samme skelet som vores BumperCar fra første del, tilsat en lyssenor foran og bagved samt et lidt større hjul på vores touch-sensor. 

Først ændrede vi en DetectWall klassen til i stedet for at bakke væk, når bumperen er trykket, så kører vi lige frem i små korte ryk. Denne behavior fik den højeste prioritet da tanken bag var at når bumperen var trykket så ville vi være lige foran en modstander og kunne forhåbentligt brute force modstanderen ud af ringen. 

Denærst monterede vi 2 lyssensorer, henholdsvis foran og bagved. Sensorerne  skulle bruges til at sørge for at vi ikke kørte eller bakker ud af banen . Her løb vi ind i et problem, hvor vi ikke kunne få bilen til at skifte prioritet mellem de klasser som håndterer lyssensoren. Vi tænkte at med samme prioritet 

(return 75;) ville de skifte imellem dem. Fx hvis en lyssensoren bagpå robotten registrerede et skift fra sort til hvid ville den køre frem for ikke at falde ned fra banen og derved tabe. Når den forreste sensor så registrerede et skift kunne den ikke tage prioritet, og visa versa.

Tanken var at vi videre hen måske ville bruge den ultrasoniske sensor  til at scanne efter en modstander. Anden ide var sætten endnu en bumper bagpå og så have bilen kører frem og tilbage, med små turns, indtil den fik et input på en bumper og så kører fuld kraft i den givne retning.

Den brugte kode kan findes her 

Konklusion

I denne uge har vi arbejdet videre med adfærdsbaseret arkitektur, som er implementeret i subsumption API'en af leJOS NXJ. Vi har lært at "motivation values" giver os en hurtigere reaktiong og derved et bedre resultat hvad vores behaviors angår. Dette kan f.eks. ses i forbindelse med, at når vores EXIT behavior aktiveres får vi en øjeblikkelig reaktion.