Viaggio a El Dorado: alla scoperta della robotica spaziale in Giappone

XI parte: Apparenza e realtàdi

Una ulteriore digressione sul rapporto tra cibo e cultura e una ripresa dell'analisi del sistema di controllo del rover panetario, lato Terra, costituiscono gli argomenti di questo articolo di una lunga serie che si avvicina alla conclusione.

Ancora sul cibo

Sarà che il cibo è uno degli elementi costituenti della cultura di un popolo, e per noi italiani questo è sicuramente vero, ma una delle impressioni più vivide del mio soggiorno giapponese è stato il cibo. Già in passato ho descritto come il cibo giapponese sia caratterizzato dalla semplicità degli ingredienti, spesso crudi, e dalla cura nella presentazione. Il gusto per il cibo semplice mi ha portato più di una volta al minimalismo alimentare: una vaschetta di pesce crudo presa al supermercato, consumata al parco utilizzando un sushi-kit portatile composto da una ciotolina, un barattolo di salsa di soya, un tubetto di wasabi e bacchette usa e getta.

Figura 1 - Un caratteristico noodle bar Giapponese.

Figura 1 - Un caratteristico noodle bar Giapponese.

Il Giappone è anche un paese con una grossa cultura di cibo espresso. Ad ogni angolo della città è possibile incontrare piccoli ristoranti che servono piatti belli e gustosi in pochi minuti. Il piatto espresso più caratteristico del Giappone sono i "noodles", gli spaghetti giapponesi. In Europa, i "noodles" sono sinonimo di cucina wok thailandese, spesso unta e malsana. I noodles giapponesi sono invece piatti saporiti, leggeri ed estremamente salutari. Esistono principalmente tre varietà di noodle in Giappone: Ramen, Soba e Udon. I ramen sono spaghettini di riso sottili, serviti con una minestra calda a base di verdure, carne di maiale o pesce. La soba è una pasta di grano saraceno, simile in spessore e consistenza alla classica pasta italiana numero 8, che viene servita per lo più fredda, accompagnata da tempura e da una zuppa in cui intingere gli spaghetti. Gli udon sono spaghetti grossi, simili ai nostri bigoli, che vengono serviti sia in piatti caldi che freddi. Gli spaghetti freddi, un'idea poco attraente per un italiano, meriterebbero un capitolo a parte: provate ad affrontare per qualche settimana il clima caldo-umido dell'estate giapponese, e vi garantisco che la cosa comincerà a rivelare il suo senso.

Visita ad un Noodle Bar

La tipica "spaghetteria" giapponese è un locale piccolo, dal soffitto basso, in cui ci si siede su larghi tavoli comuni, o sul bancone di fronte alla cucina. Ogni ristorante presenta una certa scelta di piatti, dalle 3 alle 20 portate, e alcune variazioni.

Figura 2 - Preparazione di una ciotola di ramen.

Figura 2 - Preparazione di una ciotola di ramen.

Anche nella velocità, i Giapponesi seguono un rituale e una tradizione che ha radici antiche: dopo aver effettuato l'ordine, è possibile osservare il cuoco mentre, velocissimo, cuoce gli spaghetti al dente, aggiunge il brodo, prepara la guarnizione e serve il piatto. Normalmente non occorre aspettare più di 10 minuti per essere serviti.

Figura 3 - Un tipico esempio di ramen e relative guarnizioni.

Figura 3 - Un tipico esempio di ramen e relative guarnizioni.

Niente pizza: solo Khlav Kalash!

Al contrario del tipico fast food americano, la cucina espressa giapponese è estremamente leggera e sana. Sembrerebbe insomma che in Giappone sia impossibile sprofondare nel bassifondismo alimentare che caratterizza altre città del mondo. Ma siamo sicuri che sia proprio così?

Figura 4 - Homer Simpson alle prese con Khlav Kalash e succo di granchio.

Figura 4 - Homer Simpson alle prese con Khlav Kalash e succo di granchio.

Personalmente sono un amante della cucina semplice e sana, ricca di frutta e verdura e a basso contenuto di grassi e proteine animali. Ma quando mi trovo all'estero, il senso di libertà mi porta spesso a cadere vittima della fascinazione del junk food. Per un certo periodo ho girato tutta l'Europa, provando ovunque il peggio della cucina locale. Una specie di turismo gastronomico, solamente al contrario. Ricordo un episodio dei Simpsons in cui Homer si vede offrire da un uomo dal vago aspetto mediorientale il Khlav Kalash, una specialità gastronomica di dubbia provenienza, dall'aspetto disgustoso e dal gusto orribile, servita con succo di granchio. Il Khlav Kalash è l'archetipo del junk food etnico: cibo caratterizzato da un aspetto orribile, un gusto sovra-speziato e da una preparazione in condizioni igeniche da guerra batteriologica. Cose tipo il Kebab moderno e globalizzato, con le sue salse e il suo misterioso contenuto, o il Lahmacun, detto anche Turkish Pizza, in maniera da offendere in un colpo solo tanto la tradizione gastronomica turca che quella Italiana.

Figura 5 - Condizioni... igieniche di un "ristorante" di Okonomiyaki.

Figura 5 - Condizioni... igieniche di un "ristorante" di Okonomiyaki.

Anche in questo senso il Giappone non ha rivali, al punto di assicurarsi la palma per il peggior Khlav Kalash che abbia mai provato: l'Okonomiyaki. L'Okonomiyaki è una via di mezzo tra un'omelette e un pancake a base di foglie di cavolo, spaghetti e un impasto formato da acqua, farina e uova. Preparato in locali dalle condizioni igeniche sospette su una piastra Teppan che non viene mai pulita, l'Okonomiyaki può essere guarnito con qualunque cosa: carne, pesce, uova, verdure, seppia in polvere, maionese e una salsa allo zenzero. Il tutto viene spinto di fronte al cliente, che poi lo mangia utilizzando una apposita spatolina.

Figura 6 - La preparazione dell'Okonomiyaki.

Figura 6 - La preparazione dell'Okonomiyaki.

L'Okonomiyaki è il trionfo della sofisticazione alimentare, un cibo in grado di produrre intolleranze non documentate nella letteratura medica. È senza dubbio qualcosa da provare, un'esperienza da ricordare e da dimenticare allo stesso tempo, un'altra prova dell'unicità del Paese del Sol Levante.

Figura 7 - Un "succulento" Okonomiyaki.

Figura 7 - Un "succulento" Okonomiyaki.

 

L'architettura di sistema, lato Ground Station

Tra le gioie e i dolori della cucina Giapponese espressa, mi avvicinavo inesorabilmente al momento della consegna del mio lavoro. Dopo aver introdotto il mese scorso l'architettura di sistema del rover, passerò ora a illustrare quella della ground station, di cui abbiamo già fatto accenno in altre parti di questa serie.

Shikaku (in Giapponese, "visione") è un'interfaccia utente per PC, progettata secondo un'architettura Model View Controller, schema che i lettori di MokaByte ben conoscono. Un sistema di questo tipo è suddiviso in tre componenti software, chiamati per l'appunto Model, View e Controller. La"vista" è il componente che mostra i dati a schermo. Lo stato del sistema è contenuto nel "modello",che è una struttura dati osservabile. L'utente manipola gli elementi grafici dell'interfaccia attraverso il "controller", che è la logica che codifica le azioni che l'utente esegue con mouse, tastera, touch screen, e le traduce in modifiche al modello, e tali modifiche vengono alla fine riflesse nella vista.

Figura 8 - Architettura basata sul Model View Controller.

Figura 8 - Architettura basata sul Model View Controller.

In un ambiente remoto, una parte cruciale dei dati del modello proviene da un sito remoto. Alcune delle azioni del controller devono essere inoltrate al sito remoto, dove generano un cambiamento di stato. Tale cambiamento viene poi rispedito al modello locale, dove causa un aggiornamento della vista. Il model di Shikaku viene sincronizzato con quello del rover grazie a un apposito componente che agisce da mediatore, denominato Heiwa Taishi. Heiwa Taishi è una parola giapponese che significa "ambasciatore di pace", un altro esempio di "engrish" al contrario.

Figura 9 - Architettura Model View Controller distribuita.

Figura 9 - Architettura Model View Controller distribuita.

View e Controller sono state già descritte nella settima parte di questa serie, pertanto dovrebbe essere chiaro che i componenti grafici sono condizionati dal modello, e che tutte le interazioni utente sono gestite dal controller. Il Model di Shikaku è alimentato da due sorgenti: El Dorado e le interazioni dell'utente. Il rover fornisce i dati di telemetria (posizione, orientamento, odometria e mappa di rilievo). Shikaku registra le informazioni e crea un modello dati più completo, che include un repository di tutte le informazioni di posizione e orientamento ricevute, e una mappa di rilievo locale, composta mettendo assieme tutte le mappe di rilievo locali ricevute con relativi dati di posizionamento. Il modello contiene anche le informazioni relative al percorso che l'operatore disegna sullo schermo. Il percorso è gestito come informazione locale: durante la pianificazione, nessuna informazione di percorso viene infatti inviata al rover.

Il modello contiene anche informazioni che vengono generate e consumate localmente, come la posizione della telecamera virtuale che influenza la prospettiva della rappresentazione grafica della mappa di rilievo. Il controller di Shikaku permette all'utente di alterare le proprietà visuali della mappa di rilievo a schermo con un click & drag: questo cambiamento di stato, che ha valore solo nel dominio applicativo di Shikaku, viene trattato localmente, e non viene mai inviato al rover.

Heiwa-Taishi

Heiwa-Taishi è un sistema di componenti, costruito secondo il modello client-server, che permette a El Dorado e Shikaku di scambiare informazioni di stato e direttive di moto. Prevedibilmente, El Dorado agisce da server, e Shikaku da client. Heiwa-Taishi è composto da due componenti fratelli, situati uno nella ground station e l'altro nel rover (figura 10). I due componenti sono stati sviluppati in linguaggi di programmazione differenti, C sul lato rover e Java sul lato ground station. Configurazioni software di questo tipo sono comuni in architetture a componenti distribuite, dato che spesso le piattaforme ospiti presentano requisiti che richiedono linguaggi o sistemi operativi differenti. La comunicazione tra i due componenti viene gestita con il protocollo descritto nell'ottavo articolo di questa serie.

Figura 10 - Architettura di alto livello di Heiwa-Taishi.

Figura 10 - Architettura di alto livello di Heiwa-Taishi.

I due componenti condividono una struttura simile (figura 11). Entrambi contengono tre processi concorrenti: Connector, Sender e Receiver. Connector è un processo che stabilisce la connessione con la controparte e avvia il Sender e il Receiver, in maniera da gestire in modo concorrente le due direzioni della comunicazione. Se la connessione si interrompe, Connector tenta una riconnessione a intervalli pre definiti. La comunicazione entrante è inviata ad un interprete che decodifica il comando e lo inoltra al processo host (System sul lato rover, Model sul lato ground station). La comunicazione in uscita inizia con una richiesta al subcomponente Command Dispatcher, che impachetta il comando in un messaggio ben formato e lo invia attraverso la rete.

Figura 11 - Architettura a componenti di Heiwa-Taishi.

Figura 11 - Architettura a componenti di Heiwa-Taishi.

La maggior differenza tra le due versioni di Heiwa-Taishi è il modello di interazione del command dispatcher. Sul lato ground station, Heiwa-Taishi è guidato dagli eventi. Il command dispatcher reagisce agli input dell'utente, che possono avvenire in qualunque momento. Se l'utente non compie nessuna azione, il Sender lato ground station rimane in blocking state. Sul lato rover, il Sender è un processo real time che interroga la Shared Memory ogni secondo per raccogliere i dati di telemetria. Ogni tre secondi viene inviata una nuova lettura di odometria; ogni tre secondi una nuova mappa di rilievo. Il ritardo può in linea di principio essere aumentato o diminuito per adattarsi ai requisiti di larghezza di banda

Il ricevitore lato ground station reagisce al ricevimento di dati, e rimane in uno stato di blocco durante le attese. La combinazione ricevitore-interprete lato rover è un processo non bloccante in tempo reale. Questo requisito è necessario perchè i comandi inviati al rover sono tempo-dipendenti, e la loro esecuzione deve essere eseguita in rispetto del tempo reale. Il comportamento del ricevitore lato rover è modellato secondo la macchina a stati finiti di Figura 12. Ogni 200 millisecondi, la rete viene interrogata per verificare la presenza di un nuovo messaggio Il messaggio può recapitare informazioni di percorso, direttive di moto real-time o nessuna informazione. A seconda del messaggio ricevuto, l'interprete va in uno stato differente.

Figura 12 - Macchina a stati finiti dell'interprete dei comandi del rover.

Figura 12 - Macchina a stati finiti dell'interprete dei comandi del rover.

Quando l'interprete è in stato STOP, le ruote sono nella posizione neutrale e tutti i motori sono fermi. Una direttiva di moto real-time provoca il passaggio in modalità RT-ROTATING o RT-MOVING. Queste modalità corrispondono alle due possibili configurazioni di ruote descritte nel settimo articolo di questa serie. Comandi real-time successivi, che vengono eseguiti come richiesto, possono causare o meno un cambiamento di stato. Una transizione di stato avviene ogni qual volta un comando ROTATION viene seguito da un comando MOVING o viceversa. Un timeout di 200 millisecondi senza ricevere comandi causa il passaggio a stato di STOP, con conseguente arresto del rover.

La ricezione di un comando START SEQUENCE causa il passaggio allo stato NEXT-STEP. Da qui, l'interprete controlla il primo passo e da il via alle rotazioni necessarie. Quando l'interprete si trova in modalità SP-ROTATING, l'odometria viene controllata a intervalli di  200ms interval per verificare il progresso. Dopo aver raggiunto la rotazione desiderata, l'interprete dà il via al moto in avanti. Durante gli intervalli successivi, verifica la distanza percorsa dal rover, fino a quando viene raggiunta la destinazione. L'interprete quindi torna allo stato NEXT STEP per dare il via al passo successivo, se disponibile, o torna allo stato di STOP. In qualunque momento, una direttiva "PANIC!!!" può interrompere l'esecuzione del percorso, e provocare il passaggio allo stato di STOP.

Conclusioni

Siamo oramai prossimi alla fine di questa serie di articoli che ci ha accompagnato per un anno intero, e che mi ha offerto inattese possibilità di contatto. Grazie alla visibilità ottenuta con MokaByte, per esempio, ho avuto i miei 5 minuti di gloria: una giornalista della televisione friulana Free TV, a cui era stata segnalata questa serie, mi ha contattato per una intervista che potete vedere sul link riportato in [1].

Scrivere questi "racconti" mi ha permesso di rivivere le esperienze di un periodo molto significativo per me, e di trovare nuovi significati. Il mese prossimo racconterò come è andata a finire, e condividerò le conclusioni che ne ho tratto, sperando che possano essere di aiuto a chi si trovi a desiderare, come me tre anni fa, una svolta di qualche tipo, in ambito personale e professionale.

Riferimenti

[1] Un po' di Friuli sulla Luna

http://www.youtube.com/watch?v=oUf67FqkASs

Condividi

Pubblicato nel numero
169 gennaio 2012
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…