Monday night...

Signed-off-by: Jennings Anderson <jennings.anderson@gmail.com>

docs/roboDocumentation.tex

@@ -260,18 +260,79 @@ \subsection{Threads}
 
 \subsubsection{Challenges}
 
+\clearpage
+\subsection{Sonar \& Range Finding}
+The Robot has 5 range finding sensors that operate via sonar.  That is, they emit a sound wave and measure the time it takes for the wave deflect off an object and return.  Since the speed of sound is constant, the distance it traveled in the measured time can be determined.  In order to get 5 sensors active, a relay had to be added to the circuit to overload the digital input ports on the IntelliBrain2.
+
+	As a result, when sonar is running, there is a ticking noise as the relay switches back and forth.  The logical obstacles we overcame with the sonar sensors was timing.  There is a window of time between when the sensor has received the signal and the sensor trashes the signal.  If you ask for the distance too soon after telling the sensor to \textit{ping()} (emit a sound wave), there will be no data to receive.  Too long and the data is no longer valid or trashed by the sensor.
+
+Here is a diagram of the sensor we used and its function:\footnote{Image from http://www.generationrobots.com/site/medias/Principe-fonctionnement-Sonar-Ping-Parallax.JPG}
+
+\begin{figure}[h]
+\centerline{\includegraphics[scale=.8]{img/sonar}}
+\caption{Parallax Ping))) Sensor}
+\end{figure}
+
+The timing issue made us shy away from using Threads at first because we could not control the timing very accurately if the processor was determining which processes got to run when; however, we ultimately decided to run the sensors iteratively as a single thread with hard coded 200 millisecond delays between thg ping and the retrieval of information from the sensor.
+
+The two side sensors (East and West) are connected to the relay and take turns as active distance sensors.
+
+\clearpage
+\subsection{Engine \& Motor}
+One of the more difficult parts of the robot to program, the motor, an Axial 27T electric motor is controlled by the Axial AE-1 ESC.  These are the two parts:\footnote{Images from: http://axialracing.com/ftp/ax10rtr/}
+
+\begin{figure}[h]
+\centering
+\subfloat[27T Electronic Motor]{\includegraphics[scale=.85]{img/motor}}
+\hspace{5mm}
+\subfloat[Axial AE-1 ESC]{\includegraphics[scale=.85]{img/ae1}}
+\end{figure}
+
+The AE-1 is connected to one of the MicroController's servo ports and we initialize it as a \textit{continuous rotation servo}.  This means that it takes integer arguments for the command \textit{setPower(int n)} between -16 and 16 (negative numbers representing reverse).  
+
+Additionally, active braking is available, so if the controller gets a command for the opposite direction, it will brake and bring the motor to a stop.
+
+The motor control is the ultimate showcase of theoretical versus physical programming.  The values passed to \textit{setPower()} never represent the same speed.  There are too many factors: battery level, how long its been running, what speed it was going, driving surface, etc.
+
+To remedy this, we wrote a separate driver called Engine that uses the Nubotic Wheel Watcher chip\footnote{Image in previous section} to count the rotations of the motor.  This is calculated to the number of rotations-per-minute (RPM) so that we can receive active feedback on the current wheel speed.
+
+From here, we can attempt the general motor control logic:
+\begin{enumerate}
+\item Set a desired velocity; if not 0, set the motor power to a specific range that somewhat corresponds to that velocity.
+\item Get the current RPM of the motor
+\item If the RPMs are  higher than desired, decrease motor power.
+\item If the RPMS are too low, increase motor power if its not already at maximum level.
+\item Go To Step 2.
+\end{enumerate}
+
+To implement this motor logic, we used a proportional-integral-derivative (PID) Controller.
+
+The PID is the most commonly used feedback controller.  It works to minimize error by adjusting input variables:\footnote{Image and Description from Wikipedia: http://en.wikipedia.org/wiki/PID\_controller}
+\begin{figure}[h]
+\centerline{\includegraphics{img/PID}}
+\caption{PID Controller Diagram}
+\end{figure}
+
+The PID controller is initiated in the Engine class and then power is set 
+
 \clearpage
 \subsection{Remote Control}
-In a last addition to the robot, we incorporated the original RC car remote to override the robot logic for motor control.  This was done to serve two purposes: 1) act as a kill switch and 2) provide the ability to manually drive the robot to train a Neural Network.  We played with this idea early on, but abandoned it due to difficulty in obtaining clean data from the remote.
+In a major addition to the robot, we incorporated the original RC car remote to override the robot logic for motor control.  This was done to serve two purposes: 1) act as a kill switch and 2) provide the ability to manually drive the robot to train a Neural Network.  We played with this idea early on, but abandoned it due to difficulty in obtaining clean data from the remote.
 
 Upon revisiting the idea, we determined the original problem was a limitation in the physical clock speed of the Micro Controller.  The IntelliBrain2 has a clock speed of 14.7 MHz.  The frequency of the remote is 27 MHz.  Therefore, no matter how many consecutive clock cycles we gave the remote sensor, it was incapable of accurately sampling the change in signal.
 
-To remedy this issue, our team member pursuing a Physics degree created an RC circuit (a type of Low-Pass filter) for the remote sensor that cleaned up the signal and allows for meaningful sampling of the analog input.  We should note that the current circuit is an improvement on the first attempt which utilized much larger capacitors that \footnote{featured} a multiple second delay on steering and throttle input.
+To remedy this issue, our team member pursuing a Physics degree created an RC circuit (a type of Low-Pass filter) for the remote sensor that cleaned up the signal and allows for meaningful sampling of the analog input.  
+\begin{figure}[h]
+\centerline{\includegraphics[scale=.5]{img/circuit}}
+\caption{Nate's Low-Pass Filter Circuit Diagram}
+\end{figure}
+
+We should note that this current circuit is an improvement on the first attempt which utilized much larger capacitors that \textit{featured} a multiple second delay on steering and throttle input.
 
-\subsection{Remote Input}
-After averaging the sample data, we can obtain nearly real-time steering and throttle input.  Because we must wait for the capacitor to charge/discharge, there is significant lag in control.\footnote{After all this, we've succeeded in building a simple RC car (worse than the one we started with)}
+\subsubsection*{Remote Input}
+After averaging the 3 sample points (for consistency), we can obtain nearly real-time steering and throttle input.  Because we must wait for the capacitor to charge/discharge, there is some lag in control.\footnote{After all this, we've succeeded in building a simple RC car (worse than the one we started with)}
 
-The impact of this feature is a physical kill switch: Turn the remote on and the running logic stops and the remote takes over\footnote{Also, the \textit{Mario} theme song plays}; turn off the remote, and the running logic resumes.
+The impact of this feature is a physical kill switch: Turn the remote on and the running logic stops and the remote takes over.\footnote{Also, the \textit{Mario} theme song plays}; turn off the remote, and the running logic resumes.
 
 \section{Robot User Manual}