added to docs, removed unused code

doc/doc.tex

@@ -103,7 +103,7 @@ With only two wheels its purely dynamically stable, will fall over due to its ow
 \subsection{Balancing}
 We have a vertical two wheeled robot I hope its fairly obvious when I say that it is only dynamically stable. This presents a challance because we need some system which keeps the system upright in a variaty of situations and responds dynamically to changes it cannot predict.
 \subsection{Odometry}
-Knowing that our system is very dynamic and having the forsight to know that we will need to keep in constant motion to keep upright the odometry system will need to handle that. 
+Because we intend to map an area with the robot we need to know where we are. This issue is made slightly more challanging due to the fact we are in nearly constant motion keeping ourself upright.
 \subsection{Target Positions}
 The problem of target positions like odometry is made more challenging due to the fact we are almost constantly in motion. We simply cannot "not move" when we are in the location we want to be as we'd fall over. This means the target position will need to be a "best effort" battle to keep in the same place as best as we can.
 \subsection{Communication}
@@ -121,14 +121,18 @@ The target position
 \section{Challanages}
 
 \subsection{Balancing}
-Obviously a robot which stays upright and only has two wheels 
+Balancing took the longest out every task combined. It required research on not only PID control loops but also on different libraries and calibration requirements for our \texttt{MPU6050} gyroscope. These difficulties were compounded by the fact that we did not know which part/section would cause the robot to "randomly flail about and violently crash into the wall/floor". 
+
 \subsection{Odometry}
-Keeping track of our position and angle was another challange that required careful consideration. Because the system is so dynamic and in constant motion we needed a system which could account for the constant movement to maintain a stable state.
+We origionally didn't have encoders to keep track of our position and instead attempted to use the accelerometer to calculate displacement to save money on parts. This however, did not pan out. The first problem we ran into was our heading drifting. We knew it was going to be an issue after reading docs but tried a good old fassion "how bad could it possibly be" and oh boy did it drift fast. The second issue was "double integration over a noisy inaccurate signal" lead to our calculated position quickly exiting the stratosphere. These issues very quickly lead us to just get encoders.
+
 \subsection{Target Positions}
-Because the robot is in constant motion keeping itself balanced without a "push" towards a single position it will drift around. To solve this we use the odometry system as a input to the movement system. By setting the desired heading of the robot to the vector from its position to the target position, and by biasing the direction the robot will travel to be the direction to the target position we get a crude way of staying in a single position.
+Using the bias towards a direction by setting the target angle was not the first approach we used. We originally directly added a movement speed to the motors like we do for turning. This however caused the robot to become unstable in certain situations. We eventually abandoned the approach in favor of the one used currently.
 
 \subsection{Communication}
-Since we have limited processing power and time per loop iteration we need to be smart in how we receive and transmit data to our mapping software. For this reason we designed a stateless UDP based network protocol overtop the esp8266 Wifi \& UDP libraries. \cite{wifi_lib}
+Since we have limited processing power/time per loop iteration we need to be smart in how we receive and transmit data to our mapping software. For this reason we designed a stateless UDP based network protocol overtop the esp8266 Wifi \& UDP libraries. \cite{wifi_lib}\\
+
+We originally used a TCP+Webserver based library for this as it allowed us to use HTML+JS to display information but it continually had processing requirements the controller could not meet.
 
 \section{Resources Used}
 \begin{itemize}

jdbg/src/Gui.java

@@ -66,7 +66,7 @@ public class Gui extends JFrame  implements KeyListener, MouseWheelListener {
             int number = 500;
             for(int i = 0; i < number; i ++){
                 try {
-                    sum += robot.getEverything().await()[19-1];
+                    sum += robot.getEverything().await()[17-1];
                 } catch (Exception ex) {
                     throw new RuntimeException(ex);
                 }

robot/distance.cpp

@@ -16,9 +16,6 @@ void initDistance(){
 void updateDistance(){
   if (lox.isRangeComplete()) {
     distanceReading = (float)lox.readRange();
-//    if(distanceReading>2000){
-//      distanceReading = (float)NAN;
-//    }
   }else{
     distanceReading = 8000;
   }

robot/headers.h

@@ -32,12 +32,6 @@ extern float angleOffset;
 extern float desiredYaw;
 extern float currentYaw;
 
-struct DebugState{
-  int motorTargetAngle;
-};
-
-extern DebugState dbgState;
-
 //-------- wire
 #include <Wire.h>
 #define Wire1 Wire

robot/robot.ino

@@ -17,8 +17,6 @@ float currentYaw = 0.0;
 
 FVec2 desiredPos;
 
-DebugState dbgState;
-
 void initSerial(){
   Serial.begin(115200);
   while (!Serial);

robot/webserver.cpp

@@ -70,9 +70,7 @@ struct EverythingPacket{
     Udp.write((const char*)&ID, sizeof(ID));
 
     float everything[] = {
-      (float)dbgState.motorTargetAngle, 
       (float)distanceReading,
-      0.0, //encoder.position(),
       angleSetpoint, angleInput, angleOutput,
       posSetpoint, posInput, posOutput,
       turnSetpoint, turnInput, turnOutput,