mBot e il robot marziano. Quando la comunicazione con un robot è lenta

mBot e il robot marziano. Quando la comunicazione con un robot è lenta

I contenuti qui raccolti, dedicati al coding, sono stati progettati per sperimentare un utilizzo avanzato di Scratch​, le cui funzionalità di base sono presentate nel volume ​”Technologica C – Coding e Robotica”.

Questo software ha una variante liberamente scaricabile, denominata mBlock, che permette di utilizzare il robot mBot, descritto nello stesso libro di testo. Le proposte operative qui pubblicate consentono di  lavorare in classe con il robot utilizzando anche i listati che potete scaricare qui.


 

Supponiamo di mandare un rover a esplorare la superficie di Marte, un semplice robot “stupido”  telecomandato dalla Terra. In questo caso l’intelligenza è quella remota della persona o del computer che lo controlla.
Fra i vari problemi che dobbiamo risolvere, ce n’è uno che forse non ci aspettiamo: il ritardo di comunicazione.
Un segnale radio viaggia  – nel migliore dei casi – alla velocità della luce, circa 300.000 km/s.
Così come la luce del Sole impiega alcuni minuti a raggiungere la Terra, un segnale radio, per arrivare su Marte, può impiegare da pochi minuti, quando i due pianeti sono più vicini, fino a circa mezz’ora nel caso opposto.

Nel caso peggiore, se la telecamera del robot inquadra, poniamo, una pericolosa buca, il “pilota” che sta sulla Terra la vede con mezz’ora di ritardo. Ma non è finita: se anche il pilota dà immediatamente al robot l’ordine di fermarsi, occorre un’altra mezz’ora prima che il comando arrivi e il robot finalmente si fermi… sperando che non sia già caduto nella buca da un bel pezzo! Il tempo di attesa (lag) tra l’evento e la reazione può arrivare quindi fino a un’ora.
In questa situazione, per limitare i rischi, non resta che far muovere il robot con esasperante lentezza: se su Marte ci fossero delle lumache, sorpasserebbero il nostro rover in tutta calma.

Ma torniamo per un attimo sulla terra e al nostro robot didattico, mBot, comandato da un programma che abbiamo scritto sul computer con i blocchi colorati di mBlock (il software derivato da Scratch con cui si programma mBot).
Anche in questo caso l’intelligenza di controllo non sta nel robot ma nel computer, perciò è remota. Ma il “controllore” sta a poche decine di centimetri di distanza, quindi non abbiamo certo i problemi del robot marziano, giusto?

Sbagliato! Abbiamo esattamente gli stessi problemi, anche se la scala dei tempi è diversa. Prendiamo il caso in cui abbiamo programmato mBot per seguire la classica linea nera tracciata per terra:

  1. Il sensore ottico rileva bianco o nero sotto di sé.
  2. mBot trasmette al computer il nuovo valore letto dal sensore.
  3. Il programma sul computer legge il valore ricevuto.
  4. Il programma prende una decisione.
  5. Il programma manda un ordine ai motori di mBot.
  6. Il computer trasmette l’ordine a mBot.
  7. mBot lo esegue comandando i suoi motori.

I punti da 2 a 6 sono relativamente lenti. Non come una comunicazione con Marte, naturalmente, ma complessivamente possono richiedere anche qualche decina di millisecondi (millesimi di secondo).
Sembra un tempo brevissimo, ma è più che sufficiente per far uscire mBot dalla linea tracciata se lo facciamo correre alla massima velocità: dobbiamo farlo andare più adagio, un po’ come il suo collega marziano.

Come si può risolvere il problema? Possiamo eliminare il tempo di comunicazione mettendo il programma dentro mBot stesso, con l’apposita procedura di mBlock: i tempi di risposta saranno molto più brevi e mBot seguirà la linea anche con buona velocità.
Abbiamo messo una intelligenza locale, cioè nel robot stesso.

Tutto risolto, dunque? Sì e no: abbiamo risolto un problema, ma ne abbiamo introdotti degli altri (e ti pareva…).
Tanto per cominciare, le risorse a bordo di mBot (o del rover marziano) sono limitate: lo spazio per il programma, la memoria di lavoro (RAM) e la potenza di calcolo sono molto probabilmente inferiori a quelle del nostro computer.
Insomma, non sono abbastanza per metterci una “intelligenza” particolarmente sofisticata.
Inoltre, poiché il programma sta tutto nel robot, ci siamo tagliati fuori: non abbiamo video né mouse, non sappiamo cosa stia succedendo e non abbiamo possibilità di intervenire.

La soluzione migliore è più complicata: combinare le due intelligenze, quella locale e quella remota assegnando alla prima la “tattica”, cioè le risposte che richiedono velocità (“férmati se vedi una buca”), e alla seconda la “strategia”, ossia le decisioni di alto livello (“vai a esplorare quell’altura”).

Nel caso di mBot è possibile scrivere due programmi: uno locale (su mBot stesso) e uno sul computer, che comunichi col primo attraverso i comandi per mandare e ricevere messaggi da mBot.
Una soluzione, questa, ampiamente utilizzata in campo robotico (e realizzabile anche in classe, distribuita in più lezioni).

Funzionano così, infatti, i  “veri” rover marziani e anche i veicoli a guida assistita. Sono i primi passi verso una capacità di guida completamente autonoma, che richiederà ancora diversi anni e che comunque dovrà poter comunicare con l’intelligenza del guidatore umano… se non altro per sapere dove vuole andare.

di Enrico Colombini


Enrico Colombini nasce come progettista di hardware e software di sistemi a microprocessore negli anni ’70 e ’80. Tra i primi autori di giochi per computer in Italia. Autore di corsi di programmazione e di elettronica di vasta diffusione negli anni ’80 e ’90. Attualmente progettista software e consulente industriale su sistemi embedded e autore di corsi di programmazione visuale e di robotica per la scuola primaria e secondaria.

Leggi anche

Alla ricerca di… Pitagora
Composizioni proporzionate: un'attività laboratoriale per affrontare le proporzioni
Probabilità in due e in tre dimensioni, nello spazio e nel tempo
400 docenti toscani a scuola di robotica, nuova frontiera dell'apprendimento
mBot: ne vedrete di tutti i colori. Utilizzo creativo dei led di mBot
mBot e l’interfaccia utente. Quando l’uomo comunica con la macchina