result.tex

The final result of the project, in regards to fulfilled goals, is as follows:

\begin{itemize}
    \item[\checkmark]{The drone should be airborne and be able to carry its entire payload long enough to safely map an entire mineshaft.} %Which takes approximately...?
    \item[\checkmark]{It must be cheaper than the previous mapping method.}
    \item[\checkmark]{New units must be easily replaceable.}
    \item[\text{\sffamily X}]{It must be able to ascend and descend the shaft without direct human input and land autonomously.}
    \item[\checkmark]{To facilitate this it shall implement some collision avoidance to prevent it hitting the sides of the shaft.}
    \item[\text{\sffamily X}]{Under flight, the drone should map the surrounding mineshaft, either using a rotating laser sensor or similar.}
    \item[\checkmark]{The drone should communicate with a base station and return its findings in real-time.}
    \item[\text{\sffamily X}]{The drone should return to its base station and land in case of lost communications.}
    \item[\text{\sffamily X}]{The base station shall present an interface containing relevant information for control of the drone, as well as receive data from the drone.}
    \item[\text{\sffamily X}]{The drone should not let erroneous external input jeopardize system stability.}
\end{itemize}

\subsection{UWB - Final state}
    \subsectionauthor{Author: Fredrik Grönlund}
    The following items are complete in development:
    \begin{itemize}
        \item The DW1000 library has been ported to the STM32F7 processor.
        \item Regular data transmission over UWB works.
        \item Regular data reception over UWB works.
    \end{itemize}
    Following items were not completed:
    \begin{itemize}
        \item SPI does not operate using DMA. 
        \item Code for data transfer over UWB is not in place.
        \item Ranging via UWB is not working.
        \item The DW1000 library lack functionality for many functions.
        \item LAMP needs to be extended to include Sonar and ranging data
    \end{itemize}

    Most of the missing functions should not be difficult to implement given time.
    The required infrastructure is mostly in place, such as DMA settings and ranging examples and parsing.

    Ranging was developed until the end of the project.
    Time ran out, so no real progress was made.
    The SPI team believes that the best way to implement the ranging is to scrap most of the state code borrowed from the library example and instead construct a new from scratch.
    This would likely be simpler to understand and follow, and is more likely to work than the current implementation.

    Regarding the DW1000 library, many parts of it could use expanding and explaining.
    The UWB development team encountered several event flags that were not present as one would expect.
    They also suspect that the ranging functionality file might be better if included as a library, although it is not presented as such.

\subsection{IR - Final state}
    \subsectionauthor{Author: Fredrik Grönlund}
    Development on IR was halted early in development, as we found that the sonar sensors were perfectly adequate for the application.
    In comparison, two IR sensors were required for each sonar, and they still had a worse accuracy, speed and usability.
    Thus the developer was moved to SPI and UWB development.

    The sensors were ordered and should accompany this project.
    The dev board shield has connectors dedicated to IR sensor connections, although these contacts have since been repurposed as general status LEDs.

\subsection{Sonars - Final state}
    \subsectionauthor{Author: Kamal Alkahwati}
    The Sonars are implemented according to specification requirements but
    upon testing it was discovered that they do malfunction sometimes. If HC-SR04 needs to measure a distance of more than ~600cm it will often malfuncion and give random measurement data. The problem is that the timeout of HC-SR04 doesn't work as it should, and instead of giving a timeout-pulse it just sends random data. It is suspected that this is a result of a too cheap assembly. This is solved using software filters, but they should be replace all in all in the future.


\subsection{Collision Avoidance - Final state}
    \subsectionauthor{Author: Lars Jonsson}
	The Colission Avoidance and hovering is working, the copter can fly between to walls, with some oscillations and not as stable as we had wanted.

	With further tuning of the PID's and some improved filtering of the sonar data, this could work to get a copter up and down the shaft without crashing.

	This was not a priority for us at the end, since this controlling approach probably will be changed later on in the project.


\subsection{LIDAR - Final state}
    \subsectionauthor{Author: Henrik Tjäder}
    LIDAR communication works, albeit with some caveats. Due to timing, sometimes LIDAR is not initialised properly before the much faster MCU requests data.

    A potential remedy for this is to delay during startup to give the LIDAR more time or alternatively write a parser to check for the LIDAR response.

    The intentions are to pack the LIDAR data into LAMP packets, this has not been finalized. All LIDAR data is currently sent over UDP to broadcast to ease debugging.

\subsection{Copter - Final state}
\subsectionauthor{Author: Max Unander}
	The copter worked pretty much as planed, it handled our payload with no problem and was able to fly for about ten minutes which is twice the required flight time.


\subsection{Circuit boards - Final state}
\subsectionauthor{Author: Max Unander}
	Our circuit boards are working well after a few patches. These patches includes fixing mistakes like crossed MISO and MOSI, also added a diode on the power board so that the 3.3 volt from the nucleo doesn't try to power the 5 volt when the battery isn't connected. New boards with all patches fixed and updated connectors are designed in eagle but haven't been ordered yet.

\subsection{TODO: COMPONENTS ADD A FINAL STATE. What is done/not done etc.}


%TODO: Split into other own file?
\subsection{Delivery}
    TODO: Put codebase in easier-to-reach place, like public GitHub?\\
    TODO: Generate Doxygen documentation.\\
    TODO: Instructions?

\subsection{Discussion}
    In general, development of the project has been successful.
    The timetables and designs presented early in development were rather quickly abandoned, as they were made with little understanding of the systems.
    Although the entire team had experience within their separate fields, none had worked on these systems before.
    Neither had we planned a system of this scale before.
    Because of this, timeplans were quickly deemed obsolete as we realized the scale and complexity of the project.

    Despite this, we would like to deem this project successful in its primary goal, to test if the idea was feasible.
    Although some issues were had with some hardware components, this could be resolved by using better components.
    Software trouble should smoothen out as experience grows, and it did so for our project group.

    Team members performed most of their work in the room provided by LTU, letting us cooperate and discuss.
    Alot of bugs and uncertainties were found in the in the HAL libraries throughout the project, some of which could be resolved pretty quickly whilst others were more time consuming. Some peripherals had such unreliable HAL libraries they were totally rewritten towards the end of the project. Having each other to discuss these issues, among other general questions regarding development proved to help significantly.
    This, combined with regular meetings each week allowed us to integrate our work more smoothly, as we were all present anyway.

    Many things not directly related to the project, but invaluable to the project's progress lies in the available tools and in the experince of those
    who wield said tools.

    With all of us having previous knowledge of STM32 hardware, few had delved deeper into the inner workings of how the toolchain manages to take all those source files
    and in the end produce a flashable executable. There exists many "pre-made" toolchains available from different vendors. To name a few,
    Atollic TrueSTUDIO, Kiel uVision, IAR EWARM, SW4STM32, lpcexpresso. Most of these come with their own IDE, either basing it on some opensource project such as Eclipse
    or implementing their own thing. Picking any one of these is by some means a way of getting trapped in a vendor lock-in since it is usually not trivial to maintain compatibility
    with more than one toolchain at a time or change between them.

    Then how to do it without these huge dependencies? The answer: GNU Make.

    As the project progressed the \texttt{Makefile} got improved and further functionality such as automating flashing and starting debugging sessions via OpenOCD + GDB were added.

    This gave each of us the freedom to pick our own preferred working environment, such as working directly with the files via \texttt{vim}, \texttt{sublime} or through a full-fledged
    IDE such as \texttt{Eclipse}.

    Having \texttt{git} made working together a breeze. It is easy to test things out in a new branch and then if things went as expected just merge the changes back to the main branch.

    With such modern hardware we would often need to run the very latest and in some cases even development versions of tools ta have proper support. Six out of seven group members
    chose to install and run an \texttt{Arch Linux}-based system for programming and debugging. This was thanks to the bleeding edge nature of the distribution and the extensive software library available.

    Even the very latest bleeding edge version of \texttt{arm-none-eabi} from the Debian \texttt{Sid} repository lagged behind the Arch-default version by a whole version: \texttt{5.4.1} vs \texttt{6.2.0}

    The reason this was of concern was that all versions available in Debian failed compiling due to lack of MCU specific floating point support.

    TODO: Add details from Timers, IMU, SONAR maybe?

    TODO: Continue this section!
%\subsection{Testing}
%    \subsubsection{Testing Strategy}

%    \subsubsection{Regression Hazards}

%    \subsubsection{Support Functions and Instructions}