It would make sense to pick the black/white threshold such that there is as much distance to both the black and white light values as possible. That means the threshold should be in the middle of the black and white light values which is our case is 43,5. In `LineFollower.java` the threshold is 45 which, when considering possible uncertainties of measurement, is indeed the middle value.
### Exercise 2
We first turned the floodlight off, like so:
```java
light.setFloodlight(false);
```
Our measured values are recorded in the following table:
To change the sampling interval we changed the values of the following variable.
To change the sampling interval we changed the value of the following variable.
```java
finalintsampleInterval=100;// ms
finalintsampleInterval=<value>
```
As required in the exercise we tried sample intervals of 100, 500, and 1000 milliseconds.
Below are links to short video clips of the robot trying to follow the black line for each of the sampling intervals:
[Interval of 100](https://www.dropbox.com/home/Lego/lab1?preview=black-line-100ms.mp4)
[Interval of 500](https://www.dropbox.com/home/Lego/lab1?preview=black-line-500ms.mp4)
[Interval of 1000](https://www.dropbox.com/home/Lego/lab1?preview=black-line-1000ms.mp4)
As the video clips show, the robot did reasonably well when using a sampling interval of 100 ms.
However, at sampling intervals of both 500 and 1000 ms, the robot performed poorly.
The explanation is that in order for the robot to change direction when it crosses the black line the robot has to sample during the time the light sensor is above the black line. At sampling intervals of 500 and 1000 ms the probability of the light sensor passing over the black line while sampling becomes quite low and, as a result, the robot often doesn't change direction when passing over the black line.
### Exercise 4
Again we change the `sampleInterval`, but this time to 10, 20 40, 80, 100 milliseconds.
---
---
---
---
Again we change the sampleInterval, but this time to 10, 20 40, 80, 100.
The primary observation is that as the sampling interval increases, so does the oscillation period.
The reason is that when the sampling interval is small the robot quickly discovers that the light sensor has transitioned between a black and white area which results in smaller oscillation periods (and smaller turns).
### Exercise 5
The light conditions doing the experiment was little to no natural light with indoor lighting. [What does this influence?]
with LED off: 184 when flashlight directly into the sensor. 878 when covering with a hand.
We did a small experiment where we turned the floodlight LED off and measured the light sensor's raw value. Specifically, we tried to shine a flashlight directly into the sensor which gave a reading of 184. We then covered the sensor with a hand which gave a reading of 878.
The first thing this experiment shows is that as the light intensity increases, the sensor reading decreases. Intuitively we would expect it to be the other way around which explains the light percentage formula, where a sensor reading of 0 (max brightness) is 100% and a sensor reading of 1023 (total darkness) is 0%.
The experiment also shows that it's not practically possible to get below approx. 184 and above approx. 878. It could therefore make sense to treat these values as absolute darkness and brightness, respectively.
### Exercise 6
The experiment was to see the difference in heap size when using String literal directly in the call versus declaring a variable and referencing that.
The purpose of the experiment was to see the difference in heap size when using String literal directly in the call versus declaring a variable and referencing that. To see the heap size we used `Runtime.getRuntime().freeMemory()` to get the available memory and we then wrote to the display so we were able to read it off.
The following code example shows the initial code which would reference a declared variable that was allocated on the heap.
The initial code was referencing a variable as in the following example:
```java
Stringleft="Turn left ";
...
LCD.drawString(left,0,1);
```
Using `Runtime.getRuntime().freeMemory()` we got the available memory, which we then wrote to the screen so
The available memory while running this program is 56152 bytes.
Running
In the following code example the variable has been replaced with the string literal instead.
```java
LCD.drawString("Turn left ",0,1);
```
when using strings litterals: 56152 free mem.
when using variables: 56664 free mem.
The available memory this time is 56664 bytes, which makes out to a difference of 512 bytes compared to the previous example. This is around 0.91% of the first code examples free memory. The difference is therefore not very large, but for embedded devices where we might not have very much memory at hand this could make a difference in large programs.
## Conclusion
## References
\ No newline at end of file
In this week we have looked at a range of aspects of the car we built. We looked at the light sensor, specifically, in exercises 1 and 2, where we saw that lighter colors gives a higher output from the sensor, and the difference in whether the floodlight was on or off.
In exercises 3 and 4 we learned that with the setup of this lab lesson the car does not work well with a sample interval of bigger than 100ms, which is why we choose to log the sample intervals that we did.
In exercise 5 we looked at how the light percentage of the light sensor is calculated and saw that even when we were trying to max out the light percentage we couldn't get it higher than 878 out of 1023, meaning that the percentage interval is broader than what is actually reachable. The same goes for values near 0, as we couldn't get it below 184.
In the last exercise we saw that using variables instead of string literals can make a difference with regards to memory use. As noted in the exercise the difference wasn't huge but with microcontrollers with low memory and a huge control program this could be very important.
Our goal of completing all of the exercises was therefore accomplished. As for the goal of getting our setup to work we partially accomplished it by getting a working setup with USB. The setup has the mild inconvenience of having to unplug and replug the USB for it to work. Our continued work will be on getting Bluetooth to work, which will alleviate the problem with the USB and be valuable in adjusting parameters in the coming weeks.
