Group members participating: Ole Rasmussen, Kasper Sørensen
As can be seen we have added a listener (green color) to exit the system when ESCAPE is pressed. It does not matter in what states the SoundCtrCar is in or if it is waiting for a loud sound to be heard, the system will end if ESCAPE is pressed.
We have also modified the condition (gray color), since we do not need to check the ESCAPE button here anymore.
Last, we deleted the statements (red color) after the while loop, since we would never reach this point in the program anymore. We did not add this to the listener, since the listener runs in a different thread. One could run the main program in a thread that the listener could stop, and then execute the deleted statements.
The modified program terminates immediately when the ESCAPE button is pressed, just as expected.
Goal
To complete the exercises for Lego Lab 3.
We will experiment with the sound sensor and in the process construct several robots that are variations of the 9797.
Plan
Since our goal is to complete the exercises for this weeks lab the plan will be to complete each exercise in sequence:
- Exercise 1 & 2: Experiment with the sound sensors ability to measure sound: distance, frequencies and object types
- Exercise 3: Sound controlled car
- Exercise 4: ButtonListener implementation
- Exercise 5: Clap controlled car
- Exercise 6: Party finder that drives towards loud sounds
Exercise 1 & 2
In this exercise we will experiment with the sound sensors capabilities by measuring different sounds coming from different objects at different distances.
Factors
- Environment: the physical environment in which the experiment takes place may interfere with the measurements of the sound level. The shape and texture of the of the room may for example absorb or allow sound to pass around it more or less thus allowing or disallowing more or less sound to reach the robot. Background noise is also something that should be taken into account
- Human error: If we for example want to measure sounds from a clap, the human producing the clap will not be able to generate the exact same clap each time
- Sound frequency: High frequency sounds tends to loose momentum faster than lower frequency sounds. This would mean that the sensor might have a hard time registering high frequency sounds emitted far away as they don't travel as far as easily as low frequency sounds
Setup
We have placed the robot with the sensor in an area where we believe the environment has the least impact on the measurements: on one of the large tables in Lego Lab (see figure 1). The placement of the robot is ca. center in the room and thus allows for the minimal disturbance from close objects. The elevation means the sound won't easily be disturbed by table legs etc.
With regards to background noise we did this experiment at a time where only we were in the room. The sound sensor would read a background-noise value of 3-4 which we consider as close to complete silence as we could possibly get.
With regards to background noise we did this experiment at a time where only we were in the room. The sound sensor would read a background-noise value of 3-4 which we consider as close to complete silence as we could possibly get.
 |
| Figure 1 - Setup: 10cm, 1m, 3m, 5m and 10m |
The sounds we have chosen to measure are picked based on their charasteristics. We believe that some are low frequency while some are high frequency. We will be making the following measurements:
- Sound sources: clapping, whistle (high frequency), and hitting a cardboard box with a stick (low frequency)
- Distances: 10cm, 1m, 3m, 5m, 10m
Results
 |
| Figure 2 - Clapping measured with sound sensor |
 |
| Figure 3 - Whistling measured with sound sensor |
 |
| Figure 4 - Cardboard box hit with a stick measured with sound sensor |
Analysis
Starting with the clapping we can see on the graph (figure 2) that it is easily detectable at 10cm from the robot. At 1m the sound readings decrease dramatically from peaking at around 90 to peaking at around 55 but it's still easily detectable. Even at 10m the sound sensor registers well above 30 for a clap. An interesting observation is that the 5m measurement seems to be louder than the 3m one. We believe this to be caused by the human factor we described above - we simply clapped a bit louder than we should have.
The whistling (figure 3) is very interesting because it's clearly detectable at 10cm but moving further away dramatically decreases the detectability to almost zero already at a distance of 3m. At 3m it would be difficult to distinguish between whistling and background noise assuming the robot isn't be in a completely silent environment. At 10m it's almost impossible to detect the whistling.
Compared to the whistling the cardboard box measurement is completely opposite, and this supports our initial theory about it emitting the lowest frequency sounds among the three. It is easily detectable at all measured distances. An interesting trend on all graphs except 10m is that the sound reading seems to be capped at around 93 or so. This is most pronounced on the graph for 10cm; the sound reading rises quickly and then when reaching around 93 it keeps outputting that reading for a while. In reality the cardboard box sound looks nothing like this so we conclude it's a restriction in the NXT sound sensor that a max of 93 can be output.
Exercise 3
In this exercise we are to install SoundCtrCar.java and observe and describe how it behaves.
Results
We installed the program and held the robot in our hands. We saw on the display, that it reacted to loud sounds, and that it had four different states {stop, forward, right, left} that it changed between.
We placed it on the ground, and quickly found that we needed to make pretty loud noises for it to change to the next state. After a short testing session, we were able to guide it towards a preset point and stop it there.
Analysis
We looked inside the SoundCtrCar.java program and quickly found what we expected. It listened for loud sounds and changed between states if such a sound was heard.
Exercise 4
The SoundCtrCar.java program from Exercise 3 had the problem that it would only exit if you held the ESCAPE button down at the exact moment when changing state from stop to forward. Since this is rare, we are asked to implement a ButtonListener that reacts when the button is pressed.
Results
Figure 5 shows the original program to the left and our modified program to the right. |
| Figure 5- Original SoundCtrCar (left) and our modified version using ButtonListener (right) |
As can be seen we have added a listener (green color) to exit the system when ESCAPE is pressed. It does not matter in what states the SoundCtrCar is in or if it is waiting for a loud sound to be heard, the system will end if ESCAPE is pressed.
We have also modified the condition (gray color), since we do not need to check the ESCAPE button here anymore.
Last, we deleted the statements (red color) after the while loop, since we would never reach this point in the program anymore. We did not add this to the listener, since the listener runs in a different thread. One could run the main program in a thread that the listener could stop, and then execute the deleted statements.
The modified program terminates immediately when the ESCAPE button is pressed, just as expected.
Exercise 5
The SoundCtrCar reacts to all kinds of sounds because it uses a very primitive way of deciding which sound to reach to:if the sound level passes the magic threshold of 90 it will react. In this exercise we are asked to implement a small algorithm to detect only claps. A clap starts at a low sound level, increases quickly to a high sound level and then decreases to a low sound level again. The following pattern is suggested:
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.
Implementation
We have developed the program which can be seen in figure 6.
 |
| Figure 6 - Program for detecting claps |
Our algorithm works by detecting the states defined in the clap pattern. We have defined three ClapStates = {Attack, Peak, Decay} each defined by a ClapState enum. We start with a ClapState of Attack. We then move from one ClapState to another when specific sound levels are reached. These levels are defined by the ClapState enum. A maximum allowed time for detecting a matching sound value is also recorded in the enum. If a sound level is not reached in the allowed time, we reset the algorithm by setting our state to Attack.
The highlighted parts describe the following for our ClapState enum:
- Red part
This is a boolean flag, describing if we need to detect something below or above a given threshold. - Brown part
This is the threshold value we need to detect to move to the next state in the detection algorithm. - Blue part
This is the time in milliseconds that we have to detect the threshold. If not detected within this time, we start over by moving back to ClapState Attack.
Given the implementation of the ClapState enum, it is easy to implement the algorithm, which can be seen in the detectClap() method. Here we simply move to the next state if the current ClapState is satisfied. If we satisfy the last ClapState (Decay) we have detected a clap. If we cannot move to the next ClapState in the allowed time, we reset to Attack.
Results
With the initial values for thresholds (brown in figure 6) set to 50, 85 and 50, it was very hard to detect a clap. We looked at our graphs from the first exercise to derive some useful constants. We tried with 50, 70, 50 and it was much better at detecting claps than for the default ones.We also had problems with the motors generating a lot of noise, and at times the sound level would never decrease to below 50, making it impossible for our algorithm to move from the Attack state to the Peak state.
When we made constant high noises, it would not react, as the Decay state would never be satisfied. This means that we could evade some noises which have longer Decay times then the allowed 250ms.
Exercise 6
In this exercise we construct a "party finder" robot with 2 sound sensors that can move towards a loud sound.
Results
The constructed robot can be seen in figure 7. The program for the robot can be seen in figure 8. Figure 9 shows a video of the robot following a computer playing music.
 |
| Figure 7 - Our partyfinder robot |
 |
| Figure 8 - Partyfinder source |
| Figure 9 - Partyfinder robot demonstration |
Analysis
Our first try at the partyfinder had the sound sensors mounted just above the wheels. This turned out to not work at all since the sensors would pick up noise from the wheels when moving. In the second try we mounted the sensors much higher as can be seen on figure 7.
The partyfinder works OK for sound sources close to the car (as can be seen in figure 9) but anything further away than 1 or 2 meters won't make the car turn. We are not completely sure as to why this is but we believe it to be either due to reflections in the room or interference between the sound sensors. An idea might be to mount a piece of paper between the sensors so e.g. sound coming from the left won't pass on to the right sensor and vice versa.
Conclusion
We have made all exercises for this week so next week we'll start on the week 5 exercises.
