Analyse d'EP dans une cave: méthode Starlink par bibi ;)

[eroyer 657]

Bonjour gehelem,

je prend la conversation en route et même si j'ai tout lu, je ne suis pas sûr d'avoir bien compris ce que tu calcules. D'abord, ton idée d' "encodeur optique maison" est très bonne et je pense qu'elle a un beau potentiel.

Est-ce que tu peux me confirmer que ton algo consiste à :

- prendre une image I1

- attendre que la monture tourne un peu pendant une durée delta_t

- prendre une image I2

- utiliser match_template() d'openCV pour calculer le déplacement d'un motif entre I1 et I2 (si c'est le cas, quel motif ? toute l'image ou juste une portion ?

- traduire le déplacement donné par match_template en valeur angulaire de rotation du disque et calculer l'écart entre cet angle mesuré sur 'image et l'angle correspondant à la vitesse sidérale dans l'intervalle delta_t

 

Si c'est le cas, j'ai peut-être quelques idées pour améliorer les choses.

 

 

[gehelem 187]

il y a 15 minutes, eroyer a dit :

Si c'est le cas

oui en gros c'est ça, il te manque juste l'étape "subpixel" :

en gros avec le montage de base le mouvement reste très lent (environ 2 pixels par seconde)

et la méthode de matchtemplage ne détecte que des pixels entiers, entre les deux on ne voit rien

donc on ajoute une méthode supplémentaire d'approximation de la fraction de mouvement entre deux images

il y a 18 minutes, eroyer a dit :

j'ai peut-être quelques idées

zyva !

 

 

[gehelem 187]

Il y a 11 heures, Cyrille Thieullet a dit :

(...) Le subpixel  (...)

 

 

Excuse moi je vais résumer ma compréhension :

Tu indiques en gros "bah oui c'est normal on s'y attendait"

(et merci pour tous ces développements !)

 

Du coup je vais plus loin : il faut benner cette méthode de calcul du subpixel et en trouver une autre.

Moi ça ne me convient pas du tout, il me faut un truc qui passe mon test sans faire de vague.

A la limite on pourrait acter de cette réponse non linéaire, et la compenser dans l'autre sens ...

J'avais déjà mal à la tête, là ça va être l'AVC direct

 

 

[Cyrille Thieullet 106]

14 minutes ago, gehelem said:

A la limite on pourrait acter de cette réponse non linéaire, et la compenser dans l'autre sens ...

Oui, c'est l'aspect filtrage dont je parlais. Ca sera jamais une droite. Avec le bruit en amont je ne sais pas si ca servira.

De quelle précision as tu besoin ?

Là tu passe de 7arc rms à 0.44. Tu veux descendre à combien ?

 

 

47 minutes ago, eroyer said:

Si c'est le cas, j'ai peut-être quelques idées pour améliorer les choses.

@eroyer Top !

 

[eroyer 657]

Je pense que match_template n'est pas le plus adapté pour ce cas, en plus qu'il ne donne pas de précision subpixellique.

En fait dans ce montage, le mouvement de l'image est une rotation et pas une translation. Idéalement, il faudrait chercher l'angle de la rotation qui minimise la différence d'image entre I1 et R(I2). Avec une minimisation itérative dans laquelle la fonction à minimiser est la différence d'images et la variable est l'angle de la rotation, on doit avoir un résultat plus précis. Il y a des algos d'optimisation dans scipy pour faire ce genre de choses mais c'est délicat à implémenter si on ne l'a jamais fait.

Sinon en plus simple, sans faire de code et juste pour voir ce que ça donne pour savoir si ça vaut le coup de creuser l'idée, tu pourrais utiliser un logiciel de création de panorama (par exemple hugin : https://hugin.sourceforge.io/ ). Tu rentres une série d'images dans le logiciel et il va chercher des points d'intérêt communs dans les images pour calculer une homographie entre chaque paire d'images avec un recouvrement et optimiser tout ça. Et ça donne en général un résultat très précis sur les déplacements d'image à image. Bien sûr, on est pas sur une intégration temps réel mais ça permet sans code de voir si ce type d'algo peut marcher sur tes images. Si ça fonctionne, ce n'est pas très difficile de reproduire un algo équivalent avec openCV car il y a toutes les briques de base disponibles.

[gehelem 187]

il y a 41 minutes, Cyrille Thieullet a dit :

De quelle précision as tu besoin ?

 

en tout franchise j'ai hâte déjà de voir si ce 0.44" n'est pas un peu usurpé :

j'ai tellement cuisiné le truc que je suis convaincu que j'ai arnaqué quelque part

 

Mais sinon si tout es réglo, à mon avis ce n'est pas la peine de descendre beaucoup plus bas.

Dans le cadre de la compensation en live, c'est à mon avis superflu d'essayer de descendre sous les 0.1-0.2"

Donc gagner encore un facteur 4 serait idéal, mais après on tombe largement sous la turbu c'est ridicule sauf à vouloir caractériser complètement son EP, les petits rouages les trucs précis etc etc.

 

J'ai donc commencé à faire comme toi, avec un vrai montage de l'objectif de microscope qui me fait monter à 8 pixels / seconde (et donc échantillonnage de  1.9arcs) , ça se voit vraiment bien.

Sauf que j'ai tout démonté ce matin :

je repasse avec le microscope USB d'origine, pour pouvoir tester sur la petite fenêtre de ciel clair qui semble bien vouloir se présenter ...

 

 

[gehelem 187]

[eroyer 657]

S'il y a quelques étoiles ce soir, le résultat promet d'être intéressant !

[gehelem 187]

en direct de mon jardin :

soucis "annexes" avec ma monture, rien à voir avec le procédé lui même, mais mes tests sont compromis pour ce soir

 

Et sinon tout de même un enseignement, la rosée sur le CD : on valide ?

Modifié 2 décembre 2023 par gehelem

[Cyrille Thieullet 106]

Bonjour,

 

On 12/2/2023 at 10:22 PM, gehelem said:

mes tests sont compromis pour ce soir

Ah flute ! Rien, même pas  une photo pour voir le suivi ?

 

Très bon test pour la rosée, ca rajoute des trucs aléatoires ! Top.

Le drift est en arc sec ?

 

Cyrille

[gehelem 187]

il y a 40 minutes, Cyrille Thieullet a dit :

flute ! Rien, même pas  une photo pour voir le suivi ?

Non, impossible de faire une MES même pourrie, il faut que je repasse sur une monture et un driver indi que je maîtrise, c'est chiant.

 

Unité du graphe = arcs

La rosée = non, si la goutte bouge c'est cuit :-)

[gehelem 187]

Allez, test hier soir en mode alz

[gehelem 187]

Alors je confirme que c'est vraiment pas mal cette histoire

Pour bichonner sa monture c'est très pratique

Voici donc ce que donne mon EQ8 sur le bureau

 

 

A noter tout de même que le point vraiment critique c'est la fixation du microscope, c'est très sensible

Le coup du serre-joint c'est vraiment pour voir un premier coup, mais il faut impérativement fixer le truc solidement.

 

Autre difficulté mais qui est attendue, c'est de déterminer la dérive précisément :

On ne peut pas la faire à posteriori, mais on peut s'aider de PHDLogViewer.

il faut d'abord y aller par dichotomie en mode bourrin, puis ensuite lorsqu'on approche une valeur stable on peut regarder ce truc :

 

 

ici je vois que je dérive de 0.16 pix/min soit environ 0.0026 pix/sec

Je peux donc corriger mon estimation grossière en conséquence (en me faisant des nœuds au cerveau pour savoir dans quel sens corriger cette erreur :-) )

 

 

Modifié 7 décembre 2023 par gehelem

[gehelem 187]

... et bien entendu, l'objectif final étant celui ci

si seulement on pouvait avoir un tout petit peu de ciel ...

[gehelem 187]

Je réfléchis un peu sur ces histoires de PID, et je remets une pièce pour suggérer que ce n 'est peut-être pas adapté.

Pourquoi je dis ça ?

Il suffit de regarder chez les copains :

https://openphdguiding.org/man/Guide_algorithms.htm

Je ne pige pas grand chose faute d'avoir lu attentivement tout bien comme il faut, mais en tout cas personne ne parle de PID

Donc ... des suggestions ?

A noter que bien entendu il va me falloir des heures avant de piger les concepts pour faire pareil (le LowPass2 serait pas mal je crois)

Modifié 9 décembre 2023 par gehelem

[Cyrille Thieullet 106]

Bonjour,

 

Et si tu faisais converger ton PID plus lentement ?

Et si tu faisais la mesure/correction toutes les 2, 4, 8 ou 16 images ?

Ca donnerait quoi sur les courbes ?

De combien de corrections par seconde as tu besoin au minimum pour aplatir la courbe ?

 

Après quitte à y passer des heures, tu repars de PHD2 et tu incrustes le matchTemplate à la place du carré vert standard qui devient plus grand.

Et Hop c'est fini t'as tous les paramètres possibles, les caméras, montures et un PHD qui fait du guidage sur n'importe quelle cible...

Y'aurais plus qu'a faire un merge après pour que tout le monde en profite.

 

Cyrille

Modifié 10 décembre 2023 par Cyrille Thieullet

[gehelem 187]

Il y a 14 heures, Cyrille Thieullet a dit :

Et si tu faisais converger ton PID plus lentement ?

Et si tu faisais la mesure/correction toutes les 2, 4, 8 ou 16 images ?

Ca donnerait quoi sur les courbes ?

De combien de corrections par seconde as tu besoin au minimum pour aplatir la courb

Hello

J'ai essayé tout ça (moyenne sur x images) sans succès 

Et pour estimer le nombre de corrections/s c'est difficile tant que je n'ai pas résolu le problème de la linéarité du subpixel.

Disons que pour le moment tout ce qui tombe en dessous de la seconde est suspect

Il y a 14 heures, Cyrille Thieullet a dit :

repars de PHD2

Là je bloque pour plein de raisons

D'abord j'en suis incapable !

Ensuite c'est à l'opposé de ce que je suis en train de mitonner depuis... 3 ans ?

Je tiens absolument à séparer les tâches et l'interface graphique.

Mais on sort du sujet du fil.

Je devrais tout de même pouvoir décortiquer le code de phd au moins pour m'en inspirer

[gehelem 187]

Hé bin dis donc, ça n'a pas été sans mal, m'enfin il me semble bien ...

Deux poses de 120secondes, l'une sans guidage, et l'autre avec la machine à deux balles

à 280mm de focale on ne voit pas grand chose, mais ça se voit.

(et aussi une MAP à la main sans focuser)

 

 

120s_sans_guidage.fits

120s_avec_blindpec.fits

[gehelem 187]

là on voit bien aussi