FroggySeven 182 Posté(e) 28 décembre 2017 (modifié) 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é 28 décembre 2017 par FroggySeven Partager ce message Lien à poster Partager sur d’autres sites
Tenkaichi 5 Posté(e) 28 décembre 2017 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
Jijil 265 Posté(e) 29 décembre 2017 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 2 Partager ce message Lien à poster Partager sur d’autres sites
michelectron 69 Posté(e) 29 décembre 2017 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. 2 Partager ce message Lien à poster Partager sur d’autres sites
FroggySeven 182 Posté(e) 29 décembre 2017 Merci beaucoup pour tous ces retours d'expérience Ben y'a pu qu'à s'y mettre... Partager ce message Lien à poster Partager sur d’autres sites
Jijil 265 Posté(e) 29 décembre 2017 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? 1 Partager ce message Lien à poster Partager sur d’autres sites
Tenkaichi 5 Posté(e) 29 décembre 2017 (modifié) 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é 29 décembre 2017 par Tenkaichi 1 Partager ce message Lien à poster Partager sur d’autres sites
Tenkaichi 5 Posté(e) 30 décembre 2017 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é Posté(e) 30 décembre 2017 (modifié) Ola J'avais pas lu ce post. Il y a quelques anneries que je corrige : 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é 30 décembre 2017 par Invité Partager ce message Lien à poster Partager sur d’autres sites
Jijil 265 Posté(e) 30 décembre 2017 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°... 1 Partager ce message Lien à poster Partager sur d’autres sites
FroggySeven 182 Posté(e) 30 décembre 2017 (modifié) 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é 30 décembre 2017 par FroggySeven Partager ce message Lien à poster Partager sur d’autres sites
Jijil 265 Posté(e) 30 décembre 2017 (modifié) 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é 30 décembre 2017 par Jijil Partager ce message Lien à poster Partager sur d’autres sites
Invité Posté(e) 31 décembre 2017 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
FroggySeven 182 Posté(e) 31 décembre 2017 (modifié) 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é 31 décembre 2017 par FroggySeven Partager ce message Lien à poster Partager sur d’autres sites
Invité Posté(e) 31 décembre 2017 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
FroggySeven 182 Posté(e) 31 décembre 2017 (modifié) 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é 31 décembre 2017 par FroggySeven Partager ce message Lien à poster Partager sur d’autres sites
Invité Posté(e) 31 décembre 2017 (modifié) 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é 31 décembre 2017 par Invité Partager ce message Lien à poster Partager sur d’autres sites
Jijil 265 Posté(e) 31 décembre 2017 (modifié) 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é 31 décembre 2017 par Jijil 1 Partager ce message Lien à poster Partager sur d’autres sites
Invité Posté(e) 31 décembre 2017 (modifié) 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é 31 décembre 2017 par Invité Partager ce message Lien à poster Partager sur d’autres sites
FroggySeven 182 Posté(e) 1 janvier 2018 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é Posté(e) 2 janvier 2018 Super idée oui... Avec une répétabilité de la mesure quasi impossible. On pointera à 20° près. Pour l'encodeur sur un pas à pas, vous ne savez pas non plus pourquoi en installer un...? Bon, je ne poserais plus la question. Partager ce message Lien à poster Partager sur d’autres sites
Jijil 265 Posté(e) 2 janvier 2018 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é Posté(e) 3 janvier 2018 (modifié) 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é 3 janvier 2018 par Invité Partager ce message Lien à poster Partager sur d’autres sites
Tenkaichi 5 Posté(e) 4 janvier 2018 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 ), 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
FroggySeven 182 Posté(e) 5 janvier 2018 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