46
Développement de la commande à distance de la ligne à retard d’OHANA Rapport de stage Vincent du Réau Mai – Juin 2006

Développement de la commande à distance de la ligne …20stage%20Vincent… · Rapport de stage Vincent du Réau Mai ... un interféromètre optique sur plusieurs télescopes situés

  • Upload
    buikhue

  • View
    215

  • Download
    0

Embed Size (px)

Citation preview

Développement de la commande à distance de la ligne à retard d’OHANA

Rapport de stage Vincent du Réau

Mai – Juin 2006

En couverture : Télescope CFHT et Gemini, Mauna Kéa, Hawaii.

2

Résumé Le projet OHANA: Optical Hawaiian Array for Nanoradian Astronomy, développé par le LESIA (Laboratoire d’Etudes Scientifiques et d’Instrumentation en Astrophysique) rattaché à l’Observatoire de Paris, est actuellement en fin de phase 2. L’objectif est de réaliser un interféromètre optique sur plusieurs télescopes situés sur le mont Mauna Kéa à Hawaii, la particularité étant d’utiliser des fibres optiques pour limiter les pertes sur le signal. Le montage dispose, entre autre, d’une ligne à retard qui permet d’égaliser la longueur des chemins optiques et ainsi obtenir des franges d’interférence. La ligne à retard possède déjà un système de contrôle - commande informatisé ; mais doit être pilotable à distance. Ce rapport fait état de la présentation et de l’avancement du projet, ainsi que du travail effectué au cours du stage sur la commande à distance de la ligne à retard. Il présente toutes les étapes de la réalisation de l’application commande Client/Serveur, développée avec le logiciel d’instrumentation LabView7, utilisant le protocole TCP/IP. Partir de l’idée, cibler les charges, les contraintes, et enfin concevoir.

3

Remerciements Je remercie Monsieur Guy Perrin, astronome et principal responsable de l’expérience OHANA, pour l’accueil accordé au sein du projet. Je tiens à remercier très particulièrement Pierre Fédou, mon responsable de stage, pour m'avoir encadré et guidé tout au long des deux mois passé à l’Observatoire ; pour sa patience dans les explications et ses nombreux conseils. J'adresse de sincères remerciements à toute l'équipe de OHANA ainsi qu’à tout le personnel du LESIA et de l’Observatoire de Meudon, pour leur accueil et leur aide.

4

Table des matières Résumé……………………………………………………………………………………….3 Remerciements……………………………………………………………………………….4 Table des matières……………………………………………………………………………5 Introduction…………………………………………………………………………………..6 I - L’Observatoire de Meudon……………………………………………………………..7 I-1 Historique…………………………………………………………………………7 I-2 Le LESIA…………………………………………………………………………… II – Le projet OHANA………………………………………………………………………10 II-1 Présentation d’OHANA…………………………………………………….......10 II-1.1 Résolution…………………………………………………………….11 II-1.2Principe général………………………………………………………..13 II-1.3 Phases du projet et localisation……………………………………….14 II-2 La ligne à retard : LAR…………………………………………………………15 II-2.1 La table à retard simulé : TRS………………………………………..16 II-2.2 La table à retard continu : TRC……………………………………….17 II-2.3 Le chariot central : CC………………………………………………..18 II-3 Avancement du projet, présentation du travail réalisé pendant le stage……......19 III – La commande à distance de la ligne à retard………………………………………..21 III-1 Présentation……………………………………………………………………21 III-2 Principe de la commande à distance sous LabView 7………………………....21 III-2.1 Connexion TCP/IP et Client/Serveur.....................................................21 III-2.2 Les commandes de la LAR précédemment développées……............23 III-3 Cahier des charges………....................................................................................24 III-3.1 Structure du programme….....................................................................24 III-3.2 LAR Réelle/Virtuelle….........................................................................24 III-3.3 Configuration….....................................................................................24 III-4 Développement des VIs……………………………………………………......25 III-4.1 La configuration……………………………………………………...25 III-4.2 Le Client……………………………………………………………..26 III-4.3 Le Serveur……………………………………………………………26 III-4.4 Les sous VIs………………………………………………………….28 III-5 Travail à venir………………………………………………………………….30 Conclusion…………………………………………………………………………………..32 Annexes……………………………………………………………………………………..33 Index………………………………………………………………………………………...45 Bibliographie………………………………………………………………………………..46

5

Introduction Découvrir les mystères de l’Univers et pousser toujours plus loin les limites d’observation, telle est la volonté des astronomes qui cherchent à concevoir des télescopes de larges diamètres. Plus le diamètre est grand, plus la quantité de photons collectés est importante et meilleure est la résolution angulaire. Ceci est indispensable pour recueillir les rares photons qui arrivent de l’espace lointain. Mais les grands télescopes interféromètres de la planète tels que les deux Keck (10 m) et le VLTI (4x8 m) ne suffisent plus à obtenir la résolution souhaitée. La HRA « Haute Résolution Angulaire » a pour objectif d’augmenter la résolution en interférométrie par l’utilisation de nombreux télescopes et deux technologies : l’optique adaptative et la fibre optique. La première corrige les turbulences induites par l’atmosphère, la seconde limite les pertes de signal dans l’air. L’Observatoire de Meudon et son département le LESIA « Laboratoire d’Etudes Spatiales et d’Instrumentation en Astrophysique » travaillent dans la lignée HRA en développant le projet OHANA « Optical Hawaiian Array for Nanoradian Astronomy ». Il vise la formation d’un interféromètre à partir des télescopes du Mauna Kéa à Hawaii à fin d’obtenir une résolution supérieure à celle du VLTI. Dans un premier temps nous relaterons les étapes du projet, et les éléments le constituant, dont la partie essentielle, la ligne à retard. Ensuite nous mettrons en avant le travail réalisé au cours du stage, autour du développement de la commande à distance informatique de la ligne à retard, via un réseau.

6

I - L’Observatoire de Meudon I-1 Historique La seconde moitié du XIXéme siècle fut marquée par la découverte de l'analyse spectrale et l'introduction de la technique de photographie céleste. Un immense domaine de recherches, que l'on baptisa "astronomie physique", était né. On l'appellera plus tard astrophysique. Cette nouvelle branche, où dominent la physique et la chimie, semblait suffisamment riche pour se "détacher du vieux tronc", en se développant rapidement dans un sol bien à elle, c'est à dire dans un observatoire spécifique. L'Observatoire de Meudon est installé en 1876 sur un ancien domaine royal, à la demande de Jules Janssen pour qu'il puisse y mener des recherches en physique astronomique. Le domaine, alors complètement en ruine, commence une nouvelle vie. Le château incendié durant la guerre de 1870, fut restauré pour recevoir en 1893 la grande lunette et le télescope de un mètre.

Figure 1: Construction de la coupole. Archive Observatoire de Meudon

La grande lunette possède deux objectifs (83cm et 62cm) un instrument unique en Europe par ses dimensions. Classée monument historique en 1972, elle fut utilisée pour l'observation des positions des astres, ainsi que l'étude des planètes et des comètes. Elle est actuellement inutilisée, et ce pendant toute la période de restauration de la grande coupole ; celle-ci ayant subi les conséquences de la tempête de 1999.

7

Le télescope de un mètre, quant à lui, sert à l'observation de la Lune, des planètes, des comètes et des astéroïdes. Il possède aussi une lunette munie d’un filtre polarisant sélectif, adapté à l’observation du Soleil. Deux spectrohéliographes sont installés en 1897 et 1906, puis le grand sidérostat est construit en 1908. La table équatoriale est mise en service en 1931 avec un télescope de 60cm utilisé de nos jours par les étudiants d'astrophysique. La dernière construction est la tour solaire, mise en service en 1969.

Figure 2: Observatoire de Meudon

L’Observatoire de Meudon fut rattaché en 1926 à l’Observatoire de Paris, qui compte désormais trois sites d’observation, Paris, Meudon et Nançay. De nos jours, l'Observatoire de Paris est un centre de recherches en astronomie et en astrophysique. Il est placé sous la tutelle du ministère de la Jeunesse, de l'Éducation nationale et de la Recherche, fait partie des Grands Établissements et revêt un statut d'université. La recherche s'organise autour des principaux thèmes en astronomie et en astrophysique. Les trois sites font de l'Observatoire le plus grand centre de recherche astronomique en France, et l'un des plus importants au monde ; représentant à lui seul un tiers de l'astronomie Française.

8

I-2 Le LESIA Le LESIA, Laboratoire d'Études Spatiales et d'Instrumentation en Astrophysique, est un laboratoire de l'Observatoire de Paris, sur le site de Meudon. C'est une unité mixte de recherche du CNRS, associée aux l'Université Paris VI Pierre et Marie Curie et Paris VII Denis Diderot. Il est issu du regroupement en janvier 2002 de plusieurs départements:

• DESPA (Département Recherches Spatiales), • DASOP (Département Solaire de l'Observatoire de Paris), • Groupes et chercheurs : ARPEGES, DAMAP, DASGAL.

Au 1er mars 2006, le LESIA compte 247 personnes, dont 153 chercheurs et 94 ingénieurs techniciens administratifs.

Figure 3: Organigramme du LESIA

La vocation du LESIA est la recherche scientifique dans le domaine de la physique des plasmas, de la physique solaire, de la planétologie et de l'astrophysique par le biais de la conception et la réalisation d'instrumentation scientifique embarquée à bord de sondes spatiales. Parallèlement à la recherche spatiale, le LESIA possède une vaste expertise instrumentale pour l'observation au sol, et joue un rôle de premier plan dans le développement de technologies avancées, telles que l'optique adaptative et l'interférométrie visible et infrarouge. L'activité du LESIA inclut le développement d'outils théoriques et de simulation numérique pour l'analyse des observations. Le LESIA dépend du pôle astronomie et est particulièrement spécialisé dans l'optique adaptative (dont les tip-tilts) et l'interférométrie à fibres. En ce sens, la haute résolution angulaire (HRA) est l'une des priorités actuelle et le projet OHANA regroupe ces trois domaines de l'optique astronomique.

9

II - Le projet « OHANA » II-1 Présentation d’OHANA OHANA est un acronyme de "Optical Hawaiian Array for Nanoradian Astronomy". Le principe de OHANA est de construire un interféromètre large base reliant des télescopes déjà existants au sommet du Mauna Kéa, à Hawaï. À terme, l'objectif est de faire un réseau reliant six télescopes du Mauna Kéa à Hawaï : Keck I, Keck II, CFHT, UKIRT, Subaru et Gemini.

Figure 4: Télescopes sur le Mauna Kéa, Hawaii

Ce projet et les techniques qui y sont développées, s'inscrivent dans la lignée HRA (Haute Résolution Angulaire) qui consiste à regarder le plus loin possible dans l'univers. Pour cela il faut concevoir de télescope aux diamètres toujours plus grands. Les télescopes de 10m ne suffisent plus mais la réalisation de diamètres supérieurs suppose d’énormes contraintes mécaniques. L’interférométrie propose une alternative avec une résolution équivalente à de grands diamètres ; On peut alors accéder à la physique stellaire. Caractéristiques des télescopes du Mauna Kéa :

• KECK - W. M. Keck Observatory, Diamètre: 2 x 10m • GEMINI - The Gemini North Observatory, Diamètre: 8,2m • SUBARU - National Astronomical Observatory of Japan, Diamètre: 8,2m • CFTH - Canada France Hawaii Telescope, Diamètre: 3,6m • IRTF - NASA Infra Red Telescope Facility, Diamètre: 3m • UKIRT- United Kingdom Infra Red Telescope, Diamètre: 3,8m

10

II-1.1 Résolution La finesse des détails d'une image astronomique est caractérisée par la résolution du système optique utilisé. Plus la résolution est importante et plus les structures fines sont visibles dans l'image. La résolution maximale des systèmes optiques est proportionnelle à leur taille. Dans le cas d’un télescope, la résolution angulaire est inversement proportionnelle au diamètre du miroir primaire :

Résolution angulaire R d'un télescope

R=λ/D en arcsec

D: Diamètre du miroir L: Longueur d’onde observée

Pour dépasser cette limite, on peut faire interférer de manière cohérente les faisceaux collectés par plusieurs télescopes sur un même objet astronomique. La résolution n'est alors plus donnée par la taille des télescopes mais par la distance qui les sépare. Ainsi, deux télescopes distants de 100m conduiront à une résolution équivalente à celle d'un télescope unique de 100m de diamètre.

Résolution angulaire R’ d'un interféromètre

R’=λ/B en arcsec

B: Base ou distance entre les deux télescopes L: Longueur d’onde d’observation

L'interférométrie avec deux télescopes ne permet pas d'obtenir une image, mais une figure de franges d'interférences. Cependant, le contraste des franges permet de déterminer la taille de l'objet observé à la longueur d'onde utilisée. En utilisant plusieurs bases, on obtient plusieurs mesures de visibilité, ce qui permet de déterminer la taille de la source. La connaissance du diamètre des étoiles permet de déterminer leur température et ensuite leur structure, selon les longueurs d'ondes d'observation.

Tableau 1: Longueur en mètres des lignes de bases formées par les sept télescopes du Mauna Kéa

CFHT IRTF UKIRT Keck I Keck II Subaru Gemini CFHT IRTF 346 UKIRT 349 457 Keck I 618 286 605 Keck II 518 237 616 85 Subaru 750 428 688 145 221 Gemini 163 412 204 642 626 756

11

L'objectif de OHANA est de mettre en place sur le sommet du Mauna Kéa un interféromètre optique à très longue base, de grande sensibilité. La réalisation de cet instrument repose sur deux technologies : L'optique adaptative Un front d'onde plane est déformée par son passage à travers l'atmosphère ce qui engendre une perte de résolution spatiale. L'optique adaptative permet de réduire ces pertes en corrigeant en temps réel les défauts du front d'onde. L'interféromètre peut alors utiliser les grands diamètres disponibles. La fibre optique monomode L'interférométrie en astronomie existe déjà (VLTI au Chili, Keck 1&2 à Hawaï). Les interféromètres existants arrivent à leurs limites car la propagation du signal dans l'air entraîne des pertes. De plus, OHANA doit s'intégrer sur des télescopes existants, qui n'ont pas été construits pour l'interférométrie. Aussi, le faisceau venu du ciel doit être injecté dans une fibre optique monomode, pour s'affranchir des pertes subies lors de la propagation dans l'air et ainsi augmenter la taille des bases possibles. L’utilisation de fibres optiques pour le transport de la lumière, des télescopes jusqu’au re-combinateur, limite la mise en place d'infrastructures avec miroirs optiques.

12

II-1.2 Principe général Les télescopes Gemini et CFHT sont pointés vers le même objet (étoile, planète, nébuleuse, galaxie). Les signaux sont reçus par le miroir principal de chaque télescope, puis envoyer vers leurs foyers respectifs. Ces deux télescopes possèdent chacun un système d’optique adaptative fonctionnant sur l’analyse de la surface d’onde (miroir déformable et actuateurs), qui permet de corriger les turbulences induites par l’atmosphère. Aux foyers, le signal venu du ciel est injecté dans les fibres optiques par l'intermédiaire des platines d'injection (PI), situées à la base de chaque télescope. Le signal issu du Gemini et propagé dans une fibre qui rejoint la salle d’expérience du CFHT, pour y être analysé par la ligne à retard.

Figure 5: Principe d'OHANA entre le Gemini et le CFHT

La ligne à retard (LAR) permet d'égaliser la longueur des chemins optiques avant la recombinaison des faisceaux. Ceci est particulièrement délicat puisque OHANA est monté sur des télescopes différents, possédant une optique adaptative différente, une construction différente, etc. Tous ces facteurs augmentent l'incertitude sur les chemins optiques et par conséquent le déphasage entre les faisceaux. A la sortie de la ligne à retard, les deux signaux sont « assemblés » par le re-combinateur, permettant enfin de visualiser des franges d'interférence qui peuvent ensuite être analysées. L’ensemble du système, injection dans les fibres au niveau des télescopes, commande de la LAR, et recombinaison, sont piloté par un ordinateur, l’interface étant conçue sous LabView 7.

13

II-1.3 Phases du projet et localisation Le projet OHANA se déroule initialement sur huit ans, développé autour de trois phases : Phase 1: 2000 – 2003 • Conception et réalisation des platines d'injection dans les fibres. • Tests sur les télescopes du Mauna Kéa à Hawaï. • Mesure du taux d'efficacité et de la stabilité des images vis-à-vis de l’optiques adaptatives. • Étude de la polarisation. Phase 2: 2004 – 2006 • Validation expérimentale : obtention de franges sur une des plus petite base (Gemini – CFHT). • Démonstration de l'intérêt scientifique. • Construction d'une ligne à retard permettrant, grâce à la démonstration scientifique et technique, l'obtention du financement pour le réseau entier. Phase 3: 2006 – 2007 • Observations et mise en place du réseau complet. Le site:

Figure 6: Le Mauna Kéa et ses télescopes, comparaison avec le VLTI

14

II-2 La ligne à retard : LAR La ligne à retard comporte principalement trois parties :

• Une table à retard simulé (TRS), ou table Schnee. • Une table à retard continu (TRC), ou table Aerotech. • Un chariot central (CC).

Figure 7: Principe de la ligne à retard, LESIA

Les signaux des deux télescopes arrivent chacun à une extrémité de la ligne à retard ; l’un du coté TRS, l’autre du coté TRC. Ils effectuent ensuite un parcours complexe par l’intermédiaire de miroirs, dièdres, etc. La fonction principale de la ligne à retard est d'égaliser la longueur des chemins optiques pour obtenir une différence de marche nulle et ainsi observer des franges d'interférences. Ceci en déplaçant les chariots. La position des différents chariots doit être connue à une fraction de longueur d'onde près. La longueur de la ligne à retard est de 14 m, dont 12m pour un faisceau optique. Ainsi puisque les faisceaux réalisent 4 aller/retour, la différence de parcours maximum entre les deux signaux est de 48m. La ligne à retard doit aussi permettre de suivre le paquet de franges grâce à un retard continu, l'objet observé étant en mouvement apparent du fait de la rotation de la Terre. Chacun des éléments de la ligne à retard supporte un ensemble d'optiques mobiles, qu'il faut pouvoir commander à distance, puis automatiser ces commandes pour optimiser le temps de réglage.

15

II-2.1 La table à retard simulé : TRS La table à retard simulé supporte le chariot Schneeberger dont la fonction est de simuler un retard variable dans le déplacement des franges d’interférence, en mode d'auto collimation. Cela permet de valider la procédure de recherche de franges afin d’optimiser les temps de réglage. Enfin, elle est utilisée pour vérifier, lors des observations, le bon fonctionnement de la ligne à retard indépendamment du reste de l'interféromètre.

Figure 8: Table à retard simulé, LESIA

Concrètement, ceci correspond au cas où on ne trouve pas les franges lors de l'observation. Une recherche en mode d'auto collimation permet alors de savoir si la ligne à retard est mal réglée ou si le problème est extérieur : Mauvais réglage des télescopes, fibres optiques endommagées, etc. Le signal arrive sur la table à retard simulé par la platine d'injection (PI) et effectue deux aller/retour dans la ligne à retard avant de sortir par le plateau de sortie (PS) pour être dirigé vers le re-combinateur. L'alignement motorisé est donc fait sur: La platine d'injection PI. Les miroirs d'entrée ME et de sortie MS. Le chariot Schneeberger. La platine de sortie PS.

16

II-2.2 La table à retard continu : TRC La table à retard continu supporte le chariot Aerotech, chariot de translation permettant de suivre les paquets de franges lors de l'observation puisque l'objet observé est en mouvement apparent du fait de la rotation de la Terre. Ce chariot doit être d'une grande précision, et implique une stabilité en position et en vitesse. Lors de l'observation, le chariot Aerotech "suit" les franges. Une commande de vitesse lui est envoyée à chaque instant, en fonction des observations faites. Il doit donc pouvoir répondre rapidement à chaque nouvelle commande.

Figure 9: Table à retard continu, LESIA

Le signal arrive sur la table à retard continu par la platine d'injection (PI) et effectue plusieurs aller/retour dans la ligne à retard avant de sortir par le plateau de sortie (PS) pour être dirigé vers le re-combinateur. L'alignement motorisé est donc fait sur: La platine d'injection PI. Le miroir d'entrée ME. Le chariot Aerotech. La platine de sortie PS. Le miroir de sortie est un ensemble indépendant, le FastScan (FS), qui fait varier la différence de marche continuellement et régulièrement autour de la différence de marche nulle d'une centaine de micromètres. Il balaie ainsi l'image autour de la différence de marche nulle pour visualiser les franges.

17

II-2.3 Le chariot central : CC Le chariot central est posé sur des rails d'une longueur de 12m entre les deux tables TRS et TRC. Les faisceaux effectuent chacun deux aller/retour, il peut donc générer un retard fixe pouvant aller jusqu'à 48m. Il permet ainsi une recherche rapide des franges pour trouver la position où la différence de marche entre les faisceaux est nulle.

Figure 10: Chariot central, LESIA

L'alignement motorisé sur le chariot central se fait en translation selon X, et en rotation selon Thêta-X (tangage) pour corriger l'altitude des faisceaux. Le mouvement du chariot se faisant selon l’axe Z (parallèle aux rails), et la translation selon X (perpendiculaire aux rails). Le chariot central est aussi motorisé pour le déplacement sur les rails. Le choix a été porté sur un moteur à courant continu et l'entraînement est à courroie. Enfin, ce chariot possède un capteur de position à ruban, le Meter Drive, d'une précision de 100μm soit une précision de 400μm sur la différence de marche, dont il faut lire l'information pour corriger la position du chariot.

18

II-3 Avancement du projet et présentation du travail réalisé pendant le stage Actuellement le projet OHANA est en fin de Phase 2. L’intérêt scientifique a été démontré, et la ligne à retard est construite. Au début du stage, la ligne à retard été construite depuis deux ans dans le hall d’intégration du CNRS de Meudon, l’Observatoire ne pouvant accueillir dans ses locaux une expérience de cette dimension (14m x 1m x 2m). Les derniers tests de réglage étaient en cours, j’ai eu l’occasion de la voir en fonctionnement, et de participer à ces tests. A défaut de signaux provenant de télescopes, nous utilisions un laser rouge, injecté dans le système optique de la ligne à retard. L’objectif étant de vérifier la quantité de flux lumineux en entrée et en sortie, pour les différentes positions du chariot central. Si le flux récupéré est faible ou nul, cela implique un mauvais alignement des miroirs. La position des miroirs est réglée par des moteurs qui permettent de réajuster l’alignement.

Figure 11: Coudé room au CFHT, ligne à retard en rouge, LESIA

Au cours des semaines suivantes, nous avons démonté la ligne à retard pour l’expédier par bateau vers Hawaii, où elle sera remontée à 4000m d’altitude dans la chambre expérimentale du télescope CFHT. Le travail a consisté en l’élaboration d’une liste de toutes

19

les pièces ; Mais particulièrement la création d’une notation logique qui puisse permettre un remontage aisé au niveau du câblage. (Voir en annexe) Cette partie du stage a permis d’assimiler toutes les données sur l’expérience et de s’intégrer progressivement, mais aussi d’avoir un aperçu sur la logistique d’un projet scientifique d’envergure tel que OHANA. La ligne à retard sera placé dans une chambre blanche (sans poussière) qui impose de prendre des mesures de précaution avant d’entrer. Il est donc nécessaire d’élaborer une solution qui permette la commande de la ligne à retard à distance. Or l’ensemble de moteurs est interfacé avec un ordinateur par des logiciels informatiques. Il est donc possible de créer une commande à distance, via un réseau local, ou bien même via Internet. La majeur partie de mon travail durant le stage était de programmer cette commande à distance ; c’est l’objet du paragraphe III.

20

III – La commande à distance de la ligne à retard III-1 Présentation

• Nécessité de la commande à distance La ligne à retard sera remontée en octobre prochain au sommet du mont Mauna Kéa, en haute altitude. Ceci implique des difficultés d’accès et des conditions de travail rigoureuses. De plus la salle contenant la ligne à retard est une salle blanche où la quantité de poussière est réduite au strict minimum. Dans ces conditions, il est difficile d’envisager la commande de la ligne à retard dans la même salle. Aussi la commande à distance devint une nécessité pour le projet. Elle permet de piloter la ligne à retard depuis n’importe quel ordinateur via le réseau (local ou Internet). Ceci par le développement d’une application Client/Serveur.

• Le choix de LabView: Cette ligne à retard et l'ensemble de OHANA en générale, doivent être pilotable par LabView (National Instrument). Ce logiciel permet d'écrire des programmes sous formes de modules, appelés VIs, ce qui est nécessaire dans le projet OHANA car son but est de s'intégrer dans différents environnements le plus facilement possible. Enfin, le programme de contrôle – commande et la commande à distance de la ligne à retard doivent pouvoir s'intégrer dans l'ensemble de pilotage et de contrôle de toute l'expérience OHANA ; c'est-à-dire la phase d’injection au niveau des deux télescopes, puis la recombinaison après la ligne à retard. III-2 Principe de la commande à distance sous LabView 7 III-2.1 Connexion TCP/IP et Client/Serveur

• TCP/IP sous LabView L'Internet Protocol (IP) et le Transmission Control Protocol (TCP) sont les outils de base de la communication à travers un réseau. Ce sont les deux protocoles les plus connus, qui sont à l'origine du nom TCP/IP. Avec le protocole TCP/IP il est possible de communiquer à travers des réseaux simples ou des réseaux interconnectés (Internet). Les différents réseaux peuvent être séparés par de grandes distances géographiques. Le protocole TCP/IP envoie des données d'un ordinateur relié à un réseau ou à Internet vers un autre. Comme le protocole TCP/IP est

21

disponible sur la plupart des ordinateurs, il permet de transférer des données entre différents systèmes. Le protocole TCP/IP peut être utilisé avec LabView, sur diverses plateformes puisque celui-ci possède les VIs et les fonctions nécessaires à la création de client et de serveur. L’Internet Protocol (IP) permet d’envoyer des données à travers un réseau, mais ne garanti pas la délivrance du message. Tandis que le Transmission Control Protocol assure la transmission sous forme de séquences, sans erreurs, ni pertes, ni duplications. Le TCP est basé sur un protocole qui implique la création d’une connexion avant l’envoi des données. Il permet l’établissement de plusieurs connexions d’origines différentes et en simultané. Pour cela on utilise une adresse IP, spécifique à chaque ordinateur, et on définit un port de réception. (Plusieurs ports possibles par adresse IP).

• Client/Serveur Le client et le serveur sont les deux éléments indispensables pour développer une commande à distance avec le protocole TCP/IP sous LabView7. Ils sont les deux parties qui dialoguent l’une avec l’autre via le réseau. Chacune envois et reçoit des données par TCP/IP. Le client est l’interface distante, qui envois des commandes prédéfinies au serveur via le réseau. Il attend que le serveur lui transmette les informations demandées. Le serveur est le « distributeur » d’information. C’est lui qui à travers le programme, interagit avec la ligne à retard et envois les informations demandées vers le client via le réseau.

Figure 12: Principe du Client/Serveur

En utilisant le Protocole TCP/IP, cela autorise la connexion de plusieurs clients sur un unique serveur. Chaque client étant identifié par son adresse IP et le numéro du port qu’il utilise.

22

III-2.2 Les commandes de la LAR précédemment développées Au cours de l’élaboration de la ligne à retard, l’équipe du projet OHANA a développé un certains nombres de VIs sous LabView, qui permettent de contrôler chaque éléments de la LAR ; En particulier, l’ensemble des moteurs qui déplacent les miroirs ou la position des différents chariots (Aerotech, Schnee et Chariot Central). Ces VIs ont permis de développer au fur et à mesure du temps, d’autre VIs visant le contrôle - commande de la ligne à retard entière. Voici les deux principaux: CC Interpol move, 3.vi

Ce VI permet le contrôle – commande d’une grande partie de la ligne à retard ; Déplacement et positionnement précis du Chariot Central le long des rails, ainsi que sa position en X (perpendiculaire au rails) et Theta-X (tangage). Il inclus aussi un mode d’alignement fin. LAR Manual Motor Move.vi

Ce VI permet de déplacer tous les moteurs de la ligne à retard, à l’exception des chariots Central, Aerotech et Schnee. Il concerne donc les moteurs pas à pas des miroirs et la position en X et Theta-X. Concernant la commande du Chariot Aerotech, plusieurs VIs ont été développés pour contrôler la position à tout instants, et la stabilité en vitesse. Mais pour l’instant ils ne sont pas encore intégrables dans un VI principal qui commande l’ensemble de la ligne à retard. Quant à la commande du Chariot Schnee, aucuns VIs n’a été écrit à ce jour.

23

III-3 Cahier des charges J’ai réalisé la programmation de la commande à distance autour d’axes principaux, définis selon la volonté des futurs utilisateurs du programme, en fonction de ce qu’ils en attendent. III-3.1 Structure du programme Développement de la commande à distance, de type Client/Serveur, sous LabView7, en utilisant le protocole TCP/IP, plutôt que la technologie DataSocket (réseau local, moins usité). Découpage du programme en cinq parties, concernant les éléments de la ligne à retard :

• Partie I Status : Pour permettre la configuration des éléments motorisés (voir configuration).

• Partie II CC : Pour gérer le déplacement du chariot central.

• Partie III Moteur : Pour la commande des miroirs pas à pas

• Partie IV et V, Aerotech et Schnee : Pour la gestion des chariots Aerotech et

Schnee. III-3.2 LAR Réelle/Virtuelle Pour développer l’application Client/Serveur en l’absence de la ligne à retard (celle-ci est partie en bateau vers Hawaii), il est indispensable de créer une simulation de la ligne à retard (LAR virtuelle). Celle-ci doit permet d’interagir de la même façon avec le programme Client/Serveur. De plus, la ligne à retard comporte un nombre important de moteurs (27) pour les miroirs et les chariots. Il est intéressant de pouvoir tester indépendamment chaque moteur, sans tenir compte de l’effet des autres moteurs. Ceci est donc possible avec une LAR virtuelle ; une partie des éléments peuvent fonctionner en réelle (présence physique et interaction) tandis que le reste peut être simulé par un VI (présence virtuelle et interaction). Le fonctionnement de la LAR peut être alors réel ou virtuel, pour l’ensemble de la ligne ou seulement une partie. III-3.3 Configuration Pour faire fonctionner correctement la commande à distance Client/Serveur, il est nécessaire de lui faire parvenir la configuration dans laquelle il va trouver les éléments de la ligne à retard. Pour cela il faut élaborer un fichier de configuration qui contiendra toutes les données concernant les moteurs (position, état, etc.)

24

III-4 Développement des Vis

Les VIs présentés dans cette partie sont le fruit d'un travail d'élaboration sur des versions successives. Les versions présentées ici, sont donc les plus récentes et reposent sur l'évolution des précédentes. On notera en particulier un souci de clarification des diagrammes par une programmation simplifiée mais tout aussi efficace. III-4.1 La configuration Lorsque le serveur est mis en route, celui-ci doit connaître l’état de chaque moteur ; présent/absent, position. La configuration va donc permettre de savoir quel moteur doit fonctionner en réel (moteur présent) et quel moteur va fonctionner en virtuel (moteur absent). Dans un premier temps, j’ai programmé un VI qui permet d’écrire un fichier de configuration. Le fichier est divisé en sections, elles même divisées en clés. Ici les sections correspondent aux moteurs, et les clés à l’état de chaque moteur (une clé pour présent/absent, une autre pour la position). LAR Ecrire Fichier Configuration.vi Ensuite il était indispensable de programmer un VI pour lire la configuration, et ranger ces données de configuration dans une variable globale. Celle-ci peut être appelée à tous moments par le serveur. Ceci permet de ne pas ouvrir le fichier de configuration à chaque fois ou l’on doit connaître l’état des moteurs. LAR Lire Fichier Configuration.vi

LAR Config Globale.vi

Enfin, il a semblé nécessaire de pouvoir changer la configuration en cours d’exécution du serveur. Ceci est particulièrement intéressant lors de tests, si l’on veut retirer ou ajouter des moteurs (mettre en réel-On ou en virtuel-Off). Pour cela, la configuration est changée par l’intermédiaire du VI client (Voir face avant du client, onglet Status, en annexe II), stockée dans la variable globale par LAR Ecrire Choix Status.vi. LAR Ecrire Choix Status.vi

25

La configuration changée ainsi en temps réelle, peut aussi être enregistrée sur le fichier de configuration, pour être utilisée lors du prochain lancement du serveur. Cette réécriture est effectuée par LAR Ecrire Fichier Configuration Bis.vi LAR Ecrire Fichier Configuration Bis.vi

III-4.2 Le Client LAR Client 7.vi

(Voir face avant et diagramme en annexe)

Le client et allumé après le serveur. Lors de son lancement, il envoi un message au serveur et ce dernier établit la connexion. Le client n’est qu’un moyen de communication, qui envoi des commandes et reçoit des données ; toutes les opérations sont traitées sur le serveur. Dans un premier temps le client reçoit la configuration initiale de la part du serveur. Il met ainsi a jour la page status. Si l’utilisateur désire changer la configuration, il peut sélectionner les moteurs qu’il souhaite mettre en virtuel. Il peut aussi enregistrer la nouvelle configuration dans le fichier de configuration via le serveur. Dans le cas d’un changement de configuration, le serveur renvoi une confirmation et met à jour la page status (voyants lumineux). Par la suite l’utilisateur peut envoyer différentes commandes, accessibles sur les quatre autres pages du client. Le client envoi donc les données vers le serveur, et ce dernier traite les informations. Les différentes commandes possibles, sont détaillées dans le paragraphe suivant. III-4.3 Le Serveur LAR Serveur 7.vi

(Voir face avant et diagramme en annexe)

Le serveur est toujours lancé en premier. C’est lui qui écoute les entrées sur le port spécifié, et attend la demande d’un client pour établir la connexion TCP/IP. Une fois la connexion établie, le serveur lit la configuration dans le Fichier de configuration et l’écris dans la variable globale.

26

Par la suite le serveur lis les commandes envoyées par le client et les exécute. En fonction des commandes reçues, il écrit une réponse, contenant les données éventuellement demandées, vers le client. Pour chaque commande demandée par le client, le serveur vérifie si le moteur sollicité est présent ou absent. Ainsi il détermine si il faut commander le moteur en réel ou en virtuel. Enfin dans le cas ou l’utilisateur du client change la configuration initiale, le serveur écrit la nouvelle configuration dans la variable globale et renvoi une confirmation vers le client (voyants lumineux). Descriptif des commandes : Chacune de ces commandes correspond à une page onglet de la face avant du client. Chaque page contient plusieurs commandes qui permettent d’envoyer des données vers le serveur.

• Status Permet de connaître l’état des moteurs, présent/absent et leur position actuelle. Il est possibilité de changer la configuration, et de l’enregistrer dans un fichier de configuration.

• Déplacement Chariot Central Permet de commander le chariot central, position et réinitialisation du chariot (HOME). En réel : CC interpol move 3 bis.vi En virtuel : LAR Move CC Virtuel.vi

• Déplacement des moteurs Permet de sélectionner un moteur de la ligne à retard et de déplacer à la position voulue. En réel : LAR Manual Motor Move 2.vi En virtuel : LAR Motor Move Virtuel.vi

• Déplacement Chariot Aerotech Commande de déplacement du chariot. En réel : A intégrer. En virtuel : LAR Move Aerotech Virtuel.vi

• Déplacement Chariot Schnee Commande de déplacement du chariot. En réel : A développer. En virtuel : LAR Move Schnee Virtuel.vi

27

III-4.4 Les sous VIs L’ensemble Client/Serveur est composé des deux VIs principaux ; LAR Client7.vi et LAR Serveur7.vi. Mais il a été nécessaire de développer des sous VIs, qui sont utilisé à plusieurs reprises dans le client et dans le serveur. Voici la liste des sous VIs développé au cours du stage : Au niveau de la configuration LAR Désassembler Config Globale.vi

LAR Assembler Config Globale.vi

La Configuration Globale est une variable globale organisé sous forme d’un tableau de cluster contenant des chaînes de caractères. Or le protocole TCP/IP envoi les données sous forme de chaîne et nom pas de tableau de chaînes. Dans le serveur il est donc nécessaire de désassembler le tableau de configuration pour le mettre en chaîne. Et dans le client, il faut assembler en tableau la chaîne de configuration reçue. LAR Modifier Config Globale.vi

Lorsque l’on change la valeur de la position d’un moteur ou des différents chariots (CC, Aerotech, Schnee), il faut écrire les nouvelles position dans la variable globale : Config Globale. Au niveau du déplacement des moteur LAR Es Tu Là.vi

Ce sous VI, permet de savoir si un moteur est présent ou absent ; c'est-à-dire réel ou virtuel, ou encore On ou Off. Il reçoit le nom d’un moteur et regarde l’état de ce moteur dans la variable globale Config Globale. Il retourne On ou Off, booléens qui vont déterminer l’utilisation en réel ou en virtuel du moteur.

28

LAR Manual Motor Move 2.vi LAR Motor Move Virtuel.vi

Dans le cas du déplacement des moteurs, si le booléen retourné par Es Tu Là.vi, est On (le moteur est présent), alors le sous VI utilisé est LAR Manual Motor Move 2. vi. Sinon : LAR Motor Move Virtuel .vi. Le principe est le même pour le déplacement du chariot central ; CC Interpol Move, 3Bis.vi pour la valeur On, LAR Move CC Virtuel.vi sinon. CC Interpol Move,3Bis LAR Move CC Virtuel.vi

Les deux VIs LAR Manual Motor Move 2.vi et CC Interpol Move, 3Bis.vi , sont des versions légèrement différentes des VIs LAR Manual Motor Move.vi et CC Interpol Move, 3.vi, développer précédemment par l’équipe OHANA. CC Interpol Move, 3.vi, est un VIs très évolué, dont nous n’utilisons pas toutes les possibilités dans la version actuelle de LAR Serveur7.vi. LAR Move Aerotech Virtuel.vi

LAR Move Schnee Virtuel.vi

On retrouvera le même principe pour la commande des chariots Aerotech et Schnee, lorsque les VIs de commandes réelles seront intégrable et développées.

29

III-5 Travail à venir Lors de l’élaboration du client et du serveur, je travaillais en mode local, c'est-à-dire que le client et le serveur se trouvaient sur le même ordinateur. Il suffisait d’écrire Localhost dans le champ adresse du client. Mais le but d’une commande à distance est d’avoir le client et le serveur sur deux ordinateurs différents. Cela a été fait, et nous avons réussi à créer la connexion entre le client et le serveur via le réseau interne de l’Observatoire de Meudon. Pour cela il suffit de changer l’adresse Localhost, par l’adresse IP de l’ordinateur où se trouve le serveur. Nous avons pu faire dialoguer le client et le serveur et envoyer les commandes de pilotage de la ligne à retard. Tout ceci en virtuel, puisque la ligne à retard est en chemin vers Hawaii. Voici la liste des travaux ultérieurs qui pourront améliorer l’application Client/Serveur : Détection des moteurs Par la création d’un sous VI, il serait intéressant de pouvoir détecter automatiquement la présence ou l’absence des moteurs lors du démarrage du serveur, et l’écrire dans la variable globale de configuration. Faire attention, dans ce cas, à la gestion du fichier de configuration. Fichier de configuration Pour plus de souplesse, il faudrait modifier le client et le serveur, au niveau de la configuration, pour que l’on puisse lire ou écrire autant de fichiers de configuration que l’on souhaite. Ainsi, plusieurs configurations pré enregistrées seraient disponibles. Commande Chariot Aerotech et Schnee Le client et le serveur devront être modifiés, pour intégrer les sous VIs de commandes en réel des Chariots Aerotech et Schnee. La version actuelle n’inclue que les commandes en virtuel pour ces deux éléments. Protection, limitation d’accès A terme, la commande à distance de la ligne à retard doit être utilisable sur toutes sortes de réseaux, y compris Internet. Ceci implique une protection indispensable pour empêcher les connections non désirées au serveur. Il faudrait donc développer un système de limitation d’accès, par exemple en contrôlant les connexions selon l’adresse IP du demandeur.

30

Nouveaux clients Il serait intéressant de créer de nouveaux clients, développés dans des langages et des logiciels de programmation différents de LabView, qui puissent interagir avec le serveur actuel. Ceci permettrait de récupérer les données du serveur, et de les manipuler directement sous un logiciel adapté. Ce travail nécessite un lourd remaniement de l’ensemble de l’application Client/Serveur. Ligne À Retard Virtuelle Dans l’objectif de faciliter les tests de l’application Client/Serveur, il faudrait développer un ensemble de VIs qui permettent de créer une simulation de la vraie ligne à retard. Cette simulation pourrait être d’une très grande utilité pour l’amélioration du Client/Serveur, jusqu’au remontage de la ligne à retard à Hawaii prévu fin 2006.

31

Conclusion Ce stage de deux mois m’a permis de mieux comprendre le travail d’une équipe de recherche, aussi bien sur le plan scientifique que logistique et humain. J’ai appris à m’intégrer dans un projet en cours, à produire un travail en partant de l’idée et le mener jusqu’à sa réalisation. Les objectifs fixés au début du stage ont été dans l’ensemble respectés. Le développement de la commande à distance de la ligne à retard, utilisant le protocole TCP/IP sous le logiciel Labview7, a été fait. Le principe Client/Serveur semble bien convenir aux attentes du projet. Les points principaux ont été suivis : gestion de la configuration, reconnaissance Réel/Virtuel, et l’application fonctionne. Le programme doit être testé sur les moteurs de la ligne à retard, pour confirmer les résultats. Des améliorations sont encore à prévoir, notamment sur la sécurité, pour envisager l’utilisation de l’application via Internet. Actuellement le projet OHANA se trouve dans une période charnière entre deux phases. La première étant la réalisation de la ligne à retard et la seconde, son utilisation in situ. Le développement de la commande à distance arrive donc dans une période propice à une optimisation du programme, avant l’expérimentation à Hawaii d’ici fin 2006. OHANA est un projet d’envergure de plus en plus reconnu. De sa réussite, dépend l’avenir de la HRA et la qualité des images que fourniront, dans quelques années, les grands télescopes à larges bases.

32

Annexes

A-I Photos de la Ligne à Retard

A-II Diagramme et Face Avant de:

LAR Client7.vi LAR Serveur7.vi

A-III Listes logiques, câbles et boîtiers

33

A-I Photos de la Ligne à Retard

Figure I : Coté Aerotech et ligne à retard, V.du Réau

34

Figure II : Chariot Central, V.du Réau

Figure III : Coté Schnee, V.du Réau

35

A-II Face Avant et Diagramme de: LAR Client7.vi

Les programmes sous LabView sont composés d'une face avant de commande, et d'un diagramme contenant le code.

Face Avant du Client

Figure I: Face Avant du Client, onglet Status, V.du Réau

Figure II: Faces Avant successives du Client, V.du Réau

37

Diagramme du Client

Figure III: Diagramme du Client, V.du Réau

38

LAR Serveur7.vi

Face Avant du serveur

Figure IV: Face Avant du Serveur, V.du Réau

39

Diagramme du Serveur

Figure V: Diagramme du Serveur,V.du Réau

40

41

A-III Listes des câbles et boîtiers Explications Les câbles sont nommés par leurs extrémités: Bi Ej Bk El Bi Ej 1ére extrémité Boite i Port j Bk El 2nd extrémité Boite k Port l Lorsque deux câbles sont connectés ensemble on note: Bi Ej R Bi Ej 1er Câble R BBi Ej Bk El 2 Câble nd

Les câbles ayant une extrémité reliée à l'ordinateur ou à un autre appareil, sont notés: Bi Ej Certains câbles reliés aux différents moteurs des miroirs ont conservé leurs noms Dans ce cas les extrémités et les ports portent le même nom

Liste des câbles

Ancien Nom Notation Câble libre 1 B1E1 B15E1 oui 2 B1E2 B15E2 oui 3 B1E3 B15E3 oui 4 B3E4 B15E4 oui 5 B2E5 B15E5 oui 6 B2E6 B15E6 oui 7 B2E7 B15E7 oui 8 B7E8 B15E8 oui

Status B10E1 B11E2 oui Schnee B7E1 B10E2 oui

Alim REM Aerotech B1E4 B4E1 oui Câble diode B1E5 B9E2 oui

Alim REM Schnee B2E8 B5E1 oui CC B3E1 B10E5 oui

Thêta X B3E2 RB3E2 oui CC – Thêta – X RB3E2 Non

X B3E3 RB3E3 oui CC – X RB3E3 Non Codeur Codeur B11E1 oui

REM Aerotech B4E2 B10E4 oui REM Schnee B5E2 B10E3 oui

J4 B6E1 RB6E1 oui J4J4 B8E1 RB6E1 oui

J1J1 J2J2 B6E2 B12E1 oui

CS B7E2 Non Aerotech1 B8E2 RB8E2 oui

Table Aerotech RB8E2 Non Alim 8 B8E3 oui

Tiroir com 2 B9E1 oui Mot CC B10E6 B11E7 oui Alim 10 B10E7 oui

FDC B11E3 Non ORG B11E4 Non Arrêt B11E5 Non

Moteur B11E6 Non Mot CC com 1 B11E8 oui J3J3 Aerotech 2 B12E2 RB12E2 oui Chariot Aerotech RB12E2 Non

Alim 13 B13E1 oui Lien pc 13 B13E2 oui

Lien caméra B13E3 Non Câble BNC noir B14E1 RB14E1 oui

Câble BNC jaune RB14E1 oui Lien pc 14 B14E2 oui Câble USB B15E9 oui

Alim16 B16E1 oui Réseau Aero B16E2 B17E1 oui

Alim 17 B17E2 oui Entrée clavier souris écran B16E3 oui

Aero – Périscope – E Non Aero – Périscope – S Non

Aero – Fie – X Non Aero – Fis – X Non Aero – Fie – Y Non Aero – Fis – Y Non Aero – Fie – Z Non Aero – Fis – Z Non

Aero – Me – Thêta Non Aero – Ms – Thêta Non Aero – Me – Phi Non Aero – Ms – Phi Non Schnee – Fie – X Non Schnee – Fis – X Non Schnee – Fie – Y Non Schnee – Fis – Y Non Schnee – Fie – Z Non Schnee – Fis – Z Non

43

Schnee – Me – Thêta Non Schnee – Ms – Thêta Non Schnee – Me – Phi Non Schnee – Ms – Phi Non

Liste des boîtiers

N° Boîtier Nom

B1 Boîtier REM Aerotech

B2 Boîtier REM Schnee

B3 Boîtier REM CC

B4 Boîtier Alim REM Aerotech

B5 Boîtier Alim REM Schnee

B6 Boîtier Rack électronique Aerotech

B7 Boîtier Rack électronique Schnee

B8 Boîtier Ampli de puissance Aerotech

B9 Boîtier à diode

B10 Boîtier alimentation générale

B11 Boîtier Moteur CC

B12 Boîtier Multiplieur MXH250

B13 Boîtier 1394 Repeater

B14 Boîtier National Instrument

B15 Boîtier Edgeport

B16 Boîtier Local Unit

B17 Boîtier Remote Unit

44

Index OHANA: Optical Hawaiian Array for Nanoradian Astronomy VLTI: Very Large Telescope Interferometer LESIA: Laboratoire d'Études Spatiales et d'Instrumentation en Astrophysique LAR: Ligne à Retard TRS: Table à Retard Simulé TRC: Table à Retard Continu CC: Chariot Central TCP/IP: Transmission Control Protocol / Internet Protocol Tip-tilts: Optique Adaptative, correction du front d’onde par l’effet d’actuateurs. Nanoradian: 1 nanoradian = 10-9 rad ≈ 5,7.10-8 degrés Arcsec: Seconde d’Arc 1 arcsec≈4,85.10−6 rad=4,85 µrad

45

Bibliographie Internet: www.obspm.fr, site de l'Observatoire de Paris. www.lesia.obspm.fr, site du LESIA. www.cfht.hawaii.edu/~lai/OHANA.html, site OHANA du CFHT. www.dt.insu.cnrs.fr/OHANA/OHANA.html, site OHANA de la DT/INSU. Documents: OHANA : Spécifications Système d'Alignement Automatique de la Ligne à Retard, LESIA. OHANA : Spécifications Ligne à Retard, LESIA. A Fibered Large Interferometer On Top of Mauna Kea: OHANA, Guy Perrin. Thèse, rapport: Les noyaux actifs de galaxie en interférométrie optique à très longue base. Projet OHANA, Julien Woillez, thèse, 2004. Projet OHANA, intégration des modules d'injection et de la ligne à retard, Samir El Khouloudi, rapport de stage d'IUP, 2004. Ensemble de contrôle – commande des parties mobiles de la ligne à retard de OHANA, Baptiste JAMMET, rapport de stage d’IUT, 2004

46