Merge branch 'master' of gitlab.henriktjader.com:D7039E-E7025E/conexreport

chapters/result.tex

@@ -51,6 +51,38 @@ The final result of the project, in regards to fulfilled goals, is as follows:
     The sensors were ordered and should accompany this project.
     The dev board shield has connectors dedicated to IR sensor connections, although these contacts have since been repurposed as general status LEDs.
 
+\subsection{Sonars - Final state}
+    \subsectionauthor{Author: Kamal Alkahwati}
+    The Sonars are implemented according to specification requirements but
+    upon testing it was discovered that they do malfunction sometimes. If HC-SR04 needs to measure a distance of more than ~600cm it will often malfuncion and give random measurement data. The problem is that the timeout of HC-SR04 doesn't work as it should, and instead of giving a timeout-pulse it just sends random data. It is suspected that this is a result of a too cheap assembly. This is solved using software filters, but they should be replace all in all in the future.
+
+
+\subsection{Collision Avoidance - Final state}
+    \subsectionauthor{Author: Lars Jonsson}
+	The Colission Avoidance and hovering is working, the copter can fly between to walls, with some oscillations and not as stable as we had wanted.
+
+	With further tuning of the PID's and some improved filtering of the sonar data, this could work to get a copter up and down the shaft without crashing.
+
+	This was not a priority for us at the end, since this controlling approach probably will be changed later on in the project.
+
+
+\subsection{LIDAR - Final state}
+    \subsectionauthor{Author: Henrik Tjäder}
+    LIDAR communication works, albeit with some caveats. Due to timing, sometimes LIDAR is not initialised properly before the much faster MCU requests data.
+
+    A potential remedy for this is to delay during startup to give the LIDAR more time or alternatively write a parser to check for the LIDAR response.
+
+    The intentions are to pack the LIDAR data into LAMP packets, this has not been finalized. All LIDAR data is currently sent over UDP to broadcast to ease debugging.
+
+\subsection{Copter - Final state}
+\subsectionauthor{Author: Max Unander}
+	The copter worked pretty much as planed, it handled our payload with no problem and was able to fly for about ten minutes which is twice the required flight time.
+
+
+\subsection{Circuit boards - Final state}
+\subsectionauthor{Author: Max Unander}
+	Our circuit boards are working well after a few patches. These patches includes fixing mistakes like crossed MISO and MOSI, also added a diode on the power board so that the 3.3 volt from the nucleo doesn't try to power the 5 volt when the battery isn't connected. New boards with all patches fixed and updated connectors are designed in eagle but haven't been ordered yet.
+
 \subsection{TODO: COMPONENTS ADD A FINAL STATE. What is done/not done etc.}
 
 
@@ -61,7 +93,6 @@ The final result of the project, in regards to fulfilled goals, is as follows:
     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.
@@ -73,12 +104,34 @@ The final result of the project, in regards to fulfilled goals, is as follows:
     Software trouble should smoothen out as experience grows, and it did so for our project group.
 
     Team members performed most of their work in the room provided by LTU, letting us cooperate and discuss.
-    Some uncertainties with the HAL libraries and other functionality was easiest resolved this way, among other general questions regarding development.
+    Alot of bugs and uncertainties were found in the in the HAL libraries throughout the project, some of which could be resolved pretty quickly whilst others were more time consuming. Some peripherals had such unreliable HAL libraries they were totally rewritten towards the end of the project. Having each other to discuss these issues, among other general questions regarding development proved to help significantly.
     This, combined with regular meetings each week allowed us to integrate our work more smoothly, as we were all present anyway.
 
-    TODO: Add details from Timers, IMU, SONAR maybe?
+    Many things not directly related to the project, but invaluable to the project's progress lies in the available tools and in the experince of those
+    who wield said tools.
+
+    With all of us having previous knowledge of STM32 hardware, few had delved deeper into the inner workings of how the toolchain manages to take all those source files
+    and in the end produce a flashable executable. There exists many "pre-made" toolchains available from different vendors. To name a few,
+    Atollic TrueSTUDIO, Kiel uVision, IAR EWARM, SW4STM32, lpcexpresso. Most of these come with their own IDE, either basing it on some opensource project such as Eclipse
+    or implementing their own thing. Picking any one of these is by some means a way of getting trapped in a vendor lock-in since it is usually not trivial to maintain compatibility
+    with more than one toolchain at a time or change between them.
+
+    Then how to do it without these huge dependencies? The answer: GNU Make.
+
+    As the project progressed the \texttt{Makefile} got improved and further functionality such as automating flashing and starting debugging sessions via OpenOCD + GDB were added.
+
+    This gave each of us the freedom to pick our own preferred working environment, such as working directly with the files via \texttt{vim}, \texttt{sublime} or through a full-fledged
+    IDE such as \texttt{Eclipse}.
+
+    Having \texttt{git} made working together a breeze. It is easy to test things out in a new branch and then if things went as expected just merge the changes back to the main branch.
+
+    With such modern hardware we would often need to run the very latest and in some cases even development versions of tools ta have proper support. Six out of seven group members
+    chose to install and run an \texttt{Arch Linux}-based system for programming and debugging. This was thanks to the bleeding edge nature of the distribution and the extensive software library available.
+
+    Even the very latest bleeding edge version of \texttt{arm-none-eabi} from the Debian \texttt{Sid} repository lagged behind the Arch-default version by a whole version: \texttt{5.4.1} vs \texttt{6.2.0}
+
+    The reason this was of concern was that all versions available in Debian failed compiling due to lack of MCU specific floating point support.
 
-    TODO: Continue this section!
 %\subsection{Testing}
 %    \subsubsection{Testing Strategy}
 

chapters/systemDesign.tex

 	\subsection{Code of Conduct}
-		The code follows a simple code of conduct. This generally helps avoid variable naming collisions and other issues which may result in undefined behavior.
+		The code follows a simple code of conduct. This generally helps avoid variable naming collisions and similar issues which may result in undefined behavior. With much consideration to simplicity in development it has been kept limited to resolve the most important code structuring issues.
+
+		Each file of code contains a group of functions related to a specific functionality. To avoid memory leaks and overwriting data, every function and global variable in a file has a prefix, which is the same as the name of the file. Enabling a developer to easily follow the code flow through files when coding or debugging.
+
+		The prefix must begin with a capital letter and variables and functions should begin with a lower case letter, unless it is an abbreviation, though this is discouraged.
+
+		Most of the functionality has to be initialized on boot before it can be used. The decision to make an \texttt{Prefix\_init()} function makes it easy to keep code flow and code names similar throughout the code.
+		\begin{table}[H]
+			\caption{Code of Conduct Example} \label{tab:SysDesCodeOConEx}
+			\begin{center}
+				\begin{tabular}{ r l }
+					\\
+					Prefix & \texttt{IMU} \\
+					Filename & \texttt{IMU.c} \\
+					 & \texttt{IMU.h} \\
+					Namespace & \texttt{IMU\_variable} \\
+					 & \texttt{IMU\_functionName()}\\
+					 Initialization & \texttt{IMU\_init()}
+				\end{tabular}
+			\end{center}
+		\end{table}
 
 	\subsection{Static Design}
 		\subsubsection{Class Diagram}
 			\begin{figure}[H]
 				\centering
-				\includegraphics[width=\textwidth]{Pictures/uml}
+				\includegraphics[width=0.7\textwidth]{Pictures/UML-Copter2}
 			\end{figure}
 
 		\subsubsection{Module Diagram}
 			\begin{figure}[H]
 				\centering
 				\caption{System module diagram}
-				\includegraphics[width=\textwidth]{Pictures/componentchart_2}
+				\includegraphics[width=0.7\textwidth]{Pictures/componentchart_4}
 			\end{figure}
-
-	\subsection{Dynamic Design}
-		\subsubsection{Activity Diagram}
-		\subsubsection{Sequence Diagram}
-		\subsubsection{State Diagram}
\ No newline at end of file

components/casesandmounts.tex

@@ -12,7 +12,7 @@ This was achieved by simply extending the motor mount arms so that the sonar cas
 	\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,
+The 3D model of the case for the sonar we got from \href{http://thingiverse.com}{Thingiverse} see Figure~\ref{fig:sonarcase} since it's a commonly used sensor it was easy to find,
 
 \begin{figure}[H]
 	\centering

components/copterparts.tex

@@ -2,15 +2,15 @@
 \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
+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.
+Next step was to choose motors and propellers to get enough lift force 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.
+We wanted at least five minutes of flight time so we chose a Zippy \SI{8000}{\milli\ampere} 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

components/imu.tex

 \subsection{IMU - Inertial Measurement Unit}
-    To track the movement of the copter in flight, a stable IMU with minimal swing effect has to be used.
-    There are several low cost IMU's available on the market, similar to the one in the flight controller.
-    While these are great for tracking instantaneous movement, they are not good at tracking movement over
-    time. Due to noise and swinging of the gyro while accelerating in any direction, the tracking will be
-    skewed while moving up and down the cave. This will result in a faulty scan. \newline
-    Xsens Technologies are well known in the industry for producing stable and accurate IMU's. Their
-    product series \href{https://www.xsens.com/products/mti-1-series/}{MTi 1} features all the specifications needed for the copter and was chosen as the
-    primary IMU for the project.
+    To track the movement of the copter in flight, a stable IMU with minimal swing effect has to be used. There are several low cost IMU's available on the market, similar to the one in the flight controller. While these are great for tracking instantaneous movement, they are not good at tracking movement over time. Due to noise and swinging of the gyro while accelerating in any direction, the tracking will be skewed while moving up and down the cave. This mostly results in incorrect or unreliable scanning data.
 
-    \begin{figure}[H]
-        \centering
-        \includegraphics[width=0.5\textwidth]{flowcharts/IMU}
-        \caption{IMU flowchart}
-    \end{figure}
+    Xsens Technologies are well known in the industry for producing stable and accurate IMU's. Their product series \href{https://www.xsens.com/products/mti-1-series/}{MTi 1} features all the specifications needed for the copter and was chosen as the primary IMU for the project.

components/usart.tex

 \subsection{USART - Universal Synchronous/Asynchronous \\Receiver/Transmitter}
 
-The built in USART in the \href{http://www.st.com/en/evaluation-tools/nucleo-f767zi.html}{STM32F7-NUCLEO}
-supports several communication standards for data transmission. Among these are RS-232 which requires two
-extra lines for communication. A Ready To Send (RTS) and a Clear To Send (CTS), which adds a layer of
-hardware flow control.
+The built in USART in the \href{http://www.st.com/en/evaluation-tools/nucleo-f767zi.html}{STM32F7-NUCLEO} supports several communication standards for data transmission. Among these are RS-232 which requires two extra lines for communication. A Ready To Send (RTS) and a Clear To Send (CTS), which adds a layer of hardware flow control.
+
+The processor also support Direct Memory Access(DMA). This automates the buffering of transmitted bytes, which relieves the processor of executing code to fetch each byte and store it in a buffer. This can be done both while transmitting and receiving data.

implementation/Timer.tex

+\subsection{Timer}
+\subsectionauthor{Author: Kamal Alkahwati}
+	Six separate timers are implemented for a different range of functionalities.
+
+	\begin{itemize}
+            \item TIM1 - PWM generator for triggering sonars
+            \item TIM2 - Dedicated Input Capture for manipulating PPM signals.
+            \item TIM3 - Input capture channels 1 \& 2 are used for distance measuring on sonars.
+            \item TIM4 - Input capture channels 1,2,3,4 are used for distance measuring on sonars.
+            \item TIM5 - Used to regurlarly fetch data from LiDAR
+            \item TIM9 - PWM generator used to drive the stepper motor that the LiDAR is mounted on.
+        \end{itemize}
+
+Below follows pin description for timers.
+	\begin{table}[H]
+		\begin{center}
+			\begin{tabular}{ l l }
+				\textbf{Pin} & \textbf{Usage} \\
+				\hline
+				PE9 & TIM1 CH1 \\
+				PA15 & TIM2 CH1 \\
+				PC6 & TIM3 CH1 \\
+				PC7 & TIM3 CH2 \\
+				PD12 & TIM4 CH1 \\
+				PD13 & TIM4 CH2 \\
+				PD14 & TIM4 CH3 \\
+				PD15 & TIM4 CH4 \\
+				PE5 & TIM9 CH1
+
+			\end{tabular}
+		\end{center}
+		\caption{Timer Pin Description} \label{tab:TimerPinDescription}
+	\end{table}
+

implementation/ethernet-lidar.tex

@@ -47,7 +47,6 @@ a wireless bridge between the STM32F767IZ and the LIDAR to the base station coll
 The ALFA AIP-W512 being both lightweight and operating at \SI{5}{\volt} made it an easy choice since
 any extraneous weight is unwanted and it could be directly attached to the \SI{5}{\volt} rail.
 
-The STM32 Nucleo board will request 
 Having ethernet hardware does not solve the problem altogether since the
 protocols and setup required for functional ethernet communication are non-trivial.
 

implementation/flightcontroller_imp.tex

@@ -18,10 +18,8 @@ To be able to do this we need to interact with the flight controller from our MC
 
 The flight controller do have support for four different communication protocols.
 It can take PWM inputs, where one PWM controls one channel.
-%It has
-It have PPM support, which is quite the same as a PWM but it has support for 8 PWM signals on one line.
-%does?
-It do support sBUS, which is some sort of secure serial protocol with inverted signals.
+It has PPM support, which is quite the same as a PWM but it has support for 8 PWM signals on one line.
+It does 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.
@@ -75,8 +73,6 @@ There are some things that was needed to be setup in Cleanflight to be able to f
 	\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: Add the configs from Cleanflight into an Appendix, will be done after Christmas.
 
 
 

implementation/fmea.tex

+\subsection{FMEA}
+An Failure modes and effects analysis (FMEA) was made at the beginning of this project and is found in the Appendix~\ref{appendix:fmea}.
+The FMEA is ranked from 1 - 5, where a low score is to prefer.
+As seen in the table problems with the MCU has the highest RPN score, this because it is the brain of the copter, and an faulty MCU renders in a copter crash.
+An faulty MCU is also hard to detect, because the probability to recover the drone after a crash is minor.
\ No newline at end of file

implementation/imu.tex

+\subsection{IMU}
+	\sectionauthor{Author: Daniel Björk}
+	Upon initialization of the \texttt{IMU} code, a request to go to configuration mode is sent to the MTi. The MTi is now prepared to be configured. \texttt{IMU} then transmit the configuration data, which enables the output of Euler Angles and Free Acceleration data at 100Hz.
+	
+	See Figure~\ref{fig:imuflowchart} for a visual representation of the communication flow. \texttt{IMU} first transmits a request of configuration mode, waits for a confirmation response, and then continues to transmit configuration data. When the configuration is complete, a request of measurement mode is sent to the MTi. The MTi will now continuously transmit data at the configured rate.
+	
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=0.5\textwidth]{flowcharts/IMU2}
+		\caption{\texttt{IMU} communication flowchart}
+		\label{fig:imuflowchart}
+	\end{figure}
+
+	The data received \texttt{8bits} at a time. Each data point transmitted contains \texttt{32bits}, formatted as a standard \texttt{IEEE 754 float}. The data is shifted into a temporary \texttt{32bit unsigned int} and then a \texttt{memcpy()} is executed from the \texttt{int} to a \texttt{float}. The data points are then sent over to \texttt{MSP} and stored. 
+	
+	Due to the high transmission rate of the MTi, DMA buffering has been implemented to relieve
+	the processor of constant code execution of receiving each byte. However transmission to the MTi is interrupt driven, due to the small amount of data that has to be sent. Something which is only executed upon launch, to configure the MTi.
+	
+	\begin{table}[H]
+		\begin{center}
+			\begin{tabular}{ l l }
+				\textbf{Pin} & \textbf{Usage} \\
+				\hline
+				PA3 & USART2 RX \\
+				PD5 & USART2 TX \\
+				PD3 & USART2 CTS \\
+				PD4 & USART2 RTS
+			\end{tabular}
+		\end{center}
+		\caption{Pin Description} \label{tab:IMUpindescription}
+	\end{table}
\ No newline at end of file

implementation/motor-stepper

 \subsection{Stepper motor}
+\subsectionauthor{Author: Kamal Alkahwati}
+
 A stepper motor is used to rotate the lidar to perpendicular to its own movement, thus creating a three dimensional view for the lidar to record.
 \newline
 The stepper motor is controlled via PWM on Timer 9, and the processor receives an interrupt for every step taken to keep track of number of steps (0 - 400). At every lap, a hall effect sensor gets triggered, which induces an extended interrupt on GPIOG Pin 3 to reset the step counter.
\ No newline at end of file

implementation/motor-stepper.tex

 \subsection{Stepper motor}
+\subsectionauthor{Author: Kamal Alkahwati}
 A stepper motor is used to rotate the lidar to perpendicular to its own movement, thus creating a three dimensional view for the lidar to record.
 \newline
 The stepper motor is controlled via PWM on Timer 9, and the processor receives an interrupt for every step taken to keep track of number of steps (0 - 400). At every lap, a hall effect sensor gets triggered, which induces an extended interrupt on GPIOG Pin 3 to reset the step counter.
\ No newline at end of file

implementation/ppm.tex

 \subsection{PPM}
+\subsectionauthor{Author: Kamal Alkahwati}
     The transmitter sends radio signals to the receiver, which converts these into PPM signals
     that the run on 8 different channels for controlling the copter. To be able to apply 
     automatic control to the quad, we need to modify these PPM signals as we'd like them. 

implementation/sonar.tex

 \subsection{Sonar - HC-SR04}
+\subsectionauthor{Author: Kamal Alkahwati}
 The sonars are triggered by a PWM generator on TIM1, with pulses of $\SI{10}{\micro\second}$ every 65ms. This will result in each sonar measuring in approximately \SI{15}{\hertz}.
 Pulse width measurement is done by using the input capture function on TIM3 CH1-CH2 and TIM4 CH1-CH4 respectively.
 Each input capture pin generates an interrupt if triggered, which in turn calls \emph{computeWidth} function that returns the width in microsecs. The width is then divided by 58, to get distance in cm and then transferred to MSP\_newSonardata.
@@ -11,10 +12,6 @@ Each input capture pin generates an interrupt if triggered, which in turn calls
 \end{figure}
 
 
-To start a measurement, Trig of SR04 must receive high (5V) for at least 10$\mu$s.
-This will initiate the sensor to transmit 8 cycles of ultrasonic bursts at 40KHz and wait for the reflection.
-When the receiver has detected the reflection, it will set the echo pin high (5V) and delay and delay for a period (width) which is proportionate to the distance.
-\\* To get distance in cm: Time/58.
 
 The sensors come complete with an ultrasonic transmitter and receiver module.
 \emph{Note:} If HC-SR04 needs to measure a distance of more than ~600cm it will malfuncion and give random measurement data. It is suspected that this is a result of a too cheap assembly.
@@ -25,5 +22,5 @@ This will initiate the sensor to transmit $\SI{8}{}$ cycles of ultrasonic bursts
 $\SI{40}{\kilo\hertz}$ and wait for the reflection.
 When the receiver has detected the reflection, it will set the echo pin high ($\SI{5}{\volt}$)
 and delay and delay for a period (width) which is proportionate to the distance, before pulling the pin back down.
-\\* To get distance in cm: $Width/58$.
+\\* To get distance in cm: $\frac{Width}{58}$.
 

implementation/spi-uwb.tex

 \subsection{SPI \& UWB radio}
-\subsectionauthor{Author: Fredrik Grönlund \& Emil Lundell\\Reviewer: TODO???}
+\subsectionauthor{Author: Fredrik Grönlund \& Emil Lundell\\Reviewer: Henrik Tjäder}
     \subsubsection{General description}
         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.

implementation/usartComPro.tex

+\subsection{USART Communication Protocols}
+	\sectionauthor{Author: Daniel Björk}
+	\subsubsection{xBus}
+		Communication with the IMU is preformed with an xBus message. First byte is always the preamble, followed by the destination address(which can be ignored when using USART), an operation code and the length of the message. To verify the message, a checksum is appended to the message.
+		
+		The message itself contains multiple data points, identified by a 2byte data identifier and an 1byte length.
+		
+		\begin{figure}[H]
+			\centering
+			\includegraphics[width=0.8\textwidth]{Pictures/xBus}
+			\caption{MTi xBus data point message example}
+			\label{fig:imuflowchart}
+		\end{figure}
+	
+	\subsubsection{MSP}
+		To communicate with the flight controller on board, an implementation of the MSP communication protocol is used. It shares much similarities with the xBus, but can be regarded as a simpler version. A preamble is used to trigger the start of a message, followed by the operation code and the length of the message. At the end, a checksum is appended to verify the message.
\ No newline at end of file