Report from labsession 1

Starting up
Participants:
Johan & Jacob
2 hours, 2nd september 2010
task: http://legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson1.dir/Lesson.html

Without any huge problems "The Failbot 9797" was built.
LeJOS was downloaded, and after having downloaded the stand-alone NXT driver from lego.com, nxjflashg, handled the firmware flashing expertly.

The first basic intelligence
Our robot started with no means of interacting with or interpreting the world, so we set out to empower it.
We downloaded the java code posted on the exercise sheet, compiled it and transferred it via bluetooth to the failbot.
The first test run on the black line was a succes. The failbot climbed steadily up the ramp, following the line nicely.
Now with our senses enable we generated the following table of light reflected by surfaces with and without the floodlight turned on:

Place:	Floodlight on:	Floodlight off
Wooden table	53	23
Bordeux chair	37	20
Grey laminate floor	46	16
Whiteboard	54	29
Black cabinet	32	15
Blue laminate floor	38	28
Blue carpet	34	27
Green end zone	35	26

This table clearly shows that a decent threshold value can be obtained from the average of the black and white values. It also shows that the reflected light is almost necessary to get enough variation between light and dark areas allowing us to consistently determine which type of surface we are sampling from.

Reaction times:
Having established a bunch of values and a base robot actually capable of doing something we went forward meddling with the sample frequency to determine what effect it has.
Starting with a sample interval of ~10 ms ( determined by Thread.sleep(10)),
The Failbot climbed up along the black line, without ever being close to crossing it.
Lowering the interval to 5 and 1 ms, respectively did not yield any visible alteration in the performance of The Failbot. Perhaps multiple runs should be timed to see whether the sample frequency has a negative effect when lowered.
Increasing the sample interval to 50 ms led to bigger arcs in the movement of The Failbot when following the line. The Failbot did still perform nicely with regards to stay near the line.
At 100 ms sample intervals The Failbot starts to fail. It crosses the black line without detecting it quite often, if  put close to the line and quite parallel to it, it stays with the line for quite a long time though.
For a sample interval of 500 and 1000 miliseconds the robot mostly spins around, and sometimes change direction momentarily when crossing the black line coincidentally with a sample happening, this is not happening that often though.

Cluttered Minds
Now we toyed a bit with the memory part of the brain. Specifically we passed string literals to the LCD.drawString() method, and compared how much clutter this introduced to the memory to the amount of clutter when using predeclared constant strings. When the constant strings were used the amount of free memory did not change while the program was running, quite contrary to this, when string literals were used, the memory available dwindled away at quite a fast rate. This proceeded until the garbage collector ran and freed a bunch of memory, that then again started dwindling away.
This could lead to problems when working with a robot requiring real-time performance.
On such a small computer as the NXT the act of running the garbage collector might have a notable effect on the performance of the unit.

Conclusions
Perhaps more diverse results would come from testing the robot with varying sample times on both the straight line and the more winding road. As this might lead to different conditions emphasizing the strengths and weaknesses of the different sample frequencies.
Also a further experiment would be to time the runs for different sample times, and also motor speeds to find the optimum sample time to solve a given problem.