avancement rapport

code/docker-compose.yaml

@@ -72,18 +72,18 @@ services:
     ports:
       - 80:80
 
-  #Backend de la borne : scripts pythons de reconaissances video et audio
+  #Backend de la borne : scripts pythons de reconnaissances video et audio
   #Envoient les infos a l'interface de la borne par websocket pour mettre a jour l'interface rapidement
   #Met a jour les avis en faisant des requêtes a l'API
-  backend_reconaissance:
-    build: ./backend_reconaissance
-    container_name: backend_reconaissance
+  backend_reconnaissance:
+    build: ./backend_reconnaissance
+    container_name: backend_reconnaissance
     restart: always
     devices:
       - /dev/video3:/dev/video0
     environment:
       - PORT=5000
-      - HOST=backend_reconaissance
+      - HOST=backend_reconnaissance
     ports:
       #Ce container est le serveur websocker dont le client est l'interface de la borne qui tourne dans le navigateur
       - 5000:5000

docs/rapports_pan2/module_hardware/benchmark/sysbench_in_docker.txt

@@ -1,68 +0,0 @@
-sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)
-
-Running the test with following options:
-Number of threads: 1
-Initializing random number generator from current time
-
-
-Prime numbers limit: 10000
-
-Initializing worker threads...
-
-Threads started!
-
-CPU speed:
-    events per second:   447.84
-
-General statistics:
-    total time:                          10.0008s
-    total number of events:              4480
-
-Latency (ms):
-         min:                                    1.87
-         avg:                                    2.23
-         max:                                    9.07
-         95th percentile:                        2.52
-         sum:                                 9984.89
-
-Threads fairness:
-    events (avg/stddev):           4480.0000/0.00
-    execution time (avg/stddev):   9.9849/0.00
-
-sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)
-
-Running the test with following options:
-Number of threads: 1
-Initializing random number generator from current time
-
-
-Running memory speed test with the following options:
-  block size: 1KiB
-  total size: 102400MiB
-  operation: write
-  scope: global
-
-Initializing worker threads...
-
-Threads started!
-
-Total operations: 20427874 (2042176.33 per second)
-
-19949.10 MiB transferred (1994.31 MiB/sec)
-
-
-General statistics:
-    total time:                          10.0002s
-    total number of events:              20427874
-
-Latency (ms):
-         min:                                    0.00
-         avg:                                    0.00
-         max:                                   11.07
-         95th percentile:                        0.00
-         sum:                                 5572.98
-
-Threads fairness:
-    events (avg/stddev):           20427874.0000/0.00
-    execution time (avg/stddev):   5.5730/0.00
-

docs/rapports_pan2/module_hardware/benchmark/sysbench_in_system.txt

@@ -1,68 +0,0 @@
-sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
-
-Running the test with following options:
-Number of threads: 1
-Initializing random number generator from current time
-
-
-Prime numbers limit: 10000
-
-Initializing worker threads...
-
-Threads started!
-
-CPU speed:
-    events per second:   523.38
-
-General statistics:
-    total time:                          10.0011s
-    total number of events:              5236
-
-Latency (ms):
-         min:                                    1.62
-         avg:                                    1.91
-         max:                                    7.00
-         95th percentile:                        2.18
-         sum:                                 9983.20
-
-Threads fairness:
-    events (avg/stddev):           5236.0000/0.00
-    execution time (avg/stddev):   9.9832/0.00
-
-sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
-
-Running the test with following options:
-Number of threads: 1
-Initializing random number generator from current time
-
-
-Running memory speed test with the following options:
-  block size: 1KiB
-  total size: 102400MiB
-  operation: write
-  scope: global
-
-Initializing worker threads...
-
-Threads started!
-
-Total operations: 24781447 (2477208.81 per second)
-
-24200.63 MiB transferred (2419.15 MiB/sec)
-
-
-General statistics:
-    total time:                          10.0001s
-    total number of events:              24781447
-
-Latency (ms):
-         min:                                    0.00
-         avg:                                    0.00
-         max:                                   23.98
-         95th percentile:                        0.00
-         sum:                                 5178.54
-
-Threads fairness:
-    events (avg/stddev):           24781447.0000/0.00
-    execution time (avg/stddev):   5.1785/0.00
-

docs/rapports_pan2/module_hardware/rapport.md

@@ -3,15 +3,58 @@
 * Impact de l'utilisation de docker
     * 
 * Création d'un docker compose avec les services dont on aura besoin de faire tourner simultanément
+    * Camera : multiple résolution / FPS possibles => 640x480 => fluide mais bcp de bruit en basse luminosité
     * RQ : on a pas mis la reco audio, jsute reco d'image parce que les 2 ne tourneront pas en même temps et reco image >> reco audio en ressources
     * 30fps pour la camera en 640x480 pour le stream sur le navigateur
     * Detection meidapipehands et communication des résultats avec le navigateur a 15fps
     * autres UI web sont tjr utilisables : 5ms de latence pour un GET sur l'api 
-    * utilisation moyenne cpu 270% (sur 400%) : laisse peu de marge 
+    * utilisation moyenne cpu 250% (sur 400%) : laisse peu de marge 
         * Reco video : 70% CPU
         * firefox : 70-80% CPU
     * RAM : ~2Go/4Go utilisé
         * mysql : 10%
         * firefox : 10%
     * Températures a priori OK : mais a voir comment ça se comporte dans un env fermé
-    * CCL : performances de la borne sont justes : possibilité de downgrade la qualité de la video pour aller plus vite, possibilité d'heberger la BDD, api et interfaces web sur un autre serveur => moins sécure mais plus de perfs (mysql prend 10% du cpu)
+    * CCL : performances de la borne sont justes : possibilité de downgrade la qualité de la video pour aller plus vite, possibilité d'heberger la BDD, api et interfaces web sur un autre serveur => moins sécure mais plus de perfs (mysql prend 10% du cpu)
+
+# 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.
+
+* **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">
+        * 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
+
+## 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.)
+
+## 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`
+* **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.
+
+### Résultats
+
+
+## Impact de l'utilisation de Docker
+
+