Michael Jones, PhD

line following robot. Here's an interesting verification problem: Using a model checker, verify all line-following behaviors of a robot for all interrupt interleavings, input spaces and delay loop lengths. Consider the following:

The algorithm for the light-seeking behavior is quite simple. I read the values from the two voltage-divider photoresistor circuits with inputs 0 and 1 of the HC11's A/D converter. Whichever value is the largest (left or right), I turn the robot in that direction. Like the line-following code, I use arc turns rather than pivots to always provide forward movement. The program is a continual loop looking at the sensors and either arcing left or right towards the light.

Well, we did slightly modify this simple program (Figure 10). Since the HC11 can scan the A/D converters every 64µS, or over 15,000 times a second, the result was very jerky. The first modification was to delay for about half a second each time through the loop. This resulted in the robot going in slow arcs--still not what we were looking for. What we settled on was an arced turn for about a quarter of a second, then forward movement for another quarter of a second. This is the behavior implemented in the program.

I thought this was interesting too:

Adjustments in the software timing will be needed to work with different sized wheels.

Interesting reading from the motorola 68hc11 reference manual:

• In calculating the latency time from the actual interrupt request to the CPU response to that request, the user must consider the possibility that the CPU had just started a long instruction as the interrupt was requested. Most instructions are two to four cycles long, but the multiply (MUL) and integer divide (IDIV) or fractional divide (FDIV) instructions are 10 and 41 cycles, respectively.
  
• It does contain the number of cycles per instruction for each instruction.