update typo rapport

docs/rapports_pan2/module_hardware/rapport.md

@@ -1,38 +1,43 @@
 # Rapport PAN2
 
 ## Choix du hardware
-* **Ecran** (InnoLux N133HSE): Pour l'écran nous avons choisi un écran 13.3" (non tactile), nous avons estimé la taille suffisante pour un confort de lecture a distance raisonable de la borne. De plus cet écran présente un système de montage à vis qui facilitera son intégration dans la borne.
+* **Ecran** (InnoLux N133HSE): Pour l'écran nous avons choisi un écran 13.3" (non tactile), nous avons estimé la taille suffisante pour un confort de lecture à distance raisonable de la borne. De plus cet écran présente un système de montage à vis qui facilitera son intégration dans la borne.
 
 * **Camera** : Nous avions le choix entre 2 camera 
     * Une webcam Logitech c525
         * Grand choix de résolutions avec un framerate élevé par exemple 640x480@30fps, 960x720@30fps, 1920x1080@5fps
         * Mais champs de vision beaucoup trop faible pour notre application
     * Une camera de surveillance grand angle de la marque ELP
-        * Choix de résoltions restreint, mais toujours utilisable en luminosité de jour
-        <img src="img/formats_camera.png">
+        * Choix de résoltions restreint, mais utilisable dans des bonnes conditions de luminosité
+
+        <img src="img/formats_camera.png" height=250>
+
         * Champs de vision adapté a notre utilisation
         * Cette camera apporte des distortions importantes sur les bords, cela compléxifie la reconnaissance d'image.
     * Nous avons choisi la deuxième camera pour les raisons citées ci-dessus
 
 * **Ordinateur** : 
-Nous avons a notre disposition un AMD Cubi doté de 4Go de RAM, 128Go de SSD et un Intel Core i3 5005U, l'objectif du reste de ce document est d'évaluer si les performances de cet ordinateur sont suffisantes pour notre application
+Nous avons a notre disposition un AMD Cubi doté de 4Go de RAM, 128Go de SSD et un Intel Core i3 5005U. L'objectif du reste de ce document est d'évaluer si les performances de cet ordinateur sont suffisantes pour notre application.
 
 ## Choix du système d'exploitation
-Nous avons choisi d'installer debian 11, une distribution de linux relativement légère avec laquelle nous étions familiers. Pour l'environement de bureau nous avons choisi LXDE là aussi pour le minimalisme qu'il présente au vu des performances de la machine. Nous avons par la suite désinstallé tout les packets installé par défaut par LXDE dont nous n'avions pas besoin. (Par exemple les jeux, la calculatrice, etc.)
+Nous avons choisi d'installer debian 11, une distribution de linux légère avec laquelle nous étions familiers. Pour l'environement de bureau nous avons choisi LXDE là aussi pour le minimalisme qu'il présente au vu des performances de la machine. Nous avons par la suite désinstallé tout les packets installé par défaut par LXDE dont nous n'avions pas besoin. (Par exemple les jeux, la calculatrice, etc.)
 
 ## Benchmarking
 Pour évaluer la capacité du materiel à supporter la charge de notre application, nous avons executé en parallèle les applications qui seront utilisés pour le produit final ou une application aux besoins équivalents quand cela n'était pas possible. De ce fait ce benchmark n'est pas exact mais nous donnera un ordre d'idée sur les besoins de notre projet.
+
 ### Liste des modules à executer
+
 Pour ce faire nous avons mis en place un container Docker par module de notre application :
 * **db** : un serveur mysql basique pour la base de donnée
-* **phpmyadmin** : ce container n'est pas aboslument nécessaire au produit final mais permet d'administrer facilement la base de donnée
-* **review_api** : un serveur express pour servir l'api permettant de récupérer et ajouter des avis dans la base de donnée, ainsi que de calculer les statistiques. L'image de ce container est basé sur `node:lts-alpine`
+* **phpmyadmin** : l'interface phpmyadmin pour gérer la base de donnée. Ce container n'est pas absolument nécessaire au produit final mais permet d'administrer facilement la base de donnée
+* **review_api** : un serveur express pour servir l'api permettant de récupérer et ajouter des avis dans la base de donnée, ainsi que de calculer les statistiques. 
 * **interface_borne**: un serveur apache2 permettant de servir l'interface graphique de la borne. 	
 * **interface_admin**: idem pour l'interface graphique, ce serveur pourait être fusioné avec 
 **interface_borne** mais dans le cadre de ce benchmarking on les gardera séparés.
 * **backend_reconnaissance**: Ce container s'occupera de la reconnaissance audio et video de la borne. Cependant ces deux processus ne seront jamais actifs en même temps, de plus la reconnaissance d'image sera la plus couteuse en terme de puissance de calcul. C'est pour cela qu'ici nous avons uniquement utilisé mediapipe hands  (bibliothèque python de reconaissance de mains) avec une implémentation de la communication avec l'interface de la borne comme programme équivalent.
-* **video_loopback** : ce container sert à contourner un problème que nous avons rencotré avec la gestion de camera de linux. En effet un seul programme ne peux accéder au flux d'une camera a la fois. C'est pour cela que nous avons utilisé `v4l2loopback` avec `ffmpeg` pour dupliquer le flux de notre camera dans 2 cameras virtuelles.
+* **video_loopback** : ce container sert à contourner un problème que nous avons rencontré avec la gestion des camera par linux. En effet seul un programme peut accéder au flux d'une camera à la fois. C'est pour cela que nous avons utilisé `v4l2loopback` avec `ffmpeg` pour dupliquer le flux de notre camera dans 2 cameras virtuelles.
 
+En parallèle firefox est ouvert pour afficher l'interface graphique de la borne.
 ### Résultats
 En réglant la camera a 640x480@30fps, aucune perte d'image n'est observée dans le retour vidéo dans firefox.
 
@@ -52,7 +57,7 @@ Pendance ce temps l'utilisation du processeur qui varie de 250 à 280% (sur 400%
 Les processus utilisant le plus de CPU sont la reconaissance d'image (70%) et firefox pour afficher l'interface de la borne (70-80%). En cas de besoin ces valeurs pourront être diminuées au prix de la fluidité du retour vidéo.
 Pour la RAM c'est le serveur mysql (10%) et firefox (10%) qui consomment le plus.
 
-Pour ce qui est de la température, comme la borne sera dans un environement fermé, il était important de tester le bon fonctionnement du materiel dans ces conditions. Nous avons laissé tourner l'application pendant 2h dans une boite en carton fermée. Au début du test la température du processeur était de 50°C, au bout de 2h la température était montée a 70° ce qui reste assez faible pour ne pas limiter les performances du CPU.
+Pour ce qui est de la température, comme la borne sera dans un environement fermé, il était important de tester le bon fonctionnement du materiel dans ces conditions. Nous avons laissé tourner l'application pendant 2h dans une boite en carton fermée. Au début du test la température du processeur était de 50°C, au bout de 2h la température était montée a 70°C, ce qui reste assez faible pour ne pas limiter les performances du CPU.
 
 ```
 $ sensors
@@ -69,7 +74,7 @@ Core 1:        +68.0°C  (high = +105.0°C, crit = +105.0°C)
 ```
 
 ## Impact de l'utilisation de Docker
-Nous nous sommes également posé la question de l'impact de l'utilisation de docker dans les performances de notre projet. Pour mesurer cela, nous avons effectué des benchmark directement sur le système puis dans un container Docker pour mesurer la différence. nous avons utlisé sysbench pour évaluer les performances du CPU, de la RAM et du disque (écriture/lecture aléatoire).
+Nous nous sommes également posé la question de l'impact de l'utilisation de docker dans les performances de notre projet. Pour mesurer cela, nous avons effectué des benchmark directement sur le système puis dans un container Docker pour mesurer la différence. Nous avons utlisé sysbench pour évaluer les performances du CPU, de la RAM et du disque (écriture/lecture aléatoire).
 
 Le script permettant de faire le benchmark
 ```sh
@@ -81,6 +86,7 @@ sysbench --test=fileio cleanup
 ```
 
 Le Dockerfile du container dans lequel nous avons exectué le même script
+
 ```Dockerfile
 FROM alpine:latest
 RUN apk add --no-cache sysbench
@@ -95,4 +101,4 @@ Les résultats de ce test on permis de conclure que l'impact de docker était n
 
 ## Conclusion
 
-Au vues des tests effectués le materiel dont nous disposons semble adapté a notre projet. Il est cependant possible d'optimiser l'utilisation faite de l'ordinateur embarqué dans la borne en déplaçant la partie stockage et traitement des avis sur un autre serveur, pour l'instant cette possibilité n'est cependant pas envisagée par soucis de sécurité des données et par non nécessité.
+Au vu des tests effectués le materiel dont nous disposons semble adapté à notre projet. Il est cependant possible de réduire l'utilisation faite de l'ordinateur embarqué dans la borne en déplaçant la partie stockage et traitement des avis sur un autre serveur. Pour l'instant cette possibilité n'est cependant pas envisagée par soucis de sécurité des données et car elle n'est pas nécessaire.