Realizzazione di un controllore basato su piattaforma robotica Thymio 2.

1. Università degli Studi di Trieste
Corso di Laurea in “Ingegneria elettronica ed
informatica”
Tesi di laurea
REALIZZAZIONE DI UN CONTROLLORE
PER PIATTAFORMA ROBOTICA BASATO
SU RETE NEURALE
Laureando Relatore
Anwar Nazig prof. Eric Medvet
Anno accademico 2019/2020

2. Alla mia famiglia e ad Isabella

3. 3
Indice
Introduzione..........................................................................................................................4
1 Studio hardware e software della piattaforma robotica Thymio2
..........................................................................................................................................6
1.1 Hardware......................................................................................................................6
1.2 Software.....................................................................................................................12
1.3 Linguaggio..................................................................................................................14
2 Tecniche di implementazione del controllore................................................................19
2.1 Approccio centralizzato..............................................................................................19
2.2 Approccio distribuito .................................................................................................25
2.3 Approccio diretto .......................................................................................................27
3 Progettazione...................................................................................................................28
4 Realizzazione strato software del sistema di controllo..................................................41
5 Analisi e collaudo del controllore....................................................................................48
Conclusioni..........................................................................................................................56

4. 4
Introduzione
L’obiettivo della tesi è quello di realizzare uno strato software che esegua un controllore
basato su rete neurale per una piattaforma robotica.
L’architettura della rete neurale viene precedentemente fissata in funzione del numero di
sensori e dunque di ingressi del robot Thymio e dei due attuatori da pilotare per muovere il
robot mobile. Lo strato software andrà quindi a ricevere i valori di ingresso dai sensori e dai
pesi della rete neurale già precedentemente allenata in un ambiente simulato, a questo punto
la rete neurale calcola i valori di uscita opportunamente processati in modo tale che sia
possibile controllare i due motori a nostra disposizione.
La richiesta definisce che nella prima fase, i dati dei pesi vengano forniti manualmente
dall’utente all’interno del codice, ossia che sia necessario inserire una matrice dei pesi
relativi alla forza della connessione tra i neuroni nel codice.
In una seconda fase invece, attraverso una connessione wireless, bisogna inviare queste
informazioni dalla workstation al robot, dunque è richiesto lo sviluppo di un sottosistema
per la comunicazione wireless ed elaborazione dei dati, sia sul robot che sulla workstation.
Il software sviluppato verrà utilizzato dal laboratorio ERALLAB del Dipartimento di
Ingegneria e Architettura dell’Università degli studi di Trieste durante la fase di studio sul
divario tra il comportamento nella realtà simulata dei nostri agenti e in quella fisica.

5. 5
Quadro generale
Il controllore verrà realizzato per i robot Thymio 2 nel contesto di seguito illustrato.
Abbiamo a disposizione un’arena dove i nostri robot interagiscono con l’ambiente
circostante e tra di essi tramite i sensori e gli attuatori. Il laboratorio dispone di una
videocamera posta in posizione tale da osservare il progresso dell’esperimento e da tracciare
il comportamento dei singoli agenti, attraverso un marcatore posto su ognuno dei nostri
robot.
La videocamera invia i dati alla workstation che si occupa di memorizzare i dati
dell’esperimento e comunicare con i robot via wireless. L’esigenza è dunque quella di poter
eseguire un esperimento dall’inizio alla fine senza che sia necessario l’intervento
dell’operatore umano, in quanto la sperimentazione può richiedere lunghi tempi senza
interruzioni.
Il tirocinio si è concentrato in una prima fase sullo studio del robot Thymio e del suo
funzionamento, ossia l’analisi dei suoi componenti hardware e software al fine di
individuare le modalità possibili per lo sviluppo del controllore, tenendo conto delle
richieste sopra elencate. In una seconda fase è stato portato avanti concentrandosi sulla
ricerca delle metodologie per la progettazione del controllore. La terza fase si è invece
focalizzata sull’andare a realizzare un sistema di controllo software sul robot Thymio che,
dati i pesi delle connessioni della nostra rete neurale e i valori di ingresso dei sensori, generi
in uscita valori in grado di controllare gli attuatori del robot Thymio 2.

6. 6
PRIMO CAPITOLO
Studio hardware e software della piattaforma robotica
Thymio 2
1.1 Hardware
La piattaforma robotica utilizzata è Thymio 2, un piccolo robot open source programmato
utilizzando il linguaggio di programmazione C, progettato per l’uso didattico e dotato di
una moltitudine di sensori e attuatori. Il dispositivo non offre la possibilità di definire i suoi
comportamenti direttamente con linguaggi di programmazione ad alto livello, come ad
esempio Java, Python o C.
Il sistema robotico si può modellare in 4 sottosistemi: il sistema meccanico, di attuazione,
di misura e di controllo. La prima parte del tirocinio, come spiegato in precedenza, si è
focalizzata nell’individuare le caratteristiche dei sensori a disposizione, degli attuatori e
soprattutto nel capire come controllare tali sistemi. Dunque ci si è concentrati
prevalentemente sul quarto sistema.

7. 7
Sistema di attuatori
sistema di attuatori
Gli attuatori del Thymio sono molteplici e sono controllabili tramite semplici istruzioni
descritte in un linguaggio di scripting.
I principali attuatori oggetto del nostro studio sono i due motori di Thymio, posti uno a
destra e uno a sinistra del robot.
Attraverso le variabili motor.right.target e motor.left.target si è in grado di definire la
velocità alla quale le ruote rispettivamente di destra e di sinistra devono girare, il dominio
dei valori assunto dalle variabile è l’insieme degli interi appartenenti all’intervallo
[-500,500], dove 500 è associato ad una velocita di 20cm/s.
Le altre variabili disponibili per i nostri due motori sono motor.right.speed, motor.left.speed
che misurano la velocità della rotazione delle ruote e motor.right.pwm, motor.left.pwm che
rileva la velocità di rotazione, attraverso l’invio di un segnale digitale avente un certo Duty
Cycle.
Durante l’analisi del funzionamento dei motori si è osservato che anche se si imposta
motor.right.target = 500 e ci si aspetterebbe dunque un valore della variabile

8. 8
motor.right.speed = 500, generalmente questo non accade a causa della limitata precisione
dei sensori a nostra disposizione.
I valori che le nostre variabili assumono sono soggetti a piccole variazioni nell’ordine di
circa 20 rispetto al valore nominale. Per esempio definendo motor.right.target = 500 si
possono ottenere valori di motor.right.speed nell’intorno di 480 e 520.
Si tiene a precisare che anche se i valori possono essere controllati ad una velocità massima
di 20cm/s, è possibile che la variabile motor.right.speed possa assumere velocità superiori
a quelle del dominio di appartenenza, per esempio se il robot viene spinto con la mano.
Gli altri attuatori sono: una serie di led disposti nel robot ognuno relativo ad una specifica
funzione e un altoparlante se si ha la necessità di generare o utilizzare suoni.
Per ulteriori dettagli sul funzionamento e le caratteristiche di questi sensori si rimanda alla
documentazione ufficiale1.
1 http://wiki.thymio.org/en:thymioapi
Attuatori del robot Thymio

9. 9
Sistema dei sensori
I sensori del thymio sono molteplici, dotati di una discreta precisione per elementari
applicazioni e sono controllabili tramite semplici istruzioni di codice.
I principali sensori analizzati durante lo studio sono: i sensori di prossimità, di terra, di
accelerazione sui tre assi dello spazio ed infine la misura della velocità dei motori
precedentemente discussa.
I sensori di prossimità sono in grado di rilevare la presenza di oggetti nelle immediate
vicinanze. Thymio dispone di sensori di prossimità ottici per i quali il funzionamento si basa
sulla riflessione di un fascio luminoso da parte dell'entità rilevata.
Generalmente per i sensori ottici viene usato un fascio di raggi infrarossi, in quanto questo
tipo di radiazione è facilmente distinguibile dai disturbi generati da fonti luminose
ambientali.
Sensori del robot Thymio

10. 10
Nella figura sottostante si osserva quale sia il rapporto che intercorre tra la distanza in cm e
la risposta dei sensori di prossimità, la calibrazione2 è stata effettuata su un normale foglio
A4.
I sensori di prossimità sono disposti sia sulla parte anteriore sia su quella posteriore. In
particolare ve ne sono cinque davanti, tra di loro distanziati omogeneamente e due sul retro.
2 https://cyberbotics.com/doc/guide/thymio2#proximity-sensor-response-versus-distance
Sensori del robot Thymio

11. 11
I valori assunti dalle variabili relative ai sensori di prossimità sono memorizzati su un
vettore di dimensione sette, chiamato prox.horizontal dove l’i-esimo elemento corrisponde
ad uno specifico sensore. Partendo dalla posizione zero troviamo quello relativo alla parte
anteriore destra e così via fino al quarto elemento corrispondente al rilevatore di sinistra, ed
infine i due posteriori occupano la posizione 5 e 6 del nostro vettore.
I sensori di prossimità vengono aggiornati automaticamente alla frequenza di 10Hz,
l’intervallo dei valori è approssimativamente [0-5000] dove 0 indica che nessuno oggetto
viene rilevato e 5000 l’impatto del robot con un oggetto. Si osservi che il valore 5000 è un
limite teorico secondo ottenuto dalla lettura della documentazione ufficiale, ma nella realtà
risulta essere un valore irraggiungibile.
I sensori di ground hanno un comportamento simile a quelli di prossimità, Thymio ne ha a
disposizione due e sono posizionati nella zona inferiore anteriore come illustrato nella figura
sopra illustrata. Tali sensori emettono luce infrarossa e possono sfruttare la quantità di luce
riflessa per determinare la presenza oppure l’assenza del terreno.
In linea di massima, superfici nere assorbono quasi tutta la luce infrarossa. Supponiamo di
ottenere un valore di prox.ground.reflected = 0, allora siamo in presenza di una superficie
nera sulla quale sarà possibile che il robot si muova o meno in funzione del controllo che
applica il programmatore. Per esempio possiamo definire che in presenza di tale condizione,
sia comandato al robot di muoversi e posizionando un nastro sul terreno di colore nero si
vedrà Thymio seguirne la traiettoria.
Possiamo determinare anche l’intensità di luce presente nell’ambiente circostante con questi
sensori tramite la variabile prox.ground.ambient.

12. 12
L’ultima variabile analizzata è prox.ground.delta, che calcola la differenza tra la luce
riflessa e quella dell’ambiente. Durante lo studio si è osservato una maggiore convenienza
nell’utilizzare l’ultima variabile rispetto alle altre due e quindi durante la progettazione del
controllore in sede si ha una preferenza nel suo utilizzo.
L’accelerometro effettua il calcolo della forza rilevata rispetto alla massa di Thymio ed
opera sui tre assi cartesiani. I valori vengono memorizzati su un vettore di dimensione tre
chiamato acc e le misure in questo vettore appartengono all’intervallo [-32,32] dove il
numero 23 corrisponde ad un accelerazione pari a quella di gravità (1g). Si ha una frequenza
di aggiornamento dei pesi pari a 16Hz. Questo sensore è utile quindi a rilevare accelerazioni
improvvise oppure un impatto con un oggetto. Acc[0] rappresenta un accelerazione
sull’asse x, Acc[1] invece descrive l’asse y ed infine Acc[2] è relativa all’asse z.
1.2 Software
Thymio utilizza Aseba, un’architettura basata su eventi3, distribuita e modulare, si tratta di
una rete di calcolatori nei quali la comunicazione è asincrona. Tutti i nodi inviano eventi e
reagiscono a quelli ricevuti.
Un evento consiste in un identificatore e un pacchetto dati, ossia il Payload.
Spesso i nodi sono microcontrollori per i robot di piccole dimensioni; nel nostro caso,
invece, sono i robot Thymio stessi a fungere da nodi.
3
ASEBA: AModular Architecturefor Event-Based Control ofComplexRobots, St´ephaneMagnenat, Student Member,IEEE, Philippe
R´etornaz, Michael Bonani, Valentin Longchamp, Francesco Mondada, Member,IEEE.)

13. 13
Lo strato di comunicazione può essere un qualunque bus provvisto di una logica multi-
master. Nel robot Thymio viene impiegato il CAN BUS 4 anche se in aggiunta,
opzionalmente, il robot può al suo interno possedere un calcolatore centrale, tipicamente
con un sistema operativo Linux. Questo permette allo sviluppatore di utilizzare un ambiente
di sviluppo dal suo computer.
Il non sincronismo degli eventi permette ai microcontrollori di trasmettere i dati quando lo
desiderano. Un comportamento di base non richiede un’unità centrale di controllo per la
gestione della trasmissione delle informazioni. Proprio per questo un sensore, tipicamente,
emette un evento solamente quando riceve parti di informazioni rilevanti. Ad esempio, il
sensore di distanza potrebbe emettere un evento qualora un ostacolo si avvicini ad una certa
soglia e solo quando questa transazione avvenga.
La scelta di quale evento inviare dipende dal comportamento del robot, pertanto un robot
coinvolto nell’evitare gli ostacoli non ha la necessità di utilizzare gli eventi di un robot che
segue un oggetto. In Aseba la flessibilità è implementata separando il codice del
microcontrollore in due parti:
In primo luogo, la lettura di sensori, attuatori e lo strato di comunicazione sono implementat i
in codice nativo nel microcontrollore; su Thymio viene utilizzato il linguaggio C.
Secondariamente, le applicazioni specifiche del programma che controlla l’emissione di
eventi e le politiche di ricezione sono eseguite all’interno della macchina virtuale nei
microcontrollori. I programmi sono realizzati in un semplice linguaggio di Scripting che
permette allo sviluppatore di implementare comportamenti basati su eventi, lavorando su
4 https://it.wikipedia.org/wiki/Controller_Area_Network

14. 14
un livello di astrazione superiore e permettendo di non preoccuparsi della gestione della
memoria o di lavorare a basso livello.
1.3 Linguaggio
In Aseba descriviamo il comportamento e le politiche di invio e ricezione in un linguaggio
di Scripting. La ricezione di un evento provoca l’esecuzione di una parte precisa dello script.
L’associazione del codice con gli eventi permette al programmatore di liberarsi dalla
gestione dei momenti di esecuzione del codice.
Sintatticamente il linguaggio Aseba è somigliante a quello di MATLAB, semanticamente è
un semplice linguaggio imperativo con vettori di interi a 16 bit comprendenti il bit di segno
e gli interi sono l’unico tipo di dato permesso, questa caratteristica andrà a rilevarsi molto
vincolante per le nostre applicazioni durante la progettazione.
In addizione all’usuale condizione IF, Aseba dispone della condizione WHEN che risulta
essere vera quando il confronto della condizione è vero, questo permette dunque di avviare

15. 15
uno specifico comportamento in maniera ciclica fino a quando lo stato della condizione non
cambia.
Il linguaggio fornisce la possibilità di utilizzare le subroutine, che possono essere chiamate
da una qualunque porzione del codice, anche questa caratteristica risulta vincolante per i
nostri scopi in quanto non è previsto il concetto di funzione oppure di utilizzare funzioni
ricorsive.
Per effettuare calcoli più complessi come la manipolazione di un segnale, i microcontrollori
sono dotati di funzioni native implementate in linguaggio C oppure in Assembler. Le
funzioni native standard previste sono relative alle operazioni vettoriali e trigonometriche
di base.
Alcune caratteristiche principali e vincoli del linguaggio Aseba:
le costanti non possono essere dichiarate direttamente nel codice, ma devono essere
esplicitate attraverso l’utilizzo del pannello delle costanti nell’ambiente di sviluppo Aseba
Studio.
Gli eventi possono essere emessi dall’interno del nodo come per esempio dai sensori,
oppure possono essere esterni ossia inviati da un altro nodo Aseba.
Esempio di codice basato su eventi:
var run = 0
onevent start
run = 1
onevent stop
run = 0

16. 16
L’invio di eventi esterni avviene tramite la parola riservata emit, seguita dal nome
dell’evento e il nome della variabile da inviare. E’ necessario non dimenticarsi di tenere
conto della struttura dei dati e rispettarne le caratteristiche.
Di seguito si ha un esempio di codice per invio di eventi esterni.5
onevent ir_sensors
emit sensors_values proximity_sensors_values
Limiti importanti da tenere in considerazione:
 L’unico tipo di dato numerico ammesso è l’insieme degli interi dove si hanno a
disposizione solamente 16 bit con segno, in altre parole un range [-32768,32767].
 I vettori non possono avere come argomento variabili, ma solamente costanti, il
che limita di un certo grado la flessibilità dello sviluppo del controllore.
Var x = 10
Var vettore[x]
Questa sintassi non è valida;
 Non è previsto ilconcetto di funzione inteso come nei linguaggiadalto livello.Vige
infatti la necessità di utilizzare in alternativa le subroutine per aggirare il problema.
 Una divisione ha come risultato un arrotondamento per difetto e non per eccesso,
questo porta alla propagazione di un certo errore nelle operazioni matematiche.
5 http://wiki.thymio.org/en:asebalanguage

17. 17
 Le costanti non vengono dichiarate in linguaggio testuale ma attraverso l’ambiente
di sviluppo.
 Non sono previste matrici. Realizzeremo pertanto una matrice come insieme didue
o più vettori.
Esempio di codice Aseba per Thymio 2: Thymio segue un oggetto, ad esempio la mano.
# reset outputs
call sound.system(-1)
call leds.top(0,0,0)
call leds.bottom.left(0,0,0)
call leds.bottom.right(0,0,0)
call leds.circle(0,0,0,0,0,0,0,0)
onevent prox
when prox.horizontal[2] >= 2000 do
motor.left.target = 350
motor.right.target = 350
end
when prox.horizontal[0] >= 2000 do
motor.left.target = 0
motor.right.target = 500
end
when prox.horizontal[4] >= 2000 do
motor.left.target = 500

18. 18
motor.right.target = 0
end
when (prox.horizontal[0] <= 1000 and prox.horizontal[1] <=
1000 and prox.horizontal[2] <= 1000 and prox.horizontal[3] <=
1000 and prox.horizontal[4] <= 1000) do
motor.left.target = 0
motor.right.target = 0
end

19. 19
Secondo Capitolo
Tecniche di implementazione del controllore
2.1 Approccio centralizzato
Un primo approccio alla realizzazione del controllore è quello di sviluppare il controllore
in un linguaggio ad alto livello come, per esempio, il Python oppure C.
Questa metodologia richiede la realizzazione di un canale di comunicazione e della gestione
delle comunicazioni tra il linguaggio Python ed i nodi della rete Aseba.
Il canale fisico può essere il filo Usb in dotazione del robot Thymio oppure la
comunicazione può avvenire attraverso la rete wireless. Per i nostri scopi si privilegia una
comunicazione senza fili.
Il canale deve prevedere dei protocolli di comunicazione, difatti Aseba dispone della
possibilità di utilizzare un bus dati DBUS6 in aggiunta ad un utility a riga di comando
Asebamedulla7 che consente l’accesso ad una rete Aseba.
Medulla è un software hub che consente a qualunque software Linux di accedere agli eventi
e ai dati di un microcontrollore tramite D-BUS. Al momento il suddetto software è
supportato solamente sui sistemi operativi Linux.
Per controllare Thymio utilizzando il software Medulla è necessario in prima battuta andare
sulla console del sistema operativo Linux e digitare:
asebamedulla "ser:name=Thymio-II"
6 https://it.wikipedia.org/wiki/D-Bus
7 ASEBA Meets D-Bus: From the Depths of a Low-Level Event-Based Architecture into the Middleware
Realm Stephane Magnenat and Francesco Mondada

20. 20
La sintassi del comando è di seguito illustrata.
Per ottenere maggiori informazioni sul comando Asebamedulla si esegue il seguente
comando.
In questo modo abbiamo connesso Medulla al nostro robot. E’ da sottolineare che ciò
avviene come descritto solo nell’ipotesi che il nostro dispositivo Thymio sia identificato
con il nome Thymio-II.
Ora è possibile scrivere software in grado di inviare e ricevere comandi utilizzando la
libreria DBus. Il passo successivo, dunque, consiste nel creare il nostro controllore nel
linguaggio desiderato. Per esempio in Python una realizzazione di un controllore basato
sui veicoli di Braitenberg8 è la seguente:
import dbus
import dbus.mainloop.glib
import gobject
from optparse import OptionParser
8 https://en.wikipedia.org/wiki/Braitenberg_vehicle

21. 21
proxSensorsVal=[0,0,0,0,0]
def Braitenberg():
#get the values of the sensors
network.GetVariable("thymio-II",
"prox.horizontal",reply_handler=get_variables_reply,error_ha
ndler=get_variables_error)
#print the proximity sensors value in the terminal
Print(proxSensorsVal[0],proxSensorsVal[1],proxSensorsVal[2],
proxSensorsVal[3],proxSensorsVal[4])
#Parameters of the Braitenberg, to give weight to each wheels
leftWheel=[-0.01,-0.005,-0.0001,0.006,0.015]
rightWheel=[0.012,+0.007,-0.0002,-0.0055,-0.011]
#Braitenberg algorithm
totalLeft=0
totalRight=0
for i in range(5):
totalLeft=totalLeft+(proxSensorsVal[i]*leftWheel[i])
totalRight=totalRight+(proxSensorsVal[i]*rightWheel[i])

22. 22
#add a constant speed to each wheels so the robot moves always
forward
totalRight=totalRight+50
totalLeft=totalLeft+50
#print in terminal the values that is sent to each motor
print "totalLeft"
print totalLeft
print "totalRight"
print totalRight
#send motor value to the robot
network.SetVariable("thymio-II","motor.left.target",
[totalLeft])
network.SetVariable("thymio-II","motor.right.target",
[totalRight])
return True
def get_variables_reply(r):
global proxSensorsVal
proxSensorsVal=r
def get_variables_error(e):
print 'error:'
print str(e)
loop.quit()

23. 23
if __name__ == '__main__':
parser = OptionParser()
parser.add_option("-s", "--system", action="store_true",
dest="system", default=False,help="use the system bus instead
of the session bus")
(options, args) = parser.parse_args()
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
if options.system:
bus = dbus.SystemBus()
else:
bus = dbus.SessionBus()
#Create Aseba network
network =
dbus.Interface(bus.get_object('ch.epfl.mobots.Aseba','/'),
dbus_interface='ch.epfl.mobots.AsebaNetwork')
#print in the terminal the name of each Aseba NOde
print network.GetNodesList()
#GObject loop
print 'starting loop'
loop = gobject.MainLoop()
#call the callback of Braitenberg algorithm

24. 24
handle = gobject.timeout_add (100, Braitenberg) #every 0.1
sec
loop.run()
Gli elementi di maggiore importanza in questo esempio, che permettono il controllo del
nostro dispositivo attraverso il linguaggio Python, sono di seguito elencati e descritti.
Import dbus: importa la libreria per la comunicazione tra la nostra applicazione e il
robot Thymio.
le applicazioni che utilizzano il D-bus si connettono al demone del bus, che inoltra i
messaggi tra le applicazioni. Per utilizzare il D-bus bisogna creare un oggetto Bus che
rappresenti la connessione al demone9 del bus.
bus = dbus.SessionBus(): crea una connessione al demone del bus e genera una
sessione.
network = dbus.Interface(bus.get_object('ch.epfl.mobots.Aseba',
'/'), dbus_interface= 'ch.epfl.mobots.AsebaNetwork'): crea una rete di
nodi Aseba.
network.GetVariable("thymio-II", "prox.horizontal"): dalla rete di
nodi ottiene i valori dei sensori di prossimità orizzontali.
Il vantaggio principale di questo primo metodo è l’utilizzo di linguaggi di programmazione
sia ad alto livello che a basso livello, ossia sviluppo di un controllore con ampi gradi di
libertà e ricchezza di funzionalità offerte dai linguaggi.
9 https://it.wikipedia.org/wiki/Demone_(informatica)

25. 25
Uno svantaggio invece è rappresentato dall’utilizzo di un’unità centrale che elabori i dati
in ingresso e si occupi dell’invio dei dati in uscita. Si avranno dunque dei tempi di invio e
ricezione dei dati non in tempo reale.
Oltre allo svantaggio descritto uno dei requisiti del tirocinio e della tesi è che l’elaborazione
dei dati avvenga su ogni singolo robot indipendentemente dalla workstation.
2.2 approccio distribuito
Un secondo approccio è simile al primo metodo ma con l’aggiunta della separazione
dell’esecuzione del controllore da un'unica unità centrale in modo da provvedere alla
risoluzione del problema generato dal primo metodo.
Ci si chiede ora come si possa realizzare tale soluzione. L’idea di base consiste nell’aggiunta
di un modulo Hardware su ogni singolo dispositivo robotico Thymio.
Ogni robot viene connesso tramite cavo Usb in dotazione a un dispositivo Raspberry oppure
Arduino (si precisa che un supporto su Arduino ancora non è stato realizzato) ed
alimentando il modulo con una batteria. In questo modo possiamo controllare Thymio
semplicemente attraverso il Raspberry, che acquisisce i valori di ingresso dei sensori e che
attraverso il controllore basato su una rete neurale calcola i valori di uscita dei motori del
robot.

26. 26
Fotografia del thymio con modulo Raspberry PI 4
Successivamente all’aggiunta della nostra unità si procede come è stato illustrato nel primo
approccio, ossia si esegue l’istruzione:
asebamedulla "ser:device=/dev/ttyACM0"
supposto che il dispositivo Thymio sia identificato da /dev/ttyACM0".
In conclusione, il vantaggio principale che si ottiene è quello di rendere indipendente il
controllo da un unità di elaborazione centrale, ma uno svantaggio sorge immediatamente,
non di tipo tecnico ma a livello di costi, in quanto sono necessari tanti moduli e batterie
quanti sono i robot Thymio da controllare, il che porta a costi eccessivi salendo di numero
unità in uso.
Anche per soli 5 robot i costi di realizzazione iniziano ad avere un certo peso economico.
Il costo di un modulo Raspberry pi 4 dotato di 4GB di Ram è di circa 110 euro, la batteria
invece ha un costo che si aggira tra i 15 e i 30 euro, in conclusione per 5 moduli la spesa
totale diventa all’incirca 700 euro.

27. 27
2.3 Approccio diretto
Il terzo approccio consiste nell’utilizzare il linguaggio di Scripting di Aseba e sviluppare il
controllore attraverso approssimazioni e ovviando ai limiti imposti dal linguaggio.
La parte di progettazione e di realizzazione del controllore è oggetto esclusivo della parte
di tesi triennale del candidato, che avviene in concomitanza con il tirocinio.
I passaggi fondamentali della terza fase sono riassunti di seguito:
 Normalizzazione dei dati di ingresso.
 Creazione di un’architettura di rete neurale Feedforward (che viene
precedentemente concordata).
 Implementazione attraverso dovute approssimazioni della funzione di uscita del
singolo percettrone.
 Normalizzazione dei valori di uscita per pilotare i motori.
I vantaggi di tale approccio sono l’assenza di costi aggiuntivi per lo sviluppo e l’esecuzione
diretta del controllore sul robot Thymio senza i ritardi di comunicazione con dispositivi
esterni. Lo svantaggio invece è dovuto ai limiti imposti dal linguaggio a disposizioni e la
moltitudine di approssimazioni che generano inevitabilmente una propagazione dell’errore
sui nostri valori rispetto a quelli attesi.

28. 28
TERZO CAPITOLO
Progettazione
Schema architettura della rete neurale
l’architettura della rete neurale per il robot Thymio è costituita da uno strato di ingresso
W, uno strato nascosto H, contenente un numero di neuroni pari al 65% del numero degli
ingressi ed infine uno strato di uscità Y.
Lo strato di ingresso è realizzato tramite un vettore di valori ottenuti dai sensori
opportunamente selezionati per il robot Thymio. Il primo gruppo di sensori utlizzati sono
quelli di prossimità, ossia cinque rilevatori sulla parte anteriore e due sul posteriore; i primi
dati sono memorizzati nel vettore horizontalSensor[], i valori dei due sensori di terra invece
sono immagazzinati nel vettore deltaSensor[]. Importanti sono anche i sensori di

29. 29
accelerazione identificati dalla variabili vettoriale accSensor[], ed infine utilizziamo i
sensori che stabiliscono la velocità dei motori, rappresentati da motorSpeed[].
Si precisa che la scelta di quali sensori utilizzare come ingressi della nostra rete neurale è
definita nelle prime fasi della progettazione in maniera arbitraria, ed è stabilita dai
comportamenti che si vuole ottenere o studiare.
Lo strato di ingresso ha come vincolo di progetto di possedere un numero massimo di 16
neuroni.
Il linguaggio Aseba consente di utilizzare variabili intere nell’intervallo di valori [-32768 :
32767], tenendo conto di questo vincolo, si è deciso di far sì che il singolo percettrone di
ingresso possa assumere un valore intero dell’intervallo [0:128], di conseguenza i pesi della
rete neurale sono limitati al dominio dei valori [-16,16].
Dunque il massimo valore teorico assumibile dai percettroni dello strato nascosto della rete
neurale, durante il calcolo della combinazione lineare è pari al prodotto 128 ∙ 16 ∙ 16 =
32768; si osserva che tale valore supera il limite superiore imposto dal vincolo di progetto.
Dato che 32768 è una cifra puramente teorica, la quale non può avere alcun riscontro nella
realtà, si è comunque deciso di operare con gli intervalli precedentemente stabiliti.
Infatti il valore 32768 è praticamente irraggiungibile, in quanto sarebbe necessario che ogni
sensore assuma un valore pari al suo limite superiore, tale evento è irrealizzabile a causa
della natura dei nostri rilevatori.
Alcuni sensori del Thymio non si avvicinano mai al massimo valore assumibile anche in
condizioni nelle quali ci si aspetta che tali valori vengano assunti.

30. 30
Si precisa che durante la realizzazione del controllore si è tenuto conto di solamente 14
sensori, questa scelta è giustificata dal fatto di volere ottenere in fase di collaudo del
controllore un comportamento semplice, come quello di evitare gli ostacoli durante la
marcia.
Lo strato intermedio ossia quello nascosto “H” prevede l’utilizzo di un numero di neuroni
pari al 65% del numero di neuroni di ingresso, con arrotondamenti per eccesso.
In definitiva sono ammessi un numero di neuroni massimo di undici neuroni intermedi,
mentre in questa tesi si va ad utilizzare un numero pari a dieci, in quanto i nodi di ingresso
sono pari a quattordici.
I valori calcolati dai percettroni dello stato intermedio prima di essere utilizzati dallo strato
successivo, vengono normalizzati secondo una certa logica che verrà in seguito.
Lo Strato di uscita contiene 2 neuroni, che rappresentano i valori di controllo dei nostri
attuatori, valori che verranno rappresentati nel nostro codice tramite il vettore motor[].
Si tiene a precisare che il numero dei neuroni di uscita è facilmente modificabile nei limiti
dei vincoli già elencati nei capitolo precedenti. Per esempio se si desidera avere un certo
comportamento logico dei led del robot, basterebbe l’aggiunta di un ciclo nella subroutine
compute_output.
In questa sede si è stabilito di affrontare la realizzazione dello strato software secondo 2
criteri qualitativi: in primo luogo, il codice deve essere scritto in maniera più semplice
possibile per la lettura, secondariamente, il codice deve essere facilmente modificabile ed
adattabile a seconda delle esigenze.

31. 31
Si è ritenuto che questi due criteri siano primari rispetto al proposito di realizzare un codice
con la massima efficienza di esecuzione possibile.
Schema normalizzazione dei valori di ingresso .
I valori di ingresso del vettore V sono generalmente compresi tra -500 e 5000, più sì ha che
il dominio dei sensori di prossimità sono compresi nell’intorno [0 : 5000], i valori dei due
sensori di Ground tra [0 : 1024], mentre quelli di accelerazione appartengono all’intervallo
compreso [32 : 32], ed infine i valori dei sensori di velocità dei due motori operano in un
intervallo [-500 : 500].
Il nostro vettore V necessità che l’insieme dei suoi elementi siano normalizzati, come si
osserva dalla figura soprastante, affinché si ottenga un vettore di valori appartenenti
all’intervallo [0,128]. I valori normalizzati vengono memorizzati nel nuovo vettore W,
rappresentato nel nostro codice tramite sensorsNormalized [].

32. 32
Schema semplificato sul calcolo della prima variabile di uscita
Nei neuroni dello strato intermedio, lo strato software calcola il prodotto scalare tra il
vettore di ingresso normalizzato W e il vettore dei pesi P rappresentanti la forza della
singola connessione con il neurone dello strato nascosto. Questa operazione avviene per
ogni singolo neurone dello strato intermedio.
Il risultato della combinazione lineare prevede un massimo valore di 32767, il calcolo è
fatto con l’ipotesi implicita che il valore del Bias sia nullo, mentre se è diverso da zero
allora ne va tenuto conto e dunque fare le dovute modifiche allo schema dell’architettura
della rete neurale e della parte di codice che stabilisce il risultato della sommatoria.
Il valore della somma algebrica entra successivamente nel blocco chiamato funzione di
attivazione che ha come dominio valori da -32768 a 32767, a questo punto in base alla
funzione di attivazione implementata si avrà un codominio specifico.

33. 33
In questa tesi si utilizza la tangente iperbolica, che viene inizialmente approssimata e
successivamente adattata attraverso una dilatazione della funzione, in quanto nel
linguaggio Aseba la tangente iperbolica non appartiene all’insieme delle funzioni native
previste e l’impossibilita di utilizzare i numeri decimali ma solamente interi vincolati
all’intervallo precedentemente discusso nella tesi.
I valori d’uscita per la tangente iperbolica appartengono a [-8192,8192].
Blocco di Normalizzazione di ingresso
Esempio di normalizzazione di ingresso. V è il vettore di ingresso, W è il vettore di ingresso Normalizzato.
Nel blocco di normalizzazione di ingresso idealmente si andrebbe a calcolare i valori del
vettore di ingresso normalizzato mediante la seguente formula: Wi = 128
Vi−Vmini
Vmaxi
−Vmini
Piu precisamente sia dato il vettore degli ingressi

34. 34
𝑉 = (V1,V2, …, V𝑛),
Siano inoltre dati rispettivamente i vettori di minimo e di massimo della la nostra rete
neurale, relativi ai singoli sensori considerati e definiti come:
Vmin = (Vmin1
, Vmin2
, …, Vmin 𝑛
),
Vmax = (Vmax1
, Vmax2
, …, Vmax 𝑛
),
Si definisce il vettore di ingresso normalizzato W, il vettore ottenuto normalizzando gli
ingressi di V come:
W = (V1, V2, …, V𝑛)
Tale che
Wi = 128
Vi − Vmini
Vmaxi
− Vmini
Si tiene a precisare che i valori che possono assumere i sensori del Thymio sono soggetti
a disturbi e può darsi talvolta i valori siano superiori o inferiori ai limiti teorici previsti,
difatti si andrà a tenere conto di questi eccessi, attraverso un controllo condizionale.
Ossia se i valori sono minori dell’estremo inferiore previsto per il singolo sensore, si andrà
a forzare il sensore a rilevare un pari al valore minimo teorico previsto e viceversa se i
valori sono superiori al limite superiore si andrà ad imporre alla variabile il massimo
previsto.
Ad esempio se il nostro Thymio durante la marcia rileva una velocità di marcia pari a 520,
il valore che andrà ad essere normalizzato è 500 che rappresenta la massima velocità di
rotazione dei motori.

35. 35
Blocco funzione di attivazione.
Ogni funzione di attivazione implementata è soggetta a qualche forma di adattamento e di
approssimazione a causa dei vincoli limitanti del nostro linguaggio. Di seguito si andrà a
vedere la logica attraverso la quale in questa tesi si approssima la funzione tangente
iperbolica.
La tangente Iperbolica è una funzione avente come dominio tutti i valori della retta reale
e come codominio, valori compresi tra meno uno ed uno come nella figura sottostante.
Tangente iperbolica.
In prima battuta si cerca una trasformazione espressa tramite una funzione razionale, che
abbia un andamento simile alla tangente iperbolica nell’intervallo [-4,4], ossia una
funzione in grado di approssimare la tanh(x).
Questo requisito è realizzabile tramite la relazione biunivoca :
y =
27x + x3
27 + 9x2

36. 36
Funzione che approssima la tangente iperbolica.
Si osservi che la funzione approssimazione per x che tende all’infinito, questa non sia
limitata ma tenda ad infinito al contrario della tangente iperbolica. Un altro punto da tenere
conto è che le 2 funzioni sono circa identiche al valore intero x uguale a quattro, per poi
successivamente, la differenza tra le due funzioni tende a divergere.
lim
x→+∞
27x + x3
27 + 9x2
= +∞
lim
x→+∞
tanh(𝑥) = 1
A questo punto si procede con una dilatazione della funzione ottenuta.
Ossia sapendo che il massimo risultato ottenibile dalla combinazione lineare è 32767 e
che il numero uno per la tangente iperbolica si ottiene per x uguale a quattro, allora sì
imposta come coefficiente di dilatazione Il rapporto 𝑐 =
32767
4
≅ 8192.
La cifra come risultato del rapporto rappresenta il massimo valore della nostra funzione
approssimata ed elaborata, ossia al valore 32767 corrisponde la costante c. lo stesso
discorso vale per la parte negativa della funzione. In conclusione si definisce la nuova
applicazione che approssima la nostra tangente iperbolica opportunamente approssimata
come:

37. 37
𝑦 =
27
𝑥
𝑐
+ (
𝑥
𝑐
)3
27 + 9(
𝑥
𝑐
)2
≈ 𝑐𝑡𝑎𝑛ℎ(
𝑥
𝑐
)
Approssimazione della tangente iperbolica soggetta ad adattamento.

38. 38
Blocco di Normalizzazione intermedio
Schema sulla normalizzazione dello strati di uscita.
Nel blocco di normalizzazione intermedio si vuole andare mappare ogni valore uscente
dai neuroni dello strato nascosto appartenente a [-8192,8192] ad un valore del intervallo
compreso tra -128 e 128, in quanto siamo sempre difronte ai vincoli di progetto
inizialmente discussi.
La scelta in sede di normalizzare su questo intervallo è standard per tutti neuroni dello
strato nascosto e i successivi strati, affinché si possa mantenere una certa omogeneità nella
rete neurale. La normalizzazione può essere scelta anche in maniera arbitraria, però
necessita di ulteriori studi sulle sue conseguenze e di fare attenzioni ai vincoli software
ogni volta che si va a ridefinire l’architettura della rete neurale. Dunque è preferibile

39. 39
mantenere queste impostazioni per evitare errori non previsti durante l’esecuzione del
programma.
La formula utilizzata per la normalizzazione è: 𝑂𝑖𝑛 =
𝑂𝑖𝑛
64
Si tiene a precisare che nello schema della figura sopra, troviamo scritto 𝑂𝑖 = 𝑐 𝑡𝑎𝑛ℎ(
𝑆𝑖
𝑐
),
mentre nella partica si utilizza la formula approssimativa 𝑂𝑖 =
27
𝑆 𝑖
𝑐 +(
𝑆 𝑖
𝑐 )
3
27+9(
𝑆 𝑖
𝑐 )
2 .
Blocco di Normalizzazione di uscita:
Schema sulla normalizzazione di uscita
L’esigenza di avere una normalizzazione di uscita è dettata dal fatto che i motori del
Thymio, possono essere controllati con valori compresi tra -500 e 500, mentre i valori

40. 40
derivanti dai neuroni di uscita sono compresi in un intervallo più ampio di quello
necessario [-8192,8192].
La formula di risoluzione è:
𝑈𝑖𝑛 =
500∗𝑈𝑖
8192
Schema finale.

41. 41
CAPITOLO QUARTO
Realizzazione dello strato software del sistema di controllo
Nel seguente capitolo si andrà a discutere e spiegare delle principale componenti del
codice.
Normalizzazione di ingresso
Inizialmente vengono dichiarate le variabili che andranno a contenere i valori ricevuti dai
sensori.
var horizontalSensor[7]
var deltaSensor[2]
var accSensor[3]
var motorSpeed[2]
Successivamente si crea un vettore contenente tutti i sensori che verranno impiegati.
var sensors[14]
Infine sarà necessario avere un vettore che dovrà contenere i valori di ingresso normalizzati.
var sensorsNormalized[14]
Si osservi come aggiungendo o togliendo qualunque sensore vige la necessità di andare a
cambiare il numero di elementi nelle variabili sensors e sensorsNormalized, cosi onde
evitare spiacevoli errori durante la compilazione o comportamenti inattesi.
Ora per far sì che il Thymio operi finché si desidera, si crea un ciclo che viene eseguito
finché non viene premuto il tasto centrale del Thymio, durante questo loop si andrà ad
aggiornare i valori dei sensori Periodicamente.
while (button.center==0) do

42. 42
call leds.top(255,0,0)
#vetttori sensori
horizontalSensor=[prox.horizontal[0],prox.horizontal[1],prox
.horizontal[2],
prox.horizontal[3],prox.horizontal[4],prox.horizontal[5],pro
x.horizontal[6]]
deltaSensor= [prox.ground.delta[0],prox.ground.delta[1]]
accSensor=[acc[0],acc[1],acc[2]]
motorSpeed = [motor.left.speed,motor.right.speed]
sensors = [horizontalSensor,deltaSensor,accSensor,motorSpeed]
elaborazione dati ingresso
si richiede ora di inserire i valori dei sensori in una variabile da elaborare di nome inSensor
e si andrà a chiamare la subroutine di normalizzazione dei valori di ingresso.
Successivamente l’elemento i-esimo viene memorizzato nel vettore riguardante i sensori
normalizzati.
#elaborazione dati ingresso
for i in 0:13 do
inSensor = sensors[i]
#modifiche in corso
if (i<=6) then
min =0
max =5000
end
if (i>=7 and i<=8) then
min =0
max =1024
end

43. 43
if (i>=9 and i<=11) then
min =-32
max =32
end
if (i>=12) then
min =-500
max =500
end
callsub normalize1
sensorsNormalized[i] = inSensorNorm
end
Nella subroutine di normalizzazione di ingresso , il primo passo è quello di controllare che
se abbiamo valori maggiori del massimo allora impostiamo il valore della variabile inSensor
uguale al valore massimo, se invece il valore è inferiore al minimo si assegna ad inSensor
il valore del minimo. Utilizzando la funzione nativa math.muldiv si va ad utilizzare la
formula.
Wi = 128
Vi − Vmini
Vmaxi
− Vmini
La funzione nativa ha la seguente sintassi:
math.muldiv (variabile risultato, primo fattore, secondo fattore, divisore).
sub normalize1
if inSensor>max then inSensor = max
end
if inSensor<min then inSensor = min
end
call math.muldiv(inSensorNorm,128,inSensor-min,max-min)
Alla fine del ciclo di normalizzazione si chiama la funzione che si occupa di svolgere le
operazioni della rete neurale, che a sua volta immediatamente chiama un'altra subroutine
che si occupa di calcolare i valori di uscita dei neuroni nascosti.

44. 44
Ossia callsub compute_output è la prima funzione che chiama la subroutine tramite
l’istruzione callsub calcoloCentrale.
La seguente subroutine è implementata come segue :
for i in 0:13 do
coeff = sensorsNormalized[i]*pesineurone1[i]
a = a + coeff
end
callsub tanhx
output1[0]=y
a=0
Questo ciclo for viene riscritto per un numero di volte pari ai neuroni dello strato intermedio.
La Subroutine calcoloCentrale svolge l’operazione di combinazione lineare tra i pesi e i
valori di ingresso e successivamente applicare a tale risultato la funzione approssimata
tangente iperbolica. Si osservi che pesineurone1 è riferita ai pesi tra gli ingressi e il primo
neurone dello stato intermedio. La variabile output1 si riferisce al uscita del primo neurone.
La subroutine tanhx è realizzata come segue :
sub tanhx
input=a
if (input>0) then
call math.muldiv(funx1,27,input,8192)
call math.muldiv(funx2,1,input,8192)
call math.muldiv(funx2,(funx2+1),(funx2+1)*(funx2+1),1)

45. 45
call math.muldiv(funx3,1,input,8192)
call math.muldiv(funx3,9,(funx3+1)*(funx3+1),1)
call math.muldiv(funx,8192,funx1+funx2,funx3+27)
end
if (input<0) then
call math.muldiv(funx1,27,input,8192)
call math.muldiv(funx2,1,input,8192)
call math.muldiv(funx2,(funx2-1),(funx2-1)*(funx2-1),1)
call math.muldiv(funx3,1,input,8192)
call math.muldiv(funx3,9,(funx3-1)*(funx3-1),1)
call math.muldiv(funx,8192,funx1+funx2,funx3+27)
end
y=funx
si osservi che nel codice in funzione se l’input è positivo o negativo si aggiunge 1 o si sottrae
uno, questa scelta permette una maggiore precisione dell’approssimazione ed evitando
valori nulli quando in realtà sono compresi tra 0 e 1.
Ora, calcolati i valori di uscita dei neuroni intermedi, si va a svolgere le stesse operazioni
con qualche modifica per i le due uscite che pilotano i motori. Le due uscite sono
memorizzate nel vettore motor[] avente una dimensione pari a 2.

46. 46
for i in 0:9 do
input2 = output1[i]
callsub normalize_output
hiddenNeurons[i] = output2
end
callsub neuromotor_compute
for i in 0:1 do
input2 = motor_output[i]
callsub normalize_motors
motor[i] = output2
end
La normalizzare dell’output di un neurone della rete neurale viene svolta come segue:
sub normalize_output
call math.muldiv(output2,1,input2,64)
Terminata l’esecuzione della subroutine compute_output si va a controllare i nostri attuatori
tramite le istruzioni:
motor.left.target = motor[0]
motor.right.target = motor[1].

47. 47
Di sopra si è fornito una panoramica sulle funzioni di base del codice realizzato dal
candidato, il codice come si può osservare è stato scritto con il criterio di essere facilmente
modificabile e adattabile a seconda delle esigenze, si precisa che l’aggiunta o l’eliminazione
di fonti di ingresso al nostro controllore prevedono l’aggiunta o l’eliminazione di righe di
codice in maniera manuale e anche il cambiamento dei valori nei cicli e le dimensioni dei
vettori, la realizzazione è tale che se si sbaglia le dimensioni di un vettore, il compilatore
andrà a segnalare tale inconsistenza.
Un'altra possibilità è quella di poter aggiungere nuove funzioni di attivazione come
subroutine e andare a richiamarle facilmente, ossia sostituendo il nome della subroutine per
i singoli neuroni.
Il codice completo del controllore è fornito assieme alla seguente relazione, accompagnata
da un video illustrativo su una delle possibili applicazioni del controllore dopo avere fornito
dei pesi ragionevoli alla rete neurale.

48. 48
CAPITOLO QUINTO
Analisi e collaudo del controllore
Per effettuare il collaudo del nostro controllore si è stabilito arbitrariamente l’esperimento
da effettuare. Ossia sono stati definiti i comportamenti che il Thymio deve realizzare.
L’esperimento si effettua con Thymio, il cui obiettivo è quello di muoversi all’interno di un
percorso, evitando gli ostacoli durante il suo cammino.
Il fine della sperimentazione è la raccolta dei dati e una sua successiva analisi, necessaria
per valutare quale sia la differenza tra i risultati attesi e quelli della realtà.
Simulare il robot con in esso implementato il controllore realizzato dal candidato, definisce
i risultati attesi, mentre testando Thymio nella realtà si definiscono i risultati cosiddetti reali.
L’assenza di un simulatore virtuale del Thymio diventa un vincolo sulle modalità di
realizzazione del collaudo e dell’analisi del nostro controllore. Dunque si è optato per
realizzare un programma in linguaggio Python, capace di simulare il funzionamento del
controllore realizzato.
Lo pseudo-simulatore del sistema di controllo del robot è in grado, inoltre, sia di raccogliere
i dati relativi agli ingressi del Thymio, sia di effettuare una loro analisi, che consiste nel
valutare quale sia la differenza tra i valori di uscita calcolati da Thymio nella realtà e i valori
calcolati dallo pseudo-simulatore.
In questo capitolo si andrà a spiegare come sono stati raggiunti gli obbiettivi prefissati nella
premessa di sopra.

49. 49
In primo luogo ai fini dell’esperimento, i pesi della rete neurale sono stati scelti affinché
fossero operativi soltanto i sensori di prossimità anteriori e la velocità di rotazione dei
motori di destra e sinistra.
Si ricorda che la rete neurale non è mai stata allenata e non è mai stato definito per essa un
obbiettivo da raggiungere.
Le fasi principali per il collaudo sono le seguenti:
Il primo passo è quello di effettuare la raccolta e la memorizzazione in un file di testo o
preferibilmente in formato CSV dei dati relativi ai sensori di ingresso del Thymio durante
la marcia. Allo strato software realizzato si definisce la variabile vettoriale collection1[16]
che dovrà contenere i valori dei sensori utilizzati dal controllore della rete neurale e i due
valori di uscita calcolati.
Successivamente si crea una variabile globale, di nome data1 aventi 16 parametri,
direttamente dall’editor Aseba come nell’immagine di sotto.
Schermata degli eventi globali nell'editor Aseba

50. 50
A questo punto si utilizza durante il ciclo di esecuzione del robot l’istruzione emit data1
collection1, che invia dal Thymio ad Aseba Studio la variabile globale data1 avente come
parametri i 16 definiti precedentemente.
Prima di eseguire Thymio si clicca con il tasto destro del mouse su data1 negli eventi globali
e infine su grafico data1. Ora comparirà una finestra grafico nell’editor come nella seguente
immagine.
Nell’istante in qui si andrà ad avviare l’esperimento il programma inizierà a registrare e
plottare i valori stabiliti.
Schermata del plotter di grafici in Aseba Studio

51. 51
Schermata grafico di Aseba Studio durante la marcia di Thymio.
Cliccando su salva con nome si ottiene un file di testo avente nella prima colonna il
Timetamp e nelle restanti colonne, invece, i valori di ingresso rilevati dai sensori e i due
valori di uscita calcolati.

52. 52
Esempio di File di CSV con i valori memorizzati durante la marcia del Thymio.
Un’ ulteriore elaborazione con Excel o altri strumenti a scelta, permette di adattare il file al
simulatore. Nel nostro caso viene eliminata la riga di Timestamp prima di avviare il
programma dello pseudo-simulatore.
Ora avendo raccolto i dati ed adattati allo scopo sì va a realizzare lo pseudo-simulatore del
nostro controllore in linguaggio Python.
Il programma legge i dati del file CSV, riga per riga e considera le prime 14 colonne
riguardanti i sensori, ossia simula di operare nelle stesse condizioni dell’esperimento.
A questo punto, il controllore calcola i valori di uscita e li memorizza all’interno di 2 liste,
una relativa al motore di destro e l’altra per quello sinistro.
Il codice del seguente software verrà fornito in allegato insieme alla tesi.

53. 53
Bisogna poi aggiungere delle funzionalità di analisi dei nostri dati, ossia si va in primo
luogo a calcolare la differenza in valore assoluto tra i valori ottenuti con la simulazione e i
valori ottenuti da Thymio.
Secondariamente, si effettua un plot della lista delle differenze dei risultati del motore destro
e del motore sinistro.
Si tiene a precisare che i conti realizzati dal controllore simulato non sono soggetti a forti
approssimazioni come per il controllore realizzato sul Thymio, questo è dovuto al fatto
che nel simulatore si possono operare con numeri decimali, inoltre gli arrotondamenti
sono fatti sia per eccesso che per difetto, invece che solo per difetto come nel Thymio e in
ultima analisi la tangente iperbolica nel simulatore non è stata approssimata come per il
controllore a nostra disposizione.
Durante la fase di collaudo si è fatto percorrere al Thymio un certo cammino con ostacoli,
si sono quindi salvati i dati in un file di testo e adattati al programma di simulazione. A
questo punto, si esegue il simulatore che estrae i dati dal file CSV e si ottengono i seguenti
risultati:

54. 54
Grafici della velocità di rotazione della ruota destra. In verde risultati teorici o attesi, in blu i valori reali ottenuti.
Grafico relativo alla differenza tra la velocità di rotazione del motore destro reale e il valore atteso tutto in valor
assoluto.
Nella maggior parte degli esperimenti effettuati si è osservato un andamento del
discostamento medio tra i valori d’uscita reali e quelli attesi appartenente all’incirca
all’intorno del valore 7.

55. 55
La Seconda osservazione come si evince dal grafico è che mentre la velocità di rotazione
dei motori per i valori teorici muta in maniera piuttosto regolare, nella realtà si è riscontrato
la velocità muta in modo repentino e ha un insieme di valori ben definito.

56. 56
CONCLUSIONI
Il presente studio si è posto l’obbiettivo di studiare la tecnologia a nostra disposizione al
fine di progettare e realizzare un controllore per piattaforma robotica basato su rete neurale,
il quale in seguito è stato, in seguito, collaudato.
Gli studi effettuati hanno portato a considerare un’architettura di una rete neurale avente
quattordici ingressi, uno strato nascosto avente un numero pari al 65% del numero di neuroni
di ingresso ed infine due percettroni di uscita.
Si è scelto inoltre di considerare soltanto pesi facenti parte dell’intervallo [-16,16] e di
utilizzare come funzione di attivazione un’approssimazione della tangente iperbolica.
Tali scelte sono giustificato dai limiti tecnologici ai quali si è subito dovuto far fronte; il
principale limite è stato il fatto che si potessero utilizzare soltanto numeri interi definiti su
un intervallo limitato [-32768,32767].
Con la ricerca svolta è stato possibile raggiungere l’obbiettivo di realizzare il controllore, in
particolare ci si è concentrati sulla normalizzazione dei valori all’ingresso dei percettroni
affinché non venissero superati i vincoli tecnologici stabiliti come premessa dello studio.
Nell’ultima fase dell’analisi effettuata si è cercato di individuare quale fosse il divario tra i
risultati ottenuti durante la sperimentazione del controllore e i risultati della simulazione,
concludendo grazie ai nostri esperimenti che tale divario in media risulta relativamente
basso.

57. 57
Sebbene lo scopo della tesi sia stato raggiunto, i risultati qui ottenuti ed illustrati possono
ancora fornire molti spunti per studi futuri. Ad esempio il controllore potrebbe essere
utilizzato come supporto per la fase di allenamento della rete neurale.