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.

• Dynamic Alignment : Our first plan was to check and fix the alignment as the robot was going forward. This failed because by the time the cricket had determined that the robot was out of alignment and adjusted accordingly, the robot had changed positions. Thus the cricket was constantly trying to adjust the position of the robot as it had been a few seconds earlier. By stopping to align, the final alignment procedure rectified this by stopping the robot to check and fix its alignment.
• Check Alignment while Turning: After we learned the problems with dynamic alignment, we developed a new alignment procedure that stopped the robot to check the its alignment. The cricket then determined which way the robot needed to turn to realign itself with the wall, and started the turn. It continued to turn, continually checking the alignment, until the robot was realigned parallel to the wall. In this procedure, the robot often just kept turning, never recognizing that it had passed the point of alignment. We allowed for some margin of error, but it never worked very well. The final alignment procedure rectified this by making small, pre-defined tweaks in one direction and then checking the alignment again, tweaking again if necessary.

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:

• Setting up a turn: We found that the robot often found itself in the middle of an intersection, but be oriented in a parallel/perpendicular fashion to the maze. Not realizing that, but recognizing that a decision needed to be made, it would make a decision and take action accordingly. For example, it might be in the middle of an intersection in which it needed to turn left, but was at a 45° angle to the wall on its right. Not realizing that, it would make a 90° left turn, putting itself heading right for a wall. It would then start to go forward again, and crash.
  • Before turning, Cricket 1 set up the turn. If there was a wall on its left, the robot simply used the alignment procedure (described above) to align itself parallel to the left wall. If there was a wall on the right, the robot used a similar alignment procedure to align itself parallel to the right wall. If there was no wall on either side (i.e., if it was in the middle of an intersection in which it could turn either right or left), it backed up until both left sensors detected a wall on the left, aligned with that wall, and then went forward for a specified distance (determined experimentally).
• Futile attempts to align: The robot often got stuck in a loop trying to align. Sometimes it was almost aligned, so as minor as the tweaks were, tweaking left turned it too far to the left, while tweaking right again turned it too far to the right. Other times it was trying to align when there wasn't a wall within range. This happened if, in the process of aligning, the robot tweaked its way into an intersection, and occasionally happened under other extremely random circumstances (generally non-reproducable, which is why we won't bother to explain them all here).
  • In an attempt to fix the first of these problems, we altered the tweak procedures such that the tweak right procedure turned the robot to the right slightly more than the tweak left procedure turned it to the left. Since the tweak procedures no longer adjusted the robot to the same degree, the robot no longer tweaked back and forth indefinitely because the aligned orientation was located exactly halfway through a tweak. We made the right tweak longer because the robot tended to veer to the left rather than to the right, so it would soon correct the slightly longer right tweak with its normal veering.
  • To help avoid both of the problems mentioned above, we included a time-out clause in the align procedure. If the robot had been trying to align for a certain amount of time and hadn't succeeded yet, it stopped trying to align. It went forward briefly and then tried to align again.
• Halfway into an intersection: Cricket 1 often detected a doorway before the robot was all the way into it. Cricket 1 would then start the turn and the robot would run into the wall that it hadn't cleared.
  • We altered the code such that when Cricket 1 detected a doorway, it backed up until it was back in the hallway that it had just exited. It realigned itself in the hallway and then went forward a specified distance (measured with the shaft encoder). Then it was properly positioned in the middle of the intersection, in a parallel/perpendicular orientation to the maze, and could make a turn without crashing.
• Up against a side wall: The robot sometimes got so close to the wall that the side of the robot was stuck against the wall. In this situation, the robot couldn't turn at all (we believe this was due primarily to the length of the robot), so the jog procedures could not remedy the problem.
  • We never implemented an escape clause for this situation due to lack of time and a number of more pressing problems. However, the robot proved to be suprisingly good at getting itself out of this situation. It was powerful enough to push itself off the wall most of the time.
  • We did implement measures to prevent this situation from occuring. We narrowed the range that kept the robot in the middle of the hallway, and we had it check whether or not the robot was in this range more often. These preventative measures worked almost all the time, particularly in the final stages of the code, so the robot almost never got stuck in this manner toward the end of the project.
• Up against a wall in front: The robot often just went forward despite the fact that it was heading for a wall and crashed into it.
  • Again, we did not have time to implement an escape clause for this situation. It rarely happened when the code was working properly - usually this situation was a sign that the code was wrong - so it never made it to the top of the priority list. There is a straightforward solution - when the front bathroom sensor is too close to a wall, it has or is about to crash, so it should back up and reevaluate the situation. However, this didn't work because the bathroom sensors are not accurate for very short distances. Therefore, when the robot was up against a wall in front, the front bathroom sensor might very well have had a reading that indicated that the wall was a foot away.

• Lisa Marie Hazel (lhazel@wellesley.edu)
• Meredith Shotwell (mshotwel@wellesley.edu)
• Created: May 6, 2000
• Last Modified: May 7, 2000