At first the entire project seemed like a large task which involved specialized routines to perform specific jobs at certain points on the obstacle course. If the entire process could be viewed in one frame, it can be seen that the robot needs to do only two things at any given time. Although the robot need to perform different specific tasks at different stages of the course, all these tasks fall into one of two classes; a state duty, and a state check. In every state that the robot is in, it is always doing two things:
performing some tangible duty,
sensing for certain criteria to be met.
The condition that the robot looks for changes from state to state but in all cases the satisfaction of this criteria results in a state change. In the mean time, the robot performs a duty while in that state; which in turn gave definition to the state by means of its behaviour.
As a means to keep the code size minimal it was vital to find this pattern. With the knowledge that every state can be generalized to fit a common loop, many of the specialized routines can be reused. These routines had to be called in a common way to make the main loop of the program identical for every state. Yet, they had to be flexible enough to call the proper routines for the current state of the robot. In addition to that, when the criteria of the state check is met, the program must know what the next state is.
Table of Content
Line Following Robot