Acoustic Tape Measure: Difference between revisions
Line 31: | Line 31: | ||
temperature. The variation is approximately 0.2% per degree C. |
temperature. The variation is approximately 0.2% per degree C. |
||
Code currently assumes an air temperature of 25 C, |
Code currently assumes an air temperature of 25 C, |
||
which means ± 3% over the whole range of reasonable temperatures. |
which means ± 3% over the whole range of reasonable temperatures. At short distances, accuracy is limited by the 48 KHz sample frequency, corresponding to a distance of ~7.5 mm between samples. |
||
An estimate of temperature would be useful to improve accuracy. Even an almanac, giving average temperatures by location and time of year, would be helpful. |
|||
Location+date+time might be enough to get temperature estimates? |
|||
Is there another way? |
|||
:Perhaps a known-distance measurement? Physically adjacent XO's? Could this be used as a air thermometer (Aa)ctivity? [[User:MitchellNCharity|MitchellNCharity]] 15:45, 3 October 2007 (EDT) |
|||
Alternatively, it is in principle possible to use this system to measure the air temperature due to its effect on the speed of sound. However, to achieve accuracy of 1 degree C, it would be necessary to separate the laptops by a fixed distance of at least 10 meters, known to 1 cm accuracy. This is extremely difficult, and unlikely. |
|||
Full-spectrum white noise is used to maximize accuracy. |
|||
The test signal uses the entire audio spectrum to maximize accuracy. Specifically, the test sound is a [[Wikipedia:MLS]]. |
|||
The system only seems likely to work well when the laptops are facing each other and have |
The system only seems likely to work well when the laptops are facing each other and have |
||
Line 47: | Line 47: | ||
Stability is not perfect. Typically the program runs for a few hundred measurements before hitting a networking bug. This corresponds to about 15 minutes of continuous measurement. |
Stability is not perfect. Typically the program runs for a few hundred measurements before hitting a networking bug. This corresponds to about 15 minutes of continuous measurement. |
||
Acoustic Tape Measure originally used Gstreamer for audio playback and recording. However, this proved to create threading bugs when combined with GTK and Telepathy, as all three toolkits share the same GLib mainloop. Therefore, the playback and recording were transitioned to use the ALSA aplay and arecord tools. |
|||
Now uses aplay/arecord rather than gstreamer for recording. Incorporates a delay to compensate for |
|||
amplifier weirdness, bug {{ticket|3813}}. |
|||
The code incorporates a delay to compensate for corruption at the beginning of a microphone recording, bug {{ticket|3813}}. |
|||
==Ideas for use== |
==Ideas for use== |
Revision as of 21:44, 15 October 2007
Please copy/paste "{{Translationlist | xx | origlang=en | translated={{{translated}}}}}" (where xx is ISO 639 language code for your translation) to Acoustic Tape Measure/translations | HowTo [ID# 70988] +/- |
|
Acoustic Tape Measure determines the physical distance between two XO's by measuring how long it takes sound to travel between them.
Measurement Algorithm
Normally, distance measurements that use audio transit time work by first synchronizing the clocks on the two computers. The receiver starts recording, and notes the wall-clock time at which recording started. The sender then plays some sound, noting the wall-clock time at which playback was initiated. The distance is then determined by the amount of time between the start of playback and the receiver hearing the pulse.
The speed of sound is over 300 meters per second, so 1 cm accuracy requires synchronization to within about 30 microseconds. This is very difficult to achieve, even with advanced tools like NTP, over an unreliable wireless network. Moreover, determining at what time recording or playback started is very difficult. The audio function calls typically take several millisecond to return, and recording or playback could have started at any point during that interval. Accurate timing is especially difficult on a multitasking, non-realtime operating system like the XO's Linux kernel, and even more so due when writing in a high-level language (Python) on an overtaxed, underpowered processor. On the XO, this would a be a futile approach.
Acoustic Tape Measure sidesteps the synchronization issue entirely. Instead, it uses the fact that the XO's microphone can hear the output of the XO's speaker. Therefore, the algorithm works by turning on both XO's microphones, and then having each XO play a distinctive sound. Each XO will hear its own sound almost immediately, but there will be a delay before it hears the other XO's sound, due to the propagation delay. The XO that plays a sound first will hear its sound immediately, but it will hear the second XO's sound delayed by the propagation. The XO that plays second will hear the first XO's sound delayed, but hear its own sound immediately. Therefore, the first XO will measure a longer distance between the two sounds, and the second XO will measure a shorter distance. The difference between their measurements is twice the propagation delay. In this way, Acoustic Tape Measure computes the distance between two laptops by taking the difference between two measurements of the same interval.
Development notes
In testing, accuracy was 1 cm or better at 2 m. At a distance of 10 meters, measured distance typically fluctuates no more than 1 cm, with sporadic errors up to 4 cm. However, there is likely a systematic error of a few cm, depending on temperature.
The measurements seem to be extremely accurate, under controlled conditions. In fact, accuracy seems to be limited by variation in the speed of sound with air temperature. The variation is approximately 0.2% per degree C. Code currently assumes an air temperature of 25 C, which means ± 3% over the whole range of reasonable temperatures. At short distances, accuracy is limited by the 48 KHz sample frequency, corresponding to a distance of ~7.5 mm between samples.
An estimate of temperature would be useful to improve accuracy. Even an almanac, giving average temperatures by location and time of year, would be helpful.
Alternatively, it is in principle possible to use this system to measure the air temperature due to its effect on the speed of sound. However, to achieve accuracy of 1 degree C, it would be necessary to separate the laptops by a fixed distance of at least 10 meters, known to 1 cm accuracy. This is extremely difficult, and unlikely.
The test signal uses the entire audio spectrum to maximize accuracy. Specifically, the test sound is a Wikipedia:MLS.
The system only seems likely to work well when the laptops are facing each other and have uninterrupted line of sight. However, early performance testing suggests that it is more tolerant to these disturbances than initially estimated. The measurements are unlikely to work well if the distance is changing during measurement.
Each measurement cycle requires about 8 seconds.
Stability is not perfect. Typically the program runs for a few hundred measurements before hitting a networking bug. This corresponds to about 15 minutes of continuous measurement.
Acoustic Tape Measure originally used Gstreamer for audio playback and recording. However, this proved to create threading bugs when combined with GTK and Telepathy, as all three toolkits share the same GLib mainloop. Therefore, the playback and recording were transitioned to use the ALSA aplay and arecord tools.
The code incorporates a delay to compensate for corruption at the beginning of a microphone recording, bug #3813.
Ideas for use
2D Position determination
Even given full knowledge of the distances, determining the locations of an arbitrary number of laptops is a nontrivial nonlinear optimization. And the laptops have to face each other. And computation takes a long time.
However, in the simple case of 3 laptops, 2D positioning may be possible. For 3 laptops, it is not too difficult to ensure that all 3 laptops face each other and all paths are free of obstacles. The corresponding math problem is also trivial.
Position graph matching game
The Boston Museum of Science has an exhibit which measures user distance from a computer along a long mat. The computer then horizontally scrolls a graph with a pattern, along with your current distance. Idea is you have to scurry back and forth to try and match your position to the pattern. Vaguely Digital Dance Revolution-like. I'm not really sure the concept works, but it could be easy to try, and with music added, and kids able to draw their own patterns, it might be interesting.
The algorithms would have to be greatly accelerated before something like this would be possible. Children would have to move with one laptop in hand, pointed at the stationary laptop. Also, the measurements are unlikely to work well if the distance is changing during measurement.
One possibility would be for the computer to say "go N meters away" and then have a competition to see how many tries it takes to get within, say, 5%. This could be a good distance-sense training exercise.