La nostra lunga serie sulla creazione di un sistema di controllo per un rover planetario continua all‘insegna delle conoscenze necessarie per progettare un valido modello di interazione con l‘utente, gestire il modello di locomozione della macchina e… destreggiarsi nelle complesse formalità dell‘etichetta giapponese, tanto difficili per un occidentale.
Paese che vai…
A sette settimane dall’inizio della mia esperienza avevo oramai preso piena confidenza con la mia sistemazione. Mi ero reso conto che non conoscere la lingua era un problema meno serio di quanto avessi presupposto. In Giappone lo straniero viene considerato un ospite, e trattato con molto riguardo. Se hai bisogno di qualcosa, ti basta chiedere aiuto a un passante, e quello metterà in atto i suoi migliori sforzi per capire cosa vuoi e aiutarti, spesso coinvolgendo altri passanti in una singolare catena di solidarietà. Tanto per fare un esempio, nei primi giorni mi capitò più volte di perdermi per la città, una cosa piuttosto facile in un Paese in cui le strade non hanno nome, e i numeri civici sono sparpagliati qua e la a caso, e in tutti i casi riuscii a trovare la strada di casa semplicemente chiedendo in giro.
Gaijin
Questo “eccesso di cortesia” finisce per essere un problema per gli stranieri che si sono trasferiti in Giappone in pianta stabile. Per quanto un occidentale impari la lingua, e per quanto rispetti gli usi e i costumi giapponesi, non verrà mai riconosciuto come un vero e proprio connazionale. Gli stranieri vengono chiamati gaijin (= “persona esterna”), un termine che ha una sottile connotazione razzista. Ma nel mio caso, la condizione di gaijin era decisamente comoda. Armato della mia Gaijin Card, un permesso di soggiorno temporaneo, potevo accedere a servizi pubblici, e godere in generale della ospitalità del Governo giapponese. In altri casi, il fatto di ignorare la lingua nazionale mi permetteva di approfittare del cosiddetto “Gaijin Power”, ossia la possibilità, senza alcuna punizione, di compiere azioni che i Giapponesi non si sognerebbero neanche lontanamente di fare, tipo attraversare la strada con il giallo o girare in bici con una luce rotta.
Formalità
Un altro aspetto con cui avevo preso confidenza, pur senza riuscire a comprenderlo davvero fino in fondo, era il ruolo delle convenzioni sociali. Il Giappone è una società fortemente gerarchizzata. Il ruolo all’interno della gerarchia è legato a fattori come il sesso, l’età, la famiglia d’origine, la posizione all’interno dell’organizzazione e così via. Il ruolo di un individuo, inoltre, cambia a seconda dell’organizzazione di riferimento, per cui una persona può avere un ruolo elevato in un contesto e una posizione inferiore in un’altro.
Il ruolo all’interno della gerarchia viene rinforzato dall’uso del linguaggio, che comprende declinazioni e vocaboli che denotano diversi livelli di “cortesia”. Un semplice “grazie” prevede svariate declinazioni, a seconda del contesto di utilizzo. Arigato è la forma usata tra amici, o in generale tra pesone allo stesso livello gerarchico. Domo arigato è la forma di cortesia usata con gli estranei. Arigato goimazu serve per ringraziare di una azione che non si è ancora conclusa: in generale è una forma che si usa quando qualcuno fa qualcosa per te, e sottointende un significato del tipo “grazie per quello che stai facendo ora, sono riconoscente per il disturbo che ti stai assumendo”. Arigato gozaimashita viene invece usato per ringraziare di una azione conclusa, sottointendendo “grazie per quello he hai fatto, ti sei preso un grande disturbo, hai il mio piu profondo rispetto”. Per finire, domo arigato gozaimashita è la formula in assoluto piu cortese, e ha un significato del tipo “mi prostro di fronte a Sua Altezza, esprimendo la mia più profonda riconoscenza per il disturbo che molto gentilmente Ella ha scelto di prendersi nel fare tutto questo per me”. Il tutto va accompagnato da una serie di inchini che vanno interrotti solamente dopo che l’interlocutore ha dato segno di aver recepito il nostro messaggio. Queste formule di cortesia, tradizionalmente rivolte alla nobiltà, fanno oggi parte del cerimoniale delle pubbliche relazioni commerciali. Ci sono dei precisi protocolli su come condurre questo tipo di scambi, e nel dubbio è sempre preferibile eccedere in direzione della forma più cortese: meglio suscitare ilarità che sdegno.
All’interno del dipartimento di Ignegneria della Università di Tohoku, io mi rivolgevo al Professor Yoshida con l’appellativo di sensei, un titolo onorifico riservato a insegnanti, dottori, politici, avvocati e altre figure di autorità. L’uso dell’appellativo sensei denota il rispetto verso qualcuno che ha ottenuto un elevato grado di maestria nel suo campo, ed è quindi implicito riconoscimento del suo ruolo di “maestro”, “guida”. Il titolo di cui godevo io era invece san, un titolo che viene in generale attibuito a persone adulte la cui esperienza viene riconosciuta all’interno della organizzazione. Hiroaki Inotsume, il giovane studente che mi assisteva nello sviluppo del software per El Dorado, si rivolgeva a me con l’appellativo senpai, un termine utilizzato in ambito accademico per rivolgersi a un collega anziano con più esperienza: in tal senso, la convenzione avrebbe richiesto che io mi rivolgessi a Hiroachi usando l’appellativo kun, che denota una persona con un livello inferiore di seniority, una sorta di “allievo”.
Il modello di interazione con l’utente
Nel frattempo andavo avanti con il progetto e lo sviluppo del sistema. Nel precedente articolo abbiamo visto il modello di interazione di sistema, che ha permesso di definire le varie entità di sistema, i loro ruoli e il modo in cui interagiscono tra loro. Questo mese vedremo di definire il modello di interazione con l’utente e il modello di locomozione. Come già la volta scorsa, ci concentreremo sul design delle interazioni, lasciando da parte il codice, che per forza di cose è dipendente dall’hardware sottostante.
L’interfaccia utente è un importante macrocomponente del sistema: di fatto è l’unico componente con cui l’utente finale interagisce. Fermo nel mio proposito di dare nomi giapponesi, decisi di battezzare questo componente Shikaku, una parola giapponese che significa “visione”, o “senso della vista”. L’interfaccia grafica è stata progettata secondo il paradigma Model-View-Controller, un modello con cui i lettori di MokaByte dovrebbero avere familiarità. Nei prossimi due paragrafi vedremo una descrizione della view e del controller.
La view
L’interfaccia utente è stata progettata in modo da fornire un accesso completo alle informazioni del sistema. La finestra principale mostra un modello tridimensionale dell’ambiente. Il rover è rappresentato all’interno della mappa nella posizione e orientamento corrispondenti. Le ruote del modello presentano lo stesso orientamento, e perfino il modo delle ruote viene rappresentato graficamente. Il movimento del rover nello spazio viene riprodotto nel modello tridimensionale. Il percorso attraversato viene marcato da una tracia di pixel detta “breadcrumbs”, o briciole di pane, un’idea presa dalla favola di Hansel e Gretel (o da quella, simile, di Pollicino).
La mappa utilizza il colore verde per rappresentare i dati locali della mappa di rilievo (le aree che il rover sta ispezionando al momento) mentre i dati storici, provenienti da campionamenti precedenti, sono rappresentati in blu. L’utente può ruotare la mappa in tre dimensioni, usando i bottoni del mouse, la rotella o il touch screen, se disponibile. Trascinando il mouse con il pulsante sinistro premuto, o trascinando il cursore sul touch screen, si cambia la prospettiva. Trascinando il mouse premendo il pulsante destro, o toccando lo schermo premendo il tasto ALT, permette di cambiare la posizione della telecamera. La rotella del mouse, o la combinazione di touch screen e del tasto CONTROL, permette di effettuare zoom in e out del modello.
A sinistra dello schermo è possible leggere la telemetria in forma numerica: posizione, orientamento e odometria. Due pulsanti permettono di resettare la vista in modalità “Hovering” e “Vertical”. Una serie di checkbox permette di abilitare elementi grafici come le breadcrumbs, l’elevazione e la mappa di rilievo storica.
La comunicazione tra il rover e la ground station è human readable per design. L’adozione di un formato leggibile da un essere umano presenta numerosi vantaggi, che verranno descritti più avanti, in occasione della presentazione del modello di comunicazione. Due tab in cima all’interfaccia grafica permettono all’operatore di controllare il flusso di messaggi in ingresso e in uscita. Queste informazioni sono salvate in un file di log assieme al timestamp di trasmissione e a quello di processamento, in modo da permettere un’analisi offline.
Il controllo
Shikaku è stato progettato per fornire due modalità di controllo alternative, che possono essere selezionate attraverso una coppia di pulsanti radio sul pannello di destra. La modalità real time è stata aggiunta per semplificare la gestione del rover durante il set up degli esperimenti: per quale ragione ci si deve ridurre a spostare di peso un rover da 20 kg quando è possibile farlo muovere sulle sue stesse ruote?
Quando Shikaku è impostato in modalità real-time, l’utente può inviare quattro comandi: avanti, indietro, ruota a destra e ruota a sinistra. I comandi vengono inviati attraverso i pulsanti di cursore sulla tastiera. Quando l’utente preme uno dei tasti cursore, il controller invia un comando. Se l’utente tiene premuto il tasto, un nuovo impulso viene inviato ogni 200 ms. Questo intervallo permette al sistema di rispondere rapidamente ai comandi; allo stesso tempo, 200 ms sono un tempo abbastanza lungo da permettere al rover di compleare un movimento discreto prima di ricevere il comando successivo. I comandi non vengono bufferizzati: quando l’utente rilascia il pulsante, la comunicazione viene interrotta in maniera brusca, in modo tale che non restino comandi in attesa di esecuzione. In modalità real-time, il rover si ferma qualora non riceva comandi per 200 ms.
Quando Shikaku viene impostato in modalità stored-path, l’utente può muovere il cursore sulla mappa utilizzando i pulsanti cursore per sellezionare un obiettivo. L’obiettivo viene selezionato premendo il tasto ENTER, o il pulsante Record Step (fig. 5a) sull’interfaccia grafica. Sulla colonna di sinistra, l’obiettivo viene espresso in coordinate polari, una coppia angolo-distanza che denota la rotazione e la traslazione richieste per muovere il rover fino all’obiettivo. Quando un obiettivo viene selezionato, la posizione corrispondente viene congelata sullo schermo, e l’operatore può proseguire selezionando il passo successivo. L’operatore può accodare fino a 100 passi, in modo da disegnare un percorso complesso attorno ad un ostacolo. Se necessario, l’operatore può cancellare l’ultimo passo premendo il pulsante “Undo” (fig. 5b). Il pulsante Discard Sequence (fig. 5c) permette di scartare tutta la sequenza in un colpo solo.
Quando il piano è completo, è possibile caricarlo nel rover premendo il tasto Submit sequence (fig. 5d). Il pulsante Play (fig. 5e) permette di avviare l’esecuzione del percorso. Una volta avviato il percorso, l’operatore può seguirne l’evoluzione sul monitor. In qualunque momento, la sequenza può essere abortita premendo il pulsante PANIC! (fig. 5f). Nello scenario di un ritardo di round-trip di due secondi, l’operatore vedrebbe il movimento con un ritardo di un secondo. La direttiva di ABORT raggiungerebbe il rover nel secondo successsivo. Per mitigare il problema, le direttive di moto in modalità “path planning” vengono eseguite ad una velocità piu bassa rispetto alla modalità “real-time”.
Il modello di locomozione
El Dorado è equipaggiato con quattro ruote motrici indipendenti. Ogni ruota può essere ruotata in una direzione indipendente e azionata a una velocità differente. L’interfaccia di programmazione del rover non pone alcun limite alla configurazione delle ruote, una scelta di design che è conforme al ruolo del componente, che ha l’obiettivo di fornire primitive di moto di livello intermedio.
Si noti che è possibile impostare anche configurazioni capaci di danneggiare il rover. Il fatto è che una configurazione capace di danneggiare il rover mentre questo si muove su una superficie liscia e compatta come l’asfalto può invece risultare utile o perfino necessaria in un terreno roccioso o sabbioso.
Il principio dell’incapsulamento suggerisce di esporre un set di operazioni sicuro, la cui complessità sia consistente con il livello di astrazione del componente all’interno del sistema. Data l’assunzione di un terreno piatto, e la necessità di fornire un sistema funzionante in un tempo molto breve, decisi di restringere le modalità di locomozione a due sole direttive: AVANTI e RUOTA. L’idea è modellata sul LOGO, un linguaggio di programmazione educazionale progettato da Seymour Papert alla fine degli anni Sessanta. Il LOGO è stato il primo linguaggio che ho imparato: era l’83, e io avevo 8 anni.
Una delle piu importanti feature del LOGO è la Turtle Graphics, un metodo per tracciare grafica vettoriale sviluppato attorno all’idea di muovere sullo schermo un cursore, detto “Tartaruga”, usando due direttive di moto principali: ROTATE e FORWARD, appunto. Combinando queste semplici direttive con le quattro strutture di controllo principali (sequenza, decisione, iterazione e assegnamento) è possibile disegnare pattern incredibilmente complessi sullo schermo utilizzando un pennello virtuale.
Questo modello è semplice e allo stesso tempo efficace. Permette di raggiungere qualsiasi punto in una superficie piatta attraverso una sequenza finita di passi elementari. Il modello può rimanere valido in presenza di terreni sabbiosi o accidentati, a patto che il rover venga dotato di una logica di controllo capace di risolvere localmente le differenze nella consistenza del terreno, utilizzando i sensori posti nelle ruote. Un terreno roccioso o montagnoso, d’altra parte, richiederebbe per forza di cose un modello di locomozione piu complesso.
Questo modello di locomozione può essere implementato usando solo due configurazioni delle ruote. Nella prima, detta MOVING, le ruote sono in posizione neutrale, in modo da permettere il moto in anvanti o all’indietro. Nella seconda, detta ROTATING, le ruote sono poste in una configurazione [45gradi, -45gradi, -45gradi, 45gradi], in modo da permettere al rover di ruotare su se’ stesso senza cambiare posizione.
Conclusioni
In questo articolo abbiamo visto come è stata strutturata l’interfaccia sulla base di un preciso modello di interazione con l’utente che consenta la vista e il controllo della posizione e dei movimenti del rover sul terreno. Abbiamo poi analizzato nel dettaglio il modello di locomozione, illustrando come esso si possa ridurre a poche e semplici direttive ben congegnate.
La prossima volta parleremo del modello di comunicazione, e più in generale del modello di dati interno dell’applicazione.