Line following and Proximity sensing issue!!!

Nam · 2005-03-17 14:35

·I am having issues with my programming!
Project description:
·
I am designing and building a line following mail cart.· The mail cart is designed to follow a black line around an office environment and stop at pre marked areas for mail delivery.· At each stop an audible bell is sounded letting the secretary know to come get the mail from the cart.· At this point two things will happen. (1) If no one comes to get their mail after 30 seconds the cart will continue on.· (2) If someone gets the mail they can hit a stop button (to deactivate the timer and bell) and retrieve their mail at a leisurely pace.· Then they can hit the button again to reactivate the cart sending the cart on its way!

f people or objects are in the path of the cart it will stop and wait until the object is cleared.
·
Hardware used:
·
Line following sensors : 4 QTI - 3 QTI used for line following - 4th qti is used for stop detection and crossing detection ( such as figure 8 pattern)
·
Proximity sensing - IR LED and Detector - used for object sensing
·
Bell - Piezerro
·
Push button
·
Boe-Bot - BS2 software
·
Problem description:
·
Now! With that said, I would like to discuss the problems that I have encountered.· The major problem is·the programming.· How can I possibly run the proximity sensing program·and the line following program simultaneously or near that.· I have tried to run the programs together but that does not run properly.· Does anyone have any ideas on how to organize my program in such a way it will execute all ·of the tasks I have listed in a systematic and simultaneously.·
·
Thanks
Nam Phan

KenM · 2005-03-17 15:14

A start would be to post your program

Nam · 2005-03-17 15:31

' {$STAMP BS2}
' {$PBASIC 2.5}

qti VAR Nib
Do

VeryRight: HIGH 8: PAUSE 1: qti.BIT3 = IN3: INPUT 8
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

SELECT qti

CASE %0010 ' Forward
PULSOUT 13, 850
PULSOUT 12, 650

CASE %1010 ' Forward
PULSOUT 13, 850
PULSOUT 12, 650

' Pivot Right
CASE %1011
PULSOUT 13, 850
PULSOUT 12, 750

CASE %0011
PULSOUT 13, 850
PULSOUT 12, 750

' Rotate right
CASE %1001
PULSOUT 13, 850
PULSOUT 12, 850

CASE %0001
PULSOUT 13, 850
PULSOUT 12, 850

' Pivot Left
CASE %1110
PULSOUT 13, 750
PULSOUT 12, 650

CASE %0110
PULSOUT 13, 750
PULSOUT 12, 650

'Rotate Left
CASE %1100
PULSOUT 13, 650
PULSOUT 12, 650

CASE %0100
PULSOUT 13, 650
PULSOUT 12, 650

'Cross Detection Continue foward
CASE %1111
PULSOUT 13, 850
PULSOUT 12, 650

ENDSELECT
PAUSE 40
loop

Jon Williams · 2005-03-17 16:17

What frequently happens -- especially with new programmers -- is that style (or lack thereof) gets in the way or delays success.· I'm a maniac for good style and for very good reason: good style helps the programmer create and update programs more easily.· The first thing to do is clean-up the style of your program; I've saved you the trouble as you'll see in the attachment.

The program behaves the same as yours, but is cleaned up a bit.· Notice that I've also added a place-holder for the proximity sensor code so that you can drop it in.· With servo-based robots you generally want to check the sensors, then do the movement.· In this case, the proximity sensor gets checked and if nothing is in the way, the line array is read and the movement is updated.· Since reading the proxity sensor and line arrays add a little delay, I shorted the standard loop delay from 40 to 20 milliseconds.· Servos are usually updated every 20 milliseconds, so this value will help them run a bit more smoothly.

I've also attached our stlye guide called "The Elements of PBASIC Style" -- this explains the format we prefer to use when writing PBASIC programs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

Bruce Bates · 2005-03-17 16:52

Jon -

I certainly take NO EXCEPTION to what you said below:

"What frequently happens -- especially with new programmers -- is that style (or lack thereof) gets in the way or delays success. I'm a maniac for good style and for very good reason: good style helps the programmer create and update programs more easily. The first thing to do is clean-up the style of your program; I've saved you the trouble as you'll see in the attachment."

but since I probably feel even more strongly about this than you do (and have been a programer for over 35 years) it also teaches you how to BE a GOOD PROGRAMMER and not just a code generator. Anyone can read a manual and generate syntactically correct code. Heck, programs have been written to write programs! That's NOT to say the program will ever work as intended. Good programming is both an a ART, and a SCIENCE. Both are necessary, and without one, you can't have the other. Good habits are easily learned, but bad habit DIE HARD.

Just one minor addition to your thoughts on style. It costs absolutely nothing to document every line of code in a program. Good documentation is a part of good style IMHO. Doing so will pay great rewards when you come back to that same program next week or 6 months hence, needing to make a simple change to something you wrote which was rather clever when it was first coded. Descriptive documentation is the key here, and not just saying "output pulse on pin 10". That says nothing that the programming manual doesn't say. Rather "pulse the enable gate on the external latch" says something descriptive and something which is important to the operation of the program and/or the system.
[noparse][[/noparse]soapbox mode off]

Regards,

Bruce Bates

Jon Williams · 2005-03-17 17:01

I agree, Bruce; what I didn't say is that good style frequently causes major portions of a program to become "self-documenting." Where that is not the case then yes, comments take little time to put in place and can save a programmer hours of frustration later.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

Nam · 2005-03-22 02:14

Awesome Guys!

I will try this and let you know asap!

Nam · 2005-03-22 04:36

Ok so I have updated some of the code and adjusted it to my needs.·
Update since last posted problem:· Mr. Jon Williams has kindly helped me by reorganizing the structure of the program and adding blanks for me to fill in some code. The problem: The robot does not function properly.
Problem 1:
I added some debug statements in the program to help me view what was currently running.· When an object is placed in front of the IR the Print out is “ IR is active”.· As soon as the object is cleared the program continues with the line following subroutine.· BUT! The program prints out the statement at the CAS ELSE· - Bad command and does not perform the other cases.· WHY???? This is bothering me.· PLEASE HELP!!
Problem 2:
I am trying to Print the Bit value of the sensor.· AS I understand it the CASE ELSE statement is used when none of the cases fit the sensor output.· Is there a way to view what sensors are outputting 1’s and 0’s during the CASE ELSE statement?
·
Thanks~!

<-- me as of right now
nam phan

Nam · 2005-03-22 04:37

' =========================================================================
'
' File....... Mailbot.BS2
' Purpose....
' Author.....
' E-mail.....
' Started....
' Updated....
'
' {$STAMP BS2}
' {$PBASIC 2.5}
'
' =========================================================================

'

[noparse][[/noparse] Program Description ]

'

[noparse][[/noparse] Revision History ]

'

[noparse][[/noparse] I/O Definitions ]

ServoL PIN 13 ' left servo
ServoR PIN 12 ' right servo
Sensor PIN 3 ' input from QTI sensors

'

[noparse][[/noparse] Constants ]

Active CON 1
NotActive CON 0

'

[noparse][[/noparse] Variables ]

prox VAR Bit ' proximity flag
idx VAR Nib ' loop control
qti VAR Nib ' sensor array status
irDetect VAR Bit ' IR Prox (new)

'

[noparse][[/noparse] EEPROM Data ]

'

[noparse][[/noparse] Initialization ]

Reset:
LOW ServoL ' initialize servo pins
LOW ServoR

'

[noparse][[/noparse] Program Code ]

Main:
DO
GOSUB Check_Prox ' check proximity
IF (prox = Active) THEN
PULSOUT ServoL, 0
PULSOUT ServoR, 0
DEBUG " IR is active ", CR

' deal with proximity sensor

ELSE

GOSUB Scan_QTIs: ' scan line array

' move bot

SELECT qti
CASE %0010, %1010 ' Forward
PULSOUT ServoL, 850
PULSOUT ServoR, 650

CASE %1011, %0011 ' Pivot right
PULSOUT ServoL, 850
PULSOUT ServoR, 750

CASE %1001, %0001 ' Rotate right
PULSOUT ServoL, 850
PULSOUT ServoR, 850

CASE %1110, %0110 ' Pivot Left
PULSOUT ServoL, 750
PULSOUT ServoR, 650

CASE %1100, %0100 ' Rotate Left
PULSOUT ServoL, 650
PULSOUT ServoR, 650

CASE %1111 ' Cross Detection
PULSOUT ServoL, 850 ' -- Continue foward
PULSOUT ServoR, 650

CASE %0111 ' Stop when black tape covers 3 sensors
PULSOUT ServoL, 0 ' Bell sound alerts person to pick up mail
PULSOUT ServoR, 0
FREQOUT 15, 1000, 4000 ' from cart

CASE ELSE
DEBUG " Bad Command ", CR

ENDSELECT

PAUSE 20
ENDIF
LOOP

'

[noparse][[/noparse] Subroutines ]

Check_Prox: ' code to check proximity sensor

FREQOUT 0, 1, 38500
irDetect = IN9

IF (irDetect = 1) THEN
prox = NotActive
ELSEIF (irDetect= 0) THEN
prox = Active

ENDIF
RETURN

' Activates and reads QTI sensors on pins 5 - 8

Scan_QTIs:
FOR idx = 0 TO 3 ' loop through 4 bits
HIGH (5 + idx) ' activate sensor
PAUSE 1
qti.LOWBIT(idx) = Sensor ' record sensor output
NEXT
RETURN

Line following and Proximity sensing issue!!!

Comments