Science Project Blog
Upper School students publish their progress several times weekly.
Blog authors choose whether to mark items public or limit them to the Catlin Gabel community. Please log in to see more posts.
Riddle me this...
While exporting and uploading my Cinco de Mayo edit to the web, I came across something very interesting. If I simply export the movie as quicktime directly from final cut, it comes out to be 190 megabites, and is pretty bad quality. However, James taught me how to export it in HD (720p), which looks 100x better, and somehow is only 15 megabites... I couldnt understand how something that was of such high quality could be compressed into such a small package; James tried to explain it to me, but I had never heard of half the words he said. Oh well.
HD
Low quality
Staff Meetings are Scary
So yesterday I had to stand at the front of a classroom in front of all the teachers here at BSE and the principal (my boss) and tell them all about the project I'm working on. Thankfully it was a pretty laid back meeting and the faculty were very receptive to the ideas I was pitching about using the garden in their curriculum next year. I also found an AMAZINGLY helpful book titled "The Growing Classroom" which is chock full of class plans designed to use a garden to teach 2nd-6th graders in a number of subjects ranging from science to nutrition and sustainable living. Overall the meeting went well, and I think my boss was pleased (yesss!!).
I'm also now in charge of getting a wooden chair that the fourth grade built engraved and stained to put in the garden. Hopefully I'll have enough time to get that done (I'm pretty sure I will).
Also, composting is going extremely smoothly. The kids continue to impress me with their intuitive feel for what kinds of material can and can't be composted. It's great to see them walk up and proudly throw their banana and orange peels into the correct bin. Having the fifth graders on the sustainability team is also going to be a big help, since someone is going to need to monitor the process when I'm not there to help. I am concerned that the 5th graders have to miss class, but hopefully the impact isn't too negative because I don't see a readily available alternative.
And now I must go tend to issues such as who I can borrow staining brushes from.
All's well,
Nav
Friday, 11 AM
I start my project tomorrow at Sockeye Creative. We are moving the entire editing suite from their current building in Union Station into their new space, so there will be a lot of work to be done. Im super excited about begining my project there, it looks like they have a lot of great stuff in store for me.
State Fair Reflections and Opportunity for Market Research
The fair was great! Out of the eight or so of my judges, seven of them understood my device, understood my process, and the device's importance and potential impact, and gave enthusiastically positive feedback. A couple of times one of the judges brought a friend along and gave an intro of what he thought of my project before I talked about my project.
A few of them asked me where I was planning to go to college, and they had all been to the Stanford campus and told me about how much of a good time I'll have there.
One telecommunications engineer named John was especially enthusiastic and gave me his card. He was interested in taking the idea further. I sent him an email, but I haven't heard back. I'll send him another email in a sec.
He mentioned I could tell people not only how they're oriented via the vibration, but also tell them where they are. Without knowing much about implementing location awareness, I instinctually want to keep the device silent and simple like I've designed it.
Anyway, he has connections with blind organizations. I think it's about time I conduct some market research. I'd like to give blind people descriptions of the device and find out how helpful they think it would be, and get feedback on how they want the ideal device to operate.
Implementing the Coprocessor and New Findings About Gyroscopes
If you want to get to the meat of this post, skip the next paragraph that describes what I've been up to the past few days. Below it I've written my findings of why my device hasn't already been made, and when it may be feasible if it isn't already.
As I wrote the program to use my gyroscope to find the bearing, I found that BASIC stamps don't do floating point arithmetic. That is, 3/2 = 1 to the stamp. For my calculations, I need very high accuracy, because my program ideally loops eighty times per second, and I continuously add all the values together and multiply them by the precise time each loop takes to integrate the angular speed to find the bearing. I tried making my values very large so that they could be accurate and not require decimal places, but the numbers were too large to use in my calculations (the stamp supports 16-bit integers. If I want the integers to be signed, they can range from -32768 to 32767. I'll include the english equivalent of code that I wrote for that program below. As I looked for a stamp that enable floating point arithmetic (one doesn't exist) I came across a tiny and inexpensive coprocessor that enables floating point arithmetic and 32-bit integers. Hooray! Two versions are available. One is smaller and $10. The other is twice the size and $20. I wrote the code to implement the earlier version, but then I found that the first version doesn't have a modulo operator, while the newer version does. I need the modulo operator because when the bearing increases from 359 degrees to 360 degrees and further, I want the bearing to return to 1 degree and then 2 degrees. It also works when the numbers are negative, for the opposite direction. Because the code is slightly structured slightly differently between versions, and I wanted the cheaper, smaller coprocessor, I debated writing a simple calculation that would give me the equivalent of the modulo operator. Yet that would require more instructions written to the coprocessor, which would increase the time each loops takes. In order to improve accuracy, I need to decrease the time of each loop. So I then wrote the code for the second coprocessor, which I also include below. But now I have to wait for the coprocessor to arrive in the mail. It will come mid-next week. Until then, I can set up my testing environment (I got a Lego robot from Dale that I can program to use as my simulator). I may never get to test, depending on the accuracy of the gyroscope and coprocessor, but if I can test, I'll need to do so as soon as possible. Also until the coprocessor comes, I can continue researching gyroscopes.
I'm researching all the different types of gyroscopes I can find by looking through MIT's electronic databases (thanks to my sister. Stanford won't yet let me access their electronic databases). I'll soon blog about how each type of gyroscope works soon, but the importance of my research has been finding the accuracy of present gyroscopes, and being able to predict, based on their speed of improvement, when gyroscopes will enable me to build an accurate, small, and inexpensive device.
Ultimately, I found that gyroscopes may not yet be accurate enough for me to create an accurate device, but it's only a matter of time until they are.
Many articles say that micro-machined gyroscopes have attracted a lot of attention in the past decade because they've become tiny and inexpensive. In 1998, they were so expensive their use in cars was restricted to the luxury vehicle market. Now, however, their use is widespread, especially in the clinical community and the consumer electronics industry. Yet the drift of these small and inexpensive gyroscopes requires that they only be used for short periods of time, on the order of minutes, before requiring recalibration.
In all my research, I haven't found articles that discuss my device as a possibility. I don't know whether other scientists have thought about using this technology (a device that vibrates when it points in a certain direction, to be used by blind people to gain a heighten sense of orientation), and then found that the necessary accurate, small, and inexpensive hardware didn't exist.
There's clearly a need for such a device. It could help blind people orient themselves. For one of last year's Diversity Day workshops, I was in George's workshop, and we walked around blindfolded using canes. The feeling of disorientation was slightly sickening. George told us the story of when he would walk to school, and he would know he was walking in the right direction because there was a highway running along his left. One day, he realized the highway was behind him. He had walked unknowingly across a four-lane highway that always had traffic.
My device would have prevented this disorientation.
I used to think the feelSpace experiment didn't take off and produce practical devices because that wasn't the aim of their experiment (they instead tried to find out if humans can access a new sense in a new way. They found humans can access this new sense using existing ways of sensing), and the prototype they built wasn't practical. These two reasons are true, but from my research, I conclude that the main reason their prototype wasn't developed and put to practical use was that they used compasses.
Many articles describe the heterogeneity of the magnetic field inside modern buildings, due to metallic structures and electrical appliances in the vicinity. As I found experimentally, compasses often give inaccurate headings indoors.
Accelerometers can't be used to detect rotation about a vertical axis. GPS can only track heading based on movement (see one of my posts last week).
The only device that can accurately measure orientation is a gyroscope. Yet these devices are only accurate for short periods of time. One article found that their gyroscope drifted three to five degrees in thirty seconds.
The device requires a gyroscope that will drift less than five degrees in two hours or longer. Then, the blind person can zero the device by standing against a wall they know faces in the desired direction.
I don't know about the process of product development. When gyroscope technology becomes feasible for this device, I'd love to be the one to prototype the device, and build the ideal device (I imagine it will be a patch a few millimeters thick they can slip into their breast pocket, and it will silently vibrate just enough so that the person can feel it). If I indeed can (if the real-world process of product development will allow), I'd like to build the device at Stanford.
English equivalent of my first gyroscope program, sans coprocessor:
Note: Integrating the yaw rate to find bearing is a simple calculation, but this calculation becomes complicated when we face the limitations of PBASIC (our variables can't exceed -32768 to 32767, coupled with our need to average readings to offset our gyro reading without using division. We need to avoid decimal numbers, because decimals are truncated. That is 3/2 = 1.
Initialization:
Read the speed of the stationary gyroscope five times. Add these values together. If the readings were perfect, we'd get a sum of 2560. If three of our values were 5 higher, and two of our values were 6 higher, we'd get a sum of 2587. We're going to scale all other numbers that we use during calculations by five so that we don't lose numbers via division (PBASIC truncates decimals. Unfortunately, 3/2 = 1 in PBASIC).
This sum is our OffsetSum.
Now we're going to use the OffsetSum as we integrate our gyroscope reading.
First, we read the gyroscope. Let's say we get a value of 517.
As promised, we need to scale up by a factor of five. So now we'll have a value of 2585. Let's call this number QuintupledGyroReading
If the gyroscope's bearing is 10º, and then we turn gyroscope to the right at a speed of 3 degrees per second for three seconds, and then turn the gyroscope to the left at the same speed for the same amount of time, we want the microcontroller to tell us the gyroscope once again has a bearing of 10º.
This means that as we integrate, we want clockwise speeds to cancel out counterclockwise. This means we want the clockwise speeds (which range from 0-512) to be negative, and the counterclockwise speeds (which range from 512-1023) to be positive. We want to shift the range of 0-1023 down by 512, so that we have a range of -512 to 511, where 0 means the speed is 0 degrees per second.
So now we're going to shift this value down by 5*512.
Our OffsetSum contains this value.
The OffsetSum is 512*5 + ErrorThatWeOffset*5.
In our case, we got a total error (over five readings) of 27. We want to subtract this error from our later quintupled readings from the gyro.
So now we'll take QuintupledGyroReading - OffsetSum to both scale down our range (to make speeds of different directions have different signs) and to offset our quintpuled gyro reading.
Now it's time to integrate our speed to find our bearing.
We'll multiply this gyro reading (a sample) by the time interval it takes to get this sample (the time it takes for one loop to run. In the program created on March 24, this value is 0.0042 seconds.
So we take QuintupledGyroReading * 42 and add it to all the other millions of values we've added during our integration.
This sum gives us our bearing (our angular orientation).
New we want to know the scale of our bearing (ordinarily, it would be 0 degrees to 360 degrees, but converting this value using the bs2 would be expensive time-wise, and would decrease the accuracy of our values, because we would have to use division. So we create our own scale).
We know that each step represents (300/511) degrees per second.
But remember that we've quintupled our steps, so our scale is five times larger. Each number step now represents a fifth of that value, or (60/511). And we have multiplied by seconds, so we get a bearing, not a speed.
Note that in our program, we don't ever have to multiply by this fraction. We simply use it to find our scale.
So how many steps must we have in order to reach 360º? Take 360 / (60/511) and we get 3066. We multiplied our bearing sample by 10,000 when we avoided the decimal time interval, so now we must multiply our scale by 10,000. So our scale is (-30720000 to 30660000). I can create a number this large by iterating another value to 937.5. So now if we turn the gyroscope in a full circle to the right or left, our program will read that our bearing is a value between -30720000 and 30660000. If we want to convert these values to degrees, we can multiply the value by (60/512).
But what happens when we turn two circles to the left? We want our program to warp around and still give only values (in the counterclockwise direction) from 0 to 30720000.
So whenever our bearing exceeds 30660000, we'll subtract 30660000 from it.
Similarly, whenever our bearing becomes less than -30660000, we'll add 30660000 to it.
We repeat our loop back to the location in code where we read the gyroscope hopefully eighty times per second.
Program implementing the coprocessor (this as a different program than that described above):
'Note: when a line is preceded by an apostrophe like this line is, it means the line is a comment and won't run as code.
' {$STAMP BS2}
' {$PBASIC 2.5}
'
' =========================================================================
' -----[ I/O Definitions ]-------------------------------------------------
Dout PIN 0 ' P0 <-- Dout (LISY300.2)
SCLK PIN 1 ' P1 --> SCLK (LISY300.4)
CSn PIN 2 ' P2 --> /CS (LISY300.5)
C_CS PIN 3 ' P3 --> /CS (uM-FPUV2.1) 'an arrow to the right means to the module
LED PIN 8 ' P8 --> LED
'==============================================================================
'-------------------- uM-FPU V3 SPI definitions -------------------- 2006-09-15
'==============================================================================
FpuOut PIN 14 ' SPI data out (connects to SIN/SDA)
FpuIn PIN 14 ' SPI data in (connects to SOUT)
FpuClk PIN 15 ' SPI clock (connects to SCLK/SCL) ' this can be either SCLK (SPI Clock) or SCL (I2C clock).
' I'm going to use the SCLK because its speed is 4 MHz, whereas that of the SCL is 400kHz
' must be connected through a resistor!
'-------------------- uM-FPU V3 opcodes ---------------------------------------
SELECTA CON $01 ' Select register A
SELECTX CON $02 ' Select register X
CLR CON $03 ' reg[nn] = 0
FWRITE CON $16 ' Write 32-bit float to reg[nn]
FREAD CON $1A ' Read 32-bit float from reg[nn]
ATOF CON $1E ' Convert ASCII to float, store in reg[0]
FADD CON $21 ' reg[A] = reg[A] + reg[nn]
FSUB CON $22 ' reg[A] = reg[A] - reg[nn]
FMUL CON $24 ' reg[A] = reg[A] * reg[nn]
FDIV CON $25 ' reg[A] = reg[A] / reg[nn]
FCMP CON $28 ' Float compare reg[A] - reg[nn]
FSTATUS CON $3B ' Float status of reg[nn]
FCMP2 CON $3D ' Float compare reg[nn] - reg[mm]
FNEG CON $3E ' reg[A] = -reg[A]
FABS CON $3F ' reg[A] = | reg[A] |
READSTATUS CON $F1 ' Read status byte
BREAK CON $F7 ' Debug breakpoint
TRACEOFF CON $F8 ' Turn debug trace off
TRACEON CON $F9 ' Turn debug trace on
TRACESTR CON $FA ' Send string to debug trace buffer
TRACEREG CON $FB ' Send register value to trace buffer
SyncChar CON $5C ' sync character
FMOD CON $50 ' reg[A] = reg[A] MOD reg[nn]
SYNC CON $F0 ' Get synchronization byte
VERSION CON $F3 ' Copy version string to string buffer
FTOA CON $1F ' Convert float to ASCII
LTOA CON $9B ' Convert long integer to ASCII
READSTR CON $F2 ' Read string from string buffer
'-------------------- uM-FPU variables ----------------------------------------
dataWord VAR Word ' data word
dataHigh VAR dataWord.HIGHBYTE ' high byte of dataWord
dataLow VAR dataword.LOWBYTE ' low byte of dataLow
dataByte VAR dataLow ' (alternate name)
opcode VAR dataHigh ' opcode (same as dataHigh)
format VAR dataLow ' format (same as dataLow)
status VAR dataLow ' status (same as dataLow)
status_Sign VAR status.BIT1 ' Sign status bit (0-positive, 1-negative)
'==================== end of uM-FPU SPI definitions ===========================
'==============================================================================
'==================== main definitions ========================================
'==============================================================================
' -----[ Constants ]-------------------------------------------------------
Yes CON 1 ' Yes Constant
No CON 0 ' No Constant
'----( Registers )----------------------------------------------------
SUM CON 1 'register 1
OFFSET CON 1 'also register 1
READING CON 2 'register 2. This is the reading from the gyroscope.
TIME CON 3 'register 3
INTEGRATION CON 4 'register 4
SCALEMAX CON 5 'register 5
FIVE_DEGREES CON 6 'register 6
NEG_FIVE_D CON 7 'register 7
'Rather than 0 to 360 degrees, our scale is (512 steps/(300degrees/s))(1/0.00042s)(360degrees/ 1 circle)= 1,462,857.142657 steps/cirle
' -----[ Variables ]-------------------------------------------------------
' Note: An unsigned BYTE's value can be 0 to 255. An unsigned WORD's value can be 0 to 65535
Value VAR Word ' ADC Result Value. This is the speed of the gyroscope.
Reps VAR Word
LessThanFiveD VAR Bit
GreaterThanNegFive VAR Bit
BothYes VAR Bit
' -----[ EEPROM Data ]-----------------------------------------------------
' -----[ Initialization ]--------------------------------------------------
Initialization:
HIGH CSn
LOW SCLK
PAUSE 250
'Reset:
DEBUG CR, "umfpuV3-spi", CR
GOSUB Fpu_Reset ' reset the FPU hardware
IF status <> SyncChar THEN ' check for synchronization
DEBUG "uM-FPU not detected"
END
ELSE
GOSUB Print_Version ' display the uM-FPU version number
DEBUG CR
ENDIF
HIGH C_CS
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [CLR, SUM]
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [CLR, INTEGRATION]
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FWRITE, TIME, $39,$DC,$33,$72] ' 0.00042 in hex
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FWRITE, SCALEMAX, $49,$B2,$92,$49] '1,462,857. This is the maximum value in our scale.
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FWRITE, FIVE_DEGREES, $46,$9E,$BA,$EA] '1,462,857 (5/360) = 20317.458. This number shows how many steps it takes to reach five degrees of zero. (zero can be thought of as north)
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FWRITE, NEG_FIVE_D, $C6,$9E,$BA,$EA] '-20317.458
LOW C_CS
FOR Reps = 1 TO 255 ' I want to stay in hex
GOSUB Read_Gyro
HIGH C_CS
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FWRITE, 0, ATOF, Value] 'HOW DO I LET THE COMPUTER KNOW THIS IS SIGNED?
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [SELECTA, SUM, FADD, 0] 'SELECTA+SUM means selct 1 as the A register. FADD+0 means select register 0 as the B register and calculat A = A + B
LOW C_CS
NEXT
HIGH C_CS ' here SUM should be selected as the A register. Make sure it is.
SHIFTOUT FpuOut, FPuClk, MSBFIRST, [FDIV, $FF]
LOW C_CS
'SUM should aleady be selected as the A register. Make sure it is.
' -----[ Program Code ]----------------------------------------------------
Main:
DO
GOSUB Read_Gyro
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [SELECTA, READING]
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FWRITE, READING, ATOF, Value] 'THIS MUST BE A STRING!
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FSUB, OFFSET] 'Offset the gyroscope value
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FMUL, TIME]
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [SELECTA, INTEGRATION, FADD, READING]
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FMOD, SCALEMAX]
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FCMP2, INTEGRATION, FIVE_DEGREES] ' if the integration value (the bearing) is less than +5 degrees
GOSUB Fpu_ReadStatus
IF (status_Sign = 1) THEN 'if INTEGRATION - FIVEDEGREES is negative
LessThanFiveD = YES
ELSE
LessThanFiveD = NO
ENDIF
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [FCMP2, NEG_FIVE_D, INTEGRATION] ' if the integration value (the bearing) is greater than -5 degrees
GOSUB Fpu_ReadStatus
IF (status_Sign = 1) THEN 'if INTEGRATION - FIVEDEGREES is negative
GreaterThanNegFive = YES
ELSE
GreaterThanNegFive = NO
ENDIF
BothYes = LessThanFiveD & GreaterThanNegFive
IF BothYes = YES THEN
LOW LED
PAUSE 250
HIGH LED
ENDIF
'DEBUG HOME, "Gryo Reading: ", DEC3 Value
LOOP
STOP
' -----[ Subroutines ]-----------------------------------------------------
Read_Gyro:
LOW CSn
SHIFTIN Dout, SCLK, MSBPOST, [Value\13]
HIGH CSn
RETURN
'==============================================================================
'-------------------- uM-FPU V3 SPI support routines --------------- 2006-09-15
'==============================================================================
Fpu_Reset:
SHIFTOUT FpuOut, FpuClk, MSBFIRST,
[$FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF]
PAUSE 10
' check for synchronization
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [SYNC]
GOTO Fpu_Status2
Fpu_Wait:
INPUT FpuIn ' (required for 2-wire interface)
Fpu_Wait2:
IF (FpuIn = 1) THEN GOTO Fpu_Wait2 ' wait until uM-FPU is ready
RETURN
Fpu_ReadStatus:
GOSUB Fpu_Wait ' read status byte
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [READSTATUS]
Fpu_Status2:
SHIFTIN FpuIn, FpuClk, MSBPRE, [status]
RETURN
Print_Version: ' print the uM-FPU version string
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [VERSION]
GOTO Print_String
Print_Float:
format = 0 ' set format to zero (free format)
' (fall through to Print_FloatFormat)
Print_FloatFormat:
opcode = FTOA ' convert floating point to formatted ASCII
GOTO Print_Format
Print_Long:
format = 0 ' set format to 0 (free format)
' (fall through to Print_LongFormat)
Print_LongFormat:
opcode = LTOA ' convert long integer to formatted ASCII
' (fall through to Print_Format)
Print_Format: ' send conversion command
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [opcode, format]
Print_String:
GOSUB Fpu_Wait ' wait until uM-FPU is ready
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [READSTR]
DO ' display zero terminated string
SHIFTIN FpuIn, FpuClk, MSBPRE, [dataByte]
IF (dataByte = 0 OR dataByte >= 127) THEN EXIT
DEBUG dataByte
LOOP
RETURN
Visiting the VA Research Center
Today Roger gave me a tour of his research center at the VA (the second largest audiology research center in the world), as well as the cognitive neuroscience area of OHSU, which is across the 1/8 mile hall.
Before, I was wary of the science research profession. I didn't want to be a scientist and realize I'd become a technician. I'd also heard of science researchers quitting their jobs and becoming bus drivers because they wanted a job that was more social. But at Roger's research center I felt a strong sense of community, and people seemed happy doing their work.
All Roger's colleagues were very friendly, and they worked in teams, and the facilities were very nice and aesthetically pleasing.
The coolest project I saw was that of a neuroscientist who was developing technology that could help physically impaired people who have no way of communicating to use their brains to have letters show on a computer screen.
I asked him when he thought he'd have it working, and he promised he'd do it in five years. He said he expected to have a working prototype in one year. (!)
Roger showed me the anechoic chamber he designed and helped build to carry out experiments, and it felt and looked wicked cool. I've attached a picture. Sound absorbing wedges covered all six walls (a wire mesh covered the wall under our feet) and absorbed 99% of the sound. This made the room sound dead (no echoes), and when we were quiet, I couldn't hear any sound expect the ringing of my ears, even though it was right next to a parking garage.
Roger also taught me about the different professions in their research center and the process of getting grants and publishing papers and gaining repute in the research community.
In five months, I just so happen to be attending one of the world's leading research institutions...
The Anechoic Chamber Roger Designed
Testing the Gyroscope
Thanks, Veronica! I've danced a lot, wandered around downtown, and read purely for pleasure in the sun. Even though winterim's over, I'll be dancing some more this week and relaxing plenty.
I went to Roger's house this afternoon and we solved the problem! We eventually found that the driver software that I'd downloaded was actually not the right driver. We used a program to allow us to write to COM7, which is the port (in software) that the computer uses to talk to the microcontroller. I would type letters, and the letter should be written to the transfer wire of the serial cable. After installing the proper USB to Serial converter software, we could see on the scope (a visual desplay of the voltage running through a wire) the voltage change that occured when I wrote a letter to the wire. When I typed the letter "a," we looked at the voltage, and saw a small pattern of highs and lows (see picture). "a" is an ascii letter, so we looked on a chart to find its representation in 1's and 0's. The first bit was high, to synchronize the two wires, and then there was a 1000011. The ones were high values and the 0's were low values. You can see the corresponding pattern on the scope screen in the attached picture. The line represents the voltage of the wire to which I type the "a."
So anyway, the gyroscope works just as it should, and I won't need to worry about the gyroscope rotating too quickly (more than 300 degrees in one second).
Anyway, then we found out experimentally how much current the gyroscope pulls. When we had the gyroscope plugged in, the microcontroller (which gave power to the gyroscope) pulled 9.6 mA. When we disconnected the gyroscope from the microcontroller, the microcontoller pulled 4.0 mA. Therefore, the gyroscope pulls 5.6 mA. This value was comfortably close to the recommended value of 5.25 mA.
Roger taught me that it's important to plug the wires into the breadboard before turning on the switch, because the wires actually bouce for, say, a span of 100 microseconds before they stick and the voltage levels out. The initial noise may interfere with the logic levels. Even if there are gates the same bounce occurs, so there are often capacitors that straddle the switches to dampen the noise.
Then we ran the program that reads the gyroscope, with all of my code to see the gyroscope's reading in the debugger, and see how often the gyroscope gave a reading. A very rough estimation from just looking at the debugger told us that every two seconds or so it gave 66,000 readings.
We then used the scope to find a much more accurate value for how long it took the program to loop, and how long it took the gyroscope to give a readnig. When the chip select gives a low voltage, it enables the gyroscope to give its reading. We could see a pattern of the chep select giving a low or high voltage. When the chip select gave a low voltage, the gryoscope was giving a reading. The low portions of the graph were much shorter than the high portions of the graph, indicating that my code that used the debugger, made some addition calculations, and wrote to and read from memory, took much more time run that the gyroscope took to give a reading. We could actually measure on the screen how long (in time) each segment measured.
Using the scope, we also saw that the gyroscope's clock gives thirteen readings for one reading of the gyroscope. We could also use the scope to see the serial data the SOut (serial data out) wire gave for one of the gyroscope's readings.
Anyway, we found that the when we only tell the gyroscope to give us readings and do nothing but have the microcontroller read what that reading is, the program's loop runs 381.63 times per second. When I'd had other code in the program (using memory and the debugger, etc.) the loop was running about 50 times per second. We need to shoot for 70 or 80Hz.
I need to write my code to run as efficiently as possible, and I need to find out whether I can set the microcontroller's SPI (Serial Peripheral Interface) clock to run faster than four megahertz. I need to have as many speed samples from the gyroscope and as much time for processing as possible, in order to have the most accurate angular heading possible, and the least amount of drift.
After I find this out, I'll run my program on the microcontroller using Roger's scope to see how long each program's loop takes to run, and then alter the code accordingly. Utimately, I'll need the scope to measure each time interval so that I can use this value to help me integrate the yaw rate to give me the bearing.
Lines of code that present data in the debugger is very intensive. The debugger makes data transfer both ways along a slow interface. But we found that the debugger doesn't actually slow the micocontroller, because when we disconnected the device and observed it when it ran without the debugger, the device ran just as fast.
We talked about the possibility of using three micocontrollers along with the gyroscope and the compass in the device. Each sensor wuold have a microcontroller to give clean and relavent data to the main micocontroller, which would process the data.
Roger also told me abuot a problem he ran into a couple years ago as he was building one of his devices that took him SIX MONTHS to solve!
A screenshot of five milliseconds of the scope's output while my program is running. The yellow line shows the voltage of the chip select wire. The green line shows the voltage of the wire that gives the SPI clock signal. The purple wire shows the voltage of the wire that gives the serial data.
Roger is the best
It turns out he's a neighbor of mine.
Roger gave me some very good advice for my paper. I need to split it into different disciplines for different readers. I'll write it three parts. The first part will contain the behavior study, structured as its own paper. The second will contain the technical study, structured also as its own paper (the structure will be based on articles in the JRRD, an engineering journal. The third part will contain the background information on the cognitive processes that underlie navigation. An abstract will precede each part of the paper, and an executive summary will precede my entire paper. I will include several appendices, such as an appendix describing my iPhone app and further work that I can do.
While I write my technical paper, I need to keep in mind that the typical reader of a journal only wants to learn about the function and components of the device. Yet in my paper, I also want to give a sense of the process I went through, but I want to focus more on the results. Yet I need to keep in mind the message I'm trying to get across each section of my paper.
Roger even wrote comments in the margins of five pages of my single-spaced paper. He also taught me how accelerometers work.
After dinner with his wife, Marie, we used the documentation out how the gyroscope gives yaw rate data to the microcontroller. I enjoyed it, because he taught me a lot of basic concepts of data transfer, and we were in his office in cushy chairs, reading on his projector, and sitting by the fireplace all at the same time.
The gyroscope sinks 1.6 V on an output pin when the gyroscope is stationary. When the gyroscope moves counter-clockwise, it gives a voltage between 0 and 1.6 V. The faster the gyroscope moves in that direction, the lower the voltage it gives. The maximum recorded velocity of the device is 330º per second, so when the device spins at least at this speed, it will sink 0 V on the output pin. In the other direction, the gyroscope will sink a maximum of 3.2 V when the device is rotating clockwise at least 330º per second. I don't expect to have an issue with these maximum speeds, because blind people don't turn this quickly when they're carrying out daily tasks and walking around.
So then this voltage gets converted from analog (a smooth gradation of voltage), to digital (precisely gradated numbers, as a set of ten 0's and 1's, which in base ten are numbers from 0 to 1023 or 1 to 1024). These are the readings that I get and use in my program.
I then calculate the bearing of the device by integrating (the area under a smooth curve representing speed gives distance) the yaw rate. I may find that my microcontroller doesn't read the data quickly enough to give me a sufficiently accurate estimate of the bearing. I'm approximating the angular bearing by sampling readings of the yaw rate, and multiplying the samples by the interval of time it took to get the reading. Simply put, I'm calculating the areas of the rectangles under the curve. The more quickly the microcontroller reads the data, the smaller the intervals of time are, and the narrower the rectangles are. When the rectangles are more narrow, the approximation is more accurate. I may use the trapezoid rule for integrating to make my approximation more accurate, but I don't want it to slow down the microcontroller.
In part to make filling out the forms easy, and to avoid having to move my stuff around all the time like I did last month, I'm going to do all my building at my house, rather than in Roger's shop or at the VA research center. I quite like my workspace because it's spacious, very convenient, and no one but me moves things around. Plus if I ever have a question (i.e. my current question: "Why do I still see the 'No BASIC stamp found' error, even after double-checking my wiring with Johnny from the IT department, trying two different power sources, tried two different microcontrollers, making sure I have the USB to serial converter software, and changing the micro-controller wire to serial cord setup?"), I can run to his place around the corner to ask.
My main goals for this week were to find out more about the gyroscope I have, through experience and the documentation, and also to find out about other options I have for devices that can detect orientation.
When I went to PSU yesterday, my and a couple librarians had a hard time finding an authoritative overview of how specific orientation sensors work, because engineers often write articles about specific aspects of their devices, and don't provide broad explanations from laymen. Patents achieve a degree of unhelpful abstraction. The 2007 encyclopedia had good sections on mechanical and a few other kinds of gyroscopes, and on MEMS (Micro-Electro-Mechanical Systems) technology, but not on MEMS gyroscopes, because the technology is too recent. The engineering librarian wasn't available, but fortunately, the library will be open all next week (not this weekend, however).
I did find that the only two main types of orientation sensors are compasses and gyroscopes. There are many different kinds of gyroscopes. They have evolved to become smaller, cheaper, and more accurate.
Another device that's used to determine bearing is GPS. Yet for my device, GPS doesn't work. GPS is only accurate when something is moving (like a car, airplane, or boat). Also, the object must be moving a relatively large distance, because GPS can only determine location within about 15 meters. GPS cannot determine the heading of someone who stands and turns.
Why? GPS calculates heading only by determining location. GPS measures location, and then calculates direction by connecting the dot to the next recorded location.
GPS works by having 24 to 32 satellites (each travel at about 7,000 miles an hour, weigh a literal ton, measure about 17 feet across with solar panels, and are solar powered but have backup batteries onboard to use during a solar eclipse) that constantly move, making two complete orbits in less than 24 hours. GPS devices pick up signals from at least three, usually at least four, satellites. The signals include three pieces of information:
1. Which satellite is sending the signal
2. Where the satellite should be at any time throughout the day
3. Status of the satellite (healthy or unhealthy), current date and time.
The GPS device calculates how long it took to receive each message from the satellites, and then it computes the distance to each satellite. The GPS can then can calculate its own location. (http://www8.garmin.com/aboutGPS/)
(As an aside, because the timing must be very accurate and the signal is so accessible, the global positioning system provides the accurate time to facilitate banking, mobile phone operations, and even the control of power grids).
In order for the GPS to determine direction, the GPS device must be moving. When the GPS knows where it was five seconds ago, and where it is now, it can find the direction in which the device has just moved.
If a blind person is standing in his office and turning, GPS can therefore not tell which direction he's facing. GPS is great for determining the bearing of cars, boats, and airplanes, but not for determining the bearing of a stationary person.
Here's an example of how GPS determines direction from a section of http://www.gpsreview.net/electronic-compass, titled "Movement is Necessary":
"Note that in order to determine direction, you need to be moving While standing still the GPS cannot determine what direction you are facing. Let’s say you live on a long private driveway that runs North/South; your home is at the North End and the road you live on is a the South end of your driveway. You drive from your home to the end of the driveway. The GPS will recognize that at one moment you were at the North end of the driveway and a few seconds later you were further South, so it will assume you are moving South and will show you driving in that direction.
"Now suppose you have reached the end of your driveway at the road. Instead of turning around, you put the car into reverse and drive backwards up the driveway. The GPS will think (somewhat incorrectly) that you have turned the car around and are driving forwards back towards the house. With most GPS devices in a “heading up” setting it will not keep the direction you are facing up since it doesn’t know what direction you are facing. It will put North up in this case because that is the direction you are generally moving and it assumes you are facing in the same direction you are moving. In fact, the GPS will show the exact same thing if you drive backwards up the driveway as it would if you turned the car around and drove forwards up the driveway."
Now here's my minor to do list (as opposed to my main to do list below):
1. Find out why the iPhone doesn't have a gyroscope.
2. Find out why the magnetic field varies indoors.
3. Learn better how my MEMS gyroscope works.
4. The gyroscope gives data at rate of 88 Hz, whereas the clock functions much faster at a rate of four megahertz. How does the clock ignore the data in between the readings from the gyroscope?
5. Find out my other options for gyroscopes and microcontrollers that I could use.
And here's my main to do list, most of which I drafted with Roger:
Tuesday of this week: Wire up the gyroscope into the breadboard and play with it (Wiring up the gyro was fun and easy, but I couldn't get past the "No BASIC stamp found" error. I did solve other minor problems, however).
Wednesday of this week: Go to the PSU library to find out what kinds of orientation sensors exist that aren't compasses or gyroscopes, and find out how they work. (I was out on Wednesday, so I did this on Thursday instead).
Thursday: Get all forms done by today. Revise my survey so that it's solely intended for blind people. (Ironically, because all my subjects are blind, I can no longer have my experiment be a blind study!) Decide hardware (Done, done, and somewhat done. I need to use a gyroscope, but I still need to find out the accuracy of the gyro and microcontroller I have so that I can know whether to call gyro manufacturers and find better hardware to use).
Friday: Open the ISEF package and get familiar with the forms. Write the software to find the bearing of my gyroscope, if I indeed use it (Will do.)
Next Week: (Tango this week has been a lot of fun, but I expect I'll get a lot more done now that I'll go out to tango only once next week). Spend more time learning about gyroscopes and microcontrollers at PSU. Complete the todo's on my minor to do list. Maybe order some hardware, and maybe, maybe start building if I have the parts I need. Write the program for my small computer science research project so that I can spend more time focusing on this project. Also, get ahead in English. Structure my paper in the three part format with abstracts and the executive summary. Alter the format I use to cite my sources so that I use the format that articles in the JRRD use.
March 29 - April 11: Build an accurate device (it would be great if I could build more than one, but we'll see how it all goes).
April 12 - May 3: Test blind subject(s) and analyze data.
Wiring on the Breadboard
The error I've been trying to work out.
Working in Roger's Shop (Affirmative) and Learning about My Gyroscope
I'll begin with good news. Roger is up for having me work at his shop! What's more, he says, "I will check with my boss tomorrow at the VA research center. I think if it is ok, and you are interested, it would be a good thing for you to do some work in my lab up there also. You could get an idea of what goes on in our research environment and I could show you another lab I work in."
Very cool.
I'm going over to his house tomorrow to review what I have in mind and brainstorm solutions after I return from Homework Club. Of course, we know Roger's a great guy, and even so, it's important to make sure this is safe. Roger stated it well: For safety, we will plan on having another person around, either my wife or neighbor. Then if we electrocute ourselves, someone will be able to call the doctor or coroner."
The next time he'll be available is on Wednesday in the afternoon and evening if necessary. I'm wondering how this will work with Tango (my winterim, which starts every day at four or five in the evening).
Anyway, here's what I've learned thus far about how my gyroscope works:
I have a solid-state gyroscope that is a piezoelectric single-axis yaw rate sensor.
Yaw is the rotation about a vertical axis. Yaw rate is the speed of this rotation. The faster the turn, the higher the output signal. We can use yaw rate to determine the turn angle (or cardinal direction) by integrating the yaw rate. Of course, the microcontroller doesn't use calculus to integrate. Instead, it samples the yaw signal at a fixed rate and adds up all the readings.
Two main forms of yaw rate sensors exist: the Piezolectric type and the micromechanical type.
The documentation and google searches don't distinguish the sensor I have, but I think it's safe to assume I have the piezolectric type, in which, according to Wikipedia,
"the sensor is a "tuning fork"-shaped structure with four piezo elements (two on top and two below). During straight ahead driving, the upper ones produce no voltage as no Coriolis force acts. But in cornering, the rotational movement causes the upper part of the tuning fork to leave the oscillatory plane creating an alternating current voltagewhich is proportional to the yaw rate and oscillatory speed. The output signal's sign depends on the direction (left or right)."
I'll learn more about this gyroscope tomorrow, so I can understand it better and define it in my own words. All yaw rate sensors experience some degree of drift.
Here's a simple description of the drift of yaw rate sensors, from a company called "Autonobot Control Systems": "Since turn angle is an integration of yaw rate, any small error in yaw rate will accumulate over time to become a significant error in turn angle."
Many sources have acknowledged that a compass can be used to augment the gyroscopic heading. The same article says:
"Compass sensors may be used to monitor absolute angle, but it is difficult to obtain
accurate readings due to many potential influences on the local magnetic field, which can appear to randomly alter the compass reading."
I may not be able to use the compass. If the compass zeros the gyroscope when the compass is influenced by a local magnetic field, the device will be inaccurate. Yet I may need to use the compass, in which case the device will still be more consistent than it is when I use the compass alone.
Depending on the severity of the drift, it would be great if I could let the user zero the gyroscope. If they knew they had the device facing north (perhaps they could rest it against a north-facing wall), they could press a button that would zero the device. This method has the added benefit that the user can wear the device in any orientation about the vertical access that they want, because when they zero the device, the device's original orientation doesn't matter.
This would work well if the blind person only had to zero the device every couple hours. Now, if I need to make up for the compass' drift every thirty seconds, we have a problem, and I may be better off using the compass.
Anyway, I spent a lot of time trying to find an example of how to use a compass to correct gyroscopic drift, to no avail. The libraries I have access to, namely Gale, Galter, JSTOR, and a few other literary databases, turned up zero search results when I typed in "gyroscope," so I had to resort to the less reputable database which is google. I used the "Ask a Librarian" chat, but Ian and I ended up wading through vague background information rather than finding a specific example. I'll talk about this tomorrow with Andrew.
I also ran into some difficulty deciphering the only two LISY300 gyroscope demos I could find, which are written in a language that's not PBASIC. I eventually realized that the downleads contain a .bs2 file that I'd disregarded because my mac can't open it, but that probably has the helpful PBASIC demo that I need. I'll open it on a PC tomorrow.
I'M GOING TO THE INTERNATIONAL SCIENCE FAIR!
I'm thrilled.
Now here's my dream progress for my project.
Fortunately, this fair came at the perfect time. I get all week until 4:00 every day because of winterim, and I don't plan to go on any trips during spring break. This gives me two weeks that I can focus on my project.
TODAY
Write a program that uses the gyroscope to determine orientation, and uses the compass to correct the gyroscope's drift.
Learn how my solid-state gyroscope works and how it compares to older gyroscopes.
Email Roger to see if I can build the four devices in his shop (I'll need somewhere to work over spring break, and it would be great to get his help if I can).
THIS WEEK (winterim, though I'll have all day until 4 or 5, because I get to tango in the evening)
Buy four more rechargeable batteries, three more gyroscopes, and ask for the compasses back.
Wire and solder the gyroscope into new pins on the microcontroller.
Test the device and alter it until the device is accurate 100% of the time.
Build the other three devices
Find three more blind people willing to participate in my experiment. The testing won't take very long, and I can test them anywhere indoors in a large room, because they'll be wearing ear protection, so differences in which room they're in shouldn't significantly affect the results of each testing session. Also, I can make sure I test each subject before and after in the same large room.
SPRING BREAK
(This is fantasy: Add a button on the device that allows the subject to zero the device when the subject knows they have the device pointing north. This way, they can wear the device in any orientation they want (on their belt, in their breast pocket))
Have all subjects sign consent forms.
Begin testing with the blind subjects. During this time I may need to also go to where the blind people live and repair devices if any of them break.
WEEK AFTER SPRING BREAK (tests will be running during this time. We'll have school this week.)
Update my board and research paper.
WEEK AFTER THE STATE SCIENCE FAIR (tests will be running during this time)
Conduct final testing sessions.
Statistically analyze data.
Repeat a round of tests if possible.
Update my board and research paper.
SPARE TIME
Research the ideal device I could build with best current technologies.
Learn how the data passes through all the wires of my device.
Learn more in depth how all of the components in my device work.
How I'll make sure I have enough time for all this:
1. I won't work for anyone (babysitting, petsitting, etc.) until after the state fair.
2. I may have to not go to Homework Club a few times. I'll still go tomorrow because there will be a shortage due to winterim.
3. I won't go to the math symposium at Reed the day after the state fair.
4. I'll ask Andrew if I can put my computer science research project on hold until after the state fair.
5. My iPhone app development has slowed to a crawl this winter, due to lack of time. I'll have to put it on hold entirely until after the fair.
5. I already go running in the mornings before school, so time I spend running won't overlap with time I spend with Veronica or an electrical engineer.
Going to the international science fair will cut into the first week of my senior project. I'll ask Chris Bagg and then Raven Zachary if I can extend my senior project to the week after our senior class trip.
Final Device Troubleshooting (with pictures)
I have thoroughly troubleshooted my device.
I found that during calibration, I needed to be very accurate about revolving the compass twice in two seconds, despite the laid-back tone of the instructions. (I told Paul I needed two revolutions in twenty seconds, and he said, "That's worse than South America!") I constructed an apparatus that involved a paper plate with ten equally spaced tic-marks. The calibration much improved the accuracy, but it still only worked most of the time.
I found that when I held the compass still and brought the 9V battery within two centimeters of the compass, the reading of the compass would change in a range of a hundred degrees, due to the magnetic field the battery created. No other components had such an effect on the compass, so I solved that problem by velcroing the battery to the outside of the box, on the end opposite the compass. Then, it worked nearly all the time, within a range of about twenty degrees which were necessary to reduce the number of times the device passed north without vibrating. I found that the accuracy of the device depended on which area of the building I was in, and it skipped north more when I was outside the science building.
I went down to have George test it out, and he said, "Great! It works!" So I conducted the initial round of tests with him. Later that day, however, he said it wasn't going to work. In order for George to feel comfortable using it, it needs to work all the time. I found out that the variations in magnetic field inside George's office causes the device to vibrate when it shouldn't.
So now I'm researching using a gyroscope. Parallax, the company from which I've gotten the compass modules and microcontrollers, sells a $35 gyroscope that I could easily solder into my apparatus. I'm also researching the ideal device I could make with the best current technologies.
I presented my work to my science research class and computer science research class. Here's the work left to do before the fair next Saturday:
1. Finish paper (Roger offered to look over it) and abstract
2. Write materials for display board
3. Make diagram of device in InDesign
4. Draw pictoral of device
5. Assemble board
6. Continue researching gyroscopes and the ideal device
Calibrating the Device
Using the Mill
The Device! In the top right is the compass module, middle left is the microntroller, bottom left is the vibrator, and very bottom is the battery.
Soldering
Soldering
Testing George
Testing George
Writing the Program
Testing Connections
Calibrating the Device
The Device Works!
I'll recap on my progress this past week:
First, I soldered all the devices in the science lab, one night (Veronica was VERY generous with her time—she stayed with me until 8:30 and then biked all the way home to the East side!).
Then, however, I found that none of the devices worked. I tried testing my devices with a voltmeter, but I thought my problem was the compass (which it was), so I thought there was nothing I could do. The failure of all devices was pretty discouraging. I started brainstorming for a project I could carry out in forty days.
Next, however, Dale got me in touch with an (incredibly helpful and compassionate!) electronic engineer named Roger. I showed him my devices, we analyzed all the spec sheets and my diagrams, and we drew a new pictorial. We decided the wiring was all correct, the transistors should be working, and I could use a resistor of much less resistance. Then, he took home one of the devices, cleaned up the soldering connections, put on the proper resistors, and created a four-pin and socket connection wired to specific pins of the microcontroller so that I could hook the device up to a serial-to-USB cable to my computer without having to wire everything up on the breadboard. He even brought full-size magnified color pictures of the device, and a lot of tools I could use to more effectively clean up and solder the other three devices.
Yet he found that the device still didn't work, so we looked at the software. It turns out that my software was correct, but the calibration routine needs to be precise. After we recalibrated the compass a couple times, the device worked.
So the next day I came to calibrate the other compasses, and I found that none of them work. Yet I still have one compass in a package that I can use as my backup. So George will be my one and only subject.
I tested the working device some more, and found that it only worked most of the time. In my program, I included a space of five degrees between the 'in range' and 'out of range' zones, which helped, especially with the double-buzzes. Now it works eighty to ninety percent of the time. When I'm testing, I can see in my program what value the compass reads at any moment, and the error is due to inaccuracy of the compass. For this reason, having the device work most of the time is the best I can do.
Last night, I planned out how I would fit all the components in the box, and Roger even stopped by in the morning to give me materials I could use, including foam, fuse holder clips (perfect for the vibrator), foam, and a catalog for possible belt clips. I sanded down some excess protoboard beneath the microcontroller so that it would fit in the box. I also accidentally sanded off one of the vibrator's wires, and I couldn't get into the science lab, so I soldered that back on this morning. I'll affix some of the components in the box today during seventh. Then, after school I'll stop by the robotics lab to drill a hole in the side of the box into which I'll screw the fuse holder.
I am incredibly lucky that Roger been such a great help!!
Programmed all Devices
Success! I got done everything I wanted to. I set up my breadboard (no small task), didn't blow anything up in the process, modified my program, and uploaded the program onto all four devices. It took me from 3:00 to 8:00. Here's why. Setting up the breadboard was relatively easy because I've already done it, although there are many wires going to pins, a transistor, four resistors, a compass, a microcontroller, a battery, a vibrator, and five wires for the serial cable. Then, I booted up the ancient laptop. After that, I found that the compass calibration code was missing, so I downloaded that again (the process took quite a while on the ten-year-old computer). Next, I put in code to have the calibrate the compass after every 1000 vibrations. But then I realized that ideally, when you calibrate the compass, you set it on a flat surface and revolve it twice over a twenty second period. Of course, the user won't know when the compass isn't calibrating, so this wouldn't work. When I used a new compass without calibrating it, it worked, so I'm just going to not calibrate the compasses at all. What's important is consistency, not whether the compass is pointing exactly at north or not. Then I realized that my largest variables can hold a maximum of sixteen bits. This means that the variable can hold a maximum number of two to the sixteenth minus one, which is 65535. The number of vibrations is bound to go over, at which point the variable will just reset to zero. So I wrote another variable in memory to iterate when the number of vibrations hits 65000.
And then someone accidently ripped out the power cord to the laptop. I lost all my work and had to start all over. I had to boot up, download the compass file again, and write and test all the code. Then, I decided to have the vibrator vibrate for a quarter of a second. All throughout this process, I tested frequently. Then, I uploaded the program onto the other three devices. It was a good time. Rohan brought his speakers, music was good, and I was happy to see everything work.
Tomorrow, I'm going to test my soldered device as planned. Wish me luck.
Recap on Progress Thus Far
I'll quickly recap my work thus far in science research. Skip to the bottom two paragraphs if you're in a rush. I started the year thinking I'd be testing the efficacy of a navigational aid that is an iPhone that vibrates when it points north. In order to be sure that was the project I wanted to devote myself to, I looked around and came up with other ideas for two weeks, and then decided to go forward with my original idea. Then, I looked for human subjects. This process took a long time, because few people have iPhone 3GS's, and even fewer want to be research subjects. I filled out the forms early, and that felt good. I thought making the iPhone app would be easy, and it was, so I made the app late (within two or three weeks of my first testing sessions). I wish I had begun sooner, because what wasn't easy was testing the app. Because I don't have an iPhone 3GS, I had to test it through Dan's phone, which meant whenever I made a change, I would have to day before Dan could upload the app from his home computer. For about a week, the app was working, but it appeared that it wasn't because the iPhone's compass has a three-quarter second lag. During this week, I tested all my subjects on a Friday. I found the testing stressful at first, but I got the hang of it as I tested more subjects. So I tested subjects for a total of five hours that day, in addition to giving a presentation and going to assembly, and then I spent five hours collecting data after school. I then went to James' house to test the app some more, and that's when I realized I'd need to build a device. I had posted a question to a Portland iPhone Developers forum, and a couple guys gave me some really good advice about using a Parallax stamp 2 micro-controller. I ordered parts ($200 of which Parallax donated) and in the meantime, I finished my research paper, which turned out to be eighteen pages long single-spaced. I conducted thorough research, and I now feel knowledgeable about cognitive processes behind human and animal navigation. I also familiarized myself with the language, PBASIC, and I wrote my program. As soon as the stamp 2's and compasses arrived, I headed to the robotics lab and tested my program. After a day, I got it to light up an LED when the compass pointed north. The second day I was hooking up wires, I blew a compass. That set me back $40. The new one arrived today, though. Anyway, learning how to wire up a device and use a bread board was fun. Really fun. And, of course, I learned a lot from it. I dreaded having to order a bunch of hardware, but it turned out a quirky electronics store had almost everything I needed. Now, I'm soldering my proto boards, using the band saw, and using the mill as I assemble my devices. Tomorrow I'll be in the robotics lab from ten to seven or eight. I hope to finish soldering and wiring up all my devices tomorrow, as well as calibrating all the compasses. There's a lot that could go wrong, though, but I'll try to test everything before I plug in some of my expensive equipment. As soon as I have the devices made, I schedule four experimental subjects for initial tests. Because I cut two tests, each testing session should take half an hour rather than forty minutes, will will make it less stressful. I've also improved my data collection methods, so it will take far less time to collect all the data.
Yet I've been uncharacteristically putting off testing George. I've realized that I haven't yet tested him because I'm concerned that I haven't yet gone over with you my which tests I'm cutting and my new data collection methods. Can we do that asap? Also, can we block out a large chunk of time outside of class to go over the rest of my research paper?
Anyway, overall I'm pleased with my progress and my adherence to my personal deadlines, with the exception of writing the iPhone app and testing George. I'm happy with my first draft of my research paper, and I feel I now have a strong command of how our brains enable us to navigate. When I began this project, I didn't imagine I'd be working with hardware and learning to wire up a device, but here I am, and I'm learning all the more because of my complete lack of inexperience. My only two worries are first, that tomorrow I'll break expensive equipment that will take a week to replace, and second, that one of my subjects will break his or her device. Shortening the testing time to two weeks helps with both of these worries.