147 lines
7.7 KiB
TeX
147 lines
7.7 KiB
TeX
\documentclass[10pt, draftclsnofoot,onecolumn, compsoc]{IEEEtran}
|
|
|
|
\def\changemargin#1#2{\list{}{\rightmargin#2\leftmargin#1}\item[]}
|
|
\let\endchangemargin=\endlist
|
|
|
|
\usepackage{textcomp}
|
|
\usepackage{todonotes}
|
|
\usepackage{caption}
|
|
\usepackage{pgfgantt}
|
|
\usepackage{setspace}
|
|
\linespread{1}
|
|
|
|
\def \CapstoneTeamName{Automated Fenceless Grazing}
|
|
\def \CapstoneTeamNumber{CS3}
|
|
\def \GroupMemberOne{Ryan Alder}
|
|
\def \GroupMemberTwo{Danila Fedorin}
|
|
\def \GroupMemberThree{Matthew Sessions}
|
|
\def \CapstoneProjectName{Automated Fenceless Grazing}
|
|
\def \CapstoneSponsorCompany{Oregon State University}
|
|
\def \CapstoneSponsorPerson{Bechir Hamdaoui}
|
|
\def \DocType{Project Archive Master Document}
|
|
|
|
\newcommand{\NameSigPair}[1]{\par
|
|
\makebox[2.75in][r]{#1} \hfil \makebox[3.25in]{\makebox[2.25in]{\hrulefill} \hfill \makebox[.75in]{\hrulefill}}
|
|
\par\vspace{-12pt} \textit{\tiny\noindent
|
|
\makebox[2.75in]{} \hfil \makebox[3.25in]{\makebox[2.25in][r]{Signature} \hfill \makebox[.75in][r]{Date}}}}
|
|
|
|
\begin{document}
|
|
|
|
\begin{titlepage}
|
|
\pagenumbering{gobble}
|
|
\begin{singlespace}
|
|
% 4. If you have a logo, use this includegraphics command to put it on the coversheet.
|
|
%\includegraphics[height=4cm]{CompanyLogo}
|
|
\par\vspace{.2in}
|
|
\centering
|
|
\scshape{
|
|
\huge CS Capstone \DocType \par
|
|
{\large\today}\par
|
|
\vspace{.5in}
|
|
\textbf{\Huge\CapstoneProjectName}\par
|
|
\vfill
|
|
{\large Prepared for}\par
|
|
\Huge \CapstoneSponsorCompany\par
|
|
\vspace{5pt}
|
|
{\Large\NameSigPair{\CapstoneSponsorPerson}\par}
|
|
{\large Prepared by }\par
|
|
Group\CapstoneTeamNumber\par
|
|
% 5. comment out the line below this one if you do not wish to name your team
|
|
\CapstoneTeamName\par
|
|
\vspace{5pt}
|
|
{\Large
|
|
\NameSigPair{\GroupMemberOne}\par
|
|
\NameSigPair{\GroupMemberTwo}\par
|
|
\NameSigPair{\GroupMemberThree}\par
|
|
}
|
|
\vspace{20pt}
|
|
}
|
|
% \begin{abstract}
|
|
% The Fenceless Grazing Collar system aims to reduce the amount of work
|
|
% needed by farmers to keep herds of grazing animals. The project
|
|
% will be implemented using the LoRa wireless communication protocol to allow
|
|
% for long-range interaction between animal-worn collars and a gateway device.
|
|
% The gateway device will also provide an HTTP-based JSON API to apply configuration
|
|
% changes to collars through an application built for Android mobile devices.
|
|
% The MariaDB SQL database management system will be used to store the data
|
|
% received from the collar for viewing and analysis.
|
|
% \end{abstract}
|
|
\end{singlespace}
|
|
\end{titlepage}
|
|
|
|
\pagebreak
|
|
\section*{Foreword}
|
|
% TODO
|
|
|
|
\pagebreak
|
|
\section{Project Introduction}
|
|
The Fenceless Grazing System was designed and implemented as requested by OSU professor Bechir Hamdaoui,
|
|
who also served as the project's client.
|
|
Prof. Hamdaoui believes that there is an emerging market for smart collar systems, and wanted to explore
|
|
the implementation of such a system using the LoRa \textbf{Lo}ng \textbf{Ra}nge communication protocol.
|
|
The project is meant as a proof of concept of an automated animal tracking and monitoring system.
|
|
|
|
The team consisted of three members:
|
|
|
|
\begin{itemize}
|
|
\item \textbf{Ryan Alder} served as the liaison with Prof. Hamdaoui, and as a LoRa expert. Being the
|
|
most familliar of the three team members with the LoRa protocol, he oversaw and aided the
|
|
implementation of the collar and gateway, each of which used the protocol to communicate with
|
|
the other. Ryan also tested the system in practice, measuring the effective range of the
|
|
components and verifying that data can be transmitted back and forth.
|
|
\item \textbf{Danila Fedorin} worked on the "high level" components of the system, namely
|
|
the Android application and the API server, as well on the overall system architecture.
|
|
He additionally designed the database schema and part of the data encoding protocol
|
|
used by the system.
|
|
\item \textbf{Matthew Sessions} worked on the "low level" components of the system, namely
|
|
the collar and gateway. Having strong background in embedded development, Matthew
|
|
was the source of truth in the implementation of hardware components, as well
|
|
as their troubleshooting.
|
|
\end{itemize}
|
|
|
|
Prof. Hamdaoui was largely not involved in the overall design of the system. Though he requested
|
|
the use of the LoRa protocol, and suggested an overall architecture for the project, the same
|
|
overall architecture was independently developed by the team. In meetings, scheduled approximately
|
|
once a month, Prof. Hamdaoui provided guidance on which component of the system to prioritize next,
|
|
but gave the team the freedom to decide how to implement said component.
|
|
|
|
The COVID-19 pandemic led the development to slow down slightly, since team meetings and interaction
|
|
became more difficult. While previously, hardware components were distributed among some team members
|
|
(Ryan and Matthew), this became impractical due to the requirement of social distancing. However, this
|
|
did meaningfully affect the project deliverables, as the team was able to set up a system for remotely
|
|
modifying the physical components' firmware.
|
|
|
|
\subsection*{Next Steps}
|
|
To pick the project up, we recommend that different hardware be used for the collar devices. We have run
|
|
into some serious limitations while using the LoRa-enabled ATMega controllers; the combination of LoRa,
|
|
GPS, and Protobuf firmware was too large to fit in device memory. This led us to develop our own, stripped
|
|
down versions of a lot of the software. Yet even with this, the firmware on the collar ends up running
|
|
in a very constrained environment, and small changes that increase stack usage even by a small amount
|
|
can lead to crashes.
|
|
|
|
At present, the collar is capable of sending its position, retrieving valid grazing areas, and verifying
|
|
that it is in a valid position. The next step on the collar side, then (after the hardware changes suggested
|
|
above) would be to add to the collar a physical indication of whether or not it is in a valid grazing
|
|
boundary (see the Design Document below for an idea of what that is). This physical indication can be
|
|
an LED light, but the final goal would be to have that indication be a buzzer or an eletric shock.
|
|
|
|
The gateway software is capable of receiving and configuring a single collar device (See Appendix 4
|
|
for an explanation of why only a single device is currently supported). The next step for the
|
|
gateway software, then, is to add support for multiple collar devices. Additionally, the gateway
|
|
software currently uses the Things Network to decode and process LoRaWAN packets. This is less
|
|
than ideal since it requires a connection to the Internet (rather than allowing the system
|
|
to work on a LAN), and because it uses a third-party service to process animal data. To avoid
|
|
this, the best course of action would be to use a local LoRaWAN implementation on the gateway.
|
|
At the time of writing such software is not easily available, and was deemed too difficult to
|
|
create. Finally, we recommend that a mechanism be added to the gateway software to verify
|
|
that a collar has received an updated grazing boundary.
|
|
|
|
The Android application is, in our view, the lowest priority at present. It is capable
|
|
of authenticating and working with the API server, viewing animal locations,
|
|
and of modifying collar grazing boundaries. Next steps could include the display of additional
|
|
statistics (this would also require changes to the API server).
|
|
|
|
Please refer to Appendix 4 for a description of all things that need to be done.
|
|
|
|
\end{document}
|