Lab Session 3

18092009

Attendees: Jesper Jakobsen, Mads Hansen Lund og Michael Nygaard Pedersen

This lab session will investigate the NXT sound sensor / microphone and its characteristics when mounted on the NXT main unit.

Goal

The main goal is to characterize the NXT microphone functionality under

18092009

different circumstances. Both use of a microphone and sound interpretation on and NXT are handled

Sub goals

Update the robot with the sonic sensor / microphone, so it becomes similar with Ref1.

“DataLogger.java” and “SoundSampling.jav

a” from Ref

2 should be uploaded in order to investigate the microphone and captured data.

Two different types of real inputs should be characterized: Sine sweep and clapping.

“SoundCtrCar.java” and “Car.java” from Ref2

should be uploaded to investigate the basic functionality in relation to real-time action.

Plan

• Construct a robot with one microphone and two in

  dependent motors with build-in rotation sensors.

• Upload the java programs: “DataLogger.jav

  a” and “SoundSampling.java” from Ref2

• Collect sine wave data with data logger

• Evaluate the measurements and NXT performance

• Upload “SoundCtrCar.java” and “Car.java” from Ref2

• Evaluate the performance and the influence of im

  portant parameters.

Results

This paragraph will contain all the results from the experiments from lab session 3.

Sound capturing experiment

The most interesting thing concerning the microphone is the frequency characteristic. The frequency characteristic tells about the sensitivity for the microphone for specific frequencies and might clarify the opportunities for further

development.

The research will be based on a frequency sweep through some laptop speakers. The experiment setup cannot clarify the phase spectrum since synchronization betw

een the laptop and the NXT is not possible.

NHC Tone Generator software is used for generating a sinus frequency sweep for the laptop speakers and the “DataLogger.java” from Ref2 is used to log the microphone measurements.

The frequency sweep has been limitted to a linear sweep from 400

Hz to 15000 Hz caused by the laptop speaker ratio. The sweep duration is set to 50

00 ms, which corresponds to 1000 samples for every sweep (NXT main unit sample frequency= 5 ms.)

Figure 1 - Tone generator main window (Ref5)

Figure 2 shows how the microphone is place because high frequencies can be direction oriented.

Figure 2 - Sound capturing Setup

Figure 3 - Graph showing the complete data log from the microphone with 9 complete loops of frequency sweeps.

‘3’ illustrates that the graph of the first loop- and the last loop of frequency sweep does not match with the sketch of 1000 samples for one frequency sweep. The main reason for the differences between the patterns is the inaccuracy of the clock frequency.

Figure 4 - Top graph shows the first loop of the frequency sweep in the data log and bottom graph shows the last loop in the frequency spectrum.

The calculated clock frequency has been evaluated and trusted in order to precede the calculations. This is therefore the “correct” clock frequency for the NXT.

‘3’ leads to that NXT takes more than the

1000 samples doing frequency sweep duration on 5000 ms.

Calculation for extra samples with cross-reference to ‘3’:

Calculation for the new interval and the new sampling frequency:

’4’ illustrates that the new calculated number of samples per loop is correct. The maximum limit for the microphone measurement can be estimated to 93 dB based on ’4’.

Figure 5 - All 9 loops of the frequency sweep put compared into one graph.

’ 4’ illustrates that the microphone probably contain two LC band pass circuits. The LC circuits band pass areas are approximated with the blue markers in ’4’. The Lego engineers have probably evaluated normal speak in the development phase. The Niels Bohr’s Institute confirms the maximum frequency.

”Det meste af informationen ved normal tale er under 4 kHz, det var

så hvad en gammeldags telefon kunne klare.” Ref6

Figure 6 - The abscissa is shared to a log scale and the values are calculated into mean values from the 9 loops.

Data logging

Data logging is done on board the NXT main unit (Ref4). A file named Sample.txt is created, where all the captured sound data is stored. The way to store the data either comma separated or line separated can be implemented in class “DataLogger.java”. All the data in these experiments are stored as line separated values.

The file can be downloaded from the NXT main unit via the batch program “nxjbrowse”. When the batch is executed the window shown in 6.

Figure 7 - NXJ file browser

When the connection is established, the window changes and it is possible to

download the created file. This window is shown in 7.

Figure 8 - File browser connected to NXT main unit

Sound controlled car

The java program SoundCtrCar.java (Ref2) was loaded to the N

XT robot

build as described in Ref1. When the program is running, the robot will be in 1 of 4 different states (either; forward, right, left or stopped). Every time a loud sound exceeds a preprogrammed threshold level, the robot changes state.

Clap experiment

To indentify a clap is a rather simple task in principle, but rather complex to implement, if ONLY real claps should be detected and not every sound over a certain threshold. Sivan Toledo from Ref3 has written an article about clap detection, where h

e compares a clap captured with poor sample frequency of the NXT and compared it with how a PC captures the sound.

8 and 9 shows two measurements performed by the NXT mai

n unit. Two cases is investigated, where the clapping distance vary

Figure 9 - Clapping 1 meter from the microphone

The time of a clap might vary from person to person, and amplitude for clapping might also vary.

Figure 10 - Clapping 0.5 meter from the microphone

The important thing to notice is the pattern of the clap. Therefore a correlation output between the measured data and a predefined sequence could determine the statistical content of a random measurement. If the statistical matches a clap with a certain interval it probable was a clap.

A correlation algorithm requires quite a processor and therefore a more simple approach must be chosen.

The clap pattern rises quickly above a certain threshold, e.g. 40 percent in 25-40ms for a distance of 1 meter. The curve then dives beneath 10 within 150ms. This description of the pattern is in many ways similar to Sivan Toledos, except for amplitudes.

By implementing a simple algorithm, which can detect this pattern, by detecting a threshold found by experiment and checking the negative slope after the maximum value, a clap can be successfully detected.

Programming attempts

N/A

Measurements

All measurements from this lab session are processed in either Matlab or Mathcad and are evaluated under the subparagraph “Results”.

Pictures of Lego model

Figure 11 - Picture of robot

Problems encountered

N/A

Conclusion

The microphone is a proper sensor for low and mid range sound capturing. The NXT main unit is not an audio or digital signal processing unit and therefore it is not suitable for audio sampling. However, some practical issues can be solved with a microphone on an NXT, because simple wave forms can be recognized / interpreted despite the low sample frequency.

References

Ref 1: Mindstorms education 9797 (add-on: page 24-26)

Ref2: http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson3.dir/Lesson.html

Ref3: http://www.tau.ac.il/~stoledo/lego/ClapCounter/

Ref4: http://en.wikipedia.org/wiki/Data_logger

Ref5: http://www.world-voices.com/software/nchtone.html

Ref6: http://www.nbi.ku.dk/spoerg_om_fysik/fysik/modulation/

Lab session 2

11092009

Attendees: Jesper Jakobsen, Mads Hansen Lund og Michael Nygaard Pedersen

Please check out

our video:

http://www.youtube.com/watch?v=57GEM04shQY

Goal

The main goal was to investigate the ultra sonic sensor from the Lego NXT kit.

Sub goals

Update the robot with the ultra sonic sensor, so it becomes similar with Ref1.

The software class “SonicSensorTest.java” should be uploaded to the robot and different sample intervals should be tested. Furthermore, the precession of the ultra sonic sensor must be tested in order to evaluate the credibility of the sensor measurement.

When the basic functionality is evaluated two more complex classes are uploaded to the robot. The classes “Tracker.java” and “Car.java” implements an active regulator, which tracks a certain position and regulates the actual position.

Plan

· Construct a robot with one ultra sonic sensor and two independent motors with build-in rotation sensors.

· Upload the java program from Ref2

· Measure distances from the wall manually and compare it with the ultra sonic measurement

· Evaluate the measurement accuracy and performance of the robot with different sample intervals

· Upload the java program from Ref3

· Evaluate the performance of the regulator by changing the important parameters.

· Make a wall follower program, which enables the robot drive parallel with a wall.

Results

Description of experiment

Four kinds of experiments: Distance measurement experiment, ultra sonic sample interval experiment, Wall tracker experiment, Wall follower experiment. The first two experiments are handled in the subparagraph “Measurements”. The final two experiments are dealt with in the following subparagraph “Programming attempts”.

Programming attempts

Two wall follower methods were investigated during this lab session and are explained in the following subparagraphs.

Wall follower 0.1

Philippe Hurbain’s WallFollowe

r application is based on a “bang-bang” regulator with six thresholds values (one of the thresholds is not even used). The distance estimation starts with rough determination of the new direction for the robot by using one of the thresholds values. The determination will end up in one of the following cases:

· Very close (turn in place)

· Close enough (turn)

· A bit too close (shallow turn)

· If small variation turn (avoids turning too short on salient angles)

· A bit too far (shallow turn)

Philippe Hurbain’s WallFollower application assumes that all states for the embedded system are known. The deterministic behavior of the code results in bad driving skills.

The code is not well structured and therefore it might be complicated to update or change the code for alternative use.

Philippe Hurbain’s WallFollower application is not implemented but replaced with proportional regulator code. The proportional regulator can easily be updated to PID regulator if needed.

Wall follower 0.2

The code beneath shows how simple a wall follower can be made by using a p-regulator.

error = distance - desiredDistance;

power = (int)(gain * error);

Car.backward(minPower+offSet-power, minPower+power);

The offset is used to make the motors as identical as possible. A video showing the execution of the code is also uploaded.

Measurements

Distance measurement

Several distance measurement were made and is presented in Table 1.

Manual measurement (cm]	Ultra sonic measurement [cm]
10	11
12	13
14	15
16	17
18	19
20	20
22	22

Table 1 – Distance measurements

The table is made to investigate precession of the ultra sonic sensor.

Sample interval observation

The optimal simple interval for the ultra sonic sensor can be easily calculated by calculating the maximum traveltime.

Equation 1

Equation 1 shows the simple linear relationship between time and distance. Figure 1 shows the tracking result for 255cm. The optimal sample time is therefore two times the X-value. The optimal sample time is therefore 15ms.

Figure 1 - Linear tracking

Pictures of Lego model

Figure 2 - Picture of robot

Problems encountered

N/A

Conclusion

This lab session concludes the need for real life measurements and careful selecting regulation method, by evaluating the complexity of the specific task. The PID regulator from Ref4 could be implemented to optimize the solution. The result would be more effective and more precise. The ‘I’ part would ensure that the robot would move more straight and the ‘D’ part would make the regulator faster if the correct ‘D’ gain is found trough experiments. It was prioritized to work more thorough with simpler issues and only read and understand the theory behind a more complex implementation.

References

Ref 1: Mindstorms education 9797 (add-on: page 28-30)

Ref2: http://www.legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/SonicSensorTest.java

Ref3: http://www.legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/Tracker.java and http://www.legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/Car.java

Ref4: Chapter 5, pp. 179-190 of Fred G. Martin, Robotic Explorations: A Hands-on Introduction to Engineering

Lab session 1

04092009

Attendees: Jesper Jakobsen, Mads Hansen Lund og Michael Nygaard Pedersen

This lab session was the first for the group ”LegoCarsten”. This lab session was used to adresse and solve practical issues and obtain a basic understanding of the hardware and software.

Goal

The main goal is to make a NXT robot, which should be able to track and follow a black line without any human assistance.

Sub goals

A PC should interface the NXT control unit via USB and Bluetooth.

A robot should be constructed, which can be programmed in the Eclipse environment by adding the leJOS library. The robot should be controlled by the NXT control unit by adding the necessary sensors and motors.

The introduction for this session is found on the course homepage Ref1.

Plan

· Investigate the needs for software download and install the components.

· Establish connection to the NXT control unit and upload leJOS firmware to the flash memory.

· Construct a robot with one light sensor and two independent motors with build-in rotation sensors (Ref 2).

· Download the java program from Ref1

· Measure light sensor levels in order to optimize code performance

· Evaluate the final performance of the robot

Results

There are of cause relatively few results in this lab session because it is the first one of its kind.

Description of experiment

Several experiments were made to check the credibility of the line follower class.

Line tracking

The robot should be able to follow the black line on the track. If the robot fails the threshold value from the software should be changed. The code line beneath shows how the threshold value is defined.

final int blackWhiteThreshold = 45;

No adjustment were made afterwards because the robot just fulfilled the task perfectly.

Light reflection measurement

In case the software should be optimized it could be useful with additional measurements, which can indicate the reflection value for different colors. When the program is running, the reflection percentage is printed on the LCD.

LCD.drawString("to start", 0, 3);

while (! Button.LEFT.isPressed()){

LCD.drawInt(light.readValue(), 3, 9, 0);

}

These values where noted in order to determine limits or threshold values for the lights sensor.

The same experiment was performed with only ambient light available. The LED was turned off by setting the Boolean to FALSE.

light.setFloodlight(FALSE);

The results for measurement experiments are presented in the “Measurement” chapter.

Sample interval experiment

Three additional sample delays are tested to understand importance for the right sample interval. The tested sample intervals are: 10ms(default), 100ms, 500ms and 1000ms. The sample interval is changed in the code line beneath.

while (! Button.ESCAPE.isPressed()){

…
Thread.sleep(10);

…

}

It is important to change the value within the program while loop and not the sleep parameter outside.

The results for measurement experiments are presented in the “Measurement” chapter.

String function experiment

A test was made to investigate the effect of the variable declaration on the memory usage. The condition beneath was made to update the minimum of free memory and the condition was changed to “<” to observe the maximum of free memory.

CurrentMem = Runtime.getRuntime().freeMemory();

if (freeMem > CurrentMem) {

freeMem = CurrentMem;

}

LCD.drawString("Memory "+freeMem, 0, 4);

The string content of “left” was changed, and the content was placed directly in LCD.drawstring().

// On black, turn left

LCD.drawString(left, 0, 1);

MotorPort.B.controlMotor(power, forward);

MotorPort.C.controlMotor(0,stop);

…

Maximum free memory without variables: 56796

Minimum free memory without variables: 48

Maximum free memory with variables: 56700

Minimum free memory with variables: 44

Programming attempts

The two attempts are already explained. There is no need for further explanation because of the simplicity. All the attempts are made with a-so-called “bang-bang” regulator.

Measurements

This chapter contains measurement data from lab session 1.

Light measurement

The following measurements are made with the line follower software, which prints a percentage of the reflected light.

Color	Percentage with LED [%]	Percentage without LED [%]
Black	35 ±1	26 ±2
White	62 ±1	44 ±2
Blue	47 ±2	35 ±3
Green	41 ±3	32 ±5
Yellow	61 ±3	47 ±4
Orange	55 ±2	47 ±3
Red	52 ±2	43 ±3

Table 1 - Light sensor measurements

Based on the measurements in Table 1 it can be concluded, that it is almost impossible to detect colors with the light sensor. But it is possible to determine whether the color is bright or not.

Sample interval observation

The following observations are based on four different sample intervals to estimate the perfect interval to obtain both speed and precision.

10ms(default)

It moves relatively slow, but follows the line closely.

100ms

It moves faster compared to the original setup, but it looks less smooth during the run.

500ms

The robot detects the line from time to time, but it cannot follow the line for a longer period. The sample interval is impropriet for this assignment.

1000ms

The robot cannot follow the line. The robot drives around in circles and might be lucky to detect something, but it cannot follow the line.

Pictures of Lego model

Figure 1 - Picture of robot

Problems encountered

We had several problems with installing the leJOS software because of software version conflict. Most of the first lab session was used to establish contact to robot.

Conclusion

It is possible to build a line follower with only light sensor and “bang-bang” regulator. It should be noticed that the sample interval is very important in order to make the robot follow the line. In order to make the robot follow the line, the line and track color should have a large contrast relationship. The robot can interpret the difference. The robot has only one light sensor, because the robot has to toggle between the line and the surface to determine if it is on track or not. This control pattern makes the robot less smooth during the run, which makes the robot slow.

References

Ref1 http://legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson1.dir/Lesson.html
Ref2 Mindstorms education 9797