Algorithm for counting number of lines travelled over

I'm having a problem that I hope someone can see the logic I have possibly overlooked.
The robot is to pass through, say, 5 white lines on a black surface
and then come to a rest. I am trying to work out the general logic to the algorithm rather than the proper syntax of the programming language.
I have written the program like so:
initialize variable lines_to_count = 5 initialize variable on_white_line = false
turn motors on and stay on until otherwise turned off
while (lines_to_count > 0)
if (sensor detected white surface) then on_white_line = true
if (on_white_line = true) and (sensor detected black surface) then lines_to_count = lines_to_count -1 on_white_line = false
loop while
turn motors off
All that does, however, if make the motors turn on momentarily and then immediately stop. It's as if the while loop is never entered or is executed so quickly followed by the turn motor off that it seems not to have run at all.
Can anyone see a problem with the logic? I'm stumped....can't explain why the robot just stops immediately upon being activated.
I would think the above program would make the robot move forward, stay in the WHILE loop as it keeps moving forward keepiing track of the number of lines it passeed by and, when the fifth line is passed, the robot stops.
Notice the two IF statements in the WHILE loop are mutually exclusive because one is looking for a white surface, the other a black surface. Line counting is determined by finding a white surface (the first IF) followed some time later by detecting a transition to a black surface (the second IF). The second IF toggles on_white_line variable back to false so that it can be resued for the next white line the robot encounters. You can assume the sensors are working perfectly.
Thanks.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hmm...I have rechecked the code...seems the problem was a bit of syntax afterall. Sorry for the bother.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

You have a classic and simple FSM here, and the logic seems ok. So the problem may likely be in the sintax of your program or getting the signal out of the sensor. Remember that real world sensors are noisy, and if you have not calibrated it correctly or taking the proper cautions to interpret it, you may have problems. From the symptoms you describe, seems like the program is actually working, but the sensors are giving spikes that are crossing your "sensor detected white surface" threshold.
Have fun debugging ;-)
Cheers
Padu
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote in message

Padu, my first reaction was also that the algorythm posted was a FSM. Since is was so "obviously state based" it caught my attention. The psuedo code looked very much like what I've written about IsoStructure in IsoMax(TM) FSM language documentation, as alternative ways with regular languages to write state machines. So I decided to diagram it, and code it in IsoMax(TM) as an exercise.
It was less of a maching than I'd thought, is a very subtle sort of state machine, if that. I would have to say, it really doesn't qualify as a whole machine, but only a single state with an exit transition.
While the state information is held in on_white_line and lines_to_count, there is only a delay inside the loop. That delay does nothing but wait (states are waits) until a count condition is met. There are no transitions from state to state associated with the loop, despite the first look of it.
The loop is really an input white-to-dark transition detector, with a counter of these transitions. All outputs occur outside the loop itself. The action of turning the motor on appears to be interactive and prior to the loop being entered. The action of turning the motor off on exiting the wait where the program ends.
Notice the code could be written the following way, and still function nearly identically (except maybe run faster):
while (lines_to_count > 0)
while (sensor detected white surface) and (sensor detected black surface) lines_to_count = lines_to_count -1 loop while
loop while
turn motors off
This removes the use of the on_white_line variable, which obfuscates the function of what is going on. The code is simply looking for a time when the first sensor reading shows white, and a following sensor reading shows black. This is the condition under which the count is decremented. While the sensor reading continue to show black, there will be no count. When the sensors start showing white, a second reading again showing white, there will be no count. Only when at least one count has been found to be white, and the following has been found to be black, does the count increment.
Now as noted by others, if there is any noise as the sensor moves from white to black (as one should well expect in the real world) the motors will turn off almost immediate at the first edge (white to black _or_ black to white) because the noise will show multiple edges of both kind.
Generally, hysterisis is used to debounce an input sensor for exactly this reason. Hysterisis is feedback, and feedback is another way of sensing past state, and past state implies Finite State Machine. So this algorythm could be made much more reliable and robust by adding a delay after the detection of each edge. A FSM (no matter what language encoded in) is what's needed to make this routine appropriate to its intended task.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Correction!
The inner while loop is the white to black event detector, so the loop should continue until white ot black is detected.
while (lines_to_count > 0)
while (sensor detected white surface) and (sensor detected black surface) not loop while
lines_to_count = lines_to_count -1
loop while
Note the result is not'ed in logic. The outer loop is the count loop, and should continue until the count is met.
Also there is a slight flaw in the logic I chose above, because if two consecutive reads are white, and then two consecutive reads are black, the loop will miss the edge.
The use of the variable on_white_line in the original code prevented this edge being missed. Being part of the if conditional, and being ballistic, in the same sense as a ballastic thermometer, once the sensor was even once found to be white and not cleared until it was later found black. The sensor would always be checked by the second if test to see if it was ever black. although, not necessarily on the second subsequent read. So there is a very subtle use of state information encapsulated in the use of that variable.
I wish there were some formalism to check and extract the nature of state information from different programming models. As far as I know, no such generalized tool exists. I would very much encourage research on the subject, and hope to discover such if no one else should precede me in doing so.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
there is no problem in logical error like.. i dont think there is any problem here.. ok give delay in steps and check it out.. may be senser accuracy giving problem here.. it might happened that while crossig the pattern 1st time only it compleats loop.. may b your line is not sharp anough or senser is little far from the surface.. i m just gessing.. try and observe it.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Def sounds like noise from the sensor. Remember that most sensors/signals dont necessarily operate in the same discrete manner that computer logic does (i.e. you will not receive constant "on_white" or "on_black" necessarily due to noise). Try altering the algorithm to require an on_white signal for X iterations of the loop (and find the right threshold for X). Your chance of getting false positives X times in a row decreases exponentially. Only be careful that you do not end up with the same problem reversed (i.e. "on_black" false positives prevent you from ever registering a white line). At least, that's probably what I'd try. =)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
do one thing.. keep a led or any light sourse just behind the senser so that white and blace surfaces wil b detected properly.. yaa keep proper isolation b'ween senser and light source so light should not go directly to the senser.. i m telling so because, since the senser is in down to the body so there is a chance that due to the shaddow of the body senser is fealing only black patches.. ya one more thing put a pod in the connection of light sourse so that u will b able to control the intensity of light so that it would b in optimun light.. just try and check.. hope u will do perfect if not this solution then any other..
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.