diff --git a/Pictures/PIDtuning1.png b/Pictures/PIDtuning1.png
new file mode 100644
index 0000000000000000000000000000000000000000..aeb756a7a6ce65d3833a040926813fd9dfc76908
Binary files /dev/null and b/Pictures/PIDtuning1.png differ
diff --git a/Pictures/PIDtuning2.png b/Pictures/PIDtuning2.png
new file mode 100644
index 0000000000000000000000000000000000000000..bef83c5732a7459c83702e561dfdeb17a86519ab
Binary files /dev/null and b/Pictures/PIDtuning2.png differ
diff --git a/Pictures/PIDtuning3.png b/Pictures/PIDtuning3.png
new file mode 100644
index 0000000000000000000000000000000000000000..d3fab6b5548c7a79b45aaec2c04e188b07777884
Binary files /dev/null and b/Pictures/PIDtuning3.png differ
diff --git a/Pictures/rctrasmitter_sw.jpg b/Pictures/rctrasmitter_sw.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..7e566ddfe14c57fa1e5480c0776df0d891c0755a
Binary files /dev/null and b/Pictures/rctrasmitter_sw.jpg differ
diff --git a/Pictures/reciever.png b/Pictures/reciever.png
new file mode 100644
index 0000000000000000000000000000000000000000..5c3c5a929c78a3b284039252a1b5b8643d5079de
Binary files /dev/null and b/Pictures/reciever.png differ
diff --git a/Pictures/transmitter.png b/Pictures/transmitter.png
new file mode 100644
index 0000000000000000000000000000000000000000..6283e927abecb2e0e2ae10e950e48fa3ce6bb398
Binary files /dev/null and b/Pictures/transmitter.png differ
diff --git a/chapters/introduction.tex b/chapters/introduction.tex
index 21bdf0b392bdcdf4c6382031e9d57d0e91c985ef..4876c496809eb9dbcfeb9893a0d90c44401fe3af 100644
--- a/chapters/introduction.tex
+++ b/chapters/introduction.tex
@@ -1,4 +1,5 @@
%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
diff --git a/chapters/result.tex b/chapters/result.tex
new file mode 100644
index 0000000000000000000000000000000000000000..eb4ef91b7dba31139d6cb97b56c6f43362637843
--- /dev/null
+++ b/chapters/result.tex
@@ -0,0 +1,75 @@
+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}
+
diff --git a/chapters/systemDesign.tex b/chapters/systemDesign.tex
index c7e054314cd98bd252aba076b53d28ca9885a015..454457930cf5a8e3f996e6993b9220d9cd6395dc 100644
--- a/chapters/systemDesign.tex
+++ b/chapters/systemDesign.tex
@@ -1,19 +1,21 @@
- \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.
- \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}
- \end{figure}
+ \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
+ \caption{System module diagram}
+ \includegraphics[width=\textwidth]{Pictures/componentchart_2}
+ \end{figure}
- \subsection{Dynamic Design}
- \subsubsection{Activity Diagram}
- \subsubsection{Sequence Diagram}
- \subsubsection{State Diagram}
\ No newline at end of file
+ \subsection{Dynamic Design}
+ \subsubsection{Activity Diagram}
+ \subsubsection{Sequence Diagram}
+ \subsubsection{State Diagram}
\ No newline at end of file
diff --git a/components/casesandmounts.tex b/components/casesandmounts.tex
new file mode 100644
index 0000000000000000000000000000000000000000..ed991d42eb2ef315514b67578a1d0202315a1766
--- /dev/null
+++ b/components/casesandmounts.tex
@@ -0,0 +1,31 @@
+\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
diff --git a/components/circuitboards.tex b/components/circuitboards.tex
new file mode 100644
index 0000000000000000000000000000000000000000..6fc8e09fe527ee8ae5b63f51e23ed9810e5f5bde
--- /dev/null
+++ b/components/circuitboards.tex
@@ -0,0 +1,30 @@
+\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
diff --git a/components/connectionsandwiring.tex b/components/connectionsandwiring.tex
new file mode 100644
index 0000000000000000000000000000000000000000..50a39cd5023d282cba72958d96d56f576512d72f
--- /dev/null
+++ b/components/connectionsandwiring.tex
@@ -0,0 +1,16 @@
+\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}
diff --git a/components/copterparts.tex b/components/copterparts.tex
index 2e2d5ad7f4d604b8061888d1f77ba0f41599206f..7e230767a0e44267510846e28ea4f524d473279d 100644
--- a/components/copterparts.tex
+++ b/components/copterparts.tex
@@ -1,115 +1,29 @@
\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.
- 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.
- We wanted to at least five minutes of flight time so we chose a Zippy 8000mAh 30C battery which would give us around six minutes of flight at full throttle (eq.\ref{flighttime}) and more than enough current delivery.
-
- \begin{equation}
- 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}
-
- \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}
+\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.
+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.
+We wanted to at least five minutes of flight time so we chose a Zippy 8000mAh 30C battery which would give us around six minutes of flight at full throttle (eq.\ref{flighttime}) and more than enough current delivery.
+
+\begin{equation}
+ 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
diff --git a/components/flightcontroller.tex b/components/flightcontroller.tex
index 31456fa570866f603b19be7b7a8bfd6060e5988d..5017d6444299abfc0423d94012f94f25f7791673 100644
--- a/components/flightcontroller.tex
+++ b/components/flightcontroller.tex
@@ -1,37 +1,30 @@
- \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.
-
-
- 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.
- The angular velocity is measured around the three axis x,y,z and in flight dynamics often called roll, pitch and yaw, see figure \ref{fig:roll_pitch_yaw}.
- In most flight controller software the controlling part is implemented as three individual PID controllers, where each PID controls one angle, e.g yaw, pitch and roll.
- By controlling the throttle of each motor, the flight controller will give you a steady flight.
-
- \begin{figure}[H]
- \centering
- \includegraphics[width=0.3\textwidth]{Pictures/roll_pitch_yaw}
- \caption{Quadcopter orientation principle.}
- \label{fig:roll_pitch_yaw}
- \end{figure}
-
- Because the size of this project and the time that we had, we chose to use an commercially available flight controller instead of designing and programming our own.
- The flight controller that we will use is a FLIP32 F3 AIO-Lite, shown in Figure~\ref{fig:flightcontroller}.
-
- \begin{figure}[H]
- \centering
- \includegraphics[width=0.25\textwidth]{Pictures/flip32.jpg}
- \caption{FLIP32 F3 AIO-Lite.}
- \label{fig:flightcontroller}
- \end{figure}
-
- We took this flight controller because it have support for several different communication protocols like, PWM, PPM and sBUS.
- 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
+\subsection{Flight Controller}
+\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.
+The angular velocity is measured around the three axis x,y,z and in flight dynamics often called roll, pitch and yaw, see figure \ref{fig:roll_pitch_yaw}.
+In most flight controller software the controlling part is implemented as three individual PID controllers, where each PID controls one angle, e.g yaw, pitch and roll.
+By controlling the throttle of each motor, the flight controller will give you a steady flight.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.3\textwidth]{Pictures/roll_pitch_yaw}
+ \caption{Quadcopter orientation principle.}
+ \label{fig:roll_pitch_yaw}
+\end{figure}
+
+Because the size of this project and the time that we had, we chose to use an commercially available flight controller instead of designing and programming our own.
+The flight controller that we will use is a FLIP32 F3 AIO-Lite, shown in Figure~\ref{fig:flightcontroller}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.25\textwidth]{Pictures/flip32.jpg}
+ \caption{FLIP32 F3 AIO-Lite.}
+ \label{fig:flightcontroller}
+\end{figure}
+
+We took this flight controller because it have support for several different communication protocols like, PWM, PPM and sBUS.
+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
diff --git a/components/ir.tex b/components/ir.tex
index f5f4a9a4a208287388fd4ee29d4eec6a342b2b64..622d11cbc9f176f5c64d141a07903621c5752b81 100644
--- a/components/ir.tex
+++ b/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}
diff --git a/components/spi.tex b/components/spi.tex
index acb54a7dbc1de988c7096c707c82e22384f3d8d0..98f6a4bbb61b0cc931ee9dc713d55e5c2cdbcebb 100644
--- a/components/spi.tex
+++ b/components/spi.tex
@@ -1,19 +1,8 @@
\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.
diff --git a/components/uwb.tex b/components/uwb.tex
index 13667a916b6f1ab48301100a6f0764a8f186d6fb..26cfe9dcc3b3fe72c080abd2f78579c8f5ec0c58 100644
--- a/components/uwb.tex
+++ b/components/uwb.tex
@@ -1,18 +1,26 @@
-
-\subsection{UWB Radio - Ultra WideBand Radio}
+\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
diff --git a/implementation/collision-avoidance.tex b/implementation/collision-avoidance.tex
index 3329e40d009efc184d6d0ab1c71184404b931f2c..a35a2aa2ad1dffc9215217defeba0a0308b17c09 100644
--- a/implementation/collision-avoidance.tex
+++ b/implementation/collision-avoidance.tex
@@ -1,24 +1,64 @@
\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.
- The collision avoidance will consist of three individual PID-controllers, where each one will control the position on each axis.
-
- 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.
- The output of the PID will be a number between 1000 and 2000, because that is the input the flight controller can receive.
- 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.
- This so that the copter can spin freely around it's own axis.
-
-
\ No newline at end of file
+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.
+The collision avoidance will consist of three individual PID-controllers, where each one will control the position on each axis.
+
+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.
+
+\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.
+The output of the PID will be a number between 1000 and 2000, because that is the input the flight controller can receive.
+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 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
diff --git a/implementation/ethernet-lidar.tex b/implementation/ethernet-lidar.tex
index c1f33ab3cccc2bc82f68b87e8b69964a5aa1bf38..0e36c7b32a5a94cd86a0c4c0ca51d74b487a22e9 100644
--- a/implementation/ethernet-lidar.tex
+++ b/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.
diff --git a/implementation/flight-controller.tex b/implementation/flight-controller.tex
deleted file mode 100644
index 65589fa9b31dad3e2bfde9dbafeebdb0cf49036b..0000000000000000000000000000000000000000
--- a/implementation/flight-controller.tex
+++ /dev/null
@@ -1,50 +0,0 @@
-\subsection{Flight Controller}
-% Verkar vara problem att köra "return" för nytt stycke, blir typ 10 radhopp istället för 1.
-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.
-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.\\\\
-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.
-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.\\\\
-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}.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=0.6\textwidth]{Pictures/fc_communication_1}
- \caption{This shows how the intended communication between the radio-transmitter, MCU and flight controller was going to be implemented.}
- \label{fig:fc_communication_1}
-\end{figure}
-
-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.
-With this approach the communication will look like the one in Figure~\ref{fig:fc_communication_2}.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=0.6\textwidth]{Pictures/fc_communication_2}
- \caption{This shows how the communication between the radio-transmitter, MCU and flight controller works.}
- \label{fig:fc_communication_2}
-\end{figure}
-
-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
-
diff --git a/implementation/flightcontroller_imp.tex b/implementation/flightcontroller_imp.tex
new file mode 100644
index 0000000000000000000000000000000000000000..ed5dd4b889f66b2152e9f910bdd1c31472992e7c
--- /dev/null
+++ b/implementation/flightcontroller_imp.tex
@@ -0,0 +1,80 @@
+\subsection{Flight Controller}
+\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 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 \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 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.
+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, this protocol can be seen in Figure~\ref{fig:fc_communication_1}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.6\textwidth]{Pictures/fc_communication_1}
+ \caption{This shows how the intended communication between the radio-transmitter, MCU and flight controller was going to be implemented.}
+ \label{fig:fc_communication_1}
+\end{figure}
+
+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 instead.
+With this approach the communication will look like the one in Figure~\ref{fig:fc_communication_2}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.6\textwidth]{Pictures/fc_communication_2}
+ \caption{This shows how the communication between the radio-transmitter, MCU and flight controller works.}
+ \label{fig:fc_communication_2}
+\end{figure}
+
+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 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.
+
+
+
diff --git a/implementation/spi-uwb.tex b/implementation/spi-uwb.tex
index 64ddb49c6c477e388cd5c3035a659b2e696bddbb..cdda2bd3e497a2fedbd64566d535312fea486b51 100644
--- a/implementation/spi-uwb.tex
+++ b/implementation/spi-uwb.tex
@@ -1,25 +1,22 @@
-\subsection{UWB radio development}
+\subsection{SPI \& UWB radio}
+\subsectionauthor{Author: Fredrik Grönlund \& Emil Lundell\\Reviewer: TODO???}
\subsubsection{General description}
- %TODO: Add UWB Radio description to peripherals/components.
+ Communication over SPI is done in multiples of bytes.
+ All communication is initiated by the master sending a command block of 1-3 bytes, depending on the type of command, followed by data from either the master or the slave.
+ This could be as much as 1024 bytes, excluding the command block.
+ Both lines are always transmitting, although one line is always ignored at any one time, either by the slave or master.
+ The slave ignores the master when returning data, and the master ignores the slave when issuing commands or writing data.
+
A total of two UWB radios were required, one on the copter and one on the base station.
They are configured to run at a $\SI{6.8}{Mbps}$ with a PRF of $\SI{16}{MHz}$ by default.
- These values were adjusted as needed. %\footnote{TODO: Final Values?}
- The data rate in particular may be decreased in favour of range and reliability, pending future tests.
- The UWB uses SPI to exchange data with the microprocessor, with the microprocessor acting as master and the radio as slave.
+ These values were adjusted as needed.
+ Data rate, in particular, may be decreased in favour of range and reliability, should it be required.
Due to the construction of the SPI protocol, the radio, being the slave, cannot request to be read through SPI alone.
Only the master may request a write or read.
- Thus, the radio instead sets one of its own pins, which is in turn connected to a general GPIO to generate an interrupt whenever it has finished receiving a transmission.
- This allows an interrupt to be generated that handles the input and passes it along as needed.
- \subsubsection{SPI}
- The SPI is configured in full duplex mode, allowing for one MOSI (Master Out Slave In) and one MISO (Master Out Slave In) channel.
- Since there is only one master/slave, only one Slave Select (NSS) was used.
- The UWB radio only ever sends or receives octets (8 bits) over SPI.
- All communication is initiated by the master sending a command block of 1-3 octets, depending on the type of command, followed by data from either the master or the slave.
- Both lines are always transmitting, although one line is always ignored at any one time, either by the slave or master.
- The slave ignores the master when returning data, and the master ignores the slave when issuing commands or writing data.
- This is implemented using the HAL\footnote{Hardware Abstraction Layer} libraries supplied by STMicroelectronics.
+ The DW1000 is instead configured to set its IRQ pin high which triggers an interrupt in the MCU.
+
- In this project, the UWB radio will be used in four different ways.
+ The UWB radio will be used in four different ways:
\begin{itemize}
\item A read is requested by the master.
The request specifies the register to read from.
@@ -36,6 +33,7 @@
This should generate an interrupt, prompting the microcontroller to initialize a read of the received data.
\end{itemize}
A flowchart describing this can be seen in Figure~\ref{pic:UWB_op}.
+ This also extends to ranging.
\begin{figure}[H]
\centering
@@ -44,28 +42,44 @@
\label{pic:UWB_op}
\end{figure}
- \subsubsection{SPI Development}
- Development of the SPI was given to Emil Lundell.
- Fredrik Grönlund joined him two weeks later, as ADC development was put on hold and SPI was going slower than expected.
- The decision was taken early to attempt to implement the simplest possible SPI to save time.
- This decision was twofold.
- Firstly, a working SPI was desired as soon as possible for testing, where speed was unimportant.
- The idea was that the SPI could always present a working API, with improvements being made ``behind the scenes'', invisible to other modules.
- Secondly, the data to be sent and received from the LIDAR and IMU was deemed small in comparison to the speed of the SPI and UWB.
- Thus, improvements in speed was deemed useful but not critical.
+ \subsubsection{SPI Implementation}
+ %Secondly, the data to be sent and received from the LIDAR and IMU was deemed small in comparison to the speed of the SPI and UWB.
+ %Thus, improvements in speed was deemed useful but not critical.
+ SPI is defined as follows:
+ \begin{itemize}
+ \item SPI instance used is SPI2
+ \item SPI is full duplex (both MOSI and MISO)
+ \item Data size is 8 bits
+ \item Clock polarity is low.
+ \item Clock Phase is first edge
+ \item Slave Select is software-managed
+ \item Clock prescaler is 64 in setup, 8 while running
+ \end{itemize}
- Automatic configuration of clocks was generated using STM32 CubeMX, and then some of the code was extracted.
- Some manual adjustment was initially required to make it run, as well as adjustments to the environment to make sure the debugger and build script worked correctly.
+ The SPI protocol relies on four pins:
+ \begin{itemize}
+ \item SPICSn: SPI Chip Select (also referred to as ``NSS: Slave Select'')
+ \item SPIMISO: SPI Master In Slave Out (data output from MCU to UWB)
+ \item SPIMOSI: SPI Master Out Slave In (data input from UWB to MCU)
+ \item SPICLK: SPI clock
+ \end{itemize}
- The entire team was unfamiliar with the HAL library for the STM32F7 series processor.
- Both Emil and Fredrik had experience working with an earlier STM microprocessor, of the STM32F4 series, but it used an earlier library, which was much closer to hardware.
- This led to some time devoted to learning the new libraries and researching how to implement what was desired.
+ Several SPI peripherals are available in the project MCU.
+ However, SPI2 is used to avoid collisions with other peripherals.
+ The SPI functions are bound to the following pins:
+ \begin{itemize}
+ \item \makebox[2cm][l]{SPICS:} \makebox[2cm][l]{PB12}
+ \item \makebox[2cm][l]{SPIMISO:} \makebox[2cm][l]{PC2}
+ \item \makebox[2cm][l]{SPIMOSI:} \makebox[2cm][l]{PC3}
+ \item \makebox[2cm][l]{SPICLK:} \makebox[2cm][l]{PB10}
+ \end{itemize}
- Further issues were soon encountered that stalled development.
- Since the time from NSS set low and clock start should be as short as possible for optimum performance, it was configured to be handled by hardware.
- Thus, whenever SPI is enabled and sending, hardware handles setting the NSS high or low.
- Whenever the NSS pulse (NSSP) option was enabled, this worked as intended, although NSSP caused a pulse between each transmission octet, this is shown in
- Figure \ref{pic:NSSP}.
+ Handling NSS (Slave select) in hardware would be faster and easier.
+ An undocumented hardware bug in the STMF7-series processor causes the hardware-managed NSS to malfunction if NSS Pulse was disabled. \cite{web:stm_nss_problem}
+ An example of NSS Pulse mode can be seen in Figure \ref{pic:NSSP}.
+ The DW1000 does not support NSS Pulse communication, so software NSS was required.
+ The NSS pin is instead handled like a standard digital GPIO pin.
+ All other SPI is implemented using the HAL\footnote{Hardware Abstraction Layer} libraries supplied by STMicroelectronics for this processor.
\begin{figure}[H]
\centering
@@ -74,42 +88,18 @@
\label{pic:NSSP}
\end{figure}
- Unfortunately, the UWB does not support pulse mode, so NSSP was disabled.
- This caused NSS to be initially high, set low as intended before the first SPI transmission, and remain low.
-
- A week was spent trying to troubleshoot this issue, as the developers believed they had missed some setting.
- However, it was eventually found through searching the Internet for answers that this was a hardware bug in the peripheral itself.
- It seems to have been a recurring bug in certain STM chips, notably the F0 and F3.
- There was no mention of this bug in the official errata for the chip, but threads were found on the official STMicroelectronics forums noting the problems.\cite{web:stm_nss_problem}
- Since no reliable way of making this feature work was found, the decision was made to switch from a hardware-managed NSS to a software-managed NSS.
- The pin connected to NSS was instead specified as a generic GPIO output pin and is set and reset in software.
- Software NSS is less effective and somewhat more roundabout to implement in code, although it seems like there is no alternative at the time.
- A predefined read/write function was replicated from the HAL and simplified for this project in order to speed things up.
-
-
- In a meeting with Johan, the project manager from Conex, the question of data rates was raised.
- It was believed that the simple implementation that was being worked on would have an insufficient data rate, and the decision was taken to scrap the current SPI implementation
- and instead use a DMA-based\footnote{Direct Memory Access} SPI.
- This required rewriting much of the actual functions as well as the software NSS management (as hardware NSS was still non-functional).
- This rewriting went smoother than the original part, likely due to better familiarity with the system in general.
+ In asynchronous mode, it utilizes interrupts to allow other code to execute.
+ In synchronous mode, it blocks other code execution.
- \subsubsection{UWB}
- With the SPI fully functional it was now possible to start configuring and developing the UWB.
- As the radio was perceived to be well-documented and somewhat simple to use, the decision was made to manually write the configuration and use the SPI as is.
-
- %The desired settings to be used will not be the default settings since the defaults might not work
- %well enough at longer distances. Therefore the UWB should be configured with the following settings
- %in the transmission frame control register (TX\_FCTRL):
-
- The settings that will be used in the to begin with are slower than the default
- but should make it possible to send messages over a greater distance. Another difference from the
- default settings is that a variable size of frame length will be used depending on which type of
- message is sent. The final settings to be used may vary but to begin with the transmission frame
- control register (\texttt{TX\_FCTRL}) will be set as follows:
-
- % This is what the lib sets/uses.
- % TODO: ?? change ??
+ \subsubsection{UWB Specifications}
+ Communication and operation of the DW1000 UWB module is entirely done through the DW1000 library.
+ This was supplied by Kim Albertsson as a semi-generic library, released as Open Source \cite{code:DW1000_library}.
+ The library uses two processor-specific files for interfacing against the SPI peripheral.
+ The file \texttt{dw1000-spi.c} provides the functions the DW1000 library uses to interface with the SPI.
+ The file \texttt{dw1000-hal.c}\footnote{Arguably misnamed, according to Kim.} provides interrupt functionality.
+ Sebastian Larsson, a programmer at Conex, assisted with getting the library to work.
+ The UWB is configured as follows:
\begin{itemize}
\item \makebox[5cm][l]{Transmit frame length} \makebox[3cm][l]{\texttt{(TFLEN)}} = Variable with messages
\item \makebox[5cm][l]{Transmit bit rate} \makebox[3cm][l]{\texttt{(TXBR)}} = $\SI{850}{kbps}$
@@ -117,51 +107,26 @@
\item \makebox[5cm][l]{Repetition frequency} \makebox[3cm][l]{\texttt{(TXPRF)}} = $\SI{16}{\mega\hertz}$
\item \makebox[5cm][l]{Transmit preamble} \makebox[3cm][l]{\texttt{(TXPSR+PE)}} = $\SI{128}{symbols}$
\end{itemize}
+ Note that these differ from the default settings in the DW1000 User Manual\cite{sheet:DW1000_User_Manual}.
+ This is because the default settings are either extremely suboptimal or non-funtional.
Transmission is done through writing desired data to a transmit buffer internal to the DW1000.
The transmission itself is initiated with current settings when the status bit \texttt{TXSTRT}, Transmission start, in the system control register is written to \texttt{1}.
- The DW1000 module has support for GPIO pins, one of which can be configured for interrupt.
- This pin is pulled high whenever an event occurs in the radio.
- The exact events to trigger this is configurable.
- On our development board shield, the interrupt pin was connected to GPIOB Pin 11 on the MCU, which was configured for interrupt on rising edge.
-
- \subsubsection{UWB Development}
- The development team discovered that the documentation for the DW1000 was difficult to understand, obtuse in places and had a maze-like web of references within itself making it difficult to navigate.
- Additionally, the order of writing and reading to its internal references was counterintuitive as were several of the system controls.
- The system defaults were in general suboptimal and in some places even inoperable, requiring manual tweaking in order to function.
- %TODO: Write something about project (and especially SPI) was behind schedule.
- %DONE ??
- After spending some time trying to tweak the default settings according to the section `` Default Configurations that should be modified '' in the User Manual \cite{sheet:DW1000_User_Manual}
- as well as settings for transmitting and receiving without getting any transmissions completed, it came to our attention that the SPI, or more precisely the UWB, development
- now was getting further behind schedule.
- Since development was slow and tedious with many pieces missing or not working correctly by default it was decided that in order to save time a pre-made library should be used.
-
- Several libraries exist online, although none for the STM32F7 microprocessor series.
- Plans for porting an existing Arduino library was considered but discarded due to lack of time.
- However, at LTU, Kim Albertsson had developed a semi-generic library which had been released as Open Source \cite{code:DW1000_library}.
- Some modifications were required to make it interoperable with the STM32F7 processor, as it was written for a Cortex M4 used in a previous project.
- Sebastian Larsson (TODO: ???), a programmer at Conex, assisted temporarily with getting the library to work.
-
- This library was mostly self-contained, relying only on an interface which provides the most basic functionality of sending a single byte of data to the DW1000 over SPI.
- The rest of the library then uses this functionality to do all its operations, including setup, transmission and reception.
-
- Development was slow, as beyond the porting issues the examples included in the library were very basic.
- They were also not very robust, and relied much on busy-wait loops either constantly transmitting or receiving.
- This would not work on the copter, as many other kinds of data is also required to be processed, requiring significant re-writes to be practical.
- No extra UWB radios were ordered to the project, which further slowed development.
- One was mounted on the base station board, which was only used by the SPI development team, while the other was mounted to the main copter board.
- This board was often used by other development groups, such as the flight control or sonar developers, sometimes leading to queues for use of that board.
-
+ To facilitate use, the DW1000 module has several GPIO pins and support for external interrupt pin configuration.
+ This pin can be set high as the radio finishes a receive or transmit, triggering an interrupt in the MCU.
+ This extra pin is bound as follows:
+ \begin{itemize}
+ \item \makebox[3cm][l]{UWB\_IRQ:} \makebox[2cm][l]{PB11}
+ \end{itemize}
- \subsubsection{LAMP}
- Data passed from the copter to the base station follows a simple, predictable pattern.
- Either it passes along the most recent LIDAR measurement or it transmits the current IMU data.
- In order to quantify these, a protocol was created so that a standard could be conformed to.
- This was dubbed \emph{LIDAR and Accelerometer Measurement Protocol}, or LAMP for short.
+ \subsubsection{LAMP - LIDAR and Accelerometer Measurement Protocol}
+ In order to codify sent and received data, a protocol was constructed.
+ The protocol needs to pass along data from the LIDAR, the IMU and UWB ranging data.
+ LAMP packages are currently sent using the WiFi module.
LAMP is defined as follows:
- \begin{figure}
+ \begin{figure}[H]
\begin{bytefield}[bitwidth=2.6em]{16}
\bitheader{0-15} \\
\bitbox{1}{TYP} & \bitbox{1}{SIZ} & \bitbox{1}{RSL}
@@ -171,7 +136,7 @@
\caption{LAMP protocol definition - IMU frames}
\end{figure}
- \begin{figure}
+ \begin{figure}[H]
\begin{bytefield}[bitwidth=2.6em]{16}
\bitheader{0-15} \\
\bitbox{1}{TYP} & \bitbox{1}{SIZ} & \bitbox{1}{RSL}
@@ -183,7 +148,7 @@
\caption{LAMP protocol definition - LIDAR frames}
\end{figure}
- \begin{figure}
+ \begin{figure}[H]
\begin{bytefield}[bitwidth=2.6em]{16}
\bitheader{0-15} \\
\bitbox{1}{TYP} & \bitbox{1}{SIZ} & \bitbox{1}{RSL}
@@ -222,27 +187,39 @@
\item [CHK:] Checksum of the package, calculated as an XOR of every byte of the frame.
\end{itemize}
- These options were specified from the relevant sizes and data of the various units.
+ The size of the packets must conform to the 127 byte maximum packet size of the DW1000.
+
+ Additionally, LAMP LIDAR packages were designed to not require sending partial packages of data.
+ Using the default configuration and most variations on it, LIDAR data should fit into a number of whole packages and require no partial packages.
The LIDAR has a measurement sweep of $\SI{270}{\degree}$, with four data points per degree at max.
When requesting data from it, it is possible to return only some data points, typically every other, every forth or so on.
The accuracy-to-data-size compromise was decided as $\SI{1}{\degree}$, although LAMP was set up to support changes to this on-the-fly without having to alter the protocol.
+ \emph{Example:}\\
+ The total LIDAR measurement range is an $\SI{270}{\degree}$ arc.
+ A typical package, with default TYP and $RSL = \texttt{0x04}$, a total of 270 measuring points.
+ This gives
+ \begin{align*}
+ \frac{270 \cdot \frac{1}{1}}{90 / 3} = 9\text{ packets}
+ \end{align*}
- TODO: CLEAN THIS EXAMPLE UP.
- Example:
- Total LIDAR measurement interval is $\SI{270}{\degree}$, with that default TYP and $RSL = \texttt{0x04}$ gives 9 packages per round of measurement.
- At minimum, with TYP = 0x01 and RSL = 0x08, we get 135 bytes of data which fits in two packages.
- On the other end, there's TYP = 0x03 and RSL = 0x01, giving us 1080 data points, giving us 3240 bytes of data, or 36 full packages.
+ At minimum precision and truncated data (\SI{2}{\degree} resolution and 1 byte per point), the data obtained is
+ \begin{align*}
+ \SI{270}{\degree} \cdot \frac{1}{4} = \SI{135}{bytes}
+ \end{align*}
+ which fits into two packages with \SI{90}{bytes} payload, although one will not be filled completely.
+ At maximum precision (\SI{0.25}{\degree} resolution and 3 byte per point) a total of $\frac{\SI{270}{\degree}}{0.25} = 1080$ data points, resulting in 3240 bytes of data.
+ This gives
+ \begin{align*}
+ \frac{1080}{90 / 3} = 36\text{ full packages.}
+ \end{align*}
- \subsubsection{UWB Ranging}
- In light of the slow UWB data transfer development, it was decided to focus on using the UWB for ranging as the project proceeded.
- The ranging portion of the UWB was decided to be most important, as data transfers could be handled by simpler systems.
- There were no time to acquire an alternate, easier solution for ranging, though, so focus was moved from data transfer instead.
- TODO: Define ranging better
- The ranging supported by the UWB is defined relatively simply. In the project use case, there exists one \emph{tag} and one \emph{anchor} unit,
- mounted on the copter and base station respectively. After Anchor detects a tag, it initializes ranging and calculates the distance from the timestamps of received messages.
+ \subsubsection{UWB Ranging}
+ The basic operation of ranging supported by the UWB is defined relatively simply.
+ In the project use case, there exists one \emph{tag} and one \emph{anchor} unit, mounted on the copter and base station respectively.
+ After the anchor detects a tag, it initializes ranging and calculates the distance from the timestamps of received messages.
Basic operation is as follows:
\begin{enumerate}
@@ -256,30 +233,7 @@
\end{enumerate}
Further accuracy can be achieved by calibrating for antenna delay on an individual basis.
- The ranging code was, like the rest of the library, reliant on contiki and the Mulle processor, and required some porting.
- It also appeared to be unfinished, or intended for a previous version of the library as much of it lacked expected functionality.
- Among the problems were several ways the program could end up in a deadlock state as well as timing issues.
- The development encountered several strange problems of unknown cause.
- Received packets would arrive corrupt or not at all, either causing the ranging to time out or to simply not proceed.
- As the deadline approached, the team attempted to simplify the process in hopes of getting some data.
- This was also plagued by the same problems, and was unresolved as deadline passed.
+ UWB ranging was not completed.
+ A prototype, adapted from the DW1000 library examples, can be found in the project folder.
+ It uses the files \texttt{dw-range.c} and \texttt{dw-range.h} for parsing and constructing range packets.
- The final state of the SPI and UWB is as follows:
-
- %WORKS
- \begin{itemize}
- \item SPI has been set up.
- \item SPI works in both synchronous and asynchronous mode with the DW1000 library.
- \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}
-
- %DOES NOT WORK
- \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 still lacks functionality for many functions.
- \end{itemize}
- %TODO: continue and correct.
diff --git a/latexoptions.tex b/latexoptions.tex
index f99a781b4f5c495d78d0455ec5a869856597cb08..659b08e2b4938165dd705721be10417a435d30ff 100644
--- a/latexoptions.tex
+++ b/latexoptions.tex
@@ -94,6 +94,11 @@
{}{}{0pt}{}
}
+% For the ability to change itemize-bullets
+\usepackage{enumitem}
+
+% For tickmarks
+\usepackage{amssymb}
\makeatletter
\newcommand{\sectionauthor}[1]{%
@@ -104,7 +109,7 @@
}
\newcommand{\subsectionauthor}[1]{%
{\parindent0pt\vspace*{-5pt}%
- \linespread{1.1}\large\scshape#1%
+ \linespread{1.1}\normalsize\scshape#1%
\par\nobreak\vspace*{10pt}}
\@afterheading%
}
diff --git a/main.tex b/main.tex
index d17de4bb54761d764672579a804efe4686dd1e2f..55c366a9894dd63d70388c2a6ba934d5386cccbf 100644
--- a/main.tex
+++ b/main.tex
@@ -5,6 +5,7 @@
\usepackage{bytefield}
\include{latexoptions}
+% For coloured tables.
\begin{document}
@@ -84,6 +85,9 @@
\input{./components/ir} \label{sec:IR}
\input{./components/flightcontroller}
\input{./components/copterparts}
+ \input{./components/circuitboards}
+ \input{./components/connectionsandwiring}
+ \input{./components/casesandmounts}
\newpage
@@ -99,19 +103,12 @@
\input{./implementation/ppm.tex}
\input{./implementation/motor-stepper.tex}
\input{./implementation/ethernet-lidar.tex}
- \input{./implementation/flight-controller.tex}
+ \input{./implementation/flightcontroller_imp.tex}
\input{./implementation/collision-avoidance.tex}
\newpage
\section{Result}
- \subsection{Delivery}
- \subsection{Testing}
- \subsubsection{Testing Strategy}
-
- \subsubsection{Regression Hazards}
-
- \subsubsection{Support Functions and Instructions}
-
+ \input{./chapters/result.tex}
\newpage
diff --git a/systemDesign.tex b/systemDesign.tex
deleted file mode 100644
index 2327c9780fe834f76386913a553e264f9e223f38..0000000000000000000000000000000000000000
--- a/systemDesign.tex
+++ /dev/null
@@ -1,7 +0,0 @@
-\subsection{Static Design}
- \subsubsection{Class Diagram}
- \begin{figure}[H]
- \centering
- \includegraphics[width=\textwith]{~/documents/D7039E/ConexReport/uml}
- \end{figure}
-