Date: 21/2-2014 - 25/2-2014
Duration of activity: 9.30 - 14.30, 10-12, 9-13Group members participating:
Benjamin, Christina, Levi
Goal for the lab session: Complete exercise 1 through 6 for this weeks lab session [0].
Goal for the lab session: Complete exercise 1 through 6 for this weeks lab session [0].
Plan for the activities: Go through the exercises one by one, completing them to the extent possible.
Results obtained during lab session:
Exercise 1 - Test of the Sound Sensor
We successfully mounted the sensor, and tested various sounds. The API told us that the sound value is measured in percentage, however we have been told that this is probably not the case. Normally sound values are measured in decibel, which is a linear value, and we also suspect that is the case with these sensors. However we were unable to measure sound levels higher than 93%, and no lower that 2%, so we cannot truly say what the real case is. The normal decibel scale goes above 100.
We tried with different sound frequencies to see if there was a difference in the values, but it did not seem to be the case. We tried to put the speaker directly onto the sensor, however that actually resulted in a reduction in measured value.
We performed an experiment where we measured values from a sound source at different distances from the sensor, and with different level of sound (diff. dB).
We placed the sound sensor with its cabinet at the distance of 0cm and then moved away the sounds source (an iPhone playing a tune).
The following pictures illustrate the experiment:
The iPhones speaker is at the bottom of the phone, so for all distances we measure to the edge of the phone.
Measurements of sound from phone speaker measured with sound sensor in various distances are shown here:
Decibel output (iPhones own measurement)
|
NXT sound sensor, measured %
|
distance from front of sound sensor
|
-42,8
|
16
|
1mm
|
-42,8
|
13
|
5mm
|
-42,8
|
10
|
10mm
|
-42,8
|
8
|
15mm
|
Louder sound
| ||
-17,4
|
83
|
1mm
|
-17,4
|
87
|
5mm
|
-17,4
|
90
|
10mm
|
-17,4
|
91
|
15mm
|
-17,4
|
93
|
20mm
|
-17,4
|
93
|
25mm
|
-17,4
|
90
|
30mm
|
-17,4
|
81
|
35mm
|
-17,4
|
73
|
40mm
|
-17,4
|
67
|
45mm
|
-17,4
|
65
|
50mm
|
-17,4
|
45
|
70mm
|
-17,5
|
30
|
100mm
|
Even louder sound
| ||
-6,1
|
73
|
1mm
|
-6,1
|
81
|
5mm
|
-6,1
|
86
|
10mm
|
-6,1
|
88
|
15mm
|
-6,1
|
90
|
20mm
|
-6,1
|
91
|
25mm
|
-6,1
|
92
|
30mm
|
-6,1
|
93
|
35mm
|
-6,1
|
93
|
40mm
|
-6,1
|
93
|
45mm
|
-6,1
|
85
|
50mm
|
-6,1
|
77
|
55mm
|
-6,1
|
71
|
60mm
|
-6,1
|
68
|
65mm
|
-6,1
|
65
|
70mm
|
-6,1
|
60
|
75mm
|
-6,1
|
59
|
80mm
|
-6,1
|
49
|
100mm
|
From the measurements we see that for the not so loud sound (-42,8dB), the measurements from the sensor decreases with the distance.
From the measurements with the two louder sounds, we see another phenomenon; first the measurements increase as we move the source of the sound farther away. It increases until it reaches 93% (in both of the cases) before it starts decreasing. However the maximum of 93% is not reached in the same distance in the two cases.
We suspect that this might be in connection to the fact that the measured values from the sensor gets lower when you put the sound source so close to the sensor that they touch each other. Perhaps the microphone doesn’t provide the most reliable results when the sound source is closer than a given distance, and again this distance may be correlated to the level of the sound (the dB).
However, we are not going to pursue this further.
Exercise 2 - Data logger
We tried to log two different sounds, with different distances, see table below for distances.
The first sound was a clap from a group members hands. This sound is inaccurate, both in measured distance, and in dB output, since both is estimated from a human perspective (how do we know he’s clapping with the same power, and same technique as the previous?). So both the dB and the distance has an error margin, but we did not bother to find out the extent of this error margin.
The second sound is a drum played from a sound file on a MacBook Pro. The sound is very accurate in matter of sound level, since it was played with the exact same dB every time. We also had a precise distance factor, however we do not know exactly where the sound is played from on the speaker, nor exactly where on the microphone the sound is recorded, so there can be an error margin of a few centimeters.
We expect there to be some exponential decreasing function when measuring the dB level due to the nature of sound.[1]
Clap distance (ca. cm)
|
10
|
30
|
50
|
80
|
100
|
130
|
Drum (cm)
|
10
|
30
|
50
|
80
|
100
|
130
|
The drum followed an exponential decreasing scale better, however the last measurement was so low that it drowned in background noise.
Exercise 3 - Sound Controlled Car
If the sensor hears a sound louder than soundlevel 90(as measured by the car), it triggers the waitForLoudSound() method. In the main method the waitForLoudSound() is used as a gate to when the application gets to continue. The first loud sound the application hears makes it drive forward at max speed. The second loud sound makes it turn right at max speed and the third loud sound makes it turn left. The fourth loud sound makes it stop. Once it has hit the fourth loud sound, the loop starts over, so that the next loud sound will make the car drive forward. This is continued until the program terminates (which require an odd process, see next exercise).
Exercise 4 - ButtonListener
We implemented a ButtonListener on the escape button as the first thing in the main method. The implementation was inspired by [2]. This means that whenever the escape button is pressed, the program terminates. Previously one would have to hold down the escape button while making a high dB sound while the car was turning left in order to terminate the program. Very annoying.
Exercise 5 - Clap Controlled Car
The way we implemented this was to first measure if there was a reading of a value higher than 10 and lower than 50 (the value had to be higher than 10 is so that the program wouldn’t compute if there were quiet in the room).
Next, it was set to measure values every 5 ms and store them in an array, for a total of about 300 ms. When this array has been filled out, we checked for the first 5 measured values (after the initial value between 10 and 50) i.e. within 25 ms, what the maximal value measured was. Then the following 50 values, i.e. within the next 250 ms, were checked for what the minimal value was.
Then a boolean, clapHeard, was set to true if the maximal value measured within the 25 ms was above 85 and the minimal value within the next 250 ms were lower than 50.
The code for the program can be found here: [3].
When the car is just standing still and detecting claps without starting the motors, the claps are detected fine.
A video that shows this is here (with bad focus, sorry):
Sometimes when yelling loudly in a certain way (shouting loudly for a very short time) a clap was detected, but this is because that yell follows the same pattern as the clap we are detecting.
A video that shows this is here (with bad focus, sorry):
The program detects the clap every time when no motors are running.
Sometimes when yelling loudly in a certain way (shouting loudly for a very short time) a clap was detected, but this is because that yell follows the same pattern as the clap we are detecting.
When both motors get started by detecting a clap, the next clap to be detected is detected fine in most cases. This makes the left motor stop and the right motor to go forward. When the car runs like this the next clap is hard to detect, if at all possible. We had an idea that this error came from the fact that the motors make noise, and that this influences the readings (although the values still seem to be in the right areas, a loud reading just seem harder to detect). We therefore extended the arms upon which the sensors were placed, to get them farther away from motor noise source.
Sensors placed on arms farther from the motors
This procedure didn’t help as much as when we tried setting the power with which the motor runs to half the power (50 instead of 100). When doing this, the claps were detected fine, but the motors ran very slowly.
The next thing we suspect influences the ability to detect claps when the right motor is running (but not when both are running) is the fact that the sensor is placed at the NXT’s left and not in the middle i.e. with an equal distance to both motors.
Sensor to the left of the NXT (to the right in this picture), and therefore not with equal distance to the two motors.
We tried placing the sensor in the middle, and then running the motors with a power of 100 when they should run.
A video of this (with the value within the 25 ms set to only exceed 60 instead of 85, to try to make it easier still to detect a clap) is shown here.
[Link to video (is too big to post here)]
It is obvious that it still doesn’t work as it should.
We will not try further to get the clap detection to work with the motors running at maximum power. If possibly requires a whole different algorithm to succeed in the detection of claps properly, even with the motors running.
We will not try further to get the clap detection to work with the motors running at maximum power. If possibly requires a whole different algorithm to succeed in the detection of claps properly, even with the motors running.
Exercise 6 - Party Finder Robot
There are many different ways to make the car go towards the source of the sound. One of the more simple ways of making this possible is to use the value read in on soundsensor level, and use it directly in the Car.foward method. We found that we were able to make it follow a sound source easily, but needed more speed, so we added 30 to the measured values and let the vehicle go at measured sound level + 30. We saw that the car went in the wrong direction, as the sound measured in the left speaker affected the left wheel. This led to the car turning the wrong way. Just switching the inputs to the car.forward call fixed the issue.
Seeing that this was not optimal, and not good coding, we then experimented with using the inverse value from the microphone measurement, directly in the car.forward call, like this:
Car.forward((100-sl1), (100-sl2);
This made the car turn the right way, without having to switch the inputs around, and led to another interesting thing: the louder the measured sound, the slower the car moved. This made it possible to stop the car when it was near the sound source. This solution is demonstrated in the video.
There were issues with the microphone placement. Having them further apart could make it more sensitive to sounds coming from a source far away. Our experiments with microphone placements resulted in the car losing the ability to stop at a sound source, as the recorded values never reached the high numbers, on both microphones at the same time. Even though we might have come to a good result, given enough time, we decided not to pursue this any further.
Here's a video of the car, showing that it doesn't react to sound sources far away.Other findings
The two computers not being able to connect with the NXT through BT overcame the problem. For the one computer (Mac running VM Windows) it just started working one time when trying to connect.
For the other computer (Windows machine), it started working after the file nxj.cache was deleted from the user account on the machine (C:\Users\Username\nxj.cache).
This file contains the found NXT’s from a BlueTooth inquiry at a given time but this cache had stored three NXT’s (named EV3, Predator and one more) but not the right one (our NXT), causing Eclipse to try to upload to one of these NXT’s every time trying to connect with BT (even though the computer had been paired correctly with the NXT). Upon deleting the file nxj.cache, the next time nxjbrowse program was opened, it performed a search for available NXT’s, where it found the correct NXT (our NXT) along with other available NXT’s in the room. This meant that next time trying to upload a program via Eclipse, Eclipse found the connected NXT (our NXT) and uploaded the program via BT.
Conclusion
- All the group members have BT connection to the NXT now.
[2] Lejos tutorial “Threads, Listeners and Events”
[3] ClapCtrlCar.java
Ingen kommentarer:
Send en kommentar