Nell’ottobre del 2005 il mio capo mi chiamo’ nel suo ufficio e mi chiese se ero interessato a sviluppare un sistema di telemetria per immagini/GPS/IMU da installare su un vettore suborbitale. Certo! rispondo io. Mai avrei immaginato quanto lavoro e sudore ci avrei messo dentro, ma spesso ci si infogna in queste cose senza sapere bene a cosa si va incontro. Quanto richiesto era di installare un sistema che permetteva di registrare e trasmettere immagini sincronizzate con una unita’ GPS e IMU (inertial measurement unit). Le immagini sarebbero state utilizzate per lo sviluppo e verifica di algoritmi per rilevare ostacoli e milgliorare la precisione della discesa durante l’atterraggio di sonde spaziali.
Il fornitore del vettore sarebbe stato il US Navy ed il supporto tecnico sarebbe stato fornito da NSROC http://www.nsroc.com/front/index.html. Il vettore un due stadi che nel giro di pochi secondi avrebbe portato il nostro payload a 120Km di altezza, 20g al lancio, altrettanti all’atterraggio. Durata del volo una decina di minuti. NSROC aveva gia’ un sistema totalmente chiavi in mano per fare il downlink di dati in formato analogico (NTSC) e digitale a 10Mbps. Quando avevo sviluppato un sistema simile installato su un pallone ad alta quota nel 2004 avevo assemblato un sistema che registrava su un videoregistratore professionale immagini da una telecamera analogica il cui SMPTE time-code era sincronizzato al GPS clock. Le accelerazioni in gioco erano troppo elevate per poter installare il registratore a bordo per cui la telecamera sarebbe stata installata sul vettore mentre registratore e ricevitore GPS sarebbe rimasto sulla terra. Questo sarebbe stato il sistema principale ma il mio capo voleva anche un sistema ad alta risoluzione.
Il grosso del lavoro sarebbe stato trovare un PC di piccole dimensioni, che avrebbe potuto lavorare nel vuoto, sopportare le sollecitazioni del lancio e dell’atterraggio, e che permetteva di collegare una telecamera digitale di alta qualita’, installarci Linux e scrivere il codice che in tempo reale acquisiva e registrava i dati dalla telecamera e dalla unita’ GPS e IMU. Tempo totale, 4 mesi. Kontron, un costruttore OEM tedesco aveva quello che faceva per me, un PC a raffreddamento conduttivo che solitamente viene installato su macchine della Polizia. Sostituisci il spinning drive con un flash drive, installa un acquisitore per telecamere CameraLink, compera la telecamera, obiettivo, cavi vari. Il SW che avevo girava sotto VxWorks ed usava pesantemente le chiamate di sistema, ma fortunatamente sono riuscito a fare il porting sotto Linux. Dopo inumerevoli peripezie che vi risparmio finalmente si tratta di andare a Wallops Flight Facility dove e’ NSROC per ATLO (integrare il sistema sul payload). Imballa circa 500Kg di ferraglia tra materiale da installare e (principalmente) materiale di supporto a terra e spediscila in Virginia.
Se vi capita di passare da quelle parti, vi consiglio di fare una visitina. Anche qui vi risparmio tutti i dettagli, ma dopo circa un paio di settimane il sistema era integrato e funzionava abbastanza bene. Prima di spedire il payload completo era necessario bilanciare il payload (un po’ come fare l’equilibratura delle ruote della vostra auto solo con un pezzo di metallo lungo circa 5 metri e dal peso di circa 400Kg) e il test delle vibrazioni (un po’ come mettere il vostro PC sugli altoparlanti del vostro stereo messo a tutto volume con un CD di heavy metal ma in questo caso si trattava di una voice coil alimentata da un amplificatore da 192KW).
Trasferisci il tutto a WSMR (White Sands Missile Range, New Mexico) per continuare ATLO (con enfasi su LO). Non ho idea della quantita’ di materiale trasferito, ma era tanta! A WSMR ho calibrato le telecamere, sistemato alcune delle cose che andavano riparate dopo i test a Wallops e passa il tempo a fare test su test di tutto il sistema e simulazioni del lancio. Arriva il giorno fatidico del lancio, sveglia alle 3 di mattina, inizio countdown alle 5am.
Qui e’ necessario aprire una parentesi. Al momento del progetto mi era stato assicurato che avrei potuto avere a disposizione una linea ethernet fino al mio PC anche sulla rampa di lancio. Incredulo, ma fiducioso, progettai e realizzai il sistema in modo che fosse controllato da terra durante le fasi di lancio tramite la linea ethernet. Una volta a WSMR ho scoperto che quando la linea ethernet della rampa non funzionava. Fortunatamente avevo preventivato questa possibilita’ e riprogrammai il PC in modo che al momento dell’accensione dell’alimentazione il sistema avrebbe iniziato le operazioni di acquisizioni in maniera automatica. Il problema pero’ era che una volta iniziate il PC avrebbe acquisito i dati, riempiendo il disco e poi si sarebbe automaticamente spento una volta terminata la sequenza. Insomma una volta acceso il PC l’operazione era senza ritorno.
Torniamo al momento del lancio. Durante la prima esercitazione della sequenza di lancio il mio PC fu acceso al momento sbagliato e dato che la line ethernet sulla rampa non funzionava fui costretto a portarmi monitor e tastiera da collegare al PC alla rampa di lancio. Immagino vi immaginiate la scena (ma vedete le foto), il sottoscritto a spippolare sulla tastiera vicino ad un razzo a due stadi pronto al lancio. Resetta il PC e prepara per la seconda esercitazione, circa due ore prima del lancio vero e proprio. Durante la seconda esercitazione l’errore si ripete. Torna alla rampa con monitor e tastiera, resetta il PC. Torna nel bunker ed inizia la procedura di lancio. Manco a dirlo lo stesso errore viene ripetuto. A questo punto non c’e’ piu’ tempo per resettare il PC, per fortuna il sistema analogico non e’ affetto e si lancia.
Nel giro di pochi minuti siamo all’apogeo circa 120Km, e nel giro di un quarto d’ora il payload e’ a terra. Cinque mesi di lavoro per un filmando di pochi minuti. Pero’ ho imparato un sacco.
Paolo
Seguono foto in cui WFF significa foto scattata a Wallops Flight Facility (foto scattate da me) e WSMR indica foto scattata a White Sands Missile Range (foto scattate dal fotografo di US Navy)
