Week 2

We experiment with the NXT light sensor and complete the exercises for Lego Lab 1.

Goal

To complete the exercises for Lego Lab 1.

We are given a LineFollower program to experiment with. The LineFollower is an NXJ robot that follows black lines by using a light sensor to measure the amount of reflected light. Black reflects less light than white and this is exploited in the program by turning the robot right on white sensor values and left on black sensor values. This results is the robot following a line along its left edge.

Plan

Since our goal is to complete the exercises for this weeks lab the plan will be to complete each exercise in sequence:

1. Exercise 1: Light sensor measurements with flood light on
2. Exercise 2: Light sensor measurements with flood light off
3. Exercise 3: Experiment with delays between light sensor readings in LineFollower program
4. Exercise 4: DataLogger: Experiment with sample rate in LineFollower program
5. Exercise 5: Experiment with LCD.drawString() and memory usage

Exercise 1 and 2

We wanted to test if it was possible to use the LightSensor to detect different colors.

Factors

We thought about what kind of factors might influence our experiment:

• Ambient Light: The amount of light in the surroundings. This could interfere with the light readings of the light sensor.
• Material surface: Flat surface vs rugged surface.
• Distance from sensor: Different distances will yield different results.

Experimentation

Before making our final setup, we tried experimenting with material surface.

Figure 1: Rugged lego bricks

We tried two kinds of materials, one with flat Lego bricks having studs as our rugged surface (See Figure 1) and then some Lego bricks with a flat surface (See Figure 2).

We found that the light values read from the sensor when using the rugged Lego bricks varied a lot depending on the material position under the sensor. The flat surface did not have such a problem.

Figure 2: Flat pieces

We also found that ambient light, while testing without the sensor floodlight had a tremendous influence. For example, it made a big difference if we were leaning over the robot and therefore shadowing for the ambient light or not. We therefore must make sure to not influence our readings in our experiment.

Setup

Figure 3: Test setup

As can be seen on Figure 3, we have used the standard NXT Lego robot. We have raised it a bit with some flat Lego bricks (marked in red circles) under the NXT's wheels to allow our test material to enter under the sensor.

Results

Here are the raw light results:

Floodlight Corlor	ON	OFF
Black	31	26
Yellow	61	40
Red	58	38
White	62	41
Blue	36	32

Conclusions

If we were to read the value 60 while having the floodlight turned on, it would be impossible to tell what color was under the sensor, since the light values are so close to eachother. It could be red, yellow or white. The same holds for when the having the floodlight turned off.

All in all, we do not believe it is possible to use the LightSensor to detect colors. It can detect what it was designed for - the amount of light returned. This can of course be used to detect lighter colors from darker ones.

Exercise 3

In this exercise we will experiment with the delay in the control-loop (see figure 4) and see what happens when increasing it from the default 10ms to 100ms, 500ms and 1000ms.

Figure 4: Control-loop delay in LineFollower

Hypothesis

Increasing the delay means that the robot will have a harder time following the line.

Results

100ms

The robot follows the line for 1 or 2 seconds whereafter it starts turning right. When turning right it will sometimes start following the line again for 1-2 seconds until the process repeats.

500ms/1000ms

With 500 or 1000ms delay the robot is completely unable to follow a line. 

Analysis

With a polling rate of 100ms the robot is able to follow the line for a few seconds but eventually looses sight of it. This was expected as the line isn't very thick and it is therefore likely that the robot doesn't poll the sensor quickly enough to see it before passing over it. Recall that the robot works by turning right on white and left on black thus if it doesn't see black at all it thinks it still needs to turn right to get onto the line. The result is that it will skip the line and keep turning right until hitting the line again (if ever) at which point the process repeats.

A polling rate of 500/1000ms rendered the robot completely unable to follow lines with the same argumentation as for the 100ms case.

Exercise 4

In this exercise we will use the supplied DataLogger to log the light sensor values in the LineFollower program and use these to experiment with different sample rates to see their effects on the oscillations of the  robot. We use the provided SLineFollower program updated with data logging.

Hypothesis

Increasing the sample rate will increase the frequency of the robots oscillations. 

Results

Exercise 5

We are asked what happens with memory usage if a String is created for each LCD.drawString(...) call in the LineFollower program.

Hypothesis

Figure 5: Memory test programs

We believe that the amount of memory free will be decreased for each iteration of the while loop.

Results

Instead of modifying the code for the LineFollower program, we made two simple test programs, seen in Figure 5.

The first program, called test1, creates a local String object for each iteration of the while loop, and then writes to the LCD the amount of available memory left. Looking at the display, we could see that the amount of available memory decreases from ~58.000 bytes down to ~42.000 bytes. At this point garbage collection kicks in and we now have our ~58.000 bytes available again.

Our second, program called test2, does not create a local String object to throw away. Instead it uses one local variable on the stack and uses drawInt(...) to write the amount of available memory left to the screen. This program has fixed amount of memory used, which resulted in a steady 58.984 bytes being free memory.