Lab session 1 : introduction

Date: 2. September 2010

Duration of activity: 3,5 hours (11:00 - 14:30)

Group members participating : all group members, that is Anders Dyhrberg, Guillaume Depoyant, Michaël Ludmann and Michal Owsinski.

I. Objectives and summary

I. 1. Objectives

Install the leJOS Java system

Compil and upload a program to the NXT control unit

Experiment with the light sensor

I. 2. Summary

During this lab session, we managed to :

• Install leJOS, flash the NXT brick and be able to send a program on it - at least with an USB cable
• Construct a LEGO robot with an light sensor
• Make the LEGO robot follow a black line
• Take samples of values read by the light sensor
• Show the impact of sampling frequency
• Draw some conclusions about the memory of the NXT

• Start this blog and write our first lab note
• Create a mailing-list : you can write an email to our team using lego_international [at] googlegroups [dot] com

II. Results

II. 1. Making it work : the struggle

Making it all work was not an easy task. First we tried to install the LEJOS on a mac platform, but there was a problem with USB driver, so we had to find another platform. We used lab PC for it, download the USB driver and install the LEJOS. We tried to use Eclipse to work with LEJOS software but without success. So in the end we decided to work just on bat files and notepad - at least with success. We spent almost half of the lab time for this task but we still managed to complete the other tasks. Results are below.

II. 2. Testing the light sensor

The primary use of the light sensor is for detecting different levels of light reflectivity at close range.

Besides the sensor itself, there is a small LED which is used to shine a light on close objects, while the light sensor mesures how much light is reflected back. Such a feature can be useful when you want to design a line follower robot, as we have just done it, or to differentiate between two or more colours. If the colours are bright enough, then the values returned by the sensor will be different enough to tell which colour is currently on the surface tested by the sensor.

We have taken some values depending on the colours - you can see them in the table below. The darker the surface is, the lower the value will be. Provided this information, it then seems obvious that line-following will be more efficient when the line is black and the floor white (and vice versa). The advantage of the light emitted by the LED is that the sensor is less sensitive to ambient light, and the values read should not differ so much when placed in a well-lit room or a darker one - as long as the sensor stay close to the surface. But the drawback is that a really shiny surface will reflect almost all the light in the sensor (if put directly upon it) no matter which the colour is.

It is also possible to disable the LED while using the light sensor. In this mode it can be used to measure surrounding or ambient light levels. But it will be bad at making a relevant difference between colours. We can then think of robots which wake up when someone turn on the light in a room, or when the night comes. A robot can be also build in such a way that it will always avoid dark areas or look for the brightest light.

Light values (percent) corresponding to colours

Floodlight	Red	Yellow	Blue	Green	White	Black
On	57	64	46	55	64	40
Off	39	44	32	40	44	26

Anyway, the light sensor depends a lot on the ambient light, that is why we should always consider calibrating it when we want to use it for a reliable robot. A good thing for the line-follower could be to isolate the sensor and have the robot calibrate itself just before beginning its routine.

II. 3. Line tracking / Sampling frequency

To understand the importance of the frequency (the sample interval) with the robot and the impact of this figure on the trajectory of the robot, we used four different measures and watched how the robot reacted.

We sampled the frequency 10ms, 100ms, 500ms and 1000ms.

So as to test the robot, we actually used two different types of lines:

- the first one was the main line that the robot had to follow (approximately 4-5 cm wide)

- the second one was thiner (approximately 1 cm wide)

	10 ms	100ms	500 ms	1000 ms
Wide line	✔	✔	✘	✘
Thin line	✔	✘	✘	✘

This table gives a rapid overview of the behavior of the robot, but in order to be exhaustive, we should state that the robot can only follow the thin line with the frequency 10 ms, all the other one did not give any positive result. But with the wide line it was different because the robot could follow the line with 100 ms but it had some difficulties to stay focused (he lost his goal a few times).

What we should highlight is that it may be more costly to have a high frequency (maybe in term of power saving) but we could have another results with different parameters such as the radius of the wheels, the lenght of the chassis, the speed of the rotation of the motors, the position of the sensor and so on. So the question being would be to wonder if we couldn't find a spatial configuration more efficient for this robot.

II. 4. Heap and garbage collecting

As a part of the lab session we were asked to investigate the difference between using the left, right string variables and setting them directly in the function.
It was observed that

• When using the variable the memory usage was static.
• When using the the strings directly the memory usage was decresing rapidly and when reaching around 400-500Bytes, the memory freed up, and the rapid decreesed started over. This behaviour continued in a loop.

This is clearly demonstrating the Garbage Colletor is working and behaving as expected. When declaring the variables, all required memory for this task is preallocated and we just keep reusing the same part of the memoryspace.
Every time a "..." is writen, a string object is essentially created and memory is used. Since this is done in our loop with a delay of 10ms we continue to create a new string object approximatly 100 times per second, each being of 10 chars it equals to 1KB/s. This match the decrese rate observed.
When we reach the low memory level the garbage collector kicks in, and deletes all objectes which have no reference in the program. This is valid for all our string objectes, and they are deleted.
In a normal highlevel enviroment this would often not cause any problems. But in the embedded context where ressources are tight and timing is critical, we need to take this in to consideration. Essentially it not at problem that we use the memory and free it up again. But if the GC starts to run while we do somthing timing critical, it can easy cause unpredictable results. The best way to avoid this happening is to manage our use of memory.

IV. References