Analysis of Boe-Bot Infrared Navigation - Request to Parallax Fora for comments
John Kauffman
Posts: 653
Request to Parallax Fora for comments on Analysis of Boe-Bot Infrared Navigation
·
Reference:
Robotics with Boe-Bot Student Guide version 2.2, ISBN 1-928982-03-4, Chapter 7
·
Question:
How can the IR sensor be seeing IR a full program step after the pulse is sent (250 microseconds) if the light has passed by the sensor within 50 nanoseconds after the pulse was sent?
·
Assumptions:
The IR travels at the speed of light (~30cm/nanosecond).
If the Boe-Bot is 30 cm from a wall the pulse would go out, hit the wall and bounce back past the Boe-Bot sensor in about one nanosecond.
The BS2 specs state 4,000 instructions/sec = 250 microseconds per instruction. But in case of FreqOut the next instruction may execute in less then 100 microseconds from when the last pulse is sent
The Pertinent part of the Boe-Bot code reads:
FREQOUT 8, 1, 38500
irDetectLeft = IN9
(n.b.: The IR sensor is LOW while it detects IR).
·
Empirical Observation:
If the STAMP command for detection is not immediately following the FREQOUT line then the detection will fail to see the sensor = LOW (sensing IR = TRUE). Even one intervening STAMP command will cause a failure.
·
Experiment:
Kris Magri noted that there may be some lag in the time it takes for the sensor to stop reporting that it is seeing IR. I followed up on this with some OScope work.
·
Hardware:
··········· Homework board (BS2 STAMP)
IR emitter is connected to Pin0.
IR detector is powered but not connected to code (just to the OScope)
OScope:
··········· Channel one (blue) is showing signals to IR Emitter
··········· Channel two (red) shows output of IR sensor
Code:
··········· DO
······················· FREQOUT 0,1,37500············ ‘should have been 38500
······················· PAUSE 5································ ‘ provide visual space on OScope
··········· LOOP
Results:
See attached BMP file of OScope trace
·
Analysis of OScope:
Looking at the OScope traces, the blue represents the emitter. I did not add a cap to smooth the signal because I wanted to get cleaner resolution of the moment when the last spike of IR was emitted. We see the multiple peaks of STAMP’s PWM–approximated sine wave that end at the center point of the OScope screen.
The red line represents the output of the sensor and is low (showing the sensor sees IR) on the left, while the emitter is active.
The interesting point is that after the emitter stops there is a lag after the last blue IR spike and before the moment when the sensor goes back to high (no IR detected). That lag is about one unit wide, which translates to 100 microseconds (see OScope horizontal setting on right side of screen shot).
·
Analysis of STAMP Program Timing:
The lag (decay) of the sensor explains the many-order-of-magnitude difference between when the IR light passes the sensor and when the sensor is checked by STAMP.
But there still seems to be a gap between the lag time indicated on the OScope (100 microseconds) and the time I understand it takes to execute a STAMP command (250 microseconds)
Question: Am I wrong about the BS2 STAMP execution speed = 250 microseconds?
Question: When in time does the STAMP actually finish executing the FREQOUT command relative to the last spike in the OScope? Is it possible the STAMP is moving on to the next line of code before the last of the IR emissions show up on the OScope?
Question: Is it possible the STAMP actually detects and stores the state in less then 250 microseconds and the remainder of the 250 microseconds is used to fetch the next command or some other housekeeping? That would make the effective time to execute a sensing command much smaller.
Question: At what point in time is the IN bit for the sensing pin actually changed? Is it at the time that the bit is polled by a command, or does somehow the STAMP change that bit in the background?
·
Conclusions To Date:
The IR pulse bounces back and goes past the detector far faster then the STAMP can move to its next command and detect the light. However, the sensor remains low for about 100 microseconds after the last spike of the IR pulse has been emitted & passed the sensor. That solves the issue of detecting light that has long since traveled off into space.
·
The question remains how STAMP picks up the sensor state in a length of time (determined by OScope trace) that appears to be half of the time expected to execute a command.
·
Observations for Teachers:
This looks like an excellent type of analysis to challenge students to bring together knowledge of STAMP architecture, sensor specs, physics, math, and the use of an oscilloscope. Personally, I could not afford to get this far if not for the $150 Parallax OScope.
·
Reference:
Robotics with Boe-Bot Student Guide version 2.2, ISBN 1-928982-03-4, Chapter 7
·
Question:
How can the IR sensor be seeing IR a full program step after the pulse is sent (250 microseconds) if the light has passed by the sensor within 50 nanoseconds after the pulse was sent?
·
Assumptions:
The IR travels at the speed of light (~30cm/nanosecond).
If the Boe-Bot is 30 cm from a wall the pulse would go out, hit the wall and bounce back past the Boe-Bot sensor in about one nanosecond.
The BS2 specs state 4,000 instructions/sec = 250 microseconds per instruction. But in case of FreqOut the next instruction may execute in less then 100 microseconds from when the last pulse is sent
The Pertinent part of the Boe-Bot code reads:
FREQOUT 8, 1, 38500
irDetectLeft = IN9
(n.b.: The IR sensor is LOW while it detects IR).
·
Empirical Observation:
If the STAMP command for detection is not immediately following the FREQOUT line then the detection will fail to see the sensor = LOW (sensing IR = TRUE). Even one intervening STAMP command will cause a failure.
·
Experiment:
Kris Magri noted that there may be some lag in the time it takes for the sensor to stop reporting that it is seeing IR. I followed up on this with some OScope work.
·
Hardware:
··········· Homework board (BS2 STAMP)
IR emitter is connected to Pin0.
IR detector is powered but not connected to code (just to the OScope)
OScope:
··········· Channel one (blue) is showing signals to IR Emitter
··········· Channel two (red) shows output of IR sensor
Code:
··········· DO
······················· FREQOUT 0,1,37500············ ‘should have been 38500
······················· PAUSE 5································ ‘ provide visual space on OScope
··········· LOOP
Results:
See attached BMP file of OScope trace
·
Analysis of OScope:
Looking at the OScope traces, the blue represents the emitter. I did not add a cap to smooth the signal because I wanted to get cleaner resolution of the moment when the last spike of IR was emitted. We see the multiple peaks of STAMP’s PWM–approximated sine wave that end at the center point of the OScope screen.
The red line represents the output of the sensor and is low (showing the sensor sees IR) on the left, while the emitter is active.
The interesting point is that after the emitter stops there is a lag after the last blue IR spike and before the moment when the sensor goes back to high (no IR detected). That lag is about one unit wide, which translates to 100 microseconds (see OScope horizontal setting on right side of screen shot).
·
Analysis of STAMP Program Timing:
The lag (decay) of the sensor explains the many-order-of-magnitude difference between when the IR light passes the sensor and when the sensor is checked by STAMP.
But there still seems to be a gap between the lag time indicated on the OScope (100 microseconds) and the time I understand it takes to execute a STAMP command (250 microseconds)
Question: Am I wrong about the BS2 STAMP execution speed = 250 microseconds?
Question: When in time does the STAMP actually finish executing the FREQOUT command relative to the last spike in the OScope? Is it possible the STAMP is moving on to the next line of code before the last of the IR emissions show up on the OScope?
Question: Is it possible the STAMP actually detects and stores the state in less then 250 microseconds and the remainder of the 250 microseconds is used to fetch the next command or some other housekeeping? That would make the effective time to execute a sensing command much smaller.
Question: At what point in time is the IN bit for the sensing pin actually changed? Is it at the time that the bit is polled by a command, or does somehow the STAMP change that bit in the background?
·
Conclusions To Date:
The IR pulse bounces back and goes past the detector far faster then the STAMP can move to its next command and detect the light. However, the sensor remains low for about 100 microseconds after the last spike of the IR pulse has been emitted & passed the sensor. That solves the issue of detecting light that has long since traveled off into space.
·
The question remains how STAMP picks up the sensor state in a length of time (determined by OScope trace) that appears to be half of the time expected to execute a command.
·
Observations for Teachers:
This looks like an excellent type of analysis to challenge students to bring together knowledge of STAMP architecture, sensor specs, physics, math, and the use of an oscilloscope. Personally, I could not afford to get this far if not for the $150 Parallax OScope.
Comments
Yes, it's an interesting exercise.· The Parallax USB Oscilloscope you used to take the measurements is full of educational opportunities beyond what's currently in the Understanding Signals Tutorial.
Regarding the time it takes the IR receiver's output to return to 5 V, the noise in the FEQOUT signal is what causes the delay.· This so-called noise is the pulse width modulation the BASIC Stamp uses to digitally synthesize a sine wave.··The fact that the noise in the FREQOUT command slows down the receiver works to the BASIC Stamps advantage for IR object detection on the Boe-Bot.· If you use an SX-chip an send a 50% duty cycle square wave, the receiver's output returns to 5 V in a fraction of the time.
Different PBASIC commands·take different amounts of time.· It depends mostly on how many tokens the Interpreter chip has to serially fetch from the EEPROM.· The BASIC Stamp's interpreter chip updates·the INS register, which stores all the I/O pins' input states,·between each command.· Consider this program (TestLeftBoeBotIrDetector.bs2).· Based on the rule about updating the INS register between each command, we know that the INS register will be updated some time between the end of the FREQOUT command and the start of the token fetching for the next command.
[color=#008000]' TestLeftBoeBotIrDetector.bs2 ' Filename[/color] [color=#008000]' {$STAMP BS2} ' Target module = BASIC Stamp 2[/color] [color=#008000]' {$PBASIC 2.5} ' Language = PBASIC 2.5[/color] [color=#000000]IrSenseLeft PIN 9 [/color][color=green]' IR receiver connected to P9[/color] [color=#000000]IrLedLeft PIN 8 [/color][color=green]' IR LED connected to P8[/color] [color=#000000]irRecSig VAR Bit [/color][color=green]' Bit stores IrSenseLeft state[/color] [color=blue]DO[/color] [color=green]' DO...LOOP repeats indefinitely[/color] [color=blue]FREQOUT[/color][color=#000000] IrLedLeft, 1, 37500 [/color][color=green]' Signal to IR LED[/color] [color=#000000] irRecSig = IrSenseLeft [/color][color=green]' Store IR receiver output[/color] [color=blue]HIGH[/color][color=#000000] IrLedLeft [/color][color=green]' Views nicely on O-scope[/color] [color=blue]PAUSE[/color][color=#000000] 100 [/color][color=green]' Delay for older PCs[/color] [color=blue]DEBUG[/color] [color=purple]HOME[/color][color=#000000], [/color][color=navy]BIN1[/color][color=#000000] irRecSig [/color][color=green]' Object? 0 -> yes, 1 -> no[/color] [color=blue]LOOP[/color] [color=green]' Repeat DO...[/color][color=green]LOOP[/color]Now, take a look at this Parallax USB Oscilloscope screen capture.· The blue·CH1 trace on top is the end of the FREQOUT·signal.· The red CH2 trace on the bottom is the clock signal the BASIC Stamp's Interpreter chip sends to the EEPROM to fetch the program tokens.· I got this signal by hooking a wire in the Parallax USB Oscilloscope probe, and then touching it to pin 6 of the 24LC16B chip on the BASIC Stamp 2.· Notice that there's a 36 us window between the end of the FREQOUT command and the·time the Interpreter starts fetching the tokens for irRecSig = IrSenseLeft statement.· It is during this time that the Interpreter chip updates the INS register.
······
Regards, Andy
Post Edited (Andy Lindsay (Parallax)) : 7/25/2005 7:41:11 PM GMT