Notebook 03

print

Lab Notebook

sound_sensor.png

Date: 16/02 2012
Group members participating: Falk, Jeppe and Jakob
Duration of activity: 4 hours

Goal

The goal of this lab session is to get familiar and experiment with the sound sensor by implementing programs with sound triggered behavior and running them on the nxt-device.

Plan

  1. Mount the sound sensor on the robot.
  2. Test the sound sensor using the SoundSensorTest.java.
  3. Collect a series of data using the DataLogger.java and represent it as a graph.
  4. Control a car using the SoundCtrCar.java and describe the behavior.
  5. Use the sensor to detect claps, noting the pattern of a clap.
  6. Implement the PartyFinder.java that travels towards noise.

Results

Adding the sound sensor

The sound sensor was mounted accordingly to the manual 9797 page 24-26.

Measuring sounds

The SoundSensorTest.java was constructed from the SonicSensorTest.java but with the SoundSensor class and the readings of SensorPort.S1.readRawValue() (where the SoundSensor was connected to port 1).
Measuring the raw value the value seems to be ranging from 999 (silence) to 0 and the environment noise is between 950 and 999. Unlike the ultrasonic sensor there seems to be no problem with distance, and it can also measure sounds behind the sensor.
This test can only measure if the sensor reads anything, because, depending on measurement frequency, it is very difficult to see what number the display says. There are a few other sources of error such as in the SoundSensorTest.java the interval is 300ms. It should also be remembered that sound bounces off walls and objects.

Using the DataLogger.java that writes it's output to a sample.txt as a comma-separated file, the following graph was generated.
The graph is of soundlevel in percentage measured over time, and displays three claps executed in the Lego Lab room. Soundlevel reads is performed using the readValue method on the SoundSensor class. The range of the percentage reading given by the readValue method is not well documented in the Lejos API, so there is no easy way of knowing what the threshold values 0% and 100% corresponds to in DB.
Graph_lab3-ex2.png
The measurements were performed in a closed room to minimize background noise. The distance between the clap and the sound sensor was approximately 50 cm.
The three claps are easily distinguished, and the last peak - that reaches approximately 40 - could be echo or the readings of someone turning off the program.

Controlling the car

transition_diagram_claps.png

The SoundCtrCar.java is a simple program that makes the car contronable by making loud noises. The program has a threshold of 90% as a default definition of a loud noise measured by the readValue.
When the program is run, the car has 4 states as shown in the figure. At the first loud noise detected the robot drives forward and every consecutive loud noise makes it transist to the next state. The progam is supposed to terminate the program and stop the car at any time when the escape button is pushed, but in the original program(SoundCtrCar.java) it can only be stopped when the program is executing in the outer-most loop. This behavior is corrected in The program developed by using the ButtonListener class and making a check if the escape button has been pressed in every loop.

Clap detection

In the attempt to distinguish claps from loud background noise, the specification of Silvian Toledo [5] was used. First waiting for a low noise (below 50%) followed by a loud noise (above 90%) that falls to a low noise within 250ms. The program (ClapMeasure.java) manages to distinguishes claps from background noise, but if a sound can mimic the above definition of a clap it can easily be tricked (fx. if the robot hits an object with the microphone).

IMAG0294.jpg

Party Finder

The party finder robot travels towards the source of noise. An additional sound sensor is added to the robot to make it possible to measure if the source of the sound is to the left, right or in front of the robot. The robot then uses the noise sensor on the right to control the left motor and visa versa. It does this by adding the noise to a minimum power and using that as a the power of the motor opposite the source of sound, i.e. if a loud sound is detected to the left of the robot the power of the right motor is increased.
A problem occurs when one sensor measures in a different range or more accurate than the other sensor. This must be accounted for by calibrating both sensors, an attempt to achieve this can be seen in a home made calibrating method in The program developed.

Conclusion

In completing the assignment we got familier with the sound sensor and learned how to implement sound triggered behavior.
The first part of the exercise went smoothly, but making the party finder behave correctly was quite problematic. The PartyFinder.java works well, but it becomes difficult when one sensor is more sensitive than the other, and one motor is more responsive than the other. The home made calibrating method adds a number to the power of the motor, and therefore only adjusts the sound at a specific level. To make it properly there should probably also be factor for each motor applied to the calculations.

References

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License