diff --git a/Pictures/UML-Copter2.png b/Pictures/UML-Copter2.png
new file mode 100644
index 0000000000000000000000000000000000000000..92b11296b56e31aefba6a79cd2840282c7d0d04d
Binary files /dev/null and b/Pictures/UML-Copter2.png differ
diff --git a/chapters/result.tex b/chapters/result.tex
index 532917fe43a4271b1414c28715ad21de2eb40efb..aa5eae81d7afba6f78deaf207145321bb96fa2fc 100644
--- a/chapters/result.tex
+++ b/chapters/result.tex
@@ -51,10 +51,23 @@ The final result of the project, in regards to fulfilled goals, is as follows:
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{Collision Avoidance - Final state}
\subsectionauthor{Author: Lars Jonsson}
- The Colission Avoidance is working, the copter can fly between to walls for shorter amount of time, but not as stable as we had wanted.
- There are some still some tuning of the PID's left to get a more stable copter.
+ 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{TODO: COMPONENTS ADD A FINAL STATE. What is done/not done etc.}
@@ -82,6 +95,33 @@ The final result of the project, in regards to fulfilled goals, is as follows:
Some uncertainties with the HAL libraries and other functionality was easiest resolved this way, among other general questions regarding development.
This, combined with regular meetings each week allowed us to integrate our work more smoothly, as we were all present anyway.
+ \subsectionauthor{Author: Henrik Tjäder}
+ 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!
diff --git a/chapters/systemDesign.tex b/chapters/systemDesign.tex
index 454457930cf5a8e3f996e6993b9220d9cd6395dc..cfd48f1e33a4bf1d819a6136662697f12f9c9e04 100644
--- a/chapters/systemDesign.tex
+++ b/chapters/systemDesign.tex
@@ -1,21 +1,36 @@
\subsection{Code of Conduct}
- The code follows a simple code of conduct. This generally helps avoid variable naming collisions and other issues which may result in undefined behavior.
-
+ The code follows a simple code of conduct. This generally helps avoid variable naming collisions and similar issues which may result in undefined behavior. With much consideration to simplicity in development it has been kept limited to resolve the most important code structuring issues.
+
+ Each file of code contains a group of functions related to a specific functionality. To avoid memory leaks and overwriting data, every function and global variable in a file has a prefix, which is the same as the name of the file. Enabling a developer to easily follow the code flow through files when coding or debugging.
+
+ The prefix must begin with a capital letter and variables and functions should begin with a lower case letter, unless it is an abbreviation, though this is discouraged.
+
+ Most of the functionality has to be initialized on boot before it can be used. The decision to make an \texttt{Prefix\_init()} function makes it easy to keep code flow and code names similar throughout the code.
+ \begin{table}[H]
+ \caption{Code of Conduct Example} \label{tab:SysDesCodeOConEx}
+ \begin{center}
+ \begin{tabular}{ r l }
+ \\
+ Prefix & \texttt{IMU} \\
+ Filename & \texttt{IMU.c} \\
+ & \texttt{IMU.h} \\
+ Namespace & \texttt{IMU\_variable} \\
+ & \texttt{IMU\_functionName()}\\
+ Initialization & \texttt{IMU\_init()}
+ \end{tabular}
+ \end{center}
+ \end{table}
+
\subsection{Static Design}
\subsubsection{Class Diagram}
\begin{figure}[H]
\centering
- \includegraphics[width=\textwidth]{Pictures/uml}
+ \includegraphics[width=0.7\textwidth]{Pictures/UML-Copter2}
\end{figure}
-
+
\subsubsection{Module Diagram}
\begin{figure}[H]
\centering
\caption{System module diagram}
- \includegraphics[width=\textwidth]{Pictures/componentchart_2}
+ \includegraphics[width=0.7\textwidth]{Pictures/componentchart_4}
\end{figure}
-
- \subsection{Dynamic Design}
- \subsubsection{Activity Diagram}
- \subsubsection{Sequence Diagram}
- \subsubsection{State Diagram}
\ No newline at end of file
diff --git a/components/imu.tex b/components/imu.tex
index 000d9b4a1db5ff71de8cde62db0c0ed30d8edccb..75f495577fb4883c5404a496c961e2dc8d3afc53 100644
--- a/components/imu.tex
+++ b/components/imu.tex
@@ -1,15 +1,4 @@
\subsection{IMU - Inertial Measurement Unit}
- To track the movement of the copter in flight, a stable IMU with minimal swing effect has to be used.
- There are several low cost IMU's available on the market, similar to the one in the flight controller.
- While these are great for tracking instantaneous movement, they are not good at tracking movement over
- time. Due to noise and swinging of the gyro while accelerating in any direction, the tracking will be
- skewed while moving up and down the cave. This will result in a faulty scan. \newline
- Xsens Technologies are well known in the industry for producing stable and accurate IMU's. Their
- product series \href{https://www.xsens.com/products/mti-1-series/}{MTi 1} features all the specifications needed for the copter and was chosen as the
- primary IMU for the project.
+ To track the movement of the copter in flight, a stable IMU with minimal swing effect has to be used. There are several low cost IMU's available on the market, similar to the one in the flight controller. While these are great for tracking instantaneous movement, they are not good at tracking movement over time. Due to noise and swinging of the gyro while accelerating in any direction, the tracking will be skewed while moving up and down the cave. This mostly results in incorrect or unreliable scanning data.
- \begin{figure}[H]
- \centering
- \includegraphics[width=0.5\textwidth]{flowcharts/IMU}
- \caption{IMU flowchart}
- \end{figure}
+ Xsens Technologies are well known in the industry for producing stable and accurate IMU's. Their product series \href{https://www.xsens.com/products/mti-1-series/}{MTi 1} features all the specifications needed for the copter and was chosen as the primary IMU for the project.
diff --git a/flowcharts/IMU2.png b/flowcharts/IMU2.png
new file mode 100644
index 0000000000000000000000000000000000000000..6d839d0460fe057f55b6543eedaa2bb7d2d72272
Binary files /dev/null and b/flowcharts/IMU2.png differ
diff --git a/implementation/ethernet-lidar.tex b/implementation/ethernet-lidar.tex
index 0e36c7b32a5a94cd86a0c4c0ca51d74b487a22e9..c37a281ac6599799cf4f4842ea65383260821582 100644
--- a/implementation/ethernet-lidar.tex
+++ b/implementation/ethernet-lidar.tex
@@ -47,7 +47,6 @@ a wireless bridge between the STM32F767IZ and the LIDAR to the base station coll
The ALFA AIP-W512 being both lightweight and operating at \SI{5}{\volt} made it an easy choice since
any extraneous weight is unwanted and it could be directly attached to the \SI{5}{\volt} rail.
-The STM32 Nucleo board will request
Having ethernet hardware does not solve the problem altogether since the
protocols and setup required for functional ethernet communication are non-trivial.
diff --git a/implementation/imu.tex b/implementation/imu.tex
new file mode 100644
index 0000000000000000000000000000000000000000..188f41b45e01b1ae66b5ea8bed3bddd65ceed7ef
--- /dev/null
+++ b/implementation/imu.tex
@@ -0,0 +1,28 @@
+\subsection{IMU}
+ \sectionauthor{Author: Daniel Björk}
+ Upon initialization of the \texttt{IMU} code, a request to go to configuration mode is sent to the MTi. The MTi is now prepared to be configured. \texttt{IMU} then transmit the configuration data, which enables the output of Euler Angles and Free Acceleration data at 100Hz.
+
+ See Figure~\ref{fig:imuflowchart} for a visual representation of the communication flow. \texttt{IMU} first transmits a request of configuration mode, waits for a confirmation response, and then continues to transmit configuration data. When the configuration is complete, a request of measurement mode is sent to the MTi. The MTi will now continuously transmit data at the configured rate.
+
+ \begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\textwidth]{flowcharts/IMU2}
+ \caption{\texttt{IMU} communication flowchart}
+ \label{fig:imuflowchart}
+ \end{figure}
+
+ The data received \texttt{8bits} at a time. Each data point transmitted contains \texttt{32bits}, formatted as a standard \texttt{IEEE 754 float}. The data is shifted into a temporary \texttt{32bit unsigned int} and then a \texttt{memcpy()} is executed from the \texttt{int} to a \texttt{float}. The data points are then sent over to \texttt{MSP} and stored.
+
+ \begin{table}[H]
+ \begin{center}
+ \begin{tabular}{ l l }
+ \textbf{Pin} & \textbf{Usage} \\
+ \hline
+ PA3 & USART2 RX \\
+ PD5 & USART2 TX \\
+ PD3 & USART2 CTS \\
+ PD4 & USART2 RTS
+ \end{tabular}
+ \end{center}
+ \caption{Pin Description} \label{tab:IMUpindescription}
+ \end{table}
\ No newline at end of file
diff --git a/implementation/usartComPro.tex b/implementation/usartComPro.tex
new file mode 100644
index 0000000000000000000000000000000000000000..8ea0e2592c3cf7034102493292506f838a52d895
--- /dev/null
+++ b/implementation/usartComPro.tex
@@ -0,0 +1,16 @@
+\subsection{USART Communication Protocols}
+ \sectionauthor{Author: Daniel Björk}
+ \subsubsection{xBus}
+ Communication with the IMU is preformed with an xBus message. First byte is always the preamble, followed by the destination address(which can be ignored when using USART), an operation code and the length of the message. To verify the message, a checksum is appended to the message.
+
+ The message itself contains multiple data points, identified by a 2byte data identifier and an 1byte length.
+
+ \begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{Pictures/xBus}
+ \caption{MTi xBus data point message example}
+ \label{fig:imuflowchart}
+ \end{figure}
+
+ \subsubsection{MSP}
+ To communicate with the flight controller on board, an implementation of the MSP communication protocol is used. It shares much similarities with the xBus, but can be regarded as a simpler version. A preamble is used to trigger the start of a message, followed by the operation code and the length of the message. At the end, a checksum is appended to verify the message.
\ No newline at end of file
diff --git a/main.tex b/main.tex
index ccda119ba44775dc1e5067a8190f850be3d65a3c..b1f27dc251510525bb58e2cde12f80f159e4a6e9 100644
--- a/main.tex
+++ b/main.tex
@@ -3,6 +3,7 @@
\usepackage[utf8x]{inputenc}
\usepackage[english]{babel}
\usepackage{bytefield}
+\usepackage{courier}
\include{latexoptions}
% For coloured tables.
@@ -75,6 +76,7 @@
\newpage
\section{Components and Peripherals}
\input{./components/usart}
+ \input{./components/imu}
\input{./components/ethernet}
\input{./components/lidar}
\input{./components/timer}
@@ -98,6 +100,8 @@
\newpage
\section{Implementation}
\input{./implementation/workflow.tex}
+ \input{./implementation/imu.tex}
+ \input{./implementation/usartComPro.tex}
\input{./implementation/spi-uwb.tex}
\input{./implementation/sonar.tex}
\input{./implementation/ppm.tex}