Observatoire du Prieuré Gradignan

Motorisations

 Accueil Remonter

 

 

Cet article a figuré au sommaire de la revue CCD & Télescope de l'association Aude


Systèmes de motorisation de télescopes

Préliminaires

Cet article ne constitue pas un cours sur les asservissements, mais le produit de mes réflexions et de l'expérience acquise au fil des ans dans mes réalisations d'un observatoire et d'une monture complète (à l'exception notable du tube optique, qui est celui d'un Celestron 8 pouces).

Le contexte est clairement celui de la réalisation par l'amateur, ou mieux par un club d'astronomie, de montures de bonne qualité, adaptées, outre l'observation visuelle, aux diverses techniques que nous mettons maintenant en oeuvre sans trop de complexes, comme la photographie à longue focale, la prise d'images CCD, la spectrographie CCD, l'astrométrie, la photométrie, la surveillance du ciel en vue d'identifier des (super)novae, des astéroïdes, etc.

L'expression du besoin en termes de précision statique et dynamique du système tiendra donc compte des contraintes issues de ce contexte scientifique -ou prétendu tel, pour les modestes-.

Cet article permettra de vérifier que les technologies nécessaires à la satisfaction du besoin sont aisément accessibles à l'amateur -ou mieux à un club, supposé plus "argenté", mieux nanti en compétences complémentaires, et soucieux d'utiliser les synergies pour bien faire-.

Situation du problème et données d'entrée

"E pure se muove", disait Galilée. Elle tourne, et en première approximation, elle le fait à vitesse angulaire constante autour d'un axe fixe. Par suite, un objet de la "sphère des fixes" se trouve à tout instant, par rapport à un système de coordonnées privilégié, à une position théorique sur le ciel (non corrigée de la réfraction) qui évolue de manière linéaire par rapport au temps. Que la monture utilisée soit ou non équatoriale, et même si les deux axes mécaniques dont elle dispose ne sont pas perpendiculaires, il est facile de déduire d'une position théorique donnée à un temps donné où elle se situera en un autre temps, pourvu que la géométrie du système soit elle-même connue.

Quels moyens peuvent-ils être mis en oeuvre pour réaliser la fonction principale d'un système de commande de télescope, c'est à dire le suivi précis et de longue durée d'une cible céleste?

Dans une monture azimuthale, la position des deux axes (site et azimuth) doit être à l'évidence fonction du temps. 

Qui plus est, il se produit une rotation du champ, elle-même fonction complexe du temps, qui implique, pour la prise d'images, l'usage d'un "dérotateur de champ".

Le système privilégié est la monture équatoriale, puisque en première approximation, le seul mouvement d'ascension droite à vitesse constante (une rotation par jour sidéral) permet le suivi d'un objet. Dans les faits, le phénomène de réfraction atmosphérique, qui n'est jamais négligeable, implique que tant le mouvement d'ascension droite que celui de déclinaison soient en permanence corrigés. On se retrouve donc avec un problème analogue à celui posé par les montures altazimuthales: deux axes doivent être contrôlés, et ce constat implique que les positions des axes soient rafraîchies en permanence en fonction d'un calcul itératif fourni par un ordinateur.

Dans le cas particulier d'une monture installée dans un observatoire à dôme, il est souhaitable de contrôler la rotation de la coupole. Si la monture est azimuthale, l'ouverture du dôme se situera dans l'axe du télescope. Pour une monture équatoriale, il faudra également passer des coordonnées équatoriales aux coordonnées altazimuthales pour générer cette position.

Il est théoriquement possible d'utiliser tous types de moteurs (hydrauliques, pneumatiques, à vapeur ou à explosions). On se limitera ici aux type les plus accessibles que sont les moteurs électriques de toutes natures: ils sont bien assez nombreux.

Les catégories de moteurs :

Moteurs à courant continus
  • gamme de vitesse importante sans modification appréciable du comportement; vitesses maximales élevées, jusqu'à plusieurs milliers de t/mn.
  • courbe de couple en fonction de la vitesse "plate", donc capacités d'accélération ou de freinage importantes.
    La variation de vitesse s'obtient par variation de la tension aux bornes, facile à obtenir soit d'un ampli de puissance basse fréquence, soit par découpage avec modulation de largeur d'impulsion (MLI ou PWM). L'électronique nécessaire est dans les deux cas simple.
  • Faible coût.
Moteurs asynchrones
  • Comme les précédents, mais la variation de vitesse ne peut s'obtenir que par utilisation d'un variateur de fréquence de réalisation difficile et de coût élevé.
  • Ont un "glissement" qui complique la commande
Moteurs synchrones
  • Comme les précédents, mais absence de glissement, sous réserve de ne pas exiger trop de couple.
Moteurs pas à pas
  • résolution angulaire faible: le rotor ne peut assumer que des positions discrètes, ces positions ne sont précises que si le couple résistant est constant. Une commande en "micro-pas" améliore les choses, mais il faut noter d'une part que le nombre de micro-pas est limité, et que la position de chaque micro-pas est imprécise car le couple varie entre micro-pas. Les irregularités de couple résistant (durs, "crasses" dans les réducteurs, sont directement répercutées sur la précision de positionnement.
  • vitesse maximale faible, de l'ordre de 20 tours secondes, et ce seulement pour une alimentation "étudiée" (alimentation des phases depuis une tension élevée à travers des résistances).
  • de ce fait, la gamme de vitesse est elle même faible. Il est donc à peu près impossible de calculer un système qui soit à la fois rapide en mode de positionnement sur le ciel (slew), précis en mode de suivi (track), et résolu. Une solution consiste alors à installer un autre moteur pour les déplacements rapides, mais on perd alors la connaissance des positions. Mettre directement sur les axes de sortie des codeurs n'est pas satisfaisant, sauf si l'on installe des codeurs très résolus (plus de 100000 points), extrêmement coûteux.
  • existence de modes de vibration (résonances) à certaines vitesses qui ne peuvent donc être maintenues, mais qu'il faut bien traverser lors de montées ou descentes de vitesse.
  • existence de vibrations à harmoniques élevées: chaque pas est un "choc" qui induit des vibrations dans la mécanique et peut "exciter" par exemple une monture à fourche.
  • impossibilité de réaliser des sauts de vitesse par variation brutale de la fréquence des impulsions entrantes, sous peine de décrochage du moteur. Par suite la génération des impulsions doit se faire en "rampe de fréquence", ce qui est difficile à réaliser par logiciel, ou bien implique du matériel (génération d'une rampe de tension alimentant un convertisseur tension/fréquence: dans ce cas il faut ajouter un compteur d'impulsions, ce qui enlève beaucoup d'attrait à ce type de solution).
  • commande simple: quelques transistors de puissance suffisent, mais il faut noter que c'est exactement ce qu'il faut pour réaliser une commande en PWM pour moteur à courant continu: il n'y a donc pas là un avantage déterminant.
  • asservissement en position simple à réaliser; pour connaître la position du mouvement, il suffit de tenir le compte des impulsions envoyées au moteur. Ceci n'est vrai bien sûr que si la mécanique est de bonne qualité et ne présente pas de "dur" susceptible de faire "manquer des pas" (c'est une exigence absolue).
  • faible coût, du même ordre de grandeur que pour les moteurs à courant continu.


Les moteurs "brushless"

Ces moteurs sans balais sont parmi les meilleurs que l'on puisse se procurer actuellement. Ils comportent des capteurs de position du rotor qui autorisent l'électronique de puissance spécifique associée à réaliser une commande des phases du moteur autorisant un couple optimal à chaque vitesse. Ils possèdent par ailleurs un forte "puissance au litre", mais sont très coûteux, et donc plutôt réservé aux applications de luxe, ou dans lesquelles le coût de la motorisation ne constitue qu'une faible partie des coûts globaux. S'agissant des mouvements simples d'un télescope, j'aurais tendance à penser que leurs qualités seront rarement exploitées, sauf à le transformer en théodolite pour suivre les missiles de l'île du Levant ou du Centre d'Essais des Landes.

Dans ce contexte, il semble bien que les moteurs à courant continu soient à préférer.

Les catégories d'asservissement utilisables :

  • Commande de positionnement en boucle ouverte (c'est à dire sans rétroaction sur la base des informations d'un capteur de position et/ou de vitesse). C'est celle qu'autorise l'utilisation de moteurs pas à pas. Elle est économique, ne serait-ce que parce qu'elle ne nécessite ni codeurs de position ni génératrice tachymétrique, et n'implique que peu de matériel s'agissant de l'interface à l'ordinateur de commande et des étages de puissance qui contrôlent les phases des moteurs. Elle est aussi peu performante car elle présente tous les défauts spécifiques de ces moteurs tels qu'explicités plus haut. Moyennant des compromis, elle permet en tout état de cause des réalisations d'amateur tout à fait honorables, comme par exemple le système de motorisation de Dobson réalisé par Mel Bartels et visible sur l'internet (Ref 2). En association avec une caméra CCD montée en autoguideur, et pour des longueurs focales faibles, elle permet un suivi de qualité acceptable.

 

  • Commande de positionnement en asservissement de position ; c'est la voie royale, et elle est bien sûr plus coûteuse que la précédente, car elle implique l'utilisation d'une carte d'axes et de capteurs de position (codeurs incrémentaux) et quelquefois de vitesse (génératrice tachymétrique). La nécessité des capteurs vient de ce qu'un tel asservissement se compose en général d'une "boucle" (régulation) de vitesse située à l'intérieur d'une "boucle" de position. Dans la pratique, l'information de vitesse est obtenue par dérivation de la position, et seul un codeur de position suffit. Ces capteurs, en version industrielle, sont coûteux, mais il faut savoir que Hewlett-Packard possède une gamme de capteurs dont le prix unitaire est de l'ordre de 500F (Ref 3).
    Pour ce qui est de la carte d'axe, elle se situe (avec des exceptions, comme expliqué plus loin) sur le "bus" de l'ordinateur de commande; ses rôles sont:


    • de recevoir les informations des codeurs et de "maintenir" les positions des axes dans des compteurs accessibles à l'ordinateur.
    • de générer les informations de commande des amplificateurs de puissance linéaires ou à découpage.
    • de recevoir et exécuter les ordres de positionnement ou de mise en vitesse de l'ordinateur hôte, quelquefois aussi de réaliser des "profils" de mouvements trapézoïdaux. Certaines cartes permettent l'interpolation linéaire de deux ou plusieurs axes, leur permettant, pour des mouvements de grande amplitude, de partir et d'arriver en même temps à la cible.
    • de gérer la "quotidienneté", comme par exemple les contacts de fins de course, les contacts de prise d'origine machine, les erreurs de poursuite (blocage, "dur", etc.), la raquette de commande du télescope, etc.

    Il en existe de nombreux types commerciaux, et elles coûtent en général plusieurs milliers de francs. Vu la nature simple des mouvements effectués par un télescope, les plus simples et les moins coûteuses d'entre elles sont parfaitement adaptées, les plus chères amenant des possibilités qui ne sont requises que dans le domaine de la machine-outil. Qu'il s'agisse de contrôler le télescope en mode suivi (la précision de positionnement et la fréquence de son rafraîchissement prédominent) ou en mode positionnement (seules la vitesse et l'accélération du mouvement comptent), la seule fonction réellement exigible de la carte est "va à la position donnée à la vitesse maximale et avec les accélérations maximales données".


    Il est possible de réaliser la fonction "carte d'axe" en logiciel dans l'ordinateur hôte, ce qui permet une économie correspondante en matériel, au prix d'une programmation plus importante (algorithme PID, interpolation linéaire, génération logicielle d'accélération). Dans ce cas, il faut munir l'ordinateur de cartes d'entrées/sorties logiques et analogiques pour s'interfacer avec l'électronique de puissance, les codeurs de position, la raquette, etc. L'avantage d'une telle solution est douteux.

     

  • Commande de positionnement en asservissement de vitesse.

La sagesse populaire indique souvent que le mouvement d'ascension droite d'un télescope est un mouvement à vitesse constante (en première approximation), et que sa réalisation la plus simple est un asservissement de vitesse. C'est bien ainsi que sont réalisées les commandes de télescopes du commerce, qui offrent même le luxe de plusieurs rythmes (sidéral, lunaire, "King"). Le suivi de longue durée n'est pas compatible avec cette conception, car, aussi faible que soit l'erreur de vitesse, elle est cumulative.

Pour la corriger, il faut pouvoir mesurer les positions et rectifier la valeur de la vitesse de commande, ce qui nous ramène au problème précédent! Il est à noter que les commandes numériques industrielles (qui incorporent des cartes d'axes), réalisent leurs asservissements de vitesse (par exemple pour la broche d'un tour) en mode asservissement de position, par calcul permanent de la position suivante à atteindre pour une vitesse donnée.

Les moyens de réalisation

Chez les riches, on utiliserait une carte d'axes multi-axes du commerce pour contrôler ascension droite, déclinaison, rotation du dôme, focalisation de l'optique, en association avec des moteurs "brushless" et leur électronique associée. Le coût d'un tel système, en configuration trois axes, devrait se situer aux alentours de 120 KF pour les fournitures (logiciel non compris), mais dépend bien sûr de la mécanique du télescope. Un exemple de riche est Alain Maury, qui, avec ses collègues et pour le compte du télescope de Schmidt de l'observatoire de la Côte d'Azur , a du temps pour programmer quand il fait mauvais, peut utiliser de nombreux stagiaires et thésards, a des tas de copains calés en mécanique céleste au Bdl, et fait ce genre de choses en s'amusant.

Les pauvres amateurs ou les clubs sans ressources ont quelques possibilités:

  • Si l'hypothèse de base est que le club ne possède que peu de compétences en électronique, le mieux est de se procurer une carte d'axe pour PC, d'équiper la monture de moto réducteurs et de codeurs incrémentaux et de réaliser un logiciel de commande du télescope qui sera interfacé avec la carte grâce au logiciel livré avec elle. Le coût global des fournitures ne devrait pas excéder 10000F, ou 20000F s'il est décidé d'utiliser des réducteurs de précision de type "Byers" ou équivalent (on peut en général s'en passer sur l'axe d'ascension droite par usage d'un entraînement à galets, intrinsèquement précis, mais l'axe de déclinaison ne peut pas bénéficier de cette solution). Les variateurs de commande des moteurs sont simples à réaliser (même schéma que les amplificateurs BF Audio), ou peuvent s'acheter (modules amplis de puissance Audio disponibles auprès des magasins de bricolage électronique). Un ampli de 30 à 100 Watts est adéquat pour la commande d'un moteur dans une monture de taille moyenne (quelques dizaines de kilogrammes).

Les "vrais" "pauvres amateurs" peuvent faire ce que j'ai fait (Ref 1):

  • Réalisation d'un ensemble de cartes d'axes et de cartes de puissance en modulation de largeur d'amplitude installées sur un bus passif muni de connecteurs G64, dans le style du Bus VME. Il est nécessaire d'installer des codeurs incrémentaux sur chaque axe; la carte peut contrôler trois axes, et fonctionne, dans la version actuelle, via le port parallèle de l'ordinateur. Le circuit qui réalise l'asservissement est le HCTL1000 de Hewlett Packard.
  • Ecriture du logiciel d'interface avec ce hardware (unité Pascal/Delphi).
  • Réalisation d'un logiciel sous Windows 95 de contrôle du télescope, sur la base des algorithmes de calcul de Jean Meeus (Ref 4), et possédant les fonctionnalités suivantes:
  • Suivi sidéral, lunaire et planétaire. Les positions sont rafraîchies à 50 Hz (pour la beauté du geste, 20 Hz suffiraient dans les applications les plus exigeantes).
  • Positionnement sur le ciel, à une vitesse qui ne dépend que des rapports de réduction et de la puissance des moteurs (il n'y a pas de limitations "à priori").
  • Compatibilité avec les autoguideurs (ST4, Cookbook).
  • Compatibilité avec le MEADE LX200, et donc avec tous les programmes de planétarium capables de contrôler celui-ci (Guide, Megastar, etc.), ce qui permet de bénéficier de l'accès à toutes les bases de données qu'ils apportent.
  • Interface avec des bases de données au format DBASE ou MicroSoft Access (BDD LX200 et toute autre base de donnée créée depuis les dizaines de catalogues d'objets disponibles).

Les fonctionnalités suivantes sont en projet:

  • Commande de la caméra CCD, en mode acquisition ou en mode guidage (éventuellement les deux à la fois). Cette interface impliquerait une DLL par type de camera, je dispose pour l'instant des interfaces pour caméras CookBook 245/277, Apogée et ST6.
  • Commande de l'appareil photographique (electro-aimant de déclenchement).
  • Interface avec un ordinateur distant (celui qui se trouve dans mon bureau, bien au chaud) par protocole Netbios (NETBEUI chez Bill Gates).
  • Interface avec un ordinateur distant (sur l'Internet) par protocole TCP-IP, avec interface HTML ou ATIS.

Les circuits imprimés ont été réalisés en simple face, mais pourraient l'être en double face à trous métallisés pour une petite série.

Il faut noter qu'une telle réalisation nécessite quelque expérience en électronique, et n'est probablement pas accessible à un débutant. Dans la mise au point des cartes, il faut savoir se servir d'un fer à souder et avoir accès à un oscilloscope; Canal + a cependant beaucoup fait pour démocratiser l'électronique dans les années récentes. Le logiciel actuel s'interface avec mes cartes, mais du fait de la conception modulaire du langage Pascal, il serait facile de le modifier pour le rendre compatible avec tout autre carte d'axe du commerce: tout ce qui est spécifique de l'électronique que j'ai réalisée figure en effet dans une seule et même unité Pascal/Delphi.

Si cette réalisation est susceptible d'intéresser certains, on peut me contacter en email; le système étant encore en phase de développement, ou plutôt "d'enrichissement", je n'ai encore rien publié sur le Web, mais tout est là, et le système fonctionne fort bien.

Références

1. Ma "home page": http://www.atlantic-line.fr/~soubie. Un lien mène à une rédaction que j'ai faite au début de mon étude, et qui a un peu vieilli, les spécifications ayant évolué.

NB: voir maintenant en http://www.astrosurf.com/soubie

2. Dobson motorisés par pas à pas en mode "micro-stepping": http://www.zebu.uoregon.edu/~mbartels/altaz/altaz.html. Liens intéressants vers divers sites en rapport avec le contrôle de motorisations.

3. Codeurs optiques Hewlett Packard: http://www.agilent.com/.

4. Jean MEEUS: Astronomical Algorithms; édité par Willmann-Bell, Inc. ISBN 0-943396-35-2.


 

Accueil Remonter

Envoyez un courrier électronique à robert.soubie@free.fr pour toute question ou remarque concernant ce site Web.
copyright © 2001-2010 robert soubie ; dernière modification le 30 janvier 2010 00:08