ITA - Progettazione e valutazione sperimentale di un sistema per la definizione ed applicazione di regole per il traffico di droni in ambiente urbano ENG - Design and experimental evaluation of a system for the definition and application of rules for UAVs traffic in the urban environment

1. UNIVERSIT`A DEGLI STUDI DI TRIESTE
DIPARTIMENTO DI INGEGNERIA E ARCHITETTURA
Tesi di Laurea Magistrale in Ingegneria Informatica
Progettazione e valutazione sperimentale di un sistema
per la definizione ed applicazione di regole per il traffico
di droni in ambiente urbano
LAUREANDO RELATORE
Giuseppe Lombardi Chiar.mo Prof. Eric Medvet
Universit`a degli Studi di Trieste
CORRELATORE
Chiar.mo Prof. Alberto Bartoli
Universit`a degli Studi di Trieste
Anno Accademico 2016/2017

3. Ai miei genitori e a mio fratello Giovanni.

5. Indice
1 Introduzione 2
1.1 Il presente ed il futuro dei droni . . . . . . . . . . . . . . . . . 2
1.2 Soluzione proposta . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Stato dell’arte . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Il modello 6
2.1 Spazio, edifici e droni . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Il controllore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Controllore A* . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Controllore Arco-quadro (AQ) . . . . . . . . . . . . . . 10
3 Le regole 11
3.1 Le regole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Esempi di regole . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Validazione sperimentale 15
4.1 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1 Ulteriori esperimenti . . . . . . . . . . . . . . . . . . . 17
5 Neuroevolution 25
5.1 Controllo tramite rete neurale . . . . . . . . . . . . . . . . . . 25
5.2 NEAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6 Conclusioni 32
Bibliografia 32
Ringraziamenti 35

6. Capitolo 1
Introduzione
1.1 Il presente ed il futuro dei droni
Al giorno d’oggi la popolarit`a degli aeromobili a pilotaggio remoto, pi`u
comunemente conosciuti come droni, `e in continua crescita grazie alla loro
estesa variet`a di applicazioni: dalla sicurezza urbana all’utilizzo per scopi
militari, dalla vigilanza del traffico alla pi`u recente consegna di beni o servizi
messa in atto dalle grandi aziende di commercio. Proprio a causa di questo
aspetto, esistono modelli di droni diversi tra loro per conformazione fisica,
dimensioni e pilotaggio—il quale pu`o essere messo in atto da un operatore
umano remoto, cos`ı come da un controllore a bordo dello stesso drone—oltre
ad essere accessoriati opzionalmente di videocamere e sistemi di tracciamento
GPS in base alla funzione per la quale sono predisposti.
Oggi il vero limite alle diverse applicazioni `e dovuto alla scarsa autonomia
di volo; rimanere in aria oltre i trenta minuti `e davvero difficile per questioni di
autonomia delle batterie. Per questo motivo uno dei primi miglioramenti che
ci si aspetta in questo settore `e la nascita di nuove tecnologie per alimentare
i droni, allargando enormemente il loro campo applicativo.
Per dare un’idea di quanto questo settore di mercato sia in aumento,
soprattutto da un punto di vista innovativo e tecnologico, basti pensare che
nel solo 2015 sono stati venduti all’incirca centomila droni per la fascia di
prezzo 400–500e, dimostrando che il trend sta subendo una crescita pi`u
rapida di altri settori.
Nonostante i cieli delle nostre citt`a non siano ancora invasi da questi
dispositivi, `e facile immaginare un futuro nel quale le nostre moderne citt`a
evolveranno in smart cities, rendendo ogni sottosistema dell’ambiente urbano
interconnesso e permettendo ai droni di occuparne lo spazio aereo. Questi
particolari droni dovranno essere in grado di prendere un corposo numero di
2

7. decisioni in tempo reale, con una percezione limitata e possibilmente rumorosa
dell’ambiente circostante; queste decisioni devono considerare la necessit`a di
evitare collisioni con edifici ed altri oggetti, ma al tempo stesso permettere ai
droni di eseguire un determinato compito (es. raggiungere una destinazione
finale per la consegna di un pacco). I droni presentano un certo numero di
sfide: potenza di calcolo limitata, un numero limitato di attuatori e di sensori
di bassa qualit`a.
Alla luce di questa previsione, risulta evidente che l’obbiettivo di assicurare
efficienza e sicurezza del traffico aereo urbano non pu`o essere perseguito agendo
sul solo controllore del drone, principalmente perch´e l’insieme degli attori
coinvolti in questo scenario (autorit`a di controllo, fabbricanti, utilizzatori) sono
molti e diversificati. Un’opzione alternativa consiste nel formulare ed imporre
una regolamentazione comune, similmente a come `e stato fatto nel caso del
traffico stradale nelle prime fasi del suo sviluppo. Tuttavia, attualmente non
esiste ancora un sistema di regole ufficiale, specifico del settore e soprattutto
che sia ampiamente utilizzato: per questo motivo diverse comunit`a (es. grandi
aziende come Google, Amazon, etc., o commissioni specifiche) stanno ancora
discutendo diversi scenari nei quali il traffico di droni possa essere regolato
da un sistema di controllo centralizzato oppure indipendentemente a bordo
di ciascun drone.
Queste premesse sono quindi alla base di molti spunti di riflessione quali:
(i) `e possibile generare un insieme di regole tali per cui si possano migliorare
l’efficienza e la sicurezza del traffico urbano? (ii) quale linguaggio deve essere
scelto per esprimere le regole? (iii) come impatta la scelta del controllore in
termini di efficienza e sicurezza? (iv) in che modo impattano le regole sui
diversi algoritmi di controllo del drone? (v) `e possibile generare automati-
camente un controllore per il drone? (vi) che impatto hanno le regole sul
controllore generato automaticamente?
Questi stessi interrogativi hanno ispirato e guidato il lavoro di tesi, il
quale propone le basi per condurre diversi tipi di indagini ed inoltre esplora
gli scenari sopra elencati.
1.2 Soluzione proposta
Innanzitutto `e stato proposto un modello per il traffico aereo urbano il
quale include edifici, droni ed i loro controllori che conoscono ed eventual-
mente rispettano le regole; successivamente questo modello `e stato valutato
sperimentalmente.
In secondo luogo `e stato proposto un linguaggio (sintassi e semantica)
per definire regole che possono essere imposte nel nostro modello: il rispetto
3

8. delle regole pu`o essere valutato a bordo e direttamente, indipendentemente
dall’algoritmo usato dal controllore del drone per la navigazione, e soprattutto
senza la necessit`a di comunicare con gli altri droni o autorit`a centralizzate. Il
linguaggio `e abbastanza espressivo da poter definire regole di una complessit`a
realistica come “quando in volo, mantenere un’altitudine minima” oppure
“mantieni una distanza minima dagli edifici”. Quindi, `e stato validato il modello
(con e senza regole) per mezzo di un alto numero di simulazioni: i risultati
evidenziano l’impatto coerente dell’introduzione delle regole sull’efficienza e
sicurezza del traffico dei droni in ambiente urbano.
Infine, come terzo ed ultimo contributo, si `e esplorata la possibilit`a di
generare un controllore per i droni in maniera automatica per mezzo di
Neuroevolution, nel caso in cui il traffico fosse regolato e non: gli individui
sono reti neurali che rappresentano il controllore del drone e la loro fitness
misura la capacit`a di far muovere il drone facendolo avvicinare al punto di
arrivo. Questo ha permesso di determinare nuovamente il solido impatto
delle regole per quanto riguarda la capacit`a di generare un controllore per un
ambiente regolato.
1.3 Stato dell’arte
Allo stato dell’arte vi `e solo uno studio il quale propone una metodologia per
regolare il traffico dei droni in uno scenario completamente decentralizzato,
per mezzo della Defeasible Logic [6]. Il lavoro citato si diversifica da questo
in quando il sistema di regole proposto richiede la comunicazione tra i droni
(quando devono essere risolti i conflitti) e non `e completamente indipendente
dall’algoritmo di navigazione.
Un linguaggio molto simile a quello proposto, ma focalizzato sul traffico
stradale, `e stato proposto in [9] nella forma di una grammatica context-free,
come nel nostro caso. Inoltre gli autori hanno usato il linguaggio proposto per
generare automaticamente, per mezzo di Grammatical Evolution, un nuovo
insieme di regole che pu`o migliorare l’efficienza e sicurezza del traffico.
Un altro tentativo di regolare i droni `e stato fatto in [8], lavoro nel quale gli
autori propongono un metodo basato su Genetic Algorithm (GA) per generare
un insieme di istruzioni capaci di guidare i droni. Tuttavia nell’articolo citato
si considera uno scenario militare nel quale i droni monitorano i nemici in un
ambiente aperto, piuttosto che in quello urbano.
Molta pi`u ricerca invece si `e focalizzata nel tentativo di costruire sistemi
centralizzati o decentralizzati per la gestione del traffico di droni [19, 20]: que-
sti lavori condividono un obiettivo di alto livello, ovvero quello di formalizzare
4

9. come il traffico dei droni si svilupper`a in modo da assicurare la sua efficienza
e sicurezza.
Per quanto riguarda il controllore dei droni gli approcci esplorati in
letteratura sono molti e tutti diversi tra loro—proprio perch´e `e un compito
molto impegnativo dal momento che `e richiesta una profonda conoscenza
ingegneristica del comportamento dei velivoli: dalle tecniche di controllo PID
tradizionale [10, 5] allo sviluppo di un controllore fuzzy, come viene fatto in [2];
altri lavori concentrano invece la propria analisi sulla ricerca del percorso
ottimo [13, 7].
Molta ricerca si concentra sulla creazione di controllori per mezzo di
tecniche di Evolutionary Computation, come gi`a da tempo si fa nel campo
della robotica [14]. In [4] si utilizza GA per l’evoluzione di un algoritmo di
controllo che consenta ai droni di piccole dimensioni l’atterraggio ottimale;
in [12] viene esplorata l’ipotesi di una Neuroevolution del controllore: in
questo lavoro per`o l’attenzione `e rivolta principalmente alla sicurezza del
singolo drone, differentemente da come viene fatto in questa tesi, in cui ci si
concentra innanzitutto sulla sicurezza ed efficienza di sistema in un ambiente
urbano regolato da un insieme di regole.
5

10. Capitolo 2
Il modello
Consideriamo uno scenario con spazio discreto e tempo discreto nel quale
esistono edifici e un numero arbitrario di droni si muove, eventualmente
collidendo con altri droni o con gli edifici.
2.1 Spazio, edifici e droni
Lo spazio `e un insieme finito e discreto S = [0, lS
x ] × [0, lS
y ] × [0, lS
z ] ⊂ N3
.
Chiameremo cella un punto di S: una cella `e definita dalle sue coordinate
(x, y, z).
Un edificio `e un sottoinsieme dello spazio corrispondente a un parallelepi-
pedo la cui faccia inferiore `e situata sul piano con z = 0, ovvero il suolo. Un
edificio `e definito da una posizione x0, y0 e tre dimensioni lx, ly, lz: una cella
(x, y, z) appartiene a un edificio se e solo se x ∈ [x0, x0 + lx], y ∈ [y0, y0 + ly],
e z ∈ [0, lz]. Denoteremo con B l’insieme di tutti gli edifici nello spazio S.
Un drone `e un agente che si pu`o muovere nello spazio. Il drone `e definito
dalla sua posizione (x, y, z), il suo stato s ∈ {alive, collided}, il suo controllore,
e la sua cella di destinazione (xf , yf , 0). Ad ogni istante di tempo, un drone
pu`o essere stocasticamente coinvolto in una collisione, la quale rende il
suo stato impostato a collided. In particolare, una collisione avviene se `e
riscontrata una delle seguenti condizioni:
• la posizione del drone appartiene ad un edificio (cio`e, ∃B ∈ B | (x, y, z) ∈
B) e un numero casuale in [0, 1] `e minore di pB,inside;
• la posizione del drone `e adiacente a una cella che appartiene a un
edificio (cio`e, tale che la distanza Manhattan tra la posizione e la cella
dell’edificio `e esattamente 1) e un numero casuale in [0, 1] `e minore di
pB,close;
6

11. • per ogni altro drone nella stessa posizione, un numero casuale in [0, 1] `e
minore di pU,same;
• per ogni altro drone in una cella adiacente, un numero casuale in [0, 1]
`e minore di pU,close.
Negli ultimi due casi (collisioni con altri droni), anche lo stato dell’altro drone
`e impostato a collided.
Dopo aver controllato le collisioni, la posizione di ciascun drone `e aggior-
nata in accordo alla seguente procedura. Se lo stato del drone `e s = collided
e z > 0, allora (x, y, z) → (x, y, z − 1)—cio`e, il drone cade. Se lo stato del
drone `e s = alive, la nuova posizione `e determinata dall’output del controllore
m ∈ M, dove M `e l’insieme di tutti i possibili movimenti descritto nella
Tabella 2.1. Altrimenti (cio`e, se il drone `e colliso e si trova gi`a a terra o si
trova sopra il tetto di un edificio), la posizione rimane invariata. In altre
parole, la velocit`a del drone `e compresa nell’intervallo [0;
√
3] cella per istante
di vita.
2.2 Il controllore
Il controllore del drone `e un algoritmo il quale, ad ogni istante di tempo,
elabora un input che corrisponde alla percezione dello spazio circostante al
drone con lo scopo di produrre un output m ∈ M (l’insieme M di tutti i
possibili movimenti `e presentato nella Tabella 2.1) il quale determina come la
posizione del drone deve essere aggiornata (vedi Sezione 2.1). Il controllore
pu`o essere con stato (ovvero il suo output pu`o dipendere anche dallo stato
interno che `e il risultato di precedenti elaborazioni) e non deterministico.
Pi`u in dettaglio, l’input del controllore di un drone u consiste di:
1. l’insieme B di edifici e la grandezza lS
x , lS
y , lS
z dello spazio S;
2. la posizione degli altri droni la cui posizione appartiene al cubo con lato
di lunghezza pari a 2v+1 e centrato nella posizione di u (cio`e, la posizione
(x′
, y′
, z′
) di ogni drone tale che x′
∈ [x − v, x + v], y′
∈ [y − v, y + v], e
z′
∈ [z − v, z + v]);
3. la cella di destinazione (xf , yf , 0) di u;
4. una funzione r : S → {allowed, denied} che mappa ogni cella dello
spazio in un valore binario che rappresenta se quella cella, all’istante di
tempo corrente e dal punto di vista del drone u, pu`o (allowed) o non
pu`o (denied) essere occupata.
7

12. Tabella 2.1: Insieme di tutti i possibili movimenti restituiti in output dal controllore del
drone
m ∈ M (x(k)
, y(k)
, z(k)
) → (x(k+1)
, y(k+1)
, z(k+1)
)
∅ (x, y, z) → (x, y, z)
+1x (x, y, z) → (x + 1, y, z)
−1x (x, y, z) → (x + 1, y, z)
+1y (x, y, z) → (x, y + 1, z)
−1y (x, y, z) → (x, y − 1, z)
+1z (x, y, z) → (x, y, z + 1)
−1z (x, y, z) → (x, y, z − 1)
+1x + 1y (x, y, z) → (x + 1, y + 1, z)
+1x − 1y (x, y, z) → (x + 1, y − 1, z)
+1x + 1z (x, y, z) → (x + 1, y, z + 1)
+1x − 1z (x, y, z) → (x + 1, y, z − 1)
−1x + 1y (x, y, z) → (x − 1, y + 1, z)
−1x − 1y (x, y, z) → (x − 1, y − 1, z)
−1x + 1z (x, y, z) → (x − 1, y, z + 1)
−1x − 1z (x, y, z) → (x − 1, y, z − 1)
+1y + 1z (x, y, z) → (x, y + 1, z + 1)
+1y − 1z (x, y, z) → (x, y + 1, z − 1)
−1y + 1z (x, y, z) → (x, y − 1, z + 1)
−1y − 1z (x, y, z) → (x, y − 1, z − 1)
+1x + 1y + 1z (x, y, z) → (x + 1, y + 1, z + 1)
+1x + 1y − 1z (x, y, z) → (x + 1, y + 1, z − 1)
+1x − 1y + 1z (x, y, z) → (x + 1, y − 1, z + 1)
+1x − 1y − 1z (x, y, z) → (x + 1, y − 1, z − 1)
−1x + 1y + 1z (x, y, z) → (x − 1, y + 1, z + 1)
−1x + 1y − 1z (x, y, z) → (x − 1, y + 1, z − 1)
−1x − 1y + 1z (x, y, z) → (x − 1, y − 1, z + 1)
−1x − 1y − 1z (x, y, z) → (x − 1, y − 1, z − 1)
8

13. Le quattro componenti di input rappresentano, rispettivamente: (i) la co-
noscenza illimitata degli oggetti non in movimento (cio`e, edifici)—in altre
parole, assumiamo che una mappa dello spazio `e disponibile al controllore;
(ii) la conoscenza degli oggetti in movimento (cio`e, altri droni) nelle vicinanze
del drone; (iii) la destinazione del drone stesso; (iv) la conoscenza degli effetti
risultanti dall’applicazione delle regole vigenti, dal punto di vista del drone
stesso.
Riguardo alla funzione r, la quale definisce le regioni di spazio permesse e
negate, si rimarcano tre considerazioni—la descrizione di come r `e determinata
`e fornita nella Sezione 3.1.
Primo, la funzione stessa pu`o essere differente per diversi droni o addirittu-
ra per lo stesso drone in diversi istanti di tempo: per esempio, una regola che
dichiara, informalmente, che “deve essere mantenuta una distanza minima di
sicurezza dal drone pi`u vicino” risulter`a in diverse regioni vietate in diversi
istanti, se il drone pi`u vicino `e in movimento.
Secondo, dal momento che si `e deciso di modellare il concetto di regola
con una funzione r la quale, fondamentalmente, marca alcune regioni dello
spazio come negate, invece di marcare le azioni stesse come negate (es., “non
pu`o muoverti verso l’alto”), la scelta pu`o essere estesa ad astrazioni pi`u
sofisticate, come, per esempio, spazio continuo, o droni che si spostano a
velocit`a differenti.
Terzo, le regioni negate e definite da r sono in realt`a solamente uno degli
input del controllore: un controllore specifico potrebbe ignorarlo. Questo
permette di modellare, e quindi indagare, interessanti interazioni che coin-
volgono per il controllore il trade-off tra la necessit`a di raggiungere la cella
di destinazione e la volont`a di rispettare le regole e gli indici globali come
l’efficienza e la sicurezza del traffico.
Nel lavoro qui presente, sono stati considerati due diversi controllori, di
cui seguono le descrizioni.
2.2.1 Controllore A*
A* `e un algoritmo comunemente usato nel pathfinding [3], il quale `e un’esten-
sione dell’algoritmo di Dijkstra. Data una posizione di partenza, A* esplora
tutti i possibili percorsi che conducono alla posizione di destinazione, consi-
derando prioritariamente quelli che hanno costi minori. Per questa ragione,
l’algoritmo `e capace di trovare il percorso minimo evitando gli ostacoli, e
quindi `e un buon candidato ad essere utilizzato come controllore dei droni
nel nostro modello.
Nel nostro caso, A* considera come ostacolo una cella che appartiene ad
un edificio, oppure `e occupata da uno o pi`u droni, oppure `e vietata dalle
9

14. regole. Dal momento che, sulla base di questa definizione, gli ostacoli possono
cambiare nel tempo, questo controllore riapplica l’algoritmo A* in ogni istante
di tempo. Nel nostro simulatore inoltre sono state codificate due varianti
alternative di A*: la prima, pi`u semplice, consente ai droni di muoversi
solamente lungo le tre direzioni perpendicolari, mentre la seconda consente ai
droni anche spostamenti in diagonale.
2.2.2 Controllore Arco-quadro (AQ)
Questo `e un controllore pi`u semplice il quale realizza il seguente compor-
tamento: (i) raggiunge un’altitudine di sicurezza muovendosi solo in alto
(m = +1z); (ii) se gi`a all’altitudine di sicurezza, raggiunge la coordinata
xf della cella di destinazione muovendosi solo sull’asse x (m ∈ {+1x, −1x});
(iii) se gi`a all’altitudine di sicurezza e con x = xf , raggiunge la coordinata yf
della cella di destinazione muovendosi solo sull’asse y; (iv) se sopra la cella di
destinazione, raggiunge il terreno muovendosi solo in basso (m = −1z).
L’altitudine di sicurezza zs `e determinata considerando tutti gli edifici,
le celle occupate da uno o pi`u droni e le regioni vietate la cui proiezione
interseca il percorso pianificato sul piano x, y (che ha sempre una “forma ad
L”): zs `e impostata alla prima cella libera, e nel caso in cui tale definizione
porti ad avere zs > nz, `e impostata a nz. Dal momento che le regioni vietate
possono cambiare nel tempo, l’altitudine di sicurezza viene ricomputata ad
ogni istante di tempo: da notare che il drone comunque non scender`a di quota
a meno che non si trovi sopra la cella di destinazione.
10

15. Capitolo 3
Le regole
3.1 Le regole
Si descrive in questa sezione come `e costruita la funzione r, la quale determina
le regioni di spazio negate, al corrente istante di tempo e per uno specifico
drone u. In breve, r `e costruita partendo da un insieme R di regole, espresse
sulla base di un linguaggio predefinito, e valutate sulla base del contesto del
drone (posizione, edificio, altri droni vicini).
Una regola `e una coppia R = (P, c), dove P `e un insieme non vuoto di
boxes e c `e una condizione. Un box `e definito da una tupla (x0, y0, z0, l, t, i),
dove x0, y0, z0 rappresentano la posizione del centro del box, l ≥ 0 determina la
lunghezza 2l+1 del lato del box, t ∈ {full, +x, −x, +y, −y, +z, −z} rappresenta
la forma del box, e i ∈ {incl, excl} rappresenta il fatto che il centro sia incluso
o meno nel box. La forma effettiva del box risultante deriva da un cubo con
lunghezza di lato uguale a 2l + 1 e centro in x0, y0, z0, come segue. Il cubo
`e completo, se t = full, o dimezzato altrimenti: t = +x intende la met`a con
x ≥ x0 o x > x0, con i uguale a incl o excl, rispettivamente, e similmente
per gli altri valori di t—i non impatta quando il box `e t = full. Per esempio,
(5, 5, 5, 2, +y, excl) `e il parallelepipedo che va da (3, 6, 3) a (7, 7, 7), entrambe
le celle incluse.
Una condizione `e un predicato che opera su un insieme di variabili che
riguardano la posizione del drone, la sua cella di destinazione, un altro drone
a lui pi`u vicino e gli edifici pi`u vicini. Pi`u in dettaglio, una condizione `e una
costante true o una congiunzione tra una o pi`u condizioni di base o negazioni
di condizioni di base. Una condizione di base pu`o essere una condizione sulle
coordinate o sulla distanza, le quali rispettivamente operano sulle coordinate
(eventualmente in maniera distinta) della cella di destinazione, sul drone
stesso, sulle distanze dal drone pi`u vicino e dagli edifici pi`u vicini.
11

16. R ::=({⟨boxes⟩}, ⟨conditions⟩)
⟨boxes⟩ ::=⟨boxes⟩, ⟨box⟩ | ⟨box⟩
⟨box⟩ ::=(⟨x-coord⟩, ⟨y-coord⟩, ⟨z-coord⟩, ⟨digit⟩,
⟨shape⟩, ⟨center-inclusion⟩)
⟨digit⟩ ::=0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
⟨shape⟩ ::=full | +x | −x | +y | −y | +z | −z
⟨center-inclusion⟩ ::=incl | excl
⟨x-coord⟩ ::=x | xf | xU,closest | ⟨digit⟩⟨digit⟩
⟨y-coord⟩ ::=y | yf | yU,closest | ⟨digit⟩⟨digit⟩
⟨z-coord⟩ ::=z | zf | zU,closest | ⟨digit⟩⟨digit⟩
⟨conditions⟩ ::=⟨conditions⟩ ∧ ⟨condition⟩ | ⟨condition⟩ | true
⟨condition⟩ ::=⟨basic-condition⟩ | ¬⟨basic-condition⟩
⟨basic-condition⟩ ::=⟨coord-condition⟩ | ⟨dist-coondition⟩
⟨coord-condition⟩ ::=⟨x-coord⟩⟨op⟩⟨x-coord⟩ | ⟨x-coord⟩⟨op⟩⟨digit⟩⟨digit⟩ |
⟨y-coord⟩⟨op⟩⟨y-coord⟩ | ⟨y-coord⟩⟨op⟩⟨digit⟩⟨digit⟩ |
⟨z-coord⟩⟨op⟩⟨z-coord⟩ | ⟨z-coord⟩⟨op⟩⟨digit⟩⟨digit⟩
⟨op⟩ ::= = | <
⟨dist-condition⟩ ::=⟨dist⟩ ≤ ⟨digit⟩
⟨dist⟩ ::=dU,closest | d+x
B,closest | d−x
B,closest | d
+y
B,closest | d
−y
B,closest |
d+z
B,closest | d−z
B,closest
Figura 3.1: Forma di Backus-Naur della grammatica context-free per le regole sul traffico.
La figura 3.1 mostra la grammatica context-free, nella Forma di Backus-
Naur, che definisce il linguaggio di tutte le possibili regole.
La funzione r : S → {allowed, denied} che marca ogni cella dello spazio
come permessa o negata `e definita da un insieme R di regole basandosi sulle
coordinate x, y, z del drone, la sua cella di destinazione xf , yf , zf = 0, le sue
distanze Manhattan dU,closest e dB,closest dal drone pi`u vicino e dall’edificio pi`u
vicino rispettivamente, e le coordinate xU,closest, yU,closest, zU,closest del drone pi`u
vicino—nel caso in cui due o pi`u droni si trovino alla stessa distanza minima,
solo uno di questi `e considerato casualmente. Da notare che le distanze e le
coordinate del drone pi`u vicino possono essere ottenute elaborando l’input
del controllore che include (vedi Sezione 2.2) l’insieme di tutti gli edifici
B e le coordinate di tutti gli altri droni circostanti. Il sottoinsieme di S
12

17. da impostare a denied `e determinato come segue: per ogni R ∈ R, se la
condizione `e verificata, tutte le celle appartenenti ai boxes sono impostate a
denied.
3.2 Esempi di regole
Per semplificare la comprensione della sintassi e della semantica delle regole, si
forniscono ora tre esempi di (insieme di) regole che esprimono limiti e vincoli
realistici che possono essere espressi usando il linguaggio naturale in maniera
concisa, ma anche ambigua. Gli esempi permettono anche di apprezzare
l’espressivit`a e l’essenzialit`a del linguaggio da noi proposto.
P ={(x, y, z, 1, −z, excl), (x, y, z, 1, −x, excl),
(x, y, z, 1, +x, excl), (x, y, z, 1, −y, excl),
(x, y, z, 1, +y, excl)}
R1 =(P, z < 4 ∧ ¬x = xf )
R2 =(P, z < 4 ∧ ¬y = yf )
Le due regole soprastanti esprimono assieme il vincolo che dice “vola ad
un’altezza minima di 4”. Intuitivamente, le regole impongono un’altitudine
minima di z = 4 combinando 5 half boxes ed escludendo l’unico half box
(tra le 6 possibili met`a) che `e situato nella met`a di sopra (t = +z), il che
restituisce tutte le celle circostanti al drone vietate, ad eccezione di quelle
situate esattamente sopra di lui. Il vincolo richiede due regole, che differiscono
nelle condizioni, per essere espresso. Questo riflette il fatto che il vincolo non
pu`o essere applicato quando la z attuale del drone `e gi`a ≥ 4, ma neanche
quando il drone `e attualmente sopra la sua cella di destinazione (cio`e, quando
x = xf ∧ y = yf ).
R =({xU,closest, yU,closest, zU,closest, 1, full, incl}, true)
La regola soprastante esprime il concetto di “mantieni una distanza minima
di 2 dagli altri droni”. Questa regola `e semplice dal momento che non ha
condizioni (cio`e, i boxes sono sempre presenti, ammesso che almeno un altro
drone sia visto dal drone corrente) e la regione vietata `e determinata da un
singolo box.
13

18. R−x =({(x, y, z, 1, −x, excl)}, d−x
B,closest ≤ 2)
R+x =({(x, y, z, 1, +x, excl)}, d+x
B,closest ≤ 2)
R−y =({(x, y, z, 1, −y, excl)}, d
−y
B,closest ≤ 2)
R+y =({(x, y, z, 1, +y, excl)}, d
+y
B,closest ≤ 2)
R−z =({(x, y, z, 1, −z, excl)}, d−z
B,closest ≤ 2)
Infine, le 5 regole dichiarate qua sopra esprimono assieme il vincolo che dice
“mantieni una distanza minima di 2 dagli edifici”. L’idea chiave `e di imporre
un half box vietato su una data direzione e centrato (con centro escluso) sul
drone se e quando il drone `e troppo vicino ad un edificio in quella direzione.
Le regole sono 5 invece che 6 perch´e nel nostro modello `e impossibile che
accada l’evento per il quale un drone voli al di sotto di un edificio.
14

19. Capitolo 4
Validazione sperimentale
`E stato eseguito un insieme accurato di esperimenti con un duplice scopo.
Innanzitutto `e stato validato il nostro modello per lo spazio, gli edifici, i droni
e le collisioni. In secondo luogo, `e stata verificata la capacit`a della sintassi e
della semantica delle regole proposte, per esprimere un insieme di regole le
quali potessero effettivamente impattare sul traffico (simulato) dei droni.
Per questo scopo, `e stato implementato un simulatore ed `e stato eseguito
un certo numero di simulazioni facendo variare le condizioni e la quantit`a
di traffico iniettato. In particolare, `e stato considerato un singolo spazio S
con lS
x = lS
y = lS
z = 10 e 4 insiemi B di edifici, in modo tale che il rapporto di
spazio occupato dagli edifici fosse γB =
∑
B∈B |B|
|S|
∈ {0.01, 0.05, 0.1, 0.15}. Ogni
simulazione aveva durata di T = 3000 istanti di tempo ed `e stata eseguita
come segue, ad ogni istante di tempo.
1. L’attuale numero n di droni nella simulazione (inizialmente, n = 0)
e un numero prefissato nmax di droni sono confrontati: se nnew =
rnew(nmax − n) > 0, un numero nnew di droni sono generati e aggiunti
alla simulazione. Per ogni nuovo drone, la posizione iniziale `e impostata
a z = 0 e casualmente per quanto riguarda x e y, evitando tutte le celle
appartenenti ad edifici o adiacenti ad edifici; la cella di destinazione `e
scelta casualmente con gli stessi criteri.
2. Successivamente, la posizione di ogni drone `e aggiornata in accordo alla
procedura descritta nella Sezione 2.1.
3. Infine, ogni drone il quale soddisfi almeno una delle seguenti condizioni
`e rimosso dalla simulazione: (a) il drone `e nella sua cella di destinazione;
(b) lo stato del drone `e collided e la sua posizione appartiene ad una
15

20. cella di edificio; (c) lo stato del drone `e collided e inoltre la sua z = 0
(cio`e, ha raggiunto il suolo).
In altre parole, dopo una “partenza lenta” mirata ad evitare di affollare il
suolo dall’inizio della simulazione, il numero n di droni, ovvero il traffico
iniettato, `e mantenuto costante.
Sono stati fatti esperimenti con rnew = 0.2, v = 2, pB,inside = 1, pB,close =
0.25, pU,same = 0.75, e pU,close = 0.5 e svolte 30 simulazioni per ciascuno dei
valori di nmax ∈ {1, 5, 10, . . . , 75, 80}.
Inoltre, per indagare l’impatto dell’algoritmo di controllo, sono stati
sperimentati 3 diversi metodi per la scelta dell’algoritmo di controllo nel
momento della generazione di un nuovo drone: sempre A*, sempre AQ, A* o
AQ con equa probabilit`a (denoteremo questo caso come “Mix”). Infine, sono
stati ripetuti gli esperimenti considerando il caso senza regole (R = ∅) e il
caso con R comprendente le regole espresse nella Sezione 3.2. `E stato quindi
svolto un totale di 30 × 17 × 4 × 3 × 2 = 12 240 simulazioni.
Dopo ciascuna simulazione, `e stato misurato il numero totale ¯ncollision di
collisioni e la distanza di percorrenza al suolo totale ¯dt: quest’ultima `e la
somma della distanza Manhattan tra la cella di partenza e la cella di desti-
nazione, per ciascun drone che ha raggiunto la destinazione nello stato alive
durante la simulazione. I due indici rappresentano la sicurezza e l’efficienza
dell’intero sistema di trasporto e dipendono dalla quantit`a nmax di traffico
immesso—chiaramente, maggiore `e il numero di droni in circolazione, pi`u `e la
distanza, pi`u frequenti sono le collisioni. Per mitigare questa dipendenza, ed
inoltre permettere una diversa prospettiva nell’analisi dei risultati, sono stati
derivati due altri indici: l’incidentalit`a media AA = 1
nactual
∑nactual
j=1
nj
collision
kj e
la velocit`a media di percorrenza al suolo AGS = 1
nactual
∑nactual
j=1
dj
t
kj dove nactual
`e il numero di tutti i droni che sono stati in vita nella simulazione, nj
collision
`e il numero di collisioni nelle quali il j-esimo drone `e stato coinvolto, kj
`e
il numero di istanti di vita per i quali `e vissuto nella simulazione, e dj
t `e
la misura della proiezione sul piano x, y della sua traiettoria percorso nello
spazio (impostata a 0 per i droni collisi).
4.1 Risultati
Le Figure 4.1, 4.2, 4.3, 4.4 e le Figure 4.5, 4.6, 4.7, 4.8 presentano i risultati
dell’analisi sperimentale: per tutti i grafici ogni punto `e il risultato della
media degli indici lungo le 30 simulazioni nelle stesse condizioni.
Le Figure 4.1, 4.2, 4.3 e 4.4 mostrano la velocit`a media al suolo AGS
(sopra) e l’incidentalit`a media AA (sotto) vs. il traffico iniettato nmax, in
16

21. diverse condizioni. Possono essere fatte due considerazioni interessanti. In
primo luogo, si pu`o notare che, come previsto, l’introduzione di un esempio di
regole causa un decremento dell’incidentalit`a e della velocit`a media al suolo:
questo conferma che il modello proposto e le regole permettono di avere un
impatto consistente sul trade-off tra efficienza e sicurezza del traffico di droni
simulato. Secondariamente si pu`o notare che, in particolare per l’indice di
incidentalit`a AA, la differenza tra i diversi metodi di controllo tendono ad
essere trascurabili quando in presenza di regole: in altre parole, regolare il
sistema appare come uno stratagemma per rendere la sicurezza del traffico
pi`u predicibile, indipendentemente dall’effettivo controllore usato per il drone.
Le Figure 4.5, 4.6, 4.7 e 4.8 mostrano la distanza totale percorsa ˆdt vs. il
numero totale ˆncollision di collisioni per la modalit`a di controllo Mix per diversi
valori di percentuale di edifici γB. Si pu`o evidenziare come esista un punto
(ovvero un valore per il traffico iniettato nmax) al di l`a del quale l’aggiunta di
ulteriori droni non comporta un incremento di ˆdt, anzi porta ad un incremento
del numero di collisioni. Questo punto `e il punto di congestione dello spazio e,
come previsto, la distanza totale percorsa al suolo (che rappresenta l’efficienza
del traffico) decresce con l’aumentare di γB: in altre parole, pi`u piccolo `e lo
spazio libero di volo, pi`u piccola `e la distanza totale percorsa al suolo da una
moltitudine di droni, indipendentemente dalla dimensione dello sciame.
4.1.1 Ulteriori esperimenti
Per validare ulteriormente il modello si `e indagata l’ipotesi secondo la quale,
all’aumentare dei droni immessi in uno spazio sufficientemente grande, essi si
muovono facendo crescere la distanza totale ˆdt senza per`o collidere tra loro
a causa della quantit`a di spazio libero a disposizione. Tale situazione non `e
riconoscibile dai grafici mostrati nelle Figure 4.5, 4.6, 4.7 e 4.8 discussi nella
Sezione 4.1 per lo spazio S di dimensioni lS
x = lS
y = lS
z = 10 dal momento
che, con nmax = 1 la densit`a di droni per celle libere δ = nmax
lS
x ×lS
y ×lS
z ×(1−γB)
era gi`a sufficientemente elevata. Quindi si `e esplorata la parte iniziale del
grafico scegliendo uno spazio di dimensioni lS
x = lS
y = 25 e lS
z = 15, potendo
immettere una densit`a di droni pi`u bassa.
Nella Figura 4.9 si mettono a confronto le curve di congestione dei due
spazi di dimensioni diverse e come si pu`o notare la curva dello spazio pi`u
grande conferma l’ipotesi appena descritta: la distanza totale percorsa ˆdt
inizialmente cresce senza che avvengano collisioni, poi il suo andamento rimane
crescente ma si cominciano a verificare le prime collisioni fino al punto di
congestione come spiegato pi`u dettagliatamente nella Sezione 4.1.
17

22. 0
0.2
0.4
0.6
AGS
γB = 0.01
0 10 20 30 40 50 60 70 80
0
0.5
1
1.5
nmax
AA
A*/No regole AQ/No regole Mix/No regole
A*/Regole AQ/Regole Mix/Regole
Figura 4.1: Velocit`a media al suolo AGS (sopra) e incidentalit`a media AA (sotto) vs.
traffico iniettato nmax per diversi controllori (colore linea), percentuale di edifici γB = 0.01,
e regole (stile linea).
18

23. 0
0.2
0.4
0.6
AGS
γB = 0.05
0 10 20 30 40 50 60 70 80
0
0.5
1
1.5
nmax
AA
A*/No regole AQ/No regole Mix/No regole
A*/Regole AQ/Regole Mix/Regole
Figura 4.2: Velocit`a media al suolo AGS (sopra) e incidentalit`a media AA (sotto) vs.
traffico iniettato nmax per diversi controllori (colore linea), percentuale di edifici γB = 0.05,
e regole (stile linea).
19

24. 0
0.2
0.4
0.6
AGS
γB = 0.10
0 10 20 30 40 50 60 70 80
0
0.5
1
1.5
nmax
AA
A*/No regole AQ/No regole Mix/No regole
A*/Regole AQ/Regole Mix/Regole
Figura 4.3: Velocit`a media al suolo AGS (sopra) e incidentalit`a media AA (sotto) vs.
traffico iniettato nmax per diversi controllori (colore linea), percentuale di edifici γB = 0.10,
e regole (stile linea).
20

25. 0
0.2
0.4
0.6
AGS
γB = 0.15
0 10 20 30 40 50 60 70 80
0
0.5
1
1.5
nmax
AA
A*/No regole AQ/No regole Mix/No regole
A*/Regole AQ/Regole Mix/Regole
Figura 4.4: Velocit`a media al suolo AGS (sopra) e incidentalit`a media AA (sotto) vs.
traffico iniettato nmax per diversi controllori (colore linea), percentuale di edifici γB = 0.15,
e regole (stile linea).
21

26. 0 1 2 3 4 5 6
·104
0
1,000
2,000
3,000
4,000
5,000
ˆncollision
ˆdt
γB = 0.01
Mix/No rules Mix/Rules
Figura 4.5: Distanza percorsa totale ˆdt vs. numero totale ˆncollision di collisioni per il
controllore Mix, con percentuale di edifici γB = 0.01, e regole (stile linea).
0 1 2 3 4 5 6
·104
0
1,000
2,000
3,000
4,000
5,000
ˆncollision
ˆdt
γB = 0.05
Mix/No rules Mix/Rules
Figura 4.6: Distanza percorsa totale ˆdt vs. numero totale ˆncollision di collisioni per il
controllore Mix, con percentuale di edifici γB = 0.05, e regole (stile linea).
22

27. 0 1 2 3 4 5 6
·104
0
1,000
2,000
3,000
4,000
5,000
ˆncollision
ˆdt
γB = 0.10
Mix/No rules Mix/Rules
Figura 4.7: Distanza percorsa totale ˆdt vs. numero totale ˆncollision di collisioni per il
controllore Mix, con percentuale di edifici γB = 0.10, e regole (stile linea).
0 1 2 3 4 5 6 7
·104
0
1,000
2,000
3,000
4,000
5,000
ˆncollision
ˆdt
γB = 0.15
Mix/No rules Mix/Rules
Figura 4.8: Distanza percorsa totale ˆdt vs. numero totale ˆncollision di collisioni per il
controllore Mix, con percentuale di edifici γB = 0.15, e regole (stile linea).
23

28. 0 1 2 3 4 5
·104
0
1
2
3
4
5
·104
ˆncollision
ˆdt
γB = 0.01
Spazio 10 × 10 × 10
Spazio 25 × 25 × 15
Figura 4.9: Distanza percorsa totale ˆdt vs. numero totale ˆncollision di collisioni per il
controllore AQ, con percentuale di edifici γB = 0.01 e senza regole.
24

29. Capitolo 5
Neuroevolution
Dopo aver validato sperimentalmente la consistenza del modello proposto e
l’impatto considerevole fornito dall’introduzione delle regole per il traffico
urbano di droni, ci si `e spinti oltre esplorando un possibile scenario: si pu`o
generare automaticamente un controllore per i droni e che impatto hanno le
regole sulla generazione di un controllore di questo tipo? In questo capitolo
si descrive il lavoro svolto per rispondere a questi interrogativi e si descrivono
i risultati ottenuti.
5.1 Controllo tramite rete neurale
Il controllore del drone tramite rete neurale (NNC) `e un particolare modello
matematico il quale, ad ogni istante di tempo, elabora un input che corrisponde
alla percezione dello spazio circostante al drone e produce un output il quale
determina come la posizione del drone deve essere aggiornata.
Tale modello, un cui esempio `e rappresentato graficamente in Fig. 5.1, `e
costituito da pi`u livelli di neuroni, che possono essere di tre tipi: (i) livello
d’ingresso, contenente neuroni di input—anche detti sensori; (ii) (nessuno,
uno o pi`u) livello nascosto, che contiene neuroni nascosti; (iii) livello d’uscita,
che contenente neuroni d’uscita—anche detti attuatori. Ciascun neurone di
ogni livello `e connesso con tutti i neuroni del livello successivo. Ognuna di
queste unit`a svolge un compito molto semplice: attivarsi nel caso in cui la
quantit`a totale di segnale che riceve supera una certa soglia. Se attivato, un
neurone emette a sua volta un segnale che attraversa le connessioni che il
neurone stesso ha con tutti i nodi del livello successivo nella rete. Quando
un segnale attraversa una connessione viene moltiplicato per un opportuno
25

30. Input #1
Input #2
Input #3
Input #4
Output
Hidden
layer
Input
layer
Output
layer
Figura 5.1: Visualizzazione grafica d’esempio di una rete neurale.
valore, detto peso, associato alla connessione. L’informazione scorre quindi dai
sensori nella direzione degli attuatori, venendo elaborata dai nodi nascosti.
Questo controllore riceve gli stessi input di quelli descritti nella Sezio-
ne 2.2: (i) la conoscenza illimitata degli oggetti non in movimento; (ii) la
conoscenza degli oggetti in movimento (cio`e, altri droni) nelle vicinanze del
drone; (iii) la destinazione del drone stesso; (iv) la conoscenza degli effetti
risultanti dall’applicazione delle regole vigenti, dal punto di vista del drone
stesso.
Il controllore NNC prima elabora gli input ricevuti, poi il risultato di questa
elaborazione diventa l’ingesso della rete neurale utilizzata per controllare i
movimenti del drone. La rete neurale quindi, riceve in input una percezione
limitata dello spazio circostante, sotto forma di un vettore di trenta elementi,
il quale attraversa la rete per ottenere un vettore di dimensione tre in output.
In dettaglio, l’ingresso della rete neurale usata come controllore del drone
u consiste di un vettore di trenta elementi, in cui l’i-esimo elemento `e l’input
dell’i-esimo neurone di input:
1. 27 elementi corrispondono alle informazioni relative alle celle apparte-
nenti al cubo di lato di lunghezza 3 e centrato nella posizione di u. Per
ogni cella, l’i-esimo elemento di input `e pari a 1 se (i) la cella appartiene
ad un edificio, oppure (ii) la cella contiene uno o pi`u droni, oppure
(iii) la cella `e vietata dalle regole; altrimenti `e pari a 0;
2. i restanti 3 elementi corrispondono alla sintesi delle informazioni relative
alla posizione attuale (x, y, z) e alla cella di destinazione (xf , yf , zf ) di u:
per ognuna delle 3 coordinate x, y, z, l’input alla rete neurale corrisponde
alla differenza x − xf —e similmente per le altre due coordinate.
26

31. Si osservi che anche questo controllore considera le regole come uno tra i
diversi input e per questo potrebbe anche scegliere di ignorarle. Inoltre, la
quantit`a di informazioni che la rete neurale riceve in input per determinare
l’output `e pi`u carente rispetto agli algoritmi descritti nella Sezione 2.2. Questa
scelta `e stata fatta per diminuire lo spazio di ricerca nell’evoluzione della rete
neurale descritta nella successiva Sezione 5.2.
L’uscita della rete neurale determina come la posizione (x, y, z) del dro-
ne u deve essere aggiornata. In dettaglio, ciascuno dei 3 neuroni di out-
put della rete produce rispettivamente un valore ox, oy ed oz continuo e
compreso nell’intervallo [0, 1]. Successivamente, ognuno di questi valori vie-
ne mappato in un elemento mx ∈ {−1x, 0x, +1x}, my ∈ {−1y, 0y, +1y} ed
mz ∈ {−1z, 0z, +1z} secondo la seguente procedura: (i) se ox < 1
3
, allora
mx = −1x; (ii) se 1
3
≤ ox < 2
3
, allora mx = 0x; (iii) se ox ≥ 2
3
, allora mx = +1x
—ed analogamente per oy ed oz nelle coordinate y e z;
Quindi:
1. mx = +1x corrisponde a x = x + 1, mx = −1x corrisponde a x = x − 1,
mx = 0x corrisponde a x = x ovvero all’aggiornamento della coordinata
x della posizione di u;
2. my `e analogo al precedente ma riferito alla coordinata y di u;
3. mz `e analogo al precedente ma riferito alla coordinata z di u;
Le possibili configurazioni di una rete, in termini di topologia e pesi
delle connessioni, possono essere svariate. Per questo motivo risulta evidente
che determinare la struttura della rete che si presti ad essere usata come
controllore del drone `e un compito difficile. In questo lavoro `e stata eseguita
una Neuroevolution, descritta successivamente, per indagare la possibilit`a di
controllare i droni in caso di traffico con e senza regole.
5.2 NEAT
La Neuroevolution [1] `e una forma di Evolution Algorithm (EA) nella quale
gli individui che evolvono sono reti neurali. La rappresentazione del genotipo
di un individuo pu`o essere di diverso tipo ed `e principalmente legata alla
natura del problema e alle specifiche varianti dell’algoritmo evolutivo scelto
per l’evoluzione.
NeuroEvolution of Augmenting Topologies (NEAT), introdotto da Stanley
e Miikkulainen (2002) [17], `e un algoritmo evolutivo che codifica ed evolve
geneticamente la topologia ed i pesi di reti neurali in contemporanea. Questo
approccio adopera operatori genetici che possono introdurre nuovi geni e
27

32. disattivarne vecchi: viene utilizzato un crossover tra individui con diversa
lunghezza genetica, il quale, partendo da reti molto semplici, ne produce di
complessit`a sempre crescente. La principale intuizione di NEAT `e basata
sul fatto che geni che condividono la stessa origine evoluzionistica molto
probabilmente codificano una rete simile. Per mantenere memoria dello storico
genetico, quando un nuovo gene viene creato, gli si assegna un valore numerico
che corrisponde al suo ordine di apparizione cronologico durante l’evoluzione.
Il secondo contributo innovativo introdotto da NEAT `e la speciazione degli
individui che consente agli individui di competere in primis con la propria
specie della popolazione. In dettaglio, due individui appartengono alla stessa
specie se hanno topologie simili. Infine, il terzo ed ultimo apporto di NEAT
`e la scelta di cominciare l’evoluzione con una popolazione la cui topologia
`e molto semplice ed uniforme, senza hidden layer; una nuova struttura `e
introdotta incrementalmente non appena avvengono mutazioni strutturali.
NeuroEvolution of Augmenting Topologies ha visto crescere nel corso degli
anni la sua popolarit`a, essendo stato applicato a problemi di diversa natura
come i videogames [11, 16], i sistemi di allarme per incidenti d’auto [15] e,
similmente a quanto fatto in questa attivit`a, il controllo di robot [18].
In questa fase del lavoro `e stato eseguito un numero arbitrario di train con
il duplice scopo di validare i parametri evolutivi e successivamente verificare
la possibilit`a di generare un controllore sotto forma di rete neurale—cos`ı come
descritto nella Sezione 5.1, oltre a determinare l’impatto delle regole sulla
generazione di questo controllore.
`E stato utilizzato un framework di NEAT con il quale sono state compiute
diverse indagini al fine di individuare sperimentalmente i parametri evolu-
zionistici e la funzione di fitness che pi`u si adattassero al caso in esame. I
parametri ricavati da questa fase sono mostrati nella Tabella 5.1.
Tabella 5.1: Parametri NE
Popolazione 300
Generazioni 50
Per quanto riguarda la funzione di fitness, `e stato definito un indice
di simulazione che raccogliesse la capacit`a di un controllore di compiere
movimenti e di avvicinarsi alla destinazione nel farlo.
f(NN) = AFD
Tale fitness `e riassunta nella distanza finale media, definita come AFD =
1
nactual
∑nactual
j=1 dj
f dove nactual `e il numero di tutti i droni che sono stati in vita
nella simulazione e dj
f `e la sua distanza euclidea tra la posizione attuale e
28

33. quella di destinazione del j-esimo drone al suo ultimo istante di vita—quindi
se il drone j-esimo `e arrivato a destinazione dj
f = 0.
La seconda fase di questa indagine era volta al verificare la possibilit`a
di utilizzare la Neuroevolution per ottenere una rete neurale che facesse
da controllore e, successivamente, confrontare le prestazioni dello stesso
controllore con quelli descritti nella Sezione 2.2, oltre a stabile se e come le
regole impattassero sull’evoluzione.
Si `e svolto un training della rete neurale esplorando tre casi differenti di
simulazione, nell’ipotesi con R = ∅ e con R comprendente le regole espresse
nella Sezione 3.2. Tutti i tre casi condividevano la dimensione dello spazio
lS
x = lS
y = lS
z = 10, gli step di simulazione T = 1000, le probabilit`a di collisione
ed rnew = 0.2. Tuttavia: (i) nel primo caso si considerava uno spazio con
nmax = 5 e γB = 0.01; (ii) nel secondo caso uno spazio con nmax = 5 e
γB = 0.00; (iii) nell’ultimo caso uno spazio con nmax = 1 e γB = 0.00;
`E stato svolto un numero di train di 3 × 3 × 2 = 18. Durante ciascun train
`e stato misurato l’andamento della fitness al passare delle generazioni.
5.3 Risultati
La Figura 5.2 presenta i risultati della fase di train della Neuroevolution
mediante NEAT nel caso con e senza regole. Entrambi i grafici riassumono
i risultati della ricerca evolutiva in termini di fitness del miglior individuo
nella popolazione. In particolare si mostra come la fitness media del miglior
individuo (su 3 esecuzioni) vari durante l’evoluzione. Le curve tratteggiate
sono il valor medio dello stesso indice per simulazioni con controllore Arco
Quadro ed A*.
Innanzitutto si pu`o notare che NEAT `e in generale capace di ridurre
lo score degli individui durante l’evoluzione, anche se questo poco dopo la
20-esima generazione decresce molto pi`u lentamente.
In secondo luogo, appare evidente che la miglior rete neurale alla fine
dell’evoluzione, nel caso con e senza regole, assume un comportamento migliore
di quello che assumono mediamente i due controllori A* ed Arco Quadro.
Questo risultato `e giustificabile dal fatto che, per esempio nel caso di A*,
nonostante l’algoritmo consenta di trovare il percorso pi`u breve evitando gli
ostacoli, non consideri l’attraversamento di zone con probabilit`a di collisione.
L’ipotesi fatta `e che alla fine del train, anche se la rete neurale non consente
di volare sul percorso pi`u breve, permette di evitare pi`u facilmente le aree
con probabilit`a di collisione.
Un terzo risultato lampante `e che le due curve nei casi γB = 0.01 e
γB = 0.00, con e senza regole, tendono a sovrapporsi ripetutamente lungo
29

34. tutta la durata del train. Si evince quindi che il controllo tramite rete neurale
ottiene prestazioni molto simili in presenza o meno di edifici. Questo appoggia
l’ipotesi esposta poc’anzi, la quale ci induce a pensare che il controllo per
mezzo di reti neurali sia in grado di evitare gli ostacoli e le zone con probabilit`a
di collisione.
Infine, un risultato notevole si riscontra dal confronto dei due grafici,
considerando l’andamento della miglior fitness nel caso con e senza regole.
Le prestazioni dei controllori tramite rete neurale in entrambe le situazioni
sono molto simili alla fine del train; avendo dimostrato nella sezione 4.1 che
l’introduzione delle regole ha un impatto consistente sul trade-off tra efficienza
e sicurezza del traffico di droni, allora appare sensata l’ipotesi di evolvere un
controllore che considera le regole. In questo senso, quindi, ancora una volta
emerge la loro importanza.
30

35. 0
0.5
1
1.5
2
2.5
AFD
0 5 10 15 20 25 30 35 40 45 50
0
0.5
1
1.5
2
2.5
Generation
AFD
NNC, nmax = 5, γB = 0.01 NNC, nmax = 5, γB = 0.00
NNC, nmax = 1, γB = 0.00 AQ, nmax = 5, γB = 0.01
A*, nmax = 5, γB = 0.01
Figura 5.2: Miglior fitness media durante l’evoluzione nel caso senza regole (sopra) e con
regole scritte a mano (sotto).
31

36. Capitolo 6
Conclusioni
`E stato proposto innanzitutto un modello per lo spazio, gli edifici, i controllori
dei droni e le collisioni tale per cui si potesse simulare lo spazio aereo urbano in
uno scenario decentralizzato in cui i droni sono liberi di spostarsi—scenario la
cui importanza aumenter`a considerevolmente nel prossimo futuro. Il modello `e
stato convalidato sperimentalmente attraverso un gran numero di simulazioni.
Successivamente `e stato proposto un linguaggio (sintassi e semantica) per
la definizione di regole per il traffico di droni. Il linguaggio si basa sul modello
proposto. Gli esperimenti mostrano che l’introduzione di un piccolo insieme di
regole scritte a mano, di una complessit`a realistica e formulate concisamente
attraverso il linguaggio proposto, portano ad effetti consistenti e facilmente
intuibili sull’efficienza e la sicurezza del traffico di droni.
Infine `e stata indagata la possibilit`a di generare un controllore automatica-
mente attraverso l’utilizzo di NEAT, oltre a constatare il promettente impatto
che l’utilizzo di un insieme di regole scritte a mano ha sulla generazione di
tale controllore.
Questo lavoro pone le basi per diverse estensioni future, come: (i) la
creazione di un modello ancora pi`u raffinato per quanto riguarda lo spazio
e le collisioni (ii) la generazione automatica di insiemi di regole attraverso
l’utilizzo di Grammatical Evolution (GE) (iii) una migliore esplorazione con
NEAT.
32

37. Bibliografia
[1] D. Floreano, P. D¨urr, and C. Mattiussi. Neuroevolution: from
architectures to learning. Evolutionary Intelligence, 1(1):47–62, 2008.
[2] J. F. Gomez and M. Jamshidi. Fuzzy adaptive control for a UAV. Journal
of Intelligent & Robotic Systems, 62(2):271–293, 2011.
[3] P. E. Hart, N. J. Nilsson, and B. Raphael. A formal basis for the heuristic
determination of minimum cost paths. IEEE transactions on Systems
Science and Cybernetics, 4(2):100–107, 1968.
[4] S. Khantsis and A. Bourmistrova. UAV controller design using evo-
lutionary algorithms. Lecture notes in computer science, 3809:1025,
2005.
[5] R. Krashanitsa, G. Platanitis, B. Silin, and S. Shkarayev. Aerodyna-
mics and controls design for autonomous micro air vehicles. In AIAA
Atmospheric Flight Mechanics Conference and Exhibit, pages 21–24, 2006.
[6] H.-P. Lam, S. Thakur, G. Governatori, and A. Sattar. A Model to
Coordinate UAVs in Urban Environments Using Defeasible Logic. In
RuleML Challenge, 2009.
[7] T. Liao. UAV collision avoidance using a* algorithm. PhD thesis, 2012.
[8] J. A. Marin, R. Radtke, D. Innis, D. R. Barr, and A. C. Schultz. Using
a genetic algorithm to develop rules to guide unmanned aerial vehicles.
In Systems, Man, and Cybernetics, 1999. IEEE SMC’99 Conference
Proceedings. 1999 IEEE International Conference on, volume 1, pages
1055–1060. IEEE, 1999.
33

38. [9] E. Medvet, A. Bartoli, and J. Talamini. Road Traffic Rules Synthe-
sis Using Grammatical Evolution. In European Conference on the
Applications of Evolutionary Computation, pages 173–188. Springer,
2017.
[10] G. Platanitis and S. Shkarayev. Integration of an autopilot for a micro
air vehicle. In AIAA Infotech Aerospace 2005 Conference and Exhibit,
pages 1–19, 2005.
[11] J. Reisinger, E. Bahceci, I. Karpov, and R. Miikkulainen. Coevolving
strategies for general game playing. In Computational Intelligence and
Games, 2007. CIG 2007. IEEE Symposium on, pages 320–327. IEEE,
2007.
[12] M. Salichon and K. Tumer. A neuro-evolutionary approach to micro
aerial vehicle control. In Proceedings of the 12th annual conference on
Genetic and evolutionary computation, pages 1123–1130. ACM, 2010.
[13] B. M. Sathyaraj, L. C. Jain, A. Finn, and S. Drake. Multiple UAVs
path planning algorithms: a comparative study. Fuzzy Optimization and
Decision Making, 7(3):257–267, 2008.
[14] F. Silva, M. Duarte, L. Correia, S. M. Oliveira, and A. L. Christen-
sen. Open issues in evolutionary robotics. Evolutionary computation,
24(2):205–236, 2016.
[15] K. Stanley, N. Kohl, R. Sherony, and R. Miikkulainen. Neuroevolution
of an automobile crash warning system. In Proceedings of the 7th annual
conference on Genetic and evolutionary computation, pages 1977–1984.
ACM, 2005.
[16] K. O. Stanley, R. Cornelius, R. Miikkulainen, T. D’Silva, and A. Gold.
Real-time learning in the nero video game. In AIIDE, pages 159–160,
2005.
[17] K. O. Stanley and R. Miikkulainen. Evolving neural networks through
augmenting topologies. Evolutionary computation, 10(2):99–127, 2002.
[18] K. O. Stanley and R. Miikkulainen. Competitive coevolution through
evolutionary complexification. 2004.
[19] E. Sunil, J. Hoekstra, J. Ellerbroek, F. Bussink, D. Nieuwenhuisen,
A. Vidosavljevic, and S. Kern. Metropolis: Relating airspace structure
and capacity for extreme traffic densities. In ATM seminar 2015, 11th
USA/EUROPE Air Traffic Management R&D Seminar, 2015.
34

39. [20] R. E. Weibel and R. J. Hansman. Safety considerations for operation of
different classes of UAVs in the NAS. In AIAA 4th Aviation Tehcnology,
Integration and Operations Forum, AIAA 3rd Unmanned Unlimited
Technical Conference, Workshop and Exhibit, 2004.
35

40. Ringraziamenti
Desidero ringraziare innanzitutto il mio relatore, Eric Medvet, e correlatore
Alberto Bartoli. Con la loro professionalit`a e passione mi hanno piace-
volmente permesso di portare a compimento questo lavoro e soprattutto mi
hanno consentito di raggiungere traguardi inizialmente per me inimmaginabili.
Nella stessa misura ringrazio Andrea e Fabiano, figure imprescindibili
e fondamentali nella vita di un qualunque tesista che passi per il Machine
Learning Lab.
Un ringraziamento lo devo a tutti gli amici, vecchi e nuovi, che mi hanno
accompagnato in questo percorso.
Un grande grazie ad Alessandra, soprattutto per la sua pazienza, fonda-
mentale per me.
Grazie sentitamente a tutti i miei parenti, anche quelli che non leggeranno
queste poche righe ma che mi guidano da vicino.
Ringrazio mio fratello Giovanni per la figura d’esempio che ha da sempre
rappresentato in me e per il suo implicito supporto nelle mie decisioni. Ac-
canto a lui un grosso ringraziamento anche a Laura.
Infine, non per importanza, ringrazio profondamente i miei genitori Nicola
e Francesca: non solo un supporto economico bens`ı una guida morale, di vita
ed educativa rara, attraverso i quali so che questo lavoro di tesi `e solo l’inizio
di un lungo percorso.
Grazie.
36