Senseur numérique de Tip/Tilt

 

Nous avons vu dans la page consacrée à la première version d'un miroir basculant destiné à devenir un compensateur de tip/tilt que le senseur de position analogique utilisé manque de sensibilité au regard des cibles qui nous intéresse en astronomie. Une mesure de la sensibilité nous a montré que les PSD ne permettaient pas de descendre en dessous de µW de puissance lumineuse, ce qui est trop juste pour des objets dont la magnitude produit, y compris sur des télescope de grand diamètre, des flux lumineux inférieurs au nW.

Deuxième inconvénient, l'asservissement (PID) réalisé en électronique analogique et conçue pour asservir le miroir basculant n'est pas facilement paramétrables en fonction du grandissement utilisé sur la voie de détection du compensateur de tip/tilt (pour plus de détail sur la constitution du système, voir le lien cité plus haut).

Or les cameras CMOS rapides actuellement disponibles, sont susceptible d'une très grande sensibilité, à des temps de poses très court et donc de se rapprocher des temps de cohérence de la turbulence (voir sur la turbulence atmosphérique cette page). 

Disposant actuellement d'une Basler ACA1920-150um, il me semblait possible d'envisager la réalisation d'un senseur numérique de tip/tilt paramétrable numériquement et qui permettrait, à terme, de piloter le miroir basculant décrit dans la page citée précédemment. 

La condition de réalisation d'un tel système sous tendait aussi de disposer d'un PC low cost rapide entièrement dédié au calcul du centroïde de l'objet détecté par la caméra Basler, interfacée par un port USB3. 

La solution m'as été signalée par mon collègue et ami François Colas, dans une note d'application de Basler Camera disponible sur ce lien. On peut en particulier y découvrir un microPC low cost (70euros ttc) nommé Odroïd XU4, disposant d'un processeur 8 coeurs et de deux ports USB3.

Cette petite machine semblant montrer des performances étonnante, j'ai donc cassé la tirelire pour m'en procurer un exemplaire et voir dans un premier temps comment se comporte cette machine face à la Basler. C'est sans trop de difficulté que j'ai put installer un visionneur de bureau distant (vnc4server) pour me passer d'un ensemble clavier souris écran prenant les ports USB3 dont j'avais besoin. La distribution linux implantée sur cette carte est une Ubuntu Mate pour processeur Arm. J'ai ensuite implanté un IDE de programmation (codeblocks), le Software Design Kit (SDK) Pylon5 propre à l'interfaçages des caméras Basler et la bibliothèque de traitement d'image OpenCv pour faire les traitements graphiques nécessaires. Basler fourni aussi directement dans une note d'application le moyen d'utiliser la bibliothèque OpenCV.

Après quelques heures de programmation (même si je déteste cela), je suis arrivé à contrôler, et acquérir les images de cette Basler ACA1920, et les résultats furent au delà de mes espérances. En sélectionnant sous PylonApplicationViewer (le logiciel de contrôle de la camera livré avec le SDK) le mode d'acquisition en Region Of Interest (ROI) d'une taille de 320x200 images, le débit réel, mesuré sur le nombre d'images acquise est de plus de 800 images par secondes (pose de 500µs) sans pertes (je n'annonce pas le chiffre exact, 800 images par secondes étant le chiffre raisonnable que j'ai forcé pour pour éviter de perdre des images sur la liaison USB3 (le nombre réel en ips est légèrement supérieur sans forçage du débit). Bref, l'ensemble Basler Aca/Odroid fonctionne parfaitement en haut débit, conformément au besoin et sans même en passer par un noyau linux temps réel. L'image présentée en suivant est une copie d'écran ou l'on voit dans le "viewer" de chez Basler l'image du mur de mon bureau sur lequel je projetait un laser vert, bien connu des montreur d'étoiles.

Débit réel à 800fps sur un ROI de 320x200 sous PylonViewerApp

Voila pour le coeur de la partie codage.

Quelques heures supplémentaire de codage en c++ plus tard, afin de réaliser le calcul de la position du centroïde de l'objet lumineux présent sur l'image (photocentre ou moment d'ordre 1 sous OpenCV) le code permet aussi, via la conception et la réalisation d'une carte de conversion numérique/analogique (utilisant un convertisseur AD5754 16 bits interfacé via un bus SPI de chez Analog Devices), de produire sur 3 voies des tensions de commandes du miroir dans la gamme +/-10V.

Setup de test 

(caméra Basler a droite calée par un poids en Alu)

Odroid XU4 + AD5754 Traces obtenu via le contrôle par le code c++

(mesure de la vitesse d'actualisation des tensions) :

En bleu : tensions incrémentées de façon continue (CNA voie A)

En rouge : Génération de tensions aléatoires (CNA voie B)

En Jaune : lecture du niveau de bruit (CNA voie C)

 

La vitesse maximale d'actualisation des tensions est directement dépendante de la vitesse de transmission des datas par le bus SPI de l'AD5754. Le schéma suivant montre les mesures faites aux différentes étages de l'électronique de commande. Visiblement (et c'est un problème connu sur l'Odroid, le bus de transmission SPI impose des délais inter octets très important). Il existe donc une limitation en vitesse de génération des tensions de commande. En l'état, la limitation mesurée (voir en suivant) est de 350 images secondes (cliquer sur les images pour le détail des mesures).

J'ai noté les temps caractéristiques de transmissions relevé via les tags insérés dans le code de test, sur mon tableau blanc, je reproduit ici le schéma de la chaîne d'acquisition :

Les mesures temporelles :

Débit Caméra Retour des Timestamp insérés dans le code (timing des prises de vue) Tension de consigne mesurées à l'oscilloscope

Dans cette configuration, il faudra donc se contenter d'une prise de donnée à 350 images par secondes au maximum (ce qui n'est pas si mal après tout !). Cela représente un temps de pose max de 3ms ou une cadence équivalent inférieure au temps de cohérence moyen de la turbulence sur un site correct. Malgré cela je réfléchi a une solution moins limitative pour contrer la limitation de ce temps d'écriture sur le bus SPI.

L'étape suivante à donc été de faire un test de relevé direct des positions d'un spot laser projeté dans le champs de la camera et sa restitution par le convertisseur de tension numérique/analogique. 

Le temps d'acquisition et de transferts par trame de la Basler vers l'Odroïd est inférieur à 350µs. Le temps de calcul du centroïde est d'environ 50µs. Le temps le plus long est celui du transfert de la consigne numérique en direction du CNA (0.3ms).  Le test à consisté à relever les changement de positions sur un oscilloscope (numérique dans un premier temps, mais en raison de délai de restitution à l'écran de la pile de points enregistrés et restitués sur l'écran en mode d'affichage XY, impliquant un retard de l'oscilloscope, l'analyse s'est faire avec un vieil oscilloscope analogique).

Le set up :

 

 

Oscillo Numérique et Analogique Spot laser dans le champs camera vidéo du test

Le résultat parle de lui même. La vidéo à été faite à 100images secondes, mais j'ai la même chose à 350 images secondes. On peut donc imaginer facilement à raison de 3 images par 10 millisecondes, caler un PID permettant d'activer le miroir basculant à minima vers 100 mouvement secondes.

Nous ne sommes pas encore dans le cadre d'un asservissement de position de type boucles d'asservissement (j'y reviendrait rapidement), mais entre le miroir basculant et ce senseur de position numérique, on à tout ce qu'il faut pour envisager de faire une AO low cost de compensation du tip/tilt.

23/11/2018.