results.tex

\chapter{Resultat}
\label{cha:results}

\section{Systembeskrivning - vidareutveckling av TreeD}
\label{cha:results-systembeskrivning-treed}
%% Översiktlig beskrivning system, dokument
%% Vad har kunden för värde hos det som skapats?

Nedan följer en beskrivning av det ROS-baserade system som byggde vidare på TreeD och som utvecklades innan kraven i projektet omförhandlades med kunden.

Systemet bestod hårdvarumässigt av ett rotationsbord, en avståndskamera och en linjärenhet för att flytta avståndskameran längs en axel. För att styra detta fanns det sedan tidigare mjukvara, TreeD, som kan utföra en enskild skanning. Projektet skulle ha resulterat i en mjukvara för att utföra fler skanningar från olika vinklar och sammanfoga dessa till ett komplett objekt som kunde skrivas ut på en 3D-skrivare.

Tidigt i arbetet togs en systemanatomi fram, se figur \ref{fig:system_anatomy}, som beskriver vilken funktionalitet systemet skulle ha. Denna hjälpte även till med att dela in närliggande funktionalitet i moduler och låg som underlag för arkitekturbeskrivningen.

\begin{figure}[H]
	\centering{\tiny }
	\includegraphics[width=130mm]{figures/system_anatomy.png}
	\caption{Översikt över systemanatomin.}
	\label{fig:system_anatomy}
\end{figure}

Arkitekturbeskrivningen som togs fram för systemet förklarar hur systemet skulle fungera och vilka moduler som skulle finnas. Arkitekturen gav en bra utgångspunkt för hur systemet skulle implementeras. I arkitekturbeskrivningen finns det förklarat vilka noder systemet skulle bestå av och hur de skulle kommunicera med varandra.

Denna arkitektur var uppbyggd i ROS vilket innebär att de flesta noder i det tänkta systemet fungerade som en service som tog emot ett anrop för att utföra någonting och när den var klar svarade den med resultatet av arbetet. Detta gjorde att alla noder hade tydliga gränssnitt mellan varandra vilket resulterade i en bra separation mellan olika moduler.

Systemet var uppbyggt enligt en förenklad variant av \textit{pipe and filter}-modellen, där resultatet av ett steg skickas vidare som indata till nästa steg i modellen. Detta flöde styrdes av klienten så att användaren kunde välja att köra hela eller delar av processen. Figur \ref{fig:noddiagram} visar hur systemet var uppbyggt.

\begin{figure}[H]
	\centering
	\includegraphics[width=130mm]{figures/Noddiagram.png}
	\caption{Diagram över ROS-noderna i den första versionen av systemet.}
	\label{fig:noddiagram}
\end{figure}

Det tänkta systemet kunde samla in fler punktmoln. Detta gjordes av punktmolnshanteringsnoden som tog in ett värde för hur noggrant objektet skulle skannas. Punktmolnshanteringsnoden utförde ett antal skanningar genom att noden TreeD-wrapper kallades. Sedan registrerade punktmolnshanteringsnoden dessa inkompletta punktmoln till ett punktmoln som representerade hela objektet.

När ett komplett punktmoln hade genererats skickades det vidare till meshgenereringsnoden som uppskattade en tredimensionell yta bestående av polygoner, även kallad mesh, utifrån punktmolnet. Denna mesh kunde sedan användas för att generera kod som kunde köras på en 3D-skrivare för att skriva ut objektet.

Mycket tid under de första iterationerna av projektet spenderades på att utforska och undersöka olika tekniker och algoritmer. Som resultat av det finns det mycket nyttig kunskap i projektgruppen och även en del testkod för att utföra olika delar.

Det ROS-baserade systemet var uppdelat i en serverdel och en klient. Tanken var att servern skulle köras på en dator som var fysiskt kopplad till hårdvaran och på så sätt kunde styra den genom TreeD-wrappern. Klienten skulle i första hand köras på samma dator och styra servern men med möjligheten att köras på en annan dator och styra servern över nätverket. Se figur \ref{fig:systembeskrivning_gamla} för en bild på hur det tänkta systemet var planerat att vara strukturerat.

\begin{figure}[H]
	\centering
	\includegraphics[width=130mm]{figures/Systemskiss_gamla.png}
	\caption{En skiss av det tänkta ROS-baserade systemet.}
	\label{fig:systembeskrivning_gamla}
\end{figure}

Som kan ses i figurerna \ref{fig:noddiagram} och \ref{fig:systembeskrivning_gamla} var klienten den centrala delen i programmet. Den hanterade användarens indata och använde sig av de olika noderna för att utföra det användaren vill. Konceptet var att systemet skulle använda en \textit{pipe and filter}-arkitektur där klienten skickade runt data i pipen men att användaren, genom klienten, hade möjlighet att granska resultatet och göra viss handpåläggning mellan de olika stegen. Detta genom att klienten alltid kunde spara resultatet från ett steg till en fil och använda andra program för handpåläggningen innan den skickades vidare i systemet.

\section{Systembeskrivning - 3DCopy}

Som kan läsas tidigare i denna rapport omförhandlades projektets krav och mål med kunden under projektets gång. Detta ledde till att gruppen gjorde om systemets arkitektur. ROS-arkitekturen som presenterats i avsnitt \ref{cha:results-systembeskrivning-treed} ersattes. Istället skapades ett objektorienterat program, skrivet i C++. Detta program utför både registrering, filtrering och meshning. När sedan meshen genererats kan programmet skriva ut objektet med hjälp av en 3D-skrivare. Till detta program finns också ett CLI och ett GUI.

\subsection{Arkitektur}
Programmet består av två större klasser, \textit{Registration} och \textit{Mesh}. Dessa två klasser används sedan av \textit{Cli} vilket visas i figur \ref{fig:class_diagram}.  Det har lagts stor vikt vid moduläriteten i programmet då \textit{Registration} och \textit{Mesh} ska fungera självständigt i olika program.

\begin{figure}[H]
	\centering
	\includegraphics[width=130mm]{figures/klassdiagram.png}
	\caption{Översiktligt klassdiagram över arkitekturen.}
	\label{fig:class_diagram}
\end{figure}

\subsection{Kommandoradsgränssnitt (CLI)}

Systemet kan kontrolleras av ett CLI som kan ta in olika parametrar för att anpassa registreringen. Det finns även alternativ för att bara registrera eller bara mesha objekt. Under en körning av programmet med hjälp av kommandoradsgränssnittet väljs vilka filer eller mappar med filer programmet ska läsa in och använda. Hur de används beror på alternativen. Ett exempel på ett anrop är:\\\\
\texttt{3DCopy -v -{}-max-corr-dist 15 path/to/register/ output}\\\\
Det anropet kommer registrera och sedan mesha punktmolnsfilerna i mappen \textit{path/to/register/} och döpa det kompletta punktmolnet respektive färdiga meshen till \textit{output.pcd} och \textit{output.stl}. Under registreringen och meshningen kommer programmet att skriva ut information om processen på grund av \texttt{-v} flaggan som står för \textit{verbose mode}. Med flaggan \texttt{-{}-max-corr-dist} sätts värdet på \textit{Max correspondence distance}, se avsnitt \ref{sec:theory_registration}. Om man undrar vilka alternativ som finns kan man använda \texttt{-h} flaggan. Då skriver programmet ut de alternativ som finns samt hur man använder programmet med hjälp av kommandoradsgränssnittet. 

\subsection{Grafiskt användargränssnitt (GUI)}
För att lättare kunna styra systemet utvecklades också ett webbaserat GUI. GUI:t har samma funktionalitet som CLI:t och använder CLI:t för att köra meshning och registrering. Huvudvyn för det webbaserade GUI:t kan ses i figur \ref{fig:3DCopyGUIWeb}. 

\begin{figure}[H]
	\centering
	\includegraphics[width=130mm]{figures/3DCopyGUIWeb.PNG}
	\caption{Huvudvyn i 3DCopys webbaserade GUI.}
	\label{fig:3DCopyGUIWeb}
\end{figure}

De funktioner som finns i GUI:t är \textit{Add Registration Job} och \textit{Add Mesh Job}. \textit{Add Registration Job} öppnar ett formulär där parametrar på registreringen ska sättas och de filer som ska registreras ska väljas. Formuläret för registrering kan ses i figur \ref{fig:3DCopyGUIRegJobForm}.

\begin{figure}[H]
	\centering
	\includegraphics[width=130mm]{figures/3DCopyGUIRegJobForm.PNG}
	\caption{Formuläret för att skapa ett registreringsjobb.}
	\label{fig:3DCopyGUIRegJobForm}
\end{figure}

\textit{Add Mesh Job} öppnar ett formulär där parametrar på meshningen ska sättas och den fil som ska meshas ska väljas. Formuläret för meshning kan ses i figur \ref{fig:3DCopyGUIMeshJobForm}.

\begin{figure}[H]
	\centering
	\includegraphics[width=130mm]{figures/3DCopyGUIMeshJobForm.PNG}
	\caption{Formuläret för att skapa ett meshningsjobb.}
	\label{fig:3DCopyGUIMeshJobForm}
\end{figure}

Det finns även tre funktioner för varje jobb som finns i jobblistan. De funktionerna är \textit{View Job}, \textit{Start Job} och \textit{Delete Job}. Ett jobb och dess tillhörande funktioner kan ses i figur \ref{fig:3DCopyJobInList}.

\begin{figure}[H]
	\centering
	\includegraphics[width=130mm]{figures/3DCopyJobInList.PNG}
	\caption{Ett jobb i jobblistan.}
	\label{fig:3DCopyJobInList}
\end{figure}

\textit{View Job} visar information om det specifika jobbet, bland annat de filer som är associerade och de parametrar som valdes för jobbet. \textit{Start Job} startar jobbet på servern, jobben körs inte automatiskt efter de har skapats utan de måste manuellt startas. Slutligen kan \textit{Delete Job} väljas. \textit{Delete Job} tar bort jobbet, det vill säga all information om jobbet i databasen och alla filer på servern som associeras med jobbet.

\subsection{Registrering}
Systemet registrerar punktmoln parvis genom att använda PCLs implementation av ICP. De punktmoln som läses in i antingen CLI:t eller GUI:t behandlas av registreringsklassen och utför registreringen. För att registreringen ska fungera för olika fall kan användaren själv sätta värden på parametrarna \textit{Max correspondence distance}, \textit{Transformation epsilon} och \textit{Max iterations}. I figur \ref{fig:registrering_resultat} kan en bildserie ses. Denna bildserie föreställer resultatet från registrering med 1, 5, 11, 17, 23, 29 respektive 35 punktmoln. Punktmolnen som har använts vid registreringen i bilden föreställer en byst av Einstein och är tagna med tio graders skillnad. Bildserien visar hur bystens konturer växer fram allt efter som att fler punktmoln registreras. Efter den sista registreringen har ett punktmoln som föreställer bysten, utan lutning, framställts. 

\begin{figure}[H]
	\centering
	\includegraphics[width=50mm]{figures/Result_0.png}
	\includegraphics[width=50mm]{figures/Result_5.png}
	\includegraphics[width=50mm]{figures/Result_11.png}
	\includegraphics[width=50mm]{figures/Result_17.png}
	\includegraphics[width=50mm]{figures/Result_23.png}
	\includegraphics[width=50mm]{figures/Result_29.png}
	\includegraphics[width=50mm]{figures/Result_35.png}
	\caption{Resultatet av registrering med 1, 5, 11, 17, 23, 29 respektive 35 punktmoln.}
	\label{fig:registrering_resultat}
\end{figure}

\subsection{Meshning}
Den ytrekonstruering som systemet använder, PCLs \textit{Poisson surface reconstruction}, är väldigt beroende av att det registrerade punktmolnet inte har några punkter som har hamnat fel. Om några punkter är fel eller om det är för glest mellan punkterna så kan inte algoritmen räkna ut ytnormalerna korrekt. Om ytnormalerna blir fel kommer inte meshen att stämma överens med det objekt som punktmolnet föreställer.

I figur \ref{fig:einstein_mesh_without_imposition} visas en mesh, som föreställer Einstein, gjord med 3DCopy. Det syns tydligt att olika problem uppstår. Dels blir ytorna på den genererade meshen gryniga och liknar därför inte det skannade objektet till 100 \%. Det sista och största problemet med meshen är att det uppstår oönskad massa, vilket syns tydligt på Einsteins undre del av hakan.

\begin{figure}[H]
	\centering
	\includegraphics[width=30mm]{figures/ein_mesh_without_imposition1.png}
	\includegraphics[width=30mm]{figures/ein_mesh_without_imposition2.png}
	\includegraphics[width=30mm]{figures/ein_mesh_without_imposition3.png}
	\includegraphics[width=30mm]{figures/ein_mesh_without_imposition4.png}
	\caption{Mesh utan handpåläggning, objektet föreställer Einstein.}
	\label{fig:einstein_mesh_without_imposition}
\end{figure}

I figur \ref{fig:einstein_mesh_with_imposition} visas resultat efter manuell hantering av den genererade meshen i figur \ref{fig:einstein_mesh_without_imposition}. Den oönskade massan som fanns under Einsteins haka har plockats bort. Det syns även att de gryniga ytorna har slätats till, vilket i sig leder till att man går miste om detaljer i objektet.

\begin{figure}[H]
	\centering
	\includegraphics[width=30mm]{figures/ein_mesh_with_imposition1.png}
	\includegraphics[width=30mm]{figures/ein_mesh_with_imposition2.png}
	\includegraphics[width=30mm]{figures/ein_mesh_with_imposition3.png}
	\includegraphics[width=30mm]{figures/ein_mesh_with_imposition4.png}
	\caption{Mesh med handpåläggning, objektet föreställer Einstein.}
	\label{fig:einstein_mesh_with_imposition}
\end{figure}


\section{Gemensamma erfarenheter}
\label{cha:results_experiences}
%% Goda, mindre bra
%% I projektets alla faser
%% Tekniska, process-relaterade

I detta avsnitt presenteras de erfarenheter som gruppen har samlat på sig under projektets gång.

\subsection{Övergripande projekterfarenheter}

Att göra efterforskningar innan man börjar med någonting är väldigt viktigt och det märktes direkt i projektets början. Både genom att större delen av efterforskningarna kom till stor hjälp direkt i projektet och bara några dagar in i första iterationen märktes det att det fanns några områden som behövdes undersökas mer innan kod kunde implementeras. Ett exempel på bra efterforskning som gjordes i förstudien var efterforskningarna kring ROS där alla gruppmedlemmar gick igenom handledningsexempel och läste dokumentation som utvecklingsledaren gått igenom och tagit fram. I slutet av förstudien gjordes en gemensam kodutmaning där alla fick skriva varsin chattklient med hjälp av ROS. Kodutmaningen ledde till att alla kom in i ROS, Git, Python och andra verktyg som skulle användas under resten av projektet.


\subsection{Erfarenheter gällande kommunikation}

Betydelsen av kommunikation var stor under projektets gång. Verktygen \textit{Slack} och \textit{Trello} har använts flitigt och varit givande för gruppen. Med \textit{Slack} har gruppmedlemmarna alltid kunnat nå varandra snabbt och smidigt. Informationsflöden har kunnat hållits skilda och sorterade i olika kanaler. Funktioner som påminnelser och trådar har också varit till stor hjälp för att lätt kunna komma åt den informationen som man vill åt i flödena.

För att ha en översikt i hur det går med olika delar av projektet har gruppen använt \textit{Trello}. Genom att ha olika listor för statusen av dokument och funktioner under utveckling gjorde att varje gruppmedlem lätt kunnat se hur det går och vad som behöver göras.


\subsection{Erfarenheter gällande kvalitet}

Kvalitet har varit viktigt för gruppen och kvalitetssamordnare  har gjort ett bra jobb med att se till att projektets kod och dokument håller en hög standard. Detta framförallt genom granskning av dokument och kod. All kod i projektet har genomgått granskning för att säkerställa god kvalitet. Till detta har Githubs pull request-funktion använts där alla gruppmedlemmar kunnat kommentera och diskutera koden innan den går in i master branchen på repositoriet. Dokumenten har också granskats, då genom korrekturläsning. All denna granskning har varit mycket bra för att se hur andra gruppmedlemmar skriver dokument och kod.


\subsection{Erfarenheter av att bygga vidare på ett projekt}

I mitten av projektet upptäckte gruppen att det system som skulle vidareutvecklas inte fungerade tillräckligt stabilt för att det skulle vara möjligt att integrera med det system som gruppen utvecklade. Gruppen hade inte heller tillgång till någon slags testdokumentation från det tidigare projektet. Istället för att lita blint på det tidigare systemet borde gruppen i ett tidigt skede ha testat systemet utförligt. Då hade dessa fel kunnat hittas tidigare och en bättre plan för att arbeta runt dem kunde ha tagits fram. Detta hade lett till att alla parter blivit nöjdare med projektets resultat.

%I mitten av projektet upptäckte gruppen att det system som skulle vidareutvecklas inte fungerade tillräckligt stabilt för att det skulle vara möjligt att integrera med det system som gruppen utvecklade. Gruppen litade på att kunden hade god insikt i det tidigare systemet och eftersom att dessa fel inte togs upp i början av projektet förutsatte gruppen att det tidigare systemet inte innehöll några fel.

%Eftersom att gruppen inte hade någon anledning att tro att det tidigare systemet innehöll fel så genomfördes ingen rigorös testning av det tidigare systemet. Det saknades också testdokumentation och  annan dokumentation från den grupp som hade utvecklat det tidigare systemet. Det visar vikten av att väl dokumentera sitt system för att undvika problem i framtiden.


\section{Översikt över individuella bidrag}

Här listas de individuella bidrag som gruppens medlemmar har bidragit med till rapporten:

\begin{itemize}
	\item Dunström, Hampus - Hur påverkas ett team av sin arbetsmiljö?
	\item Holmberg, Olof - Kontexters påverkan vid testning av GUI
	\item Jannering, Gustav - Hur kravhanteringsmetoder påverkar ett utvecklingsprojekt
	\item Karlsson, Michael - Analys av punktmolnsregistrering
	\item Lundberg, Martin - Att bygga ett system i ROS
	\item Tuhkala, Hannes - Verktyg som är lämpliga för att skriva stora dokument
	\item Wallström, Fredrik - Kvalitetsarbete i praktiken
\end{itemize}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% results.tex ends here