Telereview/docs/rapports_pan2/module_hardware/rapport.md

• Réinstallation de debian avec LXDE comme DE = plus léger
• Déinstallation des programmes de bases innutiles
• 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 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)

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

En réglant la camera a 640x480@30fps, aucune perte d'image n'est observée dans le retour vidéo dans firefox.

Mediapipe est capable d'analyser l'image de la camera et de communiquer les résultats à l'interface web 15 fois par seconde en moyenne

Ce taux de rafraichissement est suffisant pour que l'application paraisse réactive à l'utilisateur.

Pendant ce temps l'api de traitement des avis et la base de donnée fonctionnent correctement en affichant une lattence de 8ms pour une récupération de la liste d'avis.

Pendance ce temps l'utilisation du processeur qui varie de 250 à 280% (sur 400% pour les 4 coeurs) et une utilisation de la RAM de 50% ce qui nous laisse de la marge en cas d'ajout imprévu.

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.

$ sensors
acpitz-acpi-0
Adapter: ACPI interface
temp1:        +27.8°C  (crit = +110.0°C)
temp2:        +29.8°C  (crit = +110.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +69.0°C  (high = +105.0°C, crit = +105.0°C)
Core 0:        +69.0°C  (high = +105.0°C, crit = +105.0°C)
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).

Le script permettant de faire le benchmark

sysbench --test=cpu run >>sysbench.log
sysbench --test=memory run >>sysbench.log
sysbench --test=fileio --file-test-mode=rndrw prepare
sysbench --test=fileio --file-test-mode=rndrw run >>sysbench.log
sysbench --test=fileio cleanup

Le Dockerfile du container dans lequel nous avons exectué le même script

FROM alpine:latest
RUN apk add --no-cache sysbench
WORKDIR /app
COPY benchmark_script.sh /app/benchmark_script.sh
CMD ["sh","benchmark_script.sh"]