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

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.

C2A, qui tient le rôle d'un client ROCS distant, maintient aussi un historique des conditions météo. Lors de chaque interrogation du serveur ROCS, il reçoit en retour les conditions courantes, il les affiche dans l'interface temps réel, et il les enregistre dans un fichier au format texte selon une syntaxe pré-définie.

Il est possible à tout moment d'afficher l'historique des conditions météo en cliquant le petit triangle présent dans la partie supérieure de la zone qui affiche les conditions courantes (la croix rouge permet d'effacer l'historique et la case à cocher permet d'activer ou de désactiver l'enregistrement de l'historique).

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;Humidity
2016-09-12 23:03:13+00:00;1;-5.6;1;2176;1;57232;1;3;+21.5;1;37
2016-09-12 23:03:23+00:00;1;-5.9;1;2176;1;57232;1;3;+21.5;1;37
2016-09-12 23:03:33+00:00;1;-5.6;1;2176;1;57232;1;6;+21.5;1;37
2016-09-12 23:03:43+00:00;1;-5.6;1;2176;1;57232;1;6;+21.6;1;37
2016-09-12 23:03:53+00:00;1;-5.7;1;2176;1;57232;1;6;+21.6;1;37

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

11 septembre 2016
Grand champ dans le Cygne en mode automatique

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.

9 avril 2016
La nébuleuse Sh2-240

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.

6 avril 2016
Nuit cométaire

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


C/2013 US10 (Catalina) La queue ionique de la comète est très visible.	256P/LINEAR La coma est très brillante et on devine tout juste une queue ionique	C/2014 W2 (PANSTARRS) Noyau bien défini et faible queue	9P/Tempel Noyau bien défini et faible queue	81P/Wild	116P/Wild On voit sur la gauche l'éclat de l'étoile delta Scorpii

24 décembre 2015
Caméra All-Sky Fripon

En guise d'introduction à cette nouvelle entrée du blog ROCS, voici une image réalisée récemment avec le mode automatique de l'observatoire. Ils s'agit de la nébuleuse Sh2-155 dans la constellation de Céphée. Cette vue a été composée à partir de 10 poses de 30 minutes en H-Alpha, 10 poses de 30 minutes en OIII et 10 poses de 30 minutes en SII, représentant donc un total de 15 heures de poses. Les prises de vue ont été réalisées durant le mois de novembre 2015. Les conditions de ciel n'ont pas toujours été idéales lors des acquisitions, ce qui fait que l'image reste relativement bruitée. Un traitement classique SHO a été réalisé sous PixInsight, mais sans tentative pour l'instant pour réduire le bruit de l'image. Des acquisitions ultérieures seront réalisées afin de mieux sélectionner les vues retenues et d'améliorer la qualité de l'image.

Comme seul le mode automatique de l'observatoire a été utilisé pour cette image, elle a donc été produite principalement durant mon sommeil !

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.

La première de ces interfaces clientes est bien sûr le module de contrôle ROCS du logiciel C2A. Une vue réduite de la caméra All-Sky est affichée à la demande dans l'interface graphique. Un double-click sur cette vue réduite permet d'afficher une vue en résolution plus élevée. L'image All-Sky de la caméra Fripon est mise à jour régulièrement et le temps de pose est calculé automatiquement par C2A en fonction de trois critères: (1) la luminosité reportée par le système de monitoring météo CloudWatcher si ce dernier est en marche – cela nécessite que le PC soit démarré (2) la hauteur du Soleil à l'instant de la prise de vue (3) la phase de la Lune à l'instant de la prise de vue. Sur la base d'un ou plusieurs de ces critères, le temps de pose calculé varie entre 0.00001 seconde (avec un gain de 1) et 30 secondes (avec un gain de 15). 0.00001 seconde est le temps de pose minimal permis par la caméra et 30 secondes est le temps de pose maximal. Le gain de la caméra peut être fixé entre 1 et 30, mais il est préférable de ne pas trop pousser le gain sans quoi l'image retournée peut être assez bruitée. Un gain de 15 à 20 avec une nuit sans Lune permet de bien saisir la Voie Lactée comme cela est montré plus loin.

Un petit outil écrit en Python a été développé pour dialoguer avec le contrôleur de service ROCS_SER, ceci essentiellement à des fins de test. Des poses unitaires peuvent être réalisées avec un temps d'exposition et un gain spécifiés. De plus, il est possible de réaliser des acquisitions en boucle. L'exemple ci-contre montre la Lune à 99% en train de se lever à l'Est / Nord-Est. Le Nord est en haut.

Le protocole de dialogue, basé sur des sockets TCP/IP, est très simple. La demande d'une pose unitaire est réalisé par exemple à l'aide de la commande:

rocs_cmd_allsky_exposure;<exp>;<gain>;<root>;<ext>;$

Le temps de pose, le gain, la racine du nom de fichier dans lequel sauver l'image et son extension sont fournis en arguments et séparés par des ';'. Le caractère '$' indique la fin de la commande. Le serveur ROCS_SER renvoie un statut immédiatement après réception de la commande sous la forme:

rocs_ret_allsky_status;started;$

Le statut de la prise de vue peut ensuite être obtenu régulièrement à l'aide de la commande:

rocs_cmd_allsky_status;$

Une fois l'image réalisée, elle peut être transférée vers le client au travers d'un protocole ftp sécurisé.

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.


Pose de 0.002 secondes au coucher du Soleil avec la Lune qui se lève à l'Est. La sierra est bien visible au Nord.	Pose de 30 secondes avec un gain de 20. La Voie Lactée est bien visible.	Passage de nuages devant la Lune. Des reflets éclairent la partie interne de la caméra.

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.

16 septembre 2015
Sécurité pour la fermeture du toit

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:
http://apod.nasa.gov/apod/ap140718.html).

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.

Afin d'implémenter ce second système, j'ai opté pour un système basé sur une cellule photoélectrique à réflexion. Le faisceau de la cellule est orienté de telle façon qu'il est coupé par l'instrument ou la monture dès que l'on quitte la position parking (photo de gauche). Un petit cache est fixé sur l'instrument de manière à ce que le faisceau soit coupé rapidement après que l'instrument monte sur l'axe de déclinaison (photo de droite). Sur la photo, on aperçoit à droite du cache la lumière rouge de la cellule photo-électrique qui est dirigée vers un rélecteur fixé sur le mur opposé.

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 :

les deux contacts magnétiques fixés dur la monture doivent être actifs. On interroge pour cela les contrôleurs Raspberry Pi au travers du protocole de communication inter-contrôleurs;
le contact de la cellule photoélectrique doit être actif. Cette information est obtenue en interrogeant l'Arduino connecté au PC coupole.

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.

16 mai 2015
Mode automatique de l'observatoire

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:

Enchaînement de plusieurs séquences durant le programme d'observations, chaque séquence ayant un type possible parmi 5: light, dark, bias, flat, focus. Une séquence peut démarrer dès que la séquence pécédente est terminée ou bien attendre une heure donnée. On peut aussi imposer une heure limite au delà de laquelle la séquence doit impérativement s'arrêter.
Le programme d'observations gère la température de la caméra, l'ouverture et la fermeture du volet de la lunette, la mise en parking et la sortie de parking de la monture. Seuls l'ouverture et la fermeture du toit ne sont pas encore gérés automatiquement, toujours pas souci de prudence vis à vis de la position de la monture. Je pense toutefois le faire rapidement pusique mon niveau de confiance vis à vis du logiciel atteint maintenant un niveau élevé...
Enchaînement de poses dans les différents filtres en mode séquentiel (on épuise les poses pour un filtre donné avant de passer au suivant) ou bien en mode Round Robin (on réalise une pose sur un filtre avant de passer au filtre suivant et on recommence ajusqu'à épuisement de toutes les poses).
Possibilité de spécifier un nombre arbitraire de cibles par leurs coordonnées équatoriales.
Gestion avancée de la focalisation soit au travers d'une séquence spécifique, soit durant les poses au sein d'une séquence. Les positions de focalisation peuvent être spécifiées pour chaque filtre (il faut en effet utiliser des étoiles de magnitude différentes selon les filtres utilisés avec FocusMax), et la focalisation peut être réalisée entre les poses selon plusieurs critères: focalisation toutes les 'n' poses, focalisation après qu'un temps donné se soit écoulé, focalisation si la température a changé de plus de 'n' degrés Celcius. Il est aussi possible d'utiliser la compensation automatique de température après qu'une focalisation initiale a été réalisée.
Gestion de l'autoguidage: le programme d'observations doit être capable de calibrer l'autoguidage (réalisé dans l'observatoire au moyen de PHD Guiding 2), de le lancer et de l'arrêter par exemple pour se déplacer sur une position de focalisation.
Calibration sur le ciel possible en début de chaque séquence: une image est prise sur le champ à observer et une résolution astrométrique est réalisée automatiquement.
Sauvegarde des images avec indexation automatique.
Possibilité de spécifier des délais d'attente entre les poses et entre les séquences.

L'aspect le plus complexe a développer à probablement été la gestion de l'autoguidage. Le logiciel PHD Guiding 2 est puissant, mais l'interfaçage au travers d'une interface RPC basée sur une syntaxe JSON est excessivement complexe.

Les deux copies d'écran ci-contre montrent les deux premières séquences d'un programme d'observations destiné à réaliser des poses LRGB de 15 minutes en autoguidage sur le couple de galaxies Messier 81 et Messier 82. La première séquence est une simple focalisation en Luminance sur une étoile proche des galaxies. La seconde séquence permet de réaliser 8 poses de 15 minutes chacune en autoguidage dans les 4 filtres L, R, G et B. Une calibration sur le ciel est réalisée en début de séquence, et une focalisation est réalisée entre chaque pose sur une position qui dépend du filtre. On est en effet en début de nuit et les variations de température sont encore importantes.

Une troisième séquence, non montrée ici, pemet de réaliser 12 poses de 15 minutes chacune dans les différents filtres LRGB, mais cette fois en ne réalisant une focalisation que toutes les deux poses (donc toutes les 30 minutes). On est en effet en milieu et fin de nuit, et il n'est plus nécessaire de réaliser des focalisations aussi souvent

Les deux zones en vert sur les copies d'écran montrent les instructions respectivement pour le début et la fin du programme d'observations. Pour le démarrage, on demande que la caméra soit refroidie à -25°C (il serait possible aussi demander un abaissement relatif de la température de la caméra par rapport à la température ambiante). Au démarrage du programme, on ne cherche pas spécifiquement à sortir la monture de sa position de parking: cela sera réalisé au moment du lancement de la première séquence. Enfin, on n'impose pas de contrainte sur l'heure de démarrage du programme, ce qui signifie que le refroidissement de la caméra démarrera dès l'envoi du programme.

Pour la fin de programme, une fois toutes les séquences exécutées, la monture est mise en parking, le volet de la lunette fermé et la caméra réchauffée et arrêtée.

J'ai pu tester au cours du mois de mai le mode d'observation automatique malgré des conditions très moyennes (pas mal de nuages d'altitude). J'ai réalisé de nombreuses poses individuelles de 15 minutes en LRGB sur le couple M81/M82 durant les nuits des 8, 9, 10, 11 et 12 mai, et j'ai aussi utilisé quelques poses des 13 et 23 avril ainsi qu'une pose du 7 mai. Au final, je disposais donc d'un total de 83 poses, et après évaluation de la qualité avec le script SubFrameSelector de PixInsight, j'en ai retenu 44: 19 en R (4:45 de pose), 13 en G (3:25 de pose) et 12 en B (3 heures de pose), pour un total donc de 11 heures de pose. L'image ci-contre montre le résultat de ces acquitions en mode totalement automatique.

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):

Batch Preprocessing dark, flat, bias avec Cosmetic Correction
Dynamic Crop sur toutes les images (l'avantage du mode automatique est qu'il réalise automatiquement une calibration sur le ciel et les 44 images sont centrées sur le même point de manière presque parfaite - le crop est donc tout à fait minimal)
ImageIntegration sur chacune des 3 images R, G et B
LRGBCombination sur les 3 images RGB pour obtenir l'image couleur (sans réduction de bruit de chrominance, il sera traité plus tard)
Dynamic Background Extraction pour retirer un gradient assez fort. Je ne sais pas trop si ce gradient est dû à la mauvais qualité des flats ou bien à la présence de la Lune durant certaines poses (a priori ce serait plutôt la Lune, je n'ai pas ce genre de gradient marqué d'habitude)
Background Neutralization pour rendre le fond de ciel noir
Color Calibration pour retrouver les couleurs des galaxies
Histogram Transformation pour passer en mode non linéaire de l'image
HDRMultiScaleTransform pour faire apparaître les détails dans les zones brillantes
A nouveau un petit Histogram Transformation pour ajuster la visualisation
TGVDenoise pour enlever le plus possible le bruit sur le fond de ciel. Durant ce processus, je protège les galaxies avec un masque pour ne pas perdre de détails sur les structures. Je suis personnellement bluffé par cet outil dans PixInsight. C'est à mon avis un des principaux intérêts de ce logiciel et il donne des résultats incroyables.
A ce moment, j'exporte l'image en JPEG et je fais un petit traitement final dans PhotoShop CS6: léger ajustement du contraste, renforcement de la vibrance des couleurs et léger renforcement des détails.

16 avril 2015
Résolution astrométrique avec un Raspberry Pi

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.

Pour des raisons de performance, j'ai décidé d'utiliser le tout dernier Raspberry Pi 2 Type B (avec 1 Go de RAM) disponible pour moins de 40 Euros sur des sites marchands. Sa puissance est doublée par rapport au Raspberry Pi de première génération (model B avec 512 Mo de RAM) comme on le verra plus loin dans les tests de performance. Le Raspberry Pi est équipé d'une carte micro SD de 64 Go (cette taille importante est justifiée par la possibilité d'installer plus tard des index de résolution astrométrique de grande taille). Cette carte est disponible pour 35 Euros sur Internet, mais on peut bien sûr utiliser une carte de moindre capacité et moins cher si on cherche à résoudre des champs de plus de 1° environ. Enfin, un boîtier est utilisé pour protéger le Raspberry Pi ( boîtier B+ Pibow Coupé à 12 Euros). L'alimentation est un constituée par un petit bloc standard 1A avec une prise micro USB.

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:

Charger la distribution courante de Raspbian 'wheezy' depuis http://www.raspberrypi.org/downloads. Par défaut sur cette image le username est 'pi' et le mot de passe est 'raspberry'.
A l'aide de l'utilitaire Win32DikImager (facilement trouvable sur Internet), flasher la carte SD sur un PC avec l'image Raspbian préalablement chargée et décompressée.
Installer le logiciel Putty sur le PC Windows qui servira à administrer le Raspberry PI (ce logiciel est disponible sur http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html). Cet outil permettra d'administrer le Raspberry Pi au travers d'une ligne de commande SSH.
Connecter le Raspberry à un écran, soit directement en HDMI, soit avec un convertisseur VGA. Connecter un clavier USB.
Dans l'utilitaire de configuration, commencer par étendre le file system pour utiliser tout l'espace de la carte SD. Remarque : pour redémarrer plus tard la configuration, taper à la ligne de commande : sudo raspi-config.
Changer le clavier pour un clavier français : (1) Internationalisation Options (2) Change keyboard Layout (3) Generic 105-key (Intl) PC (4) Other (5) French (6) French (7) Right Alt (AltGr) (8) No compose key.
Changer le mot de passe pour l'utilisateur « pi » (plus tard, le mot de passe peut être changé avec la commande passwd).
Changer le nom du système dans les options avancées (par exemple astropi).
Configurer la zone horaire dans « Internationalisation Options » : Europe puis Paris.
Dans les options avancées, configurer le Memory Split (64 MB pour le GPU) et activer SSH ("Enable SSH" ).
Eventuellement "overclocker" le Raspberry Pi (voir plus bas pour les performances).
Rebooter après s'être déplacé sur « Finish ».
Se connecter avec le user 'pi' et le mot de passe spécifié pendant la configuration.
Attribuer une adresse IP statique :
cd /etc/network
sudo nano interfaces
Remplacer la ligne
iface eth0 inet dhcp
par
iface eth0 inet static
address 192.168.x.y
netmask 255.255.255.0
gateway 192.168.x.1
où x et y dépendent de la configuration de votre réseau local. Vérifier l'adresse IP après reboot avec la commande
ifconfig
Rebooter avec la commande
sudo reboot

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:

Mise à jour de la liste des paquets :
sudo apt-get update
Mise à jour des paquets installés :
sudo apt-get upgrade
Procédez à l'installation du logiciel 'astrometry.net' de la façon suivante:
sudo apt-get install libcairo2-dev libnetpbm10-dev netpbm \
    libpng12-dev libjpeg-dev python-numpy \
    python-dev zlib1g-dev \
    libbz2-dev swig cfitsio-dev
sudo apt-get install python3-pip
sudo apt-get install python-setuptools
sudo easy_install pyfits
wget http://astrometry.net/downloads/astrometry.net-0.46.tar.bz2
tar xjf astrometry.net-0.46.tar.bz2
cd astrometry.net-0.46
make
make py
make extra
sudo make install
L'ensemble de la compilation et de la configuration prend 20 minutes environ et il faut être un peu patient.
Par défaut, astrometry.net est installé dans /usr/local/astrometry.
On doit avoir une version de python-fits au moins égale à 3.1. On peut vérifier la version avec la commande :
python -c "import pyfits; print pyfits.__version__"
Pour ajouter le répertoire des exécutable de astrometry.net, il faut ajouter les 2 lignes suivantes au fichier /home/pi/.profile :
# Add the astrometry bin directory
PATH="$PATH:/usr/local/astrometry/bin"
Créer sur /home/pi un sous-dossier Tycho2 et y copier les fichiers d'index pré-compilés du catalogue Tycho2 qui peuvent être obtenus depuis http://data.astrometry.net/4100. Ces index conviennent pour les images réalisées avec ma configuration (champ de 2° par 1,5° environ). Attention, vous pourriez avoir besoin des fichiers d'index plus complets si le champ de votre télescope est plus réduit (voir http://astrometry.net/doc/readme.html). Des tutoriels sur Internet expliquent comment utiliser une clé USB pour transférer des fichiers volumineux sur un Raspberry Pi.
Ajouter le chemin d'accès aux index Tycho2 dans le fichier astrometry.cfg à l'aide de la commande:
sudo nano /usr/local/astrometry/astrometry.cfg
La ligne à ajouter est la suivante :
add_path /home/pi/Tycho2

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.

A titre d'exemple, voici une image brute que l'on va chercher à résoudre. Il s'agit d'une pose de 30 minutes sur une partie de la nébuleuse SH2‑240 prise au travers d'un filtre H-Alpha. Cette image est particulièrement complexe à résoudre puisqu'elle est prise en pleine voie lactée. On lance donc la commande:
solve-field -p --overwrite --timestamp --scale-units arcsecperpix --scale-low 2.05 --scale-high 2.15 SH2-240-H015.fit
et au bout de 240 secondes, le logiciel rend son verdict:
Field center: (RA H:M:S, Dec D:M:S) =
(05:45:00.402, +27:09:03.602)
Field size: 1.94285 x 1.46268 degrees
Field rotation angle: up is -90.2398 degrees E of N

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.

Par défaut, astrometry.net produit un "plot" de la résolution: il indique les étoiles qui ont été "matchées" durant la résolution ainsi que le triangle principal qui a été utilisé. L'image sur le droite montre une résolution réalisée sur le champ de la galaxie NGC 3184.

Attention toutefois, la production de ce plot accroit de manière significative la durée de la résolution astrométrique. L'option à ajouter sur la ligne de commande pour supprimer la production du plot est "-p".

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.

24 novembre 2014
Compensation de température pour le focuser

Avant de parler de la compensation en température du focuser, voici une image réalisée lors de plusieurs sessions "remote" entre juillet et novembre 2014. Il s'agit du complexe de Sadr dans la Cygne qui inclut entre autres la nébuleuse IC 1318 et l'amas ouvert NGC 6910 visibles sur l'image. Les conditions de seeing cet automne n'ont pas été formidables, et cela se ressent sur la qualité de l'image... Quelques regrets donc...

Pour réaliser cette image, 19 heures de poses ont été nécessaires avec des filtres à bande étoite H-alpha, OIII et SII (11h30 heures en H-alpha, 3h45 heures en OIII et 3h45 en SII). Un de mes gros soucis durant les prises de vue a été la variation de température au cours de la nuit, en particulier durant les mois de grosse chaleur. L'observatoire est surchauffé au moment de l'ouverture du toit, et même s'il se refroidit rapidement, la lunette met plus de temps pour se mettre en température.

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:

Lors de toute procédure de focalisation, on mémorise à l'issue de cette dernière (1) l'instant de la focalisation (2) la température reportée par le capteur Robofocus (3) la position absolue du focuser. La température est déterminée en réalisant 9 mesures et en prenant la valeur médiane.
Deux modes sont alors possibles : une compensation à intervalles réguliers quel que soit l'état des poses, ou bien une compensation entre deux poses.
- Toutes les 5 minutes, on fait un relevé de température Robofocus (médiane parmi 9 mesures). Si cette température diffère de la dernière température relevée lors de la focalisation initiale ou de la dernière compensation, on réalise une correction.
- Avant de démarrer une pose lancée par ROCS (soit une pose individuelle, soit une pose dans une série), on réalise une correction de la focalisation si les conditions suivantes sont réunies : (1) il s'est écoulé plus de 5 minutes depuis la dernière compensation de température ou focalisation (2) la valeur de température relevée, toujours en prenant la médiane parmi 9 mesures, diffère de la dernière température relevée lors de la focalisation initiale ou de la dernière compensation.
Si une compensation de la température s'avère nécessaire, on calcule la nouvelle position du focus de la façon suivante :
new_pos = initial_pos + delta_temp * slope
où initial_pos est la position du focuser au moment de la focalisation initiale, delta_temp est la différence de température observée entre l'instant courant et l'instant de la focalisation, et slope est la pente de la compensation de température.
On déplace alors le focuser à la position absolue calculée et on mémorise (1) l'instant de la compensation de température (2) la température reportée par le capteur Robofocus (3) la position absolue courante du focuser. Cette dernière information n'est utile qu'à titre informatif.

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!

31 août 2014
Montage de l'instrument

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

La figure ci-contre montre les hauteurs limites atteintes par l'instrument à l'Ouest, à l'Est et au Sud dans la configuration actuelle (cliquez pour agrandir). Le point de visée le plus critique est au Sud avec 15° de hauteur au plus bas. Cela est suffisant à la latitude d'Àger pour imager la plus grande partie du Sagittaire, mais Messier 7 restera à toujours invisible...

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.

27 juillet 2014
Contrôle de l'observatoire

Avant de présenter la façon dont j'ai implémenté le contrôle de l'observatoire, voici une image réalisée cette semaine en utilisant l'observatoire à distance. Il s'agit du coeur de la nébuleuse IC 1318 dans la constellation du Cygne, tout près de l'étoile Sadr (gamma Cygni). On voit aussi sur l'image le joli amas ouvert NGC 6910 qui appartient au même complexe que IC 1318 et qui permet d'ailleurs d'estimer un peu plus finement la distance de la nébuleuse (environ 3700 années-lumière). Le nuage de poussière sombre sur la droite de l'image fait environ 20 années-lumière de large.

J'ai réalisé de nombreuses poses individuelles de 15 minutes en autoguidage avec des filtres à bande étroite H-Alpha, OIII et SII durant 3 nuits. Cette image est le résultat de la composition de 32 images en H-Alpha, et elle représente donc 8 heures de poses cumulées.

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 le câblage, le coeur de l'observatoire est constitué d'une armoire électrique supportant une platine sur laquelle sont fixés les deux Raspberry Pi et l'Arduino qui contrôlent l'observatoire. On voit aussi sur l'image ci-contre les 16 relais de commande ainsi que l'alimentation électrique 5, 12 et 24 Volts. Les prises de puissance pour les instruments sont fixées sur les côtés de l'armoire ainsi que des boitiers qui recoivent les câbles en provenance des différents systèmes de l'observatoire. Afin que la platine puisse être démontée facilement, tous les câbles qui partent de cette platine sont reliés à des connecteurs. Il est donc possible de retirer la platine afin de la poser sur une table pour pouvoir travailler plus facilement.

Depuis que cette photo a été prise, un petit ventilateur de type PC a été installé pour ventiler le coffret, même si a priori la température n'est jamais excessive du fait de la faible puissance des 2 Raspberry Pi. On voit sur l'image des deux câbles Ethernet pour connecter les Raspberry Pi ainsi que les 2 câbles USB des Webcams et le câble USB de l'Arduino. Les alimentations 220V des instruments sont connectées aux prises autour du coffret par des dominos de fort diamètre.

Cette image montre globalement l'installation qui contrôle l'observatoire. On y voit le coffert qui intègre les 2 Raspberry Pi, l'Arduino et les relais, l'onduleur qui assure l'alimentation de l'observatoire en cas de panne de secteur (boîtier noir posé sur la table à côté du coffret) et le PC nécessaire au contrôle de la monture, de la caméra, du CloudWatcher et du focuser (sans écran). Fixé à la poutre, on voit un petit coffret beige qui est le système de secours GSM pour fermer l'observatoire en cas de perte de la connexion Internet. Un lumière rouge et une lumière blanche basse consommation sont intégrées à un petit boîtier juste au-dessus des deux sondes de température sur la droite du coffret.

Seuls les systèmes critiques sont reliés à l'onduleur (les ventilateurs par exemple sont directement sur le réseau 220V). On voit en bas et à doite de la photo les câbles qui partent vers l'instrument. Il serait possible de les faire passer sous le plancher, mais pour l'instant, l'utilisation de 2 passe-câbles assez plats posés sur le plancher représente une bonne solution avec une accessibilité plus grande.

8 juillet 2014
Le logiciel

L'ensemble du logiciel qui tourne au sein de l'observatoire sur les deux Raspberry Pi et le PC Windows a été développé en Python 3. Cet environnement a été pour moi une véritable découverte et j'ai été très agréablement surpris par sa puissance, sa simplicité et sa fiabilité. Il permet d'implémenter facilement des tâches "multi-threads", ce qui est indispensable dans le cadre de ce projet où de nombreuses actions simultanées interviennent. De plus, il tourne aussi bien sous Linux que sur Windows. Il s'agit d'un langage qui possède des interfaces puissantes et simples à utiliser, que ce soit par exemple pour l'envoi d'un email automatique, la manipulation de sockets ou le contrôle de cartes d'entrées sorties. La seule difficulté que j'ai rencontrée concerne le pilotage de composants Windows ActiveX en environnement multi-threads pour s'interfacer avec des logiciels comme Maxim DL ou les pilotes ASCOM de la monture ou du Focuser. Mais avec un peu de patience, on finit par trouver la solution.

Concernant l'interface client, j'ai développé un module spécial au sein de mon logiciel de cartographie stellaire C2A qui me permet de contrôler entièrement l'observatoire sans avoir à ouvrir un bureau virtuel distant. Je peux aussi entièrement contrôler la monture directement depuis les cartes de champs, lancer des poses, réaliser la focalisation et lancer l'autoguidage au sein de la même interface. La communication entre C2A et les serveurs au sein de l'observatoire se fait avec un protocole que j'ai développé et qui s'appuie sur des sockets TCP/IP avec authentification cryptée lors de la connexion. Ce protocole est conçu pour être léger et il est ainsi possible de contrôler l'observatoire au travers d'une simple liaison 3G sur un portable en faisant passer aussi des images vidéo. La copie d'écran ci-contre montre l'interface juste après l'acquisition des premières images le 9 juin 2014.

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.

6 juillet 2014
L'architecture générale du système ROCS

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:

un IP Power Switch qui gère l'alimentation générale des différents composants de l'observatoire;
Deux Raspberry Pi Linux équipés chacun d'un module d'extension PiFace pour la gestion de l'observatoire;
Un Arduino pour certaines fonctions en lien avec le PC et la gestion du télescope;
Un PC Windows 7 pour la gestion du télescope et de la station météo;
Un serveur vidéo miniature pour l'acquisition des images vidéo intérieures et extérieures.

Le tableau suivant résume les différentes fonctions implémentées dans l'observatoire ROCS et quel système a la charge de quoi.

	Observatoire	Météo	Télescope
IP Power Switch	Alimentation du système vidéo Alimentation du toit Alimentation de l'armoire de contrôle Alimentation générale des instruments
Raspberry Pi	Ouverture et fermeture du toit Gestion des alimentations du PC et de tous les instruments Démarrage et arrêt du PC Gestion des lumières Gestion de ventilateurs Capture du son dans l'observatoire Webcams intérieures Interface Web	Réception du contact de mauvaises conditions météo	Réception du contact de position parking
Arduino		Température intérieure de l'observatoire Mesure de l'humidité	Réception de la demande de parking de la monture pour les arrêts d'urgence Commande du volet de la lunette
PC Windows 7		Station CloudWatcher Caméra All-sky Acquisition de la température intérieure et de l'humidité depuis l'Arduino	Pointage du télescope et autoguidage Acquisition des images (MaximDL) Gestion de la focalisation (RoboFocus et FocusMax)
Serveur Vidéo	Caméra intérieure faible luminosité Caméra extérieure

Schéma synoptique

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:

Un onduleur qui permet d'assurer l'alimentation du système en cas de coupure du courant;
Le routeur Ethernet qui crée le réseau local à l'observatoire et qui assure le lien vers le point d'accès Internet;
Un point d'accès GSM qui permet d'arrêter l'observatoire au travers d'un simple SMS en cas de perte d'accès à Internet;
Un détecteur de perte d'alimentation qui permet d'indiquer au système que l'alimentation de l'observatoire est coupée.

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

21 juin 2014
Le toit roulant

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.


Les étais extérieurs pour soutenir le toit roulant.	Le toit roulant vu de l'intérieur avec le cadre métallique, les roues et la cournière de guidage.	Installation du support du moteur sur la poutre et de la crémaillère sur le support métallique du toit.	Le moteur de portail mis en place et ajusté sur la crémaillère.

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

9 juin 2014
Première lumière

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.

Pour commencer, voici la première image réalisée depuis l'observatoire contrôlé à distance. Il s'agit des galaxies Messier 81 et 82 dans la Grande Ourse. J'ai réalisé 12 poses de 5 minutes en luminance et avec autoguidage. Ces images ont été réalisées entre 23h et minuit heure locale le 8 juin 2014. Les conditions étaient plutôt mauvaises pour faire de l'imagerie (mauvais seeing, passage de nuages et présence de la Lune), mais le but était de valider pour la première fois l'ensemble de la chaîne d'observation, depuis l'ouverture du toit jusqu'au transfert des images. Et tout s'est bien passé!

Auteur: Philippe Deverchère