Università di Napoli Federico II

Transcript

Corso di Laurea in
Ingegneria Dell’Automazione
Dipartimento di Informatica e Sistemistica
Algoritmi per il coordinamento
decentralizzato di flotte di micro-velivoli in
missioni di monitoraggio nel post-evento
catastrofico
Relatore
Candidato
Ch.mo Prof. Ing. Bruno Siciliano
Fabrizio Schiano
Matr. 533 000 388
[email protected]
[email protected]
Correlatore
Ing. Giuseppe Persechino
CIRA (Centro Italiano Ricerche Aerospaziali)
[email protected]
Anno Accademico 2008-2009
Fabrizio Schiano
Algoritmi per il coordinamento decentralizzato di flotte
di micro-velivoli in missioni di monitoraggio nel
post-evento catastrofico
2
Fabrizio Schiano
Alla mia Famiglia e a Ida
3
Fabrizio Schiano
Ringraziamenti
Dal punto di vista didattico, probabilmente, questa è la parte meno importante
della Tesi di Laurea, ma io dentro di me sento il dovere e la volontà di
ringraziare le persone che hanno reso possibile con il loro appoggio, il loro
incoraggiamento e i loro consigli, sia etici sia professionali, il raggiungimento di
questo traguardo, per me di un’importanza incommensurabile.
Mio padre, mia mamma e mio fratello sono senza ombra di dubbio le persone
più importanti della mia vita, sono loro che fino ad oggi hanno creduto in me
ogni secondo, senza smettere mai, ed è grazie soprattutto a loro che sono
giunto al termine di questo percorso, che per me significa molto, ma penso che
per loro significhi ancora di più. Sì, è vero che per dei genitori vedere un figlio
laureato sia una gioia immensa, ma io voglio cogliere l’occasione per fargli
capire che non devono essere felici solo per questo … loro sono e saranno per
sempre i punti fermi della mia vita, ed è principalmente grazie a loro se io ho
maturato questa grande passione per la Scienza. Sono loro le persone che mi
hanno fatto capire una cosa fondamentale: “con la forza di volontà si arriva
dove si vuole”. Io sono arrivato fin qui, lontano o meno che sia, ma la cosa
fondamentale è che ci sono arrivato felice, sì indubbiamente con dei sacrifici,
piccoli o grandi che si vogliano considerare, ma senza perdere mai la felicità nel
fare una cosa che mi attrae davvero tanto.
Una parola in più per mio padre la voglio spendere, in quanto oltre all’appoggio
umano, fondamentale, me ne ha dato anche uno professionale, con consigli di
ogni genere che mi hanno aiutato davvero nel superare esami e difficoltà, nel
confrontarmi con i docenti e avvicinarmi sempre più al mondo, bello,
4
Fabrizio Schiano
dell’Ingegneria. Ribadisco che probabilmente senza di lui non sarei qui, e sarà
per sempre, per me, il più grande esempio da seguire, in tutto e per tutto.
Un’altra persona che pian piano sta diventando sempre più importante e
insostituibile nella mia vita e che devo ringraziare, per il sostegno che mi ha
fornito e mi fornisce giorno per giorno è la mia fidanzata, Ida. In questi anni
anche grazie a lei sono riuscito ad andare avanti e a non arrendermi anche nelle
situazioni più difficili, è lei che mi sopporta ogni giorno, e che come i miei
genitori, mi ha appoggiato in quasi tutte le mie scelte, credendo sempre in me,
e rendendomi il “bersaglio”, consapevole e orgoglioso, del suo amore
incondizionato e sincero.
Ci vorrebbe una pagina intera per ringraziare tutti i miei amici, universitari e
non, e per non dimenticare nessuno ho deciso di non scrivere i loro nomi,
sapendo che tanto le persone per me importanti sono a conoscenza della
grande stima che nutro nei loro confronti. Vi ringrazio davvero di cuore, avete
reso questo mio piccolo percorso davvero gioioso.
Un grazie particolare va al mio tutor, Pino Persechino, che mi ha supportato
nella stesura di questa tesi fornendomi ogni giorno materiale nuovo, e nuovi
spunti, da cui apprendere e da cui imparare tantissime cose, che a volte mi
hanno fatto venire curiosità che andavano anche oltre quello che dovevo
scrivere. Ti sono grato, perché hai alimentato ancora di più la mia passione per
quello che studio, facendomi capire ancora una volta che teoria e pratica sono
strettamente collegate e quindi, come direbbe Leonardo Da Vinci : “Studia
prima la scienza e poi seguita la pratica nata da essa scienza. Quelli che
s'innamorano della pratica senza scienza, sono come i nocchieri che entrano
nella nave senza timone o bussola.”
5
Fabrizio Schiano
Ringrazio infine il mio professore, Bruno Siciliano, per avermi consentito, con la
sua approvazione, di intraprendere un percorso di studio che mi ha
appassionato davvero molto, manifestandomi inoltre una continua disponibilità
durante tutto il periodo di svolgimento della Tesi.
A tutti voi, con immenso rispetto e grande stima, vanno i miei più sentiti
ringraziamenti.
Pozzuoli (NA), Italia
11 Maggio 2010
Fabrizio Schiano
6
Fabrizio Schiano
Sommario
In questa tesi si vuole analizzare il problema del coordinamento di una flotta di
micro-velivoli senza pilota (SUAS1) impiegati in missioni di monitoraggio.
Tali sistemi possono essere utilizzati per svariate applicazioni civili. Tra queste
quelle più promettenti riguardano il monitoraggio a fini di sicurezza e ordine
pubblico e il monitoraggio ambientale, in questi settori le applicazioni sono
ancora a livello prototipale e di ricerca, mentre l’ uso di tali sistemi in ambito
militare è ormai consolidato e in continua crescita.
In particolare in questo lavoro di tesi si è scelto di analizzare le possibili
applicazioni di flotte di SUAS alla gestione del post-evento catastrofico di un
terremoto, prendendo come caso di studio specifico la calamità che ha colpito la
regione Abruzzo ed in particolare la città dell’ Aquila.
Il sisma ha avuto come scossa principale quella del 6 Aprile 2009 alle ore 3:32
con intensità pari a 5,8 della scala Richter e 6,3 nella scala di magnitudo del
momento sismico(Mw).
Il bilancio delle vittime di questo terremoto è stato di 308 morti, mentre il
numero di feriti è stato di 1500 ca., inoltre ci sono stati ingenti danni al
patrimonio immobiliare ed artistico.
L’utilizzo dei sistemi sopraindicati, dotati di specifici sensori, ha come scopo il
miglioramento della gestione del post-evento in modo da ridurre il numero di
vittime. L’innovazione richiesta riguarda principalmente un aumento della
consapevolezza dello scenario di danno utile a dare risposte più veloci ed
accurate da parte delle forze di soccorso e al tempo stesso a ridurre i fattori di
rischio per gli addetti alle missioni di recupero.
1
Small Unmanned Aerial Systems: è un neologismo che si sta sostituendo al termine “Micro Air Vehicle
(MAV)”, per mettere in evidenza che quello di cui si parla non è semplicemente un veicolo, ma un vero e
proprio sistema, inteso come un’unità che può analizzare dei dati, memorizzarli, gestirli, prendere
decisioni e comunicare con altri tipi di sistemi. I SUAS sono delle piattaforme che pesano da 0 a 25 Kg.
7
Fabrizio Schiano
La tesi è organizzata come segue:
Capitolo 1
In questo capitolo viene inquadrato il problema relativo alla gestione del post
evento catastrofico.
La soluzione proposta prevede l’utilizzo di flotte di micro-veicoli cooperanti ed è
applicabile al monitoraggio e alla gestione di eventi catastrofici legati a
differenti cause:
naturali: sismiche, idrogeologiche, vulcaniche ecc.
antropiche: attentati, disastri ambientali, incendi ecc.
Quanto proposto riesce a coniugare una forte riduzione nei costi, rispetto ai
sistemi attualmente impiegati, con un livello di performance molto elevato, si
caratterizza inoltre per una elevata velocità operativa ed elevati livelli di
sicurezza, grazie alle dimensioni ridotte delle piattaforme utilizzate.
Per dare forza pragmatica alla nostra analisi si è scelto di utilizzare come caso di
studio lo scenario relativo al terremoto dell’Aquila. In questo capitolo vengono
da prima identificati i requisiti di missione per poi passare alla definizione delle
tipologie di sensori e delle piattaforme necessarie al monitoraggio del centro
della città dell’Aquila che si sviluppa su di un area di circa 2km per 2km.
La distribuzione, individuata, di sensori di tipo diverso installati su più
piattaforme cooperanti è, di fatto, una strategia vincente in missioni con le
dimensioni di scenario come quelle identificate.
Emerge, però, come conseguenza la necessità di utilizzare algoritmi di controllo
decentralizzato delle piattaforme in grado di rendere robusto e scalabile il
sistema.
Capitolo 2
L’esigenza di controllo decentralizzato delle piattaforme aeree emersa nel
precedente capitolo ci porta ad analizzare come possibile soluzione algoritmi di
Swarm Intelligence oggetto di questo capitolo.
8
Fabrizio Schiano
Si approfondisce il legame fondamentale, che c’è tra la Natura e i concetti propri
della Swarm Intelligence. Quindi si passa poi ad illustrare due concetti
fondamentali:
Decentralizzazione
Stigmergia
propri della Swarm intelligence.
La modellazione software di algoritmi Swarm attinge proficuamente alle
tecniche proprie dei sistemi multi-agente. In tali sistemi infatti gli “agenti”
mappano direttamente i componenti della swarm intelligence (es. insetti) e
consentono di modellare agevolmente le loro relazioni. I paradigmi di tipo
Swarm implementati con tecniche multi-agente che verranno analizzati nel
seguito della trattazione sono :
Polyagents
Ant-Colony-Optimization (ACO)
Ideati rispettivamente da H. Van Dyke Parunak e Marco Dorigo. Di questi
paradigmi verranno esaminati gli algoritmi fondamentali, mettendone in luce
vantaggi e svantaggi e le differenze tra i due approcci.
Capitolo 3
Come visto nel precedente capitolo per implementare algoritmi Swarm risulta
necessario utilizzare tecniche multi-agente. Questo capitolo vuole soffermarsi
sullo stato dell’ arte delle piattaforme di simulazione e sviluppo per tali sistemi
oggi disponibili come Open Source.
L’analisi ha riguardato le seguenti piattaforme:
NetLogo
MASON
Swarm (Java version)
Swarm (Objective-C version)
Repast
9
Fabrizio Schiano
Dopo questa analisi, si sono individuati i punti di forza e quelli di debolezza delle
piattaforme elencate. Inoltre si presenta il lavoro di standardizzazione, molto
importante, che viene svolto dalla FIPA, un’organizzazione di standard della IEEE
Computer Society che promuove la tecnologia agent-based e l’interoperabilità
dei suoi standard con altre tecnologie.
Capitolo 4: In questa ultima parte della Tesi sono riportate alcune
considerazioni conclusive sul lavoro svolto e in particolare sulla differenza
concettuale tra il paradigma proposto da Parunak (Polyagent) e quello proposto
da Dorigo (Ant-Colony-Optimization). Inoltre si presenta un elenco di priorità
relativo allo sviluppo di piattaforme software multi-agente.
10
Fabrizio Schiano
Indice dettagliato
Capitolo 1
Analisi del Problema .............................. 14
1.1 Introduzione ....................................................................... 14
1.2 Il sistema attuale di gestione del post-evento sismico....... 15
1.3 Un possibile utilizzo di piattaforme aerospaziali e terrestri per
la gestione del Post-Evento ......................................................... 18
1.4 I componenti del sistema ...................................................... 25
1.4.1
Sensori ............................................................................................26
1.4.2
Piattaforme ....................................................................................29
1.5 Problemi connessi al controllo di flotte di velivoli ................ 34
1.5.1 Sorveglianza aerea e inseguimento...................................................34
1.5.2 Elusione degli ostacoli e delle collisioni ............................................34
1.5.3 Riconfigurazione della formazione ....................................................35
1.5.4 Hardware e comunicazione ...............................................................35
Capitolo 2
Algoritmi di swarm intelligence ............. 36
2.1 Introduzione .......................................................................... 36
2.2 Dalla Natura alla Swarm Intelligence .................................... 36
2.3 Esempi di Swarm Intelligence in Natura ................................ 42
11
Fabrizio Schiano
2.3.1 Flocking (comportamento di uno stormo di uccelli o di un banco di
pesci) ...........................................................................................................44
2.3.2 Accerchiamento della preda ..............................................................44
2.3.3 Comportamento delle formiche ........................................................45
2.4 Formalizzazione del concetto di decentralizzazione ............. 48
2.5 Campo a potenziale e feromoni digitali ................................ 52
2.6 Il paradigma Polyagent .......................................................... 54
2.6.1 Descrizioni degli algoritmi .................................................................60
2.6.1.1 Algoritmo di sorveglianza e pattugliamento ............................... 60
2.6.1.2 Algoritmo di acquisizione dell’obiettivo ...................................... 62
2.6.1.3 Algoritmo di inseguimento dell’obiettivo .................................... 63
2.7 Il paradigma Ant-Colony-Optimization (ACO) ....................... 64
2.7.1 Gli algoritmi di Ant Colony Optimization più importanti ..................69
2.7.1.1 Ant system(AS) ............................................................................. 69
2.7.1.2 Elitist Ant System(EAS)................................................................. 72
2.7.1.3 Rank-Based Ant System ............................................................... 73
2.7.1.4
AS...................................................................... 73
2.7.1.5 Ant Colony System ....................................................................... 75
2.8 Differenze tra Polyagent e Ant Colony Optimization ............ 77
Capitolo 3
Piattaforme per lo sviluppo di applicazioni
multi-agente .......................................... 80
3.1 Introduzione .......................................................................... 80
3.2 Dalla tecnologia agent-based ai MAS (Multi-Agent-System) 82
3.3 Specifiche FIPA....................................................................... 86
3.4 Le piattaforme software per modelli Agent-Based ............... 87
12
Fabrizio Schiano
3.4.1 NetLogo ..............................................................................................87
3.4.2 SWARM (Objective-C & Java versions) ..............................................91
3.4.3 Repast .................................................................................................95
3.4.4 MASON ...............................................................................................98
3.5 Qual è la piattaforma migliore?........................................... 102
Capitolo 4
Conclusioni .......................................... 107
Bibliografia .......................................... 111
13
Fabrizio Schiano
Capitolo 1
Analisi del Problema
1.1 Introduzione
In questi anni tra i temi di crescente interesse nel settore dell’automazione e
dell’elettronica in generale, vi è sicuramente il controllo di flotte di veicoli
unmanned cooperanti, sia volanti (UAS: Unmanned Aerial Systems), sia terrestri
(UGV: Unmanned Ground Systems).
Le applicazioni di questi sistemi sono svariate: in questa tesi si andrà ad
approfondire l’utilizzo nel settore del monitoraggio ambientale e nella gestione
del post-evento catastrofico, che sono ritenuti tra i fattori trainanti dello
sviluppo socio-economico e che sono quindi tra i temi di interesse prioritario dei
programmi internazionali, UE e nazionali, di ricerca.
In Europa l’avvio del programma GMES (Global Monitoring for Environment and
Security), e nell’ambito dell’UE FP7, di uno specifico programma dedicato alla
sicurezza sono solo alcuni esempi di tale interesse.
Tra gli eventi, generati da cause naturali ed antropiche, che traggono maggior
vantaggio dall’utilizzo cooperativo dei suddetti sistemi aerospaziali e terrestri
per le attività di monitoraggio e gestione vi sono:
Terremoti
Eruzioni vulcaniche
Frane ed alluvioni
Incendi
Attentati terroristici
Disastri ambientali
14
Fabrizio Schiano
Come già detto nelle pagine precedenti l’applicazione specifica da cui si partirà
in questa lavoro di tesi è quella del recente evento sismico che ha colpito
l’Abruzzo. In questo primo capitolo si effettuerà una analisi di fattibilità per
l’integrazione di un sistema per il monitoraggio aereo nella gestione del postevento sismico e vulcanico. Inoltre verrà inglobata nella analisi di fattibilità
un’ipotesi di scelta delle migliori tecnologie per lo scopo richiesto, ovvero
l’analisi delle piattaforme (terrestri ed aeree) e i relativi sensori ed attuatori.
1.2 Il sistema attuale di gestione del post-evento
sismico
Le strategie per la gestione del rischio possono consistere in:
Mitigazione del rischio attraverso la riduzione della vulnerabilità e/o
dell’esposizione;
Risposta rapida per la gestione dell’emergenza nel post-evento.
Quanto prima avviene la fase di gestione del Post-Evento, da parte delle
autorità competenti, tanto più si potrà essere efficaci nel salvare le vittime.
L’utilizzo di flotte di velivoli cooperanti si può applicare sia al monitoraggio per
Early Warning che alla gestione del post evento. In tale senso il sistema di Early
Warning può essere visto proprio come un anticipatore di Post-Evento.
Un piano di emergenza, in caso di post evento catastrofico sismico o vulcanico,
predispone un sistema articolato di attivazione di uomini e mezzi, organizzati
secondo un quadro logico e temporalmente coordinato, che costituisce il
modello di intervento atto al soccorso delle popolazioni.
La base conoscitiva per il dimensionamento delle risorse da mettere in campo è
costituita dagli scenari di danno. È evidente che quanto prima viene aggiornata
la conoscenza dello scenario di danno, tanto più sarà possibile salvare vite
umane.
Gli attuali strumenti di previsione del possibile danneggiamento e del
conseguente coinvolgimento della popolazione si basano principalmente su
informazioni statiche e pregresse come la densità abitativa e la tipologia di
15
Fabrizio Schiano
edifici presenti nell’area geografica in esame. Tali informazioni rappresentano
solo un orientamento indicativo rispetto alla reale distribuzione delle vittime.
Gli scenari di danno delle fasi iniziali dell’evento catastrofico possono essere
previsti intersecando i dati territoriali di esposizione e vulnerabilità (noti) con i
dati relativi all’evento accaduto. Anche in questo caso i dati acquisiti sul campo
sono di fondamentale importanza per aggiornare tali previsioni.
La conoscenza dello scenario di danno permetterebbe di ottenere un quadro
territoriale dell’area coinvolta dall’evento fornendo, quindi, informazioni quali la
localizzazione e l’estensione dell’area maggiormente colpita, la funzionalità
delle reti dei trasporti, delle vie di comunicazione e delle linee di distribuzione,
oltre che le perdite attese in termini di vite umane, feriti, senza tetto, edifici
crollati e danneggiati ed il corrispondente danno economico. Questi dati sono di
fondamentale importanza nelle attività di pianificazione e di gestione
dell’emergenza da parte della Protezione civile.
Nell’emergenza, quindi, gli scenari di danno forniscono una descrizione
immediata dell’evento reale e del suo impatto sul territorio e sulla popolazione
e permettono di organizzare adeguatamente i soccorsi.
In caso di un terremoto, di magnitudo del momento sismico pari a 5 o superiore,
l’Istituto Nazionale di Geofisica e Vulcanologia trasmette ai dipartimenti
interessati i parametri focali (magnitudo e coordinate) dell’evento, attivando
una procedura automatica per la generazione del rapporto che viene reso
disponibile entro 10 minuti dall’evento. Il rapporto contiene dati, mappe e
informazioni relativi a tutti i comuni compresi in un raggio di 100 km intorno
all’epicentro e in particolare:
descrizione del territorio: aspetti antropici, fisici e amministrativi;
caratteristiche degli edifici e delle infrastrutture; reti di monitoraggio sismico;
pericolosità: zone sismogenetiche, terremoti storici, zone che hanno
riportato gli stessi danni, attenuazione del moto del terreno;
vulnerabilità: patrimonio edilizio, scuole, ospedali, rete stradale e
ferroviaria;
16
Fabrizio Schiano
esposizione: caratteristiche e distribuzione della popolazione residente in
ciascuna sezione censuaria;
valutazione preliminare dei danni e delle perdite: abitazioni danneggiate e
inagibili, stima dei morti e feriti, stima del danno economico.
Nei giorni immediatamente successivi ad un evento sismico, le valutazioni degli
effetti del terremoto continuano attraverso azioni sul campo diversificate e
finalizzate a determinare l’intensità macrosismica in ogni centro abitato e gli
effetti geologici e idrogeologici (frane, fagliazioni superficiali, ecc.) e ad
effettuare un’azione di monitoraggio di dettaglio del terreno e delle strutture
delle scosse successive, mediante strumentazioni mobili.
Le procedure operative di allarme di solito possono essere divise in 3 fasi:
La prima fase prevede l’acquisizione dei dati utili a definire i limiti dell’area
colpita dall’evento, l’entità dei danni, le conseguenze sulla popolazione, sulle
attività produttive, sulle funzionalità dei servizi a rete, gli interventi tecnici di
urgenza, quelli atti a salvaguardare la popolazione colpita, ed il ripristino della
funzionalità del sistema urbano.
La raccolta dei dati è affidata alle funzioni interessate, le informazioni sono poi
vagliate dall’organo decisionale ed inviate al dipartimento della Protezione
civile, alla Regione, alla provincia ed alla prefettura.
La seconda fase è relativa alla valutazione dell’evento in modo da configurare in
maniera più precisa le dimensioni e le conseguenze immediate indotte dal
fenomeno, l’entità delle risorse e dei mezzi da mobilitare.
La terza fase è relativa all’adozione dei provvedimenti del caso:
Verifica delle funzionalità delle aree di emergenza e delle strutture ricettive
e loro attivazione
Invio di squadre di soccorso nelle aree dove è concentrata la popolazione
Attivazione evacuazione, assistenza, invio risorse, materiali e mezzi.
17
Fabrizio Schiano
1.3 Un possibile utilizzo di piattaforme aerospaziali e
terrestri per la gestione del Post-Evento
Un approccio innovativo per la gestione del post-evento sismico e vulcanico
potrebbe prevedere lo sviluppo di un sistema che integri innovative piattaforme
aeronautiche, innovative piattaforme terrestri e specifici sensori con il sistema
di gestione del post evento. Tale sistema permetterebbe di monitorare in
maniera dinamica i luoghi dove e’ avvenuto l’evento e quindi di verificare e
aggiornare le mappe di scenario di danno nel post evento in modo rigoroso ed
efficiente.
Ad oggi l’utilizzo di piattaforme aeree per la gestione del post evento e’ limitata
all’utilizzo di aerei ed elicotteri, con equipaggio a bordo, spesso messi a
disposizione dalle forze dell’ordine e dalla Protezione Civile.
La disponibilità di tali mezzi è esigua, visto i loro costi, sia di acquisto che di
gestione operativa, e spesso le informazioni raccolte dai piloti sono inviate a
voce alla centrale non avendo a bordo payload e data link per trasmettere
immagini,
video
e
informazioni
automaticamente a terra.
Le quote operative dei sistemi attuali,
soprattutto aerei, sono elevate e solo gli
elicotteri possono scendere a quote più
basse ma spesso ad alto rischio per il
pilota (si pensi ad esempio all’intervento
durante un’eruzione vulcanica).
Figura 1 : Satellite Landsat5 che fa parte di un
insieme di satelliti che osservano la Terra. I dati
da loro collezionati sono stati usati per oltre 30
anni per studiare l'ambiente, le risorse, e i
cambiamenti naturali e artificiali avvenuti sulla
superficie terrestre.
Anche i sistemi satellitari (vedi fig. 1) sono
utilizzati per avere immagini di vaste aree
colpite da sisma o eruzione vulcanica, ma
la frequenza di aggiornamento di tali
immagini è bassa, tipicamente di alcuni
giorni, nel migliore dei casi 5-10 ore, e
comunque le loro risoluzioni spaziali
(tipicamente 1m) sono molto più basse di
18
Fabrizio Schiano
quelle ottenibili da sensori posti su velivoli da bassa quota (5cm). Inoltre le
piattaforme satellitari, almeno nel visibile e nell’infrarosso, sono fortemente
influenzate dalle condizioni meteorologiche.
Tutti i sistemi appena esposti sono in grado di riprendere principalmente
immagini ortonormali alla loro traiettoria o inclinate di pochi gradi, e
difficilmente possono catturare informazioni presenti su piani diversi
dall’orizzontale come quelli verticali tipici ad esempio delle facciate di palazzi
(vedi fig. 2).
Infine va detto che le piattaforme ad oggi impiegate non sono integrate con un
sistema di gestione del post-evento, lasciando quindi la divulgazione, la
memoria e il coordinamento delle informazioni al solo personale coinvolto nelle
operazioni.
I limiti degli attuali sistemi potrebbero essere quindi superati attraverso una
soluzione basata su un sistema composto da piattaforme SUAS (Small
Unmanned Aerial Systems) e sensori miniaturizzati integrati, a livello logico e di
sistema, con una centrale di elaborazione dati. Altro notevole vantaggio
potrebbe essere ottenuto attraverso un’attività di coordinamento di queste
piattaforme aeree con alcune piattaforme terrestri.
Figura 2 : Conseguenze del sisma su due palazzi di L'Aquila (questo tipo di immagini non possono essere date da
un sistema di monitoraggio satellitare).
Tale soluzione permetterebbe di coniugare una forte riduzione dei costi,
rispetto ai sistemi attualmente impiegati, con un livello di performance molto
elevato, e si caratterizzerebbe per una elevata velocità operativa grazie alle
dimensioni ridotte delle piattaforme utilizzate. Sarebbe inoltre possibile un
collegamento diretto di questi sistemi al sistema di early warning.
19
Fabrizio Schiano
Le piattaforme aeree previste e i relativi sensori dovrebbero essere capaci di
acquisire informazioni utili alla:
localizzazione ed estensione reale dell’area colpita;
verifica delle funzionalità delle reti dei trasporti, delle vie di comunicazione
e delle linee di distribuzione;
identificazione reale delle vittime, dei feriti e dei senza tetto;
identificazione reale degli edifici crollati e danneggiati.
Per la gestione del post-evento ciò permetterebbe, già nella fase di early
warning, una attività di costruzione dello scenario di danno a partire da mappe
di fragilità (vulnerabilità) da correlarsi con l’intensità e la posizione
georeferenziata dell’epicentro.
Tali mappe, che costituiscono l’output di un modello previsionale, sarebbero
disponibili entro circa 1 ora a partire dall’inizio dell’evento catastrofico.
Figura 3 : Terremoto di L'Aquila, ipotesi di scenario di danno.
20
Fabrizio Schiano
Lo scenario così calcolato potrebbe essere reso disponibile per la consultazione
attraverso un geographical information system (GIS)2.
La definizione delle traiettorie di missione delle piattaforme aeree potrebbe
realizzarsi utilizzando i modelli di scenario di danno pre-calcolati nelle fase di
early warning in modo da ottimizzarne le risorse. In questo modo infatti le
piattaforme aeree previste, si porterebbero nel più breve tempo possibile in
prossimità delle aree probabilmente più colpite, realizzando specifiche
traiettorie di volo in grado di massimizzare la copertura del territorio con i
sensori trasportati nel minor tempo possibile.
Tali piattaforme aeree potrebbero essere rese operative direttamente dal
sistema di early warning, sia perché immediatamente trasportate in loco da
specifici mezzi di soccorso, sia perche già presenti sul territorio, ad esempio a
disposizione dell’unità della protezione civile del luogo colpito.
Funzionale all’acquisizione delle informazioni, in questo scenario, sono i sensori
elettro-ottici in grado di riprendere sia immagini fisse che in movimento, ad alta
risoluzione, dello scenario osservato.
Le immagini opportunamente georeferenziate ed ortorettificate andranno ad
essere correlate ai dati generati dalla previsione e visualizzate all’interno del
GIS, fornendo così alle autorità preposte uno strumento per la
verifica/aggiornamento dello scenario di danno.
Affiancati ai sensori elettro-ottici, si potrebbero impiegare avanzati sensori
radiometrici in grado di rilevare i campi di temperatura dello scenario osservato
e quindi utili:
nella visione notturna;
a rilevare la presenza di persone;
a rilevare focolai di incendio;
alle verifiche strutturali degli edifici danneggiati.
2
Un GIS è un sistema informativo computerizzato che permette l'acquisizione, la registrazione, l'analisi,
la visualizzazione e la restituzione di informazioni derivanti da dati geografici (geo-riferiti).
21
Fabrizio Schiano
Relativamente alla misura della morfologia del terreno e alle verifiche strutturali
degli edifici danneggiati si potrebbe impiegare uno specifico sensore laser
scanner in grado di misurare con accuratezza dati geometrici.
La scelta dei sensori (COTS3) sopra elencati dovrà essere effettuata
considerando la loro installazione su piattaforme di piccole dimensioni (SUAS).
Le piattaforme aeree da utilizzare dovrebbero essere, infatti, della classe
“Small” UAS. Tali piattaforme hanno specifiche peculiarità che le renderebbero
particolarmente adatte alle missioni descritte:
La prevalenza in queste missioni di scenari urbani impone mezzi in grado di
muoversi con agilità in spazi ristretti a bassa quota, dove UAV standard non
potrebbero operare.
Le dimensioni delle aree da monitorare sono relativamente estese (ad
esempio per quanto riguarda il terremoto di L’Aquila, il centro storico è di 2Km x
2Km ca.) quindi le autonomie di volo sono compatibili con le missioni previste.
In generale per questo tipo di applicazioni i budget disponibili sono limitati e i
SUAS sono relativamente economici sia nell’acquisto che nella gestione, ancora
di più se usano payload COTS.
Considerando che le missioni si svolgono in prossimità del suolo e in aree
densamente abitate sono richiesti alti livelli di sicurezza. La bassa energia
cinetica dovuta al basso peso e alle basse velocità di questi velivoli li rende
intrinsecamente più sicuri di velivoli standard.
Considerata la loro relativa semplicità tecnologica ad oggi sono disponibili sul
mercato numerosi prodotti sia ad ala fissa che ad ala rotante a basso costo, utili
alla sperimentazione di nuove tecnologie a livello di sistema.
Relativamente alle piattaforme terrestri anche queste potrebbe essere
individuata nella classe “Small” per permettere di esplorare anche spazi ristretti
3
Commercial Off-the-Shelf component, si riferisce a componenti hardware e software disponibili sul
mercato per l'acquisto da parte di aziende di sviluppo interessate a utilizzarli nei loro progetti. L'uso di
componenti COTS hardware rappresenta una possibilità consolidata; la stessa espressione "COTS"
applicata al software viene usata per riferirsi a un obiettivo (forse il principale) dell'ingegneria del
software come disciplina: arrivare a sviluppare gli strumenti tecnologici, concettuali e pragmatici
necessari per creare un mercato dei componenti reale.
22
Fabrizio Schiano
come anfratti, cunicoli, interni di abitazioni ecc., dove le piattaforme volanti non
potrebbero accedere.
Anche se il sistema proposto ha uno scopo solo dimostrativo, per il suo
dimensionamento ci si è posti come requisito di missione, come già accennato
in precedenza, quello di poter monitorare una zona di 2Km x 2Km, ovvero con
un’estensione circa uguale a quella del centro storico di L’Aquila.
Figura 4 : schema funzionale del sistema proposto
Di seguito è riportata una possibile descrizione delle probabili fasi della missione
di monitoraggio aereo e i relativi requisiti necessari al dimensionamento del
sistema proposto; si è supposto di dividere la missione in quattro fasi salienti:
1.
La prima fase dovrebbe essere finalizzata ad ottenere un rapido
aggiornamento, in circa 30 minuti, dei dati satellitari ante-evento con nuove
informazioni provenienti dai sensori elettro-ottici e infrarosso posti sui Micro
UAV, con una risoluzione, nel visibile, di circa 4 cm per pixel e di circa 30 cm per
pixel nell’infrarosso. L’output sarà costituito da una sequenza di immagini orto-
23
Fabrizio Schiano
rettificate e geo-referenziate, utili ad aggiornare le mappe di scenario
predeterminate, che saranno rese disponibili, per la visualizzazione, nel
software GIS.
Oltre alle immagini riprese in modalità ortonormale, il sistema dovrebbe poter
contemplare la possibilità di fornire, per un numero fissato di luoghi (ad
esempio 8) definiti dall’utente (ad esempio: piazze, incroci viabilità, ecc),
immagini panoramiche con punto di vista orizzontale, che coprano un campo di
vista di 360 gradi rispetto al velivolo. Tali immagini potranno essere visualizzate
in opportuni visualizzatori (es. QuickTime-VR4).
Figura 5 : Altre immagini di L'Aquila
2.
La seconda fase della missione dovrebbe avere come fine quello di
posizionare i sensori rispetto a una serie di target da monitorare nel tempo,
definiti dall’utente. Il velivolo si porterà in prossimità del target e atterrerà,
compatibilmente con il punto di vista desiderato, o vi stazionerà in hovering.
Per il dimensionamento del sistema si dovrà considerare ad esempio che tale
acquisizione dovrà essere eseguita per 6 target diversi per un tempo di 10
minuti massimo ciascuno e con campo di vista che può essere sia ortonormale al
terreno che orizzontale rispetto al terreno. L’output dei sensori dovrà essere
una sequenza video geo-referenziata. La risoluzione opportuna sarebbe quella
di un quadro PAL5 da visualizzare in tempo reale a terra, e di un quadro full HD
da salvare a bordo e visualizzabile a terra off-line.
4
QuickTime VR (virtual reality), anche conosciuto come QTVR è un formato di file immagine supportato
da QuickTime della Apple. Esso permette la creazione e visualizzazione di panorami catturati
fotograficamente e l’esplorazione di oggetti attraverso le immagini perse da diversi angoli di
prospettiva.
5
Il PAL (acronimo dell'inglese Phase Alternating Line) è un metodo di codifica del colore utilizzato nella
televisione analogica, usato da gran parte del mondo. Fanno eccezione il continente americano, alcune
nazioni dell'est asiatico, parte del Medio Oriente, dell'Europa orientale e la Francia.Il termine "PAL" è
spesso usato informalmente per riferirsi al formato video analogico a 625 linee/50 Hz (576i, comune nei
paesi europei), così come il termine "NTSC" indica spesso il formato a 525 linee/60 Hz (480i), usato in
Nord America e in Giappone.
24
Fabrizio Schiano
Per alcuni dei target identificati andrà trasportato in loco il robot terrestre come
piattaforma di supporto nell’ esplorazione dei luoghi.
3. La terza fase della missione dovrebbe riguardare lo sviluppo di un rilievo
dell’altimetria del terreno e delle costruzioni con una risoluzione in altezza
inferiore a 10cm e con una griglia di risoluzione inferiore a 50cm di lato. Si
considererà utile una copertura relativa ad un’area di 1Km x 1Km, definita
dall’utente, da effettuarsi in circa 30 minuti.
Figura 6 : Esempi di rilievo 3D effettuato con Laser scanner
4.
La quarta fase consisterà nel riprendere da bassa quota (3-4 metri) le
principali strade della città (circa 100Km di strade totali all’Aquila di cui e’
richiesta copertura per il 40%). La ripresa potrà avvenire con una speciale
camera ad obbiettivo sferico che permetterà di riprendere in full HD un video a
360° panoramico (tipo Google Street View). Tale video sarà salvato a bordo a
piena risoluzione per essere consultato off-line opzionalmente potrà essere
inviato in formato PAL a terra.
Tutte le fasi della missione sopra descritte potranno essere svolte sia in una
sequenza temporale che in parallelo, questo dipenderà dal numero di
piattaforme impiegate, dalla loro capacità di payload e dagli algoritmi utilizzati
per la definizione delle traiettorie.
1.4 I componenti del sistema
Di seguito è riportata una analisi delle caratteristiche dei possibili componenti
del sistema necessari a valutare le performance attese dal sistema.
25
Fabrizio Schiano
1.4.1 Sensori: Come già detto, i sensori che sono probabilmente i più indicati
per la missione in esame sono i sensori COTS, i quali saranno scelti in base ad
una analisi dello stato dell’arte relativa ad ogni tipologia di sensore, ai requisiti
di missione, alle necessarie caratteristiche tecniche e al peso.
Le caratteristiche tecniche dei possibili sensori selezionati sono di seguito
elencate:
I sensori elettro-ottici possono essere divisi in due principali categorie
fotografici e video.
I sensori fotografici (Pansonic DMC FX68, Panasonic GF1) in virtù della loro
elevata risoluzione (rispettivamente: 4320 x 3240 pixel a 0.3 Hz e 4000 x 3000
pixel a 0.3 Hz) si fanno preferire, agli altri sensori presenti sul mercato, per la
prima fase della missione: aggiornamento delle mappe di scenario nel visibile.
Entrambe le macchine fotografiche individuate rappresentano il miglior
compromesso tra prestazioni, peso e costi di acquisto.
La DMC FX68, appena presentata al pubblico, ha una risoluzione di 14.1 Mpixel
con un zoom ottico 5x, peso di soli 145gr e ottica Leica stabilizzata POWER
O.I.S., questa nuova tecnologia raddoppia le già ottime performance di
stabilizzazione ottica degli obbiettivi precedenti e la rende particolarmente
adatta alle esigenze esposte in precedenza. Tale macchina permette inoltre di
acquisire sequenze video HD a risoluzione di 720p.
La Panasonic GF1 è una macchina fotografica compatta ad obbiettivo
intercambiabile con sensore Live MOS ad alta sensibilità da 12.1 Mpixel. Le
generose dimensioni del sensore (4/3 di pollice) paragonabile a quello delle più
pesanti reflex, la rendono tra le migliori macchine fotografiche con basso peso
(circa 390 gr. con obiettivo da 20mm). Tale macchina permette inoltre di
acquisire sequenze video HD a risoluzione di 720p.
Riguardo ai sensori video si potrebbe pensare di selezionare due tipi di sensore:
la Point Gray Chameleon e la Sony Bloggie PM5k.
La prima telecamera, con sensore di tipo CCD (Charge Coupled Device) da 1/3 di
pollice e risoluzione di 1296x964, è dotata di collegamento USB e sarà utilizzata
sia per controllare il velivolo che per acquisire video nella seconda fase di
missione.
26
Fabrizio Schiano
La Sony Bloggie PM5k è una telecamera Full HD 1920x1080 che permette di
registrare video panoramici a 360° con una particolare lente aggiuntiva. Le sue
ridottissime dimensioni e il bassissimo peso (solo 130gr) rendono questa
telecamera molto adatta alle installazioni su piattaforme SUAS. Questa
telecamera potrebbe essere utilizzata nella quarta fase della missione.
Relativamente ai sensori a infrarossi potrebbe essere scelto un sensore LWIR
(Long-Wave InfraRed) con sensore bolometrico non raffreddato.
Tale tipologia di sensori operano nella banda che va da 7 a 13μm e rispetto ai
sensori MWIR (Medium-Wave InfraRed), che vanno da 3 a 5μm, offrono
maggiore precisione e dinamica nella determinazione dei campi di temperatura
della scena.
Inoltre, nell’ausilio alla visione, i sistemi LWIR possono vedere attraverso il fumo
o la nebbia grazie al fatto che il range di frequenze elettromagnetiche, cui sono
sensibili questi sensori, e’ molto più basso di quello relativo al visibile e anche al
MWIR.
Nella visione notturna, poi, permettono di vedere la radiazione emessa dagli
oggetti e quindi di identificare i target anche con totale assenza di luce.
Pochi sono i prodotti COTS con sensori bolometrici disponibili in Core di piccole
dimensioni e peso. Inoltre quelli che ci sono, sono spesso di solo ausilio alla
visione e non misurano temperature, e sono usati per lo più in campi di
applicazione di tipo militare. L’unico sensore in alta definizione, 640x480 pixel a
50Hz, che consente di acquisire una reale matrice di temperature della scena è il
sensore della Thermoteknix modello Miricle 307k. Tale sensore dispone di varie
ottiche e pesa circa 160 gr con ottica 14,95mm. Questo sensore particolare
dispone di un software di acquisizione e calibrazione che permette di salvare
sequenze radiometriche di immagini a 50 fotogrammi al secondo via USB. Tale
sensore potrebbe essere utilizzato nella prima e nella seconda fase della
missione.
Come strumento di misura di altimetria e distanze la scelta potrebbe andare
verso sensori basati su tecnologia Laser, considerando i sensori ad ultrasuoni
molto leggeri ma con poco range operativo. Nella classe dei Laser scanner solo
due sono le aziende che hanno a catalogo prodotti COTS ad uso di applicazioni
robotiche: SICK e HOKUYO. Tra i due prodotti quello SICK ha performance
27
Fabrizio Schiano
superiori ma il prodotto UTM-30LX della HOKUYO ha un peso (circa 370gr) che è
circa un quarto di quello SICK. Tale Laser scanner ha un range di 30m con un
angolo di 270° con una accuratezza di circa 3cm e una frequenza di scansione di
40Hz.
Tutti i sensori sopra elencati hanno bisogno di essere correttamente
georeferenziati e ortonormalizzati affinché i dati possano essere correttamente
correlati ai dati GIS e quindi proiettati nelle mappe di scenario. Tale operazione
per essere effettuata ha bisogno di sistemi di misura di assetto e di posizione del
velivolo durante le riprese. Normalmente anche i velivoli di classe SUAS già
dispongono di tali sensori utili alla loro stabilità e navigazione, tali sensori però
non hanno sempre l’accuratezza necessaria. Si potrebbero sperimentare per ciò
specifici sensori di assetto e posizione ad alta precisione. In questa categoria si
potrebbero prendere in considerazione i seguenti: X-Sens MTI-G relativamente
all’assetto e il sistema Novatel DGPS + GLONASS per le misure di posizione;
quest’ultimo sensore consente di raggiungere la precisone di posizione di soli
2cm in orizzontale e di soli 4 cm in verticale.
Tutti i sensori analizzati finora hanno bisogno, per funzionare e per la fase di
processing e post-processing dei dati acquisiti (compressione, archiviazione,
ecc.), di un computer standard che oltre alle operazioni già elencate deve anche
essere in grado di trasmettere a terra i dati con un Data Link specifico. Questo
Pc dovrebbe appartenere alla classe micro e potrebbe avere, ad esempio, le
seguenti caratteristiche:
Processore ATOM Z530 1.6 GHz
2Gb RAM, CF 16Gb
LAN, 4x USB, 2x RS 232
OS(Sistema Operativo): Linux, Windows XP
Dimensioni 10x7,2 cm
Consumo 8W- a 5V
Peso circa 120 gr
Il PC dovrebbe essere collegato ai microcontrollori delle piattaforme attraverso
una connessione seriale.
Alcuni dei sensori selezionati hanno comunque una autonoma capacità di
storage dei dati che si affiancherà a quella disponibile sul micro PC.
28
Fabrizio Schiano
La distribuzione di payload diversi su più piattaforme interoperabili e cooperanti
è, di fatto, una strategia propria dello scenario proposto ed è strettamente
legata all’approccio scelto che vede l’utilizzo di SUAS come piattaforme. Come
già anticipato precedentemente, infatti, tale approccio si dovrebbe dimostrare
vincente in missioni con le dimensioni di scenario come quelle identificate.
Inoltre l’uso di più piattaforme, introduce un livello di ridondanza dei sensori,
cosa che rende molto robusto il sistema di fronte alla rottura (failure) di una di
esse.
Figura 7 : Esempio di monitoraggio del centro storico di L'Aquila
1.4.2 Piattaforme: Per identificare correttamente dei possibili tipi di
piattaforme da utilizzare e le performance ad essa richieste, sono stati
considerati: i requisiti di missione definiti in precedenza, le specifiche tecniche
dei singoli payload e le relative configurazioni previste nelle varie fasi di
missione.
Le piattaforme SUAS che meglio sposano i requisiti sopra esposti sono le
piattaforme ad ala rotante. Tali piattaforme sono quelle che meglio rispondono
alla necessità di svolgere missioni complesse in environment complessi (fig.8).
Considerando infatti irrinunciabile una capacità di hovering su punto fisso, una
capacità di atterraggio e decollo verticale e una altissima manovrabilità a basse
velocità, le piattaforme ad ala fissa non vengono considerate, pur
29
Fabrizio Schiano
apprezzandone i vantaggi relativi alla loro elevata efficienza. All’interno della
classe di piattaforme ad ala rotante si stanno sempre più affermando i sistemi
multirotore, costituiti da 4 fino a 12 rotori di dimensioni più piccole e contro
rotanti per compensare le coppie di rotazione in yaw6.
Figura 8 : Grafico delle varie piattaforme utilizzate, a seconda della complessità dell'ambiente e della missione
Questi sistemi rispetto ad un elicottero hanno minore efficienza aerodinamica
dovuta alla ridotta dimensione dei rotori utilizzati, ma offrono indubbi vantaggi
per le missioni specifiche del progetto in questione.
I vantaggi di un’architettura multirotore rispetto a un elicottero possono essere
elencati così:
Il peso dei multirotore, in considerazione della loro semplicità
costruttiva, è di circa la metà, a parità di payload trasportato, di quello di
un elicottero. Questo fa sì che la loro minore efficienza aerodinamica
venga recuperata completamente nel bilancio energetico totale.
Relativamente alla sicurezza questi sistemi sono intrinsecamente
molto più sicuri di un elicottero, questo perché il singolo rotore di un
multirotore ha energia cinetica molto più bassa e possono essere
6
Yaw, pitch e roll sono anche conosciuti come gli angoli di Tiat-Bryan, sono una terna specifica di angoli
di Eulero molto usati nelle applicazioni aeronautiche per definire l’orientazione relativa di un veicolo
rispetto a un riferimento fisso. I tre angoli sono definiti come angolo di imbardata (yaw), angolo di rollio
(roll) e angolo di beccheggio (pitch).
30
Fabrizio Schiano
facilmente intubati con una protezione avvolgente impedendo il contatto
delle pale con ostacoli o persone. Questa peculiarità e tanto più
importante quanto più dobbiamo impiegare tali mezzi in scenari urbani
come quello considerato.
Figura 9 : Due tipi di piattaforme ad ala rotante: monorotore (a), quadrirotore (b)
Ogni rotore contribuisce al raggiungimento della portanza
richiesta. Differentemente dall’architettura tradizionale di un elicottero,
il multirotore, grazie alla simmetria e alla contro-rotazione dei rotori, non
ha bisogno di un rotore di coda che assorbe potenza ma non da un
contributo per la portanza (serve solo a bilanciare la coppia generata dal
rotore principale). Inoltre, avendo motorizzazioni elettriche brushless,
che non necessitano di riduttori di velocità meccanici, un multirotore ha
livelli di vibrazione molto più bassi di quelli di un elicottero a beneficio
dell’elettronica e dei sistemi di ripresa.
Le architetture multirotore sono più stabili di un elicottero nei
confronti di perturbazioni esterne (raffiche di vento). La centrifugazione
dei motori, rispetto al baricentro e il loro elevato numero (4-12) fa sì che
le forze di reazione utilizzate per il controllo abbiano dei bracci
considerevoli facilitando il mantenimento della stabilità del mezzo anche
con vento sostenuto in presenza di oscillazioni ad alta frequenza.
E’ stata effettuata un’ approfondita ricerca di mercato sui prodotti disponibili in
questa categoria di mezzi. Esistono principalmente quattro aziende che
producono mezzi con caratteristiche vicine alle nostre esigenze di missione:
Draganfly, Microdrone, ASCTEC, Natural Drones.
Le performance delle piattaforme identificate sono più o meno allineate.
31
Fabrizio Schiano
Come performance sicuramente comuni a tutti i prodotti si possono considerare
le seguenti:
Figura 10 : Tabella dati velivolo
Tutti i sistemi multirotore individuati hanno capacità autonome di
stabilizzazione, anche in condizioni di vento sostenuto (10m/s), e possono
navigare per waypoint facendo uso del GPS di bordo. Tutte queste piattaforme,
per compatibilità con le normative vigenti, hanno una interfaccia di tipo Radio
Modellistico che assicura sempre il loro totale e prioritario controllo da parte di
un operatore a terra.
Figura 11 : Alcuni esempi di architetture multirotore: DraganFLY (a), Microdrone (b),
Asctec (c), Natural Drones (d)
32
Fabrizio Schiano
Relativamente alla piattaforma terrestre si potrebbe proporre, nello scenario di
studio, l’uso di una piattaforma mobile con sei gambe di tipo esapodo in grado
di trasportare circa 300gr di payload con un peso totale di 1000gr.
Tale tipo di piattaforma ha la peculiarità di potersi muovere indistintamente
nelle 3 direzioni, contrariamente a rover con ruote o cingoli che devono
manovrare per cambiare direzione, rispetto a queste ultime gli esapodi possono
muoversi su qualsiasi tipo di terreno accidentato. Nella famiglia dei robot a più
gambe sono stati scelti gli esapodi perche dotati di un alto margine di stabilità,
che gli consente di muoversi agevolmente anche superando ostacoli di altezza
ragguardevole rispetto alla lunghezza delle loro gambe.
La grande flessibilità di movimento di questi robot porta come svantaggio una
bassa velocità di spostamento se confrontati a rover con ruote o cingoli, ma la
loro dimensione compatta consente a questi robot di introdursi in spazi angusti
e quindi di esplorare luoghi inaccessibili alle piattaforme aeree.
Figura 12 : Piattaforma terrestre scelta
Inoltre nel paradigma di funzionamento del sistema proposto questo robot
potrebbe essere trasportato sul target da un multirotore, superando cosi anche
l’ intrinseca limitazione dovuta alla bassa velocità di spostamento. Ad oggi i
Sistemi COTS disponibili sono autonomi nella gestione dei gradi di liberta del
sistema (18) e utilizzano specifici microcontrollori per camminare e muoversi. I
comandi di navigazione di alto livello possono essere inviati via connessione
seriale al microcontrollore.
33
Fabrizio Schiano
1.5 Problemi connessi al controllo di flotte di velivoli
In base all’estensione dell’area da monitorare, alle performance delle
piattaforme e al dispendio in termini energetici da parte di sensori e attuatori
che compongono il sistema in questione, si è calcolato come necessario un
sistema costituito da almeno tre piattaforme aeree e una terrestre cooperanti.
Questo dimensionamento permette alla flotta di SUAS così composta di
ottemperare alle quattro fasi di missione precedentemente elencate nei tempi
richiesti e con le risoluzioni assegnate. Ad esempio il sistema consentirebbe di
ottenere una copertura totale dell’area individuata in circa 30 minuti (due
missioni da 15 minuti) con risoluzione del pixel nel visibile di circa 3cm e
nell’infrarosso di 36 cm con quote operative comprese tra 150m e 250m.
Le problematiche connesse al coordinamento di un numero N di piattaforme
richiede lo studio e l’implementazione di algoritmi per il controllo
decentralizzato in grado di rendere questa soluzione scalabile e robusta. È
evidente che tali algoritmi dovranno essere flessibili nel prevedere diverse
tipologie di missione così come diverse tipologie di velivoli.
La ricerca sui sistemi multi-vehicle che eseguono compiti cooperativi risale agli
anni ‘80 del XX secolo, inizialmente relativi al campo dei robot mobili. Aiutata
dallo sviluppo dei sistemi di comunicazione wireless, affidabili e poco costosi, la
ricerca in questi campi è notevolmente cresciuta negli anni ‘90. Alla fine degli
anni ‘90 e all’inizio del XXI secolo il controllo cooperativo di aerei, specialmente
senza pilota (UAVs), diventò un’area di ricerca particolarmente attiva negli Stati
Uniti d’America. In ogni caso il comando e il controllo cooperativo di
piattaforme aeree con piattaforme terrestri, porta con se alcune problematiche
che verranno di seguito analizzate:
1.5.1 Sorveglianza aerea e inseguimento : Le maggiori sfide nella “migrazione”
di UAV sono dovute ai vincoli fisici della piattaforma considerata e ai requisiti di
hard real-time delle applicazioni. Normalmente non è possibile caricare le
piattaforme con grandi quantità di hardware, e allo stesso tempo è di
fondamentale importanza processare l’input dei sensori in real-time.
1.5.2 Elusione degli ostacoli e delle collisioni : Evitare gli ostacoli e le collisioni
rappresenta la base di un volo sicuro di un UAV. Questo si può realizzare
34
Fabrizio Schiano
facendo sì che ogni UAV, o è in grado di rilevare gli altri UAV tramite dei sensori,
o con la conoscenza delle loro posizioni. L’elusione degli ostacoli e delle
collisioni sono solitamente incorporati negli algoritmi di volo cooperativo, infatti
un algoritmo di volo può garantire la sicurezza delle piattaforme o attraverso
specifici requisiti delle posizioni relative, o attraverso regole generali che
governano l’interazione degli UAV.
1.5.3 Riconfigurazione della formazione : Quando gli UAV eseguono un compito
cooperativo come gruppo, si può parlare di volo in formazione. Una formazione
specifica può essere vista come una macchina a stati finiti, dove le transizioni tra
le differenti formazioni possono essere innescate da cambi nella missione o
nell’ambiente. Il processo delle transizioni deve riassegnare gli UAV alle
posizioni della nuova formazione e fornire delle traiettorie che leghino le
posizioni iniziali con le nuove. Queste traiettorie dovrebbero garantire la
sicurezza degli UAV, in accordo con le loro dinamiche. Inoltre tutto il movimento
sarà, per la maggior parte di missioni, soggetto a dei vincoli temporali entro i
quali compiere i compiti assegnati.
1.5.4 Hardware e comunicazione : Gli sforzi tecnologici recenti si stanno
concentrando sul ridurre le dimensioni, i costi e il peso dei veicoli senza pilota;
quindi le scelte dei sensori saranno molto legate a questi vincoli.
Una questione irrisolta per la cooperazione di veicoli senza pilota è la
comunicazione wireless tra veicoli e con le piattaforme a terra. Tra i requisiti più
impegnativi c’è sicuramente lo smistamento real-time di informazioni video a
terra, su grandi distanze, possibilmente includendone (soprattutto in ambito
militare) la crittazione per assicurarne la sicurezza.
I problemi appena esposti rappresentano solo alcuni di quelli che si incontrano
nella messa in pratica di questi sistemi. Altre problematiche saranno gli spunti
che ci faranno preferire un sistema con un’organizzazione decentralizzata
rispetto ad uno centralizzato. Esse saranno analizzate nel prossimo capitolo in
modo da poter rappresentare un punto di partenza per lo studio della
decentralizzazione e quindi per l’esposizione della soluzione proposta relativa al
sistema finora descritto.
35
Fabrizio Schiano
Capitolo 2
Algoritmi di swarm intelligence
2.1 Introduzione
In questo capitolo andremo ad analizzare i vari paradigmi di Swarm Intelligence
proposti in letteratura, che prendono spunto dai cosiddetti ant colony
algorithms. Per l’analisi di questi algoritmi è conveniente analizzare prima i
concetti di stigmergia e decentralizzazione, i quali si possono vedere come delle
possibili soluzioni ai problemi di controllo e comando cooperativo di
piattaforme aeree e terrestri. Inoltre è bene introdurre i sistemi multi-agente e
alcuni suoi paradigmi Swarm come quello dei polyagents sviluppato da Parunak
e l’ant colony optimization (ACO) sviluppato da Marco Dorigo7.
Dopo queste brevi digressioni, si entrerà nel vivo della descrizione dei vari
algoritmi di swarming esaminati.
2.2 Dalla Natura alla Swarm Intelligence
La Natura è senza dubbio la nostra migliore maestra, è da Lei che la Scienza ha
imparato innumerevoli cose, ed è da Lei che tutt’oggi trae spunto per alcuni dei
suoi passi in avanti. Per fare qualche esempio basta citare i super tecnologici
costumi utilizzati dai nuotatori professionisti che si ispirano alla pelle degli
squali, o le ali del mastodontico Airbus A340 (vedi fig.13) e di molti altri velivoli
che assomigliano molto (in scala espansa) a quelle di un’aquila reale, o ancora il
modo di posizionare le turbine imitando il movimento di alcune specie di pesci.
7
Marco Dorigo (nato il 26 Agosto 1961 a Milano) lavora alla Libera Università di Bruxelles, dove guida
un gruppo internazionale di ricercatori sull’intelligenza artificiale
36
Fabrizio Schiano
Figura 13 : Analogia tra l'ala di un'aquila e quella di un Airbus A340
Il paradosso che i comportamenti dei singoli individui potessero generare un
complicato comportamento generale è già conosciuto da secoli. Un antico
osservatore, Re Salomone, venne a conoscenza da suo padre Davide delle
elaborate organizzazioni di corte dei re orientali e delle preparazioni che
servivano per le campagne militari. Egli si meravigliò quando capì che gli insetti
potevano assolvere entrambi questi compiti senza un controllo centrale. In
seguito pensando ai sistemi complessi che servivano per mantenere la sicurezza
nel palazzo reale scrisse (La Bibbia, 1 Cronache 27:25-31), “Go to the Ant…;
consider her ways, and be wise. Having no guide, overseer, or ruler, she
prepares her bread in the summer, and gathers her food at harvest time”,
(“Andate dalla formica, considerate i suoi modi, e siate saggi. Senza avere una
guida, essa prepara il suo sostentamento in estate, e raccoglie il suo cibo nel
tempo del raccolto”).
Quasi tremila anni più tardi, un partecipante nell’NCMS Virtual Enterprise
Workshop nel 1994, disse: “We used to think that bugs were the problem in
manufacturing software. Now we suspect they may be the solution!”,
(Credevamo che gli insetti fossero il problema nel software. Ora noi sospettiamo
che essi potrebbero essere la soluzione).
Anche il concetto di swarm intelligence si ispira alla Natura e più in particolare
alle formiche e a tutti gli animali, insetti, batteri etc. (vedi fig. 14) che sono in
grado di organizzare il loro “lavoro” in modo impeccabile senza disporre di
nessun tipo di tecnologia, ma soltanto di alcune semplici tecniche di cui sono
stati dotati dalla Natura e che hanno affinato nel tempo.
37
Fabrizio Schiano
Figura 14 : Tabella con alcuni esempi di Swarming in Natura
H.Van Dyke Parunak8, tra i ricercatori più autorevoli nel campo della swarm
intelligence, e la persona i cui risultati sono stati fondamentali ai fini di questo
lavoro di tesi, definisce lo swarming come: “useful self-organization of multiple
entities through local interactions”, cioè “l’auto-organizzazione utile di entità
multiple attraverso interazioni locali”. Molte altre definizioni di swarming sono
state date nella letteratura, e recentemente questo termine sta entrando in
voga anche nel gergo militare per indicare delle tecniche di combattimento in
cui tutti gli elementi del sistema sono organizzati in modo decentralizzato.
Un concetto molto importante che “permette” di arrivare a quello di swarm
intelligence, è quello di stigmergia introdotto negli anni ’40 e ’50 del XX secolo
dall’entomologo francese Pierre-Paul Grassè. Egli usò per primo il termine
“stigmergia” per descrivere un tipo particolare di comunicazione, utilizzato nei
sistemi decentralizzati, col quale gli individui del sistema comunicano fra loro
modificando l'ambiente circostante. Egli definì la stigmergia come:
"Stimolazione degli operai mediante il risultato ottenuto." Attualmente è anche
impiegato in alcune ricerche nel campo della robotica, dei sistemi multi-agente
e nelle comunicazioni nelle reti di calcolatori. Le due caratteristiche
8
Parunak è il capo di un gruppo chiamato New Vectors (division of TechTeam Government Solutions,
Inc.) dell’Altarum Institute di Miami. I suoi articoli che sono stati utili a questo lavoro di tesi, sono
riportati nella bibliografia.
38
Fabrizio Schiano
fondamentali che differenziano la stigmergia da altre forme di comunicazione
sono:
La stigmergia è una forma di comunicazione mediata dall’ambiente,
indiretta e non simbolica: gli insetti scambiano info modificando
l’ambiente in cui operano.
L’informazione stigmergica è locale: vi possono accedere solo quegli
insetti che visitano il luogo in cui è rilasciata l’informazione.
Come già accennato in precedenza, esempi di stigmergia sono osservabili anche
in natura nelle colonie di formiche, nelle termiti, etc. La stigmergia è dimostrata
anche su internet dove gli utilizzatori comunicano uno con l'altro lasciando
messaggi in un ambiente condiviso. Wikipedia, ad esempio, è un esempio
lampante di stigmergia: il primo utente lascia l'abbozzo di un'idea, che attrae
altri utenti che modificheranno e amplieranno il concetto iniziale giungendo
infine ad un'elaborata struttura di pensieri connessi. I sistemi stigmergici sono
sistemi che combinano la tecnologia informatica con la stigmergia e altre
ingegnose strutture computazionali trovate in natura per creare Web autoorganizzativi e sistemi low-cost di gestione della conoscenza.
Oltre alla stigmergia, un altro concetto congenito della Swarm intelligence, è
quello di decentralizzazione. Infatti se si decide di approcciare a un sistema con
gli algoritmi di Swarm Intelligence, è automatico studiare il sistema come
decentralizzato. Questo non vuol dire che non sarebbe possibile risolvere il
problema di coordinamento di più piattaforme, aeree e terrestri, con un
metodo centralizzato. Infatti proprio relativamente al sistema in questione un
approccio centralizzato andrebbe probabilmente a buon fine, rendendo però
molto complicata la scalabilità del modello trovato, per situazioni diverse da
quella studiata, e in particolar modo per circostanze in cui il numero di
piattaforme debba aumentare notevolmente.
Un semplice esempio può essere fatto pensando che fino all’avvento dei sistemi
time-sharing9 nella prima metà del 1970, sulla maggior parte dei computer
9
Il time-sharing è un approccio all'uso interattivo del processore. L'esecuzione della CPU viene suddivisa
in quanti temporali. Il time-sharing è l'estensione logica della multiprogrammazione. La CPU del
computer centrale viene utilizzata per rispondere alle richieste dei singoli utenti, passando rapidamente
da uno all'altro (context switch) dando così l'impressione ad ognuno di avere a disposizione il computer
39
Fabrizio Schiano
girava una sola applicazione alla volta, spingendo gli ingegneri del software a
concentrarsi su un approccio centralizzato per l’informatizzazione di un
qualunque sistema
Il concetto di centralizzazione non è presente molto spesso nel mondo naturale,
infatti le formiche non hanno un capo, o quanto meno se c’è un individuo più
importante degli altri (e.g. l’ape regina negli alveari), questo non da ordini ma
funziona più o meno come un bus per lo scambio di informazioni tra tutta la
comunità. Ci sono varie ragioni per non progettare un sistema dotato di un
elemento centrale, grande e complicato abbastanza da controllare l’intero
sistema:
La presenza di un elemento centrale sicuramente va a creare un
punto nevralgico del sistema, e questo rende il sistema molto più
vulnerabile a incidenti, di un sistema decentralizzato.
In condizioni di normale funzionamento l’elemento centrale
potrebbe rappresentare il “collo di bottiglia” del sistema, cioè si potrebbe
avere il suo sovraccarico dovuto al fatto che la totalità delle informazioni,
dei messaggi, delle decisioni etc. passano da quest’ultimo.
Anche se è progettato adeguatamente per l’operazione corrente, il
fatto di avere un elemento centrale potrebbe rappresentare un limite per
l’estendibilità del sistema ad altre applicazioni. Ovvero se il sistema
cresce, dovrà crescere anche l’elemento centrale, invece nei sistemi
decentralizzati per far crescere il sistema basta aggiungere nuovi
elementi senza cambiare, in modo sostanziale, nessuno degli elementi
esistenti.
L’elemento centrale potrebbe essere talmente complicato da far
risultare difficile la comprensione e il mantenimento del software che lo
sorreggono. Nei sistemi decentralizzati tutti gli elementi sono
relativamente semplici.
La centralizzazione comporta un ritardo di tempo nelle decisioni,
in quanto ognuna di queste deve essere analizzata dalla parte centrale
del sistema. Questo è inaccettabile in uno scenario che cambia
rapidamente, come ad esempio un campo di battaglia.
centrale interamente per sé ovvero dando l'impressione di un processamento multiplo in parallelo di più
processi verso più utenti.
40
Fabrizio Schiano
Un sistema di controllo centralizzato di UAV’s richiede una squadra
di due o tre persone per ogni UAV. Al contrario, il controllo di un sistema
decentralizzato avviene grazie a un’OSI (Operator System Interface, vedi
fig. 15???), ovvero un’interfaccia che è stata sviluppata per analizzare le
tecniche per abilitare un singolo operatore a monitorare e organizzare
una flotta di veicoli senza pilota in applicazioni RSTA 10. Un’interfaccia
utente può fondere i dati dei sensori da tutti gli UAV e presentarli in una
forma comprensibile all’utente, come una mappa delle minacce. In ogni
caso la logica complessiva è generalmente modulare per far sì che sia
possibile la decomposizione del problema di controllo generale.
Una delle cose che si intuisce logicamente da quanto sopra elencato, e che
rappresenta uno dei punti di forza dei sistemi decentralizzati rispetto a quelli
centralizzati, è l’abbattimento dei costi di progetto, manutenzione e
funzionamento.
Bisogna precisare che la definizione di swarming, data da Parunak, riportata
precedentemente, è appropriata per problemi con quattro caratteristiche che
Parunak sintetizza mnemonicamente come D4 : Diversi, Distribuiti,
Decentralizzati e Dinamici. Di seguito è riportata una piccola analisi di questi
quattro aggettivi.
Diversi sta a indicare il fatto che lo swarming porta con sé molte forme di
diversità:
Diverse piattaforme presenti nel sistema;
Con lo swarming si possono assolvere diverse funzioni;
Nello swarming ci possono essere informazioni di diverso tipo
Possono essere presenti diverse entità
Il sistema può prendere le informazioni di cui necessità da diverse
risorse (sensori, da altre unità, etc.)
10
Reconnaissance, Surveillance, and Target Acquisition : Ricognizione, sorveglianza e acquisizione di un
obiettivo
41
Fabrizio Schiano
Figura 15 : Un esempio di OSI grafica
L’aggettivo distribuito vuole indicare il fatto che il sistema è suddiviso
equamente su tutta l’area da monitorare.
Il concetto di decentralizzazione è stato esposto in precedenza e verrà
formalizzato, con l’aiuto di alcune definizioni, successivamente.
Infine la caratteristica del sistema di essere dinamico viene dal fatto che
l’ambiente in cui opera il sistema cambia rapidamente, e quindi per riuscire a
monitorarlo in modo accurato c’è bisogno di un sistema che sia in grado di
cambiare rapidamente e adattarsi alle nuove condizioni, imposte istante per
istante dall’ambiente.
2.3 Esempi di Swarm Intelligence in Natura
Prima di andare a formalizzare il concetto di decentralizzazione, si vogliono
analizzare alcuni esempi di Swarm intelligence presenti in natura. Questi esempi
si riferiscono a sistemi in cui un numero di entità semplici (agenti) operano in un
ambiente, dando origine a comportamenti più complessi in quanto collettività;
un comportamento del genere è spesso noto come “comportamento
emergente”.
42
Fabrizio Schiano
I comportamenti complessi non sono proprietà delle singole entità e non
possono essere facilmente riconosciuti o dedotti dal comportamento di entità
del livello più basso. Una delle ragioni per cui si verifica un comportamento
emergente è che il numero di interazioni tra le componenti di un sistema
aumenta combinatoriamente con il numero delle componenti, consentendo il
potenziale emergere di nuovi e più impercettibili tipi di comportamento. D'altro
canto, non è di per sé sufficiente un gran numero di interazioni per determinare
un comportamento emergente, perché molte interazioni potrebbero essere
irrilevanti, oppure annullarsi a vicenda. In alcuni casi, un gran numero di
interazioni può in effetti contrastare l'emergenza di comportamenti
interessanti, creando un forte "rumore di fondo" che può "zittire" ogni segnale
di emergenza; il comportamento emergente potrebbe in questo caso aver
bisogno di essere temporaneamente isolato dalle altre interazioni mentre
raggiunge una massa critica tale da autosostenersi.
Si nota quindi che non è solo il numero di connessioni tra le componenti a
incoraggiare l'emergenza, ma anche l'organizzazione di queste connessioni.
Un'organizzazione gerarchica è un esempio che può generare un
comportamento emergente (una burocrazia può avere un comportamento
diverso da quello degli individui umani al suo interno); ma forse in maniera più
interessante, un comportamento emergente può nascere da strutture
organizzative più decentralizzate, come ad esempio un mercato. In alcuni casi, il
sistema deve raggiungere una certa soglia di combinazione di diversità,
organizzazione e connettività prima che si presenti il comportamento
emergente.
Le strutture emergenti sono schemi non creati da un singolo evento o da una
regola. Non c'è niente che ordini al sistema di formare uno schema, ma le
interazioni di ogni parte con il suo intorno causano un processo complesso che
porta all'ordine. Si potrebbe concludere che le strutture emergenti sono più
della somma delle loro parti, perché l'ordine emergente non si formerà se le
varie parti coesistono solamente: è necessario che interagiscano.
Alcuni esempi biologici di comportamento emergente verranno analizzati nel
seguito:
Pesci e uccelli: Flocking (stormo di uccelli e banco di pesci);
43
Fabrizio Schiano
Lupi: Accerchiamento della preda;
Comportamento di una colonia di formiche.
2.3.1 Flocking (comportamento di uno stormo di uccelli o di un banco di pesci):
Gli stormi di uccelli stanno insieme, si coordinano quando devono cambiare
direzione, e evitano le collisioni con gli ostacoli e tra di loro. I banchi di pesci si
comportano in modo simile. Gli esseri umani hanno problemi simili nel controllo
del traffico aereo, nel controllo di convogli di navi ecc., al contrario degli animali
però questi problemi vengono risolti con l’ausilio della comunicazione e di
strutture di coordinazione centrali, tutte cose che non sono disponibili ai pesci e
agli uccelli.
Ogni uccello o pesce segue tre semplici regole (Reynolds 1987, Heppner 1990):
1. Mantiene una specifica distanza minima dall’oggetto o da altri uccelli più
vicini.
2. Uguaglia la velocità con gli uccelli vicini (in grandezza e direzione).
3. Sta vicino al centro dello stormo (banco).
Lo stormo (o il banco) è una struttura auto-vincolante alla quale tutte le azioni
individuali rispondono simultaneamente e cambiano la struttura generale dello
stormo. Sebbene ogni uccello o pesce sente solo i movimenti dei suoi pari più
vicini, le sue reazioni a questi movimenti si propagano alle altre entità della
struttura, in questo modo il sistema, come insieme, esibisce una coordinazione
globale.
2.3.2 Accerchiamento della preda : Un singolo lupo non può uccidere un alce.
Le corna dell’alce rappresentano molto più che un rischio per un singolo
aggressore. L’insieme di lupi deve prima circondare l’alce, cosicché uno di loro
può saltare sulla sua schiena mentre l’alce è occupato con gli altri. Le squadre
SWAT usano la comunicazione radio per eseguire manovre del genere, al
contrario i lupi non dispongono di walkie-talkie e dispositivi di comunicazione a
lunga distanza.
Questo compito, noto nella letteratura come problema predatore-preda
(predator-prey problem), fu per molti anni uno delle maggiori sfide
dell’intelligenza artificiale distribuita (DAI).
44
Fabrizio Schiano
Una soluzione semplice a questo problema può essere fornita solo con alcune
rudimentali azioni e sensazioni, sia da parte dell’alce che da parte dei lupi.
Quando queste azioni sono simulate su una griglia esagonale, sei lupi
cattureranno sempre un alce, sempre che l’alce non riesca a correre più veloce
dei lupi (Korf 1992).
Il sistema preda-predatore è legato a questi comportamenti:
1. Alce: si muove nella cella vicina che è la più lontana dal lupo più vicino.
Fin quando il suo tasso di movimento è più veloce di quello dei lupi,
questa strategia gli permetterà di scappare.
2. Lupi: si muovono alla cella vicina con il punteggio P più alto:
con d(alce) la distanza dall’alce e d(lupo) la distanza da un altro lupo, e k
una costante di messa a punto, che modella una forza di repulsione tra i
lupi.
Come nell’esempio dei pesci e degli uccelli, ogni individuo nel sistema lupo-alce
influenza ed è influenzato dall’intero sistema. Il comportamento generale del
sistema dipende criticamente dalle velocità relative dei lupi e dell’alce, e dal
valore del parametro k che stabilisce la repulsione tra i lupi. Quando la
repulsione e l’attrazione sono bilanciate in modo adeguato, i lupi
inevitabilmente accerchiano l’alce, senza nessuna esplicita comunicazione o
negoziazione di strategie.
2.3.3 Comportamento delle formiche : Per spiegare questo comportamento
bisogna passare prima per il concetto di moto Browniano (o cammino casuale),
con il quale si intende un concetto fisico molto semplice che ricorre in molti
campi, dalla biologia alla matematica finanziaria. Senza entrare nei dettagli
tecnici possiamo dire che il movimento di una particella atomica immersa in un
fluido segue un moto assolutamente disordinato la cui dinamica appare
indipendente dalla natura della particella stessa. Applicando il concetto di moto
Browniano alle formiche si è capito che questo moto porta la formica
arbitrariamente vicina a ogni punto del piano. Il moto Browniano è tra i più
semplici processi stocastici a tempo continuo.
45
Fabrizio Schiano
Figura 16 : Esempio di Moto Browniano di una particella
Analizzando il comportamento delle formiche, si osserva che esse sono capaci di
trovare il percorso più breve tra il formicaio e un punto del terreno in cui vi sia
del cibo disponibile. L'aspetto interessante e curioso è che sono in grado di farlo
senza informazioni visive (le formiche di molte specie sono infatti cieche), ma
utilizzando segnali "odorosi". Quando una formica ha trovato del cibo, ritorna al
formicaio depositando sul terreno una certa quantità di una sostanza chimica
detta feromone11 (o ferormone). La direzione del cammino di una formica
dipende dalla quantità di feromone che essa percepisce: dove la concentrazione
è più forte, è più probabile che la formica si diriga. Nel tempo le tracce di
feromone sul terreno evaporano ed, eventualmente, sono rinforzate dal
passaggio di altre formiche. Ora entra in gioco un meccanismo molto
importante chiamato retroazione positiva (positive feedback): più formiche
scelgono un percorso, più forte sarà la concentrazione di feromone e quindi
ancora più formiche saranno richiamate sullo stesso percorso. Per questo
motivo, dopo una prima fase transitoria in cui le formiche scelgono direzioni
diverse, si arriva ad una situazione stazionaria in cui la maggior parte delle
11
Feromone: Nome dato a sostanze chimiche, segnali attivi a basse concentrazioni, prodotte ed escrete
in particolar modo da insetti, che sono in grado di suscitare delle reazioni specifiche di tipo fisiologico
e/o comportamentale in altri individui della stessa specie che vengono a contatto con esse.
46
Fabrizio Schiano
formiche segue uno stesso percorso. Siccome il feromone evapora nel tempo, il
percorso più breve sarà quello scelto alla fine dal "sistema formiche".
Osservando la sequenza in fig.17 si può notare che: le formiche sono obbligate a
seguire solo due percorsi alternativi e, dopo un transitorio iniziale, esse
sceglieranno il ramo più corto.
Matematicamente fu osservato dal ricercatore belga S.Goss che le reti costruite
dalle formiche andavano a formare uno spanning tree minimo (MST12), che
minimizza l’energia che le formiche spendono nel portare il cibo al formicaio. La
teoria dei grafi propone vari algoritmi per calcolare gli MST, ma le formiche non
usano gli algoritmi. Al contrario, l’ottima struttura del “sistema formiche” viene
dalle semplici azioni delle singole formiche.
Ogni formica che cerca il cibo segue cinque semplici regole:
1. Evitare ostacoli.
2. Girovagare casualmente, nella direzione di qualche feromone. Se non
percepiscono nessun feromone, le formiche eseguono un moto
Browniano.
3. Se la formica sta trasportando del cibo, essa rilascerà del feromone con
un tasso costante per tutto il cammino.
4. Se la formica si trova vicina al cibo, e non sta trasportando nulla, lo
prende.
5. Se la formica sta trasportando il cibo, e arriva al nido, rilascia il cibo.
Visto che solo le formiche che portano il cibo rilasciano il feromone, e visto che
una formica può prendere il cibo solo da una fonte di cibo, ogni percorso di
feromone porta a una risorsa di cibo. Una volta che una formica che trasporta il
cibo trova la sua “strada di casa”, ci saranno anche dei percorsi di feromone che
portano al formicaio.
12
Nel caso in cui gli archi siano pesati si può definire l' Albero ricoprente minimo, o Minimum spanning
tree (MST). Un MST non e' altro che un albero ricoprente, cioè un albero formato da un sottoinsieme di
archi del grafo originale passanti per tutti i nodi,nel quale sommando i pesi degli archi si ottiene un
valore minimo.
47
Fabrizio Schiano
Figura 17 : Sequenza che rappresenta il comportamento delle formiche in risposta alla formazione di un ostacolo
2.4 Formalizzazione del concetto di decentralizzazione
Gli algoritmi descritti in questa tesi appartengono, come già detto, all’area di
ricerca della swarm intelligence appena esposta, però prima di entrare nello
specifico è bene dare alcune definizioni che saranno utili per il seguito della
trattazione.
Un veicolo è un sistema dinamico la cui posizione è data dalla sua locazione
nello spazio tridimensionale. Verrà considerato un insieme di N veicoli che
eseguono un compito comune. I veicoli possono comunicare tra loro
(direttamente o indirettamente) per soddisfare il compito a loro assegnato,
solitamente ogni veicolo può comunicare solo con un sottoinsieme di veicoli. Si
assume che la dinamica del veicolo i-esimo può essere scritta come:
dove è lo stato del veicolo i-esimo e
è l’input che controlla lo stato del
veicolo, ed
è un campo vettoriale liscio (smooth13) che rappresenta le
dinamiche del veicolo i-esimo. La posizione del veicolo i-esimo
che
è l’insieme di configurazioni del corpo rigido (posizione e orientamento). Si
13
Una funzione smooth o liscia è una funzione che ammette le derivate parziali di qualsiasi ordine.
48
Fabrizio Schiano
assumerà inoltre
veicoli.
lo stato completo per un insieme di N
Oltre alla locazione, ogni veicolo è dotato di uno stato discreto,
, che
definiamo come “ruolo” del veicolo. Il ruolo appartiene a un insieme discreto
che dipende dall’applicazione a cui ci si sta riferendo. Si assumerà che il ruolo di
un veicolo può cambiare in ogni momento e scriveremo un cambio di ruolo
come :
con α’ il nuovo valore di α. Si assumerà
tutti gli N veicoli, e
il ruolo del veicolo i all’istante t.
i ruoli dell’insieme di
Come già detto in precedenza, un veicolo può comunicare solo con un certo
insieme di veicoli, si rappresenterà l’insieme di possibili canali di comunicazione
con un grafo . I nodi del grafo rappresentano i veicoli e gli archi diretti tra due
nodi rappresentano l’abilità di un veicolo di ricevere informazioni da un altro
veicolo. Si scriverà
per rappresentare i vicini di i; generalmente
dipende dalla locazione e dal ruolo dei vari veicoli (il numero di vicini di i è
indicato con
.
Dato un insieme di veicoli con stato x e ruoli α, un compito verrà definito in
relazione a una funzione di performance:
con T il tempo in cui il compito dovrebbe terminare, L rappresenta il costo
incrementale del compito e V rappresenta il costo terminale.
Un’altra definizione importante che deve essere data è quella di “strategia” per
un determinato compito, essa è un’assegnazione degli input ui per ogni veicolo e
una selezione dei ruoli. Si assumerà che gli inputs alle dinamiche del veicolo
sono date da leggi di controllo del tipo:
ui= x,
con una funzione smooth. Per la scelta dei ruoli si farà uso di un Guarded
Command Language (GCL) : un programma è un insieme di comandi nella forma
49
Fabrizio Schiano
Con
è una “guardia” che può essere vero o falso e
una regola che definisce
i
come il ruolo dovrebbe essere aggiornato se la “guardia” assume il valore
vero. Quindi il ruolo evolve in accordo alla legge di aggiornamento seguente:
Si scriverà
i
per rappresentare la strategia totale per il veicolo i-esimo.
rappresenta la strategia completa del sistema.
Usando le definizioni fin qui esposte, Murray cerca di dare una descrizione più
formale del problema di controllo cooperativo. Il ricercatore del CIT afferma che
un compito può essere disaccoppiato se la funzione di costo può essere scritta
come:
Se un compito non è disaccoppiato si dice che è cooperativo, aggettivo con il
quale si intende che le performances dipendono dalle locazioni comuni, ruoli e
inputs dei veicoli.
Si dice che una strategia è centralizzata se i dipende dalla locazione o dal ruolo
di qualche veicolo che non è un vicino di i. Invece una strategia è decentralizzata
se:
=
con
la locazione e il ruolo dei vicini del veicolo i-esimo.
Dall’articolo di Murray emerge che le definizioni esposte non sono le più
generali possibili in quanto si sono ignorate alcune sottigliezze riguardo alla
definizione formale della soluzione di un compito. Si è assunto infatti l’esistenza
e l’unicità di soluzioni per una strategia data, cosa che non è sempre vera per i
sistemi analizzati.
I sistemi reali che possono fare uso del controllo cooperativo di veicoli multipli
sono svariati, di seguito se ne elencano alcuni:
50
Fabrizio Schiano
Sistemi militari (fig.18): volo in formazione, classificazione e sorveglianza
cooperativa, attacco cooperativo e rendezvous, sistemi a iniziativa mista.
Reti di sensori mobili: monitoraggio ambientale, sistemi distribuiti per
l’osservazione.
Sistemi di trasporto: autostrade intelligenti, controllo del traffico aereo.
Figura 18 : Scenario di gestione di un campo di battaglia con un sistema di controllo cooperativo.
Nella letteratura dei sistemi sopraelencati sono presenti varie strategie di
approccio a compiti di controllo cooperativo, che variano a seconda
dell’applicazione a cui si fa riferimento. Per l’applicazione descritta in questa
tesi, sono due le tecniche più importanti a cui si farà riferimento:
Polyagent : tecnica introdotta da H.Van Dyke Parunak.
Ant-Colony-Optimization: tecnica introdotta da Marco Dorigo.
Entrambe le tecniche partono da due concetti fondamentali che verranno
esposti nel seguito della trattazione:
Campo a potenziale
Feromoni digitali
51
Fabrizio Schiano
L’ultimo logicamente prende ispirazione dal comportamento delle formiche
sopra esposto (vedi paragrafo 2.3.3).
2.5 Campo a potenziale e feromoni digitali
I feromoni digitali sono un'estensione dell'uso dei campi a potenziale per
guidare entità robotiche. I sistemi di movimento potential-based sono ispirati
dall'elettrostatica14. Il campo elettrico vettoriale
è definito in un punto
dello spazio come una forza sentita da un'unità di carica in quel punto. Si
definisce un campo a potenziale scalare
integrando questo
campo vettoriale punto per punto nello spazio. Viceversa, il campo può essere
espresso come il gradiente del potenziale
e una particella caricata
con massa trascurabile si muoverà attraverso questo spazio lungo questo
gradiente.
In alcune applicazioni il progettista del campo non è limitato a due componenti
del campo (elettrostatico e gravitazionale), ma può includere diversi campi per
rappresentare diverse classi di obiettivi e ostacoli.
Questa introduzione sui campi a potenziale è stata fatta perché se ne potrebbe
utilizzare uno per guidare degli UAV attraverso un ambiente (vedi fig.19). Prima
di fare ciò bisogna evidenziare come un campo a potenziale non soddisfi tutti i
requisiti
esposti in precedenza nel paragrafo 2.2.
Diverso : Sì. Uno dei punti di forza dei metodi basati sui campi a potenziale
tradizionali è la loro abilità a incorporare tipi diversi di informazioni.
Distribuito: No. I metodi tradizionali basati sui campi a potenziale richiedono
che i dati fondamentali del campo siano raggruppati in un singolo punto per una
computazione centralizzata.
14
In elettrostatica, il campo è generato dalla distribuzione fisica delle cariche in accordo con la forza di
Coulomb. Einstein estese questo formalismo alla gravità, questo portò a un campo gravitazionale
generato dalla distribuzione fisica della massa. Quindi il movimento di una particella enorme caricata
seguirà una composizione di due campi.
52
Fabrizio Schiano
Decentralizzato: Sì. Gli oggetti che si muovono sotto l’influenza di un campo a
potenziale prendono decisioni locali, basate sulla forza del campo nelle loro
immediate vicinanze.
Dinamico: No. I campi a potenziale tradizionali sono calcolati nella loro interezza
prima che il robot cominci a muoversi.
In quest’ottica i campi a feromoni digitali rappresentano un modo per costruire
un campo a potenziale dinamico e distribuito.
Questo campo supporta tre diverse funzioni:
1. Aggregazione: Il campo aggrega i depositi degli agenti individuali,
fondendo informazioni tra diversi agenti e in diversi istanti temporali.
2. Evaporazione: Il campo fa sì che il feromone evapori con il passare del
tempo. Questa dinamica è una vera e propria innovazione alternativa al
tradizionale mantenimento delle informazioni nell’intelligenza artificiale
(AI). Infatti tradizionalmente un agente ricorda tutto quello che gli si è
detto fin quando non c’è un motivo valido affinché esso lo debba
dimenticare. Le formiche cominciano a dimenticare tutto quello che
hanno imparato, a meno che non sia rinforzato.
3. Propagazione: Il campo propaga i feromoni ai posti vicini, disseminando
quindi delle informazioni.
Il campo a feromoni costruito dalle formiche nell’ambiente è infatti un campo a
potenziale che guida i loro movimenti. Come accennato, a differenza di molti
campi a potenziale tradizionali, esso soddisfa tutti i requisiti .
Diverso: Sì. Le formiche possono rispondere a combinazioni di feromoni diversi,
integrando così gli effetti di input multipli.
Distribuito: Sì. Il campo a potenziale è generato dai depositi di feromone che
sono allocati nell’ambiente. Questi depositi fanno il loro lavoro vicino a dove
sono generati e sono usati in primo luogo dalle formiche che gli sono vicine.
Decentralizzato: Sì. Sia il comportamento delle formiche che il mantenimento
del campo a potenziale sono fatti in maniera decentralizzata. Le formiche
interagiscono solo con i feromoni nelle loro immediate vicinanze, facendo
depositi e “leggendo” la forza locale del campo a feromone. Visto che la
53
Fabrizio Schiano
diffusione decresce rapidamente con la distanza, i depositi contribuiscono alla
forza del campo solo nelle immediate vicinanze in cui vengono fatti.
Figura 19 : Campo potenziale corrispondente agli assetti fisici
Dinamico: Sì. Sotto un rinforzamento continuo, la forza del campo a feromoni si
stabilizza rapidamente. In questo modo le nuove informazioni sono subito
integrate nel campo, mentre quelle vecchie sono automaticamente dimenticate,
attraverso l’evaporazione del feromone.
L’interazione basata sul feromone non solo aumenta il numero di interazioni
che possiamo analizzare, ma consente anche un’esecuzione estremamente
efficiente15.
Al momento l’applicazione pratica più matura che fa uso delle tecniche basate
sul feromone è quella dell’instradamento dei pacchetti nelle telecomunicazioni.
2.6 Il paradigma Polyagent
L’entità fondamentale di un modello agent-based (ABM) è l’agente, che
corrisponde a un’entità discreta nel dominio; l’operatore fondamentale in un
ABM è l’interazione tra gli agenti.
15
In una applicazione fatta da Parunak e il suo gruppo di ricerca, venivano supportati 24000 ghosts
(vedi paragrafo 2.4) concorrentemente, più velocemente del real-time, su un Wintel Laptop a 1GHz.
54
Fabrizio Schiano
L’entità fondamentale in un modello equation-based (EBM) è un sistema
osservabile, l’operatore fondamentale è la sua evoluzione (descritta ad esempio
da una equazione differenziale).
In tutti e due i casi un agente di un’entità può eseguire solo una traiettoria per
iterazione, questo motivo ci fa capire che questo approccio non è adatto al
nostro sistema, per questo motivo si prova a risolvere il problema con una
nuova entità di modellazione detta polyagent.
Il modello polyagent-based (PBM), Introdotto da H. Van Dyke Parunak,
rappresenta ogni entità con un singolo e persistente avatar, e diversi e “nonpersistenti” ghosts. Ogni ghost interagisce con i ghosts degli altri avatars
attraverso i feromoni digitali (tecnica esaminata nel paragrafo 2.3), esplorando
più traiettorie alternative in una singola iterazione, la quale può essere più
veloce del real-time per diversi domini considerabili.
I poliagenti sono una soluzione al bisogno di catturare il risultato delle possibili
interazioni multiple tra gli agenti, in poche iterazioni del sistema.
L’avatar corrisponde all’agente che rappresenta un’entità in un modello
convenzionale multi-agente del dominio. Esso persiste fin quando l’entità a cui
si riferisce è attiva e mantiene il proprio stato che riflette lo stato della sua
entità. Ogni avatar genera un flusso di ghosts, che hanno una vita limitata. I
ghosts “muoiono” o dopo un certo periodo di tempo fissato, o in seguito al
verificarsi di un evento, o per fare spazio a un nuovo flusso di ghosts. L’avatar
controlla il tasso di generazione dei suoi ghosts e solitamente ne ha molti attivi.
I ghosts, come già detto, esplorano diversi comportamenti possibili per il loro
avatar, essi interagiscono tra loro stigmergicamente attraverso i campi a
feromoni digitali. Ogni ghost sceglie le proprie azioni stocasticamente
basandosi su una funzione pesata in base alla forza delle varie “fragranze” di
feromone nelle sue immediate vicinanze. Inoltre ogni ghost deposita il proprio
feromone per registrare la sua presenza in quel determinato posto.
Avere tanti ghosts fa aumentare il numero di interazioni che una singola
iterazione del sistema può esplorare. Invece di una sola traiettoria per ogni
avatar, in questo caso si hanno tante traiettorie quanti sono i ghosts.
55
Fabrizio Schiano
Figura 20 : Il paradigma Polyagent
Dati avatars e ghosts, se avatars depositano il feromone, tutte le azioni
del ghost sono influenzate da un massimo di altri agenti, cosicché si stanno
analizzando in effetti
interazioni per ogni entità, o
interazioni in
tutto. Se invece sono i ghosts a depositare il feromone, il numero di interazioni
che si possono analizzare è più grande, dell’ordine di .
L’avatar può fare diverse cose con i suoi ghosts, a seconda dell’applicazione:
Può attivare i suoi ghosts quando vuole analizzare altre possibili
soluzioni alternative, cambiando la quantità prodotta di ghosts a
seconda di quante alternative vuole analizzare.
Può fare evolvere i suoi ghosts per capire quali sono i migliori parametri
per una specifica situazione. Inoltre monitora le performance dei ghosts
passati, seleziona quello che ha più “successo” per determinare i
parametri della generazione successiva di ghosts.
Può esaminare il comportamento del suo insieme di ghosts per
produrre una stima unificata di quale sarà la sua evoluzione e il suo
range di variabilità.
La trattazione dei poliagenti fin qui esposta, fa riferimento ad agenti
appartenenti allo “stesso mondo”. Un problema ancora non risolto
completamente resta quello di fondere tra loro feromoni di diversi ghosts di un
agente A di un determinato tipo, in un singolo campo che poi guiderà il
comportamento di un agente B di un tipo differente.
56
Fabrizio Schiano
Nel progetto ADAPTIV16, Parunak formalizza i suoi ragionamenti sulla tecnica
polyagent. I feromoni digitali del progetto ADAPTIV sono strutture dati digitali,
non chimiche. Queste strutture dati sono presenti in una rete di place agents,
che rappresentano regioni del campo di battaglia. Per scopi simulativi, tutti i
place agents risiedono su un unico computer, invece nelle applicazioni reali ogni
place agent risiede su un sensore incustodito a terra (UGS:Unattended Ground
Sensor) e deve essere posto sul campo di battaglia tramite calo aereo o
dall’artiglieria. Il sistema software di ADAPTIV si riferisce sia agli UGS che a un
terminale di osservazione (HOST: Hostility Observation and Sensing Terminal).
Ogni place agent è vicino a un insieme limitato di altri place agents. Oltre ai
place agents, il sistema ADAPTIV prevede anche i cosiddetti walker agents, che
interagiscono con il place agent associato ad ogni zona che visitano.
Logicamente i place agents e i walker agents sono entità software, mentre gli
HOST’s e gli UAV’s rappresentano l’hardware su cui essi risiedono.
Ogni place agent mantiene una variabile scalare corrispondente a ogni fragranza
di feromone, che aumenta quando riceve altro feromone della stessa fragranza.
Come già detto, questo feromone evapora con il passare del tempo e si propaga
ai place agents vicini.
Un walker agent abita un place agent a ogni istante di tempo, può leggere la
forza attuale del feromone per quel place agent come una funzione delle sue
fragranze e può anche depositare feromoni in quel place agent. Ogni walker
agent combina le forze provenienti da feromoni differenti che percepisce,
usando una equazione di controllo, poi si muove verso un nuovo place agent,
tramite una decisione presa stocasticamente, pesando le varie opzioni (vari
place agents verso cui potrebbe muoversi) in base alla suddetta equazione di
controllo.
La piattaforma del sistema ADAPTIV è progettata in modo da poter supportare:
Agenti di swarming, includendo l’abilità di definire sottopopolazioni di
agenti
Meccanismi di interazione flessibili
16
ADAPTIV (Adaptive Control of Distributed Agents Through Pheromones Techniques and Interactive
Visualization) è un progetto al quale ha partecipato Parunak con il suo gruppo di ricerca New Vectors. E’
un progetto promosso dalla DARPA per analizzare i metodi basati sul feromone al fine di controllare le
operazioni militari aeree.
57
Fabrizio Schiano
Data logging e interfacce per le query real-time
Esecuzione efficiente per grandi numeri di agenti concorrenti
Una notevole varietà di meccanismi di scheduling
Un grande insieme di meccanismi “pheromone-based”, includendo
l’aggregazione, evaporazione e propagazione
Diverse entità software come i ghost agents
Visualizzazione del comportamento degli agenti
Visualizzazione dell’evoluzione del comportamento degli agenti
Nel seguito andremo a considerare lo spazio fisico come diviso i tanti quadrati,
in modo che ogni place agent sia dotato di 8 vicini.
Gli agenti software vagano nella cosiddetta pheromone map, si useranno due
classi di agenti: walkers e avatars. Come già accennato precedentemente un
agente walker controlla una singola piattaforma dello swarm, invece gli avatars
sono usati per rappresentare le altre entità nell’ambiente. Queste ultime
possono includere le entità amiche (blu), nemiche (rossi) e neutrali (verdi).
Un agente usa una equazione di interpretazione per pesare i feromoni che
percepisce e decidere verso quale place agent muoversi. Alcuni feromoni
possono attrarre l’agente, altri lo repellono. L’equazione di interpretazione
assegna un valore scalare V(p) al place agent corrente e a ognuno dei suoi place
agents vicini. L’agente poi o fa una scelta deterministica (muoversi verso il place
agent con il maggiore V(p) ) , o probabilistica (usare la cosiddetta “ruota di una
roulette” i cui segmenti sono pesati da ogni V(p) ).
La matematica che descrive il campo potenziale a feromoni digitali include
alcuni teoremi sulla stabilità critica che si basano su due equazioni
fondamentali. I parametri, per entrambe le equazioni, sono:
P=[pi]= insieme di place agents
N:P→P = relazione con il vicino tra place agents
f,p,t)= forza della fragranza di feromone f all’istante t e per il place
agent p
d( f,p,t) = input esterno di feromone di fragranza f, all’istante t e per il
place agent p
g( f,p,t) = input propagato di feromone di fragranza f, all’istante t e per
il place agent p
= parametro di evaporazione per la fragranza f
f
58
Fabrizio Schiano
= parametro di propagazione per la fragranza f
f = soglia inferiore: se il valore di
f,p,t) scende al di sotto di T f verrà
posto a 0, e il software non terra più in considerazione quel feromone
che scomparirà dal sistema.
f
La prima equazione descrive l’evoluzione della forza di una singola fragranza di
feromone per un place agent fissato:
Ef riflette l’evaporazione del feromone, il fattore
calcola il feromone
rimanente dopo la propagazione ai suoi vicini,
f,p,t) rappresenta la quantità
di feromone del ciclo precedente,
f,p,t) esprime i depositi totali fatti
dall’ultimo ciclo di aggiornamento e
f,p,t) rappresenta il feromone totale
propagato a p da tutti i suoi vicini. Ogni place agent applica questa equazione a
ogni fragranza di feromone una volta durante ogni ciclo di aggiornamento.
La seconda equazione fondamentale descrive proprio la propagazione di
feromone ricevuta dai place agents vicini:
Questa equazione ci dice che ogni place agent p’ che ha p come vicino, propaga
una porzione del suo feromone all’agente p in ogni ciclo di aggiornamento. La
propagazione dipende dal parametro e dal numero totale di vicini .
Usando queste equazioni si possono dimostrare diversi teoremi di stabilità
critica e di convergenza, come ad esempio:
Stabilità locale: la forza dell’output propagato da ogni insieme di place
agents ai loro vicini all’istante t+1 è strettamente minore della forza
dell’input totale (esterno + propagato) allo stesso insieme di agenti,
all’istante t.
Stabilità propagata: esiste un limite superiore fissato per la somma di
tutti gli input per un arbitrario place agent se si assume un input esterno
di un istante preciso e per un posto preciso.
59
Fabrizio Schiano
Stabilità globale: la forza del feromone per qualunque place agent è
limitata.
2.6.1 Descrizioni degli algoritmi: In questo paragrafo si andranno ad esaminare
gli algoritmi che utilizzano le funzioni identificate precedentemente. Ogni
fragranza di feromone ha un numero di parametri (settings) che mettono a
punto i feromoni per il compito specifico. Quattro parametri differenti sono
disponibili per ogni fragranza di feromone:
1. Grandezza temporale del ciclo di aggiornamento della fragranza
2. Fattore di propagazione: la frazione del feromone di un place agent che
viene distribuita equamente ai suoi vicini.
3. Fattore di evaporazione: la frazione di feromone che rimane dopo il
ciclo di evaporazione.
4. Soglia minima: sotto la quale, come già detto, la forza del feromone
viene assunta pari a 0 e il software non terra più in considerazione quel
feromone.
2.6.1.1 Algoritmo di sorveglianza e pattugliamento : Questo algoritmo deve
essere in grado di controllare veicoli di sorveglianza autonomi (ASV’s:
Autonomos Surveillance Vehicles), che esaminano una o più aree di interesse
(AOI: Area Of Interest) con una certa frequenza di rivisitazione. L’algoritmo è
anche conosciuto con il nome di “lawn cutting” (taglio del prato).
In questo algoritmo i place agents nell’AOI emettono continuamente un
feromone attrattivo (il prato) che si propaga agli altri place agents formando un
campo a potenziale che avrà un certo gradiente che porta alle AOIs. I walker
agents blu che controllano gli ASV sono attratti da questo feromone. La loro
equazione di interpretazione li porterà probabilisticamente a scalare il gradiente
del campo formato dal feromone verso l’AOI contenente la concentrazione più
alta di feromone attrattivo (l’erba più lunga). Una volta che l’ASV ha visitato il
place agent nell’AOI, tutto il feromone attrattivo viene eliminato (taglio
dell’erba) e i place agents smettono di emettere altro feromone attrattivo per
un tempo inversamente proporzionale alla frequenza di sorveglianza desiderata
per quella particolare AOI. Passato questo tempo, il “pompaggio” di feromone
ricomincia e il feromone attrattivo ricomincia ad accumularsi nel relativo place
agent (ricrescita dell’erba).
60
Fabrizio Schiano
Figura 21 : Algoritmo di sorveglianza e pattugliamento. 1: Area di sorveglianza deposita feromone attrattivo. 2
L'ASV deposita feromone repulsivo. 3 L'infrastruttura propaga sia feromone attrattivo che repulsivo il cui campo
avrà un certo gradiente. 4 L'ASV scala la rete del gradiente, prelevando feromone attrattivo
In questo algoritmo i place agents nell’AOI emettono continuamente un
feromone attrattivo (il prato) che si propaga agli altri place agents formando un
campo a potenziale che avrà un certo gradiente che porta alle AOIs. I walker
agents blu che controllano gli ASV sono attratti da questo feromone. La loro
equazione di interpretazione li porterà probabilisticamente a scalare il gradiente
del campo formato dal feromone verso l’AOI contenente la concentrazione più
alta di feromone attrattivo (l’erba più lunga). Una volta che l’ASV ha visitato il
place agent nell’AOI, tutto il feromone attrattivo viene eliminato (taglio
dell’erba) e i place agents smettono di emettere altro feromone attrattivo per
un tempo inversamente proporzionale alla frequenza di sorveglianza desiderata
per quella particolare AOI. Passato questo tempo, il “pompaggio” di feromone
ricomincia e il feromone attrattivo ricomincia ad accumularsi nel relativo place
agent (ricrescita dell’erba).
È importante sottolineare che ogni ASV deposita un feromone repulsivo nel
prossimo place agent che si appresta a visitare, in questo modo tiene lontani gli
altri ASV dallo stesso place agent, per evitare la duplicazione dello sforzo.
L’equazione di interpretazione è :
)
dove:
61
Fabrizio Schiano
Figura 22 : Settings dei feromoni per l'algoritmo di sorveglianza e pattugliamento
2.6.1.2 Algoritmo di acquisizione dell’obiettivo : Gli algoritmi di Swarm
Intelligence per posizionare i sensori per l’acquisizione dati non sono considerati
in questa tesi, per il loro studio si rimanda alla bibliografia. Qui si assumerà che
fin quando l’entità di Swarm Intelligence è nel range del sensore in questione,
l’obiettivo è acquisito con una probabilità definita da un parametro
sperimentale Pd. Un altro parametro sperimentale è usato per definire per
quanto tempo il sensore deve rimanere sull’obiettivo per confermarne
l’acquisizione.
L’algoritmo esaminato è descritto nella figura 23 , ci sono due tipi di ASV in
questo scenario. L’ASVdet che ha un sensore che può rilevare la presenza di un
obiettivo, ma non può identificarlo; l’ASVid ha un sensore che può sia rilevare
che identificare l’obiettivo. Se l’ASVdet rileva un obiettivo, crea un avatar rosso
per rappresentarlo; quest’ultimo incomincia a rilasciare un feromone chiamato
NeedsID.
Figura 23 : Algoritmo di acquisizione dell'obiettivo. 1: L’ASVdet rileva l’obiettivo e l’avatar rosso è creato. 2:
L’avatar rosso deposita il feromone NeedsID. 3: L’ASVid scala il gradiente del campo formato dal feromone
NeedsID per identificare l’obiettivo
Un ASVid è più attratto dal feromone NeedsID che da quelli che rappresentano il
“prato” (lawn), quindi in presenza di feromone NeedsID egli scalerà il gradiente
del campo formato da questo feromone e identificherà l’obiettivo. Una volta
identificato, l’avatar rosso smetterà di rilasciare feromone NeedsID. L’ASVid
62
Fabrizio Schiano
deposita una gran quantità di Visited feromone, per far sì che gli altri ASV non
vengano attratti dalla restante quantità di feromone NeedsID che nel tempo si
estinguerà. Una volta identificato, il target può essere seguito o lasciato libero
se è stato giudicato innocuo.
L’ASVid e l’ASVdet usano due equazioni di interpretazione diverse:
ASVid
→
ASVdet →
Con:
la forza del feromone “lawn” (prato) per il place agent p;
la forza del feromone “visited” (visitato) per il place agent p;
la forza del feromone “tracking” (inseguimento) per il place
agent p.
Figura 24 : Settings dei feromoni per l'algoritmo di acquisizione dell’obiettivo
2.6.1.3 Algoritmo di inseguimento dell’obiettivo : Questo algoritmo viene
utilizzato per permettere agli ASV di inseguire gli obiettivi in modo continuo o
intermittente. Un avatar rosso stima il comportamento dell’obiettivo rosso, e
deposita continuamente un feromone Tracking. In ogni caso l’ASV deposita una
grossa quantità di feromone Visited quando l’obiettivo rosso è rilevato, affinché
gli altri ASV ne stiano alla larga.
Quando questo feromone evapora o l’avatar rosso si muove fuori dal range
dell’ASV che lo sta inseguendo, il suo feromone Tracking attrarrà di nuovo gli
ASV verso di lui per stabilire un nuovo contatto e per aggiornare il suo percorso.
Variando la quantità di feromone Visited si può variare la frequenza di
rivisitazione per l’inseguimento.
63
Fabrizio Schiano
Figura 25 : Algoritmo di inseguimento dell'obiettivo. 1: L’ASV acquisisce l’obiettivo e una gran quantità di
feromone Visited è depositato per repellere gli altri ASV. 2: L’avatar rosso stima il movimento, deposita il
feromone Tracking che potrebbe vincere la forza del feromone Visited. 3: Gli ASV vicini sono più attratti dal
feromone Tracking che repulsi dal feromone Visited, quindi scalano il gradiente per riacquisire l’obiettivo.
L’equazione di interpretazione è :
Figura 26 : Settings dei feromoni per l'algoritmo di inseguimento dell’obiettivo
I settings esposti nella tabella precedente sono relativi a un periodo di
rivisitazione di 200 secondi per un obiettivo rosso che si muove a 3Km/h e 20
unità blu che si muovono a 90 Km/h su una griglia 200x200.
2.7 Il paradigma Ant-Colony-Optimization (ACO)
Negli ultimi anni si è diffuso un innovativo modo di sviluppare tecniche per
risolvere problemi di progettazione e ottimizzazione: lo studio dell’ingegneria
della natura, cioè lo studio di come dati certi vincoli ambientali, l’evoluzione
abbia creato la forma di vita ottima per quei vincoli. La comprensione di questi
meccanismi ha permesso, per analogia, lo sviluppo di nuovi algoritmi e il loro
adattamento a problemi completamente diversi da quelli in cui sono
originariamente stati osservati. Gli algoritmi naturali hanno un fascino notevole
per l’ingegnere, perché mentre la natura ci mette milioni di anni per fare
evolvere una forma di vita ottima, un buon calcolatore multi-processore può far
64
Fabrizio Schiano
durare questa evoluzione pochi giorni. Uno dei più affascinanti fenomeni di
organizzazione osservabili in natura è il comportamento delle formiche già
esposto in precedenza (vedi paragrafo 2.3.3). L’algoritmo che formalizza questo
comportamento è l’Ant Colony Optimization (ACO: Ottimizzazione del
comportamento delle colonie di formiche) introdotto nel 1991 da Marco Dorigo
del Politecnico di Milano. Questo algoritmo fu introdotto usando come esempio
di applicazione il problema del commesso viaggiatore (TSP: Traveling Salesman
Problem) che intuitivamente è il problema di un commesso che, partendo dalla
sua città, vuole trovare il percorso più breve che lo porti in un insieme fissato di
città (clienti) e poi a casa, passando per ogni cliente una e una sola volta. Più
formalmente, il TSP può essere rappresentato da un grafo completo pesato
G=(N,A) con N l’insieme di nodi rappresentanti le città e A l’insieme di archi. A
ogni arco (i,j) A è assegnato un valore (lunghezza) dij , che è la distanza tra la
città i e la città j, con i,j
N. L’obiettivo nel TSP è trovare un circuito
17
Hamiltoniano di minima lunghezza del grafico G.
Il TSP è un problema molto studiato nella letteratura, e gioca un ruolo
importante, come accennato, nella ricerca sugli algoritmi di ACO. La scelta del
TSP come problema per la descrizione degli algoritmi di Ant Colony Optimization
ha diverse ragioni:
Il TSP è un importante problema di ottimizzazione
-completo18 che si
presenta in molte applicazioni.
Il TSP è un problema al quale gli algoritmi ACO sono facilmente
applicabili.
Il TSP è facilmente comprensibile, ed è un buon banco di prova per nuovi
sviluppi algoritmici.
Inoltre la letteratura dell’Ant Colony Optimization dimostra che molto spesso gli
algoritmi più efficienti per il TSP lo sono anche per una gran varietà di altri
problemi.
17
Nel campo matematico della teoria dei grafi, un cammino in un grafo (orientato o non orientato) è
detto hamiltoniano se esso tocca tutti i vertici del grafo una e una sola volta.
18
Nella Teoria della Complessità i problemi NP-completi sono i più difficili problemi nella classe NP
("problemi non deterministici a tempo polinomiale") nel senso che, se si trovasse un algoritmo in grado
di risolvere "velocemente" (nel senso di utilizzare tempo polinomiale) un qualsiasi problema NPcompleto, allora si potrebbe usarlo per risolvere "velocemente" ogni problema in NP.
65
Fabrizio Schiano
Figura 27 : Lista (non completa) di alcuni algoritmi di Ant Colony Optimization di successo (in ordine cronologico)
Il primo algoritmo di ACO introdotto da Marco Dorigo nel 1991 si chiama Ant
System (AS) e raggiunse alcuni risultati iniziali molto interessanti, ma si capì che
era inferiore allo stato dell’arte degli algoritmi per il TSP. L’importanza dell’AS
sta comunque nel fatto di essere stato la maggiore fonte di ispirazione per gli
algoritmi di ACO seguenti. Esso infatti ha fornito un gran numero di estensioni
che ne hanno significativamente migliorato le prestazioni e sono ancora tra gli
algoritmi di ACO di maggiore successo. Molte di queste estensioni provengono
direttamente dall’AS nel senso che mantengono la stessa procedura di
costruzione della soluzione e la stessa procedura di evaporazione del feromone.
Tra queste estensioni vi sono:
Elitist AS
Rank-based AS
AS
Ant-Colony-System
Le maggiori differenze tra l’AS e queste estensioni sono le modalità in cui il
feromone viene aggiornato oltre ad alcuni dettagli sull’organizzazione delle
tracce di feromone.
Nell’ACO, il TSP è affrontato simulando un numero di formiche artificiali che si
muovono su un grafico che rappresenta il problema: ogni vertice rappresenta
una città e ogni arco rappresenta una connessione tra due città. Una variabile
chiamata feromone è associata a ogni arco e può essere letta e modificata dalle
formiche.
In generale gli algoritmi di ACO sono algoritmi iterativi. A ogni iterazione è
considerato un numero di formiche artificiali, ognuna di loro costruisce una
66
Fabrizio Schiano
soluzione camminando da vertice a vertice sul grafico con il vincolo di non
visitare nessun vertice che ha già visitato nel suo cammino. A ogni step di
costruzione della soluzione, una formica seleziona il vertice seguente che deve
visitare secondo un meccanismo stocastico che è influenzato dal feromone.
Quando una formica si trova nel vertice i (fig. 28), il vertice seguente si sceglie
tra tutti quelli che non sono stati ancora visitati, in particolare se la città j non è
stata visitata, essa sarà scelta con una probabilità che è proporzionale al
feromone associato con l’arco (i,j). Alla fine dell’iterazione, in base alla qualità
della soluzione, i valori del feromone vengono modificati per potere influenzare
le formiche, nelle iterazioni future, a costruire soluzioni simili alle migliori
precedentemente costruite.
Figura 28 : Una formica nella città i sceglie la prossima città da visitare in base a un meccanismo stocastico: se j
non è stata precedentemente visitata, può essere selezionata con una probabilità proporzionale al feromone
associato all'arco (i,j).
Come accennato, l’ACO è stato formalizzato in una metaeuristica 19 per problemi
di ottimizzazione combinatoriale da Marco Dorigo e dei suoi collaboratori. Per
potere applicare l’ACO a un problema di ottimizzazione Dorigo in un suo libro
19
Metaeuristica: Si definisce, procedimento euristico, un metodo di approccio alla soluzione dei
problemi che non segue un chiaro percorso, ma che si affida all'intuito e allo stato temporaneo delle
circostanze, al fine di generare nuova conoscenza. È opposto al procedimento algoritmico. La
metaeuristica è un metodo euristico per la soluzione di una classe molto ampia di problemi
computazionali che combina diverse procedure a loro volta euristiche, con l'obiettivo di ottenere una
procedura più robusta ed efficiente.
67
Fabrizio Schiano
(intitolato appunto “Ant Colony Optimization”) ne fornisce un apposito modello
che consiste in:
Uno spazio di ricerca S definito su un insieme finito di variabili discrete di
decisione
Un insieme di vincoli tra le variabili.
Una funzione oggettiva
da minimizzare20.
La variabile generica
ha valori in
Una probabile
soluzione
è una completa assegnazione di valori alle variabili che
soddisfino tutti i vincoli . Una soluzione
è globalmente ottima se e solo
se:
.
Il modello di un problema di ottimizzazione combinatoriale è usato per definire
il modello di feromone dell’ACO. Un valore di feromone è associato a ogni
componente di una possibile soluzione. Formalmente il valore di feromone
è
associato a un componente della soluzione
che consiste nell’assegnazione
L’insieme di tutti i componenti della possibile soluzione è indicato con
C.
Come esposto in precedenza, le formiche artificiali si muovono sul grafico da
vertice a vertice costruendo una soluzione parziale. Inoltre le formiche
depositano una certa quantità di feromone sui componenti che possono essere
associati o ai vertici o agli archi (fig. 29). La quantità di feromone depositata
può dipendere dalla qualità della soluzione trovata.
La metaeuristica ACO si può sintetizzare con il seguente pseudo-codice C-like:
Settaggio dei parametri, inizializzazione delle tracce di feromone
while non incontro la condizione di terminazione do
Le formiche costruiscono le soluzioni
Applica la ricerca locale (opzionale)
Aggiornamento feromoni
endwhile
20
Ogni problema di massimizzazione può essere facilmente ridotto a un problema di minimizzazione:
massimizzare una funzione è chiaramente equivalente a minimizzare la funzione
68
Fabrizio Schiano
Figura 29 : Esempio di possibili grafici di costruzione per un TSP a 4 città (a) e 6 città (b), dove i componenti sono
associati agli archi (a) o ai vertici (b) del grafico.
A ogni iterazione sono costruite un numero di soluzioni dalle formiche, queste
soluzioni sono poi migliorate attraverso una ricerca locale (step opzionale) e
infine il feromone è aggiornato. In particolare l’applicazione della ricerca locale
serve a migliorare le soluzioni ottenute dalle formiche, è una fase opzionale
anche se spesso è inclusa nello stato dell’arte degli algoritmi ACO.
2.7.1 Gli algoritmi di Ant Colony Optimization più importanti: In questo
paragrafo verranno presentati gli algoritmi non in ordine cronologico, ma bensì
in ordine di complessità crescente nei confronti delle modifiche che essi
introducono nei confronti del primo algoritmo Ant System. Per semplicità di
esposizione non si considererà la fase opzionale della ricerca locale.
2.7.1.1 Ant system(AS): Inizialmente furono proposte tre versioni dell’AS
chiamate rispettivamente ant-density, ant-quantity e ant-cycle. Nei primi due
l’aggiornamento del feromone avveniva alla fine di ogni spostamento delle
formiche da una città all’altra, nell’ant-cycle invece avveniva dopo che tutte le
formiche avevano costruito i percorsi e la quantità di feromone depositata era
una funzione della qualità del percorso. Al giorno d’oggi la tecnica usata nei
primi due algoritmi è stata abbandonata in quanto si è visto che quella dell’antcycle è nettamente superiore a livello prestazionale.
69
Fabrizio Schiano
Le fasi principali dell’algoritmo AS sono la costruzione della soluzione da parte
delle formiche e l’aggiornamento del feromone. In questo algoritmo un buon
metodo euristico per definire il valore iniziale delle tracce di feromone è quello
di impostarle a un valore leggermente superiore a quello che ci si aspetta che
sia depositato dalle formiche in una iterazione; una stima approssimata può
essere raggiunta definendo
, con
il numero di
formiche, e
è la lunghezza del percorso generato dall’euristico “vicino più
vicino”. La ragione di questa scelta è che se il valore di
è troppo basso la
ricerca potrebbe essere influenzata dal primo percorso generato dalle formiche.
Al contrario se è troppo grande le prime iterazioni potrebbero essere perse in
quanto esse non vengono considerate fin quando l’evaporazione del feromone
riduce abbastanza i valori dei feromoni, cosicché il feromone aggiunto dalle
formiche può incominciare a influenzare la ricerca.
Costruzione della soluzione
Nell’AS le formiche costruiscono un percorso per il TSP, in particolare se una
formica sta nella città la probabilità che vada nella città è espressa così:
con
un valore euristico che è disponibile a priori,
sono
parametri che determinano l’influenza relativa della traccia di feromone e
l’informazione euristica, infine
è il probabile vicinato della formica quando
sta nella città , cioè l’insieme di città che non ha ancora visitato.
Il ruolo concreto dei parametri
è il seguente: se
è più probabile che
siano scelte, come città successive, le città più vicine; se
solo il feromone
è usato nella scelta senza nessuna influenza euristica, questo generalmente
porta a risultati scadenti, specialmente nel caso di
si ha il rapido
emergere di una situazione di stagnazione, cioè una situazione in cui le formiche
seguono lo stesso sentiero e costruiscono lo stesso percorso, cosa che è
fortemente non ottimale.
Ogni formica mantiene una memoria
che contiene le città già visitate,
nell’ordine in cui sono state visitate. Questa memoria è usata per definire il
70
Fabrizio Schiano
probabile vicinato
nella regola di costruzione data dall’equazione
precedente di
. Inoltre la memoria
permette alla formica
sia di
calcolare la lunghezza del percorso
per depositare il feromone.
generato che di ripercorrere il sentiero
Per quanto riguarda la costruzione della soluzione, ci sono due modi di
implementazione: in serie o in parallelo. Nella costruzione in parallelo a ogni
passo tutte le formiche si muovono dalla città corrente alla successiva, mentre
in quella sequenziale una formica costruisce un percorso completo prima che
quella successiva cominci a costruirne un altro. Nel caso dell’algoritmo AS
queste due tecniche sono equivalenti in termini di comportamento
dell’algoritmo, ciò invece non è vero in altri algoritmi ACO come l’Ant-ColonySystem.
Aggiornamento delle tracce di feromone
Dopo che tutte le formiche hanno costruito i loro percorsi, le tracce di feromone
sono aggiornate. Questo è fatto prima di tutto abbassando il valore del
feromone su tutti gli archi di un valore costante e poi aggiungendo il feromone
agli archi che le formiche hanno attraversato nei loro percorsi. L’evaporazione
del feromone è espressa dalla seguente espressione:
dove
è il tasso di evaporazione del feromone, che permette
all’algoritmo di “dimenticare” le decisioni sbagliate prese precedentemente.
Infatti se un arco non è scelto dalle formiche, la quantità di feromone a esso
associata decresce esponenzialmente con il numero di iterazioni.
Dopo l’evaporazione, tutte le formiche depositano il feromone sugli archi che
hanno attraversato nel loro percorso, in accordo con la formula seguente:
con
la quantità di feromone che la formica
visitato, che a sua volta è definita così:
71
deposita nell’arco che ha
Fabrizio Schiano
con
la lunghezza del percorso
costruito dalla formica k, calcolata come la
somma delle lunghezze di tutti gli archi appartenenti a
. Più un arco
appartiene a un percorso migliore, più feromone verrà depositato su quell’arco.
Generalmente gli archi che sono usati da molte formiche e che sono parte di
percorsi brevi, sono quelli che ricevono la maggior quantità di feromone.
2.7.1.2 Elitist Ant System(EAS): Un primo miglioramento dell’AS è rappresentato
dal cosiddetto Elitist21 Ant System introdotto da Dorigo et al.. L’idea era quella
di fornire un forte rinforzamento addizionale agli archi appartenenti al miglior
percorso trovato dall’inizio dell’algoritmo; questo percorso è indicato con
(best-so-far tour = percorso migliore fino ad ora). Questo feedback addizionale
al
è un esempio di daemon action22 della metaeuristica ACO e può essere
visto come attuato da una formica addizionale chiamata formica best-so-far.
Il rinforzamento aggiuntivo del percorso
è raggiunto aggiungendo una
quantità /
ai suoi archi, dove è il parametro che definisce il peso dato al
percorso best-so-far
, e
è la sua lunghezza. Così l’equazione per il
deposito di feromone diventa:
con
definito già in precedenza e
definito così:
21
L’elitismo è una tecnica di ricerca della soluzione in un algoritmo che si basa sulla selezione dell’elite,
cioè si selezionano i percorsi migliori; in questo modo l’elitismo fa crescere rapidamente le performance
di un algoritmo in quanto, evita la perdita della soluzione migliore.
22
Le daemon actions sono delle procedure che servono per implementare azioni centralizzate che non
possono essere demandate alle singole formiche. Esempio di daemon actions sono l’attivazione di
procedure di ottimizzazione locale, la collezione di informazioni locali che possono essere usate per
decidere se è utile o meno depositare altro feromone per influenzare il processo di ricerca da una
prospettiva non locale.
72
Fabrizio Schiano
Da notare è che nell’EAS, come negli altri algoritmi che saranno presentati nel
seguito, l’evaporazione del feromone è implementata come nell’AS. I risultati
raggiunti da Dorigo nel 1992 fanno capire che l’uso della strategia elitista con un
valore appropriato per il parametro
permette all’EAS di trovare migliori
percorsi e soprattutto trovarli in un minor numero di iterazioni.
2.7.1.3 Rank-Based Ant System (ASrank): Un altro miglioramento dell’AS è la
versione rank-based (basata sul grado) proposta da Bullnheimer et al. (1999). In
questo algoritmo ogni formica deposita una quantità di feromone che decresce
con il suo grado. Inoltre, come nell’EAS, la formica best-so-far deposita sempre
la quantità più grande di feromone in ogni iterazione.
Prima di aggiornare le tracce di feromone, le formiche sono ordinate in base alla
lunghezza dei percorsi trovati e la quantità di feromone che una formica
deposita è pesata in base al grado della formica. In ogni iterazione solo a
formiche con il grado più alto e alla formica best-so-far è permesso di
depositare il feromone. Il percorso best-so-far da il contributo più forte insieme
al peso . La migliore formica -esima dell’iterazione corrente contribuisce
all’aggiornamento del feromone con il valore 1/
moltiplicato con un peso
dato dal massimo
. Quindi l’aggiornamento del feromone dell’ASrank è
espresso dalla regola seguente:
con
=1/
e
già definito nella discussione dell’EAS.
I risultati sperimentali di Bullnheimer et al. (1999) suggeriscono che l’ASrank ha
prestazioni leggermente migliori di quelle dell’EAS e significativamente migliori
dell’AS.
2.7.1.4
AS (
modifiche principali all’AS:
AS): Questo algoritmo introduce quattro
73
Fabrizio Schiano
1. Sfrutta fortemente il miglior percorso trovato: solo la migliore formica
dell’iterazione (best-iteration ant), o la formica migliore fino ad ora (bestso-far ant) possono depositare il feromone. Purtroppo questa strategia
potrebbe portare a una situazione di stagnazione, nella quale tutte le
formiche seguono lo stesso percorso, a causa dell’eccessiva crescita delle
tracce di feromone sugli archi di un buon, ma non ottimo, percorso.
2. Per ovviare al problema sopra esposto, c’è una seconda modifica: questo
algoritmo limita il range possibile del valore delle tracce di feromone
all’intervallo
3. Le tracce di feromone sono inizializzate al valore più alto
, che
insieme con un piccolo tasso di evaporazione, accresce l’esplorazione di
percorsi all’inizio della ricerca.
4. Le tracce di feromone sono re-inizializzate ogni volta che il sistema
raggiunge una situazione di stagnazione o quando un percorso migliore
non è generato per un certo numero di iterazioni consecutive.
Dopo che tutte le formiche hanno costruito un percorso, i feromoni sono
aggiornati applicando l’evaporazione come nell’AS, seguita dal deposito di
nuovo feromone espresso così:
con
= 1/
. La formica che aggiunge il feromone può essere sia la
migliore finora, e in questo caso si ha
dell’iterazione, e in questo caso si ha
= 1/
= 1/
, o la formica migliore
con
la lunghezza del
percorso migliore dell’iterazione. Nel
AS i due modi di aggiungere il
feromone sono usati in modo alternato, naturalmente la frequenza con cui le
due regole di aggiornamento del feromone sono applicate ha un influenza sulla
bontà della ricerca: quando gli aggiornamenti del feromone sono fatti sempre
dalla formica best-so-far la ricerca si focalizza velocemente attorno a
; invece
quando è la formica iteration-best ad aggiornare il feromone, il numero di archi
che ricevono il feromone è più grande e la ricerca è meno diretta.
74
Fabrizio Schiano
Risultati sperimentali suggeriscono di usare la formica iteration-best quando si
hanno piccole istanze di un TSP, mentre si suggerisce l’uso della formica best-sofar quando si ha a che fare con TSP con diverse centinaia di città.
Limiti ai valori delle tracce di feromone
I limiti ai valori delle tracce di feromone servono, come già detto, a evitare
situazioni di stagnazione. Questi limiti hanno l’effetto di limitare la probabilità
di selezionare una città quando una formica è nella città all’intervallo
, con
. Solo quando la formica k ha una
sola scelta per la prossima città, cosa che corrisponde a
, si avrà
I risultati sperimentali di Stützle del 1999 suggeriscono che per evitare la
stagnazione, il limite inferiore
gioca un ruolo più importante del limite
superiore
, che d’altro canto rimane utile per il settaggio dei valori del
feromone durante le re-inizializzazioni occasionali delle tracce di feromone.
Inizializzazione e re-inizializzazione delle tracce di feromone
All’inizio dell’algoritmo, le tracce iniziali di feromone sono settate a una stima
del limite superiore. Questo modo di inizializzare le tracce di feromone insieme
con un piccolo parametro di evaporazione, causa una crescita lenta nella
differenza relativa nei livelli delle tracce di feromone, cosicché la fase iniziale di
ricerca dell’
AS è molto esplorativa.
Per aumentare l’esplorazione di percorsi che hanno poche probabilità di essere
scelti, in questo algoritmo le tracce di feromone sono occasionalmente reinizializzate. La re-inizializzazione è programmata per avvenire, tipicamente,
quando l’algoritmo raggiunge la stagnazione o se per un numero di iterazioni
consecutive non viene trovato un percorso migliore.
L’algoritmo appena discusso è un degli algoritmi ACO più studiati ed ha un
numero notevole di estensioni.
2.7.1.5 Ant Colony System (ACS): Questo algoritmo rispetto a quelli finora
esaminati, sebbene prenda una forte ispirazione dall’AS, raggiunge il
miglioramento delle prestazioni con l’introduzione di nuovi meccanismi basati
su idee non incluse nell’AS originale.
75
Fabrizio Schiano
L’ACS fu proposto da Dorigo & Gambardella nel 1997 e differisce dall’AS in tre
punti fondamentali:
1. Accumula l’esperienza di ricerca accumulata dalle formiche in misura
maggiore rispetto all’AS, attraverso l’uso di una regola di azione più
aggressiva.
2. L’evaporazione e il deposito del feromone avviene solo sugli archi che
appartengono al percorso best-so-far ( ).
3. Ogni volta che una formica usa un arco ( ), per muoversi da una città a
una città , essa rimuove una certa quantità di feromone dall’arco per
incrementare l’esplorazione di percorsi alternativi.
Aggiornamento globale della traccia del feromone
Nell’ACS solo una formica può aggiungere il feromone dopo ogni iterazione.
Quindi l’aggiornamento del feromone in questo algoritmo è implementato così:
con
=1/
. E’ importante sottolineare che nell’ACS l’aggiornamento della
traccia di feromone si applica solo agli archi di
, e non a tutti gli archi come
nell’AS. Ciò è importante perché in questo modo la complessità computazionale
dell’aggiornamento del feromone a ogni iterazione è ridotta da
con n la grandezza dell’istanza da risolvere. è il parametro che rappresenta
l’evaporazione del feromone. Negli esperimenti iniziali si notò che il percorso
trovato per piccole istanze di un TSP usando il metodo iteration-best era poco
differente da quello trovato usando il metodo best-so-far , al contrario per
istanze con più di 100 città l’uso del percorso best-so-far dava risultati
nettamente migliori.
Aggiornamento locale della traccia del feromone
Il contributo più interessante dell’ACS rispetto agli algoritmi precedentemente
analizzati è l’introduzione di un aggiornamento locale del feromone, che si
affianca all’aggiornamento globale precedentemente esposto. Questo tipo di
aggiornamento del feromone è attuato da tutte le formiche dopo ogni step di
costruzione della soluzione, ovvero dopo che hanno attraversato un arco ( ), e
si può esprimere in questo modo:
76
Fabrizio Schiano
con ,
,e
che sono due parametri. Il valore di
è settato per
essere lo stesso valore iniziale delle tracce di feromone. Sperimentalmente, è
stato trovato che un buon valore per è 0.1, mentre un buon valore per
è
1/
, con il numero di città nell’istanza del TSP in questione e
la
lunghezza del percorso del “vicino più vicino”.
L’effetto di questo aggiornamento locale del feromone è che ogni volta che una
formica usa un arco, la quantità di feromone dell’arco attraversato diminuisce.
In questo modo l’arco in questione diventa meno desiderabile per le formiche
seguenti e quindi, come già detto, si aumenta l’esplorazione degli archi che non
sono stati ancora visitati e quindi l’algoritmo va più difficilmente in una
situazione di stagnazione. Se per gli algoritmi precedenti non c’era differenza se
le formiche agivano in parallelo o sequenzialmente, nell’ACS c’è differenza e
questo è dovuto alla regola di aggiornamento locale del feromone. Nella
maggior parte delle implementazioni dell’ACS la scelta è fatta per far sì che le
formiche si muovessero in parallelo, sebbene al momento non c’è un’evidenza
sperimentale in favore dell’una o dell’altra scelta.
In conclusione si può affermare che l’Ant colony optimization è un’euristica il cui
punto di forza consiste nell’essere un sistema intelligente distribuito. Ciò
significa che le scelte adottate non sono prese da un’unica intelligenza che
lavora al problema, ma da una colonia, che pensa autonomamente e grazie ai
feromoni riesce a condividere le soluzioni appena vengono trovate, adottando
dinamicamente il processo di ottimizzazione.
2.8 Differenze tra Polyagent e Ant Colony Optimization
La tecnica polyagent sostiene il confronto con diversi paradigmi precedenti dei
sistemi multi-agente. Nel polyagent, ogni ghost ha la stessa funzione: esplorare
un possibile comportamento di un’entità del dominio analizzato. La pluralità dei
ghosts fornisce, non una decomposizione funzionale, ma un insieme di stime di
comportamenti alternativi.
77
Fabrizio Schiano
In molti costrutti multi-agente ogni agente verifica solo una serie possibile di
interazioni con le altre entità; al contrario, nel costrutto polyagent la
coordinazione pheromone-based permette a ogni ghost di regolare il suo
comportamento in base a molti altri comportamenti alternativi di altre entità
nel dominio.
Figura 30 : Confronto tra Polyagent e altri paradigmi
Come il polyagent, l’Ant Colony Optimization usa i feromoni per integrare le
esperienze degli agenti che operano in parallelo. Il vantaggio del polyagent è la
nozione di avatar come punto centrale di contatto per gli agenti di una singola
entità.
Il termine “polyagent” è un neologismo per diversi agenti software che
congiuntamente rappresentano l’entità di un dominio e i suoi comportamenti
alternativi. Il termine è usato in altri due contesti che non devono creare
confusione.
In medicina, la cosiddetta “polyagent therapy” usa agenti di trattamento
multipli (in particolare, diversi farmaci combinati nella chemioterapia).
Vicino al dominio di interesse di questa tesi di laurea, ma comunque diverso, è
l’uso del termine fatto da K. Kijima per descrivere un approccio fondato sulla
teoria dei giochi per analizzare le interazioni sociali e organizzative di diverse
persone che prendono decisioni. Per Kijima il termine “poly-agent” ha senso
solo come una descrizione di un sistema, e non descrive un agente singolo.
78
Fabrizio Schiano
Nell’approccio introdotto da Parunak ha senso parlare di un singolo costrutto di
modellazione chiamato “polyagent”.
Infine, per la comprensione di altre differenze tra i due paradigmi di
modellazione Swarm, si rimanda al Capitolo 4 di conclusioni.
79
Fabrizio Schiano
Capitolo 3
Piattaforme per lo sviluppo di
applicazioni multi-agente
3.1 Introduzione
La modellazione software di algoritmi Swarm attinge proficuamente alle
tecniche proprie dei sistemi multi-agente. In tali sistemi infatti gli “agenti”
mappano direttamente i componenti della swarm intelligence (es. insetti) e
consentono di modellare agevolmente le loro relazioni.
Prima di entrare nel vivo della descrizione delle piattaforme di simulazione e
sviluppo di sistemi multi-agente è utile fare un passo indietro per analizzare il
tipo di sistema di fronte al quale ci si trova. Non è stato specificato
esplicitamente in precedenza, ma è facilmente intuibile che il sistema preso in
considerazione in questa tesi sarà composto da vari “agenti” (i.e. diversi
esarotori, una piattaforma terrestre, etc.), quindi si può approcciare ad esso con
le tecniche software multi-agente. H.Van Dyke Parunak nei suoi technical papers
descrive i MAS (Multi-Agent-System) come una tripla organizzata così:
A sua volta un agente è visto come una quadrupla:
è un set di valori che definiscono completamente l’
e
sono dei sottoinsiemi dello
accoppiate all’ambiente.
80
.
le cui variabili sono
Fabrizio Schiano
è una sorta di applicazione che però ha un’esecuzione autonoma, nel
senso che non viene invocata da un’entità esterna all’agente stesso. Il
va a cambiare lo
dell’
. In termini computazionali ogni
agente ha la sua CPU virtuale.
Per quanto riguarda l’ambiente in cui opera l’Agente, esso può essere visto
sintatticamente come un sottoinsieme di un Agente:
La cosa importante da capire riguardo all’ambiente è che esso stesso è un
elemento attivo del sistema, ha il suo processo che cambia il suo stato,
indipendentemente dalle azioni dei suoi agenti. L’ambiente, a differenza degli
agenti, è concettualmente illimitato.
Tutto quello che verrà esaminato in questo capitolo, parte quindi dal concetto di
agente del quale si è appena riportata una definizione in termini abbastanza
matematici.
A questo punto se ne vuole dare una definizione più debole che risulterà
probabilmente più intuitiva della precedente. Un agente è visto come un
sistema computerizzato che oltre ad avere abilità come l’autonomia, la
reattività ecc, è anche concettualizzato o implementato usando concetti che
solitamente sono applicati agli esseri umani. Quindi, un agente può essere visto
come un componente software e/o hardware di un sistema capace di agire
esattamente per assolvere dei compiti per conto del suo utente.
È in questo punto che entrano in gioco le piattaforme software che devono
fornire un supporto concreto allo sviluppo di questi concetti e far sì che
diventino sempre più diffusi.
L’obiettivo di questo capitolo è recensire e confrontare alcuni tra i software
multi-agente più usati, mettendo in luce vantaggi e svantaggi di ognuno di essi.
81
Fabrizio Schiano
3.2 Dalla tecnologia agent-based ai MAS (Multi-AgentSystem)
È convinzione diffusa in ambito scientifico che la tecnologia agent-based sia un
risultato di convergenza tra tante tecnologie all’interno della scienza informatica
così come la programmazione object-oriented, la vita artificiale e l’informatica
distribuita. Un altro aspetto importante degli agenti è la loro capacità di offrire
l’intelligenza con l’interazione, cosa che suggerisce la fusione di due differenti
flussi di ricerca quali l’intelligenza artificiale (AI) e l’interazione Uomo-Computer
(HCI: Human-Computer-Interaction). In maniera più filosofica gli agenti si
possono vedere come un mezzo per riempire il gap che c’è tra gli esseri umani e
le macchine, tramite l’intelligenza e l’interazione.
Ogni agente percepisce (lo stato dell’ambiente in cui opera), deduce (aggiorna il
suo stato interno, in accordo con le proprie percezioni), decide (su un azione),
agisce (per cambiare lo stato dell’ambiente in cui opera).
Figura 31 : Accoppiamento “human-agent”
La tecnologia degli agenti intelligenti è a un punto interessante di sviluppo, essa
si sta sviluppando in campi di applicazione molto diversi, come già esposto nel
capitolo precedente, come la meteorologia, i videogiochi di guerra, la gestione
82
Fabrizio Schiano
delle missioni di UAV, ecc.. In ogni caso, ci sono tutti indicatori che evidenziano
come questa sia una tecnologia in via di maturazione.
Dal concetto di agente, come si nota anche dalla figura 31, si passa, tramite il
concetto di raggruppamento di agenti, a quello di MAS (Multi-Agent-System) già
citato nei precedenti capitoli. Un ruolo molto fondamentale nei MAS lo
ricoprono i concetti di:
Coordinazione-Comunicazione
Cooperazione
Omicini e Ossowoski (rispettivamente dell’Università di Bologna (Italia) e di
Treviri (Germania)), definiscono la coordinazione come la gestione delle
dipendenze tra le attività. Infatti senza coordinazione gli agenti potrebbero
entrare i conflitto, vanificare i loro sforzi e sprecare risorse, fallendo nel
raggiungimento degli obiettivi richiesti. Quindi una condizione necessaria per la
sopravvivenza dell’agente e dei sistemi multi-agente è il saper coordinare i
propri sforzi.
Un altro ingrediente base di un sistema multi-agente, strettamente legato a
quello della coordinazione, è l’abilità degli agenti di comunicare tra di loro. La
comunicazione è essenziale per la coordinazione in quanto essa permette agli
agenti non solo di raggiungere i loro obiettivi individuali o per l’insieme di
agenti, ma anche di coordinare le azioni e i comportamenti degli agenti. La
comunicazione è come se servisse a vincolare le decisioni dei singoli agenti, man
mano che la “missione” evolve, cioè dato un obiettivo non è detto che all’utente
del sistema interessi solo il suo raggiungimento, ma molto probabilmente sarà
importante anche il modo in cui l’obiettivo sarà raggiunto, e per gestire ciò
serve proprio la comunicazione tra gli agenti. Da un punto di vista più
ingegneristico, quando gli agenti comunicano è come se semplificassero agli altri
agenti il proprio modello matematico, cosa che ridurrà sicuramente l’incertezza
su ogni agente e aumenterà la precisione di raggiungimento dell’obiettivo.
In un sistema multi-agente, gli agenti possono comunicare tra loro usando dei
linguaggi di comunicazione specifici (ACLs: Agent Communication Languages).
Questa capacità permette agli agenti di estrarre una conoscenza utile da un
insieme molto voluminoso di informazioni eterogenee. Inoltre questo tipo di
83
Fabrizio Schiano
sistemi, sempre basandosi sulla interazione tra gli agenti, offrono anche un
approccio potente di decomposizione strutturale dell’obiettivo da raggiungere.
I sistemi multi-agente sono molto bene esposti nel libro di Yoav Shoham e Kevin
Leyton-Brown, intitolato proprio “Multiagent Systems”.
Gli autori aprono il loro libro in questo modo: “Immaginiamo di avere un agente
software personale che è attratto per conto nostro dall’e-commerce. Diciamo
che gli obiettivi di questo agente sono quelli di seguire prodotti disponibili
online in diversi posti per un determinato arco temporale, e acquistare alcuni di
essi, per nostro conto, a prezzi allettanti. Per avere successo, il vostro agente
dovrà contenere le vostre preferenze per i prodotti, il vostro budget, e in
generale la vostra conoscenza dell’ambiente in cui egli andrà ad operare.
Inoltre, l’agente dovrà contenere la vostra conoscenza di altri agenti simili con i
quali egli si troverà ad interagire (i.e. agenti che competono in un’asta, o agenti
che rappresentano i titolari dei negozi) e dei quali bisogna avere le preferenze e
le conoscenze. Un insieme così strutturato di agenti forma un multiagent
system”
Può sembrare strano, ma in questo libro non c’è una vera e propria definizione
di multiagent system, in quanto ci sono molte definizioni che competono. Viene
data una definizione vaga che è questa: i multiagent systems sono quei sistemi
che includono diverse entità autonome, o con informazioni divergenti, o con
interessi divergenti, o con entrambi.
Già dal precedente capitolo si è capito che i sistemi multi-agente possono essere
visti come un nuovo paradigma per la comprensione e la costruzione di sistemi
distribuiti, nei quali si assume che i componenti computazionali sono autonomi,
cioè hanno la capacità di controllare i loro comportamenti nell’ottica di
raggiungere i propri obiettivi. Nel tempo i sistemi multi-agente hanno provato di
essere un paradigma valido in un numero consistente di applicazioni collegate in
rete, che richiedono l’integrazione dell’informazione proveniente da diverse
entità eterogenee e autonome.
Si può quindi definire un sistema multi-agente come un sistema composto da
diversi agenti che possono trarre vantaggio da risorse computazionali e capacità
che sono distribuite su una rete di entità interconnesse. Un approccio agent-
84
Fabrizio Schiano
based permette la creazione di sistemi flessibili, robusti, e che si possono
adattare all’ambiente, questo è d’aiuto specialmente in quelle situazioni in cui i
componenti del sistema non sono noti a priori, ma cambiano nel tempo, e sono
altamente eterogenei. L’informatica agent-based offre la possibilità di soluzioni
decentralizzate incorporando autonomia e intelligenza in applicazioni
cooperative e distribuite.
Infatti un altro beneficio offerto dai sistemi multi-agente è sicuramente la
distribuzione di tutti gli agenti su una rete. Gli agenti software possono avere
diversi livelli di intelligenza, questo permette di ridurre la quantità di
informazioni scambiate tra gli agenti con un conseguente minore tempo di
risposta, rispetto al caso dei tradizionali sistemi centralizzati.
Andando più nello specifico si può parlare di programmazione agent-oriented
(AOP: Agent Oriented Programming) che è il paradigma software usato per
facilitare l’informatica agent-based ed è un’estensione della programmazione
object-oriented (OOP), nel senso che sostituisce le nozioni di classe e
ereditarietà rispettivamente con le nozioni di ruoli e messaggi.
In questi ultimi anni, la comunità di modellazione agent-based ha sviluppato
diversi pratici toolkit di modellazione multi-agente che permettono a tutti di
sviluppare applicazioni agent-based. Molti altri toolkit stanno nascendo in
questi ultimi anni e ogni toolkit ha una varietà diversa di caratteristiche.
In ogni caso le tecnologie agent-based sono ancora immature, esse infatti non
potranno mantenere le loro promesse e non diventeranno molto diffuse fin
quando gli standard che supportano l’interoperabilità tra gli agenti non saranno
pronti e gli ambienti per lo sviluppo di sistemi multi-agente non saranno
disponibili. Comunque, molte persone stanno lavorando sulla standardizzazione
delle tecnologie multi-agente (come ad esempio Knowledge Sharing Effort,
OMG, e FIPA), e anche sullo sviluppo di ambienti di sviluppo (come ad esempio
DMARS, RETSINA, e MOLE).
Alcuni ambienti di sviluppo forniscono modelli di agente predefiniti e strumenti
per semplificare lo sviluppo dei sistemi. Inoltre, alcuni di essi provano a
interagire con altri sistemi attraverso un linguaggio di comunicazione tra agenti
85
Fabrizio Schiano
noto come KQML23. Comunque, un linguaggio di comunicazione condiviso non è
abbastanza per supportare l’interoperabilità tra diversi sistemi agent-based, in
quanto servono anche i servizi comuni relativi agli agenti.
Il lavoro di standardizzazione della FIPA riconosce questa questione e, oltre a un
linguaggio di comunicazione, specifica gli agenti chiave necessari per la gestione
di un sistema agent-based e l’ontologia condivisa che deve essere usata per
l’interazione tra due sistemi multi-agente.
Quindi prima di entrare nel vivo della descrizione di alcune piattaforme per la
modellazione multi-agente e anche se nessuno dei software di seguito analizzati
è conforme completamente alle specifiche FIPA, si è deciso lo stesso di fare una
breve digressione per parlare del lavoro di standardizzazione, molto importante,
svolto da questa organizzazione della Computer Society IEEE.
3.3 Specifiche FIPA
La Foundation for Intelligent Physical Agents (FIPA) è una associazione
internazionale no-profit di compagnie e organizzazioni che condividono gli sforzi
per la produzione di standard per tecnologie agent-based generiche. FIPA non
promuove una sola tecnologia per un unico dominio, ma un insieme di
tecnologie generali per differenti aree di applicazione che gli sviluppatori
possono integrare per creare sistemi complessi con un alto grado di
interoperabilità.
Il primo documento della FIPA, chiamato “specifiche FIPA97”, stabilisce le regole
normative che permettono a una società di agenti di esistere, operare ed essere
gestita. Loro identificano i ruoli di alcuni agenti chiave necessari per la gestione
23
Knowledge Query and Manipulation Language o anche (KQML) è un linguaggio e protocollo di
comunicazione, proposto nel 1993, che ha le proprie basi sullo SGML (Standard Generalized Markup
Language); è usato per scambiare informazioni e conoscenza.
Tim Finin ha svolto il lavoro relativo a KQML presso la University of Maryland Baltimore County, Lab for
Advanced Information Technology; il quale è parte dell' ARPA Knowledge Sharing Effort.
Il formato di messaggi e protocollo KQML può essere usato per interazioni tra sistemi intelligenti,
oppure da un programma applicativo, o da altri sistemi intelligenti. KQML è stato usato
prevalentemente per gestire la comunicazione tra sistemi multi-agente.
86
Fabrizio Schiano
della piattaforma e per descrivere il linguaggio di gestione degli agenti. Tre ruoli
obbligatori furono identificati in una piattaforma multi-agente:
L’Agent Managment System (AMS) è l’agente che esercita il controllo
supervisore sull’accesso e sull’uso della piattaforma.
L’Agent Comunication Channel (ACC) fornisce un percorso di contatto tra
gli agenti dentro e quelli fuori dalla piattaforma.
Il Directory Facilitator (DF) è quello che fornisce i servizi di “pagine gialle”
alla piattaforma.
Le specifiche FIPA definiscono anche l’Agent Communication Language (ACL),
usato dagli agenti per scambiare messaggi. La sintassi di questo linguaggio,
vicina al KQML, comunque presenta con esso alcune differenze; la più evidente
è l’esistenza di semantiche formali che dovrebbe eliminare ogni ambiguità e
confusione di uso del linguaggio.
Le parti rimanenti delle specifiche FIPA riguardano altri aspetti, dall’integrazione
agente-software alla sicurezza degli agenti, cose che esulano dallo scopo di
questo capitolo e per le quali si può consultare il sito web FIPA : www.fipa.org.
3.4 Le piattaforme software per modelli Agent-Based
Nel seguito si andranno ad analizzare e confrontare le seguenti piattaforme
software per la modellazione multi-agente:
NetLogo
MASON
Repast
3.4.1 NetLogo: Il software NetLogo, sviluppato originariamente da Uri
Wilensky nel 1999 presso il Center for Connected Learning and ComputerBased
Modeling
della
Northwestern
University
(http://ccl.northwestern.edu/NetLogo/), nasce come tool didattico ed offre un
ambiente di sviluppo programmabile di modellazione per la simulazione di
fenomeni naturali, sociali ecc. NetLogo ben si presta a sistemi che evolvono nel
87
Fabrizio Schiano
tempo, inoltre supporta centinaia o migliaia di agenti indipendenti che operano
concorrentemente. Dalle varie simulazioni è possibile esplorare le connessioni
tra i comportamenti dei singoli agenti, di basso livello, e quelle che emergono a
un livello più alto e che sono il risultato dei comportamenti di basso livello (vedi
comportamento emergente al paragrafo 2.3).
Figura 32 : Il logo di NetLogo
NetLogo è una piattaforma abbastanza semplice da usare, infatti si possono far
partire simulazioni e “giocare” con esse, e si possono creare modelli
personalizzati; inoltre dispone di una interfaccia grafica user-friendly che
semplifica molto la comprensione del software e del modello implementato, agli
utenti alle prime armi; il linguaggio utilizzato è abbastanza semplice. La sua
facilità di utilizzo è sicuramente una conseguenza anche della buona
documentazione di cui è corredato, che include anche una libreria abbastanza
fornita, all’interno della quale si possono trovare oltre 150 modelli di esempio,
che sono anch’essi molto utili per la comprensione del funzionamento della
piattaforma; oltre alla documentazione ci sono migliaia di persone che utilizzano
NetLogo nel mondo e che spesso possono rappresentare un punto di
riferimento per gli utenti inesperti, nei forum e nelle community, ormai molto
diffusi su internet.
NetLogo é scritto in JAVA ma é completamente programmabile per mezzo di
un meta-linguaggio ad oggetti semplificato basato sulla sintassi del Logo
(S.Papert, anni ‘60) ed introdotto originariamente nell’ambiente Starlogo, il
progenitore di NetLogo creato all’MIT nel 1990 (M.Resnick). Il linguaggio
utilizzato in NetLogo è sicuramente molto più semplice da usare di Java o
Objective-C, proprio perchè contiene molte strutture e primitive di alto livello
che riducono gli sforzi di programmazione. Il linguaggio inoltre contiene molte,
ma non tutte, le capacità di controllo e strutturazione di un linguaggio di
programmazione standard.
Quello adottato da NetLogo è un linguaggio di programmazione funzionale, ed è
anche questo che rende il software relativamente semplice da usare. Viceversa
88
Fabrizio Schiano
la mancanza di vere caratteristiche object-oriented a volte costituisce una
limitazione. Ad esempio potrebbe essere poco chiaro quali metodi sono
associati a quali agenti, infatti a volte le azioni di una classe di un agente
posssono essere scritte come parte di una lista di azioni eseguite da un’altra
classe di agenti. Inoltre, sebbene non ci sia un supporto esplicito per la
formazione delle strutture, le proprietà del linguaggio permettono un vero e
proprio feedback tra gli agenti, i gruppi di agenti e l’ambiente.
Con NetLogo risulta molto difficoltoso implementare comunicazioni collegate in
rete tra gli agenti, specialmente con variabili multiple, anche se NetLogo
supporta i collegamenti tra gli agenti. Molto spesso non è per niente semplice
estendere e modificare alcuni semplici modelli in NetLogo, ad esempio,
l’aggiunta di dati GIS richiede specifiche conoscenze di programmazione e l’uso
creativo delle caratteristiche di NetLogo.
All’interno di NetLogo é possibile riprodurre molte delle caratteristiche di un
sistema complesso, studiare la sua evoluzione nel tempo e visualizzarla in
tempo reale all’ interno di un laboratorio virtuale 2D o 3D.
L’ambiente di sviluppo di NetLogo interpreta direttamente il codice senza
bisogno di compilarlo, quindi al suo interno é possibile, in tempo reale:
interagire con il sistema attraverso pulsanti e sliders per modificare i
parametri di controllo;
visualizzare variabili, grafici e istogrammi relativi alla simulazione;
importare/salvare immagini e dati da/su files esterni;
E’possibile inoltre:
effettuare set di esperimenti al variare delle condizioni iniziali o dei
parametri di controllo;
lanciare le simulazioni più pesanti in modalitá off-line su computer
remoti;
usufruire di una ricca libreria di modelli di esempio da cui prendere
spunto e di un help pratico ed ipertestuale;
salvare le proprie simulazioni come applet JAVA e visualizzarle
immediatamente dentro un web browser.
89
Fabrizio Schiano
Figura 33 : Interfaccia utente di NetLogo con il modello di diffusione ad aggregazione limitata.
NetLogo è un mondo con tre tipi di agenti:
Patches : Corrispondo ai pixel del mondo virtuale e sono quindi
immobili. Possono cambiare colore o contenere informazioni sotto forma
di variabili proprietarie.
Turtles : Sono oggetti in grado di muoversi, cambiare colore, forma e
proprietà, anche stavolta sotto forma di variabili proprietarie.
Observer : monitora tutto quello che accade nel mondo
Un passo fondamentale per la comprensione di NetLogo è la conoscenza del
fatto che esso è stato progettato dai suoi ideatori con uno specifico tipo di
modello in mente: agenti mobili che agiscono concorrentemente in uno spazio a
matrice con un comportamento dominato dalle interazioni locali in brevi istanti
temporali.
90
Fabrizio Schiano
Forse proprio perché NetLogo è stato progettato chiaramente per un tipo
specifico di modello e per il fatto che utilizza un linguaggio abbastanza
semplificato, gli scienziati tendono a considerarlo troppo limitato.
Figura 34 : Il mondo in NetLogo
In conclusione si può affermare che NetLogo è una piattaforma molto in voga
per lo sviluppo di ABM, e che si presta molto per applicazioni in cui i sistemi non
sono troppo complessi, inoltre è un software molto indicato per utenti inesperti,
e ciò gli ha permesso una facile diffusione a livello mondiale.
3.4.2 SWARM (Objective-C & Java versions): Swarm è nato nel 1995, nel Santa
Fe Institute (New Mexico, USA). L'obiettivo era quello di creare un insieme di
programmi e librerie standard, da usare per simulare ed analizzare sistemi
complessi di comportamento, nell'ambito delle scienze naturali e sociali.
Figura 35 : Il logo di SWARM
91
Fabrizio Schiano
L'idea era di avere uno strumento che permettesse ai ricercatori di sviluppare le
loro applicazioni senza dovere spendere tempo su problemi tipici di
programmazione informatica (per esempio, la generazione di grafici o di
un'interfaccia grafica, o i modi di salvare i risultati delle simulazioni).
SWARM è una piattaforma per modelli agent-based (ABM) che include:
Una struttura concettuale per la progettazione, descrizione e conduzione
di esperimenti su ABM.
Un software che implementa questa struttura e fornisce molti pratici
tool.
Una community di utenti e sviluppatori che condividono le idee, i
software e l’esperienza.
Uno dei concetti chiave di SWARM è che il software deve implementare sia un
modello, sia, separatamente, fornire un laboratorio virtuale per l’osservazione e
la conduzione di esperimenti sul modello stesso. Un altro concetto molto
importante nella comprensione di questa piattaforma è il fatto che i modelli
sono progettati come una gerarchia di “Swarms”, essendo lo Swarm il
componente fondamentale che organizza gli agenti di un modello SWARM. Uno
Swarm è una collezione di agenti con un programma di eventi applicabile a
questi agenti.
Un semplice esempio di Swarm può essere un insieme di 15 lupi, 50 conigli e un
giardino con delle carote, e un semplice programma potrebbe essere: i conigli
mangiano le carote e si nascondono, i lupi mangiano i conigli. Oltre ad essere
contenitori di agenti, gli Swarm possono essere loro stessi degli agenti.
La maggior parte di risorse presenti sulla rete che riguardano questo software
sono le seguenti:
The Swarm Development Group (http://www.swarm.org/index.html)
Gruppo Torinese Utilizzatori Swarm (http://eco83.econ.unito.it/swarm/)
Benedikt
Stefansson's
course
at
UCLA
(http://cce.sscnet.ucla.edu/swarmcourse/)
Support lists (http://www.swarm.org/community-mailing-lists.html).
Economic Simulations in Swarm: Agent-based Modelling and Object
Oriented Programming, editors Francesco Luna and Benedikt Stefansson,
Kluwer Academic Publishers, 2000. Questo libro contiene rapporti su
diversi lavori che usano Swarm, i cui programmi si trovano sul sito web di
92
Fabrizio Schiano
Swarm
(ftp://ftp.swarm.org/pub/swarm/src/userscontrib/anarchy/lunabook/).
Swarm by Example: bell, Ralph Stefan: è una presentazione di un
programma,
dalla
prima
idea
alla
compilazione.
(ftp://ftp.swarm.org/pub/swarm/src/userscontrib/anarchy/bell/HTML/bell.html)
Le librerie di Swarm sono scritte con ObjectiveC. Però gli scrittori di Swarm
forniscono un'interfaccia per scrivere i programmi con Java. Non c'è dunque
un'implementazione “nativa” di Swarm in Java (e non è prevista).
Per scrivere un programma in Swarm i files che verranno scritti, sono diversi a
seconda se si utilizza ObjectiveC o Java, ma comunque si troveranno sempre gli
stessi elementi, che sono i seguenti:
Un file dove è definita una funzione main(), che è fondamentale nel
programma. Qui, viene inizializzato lo Swarm, e sono creati gli “Swarms”
importanti nel programma (il modelSwarm, l'observerSwarm o
l'experimentSwarm), ed è sempre qui che viene lanciata la simulazione.
Un Makefile che permette di compilare il programma, esso contiene i
nomi dei files che compongono il programma, le relazioni fra di loro, con
informazioni sulla posizione di Swarm nel filesystem.
Un modelSwarm, dov'`e definito il modello e sono creati gli agenti. Un
programma di Swarm funzionerebbe anche senza modelSwarm,
dichiarando tutto nel metodo main(), ma si perderebbero molte facilità di
Swarm (specialmente gli Schedules).
(Facoltativo, ma utile) Un observerSwarm, dove si trovano gli oggetti e
le interfaccie grafici.
(Facoltativo) Un experimentSwarm, dov'è definita una simulazione.
Permette di far girare il programma più volte, cambiando alcuni
parametri.
Alcuni files che definiscono gli agenti del modello.
La differenza principale tra un programma scritto in Java e uno in Objective-C è
che dichiarazioni e implementazioni delle classi non sono più separate fra i files
.h e .m. Ogni classe di nome ClassName si trova in un file ClassName.java (si noti
la corrispondenza fra il nome della classe e quello del file). La funzione main() si
trova nel file ProgramName.java, che dopo compilazione girerà con il comando:
javaSwarm ProgramName. La compilazione si fa sempre tramite il Makefile.
93
Fabrizio Schiano
Ambedue le versioni di Swarm, scritte in due linguaggi diversi, hanno
caratteristiche positive e negative.
A proposito di Objective-C:
È semplice da usare.
È il linguaggio nel quale è stato sviluppato Swarm dall'inizio, dunque la
maggioranza delle risorse (programmi, tutorials, ecc) sono scritti in
Objective-C.
È veloce.
Objective-C permette di usare le funzioni di “low-level” di C, tipo unioni e
puntatori (che tra l'altro, possono essere pericolose per il debuttante).
Permette “dynamic typing” 24.
A proposito di Java:
È semplice da usare, ma i nomi dei metodi sono generalmente più lunghi
(dunque, un pò più da scrivere).
Ha però come vantaggio il fatto che si scrivono meno files.
Possiede meno risorse (tutorials, programmi, ecc), ma in questi ultimi
anni si sta sviluppando.
Di questo linguaggio se ne fa un grande uso anche nella creazione di siti
internet, applets, ecc.
Incoraggia lo “static typing”25, quindi forza a evitare alcuni errori
(specialmente di runtime), che si possono fare con Objective-C. Dall'altro
lato, è meno flessibile in certe circostanze.
24
In Objective-C esiste un tipo di dato molto importante ed e’ il tipo id. Esso altro non e’ che un
puntatore all’oggetto, o volendo essere più precisi, un puntatore alla variabile d’istanza dell’oggetto. Il
tipo id non tiene conto di informazioni sull’oggetto, eccetto il fatto che e’ un oggetto. Ma ci sarà un
punto del programma che si dovranno usare i metodi dell’oggetto a cui l’id punta. Quindi la domanda
che nasce e’: "come fa il compilatore a sapere mentre il programma sta eseguendo (in gergo: a runtime)
a che TIPO di oggetto punta la variabile di tipo id?" Ogni oggetto deve essere in grado di dire a tempo
d’esecuzione qual’e’ il suo tipo e per farlo usa una variabile d’istanza detta isa che identifica la classe
dell’oggetto, cioè che tipo d’oggetto è. Gli oggetti sono quindi "tipati dinamicamente" a tempo
d’esecuzione.
25
I linguaggi di programmazione che utilizzano lo static typing sono quelli in cui le variabili non hanno
bisogno di essere dichiarate prima del loro utilizzo. Questo implica che in questi linguaggi ci deve essere
94
Fabrizio Schiano
Java fa automaticamente il “garbage collecting” (cioè distrugge
automaticamente gli oggetti non usati, prevenendo quindi i “memory
leaks”). Infatti visto che anche un ABM molto semplice genera milioni di
oggetti molto rapidamente, il fallimento dei programmi scritti in
Objective-C a rilasciare gli oggetti inutilizzati, fa peggiorare velocemente
le performance del sistema.
Java non è il linguaggio nativo di Swarm, dunque certe funzioni possono
essere più lente di quelle scritte con Objective-C, a causa delle necessarie
traduzioni.
L'interfaccia Java offre la possibilità di sfruttare delle numerose librerie
grafiche di Java (che sono più ricche di quelle offerte da Swarm).
Visto che queste piattaforme utilizzano ampiamente classi generiche, i
programmatori sono portati ad usare frequentemente gli operatori di
casting di Java. Questo rende il codice più complicato sia per la lettura
che per la scrittura, e rende il tutto scoraggiante per gli utenti alle prime
armi.
Per concludere si può riportare una frase di Marcus Daniels, Alex Lancaster e
Benedikt Stefansson espressa nel loro articolo: A tutorial introduction to Swarm:
“Mentre Objective-C ha molti vantaggi strettamente come linguaggio, i vantaggi
culturali e pratici di Java hanno maggior peso per le persone che vogliono
cominciare a programmare con Swarm”.
Quindi da questa affermazione si capisce che probabilmente tra queste due
versioni di Swarm non si può dire quale sia la migliore in assoluto, ma
probabilmente sarebbe consigliabile avvicinarsi alla piattaforma che utilizza Java
nel caso in cui non ci sia esperienza in questo campo.
3.4.3 Repast: Sviluppato originalmente all’University of Chicago, il Recursive
Porous Agent Simulation Toolkit (Repast) è oggi sostenuto dall’Argonne National
Laboratory e gestito dalla Repast Organisation for Architecture and
Development (ROAD). Inoltre Repast fornisce una libreria di classi per la
creazione, esecuzione, visualizzazione e collezione dei dati da una simulazione
una dichiarazione esplicita prima che le variabili vengano utilizzate. Java è un esempio di linguaggio
static typed.
95
Fabrizio Schiano
agent-based. Repast include anche diverse varietà di grafici per la
visualizzazione dei dati (i.e. istogrammi e grafici sequenziali) ed è capace di
prendere degli snapshots delle simulazioni in esecuzione, o creare video
QuickTime. Sicuramente Repast prende molto in prestito dalla piattaforma
Swarm, infatti può essere propriamente visto come una struttura di simulazione
“Swarm-Like”.
Figura 36 : Il logo di Repast
Repast provvede all’implementazione dei modelli in tre linguaggi di
programmazione:
Python (RepastPy);
Java (RepastJ);
Microsoft.Net (Repast.Net).
RepastPy permette la creazione di modelli base che possono essere sviluppati
da programmatori con una esperienza limitata attraverso una “point-and-click”
GUI26. I modelli RepastPy possono essere in seguito esportati e/o convertiti in
Java per un ulteriore sviluppo in Repastj.
Repast.Net e RepastJ permettono lo sviluppo di modelli più avanzati in quanto
in un modello possono essere programmate funzionalità più complesse.
Repast ha un gruppo di utenti esteso e una mail-list attiva, come anche una
documentazione abbastanza fornita e dei modelli di dimostrazione disponibili
sul sito ufficiale della piattaforma (http://repast.sourceforge.net/).
26
L'interfaccia utente grafica, in sigla GUI (del corrispondente termine inglese graphical user interface),
comunemente abbreviata in interfaccia grafica, è un paradigma di sviluppo che mira a consentire
all'utente di interagire con il computer manipolando graficamente degli oggetti, svincolandolo
dall'obbligo di imparare una serie di comandi da impartire con la tastiera come invece avviene con le più
tradizionali interfacce testuali CLI (command line interface). È lo strato di un'applicazione software che si
occupa del dialogo con l'utente del sistema utilizzando un ambiente grafico.
96
Fabrizio Schiano
Bisogna dire che mentre RepastJ è tuttora sostenuto, Repast.Net e RepastPy
hanno già raggiunto una loro maturità e quindi tendono a non essere più
migliorati. Essi sono stati rimpiazzati da Repast Simphony (RepastS) che fornisce
tutte le funzionalità essenziali di RepastPy e Repast.Net, sebbene
l’implementazione sia fatta in Java. Il team di sviluppo di Repast ha fornito una
serie di articoli riguardanti RepastS. L’architettura e le funzionalità essenziali
sono introdotte da North et al. (2005), mentre l’ambiente di sviluppo è discusso
da Howe et al. (2006). Inoltre Tatara et al. forniscono una descrizione
dettagliata di come sviluppare un semplice modello “preda-predatore”,
illustrando le capacità di modellazione di RepastS.
In sintesi quindi Repast ha al giorno d’oggi tre tipi di piattaforme disponibili, e
ognuna di queste ha le stesse caratteristiche fondamentali. Comunque ogni
piattaforma fornisce un ambiente diverso per queste caratteristiche. Prese
insieme, le diverse versioni di Repast danno ai “modellisti” una scelta degli
ambienti per lo sviluppo e l’esecuzione del modello. RepastS estende l’insieme
di scelta, offrendo un nuovo approccio allo sviluppo e all’esecuzione delle
simulazioni.
In breve, una simulazione in Repast è primariamente una collezione di agenti di
ogni tipo e un modello che configura e controlla l’esecuzione dei
comportamenti di questi agenti, in accordo con un programma. Quest’ultimo
non solo controlla l’esecuzione dei comportamenti degli agenti, ma anche le
azioni relative al modello, come ad esempio l’aggiornamento delle finestre, la
registrazione dei dati e così via.
Infine per quanto riguarda il futuro, il lavoro su Repast si sta concentrando su
Evolver, un ambiente di sviluppo per la simulazione rapida, che risulta utile per
la creazione di simulazioni di reti. Usando un modello drag-and-drop, una
simulazione può essere graficamente composta di vari pezzi (modelli predefiniti,
agenti, componenti di analisi, ecc.). Ogni comportamento desiderato non
incluso nei componenti predefiniti può essere specificato usando NQPython
(Not Quite Python), un linguaggio Python-like specificatamente progettato per
integrarsi alla perfezione con Repast, ed inoltre molto più semplice di Java. Si
spera infine di espandere le capacità di Evolver oltre i modelli di reti.
97
Fabrizio Schiano
Figura 37 : Interfaccia utente di Repast con il modello “predator-prey”.
3.4.4 MASON: Questa piattaforma verrà presentata come un’evoluzione
scaturente da una tradizione ispirante di precursori come: Swarm, Ascape,
Repast.
Figura 38 : Il logo di MASON
MASON, l’ultimo toolkit che verrà analizzato in questo capitolo, è utile per la
simulazione di sistemi multi-agente a eventi discreti e single-process, veloce,
facilmente estendibile e scritto in Java. MASON fu progettato per diventare la
base per un gran range di simulazioni multi-agente, dallo swarm robotics ad
ambienti sociali complessi, comunque con un’enfasi particolare per le
applicazioni di swarm con tantissimi agenti (fino a milioni). Il suo progetto nasce
per affermarsi come alternativa più piccola e veloce a Repast.
98
Fabrizio Schiano
Il sistema è open-source e free, con licenza BSD27, ed è il risultato di uno sforzo
comune del dipartimento di Computer Science e del centro di Social Complexity
della George Mason University e può essere scaricato all’indirizzo web
http://cs.gmu.edu/ ∼ eclab/projects/mason/.
MASON è provvisto di diverse applicazioni di esempio, come quelle che
riguardano la ricerca del cibo delle formiche, i comportamenti degli stormi di
uccelli o dei banchi di pesci, sia in 2D che in 3D, modelli che simulano un
infezione virale e l’osservazione cooperativa di un obiettivo.
I modelli sviluppati in MASON possono essere affiancati da un toolkit GUI che
abilita la visualizzazione e la manipolazione del modello sia in 2D che in 3D (con
Java 3D), e che può produrre screenshoots e video. MASON non offre modelli
base, per programmatori alle prime armi, come fa NetLogo.
MASON è nato per soddisfare il bisogno di avere un toolkit che rendesse
relativamente semplice la creazione di un gran range di sistemi multi-agente e
altri modelli di simulazione, e per eseguire molti di questi modelli
efficientemente in parallelo.
Figura 39 : Elementi base del modello MASON e della piattaforma di visualizzazione
Gli obiettivi di progetto di MASON si possono riassumere così:
27
Le licenze BSD sono una famiglia di licenze permissive per software. Molte sono considerate libere ed
open source. Il loro nome deriva dal fatto che la licenza BSD originale (detta anche licenza BSD con 4
clausole) fu usata originariamente per distribuire il sistema operativo Unix Berkeley Software
Distribution (BSD), una revisione libera di UNIX sviluppata presso l'Università di Berkeley.
99
Fabrizio Schiano
Un nucleo piccolo, veloce, facilmente comprensibile e semplicemente
modificabile.
Una visualizzazione separata ed estendibile in 2D e 3D.
La produzione di risultati identici, indipendentemente dalla piattaforma.
La possibilità di creare un checkpoint nel disco per ogni modello, in modo
tale che esso possa essere ripreso in qualunque altra piattaforma con o
senza visualizzazione.
Un supporto efficiente senza visualizzazione, per un gran numero di
agenti (fino a milioni).
Un supporto efficiente con visualizzazione, per più agenti possibile.
Un semplice sistema di librerie.
Per quanto riguarda l’architettura, MASON è scritto in Java, che ha una
immeritata reputazione di lentezza; è un toolkit organizzato in maniera
modulare, con una architettura a strati. Alla base c’è un insieme di strutture dati
che possono essere usate per qualunque scopo. Subito dopo viene il livello che
riguarda il modello, con una collezione di classi che consistono in un programma
a eventi discreti, un generatore di numeri casuali di alta qualità, e una varietà di
campi che possono contenere oggetti e associarli a delle locazioni. Un altro
livello è quello della visualizzazione, che permette l’esposizione di campi e il
controllo della simulazione da parte dell’utente (l’architettura di MASON è
esposta anche nella figura seguente).
Figura 40 : Architettura della piattaforma MASON
100
Fabrizio Schiano
In ogni istante si può distinguere il livello “modello” da quello “visualizzazione”,
e come già detto si può fare un checkpoint del modello sul disco, e spostarlo in
un'altra piattaforma e continuare ad eseguirlo o associarlo a un altro tipo di
visualizzazione (vedi fig. 41).
Figura 41 : Checkpoint e recupero di un modello MASON per eseguirlo stand-alone o su diversi tipi di tool di
visualizzazione
Alcune differenze tra MASON e Repast:
MASON:
Modello e visualizzazione separati.
Modelli in 3D.
Più veloce, specialmente su MAC OS X.
Più chiaro e più piccolo.
Repast:
Ha già al suo interno un supporto GIS.
Permette “l’import/export” in Excel.
Creazione di tabelle e grafici (in MASON questi dovrebbero essere
contenuti nel livello “custom simulation library”).
I modelli MASON sono tradizionalmente creati in due passi:
1. L’autore sviluppa il modello adatto semplicemente come una sottoclasse
di SimState28 completo di un codice ciclico che fa partire la simulazione,
esegue il programma, e alla fine termina. Dopo che questo codice è
completato, il modello MASON dovrebbe essere capace di eseguire sulla
command-line come un’applicazione GUI-less con ingresso indipendente.
28
Un modello MASON è interamente contenuto in una singola istanza di una sottoclasse user-defined
della classe del modello MASON (SimState). Questa istanza contiene un programma a eventi discreti e
zero o più campi.
101
Fabrizio Schiano
2. L’autore crea un GUI-State per incapsulare il SimState allegando le
caratteristiche e le dimostrazioni. A questo punto le simulazioni possono
essere anche visualizzate.
Figura 42 : Simulazione della ricerca del cibo da parte delle formiche, sviluppata in MASON.
In conclusione, possiamo affermare che MASON è una piattaforma veloce,
portabile, con un nucleo abbastanza piccolo e che produce risultati replicabili
facilmente anche in altre piattaforme. Infatti come si è accennato in
precedenza, MASON è stato progettato per poter dividere dinamicamente il
modello dalla visualizzazione, o “riattaccarli” per portare la simulazione in
un’altra piattaforma, durante un’esecuzione. Inoltre, come già detto, è possibile
fornire la visualizzazione sia in 2D che in 3D.
3.5 Qual è la piattaforma migliore?
Tra quelle elencate NetLogo è sicuramente la piattaforma a più alto livello,
fornendo un semplice ma potente linguaggio di programmazione, integrato con
interfacce grafiche e una documentazione di supporto all’uso della piattaforma.
NetLogo è altamente consigliata, per la progettazione di modelli non troppo
complessi, e per scopi didattici.
MASON, Repast e Swarm sono piattaforme che forniscono una struttura per
l’organizzazione e la progettazione di Agent Based Models (ABMs) e le
corrispondenti librerie software. MASON è meno matura ed è progettata per
massimizzare la velocità di esecuzione. La versione Objective-C di Swarm è la
piattaforma con la libreria più matura, stabile e ben organizzata. L’Objective-C
sembra più naturale di Java per gli ABM ma soffre per quanto riguarda la
102
Fabrizio Schiano
manutenzione del software e per la mancanza di tool di sviluppo. La versione
Java di Swarm permette alle librerie in Objective-C di essere richiamate da Java.
Repast fornisce funzioni Swarm-like in una libreria Java ed è una buona scelta in
molti casi, anche se parti della sua organizzazione andrebbero migliorate.
Una piattaforma che non verrà analizzata nel dettaglio nel seguito della
trattazione, ma che si è voluta citare per portare un esempio di piattaforma
conforme alle specifiche FIPA sopraesposte è JADE (Java Agent Development
Framework) che rende semplice lo sviluppo di applicazioni multi-agente in
accordo con le specifiche FIPA sopra esposte. JADE prova a mantenere alte le
performance di un sistema multi-agente distribuito, implementato in linguaggio
Java. Questa piattaforma usa un modello di agente e un’implementazione Java
che le permettono una buona efficienza di esecuzione, una buona riusabilità del
software, mobilità degli agenti e la realizzazione di diverse architetture multiagente.
Naturalmente non c’è una piattaforma migliore delle altre in assoluto, in quanto
dobbiamo ricordare che:
Le piattaforme analizzate continuano ad evolvere, alcune molto
rapidamente.
Sarebbe impossibile, anche volendo, esaminare tutte le situazioni in cui
possiamo trovarci con le simulazioni di alcuni modelli di esempio.
Ci sono tante altre piattaforme che non sono state analizzate in questo
capitolo.
NetLogo
Con la sua eredità di tool educazionale e didattico, emerge per la sua semplicità
di utilizzo e per la documentazione eccellente. È semplice raccomandare
NetLogo per modelli che sono:
Compatibili con il suo paradigma di breve termine e di interazione locale
tra gli agenti in un ambiente a matrice.
Non estremamente complessi.
Inoltre si consiglia NetLogo per la “prototipazione” di modelli che verranno più
tardi estesi con piattaforme di più basso livello.
103
Fabrizio Schiano
La sua velocità di esecuzione non è una grande limitazione per molti campi di
applicazione, anche tenendo conto del gran risparmio di tempo in termini di
programmazione. Comunque i programmatori con più esperienza potrebbero
trovarsi male con NetLogo per il suo ambiente di sviluppo troppo semplificato.
Inoltre il vincolo di dover tenere tutto il codice in un solo file diminuisce la
possibilità di organizzazione del modello, e questa cosa può essere molto
scomoda per modelli di grandi dimensioni.
Questa piattaforma sembra non offrire un buon trade-off dei benefici di Java e
Objective-C. Sicuramente essa centra il suo obiettivo di creare una versione di
Swarm per gli utenti Java, ma ora che molte altre piattaforme Java sono
disponibili, i suoi motivi di attrazione sembrano essersi esauriti.
MASON
Questa potrebbe essere una buona scelta per programmatori esperti che
devono lavorare su modelli che richiedono un gran sforzo computazionale, cioè
che hanno molti agenti o tempi lunghi di esecuzione. Alcuni esperimenti di
Steven F. Railsback, Steven L. Lytinen & Stephen K. Jackson, hanno individuato
MASON come la piattaforma più veloce tra quelle analizzate in precedenza,
anche se i tempi di esecuzione di Repast erano soltanto dall’1 al 54% più lunghi
di quelli di MASON, con questa differenza che decresce all’aumentare della
complessità computazionale del modello in questione. Molte delle innovazioni
di MASON sono abbastanza intelligenti, come ad esempio l’inclusione di tutti I
metodi di disegno nella classe di interfaccia utente.
MASON può risultare abbastanza ostico per le persone che sono alle prime armi
in questo campo o nel caso di ABM molto complessi. Le cose che solitamente
non piacciono di MASON sono:
La terminologia non standard e a volte abbastanza confusa.
Insiemi di classi incompatibili.
104
Fabrizio Schiano
La mancanza di una terminal window nella quale poter fare il debugging,
mentre si lavora nell’IDE29 Eclipse.
Figura 43 : Interfaccia di un modello originale in SWARM (sinistra) e replicato in MASON (destra).
È il padre delle piattaforme che aderiscono al paradigma “struttura e libreria”
ed ha ancora i suoi vantaggi. Swarm è stabile, relativamente piccolo e ben
organizzato ed inoltre fornisce un insieme completo di tool, ha delle basi
concettuali chiare e un progetto intelligente, infine permette una separazione
netta tra le interfacce grafiche e il modello. Il suo concetto di “swarm” aiuta ad
organizzare i modelli: i modelli possono essere progettati e implementati
gerarchicamente in swarms separati, ognuno con la sua collezione di oggetti e il
suo programma di azioni. Questa capacità fornisce un livello di organizzazione
utile per i modelli semplici e specialmente per gli ABM complessi.
Gli svantaggi della versione Objective-C di swarm sono, come già indicato in
precedenza, quelli del linguaggio Objective-C:
29
Un integrated development environment (IDE), in italiano ambiente di sviluppo integrato, (conosciuto
anche come integrated design environment o integrated debugging environment, rispettivamente
ambiente integrato di progettazione e ambiente integrato di debugging) è un software che aiuta i
programmatori nello sviluppo del codice.
105
Fabrizio Schiano
Mancanza di tool per utenti alle prime armi.
Debole gestione degli errori.
La mancanza del “garbage collecting” (vedi paragrafo 3.4.2).
Questi svantaggi sono aggravati da una bassa disponibilità di documentazione e
in generale di materiale che potrebbe essere utile per la comprensione del
funzionamento della piattaforma.
Per alcuni tipi di modelli Swarm è più veloce delle piattaforme Java e per altri
tipi di modelli è più lento. In generale l’Objective-C dovrebbe essere più veloce
per la pura computazione, ma il fatto che Swarm utilizzi il suo codice per
l’implementazione delle funzioni di basso livello (definizione di oggetti e
allocazione delle variabili) potrebbe avere un suo costo in termini di tempi di
esecuzione.
Repast
È sicuramente la piattaforma Java più completa. Per implementare molte delle
funzioni di Swarm, Repast ha aggiunto alcune capacità come l’abilità di resettare
e far ripartire i modelli dall’interfaccia grafica e il gestore dell’esperimento di
“Multi-run”. Steven F. Railsback, Steven L. Lytinen & Stephen K. Jackson, hanno
trovato la velocità di esecuzione di questa piattaforma abbastanza comparabile
con la velocità delle altre piattaforme. Inoltre Repast include molte classi per
funzioni geografiche e di reti.
Anche se sono stati compiuti molti sforzi per rendere Repast accessibile ai
novizi, alcuni dei suoi elementi di base sembrano incompleti o non
adeguatamente progettati. Per cominciare si potrebbe organizzare meglio la
distribuzione del software stesso, ad esempio etichettando i pacchetti in primo
luogo per la loro funzione e separare i modelli dimostrativi dal software di base.
Nessuno di questi problemi è grave, ma con la grande comunità che segue
questa piattaforma, essi potranno essere superati facilmente nei prossimi anni.
106
Fabrizio Schiano
Capitolo 4
Conclusioni
In questa tesi viene proposto l’impiego di flotte di piattaforme aeree e terrestri
interoperabili e cooperanti, per applicazioni di gestione del post-evento
catastrofico. Vengono anche dimensionati e selezionati, come componente
essenziale del sistema, i sensori che potrebbero essere trasportati dalle
piattaforme per compiere le specifiche missioni.
I sistemi unmanned troveranno nei prossimi anni larga diffusione in impieghi
civili, soprattutto per le loro caratteristiche di utilizzo in ambienti “ostili”, dove è
pericoloso l’intervento umano. Tra i sistemi unmanned quelli considerati, di
classe “Small” (0-25kg), per loro natura amplificano la loro efficacia quando
vengono utilizzati in modalità cooperativa. Inoltre si fanno preferire per i bassi
costi sia di acquisizione che operativi, per la loro facilità di utilizzo e per la loro
intrinseca sicurezza che rilassa i requisiti connessi alle problematiche di
certificazione al volo tipiche dei sistemi di categoria superiore.
La soluzione alla base del funzionamento “cooperativo” di tali piattaforme è un
problema aperto e va individuata analizzando un sistema di sistemi composto
da più agenti e utilizzando per la sua modellazione tecniche “multi-agente”
unite a paradigmi di cooperazione di tipo Swarm.
Nella tesi si sono analizzati i lavori di due ricercatori che da anni lavorano in
questo settore:
H. Van Dyke Parunak
Marco Dorigo
Nei loro studi sono proposti, rispettivamente, due diversi paradigmi di
modellazione per la tecnica Swarm e approccio multi-agente:
Polyagent
107
Fabrizio Schiano
Ant-Colony-Optimization
In entrambi i casi l’approccio utilizzato per risolvere problemi complessi con il
paradigma della Swarm Intelligence appare molto efficace e convincente. I due
paradigmi sono comunque molto vicini e condividono soluzioni ispirate al
comportamento degli insetti in natura.
Il paradigma Ant-Colony-Optimization di Dorigo si presta particolarmente bene
alla ricerca di soluzioni ottime per problemi complessi come il TSP e in generale
per problemi di ottimizzazione ad alta complessità noti come NP-Hard Problem.
Questo algoritmo ha basi teoriche molto forti, è molto flessibile e si presta alla
soluzione di problematiche diverse: routing, scheduling, assignment, bayesian
networks, protein folding ecc .
L’uso dell’ ACO nella ottimizzazione di traiettorie di missione per sistemi UAS in
letteratura trova applicazione in sistemi a singola piattaforma e non cooperanti.
Questo e’ dovuto alla specifica formulazione dell’ACO che, per essere estesa a
flotte di velivoli cooperanti, deve prevedere ancora uno sviluppo teorico e
algoritmico.
Il paradigma Polyagent di H. Van Dyke Parunak nasce proprio come sistema di
ottimizzazione di tipo swarm per flotte di velivoli cooperanti.
Tale paradigma non ha avuto formulazioni teoriche complete come l’ACO ma
nel corso degli anni, è stato sviluppato e raffinato grazie a fondi del DARPA e
all’interessamento di più settori del mondo militare americano. Il Polyagent,
inoltre, è arrivato a dimostrare sul campo la sua efficacia e fattibilità riuscendo a
coordinare in un caso reale piattaforme volanti e terrestri atte a proteggere una
infrastruttura critica, una base della NASA, da attacchi esterni. Le missioni di
individuazione automatica delle incursioni così come la cooperazione tra le
piattaforme e stata ottenuta proprio con il paradigma Polyagent.
In conclusione possiamo considerare che, volendo implementare un paradigma
Swarm per una applicazione reale di piattaforme cooperanti sia da preferire
l’approccio Polyagent. Al momento si intravedono alcune lacune, probabilmente
volute, dell’implementazione del Polyagent soprattutto nella descrizione del
108
Fabrizio Schiano
funzionamento dei ghost agents. Sicuramente la conoscenza del paradigma ACO
può essere di aiuto a colmare tali lacune vista l’affinità di approccio.
Nel polyagent la tecnica del campo a potenziale feromonico supera i limiti dei
campi potenziale classici rendendo il campo dinamico e distribuito attraverso la
stigmergia.
Figura 44 : Possibile scenario di una missione di monitoraggio
La possibile applicazione di tale tecnica alla gestione delle flotte di SUAS nel
post-evento nel terremoto di L’Aquila può considerarsi appropriata, soprattutto
in considerazione che l’inizializzazione della mappa feromonica potrebbe essere
effettuata grazie alla previsione dello scenario di danno già disponibile pochi
minuti dopo l’avvenuto sisma. In tale caso infatti lo scenario di danno
consentirebbe di indirizzare correttamente i velivoli che sarebbero attratti da
livelli elevati di feromone attrattivo in prossimità delle zone con la massima
probabilità di trovare vittime. L’inserimento dei dati realmente osservati dalle
piattaforme durante la missione, consentirebbe poi di attualizzare
correttamente il campo feromonico e quindi lo scenario di danno precedente,
aggiornando il dato statistico con un dato reale. Questa aumentata
109
Fabrizio Schiano
consapevolezza della situazione può facilitare il coordinamento e l’arrivo dei
soccorsi, che utilizzerebbero tali informazioni per raggiungere le zone più
critiche.
Relativamente all’analisi delle piattaforme software che implementano la
modellazione multi-agente, si riportano di seguito alcune priorità di sviluppo di
future piattaforme software, scaturite dall’analisi delle piattaforme esaminate.
1. Realizzare una documentazione completa di classi e metodi con molti
esempi. Infatti il problema della scarsa documentazione è molto presente
al giorno d’oggi, in quanto è difficile svilupparne una abbastanza
completa, ma soprattutto è complicata mantenerla continuamente
aggiornata. In questo ambito si segnala la necessità di sviluppo continuo
di documenti sull’how-to e dei modelli template30.
2. Integrare la libreria software con un IDE, come ad esempio Eclipse.
3. Uniformare con continuità la struttura della piattaforma agli standard del
settore, permettendo di raggiungere gradualmente uno degli scopi più
importanti di una piattaforma che è quello di fornire un linguaggio
comune per progettare e descrivere un ABM.
4. Garantire il supporto di modelli complessi e modelli multi-livello.
5. Rendere disponibili tool per la generazione di output statistici. Si
potrebbero utilizzare le librerie statistiche già esistenti, purché siano di
semplice utilizzo anche per i programmatori alle prime armi.
6. Migliorare il trade-off tra la facilità di utilizzo e la generalità delle
piattaforme. Questo obiettivo potrebbe essere raggiunto creando task
comuni, più facili da programmare, ad esempio usando codice ad alto
livello come quello utilizzato da NetLogo.
7. Assicurare la compatibilità della piattaforma con la maggior parte dei
sistemi operativi, o quantomeno con quelli più popolari.
30
Il termine inglese template indica in informatica un documento o programma dove, come in un foglio
semicompilato cartaceo, su una struttura generica o standard esistono spazi temporaneamente
"bianchi", da riempire successivamente.
110
Fabrizio Schiano
Bibliografia
Marco Dorigo & Thomas Stützle, Ant Colony Optimization, The MIT press, pp.
65-119, 2004.
[2] Marco Dorigo, Mauro Birattari & Thomas Stützle, Ant Colony Optimization:
artificial ants as a computational intelligence technique, IEEE Computational
Intelligence Magazine, pp. 28-39, November 2006.
[3] E.Bonabeau, Marco Dorigo & G. Theraulaz, Insipiration for optimization from
social insect behaviour, Nature vol.406 pp. 39-42, July 2000.
[4] Shervin Nouyan, Alexandre Campo & Marco Dorigo, Path formation in a
robot swarm, Springer Science + Business Media, December 6, 2007
(published online).
[5] H. Van Dyke Parunak, Go to the Ant: Engineering Principles from Natural
Multi-Agent Systems, CEC/ERIM, 1996.
[6] H. Van Dyke Parunak, Making Swarming Happen.
[7] H. Van Dyke Parunak & Sven A. Brueckner, Engineering Swarming Systems,
31 October 2003.
[8] H. Van Dyke Parunak & Sven A. Brueckner, Concurrent Modeling of
Alternative Worlds with Polyagents.
[9] H. Van Dyke Parunak, Micheal Purcell & Robert O’Connell, Digital
Pheromones for Autonomous Coordination of Swarming UAV’s, American
Institute of Aeronautics and Astronautics, 2002.
[10] John A. Sauter, Robert Matthews, H. Van Dyke Parunak & Sven A. Brueckner,
Performance of Digital Pheromones for Swarming Vehicle Control,
Forthcoming at the Fourth International Joint Conference on Autonomous
Agents and Multi-Agent Systems (AAMAS05), Utrecht, Netherlands, July
2005.
[11] Richard M. Murray, Recent Research in Cooperative Control of Multi-Vehicle
Systems, ASME Journal of Dynamic Systems, Measurement, and Control, 10
September 2006.
[12] John A. Sauter, Robert S. Matthews, Joshua S. Robinson, John Moody &
Stephanie P. Riddle, Swarming Unmanned Air and Ground Systems for
Surveillance and Base Protection, AIAA, Seattle, WA, 6-9 April 2009.
[13] John A. Sauter, Robert S. Matthews, Joshua S. Robinson, John Moody &
Stephanie P. Riddle, Distributed Pheromone-Based Swarming Control of
[1]
111
Fabrizio Schiano
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
Unmanned Air and Ground Vehicles for RSTA, Forthcoming in Proceedings of
SPIE Defense & Security Conference, Orlando, FL, March 2008.
Sabine Hauert, Laurent Winkler, Jean-Christophe Zufferey, Dario Floreano,
Pheromone Based Swarming for Positionless MAVs, Flying Insects and
Robots symposium, Monte Verità, Switzerland, August 12-17, 2007.
Allison Ryan, Marco Zennaro, Adam Howell, Raja Sengupta & J. Karl Hedrick,
An Overview of Emerging Results in Cooperative UAV Control, 43rd IEEE
conference on Decision and Control (CDC), pp. 602 - 607 Vol.1, 2004.
Guanjun Ma, Haibin Duan & Senqi Liu, Improved Ant Colony Algorithm for
Global Optimal Trajectory Planning of UAV under Complex Environment,
International Journal of Computer Science & Applications, Vol.4 Issue 3, pp.
57-68, 2007.
Igor Perkon, Ant Colony Optimization.
Paolo Gaudiano, Ben Shargel, Eric Bonabeau & Bruce T. Clough, Swarm
Intelligence: a New C2 Paradigm with an Application to Control of Swarms of
UAV’s, 8th ICCRTS Command and Control Research and Technology
Symposium, 2004.
Bruno Siciliano & Oussama Khatib, Springer Handbook of Robotics, Springer,
2008.
G.Persechino, Real time monitoring of crises scenario post eventum by
interoperable aerial platforms and innovative sensors, EUROP - EURON
2010, San Sebastian Spain 10-13 Marzo, 2010
M. Lega, R.M.A. Napoli, G. Persechino, P. Schiano, J. Kosmatka,
Measurements of the Urban and Suburban CO2 Vertical Profile with an
Airborne Electro-Optical Device, Airnow 2010: Air Quality Conferences: Air
Quality Forecasting and Mapping, Raleigh, NC (USA), March 15-18, 2010
J. Kosmatka, C. Forester, M. Lega, G. Persechino, Air quality plume detection
and monitoring using UAVs and unmanned rotorcraft, Airnow 2010: Air
Quality Conferences: Air Quality Forecasting and Mapping, Raleigh, NC
(USA), March 15-18, 2010
G. Persechino, P. Schiano, M. Lega, R.M.A. Napoli, Environment Monitoring
performed by Advanced Hybrid Airship at low altitude, TIES 2009 - the 20th
Annual Conference of
The International Environmetrics Society Conference 2009, Bologna - Italy, July 5-9, 2009
112
Fabrizio Schiano
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
M. Lega, F. D’Aniello, G. Persechino, Sistema integrato wireless per il
controllo remoto ed il monitoraggio real-time di sensori elettro-ottici
posizionati su piattaforma aerea UAV-LTA finalizzata al monitoraggio
ambientale, Forum Aerospazio e Difesa, Roma - Italy, 28 may 2009.
Massimiliano Lega, Giuseppe Persechino & Pasquale Schiano, EMPA Project:
Conquering the Third Dimension in Ambient Air Monitoring, U.S. EPA's 2009
National Air Quality Conference, Dallas-Texas, March 2009.
Zhong Zhang, James D. McCalley, Vijay Vishwanathan & Vasant Honavar,
Multiagent System Solutions for Distributed Computing, Communications,
and Data Integration Needs in the Power Industry, Iowa State University,
Ames IA USA.
Steven F. Railsback, Steven L. Lytinen & Stephen K. Jackson, Agent-based
Simulation Platforms: Review and Development Recommendations, USA,
September 2005.
N. Minar, R. Burkhart, C. Langton, and M. Askenazi, The Swarm simulation
system: A toolkit for building multi-agent simulations,Working Paper 96-06042, Santa Fe Institute, Santa Fe,1996.
Christian J. E. Castle & Andrew T. Crooks, Principles and Concepts of AgentBased Modelling for Developing Geospatial Simulations, Paper 110,
September 2006.
Matthew Berryman, Review of Software Platforms for Agent Based Models,
Land Operations Division Defence Science and Technology Organisation
(Australian Government), submitted: January 2008, published: April 2008.
Sean Luke, Gabriel Catalin Balan, Liviu Panait, Claudio Cioffi-Revilla & Sean
Paus, MASON: A Java Multi-agent Simulation Library, George Mason
University’s Center for Social Complexity and Department of Computer
Science, Fairfax (VA), USA.
Sean Luke, Claudio Cioffi-Revilla, Liviu Panait, and Keith Sullivan, MASON: A
New Multi-Agent Simulation Toolkit, George Mason University’s Center for
Social Complexity and Department of Computer Science, Fairfax (VA), USA.
J. Tweedale, N. Ichalkaranje, C. Sioutis, B. Jarvis, A. Consoli & G. PhillipsWren, Innovations in multi-agent systems, Journal of Network and
Computer Applications 30 pp. 1089–1115, accepted 25 April 2006.
113
Fabrizio Schiano
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
[45]
Seth Tisue & Uri Wilensky, NetLogo: A Simple Environment for Modeling
Complexity, Presented at the International Conference on Complex Systems,
Boston, May 16–21, 2004.
Alessandro Pluchino, Netogo: Introduzione alla programmazione di
simulazioni ad agenti, Dipartimento di Fisica e Astronomia and INFN sezione
di Catania Università di Catania – Italy.
Josè M. Vidal, NetLogo for Building Prototype Multiagent Systems,
Department of Computer Science and Engineering University of South
Carolina, August 29, 2007.
Paulo Blikstein, Dor Abrahamson, and Uri Wilensky, NetLogo: Where We
Are, Where We!re Going, In M. Eisenberg & A. Eisenberg (Eds.), Proceedings
of Interaction Design & Children, Boulder, Colorado, 2005.
Fabio Bellifemine, Agostino Poggi & Giovanni Rimassa, Developing Multiagent Systems with JADE, CSELT S.p.A. & Dipartimento di Ingegneria
dell’Informazione, University of Parma, Italy.
M.J. North, T.R. Howe, N.T. Collier & J.R. Vos, The Repast Simphony Runtime
System, paper extracted from Proceedings of the Agent 2005 Conference on
Generative Social Processes, Models, and Mechanisms, co-sponsored by
Argonne National Laboratory and The University of Chicago, October 13−15,
2005.
Nick Collier, Repast: An Extensible Framework for Agent Simulation, Social
Science Research Computing University of Chicago Chicago, IL.
Duncan A. Robertson, Agent-Based Modeling Toolkits NetLogo, RePast,
and Swarm, University of Warwick, UK.
Marie-Edith Bissey, Una piccola introduzione a swarm:ObjectiveC e Java,
Dipartimento di Politiche Pubbliche e Scelte Collettive POLIS, Università del
Piemonte Orientale, 7 marzo 2001.
Swarm Development Group, Documentation Set for Swarm 2.2, Published
17 December 2004.
Yoav Shoham & Kevin Leyton-Brown, Multiagent Systems, Cambridge
University Press, 2009.
Marcus Daniels, Alex Lancaster e Benedikt Stefansson, A tutorial
introduction to Swarm, Swarm Development Group, 2000.
114

Università di Napoli Federico II

Transcript

Documenti analoghi

viscosimetro brookfield

Scarica la scheda tecnica

Lubatti Claudio

apri il pdf

Algoritmi ed architetture per la risoluzione di problemi di visual search

Scheda tecnica Eco trap

Classi Seconde - Liceo Scientifico Statale GB Grassi Lecco

BRUNO BRUNI 1) Compensi connessi all`assunzione della carica di

Algoritmi ha aiutato NCOC e Agip KCO a mantenere il controllo dei

su JAZZIT - Angelo Olivieri