diff --git a/end-of-term-report.latex b/end-of-term-report.latex index 74163f4..993be7b 100644 --- a/end-of-term-report.latex +++ b/end-of-term-report.latex @@ -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