When a project has a zero budget, everything has to be hacked and improvised, typically with duct tape. The data collection system for project Blindspin is a good example. (For a project description, see “Does it make sense to ride a bike with your eyes shut”)
If we had a budget, we would be looking for a high-end mobile data logger with millisecond accuracy. Since we don’t, we would very much prefer to use smartphone that someone has thrown away. And it seems we can.
The basic requirement is not very complex. Our system will consist of a pair of electronic goggles which are normally opaque, but which the cyclist can turn transparent by pressing a switch. We need to record the time of the keypress, hopefully with millisecond accuracy. We also need to collect GPS location information, so that we can determine the path the cyclist drove while blinded.
There are GPS data logger apps galore for Android. We found that the AndroSensor software is almost perfect. It collects GPS location, accelerometer information, and all other sensor data at resolutions of up to 50 milliseconds. The only problem is how to input information about the key presses. There is no sensor channel for that.
However, we realized that AndroSensor can record the ambient sound level in dB. So we decided to use the audio channel to store button data. In the simplest case, button down (vision occluded) is a loud noise, button up is a quiet noise.
A major problem is that AndroSensor (and most other software we looked at) always uses the phone’s own microphone, even when a line in is used. Thus, it is necessary to input the noise directly into the external microphone.
For a pre-test, we came up with a somewhat rubegoldbergish approach, but one that works. To generate the noise, we used an aviation scanner that has a reasonably large tangent button. The scanner’s autogain means that if there are no aviation transmissions, there is no sound output. However, if the tangent button is pressed, the noise is heard. The gain can be set so that the difference in noise levels is tens of dB.
To eliminate outside noise, the speaker was attached to the phone’s microphone with Blu-Tack (sinitarra), and the whole thing covered with more Blu-Tack. Thus, the microphone hears almost no external sounds at all. When the tangent is pressed, it hears the noise from the scanner, at tens of decibels.
The speaker is buried within the mass of Blu-Tack and pressed directly onto the phone’s microphone.
The whole system was attached to the bike handlebars with zip ties. Several different setups were used; the one in the picture below is operated by the index finger. A simpler way was to mount the scanner facing the other way and below the handlebar, so that it could be operated by the thumb.
The ergonomics of the system are horrible. However, at this stage it is simply needed to demonstrate the data collection method. Subject A tested it on a straight road and a curved one. Whenever A closed his eyes, he pressed down on the tangent. Whenever he opened them, he let go of the tangent.
The image below is the first data ever produced in this project. The red blue line is the speed given by AndroSensor. The red lines are the dB levels.When the red line is above 60 dB, the eyes were closed and the tangent was pressed, and thus the scanner outputted noise directly into the phone’s microphone.
We have collected more data from subject A, but will not release data yet. Why? It is not ready yet, but even more importantly we don’t want to skew the results that the volunteers might get. Such ignorance is almost always desired in human research (with the exception of self-testing). The volunteers should have no idea whether it is possible to keep the eyes shut for one second, or for twenty — and they really should not know what we are even looking for at this stage.
For subject A in this particular case, he had a total of 9 occlusions within a 20-second period, with approximately 500-ms eyes-open periods. The occlusion times are between 1 and 2 seconds for this subject for this point on this track for this setup. The occlusion times may be longer in other circumstances… or they may be shorter.
In the final application, we will use a somewhat more complex keypress arrangement, since we will be using an Arduino to control the system. Most likely, we will use a buzzer to create an audible signal about the state of the goggles (loud buzz when goggles opaque, silent when goggles transparent).
The specs of this system are not ideal, but they are actually good enough even for real science. Data are stored at 50-millisecond intervals, but even in simulators, typical intervals are 100 ms. The biggest problem is timing the key press; even if we can get a perfectly sharp rising edge, we will have a 50-millisecond uncertainty in the timing. In practice, it may be even larger if the edges are not completely sharp. We can thus reasonably expect to get a 100-ms time resolution, but not much better. That will be sufficient, as long as we are careful to note it in the analysis.
Of course, this system does have major disadvantages, such as unknown delays in the phone software. We will design a better system if at all possible. But this is a fallback solution, which in the very worst case we can use as the actual solution. Costing zero euros.
See also Blindspin project page.
