Tenkaichi

Motorisation Dobson

Messages recommandés

C'est peut-être mieux effectivement pour des débutants comme Tenkaichi et moi,

de se dégrossir en respectant bien les axes, pour "voir comment ça marche",

plutôt que de se reposer sur des calculs qu'on ne maitrise pas...

Modifié par FroggySeven

Partager ce message


Lien à poster
Partager sur d’autres sites

En effet travailler avec des coordonnées azimutales pures est bien plus pratique, sinon le changement de repère risque d'être prise de tête à réaliser... bref !

 

Michelectron, tu parles dans un de tes postes de codeurs, pourrais-tu m'indiquer ceux que tu utilises svp?

Partager ce message


Lien à poster
Partager sur d’autres sites

J'interviens car moi aussi le sujet m'intéresse... (une monture motorisée faite maison, car dans mon cas, le telescope n'est pas standard).

L'altazimutal est quand même plus délicat à concevoir: la vitesse des moteurs doit être variable, et donc:

- le couple varie, et donc la possibilité de rater des pas aussi...

- la gestion des ralentissements/accélérations aussi (pour limiter les risques de pertes de pas, les vibrations et oscillations de la monture)

 

Pour les codeurs, ceux que j'ai vu (15-20EUR, cités ici dans ce forum) impliquent une courroie et comptent des pas également. Ils n'indiquent donc pas un angle dans l'absolu. Mais c'est peut-être suffisant?

En tous cas, il faut absolument que l'Arduino (ou autre) ne rate aucune impulsion venant de l'encodeur sinon la mesure est faussée. Donc utiliser des interruptions ou un circuit dédicacé?

C'est du langlais, mais ce montage-ci me semblait plutôt bien (et exhaustif):

http://rduinoscope.byethost24.com/

C'est bien compatible altazimutal ou equatorial. Par rapport à la question du couple, des accélérations/ralentissements, je ne sais pas encore bien comment c'est géré.

Si vous avez des avis, je suis preneur également :)

 

 

  • Merci 2

Partager ce message


Lien à poster
Partager sur d’autres sites

Mes codeurs je les ai bidouillés (disque imprimé pour l'un et plaque de plastique découpée pour l'autre placé directement sur l'axe du moteur. On peut parfaitement les placer en tête de démultiplication si on compense les jeux. Chez moi, la compensation en hauteur se fait en plaçant une masse au bon endroit: le tube a toujours tendance à descendre. Pour l'azimut, j'ai mis un petit moteur à courant continu alimenté à travers une résistance. Il a juste la force de compenser le jeu mais se laisse entraîner par le  moteur d'azimut.

À noter pour les codeurs qu'il faut 2 fourches opto décalées d'1/2 de pas. Si on détecte chaque transition avec son sens et qu'on applique la logique qui va bien, la résolution correspond à 1/4 de pas.

Toutefois, je suis un mauvais mécanicien, avec du matériel pas terrible et au final, mon bidule n'est pas un modèle de précision. Mais comme je ne fais que du visuel, c'est largement suffisant pour moi.

  • Merci 2

Partager ce message


Lien à poster
Partager sur d’autres sites

michelectron: Merci pour ton retour :) Si j'ai bien compris, ton système est constitué de roues codeuses? au final, ça donne quelle résolution par tour? Les roues ont été faites par découpeuse numérique?

 

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

J'ai une petite question pour la conversion equatoriale / azimutale. J'utilise le site web suivant (http://www.stargazing.net/kepler/altaz.html) dans lequel l'expression des angles horizontal et azimutal. A un moment l'angle horaire est défini en fonction de "Local Sideral Time" soit le temps sidéral local, lui même défini comme étant fonction du nombre de jours passés depuis la date J2000 correspondant au 1er janvier 2000, la longitude du lieu d'observation et le temps universel. Or je n'arrive pas a comprendre/trouver ce qu'est ce temps universel, le terme universel fait penser que cette une valeur universelle peu importe la position sur Terre. Une idée ?

 

EDIT: Ne serait-ce pas l'heure pour UTC ? Je tenterai le calcul pour voir si cela correspond.

 

Modifié par Tenkaichi
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Je viens de finir d'écrire mon bout de programme, je viens de faire un test avec andromède et mes calculs sont proches de ceux de Stellarium, à moins d'un degré pour la hauteur et quelques degrés d'écart pour l'azimut..

Partager ce message


Lien à poster
Partager sur d’autres sites
Invité

Ola

J'avais pas lu ce post.

Il y a quelques anneries que je corrige : xD

Citation

 

Le Picastro (l'ancètre de l'astroEQ) fait tourner les moteurs à la bonne vitesse.

L'astroEQ fait tourner les moteurs pour le pointage, mais il y a un soucis à basse vitesse.

 

Faut il existe maintenant une version ou il est possible de rester toujours en µpas. Autrefois, le soft changeait la config du driver (pas entier/µpas) et au passage perdait des pas.

 

Citation

En utilisant un encodeur couplé avec un engrenage de plus gros diamètre on peut arriver à une mesure angulaire assez précise (je n'ai pas fait de calculs encore) malgré la faible précision de l'encodeur (et donc le faible prix !!), non?

Non, il faudrait que l'ensemble ne génère pas d'erreur périodique... Les billes d'un roulement en génèrent... c'est pourtant pas trop mal rond. lol
 

Citation

 

quitte à faire une grande roue, autant y mettre directement dessus un truc genre une feuille transparente imprimée avec les stries qui vont bien ?

     Est-ce que ce type de feuille coûte d'ailleurs si chère déjà toute faite ?

 

Fabriquer un encodeur avec une feuille... Mouais, construire un dobson de 600 en pate à modeler quoi !!!


 

Citation

 

En tous cas, il faut absolument que l'Arduino (ou autre) ne rate aucune impulsion venant de l'encodeur sinon la mesure est faussée. Donc utiliser des interruptions ou un circuit dédicacé?

 

Et à quoi sert l'encodeur ? Pour compter les pas du moteur pas à pas... Ok, z'êtes bizarre les gars. Si on envoi 20 pas, il fait 20 pas... Non ?

 

 

Modifié par Invité

Partager ce message


Lien à poster
Partager sur d’autres sites

pour la derniere question, non: si l'encodeur envoie 20 pas et que l'Arduino loupe le signal (parce qu'il n'interroge pas son port digital in associé au bon moment, lorsque l'impulsion de comptage passe), on ne compte donc pas les 20 pas envoyés. Pour éviter ça: soit utilisation des interrupt (le code en cours s'interromp pour traiter le signal venant du digital in) soit utilisation d'un arduino dédicacé pour être sûr que rien n'interfère dans le comptage. Et cet Arduino fournit ensuite au contrôleur maitre, à la demande, l'info de comptage (cette opération étant gérable en multitâche).

 

Sinon, pour la feuille, y'a feuille et feuille comme toujours (on peut graver des feuilles de verre, si si...) ... Et si ca se dilate à priori, l'écart angulaire reste le même... Par contre, c'est pas avec ça qu'on pourra compter des très petits angles inférieurs à 1°...

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 1 heure, Cecil-Kris a dit :

Faut [sic] il existe maintenant une version ou il est possible de rester toujours en µpas. Autrefois, le soft changeait la config du driver (pas entier/µpas) et au passage perdait des pas

Je crois qu'on ne s'est pas compris. Je ne dis pas l'astroEQ fait ci, le Picastro fait ça... Je décris juste où j'en suis ("mon" astroEq fait ci, "mon" picastro fait ça).

 

 

Encodeur : il y a un truc que je n'ai pas compris. C'est l'encodeur qui prend l'initiative de l'envoi des données, ou le picastro qui  interroge quand ça lui chante l'encodeur ?

 

bah même avec une bête feuille transparente, on peut facilement atteindre 3 lignes par mm... et sur un disque de 20cm de diamètre ça permet de descendre en dessous du °  (sans atteindre un précision "astronomique" ;) certes).

Modifié par FroggySeven

Partager ce message


Lien à poster
Partager sur d’autres sites

C'est l'Arduino qui interroge l'encodeur. (A moins que: j'y reviendrai)

 

Soit l'Arduino scanne le disque en permanence et rapidement (polling) et si le capteur d'encodeur change d'état, l'Arduino le voit. Au risque d'être "distrait" par une routine du programme qui prenne un peu trop de temps. Le polling utilise beaucoup de CPU pour être efficace (donc ce temps processeur n'est pas dispo pour autre chose et l'Arduino tourne à fond la caisse).

 

Soit au changement d'état de l'encodeur,  le signal généré sur la (les) pin(s) concernés de l'Arduino provoque le déclenchement d'une interrupt qui permette de comptabiliser l'impulsion reçue ( -> beaucoup mieux, mais on n'a pas 10000 signaux d'interruption dispo sur un Arduino).

 

Soit encore (le "à moins que") on dédicace un Arduino à la tâche exclusive de lecture du capteur de l'encodeur. Et l'Arduino "maitre" l'interroge quand il veut. Vu le prix et la faible conso des Arduino, pourquoi pas.

 

 

Modifié par Jijil

Partager ce message


Lien à poster
Partager sur d’autres sites
Invité
Citation

Je crois qu'on ne s'est pas compris. Je ne dis pas l'astroEQ fait ci, le Picastro fait ça... Je décris juste où j'en suis ("mon" astroEq fait ci, "mon" picastro fait ça).

Fais une mise à jour du firware de l'astroeq ça evitera le probleme...

 

Sinon, j'ai toujours pas compris à quoi sert un encodeur sur un moteur pas à pas...?

Partager ce message


Lien à poster
Partager sur d’autres sites

1) Merci du tuyau :) !!!!!!!!

 

2) A vrai dire moi non plus. Effectivement une bête initialisation (étoiles ou repère sur la monture) devrait suffir.

Pourtant  je me demande si ce n'est pas toi (???)

qui comparait la qualité des encodeurs qu'on trouve dans les montures goto avec ceux des machines outils

("encodeurs de machines-outils chinoises bas de gamme").

OU ALORS LES ENCODEURS C'EST SEULEMENT POUR LES "PUSH-TO" ???

Modifié par FroggySeven

Partager ce message


Lien à poster
Partager sur d’autres sites
Invité

Oui, c'est bien moi, cette comparaison... MAIS :

Je parfais de fabriquer une monture aussi précise qu'une EQ8, plus rapide, moins bruyante, avec une meilleur erreur périodique.

Pour cela, je partais sur l'utilisation de servo moteur, et donc, d'encodeur haute définition.

Partager ce message


Lien à poster
Partager sur d’autres sites

Histoire de continuer sur les notions de bases :

pourquoi ce rôle de retour d'information ne pourait-il pas "simplement" être tenu par l'autoguidage ?

Modifié par FroggySeven

Partager ce message


Lien à poster
Partager sur d’autres sites
Invité

Quel taille ton capteur pour l'autoguidage ?

 

Je veux dire par là : Penses tu que la taille de ton capteur englobera tout le ciel ? 180° ? Il faudrait cela pour avoir une contre réaction...

 

D'ailleurs je répète ma question :

Citation

Sinon, j'ai toujours pas compris à quoi sert un encodeur sur un moteur pas à pas...?

 

Modifié par Invité

Partager ce message


Lien à poster
Partager sur d’autres sites

Je me demandais: à quels capteurs de position tu pensais, Cecil-Kris ?

Pour l'autoguidage, je n'ai pas d'expérience, mais c'est quand même pas le plus rapide à mettre en oeuvre non?

Sinon, autre idée: utiliser le capteur de déplacement d'une souris optique, sur un disque quel qu'il soit (pas spécialement gradué)

 

 

Modifié par Jijil
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Invité
Citation

Sinon, j'ai toujours pas compris à quoi sert un encodeur sur un moteur pas à pas...?

 

Et pour répondre à ta question : Avec ces servo là :

https://granitedevices.com/digital-servo-drive-argon/

 

J'utilisais ce genre de codeur :

https://www.heidenhain.fr/fr_FR/produits/

 

Bon, c'est un peu cher pour une monture. Disons le prix d'une EQ8 juste le capteur. lol

Modifié par Invité

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 31/12/2017 à 13:18, Jijil a dit :

utiliser le capteur de déplacement d'une souris optique

C'est hors de ma portée question programmation, mais c'est une super idée d'utiliser une "bête" souris optique !!!!!!

Partager ce message


Lien à poster
Partager sur d’autres sites
Invité

Super idée oui... Avec une répétabilité de la mesure quasi impossible. On pointera à 20° près. :D

 

Pour l'encodeur sur un pas à pas, vous ne savez pas non plus pourquoi en installer un...? ¬¬ Bon, je ne poserais plus la question. :P

Partager ce message


Lien à poster
Partager sur d’autres sites

Le probleme des moteurs pas à pas, c'est qu'ils peuvent rater des pas si le couple de la charge est supérieur à celui du moteur (ce qui ne devrait pas arriver, mais peut arriver tout de même)

Je peux me tromper: selon mon idée, un encodeur optique est un moyen de:

1- s'assurer que la vitesse de déplacement correspond à celle espérée

2- ajuster la vitesse de déplacement

2- s'il y a un étalonnage des coordonnées, pouvoir pointer une coordonnée "précise", selon ce que l'encodeur peut fournir en termes de précision

Partager ce message


Lien à poster
Partager sur d’autres sites
Invité

C'est bien ce que je pensais.

1 La vitesse de déplacement correspondra exactement à la fréquence des pas à l'entrée de ton driver

- Si elle ne correspond plus, ton système est planté, tu as perdu des pas, tu ne pourras pas les rattraper.

Remède = améliorer ta mécanique/puissance moteur/réduction.

 

2 La vitesse de déplacement s'ajustera comme dit ci dessus en fonction de la fréquence présente sur l'entrée de ton driver. L'encodeur ne permet pas plus ou moins un 'ajustement' de cette vitesse.

 

3 Si il y a un étalonnage, disons simplement un fin de course, ou techniquement un "homming", alors, en comptant les pas, tu sauras exactement ou se situe ta monture.

- Si la position ne correspond pas/plus, ton système est planté, tu as perdu des pas, tu ne pourras pas les rattraper.

Remède = améliorer ta mécanique/puissance moteur/réduction.

 

Dans tous les cas, il faut savoir que 99% des montures équipées avec des moteurs pas à pas fonctionnent SANS encodeur, même lorsqu'elles en sont équipées. L'AZEQ6 et l'EQ8 que je possède fonctionne en débranchant les encodeurs. L'encodeur sert uniquement lorsque tu débrayes les freins et décales manuellement les axes. Alors, les encodeurs donnent la nouvelle position. (sur l'EQ8 l'encodeur corrige aussi l'erreur périodique, mais dans ce post on est loin loin d'en causer)

 

Donc, pour résumer, tu te fais chier à mettre un encodeur, qui t'allume un voyant quand ça tourne plus... Et dans ce cas, c'est mort, tu recommences ta mise en station.

Un encodeur peu servir sur un systeme servo en boucle fermé. Là, si y'a un point dur dans la mécanique, le servo va envoyer la sauce jusqu'à atteindre la position demandé.

Et avec un servo, faut que l'électronique assure, car la limite sera souvent la mécanique qui casse. J'ai vu des paliers en fonte arraché, des vis à bille de diamètre 50mm vrillées, etc...

Modifié par Invité

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour, et bonne année ! :)

 

J'ai une question a vous poser , quand je vais sur Stellarium et que je pointe une galaxie (au hasard M31 9_9), et que j'affiche ses coordonnées équatoriales, Alt-azimutales, etc.. le logiciel m'affiche les coordonnées équatoriales à la date J2000 et à la date du jour. Du coup j'aimerais bien savoir comment calculer les coordonnées équatoriales à la date du jour en fonction de J2000, car finalement c'est de celles-ci dont j'ai besoin...

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonne annee :-) !

 

Non, l'autoguidage semble quelque chose de plus simple a mettre en place qu un goto fait maison, tout simplement parce que c est quelque chose d extremement courant. 

 

Cecile kris : je n ai personnellement jamais voulu installer de goto... mais ce n est peut etre pas la peine de s amuser a se faire peur avec le prix des capteurs pro. Dans la mesure où le guidage n a besoin d etre extrement precis qu'en valeur relative (guidage...), il existe probablement des solutions DIY d une precision suffisante pour apporter un confort reel (genre pointer une etoile facile a visualiser a cote du sujet avant de se deplacer en valeurs relatives jusqu au sujet).

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant