Intelligence embarque IMA5 2022/2023 G6
Sommaire
Vérification de l'orientation des objets sur ligne de production
Fichier:Présentation IE GP6.pdf
Installations
NanoEdgeAIStudio :
- Extraire les archives control et data.
- Executer la commande :
apt-get update -qy && apt-get -y install procps libnss3
- Dans le dossier data/opt/NanoEdge AI Studio executer nanoedgeiastudio (si nécessaire, ajouter l'option --no-sandbox)
- Insérer la license reçue par mail
- Ajouter le proxy de Polytech (host : https://proxy.polytech-lille.fr ; post : 3128 ; ID et mdp personels de polytech), tester la connexion et valider.
Description
Sur une ligne de production, l'orientation des objets transportés doit être maitrisée afin de faciliter le traitement, l'emballage ou le transport de ceux-ci. Notre produit permetterait de vérifier l'orientation des objets transportés sur un tapis roulant afin d'informer de toute divergeance non négligeable sur celle-ci afin que l'objet puisse être repositionné.
La vérification pourra se faire sur objet immobile ou bien alors que le tapis est en marche.
Notre système utilisera donc le machine learning proposé par STMicroelectronics avec le logiciel STM32 NanoEdgeAIStudio afin de vérifier l'orientation de l'objet circulant sur le tapis roulant. Nous réaliserons plusieurs mesures dans un cas "correcte" afin d'entraîner l'algorithme, qui pourra par la suite déterminer les cas "défaillant" des cas "correctes".
Ressources
Matériel
Pour réaliser un prototype permettant de vérifier la faisabilité du système, nous disposons de :
- Un microcontrôleur STM32F401RE
- Une carte d'extansion X-NUCLEO-53L5A1' embarquant un capteur TOF VL53L5CX
Logiciel
Nous programmerons le code embarqué à l'aide des logiciels :
- STM32CubeIDE
- STM32 NanoEdgeIAStudio
Réalisation
Récupération des informations de distances
Le capteur TOF récupére des informations sur une matrice de 8x8. Un projet Stm32Cube nous à été fournie permettant de récupérer les informations de distances sur chaque point entre 200mm et 600mm.
- Nous importons ce projet (via le fichier de configuration .ioc), puis nous modiffions le build configuration -> Set Active -> Release, et enfin nous compilons le projet.
- Nous observons les données récupérés via le port série sur minicom après avoir configuré le port correctement (Serial Device : /dev/ttyACM0 ; BPS/Par/Bits : 460800 8N1 ; Hardware Flow Control : No)
- Nous observons que l'affichage des données est illisible, nous modifions donc le code afin de corriger cela (ajouter un \r pour chaque \n dans le fichier X-CUBE-TOF1/App/app_x-cube-tof1.c) et pour afficher un tableau 8x8
Création de l'IA
Notre système lira les informations transmises via liaison série. Afin de faciliter la lecture des données pour l'apprentissage et la détection d'anomalies, il est nécessaire de choir le format dans lequel les données seront transférées. Nous choisissons de transférer les 64 données sur une seule ligne, séparées de point-virgules :
D0;D1;D2;D3; . . . . . . ;D61;D62;D63
Tests
Conception de la maquette de tests
Afin de réaliser nos mesures cohérentes, nous devons nous assurer que celles-ci soit réalisées dans les mêmes conditions. Nous allons fixer notre capteur de manière à ce qu'il regarde vers le bas. Nous ferons défiler un objet sous le capteur à vitesse constante. Nous devons nous assurer que la distance entre le capteur et l'objet soit quasiment similaire entre chaque mesure.
L'objet à observer sera placé sur une plateforme amovible (une feuille), que nous pousserons afin de faire défiler l'objet sous le capteur. Nous réaliserons des mesure pour l'objet bien placé et d'autre pour l'objet mal orienté.
Réalisation des tests
Dans un premier temps, nous allons essayer de différencier deux orientations distinctes : horizontale ou verticale. Nous avons placé le capteur à une distance d'environ 15cm au dessus de l'objet à observer, et avons réalisé 150 mesures de chaques cas.
Après cela nous avons réalisé un premier Benchmark avant de vérifier la fiabilité des résultats. Nous pouvons voir que sur le Benchmark nous atteignons une précision de 100%.
Nous avons alors observé que l'émulation en temps réel ne fonctionnait pas, alors que l'émulation utilisant les mêmes données écrites dans un fichier fonctionnait. Après avoir cherché une solution, nous avons compris que dans le cas de l'émulation en temps réel (via port série), le délimiteur utilisé par défaut pour séparer chaque valeur est ESPACE, tandis que nous utilisions le point-virgule.
Lors de l'émulation, nous avons observé que le logiciel est capable de différencier les deux cas, mais présente une imprécision non négligeable. En effet, une très légère modification de l'emplacement ou de l'orientation entraine de grosses incertitudes sur la différenciation.
Par la suite nous avons réalisé la même expérience en augmentant la distance entre le capteur et l'objet (environ 30 cm). Nous avons également réalisé 150 mesures par cas, puis nous avons entrainé l'algorithme via le Benchmark.
Lors de la création du Benchmark nous observons cette fois ci une précision de 84%.
Nous avons ensuite vérifier la fiabilité du modèle lors de l'émulation, et nous avons remarqué que l'emplacement était encore plus importante. Cela à entrainé de nombreuses erreurs de mesures, et les résultats n'étaient pas satisfaisants.
Enfin, Nous avons essayé de réaliser un système permettant d'indiquer si l'objet est correctement orienté. Nous précisons donc deux classes : une première classe pour le cas "correct" (200 mesures) et une seconde classe pour tous les cas "mauvais" (500 mesures dans différentes configurations).
Nous avons réalisé le Benchmark qui nous proposait une solution ayant une précision de 87%.
Nous avons réalisé l'émulation pour ce cas également, en observant plusieurs cas "mauvais".
Voici quelques exemples de cas carractérisés comme "mauvais" :
Les résultats de l'émulation sont concluants dans la mesure ou le système est capable de dire sans erreur s'il s'agit du cas "correct", cependant pour les différentes "mauvaises" dispositions, il aura plus ou moins d'erreur. Ainsi, le cas "debout" était caractérisé comme "mauvais" de manière satisfaisantes, pour le cas "horizontal" le taux d'erreur était plus élevé mais restait correct, alors que le cas "oblique" donné des résultats non satisfaisants (environ 50% "correct", 50% "mauvais").
Voici les résultats de l'émulation sur une centaine de mesures pour les cas "correct" et "horizontal" :
Cependant, un point que nous avons relevé à nouveau concerne la sensibilité du système quant à la position de l'objet. En effet, le moindre écart de l'objet de mesure dans le cas "correct" fera que la lecture sera considérée "mauvaise".
Une solution pour palier à ce problème serait de prendre un plus grand nombre de mesures pour plusieurs positions autours de la position centrale.
Pour la séance suivante nous avons réalisé une maquette pour le support du capteur TOF et la position de l'objet à scanner.
Avec cette configuration, nous avons choisi de réaliser un nouveau modèle "Correct VS Mauvais" car il s'agissait du modèle ayant obtenu les meilleurs résultats à présent.
Nous avons cette fois ci réalisé un plus grand nombre de mesures en faisant varier la position de l'objet afin d'avoir de la flexibilité quant a la position de l'objet. Nous avons réalisé 500 mesures pour le cas "Correct", 100 par position en la faisant varier légèrement et en déplaçant l'objet lentement selon l'axe, et 2000 mesures pour les cas "Mauvais", 500 mesures par orientation (horizontale, obliques, normale au support) dans les mêmes conditions que précédemment.
Avec la réalisation du Benchmark, nous obtenons une précision annoncée de 81%.
Lors de l'émulation, nous nous rendons compte que le modèle est un peut plus performant, mais nous avons toujours des imprécision. Nous observons que le modèle n'a pas trop de difficultés à reconnaître un cas "Mauvais" mais à plus de mal pour les cas "Corrects". Cela est dû soit à la différence dans le nombre de mesures effectuées pour chaque classe, soit aux évolution de l'environnement de mesure. En effet, nous avons remarqué que le système pouvais parfois détecter la main qui déplace la feuille sur laquelle l'objet est placé.
Nous avons tout de même choisi d'essayer d'implémenter ce modèle dans le microcontrôleur.
Implémentation sur Microcontrôleur
Dans un premier temps, nous avons validé notre modèle dans l'onglet validation, on nous avons observé que les cas "Correct" sont correctement identifier à 72% alors que les cas "Mauvais" le sont à 90%, ce qui confirme le fait que le modèle à plus de facilités à identifier les cas "Mauvais".
Nous constatons également que le modèle est assez régulier, présentant une variance de 5.5% sur 6 simulations, avec un delta entre le min et le max de 13%.
Ensuite, pour inclure le modèle dans le microcontrôleur, nous téléchargeons l'archive contenant les deux fichiers header et la librairie libneai.a sur l'onglet déploiement. Nous extrayons l'archive et plaçons les fichiers header dans un dossier appelé include et la librairie dans un fichier nommé lib, tous deux situés dans le dossier extrait de l'archive. nous incluons ces dossiers dans les chemins parcourus par STM32CubeIDE afin de chercher les fichiers nécessaires au programme.
Nous modifions par la suite notre code en ajoutant les lignes de code indiquées dans l'onglet déploiement (includes, fonction fill_buffer, variables nécessaires ...). Dans la fonction écrivant les 64 données sur une seule ligne que nous utilisions précédemment, nous plaçons à présent les 64 données dans le tableau d'entrée de la fonction de caractérisation.
Le tableau de sortie nous indique pour chaque mesure la probabilité pour chaque cas (il s'agit donc d'un tableau contenant 2 valeurs). Nous envoyons ces deux valeurs sur le port série, cependant nous observons que celles ci sont fixes. Ce problème n'a pas pus être résolu à temps.
