Applications des moteurs pas à pas en astronomie

[Jerry18 0]

Les moteurs pas à pas sont particulièrement adaptés au réglage de la mise au point et de l'angle dans les applications de télescopes astronomiques. En utilisant un moteur pas à pas programmé pour contrôler un télescope astronomique, vous pouvez ajouter des fonctions d'automatisation plus pratiques au télescope astronomique. Par exemple, le moteur pas à pas, en conjonction avec les cartes astronomiques pertinentes et l'emplacement de l'objet d'observation, contrôle le télescope astronomique pour rechercher et suivre automatiquement les objets. Les étoiles positionnées par le contrôleur ou l'ordinateur permettent aux utilisateurs de retrouver rapidement la cible qu'ils souhaitent observer. Mais la programmation est un problème délicat, n'est-ce pas ?

Modifié 18 décembre 2023 par Jerry18

[Pascal C03 4 081]

Bonjour Jerry 18 (18 ans ou département 18 ?) et bienvenue

 

Ce qui serait bien pour un 1er message, ce serait de te présenter un minimum et de donner un peu tes objectifs.

Merci

Pour les moteurs pap, cela fait des décennies qu'il sont employés et effectivement le comptage de pas permet un goto.

[MARCOPOLE 7 138]

il y a 24 minutes, Pascal C03 a dit :

Bonjour Jerry 18 (18 ans ou département 18 ?

 

ou 18 mois ?

[ngc_7000 125]

Il y a beaucoup d'exemple de l'utilisation des PaP

Exemple de goto en diy : facile en conception mais pas trop en programmation

https://onstep.groups.io/g/main/wiki

 

[patry 1 973]

J'avais développé une table assez simple (simpliste ?) permettant de piloter un moteur PaP pour suivre (c'est la base) et pointer un objet par ses coordonnées sur un C8 ultima (roue d'AD de 359 dents, un réducteur de rapport connu, et un moteur piloté en micro pas).

 

"Simpliste" car en première approximation tu considère ta monture comme parfaitement alignée ET que la géométrie de la monture est "parfait" aussi.

Du coup à partir d'une "unique" position connue (une étoile brillante et j'en avait mis quelque dizaines en mémoire), l'instrument est capable de pointer où tu veux.

 

Ensuite viennent les "problèmes". Ta monture n'est jamais parfaitement réglée et son axe de rotation n'est pas celui de la terre. Là il te faut au minimum 2 étoiles pour que, la monture étant toujours considérée comme parfaite, tu retrouve ton erreur de mise en station (MeS). Ce n'est qu'un "simple" changement de coordonnées sphériques au final. A partir d'au moins deux corrections, tu remonte à l'erreur de MeS et donc tu peux corriger en AD + DEC un mouvement qui ne serait "normalement" que sur un seul axe.

 

Mais ta monture n'est pas non plus parfaite, et ton tube n'est pas rigoureusement // à l'axe et tu engendre une "erreur" de cône. Cela se corrige aussi mais il faut plus d'étoiles pointées (et corrigées) pour prendre en compte ces erreurs. Et puis tu a aussi la réfraction qu'il faut prendre en compte, bref ce sont à la fin beaucoup d'équations de correction à prendre en compte. J'avais un système bien trop petit pour que cela soit bien calculé (et, j'avoue, pas trop le temps de me replonger dans mes cours de géométrie sphérique) et je me suis arrêté à implémenter l'étape 1, et à concevoir l'étape 2. 

 

Mais c'est intéressant à "poser" sur la table.

 

Marc

 

[aeropic 356]

La programmation des PAP n'est pas si compliquée que ça en utilisant les cartes ARDUINO... Il "suffit" de balancer des ordres "avance d'un pas" toutes les N microseondes pour faire tourner le moteur. Bien sûr tout est dans la gestion précise de la période du pas (N), mais on y arrive.
Tu peux regarder le code de ma table équatoriale que je viens de poster. En une ou deux pages de code ça fait le job, mais il n'y a qu'un axe à gérer. On est loin de la complexité mathématique des fonctions GOTO !
 

 

[PETIT OURS 24 662]

Il y a 2 heures, Pascal C03 a dit :

Ce qui serait bien pour un 1er message,

pour un second aussi  

 

il y a 18 minutes, aeropic a dit :

La programmation des PAP n'est pas si compliquée que ça en utilisant les cartes ARDUINO... Il "suffit" de balancer des ordres "avance d'un pas" toutes les N microseondes pour faire tourner le moteur. Bien sûr tout est dans la gestion précise de la période du pas (N), mais on y arrive.
Tu peux regarder le code de ma table équatoriale que je viens de poster. En une ou deux pages de code ça fait le job, mais il n'y a qu'un axe à gérer. On est loin de la complexité mathématique des fonctions GOTO !

 

[Adamckiewicz 5 681]

Pareil! Je viens de faire une table, avec moteur pas à pas commandé par arduino, rembobinage automatique avec capteurs de fin de course. J’y connaissais rien mais ça se fait très bien! La gestion de la vitesse de suivi est facile en suite, et j’ai pu faire un switch sidéral/lunaire  

[aeropic 356]

il y a une heure, Adamckiewicz a dit :

j’ai pu faire un switch sidéral/lunaire  

Pour la Lune, faut suivre à quelle vitesse ? J'ai compris qu'elle tourne en 24h50 donc un ratio de vitesse = 86164/89400 (~0.9638) ? J'ai bon ?

[Adamckiewicz 5 681]

il y a 58 minutes, aeropic a dit :

Pour la Lune, faut suivre à quelle vitesse ? J'ai compris qu'elle tourne en 24h50 donc un ratio de vitesse = 86164/89400 (~0.9638) ? J'ai bon ?

La Lune fait un tour du ciel en 29j environ, en « tournant » moins vite sur le ciel. Donc la durée du pas doit être 1/29 plus long que le pas de la vitesse sidérale  

Modifié 18 décembre 2023 par Adamckiewicz

[JP-Prost 1 848]

Bonjour,

Il y a 2 heures, Adamckiewicz a dit :

La Lune fait un tour du ciel en 29j environ, en « tournant » moins vite sur le ciel. Donc la durée du pas doit être 1/29 plus long que le pas de la vitesse sidérale  

 

Non pas tout à fait : la période synodique est effectivement d'environ 29j (29.53j plus exactement) mais la période sidérale est de 27.32 jours et c'est elle qu'il faut prendre en compte pour calculer la vitesse apparente de la Lune. Du coup:

• Vitesse sidérale terrestre : 24h moins la rotation de la Terre autour du Soleil en 365.25 jours ==> 24*3600/(1+1/365.25) = 86164.1 secondes et une vitesse de rotation de 360*3600/86164.1 = 15.041arcsec/seconde
• Vitesse sidérale propre de la Lune : 360*3600/(24*27.32*3600) = 0.549 arcsec/seconde ==> le suivi Lunaire doit donc être la soustraction des 2 valeurs puisque la Lune orbite globalement d'Ouest en Est donc 15.041-0.549 = 14.492 arsec/seconde

JP

[Adamckiewicz 5 681]

merci @JP-Prost  je vais corriger ca  

[aeropic 356]

il y a 8 minutes, JP-Prost a dit :

Bonjour,

 

Non pas tout à fait : la période synodique est effectivement d'environ 29j (29.53j plus exactement) mais la période sidérale est de 27.32 jours et c'est elle qu'il faut prendre en compte pour calculer la vitesse apparente de la Lune. Du coup:

• Vitesse sidérale terrestre : 24h moins la rotation de la Terre autour du Soleil en 365.25 jours ==> 24*3600/(1+1/365.25) = 86164.1 secondes et une vitesse de rotation de 360*3600/86164.1 = 15.041arcsec/seconde
• Vitesse sidérale propre de la Lune : 360*3600/(24*27.32*3600) = 0.549 arcsec/seconde ==> le suivi Lunaire doit donc être la soustraction des 2 valeurs puisque la Lune orbite globalement d'Ouest en Est donc 15.041-0.549 = 14.492 arsec/seconde

JP

Merci à vous deux et surtout à JP pour sa réponse exacte...
J'étais pas trop mal puisque 14.492/15.041 = 0,9635 ! Merci

Comme quoi, le plus dur ce n'est pas de faire tourner le moteur PAP ...

 

Modifié 18 décembre 2023 par aeropic

[crub 296]

Il y a 10 heures, aeropic a dit :

La programmation des PAP n'est pas si compliquée que ça en utilisant les cartes ARDUINO... Il "suffit" de balancer des ordres "avance d'un pas" toutes les N microseondes pour faire tourner le moteur. Bien sûr tout est dans la gestion précise de la période du pas (N), mais on y arrive.

 

Pour la mise au point, il y a pas à se prendre la tête, juste faire avancer du bon nombre de pas à une vitesse raisonnable pour que le dispositif est le temps de tourner.

Pour le suivi (pour la photo), on a souvent besoin d'utiliser des "micropas" et soit on a un contrôleur qui les fabrique, soit faut les faire par programmation.

 

Un "micropas", c'est en fait le dosage du courant entre les 2 bobines pour que le moteur se positionne non pas en face de l'un des pôles, mais plus ou moins (selon le rapport des courant) entre les 2.

Si on fait une électronique genre ampli qui ajuste l'intensité dans chaque bobinage, l'énergie non utilisée dans le moteur va être dissipée sous forme de chaleur dans l'ampli ... et il va chauffer.

On va donc activer plus ou moins longtemps les 2 bobines du moteur MAIS il faut que cela soit fait à une fréquence assez élevée pour que les inductances lissent les intensités et que les inerties mécanique finissent ce "filtrage" et pas trop élevée pour que les transistors de sortie aient le temps de basculer (et autant que possible de fonctionner en mode saturé (sinon, ils chauffent, gaspillent de l'énergie et risquent de cramer).  Cela s'appelle un PWM (Pulse WIdth Modulation).

 

Après, il y a 2 principes possible pour les micropas:

1 - on calcule l'instant auquel il faudra appliquer  le prochain micropas (le nombre de micropas est donc prédéterminé) et on applique le PWM.

2 - A période/fréquence fixe, on "calcule le micropas", c'est à dire les sens d'activation et les quotités des activations des 2  bobines  (le PWM), puis on applique. La fréquence est choisie en fonction des besoins de suivi: par exemple si l'objectif est 1/2 arc/sec, pour avoir de la marge et lisser la commande, on va faire 5 fois mieux, cela correspond à 150 hertz (pour un mouvement sidéral de 15 sec/arc par secondes).

 

Ensuite, il faut générer les micropas:

1 - c'est le driver de moteur pas à pas qui le fait (le nombre de micropas est déterminé par le contrôleur)

2 - C'est le microprocesseur qui le fait

     2.1 par logiciel

     2.2  par la programmation de circuit de production de PWM.

 

Pour implémenter 2+2.2, il y a de quoi s'amuser.