QTI Line Follower - Intersections
Hui
Posts: 4
Hey Parallax Community,
How are you? I'm a student at Duke University currently working on an electrical engineering design project. We are using BOE-bots to navigate along a path of electrical tape to certain "rooms". I have the basic movements of the QTI line follower going perfectly, but everyone is having trouble with the intersections. I've tried hard-coding the intersections, but this is often unreliable as varying batteries provide varying outputs for say, a FOR loop.
I was thinking that at an intersection you could have the bot rotate until the sensor no longer detects %111, at which point it would resume the SELECT process. However, since we're using counters to denote which intersection the bot is at, this often causes problems since the bot might go from %111 to %110 immediately back to %111, all at the same intersection (and thus messing up the intersection count).
Any ideas? I know this is really confusing, I can post that segment of my code if needed.
Thanks.
- Hui
How are you? I'm a student at Duke University currently working on an electrical engineering design project. We are using BOE-bots to navigate along a path of electrical tape to certain "rooms". I have the basic movements of the QTI line follower going perfectly, but everyone is having trouble with the intersections. I've tried hard-coding the intersections, but this is often unreliable as varying batteries provide varying outputs for say, a FOR loop.
I was thinking that at an intersection you could have the bot rotate until the sensor no longer detects %111, at which point it would resume the SELECT process. However, since we're using counters to denote which intersection the bot is at, this often causes problems since the bot might go from %111 to %110 immediately back to %111, all at the same intersection (and thus messing up the intersection count).
Any ideas? I know this is really confusing, I can post that segment of my code if needed.
Thanks.
- Hui
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
·
Make your intersections with a "White spot" or hole in the middle and check for a "101" ... at this point ignore the left and right sensors and only look at the center sensor.· When the center sensor becomes a "1", then resume normal left and right sensing.
With·a "solid" or filled intersection, if the BOE-bot comes in at an angle it will·"see" a "110" or "011" ... with the hole in the middle if the BOE-bot comes in at an angle it will "see" a "100" "001" and try to compensate for the error under the normal reading algorithm.· The "next" sample would be "101" which could be looked at in the algorithm as an ignore, but keep the current heading.
·
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 3/22/2009 6:08:03 AM GMT
Thanks for the suggestions. Beau, I would do that but we're not allowed to change the course [noparse]:([/noparse]. I think we have most of the code figured out now, but here's a copy, in case there's a much more efficient way of doing one of the functions:
' {$STAMP BS2sx}
' {$PBASIC 2.5}
qti VAR Nib
counter VAR Byte
hashCount VAR Byte
timeCount VAR Byte
counter = 0
hashCount = 0
timeCount = 0
DO
GOSUB checkSensors
SELECT qti
CASE %000 ' Not on a track - Forward
GOSUB forward
CASE %101 ' Stuck - Forward
GOSUB forward
CASE %010 ' Forward
GOSUB forward
IF hashCount = 3 THEN ' Goes forward into the room, then backs out of the room
counter = counter + 1
IF counter = 10 THEN
FOR timeCount = 0 TO 5
GOSUB rightangleRight
NEXT
ENDIF
ENDIF
CASE %011 ' Pivot right
GOSUB rightPivot
CASE %001 ' Rotate right
GOSUB rightRotate
CASE %110 ' Pivot Left
GOSUB leftPivot
CASE %100 ' Rotate Left
GOSUB leftRotate
CASE %111 ' Intersection
GOSUB intersection
ENDSELECT
PAUSE 20
LOOP
'Various subroutines
checkSensors:
Right: HIGH 5: PAUSE 1: qti.BIT0 = IN3: INPUT 5
Center: HIGH 6: PAUSE 1: qti.BIT1 = IN3: INPUT 6
Left: HIGH 7: PAUSE 1: qti.BIT2 = IN3: INPUT 7
RETURN
forward:
PULSOUT 13, 2125
PULSOUT 12, 1625
PAUSE 100
RETURN
rightPivot:
PULSOUT 13, 2125
PULSOUT 12, 1875
PAUSE 100
RETURN
rightRotate:
PULSOUT 13, 2125
PULSOUT 12, 2125
PAUSE 100
RETURN
leftPivot:
PULSOUT 13, 1875
PULSOUT 12, 1625
PAUSE 100
RETURN
leftRotate:
PULSOUT 13, 1625
PULSOUT 12, 1625
PAUSE 100
RETURN
intersection:
IF hashCount = 0 THEN 'Intersection at the front of parking space
GOSUB rightangleRight
ELSEIF hashCount = 1 THEN 'Intersection of the middle of parking lot
GOSUB rightangleLeft
ELSEIF hashCount = 2 THEN 'Intersection of path with room
GOSUB rightangleLeft
ELSEIF hashCount = 3 THEN 'Rotates 180
GOSUB rightangleRight
ELSEIF hashCount = 4 THEN 'Turn left out of the room
GOSUB rightangleLeft
ELSEIF hashCount = 5 THEN 'Path 1, 2, 3
GOSUB rightangleRight
ELSEIF hashcount = 6 THEN 'Path 1, 2, 3 exit - must be same as hashCount = 5
GOSUB rightangleRight
ELSEIF hashCount = 7 THEN 'Parking space
GOSUB rightangleLeft
FOR timeCount = 0 TO 5
GOSUB forward
NEXT
GOSUB rightangleRight
FOR timeCount = 0 TO 5
GOSUB forward
NEXT
ENDIF
hashCount = hashCount + 1
RETURN
rightangleRight:
FOR timeCount = 0 TO 3
GOSUB forward
NEXT
DO
GOSUB rightRotate
GOSUB checkSensors
LOOP UNTIL (qti.BIT0 = 0) AND (qti.BIT1 = 1) AND (qti.BIT2 = 0)
RETURN
rightangleLeft:
FOR timeCount = 0 TO 3
GOSUB forward
NEXT
DO
GOSUB leftRotate
GOSUB checkSensors
LOOP UNTIL (qti.BIT0 = 0) AND (qti.BIT1 = 1) AND (qti.BIT2 = 0)
RETURN
Another idea... If you spread out your Left and Right sensors out a little bit (trial and error) by pivoting them on their connecting screw, then "normal" line reading should only be %000, %100, %010, and %001. If an intersection is detected, then the returned value could be %110, %111, or %011 in which case you would ignore the adjustment for steering correction and make note you are in an intersection.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 3/22/2009 9:35:42 PM GMT