Mala

Adapateur monture CS pour caméra Raspberry PI

Recommended Posts

Voici une réalisation qui pourra sans doute intéresser d’autres hackers. Il s’agit d’un adaptateur d’objectif CS pour modifier une caméra IR de Raspberry grand angle de ce type...
https://fr.aliexpress.com/item/Raspberry-Pi-Camera-better-than-the-original-one-HD-5-megapixel-OV5647-sensor-adjustable-focus-for/32683743922.html?spm=a2g0s.9042311.0.0.8a956c37Ta1GXg

L’intérêt? Et bien les capteurs avec monture CS sont plus chers. Une fois l’adaptateur réalisé, on peut par exemple utiliser cet objectif 25mm F/1.2 à moins de 7€ frais de port inclus...
1/3 "25mm CCTV Objectif vue 70 m 11 degrés F1.2 IR Fixe Iris CS Mont pour CCD de Sécurité caméra

D28B6411

L’objectif ce visse directement sur l’adaptateur...

D28B6409

L’adaptateur est équipé d’un coffrage du capteur pour l’isoler au mieux des lumières parasites (j’ai ensuite peint l’intérieur en noir mat bien évidement)...

D28B6422

On peut réutiliser les deux vis de l’objectif d’origine pour fixer le capteur et solidariser le pied de test...

cs-mount-back

Le passage de la nappe peut être placé en haut comme ici (le capteur est tête en bas) ou bien en bas (la nappe se glisse alors par le pied)...

cs-mount-front

L’ensemble a été pensé pour une impression zéro support...

cs-mount-simplyfy-3d

Voili, voilou. Je réfléchi tranquillement à réaliser un viseur polaire numérique intégré à l’EM-10 avec un Raspberry PI Zéro et le tout à moindre frais (<50€). ;)

Le modèle 3D est dispo sur mon compte thingiverse...
https://www.thingiverse.com/thing:3277107

 

Edited by Mala

Share this post


Link to post
Share on other sites

Première lumière avec M42 pour tester le mini objectif CS 25mm F/1.2. Assez bluffant pour 7€!!! Je suis très agréablement surpris.
 
d28b6479.jpg
 
d28b6475.jpg
 
L’adaptateur fait très bien le job. Par contre en faible flux, j’ai l’impression que la lumière de la led rouge à proximité du capteur arrive légèrement à passer (tâche blanchâtre en bord d’image à gauche) à travers le coffrage malgré la peinture noire. Je vais devoir repasser une seconde couche voire carrément peindre la led pour être tranquille.

Share this post


Link to post
Share on other sites

Tu fais avec raspistill ?

Share this post


Link to post
Share on other sites

Oui avec raspistill. C'était vraiment un premier essai au plus simple pour vérifier le backfocus et le potentiel optique/caméra.

 

Pour la suite j'aimerais mettre en place un service qui s'occupe du pilotage de la cam et envoie les images via un socket en wifi sur le PI. Les images seront analysées par mon PC portable. Cela devrait faciliter les devs car bon Raspbian c'est bien gentil pour bidouiller mais loin d'être au top en terme d'éditeur de code et d'outils de déboggage.
 
A terme l'idée ultime serait de pouvoir prémacher les données (analyse de la taille et de la disposition des étoiles) sur le PI et d'envoyer les infos via liaison série vers l'Arduino Due de ma raquette de commande pour affichage schématique. Ainsi l'EM-10 resterait 100% autonome sans PC et c'est ce que je souhaite conserver à tout prix avec ma petite nomade. 

 

Sinon j'ai repassé une couche de peinture dans la chambre noir...

d28b6492.jpg

 

d28b6488.jpg

Et j'ai mis une touche de peinture sur la led du circuit de la cam.

 

Au final l'optique devrait se loger par là...

d28b6484.jpg

d28b6486.jpg

 

Comme l'EM-10 n'a pas de barre de contrepoids rétractable, j'ai la place qu'il faut à l'intérieur pour le raspberry PI.  Idéalement j'aimerais y mettre un PI Zéro pour optimiser l'espace et la consommation mais il faudra voir s'il tient la charge de calcul.

Share this post


Link to post
Share on other sites

Adaptation de la caméra Raspberry PI avec son objectif CS sur l'EM-10 pour le développement logiciel. Dans un premier temps, optique et Raspberry vont être placés en extérieur. Comme ça je pourrais monter/démonter le système sans condamner le viseur polaire d'origine le temps du développement. Il me reste à faire le support du Raspberry mais l'adaptateur est ok avec fixation par pas vissant et contre écrou. Simple mais efficace et assez robuste...

polarisfindertest.jpg

Share this post


Link to post
Share on other sites

Le support pour le PI Zero est maintenant en place...

d28b6580.jpg   d28b6582.jpg

 

 

Share this post


Link to post
Share on other sites

Merci Fred. :)

 

Coté développement cela prend forme. J’avance sur le pilotage de la caméra du Raspberry PI. Il existe bien le projet picamera en Python mais je souhaite quelque chose de plus performant, que ce soit au niveau des ressources CPU que mémoire, afin de tourner correctement à terme sur un PI Zéro. C’est donc le C/C++ que je privilégie. Et là les choses se gâtent sous Raspbian. Par exemple, la librairie de traitement d’image OpenCV propose bien le support de la cam mais uniquement en flux vidéo automatisé. A noter qu’il est possible de modifier certains paramètres via la méthode set (ex: CV_CAP_PROP_SATURATION) de la classe VideoCapture. Elle fait appel au driver V4L mais dans les faits c’est très limité. Impossible par exemple de régler l’exposition de ma caméra: « HIGHGUI ERROR: V4L: Property Exposure(15) not supported by device) ». Hors dans mon cas, il est nécessaire d’accéder à l’ensemble des pixels de l’image (mode « still ») avec une gestion manuelle de la caméra (exposition, balance des blancs, réglage du gain analogique, etc). Bref, pour arriver à mes fins, je suis donc contraint de coder une version modifiée à ma sauce de raspistillyuv. 

 

Niveau IDE de développement il n’y a pas grand chose de potable à mon goût. J’ai donc décidé de faire comme sur Arduino et d’utiliser l’IDE Xcode sur mon Mac pour avoir un éditeur digne de ce nom (code completion, refactoring, recherches avancées, etc). La mise en oeuvre est un peu plus complexe car cela nécessite de mettre en place des scripts de compilation à distance via un canal SSH mais ça y est ça tourne... :)

raspistill-on-mac-with-xcode.jpg

 

Cerise sur le gâteau: XQuartz me permet d’avoir la fenêtre de l’application PI directement sur le Mac (le code s’exécute sur le PI mais l’interface graphique est déportée sur le PC). Je peux maintenant coder sur mon PI avec un minimum de confort! :)

 

Le truc chiant avec cette caméra c'est qu'on ne la pilote pas directement. On doit passer par la couche MMAL (Multimedia Abstraction Layer) qui s'occupe de l'interface bas niveau. Malheureusement, elle ne permet pas un accès direct à la matrice de bayer. La débayérisation est effectuée en amont. Du coup, pour limiter la bande passante et l'usage CPU, j'ai décidé de travailler en YUV et je demande à MMAL de n'extraire que la couche Y (la luminance). Chaque image fait ainsi à peine plus de 5Mo au lieu du triple en version RVB.

raspistill-on-mac-shoot.jpg

Et maintenant que je maîtrise la prise de vue pleine trame, il est temps de vérifier la détectivité de la caméra. Le ciel n’était pas exceptionnel mais déjà avec un temps de pause de 2s, je passe le cap de la magnitude 7.5 avec l’objectif de 25mm F/1,2...

detection.gif

La détection des étoiles est effectuée ici sur mon Raspberry Pi 3 de développement en approximativement 1,4s de traitement. Cela me semble raisonnable pour une image brute de 5 mégapixel. Mon idée serait d’intégrer l’axe polaire en réalité augmentée avec les constellations proches du pôle. Il faudra voir ce que cela donne avec le PI Zéro plus limité.

Edited by Mala
  • Merci / Quelle qualité! 1

Share this post


Link to post
Share on other sites

Conception de la base d'étoiles qui va servir de référence à la corrélation de champ...

Je suis parti sur une couverture de 20° de rayon autour de la polaire. Et pour un précision optimale, j’ai pris en compte au niveau des étoiles: leur dérive annuelle, la précession des équinoxes, la nutation et l'aberration annuelle. 

  • J'aime 1

Share this post


Link to post
Share on other sites
il y a une heure, Mala a dit :

Conception de la base d'étoiles qui va servir de référence à la corrélation de champ...

Je suis parti sur une couverture de 20° de rayon autour de la polaire. Et pour un précision optimale, j’ai pris en compte au niveau des étoiles: leur dérive annuelle, la précession des équinoxes, la nutation et l'aberration annuelle. 

Chapeau !

Une question idiote pourquoi tu ne passes pas par une install en local d'astrometry.net ??

  • J'aime 1

Share this post


Link to post
Share on other sites
Il y a 3 heures, gehelem a dit :

Une question idiote pourquoi tu ne passes pas par une install en local d'astrometry.net ??

Je veux quelque chose de vraiment optimisé pour tourner sur le PI zero qui n'est pas une foudre de guerre. Je préfère donc bien maîtriser les données d'entrée pour éviter les goulets d'étranglement.

Edited by Mala

Share this post


Link to post
Share on other sites
Le 14/02/2019 à 08:28, Mala a dit :

Conception de la base d'étoiles qui va servir de référence à la corrélation de champ...

Je suis parti sur une couverture de 20° de rayon autour de la polaire. Et pour un précision optimale, j’ai pris en compte au niveau des étoiles: leur dérive annuelle, la précession des équinoxes, la nutation et l'aberration annuelle. 

 

Bravo ! C'est impressionnant !

Share this post


Link to post
Share on other sites
Il y a 20 heures, dragonlost a dit :

Bravo ! C'est impressionnant !

Merci. :)

Share this post


Link to post
Share on other sites

Je continue mon petit bout de chemin sur le viseur polaire avec la corrélation stellaire. Pour être le plus performant possible sur le Pi Zéro lors des captures en live, toutes les coordonnées cartésiennes des étoiles seront pré-calculées en pixels (sur la base de l'échantillonnage connu du couple capteur/objectif) et les distances entre chaque étoile stockées dans une  base SQLite.
Deux avantages:

  • Il sera très facile de limiter le champs de recherche des segments en bornant simplement les requêtes SQL sur leur longueur.
  • Aucune conversion supplémentaire nécessaire afin de respecter des rapports d'échelle pour comparer les distances entre les étoiles.
  • La déformation de champs de l'objectif étant très limitée, une tolérance de +-2,5 pixels semble suffisante pour filtrer correctement les segments.

Bref, l'identification commence à marcher... :) 

5ce161f56e187_Capturedcran2019-05-1915_44_02.jpg.607e38a05477dc08e1d92d39a69324e9.thumb.jpg.76de04256723fc4853be820047a988a3.jpg

 

Après avoir fait un peu le tour de ce qui existe pour la conception d'interface (Qt, Gtk, etc), j'avoue ne toujours pas être super emballé par la plateforme Linux dans ce domaine. C'est vieillo et lourd à souhait à mon goût. Du coup j'ai décidé de repartir sur ma bibliothèque ScreenView réalisée à la base pour Arduino.
 
ScreenView est donc en train de devenir une bibliothèque multiplateforme (PC/Raspberry PI/Arduino) pour concevoir facilement des interfaces graphiques en C++. Le code est très fortement inspiré des paradigmes de Mac OS avec son principe de hiérarchisation de vues et l'approche MVC (Model/Vue/Controller) que j'affectionne particulièrement...

Citation

ButtonView *button = new ButtonView();
button->setFrame(MakeRect((lateralView->frame().size.width-100)/2,300, 100, 22));
button->setTitle((char*)"Simple Button");
button->setButtonTouchDelegate(this);
_screenView->addSubview(button);

Le retour d'évènement est 100% objet avec une gestion par délégation (tel qu'on le connait en Objective-C et non en C#).
 
L'idée est donc d'avoir une API haut niveau commune et d'adapter le bas niveau en fonction de la plateforme. Pour Arduino, pas le choix c'est du quasi spécifique à l'écran 4,3" que j'utilise. Pour le Raspberry et le PC, j'ai opté pour OpenCV comme sous couche graphique commune. Voici un aperçu des premiers éléments d'interface sous Linux...

293771100_Capturedcran2019-06-0510_23_50.thumb.jpg.9386534c554d4d4d87ce2b4bdce141a6.jpg

J'ai bien dit Linux contrairement aux apparences. Ce n'est pas une appli Mac qu'on aperçoit sur la capture. Je développe en fait sur Xcode mais le code est compilé et exécuté à distance sur Raspbian qui renvoie l'interface graphique à XQuartz via un canal SSH. Linux avec le confort du Mac quoi... 
 
Le rendu des interfaces est un peu plus customisé "Desktop" pour le PI mais on retrouve les fondements de ScreenView sur Arduino avec notamment son  mode jour/nuit. Voici un aperçu en vidéo...

 

L'idée de base est donc de disposer d'un viseur polaire qui soit autonome au niveau logiciel (capture caméra, analyse du champ d'étoiles et interface graphique). Il suffira d'un simple client VNC sur une tablette, un smart phone ou un PC pour prendre le contrôle du viseur polaire sur la Raspberry.

  • Merci / Quelle qualité! 1

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.