Aller au contenu

Messages recommandés

Posté

J'ai eu un échange avec Jasem au sujet de l'utilisation de codeurs optiques avec INDI et de l'affichage dans Stellarium.

Tout est parti du projet mené avec Jacques (Algeiba09) de transformation de son dobson 300 en push to wifi.

On a une solution qui fonctionne bien avec Skysafari mais cette solution est payante (à cause de skysafari).

On aimerait bien utiliser Stellarium. Mais celui-ci reconnaît seulement les montures équatoriales pilotées par INDI.

De plus en utilisant un logiciel tiers la synchro nécessaire pour calibration sur le ciel n'est pas possible.

Pour en revenir à la discussion Jasem voici sa réponse (en shakespirien dans le texte):

Moi:

Citation
Hello Jasem
 
Just a question about the digital setting circles driver. Does the calibration computation on sky (2 stars) is done inside the driver and computed parameters stored in  it ?
 
I asked to the STellarium community to see how it could be possible to handle signals from DSC INDI drivers.
Citation
Good question... it relies on INDI ALignment Subsystem
 
but IAS is not quite reliable and when users tested it in EQMod (vs the usual EQMod alignment), the results were not good. Jean-Luc tried to make changes to the IAS to make it better and more in line with EQMod align, but that ended up introducing more problems. We evantually reverted all chanegs to IAS. Jean-Luc said he's very busy, and I am very busy even though I tried to understand it but it's quite complex mathematically.
 
The original author of IAS is quite old now and said he can no longer do coding
 
so it's left to whoever can code it

Il m'a fournit les liens sur les sources:

Citation

 

Y aurait-il parmi l'audience des volontaires pour aider et tenter de faire fonctionner le bidule ???

 

Posté

Bon, je ne suis pas matheux ni codeur en C++ mais comme je me suis déjà penché sur des histoires de mise en station et de réduction astrométrique, je peux peut-être donner un coup de main. Par contre, j'ai du mal à comprendre le problème. Est-ce que tu peux m'expliquer les objectifs généraux indépendamment d'outils spécifiques ou de problèmes particuliers à un logiciel?

Posté (modifié)

Je ne suis pas trop doué dans cet exercice  mais je vais tenter quand même d'expliquer le principe de cette "calibration" sur le ciel.

Il s'agit en quelque sorte de construire une fonction qui permet de relier la direction pointée par le télescope avec la position d'un objet sur la voûte céleste.

Pour cela on doit prendre des points de repère, des étoiles,.

A chaque étoile repère choisie correspond une position des codeurs qui équipent le télescope sur les axes en azimut et altitude.

On lit les codeurs, on demande à l'opérateur de désigner l'objet pointé dont on récupère les coordonnées en AD et DE.

Je suppose mais n'ai pu encore le vérifier qu'on transforme ces coordonnées en altitude et azimut de l'objet pour la situation locale du télescope.

On doit répéter l'opération à chaque objet choisi pour la "calibration" sur le ciel.

Je suppose que le modèle est une matrice (ou un quaternion qui est un opérateur plus exotique) qui permet de passer des infos codeur aux infos en AD et DE.

En général deux ou trois étoiles suffisent pour construire un modèle assez précis.

Lorsque la "calibration" est achevée il est alors possible de savoir où pointe le télescope en fonction de l'information fournie par ses codeurs.

Et ultime raffinement on peut assister l'opérateur en affichant la distance entre la position courante pointée par le télescope et celle de la cible choisie.

Je pense qu'on peut trouver pas mal d'info là: http://www.geocities.jp/toshimi_taki/

dans la   rubrique "equation for pointing telescope".

 

Voilà pour ce que j'ai compris du système

 

 

Modifié par patdut
Posté

Oui, j'ai compris. ;)

 

C'est uniquement pour des montures équatoriales ou il faut prévoir le cas altazimutal?

 

Plutôt que pointer spécifiquement des étoiles, on pourrait pointer dans différentes directions du ciel, faire une photo puis une réduction astrométrique. Ça fait une contrainte de plus (la rotation de champ) introduite dans le système, ce qui doit faciliter la calibration.

Sur le nombre de points de calibration nécessaires, ça dépend aussi de ce qu'on veut calibrer dans la monture: défaut de parallélisme/perpendicularité, non linéarité des capteurs, flexions... D'un autre côté, ce n'est pas non plus nécessairement utile d'avoir une super calibration de la monture. Quand on est à proximité d'une cible, on peut se recaler par réduction astrométrique. Et aussi, plutôt que faire un modèle de la physique de la monture, juste faire un morphing sur la sphère entre théorie et pratique.

 

Faut-il aussi prévoir une assistance à la mise en station?

 

Posté (modifié)

Hum, c'est pour du visuel. Donc, l'astrométrie n'est  pas d'actualité.

Heureux que ça te soit utile Gilles.

Tu veux pas nous donner un coup de main ?

Ce serait bien que nous petits français, nous contribuions aussi à l'aventure  kstars/ekos/indi

Pat

 

Modifié par patdut
Posté
Il y a 3 heures, patdut a dit :

Tu veux pas nous donner un coup de main

C'est tentant, mais d'une part je n'ai sans doute pas le niveau, et ensuite j'ai beaucoup de mal à honorer mes engagements...

Laissons venir, je reste branché 😀

 

L'idée que je pige c'est deux encodeurs qui  te donnent en permanence la position alt/az

-> arduino ou autre qui communique avec le pc

Avec stellarium il faut un driver qui transforme en ra/dec, après lui avoir pointé 2 ou 3 étoiles pour la calibration

Ensuite tu donnes la cible voulue à stellarium,  qui la transforme a nouveau en alt/az vers l'arduino.

Et l'arduino fait bip ou bip bip ou biiiiip pour t'aider a pointer en visuel 

Right ?

On doit bien avoir des bouts de code qui font ça, non ?

(C'est sans doute l'objet de ta question à Jasem, j'essaierai de regarder...)

Posté

Les encodeurs donnent une position en tics. Le python étant trop lent pour la lecture j'ai écrit un petit programme en C++ pour cela.  J'ai aussi écrit un petit serveur bidirectionnel qui renvoie ce qui est lu par le code C++ et qui réalise quelques opérations basiques.

Quand on utilise le driver INDI DSC on fournit l'adresse et le port sur lequel le petit serveur python communique.

On a donc en entrée du driver seulement une information en tics. Il faut la transformer en alt/az puis coordonnée équatoriale. Ce que fait normalement le driver DSC quand on "calibre" le télescope sur le ciel puis qu'on pointe ensuite le télescope sur le ciel.

Le driver DSC d'INDI fait donc cela mais  d'après Jasem le fait mal. De plus il faudrait pouvoir déclencher les synchros depuis stellarium pour que les calculs de "calibration" s'effectuent côté driver.

Posté
Il y a 1 heure, patdut a dit :

 

Il y a 1 heure, patdut a dit :

Les encodeurs donnent une position en tics. Le python étant trop lent pour la lecture j'ai écrit un petit programme en C++ pour cela.  J'ai aussi écrit un petit serveur bidirectionnel qui renvoie ce qui est lu par le code C++ et qui réalise quelques opérations basiques.

Quand on utilise le driver INDI DSC on fournit l'adresse et le port sur lequel le petit serveur python communique.

On a donc en entrée du driver seulement une information en tics. Il faut la transformer en alt/az puis coordonnée équatoriale. Ce que fait normalement le driver DSC quand on "calibre" le télescope sur le ciel puis qu'on pointe ensuite le télescope sur le ciel.

Le driver DSC d'INDI fait donc cela mais  d'après Jasem le fait mal. De plus il faudrait pouvoir déclencher les synchros depuis stellarium pour que les calculs de "calibration" s'effectuent côté driver.

 

tu peux détailler le hardware ? Parce que je vois pas bien :

comment les encodeurs envoient leur position ?

 

Posté

Donc, en visuel, le pointage de chaque étoile crée deux contraintes. Il faut au moins autant de contraintes que de paramètres. Un peu plus de contraintes permet de détecter qu'il y a un problème (une étoile de plus que nécessaire). S'il y a beaucoup plus de contraintes (au moins deux étoiles supplémentaires), on peut identifier l'étoile qui pose problème.

 

Si tous est parfait (mes, perpendicularités, encodeurs bien linéaires, pas de flexions...), une étoile suffit pour déterminer le zéro de chaque encodeur (2 contraintes -> 2 paramètres).

Si on suppose que la MES n'est pas parfaite, ça fait deux paramètres de plus: 4 paramètres -> 2 étoiles au moins.

Si on suppose que la MES n'est pas parfaite et que les deux axes AD et DEC ne sont pas parfaitement perpendiculaires, ça fait encore deux paramètres de plus: 6 paramètres -> 3 étoiles au moins.

Pour des modèles plus compliqués, je ne vais de toute façon pas avoir le niveau suffisant en math :be:.

 

De mon point de vue, il est aussi important de prévenir l'utilisateur quand il y a des résultats bizarres, ce que ne fait pas ma CG5-GT :mad:.

 

Par exemple, je fais une calibration à deux étoiles -> l'erreur de MES calculée est de 30°, il faut prévenir l'utilisateur et pas juste dire Calibration terminée. Ou calibration à trois étoiles -> l'angle entre les axes AD et DEC est de 80° : NON.

Posté
il y a 24 minutes, gehelem a dit :

 

tu peux détailler le hardware ? Parce que je vois pas bien :

comment les encodeurs envoient leur position ?

 

Il s'agit d'un RPi3 sur le GPIO duquel les encodeurs sont connectés. Il est évident qu'un arduino suffirait mais on perd la fonction wifi.

 

Posté
il y a 6 minutes, Eric S a dit :

Donc, en visuel, le pointage de chaque étoile crée deux contraintes. Il faut au moins autant de contraintes que de paramètres. Un peu plus de contraintes permet de détecter qu'il y a un problème (une étoile de plus que nécessaire). S'il y a beaucoup plus de contraintes (au moins deux étoiles supplémentaires), on peut identifier l'étoile qui pose problème.

 

Si tous est parfait (mes, perpendicularités, encodeurs bien linéaires, pas de flexions...), une étoile suffit pour déterminer le zéro de chaque encodeur (2 contraintes -> 2 paramètres).

Si on suppose que la MES n'est pas parfaite, ça fait deux paramètres de plus: 4 paramètres -> 2 étoiles au moins.

Si on suppose que la MES n'est pas parfaite et que les deux axes AD et DEC ne sont pas parfaitement perpendiculaires, ça fait encore deux paramètres de plus: 6 paramètres -> 3 étoiles au moins.

Pour des modèles plus compliqués, je ne vais de toute façon pas avoir le niveau suffisant en math :be:.

 

De mon point de vue, il est aussi important de prévenir l'utilisateur quand il y a des résultats bizarres, ce que ne fait pas ma CG5-GT :mad:.

 

Par exemple, je fais une calibration à deux étoiles -> l'erreur de MES calculée est de 30°, il faut prévenir l'utilisateur et pas juste dire Calibration terminée. Ou calibration à trois étoiles -> l'angle entre les axes AD et DEC est de 80° : NON.

Il n'est pas question de mise en station avec un dobson. Ceci dit on ne voit pas pourquoi ce qui peut marcher pour un dobson ne marcherait pas pour un équatorial. Il y a seulement une transformation d'écart.

Posté

Je suis un peu ignare en dobson :refl:. Néanmoins, je suppose que c'est grosso modo de l'altazimutal. Dans tous les cas, on a deux axes motorisés et supposés perpendiculaires?

Posté
Il y a 2 heures, patdut a dit :

Il s'agit d'un RPi3 sur le GPIO duquel les encodeurs sont connectés. Il est évident qu'un arduino suffirait mais on perd la fonction wifi.

 

Merci

Quel type d'encodeur ?

Posté
Il y a 5 heures, Eric S a dit :

Je suis un peu ignare en dobson :refl:. Néanmoins, je suppose que c'est grosso modo de l'altazimutal. Dans tous les cas, on a deux axes motorisés et supposés perpendiculaires?

Oui c'est exactement ça et le moteur c'est l'opérateur qui pousse ou tire le tube d'où le nom de push to.

Posté

Ok.

 

Donc, hypothèse n°1, le support est bien à plat, le pointage d'une étoile suffit pour déterminer le zéro de chaque capteur.

 

Hypothèse n°2, le support n'est pas parfaitement horizontal, il faut au moins deux étoiles pour avoir le zéro des capteurs et l'inclinaison du support.

 

Je pense qu'on peut ignorer le défaut de perpendicularité des deux axes.

 

À priori, les équations ne sont pas bien compliquées mais déjà que je n'ai pas eu temps de répondre à ton message ce week-end, alors ça va être un peu sport pour poser les équations :D.

Posté

@Eric SEffectivement il faut au moins deux étoiles pour calibrer correctement la monture.

Ce que j'aimerai faire avant cela c'est disposer d'un ou créer un client stellarium qui utilise le DSC driver. Même si IAS est peu précis, ce serait un premier pas. Comme j'ai du temps je tente de comprendre les divers clients télescope de Stellarium. Peut-être que si j'arrive à  comprendre, je pourrais en écrire un.

Après, oui, ce serait bien de rentrer dans IAS et tenter un debug.  J'ai surtout l'impression qu'il faudrait avant tout faire pas mal de tests avec la version actuelle pour tenter de cerner le(s) problème(s).

 

 

 

 

Posté

Disons qu'avec les maths, ça peut permettre de reprendre le problème à la base plutôt qu'essayer de modifier un truc existant qu'on ne comprend pas bien. Mais il faut aussi comprendre la partie logiciel avec l'interfaçage avec les autres composants/drivers.

 

Ça te gène si je te fais un exemple de calcul avec Excel (y compris les fonctions solveur)?

 

Si je résume bien, quand on pointe une étoile de référence, on a:

à hh:mm:ss, l'étoile machin de coordonnées (Ra, Dec) était à l'Az [0..8192] et la pente [0..8192].

Posté

Ce est pas tant les maths qui posent problème. Un certain Jean Luc alias gehaa le a écrit l'alignement contenu dans le driver eqmod. Il permet l'alignement sur 2 ou 3 étoiles. La difficulté réside en deux points. Câbler ce développement dans le DSC driver et écrire le client Stellarium qui exploite le driver DSC. 

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.