|
|
## Lab Notebook 3
|
|
|
|
|
|
**Date:** 25th of February 2016
|
|
|
|
|
|
**Group number:** Group 14
|
|
|
|
|
|
**Group members participating:** Camilla Vinther Frederiksen, Ida Larsen-Ledet, Nicolai Nibe and Emil Platz
|
|
|
|
|
|
**Activity duration:** 3 hours
|
|
|
|
|
|
## Goal
|
|
|
Do not kill Frej (the robot).
|
|
|
|
|
|
To understand and implement the use of the NXT sound sensor through the completion of the exercises as described in [lesson plan 3]
|
|
|
(http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson3.dir/Lesson.html)
|
|
|
|
|
|
## Plan
|
|
|
Our plan is to follow the instructions and complete the task of the lesson plan, while each group member has a primary job. Emil and Camilla will be in
|
|
|
charge of the experiments with the NXT, Ida will take notes for our report, and Nicolai will control all compiling and running of code.
|
|
|
We also intend to take some pictures and videos of the exercises that could be useful in explaining our approach. No specific person is in charge of this -
|
|
|
whoever is available and has a recording device at hand will do it. If no one does, Camilla will shout orders until someone is holding a recording device in their hand.
|
|
|
We plan to finish the exercises within three hours, if possible.
|
|
|
|
|
|
## Results
|
|
|
### Exercise 1: Testing the Sound Sensor
|
|
|
For this exercise we wrote a simple program called ***SoundSensorTest.java***, that does the exact same thing as the ***SonicSensorTest.java*** from last week,
|
|
|
except that it uses the **SoundSensor** class to get readings through the **readValue()** method, instead of the **UltrasonicSensor** getting readings using
|
|
|
the **getDistance()** method.
|
|
|
|
|
|
In order to be as precise as possible when testing which sound levels would trigger which sensor readings, we decided to use a 'stable' sound source (rather than,
|
|
|
for instance, having one of us shout at the robot). For this purpose we used a repetetive ringtone on a phone and adjusted the sound level. In doing this, we
|
|
|
made sure that variations in sensor readings were not caused by variations/instability at the sound source.
|
|
|
|
|
|
Using the ringtone, we obtained the readings of Table 1 and 2: Table 1 contains readings for a low sound level and Table 2 contains readings for a high sound level.
|
|
|
The distances of the two tables were measured from the end of the sound sensor to the phone speaker, as seen in Figure 1, and the resulting sensor readings are given
|
|
|
as a value between 0 and 100. The tables only contain four measurements, as it seemed silly to continue beyond 20 cm where the sensor readings for both low and high sound levels
|
|
|
got very difficult to differentiate from background noise in the room.
|
|
|
|
|
|
![Measuring the distance between the phone's speaker (the sound source) and the sound sensor](week5/img/exercise1.jpg)
|
|
|
*Figure 1: Measuring the distance between the phone loud speaker and the sound sensor.*
|
|
|
|
|
|
| Distance | Sensor reading |
|
|
|
| -------- | -------------- |
|
|
|
| 0 cm | 17 |
|
|
|
| 5 cm | 14 |
|
|
|
| 10 cm | ~ 7 |
|
|
|
| 20 cm | ~ 5 |
|
|
|
|
|
|
*Table 1: Readings from the sound sensor when using a phone ringtone with the same low sound level. Readings with a '~' are (especially) uncertain due to background noise.*
|
|
|
|
|
|
| Distance | Sensor reading |
|
|
|
| -------- | -------------- |
|
|
|
| 0 cm | 90 |
|
|
|
| 5 cm | 37 |
|
|
|
| 10 cm | 24 |
|
|
|
| 20 cm | 17 - 29 |
|
|
|
|
|
|
*Table 2: Readings from the sound sensor when using a phone ringtone with the same high sound level. Readings given in an interval represent the interval of
|
|
|
the different values obtained at this distance (when the display was different between values).*
|
|
|
|
|
|
What we see in the two tables is that (unsurprisingly) the reading of the sound level gets lower as we move the sound source further away from the sensor. We also see
|
|
|
how issues with the readings start to appear at a certain distance - the sounds seems to get significantly harder to detect and measure as we move the sound source further
|
|
|
away from the sensor. The uncertainty in the values obtained at both sound levels (from 20 cm at high sound level, from 10 cm at low) can most likely partly be explained
|
|
|
by the sensor readings getting lower with increased distance; the sensor's inability to distinguish and measure the sound could introduce insecurities. In the case of
|
|
|
the high sound level, we suspect that the reading of up to 29 at a distance of 20 cm might have been caused by the rather loud ambient sound level in the Suze building
|
|
|
that afternoon (all groups in our proximity were making noisy experiments).
|
|
|
|
|
|
After performing the more precise experiments with the sensor, we decided to play around with other sounds. These 'experiments' were influenced by a lot of uncertainties
|
|
|
(e.g. inconsistency of clapping noise level) and the intent of including them is only to intuitively confirm what we have seen in Tables 1 and 2. The readings can be seen in
|
|
|
Table 3, with imprecice indications of distance as this was only based on a visual check.
|
|
|
|
|
|
| Sound description | Relative position to the sensor | Sensor reading |
|
|
|
| --------------------- | ------------------------------- | -------------- |
|
|
|
| Loudly eating a carot | Very close | 7 |
|
|
|
| Loud clap | Very close | 92 |
|
|
|
| Loud clap | 2-3 meters away | 38 |
|
|
|
| Loud clap | 6-7 meters away | 28 |
|
|
|
|
|
|
*Table 3: Playing around with noises while trying to remain a bit scientific.*
|
|
|
|
|
|
Table 3 supports our suspicion that sensor readings gets lower as the sound moves away. In addition, it is clear (if we trust our data) that eating a carrot at a lecture feels
|
|
|
much louder than it actually is!
|
|
|
|
|
|
### Exercise 2: Testing using the data logger
|
|
|
As there was no explicitly given exercise in this exercise, we decided to use the given program ***SoundSampling.java*** to log continuous data from
|
|
|
various sound sources as they move away from the sound sensor.
|
|
|
|
|
|
Our first try with the SoundSampling program was Emil going 'ooh' while moving away (and at the end walking into a table and cursing). The sound sensor was
|
|
|
however plugged in at sensor port 2, while the program was reading from sensor port 1. Therefore our first try failed, and we - sadly - have no record of
|
|
|
Emil 'ooh'-ing and failing.
|
|
|
|
|
|
After this disappointing start, we fixed the sensor port issues and repeated the experiment, this time with a phone emitting a continuous high-pitched note
|
|
|
(https://www.youtube.com/watch?v=xQculw9H2N4). Aside from YouTube not accidentally bumping into tables and cursing, using this sound also prevents the aforementioned
|
|
|
problem of sound produced on-the-spot possibly being inconsistent in loudness.
|
|
|
We logged the distance starting from ~20 cm away from the sound sensor, increasing the distance to several meters (some amount beyond the ~3 m shown in Video 1).
|
|
|
The plot of this data can be seen in Figure 2, and a video recording of it can be seen in Video 1.
|
|
|
Additionally, we decided to log the sound sensor recording of a loud clap, as we thought this data could be useful to have in Exercise 5 and so decided that we might as
|
|
|
well log it when we were using the ***SoundSampling.java*** program anyway.
|
|
|
|
|
|
![Plot of consistent high pitch noise being moved away from the sound sensor](week5/img/PauseskærmLog.png)
|
|
|
|
|
|
*Figure 2: Plot of consistent high pitch noise being moved away from the sound sensor.*
|
|
|
|
|
|
[![Klartone logging](http://img.youtube.com/vi/0u5MTglIgvs/0.jpg)](https://www.youtube.com/watch?v=0u5MTglIgvs)
|
|
|
|
|
|
*Video 1: Logging a high pitched noise while increasing the distance to the sound sensor.*
|
|
|
|
|
|
The high reading in the first 200 miliseconds of the plot can be found in all of our logs. We have attributed this to most likely being a result of the
|
|
|
loud 'beep' the robot makes when booting the program, as the NXT speaker is very close to our sound sensor. At ~500 miliseconds the plot shows us
|
|
|
starting the sound emission from the phone, and it slightly increases up until around 1200 miliseconds as we position the cellphone and prepare to move
|
|
|
away. The next 2 seconds show the (somewhat) linear decline in sound level. Unfortunately we didn't remember to note the distance from the phone to the sensor
|
|
|
when stopping the sound.
|
|
|
|
|
|
### Exercise 3: Controlling the robot using sound
|
|
|
Before starting on this exercise we plugged our sound sensor into the NXT's sensor port 1 instead of 2, as we learned in the last exercise
|
|
|
that the supplied program code assumed that the sensor was plugged into port 1.
|
|
|
For this exercise we used the suggested ***SoundCtrCar.java*** program. Without reading - or opening - the code, we ran the program. This resulted in
|
|
|
a robot that sprinted for the edge of the table, while two of us were clapping around it. At some point the robot stopped one of its motors and started
|
|
|
spinning, with us still clapping away. Quickly after the first behavior change, the NXT reversed the direction of its spinning, until it finally
|
|
|
stopped and - to the best of our knowledge - terminated with us still clapping around it. After placing the robot 'safely' on its box beside Camilla's head, we started
|
|
|
talked about the program and the robot's behaviour. The loud sound of Camilla's voice near the sensor resulted in the robot sprinting forward, nearly toppling over
|
|
|
the edge of the NTX-box.
|
|
|
|
|
|
After this rather exciting experience with the program, we looked at the code and discovered that the robot wasn't really programmed to 'hear' clapping
|
|
|
noises. Instead, the program had four while-loops inside another while-loop, each waiting for a sound reading above 90. In between each of the four loops,
|
|
|
the robot would respectively drive forward at full speed, spin right, spin left, and stop. The outermost loop made sure that as long as the escape button
|
|
|
wasn't pressed, the code would move to the next of the four loops when hearing a sound above 90.
|
|
|
|
|
|
Although we tried to clap very close to the robot it was clear from our experiment, described above, that our claps rarely resulted in a reading above 90.
|
|
|
It is certainly possible (from the result of exercise 1, Table 3) to obtain a reading above
|
|
|
90 from a clap, but this is a difficult task if the robot, and thereby the sensor, is moving, or if the sound sensor isn't both to our clap and facing it
|
|
|
(it's hard to clap right beside the sensor while making sure not to hit it as it's driving towards you).
|
|
|
|
|
|
During the discusion of the program behavior, we discussed which type of controller the ***SoundCtrCar.java*** program is. We ended up classifying it as a
|
|
|
special kind of bang-bang controller, as it switches state based on a binary result (reading >90 or not). A difference to a regular bang-bang controller is
|
|
|
that it loops between four states rather than switching between two.
|
|
|
|
|
|
### Exercise 4: Adding a listener to the inner loops
|
|
|
|
|
|
We implemented a button listener on the Escape button, using the LeJOS tutorial [5]. The button listener can be seen in
|
|
|
Figure 3: It simply calls **System.exit(0)** when escape is pressed. We considered simply inserting a **break;** statement in place of the call to **System.exit()**,
|
|
|
but since the button listener is not defined inside the loop, this would not work. Neither could we just call the **Car** class and tell it to stop its engines, as
|
|
|
the program would still be running. We therefore decided that System.exit was the best (simple) solution, and it turned out to work perfectly.
|
|
|
|
|
|
![Button listener implemenation](week5/img/ButtonListener.png)
|
|
|
|
|
|
*Figure 3: Button listener implementation.*
|
|
|
|
|
|
### Exercise 5: Clap controlled car
|
|
|
We implemented the control using Toledo's heuristic: *A clap is a pattern that starts with a low-amplitude sample (say below 50), followed by a very-high amplitude
|
|
|
sample (say above 85) within 25 milliseconds, and then returns back to low (below 50) within another 250 milliseconds.* [6]
|
|
|
We implemented the program using several states where the robot was looking for different kinds of information - e.g., having registered a sound level between 25 and
|
|
|
50, the robot 'watches' for a sound level above 85 that occurs within 25 ms. This was implemented using several while-loops:
|
|
|
|
|
|
```java
|
|
|
while (noClap) {
|
|
|
soundLevel = sound.readValue();
|
|
|
LCD.drawInt(soundLevel,4,10,0);
|
|
|
|
|
|
while(soundLevel < 25 || soundLevel > 50) {
|
|
|
soundLevel = sound.readValue();
|
|
|
LCD.drawInt(soundLevel, 4, 10, 0);
|
|
|
}
|
|
|
|
|
|
time = System.currentTimeMillis();
|
|
|
while((System.currentTimeMillis() - time) < 25 && soundLevel < 85) {
|
|
|
soundLevel = sound.readValue();
|
|
|
LCD.drawInt(soundLevel, 4, 10, 0);
|
|
|
}
|
|
|
|
|
|
if(soundLevel < 85) {
|
|
|
continue;
|
|
|
}
|
|
|
|
|
|
time = System.currentTimeMillis();
|
|
|
while((System.currentTimeMillis() - time) < 250 && soundLevel > 50) {
|
|
|
soundLevel = sound.readValue();
|
|
|
LCD.drawInt(soundLevel, 4, 10, 0);
|
|
|
}
|
|
|
|
|
|
if(soundLevel > 50) {
|
|
|
continue;
|
|
|
}
|
|
|
else noClap = false;
|
|
|
}
|
|
|
```
|
|
|
|
|
|
We observed that tapping the robot's microphone is registered as a clap (with more certainty than our own claps). We made use of this when testing.
|
|
|
|
|
|
[![Clap controlled car](http://img.youtube.com/vi/WXd3zo7lgNM/0.jpg)](https://www.youtube.com/watch?v=WXd3zo7lgNM)
|
|
|
|
|
|
*Video 2: Our clap controlled car in action.*
|
|
|
|
|
|
Sometimes the robot's execution of the program did not go very well, seemingly because the robot's motors were making so much noise that a sound level above 50
|
|
|
was registered almost all of the time. The robot was also shaking a lot, which we speculated might affect the readings as well. As we mentioned earlier, even with
|
|
|
hard claps, it can be hard to get a sensor reading close to 90. We considered that it might be better to perform our own measurements and use averages of the resulting values,
|
|
|
since we would be clapping ourselves during testing and would thus want our implementation to fit with our own claps. However, due to the decent results and the motor sound being a larger issue,
|
|
|
we decided to go on with the exercises instead.
|
|
|
|
|
|
We did, however, perform a recording and data logging of a clap, as mentioned in a exercise 2. The clap was recorded in the bathroom, the place where the least of the noise
|
|
|
from the other people in the building could be heard. Thanks to the (relatively) good conditions for sound recording, we obtained a fairly 'clean' recording. It should be
|
|
|
noted that the bathroom was not tiled, but had a linoleum floor and wallpaper; i.e. it did not have very 'bathroomish' accoustic properties such as increased reverb.
|
|
|
Comparing the resulting graph in Figure 4 with Toledo's numbers, we see that it fits fairly well, rising quickly from below 40 to just above 90 and then dropping back to below 40
|
|
|
within 250 ms. This hints that, given optimal (/bathroomish) conditions, the robot should be able to recognize our claps as claps. I.e. our conclusions about disturbances
|
|
|
from the environment being the reason for the suboptimal behaviour of the robot are probably correct, as the values used in our implementation fit with our claps.
|
|
|
|
|
|
![Plot of bahtroom clap](week5/img/figure_1.png)
|
|
|
*Figure 4: Plot of bathroom clap.*
|
|
|
|
|
|
### Exercise 6: Party finder robot
|
|
|
In this exercise we mounted another sound sensor on the other side of Frej.
|
|
|
We briefly discussed having the sound sensors point a little to the sides, rather than straight ahead, so their directions of measurement would be more different. This
|
|
|
turned out to be practically troublesome and we did not try it out, as the robot seemed to function fine without the adjustment.
|
|
|
|
|
|
In the beginning of the exercise, we experimented with having the robot wearing disposable cups, intended to function as amplifiers, on the sound sensors. This, however,
|
|
|
turned out not to work very well - the robot registered noise far better once we removed the cups. The cups might have functioned better if we had shortened them or made
|
|
|
them point more to the sides. We did not experiment further, however.
|
|
|
|
|
|
We discussed the effect of the robot turning: When it turns in a direction, the corresponding motor is given more power. This could in theory cause the robot to register
|
|
|
more sound in that direction and thereby turn furhert that way - causing an ongoing turn until a louder noise is registered in the opposite direction. This would have been
|
|
|
interesting to investigate further, but we did not have the time (given that we provided ourselves with a three-hour limit).
|
|
|
|
|
|
The program has similarities with a PID controller, since it calculates how much it needs to change motorpower, by simply subtracting one sensor reading from the other
|
|
|
(eg. the left reading from the right reading). If the result is negative, then the right sensor picked up the most sound, so we need to increase power on the left motor,
|
|
|
which we do by subtracting the result (which was negative) from the standard motorpower, which in our case is 70. Vice versa, we add the (now positive) result to the right motor.
|
|
|
|
|
|
We saw immediate results from the initial program, and Frej responded somewhat as we expected. The power going into the left motor (ie. sensing more sound from the right sensor)
|
|
|
was always a bit higher when we didn't try and guide him though. We made an ad hoc calibration by adding 10 to the difference, and with this change, Frej started going straight
|
|
|
when there was no guiding sound, and he still followed the noise quite nicely. We didn't film the calibrated program though, and as you can see in the video, Frej wants to turn right.
|
|
|
|
|
|
[![Party finder bot](http://img.youtube.com/vi/UhwyAVI4cuU/0.jpg)](https://www.youtube.com/watch?v=UhwyAVI4cuU)
|
|
|
|
|
|
*Video 3: The party finder bot following noises in the room. The sensors used in this experiment are the two microphones that look kind of like hands.
|
|
|
The ultrasound sensor is only there because it looks like a head.*
|
|
|
|
|
|
## Conclusion
|
|
|
The exercises and experiments all went very well. We didn't encounter any major problems and the programming all went smoothly. The work distribution worked out well and we finished the practical part
|
|
|
within the 3 hours, that we were hoping to use. From the different ways we used the sound sensors, it seems like they enable a lot of functionality if used creatively and with a definite purpose.
|
|
|
Especially the two last exercises - the first, where we adjusted a listen/waiting algorithm to waiting for a clap instead of a loud noise, and the second, where we had Frej react very specifically to our noises -
|
|
|
showed that the sound sensors definitely has a use.
|
|
|
|
|
|
Since sound is waves going through the air, we knew from the beginning that the experiments could be subject to interference, which unfortunately also was the case.
|
|
|
However, by either drowning the other noise or taking the sensors to the bathroom, we still gained valuable results from the experiments.
|
|
|
|
|
|
## References
|
|
|
[1] Program for exercise 1 [SoundSensorTest.java](src/Lesson3programs/SoundSensorTest.java)
|
|
|
|
|
|
[2] Program for exercise 4 [SoundCtrCar.java](src/Lesson3programs/SoundCtrCar.java) (used in a modified version, as described)
|
|
|
|
|
|
[3] Program for exercise 5 [ClapCtrlCar.java](src/Lesson3programs/ClapCtrlCar.java)
|
|
|
|
|
|
[4] Program for exercise 6 [PartyBot.java](src/Lesson3programs/PartyBot.java)
|
|
|
|
|
|
[5] Tutorial used for exercise 4 [LeJOS-tutorial](http://www.lejos.org/nxt/nxj/tutorial/ListenersAndEvents/Listeners_Events.htm)
|
|
|
|
|
|
[6] Sivan Toledo's clap counter and discussion: [A Clap Counter](http://www.tau.ac.il/~stoledo/lego/ClapCounter/) |
|
|
\ No newline at end of file |