... | ... | @@ -4,76 +4,137 @@ |
|
|
|
|
|
**Date:** 03/02 2017
|
|
|
|
|
|
**Gruppemedlemmer:** Alexander, Joachim & Steffen
|
|
|
**Group members:**
|
|
|
- Alexander Qvist-Hellum (201509272)
|
|
|
- Joachim Christiansen Nyborg (201505749)
|
|
|
- Steffen Strunge Mathiesen (201407114)
|
|
|
|
|
|
**Varighed af arbejdet:** 0 hours
|
|
|
**Work duration:** 6 hours
|
|
|
|
|
|
## Mål
|
|
|
I dag vil vi forsøge at få Bluetooth til at fungere, selvom dette måske er en svær udfordring da vi kun har Ubuntu og OSX i gruppen. Efter det vil vi gennemgå opgaverne listet i Lession 1 og løse dem.
|
|
|
## Goal
|
|
|
We want to make bluetooth work, even though it might be a challenge since we only have Linux and OSX in our group. Afterwards, we will solve the exercises listed in Lesson 1.
|
|
|
|
|
|
## Plan
|
|
|
### Bluetooth
|
|
|
Vi vil forsøge at bruge en virtuel maskine til at installere Windows på vores Macs da det ser ud til at være en lettere løsning end at få OSX til at samarbejde med NXT'erne direkte.
|
|
|
Our plan here is to try and use a virtual machine with Windows installed to use bluetooth on our mac, since it seems to be an easier solution than to make OSX work directly with the NXT's.
|
|
|
|
|
|
### Lesson 1
|
|
|
Vi vil følge den givne guide [1]
|
|
|
Here we will follow the given guide [1].
|
|
|
|
|
|
## Results
|
|
|
|
|
|
### Bluetooth
|
|
|
Vi installerede først Windows 7 på VirtualBox, men konkluderede at dette ikke fungerede da vi ikke kunne få adgang til mac'ens bluetooth.
|
|
|
Vi prøvede dernæst med VMWare Fusion hvor alt virkede "out-of-the-box" så snart Java og NXJ.
|
|
|
First we tried installing Windows 7 on VirtualBox, but we concluded that we could not access the Mac hosts bluetooth.
|
|
|
|
|
|
Afterwards, we tried VMWare Fusion with great success - everything worked "out-of-the-box", as soon as Java 6 and NXJ was installed.
|
|
|
|
|
|
### Exercise 1
|
|
|
_Try to place the light sensor above different colors and make a table of light values corresponding to the different colors. Use the light percent values for black and white to explain how the threshold value could be obtained from a reading above black and white._
|
|
|
|
|
|
The read light percent values with floodlight on can be seen in appendix 1 in the column "With Floodlight". These percentages states how light the read colours are, which explains why lighter colours such as white, yellow and red has a higher percentage value than darker colours such as black, green and blue.
|
|
|
|
|
|
De aflæste farveværdier som lyssensoren viste med FloodLight ON kan ses i bilag 1 i kolonnen "Med floodlight".
|
|
|
The thresholds for this sensor can be achieved by reading above black and white, since these are the darkest and lightest colours, correspondingly. Every other colour read should lie between the values for these. In our experiment, the min (black) is 35% and the max (white) is 57%.
|
|
|
|
|
|
### Exercise 2
|
|
|
_The light sensor is used with the red LED turned on because of the method call light.setFloodlight(true). This means that the sensor measures the reflection of the red LED. Try to turn the LED off and notice the differens in measurements obtained by making a similar table of readings above different colors. With the LED turned off the ambient light level is measured. This is e.g. usefull in day/night detection._
|
|
|
|
|
|
De aflæste farveværdier som lyssensoren viste med FloodLight OFF kan ses i bilag 1 i kolonnen "Uden floodlight".
|
|
|
The read light percent values with floodlight off can be seen in appendix 1 in the column "Without Floodlight". The values for black and white have a noticeable difference (30% vs. 43%), however, the readings for the colours red, green, blue and yellow mostly flow together, making them harder to distinguish than with the floodlight on. We see that the floodlight is useful when you want to distinguish colours, whereas with the floodlight off we can only distinguish black/white (or day/night).
|
|
|
|
|
|
Vi bemærkede desuden at hvis vi stod i nærheden af enheden så kunne vi påvirke dens aflæsninger. Derudover konkluderede vi også at vi burde sørge for at orienteringen er den samme i alle målinger, således at lyset påvirkede resultatet ens uanset hvilken måling vi var ved.
|
|
|
In this exercise we also noticed that if we stood near the NXT unit, we could affect its readings. We also concluded that we should make sure that the orientation is the same in all reading, such that the room light effects the results in the same way no matter which reading we were doing.
|
|
|
|
|
|
### Exercise 3
|
|
|
Med standard-værdien til forsinkelsen imellem målinger på 10ms kunne den fint følge linjen. Dog var det bang-bang idet at den kørte frem og tilbage over linjen med store svinginger.
|
|
|
_In the program a delay of 10 msec is used between light sensor readings. We call this the sample interval. Try to let the car follow the line with a sample interval of 100 msec, 500 msec and 1000 msec. Explain what happends._
|
|
|
|
|
|
Med 100 ms kunne den i starten godt følge linjen, men efter lidt kørte den helt forbi linjen idet at den nåede at køre helt over linjen mellem en opdatering (som jo netop var 100ms)
|
|
|
Med 500 ms var det helt hen i vejret og den nåede ikke observere linjen inden den var kørt hen over den, da der gik hele 500ms imellem hver aflæsning.
|
|
|
With the default delay between measurings at 10ms it perfectly followed the line. It was a bang-bang experience due to the fact that either one of the engines was running, it wasn't a smooth transition when it crossed the line.
|
|
|
|
|
|
At 100ms it was also able to follow the line, but after a while it ended up missing the line completely meaning that it ended up going in circles.
|
|
|
|
|
|
### Exercise 4
|
|
|
Vi prøvede med følgende intervaller: 10, 20, 50, 100 og 500
|
|
|
At 500ms it completely missed the mark and couldn't see the line at all. The time between measurements was simply too high.
|
|
|
|
|
|
### Exercise 5
|
|
|
Træbord: 487
|
|
|
Macbook Pro 2013 402
|
|
|
Macbook Pro 2013 skærm (hvidt billede) 578
|
|
|
Steffen lewis 501 september 2015 (brugt hver 3. dag)
|
|
|
Blå 620
|
|
|
Sort 653, 642
|
|
|
Hvid 421
|
|
|
Rød: 435
|
|
|
Gul: 421
|
|
|
### Exercise 4: Datalogger
|
|
|
_Try to let the car follow a line with different sample intervals and see how this influences the oscillations in the graph._
|
|
|
|
|
|
We tried with the intervals 10, 20, 50, 100, and 500. The plots for the different intervals can be seen below.
|
|
|
|
|
|
![Figure 1 showing samples](https://gitlab.au.dk/ssm555/lego/raw/50de2859d2d657461a57fadc876dce7e8f6a6304/Rapport1/images/LFGraph10.png)
|
|
|
_Figure 1: Sample interval of 10_
|
|
|
|
|
|
The first frequency we tested was the default 10ms and it shows good promise as it slowly increases and decreases. We can see a small jump around 5000, 9000, and 14000 that all correspond to the crossing lines that it meets while following the line.
|
|
|
|
|
|
![Figure 2 showing samples](https://gitlab.au.dk/ssm555/lego/raw/50de2859d2d657461a57fadc876dce7e8f6a6304/Rapport1/images/LFGraph20.png)
|
|
|
_Figure 2: Sample interval of 20_
|
|
|
|
|
|
The second frequency, 20ms, shows the same behavior as the first.
|
|
|
|
|
|
![Figure 3 showing samples](https://gitlab.au.dk/ssm555/lego/raw/50de2859d2d657461a57fadc876dce7e8f6a6304/Rapport1/images/LFGraph50.png)
|
|
|
_Figure 3: Sample interval of 50_
|
|
|
|
|
|
Our third frequency, 50ms, shows a lot less fluctuations, but still manages to follow the line. We do see an interesting fluctuation at around 17500, but we believe it was just the same crossing line as above.
|
|
|
|
|
|
![Figure 4 showing samples](https://gitlab.au.dk/ssm555/lego/raw/50de2859d2d657461a57fadc876dce7e8f6a6304/Rapport1/images/LFGraph100.png)
|
|
|
_Figure 4: Sample interval of 100_
|
|
|
|
|
|
The fourth frequency, 100ms, doesn't initially show anything alarming, except the fluctuations, but the robot actually ended up taking one of the crossing lines and ending up following the edges of a green square. That's also why we see an initial colour value around 36, but after roughly 5000ms the colour value never goes below 40. As it can be seen in Appendix 1, the green colour value is around 43%, which roughly matches what the plot shows.
|
|
|
|
|
|
![Figure 5 showing samples](https://gitlab.au.dk/ssm555/lego/raw/50de2859d2d657461a57fadc876dce7e8f6a6304/Rapport1/images/LFGraph500.png)
|
|
|
_Figure 5: Sample interval of 500_
|
|
|
|
|
|
The last frequency, 500ms, completely missed the mark. It started on the black line, but immediately started turning in a circle because the update frequency was too low. Sometimes it would register the black line momentarily, as it can be seen in the graph at roughly 6000, 10000, 15000 and 25000. But ultimately 500ms was too much, and it couldn't follow the line at all.
|
|
|
|
|
|
### Exercise 5
|
|
|
_In the LightSensor class the method readValue calculates a light percent according to this formula if none of the calibration methods have been used in the class:_
|
|
|
```
|
|
|
lightPercent = 100*( 1-rawValue/1023)
|
|
|
```
|
|
|
_The rawValue is the 10 bit digital value between 0 and 1023 that is obtained directly from the light sensor by the AD conversion (analog to digital conversion). In the program SensorPortTest.java the raw values from the light sensor is displayed on the LCD. Make some experiments that justifies the formula that describes the relation between the light percent and the raw values. Could there be a reason for using the raw values instead of the light percent?_
|
|
|
|
|
|
|
|
|
| Object | Raw Value |
|
|
|
| ------ | ------- |
|
|
|
| Wooden table | 487 |
|
|
|
| Macbook Pro 2013 | 402 |
|
|
|
| Macbook Pro 2013 monitor (white image) | 578 |
|
|
|
| Steffen's Levi's 501 from September 2015 (used every 3 weeks) | 611, 635, 651 |
|
|
|
| Blue | 620 |
|
|
|
| Black | 653, 642 |
|
|
|
| White | 421 |
|
|
|
| Red | 435 |
|
|
|
| Yellow | 421 |
|
|
|
|
|
|
The formula makes sense, since we just calculate the reading according the the max value and afterwards calculate to percentage. The only reason we can find for using the raw values is that you get what corresponds to an extra decimal for precise computations.
|
|
|
|
|
|
### Exercise 6
|
|
|
|
|
|
We first tested with the default program, that is with the variables left and right, and outputted the value of Runtime.getRuntime().freeMemory() on the LCD. We observed that it started around 55.000 and slowly decreased towards 48.000 followed by a jump back to 55.000 where the process started over again. A plot of the free memory can be seen in figure 6.
|
|
|
|
|
|
![Figure 1 showing free memory with variable use](https://gitlab.au.dk/ssm555/lego/raw/50de2859d2d657461a57fadc876dce7e8f6a6304/Rapport1/images/StringVariable.png)
|
|
|
_Figure 6: Using string variables_
|
|
|
|
|
|
## Bilag
|
|
|
After that we tried using the string values "left" and "right" directly instead of using variables. The first run threw an exception after approximately 30 seconds (figure 7), but the second run worked out just fine. By the looks of it using the variable expresses the exact same behavior, decreasing, jumping back to 55.000 and then starting over again. A plot of the free memory for this execution can be seen in figure figure 8.
|
|
|
|
|
|
### Bilag 1
|
|
|
Percent angiver
|
|
|
| Farve | Med floodlight | Uden floodlight |
|
|
|
| ------- | -------------- | --------------- |
|
|
|
| Hvid | 57% | 43% |
|
|
|
| Sort | 35% | 30% |
|
|
|
| Grøn | 43% | 36% |
|
|
|
| Rød | 56% | 41% |
|
|
|
| Gul | 56% | 39% |
|
|
|
| Blå | 34% | 37% |
|
|
|
![Figure 1 showing free memory with direct string use](https://gitlab.au.dk/ssm555/lego/raw/50de2859d2d657461a57fadc876dce7e8f6a6304/Rapport1/images/Exception.JPG)
|
|
|
_Figure 7: Bad Address Exception_
|
|
|
|
|
|
![Figure 1 showing free memory with direct string use](https://gitlab.au.dk/ssm555/lego/raw/50de2859d2d657461a57fadc876dce7e8f6a6304/Rapport1/images/StringDirect.png)
|
|
|
_Figure 8: Using direct strings_
|
|
|
## Appendixes
|
|
|
|
|
|
### Appendix 1
|
|
|
|
|
|
| Colours | With floodlight | Without floodlight |
|
|
|
| ------- | --------------- | ------------------ |
|
|
|
| White | 57% | 43% |
|
|
|
| Black | 35% | 30% |
|
|
|
| Green | 43% | 36% |
|
|
|
| Red | 56% | 41% |
|
|
|
| Yellow | 56% | 39% |
|
|
|
| Blue | 34% | 37% |
|
|
|
|
|
|
## Conclusion
|
|
|
|
|
|
We ended up getting bluetooth to work by using a Virtual Machine running Windows 7. We first tried VirtualBox but failed, after which we tried VMWare Fusion and succeeded.
|
|
|
|
|
|
We solved the exercises in Lesson 1 and saw some interesting results when changing the update frequency.
|
|
|
|
|
|
## References
|
|
|
[1] http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson1.dir/Lesson.html |
|
|
\ No newline at end of file |