caperren/osurc_mars_rover_2017_2018
1
0
Fork 0
mirror of https://github.com/OSURoboticsClub/Rover_2017_2018.git synced 2025-11-08 18:21:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

Final design document

Browse Source
This commit is contained in:
Corwin Perren
2017-12-01 23:43:35 -08:00
parent 9b67f5da0e
commit d0d49b46d2
12 changed files with 42 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
cs_capstone_documents/design_document/0_design_document.tex
View File

@@ -102,7 +102,7 @@
\begin{abstract} \begin{abstract}
% 6. Fill in your 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. 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. 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{abstract}
} }

11
cs_capstone_documents/design_document/1_introduction.tex
View File

@@ -5,12 +5,12 @@ The ground station software for the Mars Rover project is the single point of co
\subsection{Scope} \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. 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 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: The controlling software must be able to do at minimum, the following:
\begin{itemize} \begin{itemize}
\item Provide the capability to remotely drive the Rover via joysticks connected to the ground station computer. \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 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 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 Provide visual feedback about the state of the joint positions of the arm as it is being moved.
@@ -20,12 +20,11 @@ The controlling software must be able to do at minimum, the following:
\item Provide a myriad of status information about the Rover's current condition including, but not limited to, the following: \item Provide a myriad of status information about the Rover's current condition including, but not limited to, the following:
\begin{itemize} \begin{itemize}
\item Connection statuses \item Connection statuses
\item Rover Sub-system connection statuses \item Rover component statuses
\item On-board sensor readings \item On-board sensor readings
\item Battery charge level \item Battery charge level
\item System Errors \item System errors
\end{itemize} \end{itemize}
\item Include documentation allowing for easy reuse of the software for future Rover competition years.
\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. 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.

12
cs_capstone_documents/design_document/4_design_considerations.tex
View File

@@ -1,9 +1,9 @@
\subsection{Assumptions} \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. 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.
The software is going to assume that the software/OS on the rover is going to be ROS Kinetic on Ubuntu 16.04. 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 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 correctly interact with the data that is provided by the station.
The rover needs to be connected to the correct network as the rover. The rover needs to be connected to the same network as the rover.
\subsection{General Constraints} \subsection{General Constraints}
@@ -47,12 +47,12 @@ The rover needs to be connected to the correct network as the rover.
\subsection{Stakeholder Concerns} \subsection{Stakeholder Concerns}
\subsubsection{Reliability} \subsubsection{Reliability}
The ground control software must be as reliable as possible. The ground control software must be as reliable as possible.
The rover operator must be able to complete all competition tasks. 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. If unable to do so, the software cannot be considered a success.
\subsubsection{Robustness} \subsubsection{Robustness}
The Mars Rover Competition requires that the rover operate successfully in a variety of environments. 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. 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. 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} \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. 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. Rapid prototyping allows the team to maximize testing time.

6
cs_capstone_documents/design_document/5_component_design_1.tex
View File

@@ -1,6 +1,6 @@
\subsection{Human Interface Device Integration} \subsection{Human Interface Device Integration}
\subsubsection{Overview} \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. 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. The systems that integrate with these HID devices will be some of the most active parts of the ground station software.
\subsubsection{Design Concerns} \subsubsection{Design Concerns}
@@ -13,7 +13,7 @@ Additionally, these input devices may change completely if they are determined t
\subsubsection{Design Elements} \subsubsection{Design Elements}
\begin{itemize} \begin{itemize}
\item The HID integrators will use the "inputs" or "pygame" libraries for joysticks or the "spnav" library for the SpaceNav mouse. \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 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 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. \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.
@@ -22,5 +22,5 @@ Additionally, these input devices may change completely if they are determined t
\subsubsection{Design Rationale} \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. 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. 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. 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. 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.

12
cs_capstone_documents/design_document/5_component_design_2.tex
View File

@@ -1,29 +1,29 @@
\subsection{Drive Coordinator} \subsection{Drive Coordinator}
\subsubsection{Overview} \subsubsection{Overview}
This sub-system will handle taking in raw joystick/s control information, and transforming them into usable drive control commands. 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. 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} \subsubsection{Design Concerns}
\begin{itemize} \begin{itemize}
\item \textit{Reliability:} This node must be incredibly reliable. \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. 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{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. \item \textit{Pause State Responsiveness:} When the pause button is pressed, the Rover will need to stop all movement quickly.
\end{itemize} \end{itemize}
\subsubsection{Design Elements} \subsubsection{Design Elements}
\begin{itemize} \begin{itemize}
\item The coordinator will take in joystick control information via QSignals. \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 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 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. \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. 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. \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} \end{itemize}
\subsubsection{Design Rationale} \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. 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. 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. 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. 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. 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.

4
cs_capstone_documents/design_document/5_component_design_5.tex
View File

@@ -13,7 +13,7 @@ During competition, the user will use these indicators to position the arm, and
\subsubsection{Design Elements} \subsubsection{Design Elements}
\begin{itemize} \begin{itemize}
\item The arm visualizer will take in position information via a ROS topic using "rospy". \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, 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 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 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.
@@ -21,6 +21,6 @@ During competition, the user will use these indicators to position the arm, and
\end{itemize} \end{itemize}
\subsubsection{Design Rationale} \subsubsection{Design Rationale}
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. 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. 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. 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.

6
cs_capstone_documents/design_document/5_component_design_6.tex
View File

@@ -14,14 +14,14 @@ If it runs off and sends continuous arm commands, for example, the physical Rove
\subsubsection{Design Elements} \subsubsection{Design Elements}
\begin{itemize} \begin{itemize}
\item The coordinator will take in SpaveNav control information via QSignals. \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 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. \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. It will then start sending commands again when brought out of the pause state.
\end{itemize} \end{itemize}
\subsubsection{Design Rationale} \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. 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. 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. 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. 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. 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.

12
cs_capstone_documents/design_document/5_component_design_7.tex
View File

@@ -1,21 +1,21 @@
\subsection{Video Coordinator} \subsection{Video Coordinator}
\subsubsection{Overview} \subsubsection{Overview}
The video coordinator will handle taking in video stream data from the Rover, and displaying that data on the GUI. 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. 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. 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} \subsubsection{Design Concerns}
\begin{itemize} \begin{itemize}
\item \textit{Reliability:} The live video stream are a necessity to be able to remotely operate the Rover for most competition events. \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. 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{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. \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. 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} \end{itemize}
\subsubsection{Design Elements} \subsubsection{Design Elements}
\begin{itemize} \begin{itemize}
\item The video coordinator will use "rospy" to retrieve compressed video data streams from the Rover. \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 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 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 automatically handle adjusting the video data so it can be properly shown in the QLabel, even after a resolution adjustment.
@@ -23,7 +23,7 @@ This does not apply if the user override the resolution settings in order to get
\end{itemize} \end{itemize}
\subsubsection{Design Rationale} \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 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. 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. 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. 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.

4
cs_capstone_documents/design_document/5_component_design_8.tex
View File

@@ -14,8 +14,8 @@ Depending on the warning, a low battery for example, it could be the difference
\subsubsection{Design Elements} \subsubsection{Design Elements}
\begin{itemize} \begin{itemize}
\item The statuses coordinator will take in Rover status messages via ROS topics using "rospy". \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 QLabel with their pertinent formatted information as received via the ROS messages. \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 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. \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} \end{itemize}

2
cs_capstone_documents/design_document/5_component_design_9.tex
View File

@@ -1,4 +1,4 @@
\subsection{Logging / Recording Coordinator - NOT AT WORD COUNT XXX/500} \subsection{Logging / Recording Coordinator}
\subsubsection{Overview} \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. 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.

12
cs_capstone_documents/design_document/6_user_interface_design.tex
View File

@@ -11,17 +11,17 @@
\subsection{Zones} \subsection{Zones}
\subsubsection{1: System Statuses / Sensor Readings} \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 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. 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} \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. 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} \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. 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} \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. 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 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. 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} \subsubsection{5: Navigation Way-points Listing}
@@ -82,8 +82,8 @@ This stream has the capability to be disabled and show a placeholder image if th
\subsection{Layout Rationale} \subsection{Layout Rationale}
This screen will be showing the most commonly looked at data for the user driving the Rover. 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. 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 don not run the Rover into anything. 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. 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. 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. 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.

2
cs_capstone_documents/design_document/7_conclusion.tex
View File

@@ -1,3 +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. 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. 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. 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.