Almost done, just editing

cs_capstone_documents/design_document/3_glossary.tex

@@ -3,15 +3,15 @@
 \item ROS - Robot Operating System
 \item GPS - Global Positioning Satellite
 \item OSU - Oregon State University
-\item OSURC - Oregon State University Robics Club
+\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 distrobution based on the classic Debian distrobution.
+\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 readibility and rapid deployment abilities.
+\item Python - A popular scripting language known for it's easy readability and rapid deployment abilities.
 \end{itemize}

cs_capstone_documents/design_document/5_component_design.tex

@@ -1,26 +1,3 @@
-% \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}

cs_capstone_documents/design_document/5_component_design_1.tex

@@ -1,4 +1,4 @@
-\subsection{Human Interface Device Integration - NOT AT WORD COUNT 398/500}
+\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 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.

cs_capstone_documents/design_document/5_component_design_2.tex

@@ -1,17 +1,30 @@
-\subsection{Drive Coordinator - NOT AT WORD COUNT XXX/500}
+\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 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.
+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{:} REPLACE
+\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 REPLACE
+\item The coordinator will take in joystick control information via QSignals.
+\item The coordinator will send Rover drive commands via a ROS topic using "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 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.
+\item If 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 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.

cs_capstone_documents/design_document/5_component_design_3.tex

@@ -1,4 +1,4 @@
-\subsection{Mapping System - NOT AT WORD COUNT 410/500}
+\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.
 
@@ -8,8 +8,8 @@ The mapping sub-system will handle the storing and loading of maps of the compet
 \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.
+Furthermore the mapping must also allow the setting of way-points.
-These waypoints allow the operator to set a location that the rover will travel to once set.
+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.
@@ -29,5 +29,6 @@ In order for it to be useful to the user the map updates must be fast and respon
 
 \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.

cs_capstone_documents/design_document/5_component_design_4.tex

@@ -1,15 +1,25 @@
-\subsection{Way-points Coordinator - NOT AT WORD COUNT XXX/500}
+\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{REPLACE:} REPLACE
+\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 REPLACE
+\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.

cs_capstone_documents/design_document/5_component_design_5.tex

@@ -1,12 +1,26 @@
-\subsection{Arm Visualizer - OF COURSE NOT AT WORD COUNT X/500}
+\subsection{Arm Visualizer}
 \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.
+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}
-Talk about what this section needs to do, establish it's boundaries from a system development standpoint.
+\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}
-Talk about what the system will encompass, from a programming standpoint.
+\begin{itemize}
+\item The arm visualizer will take in position information via a ROS topic using "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}
-Talk about why the system should be designed the way described.
+By taking in position information through ROS topics with "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.

cs_capstone_documents/design_document/5_component_design_6.tex

@@ -1,15 +1,27 @@
-\subsection{Arm Coordinator - NOT AT WORD COUNT XXX/500}
+\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{REPLACE:} REPLACE
+\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 REPLACE
+\item The coordinator will take in SpaveNav control information via QSignals.
+\item The coordinator will send Rover arm commands via a ROS topic using "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 drive commands via the 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 command 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.

cs_capstone_documents/design_document/5_component_design_7.tex

@@ -1,15 +1,29 @@
-\subsection{Video Coordinator - NOT AT WORD COUNT XXX/500}
+\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 video 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{REPLACE:} REPLACE
+\item \textit{Reliability:} The live video stream 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 override the resolution settings in order to get smoother video during times of poor radio reception.
 \end{itemize}
 
 \subsubsection{Design Elements}
 \begin{itemize}
-\item REPLACE
+\item The video coordinator will use "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 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. 
+This will both lower latency and allow the Rover to have to process less data, which are both positives in a remote, battery-powered environment.

cs_capstone_documents/design_document/5_component_design_8.tex

@@ -1,16 +1,26 @@
-\subsection{Statuses Coordinator - NOT AT WORD COUNT XXX/500}
+\subsection{Statuses Coordinator}
 \subsubsection{Overview}
-Includes compass and speed stuff.....
+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{REPLACE:} REPLACE
+\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 REPLACE
+\item The statuses coordinator will take in Rover status messages via ROS topics using "rospy".
+\item The statuses coordinator will update any necessary GUI elements such as QLabel 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.

cs_capstone_documents/design_document/5_component_design_9.tex

@@ -1,15 +1,23 @@
 \subsection{Logging / Recording Coordinator - NOT AT WORD COUNT XXX/500}
 \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{REPLACE:} REPLACE
+\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 REPLACE
+\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.
+

cs_capstone_documents/design_document/6_user_interface_design.tex

@@ -33,8 +33,8 @@ This will list, in the order they were added, the landmark way-points that the u
 \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.
+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's as close to the right hand monitor as it can be.
+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.