Perpendicular Parking
	
	The foundation of our algorithm was a state machine with the following states:
		STATE_IDLE,
		STATE_FOLLOW_WALL
	
		Each state was transitioned between by a call to "state_execute," which based on the current state and sensor values would return the move the robot
	should make next (discussed in more detail down below).  These moves were:
		LEFT,
		RIGHT,
		FORWARD,
		BACK,
		RECENTER_RIGHT,
		RECENTER_LEFT,
		STOP,
		PULL_IN_PARK
		
		Where we had a switch statement and would handle how each move should be made.
	
	Each state had the following purpose:
		STATE_IDLE - 
			Wait in this state until a call to find the next move of the robot is made.
			
		STATE_FOLLOW_WALL - 
			* Trigger left, front, and right ultrasonic sensors and wait for their echo response.  
			* Calculate the distance from each sensor.
			** Determine which move the robot should make.
			
				For determining what move the robot should make, we mostly used the front and right ultrasonic sensors.  We declared a threshold value for our 
			front sensor.  
				In the case that our front sensor received a value beneath this threshold, our robot would make a 90 degree turn to the left.
			We determined what a "90 degree turn" was by using rising edge triggered interrupts with our encoders.  In order to not have continuous, rapid 
			GPIO Pin change interrupts firing throughout our code, we made sure to enable these encoder pin-change interrupts when we wanted to do a turn,
			and similarly disdable them when we were done making our turn.
				Our robot was always right-aligned; therefore, in the case that the right sensor value went beneath or over two set threshold values, we
			made sure to make the robot move in such a way where it would run parallel to its right wall as best as possible.
				In the case where our right sensor value was suddenly a high value (again, a threshold we had set through trial and error), we knew we were
			now in the position to make a right turn.  However, in order to determine whether we should be turning right to find the parking spot, or turning
			right INTO a parking spot, we checked the left sensor as well.  If the left sensor distance was not that large and the right distance was
			greater than the width of the car, we decided that we should just be doing a right turn.  On the other hand, if the left sensor distance was large
			and the right sensor distance was, again, greater than the width of the car, then the next move should be to park.  When we get to this point,
			we know we are in the position where we should be pulling in to a parking spot.  This move uses the encoders to pull up a fixed amount of distance, 
			turn right 90 degrees, and then pull in to the parking spot and lock the code in an infinite loop as our stop "state".
			
				

Parallel Parking
	
	For the Parallel Parking algorithm, we used mostly the same logic as above with the exception of the following:
		The possible moves to get from our 'state_execute' function were now:
			LEFT,
			RIGHT,
			FORWARD,
			BACK,
			RECENTER_RIGHT,
			RECENTER_LEFT,
			STOP,
			PARALLEL_PARK
		
		With the difference being "PULL_IN_PARK" was now instead "PARALLEL_PARK".
		The logic for our PARALLEL_PARK move was as follows:
			Once we are in PARALLEL_PARK, we know that we are where are parking spot should be.  However, we need to go beside the next car so that 
			we could back up into our parking spot.  Therefore, we do continuous FORWARD, "RECENTER_LEFT" and RECENTER_RIGHT" moves (to maintain parallel
			to the parking spot) until our right sensor distance suddenly drops below our threshold.  Then, we use our encoders to turn our car 45 degrees
			towards the parking spot, back up into the spot, then turn another 45 degrees in the opposite direction we initially did in order to straighten
			our vehicle.