Initial version of tech review
This commit is contained in:
commit
08d47c0bd8
214
techreview.latex
Normal file
214
techreview.latex
Normal file
|
@ -0,0 +1,214 @@
|
|||
\documentclass[10pt, draftclsnofoot,onecolumn]{IEEEtran}
|
||||
|
||||
\def\changemargin#1#2{\list{}{\rightmargin#2\leftmargin#1}\item[]}
|
||||
\let\endchangemargin=\endlist
|
||||
|
||||
\usepackage{todonotes}
|
||||
\usepackage{caption}
|
||||
\usepackage{pgfgantt}
|
||||
\linespread{1}
|
||||
\begin{document}
|
||||
|
||||
\title{Fenceless Grazing Tech Review - Danila Fedorin}
|
||||
\author{Danila Fedorin, \and Matthew Sessions, \and Ryan Alder}
|
||||
\maketitle
|
||||
|
||||
\begin{abstract}
|
||||
\end{abstract}
|
||||
|
||||
\pagebreak
|
||||
\tableofcontents
|
||||
|
||||
\pagebreak
|
||||
|
||||
\section{Role}
|
||||
My role in this project is the development of the smart application which
|
||||
will be used to control the Fenceless Grazing Collars in the field. This
|
||||
includes the actual application, as well as the software to support
|
||||
the app, such as a web server for authentication and data retrieval.
|
||||
|
||||
\section{Team Goal}
|
||||
The goal of the Fenceless Grazing Collar (FGC) System is to reduce
|
||||
the amount of manual labor required for keeping farm animals. The FGC system
|
||||
does this by automating the process of keeping animals within their prescribed
|
||||
grazing area through the use of GPS location tracking, as well as audio
|
||||
and electric stimuli. Additionally, the FGC aims to provide information
|
||||
about the behavior of the farm animals to their keepers, with the goal
|
||||
of improving their understanding of the livestock.
|
||||
|
||||
\section{Responsibilities}
|
||||
\subsection{Smart Device Application}
|
||||
A major component of this project is the creation
|
||||
of an application that is capable of adjusting
|
||||
the settings of the wireless collar devices. This
|
||||
section describes the components of this application.
|
||||
|
||||
\subsubsection{Platform}
|
||||
The Android paltform makes up more than half of the market share
|
||||
in the United States, with a majority of the remaining share taken
|
||||
up by Apple iOS. Because iOS requires an Apple device to perform
|
||||
development [citation needed], and because Android devices are
|
||||
on average more 50\% cheaper than iPhone devices, we will
|
||||
use the Android platform for developing the mobile application
|
||||
associated with this project.
|
||||
% Source https://www.businessinsider.com/android-stops-us-market-share-decline-2013-5
|
||||
% https://www.forbes.com/sites/amitchowdhry/2015/02/03/average-iphone-price-increases-to-687-and-android-decreases-to-254-says-report/#4d9d29a3539e
|
||||
|
||||
\subsubsection{Language}
|
||||
There exists a variety of available technolgoies and techniques suitable
|
||||
for creating an Android application. The most common way for developing
|
||||
Android apps is using the Java programming language,
|
||||
utilizing the standard Android tooling. Such tooling includes
|
||||
the Android Studio Integrated Development Environment (IDE),
|
||||
and the Gradle build system. However, since Android's creation,
|
||||
multiple other ways of developing Android applications have been introduced. For
|
||||
example, technologies such as the Ionic Framework and
|
||||
React Native have been created, allowing for the creation
|
||||
of Android applications using the JavaScript programming
|
||||
language. More recently, Google announced that JetBrains' Kotlin
|
||||
language will be made an official language of the Android
|
||||
platform.
|
||||
%https://ionicframework.com/
|
||||
%https://facebook.github.io/react-native/
|
||||
%https://www.theverge.com/2017/5/17/15654988/google-jet-brains-kotlin-programming-language-android-development-io-2017
|
||||
|
||||
The use of JavaScript was ruled out due to its weak type system.
|
||||
The language does not undergo a process called "type checking",
|
||||
which means that certain bugs that can easily be detected
|
||||
in other languages may go unnoticed in a JavaScript program
|
||||
until they are observed in practice. Since this application
|
||||
must reliably control the wireless collars, this is an
|
||||
unnecessary risk.
|
||||
|
||||
The choice then remains between Java and Kotlin, both
|
||||
official languages of the Android platform. For our
|
||||
purpose, Kotlin has advantages over Java. First,
|
||||
Kotlin has a stronger type system, which, as described
|
||||
above, helps prevents certain bugs before they are
|
||||
observed in practice. Second, while Kotlin has access
|
||||
to all features of the Android platform that Java does,
|
||||
it has significantly less "boilerplate" code. This will
|
||||
help reduce the amount of code requiring maintenance,
|
||||
and thus reduce the number of mechanical issues with the final code.
|
||||
|
||||
\subsubsection{Backwards Compatibility}
|
||||
Because vendors can customize the Android operating system prior
|
||||
to using it on their products, a variety of Android devices
|
||||
run an "outdated" version of the Android platform, resulting
|
||||
in a severe fragmentation of the overall codebase. Since maintaining
|
||||
compatibility with every Android version on the market is not viable,
|
||||
the project will focus on the version of Android supported by 95\%
|
||||
of Android devices at the time the project implementation begins.
|
||||
This will allow the project to target a majority of available
|
||||
devices, while at the same time not being bogged down by the
|
||||
compatibility requirements with very old version of Android.
|
||||
|
||||
\subsection{Data Storage}
|
||||
Data storage is a major component of the fenceless grazing project.
|
||||
It is important that the collars collect and store meaningful data
|
||||
about the animals in the field, to be analyzed by the client.
|
||||
|
||||
\subsubsection{Type of Data Collected}
|
||||
The data collected will consist of GPS coordinates of the animal,
|
||||
taken every 15 seconds, as well as instances of the activation
|
||||
of the collars' sound and shock features. This way, the client
|
||||
can monitor the locations and habits of the animals, as well
|
||||
as quantatively assess the number of items that the animals
|
||||
attempt to leave the prescribed area. Each data point will
|
||||
be associated with the collar that produced it, such that
|
||||
behaviors of individual animals can be easily analyzed.
|
||||
|
||||
\subsubsection{Storage Type}
|
||||
An SQL database will be used for storing the data generated
|
||||
by the collars. A single MariaDB server will be used to store
|
||||
the data. MariaDB was chosen because of its permissive license
|
||||
and compatibility with MySQL, another SQL dialect that is very
|
||||
commonly used in the industry.
|
||||
|
||||
% https://mariadb.org/
|
||||
% https://www.mysql.com/
|
||||
|
||||
\subsubsection{Storage Hardware}
|
||||
Because MariaDB and MySQL require a server machine, a Linux machine
|
||||
will be used to host the database. This machine will be
|
||||
a Raspberry Pi, a small and low-power Linux single-board
|
||||
computer. This computer not only has a full-featured
|
||||
Debian Linux operating system, but also allows for the
|
||||
addition of hardware components, which will be used
|
||||
for communicating with collars in the field. Among the
|
||||
hardware components compatible with the Raspberry Pi is a
|
||||
LoRa shield, which allows the Pi to send and receive
|
||||
LoRa signals. This is ideal since the server machine will also act as the LoRa
|
||||
gateway, serving as the liaison between the collars
|
||||
deployed in the field and the rest of the project.
|
||||
|
||||
% https://www.raspberrypi.org/
|
||||
|
||||
\subsection{App API Server}
|
||||
An API server is needed to allow users of the Android
|
||||
smart application to interact with the fenceless collars
|
||||
deployed on farm animals. Smartphones do not have
|
||||
hardware that can communicate using the LoRa protocol,
|
||||
which is used for collars. As such, an intermediate
|
||||
device, a server that can communicate with both smartphones
|
||||
and LoRa, must be used.
|
||||
|
||||
\subsubsection{Server Technology}
|
||||
The server will run on the aforementioned Linux machine.
|
||||
This is because it is rather expensive, in terms of both
|
||||
price and complexity, to introduce two server machines
|
||||
for the individual tasks of SQL data storage and smartphone
|
||||
app support. The server will use the Python programming
|
||||
language, which is natively supportd by the Raspberry Pi,
|
||||
to host an HTTP(s) server on the local network. The
|
||||
use of Python will allow for rapid development, as give
|
||||
direct access to the server's LoRa hardware.
|
||||
|
||||
The Gunicorn server will be used to expose the Python
|
||||
application to the Android application clients. While
|
||||
other web servers, such as Apache and nginx, are very
|
||||
commonly deployed in production, Gunicorn has excellent
|
||||
support for Python, which will allow the team to
|
||||
quickly develop the HTTP application.
|
||||
|
||||
% https://www.python.org/
|
||||
% https://gunicorn.org/
|
||||
|
||||
\subsubsection{Authentication}
|
||||
The mobile app will use JSON web token (JWT)
|
||||
to allow the mobile application to make multiple requests
|
||||
without having to continously provide a username
|
||||
and password to the server. The idea of JWT is that
|
||||
a JSON (JavaScript Object Notation) object, containing
|
||||
session information (such as the identity of the current user),
|
||||
is encrypted with information from the server. The encrypted
|
||||
version of this object is then sent to the user, and can be
|
||||
used as a "proof of identity". Since only the server can decrypt
|
||||
the token, the user cannot deliberately make changes to it, preventing
|
||||
security breaches. Once a user logs in, a JWT token will be generated,
|
||||
containing the identity of the user and an experiation date, and
|
||||
returned to the app. The app will then use the token for further
|
||||
requests.
|
||||
|
||||
\subsubsection{API}
|
||||
There are several ways of communicating data to the mobile application
|
||||
from the server. Because writing custom code to encode / decode data
|
||||
send between the android application (client) and the server is
|
||||
time consuming and prone to errors, priority is given to existing
|
||||
encoding / decoding technologies. Of these technologies, Google's
|
||||
ProtoBuf, XML, and JSON are the most viable. JSON was chosen
|
||||
for this project because of the ease with which it can be decoded,
|
||||
as well as due to its compatibility with the JavaScript ecosystem.
|
||||
Virtually every language (including Kotlin and Python) has support
|
||||
for JSON decoding that is well-tested and supported. This makes
|
||||
JSON the most standard choice for an interchange format.
|
||||
|
||||
The aforementioned HTTP server will thus provide a JSON API
|
||||
to the client. During each HTTP requests, the client will
|
||||
include a JWT token, and, once that token is verified, the server
|
||||
will process the relevant information and return a JSON object
|
||||
through HTTP containing the resulting data.
|
||||
|
||||
% https://developers.google.com/protocol-buffers
|
||||
|
||||
\end{document}
|
Loading…
Reference in New Issue
Block a user