All’interno del macrosistema costituito dal veicolo, esistono alcuni compiti, o task, che devono essere eseguiti periodicamente e che devono terminare entro intervalli tempo ben specificati. Esistono cioè alcuni task che devono essere eseguiti in real time. I task real time sono task critici, nei quali lo sforamento della rispettiva deadline può comportare effetti dannosi sull’intero veicolo. Sul veicolo Ulisse, i sistemi di controllo a basso ed alto livello, il sistema di navigazione, e le acquisizioni dai sensori sono tutte effettuate all’interno di task real time. Attualmente Ulisse è ancora in fase di sviluppo, e task non real time (ma che dovranno presto diventarlo) sono al momento l’acquisizione delle immagini dalle videocamere e la gestione dell’obstacle detection.
Il sistema operativo Linux-RTAI [51] è stato selezionato per fornire un supporto real time al programmatore.
Per permettere l’interfacciamento tra il PC/104 ed il veicolo, sono stati appositamente sviluppati dei driver real time per la comunicazione tramite seriale su RTAI. Tali driver mettono a disposizione del programmatore una serie di funzioni che permettono la gestione delle porte seriali presenti sull’interfaccia COM1270.
Il software di controllo, guida, navigazione e di comunicazione con il veicolo, presente a bordo del PC104, è stato realizzato a partire da schemi realizzati con Simulink/Matlab. Tutte le funzionalità sono state raccolte in una libreria Simulink, e differenziate in base alla loro natura. Uno screenshot che evidenzia la libreria implementata è mostrato in Fig. 8.3.
Fig. 8.3 La libreria Simulink per la gestione di Ulisse
L’utilizzo di librerie facilita notevolmente le operazioni di manutenzione e aggiornamenti degli schemi, in quanto ogni modifica ad una libreria si ripercuote direttamente sugli schemi che ne fanno utilizzo.
Il codice C real-time, necessario per implementare gli algoritmi sul PC104, è stato ottenuto utilizzando il tool Real Time Workshop [52]. A partire da uno schema Simulink, Real Time Workshop è in grado di generare codice C/C++ per un gran numero di target presenti in commercio. Il codice generato è pronto per essere compilato sulla macchina host, e quindi mandato in esecuzione.
Ulisse può essere inoltre controllato tramite un dispositivo palmare Pocket PC, pensato per supervisionare e controllare in modo remoto il veicolo. La scelta del Pocket PC come strumento remoto di comando è stata compiuta valutando gli effettivi vantaggi e svantaggi che esso presentava:
• E’ un dispositivo maneggevole e portabile, quindi in grado di permettere all’utente la totale mobilità in uno spazio aperto
• Può essere dotato di un sistema operativo Microsoft, di semplice uso per un utente comune
• Il suo utilizzo è agevole grazie alla presenza del Touch Screen • Ha una buona autonomia di alimentazione
• La realizzazione di un software compatibile con Window Mobile è agevolata dall’ambiente di sviluppo visuale gratuitamente scaricabile dal web, simile ad altri ambienti di sviluppo Microsoft molto diffusi, come Microsoft Visual Studio
• Integra un ricevitore GPS al suo interno (non tutti i modelli in commercio, ma buona parte di essi)
• Può essere dotato di una scheda wireless su Compact Flash e supporta tutti i protocolli standard di comunicazione Ethernet come TCP/IP e UDP/IP
• Ha una buona potenza di calcolo se proporzionata alle sue dimensioni, ma questa comporta comunque una programmazione attenta all’ottimizzazione delle risorse
• Ha lo svantaggio di avere uno schermo piccolo, per cui le applicazione grafiche ne sono danneggiate
• All’esterno la luminosità dello schermo LCD può risultare insufficiente e quindi non garantire una buona visibilità
Il software è stato sviluppato con l’utilizzo dell’ambiente di sviluppo Microsoft Embedded Visual C++ 4.0, che permette la scrittura di software con linguaggio
C++ standard e l’utilizzo di librerie molto simili a quelle utilizzabili in ambienti di sviluppo come Microsoft Windows XP. L’ambiente mette a disposizione anche un emulatore in grado di riprodurre il comportamento di un Pocket PC nella quasi totalità dei casi.Il Pocket PC utilizzato per l’esecuzione del software è il modello Mio 168 prodotto da Mio Tecnology Corporation.
Fig. 8.5 Pocket PC Mio 168 prodotto da Mio Tecnology Corp.
In Tab. 8. 3 si riportano le principali caratteristiche tecniche:
CPU Intel® Xscale 300 MHz
Sistema Operativo Windows Mobile™ for Pocket PCs
Display 3.5’’ LCD TFT,
Risoluzione 240 x 320, 65.000 colori
Memoria 64 MB SDRAM
Slot di espansione SD/MMC/SDIO
Porta infrarossi Presente
Ricevitore GPS Integrato
Capacità batteria 1350 mAh,
Durata batteria 12 ore senza GPS; 5 ore e 30 con GPS;
Dimensioni 112.8 x 69.6 x 24.15 mm
Peso 147 g
Tab. 8. 3 Caratteristiche tecniche del PocketPC Mio 168
Il Pocket PC è anche dotato di una Wi-Fi Card SD prodotta da SanDisk Inc. compatibile con gli standard di comunicazione Wi-Fi 802.11b e 802.11g.
La progettazione di un’interfaccia funzionale ed “user friendly” è una caratteristica determinante per la funzionalità dell’applicazione finale. Nel caso dei Pocket PC ciò che gioca un ruolo fondamentale nella realizzazione di tutto il software sono le ristrette dimensioni del monitor. Il principale problema della applicazione creata, oltre a quello della pura scrittura del codice, è stato dover assolvere ad un grande numero di funzionalità. Il riassunto delle principali caratteristiche richieste al software ed implementate è descritto di seguito:
• La possibilità di comunicare con il veicolo tramite scheda di rete wireless.
• La possibilità di ricevere i dati rilevati dai sensori a bordo del veicolo e visualizzarli.
• La possibilità di ricevere lo streaming video delle webcam a bordo del veicolo.
• La capacità di inviare dei comandi al veicolo, primo tra i quali un comando di reset del sistema.
• La capacità di ricevere i dati GPS tramite il ricevitore integrato e visualizzarli.
• La possibilità di immissione di waypoint tramite un motore grafico e la capacità di comunicare al veicolo la lista dei waypoint da seguire. Si è posta dunque la questione di come rendere l’interfaccia facilmente utilizzabile ed allo stesso tempo capace di supportare e garantire tutti i requisiti sopra citati.
La soluzione adottata si è basata sulla suddivisione dell’applicazione in tabs (schede), ognuna delle quali potesse essere ricondotta ad una specifica categoria di funzionalità.
In particolare i tabs realizzati sono cinque:
• Il tab Info è adibito alla visualizzazione dei dati forniti dal ricevitore GPS integrato nel Pocket PC.
• Il tab Video permette ricevere i dati di telemetria del veicolo e lo streaming video delle webcams.
• Il tab Command è uno dei tab principali dell’applicazione e permette l’invio al kart di tutti i possibili comandi implementati.
• Il tab Graphic consente di caricare una mappa arbitraria del luogo in cui si trova il veicolo, visualizzare la posizione del veicolo sulla mappa, inserire, eliminare e modificare graficamente i waypoint sulla mappa ed accedere ad altre funzionalità grafiche avanzate.
• Il tab Settings permette l’impostazione dei parametri di comunicazione, di grafica, etc.
97
9
ROBUST POSE ESTIMATION
ALGORITHM
9.1 Introduzione
Il volo in formazione autonomo, ed il rifornimento in volo automatico, costituiscono attualmente due importanti settori della ricerca aerospaziale. Nel volo in formazione, il controllo di ogni singolo veicolo è di importanza cruciale, e molte soluzioni sono state proposte in letteratura [ 53, 54, 55], tutte prendendo in considerazione le informazioni a 6DOF dell’aereo leader e degli altri veicoli. Un tipico approccio è quello di considerare un ricevitore GPS per stimare le posizioni dei veicoli, e di utilizzare una comunicazione radio per inviare la propria posizione agli altri componenti della flotta.
Nel rifornimento in volo automatico lo scenario è costituito da due velivoli: l’aereo cisterna (tanker), pilotato manualmente e contenente il carburante, ed un UAV che deve ricevere il carburante.
Due metodi sono attualmente utilizzati: il Boeing flying boom ed il metodo
probe-and-drogue. Il primo tipo utilizza un tubo rigido, il boom, gestito
manualmente da un operatore a bordo dell’aereo cisterna. In tal caso, l’UAV deve essere capace di mantenere la posizione e l’assetto relativo rispetto al tanker. Lo scenario e le dinamiche del rifornimento Flying Boom sono molto simili al volo in formazione, e quindi il rifornimento può essere ottenuto per mezzo di un preciso e stabile posizionamento relativo con l’UAV. Nel metodo probe-and-drogue, il tanker srotola un cavo flessibile all’interno del quale scorre il carburante. Al termine del cavo è posizionato il drogue, una sorta di “cesto” che permette l’inserimento del probe, posizionato sull’UAV, all’interno del tubo. Il tubo flessibile fluttua nell’aria, soggetto alle forze aerodinamiche. Assumendo l’assenza di perturbazioni atmosferiche e la contemporanea situazione di volo stabile, la scia del tanker cambia con la temperatura dell’aria, condizioni di volo e altitudine. All’interno di queste condizioni il tubo può raggiungere una posizione stabile, ma sempre soggetta ai disturbi ambientali. Benchè possa essere utilizzato un sistema di localizzazione basato esclusivamente su GPS, la presenza di potenziali disturbi e perdita del segnale
può in teoria non permettere il successo della missione. Un sistema alternativo, già molto utilizzato nel settore della robotica mobile e computer vision [ 56- 62], è l’utilizzo della visione artificiale, tramite la quale è possibile stimare la posizione relativa tra una fotocamera ed un oggetto.
Una tipica suddivisione degli algoritmi di pose estimation separa quelli iterativi [62-65] da quelli non iterativi [59,60,61,66,67].Molti algoritmi di localizzazione sono oggi documentati in letteratura; tuttavia, solo pochi di essi potrebbero essere utilizzati in questo contesto, sia per la scarsa accuratezza che per l’inaffidabilità nelle stime di localizzazione.
Inoltre, studi sulla visione applicata al settore aeronautico non sono ancora molto numerosi. Un buon numero di lavori sono stati proposti per il volo autonomo di elicotteri; molte ricerche stanno inoltre avanzando nel campo dei micro-UAV, in cui i sistemi di visione sembrano essere diventati fondamentali per la navigazione.
In [ 68] è stato sviluppato un sistema di visione per il volo in formazione; ciascun velivolo è dotato di una singola telecamera puntata verso il basso, e di un puntatore laser che emette un fascio di luce a forma di croce. Per distinguere i veicoli ciascun fascio laser emesso viene modulato opportunamente. Tale soluzione, comunque, presenta delle inevitabili difficoltà. I velivoli devono volare parallelamente al suolo, e sul terreno non devono essere presenti asperità da pregiudicare la corretta rilevazione delle signatures da parte dei veicoli della flotta.
In [ 69] viene proposto, un sistema di visione per la stima di posizione e orientamento di un elicottero. Tale sistema si basa sull’utilizzo di due telecamere, una posizionata a terra, l’altra fissata sul veicolo. L’algoritmo, molto semplice da implementare, sfrutta la presenza di alcuni marker ottici fissati sulla telecamera a terra e sotto l’elicottero. Il punto debole dell’intero sistema sta nel fatto che le due telecamere, per costruzione stessa dell’algoritmo, devono essere sempre puntate una verso l’altra. Nel caso di voli a cielo aperto, tale assunzione può diventare molto difficile da garantire.
In [ 70] viene proposto un sistema di visione per l’atterraggio automatico di un elicottero.
Nuovi algoritmi vengono presentati in [ 71] per la stima di posizionamento e orientazione relativi di velivoli in formazione. Tali algoritmi possono essere utilizzati anche nel caso di refueling aereo. L’approccio è quello classico feature-based: alcuni marker ottici sono fissati in geometria nota sul corpo del quale se ne vuole conoscere la posizione rispetto al sensore ottico. A partire dalla geometria 3D dei marker e dalle rispettive proiezioni sul piano focale della telecamera, è possibile stimarne il posizionamento relativo. In questo caso, i marker sono realizzati mediante LED, ciascuno modulato opportunamente in modo da risultare perfettamente distinguibile dagli altri. Una particolare tecnologia, denominata VISNAV [ 72 73] (VISion-based NAVigation), che utilizza un nuovo tipo di sensore analogico, è comunque necessaria.
Nel presente lavoro lo scopo è presentare un sistema che si svincola dall’utilizzo di hardware dedicati o tecnologie particolari, in modo tale da adottare hardware facilmente reperibile in commercio ed a basso costo. Nel sistema descritto in questo capitolo [ 74- 77], una tradizionale telecamera ed alcuni LED infrarossi sono sufficienti per ottenere stime molto accurate e robuste. In particolare,
LHM, è attualmente in letteratura l’algoritmo che permette di ottenere le stime relative di posizione e rotazione con la miglior accuratezza, ed è particolarmente performante rispetto a molti altri algoritmi in tutti quei casi in cui le informazioni provenienti dalla telecamera sono corrotte da rumore.
Dalla conoscenza della posizione 3D di alcuni marker posizionati su un oggetto, e dalla posizione 2D delle rispettive proiezioni (feature) sul piano focale della telecamera, è possibile determinare la trasformazione che lega il sistema di riferimento fissato sull’oggetto con quello fissato sulla telecamera. La ricostruzione delle corrispondenze tra i punti 3D e le rispettive proiezioni 2D viene calcolata basandosi su un algoritmo noto come algoritmo ungherese [ 78], che fornisce un assegnamento ottimo, seguito da una tecnica descritta in [ 79].