Une fenêtre sur le ciel |
Ce blog a pour objectif de fournir des informations sur le système de contrôle d'observatoire à distance ROCS (Remote Observatory Control System) que j'ai conçu et de montrer les résultats que j'obtiendrai au fil du temps. Les entrées de ce blog ne décrivent pas linéairement la construction et l'exploitation de l'observatoire, mais présentent des aspects particuliers du projet selon les questions qui me sont posées.
9 juin 2014 Première lumière |
21 juin 2014 Le toit roulant |
6 juillet 2014 Architecture générale |
8 juillet 2014 Le logiciel |
27 juillet 2014 Contrôle de l'observatoire |
31 août 2014 Montage de l'instrument |
28 novembre 2014 Compensation de température |
16 avril 2015 Résolution astrométrique avec un Raspberry Pi |
16 mai 2015 Mode automatique de l'observatoire |
16 septembre 2015 Sécurité pour la fermeture du toit |
24 décembre 2015 Caméra All-Sky Fripon |
6 avril 2016 Nuit cométaire |
9 avril 2016 La nébuleuse Sh2-240 |
11 septembre 2016 Grand champ dans le Cygne en mode auto |
14 septembre 2016 Monitoring météo |
J'utilise un système CloudWatcher pour surveiller les conditions météo lors des sessions de prise de vues automatiques. Le CloudWatcher me permet d'obtenir des informations sur la présence de nuages, sur la luminosité ambiante, sur la présence de pluie et sur la vitesse du vent. Concernant les températures, j'utilise un système HWg-STE PoE avec deux sondes de température, une fixée sur le corps de la lunette pour pouvoir connaître au plus juste la température de cette dernière pour la compensation de température du focuser, et l'autre placée à l'extérieur de l'observatoire mais dans un endroit ombragé. Le capteur de température du CloudWatcher est intégré au boîtier et il est exposé au Soleil (il reporte donc des températures trop élevées avant que le Soleil ne soit complètement couché).
L'interrogation du CloudWatcher, qui est connecté au PC Windows de coupole sur un port série standard, se fait au travers d'un protocole spécifique (composant DCOM). Le serveur Python qui tourne sur le PC interroge le CloudWatcher et le HWg-STE à intervalles réguliers et il analyse donc en permanence les conditions météo durant les programmes d'observation (provoquant un arrêt d'urgence si nécessaire). Il relaie aussi les informations vers les clients ROCS distants pour un affichage des conditions météo (les températures sont envoyées par un Raspberry Pi). A noter qu'un driver INDI pour le CloudWatcher est disponible et on pourrait donc réaliser cette fonction sur une des plateformes Raspberry Pi de l'observatoire (mais la version actuelle du driver INDI ne supporte pas l'anémomètre). | ![]() |
![]() | Mon retour d'expérience avec le HWg-STE PoE est très bon et je le recommande vivement dans le cadre d'une utilisation pour une observatoire distant. L'interrogation du HWg-STE se fait à la fois depuis un Raspberry Pi et depuis le PC au travers du protocole réseau SNMP. Il est alimenté directement en PoE ce qui évite l'ajout d'une alimentation externe supplémentaire (il faut bien sûr disposer dans l'observatoire d'un Switch compatible PoE), le protocole SNMP est extrêmement flexible (il permet d'interroger le device depuis plusieurs plateformes clientes), on peut connecter plusieurs sondes de températures, la précision est très bonne et la fiabilité est au rendez-vous. J'ai expérimenté plusieurs autres solutions de prise de température (comme par exemple connecter des petits capteurs sur un Raspberry Pi ou un Arduino), et aucune ne s'est avérée aussi fiable et précise que le HWg-STE PoE. |
L'affichage en temps réel des conditions météo est réalisée directement dans l'interface ROCS de C2A comme le montre la copie d'écran ci-contre. On voit dans la partie supérieure les informations reportées par le CloudWatcher: la température de ciel pour détecter la présence de nuages, la valeur du capteur de pluie, la valeur du capteur de luminosité et la vitesse du vent. En cas de conditions météo problématiques, la couleur des indicateurs changent (orange pour une certaine plage de valeurs pré-définies et rouge au delà). Cela permet de se rendre compte en un coup d'oeil de la situation météo. La LED verte en dessous du bouton Off est un indicateur de l'état du contact d'alerte du CloudWatcher. Comme je gère moi-même finement les conditions météo, je n'utilise pas directement l'état de ce contact dont l'activation dépend directement des seuils définis dans le logiciel qui permet de paramétrer le CLoudWatcher. Si tous les indicateur météo sont bon, le rectangle en dessous du bouton On est vert avec un indication Safe. Les températures extérieure et intérieure (sur fond bleu) proviennent du HWg-STE et sont affichées avec une résolution de 0,1°C. Les deux courbes montrent l'évolution des températures extérieure (rouge) et intérieure (bleu) au cours des dernières heures. La valeur de l'humidité ambiante provient quant à elle d'un petit capteur DHT11 connecté sur l'Arduino de l'armoire de contrôle (l'interrogation se fait depuis le PC de coupole sur lequel l'Arduino est connecté par un port série). L'évolution de l'humidité au cours des dernières heures est montrée par la courbe en pointillés verts. On remarque d'ailleurs qu'en cette fin de nuit du mois d'avril, l'humidité était de 91%, un record en ce qui me concerne ! (l'humidité reste généralement en dessous de 50%). Enfin, la petite zone "Prévisions" fournit en coup d'oeil les prévisions météo pour les jours à venir (la couleur de chaque case témoigne de la couverture nuageuse prévue et le nombre de la probabilité d'avoir de la pluie). | ![]() |
Ces informations de prévision sont automatiquement obtenues par un Raspberry Pi de l'observatoire en utilisant une API JSON du système de prévisions météo Weather Underground pour un lieu proche de l'observatoire. Une prochaine entrée du blog portera sur le code Python utilisé pour adresser l'API JSON.
Plutôt que de développer ma propre interface d'affichage pour l'historique des conditions météo, j'utilise l'excellent logiciel gratuit Kst. Kst est un puissant outil d'affichage temps réel de jeux de données. Dans le cas présent, il est utilisé pour afficher 6 indicateurs météo (température extérieure, température du ciel, valeur du capteur de pluie, vitesse du vent, valeur du capteur de luminosité et indicateur d'alerte météo). Ces données sont extraites du fichier texte enrichi au fil du temps par C2A. Voici quelques lignes d'un fichier récent:
Date;Clouds;Sky Temperature;Rain State;Rain;Brightness State;Brightness;Wind State;Wind;Temperature;Safety;HumidityComme on le voit, les valeurs sont simplement séparées par des point-virgules et chaque ligne est une mesure des conditions météo réalisée ici toutes les 10 secondes. Kst surveille ce fichier et chaque fois qu'une nouvelle ligne est ajoutée, il met à jour dynamiquement les 6 courbes (avec une efficacité surprenante, même quand il y a une grand nombre de valeurs présentes). La paramétrisation de la vue est réalisée une fois pour toutes dans le logiciel Kst et elle est sauvegardée dans un fichier avec une extension .kst. Un nombre considérable d'options est disponible dans ce logiciel pour particulariser l'affichage et le système offre une très grande flexibilité.
Si vous agrandissez la copie d'écran ci-dessus, vous pouvez voir l'enregistrement des conditions météo dans la nuit du 12 au 13 septembre 2016 (la date est visible en dessous de chaque courbe). L'enregistrement a commencé vers 23h le 12 septembre pour se terminer peu après 6h le lendemain. La température a été décroissante à peu près toute la nuit (ce qui justifie pleinement ma décision de refaire une focalisation toutes les 30 minutes), et a commencé à croître à partir de 4h 30, probablement du fait d'une inversion des vents. Avec la courbe de température du ciel, on voit aussi que quelques passages de nuages se sont produits, ce que j'ai pu vérifier sur mon log d'observation automatique avec une impossibilité de focaliser à 0h 52. La prise d'image suivante a été fortement perturbée du fait de la perte de l'étoile d'autoguidage, comme on peut le voir sur cet extrait de la pose brute réalisée à ce moment là (pose brute commencée à 0h 54) :
Il y a eu très peu de vent cette nuit là, avec seulement quelques rafales jusqu'à 10 km/h en fin de nuit. En conclusion, je recommande vivement le logiciel Kst qui peut bien sûr être utilisé pour un grand nombre d'applications, en particulier lors de la production de données en temps réel.
L'intérêt d'un mode automatique dans un observatoire distant est que l'on peut profiter pleinement des nuits claires et réaliser des prises systématiques de champs contigus avec une très bonne précision sur le positionnement du télescope. On peut ensuite assembler ces prises de vue individuelles pour former une mosaïque très large, ce qui donne des résultats spectaculaires, particulièrement avec un filtre H-Alpha dans les régions de nébuleuses en émission de la Voie Lactée.
J'ai réalisé au cours des dernières semaines un grand nombre de poses autour de Gamma Cygni avec un filtre H-Alpha de 3nm Astrodon et je les ai assemblées pour former une mosaïque de 12 champs. Au total 74 poses individuelles de 30 minutes ont été réalisées sur les 12 champs de la mosaïque. Le tableau suivant récapitule les dates et conditions de réalisation de ces poses:
Date | 13 août | 14 août | 22 août | 23 août | 24 août | 25 août | 26 août | 7 septembre |
Nombre de poses | 10 | 10 | 11 | 9 | 12 | 9 | 11 | 2 |
Phase de la Lune | 75% | 83% | 80% | 70% | 59% | 47% | 31% | 75% |
HFD moyen (pixels) | 2,12 | 2,12 | 2,16 | 2,08 | 2,18 | 2,11 | 2,20 | 2,14 |
L'essentiel des poses a été réalisé sur 7 nuits, profitant d'une période de beau temps entre le 22 et le 26 août. Le cumul des temps de pose représente 37 heures, et on remarquera que l'on n'a pas cherché à éviter les nuits avec une présence de la Lune importante. L'expérience montre en effet que le filtre H-Alpha de 3nm permet de s'affranchir en grande partie de la diffusion de la lumière lunaire, ce qui est bien sûr très appréciable pour augmenter le nombre de poses sur une période donnée. Il faut aussi s'assurer que la zone exposée n'est pas trop proche de Lune au moment des prises de vue. A noter que l'on ne pourrait pas faire la même chose avec un filtre OIII ou SII, la diffusion de la lumière lunaire étant beaucoup plus gênante dans ces plages de longueurs d'onde.
Voici une vue réduite à 800 pixels de large de l'image finale. Si vous cliquez sur l'image, une vue en plus haute définition sera affichée dans laquelle vous pourrez naviguer (cette page a été produite avec l'outil GMapImageCutter créé par le CASA).
L'image finale a une taille de 8919 x 8553 pixels et elle montre un champ de 5° x 5° environ. On pourrait donc y mettre 100 pleines Lunes les unes à côté des autres!
La copie d'écran ci-dessous montre les 12 champs constitutifs de la mosaïque dans une carte C2A. Ce sont les coordonnées des centres de ces champs (marqués F#01 à F#12 dans la copie d'écran) qui permettent de pointer le télescope de manière précise dans les sessions d'observations automatiques. On remarquera le chevauchement des champs qui est nécessaire pour positionner correctement les images lors de la constitution de la mosaïque.
Toutes les sessions d'observation pour réaliser les 74 images ont été réalisées entièrement automatiquement. Une bonne manière de comprendre l'enchaînement des opérations durant une session d'observation automatique est d'analyser un log produit par le système ROCS. Analysons par exemple le log de la session réalisée durant la nuit du 25 août 2016 durant laquelle 9 images du grand champ du Cygne ont été réalisées.
Log | Description |
19:21:05 Starting fan 1 | On lance manuellement les ventilateurs muraux en début de soirée pour commencer à refroidir l'observatoire. Il s'avère à l'usage que ces ventilateurs, trop petits, sont peu efficaces et rien ne remplace un gros ventilateur posé sur le sol qui expulsera l'air chaud de l'observatoire vers l'extérieur une fois la toiture ouverte (voir plus loin). |
20:47:12 Starting PC 20:47:13 PC start request sent 20:50:58 Mount power ON 20:51:03 Initializing mount... 20:51:10 Longitude telescope OK 20:51:11 Latitude telescope OK 20:51:11 Telescope UTC time: 2016-08-25 18:51:12+00:00 20:51:21 Mount initialization complete 20:51:24 Camera power ON 20:51:37 Cloud Sensor power ON 20:51:41 RoboFocus power ON 20:51:48 Stopping fan 1 20:51:48 Starting CloudWatcher | On démarre l'observatoire après avoir vérifié les conditions météo: alimentation des systèmes (monture, caméra, station météo, système de focalisation) et on arrête les ventilateur muraux. En final, on lance le monitoring météo (constitué par un CloudWatcher). |
20:52:31 Parsing observation program... 20:52:31 Observation Program test succesful | On réalise un test du programme d'observation (appelé PO dans le reste de cet article) de la nuit. Ce programme est mis au point directement dans C2A (on y voit en particulier les traces des observations sur la voûte céleste), et un certain nombre de points sont vérifiés automatiquement sur le serveur situé dans l'observatoire (cohérence des différentes étapes, réglages et contraintes horaires imposées). On voit dans le log qu'aucune erreur n'est reportée, so we're good to go!. |
20:53:28 Parsing observation program... 20:53:29 Waiting for opening the roof at 21:15:00 | Le test ayant été concluant, on lance le programme d'observation. A partir de cet instant, tout est entièrement automatique et on n'a plus à intervenir en quoi que ce soit durant la nuit jusqu'à l'arrêt complet de l'observatoire. On voit dans le log que la première étape sera d'ouvrir le toit à 21:15. En cas d'arrivée de nuages ou de vent excessif, le PO sera automatiquement arrêté et le toit fermé (le monitoring météo est obligatoire lors d'une utilisation de l'observatoire en mode automatique). Il m'est arrivé plusieurs fois d'avoir des PO arrêtés durant la nuit, même si j'essaie d'éviter d'observer les nuits où il y a des risques de mauvais temps. En cas d'arrêt, je ne redémarre pas pour l'instant le PO interrompu. L'enchaînement des séquences du PO est optimisé et on prend en compte spécifiquement le passage du méridien qui est toujours une préoccupation pour des observations automatiques. |
21:15:02 Opening the roof... 21:15:40 Roof is now open 21:15:40 Starting fan 2 21:15:41 Waiting for OP start at 21:55:00 | Le toit est ouvert automatiquement à l'heure demandée après que le PO a vérifié soigneusement la météo et la position du télescope (il faut impérativement que ce dernier soit en position parking au moment de l'ouverture du toit et deux systèmes indépendants sont utilisés pour s'en assurer). Un gros ventilateur posé sur le sol de l'observatoire est démarré pour accélérer le refroidissement de l'observatoire dans les 40 minutes qui restent avant le démarrage des observations. |
21:55:07 Connection to telescope OK 21:55:09 Connection to camera OK 21:55:14 Connection to focuser OK 21:55:14 Cooling camera down to -20°C 21:55:14 Camera cooling plateau at 24.0°C 21:56:24 Camera cooling plateau at 20.0°C 21:56:55 Camera cooling plateau at 16.0°C 21:57:25 Camera cooling plateau at 12.0°C 21:57:56 Camera cooling plateau at 8.0°C 21:58:46 Camera cooling plateau at 4.0°C 21:59:16 Camera cooling plateau at 1.0°C 21:59:47 Camera cooling plateau at -3.0°C 22:00:17 Camera cooling plateau at -6.0°C 22:00:48 Camera cooling plateau at -10.0°C 22:01:18 Camera cooling plateau at -13.0°C 22:01:49 Camera cooling plateau at -17.0°C 22:02:29 Camera cooling plateau at -20°C 22:03:20 Camera cooling complete (-20°C) 22:03:20 Unparking telescope 22:04:16 Telescope unparking complete 22:04:16 Waiting for sequence 1 start at 22:10:00 | Un peu avant 22:00, le PO démarre réellement et on refroidit la caméra. Ce refroidissement se fait par paliers de manière à ménager le système Pelletier de la caméra. On démarre avec un premier palier à 24°C car il fait encore 25°C dans l'observatoire à 22:00! (après tout, on est en Espagne...). On amène la caméra à -20°C, environ 45°C en dessous de le température ambiante. En été, j'essaie d'utilise systématiquement une température cible de -20°C de manière à limiter les prises de darks. Une fois le refroidissement réalisé (il faut une petite dizaine de minutes), le télescope est sorti de sa position parking et la barre de contrepoids est amenée dans une position verticale avec la lunette qui pointe au Nord. On attend ensuite le démarrage de la première séquence du PO prévue pour 22:10. |
22:10:00 Starting sequence 1 of 9 22:10:00 Telescope position checking OK in step 1 22:10:00 Slewing in step 1 to ra=20.26h / de=40.325° 22:10:44 Telescope slewing complete 22:10:44 Stopping fan 2 22:10:44 Opening cap... 22:10:55 Telescope cap is open | La première séquence du PO démarre. Le système vérifie que la position du télescope est correcte et il lance le déplacement vers la première cible (il s'agit du champ numéro 8 LFCy montré dans la copie d'écran au dessus). Le ventilateur au sol est arrêté et le cache de la lunette est ouvert. |
22:10:56 Focuser initialized at pos 3931 (temp 24.1°C) 22:11:02 Focuser correctly initialized 22:11:02 Starting sky calibration... 22:11:05 Launching calibration exposure... 22:11:36 Saving calibration image... 22:11:36 PinPoint image solving... 22:11:40 Image solving has succeeded 22:11:40 Center: RA=20h16m32s DE=+40°11'52" 22:11:40 Angular distance to correct: +0.22° 22:11:40 Mount calibration... 22:11:41 Telescope re-positioning... 22:11:44 Telescope position checking OK in step 1 | Cette étape est importante car elle va conditionner la faisabilité de la focalisation automatique. On initialise le focuser à une valeur qui est calculée en fonction de la température ambiante. Le capteur de température est au contact du tube de la lunette (serré par un collier) pour plus de précision. La relation qui lie la position de focalisation à la température a été déterminée empiriquement et elle est modifiable dans les options du client ROCS (C2A). La relation utilisée actuellement pour le focuser Robofocus est: pos = 6,919 x t + 3765,2. Il est impératif de démarrer avec une position à peu près correcte de la focalisation car si ce n'est pas le cas, la calibration sur le ciel ou la première focalisation peuvent totalement échouer. Comme on a une position de focalisation à peu près correcte, on réalise tout de suite la calibration de la position du télescope sur le ciel. On prend une pose de 15 secondes en luminance et on réalise une résolution par PinPoint. La plupart du temps, cette procédure réussit, mais il se peut qu'elle échoue si l'écart entre la position réelle et la position estimée est supérieure à 0,4 ou 0,5°. Dans un tel cas, le PO utilisera automatiquement une résolution astrométrique en utilisant Astrometry.net qui tourne sur un Raspberry Pi dans l'observatoire (cette résolution réussit systématiquement). L'intérêt d'utiliser PinPoint est que la résolution astrométrique est plus rapide qu'avec Astrometry.net. Dans notre cas, on constate un écart de 0,22° que l'on corrige immédiatement en recalibrant la monture. |
22:11:44 Slewing in step 1 to ra=20.691h / de=45.28° 22:11:54 Telescope slewing complete 22:11:54 Focus with exposure 2.0s, filter 4 in step 1 22:11:56 Finding star for focus in step 1 22:11:56 Waiting to find star... 22:12:24 Star found for focus in step 1 22:12:24 Performing focus in step 1 22:14:54 FocusMax reported success in step 1 22:14:56 Focus: P=3957 T=23.8°C Filter=4 HFD=2.33 22:14:56 Focus: T=617.0u time=181s seq=1 22:14:56 Focus process done in step 1 | Le télescope est maintenant déplacé vers l'étoile de focalisation. La position de focalisation est spécifiée bien sûr dans le PO et des outils sont disponibles dans C2A pour la déterminer (avec un filtre H-Alpha, il faut une étoile de magnitude 1.5 environ et des poses de 2 secondes avec le logiciel FocusMax installé sur le PC de coupole). Si les conditions météo sont normales, la focalisation réussit systématiquement et le PO reporte le résultat obtenu: la position du focuser, la température en °C, le filtre utilisé et la valeur de HFD (Half Flux Diameter) reportée par FocusMax. Cette dernière valeur me permet par ailleurs d'évaluer immédiatement la qualité du seeing. La température en unités Robofocus et le temps de focalisation (environ 3 minutes) sont aussi fournis. Toutes ces informations sont enregistrées dans une base de données SQLite pour pouvoir être exploitées ultérieurement. |
22:14:56 Telescope position checking OK in step 1 22:14:56 Slewing in step 1 to ra=20.26h / de=40.325° 22:15:03 Telescope slewing complete 22:15:06 Launching autoguiding (calibration, exp 1000ms) 22:16:57 Light frame: 1800.0s, binning 1, filter 4 (1/1, step 1) 22:47:13 Image 2016-08-25_LFCy08-H001.fit saved in local folder (step 1) | On revient vers notre cible (le champ numéro 8 de la mosaïque) et on lance l'autoguidage. Comme il s'agit de la première session d'autoguidage à cette déclinaison, on demande une calibration. L'autoguidage est assuré par l'excellent PHD2 (Open PHD Guiding). Cette procédure prend un peu moins de 2 minutes et on peut lancer la première pose de 1800 secondes (30 minutes) en binning 1 et un filtre H-Alpha (position 4 sur la roue à filtre). A la fin de l'exposition, l'image est sauvegardée localement sur le PC dans un fichier appelé 2016-08-25_LFCy08-H001.fit. Ce nom intégère plusieurs informations importantes: la date de la session (il s'agit de la date de la veille si on observe après minuit), le nom ou la référence de l'objet observé (ici LFCy pour Large Field Cygnus), le filtre utilisé (H pour H-Alpha) et un numéro de pose sur 3 caractères. |
22:47:13 Stopping autoguiding... 22:47:14 Starting sequence 2 of 9 | On arrête l'autoguidage et on passe à la deuxième séquence. La première séquence ne comportait qu'une seule pose, ce qui est plutôt inhabituel. On réalise généralement plusieurs poses sur le même objet, éventuellement avec des filtres différents. Dans notre cas, on se déplace vers le champ suivant de notre mosaïque et on va donc initier une deuxième séquence. |
04:32:56 Telescope position checking OK in step 8 04:32:57 Slewing in step 8 to ra=20.691h / de=45.28° 04:33:06 Telescope slewing complete 04:33:06 Focus with exposure 2.0s, filter 5 in step 8 04:33:06 Finding star for focus in step 8 04:33:06 Waiting to find star... 04:33:34 Star found for focus in step 8 04:33:34 Performing focus in step 8 04:36:02 FocusMax reported success in step 8 04:36:04 Focus: P=3882 T=15.5°C Filter=5 HFD=1.92 04:36:04 Focus: T=602.0u time=178s seq=8 04:36:04 Focus process done in step 8 04:36:04 Telescope position checking OK in step 8 04:36:05 Slewing in step 8 to ra=20.17h / de=36.735° 04:36:14 Telescope slewing complete 04:36:17 Launching autoguiding (no calibration, exp 1000ms) 04:36:33 Light frame: 1800.0s, binning 1, filter 5 (2/2, step 8) 05:06:49 Image 2016-08-25_PNS_18-O003.fit saved in local folder (step 8) | Les séquences s'enchaînent tout au long de la nuit, et vers 4:30 on entame notre dernière pose. Le 25 août dernier, les heures de crépuscule astronomique étaient 22:22 et 5:34 en heure locale et on aurait pu faire une pose de plus. D'une façon générale, on réalise une focalisation avant chaque pose de 30 minutes, du moins en été lorsqu'il y a des variations de température significatives même en milieu ou en fin de nuit. En hiver, on ne réalise des focalisation que toutes les heures en milieu de nuit. La lunette Takahashi FSQ-106ED est très sensible aux variations de température et le moindre changement peut compromettre la focalisation. Pour cette dernière pose de la nuit, on s'intéresse à un champ en bordure de Voie Lactée avec une pose de 30 minutes et un filtre OIII (la Lune est couchée à ce moment là). A noter l'amélioration du seeing en fin de nuit. On obtient un HFD de 1,92 pixels alors que l'on avait commencé avec un HFD de 2,33 la veille. C'est tout à fait caractéristique du site où se trouve l'observatoire au Nord de l'Espagne. |
05:06:49 Stopping autoguiding... 05:06:51 Closing cap... 05:07:02 Telescope cap is closed 05:07:02 Parking telescope 05:07:50 Closing the roof... 05:08:30 Roof is now closed | La partie d'expositions sur le ciel du PO est maintenant terminée. On ferme le volet de la lunette et on ferme le toit, tout cela automatiquement bien sûr. |
05:08:30 Starting sequence 9 of 9 05:08:30 Dark frame: 1800.0s, binning 1 (1/7, step 9) 05:38:49 Image 2016-08-25_dark_1800_0-001.fit saved in local folder (step 9) 05:38:49 Dark frame: 1800.0s, binning 1 (2/7, step 9) 06:09:05 Image 2016-08-25_dark_1800_0-002.fit saved in local folder (step 9) 06:09:05 Dark frame: 1800.0s, binning 1 (3/7, step 9) 06:39:21 Image 2016-08-25_dark_1800_0-003.fit saved in local folder (step 9) 06:39:21 Dark frame: 1800.0s, binning 1 (4/7, step 9) 07:09:37 Image 2016-08-25_dark_1800_0-004.fit saved in local folder (step 9) 07:09:37 Dark frame: 1800.0s, binning 1 (5/7, step 9) 07:39:53 Image 2016-08-25_dark_1800_0-005.fit saved in local folder (step 9) 07:39:53 Dark frame: 1800.0s, binning 1 (6/7, step 9) 08:10:09 Image 2016-08-25_dark_1800_0-006.fit saved in local folder (step 9) 08:10:09 Dark frame: 1800.0s, binning 1 (7/7, step 9) 08:40:25 Image 2016-08-25_dark_1800_0-007.fit saved in local folder (step 9) | Cela ne veut pas dire pour autant que le PO est terminé. Dans le PO réalisé cette nuit là, on réalise des prises de darks (7 darks de 30 minutes chacun) jusque vers 8:40 du matin, bien après le lever du Soleil. D'une façon générale, je réalise toujours les poses de calibration en fin de nuit après avoir fermé le toit. |
08:40:26 Warming up camera up to 13°C 08:40:26 Camera warmup plateau at -17.0°C 08:40:56 Camera warmup plateau at -13.0°C 08:41:22 Camera warmup plateau at -10.0°C 08:41:42 Camera warmup plateau at -7.0°C 08:42:02 Camera warmup plateau at -4.0°C 08:42:23 Camera warmup plateau at -1.0°C 08:42:43 Camera warmup plateau at 2.0°C 08:43:03 Camera warmup plateau at 5.0°C 08:43:24 Camera warmup plateau at 8.0°C 08:43:44 Camera warmup plateau at 11.0°C 08:44:04 Camera warmup plateau at 13°C 08:44:24 Camera warmup complete (13°C) 08:44:26 Powering off instruments 08:44:26 Powering off Mount... 08:44:27 Waiting 3 minutes before powering off camera... 08:47:27 Powering off Camera... 08:47:28 Powering off Robofocus... 08:47:29 Stopping Cloud Watcher polling... 08:47:29 Powering off Cloud Watcher... 08:47:31 Initiating image transfer 08:47:32 19 file(s) copied to shared folder 08:47:32 Observation program completed | Une fois les poses de calibration terminées, on réchauffe la caméra par paliers, on coupe les alimentations des différents instruments et on initie le transfert des images réalisées pendant la nuit vers un dossier partagé sur Internet. Cela permettra de les récupérer plus tard dans la matinée. A 8:47, le programme d'observation automatique est officiellement terminé. |
Le log complet du programme d'observation est disponible si vous souhaitez voir plus de détails.
![]() | Au cours des derniers mois, je me suis focalisé sur la nébuleuse Sh2-240. Il s'agit d'un rémanent de supernova que l'on trouve à la limite des constellations du Cocher et du Taureau tout près de l'étoile Beta Tauri. Cette nébuleuse est située à une distance approximative de 3 000 (±350) années lumière, et elle est associée au pulsar PSR J0538+2817. L'âge de la supernova n'est pas déterminé très précisément et on l'estime à environ 40 000 ans). Malgré sa taille imposante (3,3° x 3,2° environ), ce rémanent est faiblement lumineux et demande des temps de pose importants. J'ai réalisé une mosaïque en 4 parties selon le schéma ci-contre (réalisé avec C2A) et j'ai totalisé environ 50 heures de pose sur les 4 champs adjacents en utilisant un filtre H-Alpha 3nm de marque Astrodon. Toutes les poses individuelles ont été réalisée à distance et en mode automatique (poses de 30 minutes en autoguidage avec focalisation avant chaque pose). Je n'ai retenu au final que 55 poses de 30 minutes, soit un total de 27,5 heures (suite à une sélection drastique sur la FWHM et le rapport signal sur bruit des images). |
Le détail du nombre de chose par champ est le suivant: Sh2_240_1 = 13, Sh2_240_2 = 15, Sh2_240_3 = 13, Sh2_240_4 = 14. Tout le traitement, y compris l'assemblage de la mosaïque, a été réalisé avec le logiciel PixInsight. L'image finale en pleine résolution fait 6330 x 4630 pixels.
Cliquez dans l'image ci-dessous pour obtenir des vues plus détaillées des zones indiquées (le Nord est à gauche de l'image). Si vous cliquez sur le fond de l'image, vous obtiendrez une image en négatif de la nébuleuse. Il est à noter que la zone carrée en haut et à gauche contient une petite nébulosité qui a priori semble indépendante du rémanent. Je n'ai pas réussi à déterminer la nature de cet objet (zone détachée de la nébuleuse ou bien objet en avant ou arrière plan?) et je suis intéressé par d'éventuelles observations qui pourraient être faites sur cette zone avec une focale plus longue.
Profitant d'une nuit claire le 6 avril, un petit marathon cométaire a été réalisé en mode automatique. Six comètes ont été sélectionnées dans C2A en fonction de leur magnitude et de leur position dans le ciel. Chaque image est le résultat de 9 poses de 5 minutes chacune (le stacking est bien sûr réalisé sur le noyau cométaire). On n'a pas chercher à diminuer le bruit mais simplement à faire ressortir de manière à peu près correcte la coma et l'eventuelle queue des comètes. Voici le résultat obtenu (cliquez sur les vignettes pour les agrandir).
Venons en au sujet de cette entrée du blog: l'occasion m'a été donnée d'installer à l'observatoire une caméra All-Sky Fripon (voir http://ceres.geol.u-psud.fr/fripon/). Il s'agit avant tout d'une caméra utilisée dans le cadre d'un réseau de détecteurs pour reconstruire les trajectoires de météorides au dessus de la France, mais je souhaitais voir si cette caméra convenait aussi à une utilisation classique en caméra All-Sky. Le gros avantage de cette caméra est qu'elle est pilotable directement au travers d'un port Ethernet. De plus, elle est alimentée en PoE (Power over Ethernet) ce qui évite d'avoir une alimentation extérieure à amener jusqu'à la caméra.
![]() | Comme il se doit, ma première idée a été d'utiliser cette caméra directement depuis un Raspberry Pi, ce qui fournirait une solution très simple pour la prise d'images All-Sky de jour comme de nuit sans avoir à utiliser un PC Windows ou une machine Linux plus conséquente. Le schéma ci-contre montre l'architecture du système permettant la prise d'images All-Sky. La caméra Fripon et la plateforme de service Raspberry Pi (ROCS_SER, la même plateforme que celle utilisée pour la résolution astrométrique) sont toutes les deux connectées à un Switch Gigabit Ethernet ayant une capacité PoE. Différentes interfaces clientes peuvent interroger la plateforme de service ROCS_SER (le serveur) au travers d'un protocole basé sur des sockets TCP/IP. |
J'ai aussi développé un service Web qui tourne sur un des deux Raspberry Pi de contrôle de l'observatoire. Ce service permet de connaître l'état de l'observatoire à tout instant (alimentation des systèmes, état des lumières et des ventilateurs, etc.), d'obtenir les données météo, de visualiser l'intérieur et l'extérieur de l'observatoire en reportant des images caméra, d'obtenir une vue de la caméra All-Sky Fripon dont on a spécifié la durée d'exposition et enfin d'émettre des commandes de base telles que l'allumage et l'extinction des lumières. Les copies d'écran montrent l'interface obtenue sur un smartphone Android.
![]() | ![]() | ![]() |
Voici quelques exemples de poses réalisées avec la caméra Fripon sur le site de l'observatoire.
La caméra Fripon peut bien sûr continuer à être utilisée pour son objectif premier, la détection de météores. Voici par exemple deux images de météores obtenues durant la nuit du 21 au 22 novembre 2015. Ces météores sont détectés en prenant des images de manière continue durant toute une nuit (poses de quelques secondes jusqu'à 30 secondes) puis en réalisant un film time-lapse qui permet de repérer rapidement l'apparition de météores. | ![]() | ![]() |
Cette technique ne peut pas remplacer bien sûr le système de détection Fripon qui lui est conçu pour réaliser des poses très courtes afin d'obtenir un positionnement temporel précis.
En conclusion, la caméra Fripon est bien adaptée à une utilisation en tant que caméra All-Sky pour la surveillance des conditions météo. Elle possède une sensibilité suffisante pour cette application et elle offre un mode de fonctionnement très simple et très ouvert.
![]() | Je participe en ce moment à une collaboration internationale sur la nébuleuse planétaire Ou4 découverte par Nicolas Outters en 2011. Le but est de rassembler plusieurs centaines d'heures de pose sur l'objet afin de sortir la meilleure image possible (cette nébuleuse est très faible), spécialement en OIII puisque c'est la bande où les nébuleuse est essentiellement visible. J'ai contribué de mon côté avec 27 poses de 30 minutes en OIII réalisées durant l'été 2015 en remote (les vues fournies doivent être calibrées). Voici un premier traitement réalisé juste avec mes images, donc 13,5 heures de pose avec un filtre à bande étroite (3 nm) OIII. L'image est encore assez bruitée, et je pense améliorer les choses dans l'avenir avec un plus grand nombre de poses et une meilleure sélection de ces dernières. Cette image peut être comparée à l'image obtenue par le télescope de 2,5m Isaac Newton (voir l'images sur APOD: |
Venons en au sujet de ce post, la sécurité pour la fermeture de la toiture de l'observatoire. En effet, comme cela a été mentionné dans un post précédent, l'instrument est surélevé pour se dégager au maximum de l'obstruction des murs de l'observatoire. La conséquence est qu'il est impératif que la monture soit en position parking au moment de la fermeture ou de l'ouverture du toit de l'observatoire sans quoi l'instrument serait arraché ou tout du moins gravement endommagé... Dans un premier temps, un système de contacts magnétiques sur la monture a été mis en place: une information de contact est reportée au contrôleur Raspberry Pi sur chacun des deux axes, et les commandes de mouvement du toit sont interdites par le logiciel dès que l'un des deux contacts n'est pas actif. | ![]() |
Ce système de sécurité est suffisant pour une utilisation à distance interactive de l'observatoire. Au moment de fermer ou d'ouvrir le toit, je vérifie toujours visuellement au moyen d'une des caméras de l'observatoire que la monture est bien en position parking. Toutefois, dans le cadre du mode d'utilisation automatique de l'observatoire, il m'a semblé que cette simple sécurité n'était pas suffisante et j'ai souhaité doubler la vérification de la bonne position de la monture au moyen d'un système indépendant et différent du système de contacts magnétiques.
Le relais de la cellule photoélectrique est connecté à l'Arduino géré par le PC d'acquisition de l'observatoire. On est donc totalement indépendant des deux Raspberry Pi de contrôle, et il faut de toute façon que le PC soit en marche pour l'excécution des programmes automatiques d'observation durant lesquel l'ouverture ou la fermeture automatique du toit de l'observatoire est réalisée. Le logiciel Python qui exécute les programmes d'observation vérifie soigneusement que les conditions nécessaires à l'ouverture ou à la fermeture de la toiture sont bien remplies :
Si ces deux conditions sont réunies, les mouvements de la toiture peuvent être réalisés en toute sécurité, par exemple lors de la fermeture automatique en fin de programme d'observation.
Faire de l'astrophotographie avec une lunette de 106mm pose un problème de taille: il faut cumuler un temps d'exposition beaucoup plus long qu'avec un télescope de gros diamètre... De plus, la lunette Takahashi FSQ-106ED est très sensible aux variations de température, et il est impératif de refaire régulièrement la focalisation. Ces contraintes rendent la vie très difficile pour peu que les nuits de beau temps sans Lune arrivent à un moment où les activités professionnelle demandent impérativement un volume de sommeil décent. C'est pour cette raison que j'ai développé un mode automatique du fonctionnement de mon observatoire distant. Le but est de définir un programme d'observation pour toute une nuit, de l'envoyer à l'observatoire et de laisser ce dernier ce débrouiller. Le maintien d'une connexion avec l'observatoire n'est pas nécessaire, sauf éventuellement pour recevoir des alarmes si un problème se produit ou bien si la météo se dégrade.
Les contraintes que je me suis fixé pour le mode automatique sont les suivantes:
Je n'ai retenu aucune pose en Luminance car la qualité n'était pas suffisante (je pense qu'il n'y a pas eu une seule nuit avec un bon seeing pendant toute cette période...). J'ai donc fait du RGB et pas du LRGB.
Pour mémoire, Messier 81 est situé à environ 11,8 millions d'années-lumière et l'interaction avec d'autres galaxies du groupe, en particulier Messier 82, conduit à la formation de filaments de gaz arrachés aux galaxies. Si je pousse les seuils, je peux faire apparaître ces filaments (mais ça augmente aussi fortement le bruit de l'image). Ces interactions ont perturbé en particulier M82 (qui est moins massive) et ont précipité du gaz dans la galaxie, conduisant à une flambée de formation d'étoiles, d'où ces filaments très rouge que l'on voit s'échapper de M82. On voit aussi que cette dernière est complètement "gauchie" par les effets de marée et l'image fait apparaître les nuages de poussière déformés dans les bras de la galaxie.
J'ai réalisé le traitement des images sous PixInsight. Pour les personnes que cela intéresse, voici les traitements que j'ai effectués (les noms des process et des scripts sont en italique):
Lorsque l'on met en oeuvre un observatoire contrôlé à distance, une question importante à résoudre concerne la calibration sur le ciel. En effet, si l'information concernant l'orientation de la monture est perdue pour une raison ou pour une autre, il devient indispensable de disposer d'une procédure pour recalibrer la monture (pas question en effet d'orienter manuellement la monture avec l'oeil derrière un chercheur...). La méthode la plus simple consiste a réaliser une exposition sur le ciel puis à réaliser une "résolution astrométrique" de l'image obtenue, c'est à dire de déterminer les coordonnées du centre du champ de manière à les fournir au contrôleur de la monture. Cette résolution nécessite un logiciel sophistiqué, surtout si l'on ne dispose pas des coordonnées approximatives du centre du champ. Le logiciel PinPoint, utilisé conjointement avec Maxim DL, permet de réaliser très rapidement un résolution astrométrique (moins de quelques secondes). Toutefois, il faut que le centre approximatif du champ soit fourni avec une précision de l'ordre de quelques dizaines de minutes d'arc au maximum sans quoi la résolution échoue. C'est ce système que j'utilise de manière automatique pour recalibrer précisément la monture après un déplacement important sur le ciel.
Dernièrement, suite à une série de tests logiciels sur le code Python du PC de l'observatoire, il se trouve que la monture s'est retrouvée hors calibration. Une orientation approximative de la monture ne permettant pas de réussir une résolution astrométrique avec PinPoint, j'ai alors réalisé une pose dans une position quelconque et je me suis connecté sur le site astrometry.net pour demander une résolution astrométrique sans fournir de position approximative du centre du champ. C'est ce que je fais habituellement dans ce genre de situations. Le logciciel mis en oeuvre par Astrometry.net est très performant et permet une résolution astrométrique à coup sûr sur les images produites par ma configuration. Manque de chance ce soir là, le serveur astrometry.net ne fonctionnait pas avec un message sibyllin m'indiquant que le disque était plein... Après une heure d'effort, j'ai pu identifier manuellement le champ pointé par l'instrument en m'aidant des cartes de C2A. Mais l'heure de l'occultation que je souhaitais réaliser ce soir là était malheureusement passée.
Le code du logiciel astrometry.net étant public, j'ai décidé d'essayer de le compiler sur ma plate-forme favorite, un Raspberry Pi sous Linux, et de voir si je pouvais réaliser des résolutions astrométriques dans un temps raisonnable. L'objectif est d'installer ce Raspberry Pi dans l'observatoire avec la tâche spécifique de réaliser les résolutions astrométrique facilement sans dépendre d'un accès Internet (le transfert d'une image de plus de 15 MegaOctets sur une liaison à moins de 1 Mb/s est assez long...) ou de la disponibilité de la plateforme astrometry.net. Deux heures plus tard, le système était opérationnel! Cette entrée du blog ROCS a pour objectif de décrire pas à pas l'installation réalisée.
Le système d'exploitation installé sur le Raspberry Pi est la distribution standard Raspbian (Debian Wheezy) 3.18 du 16 février 2015 disponible en téléchargement sur raspberry.org. Toute l'installation de base de ce système est disponible sur de nombreux "tutorials" sur Internet, mais en voici le détail dans le cadre de ce projet de plateforme de résolution astrométrique:
A partir de ce moment, vous pouvez débrancher l'écran du Raspberry Pi et utiliser le logiciel putty pour accéder à la machine en utilisant l'adresse statique 192.168.x.y que vous avez configurée dans votre Raspberry Pi.
Poursuivez l'installation avec les commandes suivantes:
La résolution d'une image se fait ensuite simplement en utilisant une commande de la forme suivante:
solve-field -p --overwrite --timestamp --scale-units arcsecperpix --scale-low 2.05 --scale-high 2.15 mon_image.fit
Dans cette commande, j'ai spécifié l'échantillonnage de mon image (en secondes d'arc par pixel) de manière à accélérer la résolution. Il est à noter que le code source du logiciel astrometry.net est fourni avec plusieurs exemples qui permettent de vérifier que la résolution fonctionne bien.
La résolution astrométrique a pris 4 minutes ce qui représente un pire cas sur les images que j'ai pu tester. La résolution prend en général entre 2 et 3 minutes, voire 30 secondes environ si on est en dehors de la Voie Lactée. Le Raspberry Pi peut être "overclocké" pour accélérer la résolution (en affichant l'écran de configuration au travers de la commande sudo raspi-config). J'utilise personnellement le réglage "Medium" de manière à ne pas trop faire chauffer le Raspberry Pi et ne pas l'endommager.
Le tableau suivant montre les performances obtenues pour la résolution d'un champ sur la nébuleuse IC 1318 (voir l'entrée de blog précédente) avec deux Raspberry Pi (un de première génération et un de seconde génération) et différents réglages de l'overclocking:
Plateforme et overclocking | Durée (secondes) |
Raspberry Pi 512Mo Modèle B sans Overclocking None 700MHz ARM, 250MHz core, 400MHz SDRAM, 0 overvolt | 307 |
Raspberry Pi 512Mo Modèle B avec Overclocking « Modest » Modest 800MHz ARM, 250MHz core, 400MHz SDRAM, 0 overvolt | 281 |
Raspberry Pi 512Mo Modèle B avec Overclocking « Medium » Medium 900MHz ARM, 250MHz core, 450MHz SDRAM, 2 overvolt | 257 |
Raspberry Pi 512Mo Modèle B avec Overclocking « High » High 950MHz ARM, 250MHz core, 450MHz SDRAM, 6 overvolt | 248 |
Raspberry Pi 2 Modèle B 1 Go sans Overclocking None 700MHz ARM, 250MHz core, 400MHz SDRAM, 0 overvolt | 154 |
Raspberry Pi 2 Modèle B 1 Go avec Overclocking « Modest » Modest 800MHz ARM, 250MHz core, 400MHz SDRAM, 0 overvolt | 132 |
Raspberry Pi 2 Modèle B 1 Go avec Overclocking « Medium » Medium 900MHz ARM, 250MHz core, 450MHz SDRAM, 2 overvolt | 123 |
Raspberry Pi 2 Modèle B 1 Go avec Overclocking « High » Medium 900MHz ARM, 250MHz core, 450MHz SDRAM, 2 overvolt | 118 |
On voit grâce à ces tests que la performance du Raspberry Pi 2 Modèle B est doublée par rapport au Raspberry Pi Modèle B de première génération (154s versus 307s sans overclocking). Avec un overclocking "Medium", la résolution de cette image assez complexe se fait en 2 minutes environ, ce qui est tout à fait compatible avec une procédure de recalibration complète de la monture qui est un évènement plutôt rare dans la vie d'un observatoire remote comme le mien. Une sélection plus poussée des index Tycho2 (on garde uniquement les fichiers index-4107.fits à index-4112.fits pour couvrir une plage de diamètres des repères dans les images jusqu'à 120 minutes d'arc) permet de réduire légèrement les durées de résolution. On passe par exemple de 123s à 114s pour la résolution astrométrique du champ de IC 1318.
La prochaine visite à l'observatoire sera l'occasion d'installer cette plate-forme de résolution astrométrique avec une interface spécifique qui permettra de transférer facilement l'image à traiter et de récupérer les coordonnées du centre du champ au travers d'une API RPC. Cette interface fera l'objet d'une prochaine entrée dans le blog.
De plus, la température chute assez fortement durant la première moitié de nuit, ce qui m'a obligé a refaire une focalisation après chaque pose de 15 minutes ou toutes les deux poses dans le meilleur des cas. J'ai donc décidé d'agir et de mettre en place une compensation automatique de la température au niveau du focuser Robofocus. Ce dispositif existe déjà dans le logiciel Robofocus, mais je trouve que sa mise en oeuvre est laborieuse, surtout au travers d'une interface de gestion automatisée à distance. Il me semblait plus logique d'intégrer cette fonction dans mon code Python de gestion de l'observatoire. La compensation est activée uniquement si cela est spécifiquement demandé lors du lancement d'une pose ou d'une série de poses. Il faut au préalable qu'une procédure de focalisation ait été réalisée. Le système fonctionne de la manière suivante:
Il est à noter que l'on ne réalise pas la correction de focalisation si la température augmente d'une seule unité de température. En cas d'augmentation de température, on ne réalise la correction que si cette augmentation est d'au moins deux unités de température, ceci afin d'éviter un effet « yoyo » sur la correction.
Le paramètre de pente a été déterminé par de nombreuses mesures tout au long de l'été et de l'automne puis par une régression linéaire sur l'ensemble des points. Le capteur de température du Robofocus a bien sûr été extrait du boitier électronique du Robofocus (un problème classique reporté par tous les utilisateurs) et plaqué sur le pilier en acier de la monture de manière à refléter le mieux possible la température réelle de l'instrument. Un amélioration future consisterait à le mettre sur la lunette elle-même.
J'utilise maintenant cette fonction de façon routinière avec a priori de bons résultats. Autre bénéfice non négligeable, cela me permet de bénéficier de plages de sommeil beaucoup plus longues!
![]() |
L'observatoire est équipé dune lunette Takahashi FSQ-106ED sur une monture AstroPhysics 900 GTO. La photo ci-contre montre l'instrument en mode parking avec la lunette pointée vers le Nord. La monture est surélevée à l'aide d'un tube en acier lui-même monté sur la structure réglable du pilier de l'observatoire. Ce tube a une hauteur de 500 mm et un diamètre de 90 mm. Le perçage du tube est conçu pour s'adapter sur sa face inférieure à la platine du pilier et sur sa face supérieure à l'adaptateur AstroPhysics LT2APM (et permettre la mise en station de la monture, un piège à éviter soigneusement...). J'ai développé les plans du tube et la fabrication a été réalisée par la société SkyMeca, comme pour le support de moteur du toit (avec une excellent travail de Didier, comme d'habitude). J'ai simplement nettoyé puis verni le tube en acier de manière à le protéger de la corrosion. Inutile de dire que le montage est extrêmement rigide (le tube est creux et son épaisseur est de 10 mm). |
La raison pour laquelle l'instrument est surélevé est qu'il faut se dégager au maximum des murs de l'observatoire. L'inconvénient est que le toit ne peut être ouvert et fermé que lorsque l'instrument est en mode parking. Cela est soigneusement pris en compte dans le logiciel, et les mouvements du toit sont strictement interdits si les contacts de position parking positionnés sur les 2 axes de la monture ne sont pas activés (la mise en oeuvre de ces contacts fera l'objet d'un prochain blog).
Les câbles sont soigneusement fixés au pilier pour éviter des accrochages lors des mouvements de la monture. On voit sur le pilier le boîtier du RoboFocus et son capteur de température. La descente des câbles de la lunette est réalisée à l'aide d'un passe-câble souple qui garantit un risque d'accrochage quasiment nul. On voit aussi sur la photo le volet de la lunette commandé par un moteur de modélisme et un Arduino dans l'armoire de commande, ainsi que le disque à PLU devant la lunette en position parking. Ces différents dispositifs feront l'objet de futures entrées dans le blog.
Il ne s'agit que d'un premier traitement rapide, et il va falloir que je me replonge dans les subtilités de PixInsight pour faire un travail plus précis et qui combine les 3 filtres...
Concernant la gestion de la caméra CCD, je m'appuie entièrement sur le logiciel Maxim DL 5.07 et toute la communication entre le serveur Python sur le PC et la caméra se fait au travers de l'interface ActiveX. Pour le contrôle de la monture, je procède de la même façon en passant par le driver ASCOM AstroPhysics V2. La focalisation est quant à elle réalisée au travers de FocusMax (version 3.8) qui se connecte à un RoboFocus et qui est lui aussi accessible par une interface ActiveX. Enfin, l'autoguidage se fait à l'aide de la nouvelle version de PHD Guiding (la version 2) qui permet un interfaçage ActiveX, ce qui n'était pas possible dans la précédente version.
Etant décidé à réaliser entièrement le système de contrôle de l'observatoire, il m'est apparu qu'un critère important était la consommation électrique de ce dernier. Je voulais éviter autant que faire se peut de m'appuyer sur des PC traditionnels Windows, et mon choix s'est rapidement orienté vers l'utilisation de petits ordinateurs Linux de type Raspberry PI. Ces ordinateurs ont une caractéristique très intéressante: ils ne consomment que quelques Watts et peuvent donc être laissés en marche 24 heures sur 24 et 7 jours sur 7. De plus, j'étais prévenu que l'alimentation en électricité dans ce coin perdu de Catalogne posait parfois quelques problèmes, et il me fallait donc un système capable de fonctionner sur onduleur pendant plusieurs heures. Il n'est pas facile malgré tout de se passer d'un PC Windows, en particulier pour le pilotage de la caméra CCD et de la caméra de guidage. Hors période d'utilisation de l'observatoire, le PC Windows est arrêté et il n'intervient pas dans la gestion de l'observatoire lui-même (ouverture du toit, lumières, ventilateurs, vidéo, ...).
L'ensemble du contrôle de l'observatoire est assuré par 5 systèmes différents:
Observatoire | Météo | Télescope | |
IP Power Switch |
| ||
Raspberry Pi |
|
|
|
Arduino |
|
| |
PC Windows 7 |
|
| |
Serveur Vidéo |
|
Le schéma synoptique complet et détaillé du système ROCS est le suivant:
Outre les systèmes déjà décrits (IP Power Switch, Raspberry Pi, Arduino, PC Windows 7 et serveur Video), le schéma synoptique montre 3 autres composants importants:
Enfin, l'observatoire est protégé par un système de caméras autonomes avec télétransmission équipées de détecteurs de mouvements (qui viennent s'ajouter à la protection du site lui-même).
Un des principaux problème à résoudre pour réaliser un observatoire à distance est de pouvoir s'appuyer sur une mécansime d'ouverture et de fermeture du toit ou de la coupole fiable. En effet, la pire situation est de se retrouver avec un toit ouvert et bloqué alors que l'on se trouve à plusieurs centaines de kilomètres... Au moment de l'achat, le toit possédait un système manuel rudimentaire pour l'ouverture et la fermture. La première tâche a été de concevoir et d'installer une motorisation fiable. Les photos suivantes illustrent l'étape de motorisation du toit.
Après avoir eu une discussion avec deux autres personnes de l'association qui avaient elles-mêmes motorisé leur toiture, j'ai opté pour une motorisation de portail classique avec la crémaillère fixée sur la partie mobile du toit roulant. Le moteur est alimenté en 220V et intège un transformateur 220V/12V. Etant destiné à une utilisation intensive, il est a priori d'une très bonne fiabilité. J'ai conçu le support du moteur après avoir pris soigneusement les mesures sur place et je l'ai fait réalisé par la société SkyMeca qui a fait un très bon travail. Le moteur est commandé en mode "homme mort" (c'est à dire qu'il faut maintenir un contact pour réaliser le mouvement) directement depuis la centrale de contrôle de l'observatoire constituée par deux petits ordinateurs Raspberry Pi (voir un blog à venir qui décrira ce système). Après quelques ajustements et réglages de vitesse du moteur, le système s'est avéré très fiable et il peut maintenant être utilisé en toute confiance.
Il s'agissait pour moi de la partie la plus délicate du projet dans la mesure où je suis assez peu mécanicien...
Je travaille depuis un an sur un projet d'observatoire contrôlable à distance qui me permettrait de faire de l'astrophotographie sans avoir à subir l'incroyable frustration de l'astronome citadin qui voit les occasions d'observer réduites à quelques opportunités dans l'année... Entre les rares plages de congés, la météo capricieuse, les périodes lunaires gênantes pour la photographie et la qualité du ciel franchement aléatoire, il n'est possible de réaliser qu'une image ou deux de qualité correcte chaque année. Sachant qu'il faut rouler plusieurs heures pour échapper à la pollution lumineuse et que l'assemblage et la mise en station de la configuration nécessitent entre 2 et 3 heures, le moindre passage de nuages prend l'allure d'une Bérézina...
Au printemps 2013, au retour d'une session d'astronomie itinérante qui s'était soldée par un échec cuisant, je décidai de me lancer dans l'aventure et de développer un observatoire que je pourrais contrôler à distance (j'ai donné à ce projet le doux nom de ROCS pour Remote Observatory Control System). Après quelques recherches, un utilisateur Espagnol de mon logiciel d'astronomie C2A m'a indiqué qu'il existait une "ferme" d'observatoires en Catalogne au Nord de l'Espagne. Après avoir pris contact avec l'association qui gère ce site, j'ai eu la chance de pouvoir acheter un observatoire qui se libérait à ce moment là. Il s'agit d'un chalet en bois avec un toit roulant qui s'ouvre et se ferme manuellement. Ce site au Nord de l'Espagne représente un bon compromis en termes de pollution lumineuse, qualité du ciel et nombre de nuits claires chaque année. De plus, il se trouve à moins de 4 heures de route de Toulouse où je vis (quand je ne voyage pas pour mes activités professionnelles...).
Plusieurs personnes m'ont demandé des informations sur l'implémentation de mon projet, et j'ai donc décidé de réaliser un blog pour partager ces informations plus largement. Plutôt que de raconter linéairement le développement du projet ROCS, je fournirai des détails sur des aspects spécifiques au fil du temps.
Auteur: Philippe Deverchère |