Team NXT Generation: Lesson 6 - Combining sensors

Date: 14/03 2014 + 18/3 2014

Duration of activity: 9.15 - 14.30 + 9.15 - 14.15

Group members participating: Pætur, Christian og Søren

Goal: At gennemføre ugens opgaver [1].

Plan: Gå opgaverne sekventielt igennem.

Results: Vi har gennemført alle opgaverne.

Vehicle 1

Start with vehicle 1. As sensor use a sound sensor to implement a vehicle that moves faster forward the louder the environment sound is. Use two motors to drive the vehicle and apply the same power to the two motors. The main issue is how to map sensor values to motor power. If raw sensor values are used, the mapping should be from the range 0, 1023 to the motor power range, i.e. 0, 100.

I programmeringen af denne første opgave tog vi soundSensor.readValue() værdierne, som er en repræsentation af lydniveauet fra 0-100, og mappede dette til power for begge hjul, ved at bruge Car klassen:

Figur 1: Engangskode til Vehicle 1.

Vi erfarede at når bilen først var kommet i gang med at køre fremad på gulvet, stoppede den ikke igen, da larmen fra motorerne blev opfanget af lydsensoren med en værdi på omkring 90, og dermed gav motorerne en power på omkring 90. Når man holdt bilen op i luften, opfangede lydsensoren tilsyneladende ikke støjen fra bilens egne motorer, og så snart lydkilden (i vores tilfælde en mobiltelefon) ikke længere udsendte lyd, stoppede motorerne med at køre, ganske som forventet. Derfor må det have noget at gøre med den måde som lyden bliver reflekteret på og opfanget af lydsensoren, som er anderledes når bilen er på gulvet, der bevirker denne ændring. Vi forsøgte at placere lydsensoren på forskellige måder på bilen for at se, om det ville ændre på den måde lydsensoren opfangede lyden på. Se billederne herunder. Vi kunne have normaliseret power værdien, men vi går videre til næste opgave.

Figur 2: Billede af vehicle 1 med lydsensoren pegende fremad

Figur 3: Billede af vehicle 1 med lydsensoren pegende opad

Also try to map to motor powers between -100, 100 and interpret negative motor powers as moving the motors backwards. How would you describe the resulting behaviours?

Vi prøvede at programmere dette hvor bilen kører bagud når readValue() værdien er mindre end 50 (0-49) og bilen kører fremad når værdien er større end 50 (50-100).

Værdierne fra lydmålingerne fordelte vi på et spænd mellem -100 og 100 som følgende kode viser. Se kodeudsnit herunder.

Figur 4: Vehicle1_v2.java

Når værdien sound er 0 kører bilen bagud med en power på 100, når værdien sound er 50 holder bilen stille (power = 0), og når sound er 100 kører bilen frem med en power på 100. Følgende simple graf illustrerer dette.

Figur 5: X-aksen angiver sound.readValue() og y-aksen den power som bliver sendt til motorerne. Positive værdier er en angivelse af, at bilen kører fremad og negative at den kører bagud.

Vi erfarede at bilen kørte lidt frem og tilbage: når vi startede bilen kørte den baglæns (fordi sound.readValue > 50), men støjen fra motorerne fik hurtigt værdien sound.readValue til at stige til over 50, hvilket betød at gjorde at readValue() værdien kom over 50, hvor bilen begyndte at køre frem. Men til vores overraskelse blev den ikke ved med at køre fremad som i første Vehicle 1 forsøg. En forklaring kan være, at larmen fra motorerne afhænger af power til motorerne, hvorved bilen ikke går i selvsving og kører fremad hele tiden som i forrige opgave.

In the vehicles of Figure 1 all connections are marked with a +. This means the more of the measured quantity, e.g. sound, the more motor power. These connections are called exitatory connections. Braitenberg also use connections marked with a - to mean an inhibitory connection, the more the less. Implement this kind of connection and investigate the behaviour with an inhibitory connection on vehicle 1. How would you describe the resulting behaviour?

Vi har sådan set lavet både en excitatory (50-100) og inhibitory (0-49) forbindelse i forrige opgave, hvormed vi springer denne opgave over. Resultatet i vores tilfælde med forrige opgave var, at bilen kørte lidt frem og tilbage, og at det afhang meget af den støj som motorerne udsendte.

Try to play music and make mappings from the sound sensor to the two motors that will make the vehicle "dance" to the music, like you see in the beginning of the video in Figure 2.

I vores program fra før (kode i figur 4), har vi en dead-zone når power ikke er høj nok, lad os antage at bilen først kører ved en power på 50 og derover (når power = 50 er sound.readValue() = 75 og derfor står bilen teoretisk set stille når sound.readValue() returnerer mellem 25 og 75).

Vi springer over at lave en test af den præcise power hvorved bilen bevæger sig fremad. Vi antager at denne er 50. Vi ændrer koden fra figur 4, så bilen altid kører bagud eller fremad med en power på 50-100. Derved får vi forhåbentligt en mere dansende robot:

Figur 6: Vehicle1_dance.java

Vehicle 2

In the two vehicles, 2a and 2b, use e.g. two light sensors mounted in the front, Figure 3. Again make sure to define the mappings between sensor range and motor power. Try with both excitatory and inhibitory connections and describe the resulting behaviours, e.g. as in Figure 4.

Når vi bruger en excitatory forbindelse gælder at jo mere lys jo hurtigere kører bilen. Om bilen kører imod eller væk fra lyset afhænger af, om vi bygger forbindelser som i vehicle 2a eller 2b. Vi gik ud fra koden fra Braitenberg’s vehicle [2], men i stedet for at sætte power proportional til kvadratet by lys-værdien -200:

motorizq.setSpeed((sluzizq.readValue()*sluzizq.readValue()) - 200);

anvendte vi bare lysværdien x 2. Dette var fordi i Braitenberg’s måde at omsætte lysværdi til motor-power kører bilen meget hurtigt, når der er meget lys og meget langsomt når der er lidt lys. På vores måde kører den knapt så hurtigt når det er lyst, men også knap så langsomt når der er mørkt. Vi fik lysværdier mellem 15-35, dvs. at hjulene får en power på mellem 30-70. Dette var passende til vores kontekst, da vi ikke fik bilen til at køre ind i en kasse som Braitenberg men bare rundt i et lokale med dagslys og lys fra lysstofrør.

Figur 6: Vehicle 2

Put a lamp on top or rear of your vehicle 2a or 2b with two light sensors and try to see what happens when several vehicles are put close together e.g. on a floor in a dark room, Figure 5.

Vi prøvede at lave dette med 2 biler med lys monteret bag på bilerne. Bil 2 der fulgte lyset på bil 1 kørte for hurtigt og kørte baglygten på bil 1 af. Vi skulle nok have brugt en inhibitory forbindelse, så bil 2 ikke kørte op i bil 1 men kørte langsommere jo mere lys der er, dvs. jo tættere den er på at køre op i bagenden på bil 1. Desuden skulle den forreste bil styres af en lygte fra en mobiltelefon, og lyset fra telefonen blev derfor ikke kun opfanget af bil 1 men også af bil 2.

For at få bilerne til at køre efter hinandens lys var vi nødt til at gå ind i et mørkt rum, da lysstyrken på de påsatte pærer var noget lavere end det omgivende lys i labbet. Det betød, at vi var nødt til at ændre vores power-værdi, således at bilen ville reagere på svagere lys end ved kørsel i labbet generelt. Ved at sætte grænsen for hvornår bilen skal reagere på lys ned, betød det også, at bilen ikke fungerede så snart der flød dagslys ind af vinduerne, da dette lys så ville give en power på næsten max.

In Tom Deans description the variables MAX_LIGHT and MIN_LIGHT are updated over all the sample values obtained during the lifetime of the vehicle. If the vehicle is existing for a long time under different light conditions we might only want to collect these values over the last N samples. Make changes to your program so that this is possible. How will you set up an experiment that shows if your changes to the program also influences the behavior of the vehicle?

For at lave dette program lavede vi en min og max value variable for den venstre og højre lyssensor. Vi startede med at have max som en lav værdi og min som en høj værdi og ændrede disse når en hhv. lavere eller højere værdi blev fundet. Vi lavede en normalizeLeft() og en normalizeRight() metode ud fra info fra slides fra forelæsningen [4], og vi satte motor power efter figur

Figur 7 - Ud fra dette lavede vi normalizeLeft() og normalizeRight()

Figur 8 - Ud fra dette satte vi motor power via normalizeLeft() og normalizeRight()

Vi fandt ud, af denne metode ikke er den rigtige måde at gøre bilen adaptiv fordi min og max kun bliver ændret hvis lyssensoren henholdsvis måler en lysværdi som er mindre end min eller større end max. Derfor er den kun adaptiv fra mørke til lysere omgivelser, men ikke omvendt. En måde som gør bilen adaptiv, som vi kunne have implementeret, er ved at lave en liste med f.eks. 100 lysmålinger, hvor nye lysmålinger bliver tilføjet og gamle bliver fjernet dynamisk. I hvert gennemløb af while-løkken tager man den mindste og den største værdi i denne liste og sætter dem til henholdsvis min og max. Det at have en liste som hele tiden bliver ændret dynamisk gør, at hvis bilen er i et mørkt rum i 100 omløb i while-løkken, så har min og max ændret sig, så de passer til et mørkt lokale .

Two ultrasonic sensors can also be used in vehicle 2a and 2b, e.g. mounted as in Figure 6. Watch the video in [3] and try to explain why the vehicle bumps into objects. Can you improve on that?

To mulige årsager til at bilen kører ind i objekter er, at de to ultrasonic sensorer peger ligefrem, og derfor ved den ikke hvilken vej den skal dreje for at undgå objekterne; den anden årsag er at, at de to ultrasonic sensoren sidder for langt ude i siderne, og derfor skal bilen reagere tidligt for at kunne nå at dreje uden at støder ind i objekterne. Vi valgte ikke at arbejde videre med denne opgave, da Vehicle 3 arbejder både med lys og ultrasonic sensoren.

Vehicle 3

In Figure 7 vehicle 3 is shown. It has two kinds of sensors. Try to use light and ultrasonic sensors (or maybe sound sensors to give the Party Finder from Lesson 3 another try). How would you combine the different motor power values coming from the two sensors?

Figur 9: Vehicle 3

Vi prøvede først at forbinde lyssensorerne og ultrasonic sensoren som vist i ovenstående tegning: bilen kører imod lyset via en krydskoblet exibitory forbindelse og væk fra objekter via en inhibitory forbindelse. Dette betyder at bilen speeder en del op på det ene hjul når den er tæt på et objekt i den modsatte side. Vi erfarede at bilen ofte kørte ind i objekter på denne måde. Derfor prøvede vi at forbinde ultrasonic sensoren krydskoblet med en exibitory forbindelse i stedet for, så når bilen er tæt på et objekt i venstre eller højre side reduceres farten for det modsatte hjul: