Acoustic Tape Measure

  This page is monitored by the OLPC team.

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# 83308]  +/-

Acoustic Tape Measure Status alpha—under development sources in projects/acoustic-measure-activity TST {{{1}}} POT | es  Benjamin Schwartz

  For the general public

Distance (AKA Acoustic Tape Measure) determines the physical distance between two XOs by measuring how long it takes sound to travel between them.

Using the Distance activity

You need two laptops in order to use this activity. Steps:

1. launch the Distance activity on one of the XOs by clicking on the icon on the activity taskbar;
2. Send an invitation to the other XO;
3. launch the Distance activity on the second XO by clicking on the invitation icon on the activity taskbar;
4. click on the "Begin Measuring Distance" button found near the top of the activity view on both XOs;
5. the first XO will send an audio pulse; the second XO will respond with an audio pulse of its own; then both XOs will calculate and display the distance between them in meters;
6. this process will repeat until you click on the "Stop Measuring Distance" button or you exit the activity.

Notes:

• Try not to move the laptops while they are taking measurements as it will result in a bad measurement;
• If the "Begin Measuring Distance" button does not activate, try relaunching the Distance activity again on the second laptop from the Neighborhood view.
• Atmospheric conditions can impact the accuracy of the measurement; there are overrides to the default settings under the Atmosphere tab.

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 Maximum Length Sequence.

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.

  For the general public

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 three laptops, 2D positioning may be possible. For three laptops, it is not too difficult to ensure that all three 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.