Copy pasted the report authored by Camilla Marie Vinther Frederiksen's avatar Camilla Marie Vinther Frederiksen
[Lesson 1](https://gitlab.au.dk/LEGO/lego-kode/edit/master/report_week6.md)
\ No newline at end of file
## Lab Notebook Lesson 1
**Date:** 11th of Febuary 2016
**Group number:** Group 14
**Group members participating:** Camilla Vinther Frederiksen, Ida Larsen-Ledet, Nicolai Nibe and Emil Platz
**Activity duration:** 3 hours
## Goal
Understanding of PID controllers and Embedded Java API, as described in the
[lesson plan](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson1.dir/Lesson.html "Lesson plan").
## Plan
Our plan is to follow the instructions and complete the task of the lesson plan.
## Results
### Exercise 1: Sensing different colors (floodlight on - reflective mode)
The exercise was done during the first hour of our work, starting from half past 2 pm, so the light was relatively bright (see following picture).
We made a note of this as we later repeated some measurements and the lighting had changed substantially, which we made sure to take into consideration
when discussing them.
![Light at beginning of lab session](week3_pictures/IMG_2181.JPG)
By moving the NXT around and placing its sensor over different colors we obtained the following readings:
| Black | White | Yellow | Red | Green | Blue |
| --- | --- | --- | --- | --- | --- |
| 32 | 57 | 56 | 55 | 44 | 40 |
These reflective mode readings are used by the LineFollower program, which uses a threshold of 45 percent to distinguish between black and white.
This threshold is by our measurements a good threshold since it is approximately in the middle of the values of the readings for black and white,
and therefore is a resonable estimate for the reading that our sensor should pick up when right on the border between white/black.
Alternatively we could just have measured a reading exactly on the white/black border and used this as a threshold. We however suspect that if there
had been more light in the room, our readings would have been higher and the threshold might be too low, or conversely too high if the room was darker.
![Obtaining the green reading](week3_pictures/IMG_2177.JPG "Green reading")
### Exercise 2: Sensing different colors (floodlight off - ambient mode)
The lighting level was the same as in exercise 1, as the measurements for the two exercises were performed immediately after each other.
| Black | White | Yellow | Red | Green | Blue |
| --- | --- | --- | --- | --- | --- |
| 20 | 40 | 38 | 40 | 36 | 36 |
We see here that the ambient-mode readings are much harder to seperate, as there wasn't a lot of light in the building. We expect that these would
have been better, if the test had been done outside in broad daylight. In our case it's still possible to differentiate between white and black,
but the other colors are very close (to each other and to white as well) in values.
If we wanted to determine whether it's night or day, ambient would be better than reflective, since the "fake light" from the floodlight does not
affect the reading, though there could of course be other light sources around for the sensor to read and misconstrue as daylight.
### Exercise 3: Trying out different sample intervals
The sample interval is used by the LineFollower program to stop reading sensor values for a given period of time before contacting the sensor again
and react on the resulting reading. When increasing this value, the system is saving power as it is performing fewer computations over a given time period.
It however also decreases accuracy of the program (on following the line) as it is now possible that a significant reading of color happens during a
program break and therefore isn't reacted on - e.g. a reading of black when looking for the line is missed and therefore the robot keeps on turning.
__10 ms__: The NXT follows the line very well.
__100 ms__: The higher interval results in the robot losing track of the line sometimes, as it measures white and turns right, but then passes the black line
before another sensor reading is requested (as described in the discussion above). The program then assumes that is hasn't reached the line yet, resulting in
the robot continuing in a circular motion until it hits the line again and either misses the significant reading again or registers that it has in fact
reached the line.
__500 ms__: This value results in quite a lot of circles. Sometimes brief corrections, when serendipity causes it to request a reading when right above
the black line.
__1000 ms__: Perhaps we now know how crop circles are made.
From this little experiment with the sample interval, we conclude that the 10 ms value works the best among the tested values. We could however have tried
values between 10 and 100 since the latter wasn't that bad, and a higher value would increase battery life.
### Exercise 4:
The data and the plots show exactly what we observed in exercise 3. For 10 ms we get a nice and steady curve with just abour equal amounts of white and black
readings. For 100 ms we get the same except for a few spikes where we miss a black reading and do a 180-degree turn. For 500 ms we get many more white
readings than black, and for 1000 ms we almost don't get any black readings.
10ms sample rate:
![Sample 10 plot](data/w3_plots/ex4_Sample10.png)
100ms sample rate:
![Sample 100 plot](data/w3_plots/ex4_Sample100.png)
500ms sample rate:
![Sample 500 plot](data/w3_plots/ex4_Sample500.png)
1000ms sample rate:
![Sample 1000 plot](data/w3_plots/ex4_Sample1000.png)
### Exercise 5:
In this exercise we experimented with the raw values of the light sensor in both ambient and reflective mode.
The reason behind these experiments was that we wanted to compare with values from exercise 1 and 2.
The resulting values are given in the following table, where it is important to note that the light in the room was
markedly different at this point than that of the earlier exercises (as also mentioned earlier).
This will however not affect the comparison, as it will be relative between numbers found in the same lighting.
| | Ambient | Reflective |
| --- | --- | --- |
|Black | 849 | 691 |
|White | 679 | 442 |
|Yellow | 695 | 437 |
|Red | 709 | 450 |
|Green | 732 | 572 |
|Blue | 744 | 610 |
The first thing that we noticed about the raw-values is that they are 'opposite' - i.e. reading values of black are high,
and reading values of white are low. The raw values might be calculated by deducting the light measurement from a number
(expressing for instance 100 %) which would result in black being the high and white the low.
Secondly, as a result of the larger resolution there is a greater interval between different colors, as opposed to the
percentage values used earlier. This makes it easier to distinguish between different colors - epsecially colors that reflect
very similar amounts of light - e.g. blue and green. The greater resolutin of the raw data might mean that these values are
better for programmic use. The percentages however, will be better when presented to a human user as they vary less for each
color than the raw values and are easier to read and understand.
Thirdly, using the raw values might increase battery life, as the robot will be able to skip the calculation that is perfomed
in order to report the percentage value every time a sensor reading is received. This is especially relevant if we were working
with a smaller embededed system than the NTX, or one that should perform without being recharged for a long period of time.
We discussed the calculation method where the fraction is subtracted from 1, instead of just being presented as it is. This might,
again, just be a consideration towards user interpretation - a percentage value that increases with the light level is more intuitive
than a number for which high values imply high 'lack' of light.
## Exercise 6
When providing strings directly as arguments, the amount of memory decreases over a brief period of time and then jumps back to the
highest value. We interpret this as being because the amount of free memory decreases when the strings are used and is then freed again
afterwards. Every time the loop runs, a new piece of memory is allocated and then when the garbage collector wants to free up
some memory which it deallocates since the strings aren't in scope anymore. When allocating a string outside of the loop (in this case
when setting a field variable), the garbage collector doesn't recollect the string memory, because the string is still used, but it doesn't
need to either, since we only allocate the one piece of memory.
What we think we saw was that when variables were used to hold the string values, the amount of free memory slowly decreased until some point;
and in the case where the strings were not kept in variables, the amount of free memory rappidly decreased until a somewhat similar point. The
'some point' will be where the JVM garbage collecter decides to clean up allocated memory. The reason why the 'non-variable'-case decreases more
rappidly than the 'variable' case is that it allocates memory for the two strings every time the code is run, instead of just using the same
memory every time.
## WAT - issues with names for log files
For whatever inexplicable reason, the application would crash immediately on startup when run on the NXT, if the filename set for the
DataLogger to save the data to were whatever names the NXT decided it didn't like. Most names caused it to crash. Some didn't. We need
a degree from Hogwartz to figure this one out. Or perhaps a discussion during the break at the next lecture.
## Conclusion
Each of the exercises has shown interesting behavior and data from the LineFollower program. We have also changed and manipulated the program
and learned from the observations. We suspect that these low-level observations have provided us with some useful insights that might help
spur us on to thinking in the right frame of mind regarding robot programming :)
\ No newline at end of file