106 lines
5.4 KiB
TeX
106 lines
5.4 KiB
TeX
\documentclass[10pt, draftclsnofoot,onecolumn, compsoc]{IEEEtran}
|
|
|
|
\def\changemargin#1#2{\list{}{\rightmargin#2\leftmargin#1}\item[]}
|
|
\let\endchangemargin=\endlist
|
|
|
|
\usepackage{setspace}
|
|
\usepackage{listings}
|
|
\linespread{1}
|
|
|
|
\title{Appendix 4: Work to be Done}
|
|
|
|
\begin{document}
|
|
\maketitle
|
|
|
|
\section*{Android Application}
|
|
The Android application requires only some minor touch-ups. In particular,
|
|
it would be good to add more graphs / visualizations of the collar data.
|
|
The majority of the data processing should be done on the server;
|
|
the application should merely display this data. Thus, implementing
|
|
this feature would have to be done in tandem with adjusting
|
|
the server to generate more statistics.
|
|
|
|
The application could also use some custom icons. The icons
|
|
used on the map for collars and polygon vertices are the default
|
|
ones provided by the \texttt{OSMDroid} library, and look pretty bad.
|
|
Consider replacing with custom SVG graphics.
|
|
|
|
It might be a good idea to allow the user to configure their API
|
|
URL rather than hardcoding it in \texttt{resources.xml}. Perhaps
|
|
the login screen should present a third input box which the user
|
|
can fill with their system's API URL. This means a single
|
|
Android application will work for several independent grazing systems.
|
|
|
|
\section*{API Server}
|
|
The gateway server should be modified to generate some more statistics,
|
|
and send these statistics to the Android application. It could
|
|
be useful to rewrite the Flask module using the application factory
|
|
pattern, but this would not add to functionality and should be
|
|
considered low priority.
|
|
|
|
Some thought could be put in into how the server handles authentication
|
|
tokens. Currently, they only contain the user ID, and thus, assuming
|
|
the same ``secret passphrase", a user will always have the same API
|
|
token. It's not uncommon for these tokens to be leaked; most
|
|
systems deal with this by allowing the user to invalidate their
|
|
access token and generate a new one. This can be achieved in the Fenceless
|
|
Grazing System by adding a ``generation" field to the JSON body
|
|
of the JWT token, and tracking the ``valid generation" in the database.
|
|
This would greatly improve security.
|
|
|
|
\section*{Gateway Software}
|
|
The gateway software should be updated to use the SQLAlchemy model
|
|
definitions used in the API Server. This would remove the need
|
|
for writing raw SQL queries, and thereby simplify the code.
|
|
|
|
Although The Things Network is used in this iteration of the project
|
|
to decode LoRaWAN packets, we do not think this solution is ideal.
|
|
First of all, this requires the server to be connected to the Internet,
|
|
and makes the server unable to decode incoming transmissions from
|
|
the collars when network connection drops. Furthermore, this
|
|
makes our project forward data through The Things Network,
|
|
which can be a security or privacy concern. We understand that many
|
|
users do not want their data to be piped through a third-party system.
|
|
This change is rather difficult, however, due to the fact that there
|
|
is (at the time of writting) little support for LoRaWAN. It might
|
|
be necessary to follow the LoRaWAN spec and implement a custom packet
|
|
decoder and handler, as well as custom LoRaWAN Network Access Point software.
|
|
|
|
The Gateway's current interaction with the with the collars is done
|
|
by pushing data to The Things Network's API endpoints. The Things Network
|
|
requries that the project manually defines an endpoint for every client
|
|
device (in our case, for every collar). Since we only have one collar,
|
|
we only defined one endpoint. This means that there is currently no logic
|
|
to translate a collar identifier (internal to our system) to an API endpoint
|
|
(used by TTN). Since this system aims to support many concurrent collar connections,
|
|
such a translation layer should be added, perhaps in the form of a database table.
|
|
Note that this is specific to The Things Network, and moving away from TTN would
|
|
make this change pointless.
|
|
|
|
\section*{Collar Firmware}
|
|
The collar is currently pushing its underlying hardware quite far; the ATmega chip
|
|
used by the LoRa hardware does not have a lot of application memory, and our
|
|
use of LoRaWAN, GPS, and Protobuf has put a significant strain on it. We have already
|
|
struggled with including libraries on the collar (our generated HEX file was too big);
|
|
even now, the collar is succeptible to stack overflows even on small call stacks.
|
|
On embedded hardware, these stack overflows lead to a hard crash, and make
|
|
the collar non-functional.
|
|
|
|
We recommend that a more robust chip be used for the collar, at the cost of increased
|
|
power consumption. Though there exist models of the ATmega (or other AVR controller)
|
|
that have more memory, it could be fruitful to use an ARM processor instead. Doing so,
|
|
though, will likely require the reimplementation of the collar firmware from scratch.
|
|
|
|
Additionally, a goal of the Fenceless Grazing System is to be able to redirect
|
|
animals back into a ``valid grazing area". This is to be done with an auditory
|
|
stimulus (a loud beep, for instance) or an electric shock. Currently, the
|
|
collar is capable of determining whether or not it's inside the valid
|
|
grazing boundary, but doesn't have the hardware to influence its host animal.
|
|
To make this work in a field, the collar will probably also require
|
|
a case. We suggest laser cutting one, since 3D printing at the size of the current
|
|
prototype would simply take too long and have a high chance of failure. Note
|
|
that the GPS and LoRa antennas should be outside of the case, so as to
|
|
be able to communicate with the rest of the world.
|
|
|
|
\end{document}
|