Program Workflow of Misguided 1.0
By the Olympic Team


	This autonomous car uses object oriented programming to reduce power 
consumption when processing. In simple terms, we have attempted to simplify 
repeated steps into single functions that can be used repeatedly throughout 
the program with just a single statement. Instead of looping over the same 
instructions over and over again regardless of the desired behavior, we have 
chosen to design a program that will simply execute the appropriate code when 
required. In this way, we avoid the execution of unnecessary code, reduce 
glitches, and improve processing speed. The execution of our program begins 
with the initiation of a few variables that we will use throughout the code 
to store results, track status, and define constants. Then we initialize the 
various input and output circuits on the Arduino that we will be using later 
to receive results and to send instructions. After the variables and circuits 
have been initialized, the core of Misguided 1.0 begins.

	The car uses what we have called “SerialControl” methods and “AI” 
(Artificial Intelligence) methods in order to control the more basic methods 
like moving forward or obtaining the values of the sensors. The “SerialControl” 
methods use instructions sent through a USB connection in order to control the 
car. We used these methods to test our more basic functions and to debug the car 
through a more controlled approach. The “AI” methods are actually a lot simpler 
than they sound. These two methods do not resemble what some would consider Artificial 
Intelligence because the car is not really thinking nor will it make a spontaneous 
choice. However, the car will make a decision based on its current state and as we 
will see, its choices are rather clever. The “SerialControl” and “AI” method libraries 
coexist during execution of the program. The two libraries however define opposite 
behaviors; “AI” attempts to control the car autonomously and “SerialControl” 
waits for instructions before it takes action. For this very reason we have 
defined two operating modes: Auto Mode (AI) and Controlled Mode (SerialControl). 
The modes are controlled by a switch we have added to the Arduino. Also, for 
debugging reasons, we have allowed for “SerialControl” to initiate a temporary 
state of Auto Mode in order to test our “AI” methods.

	Since we have applied Controlled Mode in order to debug the basic 
functions of our car, we will go over the behavior of Auto Mode. Auto Mode 
begins when either a temporary state of Auto Mode has been set by “SerialControl” 
or when the Arduino switch has been set to Auto Mode. In either case, the car begins 
by using a basic function to read the values of the sensors attached to the front 
of the car. The values are compared to the constants that were set when the car was 
initialized. These constants define a near and a far value. For example, if the 
value of the front sensor is greater than the near constant, then something must 
be really close to the front of the car. The results of the comparisons are kept in 
Boolean variables that were also set when the car was initialized. The side sensors 
are compared to the near constant and the resulting Booleans are stored in a left 
and right variable respectively. However, the front sensor is compared to both the 
near and far constants. The resulting Booleans are stored in a near and far variable 
respectively. Once these Booleans have been set, the car uses “AI” to decide its move.

	We will begin by considering a basic situation. If the car approaches an 
obstacle that is in front of it (near constant), the car will move in reverse and 
then once the obstacle is no longer there (far constant), the car will resume forward 
motion. Now, what if the car approaches a wall perpendicularly? This situation will 
result in an endless loop. A more appropriate behavior would be to imitate the driving 
of a person who approaches a wall. They will usually move in reverse and then once the 
obstacle can be avoided, the car will resume forward motion in a specific direction. 
This approach would probably stop the endless loop. However, since our car makes small 
turns, it would be better if the car moves in reverse in one direction and then resumes 
forward motion in the opposite direction. How will the car choose in which direction to 
drive away? We record the last turn the car made. If the car was driving and then 
encountered an obstacle to its right side, the car will turn to the left and record 
it as its last turn. Later on, if the car encountered an obstacle in front of it, 
since it already knows that there is something on the right side, the car will choose 
to move in reverse to the right and then resume forward motion to the left. Now, what 
if the car approaches obstacles on both sides but not in the front? In this case, the 
car should first see which obstacle is closer to it. Then turn in the opposite direction 
of the side that is closest to one of the obstacles. And if the two obstacles were 
equally spaced from the car, then the car should simply drive straight forward 
without turning in order to save power. 

	We have called the car’s ability to read its side sensors and make a sensible 
choice as to where to turn the “Turning Logic” and the car’s ability to read its front 
sensor and drive in reverse the “Avoidance Logic”. A more interesting situation 
would be if the car was to enter a small hall where the car would drive straight 
due to the nature of its Turning Logic. What would happen if it reached the end of 
the hall? The car would assume that there is space to make a turn so it would use 
Avoidance Logic. However, it would soon hit the other wall and we would find ourselves 
in a loop. To avoid this error, we would have to make sure that the car evaluates the 
side sensors as it makes its turn. If it finds that it has obstacles on both sides the 
car will have to use its Turning Logic backwards as it moves in reverse. We have called 
the combination of the Turning Logic and Avoidance Logic the “Reverse Logic”.
The “AI” method is hence composed of Turning, Avoidance, and Reverse Logic. Through the 
use of “AI” the car is able to navigate through an undefined obstacle course. Nonetheless, 
the car does have physical limitations. The sensors are only effective at certain distances 
and on certain objects. For example, a thin or small object will be practically invisible to 
the sensors. Also, extremely close objects will result in extraneous values. The rest of the 
code is composed of basic functions that allow the car to state its mode (Musical methods) 
through a speaker, to state its status (Basic methods) through LEDs and sensors, and to move 
(Drive methods) through its two motors.