"Quirks" of the Crickets

We encountered rather serious problems with the Crickets in terms of reliability. Sometimes the Crickets worked, sometimes they did not. Cycling the power often alleviated the problem temporarily, but this usually required several tries, and the problem almost always recurred. They suffered from random failure: at random times, they executed seemingly random decisions and took seemingly random action. This random failure was often associated with faulty sensor readings, generally indicated by all the sensors reading 255 (the maximum value in their range). The sensor readings were displayed on the LEDs, but we were able to determine that it was the sensors and not the LEDs that were failing. Although the random Cricket failure and faulty sensor readings sometimes did occur independently, they were most often associated with each other. If, when the Cricket was first started, one or more of the sensors gave a reading of 255, something was faulty and the Cricket would not run the code properly. We quickly learned to simply turn the Cricket off and try again when this occurred.

Due to the unreliability of the Crickets, we are often unable to replicate successful behavior on demand. The program generally worked extremely well and consistently for several hours, but then suddenly stopped working. So we often worked on one stage of the program design, got that stage to work consistently, and then moved on to the next stage, only to find that the previous stage no longer worked properly.

We innitially suspected that the cause was insufficient power, so we replaced the single 9V battery of the Cricket with a battery pack that has greater current capabilities. This did not eliminate the problem of random failure. We then thought that the problem might stem from the number of bus devices (five sensors and three LEDs) that were hooked up to the Cricket, so we eliminated two of the sensors and two of the LEDs. This did improve the Cricket's reliability, but did not eliminate the problem altogether.

Finally, our advisor realized the primary source of the problem: we had been cycling the power on the Crickets too quickly. In cycling the power, one should turn the Cricket off, wait five seconds, and then turn it back on. Not realizing this, we had been switching them off and then back on immediately. If the power is cycled quickly, the Crickets will indeed execute individual lines of code from the program in random order. From that point forward, we rarely encountered the problems of random failure and faulty sensor readings as long as we waited the obligatory five seconds when cycling the power.

Another odd behavior of the Crickets that we observed was their tendency to sometimes stop running the program on their own. This usually occurred after the robot had run into a wall, so we initally thought that the Cricket somehow sensed that it had been powering the motor to no avail for some period of time, and thus decided to stop the program to conserve power. However, the Crickets also stopped running the program while following a wall, with no discerbable environmental change. This happened rarely, and we were unable to reproduce this behavior on demand, so we never determined the cause. We did not often encounter this in the final stages of the robot, so it may have been related to this issue of power cycling.

"Feautres" of Cricket Logo

Cricket Logo allows for only fifteen global variables. However, although it does not recognize the sixteenth global variable as such, it does not give an error message saying that the variable is undefined. Instead, it simply assumes the value of all "undefined" variables to be 0. For example, it will allow you to declare my-var as the sixteenth variable, set my-var equal to 10, and then call my-var in subsequent procedures. It will never give an error message; instead, it will assume that my-var is 0 every time you use it. It is therefore up to the programmer to keep track of the number of global variables.

There is no way to exit from a loop in Cricket Logo. The only way to exit from a loop is to exit from the procedure, which returns control to the calling procedure. Therefore, any time a loop is needed, it must be at the end of a procedure, and the code must be structured such that the procedure containing the loop should be stopped at the same point at which the loop itself should be stopped. In our code, this resulted in a great deal of abstraction: when we needed a loop, we often wrote a separate procedure to contain it.

Cricket Logo does not have a good way to allow for concurrency. The when command does launch a new thread, but only one when can be active at a time. Moreover, Cricket Logo simulates concurrency by taking one step of the main thread, then one step of the when thread, then one step of the main thread, and so forth. Although this allows the two threads to be executed concurrently, it doubles the running time of the program. In the context of a moving robot, this delay is unacceptable: by the time the Cricket reached the next step of the main thread, the robot had moved and the informating on which the Cricket based its decisions was no longer accurate. We therefore decided not to use the when command. Instead, we used the three separate Crickets to control the different threads that needed to be executed simultaneously. Because the Crickets are small and lightweight, adding another Cricket to the robot was not structurally problematic. We envisioned a system in which the three Crickets could communicate via IR signals when the different threads needed to interact (for example, when one thread needed to be interrupted), and although we did not have time to fully integrate the three Crickets, we believe it could be done.

Cricket Logo has two commands for stopping motors: off and brake. off stops the power supply to the motor, so it may continue going briefly due to inertia. brake applies a brake to the motor, so it stops immediately. The Cricket continues to actively brake the motor until the off command is evoked, and it requires power for as long as the brake command is active. Both commands are useful, and one is often noticeably better than the other in a particular situation. For example, off proved to be a better choice in our align procedure. The align procedure stopped the robot, made a small adjustment, and then checked the sensors again. In this procedure, braking the wheels jerked the robot enough to cancel out the effects of the small adjustments. On the other hand, when the robot detects a wall approaching to the front, it needs to stop quickly before running into it, so the brake command was more effective in this situation.

The wait command in Cricket Logo is useful when you want the program to pause for a short time. However, its parameter is measured in tenths of seconds, which is a long time relative to the program. We wrote a delay procedure to simulate the wait command on a smaller scale. The delay procedure repeats some action a certain number of times, where that action requires an extremely short period of time to perform. For example, delay might reset the timer a certain number of times, or it might send an IR signal a certain number of times. The particular action does not matter in terms of the delay procedure, but we had to carefully choose an action that did not interfere with the rest of the program. For example, we first used a delay procedure that reset the timer in our code for Cricket 1. We then called delay from the align procedure. However, the align procedure was also supposed to reset the timer at a certain point and then check to make sure that the robot had not been trying fruitlessly to align for too long. Since delay reset the timer within align, this time-out in align did not work. We therefore altered delay so that set a variable equal to itself a certain number of times, which worked equally well and did not interfere with the rest of the code, since it did not change the state of anything.