Project 1: Robot Code Paper
Group 7: Robert Moe, Celi Sun, Mark Woehrer, John Zumwalt
Due: Monday, February 17

The focus of our code was to keep things as simple as possible.  This includes such things as keeping the code limited to one process, limiting the number of function calls, and not using floating point numbers.  Also the replication of work was kept to a minimum.  We chose to work with the raw encoder clicks to determine distance, along with setting the PWM values or each motor directly.  All fixed constants were defined at the top of the source-code.  The LCD was used to display debug information.

In the simplest case, the basic operation can be broken down into the following steps:  Drive straight, find the black line, drive half-way into the square, turn right 90 degrees, align to the black line, repeat.

To drive straight the angular velocity is ramped up from zero to a final value in an open-loop fashion.  This eliminates wheel slippage when accelerating, by keeping the force applied by the motors below the static coefficient of friction of the wheels.  In this case it is also important that the motors are matched since there is no feedback.  Without matched motors the robot will not travel in a straight line.

After about 5ft. the IR sensors begin looking for high readings -- black tape.  When a sensor finds what it believes to be black tape, the corresponding motor will shut off.  This gives us a rough alignment that helps us save a small amount of time.  This also gives it a way to "hook" towards the middle of the square when one sensor hits the front edge of the square and the other misses and swings around to hit the side of the square.  Once both sensors have been triggered, we drive forward about 6 inches which places us somewhere in the middle of the square to set up the turn.

When turning we employ a method which pulses the motors in-effect breaking the static coefficient of friction which each pulse.  We initially tried to simply power the motors in opposite directions to accomplish the turn.  However, this increased the inertia and made the turn less precise.  

During the turning phase we use the encoders to determine if we have turned far enough.  However, we also check the IR sensors.  The key is the left IR sensor.  Since we’re only making right turns, if the left sensor finds tape during the turn then we know that we are on the edge of the box and that the right sensor must be outside of the box.  Having the right sensor outside of the box is devastating to our alignment procedure, so in this case the robot breaks out of the turn and backs up until the right sensor is inside the box.  If the turn is 
broken the turn takes no more action.

After the turn is complete we drive forward for a short distance until we find a black line, and then align the robot to that line through a process we refer to as the "shimmy". The shimmy has separate controls for the left and right motors that are set by the left and right IR sensors accordingly.  Their default condition is to pulse forward looking for the edge of the tape, typically an IR reading of somewhere between 50 and 100.  If a sensor hits a line, the corresponding motor is pulsed with a reverse value and stopped. This is an attempt to root that side of the robot over the tape.  Additionally, if, for example, the left side sensor is over the tape while the right is not, the left 
is pulsed backwards and the right is pulsed forwards.  This results in the twisting behavior that emerged to be called "shimmy". When the robot is close to a good alignment, it "shimmys' back and forth to try and find the best alignment, usually right over the inside edge of the tape.  Finally, if both sensors have obtained an acceptable alignment, a sleep is executed to allow the wheels to settle.  Often, during this settlement the robot will pull itself out of alignment and the whole process will start over upon waking from the sleep with a recursive call.

During software development it was found that accurately aligning the robot to the black line was a difficult task -- any small error in alignment would be amplified by the distance traveled.  So instead of putting all our effort into the alignment process, we decided to instead try to handle some of the cases where the alignment was not accurate enough.

If the robot goes too far without finding a black line then an error condition has been reached.  The robot stops the motors, backs-up, turns to the left, drives straight, and returns to the main loop (again looking for a black line).  Turning in only one direction is possible since there seemed to be a slight bias toward the right when driving straight.  This allowed us to make this assumption about the direction we needed to turn.

Additional plans were to include calculating the difference in the distance traveled by each wheel when entering the square.  But this was not included due to time constraints and the success of current performance.  This additional feature would be especially useful in the case of the "hook' behavior.  If the difference between the two is above a certain range, then subtract that difference from the Ninety degree turn.  This would help us approximate our position in the box and lead to better alignment.