Di Giuseppe Cotugno
Di Giuseppe Cotugno
Si chiama Nao, ma non e’ il cugino malefico di Keanu Reeves, e’ solo un calciatore, un calciatore robotico che ogni anno si cimenta, insieme ad altri suoi tre colleghi, nella Robocup, ovvero nei campionati di calcio robotico per la categoria Standard Platform League. Ogni squadra e’ composta da tre Nao piu’ una riserva ed e’ programmata da un team di studenti, ricercatori e professori, alla competizione partecipano universita’ da ogni parte del mondo. In verita’, la Standard Platform non e’ l’unica categoria disponibile, esistono anche la Humanoid League, con robot di varie dimensioni interamente costruiti dalle universita’, la Middle-size e la Small-size, ove partecipano robot su ruote a grandezza umana o grandi quanto una noce di cocco. Non c’e’ solo il calcio-spettacolo, nella robocup c’e’ anche una competizione per le sonde robot (Resecue Robots), che dovrebbero trovare vittime in ambienti disastrati, ed il robot-maggiordomo (Robot@Home) che dovrebbe servire un umano in casa. Terminano il quadro le competizioni precedenti riprodotte su un simulatore.
Come mai, in tutto questo ben di Dio, ci occuperemmo della cosa piu’ semplice? Perche’ e’ quella che ha costi piu’ abbordabili per un’universita’ italiana (2000 euro per un Nao contro 100 000 per un robot-maggiordomo), inoltre i Nao saranno a breve commercializzati dalla azienda produttrice, la Aldebaran con sede a Parigi, e soprattutto perche’ il grosso del software che gira sul Nao e’ open, per cui e’ bene essere ben preparati ad accogliere questo nuovo prodotto quando sara’ rilasciato sul mercato.
Innanzitutto parliamo un po’ dell’hardware, il Nao dispone della bellezza di 25 gradi di liberta’, ovvero giunti attuabili indipendentemente con il solito motorino in corrente continua, la struttura e’ alta circa un metro. L’autonomia del robot e’, come al solito, abbastanza scarsa: tra la mezz’ora e un’ora, ma considerato il fatto che una partita dura 20 minuti non e’ un gran problema. Il robot e’ ben sensorizzato, dispone di due bumpers (una sorta di pulsanti) sui piedi, sensori di forza sempre sui piedi (utili per capire quando il Nao si e’ accappottato), ultrasuoni sul petto, microfoni omnidirezionali nelle orecchie, due telecamere 320×240 in formato YUV (che purtroppo si alimentano dallo stesso bus), giroscopi, accelerometri eccetera. Completano la struttura una porta ethernet, una scheda wi-fi, degli speaker e delle lucette (utilissime per avere un feedback senza collegarsi al robot). Si puo’ capire facilmente che un robot cosi’ sensorizzato ha del potenziale.
Il cuore “informatico” del robot e’ nella sua testa. Essa ospita, infatti, un processore AMD Geode LX 800 su cui gira un kernel Linux 2.6.22-9 avviato dal Grub; a sua volta il sistema operativo avvia un demone, il NaoQI che si occupa della gestione vera e propria di tutte le periferiche del Nao, e che dovrebbe essere l’unico punto di riferimento per un futuro acquirente. Sempre secondo l’idea di Aldebaran, la programmazione dovrebbe essere assistita da un programma, il Coreographe, che permette di elaborare movimenti ed azioni in maniera molto semplice, e ad occhio sembra riuscirci, in pratica non ho mai avuto necessita’ di usarlo.
Difatti, nel laboratorio della Sapienza, a fianco al NaoQI utilizziamo un framework open-source, OpenRDK, sviluppato completamente in C++ all’interno dell’universita’, ma disponibile per la comunita’ su Source Forge. Ad esso abbiamo affiancato, talvolta, delle librerie di aiuto, come OpenCV per i problemi di visione.
In verita’ quanto proposto da Aldebaran e’ pacifico finche’ l’utilizzatore e’ il solito utonto a cui basta poco per apprezzare la piattaforma, considerato che il Nao viene usato per una competizione accademica, ogni universita’, o quasi, ha sviluppato la propria alternativa piu’ o meno open, addirittura un’universita’ tedesca ha completamente bypassato il NaoQI e questo non e’ stato molto gradito da Aldebaran, visto che il NaoQI si cura anche di evitare che i giunti vadano in saturazione o si danneggino a causa di un comando troppo “ambizioso”.
OpenRDK e’ un framework altamente modulare, e non esistono versioni pacchettizzate. E’ necessario compilare il software da sorgente creando un makefile grazie al programma Cmake, tutto ovviamente open. OpenRDK carica dentro se’ dei moduli C++ che implementano tre funzioni, una per inizializzare le proprieta’ condivise tra tutti i moduli, uno per inizializzare le sue strutture interne ed uno per eseguire il compito specifico (ad esempio raggiungere la palla). Tutte le variabili condivise vengono conservate in uno specifico oggetto, da cui si alimentano tutti i moduli, per cui nel framework e’ anche cablata un minimo di gestione della concorrenza.
Giustamente il lettore si chiedera’, ma come e’ possibile che del codice compilato su una macchina Intel possa girare su un processore Geode? Ed infatti non lo fa’! Qualsiasi cosa si voglia far girare sul Nao e’ necessario prima cross-compilarla sul proprio PC per il processore Geode e poi caricarla sul Nao. In parole povere, prima si testa il funzionamento del codice sulla propria macchina linux, poi si ricompila tutto per il Geode e si copia sulla stick da 1 GB che sta nella capoccia del Nao.
Vediamo in pratica qual e’ la procedura che e’ necessario fare per eseguire del codice con un esempio.
Supponiamo che vogliamo riconoscere una palla arancione su un’immagine. Innanzitutto viene implementato un algoritmo di riconoscimento usando i tre metodi messi a disposizione da OpenRDK; dopodicche’ il codice viene compilato, corretto ed eseguito in locale sul proprio PC. Anche il codice viene eseguito da OpenRDK, in particolare da Ragent, un programma che simula un agente, ovvero che esegue tutta l’infrastruttura di base di OpenRDK su cui poi viene caricato il modulo di visione.
Se si e’ soddisfatti, si ricompila il codice dalla propria macchina per il Geode (Cmake si preoccupa di generare un makefile che istruisca correttamente il compilatore), si copia il codice oggetto sul Nao e, finalmente si avvia Ragent sul Nao caricando il modulo di visione.
Ovviamente, il Nao sara’ in grado solo di vedere la palla e niente piu’, difatti nelle partite di calcio della robocup, i task fondamentali da eseguire sono trovare la palla, avvicinarsi, posizionarsi e calciarla, tutto senza accappottarsi. Certamente una partita e’ piu’ complicata, e’ possibile far cooperare i robot per evitare che si buttino tutti sulla palla, e’ possibile fargli distinguere le porte, localizzarsi eccetera, ma per adesso ci accontenteremmo.
OpenRDK e’ stato pensato per un uso generale, in laboratorio viene usato anche per programmare i Resecue Robots in simulazione e per gestire un quadrirotore che monta un processore ARM, l’unico della Robocup capace, tra le altre cose, di riconoscere le linee a bordo, e forse un domani le finestre.
L’ultima robocup e’ stata letteralmente sbancata dalle squadre tedesche che, a differenza di quelle italiane, e’ ben finanziata e ben gestita, mentre invece le squade americane han fatto una figuraccia, considerato il budget che muovono. Questo lascia pensare che, non bastano i soldi e l’organizzazione per fare una squadra vincente. Purtroppo i problemi di uno Stato si propagano ad ogni settore della societa’ e quindi la squadra italiana non e’ riuscita ad ottenere un risultato adatto a quello che potrebbe offrire. Se si pagassero i dottorandi, e si lasciasse piu’ spazio alle idee degli studenti, forse alla robocup del 2010 a Singapore gli azzurri riusciranno ad ottenere i risultati a cui possono ambire.