TODO: traduction
Questo progetto è il risultato del lavoro svolto per il corso di Sistemi Intelligenti e Robotici presente nel corso di laurea magistrale di Scienze e Ingegneria Informatica di Cesena.
L'obiettivo di questo progetto è quello di analizzare una tecnica di adattamento online in un contesto multi-robotico.
Si vuole dotare ogni robot di un core computazionale immutabile, in grado di fornire la capacità di compiere operazioni complesse ma non conosciute a priori. L'adattamento dei robot consiste nel capire come meglio utilizzare questo core al fine di massimizzare una certa funzione di fitness. Tale funzione modella il task che il robot deve compiere. Il contesto è multi-robotico siccome nello stesso ambiente sono presenti molteplici robot interagenti.
Il robot cerca di sfruttare al meglio la propria capacità computazionale per massimizzare la funzione di fitness nell'ambiante in cui è immerso: questo avviene modificando gli allacciamenti tra il core e i propri sensori/attuatori. Monitorando l'andamento della fitness il robot determina se una particolare configurazione è migliore o peggiore della precedente, mantenendo sempre la migliore trovata. L'adattamento segue una logica di computazione evolutiva, senza però andare a mutare la logica interna del core.
La funzione di fitness dei robot modella il task del moto rettilineo uniforme con evitamento degli ostacoli, viene definita in questo modo:
dove:
è il valore di prossimità massimo letto dai sensori presenti sul robot.
minore è
indica la potenza erogata al motore sinistro,
con 0 il motore è spento.
indica la potenza erogata al motore destro,
con 0 il motore è spento.
In una fase successiva del progetto si analizzerà un secondo task in cui i robot devono muoversi con un moto rettilineo uniforme, evitando gli ostacoli e rimanendo nella metà orizzontale dell'arena in cui essi sono partiti. Dunque:
dove se il robot si trova nella propria metà, altrimenti
.
In questo progetto il core computazionale è una rete booleana di moderate dimensioni (100 nodi e con k=3). In Figura 1 è mostrata la rappresentazione dell'interazione fra sensori - rete booleana - attuatori
Per ciascun robot la rete booleana viene inizializzata all'avvio della simulazione sulla base dei parametri forniti dall'esterno:
- nodi: numero di nodi della rete
- bias: bias sulla generazione delle funzioni booleane dei nodi, ogni valore della tavola di verità di una funzione ha
probabilità di essere impostato a 1 (vero).
- k: numero di interconnessioni fra i nodi
- self_loops: indica se è possibile avere dei nodi il quale output è usato anche come input
- override_output_nodes_bias: se è impostato a true le funzioni dei nodi di output vengono sovrascritti temporaneamente (finché gli allacciamenti ai nodi di output non variano) con una funzione a bias 0.5
Ogni robot genera una propria rete booleana: la configurazione è uguale per tutti i robot ma le varie istanze sono diverse in quanto il random seed è diverso per ciascun robot. La rete booleana generata rimarrà invariata durante tutta la simulazione.
Dal punto di vista fisico ogni robot è simulato attraverso il modello del foot-bot. Ogni robot è dotato di:
- differential steering: attuatore che permette di controllare i motori delle due ruote.
- footbot proximity: sensori che permettono di individuare oggetti intorno al robot.
- positioning: sensore virtuale che permette di conoscere l'esatta posizione del robot all'interno dell'arena.
L'ambiente invece è definito come un'arena quadrata con al centro un ostacolo. La superfice è piana e priva di colorazione. L'arena e i robot si presentano in questo modo:
I robot si muovono con una velocità più elevata del normale (5 cm/s) per garantire una più elevata interazione motoria. L'unico mezzo di interazione tra i robot sono i sensori di prossimità e i motori, dunque non possono distinguere un ostacolo fissato (muro) da un robot in alcun modo.
Le simulazioni sono composte da 10 robot con un posizionamento e rotazione iniziale casuale.
Il progetto ha i seguenti obiettivi:
- determinare quali classi di reti booleane offrono migliori possibilità di adattamento del robot (caotiche, ordinate, critiche, self loops) sulla base del valore di fitness calcolato.
- determinare quali mutazioni portino ad un più veloce e/o migliore adattamento del robot (numero di rewires, numero di nodi di input) sulla base del valore di fitness calcolato.
- determinare l'emergere di comportamenti particolari, sia individuali che complessivi, tra i controller che hanno prodotto un elevato valore fitness.
Sarà interessante analizzare l'interazione che i robot troveranno più conveniente: cooperativa, competitiva o neutrale. Da sottolineare che il task in questione è indipendente dagli altri robot: può essere perseguito con successo senza l'ausilio o il contrasto da parte di altri robot, tuttavia è ovvio che il risultato di una prestazione è influenzata in vari modi dal comportamento degli altri.
Il progetto nasce da un precedente lavoro svolto da Alessandro Gnucci dal quale è stata ereditata l'implementazione di un controller con esattamente le caratteristiche necessarie per il progetto: una rete booleana immutabile che controlla il funzionamento dei motori e che viene perturbata dai valori dei sensori. Il controller muta le interconnessioni mantenendo la configurazione migliore della rete booleana sulla base della fitness calcolata. Il lavoro svolto è stato quello di adattare il controller per un contesto multi-robotico e per estrarre i dati necessari al progetto. Inoltre, è stato sviluppato un progetto parallelo che permette di lanciare le simulazioni in modo automatizzato, salvare i dati raccolti e generare le informazioni richieste.
Il controller è stato scritto in linguaggio Lua. Il funzionamento del controller può essere così descritto:
All'avvio della simulazione il controller inizializza una rete booleana (che rimarrà invariata per tutta la simulazione) sulla base della configurazione ricevuta. La simulazione verrà suddivisa in molteplici test di durata prefissata (numero di step): durante l'esecuzione di un test il controller del robot rimane invariato, facendo muovere il robot nell'arena sulla base del controllo della rete booleana e accumulando il valore di fitness calcolato ad ogni step (tick).
Ad ogni step il controller sovrascrive ogni nodo di input attuale della rete booleana con il valore binarizzato del corrispettivo sensore. Successivamente viene calcolato il nuovo stato della rete booleana e determinato il valore dei nodi di output. Questi valori vengono utilizzati per controllare i motori del robot. Al termine di ogni step viene valutata la funzione di fitness ed il valore ricavato viene sommato ad un totale parziale relativo al test attuale. Infine, vengono stampati in standard output una serie di dati relativi al robot che serviranno per analizzarne il comportamento a posteriori.
Al termine di ogni test l'attuale configurazione (nodi di input e nodi di output) viene confrontata con la precedente: se ha ottenuto un migliore o uguale valore di fitness essa diventa la nuova miglior configurazione, altrimenti rimane la precedente. L'attuale miglior configurazione viene mutata (sulla base delle impostazioni della simulazione) andando a modificare gli allacciamenti tra sensori e nodi di input, e tra nodi di output e attuatori. In poche parole, vengono scelti casualmente altri nodi di input e di output. Il valore della fitness viene azzerato e un nuovo test ha inizio.
Il lavoro più corposo di questo progetto è stato quello di configurare un ambiente automatizzato per l'esecuzione di vari esperimenti, l'estrazione dei dati e la loro analisi. In questa sezione vengono descritte le varie configurazioni utilizzate per gli esperimenti, come vengono passate al controller e in che modo le simulazioni vengono eseguite.
Ogni simulazione necessita di una configurazione, quest'ultima non potrà più essere alterata dopo l'avvio della simulazione. Sono state individuate 72 configurazioni distinte da simulare. I parametri della configurazione base sono nella seguente lista suddivisi per categoria:
- simulazione:
- ticks per seconds: 10
- experiment length: 7200 (seconds)
- network test steps: 400 (ticks)
- robot count: 10
- robot:
- proximity threshold: 0.1
- max wheel speed: 5 (cm/s)
- stay on half variation: variabile
- feed position: variabile
- rete booleana:
- max input rewires: 2
- input rewires probability: 1
- max output rewires: variabile
- output rewires probability: 1
- dual encoding: false
- node count: 100
- k: 3
- bias: variabile
- input node count: variabile
- output node count: 2
- self loops: variabile
- override output nodes bias: true
I valori applicati nei campi variabili sono:
| bias | max output rewires | self loop | input node count | half variation |
|---|---|---|---|---|
| 0.1 | 0 | true | 24 | false |
| 0.5 | 1 | false | 8 | true with position feed |
| 0.79 | true without position feed |
Nota: con feed position si intende che durante l'inizializzazione del controller viene create una rete booleana con un nodo di input in più, questo servirà per comunicare alla rete se il robot si trovi o meno sulla regione di arena corretta. Dunque, il nodo di input in più viene collegato ad un sensore virtuale che determina ad ogni step se il robot è nella regione corretta.
Ad ogni configurazione base viene applicata una combinazione di variazioni con un totale di possibili configurazioni.
Un esempio d'istanza di configurazione in formato JSON è la seguente:
{
"simulation":{
"ticks_per_seconds":10,
"experiment_length":7200,
"network_test_steps":400,
"print_analytics":true
},
"robot":{
"proximity_threshold":0.1,
"max_wheel_speed":5,
"stay_on_half":false,
"feed_position":false
},
"bn":{
"max_input_rewires":2,
"input_rewires_probability":1,
"max_output_rewires":0,
"output_rewires_probability":1,
"use_dual_encoding":false,
"options":{
"node_count":100,
"nodes_input_count":3,
"bias":0.1,
"network_inputs_count":8,
"network_outputs_count":2,
"self_loops":false,
"override_output_nodes_bias":true
}
}
}Per il lancio delle simulazioni, la raccolta e analisi dei dati è stato sviluppato un progetto parallelo in linguaggio Scala. Il progetto è nella cartella analyzer e contiene tre sezioni eseguibili. La sezione che si occupa del lancio delle simulazioni è denominata Experiments.
Per ogni configurazione distinta vengono lanciate 100 simulazioni al fine di ottenere risultati statisticamente validi.
Per ognuna delle 7200 configurazioni (72*100) è necessario avviare una relativa simulazione. Una determinata configurazione viene passata alla simulazione attraverso una fase di preprocessing del file di simulazione .argos. La configurazione stessa viene passata al controller di ogni robot in formato JSON sfruttando il tag params all'interno del tag lua_controller nel file .argos. Nel file lua/config_simulation.argos è possibile notare che in alcuni punti sono presenti dei placeholder che verranno sostituiti in fase di preprocessing con i valori della configurazione. Questo permette di definire un singolo file di simulazione .argos che muta in base ai parametri definiti. Ugualmente per il controller la configurazione giungerà in formato JSON e ne varierà il funzionamento.
Ogni simulazione genera in standard output un flusso d'informazioni derivanti dai robot. Come accennato in precedenza ogni robot ad ogni step stampa in standard output un blocco di dati relativo a sé stesso. All'inizio di ogni test il robot genera le seguenti informazioni in formato JSON:
- id del robot
"id" - step attuale
"step" - fitness attuale
"fitness" - informazioni sulla configurazione della rete booleana
"boolean_network"- matrice di boolean che determina le funzioni booleane dei nodi
"functions" - matrice di indici che determinano le connesioni tra i nodi
"connections" - indici dei nodi di input
"inputs" - indici dei nodi di output
"outputs "
- matrice di boolean che determina le funzioni booleane dei nodi
- array di boolean indicanti lo stato dei nodi della rete booleana
"states" - array di due valore double che indicano la posizione del robot nell'arena
"position"
Per esempio:
{
"step":0,
"fitness":0,
"id":"fb0",
"states":[true,...,true],
"boolean_network":{
"outputs":[71,84],
"overridden_output_functions":[
[true,true,false,false,true,true,false,false],
[true,false,false,false,true,true,true,false]],
"functions":[
[false,false,true,false,false,false,false,false],
...
...
[false,false,false,true,false,false,false,false]
],
"connections":[
[70,34,38],
...
...
[45,88,19]
],
"inputs":[76,11,30,38,2,21,56,1]
},
"position":[1.27648,0.29925]
}Ad ogni step il robot genera le stesse informazioni sopra citate omettendo il campo "boolean_network" siccome rimane invariato, per esempio:
{
"states":[false,...,false],
"id":"fb5",
"fitness":0.1274,
"position":[-0.3812343555514,0.91377662004311],
"step":22478
}Ogni JSON è compattato in una singola riga e stampato in standard output. Ad ogni step dunque vengono stampati n JSON in n righe dove n è il numero di robot presenti nella simulazione. Un'intera simulazione dunque genera un totale di 7200 (lunghezza esperimento) * 10 (tick/second) * 10 (numero di robot) = 720000 record JSON.
Salvando l'output derivante dalla simulazione si ottiene un file composto da alcune stampe iniziali della simulazione argos seguite da una lunga serie di record JSON suddivisi per righe. L'esecuzione di Experiments salva questi flussi output su file denominati sulla base della configurazione lanciata. Inoltre, la configurazione stessa viene serializzata in formato JSON ed aggiunta al file come prima riga. Il file viene compresso con il tool gzip per risparmiare una notevole quantità di spazio. Lo schema di un file generato da una simulazione è dunque:
{configurazione in formato JSON}
alcune stampe argos
...
{record JSON robot 1 step 1}
{record JSON robot 2 step 1}
{record JSON robot 3 step 1}
...
{record JSON robot 1 step 1000}
{record JSON robot 2 step 1000}
{record JSON robot 3 step 1000}
...
Una volta che le simulazioni sono terminate si ottiene un insieme di file in formato gzip salvati su disco. In questa fase vengono estratte una serie d'informazioni contenute in strutture di alto livello per facilitare l'analisi dei dati raccolti. L'estrazione di queste strutture dati di alto livello richiede molto tempo e per questo si è deciso di introdurre una fase intermedia dove tali strutture vengono estrapolate e salvate in formato JSON su un file provvisorio. In questo modo è possibile analizzare i dati prodotti dalle simulazioni in modo molto più efficiente.
La sezione del progetto che si occupa di questa fase è denominata Loader. Se messo in esecuzione esso elabora per ogni file di simulazione gzip un file JSON contenente una struttura di questo tipo:
- Per ogni robot viene generato un record con i seguenti campi:
- id del robot
robot_id - filename del percorso del file da cui sono stati estratti i dati
filename - la configurazione della simulazione
config - per ogni test il valore finale della fitness
fitness_values - la miglior rete booleana del robot durante l'esperimento
best_bn
- id del robot
- I record sono messi in un struttura ad array, uno per ciascun robot, ad esempio:
[ { "robot_id": "fb1", "filename": "/data/el=7200-rc=10-bs=0.1-mir=2-mor=0-sl=false-nic=24-hv=false-fp=false-97.json", "config": { "simulation": { "ticks_per_seconds": 10, ... }, ...} "fitness_values": [0, 2.34, 0, ..., 1.23], "best_bn": { "functions": [[...], ..., [...]], "connections": [...], "inputs": [...], "outputs": [...] } }, { "robot_id": "fb2", ... } ... ]
Al termine della fase di loading è possibile andare a generare alcuni grafici attraverso la sezione Analyzer. Questo eseguibile utilizzerà le strutture di alto livello generate dal loader.
Questa struttura Experiments -> Loader -> Analyzer ha permesso di lavorare in una modalità molto più agile, in quanto un cambiamento di qualsiasi natura nel loader o nell'analyzer non implica una riesecuzione delle simulazioni. Inoltre, si possiedono salvati su disco tutti i dati grezzi generati dalle simulazioni e ciò può tornare molto utile in una fase di review / debugging.
In un calcolatore moderno Experiments impiega circa una settimana per terminare, il Loader impiega ore e l'Analyzer secondi. Questi ordini di grandezza giustificano anche la suddivisione del progetto in tre sottosezioni.
In questo capitolo vengono mostrati i risultati raccolti e li si analizzano al fine di soddisfare l'obiettivo del progetto.
Di seguito vi è riproposta la tabella dei parametri testati:
| bias | max output rewires | self loop | input node count | half variation |
|---|---|---|---|---|
| 0.1 | 0 | true | 24 | false |
| 0.5 | 1 | false | 8 | true with feed |
| 0.79 | true without feed |
Si analizzano i risultati usando principalmente due tipi di grafici: un boxplot contenente la miglior fitness raggiunta da ogni robot in una simulazione, e un grafico della curva di fitness media. Quest'ultima viene calcolata usando la sua curva di fitness di ogni robot per poi farne una media; la curva di fitness è il valore massimo della fitness che un robot è riuscito a raggiungere fino al test in questione, dunque è una curva sempre crescente.
Per prima cosa si analizzano i risultati raggruppandoli sulle singole variazioni che si sono applicate alla configurazione. Dunque, per ogni parametro vengono raggruppate le 7200 simulazioni per un singolo parametro e poi elaborate le due misurazioni.
Il primo parametro preso in esame è il bias. Come si può notare dai grafici sottostanti le reti ordinate (bias 0.1) sono quelle che mediamente ottengono peggiori prestazioni e che migliorano con più lentezza. Le reti caotiche, invece, (bias 0.5) ottengono modeste prestazioni medie, avendo anche il miglioramento più veloce nell'arco dei primi 30 test. Le reti critiche (bias 0.79) sono quelle che ottengono prestazioni nella media migliori e che con una simulazione più lunga probabilmente porterebbero a risultati finali migliori.
Dal boxplot si determina che alcune singole prestazioni molto performanti sono ottenute anche da robot con reti ordinate e caotiche, mentre nella media le reti critiche offrono sempre una miglior prestazione. Ciò tuttavia non esclude che con una simulazione molto più lunga le reti caotiche ed ordinate raggiungano prima il loro limite, mentre quelle critiche potrebbero raggiungere livelli ben più elevati di fitness per via della loro natura.
 |
 |
Questi risultati sono in linea con le aspettative viste le proprietà offerte da un sistema complesso in uno stato critico. In questo caso il sistema complesso è la rete booleana del robot, e ci si aspettava che nel raggiungere il proprio obiettivo il robot si avalesse di questo vantaggio. Questo risultato è un'ulteriore supporto alla congettura "i sistemi viventi sono complessi".
La variazione di almeno un nodo di output alla fine di ogni test porta a grandi benefici in termini di prestazioni ottenute. I seguenti grafici mostrato i risultati nel caso in cui non si effettui mai un cambiamento ai nodi di output e il caso in cui ad ogni test si cambi (rewires) un nodo di output.
Il boxplot mostra che mediamente fare rewires dei nodi di output porta a migliori prestazioni. Tuttavia, ciò non ha escluso ad alcuni robot con output_rewires=0 di raggiungere elevate prestazioni. Ciò è probabilmente dovuto dal fatto che tali robot sono stati inizializzati con di nodi di output già validi.
 |
 |
Questo risultato rientra nelle aspettative in quanto variando anche i nodi di output il controller ha molte più configurazioni possibili da esplorare, e nel caso in cui si ritrovi inizializzato a nodi di output inefficaci questi non saranno vincolanti fino al termine della simulazione.
Come mostrato dai seguenti grafici il numero di nodi di input da utilizzare influenza la prestazione e la rapidità con cui la si ottiene in maniera notevole. Ciò rientra nelle aspettative in quanto usare 24 nodi su 100 per l'input implica che il 24% dei nodi debbano avere un effetto utile sui due nodi di output al fine di far muovere il robot nella maniera richiesta. Diminuendo il numero di nodi di input si rilassa questo vincolo, dichiarando che soltanto 8 nodi della rete dovranno avere (sulla base delle percezioni) un effetto utile sui nodi di output.
Inoltre, diminuendo il numero di input a 8 aumenta la possibilità di individuare nodi che avranno un buon effetto sui due nodi di output. Questo perché diminuisce lo spazio di combinazioni di configurazioni da esplorare () e ciò garantisce una più veloce convergenza alla miglior fitness ottenibile con la rete a disposizione. I 24 sensori di prossimità in questo caso vengono raggruppati di 3 in 3.
 |
 |
Da tenere in considerazione che sia con 8 che con 24 nodi di input il massimo numero di input rewires ad ogni test è fissato a 2. Se si mantenesse proporzionale il numero di rewires al numero di nodi forse la differenza di prestazioni non si noterebbe o i risultati sarebbero differenti.
Dai seguenti risultati non è possibile determinare se il parametro self_loops abbia qualche influenza sulle prestazioni raggiunte.
 |
 |
Tuttavia, dal test di Wilcoxon sui valori del boxplot si evince che p-value = 0.005864 dunque il piccolo gap tra i risultati è frutto dell'effetto che ha il self-loops e non è una variazione casuale. Da questo si conclude che mediamente è meglio, in termini di fitness, avere dei self-loops all'interno della rete booleana.
Dai seguenti grafici è possibile notare come la variante della metà arena determini un peggioramento in termini di fitness ottenuta dei robot. Questo è un risultato aspettato in quanto in certi momenti i robot si trovano in zone dove la fitness è per definizione 0. Un fenomeno inaspettato è quello che le due varianti con e senza feed hanno prodotto il medesimo risultato in termini di fitness. Ci si aspettava che i controller che sapevano se si trovassero sulla metà corretta ottenessero miglior risultati rispetto ai controller che dovevano basarsi solo sul feedback del valore della fitness al termine del test.
Tuttavia, i risultati in entrambi i casi mostrano che i controller riescono ad utilizzare in qualche modo il feedback fornito dalla funzione di fitness. Se non fosse stato così i controller della variante "metà arena" avrebbero dovuto ottenere mediamente la metà della fitness ottenuta dalla variante "intera arena". I risultati invece mostrano che mediamente i robot si muovono in linea retta maggiormente nella metà corretta.
 |
 |
Effettuando il Wilcoxon test sui valori del boxplot nei due casi della variante della metà arena si determina che p-value = 0.02159 dunque è possibile scartare l'ipotesi nulla, concludendo che dare alla rete booleana l'informazione della regione su cui si trova (feed_position) permette un leggero miglioramento delle prestazioni.
Per completezza sono esposti i grafici delle singole configurazioni senza raggruppamenti di configurazioni diverse (ad eccezione del self-loop che viene comunque raggruppato). Sono stati suddivisi in tre categorie per il tipo di variante usata.
Nelle legende i termini significano:
- B: bias
- OR: numero di output rewires
- NIC: numero di nodi di input
| Variante | Curva di fitness media | Miglior fitness al termine |
|---|---|---|
| Intera arena |  |
 |
| Metà arena |  |
 |
| Metà arena - feed |  |
 |
Visivamente sono state rilanciate alcune simulazioni composte da 10 robot aventi la miglior rete booleana.
Da questa prova è stato riscontrato che nella variante "intera arena" (con bias=0.79) il miglior controller fa emergere una sorta di comportamento complessivo: tutti i robot finiscono per muoversi in senso orario intorno all'ostacolo al centro dell'arena. Questo comportamento fa sì che vi siano minori collisioni fra robot e quindi la fitness finale sarà complessivamente più elevata. Questo comportamento può essere categorizzato come cooperativo in quanto tutti i robot ne traggono beneficio. Il comportamento visivamente è il seguente:
Nella variante "metà arena" invece non è visibilmente emerso nessun comportamento complessivo.
Il comportamento cooperativo descritto nel primo caso probabilmente non è nato durante la simulazione originaria ma bensì soltanto durante la simulazione dove tutti i 10 robot hanno la stessa rete booleana. Infatti, è difficile che nasca una qualche sorta di interazione fra robot durante le simulazioni perché tutti i 10 robot non hanno modo di interagire se non attraverso la loro presenza / non presenza intorno ad altri robot. Inoltre, i robot all'interno di una simulazione sono caratterizzati da reti booleane dello stesso tipo ma di istanza totalmente diversa, causando comportamenti totalmente differenti e ciò sfavorisce ulteriormente la nascita di comportamenti cooperativi.
I parametri testati che fanno raggiungere fitness più elevate ai robot in tempi più brevi sono complessivamente: bias: 0.79, output rewires: 1, nodi di input: 8. Mentre è meno chiaro l'effetto dei parametri self-loops e feed-position: entrambi sembrano avere un leggero effetto positivo sulla fitness. Riguardo al parametro feed-position in particolare ci si aspettava un deciso incremento delle prestazioni rispetto al caso contrario, ma ciò non è avvenuto. In generale i risultati sono serviti per confermare delle ipotesi iniziali come il fatto che le reti booleane critiche offrano migliori possibilità di adattamento rispetto a quelle caotiche e ordinate.
Non sono emersi comportamenti cooperativi o competitivi particolari a meno di scegliere il controller che ha ottenuto miglior fitness e copiarlo su tutti i robot in una nuova simulazione.
Sarebbe interessante provare ulteriori varianti partendo dai parametri più efficaci che si sono individuati per determinare se con una rete così piccola si riescano a raggiungere prestazioni più elevate. Inoltre, sarebbe interessante prolungare la durata di una simulazione per determinare quale sia il limite massimo di fitness raggiungibile. Si potrebbe inoltre variare la composizione della rete booleana incrementando il numero di nodi.
Sarebbe interessante introdurre una forma di interazione esplicita fra i robot come ad esempio il range and bearing per scoprire se i robot si adattassero utilizzando anche la comunicazione in modo utile.
Si potrebbe variare il task, l'arena o il robot per determinare come la stessa configurazione si riesca ad adattare in ambienti differenti.
I requisiti per eseguire nuovamente gli esperimenti sono:
- Argos3 (v3.0.0)
- eseuire
argos3 --versionper controllare la versione
- eseuire
- Il repository
git clone https://github.com/edobrb/progetto-irs.git - 16 GB di RAM liberi
- 160GB di spazio su disco
Nella cartella lua sono contenuti tutti i sorgenti necessari per le simulazioni eseguite con Argos: controller, rete booleana, descrizione dell'ambiente di simulazione e alcune utilità.
Nella cartella analyzer è contenuto un progetto Scala compilabile ed eseguibile attraverso lo strumento sbt. È necessario usare una CLI per lanciare il tool sbt o eventualmente è possibile utilizzare un IDE (consiglio IntelliJ).
Per prima cosa è necessario spostarsi all'interno del progetto analyzer.
Il progetto è suddiviso in tre sezioni principali:
- Experiments: questa sezione ha il compito di lanciare le simulazioni e salvarne gli output su disco. È necessario specificare la locazione della cartella di lavoro
lua, il file di simulazione da utilizzare (.argos), la cartella dove verranno salvati i dati raccolti e opzionalmente il grado di parallelismo che si vuole utilizzare (quante simulazioni lanciare simultaneamente).sbt "runMain Experiments ../lua config_simulation.argos /storage/data 8"
- Loader: una volta ottenuti i risultati dalla sezione Experiments è necessario elaborare i file per ricavarne una versione più compatta con soltato le informazioni d'interesse. Per ogni file generato da Experiments verrà creato un nuovo file in formato JSON con alcune informazioni estratte da esso. Questa fase permetterà di analizzare i risultati con molta più efficienza.
sbt "runMain Loader ../lua config_simulation.argos /storage/data 4"- per ogni grado di parallelismo servono circa 4 GB di memoria RAM
- Analyzer: una volta generati i file intermedi in formato JSON è possibile andare a generare i grafici sulla fitness attraverso questo eseguibile. Inoltre, è possibile modificare questa sezione per estrarre e visualizzare le informazioni di più interesse e/o lanciare i robot che hanno ottenuto più fitness per vederne visivamente il comportamento.
sbt "runMain Analyzer ../lua config_simulation.argos /storage/data"
- Settings: All'interno dell'oggetto Settings è possibile modificare la configurazione base delle simulazioni, le variazioni e il numero di ripetizioni.