Lesson 4 -PID line follower

Date: 28/2 2014

Duration of activity: 9.15-15.00

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

---

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

Plan: Gå opgaverne sekventielt igennem.

Results: Vi har gennemført alle opgaverne.

Black White Detection

First, you should mount the sensor on the LEGO 9797 car as described in LEGO Mindstorms Education NXT Base Set 9797 building instruction page 32 to page 34. Second, make a program that use and test the class BlackWhiteSensor.java. After calibration, place the car with the light sensor over different dark and bright areas and investigate how well the BlackWhiteSensor works.

Vi kalibrerede programmet på en hvid og en sort overflade, herefter placerede vi bilen over forskellige farvede overflader. Vi fandt ud af at rød og gul blev detekteret til at være hvid, mens grøn og blå blev detekteret til at være sort.

Line Follower with Calibration

As an application of the BlackWhiteSensor try the program LineFollowerCal.java. The program uses the simple class Car.java to move the car.

Programmet virkede OK men ikke optimalt. Programmet ser grøn som sort da vi kørte bilen på den ovale bane.

 

Billede af bilen påmonteret lyssensor samt mikrofoner fra sidste uges øvelser

ThreeColorSensor with Calibration

Use the idea and structure of the BlackWhiteSensor to program a class ThreeColorSensor that can detect three colors: black, green and white. Make a test program that investigate the usefulness of the class.

Vi lavede klassen ThreeColorSensor ved at have to thresholds i stedet for ét:

1. blackGreenThreshold
2. whiteGreenThreshold

Vi lavede et simpelt testprogram og målte på grønne, sorte og hvide værdier omkring i labbet og erfarede, at ThreeColorSensor er god til at skelne sort, hvid og grøn.

Line Follower that stops in a Goal Zone

Use the ThreeColorSensor to make a line follower that stops in a green goal zone.

Vi gjorde dette ved at modificere LineFollowerCal programmet til også kigge efter den grønne farve som stop condidtion: car.stop(). Vi fandt dog at bilen stoppede af og til når den kørte på den sorte/hvide linje fordi den bare fik 1 måling med grøn. Derfor valgte vi at lave en counter, så det først er når lyssensoren har målt 10 grønne målinger i træk, at bilen stopper:

Dette bevirkede, at bilen kunne køre et gennemløb af banen uden at stoppe undervejs. Dog havde bilen af og til problemer med at komme rundt om hjørnerne.

PID Line Follower

It is possible to make a line follower with just one light sensor that follows the line more smoothly and drive faster if a PID regulator is used, [1]. Try this.

Det var muligt at implementere en PID line follower, så bilen kørte rundt på banen uden at oscillere lige så meget, som den gjorde inden PID blev implementeret. Dog var det ikke let at finde gode værdier for kP, som er den konstant den fejlen bliver ganget med.

På et tidspunkt kørte bilen meget præcist rundt, men da vi ville finjustere eller rette noget begyndte bilen at opføre sig mærkeligt, den begyndte nemlig at bakke, selvom det ifølge koden ikke burde være muligt. Efter lang tids forsøgt fejlfinding, gik vi tilbage til det program, som fungerer næsten til UG, men det opførte sig stadig på uforklarlig vis mærkeligt.

Video hvor bilen kører fornuftigt

Color Sensor

In the LEGO Mindstorms series there is also a color sensor. Use the test program ColorSensorSensor.java to investigate the information that the class ColorSensor provide in Full mode. Place the color sensor over black, white and green to figure out if the information provided can be used to distinguish the three colors.

Vi afprøvde programmet og erfarede at farvesensoren godt kunne detektere farverne rød, gul, grøn, blå, hvid og sort, når vi satte farvesensoren over legoklodser.

Is it possible to use the color sensor for both following the black line and stop in the goal zone?

Vi brugte den samme metode i vi gjorde i opgaven ThreeColorSensor, hvor if-sætninger blev ændret til det nedenstående kodeafsnit, og det fungerede. Vi oplevede dog at mørkegrøn blev opfattet som sort, så bilen stoppede først, når den nåede det lysegrønne felt.

Code-snippet fra LineFollower med stop på grønt felt

Bane hvor vi testede ColorSensor testeren. Den mørkegrønne farve i bunden af billedet blev opfattet som sort, hvorfor det kun var på den lysegrønne farve i baggrunden som bilen stoppede på.

Conclusion:

Vi kom igennem alle ugens opgaver med et tilfredsstillende resultat. Dog havde vi problemer med at få PID controlleren til at køre uden at oscillere, hvilket ville kræve en del mere optimering.

Vi har efter ugens opgaver fået et større indblik i, hvordan en PID controller virker.

References:

[1] PID Controller http://www.inpharmix.com/jps/PID_Controller_For_Lego_Mindstorms_Robots.html

[2] Opgaveformulering http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson4.dir/Lesson.html

Lesson 3 - Lydsensor/mikrofon

Date: 21/2 2014

Duration of activity: 9.15 - 13.15

Group members participating: Christian Hansen, Pætur Askildsen, Søren Gregersen

---

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

Plan: Gå opgaverne sekventielt igennem.

Results: Vi har gennemført alle opgaverne.

Exercise 1 - Test of the Sound Sensor

First, you should mount the sensor on the LEGO 9797 car as described in in LEGO Mindstorms Education NXT Base Set 9797 building instruction page 24 to page 26. Second, program, compile and download a simple sound sensor test program similar to the ultrasonic sensor test program of Lesson 2, SonicSensorTest.java. Place the car at a fixed position and make sounds of different loudness and at different distances. Use this to give a description of the readings from the sound sensor.

Billede 1 - Hvor vi målte afstande fra på alle lydmålinger i denne rapport. Tommestokken er skubbet ind imod det lysegrå plast.

I starten lagde vi mærke til, at der er en baggrundsstøj hvor sensoren konstant måler mellem 1-2. Vejrtrækningning, tastaturklapren, og andre småting gav målinger på op til 5, når bilen stod på bordet mellem computere.

Almindelig “mandesnak” med en afstand på 70 cm giver værdier på 10-20. På 100 cm afstand kom værdierne kun op på 15.

Klap på en afstand af ca. 100 cm giver værdier på mellem 50-60.

	50 cm	1,5 m	3 m
Hvisken	Max 4	< Baggrundsstøj	< Baggrundsstøj
Snak	10-20	Max 20	Max 15
Råb	90	90	90
Klap	76-93	Max 67	Max 70

Når vi kommer ud på en afstand af 1,5-3 m opdagede vi, at værdierne som sensoren målte varierede meget selv med den samme lyd, eksempelvis samme klaprytme. Det virkede som om, at sensoren ikke altid opfangede lydene. Dette er fordi at vi ikke havde ændret sample rate fra SonicSensorTest programmet, så sample rate var 300 ms. Aflæsningerne fra lydsensoren lader til at være i %, 0-100, hvilket også kan ses af [2] under readValue: “Returns: value as a percentage.”

Exercise 2 - Data logger

As described in Lesson 2, a data logger, [1], is a mechanism that can be used to collect and record data from e.g. a sensor for later inspection. In the leJOS system a data logger can be implemented to collect data and record them in a flash file. An example of a simple data logger is DataLogger.java. By means of this data logger e.g. sound data can be collected and recorded in a file Sample.txt as shown in the data collection program SoundSampling.java. The data in the file can then be transfered to the PC by means of the tool nxjbrowse. The sampled data can then be used to plot a graph of the sound level data.

Vi opsamlede data om en fast klapperytme på 1 meters afstand til sensoren, hvor 1 m. er målt fra samme sted på sensoren som set på billede 1.

Dataen er plottet ind i en graf som kan ses herunder.

Exercise 3 - Sound Controlled Car

As a first application of the sound sensor try the program SoundCtrCar.java. The program uses a simple class Car.java to move the car forward, left, right, etc. Describe the behaviour of the car as you make sounds e.g. by shouting or clapping. Describe how the program interprets readings from the sound sensor as loud sounds.

Bilens opførsel består af 4 trin:

1. Ved første høje lyd kører bilen ligeud: Car.forward(100, 100);
2. Ved næste høje lyd drejer bilen til højre om sig selv: Car.forward(100, 0);
3. Ved næste høje lyd drejer bilen til venstre om sig selv: Car.forward(0, 100);
4. Ved næste høje lyd stopper bilen:  Car.stop();

Efter trin 4 starter programmet fra trin 1 igen.

Programmet fortolker målinger fra lyssensoren som høje lyde når lydniveauet er over 90. Dette kan ses i koden:

hvor soundThreshold = 90;

Exercise 4 - ButtonListener

In the program SoundCtrCar.java the ESCAPE button is polled in the outermost loop so that the ESCAPE button can be used to stop the program. This does not work when the program loops in one of the four inner loops. You can make the ESCAPE button always work as a program terminator if you also poll the state of the button in the inner loops. But you can also use the ButtonListener mechanism to listen for the ESCAPE button and exit when ESCAPE is pressed. A simple example of a ButtonListener can be seen in the leJos tutorial, [3]. Try this in the program.

Ved at kigge på den leJos tutorial som er linket til i opgaven [3] fandt vi ud af, at implementere ButtonListeneren. Vi indsatte koden i det første whileloop, og indsatte funktionerne Car.stop(), LCD.clear(), LCDdrawString(), og System.exit() i metoden buttonPressed på ESCAPE button. Koden kan ses herunder:

Exercise 5 - Clap Controlled Car

Sivan Toledo, [2], has investigated how the sound sensor can be used to detect claps. Through an investigation of a sequence of sound sensor readings during a clap he suggest the following method to detect a clap:

A clap is a pattern that starts with a low-amplitude sample (say below 50), followed by a very-high amplitude sample (say above 85) within 25 milliseconds, and then returns back to low (below 50) within another 250 milliseconds.

Try to use his method to detect claps and compare it to the method used in the program SoundCtrCar.java. Use the DataLogger class to record and investigate clap patterns.

Vi har programmeret et klap som beskrevet i opgaven. Koden kan ses her. Vi valgte af tidsmæssige årsager ikke at undersøge vores egne clap patterns.

Exercise 6 - Party Finder Robot

Try to mount two sound sensors and use the readings from these sensors to always drive towards the location with loud sound.

Billede 2 - Opstilling af to lydsensorer påsat vores bil.

Vi målte ud for hver lydsensor på 20 cm med en konstant lyd, som kom fra et smartphone program, for at undersøge om de to mikrofoner opfører sig ens. Vi målte afstanden som det ses på billede 1. Vi fandt ud af at de målte det samme med en forskel på 1 af og til, og derfor besluttede vi os for ikke at lave yderligere kalibrering.

Vi satte et partyThreshold på 40: hvis ingen af mikrofonerne målte et lydniveau på over 40 kørte bilen ligeud. Men så snart en mikrofon målte et lydniveau på over 40 drejede bilen i den retning hvorfra lyden kom. Som koden nedenfor viser, så drejede bilen til højre, hvis den højre mikrofon målte et højere lydniveau end den venstre.

Conclusion:

Vi har gennemført øvelserne og derigennem opnået erfaring med NXT lydsensoren. Ydermere har vi stiftet bekendtskab med hvordan lyd kan styre en bil samt hvordan man kan reducere antallet af lyde som bilen reagerer på, i vores tilfælde et klap.

References:

[1] Opgaveformulering http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson3.dir/Lesson.html

[2] http://www.lejos.org/p_technologies/nxt/nxj/api/lejos/nxt/SoundSensor.html

[3] http://www.lejos.org/nxt/nxj/tutorial/ListenersAndEvents/Listeners_Events.htm

Lesson 2 - Ultrasonic Sensor

Date: 14 + 18. februar 2014

Duration of activity: 9.15-16.00 + 9.15-14.00

Group members participating: Christian Hansen, Pætur Askildsen, Søren Gregersen

---

Goal: At gennemføre ugens opgaver.

Plan: Gå opgaverne sekventielt igennem.

Results: Vi har gennemført alle opgaverne.

Uge 3 - Lesson 2

Exercise 1

Place the car in front of different objects at different distances and compare the distance with the readings from the sensor. Til opgave 1, 2 og 3 brugte vi SonicSensorTest programmet som var stillet til rådighed.

Fysisk måling	Måling på NXT	Forskel
9 cm	14 cm	5 cm
15 cm	21 cm	6 cm
20 cm	24 cm	4 cm
30 cm	33 cm	3 cm
40 cm	42 cm	2 cm
50 cm	52 cm	2 cm

Exercise 2

The test program was compiled and uploaded with leJOS NXJ version alfa_03 as indicated in the comment to the program. Because of a known limitation of alfa_03 there is a 300 msec sample interval between readings of the distance. This limitation is no longer in the README list so try different values of the sample interval e.g. very small values.

Ved samplerate på 10 msec.

Fysisk måling	Måling på NXT	Forskel
9 cm	13 cm	4 cm
15 cm	21 cm	6 cm
20 cm	24 cm	4 cm
30 cm	31 cm	1 cm
50 cm	52 cm	2 cm

Ved samplerate på 1 msec

Fysisk måling	Måling på NXT	Forskel
9 cm	14 cm	5 cm
15 cm	22 cm	7 cm
20 cm	24 cm	4 cm
30 cm	33 cm	3 cm
50 cm	52 cm	2 cm

Forskellen mellem målingerne på de tre tests var meget ens gennem målingerne. Det er mærkværdigt at se, at den største forskel mellem den fysiske måling og målingen på NXT’en er størst ved 15 cm’s afstand på alle tre tests. På afstande over 15 cm falder forskellen gradvist, og bliver mere præcis op til vores største måling på 50 cm.

Exercise 3

The ultrasonic sensor detects objects in front of the sensor by emitting a short high-frequency sound and then listen for echoes. If an echo comes back there is an object in front. The time it takes for the echo to return can be used to measure the distance to the object. If there is no echo within some time limit the situation is interpreted as no object. The method getDistance returns 255 if there is no echo, hence no object, and otherwise a number less than 255 which is the distance in cm. Try to use the sensor with an object at a distance of up to 254 cm, can the sensor measure such a distance and under what conditions is it possible ? What is the time limit for the measurement - remember the speed of sound is 340.29 m/sec ? Does this limit the usage of the sensor ?

Når bilen blev placeret med en afstand på 254 cm fra væggen, viste displayet en afstand på 255 cm. Derfor fandt vi det ikke muligt at måle et objekt på en afstand på 254 cm. Det var først da vi nåede ned på en fysisk afstand på 185 cm, at displayet begyndte at viste den reelle afstand. Vi udregner tidsgrænsen for målingen:

*

Pætur (fra gruppen Team NXT generation) og Alexander (fra gruppen Surdejspianisterne) forsøger at finde den maksimale afstand som NXT’en er i stand til at måle.

Den tid det tager for lyden at rejse fra højttaleren i sensoren hen til væggen og tilbage til mikrofonen i sensoren er:

Det tager altså 10,87 msec for lyden at rejse frem og tilbage. Idet vi har et sample interval på 300 msec, og tidsgrænsen for at måle den maksimale afstand på 185cm er 10,87 msec, begrænser tidsgrænsen ikke brugen af sensoren.

Tracker Beam

As a first application of the sonic sensor try the program Tracker.java. This has been inspired by the "tracker beam" program in Chapter 5. The program uses a simple class Car.java to move the car.

Exercise 4

Describe the behaviour of the car controlled by the program and try to change the different constants of the program. The power to the car motors is the controlled variable and the distance is the measured variable. What kind of control is it?

Ved kørsel af det oprindelige program, kører bilen mod et objekt med en power på 100. Når den nærmer sig et objekt, sætter den farten ned, indtil afstanden til objektet er 35 cm. Når bilen når denne afstand bevæger den sig frem og tilbage hele tiden i oscillerende bevægelser. Hvis man sætter sin hånd foran afstandsmåleren, og afstanden er kortere end 35 cm, bakker bilen og tilpasser afstanden til 35 cm.

Vi ændrede distance til 20 cm og minimum power til 30. Det resulterede i, at bilen kørte tættere på objektet, men sænkede farten hurtigere end ved power på 60. Vi satte den ønskede distance op til 40, her forsøgte vi med en minimum power på 50, 70 og 100. Ved 50 der stoppede bilen, når den nåede den ønskede afstand. Ved power på 70 oscillerende den en smule, mens den på 100 gik fuldstændig amok og endte med at vælte, fordi den, når den nåede den ønskede afstand, bakkede med 100 % power og igen satte 100 % power på at køre frem når denne afstand var tilstrækkelig stor igen.

Der er i systemet tale om en P controller, da den kontrollerede variabel (controlled variable), motorernes power, propertionelt afhænger af den målte variabel, distance, ud fra den nuværende error value.

Exercise 5

Try to make the car oscillate by adjusting the constants in the controller.

Bilen oscillerer allerede en smule når distance er 35 og minPower er 60. Ved at sætte minPower op, oscillerer bilen kraftigere, hvorimod bilen ved en minPower på 50 næsten ikke kører når den kommer ind på den definerede afstand.  

For at integrere derivative delen af PID controlleren, modificerede vi koden en anelse, se billede herunder.

Vi fandt at ved Kp = 3 og ved Kd = 1 oscillerede bilen kun én gang før den stod stille på afstanden 35 cm eller 36 cm, hvor desiredDistance = 35.

*

Screenshot af vores kode efter tilføjelsen af derivative konstanten.

Wall Follower

Philippe Hurbain has build and programmed a wall follower based on the LEGO Mindstorms RCX and a home build distance sensor, [4]. He used NQC (not quite c) to program the controller for the wall follower

Exercise 6

Try to use his program and sensor placement to write a similar program in Java and make the LEGO 9797 car follow a wall. Compare the NQC control algorithm with the different suggestions on page 179, 5.1.3 exercises.

Vi oversatte koden fra Hurbain’s projekt til java og kørte det. Koden kan ses på pastebin.com [1].

En video af vores bil der kører programmet WallFollower.java kan ses her.

Når NQC control algoritmen sammenlignes med forslagene på side 179, 5.1.3 exercises [4], ses det, at NQC control algoritmen minder om pkt. 4, hvor: “... the three-state method  that makes progressively stronger turns as the wall sensor indicates that HandyBug is farther away from the goal distance.” NQC algoritmen bruger netop three-state metoden, se figur herunder, idet hvis man er imellem #define XL1 444 og #define XR1 430 kører bilen ligeud. Hvis man er på den ene eller anden side af denne inner og outer value, jvf. figur herunder, laver bilen progressivt voldsommere drejninger til højre eller venstre ved enten at slukke den ene motor, ved at reducere power på den ene motor eller ved at få den ene motor til at køre baglæns, hvor den anden motor kører fremad.

Three-state metoden, fra slides uge 1.

Conclusion

Vi har med møje og besvær fået alle opgaver til at køre. Specielt opgave 5 og 6 voldte os problemer på lab-dagen, men da vi satte os ned tirsdagen efter, den 18/2 for at gennemgå koden endnu engang, lykkedes det os at forstå det.

Vores WallFollower er ikke blevet så god idet den oscillerer meget, men vi har valgt, efter 10 timers arbejde på ugens opgaver at lade det være, og ikke bruge yderligere tid på at optimere denne.

Vi har fået erfaring med NXT ultrasonic sensoren og vi har fået erfaring med benyttelsen af en P-controller (opgave 4) samt en PD-controller i opgave 5 og 6.

Referencer

[1] http://pastebin.com/jJgJDMM7

[2] Opgavebeskrivelse:  http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/Lesson.html

[3] http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/SonicSensorTest.java

[4] Fred G. Martin, Robotic Explorations: A Hands-on Introduction to Engineering, Prentice Hall, 2001.