Studente/i
Terzi Edoardo
RelatoreMattei Yari
CorrelatorePoretti Giacomo
CommittenteREX SA
Corso di laureaIngegneria informatica (TP)
ModuloC10051 Progetto di diploma
Anno2019
DataIndice
Ringraziamenti 1 Abstract 3 0.1 Italiano . . . 3 0.2 Inglese . . . 4 1 Introduzione 5 1.1 Descrizione . . . 5 1.2 Obiettivi . . . 5 1.3 Compiti . . . 5 2 Analisi 7 2.1 Requisiti . . . 7 2.2 Contesto . . . 8 2.2.1 Sovrastruttura . . . 8 2.2.2 Tipologie di binari . . . 82.3 Stato dell’arte Image Processing . . . 10
2.3.1 Framework disponibili . . . 10
2.3.2 Applicazioni simili . . . 11
2.4 Matrice Omografica . . . 12
2.5 Cos’è una Feature . . . 15
3 Tecnologie utilizzate 17 3.1 Hardware . . . 17
3.1.1 Pc per lo sviluppo . . . 17
3.1.2 Smartphone per l’acquisizione delle immagini . . . 18
3.2 Software . . . 19
3.2.1 Ambienti di sviluppo, editor . . . 19
3.2.2 Elaborazione dell’immagine . . . 20
3.3 Linguaggi e librerie . . . 21
3.3.1 Java . . . 21
3.3.2 Python . . . 21
3.3.3 OpenCV . . . 21
4 Pianificazione del lavoro 23 4.1 Diagramma di Gantt . . . 24
5 Design 27
5.1 Diagramma dei casi d’uso . . . 27
5.2 Introduzione agli approcci sviluppati . . . 28
5.3 Analisi teorica degli approcci . . . 29
5.3.1 Features Detection . . . 29
5.3.1.1 Approccio 1: Trasformata di Hough . . . 29
5.3.1.2 Approccio 2: Shape detection . . . 30
5.3.2 Calibratiore e rettifica dell’immagine . . . 31
5.4 Come acquisire l’immagine . . . 32
6 Implementazione 35 6.1 Features Detection . . . 35
6.1.1 Approccio 1: Trasformata di Hough . . . 35
6.1.1.1 Binari . . . 35
6.1.1.2 Punti . . . 37
6.1.2 Approccio 2: Shape detection . . . 39
6.1.2.1 Binari . . . 39
6.1.2.2 Punti . . . 40
6.2 Calibratiore e rettifica dell’immagine . . . 41
6.3 Interfacciamento sistema preesistente . . . 44
6.3.1 Premessa . . . 44
6.3.2 Python Java . . . 44
6.4 Soluzione implementata . . . 45
6.5 Test e risultati ottenuti . . . 47
7 Conclusioni 49 7.1 Problematiche . . . 49
7.1.1 Scelta dell’approccio corretto . . . 49
7.1.2 Misure su piani differenti . . . 49
7.2 Sviluppi futuri . . . 50
7.2.1 Utilizzo della focale . . . 50
7.2.2 Calibrazione della camera . . . 52
7.2.3 Concatenazione di più fotografie . . . 53
7.2.4 Automazione dei test . . . 53
7.2.5 Controllo online della ripresa video . . . 54
Elenco delle figure
2.1 Sovrastruttura dei binari . . . 8
2.2 Scartamento dei binari . . . 9
2.3 Quote nel dettaglio . . . 9
2.4 Esempio di funzionamento di CamScanner . . . 11
2.5 Vista di un oggetto planare come descritto dall’omografia . . . 12
3.1 Dell XPS 9570 . . . 17
3.2 Huawei P30 . . . 18
4.1 Diagramma di Gantt . . . 24
5.1 Diagramma dei casi d’uso . . . 27
5.2 Vista dei parametri m e c . . . 29
5.3 Trasformazione da trapezio a rettangolo . . . 31
5.4 Come posizionare il calibratore . . . 32
5.5 Come applicare lo scotch rosso . . . 33
5.6 Come posizionare i marker gialli . . . 33
6.1 Ricerca dei binari mediante la trasformata di Hough . . . 36
6.2 Risultato filtraggi matematici . . . 37
6.3 Rilevamento delle palline da tennis . . . 37
6.4 Filtraggio sul colore delle palline . . . 38
6.5 Nastro rosso opportunamente applicato sulla scena . . . 39
6.6 Linee rette parallele ai binari . . . 40
6.7 Punti scelti per le palline . . . 40
6.8 Foto dei binari con il calibratore poggiato sulle traversine . . . 41
6.9 Risultato della detezione evidenziato dal metodo drawChessboard() . . . 42
6.10 Prima dell’applicazione della matrice . . . 42
6.11 Dopo l’applicazione della matrice . . . 43
6.12 Diagramma di sequenza . . . 45
6.13 Quote della scena . . . 47
6.14 Foto della scena . . . 48
6.15 Passerella in AR . . . 48
7.1 Disegno esplicativo della focale . . . 50
7.2 Esempio di calibrazione della camera. . . 52
Elenco delle tabelle
Ringraziamenti
Ringrazio i miei genitori, i miei professori e relatori per tutte le conoscenze e il supporto fornito durante gli anni. Ringrazio inlotre Andrea Quattrini, che durante lo svolgimento di questo lavoro di diploma si è rilevato un valido aiuto nel proporre idee e soluzioni relative al settore dell’image processing.
Abstract
0.1
Italiano
Questo progetto nasce dalla necessità dell’azienda REX di Mendrisio di creare un sistema per la progettazione di una passerella posta fra i binari di un passo ferroviario. L’azienda in questione si occupa della produzione, della progettazione e della vendita di molteplici articoli tecnici tra i quali le passerelle.
Inizialmente il sistema, costituito da una piattaforma WEB, si occupava di ricevere in input un file DXF realizzato da un geometra dell’azienda. Questo file doveva contenere le rilevazioni del geometra, il calcolo delle griglie che costituiscono la passerella e il disegno di queste. Infine, la piattaforma generava un documento PDF contenente le istruzioni e il numero di pezzi per il montaggio della passerella. Inoltre, era possibile gestire i clienti e gli ordini effettuati mediante la piattaforma.
Attualmente, in seguito a un progetto di semestre svolto da due studenti della SUPSI, la piattaforma è migliorata mantenendo sempre l’aspetto relativo alla gestione degli ordini, dei clienti e del PDF ma è stato alleggerito il lavoro del geometra. Quest’ultimo ora deve inserire nel file DXF solamente le misure effettuate e non deve calcolare a mano le griglie necessarie alla costruzione della passerella.
L’obiettivo di questo progetto di diploma è quello di rendere ancora più semplice ed auto-matico l’utilizzo dell’intero sistema mediante l’utilizzo di tecniche di processamento dell’im-magine. In particolare, si vuole realizzare un algoritmo che sia in grado di rilevare le misure necessarie alla costruzione delle griglie che compongono la passerella partendo da una o più foto della scena, quindi del passo ferroviario dove si vuole fare il lavoro di installazione.
0.2
Inglese
This project stems from the need of the REX company in Mendrisio to create a system for the design of a footbridge between the tracks of a railway pass. This company deals with the production, design and sale of multiple technical articles including the catwalks.
Initially the system, consisting of a WEB platform, took care of receiving input a DXF file created by a company surveyor. This file had to contain the detections of the surveyor, the calculation of the grids that make up the gangway and the design of these. Finally the platform generated a PDF document containing the instructions and the number of pieces needed to assembly of the gangway. It was also possible to manage the customers and the orders placed via the platform.
Currently, following a semester project carried out by two SUPSI students, the platform has improved always maintaining the aspect related to order management, customers and PDF but the surveyor’s work was lightened. The latter must now insert only in the DXF file the measurements made and must not calculate by hand the necessary grids for the construction of the gangway.
The objective of this diploma project is to make the use of the software even more simple and automatic of through image processing techniques. In particular the will to realize an algorithm that is able to detect the measures necessary for the construction of the grids that make up the walkway starting from one or more photos of the scene, and then the pass rail where the installation will take place.
Capitolo 1
Introduzione
1.1
Descrizione
Rex SA è una società manifatturiera: uno dei molti prodotti commercializzati con il proprio marchio è relativo alla produzione di passaggi di servizio ferroviari in resina per l’attraversa-mento nelle stazioni ferroviarie e per uscite di sicurezza nelle gallerie di treno o metropolita-na, articoli commercializzati con il marchio SWISSCROSS GFK. La sfida del progetto risiede nell’implementazione di un sistema capace di creare e visualizzare in modalità aumentata (sopra una fotografia) un modello virtuale di un passaggio GFK partendo da un’immagine e attivando automaticamente i processi di produzione, consegna, installazione e, in seguito, di manutenzione del prodotto. Grazie alla soluzione proposta, REX sarà in grado di raffor-zare la propria posizione sul mercato svizzero e modificare il proprio modello di business per iniziare una vendita di servizi digitali a livello internazionale. Con il progetto si vuole incrementare la competitività dell’azienda delegando al cliente la progettazione e la visione virtuale del risultato finale in modalità “self-service” prima ancora di confermare l’ordine tra-mite la piattaforma cloud, automatizzando quindi ordinazione, produzione e delivery in un vero e proprio processo di Industria 4.0.
1.2
Obiettivi
L’obiettivo principale è quello di sviluppare un algoritmo in grado di sfruttare le metriche conosciute (scarto binari e modelli 3D di binari, traversine e viterie) per ricavare una matrice omografica tramite la quale calcolare il modello completo di una passerella sulla base di un’immagine. Allineamento e sovrapposizione dei modelli generati da più immagini verranno realizzati sfruttando appositi marcatori posizionati sul terreno. Sintetizzando l’obiettivo di questo algoritmo è quello di permettere l’estrazione dei punti caratteristici da un’immagine (features) necessari al calcolo della forma e delle misure di una passerella GFK.
1.3
Compiti
Il compito principale risiede nella creazione quindi di un algoritmo in grado di elaborare un’immagine fotografica e ricavarne la relativa matrice omografa. Tramite questa matrice si potrà "raddrizzare" l’immagine e quindi calcolare le dimensioni reali del passaggio pedonale che dovrà quindi essere visualizzato in modalità "realtà aumentata" sopra la fotografia.
Capitolo 2
Analisi
2.1
Requisiti
Dopo aver effettuato una prima discussione abbiamo messo a fuoco quelli che sono i re-quisiti di questo progetto. L’idea è quella di sostituire il lavoro del geometra aziendale (che si occupa di realizzare il file DXF) con il lavoro dell’utente il quale deve occuparsi sempli-cemente dello scatto di una foto e di un eventuale posizionamento di appositi oggetti sulla scena. Vediamo nel dettaglio la lista dei requisiti emersi:
• Analisi del contesto.
• Analisi della piattaforma esistente.
• Riconoscimento dei binari all’interno di una foto.
• Riconoscimento di 4 o più marker che definiscono la passerella.
• Calcolo della matrice omografica.
• Rettifica dell’immagine mediante la matrice omografica.
• Possibilità di effettuare misure all’interno della foto.
• Interfacciamento e integrazione con la piattaforma esistente.
• Possibilità di vedere un’anteprima della passerella sulla foto acquisita.
Essendo questo progetto un primo approccio, considereremo solamente il caso più sempli-ce durante l’implementazione dell’algoritmo. Questo caso comprende un binario con una passerella, di conseguenza servirranno solo 4 marker per realizzarla.
2.2
Contesto
Una volta definiti i requisiti principali si è resa necessaria una ricerca più approfondita su quello che è il contesto di applicazione dell’algoritmo. In particolare, ci siamo documenta-ti su come sono realizzadocumenta-ti i tracciadocumenta-ti ferroviari e quali siano le metriche conosciute udocumenta-tili al funzionamento dell’algoritmo.
2.2.1
Sovrastruttura
Figura 2.1: Sovrastruttura dei binari
1. Rotaie: le rotaie sopportano il peso del treno e lo guidano. Sono fabbricate per
laminazione: si pressa l’acciaio fuso per conferirgli la forma desiderata, come si fa con la pasta.
2. Traverse e fissaggi: le traverse assicurano il rispetto dello scartamento tra le due
rotaie lungo il tracciato ferroviario. Possono essere fabbricate in legno, calcestruzzo o acciaio. Servono anche a trasferire la pressione esercitata dal peso del treno al pietrisco sottostante. Le rotaie sono ancorate alle traverse tramite i fissaggi.
3. Pietrisco: le rocce frantumate su cui sono posate le traverse costituiscono il pietrisco.
La sua funzione è tenere in forma il binario, resistendo alle enormi forze generate da rotaie e traverse in caso di variazioni di temperatura. Permette altresì di trasmettere al suolo la forza esercitata dal peso del treno.
2.2.2
Tipologie di binari
Le ferrovie non si sono sviluppate in modo identico in tutto il mondo. Per questo motivo, lo scartamento tra le rotaie può variare notevolmente da Paese a Paese o da una compagnia ferroviaria all’altra.
Figura 2.2: Scartamento dei binari
Lo scartamento più diffuso nel mondo (60 percento delle ferrovie) è di 1’435 mm, defini-to "scartamendefini-to normale". Uno scartamendefini-to superiore è definidefini-to "scartamendefini-to largo", uno scartamento inferiore "scartamento ridotto". Ancora oggi all’interno di uno stesso Paese vengono utilizzati scartamenti diversi. In Svizzera, mentre le FFS utilizzano lo scartamen-to normale, molte compagnie regionali continuano a impiegare uno scartamenscartamen-to metrico (1’000 mm) e alcuni treni a cremagliera circolano su binari di 800 mm. Essendo più adatti ai tracciati sinuosi e permettendo di seguire più facilmente la morfologia del terreno, gli scarta-menti metrici e altri scartascarta-menti ridotti sono molto diffusi in Svizzera. Di seguito invece sono elencate le misure nel dettaglio per ogni tipologia di binario.
2.3
Stato dell’arte Image Processing
2.3.1
Framework disponibili
Di seguito vi è una lista degli strumenti maggiormente utilizzati nell’ambito del processa-mento di immagini. Abbiamo fatto questa analisi al fine di scegliere lo struprocessa-mento più adatto e compatibile per implementare una prima soluzione.
1. OpenCV: Qualsiasi discussione relativa al processamento di immagini e alla
com-puter vision è incompleta senza la menzione di OpenCV. Quest’ultimo è un ottimo strumento per fare computer vision e si integra con C++, Python e Java. OpenCV comprende tutte le tecniche e gli algoritmi necessari per eseguire diverse attività di elaborazione di immagini e video. È abbastanza facile da usare e difatti è la libreria di computer vision più popolare al mondo. È multipiattaforma e consente di creare appli-cazioni per Linux, Windows e Android. Sfortunatamente allo stesso tempo, presenta alcuni inconvenienti. Diventa un po’ lento quando si lavora su enormi set di dati o immagini molto grandi. Inoltre, da solo, non ha supporto GPU e si affida a CUDA per l’elaborazione su GPU. Nonostante questi aspetti negativi ha l’immenso vantaggio di essere molto documentato e discusso sul web.
2. Matlab: Matlab è un ottimo strumento per eseguire elaborazione di immagini ed è
ampiamente utilizzato nella ricerca. Il motivo risiede nel fatto che questo strumento consente la prototipazione rapida. Un altro aspetto interessante è che il codice Ma-tlab è piuttosto conciso, rispetto a C++, facilitando la lettura e il debug. Affronta gli errori prima dell’esecuzione proponendo alcuni modi per rendere il codice più velo-ce. Tuttavia, Matlab è uno strumento a pagamento. Inoltre, può diventare piuttosto lento durante i tempi di esecuzione, questo aspetto lo rende inadatto per "andare in produzione" poiché è stato sostanzialmente costruito per la prototipazione e la ricerca. 3. TensorFlow: TensorFlow ha guadagnato popolarità negli ultimi due anni, grazie alla
sua potenza. Quest’ultimo consente di portare la potenza del Deep Learning nella computer vision. Sfrutta ottimi strumenti per eseguire l’elaborazione e la classifica-zione delle immagini. Inoltre, integra un sistema di API scitte in Python per il ricono-scimento di volti ed espressioni. Infine, è anche possibile eseguire la classificazione usando tecniche come la regressione. Uno dei principali inconvenienti di Tensorflow è che è estremamente energivoro in termini di risorse e può letteralmente divorare le capacità di una GPU in pochissimo tempo. Inoltre, risulta essere difficile da impa-rare in quanto si basa su tecniche di Machine e Deep Learning le quali sfruttano la programmazione parallela delle GPU.
4. SimpleCV: SimpleCV è un framework semplificato per la creazione di applicazioni in
computer vision. Dà accesso a una moltitudine di strumenti come OpenCV, pygame, etc. Permette di mantenere un’astrazione ad alto livello focalizzandosi sul lavoro e risulta semplice da imparare. Tuttavia, questo vantaggio ha anche il lato negativo di rendere questo strumento poco flessibile e poco personalizzabile.
Conclusa l’analisi abbiamo scelto di usare OpenCV, in quanto come detto in precedenza risulta essere ad oggi lo strumento più versatile, potente e documentato.
2.3.2
Applicazioni simili
Dopo aver effettuato una serie di ricerche ci siamo resi conto che un’applicazione simi-le, come concetto e come ambito, attualmente non esiste. Tuttavia, un’applicazione che sfrutta gli stessi principi dell’algoritmo che si vuole sviluppare è CamScanner, come tante altre quest’app permette all’utente di fotografare e scansionare documenti con il solo au-silio del proprio smartphone. L’ambito è completamente diverso da quello dell’algoritmo di fotogrammetria che si vuole andare a sviluppare tuttavia il concetto alla base è lo stesso.
Figura 2.4: Esempio di funzionamento di CamScanner
Questa applicazione sfrutta il rilevamento dei contorni del documento, in particolare dei ver-tici, per trovare una matrice di trasformazione omografica per poi "raddrizzare" il documen-to, tagliarlo sui bordi ed aumentarne la leggibilità. Di base anche l’algoritmo che andremo a sviluppare rileva delle features per calcolare una matrice di trasformazione omografica, in seguito, raddrizzata l’immagine, l’algoritmo effettua delle misurazioni su una foto priva di effetto prospettico.
2.4
Matrice Omografica
In matematica e geometria una omografia è una relazione tra punti di due spazi tali per cui ogni punto di uno spazio corrisponde ad uno ed un solo punto del secondo spazio. In Computer Vison il concetto alla base è circa lo stesso: definiamo l’omografia planare come una “mappatura proiettiva” da una superficie a un’altra. L’esempio più classico di omografia, che viene usato da ognuno di noi quotidianamente, è sicuramente la mappatura dei punti su una superficie planare bidimensionale fatta dal sensore della nostra macchina fotografi-ca. È possibile esprimere questa mappatura come moltiplicazione di matrici. Sfruttando le coordinate omogenee definiamo un punto nella realtàQ~ e la sua “mappatura”~q effettuata dal sensore: ~ Q = X Y Z 1 e ~q = x y 1
allora possiamo esprimere l’azione dell’omografia semplicemente come:
~
q = s · H · ~Q
Nella formula appena vista abbiamo introdotto il parametro s, quest’ultimo è un fattore di scala arbitrario convenzionalmente separato daH. L’osservazione più importante è cheH
è composta da due parti: la trasformazione fisica, che localizza essenzialmente il piano dell’oggetto che stiamo visualizzando e la proiezione, che introduce la matrice intrinseca della fotocamera.
Figura 2.5: Vista di un oggetto planare come descritto dall’omografia
Nell’immagine sopra vediamo una mappatura (dal piano dell’oggetto al piano dell’immagine) che comprende contemporaneamente le relative posizioni di questi due piani e matrice di
proiezione della telecamera. La parte di trasformazione fisica è la somma degli effetti di alcune rotazioni R e alcune traslazioni~tche mettono in relazione il piano che stiamo vi-sualizzando con il piano dell’immagine. Considerando che stiamo lavorando in coordinate omogenee, possiamo combinare queste trasformazioni in una sola matrice come segue:
W = [ R ~t ]
Quindi, l’azione della matrice della fotocameraM, che già sappiamo esprimere in coordina-te proiettive, viene moltiplicata perQ~, che produce:
~ q = s · M · W · ~Q Dove: M = fx 0 cx 0 fx cy 0 0 1
Tuttavia, considerando che non ci interessa una coordinata Q~ definita su tutto lo spazio ma una coordinata Q~0 definita solo sul piano che stiamo guardando. Ciò consente una
leggera semplificazione. Senza perdita di generalità, possiamo scegliere di definire il piano dell’oggetto in modo cheZ = 0. Possiamo farlo perché, se suddividiamo anche la matrice di rotazione in tre colonne3x1(ad es. R = [ r~1 r~2 r~3 ]), una di quelle colonne non è
più necessaria. In particolare:
x y 1 = s · M · h ~ r1 r~2 r~3 ~t i · X Y 0 1 = s · M ·h r~1 r~2 ~t i · X Y 1
La matrice di omografia H che mappa i punti di un oggetto planare sul sensore è quindi descritta completamente daH = s · M · [ r~1 r~2 ~t ], dove:
~
q = s · H · ~Q0
Possiamo osservare cheHora è una matrice3x3. OpenCV utilizza le equazioni precedenti per calcolare la matrice omografica. Utilizza più immagini dello stesso oggetto per calcolare sia le singole traslazioni e rotazioni per ciascuna vista nonché i valori intrinseci (che sono gli stessi per tutte le viste). Come abbiamo discusso, la rotazione è descritta da tre angoli e la traslazione è definita da tre offset; quindi ci sono sei incognite per ogni vista. Questo va bene, perché un oggetto planare noto (come la nostra scacchiera) ci fornisce otto equa-zioni, cioè la mappatura di un quadrilatero descritto da quattro punti(x, y). Ogni frame ci fornisce otto equazioni "al costo" di sei nuovi parametri estrinseci sconosciuti, quindi date
abbastanza immagini dovremmo essere in grado di calcolare qualsiasi numero intrinseco di incognite (processo di calibrazione della fotocamera). La matrice omograficaHmette in relazione le posizioni dei punti su un piano dell’immagine sorgente con dei punti sul piano dell’immagine di destinazione (di solito il piano del sensore) nel modo seguente:
~ pdst = xdst ydst 1 = H · ~psrc e p~src= xsrc ysrc 1 = H −1· ~ pdst
Si noti che è comunque possibile calcolareH senza conoscere nulla di intrinseco della fo-tocamera. OpenCV ci fornisce una comoda funzione, findHomography(), che prende un elenco di corrispondenze e restituisce la matrice di omografia che meglio descrive tali cor-rispondenze. Abbiamo bisogno di un minimo di quattro punti per trovareH, ma possiamo fornirne molti di più (come faremmo con una qualsiasi scacchiera più grande di3x3). L’u-so di più punti è utile, perché inevitabilmente ci saranno rumori e altre incongruenze il cui effetto va minimizzato:
def findHomography ( s r c P o i n t s , d s t P o i n t s , method=None ,
r e p r o j T h r e s h o l d =None , mask=None , m a x I t e r s =None , c o n f i d e n c e =None ) : Le matrici di input srcPoints e dstPoints contengono rispettivamente i punti del piano origina-le e quelli del piano di destinazione. Questi sono tutti punti bidimensionali. Il metodo di input chiamato determina l’algoritmo che verrà utilizzato per calcolare l’omografia. Se lasciato come valore predefinito pari a 0, verranno considerati tutti i punti e il risultato calcolato sarà quello che minimizza l’errore di riproiezione.
2.5
Cos’è una Feature
In computer vision, e nell’elaborazione digitale delle immagini, il concetto di rilevamento di caratteristiche (feature detection) o riconoscimento di caratteristiche racchiude una serie di metodi per l’estrapolazione di informazioni da una immagine e per prendere decisioni locali sull’esistenza o meno di una caratteristica in quel determinato punto. Le caratteristiche risultanti saranno un sottoinsieme del dominio dell’immagine, spesso in forma di punti isolati, curve continue o regioni connesse. Non esiste una definizione universale ed esatta di cosa costituisca una caratteristica dell’immagine (image feature), e la definizione esatta spesso dipende dal problema o dal tipo di applicazione. Le caratteristiche sono usate spesso come punto di partenza da molti algoritmi di computer vision. Una proprietà desiderabile per un rilevatore di caratteristiche è la ripetibilità: la stessa caratteristica dovrebbe essere rilevata in due o più differenti immagini della stessa scena. È un’operazione di elaborazione delle immagini di basso livello, che ed esamina ogni pixel. È la prima operazione che si fa su un’immagine. Se invece fa parte di un algoritmo, allora di solito esamina solamente la regione individuata.
Capitolo 3
Tecnologie utilizzate
In questo capitolo vengono riportate e commentate tutte le tecnologie, sia hardware che software, che sono state utilizzate per l’intero svolgimento del progetto. In particolare ven-gono descritti linguaggi e librerie, editor, e strumenti utilizzati per lo siluppo e l’acquisizione di immagini.
3.1
Hardware
3.1.1
Pc per lo sviluppo
Portatile con Windows 10 Pro 64-bit:Figura 3.1: Dell XPS 9570
• Intel Core i7-8750H CPU 2.20GHz x 12
• 16 GB 2 x 8 GB DDR4 a 2.666 MHz
• PCIe M.2 2280 da 512 GB
3.1.2
Smartphone per l’acquisizione delle immagini
Smartphone Android con fotocamera tripla Leica:Figura 3.2: Huawei P30
• 40 MP IMX650 Wide (f/1.8, 27mm, 1/1.7")
• 16 MP Ultrawide (f/2.2, 17mm)
3.2
Software
3.2.1
Ambienti di sviluppo, editor
IntelliJ IDEA è un ambiente di sviluppo integrato (IDE) per il linguaggio di programmazione Java. Sviluppato da JetBrains (prima conosciuto come IntelliJ), è disponibile sia in licenza Apache che in edizione proprietaria commerciale.
PyCharm è un ambiente di sviluppo integrato (IDE), in particolare per il linguaggio Python. È sviluppato dalla società ceca JetBrains. Fornisce analisi del codice, un debugger grafico, un tester di unità integrato, integrazione con i sistemi di controllo versione (VCSes) e supporta lo sviluppo Web con Django e Data Science con Anaconda. PyCharm è multipiattaforma, con versioni Windows, macOS e Linux. La Community Edition è rilasciata con licenza Apache, c’è anche la Professional Edition con funzionalità extra, rilasciata con licenza proprietaria.
Git è un software di controllo versione distribuito utilizzabile da interfaccia a riga di comando, creato da Linus Torvalds nel 2005. Git (che nello slang americano significa idiota) nacque per essere un semplice strumento per facilitare lo sviluppo del kernel Linux ed è diventato uno degli strumenti di controllo versione più diffusi. La sua progettazione si ispirò a strumenti (allora proprietari) analoghi come BitKeeper e Monotone.
Visual Studio Code è un editor di codice sorgente sviluppato da Microsoft per Windows, Linux e macOS. Esso include supporto per debugging, un controllo per Git integrato, Syntax highlighting, IntelliSense, Snippet e refactoring del codice. È un software libero, anche se la versione ufficiale è sotto una licenza proprietaria. Visual Studio Code è basato su Electron, un framework con cui è possibile sviluppare applicazioni Node.js.
3.2.2
Elaborazione dell’immagine
Adobe Photoshop è un software proprietario prodotto dalla Adobe Systems Incorporated specializzato nell’elaborazione di fotografie (fotoritocco) e, più in generale, di immagini digitali. Questo programma è in grado di effettuare ritocchi di qualità professionale alle immagini, offrendo enormi possibilità creative grazie ai numerosi filtri e strumenti che permettono di emulare le tecniche utilizzate nei laboratori fotografici per il trattamento delle immagini, le tecniche di pittura e di disegno.All’interno di questo progetto questo software è stato molto utile al fine di non dover collo-carsi fisicamente sulla scena per effettuare una fotografia per ogni approccio tentato. Difatti è stato sufficiente apportare le modifiche necessarie alla foto al fine di testare un nuovo approccio. Nei casi in cui un determinato approccio si è rilevato essere valido abbiamo fatto delle foto reali della scena per testarlo ulteriormente
3.3
Linguaggi e librerie
3.3.1
Java
Java è un linguaggio di programmazione ad alto livello, orientato agli oggetti e a tipizzazio-ne statica, che si appoggia sull’omonima piattaforma software, specificamente progettato per essere il più possibile indipendente dalla piattaforma hardware di esecuzione (tramite compilazione in bytecode prima e interpretazione poi da parte di una JVM), sebbene questa caratteristica comporti prestazioni in termini di computazione inferiori a quelle di linguaggi direttamente compilati come C e C++ ovvero dunque perfettamente adattati alla piattaforma hardware. Il back-end dell’intera piattaforma è stato sviluppato mediante l’uso di questo linguaggio e del framework Spring MVC.
3.3.2
Python
È un linguaggio multi-paradigma che ha tra i principali obiettivi dinamicità, semplicità e flessi-bilità. Supporta il paradigma object oriented, la programmazione strutturata e molte caratte-ristiche di programmazione funzionale e riflessione. Le carattecaratte-ristiche più immediatamente riconoscibili di Python sono le variabili non tipizzate e l’uso dell’indentazione per la definizio-ne delle specifiche. Altre caratteristiche distintive sono l’overloading di operatori e funzioni tramite delegation, la presenza di un ricco assortimento di tipi e funzioni di base e librerie standard, sintassi avanzate quali slicing e list comprehension.
Abbiamo scelto di utilizzare questo linguaggio in quanto la nota libreria OpenCV, descritta in seguito, è completamente supportata e documentata. Difatti gli script in python si occu-pano esclusivamente del processamento delle immagini. Inizialmente lo sviluppo è partito in Java per motivi di compatibilità con il server, tuttavia dopo poco tempo ci siamo resi conto che l’implementazione di OpenCV in Java oltre ad essere meno documentata risulta anche meno rodata rispetto a quella in Python. Di conseguenza ci siamo imbattuti spesso in bug e in malfunzionamenti di alcune funzioni. Infine, dato che Java "gira" all’interno della JVM le prestazioni erano molto inferiori a quelle normali.
3.3.3
OpenCV
OpenCV è una libreria per Computer Vision open source disponibile su http://opencv.org. Nel 1999 Gary Bradski, lavorando presso la Intel Corporation, ha lanciato OpenCV con la speranza di “migliorare la visione del computer” e l’intelligenza artificiale fornendo una so-lida infrastruttura per tutti coloro che lavorano nel campo dell’image processing. La libreria è scritta in C e C++ e funziona su Linux, Windows e Mac OS. Esiste uno sviluppo attivo sulle interfacce per Python, Java, MATLAB e altri linguaggi, incluso il porting della libreria su Android e iOS per applicazioni mobili. OpenCV ha ricevuto gran parte del suo supporto
negli anni da Intel e Google, ma soprattutto da Itseez (recentemente acquisita da Intel), che ha realizzato la maggior parte dei primi lavori di sviluppo. Infine, la Arraiy Corporation ha aderito per mantenere OpenCV.org sempre aperto e gratuito. OpenCV è stata progettata per l’efficienza computazionale e con una forte attenzione alle applicazioni in tempo reale. È scritta in C++, infatti l’uso con questo linguaggio è la soluzione maggiormente ottimizzata, inoltre è stata progettata per sfruttare a pieno le architetture multi-core. OpenCV utilizza automaticamente la libreria IPP appropriata (designata all’ottimizzazione multi-core) in fase di esecuzione se tale libreria è installata. A partire da OpenCV 3.0, Intel ha concesso al team OpenCV e alla comunità OpenCV un sottoinsieme gratuito di IPP (soprannominato IP-PICV), che è integrato e accelera OpenCV per impostazione predefinita. Uno degli obiettivi di OpenCV è fornire un’infrastruttura di Computer Vision di facile utilizzo al fine di aiutare gli utilizzatori a creare rapidamente applicazioni abbastanza sofisticate. La libreria contiene oltre 500 funzioni che coprono molte aree della Computer Vision, compreso imaging me-dico, sicurezza, interfaccia utente, calibrazione della fotocamera, visione stereo e robotica. Questo perché la visione artificiale e l’apprendimento automatico spesso vanno “mano nel-la mano”, OpenCV contiene anche una libreria di Machine Learning completa e generica (modulo ML). Questa “sotto libreria” è focalizzata sul riconoscimento di modelli statistici e clustering. Il modulo ML è estremamente utile per i compiti di Computer Vision che sono al centro della missione di OpenCV, ma è abbastanza generale da essere utilizzata per qualsiasi problema di apprendimento automatico.
Capitolo 4
Pianificazione del lavoro
Il diagramma appena visto mostra in modo esaustivo quali sono stati i task di colore blu, ed eventualmente i "sub-task" in arancione, che hanno portato a termine il lavoro. Questo diagramma è stato fatto ad inizio lavoro ed è stato adattato in corso d’opera in quanto di-verse idee sono nate dopo aver tentato diversi approcci. Come si evince dal diagramma le prime settimane sono state dedicate interamente allo studio e alle analisi del contesto, delle tecnologie e di possibili soluzioni. Successivamente abbiamo provato ad identificare le features mediante gli algoritmi di Hough. Inseguito è stato introdotto il calibratore e solo da quel punto in poi siamo stati in grado di raddrizzare l’immagine ed effettuare le prime misure. Fatte queste ci siamo accorti che l’approccio di Hough non era sufficientemente preciso, motivo per cui abbiamo esplorato nuove soluzioni come la shape detection. Nella parte conclusiva del progetto ci siamo focalizzati principalmente sull’interfacciamento con la piattaforma esistente e sull’analisi dei risultati ottenuti mediante test sul campo. Durate l’intero svolgimento del lavoro il tutto è stato documentato man mano.
4.2
Metodologia di lavoro
Durante lo sviluppo dell’algoritmo abbiamo adottato la metodologia agile SCRUM. Abbiamo perciò diviso il nostro lavoro in sprint da una settimana. In ogni sprint vi era un incontro nel quale facevamo un punto della situazione e decidevamo i passi da svolgere nello sprint successivo. Come detto in precedenza il lavoro è stato documentato sotto forma di boz-za man mano che venivano implementate nuove funzionalità. Il codice è stato versionato mediante l’uso di GIT e della piattaforma SCM messa a disposizione dalla SUPSI. Invece la documentazione è stata carica su Google Drive in modo da poterla continuamente revi-sionare. Queste tecniche ci hanno permesso di rimanere sempre focalizzati sui requisiti da soddisfare e di evitare sprechi di tempo e di lavoro.
Capitolo 5
Design
5.1
Diagramma dei casi d’uso
Figura 5.1: Diagramma dei casi d’uso
Il diagramma sopra funge da diagramma dei casi d’uso e ha lo scopo di spiegare in mo-do grafico, e quindi semplice, l’esperienza dell’utente durante l’uso dell’algoritmo. L’idea è che l’utente in questione carichi la foto o il video della scena sul cloud. Successivamente l’immagine viene elaborata e vengono costruite le griglie sulla base delle misure effettuate dall’algoritmo. Infine, l’utente potrà vedere in realtà aumentata la passerella collocata sulla scena che ha appena fotografato. Idealmente si potrebbe sviluppare un’applicazione mobile per rendere l’esperienza utente ancora più semplice e intuitiva (sviluppi futuri).
5.2
Introduzione agli approcci sviluppati
Di seguito vediamo un elenco delle tecniche principali utilizzate sia in combinazione tra loro che con tecniche più semlici di elaborazione dell’immagine quali sfcatura, thresholding, dilatazione, ersoione, etc.
• Approccio 1 (Trasformata di Hough): questa tecninca si basa sulla trasformata di
Hough la quale ci permette di rilevare i binari e i marker che delimitano la passerel-la rispettivamente mediante le funzioni OpenCV HoughLines() e houghCircles(). In seguito è descritta la matematica e l’implementazione di questo metodo.
• Approccio 2 (Shape Detection): la shape detection sfrutta il rilevamento dei contorni
e dei colori per rilevare le features, tecnica ideale per i marker ma non per i binari, infatti abbiamo seclto di applicare del nastro adesivo colorato sopra o difianco ad essi. Risulta essere una tecnica semplice e efficace.
• Calibratore: è una semplice scacchiera in bianco e nero di dimensioni note, stampata
su carta e incollata su una superficie rigida. La libreria OpenCV mette a disposizione una serie di funzioni per rilevarlo e sfruttarlo a pieno. In particolare lo useremo per la rettifica dell’immagine e in futuro per la calibrazione della camera.
5.3
Analisi teorica degli approcci
5.3.1
Features Detection
5.3.1.1 Approccio 1: Trasformata di Hough
In computer vision esistono innumerevoli tecniche per l’estrazione delle features. Una di queste è la trasformata di Hough, utilizzata per individuare linee all’interno di una immagine. Ideata nella sua forma base agli inizi degli anni ’60 da Paul Hough, fu in seguito perfe-zionata in una forma generalizzata e resa popolare nel 1981 da Dana H. Ballard, docente di informatica dell’università del Texas. La trasformata di Hough necessita di un passo di preprocessing finalizzato all’Edge Detection (es Canny Edge Detection). L’immagine così ottenuta sarà una immagine in bianco e nero dove i pixel bianchi rappresentano gli Ed-ge, ovvero i contorni dei soggetti rappresentati. L’obiettivo della trasformata di Hough è di identificare quali di questi contorni rappresentino una linea retta: se più pixel di Edge so-no allineati, anche se so-non connessi tra loro, viene individuata una linea nell’immagine. Per rappresentare una linea retta servono due parametri: un coefficiente angolareme una or-dinata all’origine c. Considerato un singolo punto, questo appartiene a infinite rette della formay = mx + c, al variare dimec. Dobbiamo quindi stabilire quali coppie(m, c)siano in grado di individuare al meglio gli allineamenti di pixel. L’idea della trasformata di Hough è di rappresentare le rette nello spazio parametricom − c. In questo modo preso un punto
(x, y)l’equazioney = mx + candrà a rappresentare una sola retta invece di infinite. Nello spazio parametrico vengono quindi rappresentate tante rette quanti sono i pixel di edge. Se queste rette si intersecano, i due punti corrispondenti dell’immagine risulteranno allineati sulla retta con i coefficienti(m, c) corrispondenti. La tecnica sembra quindi funzionare: le rette corrispondenti ad un alto numero di intersezioni nello spazio parametrico sono le linee che volevamo ottenere.
Nei grafici sopra, i parametri m e c vengono mappati nello spazio parametrico e la linea è individuata dall’intersezione delle rette. La trasformata però in questa forma presenta dei problemi che non la rendono applicabile su un calcolatore. Infatti, per linee verticali il coefficiente angolare m tende all’infinito, contrastando le limitazioni di memoria di ogni computer. Si ricorre quindi ad una versione detta forma normale dove le rette vengono rappresentate mediante la formaxcosθ + ysinθ = r. I parametriθersono rispettivamente l’angolo e la distanza della retta dall’origine. Quantizzando θ e utilizzando come spazio parametricoθ − rsi risolve quindi il problema della finitezza della memoria.
5.3.1.2 Approccio 2: Shape detection
La shape detection è una tecnica che sfrutta il rilevamento dei contorni e dei colori per ricavare le forme presenti all’interno di un’immagine. Mediante questa tecnica è possibile risalire all’area della forma e ai suoi lati. Per far questo, generalmente si cerca di inscvrivere la figura geometrica che meglio approssima l’aera rilevata. Nel nostro progetto non si è reso necesario sfruttare anche quest’ultimo aspetto della shape detection in quanto le forme erano già tutte note.
5.3.2
Calibratiore e rettifica dell’immagine
Come visto in fase di analisi, la matrice omografica richede un minimo di quattro punti pre-senti sia nella scena fotografata che nell’immagine rettificata. Il metodo più accurato e sem-plice per avere questi punti si è rilevato essere l’uso di un calibratore. Una volta rilevati i ver-tici, (come descritto in seguito) è bastato ricondurre questi vertici ad un rettangolo anzichè un trapezio.
Figura 5.3: Trasformazione da trapezio a rettangolo
Per fare questo abbiamo ideato le seguenti formule che, avendo le coordinate del trapezio, ricavano le coordinate del rettangolo facendo una serie di medie.
A0 = Ax+ Cx 2 , Ay+ By 2 B0= Bx+ Dy 2 , A 0 y C0 = A0x , Cy+ Dy 2 D0 = Bx0 , Cy0
Ricavate tutte queste informazioni siamo riusciti a calcolare la matrice omografica corretta per rettificare l’immaigne.
5.4
Come acquisire l’immagine
Per scattare correttamente la foto è necessario di munirsi di:
• 4 markers gialli, nel nostro caso palline da tennis,
• nastro adesivo rosso largo o strisce di carta sempre rosse,
• un calibratore6x4con larghezza dei quadrati pari a 78 mm.
Successivamente occore posizionare il calibratore al centro dei binari (anche ad occhio) facedo si che sia perfettamente allineato con le traversine.
Lo scotch rosso va invece attaccato sulle traversine in 4 punti intorno al calibratore. Lo scotch va subito dopo le viti usate per il fissaggio dei binari e deve essere il più possibile parallelo al binario.
Figura 5.5: Come applicare lo scotch rosso
Infine i marker gialli andranno a definire l’area della passerella, due vanno a sinistra dei binari e due a destra. La distanza tra di loro deve essere costante a meno che non si voglia una passerella che si allarga o si restringe. Occorre tenere conto che della pallina da tennis usata viene considerato il punto centrale più basso.
Capitolo 6
Implementazione
6.1
Features Detection
6.1.1
Approccio 1: Trasformata di Hough
6.1.1.1 Binari
All’interno della libreria OpenCV la trasformata di Hough si ottiene tramite la funzione:
def HoughLinesP ( image , rho , t h e t a , t h r e s h o l d , l i n e s =None ,
minLineLength =None , maxLineGap=None ) :
• image: puntatore all’immagine ottenuta tramite un algoritmo di Edge Detection.
• rho: spessore in pixel delle linee rappresentate nello spazio parametrico. Viene
utilizzato per accorpare tra loro intersezioni vicine.
• threshold: soglia sul numero di intersezioni che si devono ottenere affinché una linea
sia identificata come tale.
• lines: struttura dove la funzione scrive le linee.
• minLineLength: rappresenta la lunghezza minima di una linea.
• maxLineGap: rappresenta a distanza tra punti sulla stessa retta, per spezzarla in due
Figura 6.1: Ricerca dei binari mediante la trasformata di Hough
Come si evince dall’immagine sopra, mediante la trasformata di Hough è possibile identifi-care i binari all’interno di una foto. Al fine di identifiidentifi-care solo i binari e non altre linee rette è necessario settare correttamente i parametri, in particolar modo il valore di threshold e la lunghezza minima delle rette. Per trovare il valore ottimale di threshold abbiamo usato la soglia OTSU calcolata sfruttando la varianza tra classi di pixel (l’algoritmo che calcola questa soglia è implementato nativamente nella libreria OpenCV). Invece per determinare la lunghezza minima delle linee abbiamo effettuato un calcolo assumendo che un binario sia lungo quanto la larghezza o lunghezza della foto. Tuttavia, si può notare come un binario può essere identificato da più rette. Inoltre, nonostante il settaggio corretto dei parametri è comunque possibile che vengano rilevate linee che non centrano nulla con i binari. L’ap-proccio scelto per risolvere questi due problemi è di tipo matematico. Per identificare un binario con una sola retta abbiamo deciso di raggrupparle sfruttando l’area sottesa alla retta trovata, ovvero l’integrale, assumendo che due rette che rappresentano lo stesso binario hanno un’area circa uguale. Infine, per identificare solo i binari e non altre linee rette abbia-mo riabbia-mosso tutte le rette che si intersecano all’interno dello spazio definito dalla foto e per maggiore sicurezza l’immagine è anche stata sfocata mediante un filtro gaussiano al fine di far rimanere in evidenza solo le linee dei binari.
Figura 6.2: Risultato filtraggi matematici
Il risultato ottenuto sembra promettere bene tuttavia, sfruttando questa tecnica si rischia di non fare distinzione tra il lato interno o esterno del binario. Inoltre, non è possibile deter-minare se la linea identifica il binari sullo stesso piano. Come soluzione abbiamo deciso di sfruttare i bulloni delle traversine messe in risalto con del nastro rosso. Posizionandone anche solo quattro è possibile identificare correttamente i binari.
6.1.1.2 Punti
Figura 6.3: Rilevamento delle palline da tennis
I punti, rappresentati da delle palline da tennis, vanno a definire l’area che verrà occupata dalla passerella. Più nel dettaglio definiscono inizio e fine del passaggio. Per rilevare in modo accurato le palline da tennis abbiamo dapprima effettuato un filtraggio sul colore giallo come segue:
Figura 6.4: Filtraggio sul colore delle palline
Nell’immagine sopra sono rimaste solo le palline il resto è stato settato a 0 (quindi nero), in questo modo ci è stato possibile ricercare i contorni delle regioni di colore giallo e identificare così i 4 punti. Per fare questo abbiamo risfruttato l’algoritmo di Hough mediante la seguente funzione:
def HoughCircles ( image , method , dp , m i n D i s t , c i r c l e s =None ,
param1=None , param2=None , minRadius=None , maxRadius=None ) :
• image: puntatore all’immagine degli edge ottenuta tramite un algoritmo di Edge
De-tection.
• method: metodo sfruttato per il rilevamento di circonferenze, l’unico attualmente
disponibile e quello del gradiente.
• dp: rapporto inverso della risoluzione (default 1).
• minDist: distanza minima tra il centro delle circonferenze rilevate.
• circles: array di output.
• param1: soglia superiore per il processo di edge detection (Canny).
• param2: soglia per il rilevamento del centro, più è bassa più si rischiano falsi positivi.
• minRadius: raggio minimo delle circonferenze da rilevare.
6.1.2
Approccio 2: Shape detection
Questo approccio abbandona completamente l’uso di Hough per il rilevamento di linee e circonferenze ma comunque sfrutta il filtraggio del colore al fine di escludere oggetti e forme irrilevanti. Una volta effettuato questo filtraggio nell’immagine ottenuta viene fatta una puli-zia del rumore effettuando un’erosione seguita da una dilatazione. Così facendo vengono rimossi quei punti troppo piccoli per essere classificati come features. Successivamente viene fatta una detezione dei contorni sfruttando il metodo messo a disposizione della li-breria OpenCV findContours(). I contorni delle aree non nere (shapes) vengono ordinati in base alla dimensione dell’area che delimitano (dalla shape più grande a quella più piccola). Infine, vengono prese in considerazione solo il numero di shape che si vuole ricercare. Nel caso delle palline da tennis 4 mentre nel caso dei binari 2.
def f i n d C o n t o u r s ( image , mode , method , c o n t o u r s =None ,
h i e r a r c h y =None , o f f s e t =None ) :
• image: puntatore all’immagine in bianco e nero.
• mode: metodo sfruttato per il rilevamento dei contorni.
• method: metodo sfruttato per l’approssimazione dei contorni.
• contours: matrice di punti in output.
• hierarchy: vettore di output contenente la topologia dell’immagine.
• offset: opzionale, definisce di quanto ogni contorno può essere "shiftato".
6.1.2.1 Binari
Non potendo definire un range di colori che isolasse in modo appropriato i binari abbiamo deciso di applicare del nastro isolante di fianco ai bulloni che tengono insieme binari e traversine:
Figura 6.5: Nastro rosso opportunamente applicato sulla scena
Una volta effettuato il classico filtraggio sul colore sono state rilevate le shapes che defi-niscono i pezzi di nastro, Successivamente sono state tracciate delle linee rette sopra il
bordo più esterno della shape rilevata. In questo modo siamo riusciti a identificare una linea parallela al binario, questa linea verrà traslata sfruttando le metriche conosciute una volta calcolato il rapporto tra millimetri e pixel.
Figura 6.6: Linee rette parallele ai binari
6.1.2.2 Punti
Come per i binari abbiamo effettuato un filtraggio sul colore, giallo in questo caso, e abbiamo identificato con buona precisone le aree che delimitano le palline. Successivamente, per ridurre al minimo l’errore è stato scelto il punto più basso di quest’area.
6.2
Calibratiore e rettifica dell’immagine
Per effettuare correttamente la rettifica dell’immagine abbiamo sfruttato due matrici omo-grafiche, la prima calcolata sui vertici in alto a sinistra dei pezzi di scotch rosso posizionati sulle traversine, la seconda calcolata sui vertici di un calibratore, ovvero una scacchiera5x7. Grazie a questo approccio è stato possibile effettuare una rettifica molto precisa riducendo al minimo le distorsioni prospettiche in lunghezza e larghezza.
Figura 6.8: Foto dei binari con il calibratore poggiato sulle traversine
Questo calibratore è stato realizzato stampando su due fogli A3 la scacchiera in questione. Ne sono note tutte le misure con precisione al millimetro. Mediante il seguente metodo, presente all’interno della libreria OpenCV siamo riusciti ad indentificarne con accuratezza i vertici.
def findChessboardCorners ( image , p a t t e r n S i z e , c o r n e r s =None ,
f l a g s =None ) :
• image: puntatore all’immagine in scala di grigi contenente il calibratore
• patternSize: dimensioni (righe per colonne) del calibratore, si intendono i vertici
quindi occorre togliere 1 ad entrambi i valori.
• corners: vettore di output.
• flags: eventuali flags aggiuntivi per specificare il metodo con cui viene rilevato il
Il risultato ottenuto è il seguente:
Figura 6.9: Risultato della detezione evidenziato dal metodo drawChessboard() Una volta rilevati i quattro vertici del nastro di scotch rosso e i quattro vertici del calibratore abbiamo ricondotto questi punti (sourcePoints), che nell’immagine formano due trapezi a causa dell’effetto prospettico, a due rettangoli come nella realtà (destinationPoints). Così facendo abbiamo sfruttato i punti per calcolare le due matrici omografiche le quali ci hanno permesso di raddrizzare l’immagine ed avere una visione dall’alto della scena.
Figura 6.10: Prima dell’applicazione della matrice
Per applicare le matrici all’immagine abbiamo utilizzato un altro metodo della libreria Open-CV:
def w a r p P e r s p e c t i v e ( sr c , M, d s i z e , d s t =None , f l a g s =None ,
borderMode=None , b o r d e r V a l u e =None ) :
• src: puntatore all’immagine originale.
• M: Matrice omografica.
• dsize: dimensioni dell’immagine di destinazione.
• dst: matrice di output.
• flags: Metodo di interpolazione dei pixel da usare.
Tuttavia, prima di applicare ogni singola matrice all’intera immagine si è reso necessario applicarla solo ai vertici dell’immagine di partenza in quanto la trasformazione omografica distorce e dilata l’immagine alterandone le dimensioni, sapendo che valore assumono i verti-ci dell’immagine di partenza abbiamo calcolato le dimensioni dell’immagine di destinazione. Sfruttando questa tecnica non ci sono state perdite di informazione (in questo caso tagli nell’immagine). Inoltre, il calibratore è stato utile anche per ricavare il rapporto tra millimetri e pixel il quale ci ha permesso di convertire le distanze tra features in mm.
6.3
Interfacciamento sistema preesistente
6.3.1
Premessa
Prima di descrivere come l’algoritmo sviluppato durante il corso di questo progetto è stato integrato nella piattaforma, vediamo come è costituita quest’ultima. Inizialmente la piattafor-ma era costituita da un applicativo sviluppato in Spring MVC il quale serviva un’interfaccia grafica lato front-end al fine di registrare ordini e clienti. Un cliente, una volta registrato ha la possibilità di inserire degli ordini fornendo una serie di dati tra cui un file DXF contente una ricostruzione in scala della scena e delle griglie usate per costruire la passerella. Infine, tutte queste informazioni vengono utilizzate per produrre un PDF contenente le istruzioni di montaggio ad hoc per quella scena. Il file DXF veniva interamente realizzato a mano da un geometra aziendale. In una seconda versione è stato introdotto il calcolo automatico delle griglie. In questo modo è stato possibile alleggerire il DXF e il lavoro del geometra. Nel pro-getto attuale, quello che si vuole fare è eliminare il lavoro manuale del geometra sostituendo il file DXF con una semplice fotografia della scena.
6.3.2
Python Java
Al fine di integrare l’algoritmo nella piattaforma è stato aggiunto un campo in fase di inseri-mento dei dati che se riempito (con una fotografia) va a sostituire il ruolo del file DXF, que-st’immagine viene elaborata nella fase in cui, nella versione precedente, si elaborava il DXF. L’elaborazione in questione avviene all’interno di un processo nel quale esegue l’algoritmo scritto in Python. Per lanciare questo processo viene utilizzato il seguente codice:
Process process = Runtime . getRuntime ( ) . exec ( " python a l g o r i t h m . py sample . j p g " ) ;
Una volta fatto questo java si collega all’input stream del processo Python e resta in attesa che quest’ultimo stampi i punti di binari e palline da tennis.
BufferedReader b u f f e r e d R e a d e r = new BufferedReader ( new InputStreamReader ( process . g e t I n p u t S t r e a m ( ) ) ) ;
Appena ricevuti e letti questi punti effettua il calcolo dei punti delle griglie autonomo e ne stampa i risultati. Infine, il processo Python, leggendo i dati delle griglie prodotti dal codice Java le disegna sull’immagine la quale viene poi salvata come file *.jpg. Quest’immagine in AR viene poi riportata all’interno del PDF contente tutte le istruzioni di montaggio.
6.4
Soluzione implementata
Figura 6.12: Diagramma di sequenza
Il diagramma in figura aiuta a spiegare nel dettaglio la soluzione implementata, in particolare mostra in sequenza i passaggi che l’algoritmo svolge per processare l’immagine fornita in input. Inizialmente vengono ricercate le palline da tennis (YellowMarkers) al fine di ritagliare l’immagine mantenendo solo l’area di interesse. La posizione delle palline va poi aggiornata in quanto diversa nell’immagine tagliata, per questo motivo le palline vengono cercate una seconda volta. In seguito, vengono ricercati i pezzi di nastro rosso posizionati sulle traversi-ne al fitraversi-ne di rilevare i binari. Dopo i binari vietraversi-ne rilevato il calibratore e sfruttando i punti di
quest’ultimo e dei binari vengono calcolate le matrici omografiche necessarie per la rettifica dell’immagine. Una volta rettificata l’immagine le posizioni di binari e palline vengono con-vertite in mm sfruttando il rapporto tra pixel e millimetri ottenuto dal calibratore e stampate. Successivamente vengono letti i punti delle griglie calcolati dal programma Java all’interno del quale esegue lo script Python e, mediante questi punti, vengono disegnate le griglie sul-l’immagine. Infine, sfruttando le inverse delle matrici omografiche applicate in precedenza, l’immagine viene riportata allo stato iniziale e salvata su file.
6.5
Test e risultati ottenuti
Per effettuare un testing accurato della soluzione implementata abbiamo sfruttato un secon-do script che usa l’algoritmo per effettuare delle misure di una scena conosciuta. Consi-derata la natura del progetto dei test automatici risultavano inutili nella maggior parte dei casi o inefficaci in quanto l’algoritmo sfrutta in serie delle funzioni di OpenCV già testate. Per questo motivo abbiamo scelto di fare un test pratico effettuando le misurazioni a mano. Nello schema seguente sono riportati i rilevamenti in mm.
Figura 6.13: Quote della scena
Come si evince dal disegno in pratica abbiamo preso le misure a mano della scena e l’abbiamo fotografata posizionando correttamente tutte le features.
Figura 6.14: Foto della scena
Successivamente abbiamo fatto girare l’algoritmo e infine abbiamo effettuato le stesse mi-surazioni sulla foto e riportato i valori in una tabella calcolando l’errore commesso.
Misura Reale (mm) Calcolata (mm) Er (%) Ea (mm)
Scartamento ferroviario 1500 1498.27 0.12 1.73 Pallina in alto a sinistra binario 826 831.42 -0.66 -5.42 Pallina in basso a sinistra binario 830 825.79 0.51 4.21 Pallina in alto a destra binario 855 883.40 -3.32 -28.4 Pallina in basso a destra binario 865 866.49 -0.17 -1.49 Distanza palline di sinistra 1700 1692.79 0.42 7.21 Distanza palline di destra 1700 1753.47 -3.15 -53.47
Tabella 6.1: Misurazioni effettuate
L’errore relativo medio risultante è del -0.89%, questo dato indica che tendenzialmente l’al-goritmo sottostima le distanze. Si può comunque notare come l’errore maggiore è presente in alto e sul lato di destra. Questo può essere causato dalla deformazione prospettica della camera utilizzata e dalla distanza e posizione di scatto. Come risultato finale, oltre alle mi-sure del caso, abbiamo prodotto una visione in realtà aumentata di come sarà la passerella una volta installata sulla scena fotografata.
Capitolo 7
Conclusioni
7.1
Problematiche
7.1.1
Scelta dell’approccio corretto
Una delle principali problematiche, dovuto anche al fatto all’inesperienza nel campo dell’i-mage processing, è stata sicuramente la scelta dell’approccio corretto. Durante la fase di analisi abbiamo definito bene i requisiti e pianificato il lavoro tuttavia la strategia di risoluzio-ne non è mai stata chiara. Inizialmente si pensava di "costruire" l’algoritmo rilevando binari e traversine all’interno della foto, procedendo con il lavoro ci siamo resi conto che questo approccio non era per niente preciso. Inoltre, fare feature detection in maniera così fine, può causare grosse imprecisioni in determinate condizioni di luce. Ad esempio, se l’utente facesse una foto al tramonto l’ombra dei binari potrebbe falsare il tutto. Sfortunatamente, come nella maggior parte dei casi, prima di rendersi conto che un approccio non è ideale per risolvere un problema occorre investire tempo e risorse ma nonostante questo tempo impiegato nella sperimentazione siamo arrivati ad una buona soluzione.
7.1.2
Misure su piani differenti
Quando abbiamo tentato l’approccio con il calibratore, eravamo in dubbio se metterlo sul piano delle traversine o rialzarlo. Facendo diversi tentativi ci siamo resi conto che il dubbio era più che sensato. Ragionandoci, se collochiamo il calibratore sul piano del suolo oppure su una sedia (per estremizzare) mantenendo lo stesso punto di scatto, il numero di pixel im-piegati dal sensore della fotocamera per rappresentare cambia di molto. Per questo motivo abbiamo scelto di collocare palline da tennis, nastri rossi e calibratore sul piano del suolo.
7.2
Sviluppi futuri
7.2.1
Utilizzo della focale
Come accennato poco fa, se posizioniamo un oggetto su un piano diverso da quello del calibratore con il quale calcoliamo il rapporto millimetri pixel risulta impossibile misurare quell’oggetto con il rapporto appena calcolato. Questo non è completamente vero, se il pia-no dell’oggetto è parallelo al piapia-no del calibratore, se si copia-noscopia-no alcuni parametri della fotocamera e se si conoscono alcune distanze nella realtà, è possibili riportare una misura su piani diversi. Questo è possibile sfruttando i criteri di similitudine dei triangoli: due trian-goli sono simili se hanno una coppia di lati proporzionali e l’angolo tra essi congruente. Lo schema sottostante ci aiuta a descrivere la situazione in modo più chiaro. Vediamo come la realtà (parte sottostante dello schema) venga rappresentata da sensore (parte sopra in grigio) il quale riporta, attraverso la lente focale, i fasci di luce riflessa dagli oggetti su di un piano fotosensibile composto da pixel. Nel dettaglio vediamo come il piano dei binari, che risulta più vicino al sensore, venga riportato su un’area maggiore di pixel mentre il piano del calibratore, essendo più lontano, occupa un’area minore. Tornando al criterio di similitudi-ne vediamo come il triangolo che ha come vertici gli estremi del piano del calibratore e la lente focale, sia simile al triangolo che ha come vertici gli estremi del piano del calibratore riportato sul sensore e la lente focale.
Per questo motivo è possibile esprimere la seguente proporzione:
∆cal_low 2 : f =
Lc 2 : x1
Osservando lo schema possiamo anche definire:
x2 = x1− ∆h
Infine, possiamo esprimere la proporzione che ci serve a ricavare la nostra incognita∆cal_high:
∆cal_high 2 : f =
Lc 2 : x2
Facendo un po’ di chiarezza definiamo tutte le variabili:
• ∆cal_low è la larghezza del calibratore in pixel che abbiamo trovato con il metodo findChessboard().
• f è la lunghezza focale del sensore della camera che stiamo usando, si trova nelle specifiche tecniche della camera.
• Lcè la larghezza del calibratore in millimetri, nota a priori.
• ∆hè l’altezza dei binari, nota a prioiri.
• x1 è la distanza tra la focale e il piano del calibratore, ricavabile dalla prima
proporzio-ne.
• x2 è la distanza tra la focale e il piano dei binari, ricavabile dalla prima equazione.
• ∆cal_highè la larghezza in pixel che il calibratore assumerebbe se fosse collocato sul piano dei binari.
Una volta trovata l’incognita è possibile calcolare un rapporto che ci consente di riportare misure effettuate su un piano su di un altro. Il rapporto sarebbe definito come segue:
R =
Lc 2
∆cal_high
Questo metodo è una soluzione alternativa, ma più complessa, al mettere tutto tutto sullo stesso piano in quanto questa soluzione potrebbe non essere sempre applicabile. Ad esem-pio, se ci trovassimo con un marciapiede, una banchina o anche solo se i binari fossero rialzati rispetto al suolo, utilizzare questi calcoli potrebbe risultare comodo.
7.2.2
Calibrazione della camera
Il processo di calibrazione della camera consente di rimuovere le deformazioni causate dalla camera. Di norma queste distorsioni si notano ai bordi dell’immagine oppure in presenza di linee rette (nella realtà) che attraversano l’intera foto formando una curva. Per effettuare questo tipo di operazione possiamo sfruttare ancora una volta il calibratore: fotografandolo da un numero considerevole di angolazioni diverse (circa 40) OpenCV è in grado di calcolare la matrice che permette di correggere le distorsioni create dalla camera. Il tutto avviene mediante il metodo calibrateCamera(). Tuttavia, questo processo andrebbe fatto ogni volta che si cambia camera. Un possibile sviluppo futuro, ipotizzando che si voglia sviluppare un’applicazione per smartphone, potrebbe essere quello di inserire una sorta di calibrazione guidata da svolgere una sola volta appena installata l’applicazione. Questo procedimento migliorerebbe ulteriormente la precisione delle misure effettuate.
7.2.3
Concatenazione di più fotografie
Il prototipo dell’algoritmo implementato attualmente considera la casistica più semplice, ov-vero quando vi è un solo binario e 4 punti per costruire la passerella. In futuro sarà re-lativamente semplice estenderlo per effettuare misurazioni anche su scene più complesse combinando più foto di più binari della stessa scena. Questo sarà possibile sempre me-diante l’omografia che, come spiegato in fase di analisi, mette in relazione i puti di due piani. Sarà quindi possibile fotografare più binari e costruire dei modelli complessi come quello in figura.
Figura 7.3: Esempio dei risultati che si possono ottenere
7.2.4
Automazione dei test
Durante lo svolgimento del progetto i test sono stati fatti a mano, riportando i dati rilevati sulla scena e nella fotografia in una tablella. In futuro si può aggiungere sulla piattaforma la possibilità di inserire come input un file contenente le misurazioni della scena footgrafata, in questo modo il sistema può produrre automaticamente un report sulle misure effettuate. In questo modo, l’utente può verificare di aver fatto tutto correttamente e che l’algoritmo ha effettuato dei rilevamenti più o meno precisi.
7.2.5
Controllo online della ripresa video
Sempre nell’ottica dello sviluppo di un’applicazione dedicata un possibile sviluppo futuro potrebbe essere quello di riprendere la scena e "in live" vedere la passerella sul video. Questo sfruttando la potenza di elaborazione del server e una connessione molto veloce. Sicuramente potrebbe essere un valido aiuto per l’utente finale in quanto potrebbe avere la possibilità di effettuare più tentativi spostandosi sui binari in modo da scegliere la posizione migliore.
7.3
Considerazioni finali
Concludendo questa prima fase del progetto possiamo affermare di essere soddisfatti dei risultati. In media l’algoritmo sbaglia del -0.89%, quindi sovrastima le distanze. Considerati i requisiti è un risultato incoraggiante e visti gli innumerevoli sviluppi futuri sicuramente si può migliorare ulteriormente questo valore. Tuttavia, ci siamo resi conto che sviluppare un algoritmo che permetta di effettuare con precisione delle misurazioni, non è per nulla sem-plice ma è comunque possibile. Il lavoro è stato stimolante e ci ha permesso di approfondire aspetti e problemi che inizialmente non erano stati considerati. Inoltre, questo lavoro è stato utile per approfondire le conoscenze nel campo dell’image processing, in particolare l’uso di OpenCV e Python, e nel campo della fotogrammetria.
Bibliografia
[1] Adrian Kaehler Gary Bradski. Learning opencv 3. COMPUTER VISION IN C++ WITH THE OPENCV LIBRARY:1018.
[2] Cannarozzo e Principi. Fotogrammetria. Zannichelli, page 33. [3] SBB CFF FFS. Comprendere meglio la ferrovia. page 12.
[4] Tiziano Leidi. Tecniche base di image processing. Fondamenti di Multimedia Processing, page 36, 2017. [5] https://docs.opencv.org/4.1.1/. [6] https://stackoverflow.com. [7] https://medium.com. [8] https://opencv-python-tutroals.readthedocs.io. [9] https://www.learnopencv.com. [10] https://www.pyimagesearch.com. [11] https://bytes.com.
Allegati
• Doucmento: "HowToRunTheAlgorithm.pdf". Comprende una serie di informazioni
