Added 2017-2018 mars rover repository.

OSU Robotics Club/Mars Rover 2017-2018/README.md

@@ -0,0 +1,2 @@
+# Mars Rover Team 2017-2018
+This repository contains the embedded, rover control, and ground station firmware and software for the 2017 to 2018 school year.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/Readme.md

@@ -0,0 +1,14 @@
+# CAPSTONE DOCUMENTS
+This folder will contain all documents for the cs capstone team.
+
+## Team Members:
+* Chris Pham
+* Ken Steinfeldt
+* Corwin Perren
+
+## TA:
+* Andrew Emmott
+
+## Instructors:
+* Kevin McGrath
+* Kirsten Winters

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/0_design_document.tex

@@ -0,0 +1,135 @@
+\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
+\usepackage{graphicx}
+\graphicspath{{./figures/}}
+
+\usepackage{url}
+\usepackage{setspace}
+\usepackage{multicol}
+\usepackage{pdflscape}
+\usepackage{pdfpages}
+\usepackage{caption}
+
+\usepackage{geometry}
+\geometry{textheight=9.5in, textwidth=7in}
+
+\renewcommand\refname{}
+
+\usepackage[numbers]{natbib}
+\bibliographystyle{IEEEtranN}
+
+% \overfullrule=2in
+
+% 1. Fill in these details
+\def \CapstoneTeamName{			Ground Station Software Team}
+\def \CapstoneTeamNumber{		30}
+\def \GroupMemberOne{			Kenneth Steinfeldt}
+\def \GroupMemberTwo{			Christopher Pham}
+\def \GroupMemberThree{			Corwin Perren}
+\def \CapstoneProjectName{		OSU Robotics Club\\Mars Rover Ground Station}
+\def \CapstoneSponsorCompany{	OSU Robotics Club}
+\def \CapstoneSponsorPerson{	Nick McComb}
+
+
+% 2. Uncomment the appropriate line below so that the document type works
+\def \DocType{	%Problem Statement
+				%Requirements Document
+				%Technology Review
+				Design Document
+				%Progress Report
+			 }
+			
+\newcommand{\NameSigPair}[1]{
+  \par
+  \makebox[2.75in][r]{#1} 
+  \hfill
+  \makebox[3.25in]{
+      \makebox[2.25in]{\hrulefill} 
+      \hfill
+      \makebox[.75in]{\hrulefill}
+  }
+  \par\vspace{-12pt} 
+  \textit{
+      \tiny\noindent
+      \makebox[2.75in]{} 
+      \hfill
+      \makebox[3.25in]{
+          \makebox[2.25in][r]{Signature} 
+          \hfill
+          \makebox[.75in][r]{Date}
+      }
+  }
+}
+% 3. If the document is not to be signed, uncomment the command below
+\renewcommand{\NameSigPair}[1]{#1}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+\begin{titlepage}
+	\pagenumbering{gobble}
+	\begin{singlespace}
+		% 4. If you have a logo, use this includegraphics command to put it on the coversheet.
+        \begin{minipage}{7in}
+			\centering
+			\hspace*{-.7in}
+			$\vcenter{\hbox{\includegraphics[height=4cm]{Oregon_State_College_of_Engineering_Logo}}}$
+			\hspace*{.2in}
+			$\vcenter{\hbox{\includegraphics[height=2.5cm]{OSURCLogoOrange}}}$
+		\end{minipage}
+
+		\par\vspace{.35in}
+		\centering
+		\scshape{
+			\huge CS Capstone \DocType \par
+			{\large\today}\par
+			\vspace{.5in}
+			\textbf{\Huge\CapstoneProjectName}\par
+			\vfill
+			{\large Prepared for}\par
+			\Huge \CapstoneSponsorCompany\par
+			\vspace{5pt}
+			{\Large\NameSigPair{\CapstoneSponsorPerson}\par}
+			{\large Prepared by }\par
+			Group\CapstoneTeamNumber\par
+			% 5. comment out the line below this one if you do not wish to name your team
+			\CapstoneTeamName\par 
+			\vspace{5pt}
+			{\Large
+				\NameSigPair{\GroupMemberOne}\par
+				\NameSigPair{\GroupMemberTwo}\par
+				\NameSigPair{\GroupMemberThree}\par
+			}
+			\vspace{20pt}
+            \begin{abstract}
+			% 6. Fill in your abstract
+            This document describes the design of the Mars Rover Ground Control software for the purpose of conveying design decisions and information to the project's stakeholders.
+            The Software Design Description (SDD) supplies a clear picture of the software's future implementation and provides the development group with a clear road-map.
+
+		\end{abstract}
+		}
+	\end{singlespace}
+\end{titlepage}
+\newpage
+\pagenumbering{arabic}
+\tableofcontents
+\clearpage
+
+% Major requirements per website:
+% - Each member writes up three pieces they will be owning/managing
+% - Full document still needs an intro and conclusion
+% - This is a HOW document (finally). Can contain info like:
+% -- APIs
+% -- Time-line
+% -- Testing Information
+% - Document must follow IEEE Std 10-16-2009 structure
+% - Each component design pieces must be at least 500 words
+% - Full doc must be at least 1500 words (literally impossible to NOT hit XD)
+% - Must use IEEEtran numbered citations
+\section{Introduction}\input{1_introduction}
+\section{References}\input{2_references}
+\section{Glossary}\input{3_glossary}
+\section{Design Considerations}\input{4_design_considerations}
+\section{Component Design}\input{5_component_design}
+\section{User Interface Design}\input{6_user_interface_design}
+\section{Conclusion}\input{7_conclusion}
+
+\end{document}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/1_introduction.tex

@@ -0,0 +1,44 @@
+\subsection{Purpose}
+The purpose of this software design document is to cover the design for the Oregon State University Mars Rover Team's ground station software.
+It will cover the details about how the software will function, how we will implement that functionality, and the reasoning behind design decision choices that were made.
+The ground station software for the Mars Rover project is the single point of contact between the team-built competition Rover and the users operating or viewing the rover.
+
+
+\subsection{Scope}
+This project will consist of a software package running from a remote control base station in order to remotely operate a competition-ready robot built by the Oregon State University Robotics Club's Mars Rover team.
+The project must be completed by May 31st, 2018 in order to be ready for the University Rover Challenge taking place in Hanksville, Utah.
+The controlling software must be able to do at minimum, the following: 
+
+\begin{itemize}
+\item Provide the capability to remotely drive the Rover via joystick(s) connected to the ground station computer.
+\item Allow for viewing of up to three video feeds from the Rover, and be able to change what video streams are viewed.
+\item Via a user input device, allow for manipulation of the Rover arm.
+\item Provide visual feedback about the state of the joint positions of the arm as it is being moved.
+\item Show the user a map of the competition area, allowing the user to zoom, view the Rover's location, and place navigation and landmark way-points.
+\item Allow the user to add way-points and then place the Rover in autonomous mode, wherein the Rover will drive under its own control along the way-points provided.
+\item Upon completion of an autonomous path, provide an easy to read notification that the navigation is complete.
+\item Provide a myriad of status information about the Rover's current condition including, but not limited to, the following:
+  \begin{itemize}
+  \item Connection statuses
+  \item Rover component statuses
+  \item On-board sensor readings
+  \item Battery charge level
+  \item System errors
+  \end{itemize}
+\end{itemize}
+
+Additionally, the client has requested a document be written providing a starting guide on how to re-use the finalized software package for future Rover teams to ease development in future years.
+
+
+\subsection{Context}
+Each year the Mars Rover software team writes ground station software from scratch in order to meet the changing requirements of both the Rover itself and competition rule changes.
+As this software is the main point of contact between the users and the Rover, the success of the team during competition often hinges on how well this software performs.
+In the past, lack of modularity and abstraction has made re-use of the ground station code near impossible.
+
+
+\subsection{Summary}
+This rest of this document will provide the details about how our team will implement the ground station software for the Mars Rover team.
+We will start by covering design considerations such as the environment our software will be running in, as well as the specific concerns of our stakeholder. 
+Immediately following will be a breakdown of the individual software components we will be writing.
+These will include descriptions of what, how, and why we will be writing each component the way we are.
+The document ends with a visual breakdown of the software UI, and rationale for why each component looks the way it does.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/2_references.tex

@@ -0,0 +1,2 @@
+\vspace{-2em}
+\bibliography{bibliography}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/3_glossary.tex

@@ -0,0 +1,17 @@
+\subsection{Acronyms and Abbreviations}
+\begin{itemize}
+\item ROS - Robot Operating System
+\item GPS - Global Positioning Satellite
+\item OSU - Oregon State University
+\item OSURC - Oregon State University Robotics Club
+\item NASA - The National Aeronautics and Space Administration
+\end{itemize}
+
+
+\subsection{Definitions}
+\begin{itemize}
+\item Ubuntu - A popular open source Linux distribution based on the classic Debian distribution.
+\item Rover - A robotic, remote controlled vehicle designed and built by OSURC to compete in the NASA Mars Rover Competition held in Hanksville, Utah.
+\item QT - An open source application framework developed by the QT Company.
+\item Python - A popular scripting language known for it's easy readability and rapid deployment abilities.
+\end{itemize}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/4_design_considerations.tex

@@ -0,0 +1,61 @@
+\subsection{Assumptions}
+From the descriptions and restrictions provided by the client, there are a few things that we need to assume to assure that the software will function correctly. 
+Our team is going to assume that the software/OS on the rover is going to be a combination of ROS Kinetic on Ubuntu 16.04. 
+The rover will have all of its components working correctly such as GPS and drive systems.
+The rover needs to correctly interact with the data that is provided by the station. 
+The rover needs to be connected to the same network as the rover.
+
+
+\subsection{General Constraints}
+\begin{itemize}
+\item \textit{Time Frame:} The software must be completed on or before May 31st, 2018.
+\item \textit{URC Requirements:} The software must not violate any rules provided by the competition host. \cite{urc_competition_rules}
+\end{itemize}
+
+
+\subsection{System Environment}
+\begin{itemize}
+\item Hardware
+  \begin{itemize}
+  \item 1 x Intel NUC
+  \item 2 x 24" 1080p Monitors
+  \item 1 x Keyboard
+  \item 1 x Mouse
+  \item 1-2 x USB Joystick
+  \item 1 x SpaceMouse Pro
+  \item 1 x Ubiquiti Rocket M2 Wireless Router
+  \end{itemize}
+\item Software / OS / Libraries
+  \begin{itemize}
+  \item Ubuntu 16.04 LTS
+  \item ROS Kinetic
+  \item Python 2.7
+  \item Additional Python Libraries
+    \begin{itemize}
+    \item PyQt5
+    \item inputs
+    \item PyGame
+    \item spnav
+    \item cv2
+    \item Pillow
+    \item qimage2ndarray
+    \end{itemize}
+  \end{itemize}
+\end{itemize}
+
+
+\subsection{Stakeholder Concerns}
+\subsubsection{Reliability}
+The ground control software must be as reliable as possible.
+The rover operator must be able to complete all competition tasks, assuming all hardware on the Rover is functioning properly.
+If unable to do so, the software cannot be considered a success.
+\subsubsection{Robustness}
+The University Rover Challenge requires that the rover operate successfully in a variety of environments.
+For example, it is expected that as the rover advances through the course, range and obstacles will negatively effect the latency and bandwidth of the wireless Ethernet connection used to communicate with the rover.
+In the above example, the rover must be able to downgrade the video feed in order to accommodate the lowered communication abilities of the rover.
+\subsubsection{Rapid Prototyping}
+In order to fulfill the necessary reliability and robustness requirements of the client, the team must be able to rapidly prototype the software.
+Rapid prototyping allows the team to maximize testing time.
+\subsubsection{Documentation}
+The client has requested that documentation be a primary concern of the project.
+The ground control software will be used as a foundation for future rover competitions, therefore it is important that the software is easy to use and the code is easy to understand.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/5_component_design.tex

@@ -0,0 +1,15 @@
+\input{5_component_design_1.tex}
+\input{5_component_design_2.tex}
+\input{5_component_design_3.tex}
+\input{5_component_design_4.tex}
+\input{5_component_design_5.tex}
+\input{5_component_design_6.tex}
+\input{5_component_design_7.tex}
+\input{5_component_design_8.tex}
+\input{5_component_design_9.tex}
+
+
+
+
+
+

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/5_component_design_1.tex

@@ -0,0 +1,26 @@
+\subsection{Human Interface Device Integration}
+\subsubsection{Overview}
+During use of this ground station software, the user will need to be able to interact with a joystick(s) and SpaceNav mouse to control ground station software elements, to drive the Rover, and to manipulate the Rover arm.
+The systems that integrate with these HID devices will be some of the most active parts of the ground station software.
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{Control Latency:} Latency for these control inputs must be kept to a minimum to ensure that the Rover responds quickly to control commands and that motion is fluid.
+\item \textit{Reliability:} As these control inputs can directly control the Rover, the code must be reliable, robust, and be able to recover from errors such as a disconnect and reconnect of a joystick.
+\item \textit{Flexibility:} It is hard to determine the best possible control scheme for the Rover via these control inputs until the team has had a chance to physically drive the robot, so having the flexibility to easily change the control structure is important.
+Additionally, these input devices may change completely if they are determined to be inadequate in real-world tests later on.
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item The HID integrators will use the \texttt{inputs} or \texttt{pygame} libraries for joysticks or the \texttt{spnav} library for the SpaceNav mouse.
+\item Each integrator will be housed within a QThread class that will monitor the state of the HID devices and poll the devices for changes.
+\item Upon a device change, the class will broadcast the updates using QSignals so that other parts of the program may use the data.
+\item Upon an HID failure, such as on accidental disconnect, the class will attempt to reconnect and broadcast an error state until it is resolved.
+\end{itemize}
+
+\subsubsection{Design Rationale}
+One of the main goals of this project is to be able to rapidly prototype the software so the Rover team can spend more time testing, and less time waiting for code to be written.
+By using off the shelf libraries for reading in joystick and SpaceNav mouse input, our team's development time can be better put to use making the control systems robust and handling error cases.
+As these are commonly used and tested libraries, there is also a high likelihood that their implementations are more reliable and documented than if our design team were to try and implement equivalent libraries/classes ourselves.
+The use of QT's QSignals will also help us in this regard by minimizing the design time needed to write custom inter-thread communication protocols. 

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/5_component_design_2.tex

@@ -0,0 +1,30 @@
+\subsection{Drive Coordinator}
+\subsubsection{Overview}
+This sub-system will handle taking in raw joystick(s) control information, and transforming them into usable drive control commands.
+This will also handle the interpretation of button presses on the joystick to control GUI functions, or for example, artificially limiting the Rover max speed via the current state of the joystick throttle lever.
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{Reliability:} This node must be incredibly reliable.
+If the software runs off and sends continuous drive commands, for example, the physical Rover will be driving out of control.
+\item \textit{Speed:} As this node is what is sending drive commands, any major processing delays here will make driving the Rover a choppy, unresponsive, and unpleasant experience.
+\item \textit{Pause State Responsiveness:} When the pause button is pressed, the Rover will need to stop all movement quickly.
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item The coordinator will take in joystick control information via QSignals.
+\item The coordinator will send Rover drive commands via a ROS topic using \texttt{rospy}.
+\item The coordinator will artificially limit the max drive speed sent to the Rover through limiting with the throttle lever on the joystick.
+\item The coordinator will stop sending drive commands when it detects a joystick button press putting it in the paused state.
+It will then start sending commands again when brought out of the pause state.
+\item If using two joysticks to drive, instead of one, the coordinator will calculate the joystick differential to determine and send the correct drive command. 
+\end{itemize}
+
+\subsubsection{Design Rationale}
+The use of QT's QSignals for receiving of the joystick control commands will help alleviate inter-thread communication design time, allowing our team to focus on the more important aspects of the coordinator.
+Sending drive commands via the \texttt{rospy} package allows us to natively integrate with the ROS control stack.
+This is ideal because it allows the Rover Software team to use native navigation and motion planning packages to control the Rover, and the ground station software will fit the expected protocols that those packages use.
+By having the drive coordinator handle limiting the max speed allowed to be sent to the Rover, we can guarantee that the Rover will never drive faster than intended.
+If we had instead made the coordinator send two commands, one with the drive command, and one that was a speed limit, there is the possibility that the speed limit command could get lost in transit to the Rover.
+This same idea can also be applied to the pause state in that simply stopping commands from being sent is more reliable than sending a remote pause command to the Rover.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/5_component_design_3.tex

@@ -0,0 +1,34 @@
+\subsection{Mapping System}
+\subsubsection{Overview}
+The mapping sub-system will handle the storing and loading of maps of the competition area as well as plotting important landmarks as provided by the user.
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{Offline Use:} As this software will primarily be used in environments where there are no Internet connections, the mapping sub-system will need to be able to store local maps of the desired competition areas in advance.
+\item \textit{Zoom Options:} During competition, the user may desire to zoom in or out on any particular area. 
+The software will have to accommodate this by either digitally zooming into an the desired area, or by loading newer high-resolution images at a adjusted zoom level.
+\item \textit{Location Services:} The mapping system must accurately show where the rover is on the map so that the operator is able to keep track of it.
+Furthermore the mapping must also allow the setting of way-points.
+These way-points allow the operator to set a location that the rover will travel to once set.
+\item \textit{Reliability:} The mapping system will be one of the most used aspects of the ground station software as it will be used for properly navigating the Rover to competition way-points. 
+If the mapping system fails, it may be near impossible for the user to determine where the Rover should be driven.
+\item \textit{Responsiveness:} Outside of the drive and video sub-systems, the mapping system will be one of the most frequently updated and used features on the ground station software.
+In order for it to be useful to the user the map updates must be fast and responsive so that the user is not spending valuable competition time waiting for the map to load.
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item The mapping system will load satellite imagery of the desired area via the Google Maps API.
+\item The Google Maps tiles will be cached so they can be used offline.
+\item Individual image tiles will be stitched together into one large image to be shown in the GUI using either OpenCV or Pillow.
+\item The map will have icons and/or numbers overlaid on the map image corresponding to the Rover location, navigation way-points, and landmark way-points.
+\item The aforementioned markers will be accurate on the map based on their GPS positions.
+\item The map will show a trail of the Rover's previous driving path that fades away over time.
+\item The map will have a faint grid showing latitudinal and longitudinal divisions.
+\end{itemize}
+
+\subsubsection{Design Rationale}
+The choice of the Google Maps API allows us to use the most up-to-date and readily available maps of the competition area easily.
+Google Maps has some restrictions placed upon it's use in robots, but do not apply to this system.
+OpenCV and Pillow are both fast and well-documented frameworks for dealing with image data, and are especially good at fast image stitching.
+The other design aspects of the mapping system should make the map view easy and intuitive to use, meaning less training will be necessary before a user will understand it.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/5_component_design_4.tex

@@ -0,0 +1,25 @@
+\subsection{Way-points Coordinator}
+\subsubsection{Overview}
+The way-point coordinator will handle the storing, editing, and displaying of the way-points that the user will be placing for the rover.
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{Accuracy:} As the coordinator will be controlling the rover when a user is not presently using the HID's. The accuracy is important to reach some points correctly and within a certain distance.
+\item \textit{Queue Order:} As the coordinator is sending out the values to the drive coordinators, if the order of way-points are off, an incorrect path might be taken.
+\item \textit{Queue Editing:} The way-point coordinator needs some way of editing values to allow for user mistakes. Humans are imperfect and might enter something wrong or have done something wrong and might need to fix it.
+\item \textit{Queue Deletion:} Users might need to remove a way-point from a queue to allow for more user flexibility and sudden changes to the system.
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item The system will access the Mapping system to control and place any way-points.
+\item The system will likely be built using a linked-list of nodes that contain information for the rover.
+\item Adding a way-point to the queue can be like clicking on the visual map in the program or entering GPS coordinates via pop-up or input space in the GUI
+\item Editing a way-point could be clicking on the way-point and then editing the values that are displayed.
+\item Deleting a way-point might be clicking a visual list of points and then confirming the action.
+\end{itemize}
+
+\subsubsection{Design Rationale}
+The design of this coordinator revolves around the idea of a linked list version of a queue.
+The rover must be traveling in the order of way-points created.
+This is important for the competition in May where way-points are used to control the rover in a few events.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/5_component_design_5.tex

@@ -0,0 +1,26 @@
+\subsection{Arm Visualizer}
+\subsubsection{Overview}
+The arm visualizer will allow the user to quickly and easily view and understand where the joints on the Mars Rover arm are at any given time.
+As the arm is moved, these visual indicators will update to show the new arm positions.
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{Viewing Simplicity:} The indicators need to be visually displayed in such a way that the user instinctively understands what the data means.
+\item \textit{Responsiveness:} In order to be useful, the indicators will need to update quickly.
+During competition, the user will use these indicators to position the arm, and major delays in updating these will make them unpleasant to use.
+\item \textit{Clutter:} As there are many competition events where the arm will not be needed, these visualizations should be able to be disabled so that there is not unnecessary clutter and information on-screen when it is not needed.
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item The arm visualizer will take in position information via a ROS topic using \texttt{rospy}.
+\item The arm visualizer will, in the initial version, show this information in native QT GUI elements such as a QGraphicsView or QPixmap embedded in a QLabel.
+\item The arm visualizer will black out the unneeded visual elements when the arm is not presently attached to the Rover.
+\item In the event there is spare time, the previous visualizations will be replaced with a 3D visualization of the Rover through ROS' RVIZ tool, where the position changes accurately correspond to movement changes on the model. 
+\item If the previous option is not attainable, the visualizer will attempt to be replaced with a custom OpenGL widget containing the 3D view of the Rover arm, and like previously, will update the model to match the current arm position.
+\end{itemize}
+
+\subsubsection{Design Rationale}
+By taking in position information through ROS topics with \texttt{rospy}, we will be able to avoid having to write a custom network message system to provide and interpret this data from the Rover, which would have been a tedious and error prone process.
+Using native QT widgets, at least for the initial version, will mean that we can more quickly get the pertinent information into a display format that can be understood. 
+The QGraphics view widget in particular will let us draw a scene in a painting environment, and then manipulate the scene to show a arrow moving around a circle for example, with relative ease.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/5_component_design_6.tex

@@ -0,0 +1,27 @@
+\subsection{Arm Coordinator}
+\subsubsection{Overview}
+This sub-system will handle taking in raw SpaceNav mouse control information and transforming them into usable arm control commands.
+This will also handle the interpretation of button presses on the SpaceNav mouse to control GUI functions, for example, panning the map around.
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{Reliability:} This node must be incredibly reliable.
+If it runs off and sends continuous arm commands, for example, the physical Rover arm will also be out of control.
+\item \textit{Speed:} As this node is what is sending arm commands, any major processing delays here will make controlling the Rover arm a choppy and unpleasant experience.
+\item \textit{Pause State Responsiveness:} When the pause button is pressed on the joystick, the Rover will need to stop all movement quickly.
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item The coordinator will take in SpaveNav control information via QSignals.
+\item The coordinator will send Rover arm commands via a ROS topic using \texttt{rospy}.
+\item The coordinator will stop sending arm commands when it detect a joystick button press putting it in the paused state.
+It will then start sending commands again when brought out of the pause state.
+\end{itemize}
+
+\subsubsection{Design Rationale}
+The use of QT's QSignals for receiving of the SpaceNav control commands will help alleviate inter-thread communication design time, allowing our team to focus on the more important aspects of the coordinator.
+Sending arm commands via the \texttt{rospy} package allows us to natively integrate with the ROS control stack.
+This is ideal because it allows the Rover Software team to use native arm movement and motion planning packages to control the Rover arm, and the ground station software will fit the expected protocols that those packages use.
+By having the arm coordinator node handle stopping sending control commands to the Rover, we can guarantee that the arm won't continue moving if commands stop getting sent, such as in the pause state.
+If the Rover itself had to determine whether to move or not via a sent pause command, the arm could potentially still move if that external pause command were lost.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/5_component_design_7.tex

@@ -0,0 +1,29 @@
+\subsection{Video Coordinator}
+\subsubsection{Overview}
+The video coordinator will handle taking in video stream data from the Rover, and displaying that data on the GUI.
+It will also handling telling the Rover what resolution and potentially bit-rate the ground station would like from a particular camera.
+Lastly, it will handle switching which video streams are showed in each of the three video display areas on the GUI, including the ability to switch off the secondary/tertiary displays.
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{Reliability:} The live video streams are a necessity to be able to remotely operate the Rover for most competition events. 
+If the video streams are not functioning, the Rover will do very poorly in competition.
+\item \textit{Processing Time:} As the video streams will be used the drive the Rover remotely, processing delays should be kept to an absolute minimum so that the driving experience feels more fluid.
+\item \textit{Resolution Change Detection:} The user should not have to manually change resolutions if a video that was on the primary video window is switched to the secondary or tertiary window.
+This does not apply if the user overrides the resolution settings in order to get smoother video during times of poor radio reception.
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item The video coordinator will use \texttt{rospy} to retrieve compressed video data streams from the Rover.
+\item The video coordinator will format the video data in a way that it can be displayed on a QLabel as an embedded QPixmap.
+\item The video coordinator will automatically send resolution adjustment commands to the Rover over a ROS topic as the video streams are switched between the primary and secondary/tertiary video windows.
+\item The video coordinator will automatically handle adjusting the video data so it can be properly shown in the QLabel, even after a resolution adjustment.
+\item The video coordinator will handling blanking out the secondary/tertiary video displays and stop processing the underlying video if a user requests it.
+\end{itemize}
+
+\subsubsection{Design Rationale}
+By using ROS' built-in compressed video streams, and the accompanying \texttt{rospy} libraries for interpreting this video data, our team can focus on the logistics of showing these videos on the GUI.
+By handling automatic resolution adjustment, we are simplifying the tasks the user will have to perform during competition.
+The automatic adjustments also help alleviate unnecessary network bandwidth for streams that would not benefit from the higher resolution. 
+Automatic adjustments will both lower latency and allow the Rover to have to process less data, which are both positives in a remote, battery-powered environment.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/5_component_design_8.tex

@@ -0,0 +1,26 @@
+\subsection{Statuses Coordinator}
+\subsubsection{Overview}
+The statuses coordinator will be tasked with handling all the miscellaneous messages being sent to the ground station from the Rover.
+It will take in these messages and route them to GUI elements for display.
+This will include information such as Rover battery level, raw GPS data for the mapping sub-system, and whether sub-components of the Rover are connected, such as the arm.
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{Minimal Overhead:} As most of these messages are non-critical, it is important for this coordinator to keep its resource usage low so that the processing power is available for other ground station functions.
+\item \textit{Fast Navigational Updates:} Since navigational updates will be part of these messages, it will be important for these messages to be prioritized for updates to GUI elements such as the compass and speed indicators.
+\item \textit{Adequate Warnings:} It will be important that this coordinator provides noticeable warnings, potentially through methods such as flashing indicators, when there are problems with Rover systems that it has received a message about.
+Depending on the warning, a low battery for example, it could be the difference between the Rover winning or losing a competition event.
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item The statuses coordinator will take in Rover status messages via ROS topics using \texttt{rospy}.
+\item The statuses coordinator will update any necessary GUI elements such as QLabels with their pertinent formatted information as received via the ROS messages.
+\item The statuses coordinator will prioritize any updates to GPS and navigation messages so that the user can more easily drive the Rover.
+\item The statuses coordinator will brightly flash GUI elements that it feels the user needs to pay attention to, and allow the user to cancel the warning by clicking on the GUI element.
+\end{itemize}
+
+\subsubsection{Design Rationale}
+By using ROS topics to handle messages from the Rover to the GUI, our team is able to spend that time working on quickly showing these updates instead of creating custom network message protocols.
+Prioritizing updates to the navigation GUI elements when performing updates will help the user driving the Rover more reliably understand what the Rover is doing movement-wise, which is more important than secondarily important messages such as battery voltage.
+By flashing GUI elements in bright colors, and allowing users to cancel these warnings, we are bringing the proper amount of attention to messages that need it while not being obnoxious and having these warning continue indefinitely.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/5_component_design_9.tex

@@ -0,0 +1,23 @@
+\subsection{Logging / Recording Coordinator}
+\subsubsection{Overview}
+Recording and logging information is very important for monitoring the rover's status and re-run how a rover was performing during some set period.
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{Storage Space:} With all the video/recording the system is going to do, the space might be limited on the system or on the rover.
+\item \textit{Video Bitrate:} The video should be recorded in a quality that is independent of the streaming video stream to allow full video quality when retrieved
+\item \textit{Storage Format:} With the variable size of log files, some settings might be necessary to control logging location, size, or type. 
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item The coordinator will take any information from the rover as a stream of information.
+\item The coordinator will store any video stream that the rover sends back to save back on overhead on the rover.
+\item The rover will not be saving any files to allow for overhead and processing.
+\end{itemize}
+
+\subsubsection{Design Rationale}
+The rover is going to be overloaded with calculations and trans-coding, so the ground station should be able to offload any extra computation onto it.
+The ground control system will take care of storing information like log files in session logs.
+There is an inbuilt system using ROS that makes a bag that can be used to log everything.
+

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/6_user_interface_design.tex

@@ -0,0 +1,89 @@
+\subsection{Left Screen}
+\subsubsection{Mock-up}
+\vspace{1em}
+\begin{minipage}{\linewidth}
+  \begin{center}
+  \includegraphics[width=0.75\linewidth]{left_screen_svg}
+  \captionof{figure}{Left Screen Mock-up}
+  \end{center}
+\end{minipage}
+
+\subsection{Zones}
+\subsubsection{1: System Statuses / Sensor Readings}
+This section will display all status and sensor data both from the Rover and about the ground station itself.
+This includes items such as radio signal strength, GPS accuracy, and whether the Ground Station has connection to the drive joystick/s and SpaceNav mouse device.
+
+\subsubsection{2: Map Display}
+The map display will display a satellite view of the competition areas with navigation and land-mark way-points, the Rover, and the Rover movement trail overlaid.
+
+\subsubsection{3: Recording / Logging / Settings}
+This section will be a tabbed grouping that by default will show the controls for starting ROS bag recordings, but will also have a second tab for live logs and a third tab for settings that adjust items such as which map is being shown.
+
+\subsubsection{4: Way-point Entry / Autonomy Controls}
+This block will allow for manual entry of GPS coordinates, as are provided by the competition at the beginning of some events.
+The user will be able to choose whether the entry is being added as a navigation or landmark way-point as well as using the entry fields to edit the way-points from pre-entered points.
+
+
+\subsubsection{5: Navigation Way-points Listing}
+This area will list, in order, the navigation way-points that the system is currently set to follow, both for manual driving and for the autonomy portion.
+
+\subsubsection{6: Landmark Way-points Listing}
+This will list, in the order they were added, the landmark way-points that the user has entered to make important points on the competition field.
+
+\subsection{Layout Rationale}
+This display shows most of the information regarding the Rover that does not need to be viewed while the Rover is being actively driven, or while the arm is being moved.
+When the software starts and is first connecting to the Rover, the user will spend some time studying system statuses, entering way-points, changing settings, and checking logs if needed.
+Once they are done with these initial checks and entries, most of the rest of the control experience will take place on the right hand monitor.
+In the case that the user wants to quickly glance at the map while they are driving, the map will come in to view easily as it is as close to the right hand monitor as it can be.
+As the logging and setting views will hopefully not need to be viewed very often, combining them onto a tabbed GUI element helps reduce used space while still leaving them accessible when needed.
+
+
+\subsection{Right Screen}
+\subsubsection{Mock-up}
+\vspace{1em}
+\begin{minipage}{\linewidth}
+  \begin{center}
+  \includegraphics[width=0.75\linewidth]{right_screen_svg}
+  \captionof{figure}{Right Screen Mock-up}
+  \end{center}
+\end{minipage}
+
+\subsection{Zones}
+\subsubsection{1: Arm Visualization}
+This visualization area will show the joint positions of the Rover arm when the arm is attached.
+In its simplest form, the visualization will be a simple line drawn in a reference frame, that adjusts its position as the arm is moved.
+For this version, each joint would have its own visualization box.
+If there is enough time, our team will attempt to integrate with RVIZ, the ROS visualization package, to show a 3D view of the arm moving.
+If the RVIZ solution does not seem feasible and there is still extra time, we may alternatively try to implement a custom OpenGL view of the arm.
+
+\subsubsection{2: Primary Video Display}
+This will show the stream from the camera on the Rover is currently selected as the primary video stream.
+
+
+\subsubsection{3: Heading Compass}
+This heading compass will dynamically rotate to match the current heading of the Rover.
+It will also mark on the compass edge the currently active way-point, making it easy for the user driving the Rover to determine which direction they need to turn to line up with a way-point marker.
+
+
+\subsubsection{4: Speed and Speed Limit Display}
+This area will show the current Rover speed is meters per second as is reported by the Rover GPS.
+Additionally, it will also show the current speed limit of the Rover from zero to one hundred percent as has been limited by the user via the joystick throttle lever.
+
+
+\subsubsection{5: Secondary Video Display}
+This area will show the stream from the camera on th Rover that is currently selected as the secondary video stream.
+This stream has the capability to be disabled and show a placeholder image if the team needs to save on radio bandwidth.
+
+
+\subsubsection{6: Tertiary Video Display}
+This area will show the stream from the camera on th Rover that is currently selected as the tertiary video stream.
+This stream has the capability to be disabled and show a placeholder image if the team needs to save on radio bandwidth.
+
+
+\subsection{Layout Rationale}
+This screen will be showing the most commonly looked at data for the user driving the Rover.
+During a normal competition, the user will start by entering way-points to drive the Rover to, and then switch to the joystick(s) and SpaceNav mouse.
+Once they start driving, the user will be heavily focused on monitoring video data to make sure they do not run the Rover into anything. 
+While driving to the way-points to get to an end location, the user will be able to easily see the compass indicator, with a marker for the direction they should be heading.
+After arriving at an ending way-point, the user can then seamlessly transition to moving the Rover arm (for competition challenges where this is the case) and watching the visualization update on the same screen as the video of the arm moving.
+By laying out these particular elements on this screen, the user will be less likely to have to look at the left screen except when the Rover is not moving.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/7_conclusion.tex

@@ -0,0 +1,3 @@
+Throughout this document, we have covered the design considerations, component design, and GUI design for the Mars Rover ground station software that our team will be implementing.
+By following the design guidelines laid out in this document over the next five months, we are confident that our team will be able to accomplish the desired state of the Mars Rover ground station software.
+In doing so, not only will we be delivering to our client a useful and robust front-end to the Mars Rover for the competition next June, but also hopefully a base to work off of for many years into the future.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/bibliography.bib

@@ -0,0 +1,5 @@
+@online{
+	urc_competition_rules,
+	title="University Rover Challenge Rules 2018",
+    url="http://urc.marssociety.org/files/University%20Rover%20Challenge%20Rules%202018.pdf"
+}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/latexmkrc

@@ -0,0 +1,31 @@
+# This config is copied from overleaf so output there will match compiled output here
+
+# support for the glossaries package:
+add_cus_dep('glo', 'gls', 0, 'makeglossaries');
+add_cus_dep('acn', 'acr', 0, 'makeglossaries');
+sub makeglossaries {
+  system("makeglossaries \"$_[0]\"");
+}
+
+# support for the nomencl package:
+add_cus_dep('nlo', 'nls', 0, 'makenlo2nls');
+sub makenlo2nls {
+  system("makeindex -s nomencl.ist -o \"$_[0].nls\" \"$_[0].nlo\"");
+}
+
+# from the documentation for V. 2.03 of asymptote:
+sub asy {return system("asy \"$_[0]\"");}
+add_cus_dep("asy","eps",0,"asy");
+add_cus_dep("asy","pdf",0,"asy");
+add_cus_dep("asy","tex",0,"asy");
+
+# metapost rule from http://tex.stackexchange.com/questions/37134
+add_cus_dep('mp', '1', 0, 'mpost');
+sub mpost {
+  my $file = $_[0];
+  my ($name, $path) = fileparse($file);
+  pushd($path);
+  my $return = system "mpost $name";
+  popd();
+  return $return;
+}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/design_document/makefile

@@ -0,0 +1,19 @@
+# Makefile created by Corwin Perren
+# Generic makefile for all LaTeX projects downloaded from overleaf
+# 
+# All this makefile does is call perl against latexmkrc, which is
+# the latex equivalent of make
+
+LATEXMK_COMPILE_FLAGS = -cd -pdf 0_design_document.tex
+LATEXMK_CLEAN_FLAGS = -c
+
+.DEFAULT_GOAL := all
+
+all: latexmk_output clean
+
+latexmk_output: 
+	perl latexmk.pl $(LATEXMK_COMPILE_FLAGS)
+	mv 0_design_document.pdf design_document.pdf
+
+clean:
+	perl latexmk.pl $(LATEXMK_CLEAN_FLAGS)

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/goals/goals.tex

@@ -0,0 +1,13 @@
+\section{Goals}
+The summary of goals for the the Mars Rover Ground Station project are as follows:
+
+\begin{itemize}
+\item Create a stable, dual-monitor, full-screen GUI that runs on an Ubuntu 16.04 computer.
+\item In the GUI, display video streams, Rover arm joint positions, and status information from the Rover.
+\item Also in the GUI, provide a user-interactable map that includes the ability to plot and edit multiple kinds of way-points.
+\item Provide control elements to enable the Rover's autonomous mode for the appropriate event during the URC competition.
+\item Via various user input devices, allow the user to remotely drive and control the arm on the Rover.
+\item Maintain software stability even when radio systems are dropping packets or completely disconnecting and reconnecting.
+\item Keep the GUI intuitive enough that the user can focus on performing competition tasks rather than fighting the ground station software.
+\item Provide enough documentation so that future Rover years may more easily build off of the code foundation.
+\end{itemize}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/interesting_code/interesting_code.tex

@@ -0,0 +1,90 @@
+\lstset{ %
+  backgroundcolor=\color{white},   % choose the background color
+  basicstyle=\footnotesize,        % size of fonts used for the code
+  breaklines=true,                 % automatic line breaking only at whitespace
+  captionpos=b,                    % sets the caption-position to bottom
+  commentstyle=\color{gray},       % comment style
+  escapeinside={\%*}{*)},          % if you want to add LaTeX within your code
+  keywordstyle=\color{blue},       % keyword style
+  stringstyle=\color{purple},      % string literal style
+}
+
+\section{Interesting Code}
+\subsection{Drive Test}
+\subsubsection{Code}
+\begin{lstlisting}[language=python]
+class DriveTest(QtCore.QThread):
+    def __init__(self):
+        super(DriveTest, self).__init__()
+
+        self.not_abort = True
+
+        self.message = None
+        self.publisher = rospy.Publisher("/cmd_vel", Twist, queue_size=10)
+
+        rospy.init_node("test")
+
+    def run(self):
+        while self.not_abort:
+            self.message = Twist()
+
+            self.message.linear.x = 1.0
+            self.message.angular.z = 1.0
+
+            self.publisher.publish(self.message)
+
+            self.msleep(100)
+\end{lstlisting}
+
+\subsubsection{Description}
+This QThread example class starts a ROS publishing node on the "/cmd\_vel" topic to send raw drive control commands to the Rover.
+In this case, it is sending a command to drive the Rover forward and to the right, essentially causing it to drive in a never-ending circle.
+
+\subsection{Video Test}
+\subsubsection{Code}
+\begin{lstlisting}[language=python]
+class VideoTest(QtCore.QThread):
+    image_ready_signal = QtCore.pyqtSignal()
+
+    def __init__(self, screen_label, video_size=None, sub_path=None):
+        super(VideoTest, self).__init__()
+
+        self.not_abort = True
+
+        self.screen_label = screen_label
+        self.video_size = video_size
+
+        self.message = None
+        self.publisher = rospy.Subscriber(sub_path, CompressedImage, self.__receive_message)
+
+        self.raw_image = None
+        self.cv_image = None
+        self.pixmap = None
+        self.bridge = CvBridge()
+
+        self.image_ready_signal.connect(self.__on_image_update_ready)
+
+    def run(self):
+        while self.not_abort:
+            if self.raw_image:
+                self.cv_image = self.bridge.compressed_imgmsg_to_cv2(self.raw_image, "rgb8")
+
+                if self.video_size:
+                    self.cv_image = cv2.resize(self.cv_image, self.video_size)
+                    
+                self.pixmap = QtGui.QPixmap.fromImage(qimage2ndarray.array2qimage(self.cv_image))
+                self.image_ready_signal.emit()
+            self.msleep(20)
+
+    def __on_image_update_ready(self):
+        self.screen_label.setPixmap(self.pixmap)
+
+    def __receive_message(self, message):
+        self.raw_image = message
+\end{lstlisting}
+\subsubsection{Description}
+This example subscribes to the ROS topic that is passed in under the sub\_path argument in order to get video stream data.
+An example of this topic might be "/cam1/usb\_cam1/image\_raw/compressed".
+Inside of the body of the thread, it checks if there is image data, and if so decompresses it into a raw 8-bit image using ROS's OpenCV bridge libraries.
+Finally, it converts the OpenCV image into a QImage and then into a QPixmap before broadcasting an update signal so the main GUI thread can show the image on the QLabel.
+It is important to note that any direct GUI updates must happen in the main GUI thread, otherwise the QApplication will crash.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/latexmkrc

@@ -0,0 +1,31 @@
+# This config is copied from overleaf so output there will match compiled output here
+
+# support for the glossaries package:
+add_cus_dep('glo', 'gls', 0, 'makeglossaries');
+add_cus_dep('acn', 'acr', 0, 'makeglossaries');
+sub makeglossaries {
+  system("makeglossaries \"$_[0]\"");
+}
+
+# support for the nomencl package:
+add_cus_dep('nlo', 'nls', 0, 'makenlo2nls');
+sub makenlo2nls {
+  system("makeindex -s nomencl.ist -o \"$_[0].nls\" \"$_[0].nlo\"");
+}
+
+# from the documentation for V. 2.03 of asymptote:
+sub asy {return system("asy \"$_[0]\"");}
+add_cus_dep("asy","eps",0,"asy");
+add_cus_dep("asy","pdf",0,"asy");
+add_cus_dep("asy","tex",0,"asy");
+
+# metapost rule from http://tex.stackexchange.com/questions/37134
+add_cus_dep('mp', '1', 0, 'mpost');
+sub mpost {
+  my $file = $_[0];
+  my ($name, $path) = fileparse($file);
+  pushd($path);
+  my $return = system "mpost $name";
+  popd();
+  return $return;
+}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/makefile

@@ -0,0 +1,18 @@
+# Makefile created by Corwin Perren
+# Generic makefile for all LaTeX projects downloaded from overleaf
+# 
+# All this makefile does is call perl against latexmkrc, which is
+# the latex equivalent of make
+
+LATEXMK_COMPILE_FLAGS = -pdf
+LATEXMK_CLEAN_FLAGS = -c
+
+.DEFAULT_GOAL := all
+
+all: latexmk_output clean
+
+latexmk_output: 
+	perl latexmk.pl $(LATEXMK_COMPILE_FLAGS)
+
+clean:
+	perl latexmk.pl $(LATEXMK_CLEAN_FLAGS)

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/problems_solutions/problems_solutions.tex

@@ -0,0 +1,9 @@
+\section{Problems / Solutions}
+\subsection{Time Scheduling}
+Due to the busy schedules of our group members, the client, and our TA, it was initially hard finding times to schedule meetings.
+We solved this problem very simply by changing to remote, virtual meetings, which provided enough flexibility for all parties to find times that overlapped. 
+
+\subsection{Requirements Changes}
+As the core design of the Rover is changing on a regular basis, maintaining a solid foundation of requirements has, at times, been difficult.
+Some expectations of the final design of the ground station software have not changed, but others like the user input methods have changed two or three times over the course of the term.
+This is ultimately a minimal problem that can be easily handled by making sure we keep our requirements documentation updated as these changes are made.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/progress/deliverables.tex

@@ -0,0 +1,59 @@
+\subsection{Deliverables}
+\subsubsection{Github Repository}
+Our group gained access to and set up directories in the Github repository for storing the group's ground station code and documentation.
+All documentation was put into this repository as it was started and/or completed.
+As our team has begun testing code, useful sections of it have been added to the repository for reference during future development of the full ground station software.
+
+\subsubsection{Problem Statement Document}
+A thorough problem statement document has been created by the group.
+The document helps to direct the group and gives a high level view of the scope and goals for the project going forward.
+Work on the document began on October 17th, a rough draft of this document was completed on October 10th and the final draft was completed and delivered to the client on October 20th.
+The problem statement was approved by the client via email on October 24th.
+
+\subsubsection{Requirements Document}
+The requirements document lays out tasks that have to be completed in order for the project to be considered successful.
+The document also includes a Gantt chart that serves as a rough time table and dependencies for each module that must be completed.
+By following this document and completing each task on time, the team can be sure to complete the software within the required timetable.
+Writing of the document began on October 26th.
+A rough draft was completed on October 27th and a final version of the requirements document was delivered to the client for review on November 3rd.
+The client officially approved the requirements document on November 3rd.
+
+\subsubsection{Technology Review Documents}
+The technology review documents serve as research for the technologies required to complete the project successfully.
+Three documents were created, one by each member of the team.
+The documents review technologies for the following aspects: 
+
+\vspace{1em}
+\begin{tabular}{| p{0.3\linewidth} | p{0.3\linewidth} | p{0.3\linewidth} |}
+% Table headings
+\hline\bf Corwin Perren & \bf Chris Pham & \bf Ken Steinfeldt \\\hline
+
+
+\begin{itemize}
+\item Robotics Framework
+\item Communication Technologie\-s
+\item Joysticks
+\end{itemize}
+
+&
+\begin{itemize}
+\item Application/GUI Framewor\-ks
+\item Arm Visualization
+\item Mapping
+\end{itemize}
+
+&
+\begin{itemize}
+\item Operating Systems
+\item Hardware
+\item Ground Station Deployment
+\end{itemize}\\\hline
+\end{tabular}
+\vspace{1em}
+
+Each team member's technology review was completed by November 21st.
+
+\subsubsection{Software Design Document}
+The Software Design Document (SDD) serves as a comprehensive plan for project completion, supplying an in-depth review of the requirements and plans to fulfill them.
+Work began on the SDD on November 30th and the document was completed on December 1st. 
+The SDD has not yet been submitted to the client for review and approval but will be in the near future.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/progress/progress.tex

@@ -0,0 +1,4 @@
+\section{Progress}
+\input{progress/summary}
+\input{progress/deliverables}
+\input{progress/weekly_progress}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/progress/summary.tex

@@ -0,0 +1,14 @@
+\subsection{Summary}
+The primary focus for the last ten weeks has been design and preparation for the ground station project.
+In preparing the required documents and submitting the completed documents to our client we, also ensure that the team and the client are in agreement about the development of the ground station software.
+Each document is built on the previous document as the team and client have developed a more thorough understanding of the requirements of the software that we will produce.
+First, the problem statement laid out a broad understanding of what the problem to be solved was, helping to focus the scope of the project.
+By defining the problem to be solved, our team was able to write the requirements document.
+The requirements document states what solutions are needed in order to accomplish the problems previously defined in the problem statement.
+With the requirements defined the team was able to research the best tools available to fulfill the stated requirements.
+The technology review lays out several possible tools available, each able to fulfill a requirement.
+The research required in order to complete the technology review allowed the team to not only attain a better grasp on technological problems, likely to present themselves during development, but also to choose tools that will be used as development progresses.
+With all of the previous documents written the team was able to put together a comprehensive design document that will serve to guide development.
+In addition to the creation of the necessary design documents, the team also gained access to the repository that will retain the development code.
+All work completed in the last ten weeks accomplishes one overarching task, that is, laying the foundation for the project.
+Going forward, the foundation we have created will ensure that our team and the client are on the same page, the project is completed to the specifications required by our client, and the project is completed in a timely manner.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/progress/weekly_progress.tex

@@ -0,0 +1,161 @@
+\subsection{Weekly Progress Breakdown}
+\subsubsection{Week 1}
+\begin{itemize}
+\item Activities
+  \begin{itemize}
+  \item Individually submitted preferences for capstone projects
+  \item Corwin contacted OSURC stakeholder to request himself and Chris Pham be on the project
+  \end{itemize}
+  
+\item Problems / Solutions
+  \begin{itemize}
+  \item None
+  \end{itemize}
+\end{itemize}
+
+
+\subsubsection{Week 2}
+\begin{itemize}
+\item Activities
+  \begin{itemize}
+  \item Were assigned project groups
+  \item Socialized as a group to meet each other, including exchanging contact info
+  \item Made plans to contact client for an introductory meeting
+  \item Were added to the Mars Rover team's Slack channel and Github
+  \end{itemize}
+  
+\item Problems / Solutions
+  \begin{itemize}
+  \item None
+  \end{itemize}
+\end{itemize}
+
+
+\subsubsection{Week 3}
+\begin{itemize}
+\item Activities
+  \begin{itemize}
+  \item The group had a virtual meeting with the client to cover the project requirements
+  \item We worked on and completed our individual rough drafts of the problem statement document
+  \item Initial research was done on the potential tools and frameworks the team might be using
+  \item Communications began with the TA to set up weekly meeting times
+  \end{itemize}
+  
+\item Problems / Solutions
+  \begin{itemize}
+  \item Difficulty in scheduling a time to meet with the TA due to scheduling conflicts.
+  We ended up opting for a remote meeting to make scheduling a time easier.
+  Remote meetings have been successful and productive.
+  \end{itemize}
+\end{itemize}
+
+
+\subsubsection{Week 4}
+\begin{itemize}
+\item Activities
+  \begin{itemize}
+  \item We combined and edited our individual problem statement documents into a final draft
+  \item We emailed the problem statement to our client for approval
+  \end{itemize}
+  
+\item Problems / Solutions
+  \begin{itemize}
+  \item None
+  \end{itemize}
+\end{itemize}
+
+
+\subsubsection{Week 5}
+\begin{itemize}
+\item Activities
+  \begin{itemize}
+  \item The group had the first meeting with the TA
+  \item The group began work on the rough draft for the design requirements rough draft
+  \end{itemize}
+  
+\item Problems / Solutions
+  \begin{itemize}
+  \item None
+  \end{itemize}
+\end{itemize}
+
+
+\subsubsection{Week 6}
+\begin{itemize}
+\item Activities
+  \begin{itemize}
+  \item Had a group meeting with our TA
+  \item As a group, continued working on the requirements document rough draft until complete
+  \item Emailed our client the requirements document and made the edits he requested
+  \item Turned in the final draft and sent it to the client for approval
+  \end{itemize}
+  
+\item Problems / Solutions
+  \begin{itemize}
+  \item None
+  \end{itemize}
+\end{itemize}
+
+
+\subsubsection{Week 7}
+\begin{itemize}
+\item Activities
+  \begin{itemize}
+  \item Had a group meeting with our TA
+  \item As a group, determined how we would split up technologies for the individual tech review documents
+  \item We set up the initial hardware for the Mars Rover ground station in Graf 306
+  \end{itemize}
+  
+\item Problems / Solutions
+  \begin{itemize}
+  \item None
+  \end{itemize}
+\end{itemize}
+
+
+\subsubsection{Week 8}
+\begin{itemize}
+\item Activities
+  \begin{itemize}
+  \item Had a meeting with our TA
+  \item We all finished and turned in our rough drafts of the tech review documents
+  \item We peer reviewed another class member's tech review, and received revisions on our own
+  \item We got some initial example ground station code written that could display video stream and send minimal control commands
+  \end{itemize}
+  
+\item Problems / Solutions
+  \begin{itemize}
+  \item None
+  \end{itemize}
+\end{itemize}
+
+
+\subsubsection{Week 9}
+\begin{itemize}
+\item Activities
+  \begin{itemize}
+  \item We all finished and turned in final drafts of our edited tech review documents
+  \end{itemize}
+  
+\item Problems / Solutions
+  \begin{itemize}
+  \item None
+  \end{itemize}
+\end{itemize}
+
+
+\subsubsection{Week 10}
+\begin{itemize}
+\item Activities
+  \begin{itemize}
+  \item We had the final meeting of the term with our TA
+  future meetings will likely be scheduled at a different time.
+  \item We worked on, edited, completed, and turned in the final draft of our design document
+  \end{itemize}
+  
+\item Problems / Solutions
+  \begin{itemize}
+  \item None
+  \end{itemize}
+\end{itemize}
+

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/progress_report.tex

@@ -0,0 +1,149 @@
+\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
+\usepackage{graphicx}
+\graphicspath{{./figures/}}
+
+\usepackage{url}
+\usepackage{setspace}
+\usepackage{multicol}
+\usepackage{pdflscape}
+\usepackage{pdfpages}
+\usepackage[british]{babel}
+\usepackage{listings}
+\usepackage{xcolor}
+
+\usepackage{geometry}
+\geometry{textheight=9.5in, textwidth=7in}
+
+% \overfullrule=2in
+
+% 1. Fill in these details
+\def \CapstoneTeamName{			Ground Station Software Team}
+\def \CapstoneTeamNumber{		30}
+\def \GroupMemberOne{			Kenneth Steinfeldt}
+\def \GroupMemberTwo{			Christopher Pham}
+\def \GroupMemberThree{			Corwin Perren}
+\def \CapstoneProjectName{		OSU Robotics Club\\Mars Rover Ground Station}
+\def \CapstoneSponsorCompany{	OSU Robotics Club}
+\def \CapstoneSponsorPerson{	Nick McComb}
+
+
+
+%Personal \newcommands
+
+\newcommand{\functRequ}[4]{
+\item #1%
+\par
+\begin{itemize}
+\item \textit{Description:} #2.%
+\item \textit{Rationale:} #3.%
+\item \textit{Dependencies:} #4%
+\end{itemize}
+}
+\definecolor{backcolor}{rgb}{0.95,0.95,0.92}
+\lstset{basicstyle=\ttfamily,
+  backgroundcolor=\color{backcolor},  
+  showstringspaces=false,
+  commentstyle=\color{red},
+  keywordstyle=\color{blue},
+  columns=fullflexible,
+  breaklines=true,
+  postbreak=\mbox{\textcolor{red}{$\hookrightarrow$}\space},
+}
+
+
+% 2. Uncomment the appropriate line below so that the document type works
+\def \DocType{	%Problem Statement
+				%Requirements Document
+				%Technology Review
+				%Design Document
+				Progress Report
+			 }
+			
+\newcommand{\NameSigPair}[1]{
+  \par
+  \makebox[2.75in][r]{#1} 
+  \hfill
+  \makebox[3.25in]{
+      \makebox[2.25in]{\hrulefill} 
+      \hfill
+      \makebox[.75in]{\hrulefill}
+  }
+  \par\vspace{-12pt} 
+  \textit{
+      \tiny\noindent
+      \makebox[2.75in]{} 
+      \hfill
+      \makebox[3.25in]{
+          \makebox[2.25in][r]{Signature} 
+          \hfill
+          \makebox[.75in][r]{Date}
+      }
+  }
+}
+% 3. If the document is not to be signed, uncomment the command below
+\renewcommand{\NameSigPair}[1]{#1}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+\begin{titlepage}
+	\pagenumbering{gobble}
+	\begin{singlespace}
+		% 4. If you have a logo, use this includegraphics command to put it on the coversheet.
+        \begin{minipage}{7in}
+			\centering
+			\hspace*{-.7in}
+			$\vcenter{\hbox{\includegraphics[height=4cm]{Oregon_State_College_of_Engineering_Logo}}}$
+			\hspace*{.2in}
+			$\vcenter{\hbox{\includegraphics[height=2.5cm]{OSURCLogoOrange}}}$
+		\end{minipage}
+
+		\par\vspace{.35in}
+		\centering
+		\scshape{
+			\huge CS Capstone \DocType \par
+			{\large\today}\par
+			\vspace{.5in}
+			\textbf{\Huge\CapstoneProjectName}\par
+			\vfill
+			{\large Prepared for}\par
+			\Huge \CapstoneSponsorCompany\par
+			\vspace{5pt}
+			{\Large\NameSigPair{\CapstoneSponsorPerson}\par}
+			{\large Prepared by }\par
+			Group\CapstoneTeamNumber\par
+			% 5. comment out the line below this one if you do not wish to name your team
+			\CapstoneTeamName\par 
+			\vspace{5pt}
+			{\Large
+				\NameSigPair{\GroupMemberOne}\par
+				\NameSigPair{\GroupMemberTwo}\par
+				\NameSigPair{\GroupMemberThree}\par
+			}
+			\vspace{20pt}
+            \begin{abstract}
+			% 6. Fill in your abstract
+			This document contains the summary of the purpose and goals of the ground station software, the progress our team has made during the term, as well as problems and solutions to those problems we've encountered over the term. Additionally, it contains snippets of useful code and a retrospective on the work our team has done this term. Overall, this document provides a good overview of everything our team has accomplished over the Fall term.
+
+		\end{abstract}
+		}
+	\end{singlespace}
+\end{titlepage}
+\newpage
+\pagenumbering{arabic}
+\tableofcontents
+\clearpage
+
+% Write stuff here....
+\input{purpose/purpose}
+\input{goals/goals}
+\input{progress/progress}
+\input{problems_solutions/problems_solutions}
+\input{interesting_code/interesting_code}
+\input{retrospective/retrospective}
+
+\end{document}
+
+
+
+
+

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/purpose/purpose.tex

@@ -0,0 +1,6 @@
+\section{Purpose}
+The purpose of this project is to create ground station control software that will interface with the OSU Robotics Club's Mars Rover.
+This software will take in controls via user input devices such as joysticks, a SpaceNav mouse, as well as traditional keyboard and mouse in order to send remote control commands.
+These commands will allow a user to drive the Rover and control the Rover arm.
+Additionally, this software will allow for viewing of video streams and status information being sent back to the ground station from the Rover.
+The point of writing this software is to complete the package that is the Mars Rover competition robot so that it may compete in the University Rover Challenge taking place in June of 2018.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/fall_progress_report/retrospective/retrospective.tex

@@ -0,0 +1,29 @@
+\section{Retrospective}
+\vspace{1em}
+\begin{tabular}{| p{0.3\linewidth} | p{0.3\linewidth} | p{0.3\linewidth} |}
+% Table headings
+\hline\bf Positives & \bf Deltas & \bf Actions \\\hline
+
+% All the positives
+\begin{itemize}
+\item Clear Project Goals
+\item Flexible Client
+\item Code Development Started
+\end{itemize}
+
+% All the things we need to change
+&
+\begin{itemize}
+\item Background Knowledge
+\item Avoid Time Crunches
+\end{itemize}
+
+% All the actions to make the changes
+&
+\begin{itemize}
+\item Mastery Challenges
+\item Complete ROS Tutorials
+\item Earlier Starts
+\end{itemize}\\\hline
+
+\end{tabular}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/group/latexmkrc

@@ -0,0 +1,31 @@
+# This config is copied from overleaf so output there will match compiled output here
+
+# support for the glossaries package:
+add_cus_dep('glo', 'gls', 0, 'makeglossaries');
+add_cus_dep('acn', 'acr', 0, 'makeglossaries');
+sub makeglossaries {
+  system("makeglossaries \"$_[0]\"");
+}
+
+# support for the nomencl package:
+add_cus_dep('nlo', 'nls', 0, 'makenlo2nls');
+sub makenlo2nls {
+  system("makeindex -s nomencl.ist -o \"$_[0].nls\" \"$_[0].nlo\"");
+}
+
+# from the documentation for V. 2.03 of asymptote:
+sub asy {return system("asy \"$_[0]\"");}
+add_cus_dep("asy","eps",0,"asy");
+add_cus_dep("asy","pdf",0,"asy");
+add_cus_dep("asy","tex",0,"asy");
+
+# metapost rule from http://tex.stackexchange.com/questions/37134
+add_cus_dep('mp', '1', 0, 'mpost');
+sub mpost {
+  my $file = $_[0];
+  my ($name, $path) = fileparse($file);
+  pushd($path);
+  my $return = system "mpost $name";
+  popd();
+  return $return;
+}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/group/makefile

@@ -0,0 +1,18 @@
+# Makefile created by Corwin Perren
+# Generic makefile for all LaTeX projects downloaded from overleaf
+# 
+# All this makefile does is call perl against latexmkrc, which is
+# the latex equivalent of make
+
+LATEXMK_COMPILE_FLAGS = -pdf
+LATEXMK_CLEAN_FLAGS = -c
+
+.DEFAULT_GOAL := all
+
+all: latexmk_output clean
+
+latexmk_output: 
+	perl latexmk.pl $(LATEXMK_COMPILE_FLAGS)
+
+clean:
+	perl latexmk.pl $(LATEXMK_CLEAN_FLAGS)

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/group/project_statement.tex

@@ -0,0 +1,154 @@
+\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
+\usepackage{graphicx}
+\graphicspath{{./figures/}}
+
+\usepackage{url}
+\usepackage{setspace}
+\usepackage{multicol}
+
+\usepackage{geometry}
+\geometry{textheight=9.5in, textwidth=7in}
+
+% \overfullrule=2in
+
+% 1. Fill in these details
+\def \CapstoneTeamName{			}
+\def \CapstoneTeamNumber{		30}
+\def \GroupMemberOne{			Kenneth Steinfeldt}
+\def \GroupMemberTwo{			Christopher Pham}
+\def \GroupMemberThree{			Corwin Perren}
+\def \CapstoneProjectName{		OSU Robotics Club\\Mars Rover Ground Station}
+\def \CapstoneSponsorCompany{	OSU Robotics Club}
+\def \CapstoneSponsorPerson{	Nick McComb}
+
+% 2. Uncomment the appropriate line below so that the document type works
+\def \DocType{	Problem Statement
+				%Requirements Document
+				%Technology Review
+				%Design Document
+				%Progress Report
+			 }
+			
+\newcommand{\NameSigPair}[1]{
+  \par
+  \makebox[2.75in][r]{#1} 
+  \hfill
+  \makebox[3.25in]{
+      \makebox[2.25in]{\hrulefill} 
+      \hfill
+      \makebox[.75in]{\hrulefill}
+  }
+  \par\vspace{-12pt} 
+  \textit{
+      \tiny\noindent
+      \makebox[2.75in]{} 
+      \hfill
+      \makebox[3.25in]{
+          \makebox[2.25in][r]{Signature} 
+          \hfill
+          \makebox[.75in][r]{Date}
+      }
+  }
+}
+% 3. If the document is not to be signed, uncomment the command below
+\renewcommand{\NameSigPair}[1]{#1}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+\begin{titlepage}
+	\pagenumbering{gobble}
+	\begin{singlespace}
+		% 4. If you have a logo, use this includegraphics command to put it on the coversheet.
+        \begin{minipage}{7in}
+			\centering
+			\hspace*{-.7in}
+			$\vcenter{\hbox{\includegraphics[height=4cm]{Oregon_State_College_of_Engineering_Logo}}}$
+			\hspace*{.2in}
+			$\vcenter{\hbox{\includegraphics[height=2.5cm]{OSURCLogoOrange}}}$
+		\end{minipage}
+
+		\par\vspace{.35in}
+		\centering
+		\scshape{
+			\huge CS Capstone \DocType \par
+			{\large\today}\par
+			\vspace{.5in}
+			\textbf{\Huge\CapstoneProjectName}\par
+			\vfill
+			{\large Prepared for}\par
+			\Huge \CapstoneSponsorCompany\par
+			\vspace{5pt}
+			{\Large\NameSigPair{\CapstoneSponsorPerson}\par}
+			{\large Prepared by }\par
+			Group\CapstoneTeamNumber\par
+			% 5. comment out the line below this one if you do not wish to name your team
+			% \CapstoneTeamName\par 
+			\vspace{5pt}
+			{\Large
+				\NameSigPair{\GroupMemberOne}\par
+				\NameSigPair{\GroupMemberTwo}\par
+				\NameSigPair{\GroupMemberThree}\par
+			}
+			\vspace{20pt}
+		}
+		\begin{abstract}
+			% 6. Fill in your abstract    
+            This project involves the creation of the user interface and associated back-end systems needed to control the OSU Robotics Club's Mars Rover.
+            The club's Rover implements numerous control and sensor systems, all of which require ground station software to facilitate quick and easy use of the 
+            Rover during timed competitions.
+            The ground station software will send the Rover control information received via Joystick input or GUI interaction, as well as process and interpret
+            status data and multiple, concurrent video streams. 
+            An integrated mapping system will allow the Rover to run autonomously using predefined way-points. 
+            More complex readouts will dynamically show critical system components, such as a live view of arm joint positions and compass showing current 
+            heading and markers for way-points and points of interest. 
+		\end{abstract}
+	\end{singlespace}
+\end{titlepage}
+\newpage
+\pagenumbering{arabic}
+\tableofcontents
+% 7. uncomment this (if applicable). Consider adding a page break.
+%\listoffigures
+%\listoftables
+\clearpage
+
+% 8. now you write!
+\section{Problem Description}\par
+For this project, the Mars Rover Team of the OSU Robotics Club is striving to build a ground station that will serve as the primary point of contact between the operating user and the rover itself.
+In order for the Mars Rover team to be successful during competition the software must be easy to use and free from crashes and major errors that may impede progress in the competition.
+This project is going to be completely rebuilt from from the ground up instead of using a pre-made solution, such as last year's code or an open source repository.
+The competition is the University Mars Rover Challenge and will be held at Hanksville, Utah during the weekend of May 31st to June 2nd 2018 in hilly areas of the Mojave desert.
+Not only does the ground station software need to fit the needs of the client, but more importantly, it needs to fit the needs of the members of the Mars Rover Team as they will also be using this software. 
+Both the client and the club ask that the project be written in the Python programming language with the GUI (Graphical User Interface) framework QT.
+\subsection{Requests}
+\begin{itemize}
+\item Users will control the Rover through a combination of two USB joysticks as well as a keyboard and mouse.
+\item USB joysticks will allow users to drive the Rover as well as control secondary systems such as the arm and main-navigation camera positioning. 
+\item The users will view what the rover will sees using two 24 inch HD monitors: one as a main viewing screen and the other as a selection and statuses screen. 
+With this interface, users will need the ability to see and record the one or more video streams being sent back from the Rover, GPS position of the Rover on a map of the competition area, and readouts of the rover systems.
+\item Readouts on this software will need to display status information such as accessory connection states, GPS heading and speed, drive motor power, battery and system voltages, network latency, radio signal strength, and science data. 
+\item Due to the competition environment this software will need to be able to handle potential network issues, large spikes in network latency, or frequent packet loss. 
+As testing of the Rover itself is the single largest priority, rapid prototyping and development of this software is desired.
+\end{itemize}
+Additionally, the ground station software must be written keeping in mind that future Rover software teams will likely reuse and modify the code for future iterations of the robot.
+Ideally, even incomplete versions of the software will need to be available to test specific components of the Rover during its assembly phase. 
+When properly functioning, this software will need to allow a trained user to effectively and efficiently use the Rover to complete competition tasks.
+
+
+\section{Proposed Solution}
+\subsection{Frameworks}
+In order to meet the goals of this project, the client has proposed a solution to design the ground station software using Python 3, the application framework "QT" through use of the PyQt5 library. Running on Linux (Ubuntu 16.04) and Robot Operating System (ROS) version "Kinetic".
+\subsection{Rapid Prototyping}
+Since rapid prototyping will be needed, Python will allow our team to more quickly develop and test prototypes while also making it easier for future members of Rover software teams to understand, and contribute to, what was written. 
+The use of the QT framework will also help with rapid prototyping by greatly simplifying the creation of an interface and allowing the team to make quick and easy adjustments to its layout in the future. 
+\subsection{Robot Operating System}
+By using ROS, we will also be able to accelerate the design time by using the robust ROS topic subscription and broadcasting services already built into the framework. 
+This feature in particular will let us avoid creating custom command control packets that would be hard to reuse without major modifications for future years, as well as allow the Rover to natively accept these commands without the need for any sort of interpreter node.
+
+\section{Performance Metrics}
+The primary metric for whether the software has met the criteria for the project will be if the team president, a team officer, and at least three other Rover team members personally use the ground station software to control the rover and sign-off that it is adequately responsive, intuitive to use, and does not crash even under unideal conditions such as partial message loss or high latency. 
+For these tests, unideal conditions will be simulated via purposeful improper placement of Rover radios.
+Additionally, there will be empirical measurement of software traits. 
+Examples of these measurements include video stream frame rates, maximum latency values for GUI element updates, and maximum latency for control input to rover response.
+The time requirements we need to fulfill will be finishing the requirements before Engineering Expo which is May 18, 2018. The hard deadline will be May 30st, 2018, the day before the ground control station will compete in the Mars Rover competition. 
+\end{document}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/perrenc/latexmkrc

@@ -0,0 +1,31 @@
+# This config is copied from overleaf so output there will match compiled output here
+
+# support for the glossaries package:
+add_cus_dep('glo', 'gls', 0, 'makeglossaries');
+add_cus_dep('acn', 'acr', 0, 'makeglossaries');
+sub makeglossaries {
+  system("makeglossaries \"$_[0]\"");
+}
+
+# support for the nomencl package:
+add_cus_dep('nlo', 'nls', 0, 'makenlo2nls');
+sub makenlo2nls {
+  system("makeindex -s nomencl.ist -o \"$_[0].nls\" \"$_[0].nlo\"");
+}
+
+# from the documentation for V. 2.03 of asymptote:
+sub asy {return system("asy \"$_[0]\"");}
+add_cus_dep("asy","eps",0,"asy");
+add_cus_dep("asy","pdf",0,"asy");
+add_cus_dep("asy","tex",0,"asy");
+
+# metapost rule from http://tex.stackexchange.com/questions/37134
+add_cus_dep('mp', '1', 0, 'mpost');
+sub mpost {
+  my $file = $_[0];
+  my ($name, $path) = fileparse($file);
+  pushd($path);
+  my $return = system "mpost $name";
+  popd();
+  return $return;
+}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/perrenc/makefile

@@ -0,0 +1,18 @@
+# Makefile created by Corwin Perren
+# Generic makefile for all LaTeX projects downloaded from overleaf
+# 
+# All this makefile does is call perl against latexmkrc, which is
+# the latex equivalent of make
+
+LATEXMK_COMPILE_FLAGS = -pdf
+LATEXMK_CLEAN_FLAGS = -c
+
+.DEFAULT_GOAL := all
+
+all: latexmk_output clean
+
+latexmk_output: 
+	perl latexmk.pl $(LATEXMK_COMPILE_FLAGS)
+
+clean:
+	perl latexmk.pl $(LATEXMK_CLEAN_FLAGS)

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/perrenc/project_statement.tex

@@ -0,0 +1,143 @@
+\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
+\usepackage{graphicx}
+\graphicspath{{./figures/}}
+
+\usepackage{url}
+\usepackage{setspace}
+\usepackage{multicol}
+
+\usepackage{geometry}
+\geometry{textheight=9.5in, textwidth=7in}
+
+% \overfullrule=2in
+
+% 1. Fill in these details
+\def \CapstoneTeamName{			}
+\def \CapstoneTeamNumber{		30}
+\def \GroupMemberOne{			Kenneth Steinfeldt}
+\def \GroupMemberTwo{			Christopher Pham}
+\def \GroupMemberThree{			Corwin Perren}
+\def \CapstoneProjectName{		OSU Robotics Club\\Mars Rover Ground Station}
+\def \CapstoneSponsorCompany{	OSU Robotics Club}
+\def \CapstoneSponsorPerson{	Nick McComb}
+
+% 2. Uncomment the appropriate line below so that the document type works
+\def \DocType{	Problem Statement
+				%Requirements Document
+				%Technology Review
+				%Design Document
+				%Progress Report
+			 }
+			
+\newcommand{\NameSigPair}[1]{
+  \par
+  \makebox[2.75in][r]{#1} 
+  \hfill
+  \makebox[3.25in]{
+      \makebox[2.25in]{\hrulefill} 
+      \hfill
+      \makebox[.75in]{\hrulefill}
+  }
+  \par\vspace{-12pt} 
+  \textit{
+      \tiny\noindent
+      \makebox[2.75in]{} 
+      \hfill
+      \makebox[3.25in]{
+          \makebox[2.25in][r]{Signature} 
+          \hfill
+          \makebox[.75in][r]{Date}
+      }
+  }
+}
+% 3. If the document is not to be signed, uncomment the command below
+\renewcommand{\NameSigPair}[1]{#1}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+\begin{titlepage}
+	\pagenumbering{gobble}
+	\begin{singlespace}
+		% 4. If you have a logo, use this includegraphics command to put it on the coversheet.
+        \begin{minipage}{7in}
+			\centering
+			\hspace*{-.7in}
+			$\vcenter{\hbox{\includegraphics[height=4cm]{Oregon_State_College_of_Engineering_Logo}}}$
+			\hspace*{.2in}
+			$\vcenter{\hbox{\includegraphics[height=2.5cm]{OSURCLogoOrange}}}$
+		\end{minipage}
+
+		\par\vspace{.35in}
+		\centering
+		\scshape{
+			\huge CS Capstone \DocType \par
+			{\large\today}\par
+			\vspace{.5in}
+			\textbf{\Huge\CapstoneProjectName}\par
+			\vfill
+			{\large Prepared for}\par
+			\Huge \CapstoneSponsorCompany\par
+			\vspace{5pt}
+			{\Large\NameSigPair{\CapstoneSponsorPerson}\par}
+			{\large Prepared by }\par
+			Group\CapstoneTeamNumber\par
+			% 5. comment out the line below this one if you do not wish to name your team
+			% \CapstoneTeamName\par 
+			\vspace{5pt}
+			{\Large
+				\NameSigPair{\GroupMemberOne}\par
+				\NameSigPair{\GroupMemberTwo}\par
+				\NameSigPair{\GroupMemberThree}\par
+			}
+			\vspace{20pt}
+		}
+		\begin{abstract}
+			% 6. Fill in your abstract    
+            This project involves the creation of the user interface and associated back-end systems needed to control the OSU Robotics Club's Mars Rover.
+            The club's Rover implements numerous control and sensor systems, all of which require ground station software to facilitate quick and easy use of the 
+            Rover during timed competitions.
+            The ground station software will send the Rover control information received via Joystick input or GUI interaction, as well as process and interpret
+            status data and multiple, concurrent video streams. 
+            An integrated mapping system will allow the Rover to run autonomously using predefined way-points. 
+            More complex readouts will dynamically show critical system components, such as a live view of arm joint positions and compass showing current 
+            heading and markers for way-points and points of interest. 
+		\end{abstract}
+	\end{singlespace}
+\end{titlepage}
+\newpage
+\pagenumbering{arabic}
+\tableofcontents
+% 7. uncomment this (if applicable). Consider adding a page break.
+%\listoffigures
+%\listoftables
+\clearpage
+
+% 8. now you write!
+\section{Problem Description}\par
+The OSU Robotics Club Mars Rover Ground Station is the primary point of contact between the operating user and the Rover itself.
+In order for the Mars Rover team to be successful during competition the software must be easy to use and free from crashes and major errors.
+Users will control the Rover through a combination of two USB joysticks as well as a keyboard and mouse, across two 24" 1080p monitors.
+With this interface, users will need the ability to see and record the one or more video streams being sent back from the Rover as well as the GPS position of the Rover on a map of the competition area.
+\par
+Readouts on this software will need to display status information such as accessory connection states, GPS heading and speed, drive motor power, battery and system voltages, network latency, radio signal strength, and science data. 
+USB joysticks will allow users to drive the Rover as well as control secondary systems such as the arm and main-navigation camera gimbals. 
+Due to the competition environment this software will need to be able to handle potential network dropouts, large spikes in network latency, or frequent packet loss. 
+As testing of the Rover itself is the single largest priority, rapid prototyping and development of this software is desired.
+Additionally, the ground station software must be written keeping in mind that future Rover software teams will likely reuse and modify the code for future iterations of the robot.
+Ideally, even incomplete versions of the software will need to be available to test specific components of the Rover during its assembly phase. 
+When properly functioning, this software will need to allow a trained user to effectively and efficiently use the Rover to complete competition tasks.
+
+\section{Proposed Solution}
+In order to meet the goals of this project, the team's proposed solution will be to design the ground station software using Python 3, the application framework "QT" through use of the PyQt5 library, and a yet to be determined version of Robot Operating System (ROS). 
+Since rapid prototyping will be needed, Python will allow our team to more quickly develop and test prototypes while also making it easier for future members of Rover software teams to understand what was written. 
+The use of the QT framework will greatly simplify the creation of a sleek user interface and allow the team to make quick and easy adjustments to the layout in the future. 
+By using ROS, we will also be able to accelerate the design time by using the ROS topic subscription and broadcasting services built into the framework. 
+This feature in particular will let us avoid creating custom command control packets that would be hard to reuse without major modifications for future years, as well as allow the Rover to natively accept these commands without the need for an interpreter node.
+
+\section{Performance Metrics}
+The primary metric for whether the software has met the criteria for the project will be if the team president, a team officer, and at least three other Rover team members personally use the ground station software to control the rover and sign-off that it is adequately responsive, intuitive to use, and does not crash even under unideal conditions such as partial message loss or high latency. 
+For these tests, unideal conditions will be simulated via purposeful improper placement of Rover radios.
+Additionally, there will be empirical measurement of software traits. 
+Examples off these measurements include video stream frame rates, maximum latency values for GUI element updates, and maximum latency for control input to rover response.
+
+\end{document}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/phamchr/makefile

@@ -0,0 +1,54 @@
+CC=gcc
+CFLAGS=-c -Wall -g
+LDFLAGS=-pthread
+SOURCES=concurrency1.c
+OBJECTS=$(SOURCES:.c=.o)
+EXECUTABLE=concurrency1
+
+LATEX	= latex -shell-escape
+BIBTEX	= bibtex
+DVIPS	= dvips
+DVIPDF  = dvipdft
+XDVI	= xdvi -gamma 4
+GH		= gv
+
+EXAMPLES = $(wildcard *.c)
+SRC	:= $(shell egrep -l '^[^%]*\\begin\{document\}' *.tex)
+TRG	= $(SRC:%.tex=%.dvi)
+PSF	= $(SRC:%.tex=%.ps)
+PDF	= $(SRC:%.tex=%.pdf)
+
+all: pdf
+
+$(EXECUTABLE): $(OBJECTS)
+	$(CC) $(LDFLAGS) $(OBJECTS) -o $@
+
+.c.o:
+	$(CC) $(CFLAGS) $< -o $@
+
+pdf: $(PDF)
+
+ps: $(PSF)
+
+$(TRG): %.dvi: %.tex $(EXAMPLES)
+	$(LATEX) $<
+	$(LATEX) $<
+	$(LATEX) $<
+
+$(PSF):%.ps: %.dvi
+	$(DVIPS) -R -Poutline -t letter $< -o $@
+
+$(PDF): %.pdf: %.ps
+	ps2pdf $<
+
+show: $(TRG)
+	@for i in $(TRG) ; do $(XDVI) $$i & done
+
+showps: $(PSF)
+	@for i in $(PSF) ; do $(GH) $$i & done
+
+clean:
+	rm -f *.pdf *.ps *.dvi *.out *.log *.aux *.bbl *.blg *.pyg *.o
+
+.PHONY: all show clean ps pdf showps
+

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/phamchr/project_statement.aux

@@ -0,0 +1,27 @@
+\relax 
+\providecommand\hyper@newdestlabel[2]{}
+\providecommand\HyperFirstAtBeginDocument{\AtBeginDocument}
+\HyperFirstAtBeginDocument{\ifx\hyper@anchor\@undefined
+\global\let\oldcontentsline\contentsline
+\gdef\contentsline#1#2#3#4{\oldcontentsline{#1}{#2}{#3}}
+\global\let\oldnewlabel\newlabel
+\gdef\newlabel#1#2{\newlabelxx{#1}#2}
+\gdef\newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}}
+\AtEndDocument{\ifx\hyper@anchor\@undefined
+\let\contentsline\oldcontentsline
+\let\newlabel\oldnewlabel
+\fi}
+\fi}
+\global\let\hyper@last\relax 
+\gdef\HyperFirstAtBeginDocument#1{#1}
+\providecommand*\HyPL@Entry[1]{}
+\HyPL@Entry{0<</P()>>}
+\HyPL@Entry{1<</S/D>>}
+\@writefile{toc}{\contentsline {section}{\numberline {1}Overview}{2}{section.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {2}Logistics}{2}{section.2}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}Software}{2}{section.3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Requirements}{2}{subsection.3.1}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.1}GUI}{2}{subsubsection.3.1.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}Hardware}{3}{section.4}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}Suggested Solution}{3}{section.5}}
+\@writefile{toc}{\contentsline {section}{\numberline {6}Performance Metrics}{3}{section.6}}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/phamchr/project_statement.out

@@ -0,0 +1,8 @@
+\BOOKMARK [1][-]{section.1}{Overview}{}% 1
+\BOOKMARK [1][-]{section.2}{Logistics}{}% 2
+\BOOKMARK [1][-]{section.3}{Software}{}% 3
+\BOOKMARK [2][-]{subsection.3.1}{Requirements}{section.3}% 4
+\BOOKMARK [3][-]{subsubsection.3.1.1}{GUI}{subsection.3.1}% 5
+\BOOKMARK [1][-]{section.4}{Hardware}{}% 6
+\BOOKMARK [1][-]{section.5}{Suggested Solution}{}% 7
+\BOOKMARK [1][-]{section.6}{Performance Metrics}{}% 8

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/phamchr/project_statement.tex

@@ -0,0 +1,116 @@
+\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
+\usepackage{graphicx}
+\usepackage{url}
+\usepackage{setspace}
+\usepackage{hyperref}
+
+
+\usepackage{geometry}
+\geometry{textheight=9.5in, textwidth=7in}
+
+% 1. Fill in these details
+\def \CapstoneTeamName{			}
+\def \CapstoneTeamNumber{		30}
+\def \GroupMemberOne{			Kenneth Steinfeldt}
+\def \GroupMemberTwo{			Christopher Pham}
+\def \GroupMemberThree{			Corwin Perren}
+\def \CapstoneProjectName{		OSU Robotics Club\\Mars Rover Ground Station}
+\def \CapstoneSponsorCompany{	OSU Robotics Club}
+\def \CapstoneSponsorPerson{	Nick McComb}
+
+% 2. Uncomment the appropriate line below so that the document type works
+\def \DocType{		Problem Statement
+				%Requirements Document
+				%Technology Review
+				%Design Document
+				%Progress Report
+				}
+			
+\newcommand{\NameSigPair}[1]{\par
+\makebox[2.75in][r]{#1} \hfil 	\makebox[3.25in]{\makebox[2.25in]{\hrulefill} \hfill		\makebox[.75in]{\hrulefill}}
+\par\vspace{-12pt} \textit{\tiny\noindent
+\makebox[2.75in]{} \hfill		\makebox[3.25in]{\makebox[2.25in][r]{Signature} \hfill	\makebox[.75in][r]{Date}}}}
+% 3. If the document is not to be signed, uncomment the RENEWcommand below
+\renewcommand{\NameSigPair}[1]{#1}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+\begin{titlepage}
+	\pagenumbering{gobble}
+	\begin{singlespace}
+		\begin{minipage}{7in}
+			\centering
+			\hspace*{-.7in}
+			$\vcenter{\hbox{\includegraphics[height=4cm,natwidth=347,natheight=316]{Oregon_State_College_of_Engineering_Logo.eps}}}$
+			\hspace*{.2in}
+			$\vcenter{\hbox{\includegraphics[height=2.5cm,natwidth=420,natheight=149]{OSURCLogoOrange.eps}}}$
+		\end{minipage}
+		%     	\begin{center}
+		%     	\includegraphics[height=4cm]{Oregon_State_College_of_Engineering_Logo}
+		%         \hfill
+		%         \includegraphics[height=2cm]{OSURCLogoOrange}  
+		%         \end{center}
+
+		% 4. If you have a logo, use this includegraphics command to put it on the coversheet.
+
+		\par\vspace{.25in}
+		\centering
+		\scshape{
+			\huge CS Capstone \DocType \par
+			{\large\today}\par
+			\vspace{.5in}
+			\textbf{\Huge\CapstoneProjectName}\par
+			\vfill
+			{\large Prepared for}\par
+			\Huge \CapstoneSponsorCompany\par
+			\vspace{5pt}
+			{\Large\NameSigPair{\CapstoneSponsorPerson}\par}
+			{\large Prepared by }\par
+			Christopher Pham\par
+			% 5. comment out the line below this one if you do not wish to name your team
+			% \CapstoneTeamName\par 
+			\vspace{5pt}
+% 			{\Large
+% 				\NameSigPair{\GroupMemberOne}\par
+% 				\NameSigPair{\GroupMemberTwo}\par
+% 				\NameSigPair{\GroupMemberThree}\par
+% 			}
+% 			\vspace{20pt}
+		}
+		\begin{abstract}
+			% 6. Fill in your abstract    
+			The purpose of this document is to prove my understanding of the problem that will occur. By listing out the requirements that are requested of this project, this allows for I to define, explain, and bring into my own words how the problem is perceived and allows for misunderstandings to be brought up sooner rather than later. 
+		\end{abstract}
+	\end{singlespace}
+\end{titlepage}
+\newpage
+\pagenumbering{arabic}
+\tableofcontents
+% 7. uncomment this (if applicable). Consider adding a page break.
+%\listoffigures
+%\listoftables
+\clearpage
+
+% 8. now you write!
+\section{Overview}
+For this project, our group is looking to build a ground control station for the Mars Rover group which is a part of the Oregon State Robotics Club. The product is necessary for their club because this is going to view, control, and access the rover while it is on the ground in competition or even possibly in space. Our client, Nick McComb, is the Mars Rover team lead and we possibly might be in contact with other people of the Mars Rover team to fit their needs as this is an integral part of their combined systems. We had our first meeting October 8th to go over our requirements and expectations for our project.
+
+\section{Logistics}
+For our group, we are expected to use \href{https://app.asana.com}{Asana} which will be our team tracking software and will delegate tasks as decided by Nick or some other leads to accomplish goals in time. Asana will be used compared to other software because of the request of the Robotics team and there is already a subscription with them. Our version control will be the Robotics club's because it is what they requested because other code pertaining to the event will be located there too. 
+
+\section{Software}
+For the software we are creating, there are requirements that are requested by our client. There might possibly be more requests by club members but those can be appended on as we progress.
+\subsection{Requirements}
+There is a requirement for us to use Python 3 with \href{https://www.python.org/dev/peps/pep-0008/}{PEP-8 standard} linting. We are required to use the QT framework under the wrapper PyQt5 to make any graphical user interfaces (GUI). All the code needs to be deployable by May 31, or the day of the competition. For the software we are creating, we will need to use \href{http://www.ros.org/}{Robot Operating System (ROS)}framework to handle sending and receiving controls and statues, video streams over remote Ethernet link. All the code must be multi-threaded using QThreads and/or multi-process with ROS node system.
+\subsubsection{GUI}
+As per request of the client, we need to build a system that has a dark theme that is suitable for the location of the competition near Hanksville, Utah, such that the desert light does not cause a bunch of glare when trying to use the system. There needs to be a system that can adjust the bitrate of the video streams to allow for network interference at the competition and flexibility. The system should adjust the video bitrate automatically but a user could override the quality. 
+\\
+\noindent The project most likely will run on two 1080p (1920x1080) monitors in full-screen mode on both displays. The left monitor should contain an active video selection for the other display and should show a navigational map which contains the rover's current location, points of interests, and way-points. The map should have the ability to put pins for points of interests by the rover's location, by clicking on the map, or by explicitly putting in GPS coordinates. A way of editing the way points is required to show active way points, change order of way-points, or delete way-points. It should also contain a compass indicator, an Inertial measurement unit (IMU) visualization like pitch, roll, yaw like a flight attitude indicator. Autonomy settings are required like enabling it, video overlays showing processing/processed data if possible, and indicator for when the rover reaches its location and stopped. There is a need to show the statues of the core systems: "bogie" connection statuses, arm connection status, camera presences, joystick connection status, current connection latency, current network max throughput, radio calculated distance, current radio signal strength, GPS connected, Rover's Next Unit of Computing (NUC) CPU usage, NUC Ram Usage, NUC file-system usage, GPS speed in m/s, GPS heading, GPS connected satellites, GPS accuracy. There should be a way to monitor voltages like minimums or approximate safe discharge time. Another request was finding a way to simulate the moving arm using the OpenGL wrapper in Python/PyQT to show the operator how the arm is moving. Another display would be showing the science probes like soil sample sensors or biological sensors attached to the rover. The right monitor will contain the primary video display or a secondary display in "picture in picture" mode or "picture by picture" mode and tools to save the video stream that is coming from the rover.
+\section{Hardware}
+The client requests that we run the software on an Intel NUC (2016) or a laptop that will be running Ubuntu 16.04 LTS. There will be two 24" 1080p monitors attached to the system. We will need to somehow to figure a way to interface the two universal serial bus (USB) joysticks to control the rover or via keyboard and mouse.  
+\section{Suggested Solution}
+The project itself leans towards like a wrapper like system for ROS and end user to control using PyQT to see, inputs via USB to control, and Python to control and send back data to the rover. For this project, most of it is broken up into the front-end QT/OpenGL and back-end python code to run the front end. To solve how to place points of interests via clicking, it could be done by calculating where in the "box" the click landed and then comparing that to the map texture. To simulate an IMU, you could use OpenGL and make a lens and sphere and calculate the changes needed. An overlay for autonomy mode finishing would just overlaying an object over the video stream which could be an OpenGL object, or covering it up with Qt. The rest of the GUI requests are just displaying the info to screen. The way of solving the way-point system would be harder than expected by using some database base system like SQLite and allowing for path finding.  
+
+\section{Performance Metrics}
+This project needs to be done before May 31, 2018, the date of the competition but the metrics that are necessary and required are the requirements above. Any addendum to the project will be listed under requests and not mandatory for project completion.   
+\end{document}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/phamchr/project_statement.toc

@@ -0,0 +1,8 @@
+\contentsline {section}{\numberline {1}Overview}{2}{section.1}
+\contentsline {section}{\numberline {2}Logistics}{2}{section.2}
+\contentsline {section}{\numberline {3}Software}{2}{section.3}
+\contentsline {subsection}{\numberline {3.1}Requirements}{2}{subsection.3.1}
+\contentsline {subsubsection}{\numberline {3.1.1}GUI}{2}{subsubsection.3.1.1}
+\contentsline {section}{\numberline {4}Hardware}{3}{section.4}
+\contentsline {section}{\numberline {5}Suggested Solution}{3}{section.5}
+\contentsline {section}{\numberline {6}Performance Metrics}{3}{section.6}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/steinfek/Makefile

@@ -0,0 +1,42 @@
+LATEX	= latex -shell-escape
+BIBTEX	= bibtex
+DVIPS	= dvips
+DVIPDF  = dvipdft
+XDVI	= xdvi -gamma 4
+GH		= gv
+
+EXAMPLES = $(wildcard *.h)
+SRC	:= $(shell egrep -l '^[^%]*\\begin\{document\}' *.tex)
+TRG	= $(SRC:%.tex=%.dvi)
+PSF	= $(SRC:%.tex=%.ps)
+PDF	= $(SRC:%.tex=%.pdf)
+
+pdf: $(PDF)
+
+ps: $(PSF)
+
+$(TRG): %.dvi: %.tex *.bib $(EXAMPLES)
+	$(LATEX) $<
+	$(BIBTEX) $(<:%.tex=%)
+	$(LATEX) $<
+	$(LATEX) $<
+
+$(PSF):%.ps: %.dvi
+	$(DVIPS) -R -Poutline -t letter $< -o $@
+
+$(PDF): %.pdf: %.ps
+#	$(DVIPDF) -o $@ $<
+	ps2pdf $<
+
+show: $(TRG)
+	@for i in $(TRG) ; do $(XDVI) $$i & done
+
+showps: $(PSF)
+	@for i in $(PSF) ; do $(GH) $$i & done
+
+all: pdf
+
+clean:
+	rm -f *.pdf *.ps *.dvi *.out *.log *.aux *.bbl *.blg *.pyg
+
+.PHONY: all show clean ps pdf showps

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/problem_statement/steinfek/project_statement.tex

@@ -0,0 +1,145 @@
+\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
+\usepackage{graphicx}
+\usepackage{url}
+\usepackage{setspace}
+
+\usepackage{geometry}
+\geometry{textheight=9.5in, textwidth=7in}
+
+% 1. Fill in these details
+\def \CapstoneTeamName{			}
+\def \CapstoneTeamNumber{		30}
+\def \GroupMemberOne{			Kenneth Steinfeldt}
+\def \GroupMemberTwo{			Christopher Pham}
+\def \GroupMemberThree{			Corwin Perren}
+\def \CapstoneProjectName{		OSU Robotics Club\\Mars Rover Ground Station}
+\def \CapstoneSponsorCompany{	OSU Robotics Club}
+\def \CapstoneSponsorPerson{	Nick McComb}
+
+% 2. Uncomment the appropriate line below so that the document type works
+\def \DocType{		Problem Statement
+				%Requirements Document
+				%Technology Review
+				%Design Document
+				%Progress Report
+				}
+			
+\newcommand{\NameSigPair}[1]{\par
+\makebox[2.75in][r]{#1} \hfil 	\makebox[3.25in]{\makebox[2.25in]{\hrulefill} \hfill		\makebox[.75in]{\hrulefill}}
+\par\vspace{-12pt} \textit{\tiny\noindent
+\makebox[2.75in]{} \hfill		\makebox[3.25in]{\makebox[2.25in][r]{Signature} \hfill	\makebox[.75in][r]{Date}}}}
+% 3. If the document is not to be signed, uncomment the RENEWcommand below
+\renewcommand{\NameSigPair}[1]{#1}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+\begin{titlepage}
+	\pagenumbering{gobble}
+	\begin{singlespace}
+		\begin{minipage}{7in}
+			\centering
+			\hspace*{-.7in}
+			$\vcenter{\hbox{\includegraphics[height=4cm]{Oregon_State_College_of_Engineering_Logo}}}$
+			\hspace*{.2in}
+			$\vcenter{\hbox{\includegraphics[height=2.5cm]{OSURCLogoOrange}}}$
+		\end{minipage}
+		%     	\begin{center}
+		%     	\includegraphics[height=4cm]{Oregon_State_College_of_Engineering_Logo}
+		%         \hfill
+		%         \includegraphics[height=2cm]{OSURCLogoOrange}  
+		%         \end{center}
+
+		% 4. If you have a logo, use this includegraphics command to put it on the coversheet.
+
+		\par\vspace{.25in}
+		\centering
+		\scshape{
+			\huge CS Capstone \DocType \par
+			{\large\today}\par
+			\vspace{.5in}
+			\textbf{\Huge\CapstoneProjectName}\par
+			\vfill
+			{\large Prepared for}\par
+			\Huge \CapstoneSponsorCompany\par
+			\vspace{5pt}
+			{\Large\NameSigPair{\CapstoneSponsorPerson}\par}
+			{\large Prepared by }\par
+			Group\CapstoneTeamNumber\par
+			% 5. comment out the line below this one if you do not wish to name your team
+			% \CapstoneTeamName\par 
+			\vspace{5pt}
+			{\Large
+				\NameSigPair{\GroupMemberOne}\par
+				\NameSigPair{\GroupMemberTwo}\par
+				\NameSigPair{\GroupMemberThree}\par
+			}
+			\vspace{20pt}
+		}
+		\begin{abstract}
+			% 6. Fill in your abstract
+			For this project our group will design and create the ground station software for the Oregon State University Robotics Club.
+			When the Mars rover embarks on its mission it will require a ground control station that will direct and monitor the rover through the mission.
+			In addition to directing the rover the control station will also monitor various aspects of the rover.
+			These include a video feed, a navigational map, an accurate compass indicator, waypoint editing and placement, core system status, arm joint position, etc.
+
+			In order to achieve this we will be using the Python 3 language following the PEP8 standard.
+			The software will use the Robot Operating System (ROS) framework to monitor the rover and the Python QT framework to power the user interface.
+			The Ground Control Station will communicate to the rover via a remote ethernet link that can dynamically adjust bandwidth according to necessity.
+			When complete the Control Station will allow the user to fully control and monitor the Mars Rover remotely through the variety of challenges and obstacles laid before it at the University Mars Rover Challenge in Hanksville, Utah.
+
+		\end{abstract}
+	\end{singlespace}
+\end{titlepage}
+\newpage
+\pagenumbering{arabic}
+\tableofcontents
+% 7. uncomment this (if applicable). Consider adding a page break.
+%\listoffigures
+%\listoftables
+\clearpage
+
+% 8. now you write!
+\section{introduction}\par
+	The Oregon State University Robotics Club will be competing in the University Mars Rover Challenge held in Hanksville, Utah, May 31 - June 2, 2018.
+	The rover must be a standalone, off the grid, mobile platform.
+	In order to accomplish this task a ground station is required in order to fully monitor and operate the mobile rover as it navigates the obstacles of the competition.
+	The following document lays out how our group will design and write the software that will accomplish this task.
+
+\section{competition requirements}
+	In order to compete, the rover must be controlled from a central, remote command and control station.
+	This ground control station is required for course traversal as control station to rover line of sight will be blocked throughout the course.
+	There are several tasks for the rover to compete in, and for each task the rover may be outfitted.
+	However, no matter the task, the rover must be controlled by the same ground control station.
+
+\section{requirements}
+\subsection{programming}
+	The software must be written in Python 3.6 following the PEP 8 standard.
+	The GUI must be written using QT and the PyQT5 framework.
+	The software must interact with the rover's Robot Operation System (ROS) framework in order to handle the transmission of: control, status information, and video feed over a remote ethernet connection.
+	Bandwidth must be dynamic in order to adjust to varying environmental constraints, this should be both automatic and manual.
+
+\subsection{graphic user interface}
+	The GUI will cover 2 monitors running at 1080p resolution.
+	The left monitor will display the following: \begin{itemize}
+														 \item selectable video display
+														 \item main navigational map
+														 \item compass
+														 \item IMU status
+														 \item waypoint indicators
+														 \item arm position
+														 \item science data
+														 \item logging information
+\end{itemize}
+
+	The right monitor will display the following: \begin{itemize}
+													  \item primary video stream
+													  \item video tools, such as record to disk
+\end{itemize}
+\subsection{Hardware}
+	The software will running on an Intel NUC device running Ubuntu 16.04 LTS able to drive the two required 1080p monitors.
+	The primary control interface will be two USB joysticks.
+	A keyboard and mouse will be connected to the NUC and usable.
+	A remote ethernet network connection will be provided via 2 Ubiquiti Rocket M2 radios.
+	The base station will be self-contained for easy deployment.
+
+\end{document}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/requirements/latexmkrc

@@ -0,0 +1,31 @@
+# This config is copied from overleaf so output there will match compiled output here
+
+# support for the glossaries package:
+add_cus_dep('glo', 'gls', 0, 'makeglossaries');
+add_cus_dep('acn', 'acr', 0, 'makeglossaries');
+sub makeglossaries {
+  system("makeglossaries \"$_[0]\"");
+}
+
+# support for the nomencl package:
+add_cus_dep('nlo', 'nls', 0, 'makenlo2nls');
+sub makenlo2nls {
+  system("makeindex -s nomencl.ist -o \"$_[0].nls\" \"$_[0].nlo\"");
+}
+
+# from the documentation for V. 2.03 of asymptote:
+sub asy {return system("asy \"$_[0]\"");}
+add_cus_dep("asy","eps",0,"asy");
+add_cus_dep("asy","pdf",0,"asy");
+add_cus_dep("asy","tex",0,"asy");
+
+# metapost rule from http://tex.stackexchange.com/questions/37134
+add_cus_dep('mp', '1', 0, 'mpost');
+sub mpost {
+  my $file = $_[0];
+  my ($name, $path) = fileparse($file);
+  pushd($path);
+  my $return = system "mpost $name";
+  popd();
+  return $return;
+}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/requirements/makefile

@@ -0,0 +1,18 @@
+# Makefile created by Corwin Perren
+# Generic makefile for all LaTeX projects downloaded from overleaf
+# 
+# All this makefile does is call perl against latexmkrc, which is
+# the latex equivalent of make
+
+LATEXMK_COMPILE_FLAGS = -pdf
+LATEXMK_CLEAN_FLAGS = -c
+
+.DEFAULT_GOAL := all
+
+all: latexmk_output clean
+
+latexmk_output: 
+	perl latexmk.pl $(LATEXMK_COMPILE_FLAGS)
+
+clean:
+	perl latexmk.pl $(LATEXMK_CLEAN_FLAGS)

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/requirements/requirements.tex

@@ -0,0 +1,472 @@
+\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
+\usepackage{graphicx}
+\graphicspath{{./figures/}}
+
+\usepackage{url}
+\usepackage{setspace}
+\usepackage{multicol}
+\usepackage{pdflscape}
+\usepackage{pdfpages}
+
+\usepackage{geometry}
+\geometry{textheight=9.5in, textwidth=7in}
+
+% \overfullrule=2in
+
+% 1. Fill in these details
+\def \CapstoneTeamName{			Ground Station Software Team}
+\def \CapstoneTeamNumber{		30}
+\def \GroupMemberOne{			Kenneth Steinfeldt}
+\def \GroupMemberTwo{			Christopher Pham}
+\def \GroupMemberThree{			Corwin Perren}
+\def \CapstoneProjectName{		OSU Robotics Club\\Mars Rover Ground Station}
+\def \CapstoneSponsorCompany{	OSU Robotics Club}
+\def \CapstoneSponsorPerson{	Nick McComb}
+
+
+
+%Personal \newcommands
+
+\newcommand{\functRequ}[4]{
+\item #1%
+\par
+\begin{itemize}
+\item \textit{Description:} #2.%
+\item \textit{Rationale:} #3.%
+\item \textit{Dependencies:} #4%
+\end{itemize}
+}
+
+
+
+% 2. Uncomment the appropriate line below so that the document type works
+\def \DocType{	%Problem Statement
+				Requirements Document
+				%Technology Review
+				%Design Document
+				%Progress Report
+			 }
+			
+\newcommand{\NameSigPair}[1]{
+  \par
+  \makebox[2.75in][r]{#1} 
+  \hfill
+  \makebox[3.25in]{
+      \makebox[2.25in]{\hrulefill} 
+      \hfill
+      \makebox[.75in]{\hrulefill}
+  }
+  \par\vspace{-12pt} 
+  \textit{
+      \tiny\noindent
+      \makebox[2.75in]{} 
+      \hfill
+      \makebox[3.25in]{
+          \makebox[2.25in][r]{Signature} 
+          \hfill
+          \makebox[.75in][r]{Date}
+      }
+  }
+}
+% 3. If the document is not to be signed, uncomment the command below
+\renewcommand{\NameSigPair}[1]{#1}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+\begin{titlepage}
+	\pagenumbering{gobble}
+	\begin{singlespace}
+		% 4. If you have a logo, use this includegraphics command to put it on the coversheet.
+        \begin{minipage}{7in}
+			\centering
+			\hspace*{-.7in}
+			$\vcenter{\hbox{\includegraphics[height=4cm]{Oregon_State_College_of_Engineering_Logo}}}$
+			\hspace*{.2in}
+			$\vcenter{\hbox{\includegraphics[height=2.5cm]{OSURCLogoOrange}}}$
+		\end{minipage}
+
+		\par\vspace{.35in}
+		\centering
+		\scshape{
+			\huge CS Capstone \DocType \par
+			{\large\today}\par
+			\vspace{.5in}
+			\textbf{\Huge\CapstoneProjectName}\par
+			\vfill
+			{\large Prepared for}\par
+			\Huge \CapstoneSponsorCompany\par
+			\vspace{5pt}
+			{\Large\NameSigPair{\CapstoneSponsorPerson}\par}
+			{\large Prepared by }\par
+			Group\CapstoneTeamNumber\par
+			% 5. comment out the line below this one if you do not wish to name your team
+			\CapstoneTeamName\par 
+			\vspace{5pt}
+			{\Large
+				\NameSigPair{\GroupMemberOne}\par
+				\NameSigPair{\GroupMemberTwo}\par
+				\NameSigPair{\GroupMemberThree}\par
+			}
+			\vspace{20pt}
+            \begin{abstract}
+			% 6. Fill in your abstract
+            This document covers the design requirements for the OSU Robotics Club Mars Rover Team's Ground Station Software.
+            It begins with details about why the software is necessary, and a general overview of what it needs to accomplish.
+            We then go into further detail about what the specific functional requirements will be, how they relate to each other in terms of dependencies, and then end with stretch goals if there is extra time to complete them.
+
+		\end{abstract}
+		}
+	\end{singlespace}
+\end{titlepage}
+\newpage
+\pagenumbering{arabic}
+\tableofcontents
+\clearpage
+
+% 8. now you write!
+\section{Introduction}
+\subsection{Purpose}
+The purpose of this document is to formally define the characteristics of the software to be implemented. 
+These requirements can then be used to determine if the software is complete once the project is done, while also serving as a reference during development.
+
+
+\subsection{Scope}
+We will be creating the "Mars Rover Ground Station" software package. 
+This software will allow Rover team members to interact with the Oregon State University Robotics Club's Mars Rover for the purpose of a competition taking place in Drumheller, Alberta, Canada during August of 2018. 
+The software will provide Rover systems monitoring as well as control of drive and arm systems. 
+During competition, the software will be run on a remote base station primarily operated off the back of a truck, allowing users to tele-operate the Rover during manned controlled missions, or to monitor progress during autonomous missions. 
+Properly functioning and fully featured ground station software will be a major factor in the success of the Mars Rover during this competition.
+
+
+\subsection{Definitions / Acronyms / Abbreviations}
+\begin{itemize}
+\item ROS - Robot Operating System
+\item QT - A multi-platform GUI and application framework
+\item GPS - Global Positioning Satellite 
+\item User - Person operating rover from ground control station
+\item GUI - Graphical User Interface
+\item RTT - Round-trip Time, the length of time for a signal to be sent plus the length of the time it takes for an acknowledgement of the signal to be received.
+\item Bogie - Groups of two individual wheels on the Rover, each with the ability to be driven independently.
+\item IMU - Inertial Measurement Unit
+\item CAD - Computer Aided Design
+\end{itemize}
+
+
+\subsection{Overview}
+The remainder of this document consists of 4 sections and will describe the requirements that must be met in order for this project to be considered fully complete. The next section gives a description of the process. 
+The fourth section describes the ground control software's functions, user characteristics, constraints, and assumptions and dependencies. 
+The fifth section describes the specific requirements that must be met for the software to be a success.
+Finally, stretch goals in the sixth section will describe hopeful, but not mandatory goals for the software.
+
+\section{Description}
+\subsection{Product Perspective}
+This project interacts with and requires the Robotics Club's Mars Rover robotics vehicle in order to be useful.
+If the Rover is not connected, the software will still be able to launch, but will not perform any useful functions until it has established a connection to the Rover.
+In order to accomplish interaction with the rover, the ground station software will use ROS for primary functionality and feedback from the rover.
+
+
+\section{Product Functions}
+The ground control software will primarily accomplish two tasks:
+\begin{itemize}
+\item Provide Rover control to the user.
+Direct rover control will be accomplished with joystick(s) and/or a SpaceNav mouse along with a keyboard and mouse.
+\item Enable and present rover feedback to the user.
+The rover will send health and status information to the ground control station.
+\end{itemize}
+
+
+\subsection{User Characteristics}
+Users of the Rover Ground Station software will comprise of Rover team leads and members.
+
+\subsubsection{User Stories}
+\begin{itemize}
+\item User should be able view ground station UI on two HD monitors so that valuable competition time will not be spent switching between screens on a single monitor
+\item User should be able to add way-points because way-points are needed to find useful points in the competition field and are necessary for autonomous navigation
+\item User should be able to remove way-points because way-points may become unneeded or need to be reset for a new competition event
+\item User should be able to edit way-points because there's a chance that the User may enter way-point details incorrectly and will need to change them
+\item User should be able to change the order of way-points because we might need to traverse back to a location, or fix improperly entered way-points
+\item User should be able to control the Rover by joystick(s) because that is the preferred way of controlling the Rover  
+\item User should be able to select video streams because the Rover has more cameras than can be streamed at any one time, and being able to view any camera on demand will help the User drive the Rover and manipulate the arm
+\item User should be able to view the pitch, yaw, roll of the Rover because we want to know if the rover is on an incline, decline, or about to tip over
+\item User should be able to switch on and off autonomy because there are competition events that require autonomy and others that require manual control
+\item User should be able to tell that autonomy is enabled because that alerts the User that they can no longer manually control the Rover
+\item User should be able to view how the arm joints positions as that can show us if the arm is performing correctly
+\item User should be able to control the arm because competition events require the use of a Rover arm
+\item User should be able to set the Rover speed limit so that the User can more easily drive the Rover over difficult terrain
+\item User should be able to view the Rover CPU usage because the User can use this information to tell if there is a software problem on the Rover or if the Rover is trying to process too much information
+\item User should be able to view the Rover memory usage because the User does not want the Rover to crash or slow down to unusable levels due to running out of memory
+\item User should be able to view the Rover drive usage because the User does not want the Rover to crash if the drive is full
+\item User should be able to see the speed of the Rover because it can be used to determine if the Rover is driving at a speed that is reasonable for the current terrain
+\item User should be able to see how accurate the GPS positioning is because at the competition there is a requirement to be a certain distance from an object
+\item User should be able to see what heading the Rover is at because it allows for the User to know what direction to go
+\item User should be able to see the maximum throughput of the network because it will allow for video stream quality to go up or down depending on the connection quality
+\item User should be able to confirm connected devices because this will allow for debugging and checking of other connected devices
+\end{itemize}
+
+
+\subsection{Constraints}
+Due to the nature of the Mars Rover project, there are multiple hardware and software constraints to ensure that the Ground Station software can properly communicate with the Rover. 
+Additionally, the following constraints will help ensure future re-usability of the finalized software, which is a key goal of the Mars Rover team. 
+\par
+The software language allowed is the primary constraint for this project. 
+Python 2.7 is required by the Mars Rover team as it maintains consistency with the software written on the Rover itself. 
+The team also requires Python as it more easily allows future team members to reverse engineer code to be reused in future projects.
+\par
+Use of the QT application framework is another constraint placed by the Rover team in order to facilitate rapid prototyping of the user interface for this project. 
+It will also allow for faster and easier modification both by future members of the team, and during competition as that has previously been necessary.
+\par
+The Rover internally uses ROS to handle routing and interpreting control and status information as well as video data. To be able to view this video data, status information, and to be able to send the Rover control information, this ground station software must also incorporate ROS.
+\par
+At a hardware level, the Rover team will be providing an Intel NUC desktop computer running Ubuntu 16.04 that the Ground Station software will need to be able to run on.
+They will also provide two HD monitors, one or two USB joysticks, a SpaceNav mouse, as well as a keyboard and mouse that will be used to view and interact with the software.
+\par
+As the Rover project is highly volatile where designs change frequently and hardware development often falls behind, any systems that cannot be explicitly implemented must at least have placeholders in both the GUI frontend and code backend to make eventual development easier when the hardware becomes available.
+
+
+\section{Specific Requirements}
+\subsection{User Interfaces}
+Upon initial launch, the application should be in full-screen mode across both of the monitors. 
+The left-hand screen will show navigation, Rover status, and miscellaneous Rover controls. 
+The right hand monitor will show the three live video streams from the Rover. 
+In the case that the software is started without a Rover to connect to, the software will display as-such and show placeholder information until such a connection is made.
+
+
+\subsection{Functional Requirements}
+\subsubsection{Statuses / Informational Readouts}
+\begin{enumerate}
+\functRequ{Rover Connection Status}
+{This indicator will show a binary state of whether or not the Rover is currently connected}
+{The Rover must be connected in order for most of the software aspects to function. 
+It is also useful to tell when full network dropouts happen}
+{None}
+
+\functRequ{Joystick(s) Connection Status}
+{Status indicators will visually show binary states as to whether joystick(s) are currently connected}
+{Joystick(s) must be connected to drive the Rover}
+{Rover Connection Status}
+
+\functRequ{SpaceNav Mouse Connection Status}
+{Status indicators will visually show binary states as to whether the SpaceNav mouse is connected}
+{SpaceNav mouse must be connected to control the Rover arm}
+{Rover Connection Status}
+
+\functRequ{Rover Battery Voltage}
+{This indicator will show the Rover's battery voltage}
+{The User should know what the battery voltage is to be able to determine remaining runtime and to diagnose other Rover errors}
+{Rover Connection Status}
+  
+\functRequ{Wheel Connection Statuses}
+{These indicators will show whether each of the six wheels are connected to the Rover}
+{This will let drivers of the Rover know if a wheel has failed, which is a common occurrence}
+{Rover Connection Status}
+
+\functRequ{Arm Connection Status}
+{This indicator will be a binary state of weather or not the mechanical arm is connected or not}
+{This will show the User whether the arm is connected, and therefore whether they will be able to use the joysticks to control the arm}
+{Rover Connection Status}
+
+\functRequ{Arm Joint Positions}
+{These indicators will show Rover Arm joint positions in terms of degrees or via visual relationships}
+{These indications will help ensure the User knows where the Arm actually is, and whether it is being moved within its operating limits}
+{Rover Connection Status, Arm Connection Status}
+
+\functRequ{Camera Presence Statuses}
+{This indicator will show which cameras on-board the Rover and connected and functional}
+{The User can use such indicators to verify a failed camera for easy troubleshooting}
+{Rover Connection Status}
+
+\functRequ{IMU Status}
+{This will indicate the pitch, yaw, and roll of the Rover}
+{This can be used by the User to help navigate uneven terrain and to avoid flipping the Rover}
+{Rover Connection Status}
+
+\functRequ{Map Visualizer}
+{This will display a map of  the current Rover location and surrounding areas}
+{This can be used to see terrain maps of the area and to place useful way-point and autonomous navigation markers}
+{Rover Connection Status}
+
+\functRequ{Rover Computer Statuses}
+{These indicators will show the current CPU, memory, and disk usage of the Rover's on-board computer}
+{These can be used to ensure the Rover's processing computer is not overloaded.
+It can also show potential software failures while serving as a useful indication that the connection to the Rover is stable}
+{Rover Connection Status}
+
+\functRequ{Current Radio Signal Strength}
+{This indicator will display the strength of the connection between the Rover and ground station}
+{The User can use this information to determine if the Rover is driving out of range to ensure a connection is not fully lost}
+{Rover Connection Status}
+  
+\functRequ{Rover Network Potential Throughput}
+{This indicator will show the maximum theoretical throughput in Kbps between the Rover and this software as provided by the Ubiquity routers}
+{The User can use the information to help tune video bit-rates and resolutions to ensure the connection is not overloaded}
+{Rover Connection Status, Current Radio Signal Strength, Rover RTT}
+
+\functRequ{Estimated Rover Distance}
+{This indicator will show the distance from the Ground Station radio to the Rover radio, as calculated by the Ubiquiti radio systems}
+{The User can use this information to help ensure they do not drive out of communications range}
+{Rover Connection Status, Current Radio Signal Strength}
+
+\functRequ{Rover Speed Limit}
+{This display will show the Rover's speed limit in terms of 0 to 100 percent}
+{During manual driving operations it is often useful to limit the max speed of the Rover.
+A visual indication of this limit will help avoid confusion if the User forgets that a limit has been set, or if the limit is accidentally changed}
+{Rover Connection Status, Rover Bogie Status}
+
+\functRequ{Display Data Collection Sensors}
+{Provide data displays for any scientific sensors attached to the Rover}
+{During some competition phases, scientific sensors will be placed into the soil to gather scientific data.
+This data needs to be sent back to the Ground Station so it can be recorded}
+{Rover Connection Status}
+\end{enumerate}
+
+\subsubsection{Rover Control}
+\begin{enumerate}
+\functRequ{Rover Joystick Driving Control}
+{When both joysticks are connected and the Rover is also connected, the joysticks can be used to drive the Rover}
+{The joystick control is needed to be able to drive the Rover}
+{Rover Connection Status, Joystick Connection Statuses, Bogie Connection Statuses}
+
+\functRequ{Rover SpaceNav Mouse Arm Control}
+{When the SpaceNav mouse is connected, the Rover is connected, and the Arm is connected, this mouse can be used to manipulate the Rover arm}
+{During some competition events, the arm will need to be manipulated by the User to complete competition tasks}
+{Rover Connection Status, Joystick Connection Statuses, Arm Connection Status}
+
+\functRequ{Rover Speed Limit Control}
+{When both joysticks are connected and the Rover is also connected, buttons or levers on a joystick may be used to adjust the max speed limit of the Rover}
+{This quick adjustment is often needed to allow for finer control of the Rover over difficult terrain or when manipulating the Rover arm}
+{Rover Connection Status, Joystick Connection Statuses, Bogie Connection Statuses}
+\end{enumerate}
+
+\subsubsection{Navigation}
+\begin{enumerate}
+\functRequ{GPS Status}
+{This will show whether the GPS on the Rover is connected and whether it has GPS lock}
+{This is needed to check to see if GPS is working and functioning properly}
+{Rover Connection Status}
+
+\functRequ{Rover Speed}
+{This indicator shows how fast the Rover is moving in meters per second via the GPS}
+{This will help the User ensure they are driving within the mechanical limits of the Rover}
+{Rover Connection Status, GPS Status}
+
+\functRequ{Rover GPS Heading}
+{This indicator will show what bearing the Rover is heading}
+{The User can use this information to help navigate the competition course}
+{Rover Connection Status, GPS Status}
+
+\functRequ{GPS Satellites Connected}
+{This indicator will show how many GPS satellites are currently active}
+{This can help tell the User if the Rover is in a location that is bad for GPS reception, allowing them to drive to a better location before the GPS lock is lost}
+{Rover Connection Status, GPS Status}
+
+\functRequ{GPS Accuracy}
+{This indicator will how accurate the current GPS location is in meters}
+{This will allow the User to judge how much the GPS location of the Rover can be trusted, as well as giving useful information about how well the Rover might perform during the autonomous challenge}
+{Rover Connection Status, GPS Status, GPS Satellites Connected}
+
+\functRequ{Way-point Placement}
+{Give the ability to place way-points on a map by GPS location, by current Rover location, or via manual GPS co-ordinate entry and add this way-point to a queue.
+These way-points will also need to show up visually on the map}
+{This will used to map out the course during the autonomous challenge as well as to place points of interest during manual driving events}
+{Rover Connection Status, GPS Status, GPS Satellites Connected, Map Visualizer}
+
+\functRequ{Way-point Editing}
+{Allow for editing any way-point in the queue by drag and drop of the way-point, or via manual editing of the GPS co-ordinates}
+{This will allow for easy adjustment of way-points if they were placed incorrectly}
+{Rover Connection Status, GPS Status, GPS Satellites Connected, Way-point Placement, Map Visualizer}
+
+\functRequ{Way-point Re-Ordering}
+{Allow for changing the order of way-points}
+{This will allow the User to skip unneeded way-points or fix incorrectly ordered way-points}
+{Rover Connection Status, GPS Status, GPS Satellites Connected, Way-point Placement, Map Visualizer}
+
+\functRequ{Active Way-point Selection}
+{Allow for the selection of a way-point from the queue as currently active.
+Setting the way-point active will update a "Heading To" indicator to help a User drive to the desired way-point}
+{This is useful to make navigating to competition provided co-ordinates easier}
+{Rover Connection Status, GPS Status, GPS Satellites Connected, Way-point Placement, Map Visualizer}
+
+\end{enumerate}
+\subsubsection{Autonomy}
+\begin{enumerate}
+\functRequ{Autonomy Switch}
+{A toggle to enable and disable the Rover's autonomous mode operation}
+{This is necessary to place the Rover into autonomous mode for that portion of the University Rover Challenge competition}
+{Rover Connection Status}
+
+\functRequ{Autonomy Indicator}
+{An alert or indicator for when the Rover is in autonomous mode}
+{This indicator will make it easy to tell whether the joystick(s) can presently be used to drive the Rover}
+{Rover Connection Status, Autonomy Switch, Way-point Placement}
+\end{enumerate}
+
+
+\subsubsection{Video / Cameras}
+\begin{enumerate}
+\functRequ{Video Stream Displays}
+{The software should show three video displays in terms of a primary, secondary, and tertiary display.
+These displays will show streamed video feeds from cameras on the Rover and should be able to be individually disabled}
+{The User will need video feeds from the Rover to navigate the competition course and to actuate the Rover arm}
+{Rover Connection Status, Camera Presence Status}
+
+
+\functRequ{Camera Source Selection}
+{For the primary, secondary, and tertiary video displays provide controls to switch which Rover camera is currently active}
+{During competition, the User will frequently be changing the active cameras to best navigate the competition course and interact with objects}
+{Rover Connection Status, Camera Presence Status}
+
+\functRequ{Camera Quality Adjustments}
+{For the primary, secondary, and tertiary video displays provide controls to adjust the camera resolution and/or bit-rate}
+{As the Rover gets farther away from the ground station, connection quality will diminish and require that the video stream qualities be lowered to ensure smooth Rover operation}
+{Video Stream Displays}
+\end{enumerate}
+
+
+\subsubsection{Miscellaneous}
+\begin{enumerate}
+\functRequ{Offline Functionality}
+{The ground station software must function without a connection to the Internet during competition.
+Software elements that require the Internet such as maps must be able to be cached for use offline}
+{The competition is in a remote location with no access to an Internet source}
+{None}
+
+\functRequ{UI Dark Theme}
+{The software must be visually "dark" themed}
+{The dark theme will help ease User eye strain and was also a client request}
+{None}
+
+\functRequ{Getting Started Document}
+{A 1-2 page document describing general useful details for future Rover teams on where to begin for reusing the software}
+{This was requested by the client}
+{All Prior Requirements}
+
+\functRequ{Quick Deployment}
+{This requirement is to package all items necessary for the Ground Station to function in a quickly deployable physical case that can be set-up and software started in less than two minutes during competition setup time}
+{Fast setup times will allow the User to spend extra time testing Rover communications during the setup phases of competition}
+{All Prior Requirements}
+\end{enumerate}
+
+
+\section{Gantt Chart}
+\includepdf{gantt_image}
+
+\section{Stretch Goals}
+\begin{enumerate}
+\functRequ{Autonomy Streams / Overlay}
+{This would display a specialty video stream either independently or via an overlay showing the course obstacles and/or features the Rover is detecting during autonomous mode navigation.
+This would depend on the computational overhead remaining on the Rover processing computer}
+{This would help the team judge autonomous navigational performance of the Rover}
+{Rover Connection Status, Autonomy Switch}
+
+\functRequ{3D Rover Arm Visualization}
+{Represent the arm joint positions using a 3D CAD model of the arm}
+{A 3D representation of the arm and its positioning will make it easier for the user to precisely use the arm to manipulate objects}
+{Rover Connection Status, Arm Connection Status}
+
+\functRequ{Automatic Video Steam Quality Adjustment}
+{The software would automatically detect poor video quality through use of low FPS counts and/or high network latency and use this information to adjust video resolution and bit-rates to increase video stream FPS to reasonable levels}
+{Automatic control of video stream quality would help the User avoid spending time adjusting values during valuable competition time}
+{Video Stream Displays, Camera Quality Adjustments, Video Streams FPS Counters}
+
+\end{enumerate}
+\end{document}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/spring_final_report/01-introduction/introduction.tex

@@ -0,0 +1,30 @@
+\section{Introduction}
+\subsection{Who Requested the Project?}
+This project was requested by the Oregon State University Robotics Club's (OSURC) Mars Rover team.
+
+\subsection{Why Was the Project Requested?}
+This project was requested due to the Mars Rover team's need for a complete and functional ground station in a time frame that the existing software team may not have been able to accomplish. Additionally, new requirements for the ground station meant that the increased complexity was most likely going to require a more dedicated team to complete than the volunteers the club normally has working on the Mars Rover project.
+
+\subsection{What is the Importance of the Project?}
+This project solves some of the most common problems for the Mars Rover team in previous competition years. Historically, the team is allowed a 10-15 minute set up time during competition where the Rover must be turned on, ground station connected, and core systems tested before actually competing in a task. In previous years, the Rover's ground station has normally been a laptop with a handful of random pieces of hardware plugged into it over USB. Many times, this hardware has been damaged during transit and caused problems during the setup phase. Additionally, previous software has often been command line driven and extremely specialized meaning the software is difficult to use, difficult to teach, and has ended up getting re-written with each new Rover competition year.
+
+\subsection{Our Client and Their Role}
+Our client was Nick McComb, team lead and electrical lead of the Mars Rover team for the 2017-2018 competition year. His role was mainly supervisory, helping our group set up the initial requirements for the software, and occasionally making requests for additional features as the year progressed. 
+
+\subsection{Our Team Members and Roles}
+\begin{itemize}
+\item Chris Pham
+	\begin{itemize}
+    \item Rover mapping systems
+	\end{itemize}
+\item Ken Steinfeldt
+	\begin{itemize}
+    \item Rover status systems
+	\end{itemize}
+\item Corwin Perren
+	\begin{itemize}
+	\item Team Manager
+    \item Rover video systems
+    \item Program structure / startup
+	\end{itemize}
+\end{itemize}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/spring_final_report/02-requirementsdoc/requirementsdoc.tex

@@ -0,0 +1,97 @@
+\section{Requirements Document}
+\subsection{Original Document}
+\includepdf[pages=-, frame=true, scale=0.95]{02-requirementsdoc/group-design-requirements.pdf}
+
+\subsection{Additions}
+\subsubsection{Final Revision Document}
+\includepdf[pages=-, frame=true, scale=0.95]{02-requirementsdoc/cs_group30_design_requirements_revision1_1.pdf}
+
+\subsubsection{Description of Changes}
+Version 1.1 of document was approved by all team members and stakeholder on 4/26/2018.
+
+\begin{itemize}
+\item Edited descriptions of competition from University Rover Challenge to Canadian International Rover Challenge
+	\begin{itemize}
+	\item The Mars Rover team changed competitions, so we updated the document to reflect this
+	\end{itemize}
+    
+\item Removed user story for manual video quality adjustment
+	\begin{itemize}
+	\item Our team implemented automatic quality adjustment, so manual adjustment was no longer necessary
+	\end{itemize}
+    
+\item Removed user story about easily seeing when an autonomous run has completed
+	\begin{itemize}
+	\item The new Rover competition does not require this display element
+	\end{itemize}
+    
+\item Removed user story about needing to view live logs
+	\begin{itemize}
+	\item Log viewing was determined to not be needed as there would be too many logs to sort through in a short amount of time
+	\end{itemize}
+    
+\item Removed user story about seeing network latency (round trip time)
+	\begin{itemize}
+	\item The network connection percentage was determined to be correlated with this value enough that this redundant element was not needed
+	\end{itemize}
+
+\item Added constraint that the GUI software must have placeholder for GUI elements and software features that can not be completed due to waiting on Rover team progress
+	\begin{itemize}
+	\item Our team encountered many situations where we could not continue development due to lack of hardware/software on Rover
+    \item This new constraint allows us to still meet requirements if the bottleneck is the Rover team
+	\end{itemize}
+    
+\item Changed functional requirement for joystick statuses so that the SpaceNav mouse had its own requirement
+	\begin{itemize}
+	\item The team changed to a SpaceNav mouse earlier in the year and it was determined that an individual readout for this input device would be convenient
+	\end{itemize}
+    
+\item Changed functional requirement for battery status to battery voltage
+	\begin{itemize}
+	\item The battery status value was determined to be most useful as a voltage, rather than a percentage estimate
+	\end{itemize}
+    
+\item Removed functional requirement for Rover voltage statuses
+	\begin{itemize}
+	\item The Rover design changed so that only the battery voltage is measured
+	\end{itemize}
+    
+\item Changed functional requirement for bogie connection statuses to be individual wheel statuses
+	\begin{itemize}
+	\item The Rover software team got individual status information for each wheel, rather than a two wheel bogie group, and requested this change
+	\end{itemize}
+    
+\item Removed functional requirement for Rover network round trip time
+	\begin{itemize}
+	\item The network connection percentage was determined to be correlated with this value enough that this redundant element was not needed
+	\end{itemize}
+    
+\item Changed functional requirement for Rover arm joystick control to SpaceNav mouse control
+	\begin{itemize}
+	\item The team changed to a SpaceNav mouse over a second joystick for arm control
+	\end{itemize}
+    
+\item Removed functional requirement for way-point navigation path
+	\begin{itemize}
+	\item Expectations for how autonomy on the Rover would work would not easily give our team this information to display
+	\end{itemize}
+    
+\item Changed functional requirement for the autonomy indicator so that it shows whether autonomy is active rather than when autonomy is finished
+	\begin{itemize}
+	\item Changing to the Canadian International Rover Challenge made the old requirement unnecessary
+	\end{itemize}
+    
+\item Removed functional requirement for video FPS counters
+	\begin{itemize}
+	\item FPS counters would have been useful for manual video quality adjustment, but are no longer needed with automatic quality adjustment
+	\end{itemize}
+    
+\item Removed functional requirement for log file viewing
+	\begin{itemize}
+	\item Log files were too large to usefully sort through in a short amount of time
+	\end{itemize}
+    
+\end{itemize}
+
+\subsection{Final Gantt Chart}
+\includepdf[pages=-, frame=true, landscape, scale=0.95]{02-requirementsdoc/final_gantt.pdf}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/spring_final_report/03-designdoc/designdoc.tex

@@ -0,0 +1,5 @@
+\section{Design Document}
+\subsection{Original Document}
+\includepdf[pages=-, frame=true, scale=0.95]{03-designdoc/group-design-document.pdf}
+\subsection{Additions}
+There were no additions to our original design document.

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/spring_final_report/04-techreviewdocs/chris.tex

@@ -0,0 +1,2 @@
+\subsubsection{Chris Pham}
+\includepdf[pages=-, frame=true, scale=0.95]{04-techreviewdocs/phamchr-tech-review.pdf}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/spring_final_report/04-techreviewdocs/corwin.tex

@@ -0,0 +1,2 @@
+\subsubsection{Corwin Perren}
+\includepdf[pages=-, frame=true, scale=0.95]{04-techreviewdocs/tech_review_perrenc.pdf}