Aller au contenu

Messages recommandés

Posté

Salut,

 

voilà http://astrimage.org/index.php?module=documents&JAS_DocumentManager_op=downloadFile&JAS_File_id=178

 

première version Altaz, prévue pour le PIC-ASTRO A1, elle utilise des commandes spécifiques incompatibles avec les logiciels habituels.

 

une documentation, incluse, donne les informations nécessaires pour le développement d'un logiciel PC ou autre.

 

Les fonctions suivantes ont été testées:

- Sync

- Goto

- réglage des vitesses

 

les vitesses ont une tolérance à +-5e-4,

 

Le paramétrage se fait avec le .xls inclus.

 

Arnaud

Posté

Super merci beaucoup !!!

 

Ca c'est vraiment une très bonne nouvelle, surtuot que je veux acheter une monture Altaz...

 

Tiens nous au courant de l'évolution.

Posté

Hum, cela pourrait aussi m'intéresser un de ces quatres...

En tout cas je suis admiratif du boulot que tu fais Arnaud. ;)

Tu n'as plus qu'à t'associer avec Dobcat, lui taille les miroirs composites carbonne/verre ultra-léger et toi une motorisation altaz optimisée et vous allez casser la baraque !!!! :p

 

Albéric

Posté

Hello,

Je me pose la question : à quoi peut servir un pic astro altaz en photo longue pose étant donné la rotation de champ que ça va entraîner ?

Posté
Hello,

Je me pose la question : à quoi peut servir un pic astro altaz en photo longue pose étant donné la rotation de champ que ça va entraîner ?

 

Mais personne a parlé de photo longue pose.:be:

Posté

Salut,

 

j'ajouterai: a quoi ça sert d'avoir un système qu'on ne peut pas piloter avec les logiciels habituels?:?:

 

et je répondrai: c'est comme d'avoir un PC sans OS.:coupe:

 

c'est comme quand on me parle de Windows ou de Linux et que je me rappelle les joies du compilateur C sur AppleII ou du dos sur XT. c'est créationniste contre évolutionnistes:D

 

Le petit PIC-ASTRO peut faire plein de choses mais il faut lui amener le logiciel qui va bien. Comme je ne suis qu'un pauvre humain donc ne sachant pas tout et commettant plein d'erreurs je commence par une version très Lite pour qu'avec l'aide de bonnes volontés nous puissionsi valider les principes de base. On fera évoluer le soft par la suite.

 

PIC-ASTRO est suffisament souple pour s'adapter à toutes les montures, il est possible de le faire encore évoluer coté soft, je suis à votre service pour ça.

 

La rotation de champ sera la dernière chose que je traiterai, pour cela il sera possible d'utiliser la partie commande de focus, pas très souple celle là et pas mal de boulot. Ce n'est pas du tout cuit mais ça me semble jouable.

 

Arnaud

Posté

Et à propos d'aide:

 

Y-a-t-il un matheux qui pourrais me fournir les équations des vitesses altitude et azimuth en fonction de l'altitude, de l'azimuth et des lat/long du lieu d'observations? Il me semble que ce sont les seuls paramètres utiles, mais je peux me tromper.

 

Je n'ai pas réussi à trouver sur la toile et les décennies m'ont rendu incapable de me replonger dans la trigo & co.

 

Merci

 

Arnaud

Posté

Merci Coredump,

 

mais je suis un indécrottable fainéant,:confused:

 

il faut le prendre dans le bon sens du terme, j'aime que les choses compliquées soient simple.

 

En altaz les formules qu'on trouvent sont les transformations de coordonnées qui sont des calculs demandent le traitement de nombreux paramètres. En réduisant le nombre de paramètres, lorsque c'est faisable, on améliore la précision du système.

 

Je dispose déjà des formules complexes, nécessaires pour la transformation equat/Altaz et inverse. Ces formules sont les seuls applicables pour le changement de coordonnées. Pour les vitesses de suivi l'idéal est d'avoir des formules plus simples ( supprimant AD,De, Date, heure, lat/long du lieu). Là dessus, je peux me tromper, il me semble que seul les paramètres alt, az et latitude du lieu sont nécessaires pour calculer les vitesses instantannées.

 

Pour simplifier: en utilisant un logiciel de cartographie standard:

- PA reçoit les coord AD,De

- PA calcul Alt, Az

- PA peut calculer les vitesses instantannées

- PA peut entretenir les coordonnées et donc ajuster les vitesses à fréquence élevées ( entre 10 et 100 fois par seconde)

 

Voilà ce que je cherche à faire, jusqu'à ce qu'on me démontre que ça ne tient pas la route. Dans le cas contraire ce sera super tip-top.

 

Arnaud

Posté

Hello,

 

J'ai pas pigé: tu veux les formules de transformation AD/Dec en Alt/az (ça, j'ai) ou bien tu les as déjà et tu veux des formules plus simples ?

Posté

Salut,

 

sans bla-bla:

 

je voudrais uniquement les formules de calculs des vitesses instantanées, avec pour seules variables: l'altitude et azimut courants et la localisation du lieu d'observation.

 

Ca j'ai pas trouvé.

 

 

Merci quand même.

 

Arnaud

  • 4 semaines plus tard...
Posté

Salut,

 

en passant au club Voyager3, j'ai posé la question et j'ai eu la réponse quelques jours après. Le service est super efficace.

 

Disposant des précieuses formules qui sont, comme je l'espérais, bien plus simples je vais pouvoir avancer sérieusement. Une version de PIC-ASTRO ALt-AZ qui permet d'avoir un suivi en autonome devrait donc voir le jour avant la fin de l'année. Cette version devrait aussi être compatible avec certains logiciels de cartographie tournant sur PC autorisant les goto; il y a restriction sur ces logiciels, hors ceux qui utilise,t le driver ASCOM LX200 GPS car il faut que ces soft ou drivers fournissent les infos locales: date, heure, latitude du lieu d'observation. Ce dernier paramètre étant indispensable en autonome il sera ajouté dans le fichier de configuration.

 

Il ne devrait y avoir qu'un problème bien identifié: le passage au zénith entrainera une erreur de suivi qui est fonction de la vitesse maximale; en théorie la vitesse est infinie à ce moment là.

 

A+

 

Arnaud

Posté

Sympa ca, ca évite de faire des mariages contre nature (même si cela fonctionne) entre un dobson (en l'occurence un 400mm JML) et l'electronique et la motorisation d'un LX200 ... en alt-az ! Et hop un dob 400 alt-az ! En plus il paraît que ca marche.

 

La solution pic astro évite le sacrifice (ou l'achat suivi du sacrifice) d'un LX200 !

Posté
Salut,

 

en passant au club Voyager3, j'ai posé la question et j'ai eu la réponse quelques jours après. Le service est super efficace.

 

Disposant des précieuses formules qui sont, comme je l'espérais, bien plus simples je vais pouvoir avancer sérieusement. Une version de PIC-ASTRO ALt-AZ qui permet d'avoir un suivi en autonome devrait donc voir le jour avant la fin de l'année. Cette version devrait aussi être compatible avec certains logiciels de cartographie tournant sur PC autorisant les goto; il y a restriction sur ces logiciels, hors ceux qui utilise,t le driver ASCOM LX200 GPS car il faut que ces soft ou drivers fournissent les infos locales: date, heure, latitude du lieu d'observation. Ce dernier paramètre étant indispensable en autonome il sera ajouté dans le fichier de configuration.

 

Il ne devrait y avoir qu'un problème bien identifié: le passage au zénith entrainera une erreur de suivi qui est fonction de la vitesse maximale; en théorie la vitesse est infinie à ce moment là.

 

A+

 

Arnaud

 

Salut,

 

Ce serait possible d'avoir ces formules?

Posté

Salut Coredump,

 

pas de problème:

Vaz = sin(lat) + tan(hau) cos(az) cos(lat)

Vhau = -sin(az) cos(lat)

 

avec:

az: azimuth courant

hau: hauteur courante

lat: latitude du lieu d'observation

 

et l'unité est 1X soit env 15"/s.

 

le résultat de ces formules a été vérifié en les comparant à celles trouvées dans: http://www.obs-hp.fr/~lardiere/chapitres-controle-telescope.pdf sous Excel: le résultat est identique avec une complexité divisée par 5.

 

Pas de problème pour les implémenter dans PIC-ASTRO, le plus dur va être de contrôler les effets de bords: en cas de déplacement manuel ou automatique il faut prendre en compte les vitesses de suivi pour éviter de trop brusques variations de vitesses et ça va sûrement demander un traitement conséquent et difficile à controler.

 

Arnaud

Posté

bonsoir,

Je suis entrain de me tailler un miroir pour un scope dédié au planétaire. Vous dites qu'avec un suivi en altaz les longues poses sont interdites, mais concernant les photos des planètes : est-ce adapté ?

merci

jpierre

Posté

Merci pour les equations, j'aimerais bien motoriser un dob, mais sans avoir les inconvénients du systeme bartels.

 

Donc encodeur pour avoir la position en permanence et petits moteurs CC pour entrainer les axes. J'ai fait une super affaire sur ebay, 60€ pour deux encodeurs 1024 points et deux micromoteurs reductés 1/900 sans backslash et encodeur.

 

D'ailleurs pour ceux que ca interesse le vendeur:

 

http://shop.ebay.fr/merchant/goyo17

 

Il en a encore pas mal, a des prix plus qu'interessants.

Posté
bonsoir,

Je suis entrain de me tailler un miroir pour un scope dédié au planétaire. Vous dites qu'avec un suivi en altaz les longues poses sont interdites, mais concernant les photos des planètes : est-ce adapté ?

merci

jpierre

 

Salut Jean-Pierre,

 

en supposant que j'arrive à obtenir des résultats même excellents il restera le problème de la rotation de champ. Cette rotation interdit les longues poses. Il est possible de la traiter sur les images obtenues mais je n'ai aucune connaissance de cette opération et des résultats qu'on peut en attendre.

 

Pour le planétaire les poses étant bien plus courtes je suppose que ça doit fonctionner, hors passage au zénith.

 

 

Arnaud

Posté

Il s'agit donc essentiellement d'un suivi de confort pour observation visuelle ? Je me pose alors la question, qu'elle est l'utilité d'investir autant temps et d'argent pour un suivi altaz alors que la même "énergie" permettrai de faire un peu de prise de vue en suivi équat. ?

 

ceci dit, si ce n'est que pour le plaisir de la "bidouille" je comprends...

 

merci

 

jpierre

Posté

C'est clair que pour moi c'est plutôt le défi qui m'intéresse le plus;).

 

Pour l'équato PIC-ASTRO me parait bien mûr puisqu'il permet de piloter avec la même précision toutes les montures quelles que soit leur taille. Alors, pour répondre à un certains nombre de demandes, je me lance dans une version Alt-Az.

 

Du fait de la polyvalence l'investissement ne me semble pas important excepté pour la partie mécanique d'ailleurs les personnes les plus intéressées sont justement celles pour qui la mécanique n'est pas un problème. On peut aussi comparer le coût à d'autres systémes de suivi.

 

Pour les gros Dobson le suivi en visuel est plus qu'un confort, pour les plus petits aussis: le nombre croissant de table équatoriales montre bien ce besoin.

 

Je m'amuses donc à faire ce genre de truc avec l'unique souci de mettre à la disposition d'un maximum d'astram un système économique. Libre à chacun de s'y intéresser ou pas, ce n'est pas mon problème, et d'autant moins que ça ne me rapporte strictement rien bien au contraire.

 

Ainsi le jour où un produit commerciale équivalent sortira j'arrêterai, enfin je pense que je ferai autre chose.

 

Arnaud

Posté

Il y a une solution qui regroupe les avantages du bartels et des systèmes à moteur CC et encodeur.

Je voulais le faire , car c'est plutôt simple à faire et tout est dispo sur le net ...

Je m'explique :

On convertit toute la partie conversion et calculs issus du programme de Bartels et on met ce qui nous intéresse dans un PIC32 par ex. Ca nous donne un dir et un clk sur chaque axe ( 4axes possibles !).

On récupère les 4 données concernant l'azimut et l'altitude et on les injecte dans le montage suivant :

http://members.shaw.ca/swstuff/dspic-servo.html

 

Et on obtient un système hyper précis, très rapide en déplacement rapide :be: et à la portée de plein d'astrams ...

Posté

Salut à tous, salut Arnaud,

 

Je viens de tomber sur cette discussion qui m'intéresse à plusieurs titres. Comme j'en ai déjà parlé ici il y a quelques temps, je suis en école d'ingénieur et mon projet principal (en binôme) pour cette année est de motoriser mon Strock-250 en respectant au mieux son aspect de portabilité. Après étude, seule une monture alt-azimutale pouvait y parvenir (ou peut être une monture trois axes, mais on n'est pas allé aussi loin).

 

On a un gros impératif de délais (juin). Par conséquent, la partie mécanique est presque terminée et la partie électronique (Pic astro vous l'aurez compris!)également!

 

Je passe donc maintenant au soft. Je ne connais que le JAVA (pas le C), mais ça serait bête de ne pas s'inspirer du boulot de Mel Bartel. Bon il y a quand même une grosse spécificité par rapport à ce dernier : le but ultime est de concevoir un soft capable de suivre l'ISS automatiquement, et ce de façon asservie (pas uniquement grâce aux TLE de la station, mais en faisant aussi une analyse d'image en temps réel). Par ailleurs je ne sais pas si le soft de Mel Bartel a une fonction autoguidage, mais le notre en aurra une! Je ne sais pas si un soft du genre a déjà été envisagé, en tout cas je n'en ai pas trouvé sur google...

 

Bon, les questions maintenant! :

 

1) CoreDump :

Merci pour les equations, j'aimerais bien motoriser un dob, mais sans avoir les inconvénients du systeme bartels.

 

Quels sont-ils?

 

2) Pourquoi les fonctions LX-200 ne sont pas compatibles avec les logiciels standards de suivit et go-to alt-az?

J'ai pas tout compris dans :

Cette version devrait aussi être compatible avec certains logiciels de cartographie tournant sur PC autorisant les goto; il y a restriction sur ces logiciels, hors ceux qui utilise,t le driver ASCOM LX200 GPS car il faut que ces soft ou drivers fournissent les infos locales: date, heure, latitude du lieu d'observation. Ce dernier paramètre étant indispensable en autonome il sera ajouté dans le fichier de configuration.

 

2) Super les formules Valt et Vaz en fonction uniquement des coordonnées alt-azimutales de l'objet. Ca permet en effet d'être indépendant du PC sans trop de calculs. Cependant dans la convertion des coordonnées équatoriales en alt-azimutales, tu es obligé de faire un calcul assez bourrin (Temps sidéral etc...). Tu comptes rentrer cela aussi dans le PIC? A ce moment le PC ne sert plus qu'à envoyer des coordonnées alpha et delta pour le go-to (et ne calcul plus rien) c'est ça?

Si oui, quand penses tu avoir rentré cela dans le PIC? (la vrai question est : est ce qu'on doit coder l'intéligence de suivi et go-to dans le soft, ou bien juste se concentrer sur l'ISS en te faisant confiance pour le codage des deux autres trucs d'ici fin Mai ou avant?)

 

Merci d'avance

 

Daniel PALETTI

Posté

Salut Daniel,

 

Je ne suis pas sûr pouvoir tout implémenter pour votre projet.

 

Avant de répondre aux questions:

 

Il ne faut donc pas que tu comptes t'appuyer sur cette version. D'autant plus qu'il n'est pas question de pouvoir suivre l'ISS en autoguidage car là il ne s'agit pas de corriger une dérive lente de la cible: l'autoguidage est prévu pour compenser les dérives dues à la mécanique par rapport à une trajectoire donnée ( le suivi). Dans le cas de trajectoire légèrement écartée du celle du suivi ( comètes ou astéroides) l'autoguidage peut être suffisant. Dans le cas de satellites c'est plus complexe car il faut programmer le suivi pour qu'il aie la même trajectoire que le satellite et seulement dans ce cas on peut, pour améliorer le systéme, effectuer un autoguidage qui corrige les dérives.

 

Dans la version logicielle que je t'ai fournie tu disposes de tout ces éléments: programmation des vitesses de suivi sur chacun des axes et autoguidage qui s'autoadapte à ces vitesses de suivi ( pourcentage de ces dernières). La solution idéale, dans votre cas, serait de modifier les vitesses de suivi en fonction des dérives constatées par le système de guidage. Mais il reste nécessaire que les calculs soient faits sur un PC, c'est la partie soft de votre projet.

 

Réponses aux questions:

2) Oui les calculs de conversions sont relativement complexes et prendront un peu de temps du PIC. Les logiciels de cartographie travaillent en AD/De. Mais leur périodicité est très faible puisqu'elle correspond, en réception, aux demandes de synchronisation et de goto. Si le PIC dispose des infos nécessaires c'est donc faisable. Avec le driver ASCOM j'ai vérifié les commandes LX200 émises à l'initialisation et les ai codées dans la version en cours de développement. Le PIC dispose donc des infos nécessaires.

En émission, les demandes de position peuvent se faire toutes les 1 ou 2s donc c'est la même chose.

 

3) il ne faut jamais faire confiance à une seule personne. Il peut toujours y avoir des bugs et la version que je t'ai fournie n'a été testée que par moi. N'étant pas infaillible, il ne faut pas pas me faire confiance aveuglément et vous devez commencer par vérifier que chacune des fonctions nécessaires fonctionnent bien. Dans cette version il ne faut utiliser que des commandes qui utilisent des Azi/Haut pour les Sync et Goto puisque les conversions ne sont pas impémentées.

 

Arnaud

Posté

En conversion alt-az, je te vois mal faire çà sur un seul pic ! Fusse-t'il PIC32:be: Il peut servir de processeur de calcul et d'affichage-gestions des boutons et tu devras laisser à un autre uC , la gestion des moteurs...

Ca me parait plus simple pour d'évidentes raisons de debugage et de taille du produit final ... Un projet de ce type n'est pas de la même envergure que le pic-astro ;) Tu auras beaucoup plus de choses à gérer, donc autant diviser les fonctions au début, quitte à faire une evo2 en simple uC !

Posté

Le defaut du systeme bartels:

 

- Il faut un PC: c'est gros, lourd, et ca demande beaucoup de puissance electrique.

- Ca demande un PC avec port parallele. Introuvable en portable de nos jours, de plus en plus dur en format classique. Meme un laptop d'occasion n'a pas forcement de port parallele.

- Ca utilise des steppers. Moins cher mais beaucoup plus gourmants, sauf a faire un driver adapte (ce que n'est pas l'interface bartels).

- C'est un goto a la base, donc on touche pas au scope, on a une mise en station 2 ou 3 etoiles. Y'a une extension pour les codeurs, mais c'est pas vraiment fait pour.

 

Si on veut juste l'equivalent d'une plateforme equato (en visuel), sans pour autant se trimbaler la dite plateforme, on pourrait imaginer une solution legere ou on drive en fonction du pointage alt/az. Avec les equations je pourrais calculer la precision requise sur les parametres alt/az pour garantir une certaine derive admissible.

En visuel c'est pas vraiment impactant d'avoir une derive lente. Du coup on pourrait avoir des encodeurs plus leger (et donc moins cher). Voir pas d'encodeur en alt (accelerometre).

Cote mecanique, outre les encodeurs, y'a le probleme epineux des embrayages.

 

Quand la la puissance du uC, c'est plus vraiment un probleme. Une monocarte ARM7 a 50Mhz c'est 50€, un ARM9 a 200Mhz qui tourne du linux c'est 170€. Et au pire y'a les eeepc a moins de 300€...

Rejoignez la conversation !

Vous pouvez répondre maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous pour poster avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

  • 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.