public/Telereview
1
0
Fork 0
mirror of https://git.roussel.pro/telecom-paris/pact.git synced 2026-02-09 10:30:17 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

avancement rapport

Browse Source
This commit is contained in:
Quentin Roussel
2023-01-14 20:10:56 +01:00
parent ff8d4315c7
commit 4e98101417
14 changed files with 50 additions and 143 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
docs/rapports_pan2/module_hardware/rapport.md
View File

@@ -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