PanoPi: système robotisé pour la réalisation de photos panoramiques

Après quelques semaines de congé parental, Alice (qui contribue par sa patience et ses siestes!) et moi sommes fiers de vous annoncer la naissance de PanoPi!

PanoPi est un système utilisant un nano-ordinateur Raspberry Pi pour contrôler des moteurs et un appareil réflexe de façon à automatiser la prise de photos destinées à être assemblées ensuite pour constituer un panorama comme celui-ci:

Voici un équivalent commercial du PanoPi: le GigaPan Epic (995$ quand même!).

PanoPi est opérationnel et servira maintenant (j’espère!) à réaliser de beaux panoramiques… et peut-être même un peu plus puisque le même système peut servir pour des « timelapse », des photos à haute dynamique (HDR) et même des gigaphotos à très haut niveau de détails (plus de 1 gigapixels!). Ce projet a été très formateur et je l’ai d’ailleurs avant tout choisi comme un prétexte pour découvrir les immenses perspectives offertes par le Raspberry Pi: un nano-ordinateur Linux complet de la taille d’une carte de crédit et vendu 35US pour sa version la plus musclée (il y en a une à 20US!!!!). Voici donc les grandes lignes de la réalisation du PanoPi et de son utilisation pour faire des panoramas.

Cahier des charges du projet:

Les principaux objectifs et les contraintes auto-imposées sont:

1. Permettre de faire pivoter l’appareil photo selon 2 axes (haut-bas et droite-gauche) passant par un point de la lentille appelé pupille d’entrée de façon à ce que les images obtenues puissent être assemblées sans erreurs de parallaxe (c’est à dire que toutes les photos semblent prises du même endroit exactement). Avec un trépied photo ordinaire, l’appareil pivote autour d’un point situé en dessous du boiter donc décalé de typiquement 5 à 15 centimètres par rapport à la pupille d’entrée. Les prises de vues sont décalées les unes par rapport aux autres donc l’image obtenue par assemblage comporte des erreurs de parallaxe: les objets proches semblent démultipliés, flous… La situation est acceptable si tous les objets sont loin (panorama de paysage) mais le problème devient flagrant en intérieur ou s’il y a un sujet en premier plan!
2. S’installer sur un trépied photo ordinaire.
3. Fonctionner avec un appareil photo de qualité (lentille etc.) et non pas une simple mini-camera (pas de diaphragme ni de mise au point). L’appareil devrait idéalement pouvoir être installé horizontalement ou bien verticalement.
4. Compact – Tous les éléments du système doivent être contenus dans le même boîtier pour éviter les fils qui s’emmêlent lorsque le boiter tourne.
5. Doit pouvoir fonctionner de façon autonome (sans être commandé via un portable ou un téléphone).
6. Coût raisonnable et possibilité de patenter le tout avec les matériaux et outils disponibles (c’est à dire pas de fraiseuse CNC ou de découpe laser de métal ou plexiglas… on en reste au banc de scie!).
7. Bien sûr, être basé sur le Raspberry pi, Linux et les logiciels open source uniquement!
8. Last but not least, pouvoir être patenté sans négliger la raison principale de mon congé parental c’est à dire en ne travaillant que pendant 2 ou 3 heures par jour, pendant les siestes d’Alice!!!!

Principe de base:

Après lecture de tutoriels Raspberry Pi (Adafruit) et inspiration à partir de projets apparentés trouvés sur le web (GigaPi, David Singleton Raspberry Pi timelapse controller, HDR photography with Raspberry Pi, PiTimeLapse), le système PanoPi a été conçu comme suit:

• Raspberry Pi modèle B+ (car c’est ce que j’avais sous la main mais tout autre Raspberry pourrait convenir, même un A+ à 20USD je crois) et d’un adaptateur wifi.
• Programmation en langage Python (ça a été une première pour moi!) à partir d’un autre ordinateur qui communique avec le Raspberry via ssh (sans fil).
• La séquence de photos à exécuter (nombre de photos, déplacements entre chacune etc.) est codée dans un fichier (CSV) indépendant lu lors de l’exécution du code python. Cela permet de prévoir plusieurs séquences différentes selon les besoins (panorama 180 ou 360 degrés etc.).
• Utilisation de 2 moteurs électriques de type pas-à-pas et de cartes « driver » spécifiques pour transformer les signaux de commande du Pi (basse puissance) en courant suffisant pour les moteurs.
• Alimentation de l’ensemble par une batterie 12V 1.5AH au plomb (durable, économique, facile à trouver et à recharger) et utilisation d’un convertisseur DC/DC pour obtenir le courant 5V requis pour le Raspberry.
• Utilisation d’un afficheur LCD (2×16 caractères) et de 5 boutons poussoirs pour naviguer dans les menus (le kit Adafruit requière 30 minutes de soudure mais il fait parfaitement l’affaire!).
• Utilisation du logiciel et des librairies gPhoto pour contrôler un appareil photo via la connexion USB. Il aurait également été possible de contrôler le déclenchement grâce à un déclencheur à distance (simple interrupteur) ou même un servomoteur appuyant physiquement sur le déclencheur de l’appareil mais gPhoto offre bien plus de possibilités telles que changer les réglages de l’appareil (vitesse, diaphragme, ISO, balance des blancs etc.), télécharger chaque photo immédiatement après déclenchement (pour analyse ou traitement automatique du résultat dans imagemagick par exemple).
• Utilisation du Canon EOS 400D Rebel XTi + 18-55mm de base (en mode grand-angle équivalent à un 28mm full-frame) pour la prise de vue… car c’est ce que j’ai sous la main! Ce dernier choix est malgré tout un peu contraignant puisqu’il s’agit de l’appareil avec lequel Marianne fait ses photos intra-orales! Je ne peux l’utiliser que pendant les fins de semaine.
• Utilisation du FANTASTIQUE logiciel open source Hugin pour automatiquement assembler les images en un panorama!

Voici un petit schéma électrique de principe:

Réalisation:

Le système est d’abord assemblé par étapes, sans soudures (mis à part le kit Adafruit pour l’afficheur LCD), sur une plaquette de type « breadboard » qui permet de tester l’électronique, la première ébauche de logiciel et l’alimentation autonome par batterie en quelques minutes. Remarque: pour cette étape j’ai utilisé des moteurs plus petits (sous les bonhommes en papier servant uniquement à mieux voir quand les axes tournent!) qui ont été changés depuis.

Le breadboard est ensuite remplacé par une plaquette PCB sur laquelle les composants sont soudés avec le filage et les nappes de fils faites maison. Une plaquette de contreplaqué et des vis ont été utilisées pour assembler les 3 étages Raspberry Pi + plaquette PCB maison + afficheur LCD en un bloc compact.

La partie mécanique a pris un peu plus de temps. L’appareil photo pèse environ 800g et on veut qu’il pivote autour de la pupille d’entrée située à environ 10cm du centre de gravité du boîtier. On peut donc estimer le couple nécessaire au mouvement à 0.8kgx10cm=8kg.cm. Le moteur économique choisis (6$!) a un couple de 80g.cm soit 0.08kg.cm ce qui est environ 100 fois trop faible pour être en prise directe!!! Il est donc nécessaire d’utiliser des engrenages pour démultiplier le couple. Inspiré par GigaPi,  j’ai choisi le principe de la vis sans fin pour que l’appareil reste immobile même lorsque les moteurs ne sont pas alimentés (économie d’énergie) mais je n’ai pas trouvé de solution simple et économique pour des engrenages sur mesure. J’ai finalement acheté 2 ensembles moteurs DC + engrenages de récupération. Par chance, il n’a pas été trop difficile d’adapter les moteurs pas-à-pas à la place de ceux d’origine (la vis sans fin maintenue « press fit » sur l’axe a été retirée du moteur d’origine puis placée au four à 250C pour dilater un peu avant d’être encastré sur l’axe du moteur pas-à-pas!). Le même système a été utilisé pour les deux moteurs.

Le train d’engrenages utilisé à un ratio de 1:112 donc en sortie le moteur tourne 112 fois moins vite mais avec un couple de l’ordre de 112 fois plus élevé (que l’on peut arbitrairement arrondir à 100 pour tenir compte des frottements dans les engrenages) soit 0.08*100=8kg.cm!!!!!! En théorie donc, l’ensemble moteur + engrenages devrait être juste suffisant pour fournir le couple requis!!! J’ai tout de même installé deux contrepoids de 500g environ (obtenus en coupant en 2 un plomb de plongée sous-marine!) qui équilibrent presque l’appareil photo pour avoir une grande marge de sécurité et compenser les frictions dans le mécanisme, le vent, la gène causée par le cable usb etc (mais le contrepoids signifie qu’il y a plus de poids pour le moteur de déplacement horizontal!). L’ensemble du châssis est constitué de contreplaqué de 3 à 12mm (1/8 à 1/2 pouces) et de quincaillerie standard (boulons, rondelles, écrous…). Par chance la vis servant à fixer un appareil photo à un trépied correspond à une taille 1/4-20 qui est très courante donc aucun soucis de ce côté! Voici donc PanoPi presque complet:

L’ensemble PanoPi, trépied et appareil photo étant assez encombrant et lourd, un châssis de sac à dos de randonnée a été utilisé pour fabriquer une boite servant à transporter le tout.

Premiers essais:

Le premier panorama a été fait en intérieur à partir d’une séquence de 40 images horizontales soit 5 bandes (centré sur l’horizon puis -30, -60, +30 et +60 degrés) de 8 images centrées (45degrés de décalage horizontal). Les images se recouvrent d’environ 25%. Une fois les photos chargées dans Hugin, le logiciel identifie des points de contrôle qui se retrouvent sur au moins 2 photos puis des calculs d’optimisation sont effectués pour trouver les déplacements et déformations de chaque image de façon à ce que les points de contrôle se correspondent du mieux possible. Un aperçu de panorama est alors disponible et il reste à choisir la projection, le cadrage et la taille du panorama et enfin de lancer le calcul final (qui prend typiquement une heure à plusieurs heures selon le nombre et la taille des photos d’origine). La première image est en projection equirectangulaire classique:

Lorsque le panorama couvre 360 degrés, il est amusant d’appliquer une transformation polaire (dans Gimp) pour enrouler l’image sur elle même. Le résultat est un disque ou un bagel! Voici ce que cela donne avec le sol ou le plafond au centre du disque!

La même séquence d’image mais avec une projection dite « fisheye » dans Hugin:

Et pour finir, la première photo en extérieur, au pied de grands arbres situés au centre du parc Jarry (ici encore projection fisheye):

Et ensuite?

Et ensuite? Avec le (peu de) recul de ce premier prototype j’ai déjà quelques idées qui permettraient d’avoir un PanoPi plus rapide et plus compact mais je pense surtout me concentrer sur l’optimisation du mécanisme actuel plutôt que de recommencer une phase de fabrication! En priorité donc, il reste du travail à faire sur:

• le code python pour une meilleure interface avec les boutons et l’écran LCD (J’essaierai de partager le code lorsqu’il sera un peu dégrossi)
• une optimisation des séquences (nombre de photos, pourcentage de recouvrement, nombre de photos sur les bandes les plus hautes ou les plus basses etc.)
• La vitesse des moteurs
• La finition de la façade avec les boutons…

A suivre??? N’hésitez pas à utiliser les commentaires si vous avez des questions.

 

(503)