Remotizzazione

aggiornata al 20/2/2016


Remotizzazione o automazione?

I due termini vengono spesso interpretati come sinonimi ma non lo sono. La completa automazione di un osservatorio implica la capacità autonoma della strumentazione di prendere decisioni, le più varie, in conseguenza delle condizioni del momento: giorno/notte, condizioni meteorologiche, stato di salute della strumentazione. Questo non è mai stato il mio scopo, sebbene la sola remotizzazione possa implicare la necessità o l'opportunità di automatizzare (poco o tanto) alcune fasi o operazioni dell'osservatorio. 


Un po' di storia

Il primo barlume di remotizzazione risale a molti anni fa, quando andavo in giro con gli amici astrofili nei posti più sperduti e passavo le notti al freddo e al gelo, e quando l'unica possibilità di scaldarsi era rifugiarsi in macchina. Allora realizzai che operare con due PC collegati in rete (quello principale collegato alla strumentazione, il secondo con me in macchina) mi avrebbe consentito di vigilare sul funzionamento della strumentazione restando al calduccio. A quel punto avrei dovuto recarmi al telescopio solo nelle situazioni in cui l'intervento manuale si rivelava indispensabile.

E' chiaro che la strumentazione volante di un astrofilo zingaro non consente di realizzare setup complessi tali da affinare le problematiche di remotizzazione, ma il principio era stato stabilito: il controllo remoto della strumentazione era alla mia portata, e se si poteva fare a 4 o 5 metri di distanza, in linea di principio era fattibile anche a 100Km di distanza.

La cosa è rimasta in embrione fino al mio trasferimento in postazione fissa al Dalai Lama nell'ottobre 2010.

Qui ho potuto realizzare un setup della strumentazione sempre più sofisticato, con lo scopo di avere il telescopio utilizzabile in pochi minuti.

Naturalmente la cosa è stata tutt'altro che facile. Nei primi tempi mi sono reso conto che nonostante la postazione fissa continuavo a espletare tutta una serie di operazioni manuali che ritardavano l'operatività dell'osservatorio. Non solo: le molte operazioni manuali (praticamente le stesse che facevo da zingaro) erano soggette all'errore umano, costringendomi spesso a ricominciare daccapo.

Come soluzione mi sono messo a scrivere un programmino in Visual Basic che mi aiutasse a tenere traccia delle operazioni da eseguire nel corretto ordine. Con fantasia teutonica ho chiamato il programma Astromaster e nella sua versione iniziale non era nient'altro che una checklist. L'utilità di questo programmino è stata fondamentale: mi ha indotto a riflettere su ogni operazione che facevo, aiutandomi a snellire e ottimizzare il flusso delle operazioni, ed infine mi ha portato a raggruppare e automatizzare molti passaggi. A metà 2015 le operazioni manuali che facevo erano: apertura osservatorio, rimozione protezioni, accensione e collegamento telescopio-PC, puntamento alla prima stella. Tutto il resto era gestito in remoto da un secondo PC situato dentro la roulotte (4 metri di distanza). Senza contare la messa a fuoco e il tempo di raffreddamento del CCD, ero pronto a operare entro 15 minuti dal mio arrivo all'osservatorio.

Nel frattempo avevo installato una rete locale con accesso a internet (tramite router wifi 3G) che mi consentiva (tramite un'applicazione di desktop remoto) di operare dall'interno della roulotte come se fossi davanti al PC dell'osservatorio.

Determinante si è rivelata anche una iniziativa che apparentemente non aveva niente a che vedere con l'astronomia: con Lucio abbiamo cominciato ad installare alcune telecamere di sorveglianza. In realtà non ce n'era bisogno, ma la soddisfazione di poter vedere i pressi dell'osservatorio, e vedere da Torino che tempo c'era al Dalai Lama, era notevole.

Nel tempo la strumentazione remota è cresciuta con una stazione meteo, una telecamera allsky, un sqm. Tutto ciò è stato di fondamentale importanza per prendere dimestichezza con i problemi di comunicazione a grande distanza, tenuto conto che il canale di comunicazione era Internet, e che mentre in città lo si da per scontato, in montagna la continuità e l'affidabilità del servizio sono tutt'altro che fatti consolidati.

telecamera a sud

 

telecamera a est

 

telecamera a ovest

 

sensore neve

 

All Sky Camera & Sky Quality Meter

 

Stazione meteo

 


Comunicazione...

Il primo concetto fondamentale se si vuole remotizzare un osservatorio è la comunicazione; bisogna cioè assicurarsi che la comunicazione fra operatore e osservatorio sia continua e affidabile. In montagna ben difficilmente si ha accesso ai servizi comunemente disponibili in città: ADSL e Fibra ottica (o altro tipo di collegamento cablato) non sono quasi mai disponibili.  Restano i collegamenti non cablati come i servizi GSM-dati forniti da tutti gli operatori telefonici, servizi dati satellitari o servizi Wifi punto-punto. Questi ultimi sono spesso l'ultima risorsa  nei luoghi in cui non arriva neanche il segnale GSM, ma i costi possono essere notevoli e sulla continuità e affidabilità del servizio non saprei esprimermi.

Al Dalai Lama siamo fortunati: ben due operatori di telefonia mobile raggiungono il campeggio con un segnale accettabile. Quindi ci siamo dotati di router Wifi con ingresso per modem GSM 3G. Si tratta di normali router con mediamente 4 connessioni ethernet cablate e un server Wifi ampiamente configurabile, che offrono anche la possibilità di accettare su apposita porta una chiavetta USB che ospita una sim GSM. La configurazione del router, anche se non si tratta di una operazione difficile, è da fare con estrema cura per sfruttare appieno il canale di comunicazione con internet. Un aspetto degno di nota è stato dotare il Modem GSM (la chiavetta USB) di una antenna esterna direzionata sul ripetitore di segnale (con un segnale migliore in ingresso migliorano gli aspetti fondamentali già citati: continuità e affidabilità del servizio).

Ammesso che tutto funzioni a dovere bisogna sempre porsi la domanda: cosa può andare storto? Escludendo tutti gli accidenti su cui non si può intervenire (tipo guasto del ripetitore GSM), esiste la possibilità che il router si blocchi. Questa è una situazione tutt'altro che remota e può essere risolta solo resettando il router (togliendo l'alimentazione per qualche secondo). La soluzione che ho utilizzato è basata su un combinatore GSM che tramite opportuni sms agisce su dei relè; in pratica il combinatore che riceve il messaggio sms 'resetta il router' apre un relè che toglie alimentazione al router per una manciata di secondi; una volta rialimentato, il router parte normalmente rendendo disponibile il canale di comunicazione nel giro di 2 minuti al massimo.

Normalmente un combinatore telefonico del genere ha un costo non indifferente; io l'ho realizzato con elettronica in stile Arduino: economica, facile e divertente se si ha un minimo di infarinatura di elettronica e programmazione.

antenna GSM

 

combinatore GSM e relè


Alimentazione...

Sull'alimentazione dell'osservatorio è opportuno considerare qualche aspetto non banale. L'alimentazione elettrica in zone rurali o montuose può avere qualche oscillazione (frequenza, ampiezza) che normalmente in città non si verifica; le interruzioni di servizio sono rare ma più frequenti che in città; le linee elettriche sono un bersaglio ideale per i fulmini, frequenti in montagna specialmente fra primavera inoltrata e inizio autunno. Una soluzione che mi fa dormire sonni un po' più tranquilli è quella di alimentare tutto l'osservatorio con un UPS (o gruppo di continuità), una specie di batteria che all'occorrenza alimenta l'osservatorio per parecchi minuti anche in assenza di alimentazione esterna, che regola in modo ottimale l'alimentazione anche in presenza di oscillazioni di frequenza o ampiezza, e che filtra eventuali scariche provocate da fulmini.

Un secondo aspetto riguarda la distribuzione dell'alimentazione e l'accensione/spegnimento dei vari apparati. Normalmente ogni apparato utilizzato nell'osservatorio ha un suo alimentatore e tenere in ordine tutti i cablaggi non è cosa semplice. Io ho risolto con un unico alimentatore a parete da 12V e due batterie di relè, 8 comandati da USB e 8 comandati da LAN. Anche queste batterie di relè sono state realizzate con elettronica in stile Arduino. Queste batterie di relè sono indispensabili per accendere spegnere a distanza ogni apparto nell'osservatorio.

relè con interfaccia USB

 

relè con interfaccia Ethernet

 


Is there anybody out there?

Siamo davanti al PC di casa e il canale di comunicazione c'è, ma con cosa comunichiamo? Ma col PC dell'osservatorio naturalmente! Orbene la scelta del PC non è cosa banale. Le caratteristiche che deve avere sono molteplici:

1 - deve essere affidabile e sufficientemente potente da non fermarsi MAI.

2 - deve essere possibile accenderlo/spegnerlo e resettarlo in remoto.

3 - deve avere un'ampia dotazione di porte USB native (meglio se ha anche un paio di RS232).

4 - deve consumare e scaldare poco.

5 - deve poter operare in condizioni di temperatura e umidità estreme.

In questi anni mi sono cimentato nell'utilizzo di varie soluzioni e posso dire tranquillamente che i PC desktop sono quelli che ho scartato quasi subito: consumano troppo e gli alimentatori sono particolarmente sensibili a temperatura e umidità fuori norma; paradossalmente gli alimentatori più costosi e raffinati sono quelli che fanno dei controlli più selettivi di temperatura e umidità, per cui non consentono di accendere il PC a temperature troppo basse o in presenza di umidità troppo elevata.

I portatili sono molto più aderenti ai requisiti di cui sopra, tranne per un aspetto fondamentale: non è possibile accenderli, spegnerli e resettarli in remoto con certezza matematica. Anche le funzionalità di WOL (Wake-On-Lan, che però non tutti i portatili offrono e sicuramente non quelli di fascia economica) non garantiscono il corretto comportamento proprio nelle situazioni in cui è necessario l'intervento remoto: un malfunzionamento HW o SW quasi sempre implica una mancata attivazione della funzione WOL. In tal caso il risultato è sconfortante: magari si riesce a spegnere il PC ma non si riesce più a riaccenderlo.

Recentemente (grazie a una segnalazione del solito Lucio) ho messo le mani sulla soluzione finale (mai dire mai...) che ormai da diversi mesi funziona senza perdere un colpo. Si tratta di un barebone, cioè di un mini PC che viene venduto senza memoria, HD e sistema operativo, che va completato e configurato a cura dell'utente, ma che ha tutte le caratteristiche richieste.

Una nota sui consumi: l'energia elettrica al Dalai Lama è garantita da torrette di distribuzione che hanno un limite di 1,5 Kw/h. E' la metà di una utenza domestica  ma è sufficiente ad alimentare 2 osservatori, l'illuminazione interna alla roulotte, una tv lcd, la macchina per il caffè ecc, però è abbastanza cara. Tenendo conto che il PC deve restare SEMPRE acceso per consentire il download di immagini e di dati meteorologici vari, va da se che se deve essere parco di consumi. Il mio barebone consuma al massimo 40W nelle condizioni peggiori, e tutto il resto (telecamere e sensori) forse non fanno altri 40W di picco; se  l'osservatorio non è operativo me la cavo con un consumo medio di 50-55W continui.

Per farla breve sono rimasto così contento delle performance di questo PC che ho deciso di destinarlo alla sola funzione di PC principale, che viene acceso, spento o resettato dal combinatore GSM, e di comprarne un altro da dedicare all'osservatorio Nunki (a sua volta acceso, spento o resettato dal PC principale).

Ultima nota: operando in sola modalità remota i due barebone non sono dotati di monitor, tastiera o mouse: semplicemente non ce n'è bisogno!

Barebone [20 x 16.5 x 3.95 cm]

 

Barebone - interfacce

 


Desktop remoto & automazione spicciola

E' il cuore della soluzione. In pratica si tratta di dotarsi di una applicazione (ne esistono diverse anche free) che consenta di collegarsi ad un computer remoto e di operare come se fosse fisicamente davanti a voi. Non c'è nulla di magico o di particolarmente difficile da configurare. Va solo ricordato che le performance sono direttamente legate alla velocità e alla affidabilità del canale di comunicazione.

Una volta acceso il barebone dedicato a Nunki mi collego ad esso e faccio partire il mio programma Astromaster  che negli anni è diventato ben più di una checklist.

 

Le cose che fa di routine alla partenza sono:

1 - Comanda i relè per alimentare CCD, guida attiva, focheggiatore, montatura, ccd di guida e ruota portafiltri.

2 - Avvia i Software e i driver richiesti: Ascom, Thesky, MaximDL, Pinpoint, Focusmax, Astrometry.net

3 - Carica le configurazioni ottimali per HW, SW e driver.

4 - Verifica che HW, SW e driver siano presenti e funzionino correttamente.

5 - Imposta le coordinate iniziali della montatura sulla posizione HOME (funzionalità mancante nel controller FS2 della mia montatura).

6 - Legge la temperatura ambiente e calcola la temperatura minima da impostare per il CCD.

7 - In base al punto precedente imposta una rampa di raffreddamento che porti il CCD alla temperatura ideale in circa 20 minuti.

8 - Calcola tramonto, levata e crepuscoli e imposta l'orario di fine delle operazioni allo scoccare del crepuscolo nautico (sole a -12°)

Il tutto senza toccare un tasto!

 

Il programma può terminare in due modi:

a) perchè gli è richiesto

b) perchè è scoccato il crepuscolo nautico

In entrambi i casi il programma:

1 - interrompe qualsiasi operazione in corso

2 - avvia la rampa di riscaldamento del CCD

3 - se è prevista la ripresa dei flat: posiziona il tubo di fronte al pannello dei flat, lo accende, riprende i flat richiesti per tutti i filtri e i binning previsti, spegne il pannello dei flat

4 - posiziona il tubo in posizione home

5 - termina nell'ordine corretto SW e driver

6 - opera sui relè per spegnere i vari apparati

 

L'operatività a valle della fase iniziale o prima della conclusione della notte è a carico del sottoscritto.

Ho inserito una singola operazione di automazione per potermi permettere qualche ora di sonno in più: posso inserire le coordinate di massimo tre oggetti distinti, unitamente alle sequenze di ripresa richieste (filtri, binning, durate) e agli istanti in cui il telescopio deve spostarsi.

Ulteriori funzioni richiamabili in base a necessità:

1 - Messa a fuoco totalmente automatica (rintraccia una stella adatta nei pressi dello zenit, trova il fuoco ideale, riporta il tubo nella posizione precedente).

2 - Modellizzazione totalmente automatica della montatura (su 30 stelle equamente distribuite viene rilevato l'errore di puntamento e aggiornato il modello).

3 - Plate solving in doppia tecnologia: sono integrati sia PinPoint che Astrometry.net (vengono utilizzate da tutte le funzioni che implicano uno spostamento del tubo).

4 - I flat field possono essere anche ripresi ad hoc o si possono verificare i tempi ed eventualmente correggerli.

 

Tutto rose e fiori?

Naturalmente no. Problemi aperti ce n'è per tutti i gusti. I maggiori:

1 - La posizione HOME non coincide fra partenza e chiusura. Sono anni che cerco di capire perché, ma non ci sono ancora riuscito. L'errore è quasi tutto in AR e varia mediamente da una ventina a una sessantina di primi. E' stato il problema fondamentale che ha frenato la remotizzazione fino a poco tempo fa, in quanto non si può letteralmente operare senza sapere dove sta puntando esattamente il telescopio. Ogni tentativo di aggirare il problema tramite plate solving è naufragato in quanto i tempi di calcolo di Pinpoint divergono esponenzialmente man mano che l'errore iniziale cresce. Recentemente ho integrato la funzione di plate solving di Astrometry.net che usa un algoritmo completamente diverso da Pinpoint e mi ha finalmente consentito di poter fare un puntamento al primo oggetto affidabile e ripetitivo. Mi resta comunque il tarlo di un errore insito nel programma.

2 - Devo ancora escogitare qualcosa per richiamare la mia attenzione (anche quando dormo?!?) se la stella di guida viene persa o le condizioni del cielo degradano velocemente.

3 - Stesso dicasi per la funzione di puntamento automatico dei 3 target possibili: il punto debole è la stella di guida. Non sempre l'inseguitore cattura la stella come previsto; attualmente non succede nulla di pericoloso ma si perde tempo prezioso.

 

Infine non credo di aumentare ulteriormente il grado di automazione se non per qualche dettaglio o miglioria. Per esempio prossimamente monterò un tetto ad apertura elettrica che realizzerà il passo finale per la totale remotizzazione, ma non prevedo di automatizzarlo: apertura e chiusura del tetto saranno effettuate in remoto e comandate esplicitamente da me. E' troppo grande il possibile danno conseguente  a una collisione accidentale fra tetto e strumentazione! 

 


Gruppo Router

 

Colonna attrezzata

 

Colonna attrezzata


Infine il tetto...

15 gennaio: arrivato il nuovo tetto Presso Tecnosky.

22 gennaio: sorpresona di Lucio che mi ha portato il tetto a casa. A breve termine la neve ghiacciata al DL non rende fattibile il montaggio e neanche il semplice trasporto in loco.

16 Febbraio: Missione compiuta! Il tetto è montato e funzionante

20 Febbraio: Ultimi ritocchi

 

 

CONTINUA???


Torna indietro

Home