Fixed system design chapter indexing and mergefix

chapters/introduction.tex

 %TODO: Rewrite this as needed.
+\sectionauthor{Author: Fredrik Grönlund}
 Within the LKAB mine, ore is dumped down slanted mine shafts in order to transport them to further handling %?
 These ore shafts should conform to a maximum width of $\SI{3}{\meter}$, but dumped ore can erode the walls of the shaft to unsafe levels.
 This erosion must be measured, as it can become a safety and efficiency issue, should it undermine other tunnels.
@@ -10,7 +11,6 @@ This report will document the creation of a semi-autonomous drone, equipped to s
     This project was conducted at Luleå University of Technology, in cooperation with Conex AB and LKAB.
     Analysis of their roles in the project is presented in Table~\ref{tab:stakeholder_matrix}.
     This describes each shareholder, the problem they wish to solve, the what each can aid the project with and their interaction with the project.
-    %TODO: Explain better?
 
     %Use Stakeholder Analysis Matrix
     \begin{table}[h]
@@ -19,9 +19,12 @@ This report will document the creation of a semi-autonomous drone, equipped to s
         \label{tab:stakeholder_matrix}
         \begin{tabular}{|p{0.16\textwidth}|p{0.26\textwidth}|p{0.2\textwidth}|p{0.2\textwidth}|p{0.14\textwidth}|}
             \hline
-            \textbf{Stakeholders} & \textbf{Problem} & \textbf{Interest} & \textbf{Potential} & \textbf{Interaction} \\ \hline
-            LKAB & Erosion in dumping mine shaft. Mine shafts off-limits for humans. & Wants to improve erosion detection for efficiency. & Knowledge of environment and solutions. & Indirect \\ \hline
+            \textbf{Stakeholders} & \textbf{Problem} & \textbf{Interest} & \textbf{Potential} & \textbf{Interaction} 
+            \\ \hline
+            LKAB & Erosion in dumping mine shaft. Mine shafts off-limits for humans. & Wants to improve erosion detection for efficiency. & Knowledge of environment and solutions. & Indirect 
+            \\ \hline
             Conex & No ready solution or direct experience of measuring mine shafts. & Develop a suitable solution for mapping. Receive expertise on drones and mapping. & Experience with unmanned drones, sensors and mapping. & Indirect /Direct \\ \hline
-            LTU & TODO: ? & Section of doctorates interested in unmanned drones. & Experts in drone control. Programming expertise. Has access to equipment and locale. & Direct \\ \hline
+            LTU & Research interest in drone usage. & Section of doctorates interested in unmanned drones. & Experts in drone control. Programming expertise. Has access to equipment and locale. & Direct 
+            \\ \hline
         \end{tabular}
     \end{table}
\ No newline at end of file

chapters/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{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}
+    \subsectionauthor{Author: Fredrik Grönlund\\Add people as they write}
+    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 the scale and complexity of the project became obvious.
+
+    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.
+
+    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}
+

chapters/systemDesign.tex

-    \subsection{Static Design}
 	\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.
+		
+	\subsection{Static Design}
 		\subsubsection{Class Diagram}
 			\begin{figure}[H]
 				\centering
 				\includegraphics[width=\textwidth]{Pictures/uml}
 			\end{figure}
+		
 		\subsubsection{Module Diagram}
 			\begin{figure}[H]
 				\centering
-                \includegraphics[width=\textwidth]{Pictures/componentchart_2}
 				\caption{System module diagram}
+				\includegraphics[width=\textwidth]{Pictures/componentchart_2}
 			\end{figure}
 
 	\subsection{Dynamic Design}

components/casesandmounts.tex

+\subsection{Cases and mounts}
+\subsectionauthor{Author: Max Unander \\Reviewer: Lars Jonsson}
+
+When designing mounts we started with the ultrasonic sensors, we wanted the sonar arms and cases to double as bumpers so if we hit something like a wall these would hit the wall instead of the propellers. 
+This was achieved by simply extending the motor mount arms so that the sonar case would protrude beyond the propellers, see Figure~\ref{fig:sonararm}.
+
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.5\textwidth]{Pictures/sonar3}
+	\caption{3D model of a sonar arm in 3D Builder}
+	\label{fig:sonararm}
+\end{figure}
+
+The 3D model of the case for the sonar we got from "thingiverse.com" see Figure~\ref{fig:sonarcase} since it's a commonly used sensor it was easy to find,
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.5\textwidth]{Pictures/sonarfram}
+	\caption{3D model of a sonar case in 3D Builder}
+	\label{fig:sonarcase}
+\end{figure}
+We designed a tower that would hold our LIDAR and stepper motor. This elevates the LIDAR so it's field of view is not obstructed by the copter as much and also gives us room to mount the stepper motor.
+When designing the tower that would hold our stepper motor and LIDAR we decided to include a mount for our MCU on the side, see Figure~\ref{fig:steppermcu}
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.5\textwidth]{Pictures/steppermcu}
+	\caption{3D model of the mount that holds the stepper moter with laser scanner and has a mount for the MCU on the side}
+	\label{fig:steppermcu}
+\end{figure}
\ No newline at end of file

components/circuitboards.tex

+\subsection{Circuit boards}
+\subsectionauthor{Author: Max Unander \\Reviewer: Lars Jonsson}
+
+We decided to make a shield to distribute all connectors from the Nucleo board base see Figure~\ref{fig:shield}. 
+The reason we decided to make a shield was that we still wanted to use the Ethernet port on the Nucleo and since we lack any real analogue components keeping the short traces to reduce disturbances was not a priority.
+The shield board contains connectors to all our peripherals except the LIDAR, because the LIDAR uses Ethernet communication which is already integrated on the Nucleo board. 
+We used a dip socket for the IMU because of the convenience when setting up the chip with our breakout board and then just moving the chip.
+We decided to use a switching regulator to make a five volt rail for peripherals, because of efficiency when stepping down from 15 volts.
+A 3.3 volt rail for logic level was needed so a linear regulator from five volt was suitable there.
+All power rails and 15 volt peripherals were handled on a separate board to avoid disturbance seen in Figures \ref{pwreagle} and \ref{pwrirl}.
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.5\textwidth]{Pictures/copterboard}
+	\caption{Soldered shield attached to the Nucleo without peripherals}
+	\label{fig:shield}
+\end{figure}
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.5\textwidth]{Pictures/pwrbrd-final}
+	\caption{Power distribution board with stepper motor driver}
+	\label{pwreagle}
+\end{figure}
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.5\textwidth]{Pictures/pwrirl}
+	\caption{Power board on the copter}
+	\label{pwrirl}
+\end{figure}
\ No newline at end of file

components/connectionsandwiring.tex

+\subsection{Connections and wiring}
+\subsectionauthor{Author: Max Unander \\Reviewer: Lars Jonsson}
+% Bilder på bägge kontakterna hade nog varit nice, isåfall i en subplot.
+When wiring everything up on the copter we used xt60 connectors to distribute power from the battery to ESCs and power board because of their high current capability and keyed design. 
+The connectors we used on the shield and power board were "Molex LLC" which have stable locking connection that can only be plugged in one way. 
+The only complicated part of the wiring was when connecting the laser scanner, because we wanted to rotate the laser to get 3D images we had to route wires though the motor.
+To do this we need to use a slip-ring to avoid twisting the cables see Figure~\ref{fig:slipring}.
+% Vet man vad en slip-ring är? kanske måste ha bild här också? eller förklara lite mer.
+A hollow shaft stepper motor was used to be able to route wires through the motor.
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.3\textwidth]{Pictures/slipring.jpg}
+	\caption{Slipring for rotating connection without twisting wires}
+	\label{fig:slipring}
+\end{figure}

components/copterparts.tex

 \subsection{Copter parts}
-	    % Kanske bör sägas något om varför vi valde att bygga en egen kopter till att börja med? //Lars
-	    % Kom ihåg SI kommandot \SI{1}{\kilogram} t.ex.
+\subsectionauthor{Author: Max Unander \\Reviewer: Lars Jonsson}
+
 Since we decided to base our quadrocopter around the open source flight controller Flip32 because of the ability to customize 
 your configuration and multiple ways of communicating with the flight controller, this also meant we had to build the copter
 When starting to assemble a copter we first started by choosing a suitable frame to fit the equipment.
 A 65cm square frame was chosen to get space for the sensors between the rotors.
 Next step was to choose motors and propellers to get enough lift for our payload at a comfortable throttle setting.
 The NTM propdrive 28-30S motor with a TGS 12x6 propellers and a 4S Li-Po battery would suit our needs.
-        % Ekvationsreferens som flytande text. //Lars
 This would give us enough lift for 3kg of payload at full throttle see equation(\ref{mcopter}-\ref{payload}), which means we should be able to fly with \SI{1}{\kilogram} payload at a reasonable throttle setting.
 ESC's where chosen to handle the battery voltage and amperage of the motors, Afro 30A fit these requirements and also runs th open source software SimonK which allows a lot of settings.
 The last step was to choose battery size and discharge rating to handle flight time and current delivery. 
@@ -17,99 +16,14 @@
 	M_{Copter} = M_{frame} + 4\cdot M_{motors} + 4\cdot M_{ESC} + 4\cdot M_{prop} + M_{battery} = 1749.2g
 	\label{mcopter}
 \end{equation}
+
 \begin{equation}
 	Payload_{max} = Thrust_{tot}-M_{Copter} = 4*1200-1749.2=3050.8g
 	\label{payload}
 \end{equation}
+
 \begin{equation}
 	Flight\ time = \frac{Battery\ capacity}{Max\ amp} =
 	\frac{8000mAh}{80A} \approx 6\ minutes
 	\label{flighttime}
 \end{equation}
\ No newline at end of file
-        
-                \subsection{Circuit boards}
-        
-        We decided to make a shield to distribute all connectors from the Nucleo board base. 
-        The reason we decided to make a shield was that we still wanted to use the Ethernet port on the Nucleo and since we lack any real analogue components keeping the short traces to reduce disturbances was not a priority.
-        The shield board contains connectors to all our peripherals except the LIDAR, because the LIDAR uses Ethernet communication which is already integrated on the Nucleo board. 
-        We used a dip socket for the IMU because of the convenience when setting up the chip with our breakout board and then just moving the chip.
-        % Frågande utifall man ska skriva 3V och 5V eller om måste hålla sig till rule of 12?
-        We decided to use a switching regulator to make a five volt rail for peripherals, because of efficiency when stepping down from 15 volts.
-        A three volt rail for logic level was needed so a linear regulator from five volt was suitable there.
-        All power rails and 15 volt peripherals were handled on a separate board to avoid disturbance.
-        
-        % Finns en bild på pwrboard i eagle, men inte på shielden? Ska man ha bägge, eller ingen? Kanske har en tanke bakom detta?
-        % Kom ihåg lable på alla figurer, (fig:_____)
-        \begin{figure}[H]
-        	\centering
-        	\includegraphics[width=\textwidth]{Pictures/copterboard}
-        	\caption{Soldered shield attached to the Nucleo without peripherals}
-        \end{figure}
-        
-        \begin{figure}[H]
-        	\centering
-        	\includegraphics[width=\textwidth]{Pictures/pwrbrd-final}
-        	\caption{Power distribution board with stepper motor driver}
-        	\label{pwreagle}
-        \end{figure}
-        
-        \begin{figure}[H]
-        	\centering
-        	\includegraphics[width=\textwidth]{Pictures/pwrirl}
-        	\caption{Power board on the copter}
-        	\label{pwrirl}
-        \end{figure}
-        
-        
-        \subsection{Connections and wiring}
-        % Bilder på bägge kontakterna hade nog varit nice, isåfall i en subplot.
-        When wiring everything up on the copter we used xt60 connectors to distribute power from the battery to ESCs and power board because of their high current capability and keyed design. 
-        The connectors we used on the shield and power board were "Molex LLC" which have stable locking connection that can only be plugged in one way. 
-        The only complicated part of the wiring was when connecting the laser scanner, because we wanted to rotate the laser to get 3D images we had to route wires though the motor.
-        To do this we need to use a slip-ring to avoid twisting the cables see Figure~\ref{fig:slipring}.
-        % Vet man vad en slip-ring är? kanske måste ha bild här också? eller förklara lite mer.
-        A hollow shaft stepper motor was used to be able to route wires through the motor.
-        
-        \begin{figure}[H]
-        	\centering
-        	\includegraphics[width=0.5\textwidth]{Pictures/slipring.jpg}
-        	\caption{Slipring for rotating connection without twisting wires}
-        	\label{fig:slipring}
-        \end{figure}
-        
-        
-        
-        \subsection{Cases and mounts}
-        
-        When designing mounts we started with the ultrasonic sensors, we wanted the sonar arms and cases to double as bumpers so if we hit something like a wall these would hit the wall instead of the propellers. 
-        This was achieved by simply extending the motor mount arms so that the sonar case would protrude beyond the propellers, see Figure~\ref{fig:sonararm}.
-        
-        
-        \begin{figure}[H]
-        	\centering
-        	\includegraphics[width=\textwidth]{Pictures/sonar3}
-        	\caption{3D model of a sonar arm in 3D Builder}
-        	\label{fig:sonararm}
-        \end{figure}
-        
-        The 3D model of the case for the sonar we got from "thingiverse.com" see Figure~\ref{fig:sonarcase} since it's a commonly used sensor it was easy to find,
-        
-        
-        \begin{figure}[H]
-        	\centering
-        	\includegraphics[width=\textwidth]{Pictures/sonarfram}
-        	\caption{3D model of a sonar case in 3D Builder}
-        	\label{fig:sonarcase}
-        \end{figure}
-        
-        
-        When designing the tower that would hold our stepper motor and LIDAR we decided to include a mount for our MCU on the side, see Figure~\ref{fig:steppermcu}
-        
-        
-        
-        \begin{figure}[H]
-        	\centering
-        	\includegraphics[width=\textwidth]{Pictures/steppermcu}
-        	\caption{3D model of the mount that holds the stepper moter with laser scanner and has a mount for the MCU on the side}
-        	\label{fig:steppermcu}
-        \end{figure}

components/flightcontroller.tex

 \subsection{Flight Controller}
-	   %Behov av städning efter flytt
-       % To get the copter flying up and down through the shaft without crashing into the walls, we need to take away as much human interaction as possible.
-       % Therefore we will only use high level commands to fly this copter. 
-       % Only a couple of commands for controlling the copter like "go up", "go down" or "manual control" will be available in the final product.
-       % When you send the commands up/down the copter will start to navigate its own way up or down through the shaft using Infrared, Sonar and LIDAR.
-       % If you set the copter to manual mode, you will be controlling the Copter using a radio transmitter/receiver, and no sensors will be there to guide you.
-   
+\subsectionauthor{Author: Lars Jonsson \\Reviewer: Max Unander}
 
 A flight controller is needed to keep the quad copter stable while it's in the air.
 To be able to do this the flight controller uses an on-board IMU that measures the acceleration and the angular velocity of the copter.
@@ -34,4 +28,3 @@
 It has a quite powerful CPU if you compare to other flight controller in the same price range, the one it uses is a SMT32F3 processor.
 The use of an STM processor was also one of the requirements.
 The flight controller do also have support for some different open-source softwares.
\ No newline at end of file
-	   	        
\ No newline at end of file

components/ir.tex

@@ -10,10 +10,7 @@
         \href{https://www.arrow.com/en/products/gp2y0a710k0f/sharp?wm_g_phyloc=1012273&wm_g_intloc=&gclid=CO%5F1xubhidACFUvqcgodU7cF%2Dw&utm_source=google&utm_medium=cpc&utm_term=sharp+gp2y0a710k0f&utm_campaign=int+%2D+sku+%2D+sharp+%2D+dynamic+inventory}{Sharp GP2Y0A710K0F}.
         Its distance measuring range is $\SI{100}{}$ to $\SI{550}{\centi\metre}$.
         Accuracy could not be ascertained from the data sheet.
-        Output of the sensor is a current, where the voltage varies between
-        $\approx\SI{1.5}{} - \SI{3}{\volt} $, where lower values corresponds to longer distance.
-        % TODO: Add a picture?
-        % The voltage curve is demonstrated in Figure \ref{fig:long_ir_voltage}.
+        Output of the sensor is a current, where the voltage varies between approx. $\SI{1.5}{} - \SI{3}{\volt} $, where lower values corresponds to longer distance.
         Measurements are carried out continuously every $\SI{16.5}{\milli\second}\pm \SI{3.7}{\milli\second}$,
         and output is updated after maximum $\SI{5.0}{\milli\second}$.\cite{sheet:ir_long}
 

components/spi.tex

 \subsection{SPI - Serial Peripheral Interface}
-For sending data between the base station and the copter an Ultra WideBand (UWB) radio will be used.
-This radio communicates with the microcontroller (MCU) over a Serial Peripheral Interface (SPI) bus which will need four GPIO pins set in alternate function mode for SPI.
-
-\begin{itemize}
-    \item SPICSn: SPI Chip Select
-    \item SPIMISO: SPI Master in Slave out (data output)
-    \item SPIMOSI: SPI Master out Slave in (data input)
-    \item SPICLK: SPI clock
-\end{itemize}
-A flowchart giving a brief description of a transmission is illustrated in Figure \ref{pic:spi-flow}.
-%
-\begin{figure}[H]
-    \centering
-    \includegraphics[width=0.5\textwidth]{flowcharts/UWB}
-    \caption{UWB flowchart}
-    \label{pic:spi-flow}
-\end{figure}
-%
+\label{sec:components-SPI}
+The UWB (see Section~\ref{sec:components-UWB}) uses SPI to communicate with the microcontroller unit (MCU).
+Units communicating are arranged as one \emph{master} and several \emph{slaves}.
+In this project, only the UWB requires SPI, which simplifies the protocol.
+Thus, the MCU is set up as master with the radio as slave.
+The SPI should be configured in full duplex mode, allowing for one MOSI (Master Out Slave In) and one MISO (Master Out Slave In) channel.
+This SPI configuration requires four GPIO pins with SPI functionality.

components/uwb.tex

-
 \subsection{UWB Radio - Ultra WideBand Radio} 
+\label{sec:components-UWB}
     The UWB radio chosen for communication between the base station and the copter is a \href{http://www.decawave.com/products/dwm1000-module}{DW1000} module, as seen in Figure~\ref{pic:dw1000}.
     It can transmit data at speeds between $\SI{110}{kbps}$ and $\SI{6.8}{Mbps}$ over Line of Sight (LOS) at ranges up to $\SI{300}{\meter}$.
+    To communicate with the MCU, it uses SPI as outlined in Section~\ref{sec:components-SPI}.
     It uses approximately \SI{1}{\micro\ampere} while in sleep mode, rising to \SI{70}{\milli\ampere} and \SI{30}{\milli\ampere} while transmitting and receiving, respectively.
     Transmit and receive times are typically short, due to high data rates and small amounts of data.
     Additionally, the module has built-in support for ranging, for use when compiling measurment data.
+    A flowchart giving a brief description of a transmission is illustrated in Figure \ref{pic:spi-flow}.
 
     The module was chosen for its effective range, data rate and ranging features, as well as the inherent noise-resistance of UWB radio.
-    To facilitate use, the DW1000 module has several GPIO pins and support for external interrupt pin configuration.
     %Transmissions are made by writing data to a buffer, configuring the transmit parameters and finally writing to a register telling the \href{http://www.decawave.com/products/dwm1000-module}{DW1000} to start transmitting.
     
     \begin{figure}[H]
         \centering
-        \includegraphics[width=0.5\textwidth]{Pictures/DW1000}
+        \includegraphics[width=0.35\textwidth]{Pictures/DW1000}
         \caption{The DW1000 module}
         \label{pic:dw1000}
     \end{figure}
+
+    \begin{figure}[H]
+        \centering
+        \includegraphics[width=0.5\textwidth]{flowcharts/UWB}
+        \caption{UWB flowchart}
+        \label{pic:spi-flow}
+    \end{figure}
\ No newline at end of file

implementation/collision-avoidance.tex

 \subsection{Collision avoidance}
+\subsectionauthor{Author: Lars Jonsson \\Reviewer: Max Unander}
 
-		   %Behov av städning efter flytt
 To be able to fly the copter up and down these shafts without colliding, we have put six ultrasonic sensors on the copter in each direction, see figure \ref{label}.
 In this case there will be three pair of sensors, where each pair represent one axis in the Cartesian coordinate system.
 With help of the measurement from each sensor, a controller for collision avoidance will be implemented.
@@ -9,8 +9,6 @@
 To get this to work we will have to map the copters movement in the Cartesian coordinate system to roll, pitch and throttle commands that will be sent to the flight controller.
 This will work in the way that the output from the PIDs in each direction will be represented by either a pitch, roll or throttle command to the flight controller.
 
-	   % This will work in the way that the output from the PID in the y-direction will be a pitch command and the output from the PID in the x-direction will be a roll command, and of course the output from the PID in the z-direction will be a throttle command, see picture \ref{system bild}.
-	    
 \subsubsection{PID - controller}
 The PID controller will have the difference value between the measurement of the two ultrasonic sensors as control variable, and it's task is to converge this difference into 0. 
 When the difference value goes to 0 it means that the copter is right in the middle between two objects.
@@ -18,7 +16,49 @@
 The input to the flight controller is a linear function where for the roll and pitch command where 1000 represents by a setpoint of $-10^\circ$ and 2000 will induce a setpoint of $+10^\circ$.
 This function is linear so 1500 represent no inclination.
 For the throttle command 1000 will be no throttle at all and 2000 will set full throttle to the motors. 
-		The yaw command do differ a bit, it will not set a specific setpoint, it will instead set an angular velocity to the copter.
+The yaw command do differ a bit, it will not set a specific set-point, it will instead set an angular velocity to the copter.
 This so that the copter can spin freely around it's own axis.
+With this setup we wont have any controller to keep the heading of the copter, which should be implemented in the future.
+
+The first controller we started out with was the hovering controller.
+We wanted to set an height that we wanted the copter to hold, this height was measured with a Sonar placed under the copter.
+As we were implementing the flight controller we saw that the flight controller already had an built-in PID that used one Sonar to hover.
+We tested this out, tuned the values a bit so it would fit our large copter, and saw that it worked pretty well, and therefore we didn't program our own hovering function.
+One drawback with this function was you couldn't set an height that you wanted the copter to hold, instead it will hold the hegiht the copter have when you turn on the hovering.
+
+When we had the hovering function working quite good, we started out with trying to get the copter flying stable between two walls.
+To do this we used the SonarDifference algorithm mentioned above.
+We started out with just the P variable and saw that it "bounced" a lot between the walls.
+We concluded that we needed the D parameter as well to reduce the bouncing.
+When we saw that this worked we started to fine tune the variables.
+This was done by logging data while flying, and afterwards we could check the graphs and from those do some conclusions on how we should change the variables.
+The graphs from the final tuning of the \texttt{PID\_Roll} is shown in Fiugre~\ref{fig:PIDtuning1}.
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.7\textwidth]{Pictures/PIDtuning1}
+	\caption{This shows how the intended communication between the radio-transmitter, MCU and flight controller was going to be implemented.}
+	\label{fig:PIDtuning1}
+\end{figure}
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.7\textwidth]{Pictures/PIDtuning3}
+	\caption{This shows how the intended communication between the radio-transmitter, MCU and flight controller was going to be implemented.}
+	\label{fig:PIDtuning3}
+\end{figure}
 
 
+\begin{table}[h]
+	\centering
+	\caption{Table showing the how the switches of the RC controller are mapped, and which function each channel represents.}
+	\label{tab:controller_channels}
+	\begin{tabular}{|c|c|c|c|c|}
+		\hline
+		\textbf{SWITCH:} & \textbf{SWA (3-way)} & \textbf{SWB (2-way)} & \textbf{SWC (2-way)} & \textbf{SWH (2-way)} \\ \hline
+		\textbf{Channels:} & AUX2 & AUX3 & AUX1 & AUX4 \\ \hline
+		\textbf{\begin{tabular}[c]{@{}c@{}}HIGH:\\ (2000)\end{tabular}} & \begin{tabular}[c]{@{}c@{}}HOVER/LANDNING \\ (OFF)\end{tabular} & \begin{tabular}[c]{@{}c@{}}PID\_PITCH \\ (OFF)\end{tabular} & \begin{tabular}[c]{@{}c@{}}MOTOR \\ DISARM\end{tabular} & \begin{tabular}[c]{@{}c@{}}PID\_ROLL \\ (OFF)\end{tabular} \\ \hline
+		\textbf{\begin{tabular}[c]{@{}c@{}}MIDDLE:\\ (1500)\end{tabular}} & \begin{tabular}[c]{@{}c@{}}HOVER \\ (ON)\end{tabular} & - - - - - - & - - - - - - & - - - - - - \\ \hline
+		\textbf{\begin{tabular}[c]{@{}c@{}}LOW:\\ (1000)\end{tabular}} & \begin{tabular}[c]{@{}c@{}}LANDING \\ (ON)\end{tabular} & \begin{tabular}[c]{@{}c@{}}PID\_PITCH \\ (ON)\end{tabular} & \begin{tabular}[c]{@{}c@{}}MOTOR \\ ARM\end{tabular} & \begin{tabular}[c]{@{}c@{}}PID\_ROLL \\ (ON)\end{tabular} \\ \hline
+	\end{tabular}
+\end{table}
\ No newline at end of file

implementation/ethernet-lidar.tex

@@ -54,6 +54,7 @@ protocols and setup required for functional ethernet communication are non-trivi
 
 \subsection{LIDAR}
 \label{sec:lidar}
+\subsectionauthor{Author: Henrik Tjäder}
 
 The \href{http://www.robotshop.com/en/hokuyo-ust-10lx-scanning-laser-rangefinder.html}{Hokuyo UST-10LX Laser range finder}
 communicates over TCP/IP.
@@ -108,4 +109,5 @@ This will be great for controlling the amount of data sent over the UWB radio li
 The standard setting sends $2 \cdot 1474 + 543 = 3491$ bytes of data (including headers). The \texttt{UWB} maximum \texttt{MTU} is \texttt{127 bytes}.
 Thus the UWB would have to transmit at least 28 frames just for the LIDAR. Then there is the metadata such as the stepper motor angle, the sonar data etc.
 
+This is where the \texttt{LAMP} protocol comes into play.
 

implementation/flight-controller.tex → implementation/flightcontroller_imp.tex

 \subsection{Flight Controller}
-% Verkar vara problem att köra "return" för nytt stycke, blir typ 10 radhopp istället för 1.
+\subsectionauthor{Author: Lars Jonsson \\Reviewer: Max Unander}
+
 To be able to start up the flight controller for the first time you will need to flash the flight controller with some sort of software.
 There are many flight controller softwares on the market, a couple of them are open source.
 After some reading around on the web we decided to flash a software called \href{http://cleanflight.com/}{Cleanflight} to the flight controller.
-We chose Cleanflight because of it has a well documented source code, gets regularly firmware updates and has a broad hardware support.
+We chose Cleanflight because it has a well documented source code, gets regularly firmware updates and has a broad hardware support.
 The main GUI looks nice and is easy to start out with, it's straight forward how to change parameter values, and how to setup the board before your first flight.
-The firmware that we flashed our flight controller with is the cleanflight\_SPRACINGF3.hex v$1.13.0$. 
-Which was the newest stable version of Cleanflight at the time.\\\\
+The firmware that we flashed our flight controller with is the \href{https://github.com/cleanflight/cleanflight/releases}{cleanflight\_SPRACINGF3.hex v$1.13.0$}. 
+Which was the newest stable version of Cleanflight at the start of this project.
+
 Normally a quad copter or any other RC vehicle is controlled by a radio transmitter.
 For a quad copter the radio transmitter must have at least 4 channels.
 The four channels that is necessary to have is the three rotation axis yaw, pitch and roll plus the absolute throttle to all the motors.
 In this project we are going to use another approach to control the copter. 
-Instead of having full control of the copter using the radio transmitter you will only be able to maneuver the copter with high level commands.\\\\	
-To be able to do this we need to interact with the flight controller from our MCU.
-The flight controller has support for four different communication protocols.
+Instead of having full control of the copter using the radio transmitter, you will only have to ability to send high level commands.
+To be able to do this we need to interact with the flight controller from our MCU somehow.
+
+The flight controller do have support for four different communication protocols.
 It can take PWM inputs, where one PWM controls one channel.
 It have PPM support, which is quite the same as a PWM but it has support for 8 PWM signals on one line.
 It do support sBUS, which is some sort of secure serial protocol with inverted signals.
-The last protocol it supports is called MSP (MultiWii Serial Protocol), which also is a serial protocol.\\\\     
+The last protocol it supports is called MSP (MultiWii Serial Protocol), which also is a serial protocol.
 Our first thought was that we wanted to implement both the MSP and PPM protocols to control the copter.
 We wanted PPM to be able to maneuver the copter with the RC transmitter, and MSP to control the copter with our MCU.
 We also hoped that we will be able to have a 2-way communication with the flight controller using MSP.
-This so we could be able to not only send commands to the flight controller, but also retrieve information from the flight controller as well, which can be seenn in Figure~\ref{fig:fc_communication_1}.
+This so we could be able to not only send commands to the flight controller, but also retrieve information from the flight controller as well, this protocol can be seen in Figure~\ref{fig:fc_communication_1}.
 
 \begin{figure}[H]
 	\centering
@@ -33,7 +36,7 @@ This so we could be able to not only send commands to the flight controller, but
 The hard part with this approach was how to be able to switch between these two protocols mid air.
 We did have some thought how we could do this, but we did not manage to get this working without rewriting some code in the flight controller.
 As this could be a hassle, we thought out another way to solve this.
-The easiest way was to decode the PPM signal from the transmitter into the MCU, and do the conversion between raw transmitter data and controlled data in the MCU and send all data through MSP.
+The easiest way was to decode the PPM signal from the transmitter into the MCU, and do the conversion between raw transmitter data and controlled data in the MCU and send all data through MSP instead.
 With this approach the communication will look like the one in Figure~\ref{fig:fc_communication_2}.
 
 \begin{figure}[H]
@@ -45,6 +48,33 @@ With this approach the communication will look like the one in Figure~\ref{fig:f
 
 The disadvantage with this approach is that if anything goes wrong with the MCU, we won't have the ability to control the copter at all.
 But there are also some advantages with this approach.
-We now have the ability to map the control stick in any way we want it and we can use all the available channels on the RC transmitter to start certain functions on the MCU.\\\\
-The things that we had to setup in Cleanflight to be able to fly
+We now have the freedom to map the control stick in any way we want it and we can use all the available channels on the RC transmitter to start certain functions on the MCU, which will be shown later on.
+
+In Cleanflight you have the ability to choose between three different flight modes.
+The three modes are Rate mode (default), Horizon mode and Angle mode.
+The default flight mode does not stabilize the copter around the roll and pitch axes.
+Which means that the copter wont stabilize on its own if you center roll and pitch control sticks on the transmitter.
+Instead the copter will respond with an angular velocity around these axes related to the stick.
+In Angle mode the roll and pitch channels control the angle between the relevant axis and the vertical, achieving leveled flight just by leaving the sticks centered.
+Horizon mode is some hybrid between the auto-level Angle mode, and the manual Rate mode, so for our application it´s best to go with Angle mode.
+
+In Cleanflight you will also need to choose between three different PID controllers, MultiWii, MultiWii (2.3) and LuxFloat.
+We started out with MultiWii, and did get the copter to fly, but it didn´t fly as good as we had hoped.
+After weeks of tweeking with this PID, we saw that in newer versions of Cleanflight only LuxFloat will be available.
+When changing to this PID controller instead and with some minor changes, the flight performance was improved drastically.
+
+There are some things that was needed to be setup in Cleanflight to be able to fly the copter for the first time.
+\begin{itemize}
+	\item First we did set the flight orientation of the copter, at default it is set to "X-config", but we wanted the "+-config" becuase of the placement of the sonars.
+	\item Second thing was to set the orientation of the flight controller, so the copter wont respond in the wrong direction.
+	\item When all the orientations was set right, we did calibrate the accelerometer.
+	\item Next thing to do was to setup the MSP communication port. Which we programmed to UART3 running at 115200 baudrate.
+	\item After that we did setup command bindings on certain channels, like arming the copter and choosing flight mode.
+	\item Last thing to do is to choose an PID controllers and assigning values for the P, I and D.
+\end{itemize}
+
+All our configurations that was set in Cleanflight can be shown in the Appendix \ref{label}.
+TODO: Ta config från cleanflight lägga in i en appendix.
+
+