Algorithm for counting number of lines travelled over

Hmm...I have rechecked the code...seems the problem was a bit of syntax afterall. Sorry for the bother.

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

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.

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. =)

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.

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..

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.