|
|
@ -78,10 +78,10 @@ |
|
|
|
\pagebreak |
|
|
|
|
|
|
|
\section{Project Recap} |
|
|
|
The Fenceless Grazing System project aims to reduce the need for manual labor |
|
|
|
The Fenceless Grazing System (FGS) project aims to reduce the need for manual labor |
|
|
|
for farmers and ranchers caring for large numbers of grazing animals. The |
|
|
|
system does so by automating the common task of herding through the use |
|
|
|
of GPS-equipped collars that emit negative auditory of electrical stimuli. |
|
|
|
of GPS-equipped collars that emit negative auditory or electrical stimuli. |
|
|
|
Animals that leave a rancher-defined grazing area are met with increasingly |
|
|
|
potent uses of the aforementioned stimuli, intended to discourage |
|
|
|
such behavior. In addition to the automated herding capabilities, |
|
|
@ -103,10 +103,10 @@ The Fenceless Grazing System is split into three major components: |
|
|
|
collars, as well as to store the data transmitted by the |
|
|
|
collars. This component is currently implemented |
|
|
|
using a Raspberry Pi, a low power, miniature single-board |
|
|
|
computer running Linux. The gateway server also provides |
|
|
|
computer running Raspbian Linux. The gateway server also provides |
|
|
|
a JSON API to external clients, allowing them to view |
|
|
|
and modify collar settings. The current reference |
|
|
|
client is the \emph{Android Application} |
|
|
|
client is the \emph{Android Application}. |
|
|
|
\item \emph{Android Application:} The Android application |
|
|
|
uses the JSON API provided by the gateway server to view |
|
|
|
the locations of the grazing animals, as well as adjust |
|
|
@ -121,13 +121,13 @@ Below are the descriptions of the current state of each |
|
|
|
of the project components. |
|
|
|
|
|
|
|
\subsection{GPS Collar} |
|
|
|
The collar controller (implemented as an ATmega328p microprocessor) |
|
|
|
The collar controller (implemented as an Arduino Nano with an ATmega328p microprocessor) |
|
|
|
is currenly able to interface with the on-board GPS module and |
|
|
|
determine its own location, within about a foot. This was tested |
|
|
|
in a somewhat populated area, meaning that such precision is in |
|
|
|
spite of various obstacles such as buildings and trees |
|
|
|
that would not commonly be present in a grazing field. The collar |
|
|
|
can also use a single-channel LoRa tranciever to communicate its |
|
|
|
can also use a single-channel LoRa transceiver to communicate its |
|
|
|
location to the gateway server. |
|
|
|
|
|
|
|
Currently, the collar is assembled using prototyping materials |
|
|
@ -146,8 +146,8 @@ the project uses a data encoding/decoding tool named Protobuf (short for Protoco |
|
|
|
The tool provides a separate language for describing data structures to be encoded, |
|
|
|
and has the advantage of tightly packing data, reducing the number of bytes needed |
|
|
|
to store the information. This is especially useful for our purposes, since it |
|
|
|
minimzes the amount of data to be transmitted over radio, and therefore minimizes |
|
|
|
the potential for error. |
|
|
|
minimizes the amount of data to be transmitted over radio, and therefore minimizes |
|
|
|
the potential for error as well as increasing scalability. |
|
|
|
|
|
|
|
Currently, the communication protocol fits in two Protobuf data structures. The |
|
|
|
code is as follows: |
|
|
@ -176,18 +176,18 @@ provided by 32-bit floating point numbers seem sufficient for our purposes. |
|
|
|
\end{figure} |
|
|
|
|
|
|
|
\subsection{Gateway Server} |
|
|
|
The gateway server can currently correctly serve as the intermediary between |
|
|
|
GPS colalrs in the field and the Android application. It does so by providing |
|
|
|
The gateway server can correctly serve as the intermediary between |
|
|
|
GPS collars in the field and the Android application. It does so by providing |
|
|
|
two separate services: a REST API, written in Python, and a LoRa client, |
|
|
|
written in C. |
|
|
|
|
|
|
|
The LoRa client is used to interface with the Raspberry Pi LoRa shield, |
|
|
|
and provide all the communication-related functionality. Currently, |
|
|
|
and provides all the communication-related functionality. Currently, |
|
|
|
this entails waiting for location broadcasts from the GPS collars, |
|
|
|
decoding them into C data structures from Protobuf, and storing |
|
|
|
this information into an SQLite database using SQLite's C API. |
|
|
|
Because the C Protobuf API is much more low-level than the |
|
|
|
Arduino / ATmega128 API, it requires the users (us) to provide |
|
|
|
Arduino / ATmega328 API, it requires the users (us) to provide |
|
|
|
it with implementation details, such as the method for memory |
|
|
|
allocation. We use C's standard \texttt{malloc} function |
|
|
|
to do so: |
|
|
@ -196,7 +196,7 @@ to do so: |
|
|
|
|
|
|
|
The REST API uses the Flask microframework to provide an HTTP-based |
|
|
|
interface to the Android application. Currently, it receives |
|
|
|
login information from the client, verifies it against its |
|
|
|
login information from the client, and verifies it against its |
|
|
|
database of user accounts. If the account information is correct, |
|
|
|
it creates a JSON Web Token which can then be used by the Android |
|
|
|
application in further requests. |
|
|
@ -213,7 +213,7 @@ application: a way to get the list of currently active collars, |
|
|
|
and an endpoint to list the recent history of a single collar. |
|
|
|
|
|
|
|
The REST API and the LoRa client share the same SQLite database. |
|
|
|
However, wheras the SQLite C API (used by the LoRa client) is |
|
|
|
However, whereas the SQLite C API (used by the LoRa client) is |
|
|
|
very low-level, the Flask-based API server is capable of using |
|
|
|
a high-level interface with the database, called an Object Relational Model (ORM). |
|
|
|
Through this interface, the Python code can treat SQL data like Python |
|
|
@ -274,7 +274,7 @@ it for further interaction with the gateway server. It also |
|
|
|
uses the JWT to retrieve a current list of active collars |
|
|
|
(triggering the code snippet in the previous section). |
|
|
|
|
|
|
|
The application is capable of using the OpenStreeMaps API to display |
|
|
|
The application is capable of using the OpenStreetMaps API to display |
|
|
|
the locations of the active collars on an interactive map. This |
|
|
|
map supports zooming in and out and panning. Each individual |
|
|
|
collar is presented on the map as a single marker. In |
|
|
@ -346,7 +346,7 @@ for these messages, and send them to collars as they arrive. |
|
|
|
|
|
|
|
\subsection{Grazing Boundary Tracking and Response} |
|
|
|
Currently, while the collars are able to keep track of their location, |
|
|
|
they are not able determine whether or not they are in a "valid" location, |
|
|
|
they are not able to determine whether or not they are in a "valid" location, |
|
|
|
or whether they should emit the auditory or electrical stimulus. This |
|
|
|
must be implemented, along with the ability to configure the grazing |
|
|
|
boundary through the LoRa protocol. |
|
|
@ -355,7 +355,7 @@ We will likely define the grazing area to be a 16-point polygon. |
|
|
|
The coordinate for each vertex of the polygon will be delivered |
|
|
|
through the Protobuf-encoded LoRa communication to the collar, |
|
|
|
and an existing algorithm will be used to determine if the current |
|
|
|
coordinate of the collar is within thgee polygon. This is likely |
|
|
|
coordinate of the collar is within the polygon. This is likely |
|
|
|
sufficient, since grazing fields are unlikely to become large enough |
|
|
|
for the Earth's spherical nature to significantly affect the calculations. |
|
|
|
|
|
|
@ -390,11 +390,11 @@ gateway server and the collar. |
|
|
|
Although the current application is capable |
|
|
|
of displaying the present location of various |
|
|
|
collars, it does not display the grazing |
|
|
|
boundary (which is as yet nonexistent |
|
|
|
boundary (which is as of yet nonexistent |
|
|
|
in the code). The application also does not |
|
|
|
provide any significant ability to analyze the |
|
|
|
gathered data. The client has requested that |
|
|
|
address this, especially in preparation |
|
|
|
we address this, especially in preparation |
|
|
|
for the engineering expo. |
|
|
|
|
|
|
|
In particular, the client has asked that |
|
|
@ -407,10 +407,10 @@ and we plan on including this functionality |
|
|
|
in the final product. Other, more visually |
|
|
|
interesting diagrams --- such as graphs |
|
|
|
of the number of "escapes" per day --- will |
|
|
|
be considered, by considered low priority. |
|
|
|
be considered. |
|
|
|
|
|
|
|
\subsection{Physical Casing} |
|
|
|
The team is yet to create a physical casing for the collar |
|
|
|
The team has yet to create a physical casing for the collar |
|
|
|
component, which would allow for safer transportation and |
|
|
|
more robust testing. This will likely be done with |
|
|
|
the help of the university's laser cutter, since |
|
|
|