In questo ottavo articolo della serie, affrontiamo lo sviluppo del modello di comunicazione all’interno del sistema di controllo del nostro rover planetario El Dorado. Ma, nella prima parte dell’articolo, non mancano le oramai consuete ‘note di viaggio’, che hanno questa volta un particolare significato: alcuni delle località e delle strutture qui descritte sono state devastate dal terribile terremoto/maremoto del marzo 2011.
Scorci perduti del Tohoku
La fine della stagione delle pioggie aprì la possibilità di esplorare una straordinaria dimensione della regione di Tohoku, che fino a quel momento mi era rimasta nascosta: la natura incontaminata che è possibile trovare a poche decine di minuti di treno dalla città.
Sendai, la città foresta
Uno dei cliche’ del Giappone è quello delle città caotiche e sovraaffollate, in cui i pendolari vengono spinti a forza nei treni stracarichi. E malgrado questo sia indubbiamente un aspetto del paese del Sol Levante, esiste anche una reltà meno nota, ma non per questo meno caratteristica. Il Giappone ha molte aree di periferia, dove la densità di popolazione è piu bassa, e dove è possibile trovare paesaggi stupendi, natura incontaminata e fauna selvatica. La città di Sendai in questo senso presenta una ottima sintesi delle due realtà. Soprannominata “la città foresta”, Sendai è attraversata da stradoni alberati, come la bellissima Aoba Dori.
Subito fuori dal circuito cittadino, una distesa di vegetazione si perde a vista d’occhio. Questa vegetazione conserva in molti tratti la sua natura originaria, nella quale è possible trovare una fauna composta da uccelli, insetti, orsi e decine di altre speci animali.
Grazie ai miei amici dell’università di Tohoku, ho avuto modo di esplorare queste zone, e di scoprire i tesori nascosti della regione. A marzo di quest’anno, come i lettori sapranno, la regione di Tohoku è stata colpita da un devastante terremoto e dal conseguente tsunami. Le zone costiere sono state severamente interessate, con danni enormi a persone e cose. Quella che segue è una rassegna di alcune di queste località ferite.
Shiogama
Shiogama è una città situata a 15 chilometri da Sendai, ed è considerata una delle piu belle città costiere del Giappone. L’economia di Shiogama è basata sulla pesca, ed è infatti sede di un caratteristico mercato del pesce.
Shiogama presenta la maggior quantià di ristoranti di sushi per chilometro quadrato di tutto il Giapone, e lì si può mangiare quello che viene considerato il miglior sushi del giappone. La località di Shiogama è il maggior produttore nazionale di tonno, che è disponibile in diverse varietà, come il pregiatissimo blue fin tuna, o tonno dalla pinna azzurra.
La città ospita il tempio di Jinja, il piu importante tempio shintoista della regione, situato in cima a una collina che domina la città. I templi shinto sono dei capolavori di architettura, caratterizzati dal colore rosso degli edifici e dagli splendidi giardini.
In Giappone coesistono due tradizioni religiose: quella buddhista e quella shinto. La natura pragmatica del popolo Giapponese in tema di fede religiosa ha favorito lo sviluppo di queste due religioni di natura sincretica, la cui pratica non richiede nè una professione di fede, nè tantomento l’abiura di altri credi. In Giappone, gli eventi legati alla vita (nascita, matrimonio ma anche promozione sul lavoro, esito negli esami…) vengono scanditi da rituali shinto, mentre tuttli gli aspetti della spirituali legati alla morte (funerali, culto degli antentati…) vengono gestiti sotto rituale buddhista.
I templi shinto sono spesso frequentati da giovani in cerca di lavoro, coppie alla vigilia del matrimonio, commessi viaggiatori che benedicono l’auto su cui percorrono tanti chilometri, studenti in vista di un esame e, piu in generale, persone che vogliono avverare un desiderio. Ogni tempio è dedicato agli spiriti del luogo: per chiedere una concessione, è sufficiente presentarsi all’altare, inchinarsi, gettare una moneta nell’apposita cassetta, suonare la campana per richiamare l’attenzione, battere le mani due volte e concentrarsi sulla richiesta.
È possibile anche fare un’offerta e prelevare un biglietto, con su scritta la fortuna. Se cio che leggiamo nel biglietto non ci piace, possiamo lasciarlo su un apposito pannello, affichè gli dei del luogo si prendano cura della nostra buona sorte.
Matsushima
Matsushima è una località costiera, che comprende 260 piccole isole (shima) coperte di pini (matsu). Dalla costa è possibile prendere un barcone che attraversa l’area, attorno alle isole piu importanti.
L’isola di Ojima era collegata alla terraferma dal Togetsukyo Bridge, un ponte rosso lungo piu di 20 metri che è andato perduto in seguito al terremoto.
All’interno dell’isola, si sviluppava una rete di stupendi viali alberati, intervallati da statue e costruzioni in legno. Niente di questo è sopravvissuto, solo il ricordo resta.
Yama-dera
Yama-dera è un tempio buddhista situato in cima ad una collina ripidissima, a circa 60 chilometri da Sendai. I templi antichi Giapponesi hanno una particolarità che li distingue dai monumenti antichi occidentali. Come per tanti edifici storici, la loro origine è antichissima: molti risalgono ai primi secoli dopo Cristo. Il tempio di Yamadera, ad esempio, risale all’860, ed è pertanto più antico del nucleo originale della Basilica di San Marco a Venezia. Ma a differenza delle nostre chiese di pietra, i templi Giapponesi sono fatti di legno e richiedono una costante manutenzione, con la sostituzione dei pezzi che eventualmente vanno deteriorandosi per il passare del tempo. Pertanto l’edificio che vediamo oggi non è “esattamente” lo stesso di mille e quattrocento anni fa: il disegno, le decorazioni, la collocazione dei vari elementi e le tecniche con sui sono realizzati sono esattamente quelli antichi, ma il materiale con cui è realizzato risale a tempi ben più recenti. L’odore di legno che caratterizza questi edifici, antichi e nuovi allo stesso tempo come molte altre cose in Giappone, unito all’aroma dell’incenso è un elemento estremamente suggestivo, che riflette un tipo di spiritualità differente da quello dell’architettura cristiana.
Per accedere alla cima del tempio, è necessario percorrere a piedi una scala composta da 1015 scalini, il tutto sotto il sole battente e il caldo soffocante dell’estate giapponese. Alla base della collina, un cartello avverte che i desideri terreni che ci bloccano dall’illuminazione scompaiono via via che percorriamo i gradini che portano alla cima. Un migliaio di scalini non sembrano molti, ma provate a pensare che un monumento come la Torre di Pisa ne conta apena 296, e vi renderete conto che raggiungere l’illuminazione richiede uno sforzo non banale, dopotutto.
Ma la vista che si gode dalla cima della collina ripaga della fatica spesa. Il magnifico paesaggio, l’architettura del tempio e i colori della vegetazione sono una visione idimenticabile.
Il poeta Matsuo Basho, in visita in questa regione verso la fine del 1600, scrisse un famoso haiku: “Silenzio, e penetrando nelle rocce, il pianto della cicala.” Il significato di questo Haiku diventa presto evidente nei primi minuti appena scesi dal treno. La cicala è un grosso insetto: ci sono esemplari che raggiungono facilmente i 5-6 cm. Durante l’estate, il maschio della cicala produce un suono stridente, che viene amplificato enormemente dalla risonanza di alcune membrane poste nell’esocheletro. Le cicale sono in grado di sentire questo suono, e di entrare in risonanza tra di loro, portando il volume oltre i 120 decibel a breve distanza, una soglia vicina a quella di un concerto degli Who, la più rumorosa rock band della storia.
Queste visite nella natura della regione di Tohoku hanno aiutato non poco a gestire lo stress legato ai ritmi serrati di lavoro all’università di Tohoku, un lavoro che nel frattempo stava continuando a produrre i suoi frutti.
Il modello di comunicazione
Torniamo adesso all’illustrazione dell’architettura del mio progetto: come premesso, in questo articolo parlo sostanzialmente del modello di comunicazione, poiche’ occorre ricordare che, nel caso di un rover planetario, siamo in presenza di una serie di “difficoltà” e parametri da tenere in considerazione, legati anche alla distanza tra stazione a terra e robot a distanze siderali.
Prima ancora di iniziare lo sviluppo dello strato di comunicazione dell’architettura di sistema, quindi, ho definito un modello di comunicazione. El Dorado e il PC che agisce da ground station sono i due elementi terminali del sistema, e al momento dello sviluppo, non si sapeva molto sui parametri operativi della connessione Terra-Luna che sarebbe stato disponibile nella missione finale.
L’unico parametro noto è ritardo di comunicazione: un ritardo di circa 2.5 secondi tra l’invio di un comando e la ricezione del feedback. Il collegamento fisico tra El Dorado e la ground station era dato da una connessione Wi-Fi da 10 mb/s, e il protocollo era un TCP/IP standard. Non essendo state formulate ulteriori restrizioni, ho documentato le caratteristiche prestazionali del TCP/IP: comunicazione punto a punto affidabile, e assenza di garanzie sulla qualità del servizio. Il TCP/IP è un protocollo affidabile in quanto garantisce la consegna, la correttezza e l’ordine dei messaggi. Il TCP/IP supporta la creazione di un canale di comunicazione punto a punto, che trasmette uno stream di byte. Se la connessione cade, il programma utente sa con certezza quali informazioni hanno raggiunto l’host remoto e quali no. Il TCP/IP non garantisce la qualità del servizio (Quality of Service, QoS), il che vuol dire che la prestazione del canale non è conosciuta in anticipo e potrebbe cambiare in ogni momento. Il protocollo TCP/IP presenta ulteriori caratteristiche, come l’indirizzamento basato su protocollo IP, e la risoluzione dei nomi basata su Domain Name Service (DNS), che sono probabilmente inutili o ridondanti nel caso di studio in oggetto. Lo sviluppo di un protocollo di comunicazione punto a punto a livello data link, più adatto alla circostanza, è un compito che esulava dagli scopi della mia ricerca.
Un linguaggio formale
Il protocollo usato da Kaizen 2010 è asimmetrico, dato che il flusso di informazioni è differente nelle due direzioni. È indipendente dall’architettura, dato che utilizza caratteri ASCII e una rappresentazione dei dati numerici indipendente dall’architettura sottostante. È consistente, dato che il suo stato presente, nonchè l’insieme dei possibili stati successivi, sono formalmente definiti in ogni momento. È human readable, dato che i messaggi possono essere letti e capiti da un essere umano. È auto esplanatorio, in modo da rendere piu semplice l’analisi e la diagnostica. È caratterizzato nel tempo, dato che ogni messaggio riporta il timestamp relativo al momento della emissione.
Per rispettare questi requisiti, ho definito il protocollo come un linguaggio formale. Un linguaggio formale è un modello algebrico, caratterizzato da un alfabeto, l’insieme dei messaggi ben formati, e da un insieme di regole di transizione, le regole di composizione. L’insieme dei messaggi ben formati è a sua volta un linguaggio formale, che può essere definito attraverso una grammatica esente da contesto (Context Free Grammar). Data la semplicità del protocollo, ho preferito presentare l’insieme dei messaggi ben formati in maniera informale.
Un linguaggio formale è un modello matematico che denota un insieme di stringhe che rispettano un insieme di regole di composizione. In questo caso, ho creato le regole attraverso un automa a stati finiti (Finite State Automaton), un formalismo algebrico che si presta ad una rappresentazione grafica estremamente intutiva. L’automa a stati finiti è il formalismo di calcolo piu utilizzato in automazione e controllo perchè presenta una proprietà matematica estremamente importante: è decidibile. “Decidibile” significa che, per ogni input, è possibile verificare staticamente il corrispondente output. Formalismi di calcolo piu complessi, come quelli che modellano il funzionamento di un calcolatore elettronico, non presentano questa proprietà: per questo motivo, il testing statico del software è un problema impossibile da risolvere (indecidibile), che va “aggirato” con alcune strategie atte a limitare in maniera controllata l’esplosione combinatoria.
Protocollo lato rover
Il protocollo utilizzato dal rover per descrivere il proprio stato è definito dall’insieme di messaggi ben formati presentati nel listato poco sotto e dalle regole di composizione descritte dall’automa a stati finiti di figura 11. Ogni messaggio è costruito attorno ad una struttura portante, denotata da parole in maiuscolo, come TIMESTAMP o ITERATION, e da un insieme di variabili rappresentato da lettere minuscole in grassetto, tipo x o y. Le variabili sono valori numerici che utilizzano il carattere “.” come punto decimale (esempio: “2343.665”). La conversione dei valori viene demandata alle routine standard di C e Java, quelle che vengono applicate usando la printf() in C e la System.out.printf() in Java. Ogni messaggio è marcato da un numero di TIMESTAMP, che viene preso dall’orologio di sistema. I messaggi che trasportano dati odometrici sono caratterizzati da un numero di iterazione, che permette al ricevente di distinguere misurazioni prese in momenti differenti. Anche i dati che costituiscono una rilevazione della mappa di rilievo sono marcati da un numero di versione, in modo da distinguere misurazioni successive. Il seguente listato mostra l’insieme dei messaggi ben formati sul lato rover: le variabili sono le lettere minuscole in grassetto:
TELEMETRY ATTITUDE_AND_POSITON TIMESTAMP t ITERATION i X x Y y Z z ROLL r PITCH p YAW y TELEMETRY ODOMETRY_STEER TIMESTAMP t ITERATION i WHEEL1 w1 WHEEL2 w2 WHEEL3 w3 WHEEL4 w4 TELEMETRY ODOMETRY_SPEED TIMESTAMP t ITERATION i WHEEL1 w1 WHEEL2 w2 WHEEL3 w3 WHEEL4 w4 TELEMETRY DEM_UPDATE_START TIMESTAMP t DEM_NUM n DEM_X x DEM_Y y DEM_Z z DEM_ROLL r DEM_PITCH p DEM_YAW y TELEMETRY DEM_POINT TIMESTAMP t DEM_NUM n X x Y y Z z DEM_UPDATE_END TIMESTAMP t DEM_NUM n
La sequenza di messaggi segue le regole descritte dalla macchina a stati finiti di figura 16. Quando il rover si trova in stato 1, puo dare l’avvio ad un ciclo di trasmissione di dati telemetrici. Questo ciclo è composto da un messaggio di tipo ATTITUDE_AND_POSITION, seguito da un ODOMETRY_STEEER e un ODOMETRY_SPEED. Dallo stato 1, il rover può anche iniziare la trasmissione di una mappa di rilievo. In questo caso, avremo un messaggio DEM_UPDATE_START, che contiene le coordinate in cui si trova il rover al momento della rilevazione. A questo messaggio segue un numero arbitrario di messaggi DEM_POINT, ciascuno dei quali contiene le coordinate x, y e z di un rilievo. Per ridurre la quantità di dati trasmessa, vengono inviati solamente i punti che presentano una elevazione diversa da zero. La trasmissioni di dati termina con un messaggio DEM_UPDATE_END.
Ecco un esempio di come appaiono i messaggi inviati dal rover alla ground station:
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY ATTITUDE_AND_POSITON TIMESTAMP 290044 ITERATION 0 X 0.000000 Y
0.000000 Z -0.000000 ROLL 2.035689 PITCH 2.355626 YAW 6.878107
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY ODOMETRY_STEER TIMESTAMP 290044 ITERATION 0 WHEEL1 0.129406
WHEEL2 -0.119861 WHEEL3 -0.172940 WHEEL4 -0.118116
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY ODOMETRY_SPEED TIMESTAMP 290044 ITERATION 0 WHEEL1 0.000000
WHEEL2 0.000000 WHEEL3 0.000000 WHEEL4 0.000000
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY DEM_UPDATE_START TIMESTAMP 290054 DEM_NUM 3 DEM_X 0.000000 DEM_Y
0.000000 DEM_Z -0.000000 DEM_ROLL 2.036293 DEM_PITCH 2.354609 DEM_YAW 6.874767
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY DEM_POINT TIMESTAMP 290055 DEM_NUM 3 X 244 Y 244 Z 0.000000
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY DEM_POINT TIMESTAMP 290055 DEM_NUM 3 X 244 Y 245 Z 0.000000
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY DEM_POINT TIMESTAMP 290055 DEM_NUM 3 X 244 Y 246 Z 0.000000
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY DEM_POINT TIMESTAMP 290055 DEM_NUM 3 X 244 Y 247 Z 0.000000
[…]
[…]
[…]
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY DEM_POINT TIMESTAMP 290132 DEM_NUM 3 X 288 Y 247 Z 1.288413
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY DEM_POINT TIMESTAMP 290132 DEM_NUM 3 X 288 Y 248 Z 1.292123
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY DEM_POINT TIMESTAMP 290132 DEM_NUM 3 X 288 Y 249 Z 1.291718
Sent:Thu_Jan_01_09:04:50_JST_1970-Processed:Wed_Aug_04_14:04:42_JST_2010
TELEMETRY DEM_UPDATE_END TIMESTAMP 290133 DEM_NUM 3
Lato ground station
Il protocollo utilizzato dalla ground station per trasmettere i comandi al rover è caratterizzato dai messaggi ben formati elencati nel listato riportato poco sotto, e dalla macchina a stati di figura 12. Quando la macchina si trova in stato 1, il rover è fermo. Se riceve un comando in real-time, si muove nello stato 2, dove codifica ed esegue qualunque sequenza di comandi real-time. In caso di assenza prolungata di messaggi (timeout), l’automa torna in stato 1.
Un percorso viene comunicato mediante l’invio di un messaggio STORED_SEQUENCE_START, seguito da un elenco di messaggi STORED_SEQUENCE_STEP, ciascuno dei quali specifica una coppia di coordinate. Un messaggio STORED_ SEQUENCE_END conclude l’invio della sequenza. Per avviare il rover è necessario a questo punto inviare un messaggio STORED_SEQUENCE_PLAY; l’esecuzione può essere interrotta con il messaggio PANIC. Nel listato di seguito mostriamo dei messaggi ben formati, lato ground station. Le variabili sono rappresentate da caratteri minuscoli in grassetto.
COMMAND PANIC TIMESTAMP t COMMAND RT_FORWARD TIMESTAMP t COMMAND RT_BACKWARD TIMESTAMP t COMMAND RT_TURN_RIGHT TIMESTAMP t COMMAND RT_TURN_LEFT TIMESTAMP t COMMAND STORED_SEQUENCE_START TIMESTAMP t COMMAND STORED_SEQUENCE_STEP TIMESTAMP t TARGET_X x TARGET_Y y COMMAND STORED_SEQUENCE_END TIMESTAMP t COMMAND STORED_SEQUENCE_PLAY TIMESTAMP t
Ecco come compare il file di log delle comunicazioni lato ground station:
Sent:Wed_Aug_04_12:58:29_JST_2010 COMMAND RT_FORWARD TIMESTAMP 1280894309756 Sent:Wed_Aug_04_12:58:30_JST_2010 COMMAND RT_FORWARD TIMESTAMP 1280894310473 Sent:Wed_Aug_04_12:58:34_JST_2010 COMMAND RT_TURN_RIGHT TIMESTAMP 1280894314094 Sent:Wed_Aug_04_12:58:34_JST_2010 COMMAND RT_TURN_RIGHT TIMESTAMP 1280894314645 Sent:Wed_Aug_04_12:58:35_JST_2010 COMMAND RT_TURN_RIGHT TIMESTAMP 1280894315063 Sent:Wed_Aug_04_12:58:35_JST_2010 COMMAND RT_TURN_RIGHT TIMESTAMP 1280894315480 Sent:Wed_Aug_04_12:58:35_JST_2010 COMMAND RT_TURN_RIGHT TIMESTAMP 1280894315897 […] […] […] Sent:Wed_Aug_04_12:58:45_JST_2010 COMMAND RT_TURN_LEFT TIMESTAMP 1280894325806 Sent:Wed_Aug_04_12:58:47_JST_2010 COMMAND RT_TURN_LEFT TIMESTAMP 1280894327657 Sent:Wed_Aug_04_12:58:49_JST_2010 COMMAND RT_TURN_LEFT TIMESTAMP 1280894329285 Sent:Wed_Aug_04_12:58:49_JST_2010 COMMAND RT_TURN_LEFT TIMESTAMP 1280894329827
Considerazioni sull’ottimizzazione della larghezza di banda
Nonostante il fatto che l’ottimizzazione della larghezza di banda non fosse un requisito del mio progetto, ho presentato alcune considerazioni su come adattare la mia proposta a tali requisiti, nel momento in cui questi verranno pubblicati.
Ho deciso di progettare protocollo in ASCII, invece di usare un protocollo binario, per ottenere un linguaggio human readable e indipendente dalla macchina. L’uso di un linguaggio formale garantisce robustezza e consistenza. Lo svantaggio del formato corrente è il fatto che il linguaggio risultante è piuttosto ridondante: ogni messaggio ben formato comprende una struttura portante composta da diverse parole costanti, come “COMMAND”, “TELEMETRY”, “TIMESTAMP” e così via. La rappresentazione testuale dei numerali consuma a sua volta molto piu spazio di una rappresentazione binaria: il numero “57839376984232343.2462643”, per fare un esempio, consuma 25 byte se espresso in carattery ASCII, mentre ne occupa solo 4 se espresso in floating point 32 bit. Si pensi a quanti numeri vengono trasmessi durante l’invio di una mappa di rilievo.
Velocità di trasmissione
Nella comunicazione di rete, i tempi di latenza dovuti alla distanza fisica tra i due host (e alla conseguente lunghezza dei cavi in caso di comunicazione terrestre) sono maggiori di alcuni ordini di grandezza rispetto ai tempi che trascorrono tra l’invio di due caratteri successivi. Nell’ambiente di rete che utilizzavo all’università di Tohoku, per esempio, un pacchetto impiegava circa 10ms a raggiungere la destinazione, indipendentemente dal contenuto. Considerando una larghezza di banda di 10 mb/s, è possibile vedere che ci vuole circa lo stesso tempo a ricevere un pacchetto da 1 byte (10 ms) o uno da 10 kb (10ms più un delta molto minore di 10 ms). Il volume di dati scambiato da questa applicazione è, alla fin dei conti, estremamente ridotto, e non ha senso, a questo livello del progetto, scartare la human readability in favore di una ulteriore riduzione del volume dati trasmesso.
Nell’informatica moderna, ad esempio, il successo delle web application è legato in gran parte al fatto che adottano un protocollo di comunicazione a caratteri (HTTP) e un formato di dati basato sull’XML, che è facile da processare con strumenti automatici (SAX/DOM) e human readable al tempo stesso. Il fatto che messaggi XML siano fino a 100 volte piu voluminosi di protocolli binari equivalenti non ha conseguenze rilevanti sulla prestazione del canale.
Flessibilità e adattamento
Ma cosa si deve fare se si desidera transitare il protocollo su un contesto operativo caratterizzato da parametri differenti? La prima cosa da fare è procedere ad un assessment dell’ambiente operativo, in modo da verificarne i requisiti e quantificare il delta prestazionale. L’ottimizzazione può produrre risultati disastrosi, se si ottimizzano i parametri sbagliati. Il volume di dati trasmessi dal protocollo può essere ridotto applicando una o più delle seguenti strategie:
- La frequenza di trasmissione è il primo parametro che influenza il volume di dati trasmesso. Si può regolare la frequenza di refresh (numero di sample per unità di tempo), in modo da portarla a un livello che permetta di monitorare lo stato senza saturare il canale.
- Letture duplicate possono essere scartate. Al momento, il rover invia una lettura al secondo anche quando il rover è fermo e niente attorno è cambiato Quando il rover è fermo, le letture successive possono essere ridotte o scartate (sulla base dell’assunto, tutt’altro che banale, che sulla Luna non ci sia niente che si muova a parte il rover…)
- La telemetria può essere combinata all’interno di messaggi filler e keep-alive, ossia quei messaggi di servizio che vengono utilizzati da un protocollo di data link per assicurare che il canale sia aperto e operativo.
- Un linguaggio formale denota una struttura algebrica, che può essere trasformata in una forma equivalente piu compatta attraverso un un isomorfismo.
- I messaggi di testo possono essere compressi facilmente fino al 90% con un algoritmo di compressione standard come lo Lempel-Ziv-Welch. La compressione di dati può essere applicata in maniera trasparente a entrambi gli estremi della comunicazione, in modo da preservare il formato corrente del protocollo.
- Una compressione sensibile al contesto, che tenga in considerazione le particolarità del contenuto, può portare ad una riduzione del 500% o maggiore. Per fare un esempio, le informazioni numeriche che vengono trasportate da questo protocollo assumono solamente un sottoinsieme di tutti i possibili valori di una variabile a virgola mobile a doppia precisione, a seconda della sensibilità del sensore utilizzato e delle caratteristiche geologiche del terreno da campionare. Una analisi dei dati può fornire importanti indicazioni su come procedere per ridurre il volume dei dati senza perdere informazioni.
Conclusioni
E anche per questo mese, la panoramica sull’architettura di Kaizen 2010 è finita. Il mese prossimo vedremo alcune considerazioni sul lavoro di sviluppo, e cominceremo a descrivere l’architettura complessiva del sistema.
Nel frattempo, però, segnalo ai lettori interessati una iniziativa legata alla mia esperienza nell’ambito delle tematiche aerospaziali. Si tratta di una rivista [3], lo Space Safety Magazine, presente anche su Facebook [1], edita dalla International Association for the Advancement of Space Safety (IAASS) [2], che si occupa dei temi relativi alla sicurezza nelle attività aerospaziali. Recentemente, ad esempio, Space Safety Magazine si è occupato direttamente del rientro nell’atmosfera terrestre del satellite UARS, monitorando in tempo reale i dati inerenti la caduta.
Riferimenti
[1] Space Safety Magazine su Facebook
https://www.facebook.com/spacesafetymagazine
[2] IAASS
[3] La pagina ufficiale di Space Safety Magazine
http://www.spacesafetymagazine.com/
Andrea Gini è un professionista del settore aerospaziale, un consulente IT e un giornalista scientifico. La collaborazione con MokaByte, iniziata nel lontano 1999, è stata l‘unica costante in un percorso professionale che lo ha portato dalla fotografia professionale alla scienza spaziale. Attualmente lavora al Payload Safety Review Panel presso il centro di sviluppo tecnologico ESTEC dell‘Agenzia Spaziale Europea (ESA) a Noordwijk, nei Paesi Bassi. Andrea è anche fondatore ed editore responsabile dello Space Safety Magazine, un giornale specializzato pubblicato congiuntamente dall‘International Association for Advancement in Space Safety (IAASS) e dalla International Space Safety Foundation (ISSF). Nella IAASS, Andrea ricopre il ruolo di Chairman dell‘Information and Communication Committee, ed è responsabile dello sviluppo della strategia di comunicazione dell‘associazione. Nel tempo libero, ama stare con le figlie, cucinare, viaggiare, suonare con la chitarra, studiare le lingue e la storia contemporanea, abbracciare il suo cane e ascoltare la musica degli Who, dei Led Zeppelin, di Rihanna, 50 Cents, Eminem, Lady Gaga e Britney Spears.