Added 2017-2018 mars rover repository.

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

@@ -0,0 +1,21 @@
+@online{
+	thrustmaster,
+	title="Thrustmaster T-16000M Flight Stick",
+    url="https://www.amazon.com/Hercules-2960706-Thrustmaster-T-16000M-Flight/dp/B001S0RTU0"
+}
+
+@online{
+	evo,
+	title="Saitek Cyborg Evo Joystick",
+    url="https://www.amazon.com/Saitek-102989-Cyborg-Evo-Joystick/dp/B0000AW9P1"
+}
+
+@online{
+	x52,
+	title="Logitech G Saitek X52 Flight Control System",
+    url="https://www.amazon.com/Logitech-Saitek-Flight-Control-System/dp/B01LY285ZH/ref=pd_day0_147_4?_encoding=UTF8&psc=1\refRID=050PFE0S4QS28T91V2J7"
+}
+
+%\\
+%\\
+%

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

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

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

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

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

@@ -0,0 +1,316 @@
+\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
+\usepackage{graphicx}
+\graphicspath{{./figures/}}
+
+\usepackage{url}
+\usepackage{setspace}
+\usepackage{multicol}
+
+\usepackage[numbers]{natbib}
+\bibliographystyle{IEEEtranN}
+
+\usepackage{geometry}
+\geometry{textheight=9.5in, textwidth=7in}
+
+% \overfullrule=2in
+
+% 1. Fill in these details
+\def \CapstoneTeamName{			Ground Station Software Team}
+\def \CapstoneTeamNumber{		30}
+\def \GroupMemberOne{			}
+\def \GroupMemberTwo{			}
+\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 will cover my personal team role in developing the OSU Robotics Club's Mars Rover Ground station software.
+            Additionally, it will cover different options for robotics frameworks, radio systems, and joysticks that the Rover team and specifically the Ground Station software team may end up using to complete our software package.
+		\end{abstract}
+		}
+	\end{singlespace}
+\end{titlepage}
+\newpage
+\pagenumbering{arabic}
+\tableofcontents
+\clearpage
+% My stuff here
+\section{Personal Role}
+My role on the Mars Rover Ground Station team will primarily be as a programmer writing code to interface with the team's Mars Rover. 
+As part of this interfacing, the software I help write will allow for remote control of the Rover, the showing of video streams broadcast from the Rover, and the showing of Rover status and mapping information.
+An additional role I will have will be as a bridge between the rest of our capstone team and the Mars Rover group, as needed.
+In the past, I have both been a member of the Mars Rover team and the electrical team lead, so my knowledge of the competition as well as those in charge of the Rover team will help facilitate easy communication.
+\section{Goals}
+The goals of the rest of this document are to cover three separate technological aspects of the Mars Rover Ground Station that have multiple viable solutions. Evaluation of three of these options will then culminate in choosing one of one to be used on the Ground Station.
+The first technology to be looked at will be the robotics framework the software will be interfacing with. As the Mars Rover is a complicated robot, choosing the right option here will affect how difficult it will be to interface with the Rover's systems.
+The second technology will cover the radio system options the Ground Station could use to communicate with the Rover. Selection of this system will determine how much and how fast data can be transmitted between the Ground Station and Rover, both of which are major factors in how usable the Rover is during competition.
+The final technology will be the options for USB joysticks that will be used to drive the Rover remotely using this Ground Station software.
+
+% Robotics Frameworks
+\section{Robotics Frameworks}
+\subsection{Overview}
+When working with large robotic systems there are often many sensors, actuators, computers, and cameras that all need to work in unison to make the platform perform its desired task.
+In order to facilitate this intercommunication most robots use off the shelf robotics frameworks so that programmers can focus on implementing higher level features. The result is that less time is spent on lower leveling coding for things like sending messages between robot system nodes and more time can be spend implementing features such as obstacle avoidance.
+As the Mars Rover Ground Station software is interfacing with a complicated robot, it is definitely important to consider different options for these frameworks to choose the one best suited to the project.
+
+\subsection{Criteria}
+\begin{itemize}
+\item \textit{Feature Coverage}: Ideally the framework should take care of as many lower level tasks as possible including, but not limited to, inter-node communications, simplified computer vision, localization, motion-planning, and built-in simulators.
+\item \textit{Hardware Compatibility}: The framework would preferably have pre-built nodes/libraries/drivers for common hardware like GPS and cameras.
+\item \textit{Documentation}: In order to facilitate rapid development, ample and well-maintained documentation is a must.
+\item \textit{Community / Resource Availability}: To supplement official documentation, the framework should have a well-developed community to allow for easy answering of framework programming questions when encountered as well as example code when needed.
+\item \textit{Development Time}: Due to the limited time constraints, the framework used should allow for fast development of the software.
+This component will take into account all the previous criteria.
+\end{itemize}
+
+\subsection{Potential Options}
+\subsubsection{Custom Framework}
+This option involves writing a framework from scratch in-house. 
+Due to its popularity within the Mars Rover team, Python would most likely be used as the language of choice to develop such a system.
+A custom framework would have to incorporate writing nodes for handling GPS localization, camera processing, computer-vision based obstacle avoidance, drive system control, arm system control, and many others with little to no starting code. 
+And important aspect of this system, with respect to the ground control software, is that a custom system would need specialty sending and receiving nodes for handling transmission of control, status, and video data.
+
+\begin{itemize}
+\item \textit{Feature Coverage}: Complete coverage is possible.
+\item \textit{Hardware Compatibility}: Complete hardware support is possible.
+\item \textit{Documentation}: Only pre-made documentation for libraries is available.
+\item \textit{Community / Resource Availability}: Reliant on availability for any libraries used.
+\item \textit{Development Time}: Development will take an incredibly long amount of time.
+\end{itemize}
+
+\subsubsection{Mobile Robotics Programming Toolkit (MRPT)}
+The Mobile Robotics Programming Toolkit is a robotics framework developed to handle the difficult aspects of robot localization, mapping, computer vision, and motion planning. 
+While this does not cover all of the modules needed for the Mars Rover team, nor the ground station, it would greatly simplify some of the design work for the more challenging aspects of the Rover. 
+Custom nodes would still have to be made for drive and arm system control as well as custom messaging nodes.
+
+\begin{itemize}
+\item \textit{Feature Coverage}: Partial coverage.
+Still requires writing complex nodes for some features.
+\item \textit{Hardware Compatibility}: Partial hardware support.
+Custom additions would be needed to support the rest of the robot hardware.
+\item \textit{Documentation}: A reasonable number of official tutorials are available.
+\item \textit{Community / Resource Availability}: Help can be found on stackoverflow.com with the search tag "mrpt".
+\item \textit{Development Time}: Development will take a moderate amount of time.
+This option still requires a significant amount of custom node development.
+\end{itemize}
+
+
+\subsubsection{Robot Operating System (ROS)}
+ROS is the most popular robotics framework in the world, and it shows in terms of the complete package it provides. 
+Nodes can be found, both official and unofficial, for most features the Robotics Club's Mars Rover might need.
+This includes localization and mapping, computer-vision, obstacle avoidance, motion planning, arm and drive system nodes, and and robust messaging framework.
+For any nodes that are not complete, they often provide a great starting point so we would at least not be starting from scratch.
+
+
+\begin{itemize}
+\item \textit{Feature Coverage}: Excellent coverage.
+Will require some modification of some feature nodes, but most are pre-built and ready to use.
+\item \textit{Hardware Compatibility}: Excellent hardware support.
+ROS comes with support for many robotic hardware tools, and abstracted nodes also for easy modification for custom hardware when needed.
+\item \textit{Documentation}: Excellent documentation and tutorials on ROS's website.
+\item \textit{Community / Resource Availability}: Many forums and sites provide help with ROS, as well as many Youtube video series dedicated to ROS.
+\item \textit{Development Time}: Development time will be greatly reduced due to pre-built nodes and great documentation.
+\end{itemize}
+
+\subsection{Discussion}
+In terms of feature coverage, ROS seems to be most complete. However, depending on how difficult implementing the remaining nodes might be, MRPT might not be too far off in terms of complexity. A custom solution has the benefit of having complete coverage once the code is written, but would take considerably longer to write overall.
+
+With regards to hardware compatibility, it's a similar spread as with feature coverage. ROS is most compatible with the least amount of effort from the start. MRPT would require a fair bit of work to get working with a lot of the hardware that is not directly related to mapping, localization, and computer-vision. The custom solution again has the benefit of having complete hardware support once done, but could require a very large amount of time to get all hardware working.
+
+Documentation-wise, the custom solution is the worst option. Any development will depend on general programming documentation for the language used, and any that exists for libraries in that language. MRPT has some documentation, but it's mostly limited to tutorials and provides less in-depth information for programmers wanting to adjust MRPT to a custom application. ROS, on the other hand, has excellent documentation and many tutorials.
+
+The community and resource availability for the custom solution is essentially non-existent. Any community and resources would have to be internal to the Rover team or Ground Station software team. MRPT at least has a small community and is active on stackoverflow to answer questions when needed. ROS's community and availability is excellent by contrast. There are a multitude of forums, but official and unofficial providing support, and ample third party resources providing examples and videos.
+
+Lastly, when it comes to development time ROS appears to win in this category. The combination of many pre-built nodes plus excellent documentation and community support helps make development much speedier than other options. MRPT is next best, with at least a starting framework to begin with and build off of. The custom solution would be a nightmare in terms of development time and would likely not be complete before competition.
+
+\subsection{Conclusion}
+For the choice of a robotics framework ROS definitely seem to be most fully-featured and quickest to implement framework and wins out in every single category compared to MRPT or a custom solution.
+Additionally, the fact that ROS has been actively developed for ten years shows in its mature and robust nodes and documentation that should allow the Rover team and our Ground Station software team to more quickly develop the desired application.
+
+% Radio Systems
+\section{Radio System}
+\subsection{Overview}
+During the University Rover Challenge competition, most of the events that take place are remote control events where the user must remotely operate their Rover from a remote base station. During both the remotely operated and autonomous events, data will need to be sent back and forth between the Rover and its base station. As such, the radios used make a huge difference in how well the Rover performs. Here, we'll look into a few different options for radio systems.
+
+\subsection{Criteria}
+\begin{itemize}
+\item \textit{Cost}: The radio must be as low cost as possible while still providing all needed functions.
+\item \textit{URC Radio Rules}: The radio must meet the URC competition radio requirements.
+\item \textit{Data Throughput}: The radio must allow for high enough data throughput to allow for comfortable remote driving of the Rover.
+\item \textit{Range}: The radio must be able to reach at least 1km away per URC requirements.
+\end{itemize}
+
+\subsection{Potential Options}
+\subsubsection{RockBLOCK Mk2 Iridium SatComm}
+This satellite modem would allow for remote communications with the Rover anywhere the Rover has line of sight to the open sky. While more difficult to come by, and more difficult to interface with, these radios would near guarantee consistent communication between the Rover and ground station due to the open nature of the Utah desert where the competition will take place.
+
+\begin{itemize}
+\item \textit{Cost}: The radio is expensive at \$250, and also has costs per message.
+\item \textit{URC Radio Rules}: This radio would meet URC requirements with prior approval.
+\item \textit{Data Throughput}: The data throughput of this radio would be abysmal at one message every 10 seconds. 
+\item \textit{Range}: Range is essentially unlimited in the open desert of the competition area.
+\end{itemize}
+
+\subsubsection{LoRa 433MHz Radio}
+These small serial radios are cheap and easy to use, but have low power output and require an amateur radio license to operate.
+These radios are quite easy to acquire and provide a simple abstract serial-over-radio interface that is easy to use.
+
+\begin{itemize}
+\item \textit{Cost}: The radio is incredibly cheap at \$20 each.
+\item \textit{URC Radio Rules}: This radio would meet URC requirements with prior approval and licensing.
+\item \textit{Data Throughput}: The data throughput of this radio would be quite slow at 19.2 kbaud per second, but enough to drive the Rover and receive status messages.
+\item \textit{Range}: Line of sight these radios are rated at 2km.
+\end{itemize}
+
+\subsubsection{Ubiquity Rocket M2}
+The Rocket M2 radios are 2.4GHz long-range WiFi radios that provide a remote Ethernet link between two stations. These radios are reasonably easy to come by, and while requiring some networking knowlege to set up, provides a simple-to-use interface that natively will integrate with Robotics Frameworks such as ROS.
+
+\begin{itemize}
+\item \textit{Cost}: The radio is expensive at \$250 each.
+\item \textit{URC Radio Rules}: This radio meets URC requirements as it is on the pre-approved radios list.
+\item \textit{Data Throughput}: The data throughput of these radios are up to 100MBit per second, enough to do control and status data as well as Rover video.
+\item \textit{Range}: Line of sight, these radios have been tested at up to 1.25km by Rover team members.
+\end{itemize}
+
+\subsection{Discussion}
+From a cost perspective, the LoRa radios definitely win out at a mere \$20. 
+The Rocket M2 and RockBLOCK are matched in price, but barring being beyond the range limit of the M2 radios, the RockBLOCK is not a very good contender in terms of throughput for price.
+
+All of these radios are valid by URC competition rules, although both the satellite radio and LoRa radio would require express prior permission from the URC judges.
+
+In terms of data throughput, the Rocket M2 is an easy winner, especially when considering the fact that it's fast enough to also send video data over rather than having to have a second radio for video transmission. The LoRa radio would be reasonable if only control and status information was being sent, but the satellite RockBLOCK would basically be useless for remote operation. To use the RockBLOCK you'd have to send the Rover way-points and let the Rover drive on its own.
+
+Range-wise the satellite modem is the best option, but overkill for what the requirements of the competition are. LoRa is the next best option with 2km line of sight, but it is worth noting that the M2 radios also have a range greater than what is needed during competition.
+
+\subsection{Conclusion}
+Not surprisingly the RockBLOCK is not a reasonable option for this project. However, both the LoRa and M2 radios have enough data throughput and range to make it through the competition happily. With this in mind, the Rocket M2 radios are the optimal radio to use. While they are expensive at \$250, they have enough bandwidth to transmit video data as well as control data meaning the team can save the costs of a secondary radio system for video.
+
+% Joysticks
+\section{Joysticks}
+\subsection{Overview}
+The ground station software's primary function is to allow for remote control of the Rover via the use of joysticks. Therefore, it is not surprising that the choice of joystick is important as it is the primary point of contact between a driver and the Rover itself. Below we'll compare a few different choices for USB joysticks.
+
+\subsection{Criteria}
+\begin{itemize}
+\item \textit{Cost}: Due to cost restrictions imposed by the competition rules, keeping the cost as low as possible is a priority.
+\item \textit{Control Feature Set}: The joystick chosen should have pitch, roll, a four position hat stick, at least five buttons, and a throttle slider.
+\item \textit{Ambidextrous Grip}: As two joysticks will be bought, one to use with the left hand and one with the right, it must be one capable of being used with either hand from the factory.
+\item \textit{Reviews}: User reviews for the joystick must imply that the joystick is well-made and is unlikely to fail during competition.
+\end{itemize}
+
+\subsection{Potential Options}
+\subsubsection{Logitech Saitek X52}
+The Saitek X52 Flight Control joystick has a large airplane style throttle control as well as a normal ambidextrous joystick.
+The throttle unit and joystick are separate pieces that are connected via a cable. \cite{x52}
+
+\begin{itemize}
+\item \textit{Cost}: Expensive at \$142.
+\item \textit{Control Feature Set}: Exceeds minimum feature set.
+\item \textit{Ambidextrous Grip}: Yes
+\item \textit{Reviews}: This joystick has slightly better than average reviews, but complaints seem to focus on build quality issues where the joystick wears out prematurely.
+\end{itemize}
+
+\subsubsection{Logitech Saitek Evo}
+The Saitek Evo joystick is a simple single-piece unit that has nine buttons, an 8-way POV hat, and a single throttle control. This is a pretty generic joystick. \cite{evo}
+
+\begin{itemize}
+\item \textit{Cost}: Very cheap at \$45.
+\item \textit{Control Feature Set}: Exceeds minimum feature set.
+\item \textit{Ambidextrous Grip}: Yes
+\item \textit{Reviews}: This joystick gets average reviews, with major complaints being issues with the joystick not staying centered as it gets worn in, causing small amounts of drift on the control axes.
+\end{itemize}
+
+\subsubsection{Hercules Thrustmaster T16000M}
+The Hercules Thrustmaster T16000M is a plain looking, but fully featured joystick with 16 buttons, one 8-way POV hat, a throttle slider, and a special hall-effect axis sensor system that provides greater precision than standard analog joysticks. \cite{thrustmaster}
+
+\begin{itemize}
+\item \textit{Cost}: Low-mid cost at \$65.
+\item \textit{Control Feature Set}: Exceeds minimum feature set.
+\item \textit{Ambidextrous Grip}: Yes
+\item \textit{Reviews}: This joystick gets better than average reviews with most complaints focusing on the joystick feeling cheap while performing admirably.
+\end{itemize}
+
+\subsection{Discussion}
+From a cost perspective, the Saitek Evo wins out, but only barely. The Thrustmaster is a close second, while the X52 is overly expensive at the cost of both of the previous joysticks put together. 
+
+All of the joysticks exceed the needed feature sets and are all ambidextrous, so in these categories they're all on an even playing field.
+
+When reviews are factored in, the Thrustmaster is well-regarded whereas the other two get average reviews that aren't too spectacular.
+
+\subsection{Conclusion}
+Once you combine the excellent reviews with the reasonably cheap costs of the Thrustmaster T16000M, it comes out as the clear winner for the joystick category. It is definitely the best performance per dollar. The Saitek Evo is a close second, but the the X52 should not even be considered as an option.
+
+\section{References}
+\bibliography{bibliography}
+\end{document}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/tech_review/phamchr/latexmkrc

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

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

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

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/tech_review/phamchr/techreview.tex

@@ -0,0 +1,284 @@
+\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
+\usepackage{graphicx}
+\graphicspath{{./figures/}}
+
+\usepackage{url}
+\usepackage{setspace}
+\usepackage{multicol}
+\usepackage{pdflscape}
+\usepackage{pdfpages}
+\usepackage{hyperref}
+\usepackage{subfig}
+\usepackage{caption}
+\usepackage{geometry}
+\geometry{textheight=9.5in, textwidth=7in}
+
+% \overfullrule=2in
+
+% 1. Fill in these details
+\def \CapstoneTeamName{			Ground Station Software Team}
+\def \CapstoneTeamNumber{		30}
+\def \GroupMemberOne{			Christopher Pham}
+\def \GroupMemberTwo{}
+\def \GroupMemberThree{}
+\def \CapstoneProjectName{		OSU Robotics Club\\Mars Rover Ground Station}
+\def \CapstoneSponsorCompany{	OSU Robotics Club}
+\def \CapstoneSponsorPerson{	Nick McComb}
+
+
+
+%Personal \newcommands
+
+\newcommand{\functRequ}[4]{
+\item #1%
+\par
+\begin{itemize}
+\item \textit{Description:} #2.%
+\item \textit{Rationale:} #3.%
+\item \textit{Dependencies:} #4%
+\end{itemize}
+}
+
+
+
+% 2. Uncomment the appropriate line below so that the document type works
+\def \DocType{	%Problem Statement
+				%Requirements Document
+				Technology Review
+				%Design Document
+				%Progress Report
+			 }
+			
+\newcommand{\NameSigPair}[1]{
+  \par
+  \makebox[2.75in][r]{#1} 
+  \hfill
+  \makebox[3.25in]{
+      \makebox[2.25in]{\hrulefill} 
+      \hfill
+      \makebox[.75in]{\hrulefill}
+  }
+  \par\vspace{-12pt} 
+  \textit{
+      \tiny\noindent
+      \makebox[2.75in]{} 
+      \hfill
+      \makebox[3.25in]{
+          \makebox[2.25in][r]{Signature} 
+          \hfill
+          \makebox[.75in][r]{Date}
+      }
+  }
+}
+% 3. If the document is not to be signed, uncomment the command below
+\renewcommand{\NameSigPair}[1]{#1}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+\begin{titlepage}
+	\pagenumbering{gobble}
+	\begin{singlespace}
+		% 4. If you have a logo, use this includegraphics command to put it on the coversheet.
+        \begin{minipage}{7in}
+			\centering
+			\hspace*{-.7in}
+			$\vcenter{\hbox{\includegraphics[height=4cm]{Oregon_State_College_of_Engineering_Logo}}}$
+			\hspace*{.2in}
+			$\vcenter{\hbox{\includegraphics[height=2.5cm]{OSURCLogoOrange}}}$
+		\end{minipage}
+
+		\par\vspace{.35in}
+		\centering
+		\scshape{
+			\huge CS Capstone \DocType \par
+			{\large\today}\par
+			\vspace{.5in}
+			\textbf{\Huge\CapstoneProjectName}\par
+			\vfill
+			{\large Prepared for}\par
+			\Huge \CapstoneSponsorCompany\par
+			\vspace{5pt}
+			{\Large\NameSigPair{\CapstoneSponsorPerson}\par}
+			{\large Prepared by }\par
+			Group\CapstoneTeamNumber\par
+			% 5. comment out the line below this one if you do not wish to name your team
+			\CapstoneTeamName\par 
+			\vspace{5pt}
+			{\Large
+				\NameSigPair{\GroupMemberOne}\par
+				\NameSigPair{\GroupMemberTwo}\par
+				\NameSigPair{\GroupMemberThree}\par
+			}
+			\vspace{20pt}
+            \begin{abstract}
+            This document examines the differences between three technologies in three different subjects.
+            Python GUI frameworks are going to be used on the project to show and abstract information coming from the rover towards the end user.
+            The arm and graphical visualizers will be used to show how an object or the rover's state.
+            Mapping software is going to be needed for any autonomy or any view of dangers on the map.
+            This document goes over these different subjects and reviews technologies that will be suited for the system.
+
+		\end{abstract}
+		}
+	\end{singlespace}
+\end{titlepage}
+\newpage
+\pagenumbering{arabic}
+\tableofcontents
+\clearpage
+
+% 8. now you write!
+\section{Introduction}
+My section of the technology review document is going to revolve around the "graphical" side of the ground station software. 
+\section{Python GUI Frameworks}
+\subsection{Overview}
+A graphical user interface (GUI) is used by a program to obscure and allow the user to access and interact with objects instead of a command line interface system.
+The GUI allows for people to interact with the system even if they are not trained.
+A GUI framework is a pack of tools that will build a GUI using a commands and bindings and will allow for bindings across many systems like Linux, OS X, Windows, Android, and iOS.
+A framework also comes with an added benefit of being made and maintained by the public or a company instead of being made in-house.
+
+\subsection{Criteria}
+Given the restrictions at the request of our client, I've chosen to focus more towards Python based implementations of graphical user interfaces. 
+Some potential choices can be used in other languages but that is not a main focus point of this project.
+The interface needs to be able to go into full-screen and needs to be able to change the colors of the GUI itself to a darker theme.
+It also needs to support many video streams.
+
+\subsection{Potential Choices}
+\subsubsection{PyQT}
+PyQt is a set of bindings for Python for the GUI framework Qt developed by The Qt company. \cite{PyQt}
+PyQt can run on any platform that can support Qt like Windows, OS X, Linux, iOS, and Android.
+Qt is not just a GUI toolkit, but also comes with "abstractions of network sockets, threads, Unicode, regular expressions, SQL databases, SVG, OpenGL, XML, a fully functional web browser, a help system, a multimedia framework, as well as a rich collection of GUI widgets." \cite{PyQt}
+Qt also includes a designer called Qt Designer and PyQt is able to generate Python code from it.
+
+\subsubsection{Tkinter}
+Tkinker is GUI framework that is included in any Python 2 or 3 installation package.
+Tkinker itself is a wrapper on top of the Tcl/Tk package from ActiveState. \cite{Tkinker}
+Tkinker supports "most Unix platforms, as well as on Windows systems". \cite{Tkinker}
+Tcl/Tk comes with a BSD-like license that allows for commercial use of their framework.
+
+\subsubsection{Kivy}
+Kivy is an open source framework for Python that is under MIT license. \cite{Kivy}
+Kivy runs on Linux, Windows, OS X, Android, iOS and can use the same code for all platforms.
+It can natively use most inputs and devices including "WM\_Touch, WM\_Pen, Mac OS X Trackpad and Magic Mouse, Mtdev, Linux Kernel HID, TUIO". \cite{Kivy}
+Kivy also includes hardware acceleration using OpenGL ES 2.
+
+\subsection{Comparison}
+With all these frameworks, Tkinker/(Tcl/Tk) and PyQt/(Qt) are also possible on other languages using some other wrappers, unlike Kivy.
+However, unlike the other frameworks, which are built in C or C++, Kivy is natively built in Python.
+All the frameworks support OpenGL contexts (windows/frames) only PyQt and Kivy support OpenGL acceleration on the menus which might be necessary for how many video streams we are pushing.
+Kivy in contrast to the other frameworks also supports multi-touch enabled devices like phones, and tablets unlike the other frameworks.
+Tkinker however is included in all builds of Python released, making it very easy for quick and lightweight programming and prototyping compared to other frameworks.
+Qt requires payment for any commercial product, unlike the others.
+
+\subsection{Decision}
+My suggestion for this project would be PyQt.
+PyQt's fee that Qt asks for is not applied to this project.
+PyQt and Qt in general have good support and documentation because its longevity, numerous tutorials, and support by the community.
+Kivy would work well for the project if it had more documentation but its OpenGL rendering would be fantastic for design ideas we have.
+Kivy is also built more towards multi-input systems which is not our focus.
+Tkinker would work well for small projects but the lack of OpenGL acceleration might be questionable for the all the video streams that might be handled on the system.
+
+\section{Arm/Graphical Visualization}
+\subsection{Overview}
+For this project, one important aspect is going to be visualizing how the arm is currently moving in respect to the rover itself and showing how the user input changes the arm visually.
+The need comes from the integration between our project and the other senior project that revolves around the rover arm.
+Without the visualization, the other senior project can not test to see if their arm works correctly on the rover and for later competition usage. 
+
+\subsection{Criteria}
+If this was to be made using the command line or via text, it would be very confusing.
+Per requests, the arm visualizer needs to resemble the arms.
+The other requirements would be needing to able to run on Linux (Ubuntu) and easy integration with the ROS (Robot Operating System) on the Rover. 
+
+\subsection{Potential Choices}
+\subsubsection{ROS Visualization}
+Inbuilt into ROS, there is a package called rvis which allows for the system to visualize objects using displays.
+The included displays in rvis are \cite{rvis}:
+\begin{center}
+\begin{tabular}{c c c c}
+Axes & Effort & Camera & Grid \\
+Grid Cells & Image & Interactive Marker & Laser Scan \\
+Map & Markers & Path & Point \\
+Pose & Pose Array & Point Cloud (two types) & Polygon \\
+Odometry & Range & RobotModel & TF \\
+& Wrench & Oculus & \\
+\end{tabular}
+\end{center}
+The package is also very well documented with sample code and projects to show how some interactions happen.
+
+\subsubsection{OpenGL visualization}
+We can build a system using one of our GUI frameworks to give us access to an OpenGL window.
+In that window, we can then write to it using some OpenGL and Python code to form the arm. 
+We can use any shapes we want like line pieces or even importing the arm's 3D model and modifying it from there. 
+Inverse kinematics is needed to get the joints working correctly if the arm is moving from point to point, and normal kinematics to get the final location from arm segment movements.
+We would be able to control how fast the video/render would be refreshing, drawing, or rendering size which would allow for granularity control to reduce CPU or GPU usage.
+
+\subsubsection{Moveit Simulator}
+We could also use simulator software that can take the signals from the inputs/joysticks and then send them both to the rover and simulator.
+The simulator can emulate what the arm SHOULD do and can be imported from the other senior project that is already simulating the arm using the same software.
+The video can be captured using OpenCV or open source prorgrams like Istanbul to stream the video to the GUI.
+
+\subsection{Comparison}
+Compared to ROS and OpenGL, Moveit actually just emulates the arm while the others calculate how the arm should move using inverse kinematics.
+ROS has all built-in displays in which many other things like mapping software and waypoint systems would be much simpler than building our own system for the project.
+OpenGL provides flexibility compared to the others but does not include any built-in packages or anything of the sort.
+
+\subsection{Decision}
+I think that the visualization should be a mix of ROS and some custom OpenGL.
+The combination of the two allow for access to packages that are included and built around ROS while also including the flexibility that is included with OpenGL. 
+The arm can be visualized using the included packages like rvis, but other things like the IMU (Inertia Measurement Unit) might be hard to visualize in rvis and would be possible with custom OpenGL code.
+
+\section{Mapping Software}
+\subsection{Overview}
+Another part of the project is the mapping system.
+In competition, the Robotics team wishes to see where the rover is currently on the map.
+We are going off the assumption that the way-point system needs to be built, but we can use a package to deal with the GPS location and mapping.
+
+\subsection{Criteria}
+A requirement would be ease of integration between the rover and ground station.
+Another would be the ability to use the mapping software with a reasonable amount of delay or no Internet at all.
+
+\subsection{Potential Choice}
+\subsubsection{ROS Packages}
+There are inbuilt packages for GPS and GPS location parsing in the ROS subsystem.
+Using packages like rvis or mapviZ can display the map and transform the map image to display the correct location.
+The location can be calculated on the rover or on the ground control system.
+
+\subsubsection{Google Maps/Earth}
+Using the same packages as above, instead of parsing the location on the robot or ground control system, the rover/ground station can parse the information given to it by sending it to Google.
+This would remove any need for calculating location at all and the map would be generated by Google.
+
+\subsubsection{Custom Mapping/Packages}
+We could build a system using our own polling and parsing of the GPS information.
+This can be represented by texture location using an external package like Kartograph \cite{karto} for Python.
+Kartograph can then return an SVG (Scalable Vector Graphics) which can be displayed on the GUI.
+
+
+\subsection{Comparison}
+ROS and Google are very similar with the only differentiating thing about the two would be where the information being sent, locally or via ground control to a remote server.
+ROS and the custom software are very similar but uses in-house code or open source code.
+The only difference between all of these is how the GPS data is analyzed and texture map is generated and then put onto the screen.
+\begin{figure}[h]
+\centering
+\subfloat[Map Visualization Using Mapviz Package \cite{mapviz}]{\label{ref_label1}\includegraphics[width=0.33\textwidth]{mapviz}}
+\subfloat[Google Maps using Decimal Degrees]{\label{ref_label2}\includegraphics[width=0.33\textwidth]{chrome_2017-11-21_13-32-08}}
+\subfloat[Kartograph Render \cite{karto}]{\label{ref_label3}\includegraphics[width=0.33\textwidth]{detail}}
+\captionsetup{justification=centering}
+\centering\caption{Map Visualization}
+\end{figure}
+
+\subsection{Decision}
+I think that the project should use the ROS packages because all of those are open source and packages are constantly made for problems like this.
+ROS also has integrations between other packages like rvis and mapping software.
+And in the environment where the competition is going to take place, the speed and the Internet quality might be sub-par and any external requests would make the system react very slowly or be completely off.
+Another problem with using Google would be that we can not use their mapping system to do anything autonomous as stated from their ToS (Terms of Service) and we would need to use some other system like OpenSourceMaps. 
+If we had to build a custom solution to this project, Kartograph would be good.
+Kartograph produces SVG files which Qt takes for but the lack of documentation might make building the project longer than alloted.
+
+\begin{thebibliography}{9}
+\bibitem{PyQt}\href{https://riverbankcomputing.com/software/pyqt/intro}{"What is PyQt." Riverbank Computing Limited. November 2017}
+\bibitem{Tkinker}\href{https://docs.python.org/2/library/tkinter.html}{"Tkinker -- Python interface to Tcl/TK" Python Software Foundation. November 2017}
+\bibitem{Kivy}\href{https://kivy.org/}{"Kivy." Kivy Organization. November 2017}
+\bibitem{rvis}\href{http://wiki.ros.org/rviz/DisplayTypes}{"rvis/DisplayTypes" David Gossow. August 17, 2013}
+\bibitem{mapviz}\href{https://github.com/swri-robotics/mapviz}{"Mapviz." swri-robotics, November 21, 2017}
+\bibitem{karto}\href{http://kartograph.org/}{"Kartograph - A Simple and lightweight frameowkr for createing interavtive vector maps"}
+\end{thebibliography}
+\end{document}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/tech_review/steinfek/latexmkrc

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

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/tech_review/steinfek/main.bbl

@@ -0,0 +1,31 @@
+% Generated by IEEEtranN.bst, version: 1.14 (2015/08/26)
+\begin{thebibliography}{2}
+\providecommand{\natexlab}[1]{#1}
+\providecommand{\url}[1]{#1}
+\csname url@samestyle\endcsname
+\providecommand{\newblock}{\relax}
+\providecommand{\bibinfo}[2]{#2}
+\providecommand{\BIBentrySTDinterwordspacing}{\spaceskip=0pt\relax}
+\providecommand{\BIBentryALTinterwordstretchfactor}{4}
+\providecommand{\BIBentryALTinterwordspacing}{\spaceskip=\fontdimen2\font plus
+\BIBentryALTinterwordstretchfactor\fontdimen3\font minus
+  \fontdimen4\font\relax}
+\providecommand{\BIBforeignlanguage}[2]{{%
+\expandafter\ifx\csname l@#1\endcsname\relax
+\typeout{** WARNING: IEEEtranN.bst: No hyphenation pattern has been}%
+\typeout{** loaded for the language `#1'. Using the pattern for}%
+\typeout{** the default language instead.}%
+\else
+\language=\csname l@#1\endcsname
+\fi
+#2}}
+\providecommand{\BIBdecl}{\relax}
+\BIBdecl
+
+\bibitem[Wiki()]{rossupport}
+R.~Wiki, ``Introduction.''
+
+\bibitem[Group()]{macunix}
+T.~O. Group, ``The open group official register of unix certified products.''
+
+\end{thebibliography}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/tech_review/steinfek/main.tex

@@ -0,0 +1,293 @@
+\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
+\usepackage{graphicx}
+\graphicspath{{./figures/}}
+
+\usepackage{url}
+\usepackage{setspace}
+\usepackage{multicol}
+\usepackage[numbers]{natbib}
+\bibliographystyle{IEEEtranN}
+
+\usepackage{geometry}
+\geometry{textheight=9.5in, textwidth=7in}
+
+% \overfullrule=2in
+
+% 1. Fill in these details
+\def \CapstoneTeamName{			}
+\def \CapstoneTeamNumber{		30}
+\def \GroupMemberOne{			Kenneth Steinfeldt}
+\def \GroupMemberTwo{			Christopher Pham}
+\def \GroupMemberThree{			Corwin Perren}
+\def \CapstoneProjectName{		OSU Robotics Club\\Mars Rover Ground Station}
+\def \CapstoneSponsorCompany{	OSU Robotics Club}
+\def \CapstoneSponsorPerson{	Nick McComb}
+
+% 2. Uncomment the appropriate line below so that the document type works
+\def \DocType{	Problem Statement
+				%Requirements Document
+				%Technology Review
+				%Design Document
+				%Progress Report
+			 }
+			
+\newcommand{\NameSigPair}[1]{
+  \par
+  \makebox[2.75in][r]{#1} 
+  \hfill
+  \makebox[3.25in]{
+      \makebox[2.25in]{\hrulefill} 
+      \hfill
+      \makebox[.75in]{\hrulefill}
+  }
+  \par\vspace{-12pt} 
+  \textit{
+      \tiny\noindent
+      \makebox[2.75in]{} 
+      \hfill
+      \makebox[3.25in]{
+          \makebox[2.25in][r]{Signature} 
+          \hfill
+          \makebox[.75in][r]{Date}
+      }
+  }
+}
+% 3. If the document is not to be signed, uncomment the command below
+\renewcommand{\NameSigPair}[1]{#1}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+\begin{titlepage}
+	\pagenumbering{gobble}
+	\begin{singlespace}
+		% 4. If you have a logo, use this includegraphics command to put it on the coversheet.
+        \begin{minipage}{7in}
+			\centering
+			\hspace*{-.7in}
+			$\vcenter{\hbox{\includegraphics[height=4cm]{Oregon_State_College_of_Engineering_Logo}}}$
+			\hspace*{.2in}
+			$\vcenter{\hbox{\includegraphics[height=2.5cm]{OSURCLogoOrange}}}$
+		\end{minipage}
+
+		\par\vspace{.35in}
+		\centering
+		\scshape{
+			\huge CS Capstone \DocType \par
+			{\large\today}\par
+			\vspace{.5in}
+			\textbf{\Huge\CapstoneProjectName}\par
+			\vfill
+			{\large Prepared for}\par
+			\Huge \CapstoneSponsorCompany\par
+			\vspace{5pt}
+			{\Large\NameSigPair{\CapstoneSponsorPerson}\par}
+			{\large Prepared by }\par
+			Group\CapstoneTeamNumber\par
+			% 5. comment out the line below this one if you do not wish to name your team
+			% \CapstoneTeamName\par 
+			\vspace{5pt}
+			{\Large
+				\NameSigPair{\GroupMemberOne}\par
+			}
+			\vspace{20pt}
+		}
+		\begin{abstract}
+			% 6. Fill in your abstract    
+            In order to successfully compete in the Mars Rover competition, the ground station software must run from an actual ground station.
+            This means that the ground control software must run on hardware that will make up the physical ground control station before it can be delivered to the robotics club.
+            In order to accomplish this we must determine various levels of technology.
+            In this document I research different solutions that can be used for this purpose.
+            The technologies discussed in this document are the host operating system, the computing hardware that will make up the host, and how that hardware will be physically packaged for quick deployment at the competition.
+            
+		\end{abstract}
+	\end{singlespace}
+\end{titlepage}
+\newpage
+\pagenumbering{arabic}
+\tableofcontents
+% 7. uncomment this (if applicable). Consider adding a page break.
+%\listoffigures
+%\listoftables
+\clearpage
+
+% 8. now you write!
+\section{Operating System}\par
+
+\subsection{Overview}
+The ground control software must run from a central host in order to be controlled by the operator.
+Therefore, an operating system must be chosen on which the software will run.
+This is an important technology decision as it is integral to the foundation of the software, and will likely be unchanged by future robotics team developers.
+This section describes the research and process behind deciding the best operating system on which to run the ground control software.
+
+\subsection{Criteria}
+The chosen operating system must meet several points of criteria.
+It should be well supported in robotics in order to ease development work, ensure robust software, and enable future developers.
+It should be acquired at minimum cost in order to best allocate robotics resources now and in the future.
+There should be a reasonable expectation that development on the operating system is familiar to this team as well as future teams doing development work on the ground control software.
+
+\subsection{Linux}
+Going into this research Linux was the preferred choice for this technology.
+Linux meets all basic criteria for this choice.
+\begin{itemize}
+\item 
+Linux is the primary choice of operating systems in robotics. 
+Because of this it is best supported by the community and will offer developers the greatest amount of support going forward.
+Of note, the Robot Operating System (ROS) \cite{rossupport}, which is the foremost robotics operating system and academically supported, only runs on the Linux operating system.
+Furthermore, ROS is technology under review by this team, for this project.
+The use of ROS would require that Linux be chosen.
+
+\item 
+All robotics team developers are students of Oregon State University, and as such have been routinely exposed to developing on Linux.
+Computer science students of OSU are required to develop on Linux for a majority of their programming courses.
+Because of this there is a reasonable expectation that all developers, future and present, will be familiar with Linux development.
+It is true that this team is most familiar with Linux development.
+In fact, it is likely that a large majority of these developers are more familiar with Linux development than development on any other operating system.
+We expect that this familiarity will greatly increase the quality of the software as well as the pace at which this software can be built and maintained.
+
+\item
+Linux is famously free and open sourced.
+This means that procurement of this operating system is exceedingly easy and cost free.
+This is greatly beneficial to the team as resources are limited.
+In acquiring this technology freely, the robotics team is free to allocate more resources to other parts of the project, such as the rover itself, or other ground station costs.
+
+\item
+Linux is famously light-weight and modifiable, allowing for a less powerful hardware solution.
+
+\end{itemize}
+
+
+\subsection{MacOS}
+MacOS is Apple's Unix operating system designed for Apple computers.
+MacOS meets some but not all base criteria for this choice.
+
+\begin{itemize}
+\item 
+MacOS is a Unix operating system \cite{macunix}, and as such shares many traits and tools with Linux.
+Because of this ROS runs and is supported on MacOS \cite{rossupport}.
+
+\item
+Because of its similarity to Linux, it is also fair to say that there is a reasonable expectation that developers, present and future, will be familiar with the development environment it provides.
+Therefore it is reasonable to expect that MacOS can provide a stable, robust foundation on which the ground station can be built.
+
+\item
+Unfortunately, MacOS is only legally permitted to be run on Apple hardware.
+This requirement causes significant additional cost to the project and restricts development environment for anyone working on the ground station.
+
+\end{itemize}
+
+\subsection{Windows}
+Microsoft Windows is the most popular PC operating system in the world.
+It is vastly different from Linux in both design and philosophy and represents a significant choice for this project.
+
+\begin{itemize}
+\item 
+ROS is not supported on the Windows platform \cite{rossupport}, which means that selecting the Windows operating system restricts us greatly.
+Moreover, Windows generally does not have the support of the general robotics environment in academics.
+Finding a Windows specific solution could be a significant hindrance to this team.
+
+\item
+The standard path through computer science at OSU does not include much, if any, development experience on the Windows platform.
+Therefore it is not reasonable to expect that current or incoming developers will be able to meaningfully impact the project without a significant, upfront, learning curve.
+It is also fair to say that the unfamiliarity of developing on Windows and the rapid deployment model that this project will take is likely to create a more mistake prone environment that will likely lead to less robust and reliable software.
+
+\item
+Windows is a licensed operating system that runs on nearly all PCs.
+However, a license can be procured through the University at no cost.
+Windows would not be a significant monetary burden if selected.
+
+\end{itemize}
+
+\subsection{Summary}
+Clearly each operating system has different traits and attributes.
+MacOS and Linux are both Unix operating systems and share many ideas and offer a similar environment.
+Windows is a drastic change from the previously mentioned two, but is the world's most popular PC operating system, and is professionally supported.
+
+\subsection{Conclusion}
+Linux is the clear choice here as it offers the project everything that is needed in an operating system and affords the greatest amount of flexibility on future choices.
+Linux is also the most familiar operating system to the developers and can be modified as needed in order to meet the exact definitions required for the project.
+
+\section{Computing Hardware}
+\subsection{Overview}
+As the ground station controls the rover, it must be a self-contained computer.
+This affords us a few choices.
+This team can choose to install the ground station software on either a laptop, an Intel NUC mini-PC, or a full-sized workstation PC.
+It is important to note that the ground station must be transported a significant distance to the competition and must be setup and torn down quickly.
+
+\subsection{Criteria}
+The computing hardware for the project must fulfill specific requirements.
+It must have enough processing power to drive the software.
+It must be small, portable, and easy to setup.
+It must not incur a significant cost.
+Due to the nature of the ground control software, all three of these requirements must be met.
+
+\subsection{Laptop}
+A laptop may seem like the most obvious choice and offers many advantages.
+They are already designed to be portable and offer enough computing power for the base station.
+They can be developed on just the same as any other computer.
+To use a laptop, one will have to be purchased, causing significant cost to the project.
+
+\subsection{Intel NUC}
+An Intel NUC is a miniature computer designed for similar use cases as this.
+It provides more than enough computing power and its small size will afford easy transportation and setup.
+The client prefers the use of an Intel NUC and is providing one for the project.
+
+\subsection{Full-Sized PC}
+A full-sized PC offers significant processing power but at the cost of size.
+Transporting and setting up one of these will be laborious and slow.
+The extra computing power afforded by a full workstation is unnecessary and wasted on the task.
+A workstation such as this will have to be purchased, causing significant cost to the project.
+
+\subsection{Summary}
+All three options can adequately fill the need of the project.
+A laptop is more portable and as powerful as a NUC, and a workstation is significantly more powerful than both.
+However, this nature of the project requires that the most efficient choice be made.
+
+\subsection{Conclusion}
+While a laptop may represent the most desirable choice, it is not the most efficient choice to complete the task.
+An Intel NUC is being provided to the group at no cost, and it has been indicated by the client that this is the preferred hardware choice.
+the NUC provides more than enough computing power than is required with almost the same portability as a laptop.
+
+\section{Quick-Deploy Package}
+
+\subsection{Overview}
+Transportation and set up are important to the Mars Rover competition, as it is a timed trial.
+In order to be successful, a packaging solution must be thoroughly considered.
+For example, does a solution have to be created, or does a solution already exist that can be purchase?
+Should the packaging be totally self contained or require external set up materials?
+
+\subsection{Criteria}
+The ground station will have to easily transported and unpacked.
+The competition is in the desert and reliability is paramount is it is also important that the transportation solution is adequate to protect the equipment while in transit and also in use.
+Also required is that the ground station must be setup with software launched in 2 minutes or less.
+
+\subsection{Self-Contained Case}
+This case contains all equipment necessary for the ground station to function, already connected, missing only power.
+Logistically this is the nicest solution, however, such a case will require some customization from the team, as such a case has not yet been found ready-made.
+Also the equipment will have to be carried approximately 50 feet from the transportation vehicle to the setup location, so it cannot be too heavy to be carried.
+
+\subsection{Separately Packaged Components}
+In this solution, all components of the station are packed individually and will have to be connected and powered separately once transported to the setup location.
+In contrast to the self contained case, this does not require any modification or customization, which means it is less resource intensive.
+However, moving the station from the transport vehicle to the setup location will require more than a single trip.
+This can introduce error as the client's rover team moves quickly to meet the two minute deadline.
+
+\subsection{Pre-Packed Case}
+Unlike the previous two solutions, in this case all necessary components are fit into a backpack or case, but not connected.
+This is different from the previous option because components are packaged together as opposed to separately, but are not connected.
+This allows for a single trip to unload the vehicle, but still requires that each component is connected and powered on in two minutes.
+Again this could lead to errors or troubleshooting in the two minutes allowed for setup, but may prove to be more feasible than the fully contained and connected ground station.
+
+\subsection{Summary}
+Each solution carries pros and cons.
+In this decision the team must determine how much value to impose on time.
+Is two minutes enough time for a full setup?
+
+\subsection{Conclusion}
+Though it is more resource heavy, it is better to have the entire ground station pre-connected in a hard case.
+This solution will cost both time and money, but will greatly increase the chance of success for the Mars Rover team during the competition.
+Moreover the solution can be reused in years to come, which is an important condition from our client.
+Packaging the ground station together unconnected provides the second most favorable option.
+
+\newpage
+\bibliography{mybib.bib}
+\end{document}

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/tech_review/steinfek/makefile

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

OSU Robotics Club/Mars Rover 2017-2018/cs_capstone_documents/tech_review/steinfek/mybib.bib

@@ -0,0 +1,43 @@
+@book{understanding,
+author = "Cesati, Marco and Bovet, Daniel P.",
+title = "Understanding the Linux Kernel",
+publisher = "O'Reilly Media, Inc.",
+year = "2002",
+edition = "2nd",
+}
+
+@misc{rossupport,
+author 	  = "ROS Wiki",
+title  	  = "Introduction",
+publisher = "ROS",
+howpublished = \url{http://wiki.ros.org/ROS/Introduction},
+}
+
+@misc{macunix,
+author 	  = "The Open Group",
+title  	  = "The Open Group official register of UNIX Certified Products",
+publisher = "The Open Group",
+howpublished = \url{https://www.opengroup.org/openbrand/register/},
+}
+
+@misc{cfq,
+author 	  = "Linux Foundation",
+title  	  = "CFQ",
+publisher = "Linux Foundation",
+howpublished = \url{https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt},
+}
+
+@misc{bsdelv,
+author		= "freebsd.org",
+title		= "Pluggable disk scheduler for FreeBSD",
+publiser	= "FreeBSD.org",
+howpublished =url{https://wiki.freebsd.org/Hybrid}
+}
+
+@book{windowsint,
+author = "Mark Russinovich, David Solomon, Alex Ionescu",
+title = "Windows Internals",
+publisher = "Microsoft Press",
+year = "2012",
+edition = "6th",
+}