Embedded Files
All of these problems were resolved by using the indirect jump to subroutine instruction. The address of the next state, the state checker, and the state duty were all saved in pre-defined variables that were jumped to when the need arose. This method did not require a dispatcher to instruct the program where the go next because this matter was sorted out the moment the robot entered a new state. Essentially the robot always did the same thing by jumping to the address in the "STATEDUTY" variable, and the address in the state check variable, "LOOKFOR". If the condition was satisfied in the state checker, the robot changed its behavior by jumping to a state initializing routine which had its address stored in the variable appropriately called "NEXTSTATE". The routine that was addressed in the NEXTSTATE variable was responsible for a few things that were only done once at the entry of a new state. It was responsible for marking the address of the string that described the robots current state, the starting motor controls at the beginning of the current state and the size of a software delay value if need be. The most important things that it did was save the addresses of, the next state initializing routine, the criteria checking routine, and the current state duty routine.
The criteria checking routines that were responsible for conditionally taking the robot to the next state included routines that checked for the bumper, the light sensors, and even a routine that looked for the software delay alarm. These same routines were used at different point on the course at only selected time as defined by the "LOOKFOR" variable. The heart of these routines were the compare instruction that branched the program into one of the state initializing routines as defined by the variable "NEXTSTATE". If the conditions were not met these state checking routines simple ended.
While in the main loop the program always jumped to the subroutine in the "STATEDUTY" variable. These duties included either tracking the line, decrementing the delay alarm counter, and even a void routine that just did nothing by only containing that RTS instruction. The "do nothing" routine or "DONUTN" as it was called was needed for instances when the robot was in a turn and needed to do nothing while in that turn because the motors were already set.
The track line routine was the most impressive of all the robots abilities. It tracked the line by using the E and F line sensors to determine whether the robot was steering left or right of the line. Using that data the robot corrected itself by switching off the appropriate motor to initiate a turn. The last routine was responsible for decrementing a delay variable that the alarm checker looked at. This decrementing process occurred once per main loop, so essentially the program didn't stall during any of the delays. The waiting process was part of the main loop, and not a subroutine that stalled the entire program.
Table of Content
Page updated
Google Sites
Report abuse