PIC-ASTRO enfin un début d'Altaz

Salut Bigeye,

j'espère que tu parles en connaissances de cause. Et dans même dans ce cas tu te trompes.

30 ans d'informatique, principalement sur des logiciels très contraints, que ce soit sur PC, µcontroleurs, processeurs graphiques, ADSP, et des cas bien plus complexes. Plus une parfaite maitrise du C et une bonne connaissance du hard. Ca me permet d'avoir une bonne approche réaliste des problèmes et d'apprendre à vérifier, tester et mesurer avant d'avancer des idées.

Dans le cas qui nous intéresse les opérations de conversions, ne prennent que de 30000 à 60000 cycles, avec un PIC à 40 MHz ça fait entre 3 et 6 ms. Compte-tenu du temps de traitement des IT il faut multiplier ces temps par un facteur 2 à 10. La plage est large car dans le soft une constante permet de limiter la période des ITs, le PIC prend automatiquement en compte cette limite pour la programmation de toutes les vitesses.

Ces données ont été mesurées sur les formules les plus complexes, il faut que je réitère avec les formules simplifiées et pour un échantillons plus large des valeurs d'entrées.

Donc c'est jouable, même avec un PIC18F.

Mais j'abonde dans ton sens, une version 32 bits est prévu par la suite, avec traitement des en codeurs. Les connaisseurs pourront constater que la nouvelle carte puissance est conçue aussi pour les moteurs CC mais le PIC ne peut pas gérer les encodeurs. Ca c'est une autre histoire qui peut aller très vite car le code développé est réutilisable tel quel à plus de 99%, juste une dizaine d'instructions ( que j'ai mal codé) et un fichier unique qui qui fait la traduction entre application et micro ou application et compilateur.

J'ai levé les principaux risques, mais n'étant pas infaillible il est possible qu'il y en aie que je n'ai pas identifié et là tout peut capoter.

Arnaud

Non, je ne crois pas me tromper ...

Mais il est plus prudent dans un premier temps de séparer la partie calcul/affichage et compagnie de la partie puissance et gestion des moteurs ...

C'est juste un point de vue ;-)

Car qd tu fait tirer ta plaque et que tu t'aperçois d'une bétise, ca coute des sous ! Et comme la plupart d'entre nous n'a pas accès à un labo ...

Dans mon esprit, il était plutôt simple de prendre directement le montage de commande des servos qui existent et qui fonctionne . Je le sais , j'en ai fait 2 ! Vu la puissance nécessaire pour nos scopes, cette carte suffit bien !

Comme çà , tu peux te concentrer sur la partie conversion des coordonnées et tout ce qui va après !

Tu sépare le pb pour commencer... Je ne doute pas de tes capacités, mais la manière d'aborder la chose peut être différente entre collègues

Je fais aussi beaucoup d'électronique , mais dans le domaine des petits appareils portable sur accu li-ion en général ...

Mais bon, je ne parlerais pas de mes projets, c'est confidentiel Comme toi, je gravite aussi beaucoup autour de microchip et TI, Maxim Ic et Cie ...

Je voulais juste t'apporter quelques éléments et mon point de vue

Je vois qu'en fait nous sommes totalement d'accord. C'est juste que nous ne voyons pas les choses du même "point de vue".

Les solutions que tu proposes, je les envisage, mais ce qui me freine c'est qu'elles ne sont pas accessibles à tous pour cause de composants non soudables entre autres. Mais il faudra trouver une solution lorsque cette étape sera inéluctable.

Dans le cadre de la version Alt-az j'ai eu les mêmes doutes que toi et le plan B était, comme tu le suggères, d'utiliser PIC-ASTRO comme une interface intelligente de pilotage des moteurs et de déporter tous les traitements de coordonnées vers un PC, pocket PC ou PDA. Après analyse des possibilités du PIC ce plan B reste un plan B au cas où je me plante.

Donc je continue le chemin jusqu'à arriver aux limites du PIC, conscient que je ne pousserai pas beaucoup plus loin mais aussi que c'est la meilleure méthode pour obtenir les meilleurs algos que j'envisage toujours les plus universels possibles. Faire le maximum avec le minimum reste toujours la meilleure solution, l'inverse c'est l'approche Microsoft.

Si mes propos t'ont paru désagréables, c'est volontaire de ma part, il ne faut pas me dire que quelquechose n'est pas faisable j'ai systématiquement la réaction de dire que quand on sait faire on y arrive. C'est une spécialité: relever les défis et faire fonctionner ce qui n'a jamais fonctionner correctement. Pisseur de code et informaticien compétent c'est comme boucher et chirurgien, il fallait bien te titiller pour savoir de quel clan tu fais partie.

Amicalement

Arnaud

Salut,

j'ai regardé les sources des driver ASCOM, les fonctions de conversions sont présentes dans la dll astro32.

Dans les drivers Meade classic et lx200 les commandes alt-az ne sont pas implémentées.

Avis aux amateurs de VB, quelques heures de boulot et il sera possible d'avoir une version 100% altaz.

Arnaud

Salut,

J'ai vérifié les formules. Sauf erreur de ma part, les formules sont celle ci :

Vaz = -sin(lat) + tan(hau) cos(az) cos(lat) (attention au signe moins)

Vhau = -sin(az) cos(lat)

Et en prime time, l'équation de rotation de champ :

Vrot = -cos(az)*cos(lat)/cos(hau)

Les conventions utilisées pour les angles sont celles classiques :

azimut : 0 au Nord et + vers l'Est

hauteur : 0 à l'horizon, + vers le zenith, et de -90 à +90

Toutes ces formules sont en fait dans le document http://www.obs-hp.fr/~lardiere/chapitres-controle-telescope.pdf,'>http://www.obs-hp.fr/~lardiere/chapitres-controle-telescope.pdf, mais il faut prendre une feuille, un crayon et pas se perdre dans les conventions d'angle!

Effectivement la complexité semble au premier abord divisée de beaucoup... mais ce n'est qu'en apparence. Cela revient strictement au même de convertir les coordonnées équatoriales en alt-az puis d'utiliser ces formules, ou bien d'utiliser directement les formules de vitesse en équatorial.

Enfin, même si les formules ci-dessus divergent vers le zénith, il faudrait déjà avoir pas mal de malchance pour vouloir suivre un astre qui va passer pil poile au zénit, mais aussi avant d'atteindre des vitesses prohibitives (disons plus que 300x), il faut être à moins d'un degrès du zénith... Ceci laisse donc pas mal de marge de manoeuvre.

Pour avoir un ordre d'idée, les vitesses necessaires pour s

Suivre un astre à une hauteur de 89.5° sont de l'ordre de 82x, et pour une hauteur de 89.9°, de l'ordre de 415x...

J'ai vérifié et revérifié mes calculs qui semblent correct, mais je ne suis pas à l'abris d'une erreur. Si Arnaud tu pouvais confirmer avec le fichier Excel ce serait bien.

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

Salut Daniel,

ta formule ne fonctionne en Az, le signe - ne semble pas correct mais rien ne nous dit que le document de référence soit parfait.

Erreur, sous toute réserve, aussi sur les vitesses au zénith ( az 180, hau 89.5) la vitesse est de 1200X et à hau=89.9 6000X

Dans le cas d'une version altaz, les données entretenues dans PIC-ASTRO sont justement ALt et Az. Pour permettre d'avoir un simple suivi il n'est donc pas nécessaire de faire des conversions et les sin(alt) et cos (alt) sont des constantes; ces formules sont donc faciles à utiliser.

Les données AD,De ne sont utiles que pour les échanges avec un logiciel cartographie, etc... donc lors d'une Synchronisation ou d'un goto. Ces commandes sonr relativement rares, plusieurs minutes entre chacune et si le traitement prenait plusieurs secondes, ce temps n'aurait que peu d'incidence sur la précision des opérations. Les commandes les plus fréquentes seront, sans nul doute, celles de demandes de coordonnées du télescope; la période entre 1 ou 2s pourrait occasioner une saturation du PIC à cette même période, le cas ne se présente pas si le logiciel rtravaille réellement en Alt-az et demande AZ,haut.

Je ne suis pas un expert dans ce domaine et si mes références ne sont pas bonnes je peux dire de grosses bêtises.

Arnaud

Bonsoir,

Je maintiens les vitesses proche du zénith . Les valeurs que tu donnes sont les vitesses, mais exprimées en ''/sec. Il faut encore les diviser par environ 15 pour obtenir les vitesses en unité x .

En ce qui concerne le signe -, je viens de refaire tous les calculs à la main, et il ne me semble pas m'être trompé. Pour cela j'ai utilisé la méthode de référence, mais ai reposé tous les changements de repère.

Bon, j'ai pu quand même me tromper, mais en tout cas mes calculs sont en total accord avec ceux du document de référence.

Ca serait intéressant de demander aux personnes qui t'on donné les formules, d'où elles vienne, pour pouvoir vérifier encore une fois.

Le signe n'est pas si anodin, surtout aux basses vitesses.

En tout état de cause, le juge de paix sera le ciel!

Daniel

Salut,

un petit up pour donner des nouvelles.

Oui il y avait bien un problème de signe, les tests menès il y a quelques mois l'ont démontré. Le point intéressant est que pour pouvoir passer le zénith il faut que la vitesse minimale de Goto soit de 300X, avec la solution adoptée ( calcul des vitesses instantanées).

J'ai fait les tests en mettant quelques verrues dans le driver ASCOM lX200GPS. Astrimage développe actuellement un driver spécifique PIC-ASTRO dans un premier temps en équatoriale en suite on y ajoutera les fonctions spécifiques altaz.

Le projet tient la route, c'est le principal et en effet le ciel nous dira si c'est bon ou pas.

Pour pouvoir aller plus loin il va falloir changer de technologie, je commence à travailler sur une version plus sérieuse qui sera sûrement une version commerciale car entièrement en CMS donc irréalisable par un amateur mais comme je tiens aussi à ce que chacun puisse faire comme il l'entend je prévois aussi une version hybride: carte logique ( processeur en CMS) plugable sur une carte interface en composants "normaux". Cette nouvelle architecture permet de piloter un dérotateur de champ, d'avoir jusqu'à 2048 µpas par demi-pas, de gérer des encodeurs, d'être piloté par ethernet, série ou usb etc... Un très gros boulot en perspective, intéressant car on améliore encore le système sur tous les points à un coût défiant toutes concurrrences.

L"aspect commercial me dérange un peu mais il faut bien que je récupère, en partie les investissements consentis et m'assure ma future retraite ( par les temps qui courent c'est plus prudent).

Arnaud

tu viens au RAP pour démonstrater???

Non,

désolé, mais je suis un peu excentré (coté Ouest).

Je ne dispose pas de monture ALtaz. Les tests sont faits "indoors", en utilisant CDC avec le driver LX200GPS modifié et les informations retournées par PIC-ASTRO (position Altaz des moteurs).

Les positions retournées sont très fiables, les tests ont duré des dizaines d'heures ( voir centaines), les cas critiques identifiés ( trouver une cible qui passe exactement au zénith, dans certains cas il faut plus d'une heure), essais aussi nombreux dans les cas de vitesses lentes ( erreur de signe) puis dans des positions aléatoires. Tous ces tests ont montrés des dysfonctionnements qui ont été résolu par la correction de signe.

Ce n'est pas forcement exhaustif, il faudra des béta-testeurs qui disposent du matériel adéquat mais aussi du driver spécifique. Je propose une solution qui ne peut être que perfectible et reste disponible pour la mettre au point. Dans le registre, nous travaillons aussi ( là j'ai des testeurs) pour des améliorations permettant le remote le point délicat étant la fonction Park mais avec le driver spécifique les risques ont été levés.

Arnaud

Le CMS n'est pas du tout irréalisable pour l'amateur. A condition d'avoir un circuit de qualité (solderscreen) c'est tout a fait faisable.

Tu pars directement sur des drivers type allegro? Quid de l'alim, toujours 12v ou passage a des tensions supérieures pour gagner en vitesse?

Que voilà une excellente nouvelle!

Toujours intéressé pour un goto/pushto pour ma Macrostar

S'il faut passer par un constructeur qui monte le kit complet, ça reviendra à combien au final?

Salut,

CoreDump, par amateur je sous-entends débutant, déjà que beaucoup n'ont pas osé se lancer dans la version "DIL".

J'ai eu des nouvelles du driver cet après-midi, en équatoriale c'est OK il faut maintenant procéder à quelques évolutions du soft PIC-ASTRO ( une version spéciale avait été faite pour vérifier les Park) puis les essais plus poussés. L'objectif est d' avoir l'ensemble mi-Juillet pour présentation aux rencontres Astrimage, donc diffusion pour Aout ou la rentrée au plus tard ( délais non garantis en cas de manque de disponibilité).

Astroperenoel, le sujet est récent et il faut donc se poser beaucoup de questions: trouver la société pour réaliser et distribuer le produit, définir le produit basé ur la version actuelle mais pour une version commercialisable il faudra sans doute modifier et ajouter quelques petits trucs ( liaison USB, possibilité de charger le PIC in situ par exemple)... Difficile donc de répondre à la question du coût, plus facile pour la stratégie il faut trouver un partenaire compréhensif qui puisse proposer les CIs nus, les CI montés ou des PIC-ASTRO clés en main. Sans compter la négociation du contrat.

Suite au prochain épisode.

Arnaud

Salut,

je déterre le post pour informer ceux que cela intéresse que j'ai mis à disposition une version à tester sur le ciel:

http://astrocoolpix.net/www/index.php?showtopic=7376

C'est la version d'époque que j'ai revalidée ( en labo avec CDC), petites mises au propre et rouler jeunesse.

Amusez-vous bien.

Arnaud