autoguidage "maison"

[samR 1]

Bonjour à tous

je suis nouveau sur le forum, première fois que je poste. J'ai l'impression que je frappe à la bonne porte pour les questions existentielles que je me pose. :-)
Je possède un télescope maison (un newton de 200mm basé sur le livre de JM Lecleire) motorisé deux axes.
Je souhaite maintenant faire un autoguidage "maison". A cet effet, j'avais refait l'électronique il y a 8 ou 10 ans de cela pour que les impulsions envoyées sur les moteurs pas à pas soient gérées par un microcontroleur (PIC 16F84). Je peux ainsi régler la fréquence des pulses sur 256 niveaux:
- une bonne fois pour toutes au moment de la programmation du PIC
- mais aussi en cours de route, depuis le port série d'un PC, qui envoie un nombre qui est lu par le PIC.

J'ai un petit programme en C++ pour faire ma boucle d'asservissement (type PID), qui lit l'image d'une webcam, calcul le centre de l'étoile guide, et envoie l'information adéquate sur le port série. Allez savoir pourquoi, ça n'a jamais bien fonctionné! P'têt parce que je suis assez nul en programmation!... et aussi la mécanique du télescope laisse parfois à désirer. J'ai peut-être des erreurs dans le suivi de mon étoile un peu trop rapides pour être corrigées...
Aujourd'hui, j'ai un peu amélioré la mécanique, et je souhaite remettre tout ça au goût du jour. Je ne vais pas vous demander de debugger mon programme bien sûr, mais voila mes questions: est-ce que certains d'entre-vous ont l'expérience d'un système d'autoguidage fait maison? Est-ce que la solution que j'envisage vous parait bonne? Est-ce qu'il n'y a pas plus simple? ou est-ce que je peux introduire dans ma boucle des composants qui me faciliteraient la vie? (j'ai lu des choses sur des cartes Arduino... je ne connaissais pas, et ne sais pas vraiment si ça peut m'être utile)

Merci pour vos avis éclairés!!

Samuel

[PETIT OURS 24 630]

Salut et bienvenu
GG

[frédogoto 2 005]

bonjour
je n'ai pas d’expérience en programmation;
je peux comprendre qu'il est stimulant de tout faire soi même, mais sache qu'il existe déjà des solution gratuite fait maison
il y a PHD guiding, guidemaster pour ne citer que les deux plus connus

mon conseil est le suivant : valide déjà que ça marche avec ces logiciels éprouvé et fonctionnel, pour valider qu'il n'y a pas de bug coté instrumental. une fois ceci validé, écris ton programme

[baroche 8 512]

Bonjour et bienvenue sur le forum Samuel ... je ne peux pas t'aider dans ta quête mais d'autres le feront c'est sûr ...

[samR 1]

merci pour ces premiers éléments de réponse. Alors si je peux trouver un programme gratuit gui fait ça, très bien! Je vais explorer les solution que tu proposes, frédogoto.
Mais, sauf erreur de ma part, ces programmes utilisent une norme en terme de discussion entre l'ordinateur et la monture, non? Moi mon problème, c'est plutôt du coté des moteurs de la monture! Il n'y a rien de standard. C'est mon électronique maison, que j'ai bidouillée pour que le microcontrôleur puisse «écouter» l'information envoyée depuis le port série du PC... Je ne vois pas comment ces logiciels qui existent déjà pourrait me convenir... à moins de pouvoir les modifier. Je vais regarder tout ça.

[Leforgeron 22]

Bonjour samR

Tu dis avoir fais un programme qui fonctionne en PID, est ce une boucle ouverte ? Il semble que oui, car tu ne parle pas de codeurs.
Je ne suis vraiment pas spécialiste, mais il faut que tu puisse régler pas mal de paramètres en boucle ouverte afin que ton système fonctionne. En boucle fermée l'asservissement serait plus simple.(peut être)
Mais là, il faut de vrais spécialistes.
En espérant ne pas trop dire de bêtises.

A+
Régis.

[samR 1]

bonjour regis

l'idée est de fermer la boucle sur l'étoile guide bien sûr! pas besoin de codeurs ici...

[frédogoto 2 005]

en fait l'idée de ferme un boucle sur des codeur si possible HR directement monté sur l'axe est hyper intéressante
meade avait un systeme comme y'a qques année le TDM
ça permet de s'affranchir de la turbu tout en régulant en temps réel les défaut de la mécanique
mais des codeur HR ça coûte une blinde

[ZeSly 0]

Bonjour,

La première chose a faire est une mesure de l'erreur périodique de ta monture. Ça permettra de savoir si elle tourne de façon suffisamment régulière ou pas et de savoir s'il sera difficile de faire de l’autoguidage ou pas.

La norme de discussion entre l'ordinateur et la monture que les logiciels utilisent s'appelle ASCOM. Ils l'utilisent aussi pour discuter avec des cameras, des focuser, des dômes de coupoles, etc. Tu peux écrire ton propre driver de télescope ASCOM pour ton système de motorisation. Si tu connais le C++, tu pourrais de mettre au C# pour ça. http://www.ascom-standards.org/
Il existe d'autre "norme" comme le protocole LX200.

Sinon, PHD2 est open source, donc tu peux télécharger les sources et les modifier toi même pour ton système. Le logiciel est dispo là : http://openphdguiding.org/
Les sources sont là :
https://code.google.com/p/open-phd-guiding/source/checkout
Je te conseil TortoiseSVN pour les télécharger. Regarde les fichiers scope_*.cpp. Tu dois juste créer ta propre classe qui hérite de Scope et implémenter 3 fonctions : Connect, Disconnect et Guide. Regarde scope_gpint.cpp pour un exemple simple.

A propos des boucles d'asservissement, un système d'autoguidage est une boucle fermé. Pas besoin d'encodeur puisque c'est la caméra de guidage qui donne la position à corriger. C'est ce qu'a fait samR mais quand on connais les logiciels d'autoguidage, je ne suis pas sur qu'un système de type PID soit suffisant.

Une boucle avec des encodeurs sur l'axe permettent uniquement de faire de la correction d'erreur périodique. C'est ce que font les montures direct-drive avec des encodeurs très très précis et moyennant une excellente mise en station. L'autoguidage corrige la position réel de l'étoile guide et corrige donc l'erreur périodique et la mise en station. Enfin dans une certaine mesure, vous connaissez tous les avantages de l'un par rapport a l'autre.

[samR 1]

merci Zesly!

oui, j'ai vu, ASCOM, ST4... je m'y perd un peu, et si je comprends bien, mon électronique devrait être à la base conçue pour satisfaire ces protocoles, ce qui n'est pas le cas bien sûr... (faut savoir que j'en suis encore à guider à l'oculaire moi, alors, les protocoles pour l'autoguidage, c'est nouveau!...)

Je suis effectivement en train de regarder phd2 guiding. J'ai téléchargé les sources et compilé (je suis sous linux en plus ca m'arrange, quoique la version sous linux n'a pas l'air bien mature encore)... mais pfff, c'est compliqué, les truc avec INDI server et tout et tout (pour l'instant je suis bloqué à "Failed to connect to INDI server" - pourtant une fois j'ai réussi, j'avais même l'image de ma caméra, puis là, plus rien. grrr).
Mais effectivement, si les asservissements type PID sont insuffisants comme tu dis (je n'aurai pas cru! un bon PID bien réglé, ça suffit pas?) il vaut mieux que j'essaye d'utiliser un vrai logiciel... mais ça va être long à tout comprendre, je ne suis pas bien à l'aise en C++. Merci pour tes tuyaux qui vont m'aider à démarrer. Je vous tiens au courant!

[samR 1]

mmmh, si j'en crois ce qui est écrit ici:
http://indilib.org/about/discover-indi.html

je pourrais écrire un driver spécial pour mon instrument qu'utiliserait ensuite le client phd2 guiding. (sans modifier ce dernier, donc?)
En suis-je capable??? suspens...

[christian_d 3 150]

Bonjour

"..La première chose a faire est une mesure de l'erreur périodique de ta monture. Ça permettra de savoir si elle tourne de façon suffisamment régulière ou pas et de savoir s'il sera difficile de faire de l’autoguidage ou pas..."

Oui, sage réponse. Commencer par le commencement est la bonne démarche.
Connais tu l'EP de ta monture en charge ?

Christian

[samR 1]

oui oui, dès que j'ai l'occas, je regarde ces choses, depuis plus de 10 ans maintenant, et j'améliore par petit bout à chaque fois ;-)
Ca devrait commencer à être pas mal maintenant, j'ai éliminé au maximum les sources d'erreurs qui me faisaient des "saut" dans le suivi.
J'ai encore fait des modifs récemment, il faut que je refasse des mesures, dès qu'une étoile montrera la bout de son nez :-)
Avez-vous une idée de la vitesse de dériv maximale acceptable pour un bon autoguidage? J'imagine que ca ne dépend pas que du logiciel, mais de toute la chaine, monture inclue, et que ca dépend de la qualité de suivi qu'on recherche...

[samR 1]

bon en guidage à l’oeil, j'ai pu faire ça, jadis, avec ce télescope: http://samronayette.fr/photos/picture.php?/1417/category/astro

j'imagine donc qu'un autoguidage pourra le faire aussi! non? Si l'étoile guide est suffisamment brillante pour permettre des poses courtes...

[amateurAstro64 307]

Bonjour Samuel,

pas mal du tout la M27

Concernant ton projet je te souhaite bien du courage...

Pour ma part, je suis en train de réaliser une monture azimutale motorisée
à suivi automatique mais ma démarche est plus "simple" de la tienne.

Car pour l'instant je me limite à un fonctionnement en boucle ouverte.

Mettre en place une boucle fermée est beaucoup plus difficile,
et nécessite à priori beaucoup de calculs, tout dépend sur quoi on se base.

Le problème de l'asservissement et de la fonction de transfert, c'est que
si tu veux améliorer celle ci soit ça te coutera de l'argent (encodeurs précis,
taux de calculs sur ta cible matérielle plus important, sensibilité du capteur, etc..., sans oublier les aspects temps réels, bus, protocoles, etc... à gérer)

Apparemment tu travailles pour les exigences de la photographie, ce qui n'est pas mon cas

Personnellement au lieu de bosser sous un microcontroleur genre PIC16F,
j'ai préféré tout gérer à partir d'une petite carte genre raspi,
et tout développer en C sous LINUX.

Sinon pour les difficultés que tu rencontrent, il faut avancer pas par pas lol

tu dis que tu as un problème avec les moteurs, quels sont ils ?
tu travailles avec le port série, est ce que les moteurs avancent en utilisant ton port ?
peux tu en dire plus ?
peux tu paramétrer ton programme pour qu'il travaille en boucle ouverte et boucle fermée
successivement, et voir ce qui se passe ?

est-ce que ta boucle est bien paramétrée ?
reçois tu un signal depuis ton capteur depuis ton étoile quide ?
peux tu mesurer ce signal et le quantifier déjà sans l'utiliser dans ta boucle ?
etc..

bonne chance à toi,

stef

[S.Chapeland 730]

Bonjour Samuel,

je guide mon matériel avec une solution maison à base de PIC depuis une dizaine d'années. dans ton cas, il me semble que le plus simple serait d'équiper ton contrôleur de moteurs d'un port autoguidage ST4. comme j'imagine que tu as une raquette de commande pour bouger dans les directions (N,S,E,W), ca devrait pas être bien compliqué à rajouter (éventuellement, 4 entrées sur le pic qui actionnent les moteurs à une vitesse réduite par rapport aux actions manuelles, typiquement 0.5x la vitesse de suivi sidérale, ou un switch pour régler la vitesse si tu réutilise les entrées du joystick).

une fois que tu as une entrée type ST4, tu seras capable d'interfacer ton matériel avec à peu près tous les logiciels, par exemple avec une petite interface USB<->ST4 qui recoit des commandes standard LX200 (une trentaine d'euros dans le commerce il me semble... dans le temps j'ai dû bricoler la mienne avec un autre PIC). et le jour ou tu as une caméra d'autoguidage, tu pourras aussi la brancher directement sur ton port ST4.

après, si les logiciels disponibles ne te plaisent pas, rien n'empeche de t'en faire un... (je me suis aussi amusé à ça, et pas besoin d'une boucle d'asservissement compliquée pour que ca marche, le point critique c'est la calibration orientation/vitesses)

bon courage
Sylvain

[samR 1]

ah ah, équiper mon matériel d'un "port d'autoguidage ST4". Ça j'ignorais que c'était possible!je regarderai plus en détail.

Oui je m'étais aussi fait un petit logiciel, avec une étape de calibration orientation/vitesse, puis une tentative d'autoguidage... mais c'était sous Windows, et ça n'a jamais bien marché, c'était il y a longtemps, et maintenant j'aimerais faire marcher tout ça sous Linux.

Pour l'instant je pars sur l'écriture d'un driver INDI spécifique pour mon électronique, que je devrais pouvoir utiliser avec des logiciel type phd2 ou Kstars/Ekos. L’intérêt, c'est quand même que tout est en place pour piloter la caméra (exposition, gain...), puis faire l'autoguidage. Reste à voir si je suis capable de programmer ce driver... mais il y a des exemples et tutorials.

@stef: non, je n'ai pas de problème avec les moteur, et la mécanique de la monture et des entraînements AD et DEC commence à devenir très correcte. j'ai un boîtier électronique qui envoie les impulsion sur les moteurs pas-à-pas, avec effectivement une raquette de commande pour manuellement aller au nord, au sud, à l'est à l'ouest (avec une vitesse lente et une rapide). Bref, classique! Ensuite je peux remplacer la raquette de commande manuelle par un ordinateur (via le port série) qui fait globalement la même chose: N, S, E, O, avec éventuellement différentes vitesses. Mais pour l'instant, je n'ai pas de programme digne de ce nom pour piloter cette électronique par le port série, et encore moins avec guidage! voilà tout!

merci à tous pour vos infos jusqu'à présent, en tout cas, c'est très précieux. Je continue et vous tiens au courant! :-)

[amateurAstro64 307]

Bonjour samuel,

je viens de relire tout ton post afin de ne rien oublier..

Donc si j'ai bien compris, tu as déjà fait ton programme en C++
qui lit l'image depuis la webcam, calcule le centre de l'étoile guide
et envoie le nombre encodé sur 8 bits (entre 0 et 255) via le port série
sur ta raquette de commande, qui est censée ensuite actionner les moteurs
à la bonne vitesse ?

Donc ton programme mets en place le recalage PID (boucle fermée)
et tu rafraichis tes calculs tous les lambda;

ok, parfait,

Sur le web, tu trouveras beaucoup d'infos concernant la programmation
d'un port série en C++, c'est bcp moins compliqué qu'un port USB par exemple il me semble.

si ton problème se tourne donc de ce côté là, il faudrait
que tu vérifies simplement à l'aide de LED + résistance que tu as effectivement une sortie à l'autre bout du câble.

ensuite je ne sais pas comment est interfacé ton port série avec ta raquette mais la première chose à vérifier est dans tous les cas que tu as bien un signal.

je suppose que ton électronique est basé sur un oscillateur à quartz ou bien un NE555 sur lequel tu as ajouté un diviseur de fréquence 8 bits ?

peux tu en dire plus ?

là j'ai pas le temps mais cherches sur le web, tu trouveras moultes infos
concernant la programmation des ports séries, c'est pas bien compliqué.

ensuite vérifier un signal sur un port série, c'est très simple puisque on a affaire à des niveaux logique TTL 0-5V , donc une LED et une rési et tu vérifies le port 8 bits en sortie (relier les masses évidemment)

pour un port parallèle c'est plus compliqué, il faut étudier la trame à l'oscillo avec les bits d'entrée et de sortie de trame,

Personnellement je travaille avec le port I2C de la Raspi, ça marche très bien, et ça gère un nombre d'entrées sorties quasiment à la demande, pour encoder et envoyer mes informations à la carte de contrôle moteur,

l'avantage c'est que je travaille en réseau directement via le port ssh ou telnet (ou http, etc..), ce qui évite les fils et la connectique, et ceci est difficile à mettre en place avec un simple PIC16F, bien que réalisable,

je te suggère donc dans un 1er temps d'écrire un petit driver pour ton port série (voire en chercher un sur le net), d'envoyer déjà un simple nombre 8 bits en C++, et de vérifier la sortie avec led + résistance,

stef

[samR 1]

merci Stef,

mais en fait je n'ai pas vraiment de problème. Mon premier message était surtout pour savoir si la solution que j'ai envisagée semblait bonne et si certains avaient d'autres suggestions. Ce qui m'a orienté vers les logiciels d'autoguidage, fait découvrir phd2 et les drivers INDI, ou apprendre que je pouvais équiper mon matériel d'un port autoguidage ST4... à voir

Oui, j'ai une électronique que je peux commander avec le port série, j'ai un programme en C++ qui tourne sous Windows qui fait ça bien, et qui lit aussi l'image de la webcam. Entre les 2 (webcam et port série), il y a un bout de code que j'ai écrit qui est censé faire l'asservissement sur l'étoile guide. Ça ne marche pas bien, mais je ne sais pas exactement pourquoi, peut-être un mauvais réglage des paramètres PID, et il faudrait que je refasse des essais maintenant que j'ai amélioré la mécanique du télescope. Mais tout ça est un peu vieillot, et je m'oriente vers une solution différente (voir message précédent) qui me permettra d'utiliser des logiciels d'autoguidage existant, et sous Linux. Si ça s'avère trop compliqué, dans un premier temps, je ressusciterai alors mon programme C++ qui tourne sous XP...

Samuel.

[amateurAstro64 307]

bien bien,
ben bon courage alors dans ton projet,

stef