Le immagini acquisite del veicolo e i dati degli altri sensori sono salvati su un .bag file. Questo consente di registrare dati da un ROS system in esecuzione all’interno di un .bag file. Pu`o essere riprodotto per rigenerare i dati come se il sistema fosse in esecuzione oppure ogni dato pu`o essere esportato e analizzato. Ogni dato `e indicizzato dal tempo
ROS time , le immagini sono estratte dal .bag file con opportuni comandi e rinominate
left/right in caso di stereo visione seguite dal tempo in cui sono state scattate.
Le prove sono state fatte a profondit`a costante, la non uniformit`a del terreno fa si che la distanza camera-fondale vari tra 3 e 4 m.
Inizialmente `e stata impostata al minimo la torbidit`a dell’acqua. Ho composto un dataset di immagini provenienti da missioni sia a velocit`a costante che variabile, facendo avanzare il veicolo o facendolo traslare lateralmente. Missioni con componenti di velocit`a di surge e sway, inoltre combinando a queste la rotazione angolare lungo l’asse Z del veicolo. Tutte queste sono state eseguite imponendo le velocit`a al veicolo tramite la topic /DataNavigator , con questa modalit`a la dinamica del sistema e i controllori sono
disattivati, ma il veicolo si muover`a esattamente con la velocit`a imposta. In Fig.(51) `e mostrata la logica del sistema.
Figura 51: Rqt graph, topic /DataNavigator.
Per verificare la robustezza dei sistemi di VO, le stesse prove sono state eseguite con di- versi angoli di inclinazione della camera (0° - 60°) orientata come in Fig.(52), e aumentando il grado di torbidit`a dell’acqua.
Figura 52: Angolo di inclinazione della camera.
Infine per testare gli algoritmi nella modalit`a pi`u vicina alla realt`a, il G500 ha navigato autonomamente, tramite la guida a waypoint. In questa modalit`a l’heading viene conti- nuamente corretto per raggiungere il waypoint successivo e dato che il veicolo non `e neutro, la profondit`a `e mantenuta dal controllore in quanto la dinamica del sistema `e attiva. In Fig.(53) `e mostrato lo schema di comunicazione tra UWSim e la guida a waypoint.
5
Visual Odometry
L’odometria visiva `e il processo per determinare la posizione e l’orientamento di una camera analizzando una sequenza di immagini. La fotocamera scatta una sequenza di immagini (frame) indicizzate dal tempo t, tra un frame e il successivo, la camera subisce una rotazione (rollio, beccheggio, imbardata) e una traslazione (tx, ty, tz). In questo capitolo si mostra come stimare la traiettoria di una singola camera calibrata da una sequenza di immagini.
Figura 54: Stima dell’assetto di una Camera in movimento, [11].
5.1
Test sistemi stato dell’arte
Cercando fra gli algoritmi implementati di VO open-source, ho provato ad integrarli con il sistema simulato, in particolare LIBVISO2 e SVO.
5.1.1 LIBVISO2: C++ Library for Visual Odometry 2
LIBVISO2 (Library for Visual Odometry 2) `e una libreria C ++ utilizzabile sia con piat- taforme Linux che Windows, molto veloce con wrapper MATLAB per il calcolo del movi- mento a 6 DOF di una camera mono/stereo. La versione stereo si basa sulla riduzione al minimo dell’errore di riproiezione delle features sparse ed `e piuttosto generale (nessun mo- dello di movimento o restrizioni di configurazione eccetto che le immagini di input devono essere rettificate e i parametri di calibrazione devono essere noti). La versione monoculare `e ancora sperimentale e utilizza l’algoritmo a 8 punti per la stima della matrice fondamen- tale. Suppone inoltre che la camera si muova a un’altezza nota e fissa rispetto al terreno (per stimare la scala). A causa delle 8 corrispondenze necessarie per l’algoritmo a 8 punti, `e necessario disegnare molti pi`u campioni RANSAC, il che rende l’algoritmo monoculare pi`u lento dell’algoritmo stereo, per il quale 3 corrispondenze sono sufficienti per stimare i parametri. Le differenze pi`u significative rispetto a LIBVISO1 sono le seguenti:
Nessuna dipendenza dalle librerie esterne
Maggiore densit`a delle features (fino a 15.000 features matchanti)
Accelerazione del Feature matching di un fattore 10 (1.000 features richiedono circa 35 ms)
Accelerazione dell’odometria visiva di un fattore 100 (4 ms a 1.000 features)
Supporta anche la stima con camera monoculare ipotizzando un’altezza fissa della fotocamera rispetto al suolo
Ho provato ad integrare Libviso2 nel nostro ambiente simulato in versione stereo, ma i risultati ottenuti non sono stati quelli sperati, in quanto pensato per camere montate con asse ottico allineato con l’asse longitudinale del veicolo. Nel nostro caso per guardare il fondale, l’asse ottico della camera `e ruotato di 90° rispetto all’asse longitudinale del veicolo. A seguito di questo ho cercato un algoritmo che fosse pensato per camere orientate verso il basso, come nel caso di quelle montate sui droni. Indivuato l’algoritmo SVO (Fast Semi-Direct Monocular Visual Odometry) `e stato integrato in UWSim.
5.1.2 SVO: Fast Semi-Direct Monocular Visual Odometry
SVO `e un algoritmo basato sull’odometria visiva monoculare, semi-diretta, preciso, robusto e pi`u veloce degli attuali metodi all’avanguardia. L’approccio semi-diretto elimina la necessit`a di costose funzioni di estrazione delle features e tecniche di matching robusto per la stima del movimento. L’algoritmo funziona direttamente sull’intensit`a dei pixel con frame rate elevati. L’algoritmo viene testato con successo per la stima dello stato di un micro veicolo aereo in ambienti negati al GPS e funziona a 55 frame al secondo, integrato sul computer di bordo. Su un laptop consumered `e possibile far girare l’algoritmo a di pi`u di 300 fotogrammi al secondo. Il software `e open-source. La ricerca delle features `e basata sull’algoritmo FAST (Features from accelerated segment test) [20]. Il principio di funzionamento consiste nell’analizzare la luminosit`a dell’immagine intorno ad un presunto keypoint. Per capire se tale punto `e effettivamente un keypoint, viene esaminato un cerchio di 16 pixel attorno ad esso. Se `e possibile trovare un arco di punti contigui, di lunghezza maggiore a ¾ del perimetro del cerchio, in cui la luminosit`a dei pixel differisce sostanzialmente dal punto al centro, allora quest’ultimo `e un keypoint. L’algoritmo usa un trucco per aumentare la velocit`a del processo che consiste nel cominciare esaminando 4 punti separati di 90° sul cerchio, ad esempio superiore, inferiore, destro e sinistro. Si pu`o facilmente dimostrare che per soddisfare le condizioni sopraccitate, almeno 3 di questi punti devono essere pi`u luminosi o pi`u scuri del pixel centrale. Se non `e cos`ı il presunto punto chiave pu`o essere direttamente rifiutato, senza dover analizzare altri punti sulla circonferenza. Questo metodo `e molto efficace, in quanto la maggior parte dei possibili keypoint viene respinta confrontando semplicemente 4 punti. FAST `e un algoritmo molto veloce ma non possiede un descrittore per l’estrazione dei keypoints.
Integrato questo algoritmo in UWSim, `e stato riscontrato il fallimento dello stesso in quanto il metodo di estrazione di features FAST non `e efficiente con le immagini raccolte dalla nostra camera virtuale. Sebbene in alcuni punti l’algoritmo riusciva a inizializzarsi (trovando almeno 100 features) e iniziando a stimare correttamente la posizione del veicolo, dopo pochi secondi di navigazione, terminava la stima per mancanza di features. Ho provato ad abbassare le soglie minine riguradanti il numero di features, in questo caso l’algortimo continua a stimare ma perde la sua efficacia. L’inefficienza dell’algoritmo FAST per l’estrazione della features con il dataset di imaggini sottomarine virtuali, `e stata verificata anche tramite la MATLAB function detectFASTFeatures .
A seguito di questo fallimento, `e stato individuato l’algoritmo SURF:Speeded Up Ro- bust Features [17], come il miglior riconoscitore di features in relazione al dataset di im- magini virtuali sottomarine. Questo algoritmo esiste implementato in MATLAB tramite la funzione detectSURFFeatures .
Ottenute le coordinate delle features e quelle dei relativi matching tra frame succes- sivi, `e stato implementato un algoritmo di VO basato sulle leggi di geometria proiettiva presentate da Robert Collins [11]. Per risolvere l’ambiguit`a sul fattore di scala `e stata integrata la misura della distanza tra camera e fondale con un echosounder.