archive/todo.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}