106 lines
7.2 KiB
TeX
106 lines
7.2 KiB
TeX
\documentclass[10pt, draftclsnofoot,onecolumn, compsoc]{IEEEtran}
|
|
|
|
\def\changemargin#1#2{\list{}{\rightmargin#2\leftmargin#1}\item[]}
|
|
\let\endchangemargin=\endlist
|
|
|
|
\usepackage{setspace}
|
|
\linespread{1}
|
|
|
|
\title{Conclusions and Reflections}
|
|
|
|
\begin{document}
|
|
\maketitle
|
|
|
|
\section*{Ryan Alder}
|
|
\subsection*{What technical information did you learn?}
|
|
I learned how to write C++ code for AVR, how to compile and flash code onto Arduino chips, and how to use a bootloader (vs no bootloader) for Arduino. Outside of the hardware, I learned a lot regarding LoRa and LoRaWAN, including the specific implementation and design constraints of this communication protocol. I went into this project knowing nothing regarding LoRa, and have come a very long way since then. Diving into LoRa specification was extremely fun and rewarding, as it helped us to understand how to implement the protocol into our network. This information also provided me with knowledge regarding the constraints of the LoRa protocol, informing me of the scalability and efficiency of a full LoRaWAN network.
|
|
|
|
\subsection*{What non-technical information did you learn?}
|
|
How to communicate with team members, project management, and document design. This class required a lot of writing which I would not classify as a strong suit for myself, and having the opportunity to write helped me to build that skill.
|
|
|
|
\subsection*{What have you learned about project work?}
|
|
Specifically, I have learned how to effectively spread out work and work as a team. While I have had internship experience before, much of my work was completely solo and I do not have much experience working on software as a team. This is the largest project I have participated in where there were other people working on the same code base, which taught me how to develop software with others.
|
|
|
|
\subsection*{What have you learned about project management?}
|
|
Mostly, each team needs an actual leader. A team is more efficient with a person in charge helping to make decisions and assign work. Our team learned this after the Fall term, and had one of our team members assign out work during the Winter term.
|
|
|
|
\subsection*{What have you learned about working in teams?}
|
|
I have learned how to communicate with others and spread out the work. As a team member you must be flexible to other ideas, especially if you are not in charge of the team. Learning new things that others want to do is required, otherwise you wont be able to contribute or will end up forcing other people to do things that only you are confident with. Flexibility and maleability leads to a good, effective team. The more variety in terms of ideas that are brought to the table results in a better product.
|
|
|
|
\subsection*{If you could do it all over, what would you do differently?}
|
|
Honestly I wouldn't change much. After the first term, our team discovered a better way of splitting up work to make us more efficient and ensure work was being done evenly. The only significant thing I would change would be to implement this design from the beginning, to reduce anger amongst teammates and increase our efficiency. We used an online resource to assign out action items to the team members, and then team members could complete these action items on their own time and report results back to the team via this online tool.
|
|
|
|
\pagebreak
|
|
\section*{Matthew Sessions}
|
|
\subsection*{What technical information did you learn?}
|
|
That sometimes Arduino drivers will include an operating system, which consumes most of the available memory. How to write code that uses the least amount of space in C, C++ would generate a lot of useless code.
|
|
|
|
Rewriting Arduino drivers that were made in C++ can save a lot of application memory, each byte used matters a lot.
|
|
|
|
\subsection*{What non-technical information did you learn?}
|
|
Most wireless technology does not penetrate buildings, so an a area with a lot of buildings will yield poor signals between wireless devices.
|
|
|
|
\subsection*{What have you learned about project work?}
|
|
To commit changes often means that you can go back to something that worked a few minutes ago, being able to do this usually saves a lot of time.
|
|
|
|
Many (Arduino) libraries from the internet are poorly implemented and more often than not can be further optimized and tailored to the specific application.
|
|
|
|
\subsection*{What have you learned about project management?}
|
|
Storing all documents in a shared space keeps documents from getting lost and allows project members to access information quickly.
|
|
|
|
\subsection*{What have you learned about working in teams?}
|
|
Maintaining constant communication with the team is critical to making progress in any project.
|
|
|
|
That even with hardware it is possible to work with hardware over the internet through VPN and SSH.
|
|
|
|
\subsection*{If you could do it all over, what would you do differently?}
|
|
Hardware wise it would have been easier had we used an ARM CPU based microcontroller instead of AVR, as this would have provided us with much more memory and disk space for our application.
|
|
|
|
\pagebreak
|
|
\section*{Danila Fedorin}
|
|
|
|
\subsection*{What technical information did you learn?}
|
|
I did not learn any technical information this year. I did the sections of the project
|
|
that I knew how to do - the Android application and the API server. Our team did a great
|
|
job in separating concerns, so that I only needed to be aware of the boundaries between
|
|
our parts, and not of the implementation of the hardware.
|
|
|
|
\subsection*{What non-technical information did you learn?}
|
|
I learned that cows are actually surprisingly hard to train - though our project did not
|
|
reach the animal testing stage, I did some research, which suggested that fenceless collar
|
|
systems will be ineffective with most livestock.
|
|
|
|
\subsection*{What have you learned about project work?}
|
|
I did not learn much about project work, since this is not
|
|
at all my first project, and nor is it my biggest one. I find
|
|
that our inability to pick our own capstone projects tends to
|
|
lead to rather uninspired final products.
|
|
|
|
\subsection*{What have you learned about project management?}
|
|
I learned that having a centralized archive of all files related to the project
|
|
is very helpful. This is the first project I was part of
|
|
that was not entirely contained within a Git repository, and
|
|
had other metadata (images, documents, receipts). With the year
|
|
coming to an end, we now find ourselves with a complete
|
|
archive of all our data, without any hastle.
|
|
|
|
\subsection*{What have you learned about working in teams?}
|
|
This was the first project I was part of that did not
|
|
have a well-defined position of power. Though the client
|
|
did effectively tell us what to do, they did not micromanage
|
|
the majority of our group work, and the team had to find
|
|
its own dynamic to meet deadlines. I learned about the
|
|
value of explicitly delegating action items to group members,
|
|
who, though willing to help, would not do so without
|
|
request. This is likely because, without well-defined
|
|
goals, it's hard to know where to start.
|
|
|
|
\subsection*{If you could do it all over, what would you do differently?}
|
|
I would take some time to look into what my teammates are doing.
|
|
I did what I knew how to do, and time pressures led me to not stray
|
|
far from my own part of the work. However, my team members were
|
|
working on some interesting stuff, and I would've learned a lot
|
|
from looking over their shoulders.
|
|
|
|
\end{document}
|