Intelligence embarque IMA5 2022/2023 G8 : Différence entre versions

Version du 12 décembre 2022 à 11:10

Sommaire

1 Projet utilisation de l'IA pour une application embarquée

Projet utilisation de l'IA pour une application embarquée

L'objectif du projet est d'utiliser une application utilisant de l'intelligence artifielle avec des microcontroleurs STM32F401 ainsi qu'un capteur TOF X-NUCLEO-53L5A1

Idées en vrac :

reconnaissance d'objets (formes, dimensions) : par exemple boîte en carton
détection de position d'objet
IHM avec reconnaissance gestuelle (main, mouvements, doigts ...)
Détection de la fatigue en regardant les clignements des yeux.
Detection du port du casque et équipements de sécurité dans une usine.

Idée retenue : Détection du port du casque et équipements de sécurité dans une usine (lunettes de sécurités, masques...)

Installation de STM32 Cube IDE et de nanoedgeaistudio

Extraire les dossiers control et data
Executer la commande :

 apt-get update -qy && apt-get -y install procps libnss3

Configuration de STM32 Cube IDE

Configurer le réseau de manière à avoir le proxy : proxy.polytech-lille.fr avec le port 3128.
Ajouter la licence.

Téleversement du programme

Dans STM32Cube IDE, on ouvre le projet 53L5A1_ThresholdDetection.ioc et on build le project en mode release, cela génère un fichier éxecutable .elf. Enfin on fait un run pour téléverser le programme et le lancer sur la carte.

Affichage des résultats

Dans le programme fourni, il faut modifier les affichages en ajoutant des retours chariot pour pouvoir afficher correctement les valeurs sur le terminal. Ouvrir un terminal et ouvrir minicom dessus, configurer le nombre de bauds à 460800, et observer le tableau des distances.

Utilisation de nano edge ai studio

Sélectionner un capteur générique avec 64 axes pour le capteur.

Acquisition des signaux avec 4 cas possibles (port de casque, port de lunettes, port des deux, aucune protection) via le port série configuré avec le bon nombre de Bauds. Pour ce faire on a modifié le programme de base pour qu'il envoie les différentes données avec comme délimiteur une virgule. Lorsque le programme devait afficher une croix on l'a remplacé par un zéro. On essaie d'avoir un maximum de données pour que le programme soit le plus fiable possible.

Benchmarking des 4 classes de signaux, on remarque que la précision est plutôt bonne :

Emulation du benchmark. Pendant l'émulation on se rend vite compte que notre programme n'est pas précis. En effet, il détecte que l'utilisateur ne porte pas decasque alors qu'il en porte un et inversement.

Maquette

Pour la maquette nous nous sommes munis d'EPI (Équipement de protection individuelle) à savoir un casque et des lunettes de protection. Nous avons positionné le capteur à une distance fixe de l'utilisateur.

Problème

Le benchmarking fait des 4 classes de signaux, avec 100 mesures par classe, ne donne pas des résultats corrects vu que le modèle indique la présence du casque ou des lunettes même en leur absence.
Le fait de s'éloigner même de quelques centimètres du capteur fait que les résultats attendus sont erronés, le test a été refait à une distance fixe sans trop bouger.
Le modèle a vraiment du mal à identifier la différence entre le cas où l'utilisateur ne porte qu'un EPI (lunette ou casque) du cas où il en porte 2.

Solution Envisagée

Ajouter plus de mesures dans chaque signal. Cependant il a un problème lorsque'on utilise trop de mesures, lors de la création du benchmark, le pc freeze ou crash.

Les mesures ont été prises d'une distance très proche du capteur vu que la précision est un peu faible lorsqu'on s'éloigne du capteur.

Faire une classification où on ne vérifie que si l'utilisateur porte un casque ou non, puis faire un autre modèle où il ne vérifie que les lunettes.

Résultats de la nouvelle solution

Le fait de ne regarder que 2 classes améliore grandement la précision du modèle, de plus nous avons pris 150 valeurs pour les datasets pour éviter que le PC crash. En revanche même en n'ayant que 2 classes, le modèle ne parvient pas à discerner les lunettes. Cela peut être dû au fait que les lunettes ne modifient pas grandement la valeur du capteur de par leurs tailles ou du fait de leurs transparences.

Déploiement

Le déploiement du benchmark génère 2 fichiers .h et 1 fichier .a que nous rangeons dans un dossier include et lib respectivement.

@@ Ligne 58 : / Ligne 58 : @@
 *Le fait de s'éloigner même de quelques centimètres du capteur fait que les résultats attendus sont erronés, le test a été refait à une distance fixe sans trop bouger.
 *Le modèle a vraiment du mal à identifier la différence entre le cas où l'utilisateur ne porte qu'un EPI (lunette ou casque) du cas où il en porte 2.
 === Solution Envisagée ===
@@ Ligne 65 : / Ligne 66 : @@
 *Faire une classification où on ne vérifie que si l'utilisateur porte un casque ou non, puis faire un autre modèle où il ne vérifie que les lunettes.
+=== Résultats de la nouvelle solution ===
+Le fait de ne regarder que 2 classes améliore grandement la précision du modèle, de plus nous avons pris 150 valeurs pour les datasets pour éviter que le PC crash.
+En revanche même en n'ayant que 2 classes, le modèle ne parvient pas à discerner les lunettes. Cela peut être dû au fait que les lunettes ne modifient pas grandement la valeur du capteur de par leurs tailles ou du fait de leurs transparences.
+=== Déploiement ===
+Le déploiement du benchmark génère 2 fichiers .h et 1 fichier .a que nous rangeons dans un dossier include et lib respectivement.