Cricket 1: The Driver
Hallway Navigation

The navigational system of the hallway mode was comprised of four parts:

  1. Following a wall. Following a wall entailed going on a roughly straight path that was roughly parallel to the wall on one of its sides (in this case, the wall of its left side). If it veered from its path such that it was no longer parallel to the wall, it needed to determine and correct this. If it veered too far away from or too close to the wall, it needed to determine and correct these conditions as well.
  2. Making a 90° turn. This turn was a rough estimate of a 90° turn rather than an exact one. Once the turn was complete, it could correct errors of a small degree by using the same alignment procedure that enabled it to stay parallel to the wall.
  3. Making decisions. The robot recognized when a turn was possible or necessary, and it decided whether to go straight, turn right, or turn left. This involved checking the front of the robot for an approaching wall and also checking both sides for doorways or different branches of the hallway.
  4. Escape clauses. If the robot found itself in an unusual situation and needed to get out of it, it recognized the situation and corrected it. For example, if it was wedged in a corner, it backed up and then tried again. These escape clauses needed to cover a wide range of possible pitfalls; we did not have time to add checks and procedures for all of them.

In addressing these four components, we tried many different methods. We have included on this page links to some of the methods that we tried that were not as sucessful. Click here to see all of the navigation designs that didn't work.

We did end up with a method for each component that worked well and reliably. Integrating these working components proved to be challenging and time-consuming, and we had varying degrees of success in this endeavor.

Click here to see our code for Cricket 1 (only for those who truly care . . .).


Following a Wall

Following a wall requires two sub-components: staying parallel to the wall and staying in the center of the hallway. The robot stayed parallel to the wall on its left by stopping frequently for Cricket 1 to check the alignment of the robot. There were two bathroom sensors on the left side of the robot, one toward the front of the robot (front left sensor) and one toward the back (back left sensor). The check its alignment, Cricket 1 comapred the values of these two sensors. If the values were within a certain range of each other, the robot was parallel to the wall and could continue going forward. If the back left sensor was closer to the wall than the front left sensor, it turned to the left for a very brief period of time, then checked the alignment again. If the front left sensor was closer to wall than the back left sensor, it turned briefly to the right, then checked the alignment again. By tweaking its orientation with respect to the wall in this way, Cricket 1 kept the robot parallel to the wall.

The robot stayed in the center of the hallway by using a similar process. Through experimentation, we determined the range of sensor readings that indicated an appropriate distance from the left wall. Every time the robot stopped and Cricket 1 checked its alignment, Cricket 1 also checked its distance from the left wall. If both left sensors were within the range, the robot was more or less in the middle of the hallway and could continue to go forward. If both sensors were outside of the range, the robot made a small jog to correct this. For example, if both sensors were too far away from the left wall, it jogged to the left by turning left briefly (similar to the tweak method used for aligning, described above), going forward briefly, and then turning right briefly to realign itself with the wall. If both sensors were too close to the left wall, it jogged to the right in the same manner. At the end of the jog, Cricket 1 checked the alignment and position of the robot again, and readjusted if necessary. The jogs made rather minor corrections, so occasionally the robot needed to make two consecutive jogs to get back to the middle of the hallway. However, we deliberately made the range small enough to prevent this most of the time; the robot did not usually have time to get very far from the center of the hallway before Cricket 1 corrected its course, so one jog was almost always sufficient.

The alignment procedure was one of the most crucial components of the program, and we tried a number of different methods before arriving at the one described above.


Making a 90° Turn with Shaft Encoding

When the robot arrived at a place in the hallway where it could, or needed, to turn, it made a turn that was more or less a 90° turn. After previous trials with sensor based turns and timed turns, we decided to use a shaft encoder in turning. The shaft encoder counted the number of axle revolutions using an IR sensor, thus ensuring that the robot always turned the same amount (the number of revolutions required for a 90° turn was determined experimentally). Unlike a timed turn, a turn made with a shaft encoder did not vary with battery and moter strength. The shaft encoder cannot account for slippage of the axles or wheels, but we did not encounter any problems in this area.


Making a Decision

When the robot reached a point at which it could or should turn, it checked all of the bathroom sensors to determine where the walls were. There were several possible situations that the robot could be in at this point, given the design of the maze. The table below explains the different situations and what the robot did.

Situation of the robot

Action taken

Walls to the front and to the left

Turned right

Walls to the front and to the right

Turned left

Wall to the front only

Could turn right or left; made a randm decision between the two

Wall to the left only

Could turn right or go forward; made a randm decision between the two

Wall to the right only

Could turn left or go forward; made a randm decision between the two

The alignment procedure (described above) checked to see if a decision needed to be made (i.e., if there was a wall in front or a doorway on either side). If so, it triggered Cricket 1 to stop following the wall and instead make a decision. After checking the environment, Cricket 1 made a decision (as per the table above) and then either went forward for a specified distance, in order to get out of the intersection and begin following the left wall again, or called the turning procedure (described above).


Escape Clauses

The robot often got itself into situations that it shouldn't have been in. On a theoretical level, the robot should have always been oriented in a parallel/perpendicular fashion to the walls. On a practical level of course, it often ended up askew. Ultimately, not being on a parallel course resulted in the robot crashing into a wall, so these situations were to avoided, and if encountered, recitfied as quickly as possible. We thus implemented a number of escape clauses and prevention clauses:




Robot Home  Introduction  Final Robot  Structural Design  Navigational Systems  Misadventures