In questo articolo parliamo ovviamente di robotica ma, almeno all’inizio, sotto un’ottica diversa da quella di cui ci occupiamo nella serie: raccontiamo infatti qualcosa sui robot ‘umanoidi’ e sul rapporto che con essi esiste in Giappone. Ma non dimentichiamo anche il nostro ‘scatolotto’ con le ruote, parlando diffusamente dell’architettura software del nostro rover spaziale, specie per quello che attiene al movimento e alla gestione dei sensori.

Il mondo dei robot

Nei miei racconti sul Giappone, è emerso più volte il contrasto tra ciò che è proiettato nel futuro e ciò che è saldamente radicato nella tradizione. Durante l’Open Campus, verso la fine del mio soggiorno, ho avuto una ulteriore prova di questa singolare dicotomia. L’Open Campus è un evento piùttosto importante per l’Università di Tohoku: in questa occasione, i laboratori vengono aperti al pubblico, e presentano i frutti dei lavori di ricerca. Avevo già avuto occasione di visitare alcuni di questi laboratori, ma non si poteva rinunciare a una visita al laboratorio di robotica umanoide.

La robotica umanoide è un campo di ricerca in cui il Giappone sta investendo molte risorse, con risultati che spesso sono sulla frontiera di quella che viene chimata “Uncanny Valley”. La Uncanny Valley, traducibile liberamente come “valle dell’inquietudine”, è la soglia superata la quale un oggetto di forma umana smette di creare familiarità, e invece genera disagio.

Questa teoria, formulata dallo studioso Masahiro Mori nel 1970, considera la somiglianza all’uomo come un fattore desiderabile, che migliora la qualità dell’interazione uomo-macchina, ma solo fino ad una certa soglia, superata la quale la macchina comincia a generare una forma di paura ancestrale. Questa paura è un meccanismo profondamente radicato nella psiche umana, che associa un oggetto di forma umana all’idea della morte, con tutto il suo immaginario di zombie e fantasmi. Esistono molti esempi di robot umanoidi con aspetti inquietanti, e questo fatto è stato spesso spunto per le trame di libri o film. Per mia fortuna, i robot umanoidi che ho incontrato all’Università di Tohoku avevano una qualità diversa, più simile a Futurama che a Blade Runner.

Il mio incontro con Gundam

Dopo due mesi passati a lavorare sopra uno scatolotto metallico con le ruote, avevo ancora la curiosità di vedere se il Giappone fosse al lavoro, dopo tutto, su robot umanoidi futuristici. Nel laboratorio di robotica umanoide ho potuto vedere un esemplare di HRP-2 “Promet”, un robot che sembra uscito a tutti gli effetti da un cartone animato di Yoshiyuki Tomino. La cosa non deve stupire: l’aspetto esteriore del robot è stato infatti progettato da Yutaka Izubuchi, un famoso “mecha designer” che ha realizzato, tra le altre cose, i robot di Kido Senshi Gundam ZZ (1986), Kido Senshi Gundam: Gyakushu no Char (1988) e Kido Senshi Gundam 0080: Pocket no naka no senso (1989).

L’HRP-2 è una piattaforma per la ricerca e lo sviluppo di applicazioni di robotica umanoide. In Giappone è possibile acquistarne uno (o anche affittarlo), e sviluppare un software di controllo utilizzando una API Open Source. La dimostrazione più famosa studiata dal dipartimento di robotica umanoide dell’Università di Tohoku è qualla in cui HRP-2 suona un tamburo, un’operazione semplice solo in apparenza, dato che richiede una attenta coordinazione con i sensori di feedback delle braccia e dei polsi per calibrare il colpo e gestire il rimbalzo della bacchetta sulla pelle dello strumento.

Fembot e Crushinators

Ma le soprese non erano finite. Esiste qualcosa di più giapponese di un robot che sembra uscito da un cartone manga? Certo: un robot femmina progettato per fare la dama nel ballo da sala. Il Partner Ballroom Dance Robot è un progetto che ha ricevuto una grossa esposizione mediatica quando fu presentato nel 2005. Progettato dal professor Kazuhiro Kosuge e sviluppato nell’arco di quasi sei anni, il Partner Ballroom Dance Robot è un robot provvisto di una sfilza di sensori di movimento, gravitometri, bussole elettroniche, capace di percepire il cambiamento del baricentro del partner umano e di rispondere di conseguenza.

Ma è inutile girarci intorno: quello che colpisce veramente di questo prodigio tecnologico è l’aspetto. Con un viso modellato sulle fattezze di Marylin Monroe, un paio di orecchie da Minnie Mouse e curve da pinup, questo esemplare di “fembot” sembra uscito da un episodio di Futurama. L’umorismo di Futurama è basato sulla contrapposizione tra tecnologie avveniristiche e aspetti della natura umana che, nonostante il progresso, sembrano non cambiare mai. Su Futurama, Robot e Fembot sono personaggi integrati tra gli umani, e si caratterizzano solitamente per un pessimo carattere e per comportamenti discutibili, tra cui vizi come l’alcolismo, il fumo e il gioco d’azzardo. Robot e Fembot sono inoltre coinvolti, spesso e volentieri, in tresche degne delle migliori soap opera. La stretta interazione tra umani e robots ha causato in Futurama anche alcuni episodi di “robosessualità”, un fenomeno che viene presentato come estremamente serio e ridicolo allo stesso tempo. Credevo che la robosessualità fosse un ulteriore esempio di comicità paradossale di Futurama, ma dopo tre mesi passati all’università di Tohoku, ho cominciato a capire la reale natura di questo fenomeno.

Una diversa prospettiva

In Occidente, i robot vengono tipicamente caratterizzati come freddi e spersonalizzati. Questa caratterizzazione nasce, tra le altre cose, da concetti presenti da millenni nella nostra eredità giudaico-cristiana, secondo la quale i robot non sono nient’altro che oggetti senz’anima. Nella nostra cultura, quando i robot acquisiscono autocoscienza sono di solito problemi grossi per tutti: come ci hanno insegnato Terminator, Matrix e Battlestar Galactica, l’autocoscienza porta le macchine a diventare esseri inumani e spietati, il cui unico desiderio è liberarsi della “odiosa razza umana”. Opere classiche come “Il Golem” e “Frankenstein” danno una testimonianza della profonda immoralità che l’Occidente attribuisce all’idea di dare la vita a oggetti inanimati.

Nella cultura giapponese invece, ogni oggetto possiede un’anima, e come tale è degno di attenzione e rispetto. Quando un giapponese compra un biglietto del treno al distributore automatico, prima di andarsene si inchina di fronte alla macchina per ringraziarla del suo servizio, esattamente come farebbe di fronte a un operatore umano. A noi sembra strano, ma tutto questo ha le sue ragioni storiche. Nella cultura giapponese, un robot umanoide ha a tutti gli effetti il potenziale di essere accettato come un nuovo soggetto sociale. Robot come HRP-2 e la fembot ballerina sono infatti precursori di robot domestici, ai quali in futuro verrà delegata l’assistenza di anziani e infermi. Questa prospettiva, inconcepibile da noi, è un campo di ricerca su cui il Giappone sta investendo notevoli risorse economiche e tecnologiche.

La prospettiva Giapponese sul rapporto con i robot umanoidi può essere colta nel manga Astroboy, creato dal leggendario Osamu Tezuka nei primi anni Cinquanta. In Astroboy, uno scenziato crea un robot, Atom, a cui attribuisce le fattezze del figlio, morto in un incidente. Atom decide di mettere i suo poteri a servizio dell’umanità, combattendo nemici sia umani che robot. Nell’universo di Tezuka, non c’è distinzione morale o ideologica tra i due mondi: umani e robot convivono sullo stesso piano, alimentati in ugual misura da nobili sentimenti o da vili propositi.

Quello del robot-umano è un tema ricorrente nella cultura giapponese, che l’Occidente non ama e non comprende appieno. Il film “A.I.” di Steven Spielberg, ad esempio, parte da un soggetto simile ad Astroboy, ma sviluppa il tema in modo completamente diverso, giungendo alla conclusione che la convivenza tra umani e macchine intelligenti è qualcosa di sostanzialmente impossibile, che finisce per causare dolore e sofferenza sia negli umani che nei robot.

El Dorado: l’architettura di sistema

Dopo questa digressione sul mondo dei robot umanoidi, torniamo al nostro rover planetario: certo, il nostro El Dorado non ha il volto di Marylin, ne’ la capacità di suonare un tamburo, ed è in effetti uno scatolotto di metallo con le ruote… però è capace di muoversi su terreni difficili e di effettuare rilevamenti, e a lui ci dobbiamo dedicare con la massima attenzione. Continuiamo quindi a vedere i principi alla base dell’architettura del suo software, dedicandoci in particolare ad aspetti quali il movimento e il controllo dei sensori.

Sistema distribuito

Da un punto di vista architetturale, Kaizen 2010 è un sistema distribuito a componenti. In una architettura di questo tipo, il sistema è diviso in entità software discrete, dette componenti, che possono trovarsi fisicamente su sistemi host differenti, connessi tra loro attraverso la rete. Ogni componente ha un ruolo preciso all’interno del sistema, e un insieme predefinito di possibili interazoni con gli altri componenti. I componenti possono utilizzare diversi meccanismi di comunicazione (chiamata di funzione, memoria condivisa, networking e così via). Ciò che è davvero importante nel software a componenti è il fatto che ogni entità possiede un’interfaccia che denota le possibili interazioni con il componente stesso. Lo stato del componente è nascosto: solo un sottoinsieme di esso è visibile all’esterno, e può essere interrogato attraverso l’interfaccia di programmazione. Ogni componente può essere sviluppato in un linguaggio e su una piattaforma differente, a patto che componenti comunicanti utilizzino un medesimo protocollo di comunicazione (l’interfaccia di programmazione) e relativo meccanismo sottostante (RPC, RMI e così via). L’architettura di alto livello di Kaizen 2010 è visibile in figura 8. Nelle prossime sezioni forniremo un dettaglio dell’architettura del rover; l’architettura di sitema del software della ground station verrà invece descritta il mese prossimo.

Lato Rover

I due componenti più importanti dell’architettura di sistema del rover sono System e Shared Memory. System è un processo che possiede l’accesso esclusivo all’hardware. Shared Memory è un bus software che fornisce un canale di comunicazione tra i processi utenti e System. System è un processo real-time, nel senso che la sua esecuzione è tempo-dipendente. In un sistema tempo-dipendente, la medesima sequenza di comandi porta a risultati differenti a seconda di quando viene immessa. Un driver di periferica è un tipico esempio di sistema real-time. La richiesta di lettura di una serie di blocchi sul disco verrà eseguita in maniera differente a seconda di dove si trovi il piatto e in quale direzione si stia muovendo la testina. Ad alto livello, una richiesta darà sempre il medesimo risultato, un flusso di byte, ma a basso livello, ogni esecuzione sarà fisicamente diversa dalle altre.

I processi utenti non hanno accesso effettivo all’hardware: utilizzano Shared Memory come mediatore. Shared Memory dispone di una interfaccia di programmazione che include 31 chiamate. Queste permettono di impostare la velocità di ogni ruota, di fermarle, di selezionare l’angolo di sterzata e di leggere l’odometria, l’orientamento e la posizione. Le chiamate effettivamente utilizzate durante lo sviluppo di Kaizen 2010 sono mostrate nel listato sottostante.

void Dra_stop(void)
void Dra_set_steer(double str1, double str2, double str3, double str4)
void Dra_set_steer_and_wait(double ref1, double ref2, double ref3, double ref4)
void Dra_set_rpm(double rpm1, double rpm2, double rpm3, double rpm4)
void Dra_get_steer(double *str1, double *str2, double *str3, double *str4)
void Dra_get_rpm(double *rpm1, double *rpm2, double *rpm3, double *rpm4)
void Dra_get_gyro_rpy(double *r, double *p, double *y)
void Dra_get_pos3D(double *pos_x00, double *pos_y00, double *pos_z00,
            double *pos_x01, double *pos_y01, double *pos_z01,
            double *pos_x02, double *pos_y02, double *pos_z02 )
void Dra_get_rpm(double *rpm1, double *rpm2, double *rpm3, double *rpm4)

Il livello di astrazione dei comandi esposti dall’interfaccia di programmazione di Shared Memory è abbastanza basso da permettere a un processo utente di configurare il rover in qualunque maniera. Questo livello è comunque più alto rispetto al livello di astrazione dell’interfaccia di programmazione di System, che permette di accedere ai singoli motori fisici e leggere i dati grezzi dei sensori. System interroga Shared Memory ogni 50 millisecondi. Durante un ciclo di polling, processa l’odometria di basso livello, espressa come funzione della lettura di un sensore e dei parametri del motore corrispondente, e produce una rappresentazione di alto livello, espressa in metri, giri al minuto e così via. Quindi legge il comando corrente e lo esegue, inviando una sequenza di istruzioni di basso livello a un particolare componente hardware.

Il movimento

Un processo utente può avviare un movimento complesso inviando un comando al sistema operativo del rover attraverso l’interfaccia di programmazione di Shared Memory. A questo punto, il processo si mette a controllare l’odometria a intervalli regolari, per verificare l’effettiva esecuzione. Data la performance complessiva dei sensori e degli attuatori di El Dorado e la frequenza di update di System, un update ogni 50 millisecondi, ho scelto di adottare sul processo utente un intervallo di campionamento di 200 millisecondi, ossia 5 campionamenti al secondo. Una frequenza di controllo più ridotta, tipo 4 controlli al secondo, ridurrebbe la precisione. Una frequenza di controllo più rapida risulterebbe ridondante, dal momento che l’effettivo spostamento degli attuatori tra una misurazione e l’altra diventa via via trascurabile rispetto all’ordine di grandezza delle distanze da percorrere. È inutile avere un controllo che fornisca una precisione teorica al millimetro, quando il sistema nel suo complesso ha una precisione di due centimetri in più o in meno per ragioni dipendenti sia dall’hardware che, ancor più, da fattori ambientali come il terreno (se ordino al rover di spostarsi di 150 cm, la sua posizione finale sarà compresa tra 148 e 152, anche alzando la frequenza di controllo). Una frequenza di un controllo ogni 200 millisecondi è un ottimo compromesso; una frequenza superiore ruberebbe cicli alla CPU senza produrre un vantaggio reale.

Microchirurgia software

Per permettere a Sistema e Shared Memory di dinteragire con gli altri componenti di Kaizen 2010, ho introdotto una piccola modifica a Shared Memory, aggiungendo una struttura dati interna capace di registrare i dati della mappa di rilievo locale. Questa struttura dati è una matrice floating point di 500 x 500. Ogni cella della matrice rappresenta un’area di terreno di 10 centimetri quadri, e il valore floating point rappresenta l’altitudine media di quell’area. Ho aggiunto anche un contatore incrementale, che permettesse di distinguere tra letture successive della matrice, e i dati della telemetria al momento della scansione. L’interfaccia di programmazione di Shared Memory è stata estesa in modo da permettere l’interrogazione di questa struttura dati. Le chiamate a funzione aggiunte a Shared Memory, mostrate nel listato qui sotto, sono state sincronizzate con semafori POSIX, seguendo un framework descritto nel paper “Shared Memory and Semaphores” di Gaughan (2003), in modo da assicurare la mutua esclusione nella lettura e scrittura.

void setDemData(int *demNum, double *demX, double *demY, double *demZ,
            double *demRoll, double *demPitch, double *demYaw,
            double dem[][GRID_PLUS_ONE],
            int flags[][GRID_PLUS_ONE])
void getDemData(int *demNum, double *demX, double *demY, double *demZ,
            double *demRoll, double *demPitch, double *demYaw,
            double dem[][GRID_PLUS_ONE],
            int flags[][GRID_PLUS_ONE])

La modifica alla Shared Memory è stata introdotta con una tecnica di crosscutting, mutuata dalla programmazione aspect-oriented. Attraverso il crosscutting, noi definiamo un nuovo comportamento, quindi lo inseriamo all’interno di una procedura pre esistente attraverso una sorta di operazione chirurgica, che consiste nell’individuare un pointcut (“punto di taglio”) ove inserire una chiamata al nuovo comportamento. In questo modo, il nuovo comportamento viene integrato nella procedura preesistente in maniera trasparente al resto del sistema, che prosegue le sue attività ignaro che qualcosa sia cambiato.

Occhi belli

Utsukushii-Me è un componente che controlla il sensore laser tridimensionale del rover, costruisce una mappa di rilievo, e la registra nella Shared Memory. Utsukushii-Me, che in giapponese significa “occhi belli”, è un’evoluzione del componente che nell’architettura originale si chiamava Urg3Dnew_DemView. Il cambio di nome è a tutti gli effetti un upgrade, allo stesso livello delle modifiche funzionali che ne hanno permesso l’interfacciamento con Shared Memory. Come ho già spiegato nella “Parte V: Zone Depresse”, i nomi sono una componente fondamentale in un progetto, non un dettaglio irrilevante. Un nome che sia significativo per il cliente, magari con una connotazione umoristica come in questo caso, ha una funzione descrittiva e documentale, che ha conseguenze fondamentali sull’efficacia della comunicazione. Utsukushii-Me scansiona l’ambiente circostante ogni tre secondi, e campiona l’ambiente in modo da ricavare dati di altitudine. Questi dati sono poi mappati in una matrice di 500 x 500 mediante triangolazione. La griglia, che ha una precisione di 10 centimetri, è misurata in coordinate relative alla posizione di inizio del rover. Ogni campione è caratterizzato dalla posizione e dall’orientamento del rover al momento della misurazione. I dati vengono registrati nella Shared Memory, assieme a un numero di versione incrementale che permette al processo client di distingure tra invii successivi, in modo da evitare di inviare dati duplicati.

Conclusioni

Come al solito, abbiamo suddiviso il nostro articolo tra note “di colore”, questa volta dedicate perà all’interessante concezione che i Giapponesi hanno del robot umanoide, e note metodologiche inerenti l’architettura di sistema del software del nostro rover. Ci siamo questa volta concentrati sul rover in se’ stesso, mentre nel prossimo articolo ci occuperemo del sistema della stazione a terra.

Come avevo anticipato il mese scorso, però, vorrei mettere i lettori al corrente di una novità per me importante sia sul piano personale che professionale. Il 21 novembre scorso ho cominciato il mio nuovo lavoro nel Payload Safety Review Panel all’European Space Research and Technology Centre (ESTEC) a Noordwijk, Paesi Bassi. La ESTEC è il maggior centro di sviluppo tecnologico della European Space Agency (ESA), la “NASA Europea” che ha finanziato la mia borsa di studio alla International Space University. L’anno passato all’ISU, di cui ho ampiamente trattato su queste pagine, è stato una delle carte che mi hanno permesso di ottenere questo lavoro.

L’ufficio in cui lavoro ha il compito di verificare la conformità ai severi requisiti di sicurezza di tutto il materiale che viene fisicamente spedito in orbita alla Stazione Spaziale Internazionale, dalle attrezzature tecnologiche, ai rack di esperimenti scientifici finanche alla carta igenica. Giovann Puliti, direttore di MokaByte e amico carissimo, ha commentato divertito: “ah, ho capito: vai a fare il doganiere spaziale!” Colpito dal parallelo tutt’altro che avventato, ho riso di cuore all’ironia di essere diventato, ancora una volta, un personaggio di un episodio di Futurama.