Lab 11

Date: 25/11 - 2010
Duration of activity: 14 - 17
Group members participating: Morten Rasmussen, Kenneth Sejdenfaden Bøgh, Morten Nikolaj Pløger.


Goal:


Today we will try to figure out what end course project we would like to do.


Results:


list of projects considered with a short description of each, e.g. a description could be:"robot that can dry wet spots on the floor during a handball match".

The list below is ordered. That is we would prefer to do project number 1. The reason for the choice of this project is that we think it is doable and yet contains enough challenges. The other projects are either too difficult or too trivial from our point of view. It should also be mentioned that although we are only three participants today we will be four people working on this project. As such we believe that we will be able to take on this rather large task.  


Projects considered:

1. Laundry pickup robot: two robots. One drives around and picks up laundry. Another is stationary and raises a platform to put the laundry into the laundry basket.

Sensors needed: 3x Sonic Sensors, 3+x Pressure Sensors.

Here were would need two NXT’s, for two individual robots, one to retrieve the laundry and deliver it to the second robot which then puts the laundry into the laundry basket. The laundry retrieving robot would be a Behaviour based robot, with behaviours such as Wander(looking for laundry), Pick up laundry, Deliver laundry to laundry basket, avoid obstacles, recharge. The second robot would be mounted to the laundry basket with a mechanism which enables it to lift clothes. The scenario is: First the wandering robot delivers a piece of cloth to the mounted lifting robot and leaves the clothes on a platform. Then the mounted lifting robot lifts up the platform to the edge of the basket, where it will tilt the platform so taht the clothes fall into the basket and returns back to its initial position.

Some thoughts about the behaviours:

Wander will require some sort of pressure sensor attached to the robot in such a way that the sensor will sense laundry. This could be achieved using multiple pressure sensors in front of the robot in a line with a flat panel attached close to the ground though not touching the ground (multiple sensors can in this case be connected to the same port).

Pick up laundry is invoked after Wander has detected some clothes on the floor. The way we imagine the robot would be able to move laundry would be to use two ‘hands’ in the form of pads with rough surfaces, which it then move together around the clothes and start dragging it by moving backwards towards the laundry basket.

Delivering laundry to laundry basket involves three Sonic Sensors. The laundry retrieving robot sends a signal to the other basket robot ‘Hey I got laundry!’ and the basket robot starts sending a constant signal with its Sonic Sensor. Now, the retrieving robot can find its way to the basket in a Braitenberg[1] fashion, hence feeding the input directly to the motors, since it is equipped with two Sonic Sensor’s. When the laundry is delivered the basket robot stops sending the ultrasonic signal.

Avoid obstacles would make use of the two Sonic Sensor’s. This could lead to some interesting problems since we risk disturbance between the two sensors and hence be forced to make e.g. a distribution in time to make atomic measurements. This behaviour also includes a Pressure Sensor at the back of the robot with the sole purpose of avoiding objects while dragging laundry since the Sonic Sensor’s at this time are unable to do nothing but listen in order to locate the basket.

We expect to be able to present a robot that is able to detect and retrieve laundry to an active landmark in the form of an NXT, avoiding objects both as it is searching and on its way back to delivery.


2. Multicolour printer: One robot that is a able to draw in several colors and print line-by-line like an actual printer does. ie something like this http://www.youtube.com/watch?v=zX09WnGU6ZY but using nxt

This would require a single NXT and a lego setup that would be able to feed the paper in a controlled manor.
One motor will feed the paper forward, another one will control the left to right motion and the last one will control which pen is currently used to draw.
The software would be client server based. That is the NXT would be the server and then PC’s would be able to connect to it using bluetooth. The client software would then need to transform the bitmap picture to a resolution that the robot would be able to print.

The most difficult part of this project would be the transformation of the pictures and to get the tacko counter to move the paper exactly the same distance every time(so that all pixels have the same width)
Also it might be hard to avoid the pen “bleeding” if it stops on the paper for a short while.

At the end we would be able to present a printer that could print bitmap pictures, although they would probably be in a rather crude resolution(ie pixilated).


3. Stalker robot: robot that picks out a moving target and follows it around stopping when the target stop and moving when the target is moving

For this project we considered using the sonic sensor to keep track of the stalking victim. The idea was to make the robot follow a person and keep following this person for a given time period or until the robot looses track of the victim. We discussed how the software should interact with the world. This should be done through a behaviour model, where the behaviour should be in the layer of: find victim, follow victim.

This project would, in our opinion, be either too difficult or not difficult enough.
The part where this project would be too easy, is when the robot is just stalking a random victim, which may change, for instance if the person enters a group the robot may stalk any random victim of the group.
The part where this project would be too difficult, is the opposite situation as above. The robot initially stalks a random victim and keeps stalking this victim, if the victim enters a group, the robot should stalk the same person when the victim leaves the group.

If we chose this project, we should be able to present a robot, which would be able to stalk a random victim, but if the victim enters a group, the robot would choose a new random victim to stalk.



4. Hamster ball:  Pet robot, something similar to http://xkcd.com/413/

For this project we would need two large hamster balls and two nxts. It would require some modifications though. The camera on top in the comic is too advanced to build for this course, so we would be dropping that. Since real hamster balls are not very see through we would not be able to put light sensors inside the robots.
Instead we would create two pets and and have them use bluetooth to locate each other and stuff like food, “litter tray” and bed.  They would then have an amount of behaviors to make them act like real pets. As such they would wonder around until they found another pet in which case they would start playing, and go to the food when they become hungry, go to the sleep area then they are running out of power etc.
The idea is, although we do not know if it will work, to connect to the bluetooth device which is named according to what it represents. Ie a phone or another bluetooth emitting device acts as food by having the name “food” and another acts as sleeping area etc.
After the connection is established the robot will move to that object by measuring the strength of the bluetooth signal.

There are two major obstacles for this project. First we need to find a hamster ball big enough to contain the lego construction, besides this it also needs to be able to open in two half's. Most hamster balls have a small hole that opens instead of being in two half's, as described above, which will not be big enough to fit the nxt through.
Secondly the idea of using bluetooth strength to navigate to a point might not work since the signal strength measurements might not be accurate enough to determine a direction. Even if it works it might be difficult to implement efficiently.

Assuming we can find the hamster balls we would be able to present two robots that can at least wonder around a play very simply with each other. The scenario is: both robots look for the other robots bluetooth signal. Once a bluetooth signal is found, one robot sends a small sound file to the other using bluetooths. The robot that received the file then starts playing it, while the robot that originally send the file starts to listen for the specific sound sequence. This would enable the robots to identify one and another.


References:

[1], Braitenberg, V. 1984. Vehicles, Experiments in Synthetic Psychology London, Cambridge: The MIT Press.

Lab 10

Dato: 18/11 - 2010

Varighed: 14 - 16
Medvirkende: Morten Rasmussen, Kenneth Sejdenfaden Bøgh, Morten Nikolaj Pløger.

Mål:

http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Lesson.html

  I dag skal vi eksperimentere med behaviour robotter, der skifter opførsel baseret på en prioriteringsliste af Behaviour objekter. 

Plan:

  Opgaven i dag er beskrevet i punktform, så derfor tager vi simpelthen et punkt af gangen og skriver en beskrivelse af hvad vi oplevede og fik ud af opgaven. 

Robottens konstruktion:

Standard 9797 Lego robot med tryk- og sonicsensor tilføjet.


Udførsel:


First, make BumperCar run on an NXT:

 BumperCar er et eksempel på et stykke kode der anvender LejOS' Behaviour API [1]. Programmet beskrives til at lade robotten køre fremad som laveste prioritet, og som højeste prioitet undvige, altså bakke og dreje lidt, hvis enten dens tryk- eller sonicsensor 'ser' noget.
  Programmet opfører sig fuldstændig som forventet og det ses tydeligt, hvad enten vi rammer tryksensoren eller sætter hånden foran sonicsensoren, at den behaviour der er ansvarlig for at undvige (DetectWall) overtager kontrollen.

Press the touch sensor and keep it pressed. What happends ?:

 Der sker det, at robotten hele tiden udfører DetectWall, hvilket vil sige at robotten først bakker en smule og stopper. Den anden behaviour, DriveForward, får aldrig lov til at tage kontrollen, idet den har laveste prioritet, og inden den når at få en chance for at styre, så har DetectWall allerede kaldt takeControl().

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:

  For at være helt sikre, lavede vi her noget udskrift til skærmen på vores NXT, med en tæller der incrementes for hver gang takeControl() kaldes for de to Behaviours. Med disse udskrift var det tydeligt at DriveForward ikke kalder takeControl(), end ikke hvis DetectWall bliver færdig med sin action og Arbitrator skal finde den næste Behaviour. Dette skyldes nødvendigvis at Arbitratorens liste af Behaviour's gennemløbes bagfra (højeste prioritet først), hvilket giver god mening, idet den første der tilkendegiver at den ønsker kontrollen nødvendigvis også vil have den højeste prioritet, også er der ingen grund til at spørge dem med lavere prioritet.

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.  

Den endeligfe kode: http://daimi.au.dk/~u071354/BumperCar.java

Denne Behavior indsættes som den sidste i listen og vil dermed have den højeste prioritet.

Is the Exit behavior activated immediately ? 


  Vi forventer at der vil være en mindre forsinkelse idet den tidligere acition skal være færdig før Exit kan få lov at overtage kontrollen.

  Nej, den kan ikke aktiveres før den nuværende behaviour er færdig med at udføre sin action.

  Den måde at gennemløbe Behaviours og lade dem kalde deres action, udelukker muligheden for at lade en højere prioritet overtage kontrollen midt i en anden Behaviours action. 

What if the parameter to Sound.pause(20) is changed to 2000 ?

  Så vil det tage 1980ms længere inden programmet terminerer. 

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:

   Vi lavede en tråd der som beskrevet ovenfor med en enkel variabel der husker den sidste måling.
  Denne ændring fjernede fuldstændig den lille pause der var for takeControl metoden tilhørende DetectWall.

Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning. 

  Denne opgave klarede vi ved at tilføje 3 linier i starten af is(suppressed) blokken.

  Motor.A.backward();
  Motor.C.backward();
  Sound.pause(1000);

  Hermed sættes motorene til at køre baglæns og programmets udførsel sættes på pause et enkelt sekund. Efter pausen er gået, vil robotten dreje, og DetectWall's action er slut.

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.

  For at gøre det muligt at afbryde en action, er vores første idé at lægge alt koden fra DetectWall's action ud i sin egen tråd, som så bliver interrupted når tryksensoren rammes.
  Vi havde ikke held med denne løsning, idet vi fik java exception på  NXT'en hver gang vi brugte tryksensoren. Desværre fandt vi ikke ud af hvad vi gjorde forkert, og tiden er ved at løbe fra os så vi stopper her.

 

Referencer:


[1],  behavior-based architecture: http://lejos.sourceforge.net/nxt/nxj/tutorial/Behaviors/BehaviorProgramming.htm

Lab 9

Dato: 11/11 - 2010

Varighed: 14 - 16
Medvirkende: Morten Rasmussen, Kenneth Sejdenfaden Bøgh, Morten Nikolaj Pløger.

Mål:

http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson9.dir/Lesson.html


Idag skal vi afprøve forskellige måder at holde styr på en NXT robots' position via motorens tacho counter.

Plan:

Robottens konstruktion er standard LEGO 9797 model.

1:
Vi vil som det første lave et program så robotten kører i det samme mønster som beskrevet til Brian Bagnall's Blightbot med LeJOS navigator klassen.
Her vil vi undersøge om vi når samme konklusion som Brian, nemlig at denne setup gør robotten god til at køre ligeud og måle afstand, men er upræcis til at rotere om sin egen akse.

2:
Her efter vil vi undersøge muligheden for at køre i et bestemt mønster samtidig med at undgå objekter.

3:
Til sidst vil vi forsøge at sammenligne to algoritmer til differential drive med den SimpleNavigator i LeJOS, og undersøge muligheden for at bruge en af dem til at forbedre SimpleNavigator.

Forløb: 

1:
Setup
Til denne opgave valgte vi at køre Tacho Navigator Test, fra leJOS Tutorial: Controlling Wheeled Vehicles[1] og redigerede koden således at robotten kørte i en firkant.
Det krævede nogle ændringer at få programmet til at køre, da klassen lejos.navigation.TachoNavigator ikke længere eksistere. Istedet skal man have fat i lejos.robotics.navigation.SimpleNavigator som tager en lejos.robotics.navigation.TachoPilot som parameter.
Vores kode kan findes her: http://cs.au.dk/~u071354/FirstPilotTester.java
Grunden til at vi vælger denne test, er at den er simpel og vil tydeligt vise hvor præcist SimpleNavigator klassen får robotten til at rotere, og om den kører i en firkant som forventet.
Test 
Ved den første test drejede robotten meget mere end den burde, dvs når vi bedte den om at rotere 90 grader i koden, ville den nærmere rotere 120 grader i virkeligheden.
Da det ikke er åbenlyst hvilken afstand imellem hjulene TachoPilot klassens parameter ønsker (altså om det er fra de yderste kanter, midten, eller indersiden af hjulene) kørte vi næste test med denne afstand sat til 13cm i stedet for de originale 14cm. Denne ændring gav en lille forbedring, men robotten er stadig meget upræcis i sin rotation.

Det er her vi får en mistanke om at baghjulet i konstruktionen har en del af skylden for den afvigelse vi ser imellem kode og praksis. Kenneth får den ide, at man kunne påmontere en bold der frit kan rotere istedet for baghjulet. Tankegangen er den samme som en gammeldags kuglemus.



Denne ændring i konstruktionen bekræftede vores mistanke, og har bragt os tættere på den forventede firkant.
Nu roterer den til gengæld en lille smule for lidt, hvilket resultere i at den ikke lukker firkanten helt.

kørsel med kuglebaghjul

Brian Bagnal
Som det sidste valgte vi alligevel at køre Brian Bagnall's rute af den årsag at den anvender nogle andre vinkler [2].
Vi foretog den første kørsel med ruten skaleret op med en faktor 2, og kunne konstatere at den lavede for store vinkler.
Da vi stadig, som nævnt tidligere, ikke er klar over hvilken afstand imellem hjulene vi skal sende med som parameter, valgte vi endnu engang at sætte denne værdi ned fra 13cm til 12cm. Ydermere kører vi ruten skaleret op med en faktor 3 for lettere at kunne se udsving i kørslen.
Disse ændringer viste betydelige forbedringer. En kørsel med ruten sat i loop 4 gange er illustreret nedenfor.

Som det kan ses fra ovenstående billede, er de 3 af kørslerne næsten helt symmetriske, hvorimod den sidste ryger en smule ved siden af, formentlig grundet at bolden ikke løber 100% frit et øjeblik. Det kunne selvfølgelig også skyldes drift, men i så fald ville man forvente en gradvist størrer afvigelse i løbet af de 4 kørsler. Koden findes her: http://cs.au.dk/~u071354/PennyPilotTester.java

Referencer:


[1], leJOS Tutorial: Controlling Wheeled Vehicles
[2], Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization, p.297 - p.298.



Generelle resultater og observationer: 

Lab 8

Dato: 4/11 - 2010
Varighed: 14 - 17
Medvirkende: Morten Rasmussen, Kenneth Sejdenfaden Bøgh, Morten Nikolaj Pløger.

Mål:


http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson8.dir/Lesson.html

Idag skal vi prøve at arbejde med en 9797 Lego bil, der udviser forskellige former for og prioritering af adfærd igennem concurrent tråde.

Til at starte med er det eneste vi skal, er at afprøve og observere et program vi får givet der har tre opførsler:
1: Spil en lyd hvert 10. sekund
2: Undgå objekter
3: Kør tilfældigt omkring

Herefter skal vi forsøge at tilføje en opførsel der gør at vores robot søger mod lys.

Plan:

Der er ikke så forfærdelig meget at sige til dette punkt, udover at vi følger planen i linket, altså:

Vi starter med at bygge standard robotten 9797 fra manualen, og overfører programmet SoundCar.java for at se hvordan den opfører sig.

Når det er klaret implementerer vi vores egen behavior der får robotten til at køre efter lys. Her overvejer vi at låne endnu en NXT lyssensor og følge idéen fra sidste lab, således at to lyssensorer kan bruges til at styre robotten i den rigtige retning.

Forløb:

LEGO car that exhibits several behavior
Vi har nu ombygget robotten så den ser ud som på billedet nedenfor:

Programmet SoundCar.java opfører sig som forventet, idet den som førsteprioritet afspiller en lyd hver 10. sekund, dernæst vil forsøge at undgå objekter, og som det sidste kører tilfældigt rundt.
Vi forsøgte også her at blive ved med at holde noget foran robotten, hvoraf det ses tydeligt, at den afspiller lyden selvom den er midt i at bakke tilbage for at undgå sammenstød.

Class Behaviour:

Hvis ikke trådene var markeret som daemon, ville de have mulighed for at leve videre selvom programmet termineres på NXT'en, hvilket er årsagen til at daemon er sat til true.

SuppressCount, der anvendes i Behaviour.java filen, er implementeret som en tællesemafor. Det vil sige, så længe SuppressCount er lig 0, er den tilhørende Behaviour supprressed og kan ikke tilgå robottens motore. Hver Behaviour kender sin underlæggende Behaviour. Så, når en Behaviour konstatere at den vil tilgå motoren, kalder den suppress(), der tæller alle underlæggende Behaviours' suppressCount én op. Bagefter, nær den er færdig, kaldes release(), der tæller alle underlæggende suppressCounts én ned, hvilket muligvis åbner muligheden for at en ny Behaviour ikke længere er suppressed og nu kan få lov at tage kontrollen.

Fred Martin's version baserer sig på et gennemløb af et array af processer, der har tilkendegivet at de ønsker at blive 'enabled', altså tage kontrol. Ud af dette array udvælges den process der har højest prioritet, som får lov at køre, hvorefter den kan afmelde sig listen af 'enabled' processor, og give plads til en ny opførsel.

Vi mener at de to algoritmer vil give den samme opførsel, men at Fred Martin's version kunne være smartere i det tilfælde hvor man ønsker størrer kontrol på runtime over hvilke mulige opførsler robotten kan have, idet det nemt kan arrangeres således at man kan påtvinge en process aldrig at blive enabled.

Spørgsmål fra forelæsning omkring boolean og Behaviour strategien:
Grunden til at boolean ikke fungerer her, er, at så snart der er mere end to lag med behaviour, så ønsker man at oprette en kø over hvem der skal have lov til at have kontrol over motorene. Hvorimod, hvis der blev brugt en boolean, ville man kunne risikere at flere underlæggende behaviors der venter på at opnå kontrol, vil kunne tilgå kontrollen på samme tid.

Add a behavoiur "Drive towards light":

Til denne opgave har vi anskaffet os 2 NXT lyssensorer og forsøgte at genanvende koden fra sidste uge, hvor vi tager input fra venstre sensor (hvor i det her tilfælde mørke er 0 og skarpt lys 100) og sender direkte til højre motor og vice versa.
Det første problem vi løb ind i, var at selvom vi har anskaffet os NXT sensorer, så var lysstyrken i lokalet vi befinder os i relativt lav, under 35. Så hvis vi placerede robotten i et mørkt lokale og forventede at den ville søge mod lyset i døren der fører ud af lokalet, så ville robotten stå stille og lave en høj hyletone, idet motorene ikke får strøm nok til at skubbe robotten fremad.
Herefter forsøgte vi, for at komme ud over det ovenstående problem, at lave vores egen mapping fra sensorenes målinger til den strøm vi giver motorene således at robotten skulle blive mere lysfølsom, og dermed kunne køre selvom det er mørk. Denne ændring gjorde at robotten stadig bevæger sig langsomt i mørke og hurtigt når det er lyst, hvilket ikke umidelbart er ønskværdigt, men hvad vigtigere er, så kan vi se at den kører imod lys!
Vi diskuterede os frem til at det måtte være muligt at implementere, i vores mapping fra sensorene til motorene, en algoritme der gør robotten hhv. mere eller mindre lysfølsom over tid. Det vil sige, hvis den placeres i et mørkt rum, vil den køre målbevist efter små lysværdier, og omvendt, stilles den i et lyst lokale bør den ikke køre særlig hurtigt, idet de høje værdier over tid skulle have mindre betydning for strømmen der sendes til motorene. Desværre kom vi ikke så vidt at vi fik implementeret denne tankegang, men det var nogle overvejelser vi gjorde os i løbet af eksperimentet.

Lab 7

Dato: 28/10 - 2010
Varighed: 12 - 16
Medvirkende: Morten Rasmussen, Kenneth Sejdenfaden Bøgh, Morten Nikolaj Pløger.

Mål:

http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Lesson.html

At teste forskellige måder at opsætte agents vha. sensorer.
Vi vil starte med at sætte en enkelt agent op, og derefter gå videre til at afprøve to sensorer, både parallel og krydset opsætning.

Vi har valgt at lave vores forsøg med lydsensorer i første omgang og så evt gå over til lys sensorer senere.

Plan:

Først afprøve en enkelt sensor, som vist på tegning 1. Derefter vil vi lave 2a og slutte af med 2b.

Vi bruger standard robotten fra mindstorms manualen som base og modificerer den efter behov.

Forløb:

En sensor:

Vi startede med at genanvende koden fra SonicSensorTest fra en tidligere lab, hvor vi selvfølgelig kalder på lydsensoren istedet for sonicsensoren.

Se koden her.

Herved kunne vi konstatere at lydsensorens metode readValue() giver en et output fra 0 til 100, og at sensoren forøvrigt virker. Denne fordeling passer godt med at motorens metode Motor.setPower(int value) tager værdier fra 0 til 100.
Vi holdt vores agent simpel og sender output fra sensoren direkte ned til motoren. Dette virker fint og vi kan få robotten til at kører frem med en enkelt sensor uden problemer.
Altså virker vores første konstruktion ved at sende umodificerede rå værdier direkte ned i motoren.
Vi har dog observeret at værdien til motorens setPower() skal være over 15 før vi får en reaktion hvilket bevirker at lyd langt væk ikke påvirker robotten særlig meget.
Denne observerede opførsel har vi valgt at beholde da det gør tests lettere i lab hvor der jo er noget baggrundsstøj.

Koden til vores setup med én sensor kan findes her.

To sensorer:

Efter vores første success valgte vi at beholde det grundlæggende design på robotten, og blot modificerer designet til at supporterer to sensorer.

Derefter skrev vi vores kode lidt om således at vi havde et setup magen til figur 2a. Altså skulle robotten sende signal fra venstre sensor til venstre motor og gøre det samme i højre side.
Dette medførte nogle interference problemer da begge sensorer læste næsten de samme værdier, hvilket medfører at robotten kun drejer meget lidt ved lyd fra forskellige retninger.

Den første kode vi har brugt til to sensorer kan findes her.

Efter lidt brainstorming kom vi frem til to løsninger. Enten skulle sensorerne flyttes længere væk fra hinanden, eller også skulle vi introducerer en slags støjværn.
Vi blev enige om at starte med den sidste løsning, hvilket gav gode resultater når lyden kom fra siden, men det gik mindre godt når lyden kom forfra. Ved lidt eksperimentering fandt vi ud af at problemet lå i at mikrofonerne pegede ned af og at den øverste plade af støjværnet lukkede for mange lyde ud. Som sådan fjernede vi den øverste plade og instruktoren foreslog at fjerne baghjulet for at justerer vinklen.
Dette gav gode resultater og robotten begyndte at reagerer meget godt uanset hvor lyden kom fra, så længe den lydkilden relativt tæt på.

2a.1

2a.2 front

2a.2 back

Da vi havde dette setup til at kører byttede vi om på motornes porte for at få et setup magen til tegning 2b.

Dette setup virkede med det samme og robotten kommer når man kalder som man kan se i videoerne nedenfor.

Vi har stadig det meget simple setup med at sende rå værdier direkte fra sensor til motor. Dette gør robotten lidt mindre følsom, og medfører også at den har svært ved at reagerer på lyde langt væk som det også ses i videon ovenfor.
I et forsøg på at forbedre denne opførsel, prøvede vi at forøge power til motorene med en konstant værdi på 10, da baggrundsstøjen var på ca. 10. Altså ændrede vi power til sensoroutput plus 10.
Det løste ikke problemet med at reagere på lyde langt væk fra robotten, men gjorde til gengæld at den reagerer lidt kraftigere på de lyde den kan høre. Denne modification gør at robotten virker mindre 'sløv', så på den måde er det en forbedring.

Den modificerede kode til to sensorer kan findes her.

To sensorer og to tråde:

Vi har som det sidste afprøvet et setup, hvor hver sensor og motor par lever i hver sin tråd. Dette har vi lavet ved at genanvende koden fra tidligere, blot ved at lave en ny klasse kaldet SensorThread, der essentielt udfører det samme arbejde som vi tidligere gjorde i main klassen for én motor og én sensor.
Man kunne forestille sig at der her kunne opstå problemer, idet hver motor kan få ændret hastigheden på forskellige tidspunkter. Det viste sig dog ikke at være tilfældet, og robotten opførte sig præcist som før.
Altså gav denne ændring ikke nogen forbedring, men man kunne forestille sig at et mere avanceret setup ville kunne anvende dette med fordel.

De to klasser der udgør denne kode er SoundThread.java og Sound4.java.


Generelle resultater og observationer:

Så længe vi arbejdede med én sensor var det relativt simpelt at få gode resultater, da sensorens output og motorens input værdier ligger i samme interval.
Da vi gik over til to sensorer blevet det skarpt sværer da lyd bølge interference var et meget reelt problem.
Vi startede med at sætte en enkelt plade i mellem de to sensorer, hvilket ikke var nok værn til at skabe reele forbedringer.
Vores sidste setup med afskærmning i to vinkler virkede tilgengæld ret godt (billede 2a.2).
Der var stadig lidt interference men vi nåede til et punkt hvor vi kunne kalde på robotten fra forskellige vinkler og få den til at opfører sig som vi forventede.

Derud over observerede vi at sensorerne reagere bedre jo højere frekvens vi brugte. Fx gav almindelig højlydt tale næsten ingen reaktion. Tilgengæld reagerede den fint på fløjt og lyse stemmer som vores videoer tydeligt demonstrerer.

Som en sidste observation opdagede vi at mikrofonerne er klart bedst på kort afstand. Hvis man kommer et par meter væk, skal der virkelig råbes igennem for at få en reaktion. Dette har nok mere at gøre med lydbølgers opførsel end mikrofonens kvalitet, men det var dog alligevel noget vi bed mærke i da målingerne falder meget brat når man kommer en vis afstand væk.

Lab 6

Dato: 7/9 - 2010

Varighed: 14 - 17
Medvirkende: Morten Rasmussen, Kenneth Sejdenfaden Bøgh, Morten Nikolaj Pløger.

mål: http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson6.dir/Lesson.html

Forløb:

 Som det første ændrede vi på vores robots design. Morten Rasmussen havde efter sidste lab ændret på robotten med tanke på at få sensorene til at vedligeholde den samme afstand fra underlaget. Det virkede ikke efter hensigten og ødelagde muligheden for at påmontere store hjul.

Alpha

Beta

Awesome

  Dernæst ændrede vi i koden, således at det ikke længere er nødvendigt at kalibrere alle sensorer hver for sig, men derimod kan nøjes med at læse hhv sort, hvid og grøn én gang.

 Disse ændringer optog ligepludselig meget mere tid end forventet, hvilket resulterede i at vi faktisk ikke opnåede nogen form for resulater på banen. Til gengæld fik vi diskuteret os frem til hvilken strategi vi ville have forsøgt os med og blev enige om følgende:

 En PID beregning for hhv højre og venstre motor baseret på de tre sensorer (Sl, Sm, Sr).

 To booleans turningRight og turningLeft, der som navnet hentyder sættes true ved sving eller korrektioner. Så længe én er true, vil der ikke kunne drejes i modsatte retning. De sættes til false så snart (Sl = hvid, Sm = sort, Sr = hvid).
 Denne opsætning skulle gerne modvirke at robotten følger de 'forkerte' streger der fører ud af banen.

 Hvorvidt man kan viderføre alle idéerne fra PID til vores opsætning eller om det giver mere mening at nøjes med en PI beregning, nåede vi som skrevet ikke at dykke ned i, men det kan tænkes at være tilfældet eftersom vi har med binære værdier (sort/hvid) at gøre. Dermed vil vi ikke have nogen desideret error værdi og må nødvendigvis spekulere mere i antal målinger der kræver en korrektion.
 Her kunne vore indførte booleans også være en hjælp. Hvis den midterste sensor Sm = hvid, ved vi at den er helt gal, men vi ved også i hvilken retning den er gal, og kan nu begynde at dreje endnu skarpere.

Lab 5

Dato: 30/8 - 2010
Varighed: 14 - 17
Medvirkende: Morten Rasmussen, Kenneth Sejdenfaden Bøgh, Morten Nikolaj Pløger.

Mål: http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson.html

Forløb:

Black White Detection:

Efter at have bygget LEGO9797 kørte vi BlackWhiteSensor og så at sort er ~52 og hvid ~34.

Line Follower with Calibration:

Kørte programmet og vores robot kørte i første omgang af den sorte streg pga for store hjul. Vi satte
derefter de små hjul på også fulgte robotten den sorte streg fint efter kalibrering.

ColorSensor with Calibration:

I første omgang har vi modificeret BlackWhiteSensor ved at tilføje en greenLightValue.

Her er måden der skelnes imellem sort og hvid samme som før:
White:34 --------> blackWhiteThreshold <------- Black:52

For at afgøre om farven er grøn gør vi følgende:
White:34 --> GWThreshold--|GREEN:43|--GBThreshold <-- Black:52

Med denne måde at afgøre farven grøn, er det muligt at der bliver læst værdier der kan tolkes for at være grønne ved overgangen mellem sort og hvid.
Derfor regner vi med at forsøge os med at lade programmet læse værdien grøn X antal gange, før
vi endeligt konstaterer at farven reelt er grøn.

Line Follower that stops in a Goal Zone:

Robotten er nu udvidet til at have tre RCX lyssensorer i front og én NXJ lyssensor i bag.



Ideen er at det må være muligt at lade RCX sensorene skelne mellem hvid og sort, og give et relativt præcist billede af placering i forhold til stregen. NXJ sensoren's eneste opgave er at holde øje med om vi er i mål.

Programmet til at styre robotten bliver i første omgang ret simpel.

Lad S[i] i = 1,2,3 være RCX sensorer og NS være NXJ sensoren.
(S1=white, S2=black, S3=white) Kør fremad
(S1=black, S2=black, S3=white) Sænk farten og drej til venstre ved at forøge power
(S1=white, S2=black, S3=black) Sænk farten og drej til højre ved at forøge power
(NS=Green)                Stop vi er i mål.


Vi nåede ikke at implenetere stop ved grøn, men den simple algoritme viste sig faktisk at være ganske
effektiv. Næste skridt må være stop ved grøn for det første, og kørsel via PID for en hurtigere tid.