mirror of
https://github.com/OSURoboticsClub/Rover_2017_2018.git
synced 2025-11-08 10:11:14 +00:00
added personal tech review
This commit is contained in:
6347
cs_capstone_documents/tech_review/phamchr/IEEEtran.cls
Normal file
6347
cs_capstone_documents/tech_review/phamchr/IEEEtran.cls
Normal file
File diff suppressed because it is too large
Load Diff
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
Binary file not shown.
8802
cs_capstone_documents/tech_review/phamchr/latexmk.pl
Normal file
8802
cs_capstone_documents/tech_review/phamchr/latexmk.pl
Normal file
File diff suppressed because it is too large
Load Diff
31
cs_capstone_documents/tech_review/phamchr/latexmkrc
Normal file
31
cs_capstone_documents/tech_review/phamchr/latexmkrc
Normal file
@@ -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;
|
||||||
|
}
|
||||||
18
cs_capstone_documents/tech_review/phamchr/makefile
Normal file
18
cs_capstone_documents/tech_review/phamchr/makefile
Normal file
@@ -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)
|
||||||
241
cs_capstone_documents/tech_review/phamchr/techreview.tex
Normal file
241
cs_capstone_documents/tech_review/phamchr/techreview.tex
Normal file
@@ -0,0 +1,241 @@
|
|||||||
|
\documentclass[onecolumn, draftclsnofoot, 10pt, compsoc]{IEEEtran}
|
||||||
|
\usepackage{graphicx}
|
||||||
|
\graphicspath{{./figures/}}
|
||||||
|
|
||||||
|
\usepackage{url}
|
||||||
|
\usepackage{setspace}
|
||||||
|
\usepackage{multicol}
|
||||||
|
\usepackage{pdflscape}
|
||||||
|
\usepackage{pdfpages}
|
||||||
|
\usepackage{hyperref}
|
||||||
|
\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}
|
||||||
|
% 6. Fill in your abstract
|
||||||
|
|
||||||
|
|
||||||
|
\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 some command line interface system.
|
||||||
|
The GUI allows for people to interact with the system even if they are not keen to the system or technologically challenged.
|
||||||
|
A GUI framework is a pack of tools that will build a GUI using a command 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 instead of being made in-house by us.
|
||||||
|
\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 focusing 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 to fit the requirements.
|
||||||
|
\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 and they are not at fault for anything about their program.
|
||||||
|
\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 and PyQt are also possible on other languages using some other wrappers for other languages, unlike Kivy which is only currently working Python.
|
||||||
|
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 compared to other frameworks.
|
||||||
|
Unlike the other frameworks in where including the framework is free for commercial projects, Qt requires payment for any commercial product.
|
||||||
|
\subsection{Decision}
|
||||||
|
My choice for this project would be PyQt because any of the limitations that it puts out like the fee for publishing Qt is non-existent for this project.
|
||||||
|
PyQt and Qt in general have good support and documentation because its longevity, numerous tutorials, and support.
|
||||||
|
Kivy would work well for the project if had more documentation but its OpenGL rendering would be fantastic.
|
||||||
|
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 Visualization}
|
||||||
|
\subsection{Overview}
|
||||||
|
For this project, one important view of this project is going to be visualizing how the arm is currently moving in respect to the rover itself and the user input.
|
||||||
|
The need comes from the integration between our project and the other senior project that revolves around the rover subject.
|
||||||
|
Without the visualization, the other group can not test to see if their arm works on the rover and for later competition usage to accurately use the arm with the camera on the rover.
|
||||||
|
\subsection{Criteria}
|
||||||
|
Per requests, the arm visualizer needs to be at least slightly resemble the arms.
|
||||||
|
If this was to be made using the command line or via text, it would be every confusing unless they knew how to animate the hand using inverse kinematics.
|
||||||
|
The other requirement would be needing to able to run on Linux (Ubuntu) and that prevents any DirectX usage.
|
||||||
|
\subsection{Potential Choices}
|
||||||
|
\subsubsection{ROS Visualization}
|
||||||
|
Inbuilt into ROS, there is a package called rvis which allows for the system to visualize using displays.
|
||||||
|
The included displays in rvis are \cite{rvis}:
|
||||||
|
\begin{center}
|
||||||
|
\begin{tabular}{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}
|
||||||
|
|
||||||
|
\subsubsection{OpenGL visualization}
|
||||||
|
We can build a system using one of our GUI frameworks to give us access to an OpenGL window that we can then write to using some other code to simulate 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.
|
||||||
|
There would need to be a way to do the inverse kinematics to get the joints working correctly.
|
||||||
|
In this method too, we would be able to control how fast the video/render would be refreshing at and could control the granularity of the feed.
|
||||||
|
|
||||||
|
\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 then the 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.
|
||||||
|
|
||||||
|
\subsection{Comparison}
|
||||||
|
Compared to ROS and OpenGL, Gazebo 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, which makes recommending hard
|
||||||
|
\subsection*{Decision}
|
||||||
|
I think that it should be a mix of ROS visualization and some custom OpenGL for other portions of code that is not covered by the package.
|
||||||
|
The package itself is very through with what it provides and allows for easy use with the ROS subsystem on-top of Ubuntu.
|
||||||
|
|
||||||
|
\subsection{Mapping Software}
|
||||||
|
\subsection{Overview}
|
||||||
|
For another part of the project, in competition there needs to be a way to map our rover to a map.
|
||||||
|
For my selection, I will going off the basis that we will have to build the mapping front-end but we will need other things like GPS handling
|
||||||
|
\subsection{Criteria}
|
||||||
|
One of the requirements for the competition was some way of controlling the rover using GPS coordinates.
|
||||||
|
One of the client's request was to use a way-point system using a map and/or some inputs to enter the values.
|
||||||
|
\subsection{Potential Choice}
|
||||||
|
\subsubsection{ROS Packages}
|
||||||
|
There are inbuilt packages for GPS and GPS location parsing in the ROS subsystem.
|
||||||
|
Using other packages like rvis can be used to display the map and transform the image to display the correct location.
|
||||||
|
\subsubsection{Google Maps}
|
||||||
|
Using the same packages as above, instead of parsing the location on the robot, the rover/ground station can parse the information given to it by sending it to Google.
|
||||||
|
\subsubsection{Custom Mapping}
|
||||||
|
We could build a system using our own polling of the GPS data and then parse the GPS information into a way that can be represented by texture location.
|
||||||
|
That texture location can then be the location of where the rover is and then can the texture can be placed around the sudorover.
|
||||||
|
\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 rover to a remote server.
|
||||||
|
ROS and the custom software are very similar too but instead of building and trusting ourselves with the GPS analysis instead of the open-sourced code.
|
||||||
|
The only difference between all of these is how the GPS data is analyzed and then put onto screen.
|
||||||
|
\subsection{Decision}
|
||||||
|
I think that the project should use the ROS packages because all of those are open source and many other people have looked over and used this software and tested it.
|
||||||
|
ROS also has everything rolled in and has integrations with the other packages like rvis and mapping software in ROS.
|
||||||
|
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.
|
||||||
|
\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}
|
||||||
|
|
||||||
|
\end{thebibliography}
|
||||||
|
\end{document}
|
||||||
Reference in New Issue
Block a user