IMA3/IMA4 2019/2021 P6+

Présentation générale

Description

Un boitier Raspberry Pi et deux cameras permettent de monitorer le positionnement d'une fibre optique avec précision.

Objectifs

L'objectif de ce projet est de redévelopper une interface permettant de visualiser simultanément les images de deux caméras. L'interface de visualisation actuelle présente de nombreux défauts. Les deux caméras sont connectées à une Raspberry Pi grâce à un multiplexeur sur le bus CSI.

Préparation du projet

Choix techniques : matériel et logiciel

Multiplexeur de caméra : https://www.arducam.com/product/multi-camera-v2-1-adapter-raspberry-pi/ Dépôt git : https://github.com/ArduCAM/RaspberryPi/tree/master/Multi_Camera_Adapter/Multi_Adapter_Board_4Channel

Liste des tâches à effectuer

• Installation de Raspberry OS
• Installation software caméra multiplexer
• Compréhension du logiciel constructeur
• Recherche d'un bottleneck dans le programme
• Etude des technologies disponibles pour redévelopper l'interface

Réalisation du Projet

Semaine 1

Installation de Raspberry OS Installation du script fourni avec la carte => Suivre le git, attention à activer la caméra (SPI) et le bus I2C dans le raspi-config.

Le logiciel constructeur fonctionne. Problème :

• Impossible de fermer la fenêtre sans kill le programme.
• Faible fps (~6)
• Impossible de redimensionner

Fonctionnement du logiciel de la carte multiplexeur : Le choix de la camera relié au bus SPI se fait commande I2C. Le logiciel commence par l'analyse des caméras connectées (1 à 4) en interrogeant les capteurs sur la carte à travers le bus I2C. Pour afficher les deux caméras simultanément le logiciel va switch très rapidement entre les caméras détecté et appeler l'affichage OpenCV pour chaque caméra à chaque switch.

Toutes mes tentatives d'amélioration se sont soldées par une instabilité de l'image, que ce soit en augmentant la résolution ou en diminuant la période entre chaque switch (augmentation FPS).

Pour déterminer d'où venait le blocage j'ai décidé d'essayer une camera connecté au bus SPI sans le multiplexeur : On atteint des performances bien supérieures avec un script de lecture du flux vidéo avec un OpenCV (1440x1080 30 fps).

Le switch rapide des caméras entraine forcément une réduction des FPS mais cela n'explique pas la faible résolution imposée.

Un essais avec une seule caméra placée sur la carte multiplexeur (pas encore effectué) permettrait de déterminer si le module empêche une meilleure qualité. (Une caméra sur le module avec le code constructeur est à 6 fps)

Recherches effectuées :

• Choix de l'interface : la combinaison OpenCV pour la gestion de la vidéo et Qt pour l'interface semble tout indiqué. Je me suis donc renseigné sur le fonctionnement de ces deux bibliothèques.
• Remise à niveau en C++
• Faibles performances des caméras Raspberry pi de manière générale : Diviser l'action en deux thread différents semblerait grandement améliorer les performances ? (Sources peu fiables : Forum et Blogs personnels)

Semaine 2

J' ai décidé de travailler en Python pour continuer d'effectuer différents tests plus simplements sur le materiel, dans l'idée que si un developpement C++ est necessaire par la suite, la retranscription du code reste possible.

J' ai donc crée dans le dossier git /python différents scripts permettant de faire fonctionner les caméras sur le module multiplexeur. On obtient des performances similaires à celles du code constructeur ( ~6 fps + latence)

Le changement de résolution semble n'avoir que très peu d'impact sur les performances. Pour avoir des images stables on est obligé de forcer une baisse des FPS, pour laisser le temps au module de changer de caméra. Il semblerait donc que ce changement de caméra soit le goulot d'étranglement du système.

Afin de vérifier qu'il ne s'agit pas d'un problème de puissance de calcul je vais essayer de diviser les opérations en différents threads. Si il s'agit d'un problème de puissance sur le GPU alors un essai sur Raspberry Pi 4 pourrait obtenir de bien meilleures performances. --> Les tests sur raspberry pi 4 n'ont pas donner resusltat significativement meilleur.

J'ai ensuite chercher à confirme l'hypothèse que le temps de changement de camera est trop lent pour obtenir de belles performances pour l'affichage des deux caméras simultanement : Pour cela j'ai crée un programme nommé meaure_min_swap_time.py, celui-ci permet de faire varier le temps d'attente entre chaque changement de camera avant d'afficher l'image. Ce pourrait permettre de nous donner une idée plus precise de la fréquence maximale pour maintenir une stabilité d'image.

Documents Rendus

lien gitlab