Adding an initial version of the document for compile testing

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 roadmap.
+
+		\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}

cs_capstone_documents/design_document/1_introduction.tex

@@ -0,0 +1,45 @@
+\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 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 joysticks 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 Sub-system connection statuses
+  \item On-board sensor readings
+  \item Battery charge level
+  \item System Errors
+  \end{itemize}
+\item Include documentation allowing for easy reuse of the software for future Rover competition years.
+\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.

cs_capstone_documents/design_document/2_references.tex

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

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 Robics Club
+\item NASA - The National Aeronautics and Space Administration
+\end{itemize}
+
+
+\subsection{Definitions}
+\begin{itemize}
+\item Ubuntu - A popular open source Linux distrobution based on the classic Debian distrobution.
+\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 readibility and rapid deployment abilities.
+\end{itemize}

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 is working correctly. 
+The software is going to assume that the software/OS on the rover is going to be 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 correct 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.
+If unable to do so, the software cannot be considered a success.
+\subsubsection{Robustness}
+The Mars Rover Competition 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 lower 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.

cs_capstone_documents/design_document/5_component_design.tex

@@ -0,0 +1,38 @@
+% \subsection{Graphical Interfacing System}
+% Not so sure about this section..... Needs to be molded into what the rest look like
+% \subsubsection{Overview}
+% The Graphical Interfacing System is of particular importance to this project.
+% Information from the rover must be quickly, efficiently, and accurately displayed to the user.
+% The rover will generage large amounts of information in real time that is vital to the success of the operator during the competition.
+% Furthermore, options must be presented to the user that alow rover functionality to be modified on the fly.
+% Without quick and accurate feedback, the operator will be unable to successfully compete in the challenge. 
+% \subsubsection{Design Concerns}
+% The GUI is what the user uses to abstract the underlying software package into a black box for ease of use. 
+% The GUI will show values and display video from the rover. 
+% The GUI will not allow the user to go through the package while in use.
+% \subsubsection{Design Elements}
+% The GUI will use a framework called Qt, which is named for the company by the same name. 
+% This system will take care of any video streams that the rover may have. 
+% The GUI will also visually display values of sensors that are on the rover. 
+% The GUI will show any status using indicators to show any errors for new information for the user to see.
+% The GUI will also translate any information that is hard to visualize data into real life representations of sensors like the IMU. 
+% All of these can be done mostly the GUI itself, and other things will be run with OpenGL code or embedded programs like some ROS packages.
+% \subsubsection{Design Rationale}
+% Without a system that simplifies use of the software, the re-usability of the software decreases and does not meet requirements. 
+% The GUI also feeds information to the team that is necessary for competition.  
+
+\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}
+
+
+
+
+
+

cs_capstone_documents/design_document/5_component_design_1.tex

@@ -0,0 +1,26 @@
+\subsection{Human Interface Device Integration - NOT AT WORD COUNT 398/500}
+\subsubsection{Overview}
+During use of this ground station software, the user will need to be able to interact with a joystick 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 "inputs" or "pygame" libraries for joysticks or the "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.
+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. 

cs_capstone_documents/design_document/5_component_design_2.tex

@@ -0,0 +1,17 @@
+\subsection{Drive Coordinator - NOT AT WORD COUNT XXX/500}
+\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 handling 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{:} REPLACE
+
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item REPLACE
+\end{itemize}
+
+\subsubsection{Design Rationale}

cs_capstone_documents/design_document/5_component_design_3.tex

@@ -0,0 +1,33 @@
+\subsection{Mapping System - NOT AT WORD COUNT 410/500}
+\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 waypoints.
+These waypoints 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.
+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.

cs_capstone_documents/design_document/5_component_design_4.tex

@@ -0,0 +1,15 @@
+\subsection{Way-points Coordinator - NOT AT WORD COUNT XXX/500}
+\subsubsection{Overview}
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{REPLACE:} REPLACE
+
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item REPLACE
+\end{itemize}
+
+\subsubsection{Design Rationale}

cs_capstone_documents/design_document/5_component_design_5.tex

@@ -0,0 +1,12 @@
+\subsection{Arm Visualizer - OF COURSE NOT AT WORD COUNT X/500}
+\subsubsection{Overview}
+The ground control software will allow for the visualization of rover arm movement, allowing the operator to see the actuation of the rover arm while controling it.
+
+\subsubsection{Design Concerns}
+Talk about what this section needs to do, establish it's boundaries from a system development standpoint.
+
+\subsubsection{Design Elements}
+Talk about what the system will encompass, from a programming standpoint.
+
+\subsubsection{Design Rationale}
+Talk about why the system should be designed the way described.

cs_capstone_documents/design_document/5_component_design_6.tex

@@ -0,0 +1,15 @@
+\subsection{Arm Coordinator - NOT AT WORD COUNT XXX/500}
+\subsubsection{Overview}
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{REPLACE:} REPLACE
+
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item REPLACE
+\end{itemize}
+
+\subsubsection{Design Rationale}

cs_capstone_documents/design_document/5_component_design_7.tex

@@ -0,0 +1,15 @@
+\subsection{Video Coordinator - NOT AT WORD COUNT XXX/500}
+\subsubsection{Overview}
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{REPLACE:} REPLACE
+
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item REPLACE
+\end{itemize}
+
+\subsubsection{Design Rationale}

cs_capstone_documents/design_document/5_component_design_8.tex

@@ -0,0 +1,16 @@
+\subsection{Statuses Coordinator - NOT AT WORD COUNT XXX/500}
+\subsubsection{Overview}
+Includes compass and speed stuff.....
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{REPLACE:} REPLACE
+
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item REPLACE
+\end{itemize}
+
+\subsubsection{Design Rationale}

cs_capstone_documents/design_document/5_component_design_9.tex

@@ -0,0 +1,15 @@
+\subsection{Logging / Recording Coordinator - NOT AT WORD COUNT XXX/500}
+\subsubsection{Overview}
+
+\subsubsection{Design Concerns}
+\begin{itemize}
+\item \textit{REPLACE:} REPLACE
+
+\end{itemize}
+
+\subsubsection{Design Elements}
+\begin{itemize}
+\item REPLACE
+\end{itemize}
+
+\subsubsection{Design Rationale}

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 they Ground Station has connection to the drive joystick/s and SpaceNav mouse.
+
+\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 tabbed group that by default will show the controls for starting ROS bag recordings, but will also have a tab for live logs and a third tab for settings to adjusting items such as what map is being shown.
+
+\subsubsection{4: Way-point Entry / Autonomy Controls}
+This block will also for manual entry of GPS coordinates, as are provided by the competition at the beginning of some events.
+The user will be able to chose 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're 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's 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 and SpaceNav mouse.
+Once they start driving, the user will be heavily focused on monitoring video data to make sure they don 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.

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 providing 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.

cs_capstone_documents/design_document/backup_content.tex

@@ -0,0 +1,16 @@
+% chris pham mapping section
+\subsection{Mapping System}
+\subsubsection{Design Concerns}
+The mapping system that will be included in our GUI will be displaying a map of the terrain and location of our rover.
+The mapping must allow for a way-point like system that can be used as guiding points.
+The way-points need to be added by clicking on a map, or entering in a GPS location in the software.
+The way-points need to be editable, and deletable.
+The rover needs to be able to take the way-points on the software and then translate them into actual locations.
+\subsubsection{Design Elements}
+The system will be based around rvis, a package in ROS, that can display an image on a screen.
+The system takes in an image and a GPS location and then the package will return an image and line path of the rover.
+The system gets the package off of Github and then compiles it on the system.
+The system might need extra logic that is not present in rvis and can be written in Python or C to make the package work.
+\subsubsection{Design Rationale}
+Talk about why the system should be designed the way described
+

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"
+}