diff --git a/doc/doc.pdf b/doc/doc.pdf index 6511a1d..5ef54d5 100644 Binary files a/doc/doc.pdf and b/doc/doc.pdf differ diff --git a/doc/doc.tex b/doc/doc.tex index e4c35b6..7e3f560 100644 --- a/doc/doc.tex +++ b/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} diff --git a/jdbg/src/Gui.java b/jdbg/src/Gui.java index deff08e..7d5d6b5 100644 --- a/jdbg/src/Gui.java +++ b/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); } diff --git a/robot/distance.cpp b/robot/distance.cpp index 923fe2f..23e01cc 100644 --- a/robot/distance.cpp +++ b/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; } diff --git a/robot/headers.h b/robot/headers.h index 1707192..1eb9875 100644 --- a/robot/headers.h +++ b/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 #define Wire1 Wire diff --git a/robot/robot.ino b/robot/robot.ino index 5ae7c8c..7c7965e 100644 --- a/robot/robot.ino +++ b/robot/robot.ino @@ -17,8 +17,6 @@ float currentYaw = 0.0; FVec2 desiredPos; -DebugState dbgState; - void initSerial(){ Serial.begin(115200); while (!Serial); diff --git a/robot/webserver.cpp b/robot/webserver.cpp index 59721e6..837b191 100644 --- a/robot/webserver.cpp +++ b/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,