|
|
[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 |