Un simulatore
Per l’edizione 2023/24 il Team Marte(llo) del Liceo Scientifico Statale “L. Spallanzani” di Tivoli (RM) composto da Fabio Massimo Proietti (3F), Giancarlo Napoleoni (3E), Ruben Piselli (4E) e Valerio Memeo (3E) hanno sviluppato un simulatore, cosa dire GRANDI 🙂 Di seguito il loro articolo
La necessità di un simulatore in grado di, appunto, simulare un robot con quattro ruote motrici nasce alla fine della prima fase di formazione: mentre alcuni stavano già comprando e costruendo il robot, noi continuavamo a fare a botte – metaforicamente – con l’amministrazione scolastica per comprarlo. Chiaramente non è una battaglia che abbiamo potuto vincere.
Di conseguenza, con ancora tre mesi dall’inizio della gara, ci chiedevamo che fare per il resto delle ore asincrone di PCTO (e come potevamo effettivamente esercitarci per la gara). Parte quindi la ricerca di un simulatore di un robot con, molto semplicemente, quattro ruote.
A sentirla così sembrerebbe una cosa estremamente comune e facile da trovare, ma non è affatto così. Dopo aver provato alcuni siti di NASA (come quello qui al lato), troppo “giocattolosi”, siamo arrivati alla conclusione che un simulatore proprio come lo volevamo noi non esisteva, e che ce lo saremmo dovuti creare da (quasi) 0.
Dopo aver provato, con molto poco successo ma effettivamente anche molto poco impegno, Unity, siamo arrivati alla conclusione che era (a) decisamente troppo complicato, e (b) non realistico.
La nostra docente tutor, Valeria Lorusso, ci fa quindi conoscere CoppeliaSim, un sistema di simulazione fisica fatto apposta per essere realistico e decentemente semplice da usare, restando comunque estremamente personalizzabile: quello che ci serve. Tra l’altro, durante l’OpenDIAG di quest’anno abbiamo avuto modo di notare come anche diversi gruppi lì in Sapienza lo utilizzassero per i loro progetti.
Scarichiamo quindi la versione EDU del software e iniziamo a prendere un po’ di familiarità con il sistema. Vediamo come ogni elemento che noi inseriamo può contenere altri elementi, che si muovono assieme ad esso, e, cosa importante, ogni elemento ha uno script associato.
Ora, ci troviamo davanti un’altra piccola challenge, diciamo. Coppelia, infatti, si programma principalmente in Lua, un linguaggio che nessuno di noi conosce. Scaviamo nella documentazione e troviamo una soluzione: un API “remota” (che poi remota non è, visto che gira sulla stessa macchina).
Un’API, in poche parole, è un pezzo di software che fa interfacciare due sistemi altrimenti separati. In questo caso, visto che l’API era disponibile per C++ e Python, abbiamo di implementare le funzioni classiche del robot ROSITA (setSpeed4W, pan, tilt) in Python.
Lo script Lua è impostato in modo da accettare chiamate all’API su una porta predeterminata e basta.
Il robot in sé è uno dei modelli già presenti nel programma, un Robotnik Summit XL a cui abbiamo aggiunto una joint (un’“articolazione”, di fatto un motore) su cui si trova un Microsoft Kinect (anch’esso già presente nel simulatore, ma modificato per avere una viewing distance più elevata).
La joint che abbiamo aggiunto noi ci dà la possibilità di muoverci in orizzontale, mentre, per quanto riguarda il movimento verticale, il Kinect lo aveva già nel modello stock.
Dopo aver “creato” il modello del robot in sè, siamo passati all’implementazione software del controllo di questo. Più o meno in questo periodo abbiamo anche creato una repository su GitHub in cui raccogliere il codice e il progetto con obiettivi etc.
Quindi, con la documentazione sottomano, ci siamo addentrati nella scrittura del codice.
La parte del movimento, tutto sommato, è stata anche molto semplice. Presi un po’ di spezzoni di codice da una parte e dall’altra, modificati un po’, e il gioco era fatto.
La gestione della telecamera, invece, è stato un lavoraccio incredibile, ricco di colpi di scena.
Innanzitutto, la documentazione era molto poco chiara su come funzionassero effettivamente gli oggetti visivi – e soprattutto la differenza tra una camera e un passive vision sensor. Ad oggi non la capiamo veramente, ma non ci interessa più di molto: di fatto, i PVS possono acquisire immagini e le camera no, e visto che il kinect ha un PVS “di serie”, questo non è stato nemmeno troppo un problema.
Capire effettivamente come si acquisiva un’immagine ci ha richiesto molto tempo e molte capocciate su vari tavoli (metaforici e non).
Fatto sta che, alla fine, siamo riusciti ad implementarlo, e, allo stesso tempo, abbiamo scovato un bug di CoppeliaSim che abbiamo segnalato agli sviluppatori, gentilissimi, che ci hanno inviato un hot fix pochissimo tempo dopo.
Trovato il modo di acquisire un’immagine, di fatto, il progetto era pressoché terminato, almeno in una sua versione base ma comunque funzionale.
L’implementazione della scansione dei tag è stata molto semplice, avendo utilizzato la libreria python Qreader, che fa tutto da solo (ma che dovremmo cambiare perché crea notevolissimi problemi di performance).
Il simulatore in azione
Moving forward
I prossimi passi sono quelli di
- Creare un interfaccia web con la quale comunicare con il simulatore (un po’ come quella di MARRtino)
- Creare una macchina virtuale che racchiuda tutto (oppure un container Docker)
- Creare nuove ambientazioni e scenari
- Implementare una scansione dei tag con barebones OpenCV per migliorare le performance e avere la possibilità di utilizzare i tag Aruco e non i qrcode veri e propri che fanno fatica per via dei dettagli etc.
- Implementare una creazione programmatica dei QRcode all’interno di queste mappe.
Anche se questi sono obiettivi che comunque richiederanno un po’ di tempo, c’è molta voglia di portarli a termine.
Questo simulatore, secondo noi, può essere una grandissima opportunità per coloro che non hanno avuto la possibilità di acquistare un ROSITA vero ma che sono comunque curiorsi e vogliosi di lavorare su questo progetto.
Tutto il nostro codice è pubblico, su GitHub, https://github.com/Fabio53443/Rosita-CoppeliaSim, e open source (licenza MIT).
Rimaniamo disponibili per qualsiasi domanda a martello@theseuscodes.uk o sugli issue di GitHub.
Il team Marte(llo) è la squadra del Liceo Scientifico Statale “L. Spallanzani” di Tivoli (RM) nel progetto Rosita-LAB2GO. È composto da Fabio Massimo Proietti (3F), Giancarlo Napoleoni (3E), Ruben Piselli (4E) e Valerio Memeo (3E)