Comptage de noix à grande vitesse basé sur la vision par ordinateur – Centre de données| Informatique en nuage | Centre de données

“Je ressens le besoin, le besoin de vitesse”, une citation célèbre du film hollywoodien “Top Gun” sonne vrai pour la plupart des ingénieurs. Nous nous efforçons de rendre les algorithmes, les logiciels et le matériel existants de plus en plus rapides. Cet article de blog explique la conception d’une de ces solutions à haute vitesse et haute précision : une solution basée sur la vision par ordinateur pour le comptage de pièces industrielles. Ces solutions industrielles automatisées sont de plus en plus demandées dans les usines du monde entier, alors qu’elles luttent pour réduire les coûts de main-d’œuvre et augmenter la productivité de leurs chaînes de montage.

il a été travaillé avec une société de capteurs d’images de premier plan pour démontrer les capacités de leur capteur haute résolution 90 FPS dans un cas d’utilisation industrielle pour le comptage de pièces, en particulier le comptage de noix.

Calculs :

• Vitesse de capture de la caméra – 90 FPS. 90 images par seconde se traduisent par 11 ms. Ainsi, toutes les opérations allant de la capture d’image à l’affichage qui devaient être configurées pour le comptage des noix devaient être exécutées en seulement 11 ms. Si la latence totale du système de bout en bout dépasse 11 ms, nous perdons les images car la caméra va toujours écrire de nouvelles images à cette vitesse.

Énoncé du problème pour la construction de la solution de comptage de noix

Pour démontrer les performances de ce capteur d’image à 90FPS, des objets en mouvement rapide ont dû être utilisés. La caméra peut alors capturer des images de ces objets en mouvement rapide et le logiciel peut traiter ces images. La simulation de telles vitesses élevées a été rendue possible en construisant un système rotatif au lieu d’un système linéaire.

Une plate-forme rotative à grande vitesse a été créée comme le montre la figure 1. Elle avait 12 secteurs, nommés par ordre alphabétique de A à L. Chaque secteur a plusieurs fentes dans lesquelles un nombre variable d’écrous peut être inséré par l’utilisateur. Lorsque le disque commence à tourner, la caméra capture les images, l’algorithme compte les noix dans chaque secteur et le décompte final s’affiche à l’écran. Cela semble simple ? Ce n’est pas le cas en réalité.

Défis rencontrés

Contraintes d’interface

Étant donné que le pipeline de capture d’images de la caméra était encore en cours de développement, il a été décidé d’utiliser une carte basée sur FPGA comme plate-forme de développement. En raison de la prise en charge limitée des frameworks d’apprentissage profond actuels (lire : TF, Keras, Torch) sur la plate-forme spécifique, il a été décidé d’adopter une approche uniquement logicielle pour tous les composants du pipeline après la capture d’images. En d’autres termes, le calcul et l’affichage étaient gérés uniquement par un logiciel exécuté sur un processeur intégré standard plutôt que par des accélérateurs matériels. Plus précisément, une approche de traitement d’image classique pour garder les exigences de calcul légères a été choisie.

Le pipeline consistait à recadrer le segment en premier. Décider ensuite de la couleur dominante du secteur. Vient ensuite la recherche du contour et finalement le comptage des écrous. Enfin, le nombre de noix est affiché à côté du nom du secteur.

Problèmes logiciels

Copie mémoire

L’appareil disposait d’un pipeline de capteurs qui vidait les images en continu dans la mémoire DDR partagée. La mémoire partagée a une adresse physique. Et comme des composants comme openCV étaient utilisés pour le traitement des images et les fonctionnalités d’affichage de base pour la sortie, il fallait un système d’exploitation. Le système d’exploitation choisi était Petelinux. Il y a eu de nombreux cas où python faisait une copie des données. Ce temps de copie lui-même dépassait la latence de pipeline acceptable. Pour résoudre ce problème, chaque ligne du code a été revue et réécrite dans certains cas. Pour éviter la copie de la mémoire, la fonctionnalité de mappage de mémoire a été utilisée pour mapper l’adresse physique de la mémoire partagée à l’adresse virtuelle.

Bibliothèques OpenCV

La fonction de redimensionnement d’OpenCV peut surprendre en travaillant sur du code de bas niveau. Les utilisateurs expérimentés peuvent comprendre la syntaxe de base comme output_image=resize(input_image, dimensions). Dans cette situation, une copie inhérente de input_image était créée. Pour résoudre ce problème, notre fonction de redimensionnement d’image personnalisée basée sur l’échantillonnage a été écrite. C’était une méthode avec perte, mais fonctionnait parfaitement pour l’application donnée.

Problèmes au niveau du système

Étalonnage de position

Afin de détecter correctement un secteur, l’utilisateur doit placer le disque rotatif précisément sous la caméra de telle sorte que l’axe principal de la caméra (une ligne imaginaire passant par le centre de l’objectif) coïncide avec le centre du cercle rouge illustré à la Fig. 1 Cela s’est avéré être un défi pratique. il a été constaté que l’erreur humaine dans un (mauvais déplacement vertical et b) disque sortant du cadre.

Afin de résoudre ce problème, un mécanisme d’étalonnage a été créé. En se référant au cercle rouge central, l’algorithme d’étalonnage a été conçu pour gérer les erreurs dans la position de montage. Les erreurs de montage vertical ont été évitées en mesurant la zone de pixels du cercle central et en la limitant dans une plage acceptable. Des erreurs de position mal alignées ont été signalées en faisant référence à un rectangle imaginaire dans une image. Les positions détectées automatiquement seraient recouvertes de marqueurs de couleur via une interface utilisateur conviviale sur un écran permettant de fermer la boucle d’étalonnage.

Éclairage

Les algorithmes compatibles avec l’IA peuvent bien gérer les changements de luminosité. Mais les méthodes classiques de traitement d’images utilisées ici manquent de ce niveau de robustesse. Bien sûr, il est possible d’implémenter des méthodes globales comme l’égalisation d’histogrammes, etc., sur chaque trame, mais encore une fois, cela augmenterait le temps de traitement.

Il existe une énorme différence entre les images capturées dans un environnement bien éclairé pendant la journée par rapport à un environnement faiblement éclairé pendant la nuit. De plus, l’éclairage artificiel n’aide pas beaucoup car il s’agit d’une capture d’image à grande vitesse. Il faut de plus en plus d’éclairage pour une capture à fréquence d’images plus élevée.

Le problème a été résolu par un étalonnage basé sur l’éclairage. Le cercle rouge central a été analysé dans différentes conditions d’éclairage et des plages favorables de ses valeurs HSV ont été calibrées. Dans le cas où l’éclairage environnant est plus faible ou plus lumineux que la plage attendue, un mécanisme d’affichage d’erreur a été ajouté au système. En regardant l’erreur sur le terminal, l’utilisateur peut composer vers le haut ou vers le bas les commandes d’éclairage intégrées dans le système rotatif, au réglage approprié.

Conclusion

En conclusion, j’ai souhaité partager quelques apprentissages avec tous les praticiens du traitement d’images, de la vision par ordinateur et du deep learning. En tant qu’ingénieurs, nous développons et expérimentons plusieurs fois dans l’environnement sandbox. De bonnes ressources de calcul sont disponibles la plupart du temps sans aucune contrainte de latence. Jouer avec un système réel est vraiment intéressant et donne un immense apprentissage. Les défis sont réels et il faut penser à un niveau de base pour les relever. Dans ce cas de construction d’une solution de comptage de noix, les bases de linux, C, python, openCV, embarqué, traitement d’image, vision par ordinateur et étalonnage de caméra sur un seul projet ont été déployées.

Ce blog est apparu à l’origine sur la page Blog d’Ignitarium.com.