311 lines
16 KiB
TeX
311 lines
16 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}
|
|
\usepackage{parcolumns}
|
|
\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{Retrospective}
|
|
|
|
\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 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{25pt}
|
|
}
|
|
\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
|
|
\tableofcontents
|
|
|
|
\pagebreak
|
|
|
|
\section{Introduction}
|
|
% TODO briefly recap the project purposes and goals
|
|
This document describes the current state, problems, and future
|
|
plans of the Fenceless Grazing Collars project. The FGC system's
|
|
purpose is to reduce the amount of manual labor required for herding
|
|
large numbers of livestock. The system does so by placing GPS-equipped
|
|
collars onto individual animals, and producing a negative stimulus
|
|
(either auditory or electrical) to discourage the animals from leaving
|
|
user-configured grazing areas. The goal of the project is to
|
|
provide a reliable, cost-effective, and accessible replacement
|
|
for manual farmer labor.
|
|
|
|
\section{Current Project State}
|
|
% TODO describe where you are currently on the project
|
|
At present, the initial design of the project is complete. The project's structure
|
|
lends itself very well to division among the three group members, and all
|
|
team members' responsibilities have been explicitly defined and agreed upon.
|
|
The team members all successfully researched the components of the project that
|
|
they are responsible for, and their research has been incorporated into a thorough
|
|
design document.
|
|
|
|
Both the technical reviews produced by the individual team members and the
|
|
design document have been validated by the client, and there is consensus
|
|
between the team and the client regarding future plans.
|
|
|
|
With the initial design complete, the project is ready to move into the
|
|
implementation stage, with the exception of funding: once the department
|
|
provides the team with funding required to purchase the hardware components
|
|
specified in the design document, work can begin on implementing an initial
|
|
prototype.
|
|
|
|
\section{Problems}
|
|
One of the few problems we had this term was difficulty scheduling meetings in which all
|
|
team members could meet with our client. As a result our interaction with our client was
|
|
minimal at times, and resulted in only a few meetings over the course of the term. While
|
|
this did not prove to be a significant blocker for our work, it did result in some necessary
|
|
clarification recently with our client in regards to our vision on how we planned to move forward.
|
|
We plan on fixing this problem by scheduling a biweekly meeting with our client at the beginning
|
|
of next term. The best way to ensure that our team can keep our client up to date is to have a
|
|
definite meeting time, and the best way to schedule this meeting would be as soon as all class
|
|
schedules have been finalized.
|
|
|
|
Another problem we encountered was lack of funding. While this was not an issue at the
|
|
beginning of the term, it is looking to be a serious blocker in the near future as our next step
|
|
the moment we get back from winter break is to purchase hardware. Ideally, this hardware would be
|
|
purchased prior to even returning to school to allow our team to start work on the physical
|
|
aspect of our project immediately. Our client has approved our hardware proposal, which was the
|
|
last step before purchasing. Our team has discussed this funding with our TA, who in turn has
|
|
brought it up to Professors Winters and Fairbanks. In an effort to ensure funding will be secured
|
|
as soon as possible, we will continue to follow up with our TA and the professors if necessary.
|
|
|
|
Our last small problem we came across was in regards to formatting for our different submissions.
|
|
One of our documents was incorrectly formatted as a result of our misunderstanding of the
|
|
requirements. Also, towards the beginning of the term we named our files incorrectly, resulting
|
|
in the loss of points. In order to ensure that all style guidelines are met in the future, we
|
|
will communicate with our TA, other students, and our professors as needed. Prior to asking
|
|
others, we will peruse the online documents provided to us on Canvas to ensure that we are
|
|
not asking questions that have already been answered.
|
|
|
|
\section{Weekly Progress}
|
|
% TODO The document should include a detailed, week-by-week summary of activities,
|
|
% problems, solutions, and the like (consider using your blogs to inform this report).
|
|
% The report should not include more than a summary of any bigger documents you produced
|
|
This section contains the summary of each week of the Fall term during which the
|
|
project was active.
|
|
|
|
\subsection{Week 3}
|
|
This was the first week during which we tracked progress. It consisted largely
|
|
of drafting, submitting, and merging
|
|
the requirements document and problem statements. This went smoothly; each team member
|
|
felt confident in their understanding of the project's requirements and the
|
|
problem it is solving, likely because our group was offered the project in
|
|
the summer before the class had started. The only foreseeable problems at
|
|
this point is the difficulty in scheduling a semi-regular meeting with the
|
|
client: each group member, and the client themselves, are exceptionally
|
|
busy during this academic term, and on most week, no single time works
|
|
for every person. This problem is not significant at this point, however,
|
|
because the team has enough information to work for the time being.
|
|
|
|
\emph{Note: At this point, some members of the team received lower scores
|
|
than expected for certain submissions. Since the content of the various
|
|
submissions was agreed upon by each team member, the variance in
|
|
the received scores was unexpected and was listed as a "problem". However,
|
|
this did not impact the project itself, since one of the submissions
|
|
received full points.}
|
|
|
|
|
|
\subsection{Week 4}
|
|
This week consisted largely of revisions to the requirements document and
|
|
independent research. Team roles have been decided as early as this week:
|
|
each team member has a particular "strong suit", and will be playing
|
|
to their strengths in implementing this project. Since team roles have
|
|
been assigned, and since the team already has a vague understanding
|
|
of what components the project will consist of, members are eager to purchase
|
|
hardware and begin tinkering. However, a meeting has not yet been established
|
|
with the client at this point, and the matter of funding has not yet been
|
|
decided. It is not clear at this point who will be financing the hardware
|
|
required for the project.
|
|
|
|
\subsection{Week 5}
|
|
During this week, the source of funding was somewhat elucidated by a team
|
|
member's individual meeting with the client. The team was informed
|
|
that \$300 has been set aside for each Senior Capstone team to help with funding.
|
|
The team's TA was asked about this, but was not aware of the details, and
|
|
offered to contact Dr. Winters.
|
|
|
|
While there is not yet an exact date for a meeting with the client, one
|
|
is soon to be established. Each group member and the client provided the
|
|
times during which they are available, revealing that there were no
|
|
time slots during which each individual was available to meet. As such,
|
|
one of the group members will likely skip this meeting, and the rest
|
|
of the group members will fill them in.
|
|
|
|
In preparation for the client meeting, team members have been doing further
|
|
research into their components of the project. This coincides well with the
|
|
first drafts of the technical review, which require exactly the type of
|
|
research that the team will present to the client in the meeting.
|
|
|
|
\subsection{Week 6}
|
|
The highlight of this week was the first meeting with the client. This meeting
|
|
was scheduled last-minute, but went very well. The team's plan and the client's
|
|
expectations were not significantly different. To accommodate the team and
|
|
the client's busy schedule, meetings were agreed to be bi-weekly, and made
|
|
optional (to prevent wasted time in the event that no new information is
|
|
required by the group). During this week, team members wanted to begin
|
|
prototyping to accelerate the development and revision of an initial
|
|
design. However, the issue of funding remained at this point; a team member noted
|
|
"any kind of funding is a long way away" in their individual progress report.
|
|
In retrospect, this was not a significant challenge at this time: many changes
|
|
were made to the original design during the drafting of the Design Document,
|
|
meaning that some purchased hardware might not have been used.
|
|
|
|
\subsection{Week 7}
|
|
During this week, the team completed an initial draft of the Design Document.
|
|
This was not written in IEEE 1016-2009 compliant format, and generally
|
|
consisted largely of information from the Tech Review. The team was aware
|
|
of this, and planned to modify the document to be compliant to IEEE 1016-2009
|
|
in the second draft. The first draft was submitted on time and with no other issues.
|
|
|
|
Since the team was busy with the creation of the design (and the design document),
|
|
the issue of funding was not significant at this time. The group member responsible
|
|
for the hardware simulated some components of the initial design, in order
|
|
to explore the implementation of the project. However, no significant insight
|
|
was gained from this, with the exception of familiarity with the tooling.
|
|
|
|
\subsection{Week 8}
|
|
In this week, the design document was completely transitioned to IEEE 1016-2009 format.
|
|
This took a significant amount of work for three reasons: the IEEE spec is very wordy
|
|
and needlessly abstracted, the specified perspectives in the IEEE spec were not
|
|
entirely covered by the first draft, and a medical emergency temporarily took out a team member.
|
|
Despite the difficulties, the assignment was completed before the initial deadline (which
|
|
was later postponed), and the team had a chance to verify the content of the design document
|
|
with the course's instructors. This helped discover several minor issues with the format
|
|
of the document, which were promptly corrected. At this point, the document was
|
|
complete with the exception of UML diagrams, which were scheduled to be inserted
|
|
during the weekened.
|
|
Other than the medical emergency and the design document, no significant problems
|
|
or progress occurred this week.
|
|
|
|
\subsection{Week 9}
|
|
This was a short week which ended in Thanksgiving, and no significant changes
|
|
to the state of the project occurred at this time. The team submitted all the
|
|
generated documentation to the client / advisor, but did not receive a
|
|
response during this week. No issues were encountered during this time.
|
|
|
|
\subsection{Week 10}
|
|
The entire team, as well as the client, had a chance to meet and discuss
|
|
the submitted documents this week. The client was very satisfied with the results,
|
|
but wanted a high-level overview of the system that was not "scattered through
|
|
a big document".
|
|
On the team level, a new system was introduced to help evenly distribute workload
|
|
among team members. A Trello-style board will be used to plan for the tasks
|
|
ahead and assign work to members, so that there is a larger degree of personal
|
|
responsibility for parts of each assignment.
|
|
|
|
\section{Retrospective}
|
|
% TODO add retrospective
|
|
% positives column: anything good that happened
|
|
% deltas column: changes that need to be implemented
|
|
% actions column: specific actions that will be implemented in order to create the necessary changes
|
|
\setlength{\columnseprule}{0.4pt}
|
|
\begin{parcolumns}[colwidths={1=0.3\textwidth}]{3}
|
|
\colchunk{
|
|
\subsection{Positives}
|
|
\emph{Week 3} This week included full completion of the requirements document rough draft and we began merging our problem statements. The requirements document is very near
|
|
complete and we anticipate very little additional work to finish. Our team
|
|
reports good division of labour, and initial communication with client
|
|
went well.
|
|
|
|
\emph{Week 4} Good work has been put into researching the specific
|
|
hardware we will need for our project. Specifics into the protocol
|
|
and communication between modules has been decided on well prior
|
|
to the design document. Professor Hamdaoui is aware of our progress
|
|
and mentioned we are ready for funding. Lastly, we have completed
|
|
the requirements document and are pleased with our work on it.
|
|
|
|
\emph{Week 5} All team members have completed their tech reviews
|
|
with no problems to report. Our team met with our client, who was
|
|
pleased with our work so far and continued to mention funding, and
|
|
asked for some form of presentation in regards to our hardware
|
|
decisions.
|
|
|
|
\emph{Week 6} A biweekly meeting has been setup with our client
|
|
to discuss current status. All tech reviews have been completed,
|
|
and the meeting with our client went very well, with plans to talk
|
|
more in the future.
|
|
|
|
\emph{Week 7} Design document has been fully completed and
|
|
submitted, fully packed with specific information on how we will
|
|
complete our project.
|
|
|
|
\emph{Week 8} Design document has been sent to our client for
|
|
review. We are one step closer to funding as the question has been
|
|
posed to both our TA and the professors.
|
|
|
|
\emph{Week 9} We culminated our finalized work and sent it to our
|
|
client for review.
|
|
|
|
\emph{Week 10} We met with our client in regards to our submitted
|
|
documents. Our client, Professor Hamdaoui, was really receptive to
|
|
our work and is excited for us to get our hands on the hardware in
|
|
order to begin the actual project.
|
|
}
|
|
\colchunk{
|
|
\subsection{Deltas}
|
|
|
|
Eventually the project will need to be funded in order to get the hardware that is needed to prototype
|
|
the device that is the focus of this project.
|
|
|
|
Document requirements need to be more thoroughly processed such that they satisfy all requirements as are appropriate.
|
|
|
|
Across the team tasks need to be more evenly distributed and properly managed such that deadlines can be met in a more efficient manner.
|
|
}
|
|
\colchunk{
|
|
\subsection{Actions}
|
|
|
|
Add some text
|
|
}
|
|
\end{parcolumns}
|
|
\end{document}
|