diff --git a/memoire/chapters/content/besoins.tex b/memoire/chapters/content/besoins.tex
index a7563b8e543d450fede47198ddb9ce0c1bb5985d..105cb784c43b521bb18e015f4aece7b6959c596d 100644
--- a/memoire/chapters/content/besoins.tex
+++ b/memoire/chapters/content/besoins.tex
@@ -1,35 +1,47 @@
\chapter{Besoins et Fonctionnalités}
\section{Définition des besoins}
-La librairie doit permettre à l'utilisateur de l'utiliser simplement en l'important dans son projet. Il faut réduire sa complexité en :
-\begin{itemize}
- \item supprimant l'architecture client-serveur
- \item retirant l'affichage de librairie et la délégant à l'application utilisateur
-\end{itemize}
-Il faut aussi :
+Lors du montage de l'infrastructure du bac à sable, la caméra et le vidéoprojecteur peuvent ne pas être exactement positionnés comme ils le devraient, c'est pourquoi nous prenons en compte les paramètres décrient dans \textit{problématiques géométriques}. Mais ces paramètres ne sont pas facilement déterminables, c'est pourquoi il faut mettre en place une application de calibration permettant de déterminer ces paramètres de manière guidée. De plus cette application devra se baser sur une librairie de calibration, afin de pouvoir créer différentes applications de calibration si besoin.\\
+De plus, il faudrait aussi éviter de réitérer la procédure de calibration à chaque utilisations de la librairie.\\
+Enfin, il faudra fournir une librairie d'utilisation du bac à sable, afin que les développeurs puissent utiliser le bac de manière simple. C'est à dire, charger la configuration établi lors de la calibration et initialiser le système, ainsi que récupérer les images prises par la caméra et ajuster correctement l'image à projeter. Le tout en essayant de minimiser le temps des traitements, afin de rendre les applications le plus dynamique possible.
+
+
+
+\section{Fonctionnalités}
+La librairie devra être séparée en deux parties distinctes. Une devra fournir les fonctionnalités
+de calibration de la librairie, et l’autre devra fournir les fonctionnalités d’utilisation de la
+librairie.\\
+\subsection*{Librairie d'utilisation}
+La librairie d'utilisation devra permettre ces points clé :
\begin{itemize}
- \item faciliter la calibration pour l'utilisateur
- \item sauvegarder la configuration pour la rendre persistante
- \item améliorer la précision de l'affichage d'une image
- \item améliorer les performances de la librairie
+ \item capture les photos de profondeurs et couleurs avec la camera
+ \item ajuste une image à projeter sur le bac à sable
+ \item charge la configuration depuis le fichier
+ \item initialise le bac à sable
\end{itemize}
-\section{Fonctionnalités}
-La librairie devra être séparé en deux parties distinctes. Une devra fournir les fonctionnalités de calibration de la librairie, et l'autre devra fournir les fonctionnalités d'utilisation de la librairie.
+De telle manière que nous puissions l'utiliser de la façon suivante :
+\begin{figure}[H]
+ \centering
+ \includegraphics[scale=0.7]{diagram_sequence_sandbox.jpg}
+ \caption{Diagramme de séquence de la librairie d'utilisation}
+ \label{fig:besoins_diagram_sequence_sandbox}
+\end{figure}
+
+Une fois les étapes de configuration et initialisation effectuées avec succès, l'utilisateur de la librairie pourra récupérer les images de la caméra et effectuer un traitement dessus pour projeter son image après l'avoir ajustée.
+\subsection*{Librairie de calibration}
+La librairie de calibration devra permettre à l'application d'exécuter correctement les routines et sauvegarder la configuration. Elle devra donc :
\begin{itemize}
- \item Librairie d'utilisation
- \begin{itemize}
- \item capture les photos de profondeurs et couleurs avec la camera
- \item ajuste une image à projeter sur le bac à sable
- \item charge la configuration depuis le fichier
- \item initialise le bac à sable
- \end{itemize}
-
- \item Librairie de calibration
- \begin{itemize}
- \item charge certaines informations du fichier de config si disponible
- \item fournit les methodes de calibration
- \item sauvegarde la config dans un fichier
- \end{itemize}
+ \item charger certaines informations du fichier de config si nécessaire
+ \item fournir les méthodes de calibration permettant de déterminer les données de configuration
+ \item sauvegarder la configuration dans un fichier pour la rendre persistante
\end{itemize}
-Il faudra aussi fournir une application de calibration qui produira un fichier de configuration pour faciliter la calibration de la librairie avec son environnement et ne pas devoir la répéter à chaque utilisations de la librairie d'usage. L'application utilisera la librairie de calibration.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[scale=0.7]{diagram_sequence_sandbox_setup.jpg}
+ \caption{Diagramme de séquence de la librairie de calibration}
+ \label{fig:besoins_diagram_sequence_sandbox_setup}
+\end{figure}
+
+Dans ce scénario, nous allons récupérer les données de configuration en effectuant les routines de calibration, puis les sauvegarder dans un fichier. Ainsi nous avons notre configuration de prête pour les applications utilisateurs.
diff --git a/memoire/chapters/content/dispositif.tex b/memoire/chapters/content/dispositif.tex
index fd63c56a53fa64765e03517d9d57f1129db43b14..6e29de421fb80211c1468eaaea76e6ec5f51f2b4 100644
--- a/memoire/chapters/content/dispositif.tex
+++ b/memoire/chapters/content/dispositif.tex
@@ -1,26 +1,43 @@
\chapter{Description du dispositif}
-Le projet utilise une camera pour récupérer la topologie du bac à sable qui nous permettra d'ajuster en conséquence l'image à projetée par le vidéoprojecteur sur le bac à sable.
+Le projet utilise une camera pour récupérer la topologie du bac à sable qui nous permettra d’ajuster en conséquence l’image à projetée par le vidéoprojecteur sur le bac à sable.
\begin{figure}[H]
\centering
\includegraphics[scale=0.5]{dispositif.jpg}
+ \caption{Dispositif}
+ \label{fig:dispositif_dispositif}
\end{figure}
-Dans notre cas, nous utilisons la camera Intel D415 avec la librairie realsense 2.
-\\\\
-Le but de la librairie sandbox est de fournir les images de couleurs et de profondeurs transmisent par la caméra correspondant à la zone d'affichage du vidéoprojecteur.
+Contrairement au projet décrit dans l'introduction, nous utilisons la caméra d'Intel D415 avec la librairie realsense 2, ainsi que le vidéoprojecteur PLC-XU116 de la marque Sanyo.
+
+\section{Problématiques géométriques}
+Normalement, lorsque nous voulons projeter une image avec un vidéoprojecteur, nous le faisons sur une surface plane. Hors dans notre cas, l'image est projetée sur le sable avec une certaine topologie.
\begin{figure}[H]
\centering
- \includegraphics[scale=0.35]{camera_zones.jpg}
+ \includegraphics[scale=0.4]{adjust_pixel.jpg}
+ \caption{Projection pixel}
+ \label{fig:dispositif_adjust_pixel}
\end{figure}
-Elle doit aussi adapter l'affichage d'une image projetée par rapport au point de vue du vidéoprojecteur.
+
+Comme notre vidéoprojecteur doit pouvoir projeter sur une surface plane, nous avons défini le sommet du bac à sable comme repère pour projeter notre image. Ainsi le champ de vision de la caméra correspond à la zone de projection du vidéoprojecteur. \\
+Dans ce schéma, nous avons la caméra qui récupère la hauteur à un certain point (orange) et nous avons notre vidéoprojecteur qui projette un pixel. Ce pixel sera projeté à la position bleu sans ajustement, car l'image projetée correspondant au champ de vision de la caméra. C'est seulement en corrigeant la position sur notre plan (sommet du bac à sable), que nous pouvons adapter notre affichage à la position du vidéoprojecteur. Donc en ajustant le pixel qui serait projeté à la position bleu, vers la position orange, nous arrivons à projeter une image cohérente sur le sable.\\
+Malheureusement, l'infrastructure mise en place ne sera pas toujours aussi exacte que celle sur le schéma. Notamment la position de la caméra et du vidéoprojecteur, ainsi que la taille du bac à sable. C'est pourquoi il faut ajuster la taille de l'image projetée à celle de la capture de la caméra.
+
\begin{figure}[H]
\centering
- \includegraphics[scale=0.4]{adjust_pixel.jpg}
+ \includegraphics[scale=0.35]{camera_zones.jpg}
+ \caption{Zones de la caméra et de la projection}
+ \label{fig:dispositif_camera_zones}
\end{figure}
-Si on ne corrige pas l'image projetée, on aura un décalage des pixels. Par défaut le pixel orange sera projetée à la position bleu. Tandis qu'avec la correction, il sera à la position orange. Le plan sur lequel les points rouge et vert sont alignés nous sert de base pour l'ajustement.
-\\\\
-Il faut aussi corriger la rotation de la projection pour que la zone affichée corresponde à celle de la camera, car le vidéoprojecteur ne sera pas forcément toujours bien positionné.
+
+Ainsi, en ajustant seulement les pixels de la projection, nous conservons la cohérence entre la zone de projection et la zone capturée par la caméra.\\
+Enfin il se peut que le vidéoprojecteur ne soit pas parfaitement droit et qu'il y ait une rotation de l'image projetée par rapport à la caméra.
+
\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{rotation.jpg}
+ \caption{Correction de la rotation du vidéoprojecteur}
+ \label{fig:dispositif_rotation}
\end{figure}
+
+En corrigeant cette rotation lors de l'affichage, nous aurons une projection juste par rapport à la caméra.
+
diff --git a/memoire/chapters/content/existant.tex b/memoire/chapters/content/existant.tex
index 71b15151b2cfb9dfdb50845542c992644e12d441..d215abc497882c0a19308fa8596491eeecae5722 100644
--- a/memoire/chapters/content/existant.tex
+++ b/memoire/chapters/content/existant.tex
@@ -1,12 +1,47 @@
\chapter{Etude de l'existant}
-Le projet duquel est inspiré celui-ci était une application qui permettait l'utilisation du bac en réalité augmentée. Malheureusement, il était impossible de partir de ce projet pour faire d'autres applications.
-\\
-site ar sandbox université california : \url{https://arsandbox.ucdavis.edu/}
-\\
-Dans la version précédente réalisé par mon prédécesseur, le but était faire une première version de la librairie.
+\section{UCDavis}
+Comme vue précédemment dans l'introduction, ce projet se base sur d'autres projets de réalité augmentée de bac à sable. Nous avons entrevu le projet de l'université de Californie à Davis qui fonctionnait ainsi :
+\begin{figure}[H]
+ \centering
+ \includegraphics[scale=1]{ARSandboxLayout.jpg}
+ \caption{Infrastructure du bac à sable de l'université de Californie à Davis, \url{https://arsandbox.ucdavis.edu/instructions/hardware-2/}}
+ \label{fig:existant_ARSandboxLayout}
+\end{figure}
+Le projet utilise la Kinect 3D de Microsoft, ainsi qu'un vidéoprojecteur courte portée avec un ratio d'affichage de 4:3, afin que la zone projetée corresponde à la zone de capture de la Kinect. Enfin nous avons les applications qui s'exécutent sur l'ordinateur connecté.\\
+Ce projet est abouti, malheureusement, la Kinect utilisée dans ce projet n'est plus en production depuis octobre 2017(\url{https://fr.wikipedia.org/wiki/Kinect}). Bien qu'un nouveau modèle de la Kinect soit sortie (Azur Kinect DK,\url{https://www.microsoft.com/en-us/p/azure-kinect-dk/8pp5vxmd9nhq}), le projet ne la supporte pas, par contre il supporte les caméra Realsense de Intel.\\
+Toutefois, le projet fournit directement ces application et ne propose pas de librairie permettant de développer des application pour le bac. De plus, les infrastructures utilisant les applications disponibles doivent respecter cet infrastructure.
+
+\section{Adow}
+Le second projet est celui de Mr. Adow, réalisé dans le cadre de son travail de bachelor. Son projet était basé toujours sur la même infrastructure de bac à sable en réalité augmentée, mais il utilisait la caméra d'Intel D415, avec le vidéoprojecteur PLC-XU116 à focale courte de la marque Sanyo.\\
+De plus le projet proposait une API qui était accessible au travers d'un serveur local. Cela permettait une flexibilité sur le langage de l'interface de la librairie.
+
\begin{figure}[H]
\centering
\includegraphics[scale=0.3]{old_lib_srv.jpg}
+ \caption{Architecture API client-serveur du projet de M. Adow, \url{https://arsandbox.ucdavis.edu/instructions/hardware-2/}}
+ \label{fig:existant_ARSandboxLayout}
\end{figure}
-Cette version de la librairie est basé sur une architecture client-serveur et était encore trop lié à l'application. Il fallait donc vraiment dissocier l'API des applications et réduire au maximum sa complexité. Autrement dit, une librairie sans architecture client-server.
+
+Une fois le serveur exécuté et la calibration du bac à sable complétée, nous pouvions utiliser le bac en envoyant l'image à projeter au serveur.\\
+Bien que ce projet offre un API pour développer des applications, certains points restent à améliorer comme le fait que l'étape de calibration soit nécessaire à chaque exécution du serveur, ainsi que le manque d'une véritable application de calibration.
+
+
+\section{Camera}
+
+Lors du choix de la caméra, il faut prendre en compte ses performances, ainsi que ses spécificités d'objectif. Le but étant de trouver une caméra pouvant être positionné à un mètre au-dessus du bac, nous avons comparé les caractéristiques de la Realsense D415 et de la D435.
+
+\begin{center}
+ \begin{tabular}{|m{2cm} m{2cm} m{2cm} m{2cm} m{2cm}|}
+ \hline
+ Caméra & Ouvertures objectif & Distance minimum & Résolution profondeur & Vitesse de rafraîchissement \\
+ \hline
+ D415 & 65°±2° × 40°±1° & 0.16 m & Up to 1280 × 720 & Up to 90 fps \\
+ \hline
+ D435 & 86° × 57° (±3°) & 0.105 m & Up to 1280 × 720 & Up to 90 fps \\
+ \hline
+ \end{tabular}
+\end{center}
+
+Les deux caméras ont globalement les mêmes caractéristiques, avec la D435 qui est plus imposante que la D415. Mais ce qui détermina notre choix, c'est l'ouverture des caméras. La D435 a une ouverture plus grande que la D415, ce qui implique que si nous voulons avoir notre bac à sable complètement dans l'objectif, nous devrons poser la D435 plus bas que la D415. Mais comme nous voulons poser notre caméra à un mètre et que notre bac à sable est de dimensions 100cmx75cm. Nous avons déduit que la D415 s'approchait le plus de cette hauteur.
+
diff --git a/memoire/chapters/content/implementation.tex b/memoire/chapters/content/implementation.tex
index 0da47ad5cef71931c98e41000e111163b6d64697..727f81d42b2d95ae5b382d7cdc7eb00a07cc610f 100644
--- a/memoire/chapters/content/implementation.tex
+++ b/memoire/chapters/content/implementation.tex
@@ -1,6 +1,6 @@
\chapter{Conception et implémentation}
\section{Sandbox}
-\subsection{Principe}
+\subsection*{Principe}
La librairie Sandbox doit fournir une interface permettant l'affichage d'une image dans le bac à sable adapté à la topologie de celui-ci. Comme vu précédemment dans la description, plusieurs ajustement sont nécessaires. Nous allons donc voir plus précisément comment l'ajustement de l'image ce fait.\\
En appelant la fonction adjustProjection, l'utilisateur passe son image en couleur à projeter :
\begin{itemize}
@@ -25,10 +25,10 @@ En regardant de plus près la fonction adjustFrame, on peut voir qu'elle suit ce
Maintenant nous avons une compréhension plus précise de ce qu'il se passe lors du traitement d'une image. Nous verrons plus en détails la fonction adjustFrame dans Projection.
-\subsection{SandboxConfig}
+\subsection*{SandboxConfig}
Bien que nous ayons vu le principe de l'ajustement d'une image, il est irréalisable tant que nous ne possédons pas les informations de configuration. C'est pourquoi dans la librairie, il y a une méthode permettant de lire le fichier de configuration yaml et charger les informations dans leurs variables respectives. Si on regarde dans cette méthode, on s'aperçoit qu'elle utilise les méthodes statiques de la classe SadnboxConfig, afin de charger les informations nécessaires lors du processus d'ajustement de l'image projetée. Grâce à la librairie yaml-cpp, il est très facile d’interagir avec les données. Il suffit de charger les données dans un nœud, pour ensuite interagir avec ce nœud comme avec un tableau associatif. De plus, il est aussi facile d'écrire les données dans un fichier, il suffit de traiter le nœud comme du texte lors d'un affichage dans la sortie standard en C++.
-\subsection{Camera}
+\subsection*{Camera}
La librairie utilise la caméra D415 de Intel. Elle comprend deux récepteurs stéréo avec un projeteur qui servent à capturer l'image de profondeur et un récepteur RGB qui sert à capturer l'image de couleur. https://www.intelrealsense.com/wp-content/uploads/2020/06/Intel-RealSense-D400-Series-Datasheet-June-2020.pdf (p.108)
\begin{figure}[H]
\centering
@@ -78,7 +78,7 @@ Nous nous sommes permis de réimplémenter ces deux fonctions, car nous avions b
Comme les images capturées par la caméra et le profil intrinsèque sont liés, s'il l'on veut adapter les valeurs de f et pp tout en restant cohérent avec une image de dimensions différentes, il faut adapter l'image à la matrice capturée par la caméra pour qu'elles correspondent lorsqu'on les déprojettent. C'est pourquoi nous avons la méthode getAdaptedIntrinsics qui retourne ces deux paramètres ajustées à l'image à projetée.\\
Les images de profondeurs subissent aussi un filtre spatiale et temporelle. Le spatiale permet de réduire le nombre d'information manquante dans l'image de profondeurs et le temporelle permet de stabiliser les valeurs, car les valeurs varient légèrement entre deux images même si rien n'a changé physiquement.\\
-\subsection{Projection}
+\subsection*{Projection}
Projection
Projection est la classe qui nous permet d'ajuster l'image projetée sur le bac à sable en tenant compte des données de l'environnement. C'est but est donc principalement tourné vers l'utilisation de la fonction adjustFrame. Dans cette fonction nous utilisons plusieurs buffeurs qui ont tous les mêmes dimensions : resized-src, resized-depth, deprojectMap et frameMap. Ainsi avec le pseudo code suivant nous pouvons reconstruire l'image à projeter:
\begin{itemize}
@@ -121,14 +121,14 @@ Ensuite nous parcourons frameMap pour connaître à quel autre pixel correspond
C'est pourquoi il s'en suit l'étape de rebouchage de trous. Dans cette étape, nous parcourons à nouveau frameMap, mais cette fois à la recherche de valeurs manquantes. Lorsque nous en trouvons une, nous copions la valeur du premier voisin non vide ce trouvant à une distance d'une case.
Enfin, il ne reste plus qu'à appliquer la matrice de rotation à notre image de sortie.\\
-\subsection{Beamer}
+\subsection*{Beamer}
Dans le cas de la librairie sandbox, la classe Beamer sert à fournir la position 3D relative à la caméra de celui-ci et sa résolution. Ces informations sont toutes deux utilisées lors de l'adaptation de l'image projetée.
\section{SandboxSetup}
La classe SandboxSetup sert de deuxième interface à la librairie sandbox, mais son but est de fournir les méthodes nécessaires à la génération d'un fichier de configuration complet. La classe SandboxSetup fournit les éléments comme la classe Sandbox, c'est à dire l'accès aux classes Beamer, Camera et Projection, mais aussi à SandboxConfig. Le principe est de paramétrer les classes comme si nous allions utiliser l'interface Sandbox, sauf que nous allons sauvegarder la configuration dans un fichier yaml grâce à la méthode fournit par SandboxSetup, elle permet de sauvegarder tout les éléments nécessaires en utilisant les fonctions de SandboxConfig.
La classe fournit aussi de quoi calculer la matrice de rotation et la zone d’intérêt de la capture de la caméra, car à ce stade, aucun traitement n'est fait sur les images. Nous utilisons simplement la camera et renvoyons les informations telles quelles. Il est aussi possible de charger le FrameProcessProfil qui sera utile lors du traitement d'images durant la calibration. Nous verrons plus en détails dans la partie Beamer.
-\subsection{AdjustMatrix}
+\subsection*{AdjustMatrix}
La méthode permettant de déterminer la matrice de rotation dans la classe SandboxSetup prend simplement la liste des coins d'un rectangle et son centre, afin de déterminer son angle de rotation grâce aux points P0 et P3, où le coin de référence pour la rotation dépendra de P0. Une fois la matrice déterminée, nous la sauvegardons dans la classe Projection.
\begin{figure}[H]
@@ -139,10 +139,10 @@ doc adow p.30
\\
Il est important de noter que comme la matrice redresse l'image, elle est dépendante de la rotation de la caméra si on applique la matrice à une image prise avec celle-ci.
-\subsection{CroppingMask}
+\subsection*{CroppingMask}
La méthode permettant de déterminer le masque de découpage utilise les mêmes points que pour la déterminer la matrice de rotation, sauf qu'on applique la rotation aux coins pour avoir un rectangle droit. Puis nous la sauvegardons dans la classe Camera.
-\subsection{Beamer}
+\subsection*{Beamer}
La classe Beamer propose elle aussi des méthodes liées à la calibration. En effet c'est même le cas pour la majorité d'entre elles.
\subsubsection*{Procédure}
Ces méthodes sont basées sur une procédure de calibration précise. L’utilisateur devra ce munir d’une cible comme ci-dessous afin de la réaliser.
@@ -174,7 +174,7 @@ Retourne une liste de coordonnées correspondant aux croix à viser lors de la c
Cette méthode adapte le constraste et la luminosité d’une image en noir et blanc en suivant cette equation :\\
g(i,j) = alpha * f(i,j) + beta où alpha > 0\\
\url{https://docs.opencv.org/2.4/doc/tutorials/core/basic_linear_transform/basic_linear_transform.html}
-\subsubsection{findCircles}
+\subsubsection*{findCircles}
Cette méthode permet de récupérer la position des cercles détectés. Elle est basée sur la méthode houghCircles d’OpenCV définit par :
void HoughCircles(InputArray image, OutputArray circles, int method, double dp, double minDist, double param1=100, double param2=100, int minRadius=0, int maxRadius=0 )
HoughCircle est basé sur une matrice de compteurs, appelée accumulateur. Pour détecter un cercle, il faut tout d’abord appliquer un filtre Canny permettant de ne garder que les contours des formes dans l’image. Puis nous allons parcourir chaques pixels de notre image de contours et lorsque nous rencontrons un pixel de valeur non vide/noir, nous allons tracer un cercle autour de ces pixel, en traçant ce cercle, nous incrémentons de un aux mêmes coordonnées dans notre accumulateur. Une fois l’image parcourue, nous pouvons controller notre accumulateur pour trouver les cercles potentiels. Si les valeurs de l’accumulateur dépasse un certain seuil, alors nous avons un cercle centré à cette endroit de l’image de radius égal à celui avec lequel nous avons parcourue notre image de contours précédement.
@@ -227,7 +227,7 @@ Donc nous avons :
\end{itemize}
\section{Fichier de configuration}
Le fichier de configuration est le fichier permettant de sauvegarder les données nécessaires à l’utilisation de la classe Sandbox et déterminées lors de la calibration. Il écrit au format YAML et est donc facilement lisible et modifiable.
-\subsection{AdjustingMatrix}
+\subsection*{AdjustingMatrix}
Cette variable contient la matrice qui permet de corriger la rotation du vidéoprojecteur. Elle est sauvegardée dans le fichier sous forme de vecteur, mais il s’agit bien d’une matrice de 2x3 comme l’indiqueront la hauteur et la largeur. L’angle sur lequel est basé la matrice de rotation est aussi disponible.
Si la matrice a de telles dimensions, c’est parce qu’elle est basé sur les transformations affines, on doit donc pouvoir appliquer une rotation, une translation ou un changement d’échelle avec celle-ci.
\begin{figure}[H]
@@ -242,16 +242,16 @@ De plus si l’on regarde la fonction d’OpenCV warpAffine, qui applique notre
\end{figure}
\url{https://docs.opencv.org/2.4/modules/imgproc/doc/geometric_transformations.html?highlight=warpaffine#warpaffine}
Avec cette formule, on observe que seul les deux premières colonnes sont multipliés aux coordonnées, donc la troisième contient le décalage lié au centre de rotation en cas de translation de l’image et les deux priemières sont celles liées à la rotation et à l’ajustement de l’échelle.
-\subsection{DistanceTopSandbox}
+\subsection*{DistanceTopSandbox}
Cette variable sert à déterminer la distance entre la caméra et le dessus du bac à sable, car c’est à cette distance que l’image virtuelle reconstruite pour le vidéoprojecteur se trouve. Comme la matrice de profondeur fournit par la caméra, est en float, cette distance l’est aussi.
-\subsection{CroppingMask}
+\subsection*{CroppingMask}
Le CroppingMask est le rectangle permettant de rogner l’image de la caméra afin d’avoir uniquement la zone où le vidéoprojecteur affiche dans le bac à sable. Comme c’est un rectangle dans le même sense que la caméra, il n’a pas de rotation et est dépendant de la résolution de la caméra. Nous pouvons donc manipuler sa position et ses dimensions si nous connaissons le matériel.
-\subsection{BeamerResolution}
+\subsection*{BeamerResolution}
BeamerResolution permet de connaître la résolution de l’image à reconstruire et projeter. Elle est simplement constituer d’une largeur et d’une hauteur.
-\subsection{BeamerPosition}
+\subsection*{BeamerPosition}
BeamerPosition est la position du vidéoprojecteur en 3D basée sur la caméra en mètres. Où dans le cas de la librairie realsense 2, le point (0,0,0) représente le centre, l’axe des x positif va vers la droite, celui des y positif vers le bas et celui des z positif pointe tout droit. En sachant cela, nous pouvons, si besoin est, approximer directement la position du vidéoprojecteur par rapport à la caméra et la modifier. Les valeurs sont séparées par les trois axes et sont en float.
\url{https://dev.intelrealsense.com/docs/projection-in-intel-realsense-sdk-20#distortion-models}
-\subsection{FrameProcessProfil}
+\subsection*{FrameProcessProfil}
Cette variable est la seul qui nous est utile uniquement pour l’application de calibration. Son but est de contenir les informations de la classe FramProcessProfil, car il est fastidieux de saisir ce profil à chaque calibration, si certains éléments de l’environnement où ce trouve le bac à sable ne change pas. Comme énoncé précédemment et avec des précisions :
\begin{itemize}
\item contrast doit être supérieur à 0.
@@ -264,7 +264,7 @@ Cette variable est la seul qui nous est utile uniquement pour l’application de
\end{itemize}
\section{Application de calibration}
L’application de calibration est l’application permettant de créer le fichier de configuration complet et qui se base sur la classe SandboxSetup. Comme vu précédemment dans l’architecture
-\subsection{SubApp}
+\subsection*{SubApp}
Cette classe représente une étape de la calibration, soit une forme dans l’application. Elle hérite de la classe Widget de Qt, afin de permettre une insertion de la classe qui en découle d’être traitée comme un Widget. Cette classe SubApp fournit quleques fonctions permettant de la gérer comme une étape d’un processus. Elle propose donc les méthodes clés suivantes :
\begin{itemize}
\item checkRoutine() : permet de vérifier si l’étape s’est bien déroulée en retourant un booléan
@@ -272,7 +272,7 @@ Cette classe représente une étape de la calibration, soit une forme dans l’a
\item cancelRoutine() : permet d’annuler l’étape comme si celle-ci n’avait pas encore commencée
\end{itemize}
La classe permet aussi d’envoyer un signal avec "sendNotif" et contiendra un int comme état de l’étape en cours. Cela permet à celle-ci d’envoyer une notification d’état au parent, soit l’application de calibration qui gère les étapes.
-\subsection{MainWindow}
+\subsection*{MainWindow}
MainWindow est la classe de notre application de calibration, c’est elle qui va regrouper et ordonner les différentes étapes afin de générer correctement le fichier de configuration final. Cette application va instancier les éléments nécessaire afin d’exécuté les étapes dans l’ordre ci-dessous. Les étapes sont directement représentées par leur classe respective héritant de SubApp. Nous avons donc une liste de SubApp exécutée dans cet ordre :
\begin{figure}[H]
\centering
@@ -280,14 +280,14 @@ MainWindow est la classe de notre application de calibration, c’est elle qui v
\end{figure}
Afin de naviguer entre chaque étapes avec les boutons de l’interface "précédent" et "suivant", notre classe parente va exécuter "cancelRoutine" de la forme actuelle en cas de clique de l’utilisateur sur "précédent" ou va exécuter "verifyRoutine" si le bouton "suivant" est pressé, si la méthode ne retourne rien d’anormal, "valideRoutine" est à son tour exécutée avant de passer à la forme suivante.\\
Dans le cas où la forme actuelle à besoin d’intéragir avec MainWindow, la forme peut envoyer un signal à travers "sendNotif" qui sera lié au slot "receiveNotif" de MainWindow et ainsi envoyer l’état.
-\subsection{InitCameraGui}
+\subsection*{InitCameraGui}
Cette classe sert à vérifier la précense de la caméra et l’initialiser. Comme la routine d’initialisation est bloquante, elle est exécutée dans un thread à part.
-\subsection{MonitorGui}
+\subsection*{MonitorGui}
MonitorGui permet de choisir la sortie correspondant au vidéoprojecteur. Elle utilise la librairie xrandr afin de récupérer les informations liées aux écrans connectés et leurs résolutions. De plus un apperçu de l’écran est visible lors de la sélection d’une sortie. Le but était utilisé Qt afin de récupérer les écrans et résolutions de ceux-ci. Malheureusement, Qt ne permet de récupérer que les résolutions actives des écrans actifs. En faisant des recherches, nous avons trouvé que le peu de personnes voulant accéder à ces informations sous les systèmes linux, uitilisaient xrandr, ou essayaient. La librairie offre une interface plus haut niveau, mais compatible uniquement avec Windows. Au vu du manque de documentation et du peu utilisation de la librairie sur les système linux, les utilisateurs ont tendances à executer la commande dans une console et traiter sa sortie. Comme il était fastidieux d’utiliser la librairie et que ça n’était pas une priorité, nous avons opté pour le traitement de la sortie de la console comme solution temporaire.\\
Puis plus tard dans le développement, nous sommes revenus dessus et avons modifier le code pour qu’il utilise la librairie C. Afin de récupérer ces informations, il faut tout d’abords ouvrir une connexion avec le serveur gérant les différent écrans. Puis récupérer l’écran virtuel "screen", qui contient les informations des différentes fenêtres observant cet écran virtuel. Grâce à "screen" et ses informations, nous pouvons déterminer les sorties vidéo présentes et leurs résolution. De plus lorsqu’une sortie vidéo n’est pas connectée, elle possède une liste vide de résolution.
-\subsection{ProjectionGui}
+\subsection*{ProjectionGui}
Cette étape projette un écran bleu dans la sortie sélectionnée à l’étape MonitorGui. Grâce à l’aperçu de la caméra en couleur, l’utilisateur peut ajuster la position de la caméra, sa rotation, l’affichage du vidéoprojecteur et sa nettée. Il est important que la caméra soit perpendiculaire au plan au-dessus du bac à sable.
-\subsection{CameraFocusGui}
+\subsection*{CameraFocusGui}
Cette étape permet d’ajuster les paramètres de traitement d’image, afin d’améliorer la détection de notre cible. Cela nous sera utile lors de la procédure de localisation du vidéoprojecteur. Notre interface ressemble à ceci :
\begin{figure}[H]
\centering
@@ -305,11 +305,11 @@ Puis nous avons les paramètres liés à la fonction HoughCircles d’OpenCV :
\item Maximum circle radois... : Taille maximum du rayon du cercle lors de la détection
\end{itemize}
Finalement nous avons la checkbox "Unrestricted", actuellement, les valeurs sont bloquées à un interval de valeur raisonnable pour la majorité des cas. Mais si une des échelles ne convient pas à l’utilisateur, il peut cocher "Unrestricted" afin d’avoir le choix complet sur ses valeur dans la limite de la théorie.
-\subsection{CroppingMaskGui}
+\subsection*{CroppingMaskGui}
Cette étape permet à l’utilisateur de définir le masque de découpage de la caméra. Cette classe utilise la classe MaskEdit, elle nous permet de dessiner le masque de découpage de l’utilisateur sur le flux vidéo de la caméra. Elle est nécessaire, car Qt ne fournit pas d’évenement de dessin, le seul disponible étant celui exécutée à l’apparition de l’élément et dessine donc tout l’élément. Nous avons donc créer un composant affichant uniquement l’image de la caméra avec le masque tracer par dessus.\\
Durant cette étape, l’utilisateur peut modifier la position des coins du masque en les attrapant et déplaçant.\\
Lors de la validation, la rotation du masque afin de le redresser est appliqué autour du coin supérieur gauche, et la matrice de rotation sauvegardée est basé sur la rotation centrée au pixel haut gauche de l’image.
-\subsection{BeamerLocationGui}
+\subsection*{BeamerLocationGui}
Cette étape est celle où déterminons la position du vidéoprojecteur. Pour ce faire, l’application est basé sur la routine énoncé dans Beamer de SandboxSetup. L’application va laisser tourner dans un autre thread l’affichage et le traitement d’image de la photo capturée par la caméra, et ainsi laisser le thread principale s’occuper de valider un point lorsque l’utilisateur clique sur le bouton "Lock".
\\
Dans le thread secondaire, nous suivons cette démarche :
@@ -328,5 +328,5 @@ Dans le thread principal, nous avons la méthode de validation d’un point :
\item fini la routine s’il y a assez de droite
\item approxime la position du vidéoprojecteur à partir des droites estimées
\end{itemize}
-\subsection{SaveConfigGui}
+\subsection*{SaveConfigGui}
Cette dernière étape sauvegarde la configuration actuelle dans un fichier de configuration à l’endroit où l’appplication est exécutée. Elle affiche un message indiquant si la configuration a bien été sauvé.
diff --git a/memoire/chapters/content/intro.tex b/memoire/chapters/content/intro.tex
index e5e4be69326f6cd5b566e562180e5d9d67025d81..2324f0a6f99b93454b26d3272e3ce94c21e0bfc5 100644
--- a/memoire/chapters/content/intro.tex
+++ b/memoire/chapters/content/intro.tex
@@ -1,13 +1,37 @@
% !TeX spellcheck = fr_FR
\chapter{Introduction}
-\addcontentsline{toc}{chapter}{Introduction} % Adding toc entry
-
-Produire une maquette en tant qu'architecte ou paysagiste a un coût en ressources et en temps. C'est pourquoi il est fastidieux de modifier une maquette une fois contrsuite.
-Afin de palier à ce problème, HEPIA c'est inspiré d'un projet permettant de faire de la réalité augmenté basé sur un bac à sable. Dans le but de reproduite ce projet, HEPIA a installé une infrastructure similaire permettant cette réalité augmenté.
-Mais pour faire fonctionner le bac correctement, il faut une libraire permettant de l'exploiter. Hors, le projet d'origine n'en dispose d'aucune, le rendant complexe et peu flexible.
-\\
-\\
-Un prototype de libraire avait été fait par l'étudiant précédent impliqué dans ce projet. Son but était de permettre la création de diverse application intéragissant avec le bac à sable. Mais comme il s'agissait d'une "proof of concept", certains points du projet ne correspondaient pas à ce qu'on attendait de la librairie, elle méritait donc une refonte. Durant le processus, nous avons remarqué que les données de configuration nécessaires au bon fonctionnement de la libraire méritaient une saisie facilité pour l'utilisateur et une persistance, afin d'éviter de configurer la librairie à chaque utilisation. Une fois la librairie stable, il a fallu améliorer les performances de la librairie pour lui permettre d'être plus réactive.
-\\
-\\
-Tout d'abord, nous verrons ce qui constitue l'infrastructure nécessaire au projet. Puis nous verrons un comparatif avec ce qui était présent auparavant et les besoins de la nouvelle librairie. Suivi des fonctionnalités de chaque parties du projet et de l'architecture logicielle. Vous aurez ainsi une bonne vue globale du projet. Ensuite nous verrons les différentes technologies et outils utilisés dans le projet. Puis la conception et l'implémentation avec plus de détails sur l'application de configuration et une partie "application utilisateur", où tout deux utilisent la librairie. Enfin nous terminerons par les tests liés à l'optimisation avec les résultats du projet et la conclusion.
+\section{Contexte}
+Les architectes et paysagistes doivent produire des maquettes afin de concrétiser leurs plans. Malheureusement ces maquettes basées sur divers matériaux comme le bois ou le carton, font de celles-ci des maquettes difficilement ajustable en cas de modifications souhaitées.
+\begin{figure}[H]
+ \centering
+ \includegraphics[scale=0.2]{maquetteNiveaux.jpg}
+ \caption{maquette de niveaux, \url{https://www.figurasfondo.fr/maquette-darchitecture-en-carton-gris/}}
+ \label{fig:intro_maquetteNiveaux}
+\end{figure}
+
+
+En conséquence ils doivent recommencer leur maquette à chaque modifications majeurs de leur plan. Ce manque de flexibilité lors de la moindre modification ne leur permet pas de visualiser rapidement différents plans et nécessite un travail mûrement réfléchi en amont.\\
+Cependant, un projet de bac à sable en réalité augmentée a été réalisé par l'université de Californie à Davis. Celui-ci est composé d'une caméra Microsoft Kinect 3D, d'un vidéoprojecteur et d'un bac rempli de sable. De plus, le projet propose des applications permettant l'interaction avec celui-ci, comme celle d'affichage des courbes de niveaux, ou de simulation de cours d'eau sur une topologie.\\
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[scale=0.3]{uclaSandboxWater.jpg}
+ \caption{UCLA démo bac à sable avec simulutation d'eau, \url{https://arsandbox.ucdavis.edu/}}
+ \label{fig:intro_uclaSandboxWater}
+\end{figure}
+
+
+Ainsi, grâce à ce concept, nous pourrions développer des applications plus complexes, qui serviraient d'outils de modélisation aux architectes et paysagistes.
+
+
+
+\section{Problématique}
+Bien que l'université de Californie à Davis propose ce projet, il est impossible en l'état de développer d'autres applications basées sur celui-ci, car le projet fournit directement les applications. Le but étant d'utiliser le bac à sable, afin de créer des applications pouvant répondre aux besoins des architectes et paysagistes.
+
+\section{Solution envisagée et objectifs}
+Afin de pouvoir réaliser ces applications, il faudra tout d'abord réaliser une librairie permettant l'utilisation de l'infrastructure mise en place. De plus, comme chaque installation peu légèrement différer, une application de calibration sera nécessaire, afin de faciliter sa configuration.
+
+
+\section{Résumé du travail réalisé, méthodologie et annonce du plan du rapport}
+Lors de ce projet, nous avons fait une refonte de la librairie, afin de fournir une librairie utilisateur, qui sera utilisée lors du développement d'applications utilisant le bac de réalité augmentée, ainsi qu'une librairie de calibration permettant la création d'application de calibration du bac. Grâce à cette librairie de calibration, nous avons pu développer une application permettant la configuration du bac, ainsi que la sauvegarde de cette configuration dans un fichier afin qu'elle soit persistante.
+Dans ce document, nous allons voir tout d'abord à quoi ressemble le bac de réalité augmentée, puis les problématiques géométriques liées à l'utilisation de l'infrastructure, suivi d'une brève comparaison avec d'autres projets similaires. Puis nous verrons les besoins du projet, l'architecture global de notre solution et les technologies utilisées pour y parvenir. Finalement nous verrons la conception et implémentation détaillés du projet, ainsi que les tests et résultat avant de finir par notre conclusion.
diff --git a/memoire/figures/ARSandboxLayout.jpg b/memoire/figures/ARSandboxLayout.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..abb2164216ae9005f32c2ec417745147e4d56eff
Binary files /dev/null and b/memoire/figures/ARSandboxLayout.jpg differ
diff --git a/memoire/figures/adjust_pixel.jpg b/memoire/figures/adjust_pixel.jpg
index 7478a841a741592c06a4e74c46e59e93ef7dd42c..effa980bb74f6370f47e78d219edc25da1f7b20d 100644
Binary files a/memoire/figures/adjust_pixel.jpg and b/memoire/figures/adjust_pixel.jpg differ
diff --git a/memoire/figures/diagram_sequence_sandbox.jpg b/memoire/figures/diagram_sequence_sandbox.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..ed41dd85aeb55381dbcbc1bc32ab063cc9ffa86f
Binary files /dev/null and b/memoire/figures/diagram_sequence_sandbox.jpg differ
diff --git a/memoire/figures/diagram_sequence_sandbox_setup.jpg b/memoire/figures/diagram_sequence_sandbox_setup.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..72d69beb50b76bb8b6d54549efe95be4f839d6a6
Binary files /dev/null and b/memoire/figures/diagram_sequence_sandbox_setup.jpg differ
diff --git a/memoire/figures/maquetteNiveaux.jpg b/memoire/figures/maquetteNiveaux.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..d26525326f3962e3726a5591f2aecc12575bb716
Binary files /dev/null and b/memoire/figures/maquetteNiveaux.jpg differ
diff --git a/memoire/figures/uclaSandboxWater.jpg b/memoire/figures/uclaSandboxWater.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..7534d293d7bbb973455cfb36fc856e91b6b7de16
Binary files /dev/null and b/memoire/figures/uclaSandboxWater.jpg differ