Correction EP par variation de vitesse

[Didou]

En fouillant et lisant j'ai vu cet article qui conserne la correction d'EP par variation de la vitesse de suivi.

Ca correspond un peu au PEC, mais est-ce aussi efficace qu'annoncé et quelqu'un utilise-t-il cette méthode?

http://www.freewebs.com/eq6modfr/eqspeed.htm

En plus de l'autoguidage,est ce que cela fonctionne?

[Fred_76]

Qu'est-ce que la variation de vitesse de suivi ? Les montures sont mises en mouvement par des moteurs pas-à-pas et tournent donc de façon discrète et non continue. Passer à une vitesse plus importante/faible revient à ajouter/retirer des (micro) pas dans la séquence. C'est pareil que la PEC classique ou même que l'autoguidage.

 

Et il me semble que l'autoguidage prédictif fait un peu la même chose, non ?

 

Le seul truc qui serait effectivement bien, c'est d'avoir un encodeur sur la position de la VSF (et peut être aussi de la couronne) qui permettrait de caler parfaitement la correction PEC avec la position de la VSF (et de la couronne). Associé à un entrainement par courroies à la place des engrenages, on se retrouve avec une monture pro.

 

L'alternative serait un autoguidage prédictif avec apprentissage de l'erreur périodique (et recallage automatique pour ne pas avoir à tout refaire à chaque nouvelle session). Il pourrait alors combiner tout ça pour améliorer le suivi. N'est-ce pas ce que fera le futur Pic Astro ?

[arnaud.gerard]

Salut,

c'est amusant car j'ai ressorti hier les évaluations que j'avais faites et que je pense intégrer ultérieurement à PIC-ASTRO si j'ai le temps de continuer l'analyse.

 

Je confirme que la méthode a du bon, en théorie, au moins pour les montures bas ou milieu de gamme. J'aurais bien ajouté des courbes mais depuis mon dernier post les choses ont changées, il va falloir que je regardes ça.

 

Pour en revenir au sujet, je ne vais pas m'y étendre maintenant car vu les retard pris sur les développement de PA-A2 ( dus à des bugs du nouveau PIC)je ne pourrais pas présenter celui-ci aux GRAO et je pense faire une présentation des problèmes de l'autoguidage: que ne peut-on pas faire mais comment faire au mieux. Lorsque cette présentation sera faite, après les multitude de critiques que je vais recevoir , je ferai un retour. Je précise que pour moi ce n'est que théorique et que c'est après avoir implémenter cette fonctionnalité et après les essais effectués par les utilisateurs qu'on pourra reconnaître ou pas le bien fondé de ce principe.

 

En fait je n'ai pas répondu directement à la question donc voici des éclaircissements.

 

la FFT de l'EP et la courbe d'EP permettent de comprendre le phénomène.

L'erreur maximale est la période de la vis sans fin soit 300 à 600s.

 

Pour une période P des ordre de correction ( autoguidage) de 2s, il est impossible de corriger les erreurs de période inférieure: l'erreur minimale est donc l'erreur maximale de la FFT entre 0 et 2s ( pas facile à suivre, il faut bien relire). Cette valeur Vmin est le mieux qu'on puisse espérer .

Le reste un un peu plus compliqué à expliquer et c'est le coeur du sujet, un dessin vaut mieux qu'un long discours. si la pièce jointe passe.

 

 

Arnaud

 

Edit:

La courbe présentée est une courbe réelle après filtrage des erreurs hautes fréquence pour simuler une très bohnne monture.

Des simulations ont été aussi réalisées sur des courbes théoriques ( triangle, sinus) avec ajout d'un bruit aléatoire.

Les résultats sont du mêmes ordre de grandeur.

Modifié 15 mars 2012 par arnaud.gerard

[arnaud.gerard]

Je tenais à faire la réponse en 2 posts,

 

pour bien faire comprendre le seul inconvénient qui est visible sur la courbe:

celle-ci survient, inévitablement, lorsque la variation de l'erreur change de sens.

 

C'est totalement normal puisque la prédiction modifie la vitesse de suivi, si l'erreur augmente de xAsec/s on corrige la vitesse de cette valeur mais à un moment donné la vitesse d'erreur change de sens, elle passe à -yAsec/s on a alors une l'erreur devitesse de suivi est x+y ( valeur max qui est statistiquement divisée selon le moment u l'erreur change de sens entre les 2 ordres de correction).

 

Arnaud

[christiand]

Bonsoir

 

J'ai lu l'article mis en lien en début de post. J'avoue que je ne suis pas totalement convaincu de l'intérêt du systéme, mais je ne demande qu'à l'être

 

Christian

[Eguzkiarte]

Ma question va peut-être vous paraître stupide, mais pourquoi ne pas "filtrer" ces EP de courte période mécaniquement, par exemple avec une roue à forte inertie (masse et/ou vitesse de rotation)?

[arnaud.gerard]

Salut Christian,

 

oui l'article n'est pas probant. Normal, il se veut vendeur, sans approche réellement convaincante. Mais je pense que c'est à tester avant de jeter.

 

Mon approche est différente: une idée ( 2010), présentation de cette idée, réception des avis contradictoires, prise en compte des remarques pertinentes, intégration dans une version de test, analyse des résultats si retour.

 

En gros, je ne fais que suggérer, on en cause, je fais et on teste.On ne peut plus démocratique et surtout pragmatique.

 

Entre-temps, le post de Pascal est tombé. La réponse est simple et directe: les erreurs de faibles périodes ne peuvent être réduites que par un système de transmission par poulie et courroie. Dans ce domaine il y a des avancées avec les poulies/courroies RPP. Etant donné la très faible période de rotation l'inertie est négligeable.

 

Arnaud

[Eguzkiarte]

La réponse est simple et directe: les erreurs de faibles périodes ne peuvent être réduites que par un système de transmission par poulie et courroie. Dans ce domaine il y a des avancées avec les poulies/courroies RPP. Etant donné la très faible période de rotation l'inertie est négligeable.

 

Arnaud

Effectivement, réguler le mouvement en final ne permettrait pas un système de régulation inertiel rotatif, car, comme tu le dis, la vitesse de rotation d'un tour par 24h ne permet pas un stockage d'énergie suffisant.

Mais la régulation électronique agit côté moteur (avec une mesure côté instrument), là où les vitesses de rotations sont beaucoup plus importantes et permettraient d'ajouter un volant d'inertie!

Mais s'il s'agit de lisser le mouvement et les erreurs périodiques dues au système d'entrainement lui-même, côté instrument, pourquoi ne pas utiliser des systèmes largement utilisés comme les régulateurs hydrauliques, ceci, bien sûr, en plus de la régulation électronique "en feed back" qui a ses limites en ce qui concerne les erreurs de courte période?

J'espère que mon propos n'est pas trop embrouillé:?:

[astrocloclo]

développement de PA-A2

 

Bonjour Arnaud

je possède un PA1 de première génération que j'avais acheté à Gibhem

il fonctionne toujours nickel .

 

Mais je comprends dans ton post qu'un nouvelle version est en cours de développement .. cela inclura t'il un changement du hardware ? nouvelle carte, composants, moteurs etc ??

si c'est le cas, doit on s'inscrire pour un achat groupé etc etc.... ??

 

ou les nouvelles fonctionnalités et modifications ne seront que logicielles ?

 

D'avance merci de ta réponse

Astroamicalement

 

Claude

[OrionRider]

Voilà un post qui m'intéresse au plus haut point, ayant développé un autoguidage 'perso' pour corriger les erreurs de mon EQ2, puis de ma Vixen NP.

 

L'EP de l'EQ2 est gigantesque (image 1) comme vous pouvez l'imaginer, mais j'étais arrivé à des résultats en utilisant de simples moteurs à courant continu. Ces moteurs pour EQ2 coûtent une trentaine d'euros. J'ai complètement viré la (mauvaise) électronique chinoise et simplement ajouté un pot 1K en série.

 

Dans mon implémentation, la résistance appliquée changeait en fonction des correction à effectuer, selon trois 'vitesses': neutre = valeur du pot, Est = (pot-100ohm), Ouest = (pot+100ohm) + un inverseur pour le sens de correction. Les corrections se faisaient via des relais, par 'impulsions'. Le résultat est une courbe en dents de scie de faible fréquence et amplitude (image 2).

 

 

Le top aurait été de pouvoir programmer un PIC pour changer la vitesse de façon analogique. Je pense qu'il aurait été possible d'obtenir un résultat vraiment spectaculaire, même avec cette monture pourrie. Hélas, je suis programmeur, pas électronicien...

 

Pourquoi utiliser des moteurs 'pas à pas' très précis si de toute façon on doit changer leur vitesse?

Un moteur à courant continu a un fonctionnement bien plus souple, moins de vibrations et on peut régler sa vitesse très simplement et de façon progressive. En plus ces moteurs sont bon marchés et puissants (j'en ai vu sur des tables équatoriales pour Dob 400).

 

Pour résumer: pourquoi ne pas utiliser de moteurs CC?

[Fred_76]

C'est sur si tu changes tout, autant mettre des moteurs à courant continu. Mais si tu veux conserver le maximum et ne gérer le suivi que de façon logicielle, on doit garder les moteurs existants, et ce sont des moteurs pas a pas. Il n'y a que les encodeurs à installer sur les arbres (si c'est possible... ).

[Didou]

Les moteurs Pas à pas sont en effet pas "lisse"

Après c'est la fréquence qui le rend lisse

Dans EQMOD, il y a un paramètre à 15.06 et des bananes qui donne la vitesse de rotation stellaire.

Le guidage par variation de vitesse viendrait donc faire varier cette vitesse.

J'y verrais un avantage c'est débiter les impulsions négatives et positives en RA qui dégrade le suivi quand le backslash est très important.

 

"Ralentir" la rotation serait mieux que d'envoyer des pulses négatives je pense.

 

Faudra d'abord que je maitrise le guidage 'classique' avant de me lancer dans ce genre de test

 

Au final, je crois que peu de personne utilise la variation de vitesse, il y a peut être une raison : la simplicité de l'autre méthode...

 

Merci pour cette participation.

[christiand]

Je n'ai pas tout pigé : comment obtient on le parametrage pour faire varier la vitesse ?

On fait un enregistrement à la manière d'une table PEC que l'on conserve en mémoire ? C'est cela ?

 

Christian

[Didou]

Je pense (mais c'est juste moi) que EQMOD envoit la vitesse stellaire à la monture, puis ensuite des impulsions dans le cas "normal"

C'est pour cela que si EQMOD plante, la monture continue à tourner seul (sur les EQ6 et HEQ5 en tout cas, les autres, je ne les connait pas).

Donc la monture garde en "mémoire" une vitesse de rotation.

 

Dans le guidage par variation de vitesse, il doit juste envoyer une nouvelle vitesse de suivie à chaque mouvement de l'étoile guide et donc pas d'impulsion de rattrapage, c'est juste la vitesse qui varie (QUID de l'axe AD bien sûr?? )

 

PS: en relisant, ce serait plutôt un PEC de vitesse enregistré donc le guidage serait toujours sous forme d'impulsion RA+/ RA- ??

[christiand]

PS: en relisant, ce serait plutôt un PEC de vitesse enregistré donc le guidage serait toujours sous forme d'impulsion RA+/ RA- ??

 

 

Oui, si je comprends bien c'est un peu le même principe qu'un PEC;

Alors que la table PEC enregistre les écarts de l'étoile guide toutes les 10 ou 15 secondes, ici c'est la vitesse qui varie selon l'EP. Donc c'est mieux lissé.

 

Donc il faut bien enregistrer une "synchro", un top départ avec la VSF, tout comme un PEC.

 

J'ai souvent utilisé le PEC, le soucis c'est le décalage progressif de la table par rapport à l'EP, à cause du jeux dans la VSF.

Aprés quelques utilisations (et surtout quelques Goto..) les pics de la table PEC ne coincident plus avec les pics de la VSF. Les 2 courbes s'écartent et on finit par corriger "à coté".

 

Bref c'est un peu casse pied et il faut ré enregistrer la table fréquemment.

 

 

 

Bon, laissons faire Arnaud qui nous apportera prochainement des commentaires sur cette méthode.

 

 

 

Christian

[arnaud.gerard]

Salut,

 

j'ai pris du retard, comme d'hab. Je commence par préciser que je n'ai aucune expertise dans le domaine ce que je dis ne doit être pris que comme des idées. Actuellement je ne travaille que sur des simulations sous Excel, le problème c'est qu'avec un 4 cores c'est plus de 2 heures de calcul, il faut que je refasse la même chose en C/C++, si nécessaire.

 

Je peux même dire que la méthode est pire que mieux dans certains cas. Ce n'est pas que la méthode est mauvaise mais qu'elle doit être améliorée et on tombe sur le problème de répartition des clculs entre PC et PIC.

 

Je rajoute à mes posts précédents: la valeur Vmin ne concerna que la mécanique en réalité Vmin sera la valeur de la turbulence si celle-ci est supérieure à Vmin.

 

Claude: la version A2 n'est pas pour demain, les moteurs seront les mêmes que pour la version A1. Les évolutions hard ont été faites pour éradiquer les problèmes connus, principalement les résistances série qui disparaissent purement et simplement. Coté hard/soft les 2 bobines sont pilotés simultanéement, donc plus grande précision et plus faible consommation. A noter que la fluidité des moteurs est améliorée par une augmentation des µpas générés. Le A2 devrait déjà fonctionner mes des bugs bloquants du PIC choisi m'a obliger à trouver d'autres solutions sans tout casser, elles sont en cours de réalisation.

 

OrionRider: les moteurs CC sont beaucoup plus facile à piloter que des moteurs pas à pas. PIC-ASTRO peut générer n'importe quelle vitesse avec une précision de 5e-4, il est donc à même de modifier la vitesse de suivi par pas de 0.006Asec/s. En pièce jointe une courbe réelle, non simulée montre que certains traitements permettent d'amener l'erreur à 0.

 

Didou: si les vitesses d'autoguidage AD sont généralement 0.5X et 1.5X c'est justement pour qu'il n'y aie jamais d'inversion du moteur AD. Comme tu le dis, il ralentit mais jamais en inverse. Personne n'utilise cette méthode, c'est en fait que les choix techniques et les logiciels ne peuvent pas modifier les vitesses d'une valeur suffisamment faible.Là je m'avance un peu, je n'ai pas regarder depuis longtemps si des progrès avaient été faits.

 

Christiand: voilà une question intelligente, l'information n'est actuellement transmise par les logiciels d'autoguidage, il faut la créer. Il existe un moyen simple: dater les ordre de correction on dispose alors de l'écart angulaire ( la correction) et le temps ( durée entre 2 corrections). C'est un calcul simple.

9a répond à ton second post: rien avoir avec la PEC( la daube) c'est du calcul en live.

 

 

Arnaud

Modifié 17 mars 2012 par arnaud.gerard

[christiand]

salut Arnaud

 

l'information n'est actuellement transmise par les logiciels d'autoguidage, il faut la créer. Il existe un moyen simple: dater les ordre de correction on dispose alors de l'écart angulaire ( la correction) et le temps ( durée entre 2 corrections). C'est un calcul simple.

 

Oui, j'imagine qu'il existe d'autres moyens plus efficaces que la table PEC.

 

Mais pour ma curiosité, comment fais tu pour synchroniser les variations de vitesse du moteur (= la courbe de correction) avec celle des EP de la vis de la vis sans fin ?

Pendant le tracking ces 2 courbes doivent être parfaitement synchro, quasi superposables si je puis dire.

 

Enfin une derniére question, ensuite je te laisse tranquille : Si la courbe de vitesse est lissée (comme on le voit sur les courbes présentées), comment corrige t on les harmoniques de fréquences élevées d'origine mécanique ?

 

 

Ces questions montrent probablement mon incompréhension sur ce principe. Je suis un peu "lourd", désolé. Une fois que j'aurais compris ça ira nettement mieux, il me faut du temps

 

 

Christian

[arnaud.gerard]

A priori nous ne nous plaçons pas sur le même point de vue. Je vais donc expliciter le mien.

 

Je raisonne autoguidage donc une ccd ou webcam couplée à un logiciel sur PC qui se charge d'interpréter la dérive de la cible et à période constante envoie à la monture un ordre de correction. Cet ordre est effectué à une vitesse de +-0,5X par rapport à la vitesse de suivi donc +-0.5X en Dec et 0.5X/1.5X en AD. La mesure étant "instantannée", il n'y a pas besoin de synchronisation. Si la période de correction est de 2s, toutes les 2s le logiciel envoie l'ordre pour compenser la dérive constatée durant ce délai.

 

La dernière courbe permet simplement d'obtenir une vitesse moyenne la plus proche possible de la vitesse demandée. Le principe est le même pour l'autoguidage sauf que la période de correction est de 100ms. Dans le cas présenté, la vitesse demandée est de 1X mais le PIC n'arrive pas à fournir cette vitesse, il peut avoir 2 vitesses approchées, une par excès et une par défaut: 1.0003X ou 0.9998X toutes les 2 dans la tolérance de 5e-4. En jouant avec ces 2 vitesses on obtient une vitesse moyenne très proche de la valeur théorique. J'ai fourni cet élément pour montrer qu'avec des systèmes bien conçus il est possible d'arriver à la quasi-perfection. Malheureusement PIC-ASTRO est une exception, il est le seul système abordable qui soit conçu pour une parfaite maitrise de l'entrainement.

 

Je vous ai bien saouler avec mes analyses, juste pour essayer de faire comprendre le principe. Mais j'ai laissé tomber par la suite et non sans raison.

Les résultats obtenus par Bertrand Bertin et Vincent Steimetz montrent qu'il n'est pas nécessaire de pousser plus loin la gestion de l'autoguidage. Lorsque Bertrand à sorti les résultats enregistrés par MaximDL je me suis rendu compte qu'il était impossible de faire mieux; 0.017Asec rms c'est imbattable. Le résultat est là mais avec des conditions exceptionnelles: d'abord turbu nulle puis monture( excellente) controlée, vérifiée et réglée par des personnes très consciencieuses la partie est facile pour le soft et ça fait plaisir puisque les résultats sont dans ce qu'on peut attendre théoriquement. Je suis peut-être con mais je ne me satisfais pas du résultat, je veux le comprendre pour que chacun puisse tirer le meilleur parti de sa monture. C'est pour cela que j'ai commencé par parler des limites qu'on est en droit d'attendre. UNE MESURE D'EP EST TOUJOURS NECESSAIRE. La turbulence n'est fonction que de la localisation et de la météo. A ces 2 paramètres, il faut ajouter la précision des moteurs qui avec les systèmes commerciaux est d'environ 0.3Asec.

En complément: pourquoi 0.017Asec est imbattable??? tout simplement que parce que 15Asec/1000 = 0.015Asec en clair cela correspond à la précision des commandes d'autoguidage actuelles. En fait un PIC-ASTRO peut faire 4 fois mieux mais non exploitables avec les logiciels et les protocoles du jour.

 

 

Désolé, j'ai été long, mais je n'aurai rien à dire de plus.

 

Arnaud

Modifié 17 mars 2012 par arnaud.gerard

[Didou]

Désolé, j'ai été long, mais je n'aurai rien à dire de plus.

 

Bah c'est déjà pas mal

Moi j'ai compris qu'il y a une limite.