This lab session will investigate the NXT sound sensor / microphone and its characteristics when mounted on the NXT main unit.
The main goal is to characterize the NXT microphone functionality under
different circumstances. Both use of a microphone and sound interpretation on and NXT are handled
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.
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
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
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.
‘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’.
’ 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 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.
When the connection is established, the window changes and it is possible to
download the created file. This window is shown in 7.
Sound controlled car
The java program SoundCtrCar.java (Ref2) was loaded to the N
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.
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
The time of a clap might vary from person to person, and amplitude for clapping might also vary.
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.
All measurements from this lab session are processed in either Matlab or Mathcad and are evaluated under the subparagraph “Results”.
Pictures of Lego model
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.
Ref 1: Mindstorms education 9797 (add-on: page 24-26)