224 lines
10 KiB
Plaintext
224 lines
10 KiB
Plaintext
\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}
|
|
The Fenceless Grazing Collar System aims to reduce the burden
|
|
on farmers caused by the need of constant manual herding of livestock.
|
|
The project will use LoRa wireless technology, and will prevent
|
|
animals from leaving prescribed grazing areas through the use of
|
|
an auditory or electrical stimulus. The project will additionally provide
|
|
data gathering features. As a member of the FGC team, I will be
|
|
responsible for creating the smart application that will be used
|
|
to control the wireless collars, as well as some supporting
|
|
software such as an HTTP API server.
|
|
\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}
|