UNIVERSITÀ DEGLI STUDI DI PADOVA
DIPARTIMENTO DI INGEGNERIA DELL’INFORMAZIONE
CORSO DI LAUREA IN INGEGNERIA DELL’ AUTOMAZIONE
ANNO ACCADEMICO 2007/2008
Calibrazione di sensori distribuiti tramite
algoritmi di consensus
Relatore: Ch.mo prof. LUCA SCHENATO
Laureando: Simone Cieno
Padova, 14 Dicembre 2007
“Credo fermamente che l’ora piú bella per ogni uomo... la completa realizzazione di tutto quello che gli sta piú a cuore... sia quel momento in cui, avendo
dato l’anima per una buona causa, egli giace esausto sul campo di battaglia...
vittorioso.”
Vince Lombardi (1913, 1970)
Alla mia famiglia
Indice
Abstract
1
Introduzione
3
1 Reti di sensori wireless
1.1 Le reti di sensori . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 ZigBee e lo standard IEEE 802.15.4 . . . . . . . . . . . . . . . . .
7
7
7
9
2 Analisi apparato
2.1 TMOTE SKY . . . . . . .
2.1.1 Energia . . . . . .
2.1.2 Microprocessore . .
2.1.3 Radio . . . . . . .
2.1.4 Antenna . . . . . .
2.1.5 Sensori . . . . . . .
2.1.6 Memoria Flash . .
2.1.7 Connettori . . . . .
2.2 Software . . . . . . . . . .
2.2.1 TinyOS . . . . . .
2.2.2 Il linguaggio NesC
.
.
.
.
.
.
.
.
.
.
.
11
11
11
11
13
13
14
14
15
15
16
17
.
.
.
.
.
.
19
19
20
21
21
24
28
4 Algoritmo sviluppato
4.1 Algoritmi di consensus . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Il consenso nel dettaglio . . . . . . . . . . . . . . . . . . . . . . .
4.3 Sviluppo del software . . . . . . . . . . . . . . . . . . . . . . . . .
29
29
29
32
.
.
.
.
.
.
.
.
.
.
.
3 Studio del problema
3.1 RSSI & RSS . . . . . . . . .
3.2 Scopo del progetto . . . . .
3.3 Analisi preventiva della rete
3.3.1 Esperimento I . . . .
3.3.2 Esperimento II . . .
3.3.3 Brevi cosiderazioni .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ii
INDICE
5 Analisi dei dati
5.1 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Il problema dei cicli . . . . . . . . . . . . . . . . . . . . . . . . .
33
34
40
6 Conclusioni e studi futuri
43
A Algoritmo di analisi della connessione
A.1 Config.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 BaseStationC.nc . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 PeerC.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
45
47
50
B Algoritmo di consenso
B.1 consenso.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
59
Bibliografia
65
Elenco delle figure
67
Elenco delle tabelle
68
Ringraziamenti
71
Abstract
Nella tesi verrà discusso ed analizzato il problema della calibrazione di un parametro molto importante di ciascun nodo di una wireless sensors network (WSN).
Tale parametro, che corrisponde al nome di RSSI (Received Signal Strength Indicator), non è altro che un indice di bontà del segnale radio spedito dal singolo
sensore e ricevuto dai suoi vicini, ossia dagli altri con cui esso comunica. Da
cosa dipenda e come esso venga elaborato verrà esposto più avanti nella tesi, per
ora ci si limita a soffermarsi sulla sua estrema importanza in quanto viene spesso
utilizzato nella costruzione di algoritmi complessi per reti di sensori wireless quali
localizzazione e tracking in real time.
Il problema che si andrà a sottolineare riguarderà la presenza di un certo offset
di misura dell’RSSI che viene ad istaurarsi tra due sensori che comunicano reciprocamente.
Inoltre verrà esposto un software da implementare sulla rete di sensori in grado di
ottenere miglioramenti alquanto significativi nelle trasmissioni del parametro in
questione, software ottenuto attraverso l’utilizzo di un semplice schema iterativo
distribuito basato su una speciale classe di algoritmi per WSN chiamata algoritmi
di consensus.
Nell’elaborazione dei dati si noterà come questo tipo di algoritmo, nonostante
sia per nulla complesso, risulterà ridurre nettamente il problema esposto senza
alterare alcuna variabile interna propria dell’hardware, ma solo costruendone una
nuova indipendente che potrà essere utilizzata dall’operatore (o comunque da un
programma più globale) per compensare l’offset dell’RSSI istante per istante.
Introduzione
Le Wireless Sensor Network sono, letteralmente, reti di sensori senza fili: in realtà il sensore è solo una parte dell’intero sistema che costituisce la WSN, mentre
c’è tutto un insieme di hardware e software dedicato affinchè le misure rilevate
dal sensore siano scambiate tramite comunicazione radio e messe a disposizione
dell’utente.
L’idea di avere un qualcosa che possa monitorare dei parametri ambientali e che
sia capace di integrarsi nell’ambiente in cui si trova nasce nei laboratori della
NASA verso la fine del XXI secolo: l’ambiziosa intuizione iniziale prevedeva addirittura di realizzare della smart dust, polvere intelligente, per l’appunto, ossia
un insieme di piccolissimi elementi in grado di configurarsi e comunicare fra loro
costruendo una rete di comunicazione. Nella realtà non si è poi dato seguito a
questo progetto, ma è nato un nuovo filone di ricerca, quale quello delle reti di
sensori wireless.
Dopo anni di studi, oggi abbiamo sul mercato numerosi tipi di hardware su cui
è alloggiata una parte di controllo, una di comunicazione e una di sensori che
permettono di costruire una rete di sensori, capaci di essere dislocati su aree
abbastanza vaste e in grado di comunicare tra loro tramite dei protocolli di comunicazione sviluppati ad hoc per tali sistemi.
In questi ultimi tempi le reti di sensori wireless di tipo distribuito, ovvero il
processo dei segnali avviene distribuito tra i sensori stessi, stanno sempre più
incrementando la loro popolarità per il grandissimo numero di applicazioni possibili nelle discipline scientifiche più diverse. Tali applicazioni possono essere
raggruppate come prima analisi in tre grandi categorie:
• Monitoring: tipo di rete utilizzato per tener traccia con continuità di
grandezze relative ad una particolare area geografica (monitoraggio ambientale dell’acqua, dell’aria, chimica del suolo, monitoraggio di possibili
incendi in zone boschive e rischio ecc...)
• Tracking & Localization: vengono sfruttate le capacità di riorganizzazione della topologia della rete di sensori per identificare gli spostamenti
di un oggetto in una determinata area geografica (ad esempio in campo
militare, in quello edile nelle zone di cantiere a rischio, negli ospedali per
migliorare il controllo sulla degenza dei pazienti, ecc...)
• Controlling: tipo di rete finalizzato a riconoscere determinati eventi relativi alle misure rilevate da sensori o gruppi di sensori (nei campi dell’agri-
4
INDICE
coltura di precisione, strumentazioni di fabbrica, videosorveglianza wireless,
ecc..)
Figura 1: Esempio di WSN per monitorare possibili incendi
Le capacità e le qualità delle trasmissioni tra i sensori di una rete wireless sono
però fortemente vincolate alle condizioni degli ambienti in cui sono costruite. Infatti tali ambienti nella maggior parte dei casi non possono essere considerati
statici in quanto in essi sono presenti ad esempio ostacoli (muri, mobili, persone...) e campi magnetici variabili (cellulari, apparacchiature hi-fi, dispositivi
bluetooth...) che interferiscono con i segnali trasmessi dai singoli nodi. In particolare i fattori che condizionano in modo significativo la qualità delle trasmissioni
sono:
• distanza tra un nodo e l’altro
• ostacoli presenti
• potenza di trasmissione
• disturbi elettromagnetici
• alimentazione fornita
• diversità costruttive dell’hardware
• variazioni climatiche
• ...
Le radio dei sensori in questione possono fornire alcuni parametri quali ad esempio l’LQI (Link Quality Indicator) e l’RSSI (Received Signal Strength Indicator)
che acquistano una notevole importanza qual’ora vengano utilizzati come indici di
INDICE
5
grandezze in algoritmi complessi per WSN. L’RSSI ad esempio varia in funzione
della distanza e quindi può diventare un ottimo alleato nei campi del tracking e
della localizzazione, dove sono proprio le distanze, fisse o variabili, fra i nodi a
farla da padrone.
Tali parametri, purtroppo, essendo direttamente correlati alla qualità della trasmissione, sono soggetti, per i motivi sopracitati, a variazioni e codizionamenti esterni
indesiderati che in molte occasioni li rendono inaffidabili. E’ evidente quindi la
necessità di studiare un modo per calibrare questi indici istante per istante, fra un
nodo e l’altro di una SWN, cercando di escludere le variazioni a cui sono soggetti per interazioni esterne ed avvicinarsi sempre più ad un valore esatto privo di
disturbi che possa essere utilizzato senza restrizioni da algoritmi più globali.
Nella tesi sviluppata si prospetta per l’appunto di identificare e studiare le alterazioni indesiderate del parametro RSSI in una rete di sensori e creare quindi un
algoritmo di calibrazione dei singoli nodi in modo tale da minimizzarne gli errori
e migliorarne la stima del valore reale. A tal proposito si propone l’utilizzo di un
semplice schema iterativo distribuito basato su un algoritmo di consensus la cui
esaustiva descrizione è rimandata al capitolo n◦ 4.
Capitolo 1
Reti di sensori wireless
1.1
Le reti di sensori
Una Wireless Sensor Network è costituita da un insieme di elementi, definiti nodi
(o mote), che rispettano certe caratteristiche, come quelle di energy saving, auto
configurabilità, data processing, comunicazione wireless, che hanno per lo più il
compito di monitorare determinati parametri ambientali, tramite dei sensori appositi alloggiati su di essi.
Ogni nodo può interagire con gli altri nodi, secondo il protocollo di comunicazione
adottato, in modalità flat o gerarchica.
L’uso del wireless è soprattutto una necessità, molto spesso infatti la zona da monitorare non possiede infrastrutture per l’energia o per le comunicazioni, dunque
risulta necessario l’uso di nodi senza cavi con sorgente di energia piccola e finita. Proprio la limitata disponibilità di energia costituirà il principale limite col
quale ci si deve scontrare, ed è questo il limite che porta alla scelta di realizzare
una rete il più possibile distribuita anzichè centralizzata. La potenza del segnale
radio diminuisce con la distanza alla quarta potenza a causa delle riflessioni sul
terreno di un’antenna di piccole dimensioni; risulta quindi conveniente processare i segnali direttamente nei nodi per ridurre il più possibile la quantità di bit
trasmessi.
1.2
Architettura
In generale, per le reti è possibile fare una grossolana distinzione che si basa tanto
sulla distanza coperta quanto sulla topologia. Nel primo caso si distinguono BAN
(Body Area Network), PAN (personal Area Network), LAN (Local AN), MAN
(Metropolitan AN) e WAN (Wide AN), secondo quanto schematizzato in Figura
1.1. Particolarmente significative per le applicazioni sensoristiche sono proprio le
prime due.
Per quanto riguarda la topologia di rete, invece, si possono grosso modo individuare tre soluzioni differenti. La prima, più semplice dal punto di vista implementativo, è denominata topologia a stella: un nodo assume un ruolo particolare,
8
Cap. 1. Reti di sensori wireless
Figura 1.1: Classificazione delle reti in funzione dell’area coperta
tipicamente viene denominato coordinatore della rete, e tutti i rimanenti nodi fanno riferimento ad esso. In altre parole si implementa una struttura master-slave
nella quale il coordinatore è l’unico dispositivo ad effettuare più di un collegamento verso gli altri nodi; inoltre, in genere funge anche da bridge verso altri
sistemi di connessione.
Figura 1.2: Classificazione delle topologie di rete
Tale soluzione è superata dalla topologia Peer to Peer, detta anche topologia Mesh, nella quale il ruolo del coordinatore non è strettamente necessario, in
quanto ogni dispositivo è in grado di connettersi a tutti gli altri: in questo modo è
possibile realizzare percorsi ridondanti, che aumentano l’affidabilità complessiva a
discapito di un protocollo di gestione più complesso. Le reti mesh sono particolar-
1.3 ZigBee e lo standard IEEE 802.15.4
9
mente adatte per comunicazioni casuali tra gli interlocutori, mentre la topologia
a stella rappresenta la soluzione più efficiente per le comunicazioni organizzate
secondo una scansione ciclica. Infine, è possibile immaginare una struttura di
tipo gerarchico o ad albero, ottenuta interconnettendo ammassi (clusters) differenti di nodi come i rami e le foglie di un albero. Ciascun cluster ha un nodo
privilegiato che costituisce il punto d’accesso alla sottorete. Il vantaggio di questo
approccio è di ridurre il numero di collegamenti possibili (e quindi semplificare
la loro gestione) rispetto ad una rete Peer to Peer completamente connessa. Una
schematizzazione di questi concetti è mostrata in Figura 1.2.
1.3
ZigBee e lo standard IEEE 802.15.4
ZigBee è un protocollo per reti wireless specificatamente progettato per reti di
controllo e sensori a bassa velocità di dati. Ci sono un gran numero di applicazioni che possono beneficiare del protocollo ZigBee: reti di automazione industriale, sistemi di sicurezza per casa, misurazione remota e periferiche per PC.
Confrontato con gli altri protocolli wireless (WiFi, BlueThooth,...) lo ZigBee offre
bassa complessità, richiede risorse ridotte e, più importante, ha un set standard
di specificazioni.
Inoltre offre tre bande di frequenza di lavoro assieme ad un certo numero di configurazioni di rete e opzioni di sicurezza.
Lo ZigBee è basato sulle specifiche definite dallo standard IEEE 802.15.4 che fornisce una metodologia standard per funzioni, incluse la formazione della rete, i
formati dei messaggi e la ricerca dei dispositivi nella rete.
Lo ZigBee utilizza il MAC (Medium Access Layer) e il PHY (Physical Layer) del
IEEE 802.15.4.
Lo IEEE 802.15.4 definisce tre bande di frequenze operative ognuna con un numero fissato di canali. Le bande di frequenza sono: 2.4 GHz con 16 canali (11-26),
915 MHz con 10 canali (1- 10) e 868 MHz con un solo un canale (canale 0). La
velocità di trasmissione dati (bit rate) dipende dalla frequenza in cui si opera.
La banda sui 2,4GHz ha un bit rate di 250kbps, la banda sui 915MHz di 40kbps
mentre la 868MHz di 20kbps. Il valore reale del bit rate utilizzato sarà minore di
quello specificato per il sovraccarico dei pacchetti e i ritardi di elaborazione. La
lunghezza massima di un pacchetto IEEE 802.15.4 MAC è di 127 byte comprensivo di un CRC a 16 bit che controlla la integrità del frame. In più, il protocollo
IEEE 802.15.4 usa opzionalmente un meccanismo di Acknowledge per il trasferimento dei dati. Con questo metodo, tutti i frames con un speciale flag ACK
settato sono Acknowledged dal loro ricevitore. Questo assicura che un frame è
realmente arrivato. Se il frame è trasmesso con il flag ACK settato e l’Acknowledgement non è ricevuto all’interno di un certo tempo, il trasmettitore riproverà
a trasmettere per un numero di volte fissato prima di dichiarare un errore. E’
importante notare che la ricezione di un ACK semplicemente indica che un frame
è stato ricevuto dal MAC del ricevitore, ma non indica che il frame è stato processato correttamente. E’ possibile che il MAC del nodo ricevitore riceva e dia
10
Cap. 1. Reti di sensori wireless
l’ ACK correttamente ma data la scarsezza di risorse un frame potrebbe essere
scartato da altre patri del nodo che possono richiedere un ulteriore frame.
Capitolo 2
Analisi apparato
2.1
TMOTE SKY
I mote utilizzati nell’elaborato, a cui si farà riferimento nel testo, sono i Telos
revision B, detti anche Tmote Sky, prodotti dalla MoteIv Corporation [4]. Sono
nodi wireless a bassissima potenza, in grado di fornire un’ampia copertura delle
applicazioni tipiche delle reti di sensori wireless, dal momento che usano standard industriali ed integrano sensori di umidità, temperatura e luce. Di seguito
vengono elencate le caratteristiche principali che fanno del Tmote Sky una delle
più moderne piattaforme wireless.
2.1.1
Energia
Il Tmote Sky è alimentato con due batterie del tipo AA. Le celle di tipo AA
possono essere usate in un range operativo da 2,1 a 3,6 V DC, comunque la
tensione deve essere di almeno 2,7 V quando si programmano le memorie flash
esterne o del microprocessore. Se il nodo è connesso tramite la porta USB per
essere programmato o per trasmettere, le batterie non sono necessarie perchè
riceverà energia dal computer stesso operando ad una tensione di 3 V.
2.1.2
Microprocessore
Le operazioni a bassa energia del telos sono dovute alla peculiarità di bassissima energia richiesta dal microcontrollore MSP430 della Texas Instruments [6],
caratterizzato da 10kB di RAM, 48kB di memoria flash e 128B di memoria per
le informazioni. Il processore RISC a 16 bit ha un consumo di corrente attivo
e a riposo che permette al telos di lavorare per anni con una coppia di batterie
AA. Il MSP430 ha un oscillatore interno digitalmente controllato (DCO) che può
operare fino a 8MHz. Il DCO può essere acceso dallo stato di sleep in 6 µs.
Oltre al DCO, l’MSP430 ha 8 porte esterne ADC (analog to digital converter)
e 8 porte interne ADC. Queste ultime possono essere usate per la temperatura
interna o per monitorare la tensione delle batterie. Sono inoltre disponibili una
12
Cap. 2. Analisi apparato
Figura 2.1: le due faccie del Tmote-Sky
2.1 TMOTE SKY
13
varietà di periferiche incluso l’SPI (Serial Peripheral Interface), lo UART (Universal Asynchronous Receiver Transmitter), digital I/O ports, Watchdog timer, e
altri che catturano e comparano le funzionalità. Il microcontrollore include anche
un modulo DAC (digital to analog converter) a due porte a 12bit, un Supply
Voltage Supervisor e un controllore DMA (Direct Memory Access) a tre porte.
2.1.3
Radio
Il Tmote Sky è equipaggiato con il chip radio Chipcon CC2420 [5] per le comunicazioni wireless. Il CC2420 rispetta lo standard radio IEEE 802.15.4 e fornisce
il PHY (Phisical Layer) e alcune funzioni MAC (Medium Access Control). Fornisce una comunicazione wireless affidabile grazie alla sua sensibilità e alla sua
possibilità di operare a bassa energia. Il CC2420 è altamente configurabile per
molte applicazioni poichè è provvisto di default di settaggi conformi allo standard sopracitato. Il chip radio è controllato dalla cpu attraverso la porta SPI e
si possono impostare vari parametri per la trasmissione, come il canale radio e
la potenza del segnale in uscita. Per quanto riguarda la potenza di trasmissione
sono disponibili otto livelli come riportato in Tabella 2.1. Il dispositivo inoltre
Livello di potenza
31
27
23
19
15
11
7
3
Potenza in uscita (dBm)
0
-1
-3
-5
-7
-10
-15
-25
Consumo corrente (mA)
17.4
16.5
15.2
13.9
12.5
11.2
9.9
8.5
Tabella 2.1: Potenza della radio
fornisce i due valori di RSSI e LQI per ogni pacchetto ricevuto.
E’ importante tenere in considerazione i livelli minimi di tensione e temperatura
che permettono il funzionamento della radio: la radio funziona con una tensione
di alimentazione minima di 2,1 V e a temperature ambientali comprese tra i -40
e +85 ◦ C.
2.1.4
Antenna
Il Tmote Sky ha un’antenna a microstriscia a forma di F-invertita al margine
della scheda di supporto, lontano dall’alloggiamento delle batterie (Figura 2.2).
L’antenna è un dipolo dove la parte alta è piegata per essere parallela al piano
della terra. Anche se non ha un pattern di radiazione omnidirezionale può raggiungere un copertura di circa 25 metri in ambiente indoor e di oltre 125 metri
all’aperto.
14
Cap. 2. Analisi apparato
Figura 2.2: Antenna a microstriscia
E’ comunque prevista la possibilità di montare un’antenna esterna.
2.1.5
Sensori
Il Telos è dotato di un sensore di temperatura e umidità prodotto dalla Sensirion
AG [7].Il sensore è calibrato e produce un’uscita digitale; i dati poi vengono immagazzinati nella EEPROM del sensore.Quest’ultimo è realizzato con tecnologia
CMOS ed è dotato di un convertitore A/D a 14bit.
Il Tmote Sky ha inoltre integrati due fotodiodi per il rilevamento dell’intensità
luminosa prodotti dalla Hamamatsu Corporation [8]. L’S1087 misura il PAR
(Photosynthetically Active Radiation), mentre l’S1087-01 cattura dati relativi al
TSR (Toltal Solar Radiation) per monitorare l’intero spettro del visibile e in più
l’infrarosso.
2.1.6
Memoria Flash
La memoria flash è un chip (M25P80) che fornisce 1MB di memoria per memorizzare i dati. Lo spazio è suddiviso in 16 segmenti da 64 KB ciascuno ed è connessa
alla cpu mediante bus SPI.
Radio e flash usano lo stesso bus per comunicare con il microprocessore e questo
crea la necessità di dover gestire la condivisione della risorsa.
Anche per la memoria flash è importante considerare che il livello minimo di
alimentazione che ne consente la lettura, la scrittura e la cancellazione è di 2,7 V.
2.2 Software
2.1.7
15
Connettori
Il Tmote Sky è provvisto di due connettori per l’espansione (6 e 10 pin) e di alcuni jumper che possono essere configurati per collegare dispositivi esterni come
sensori analogici, display LCD e altre periferiche digitali.
Per le comunicazioni mote-pc, per caricare il software o per un’eventuale alimentazione di rete, il mote è provvisto di un controller usb 2.0. Basta collegare il
dispositivo al pc ed esso viene immediatamente identificato da qualunque sistema
operativo.
Figura 2.3: Schema a blocchi del Tmote Sky
2.2
Software
Oltre all’hardware, i nodi wireless devono ospitare il software necessario a gestire
le comunicazione tra di loro e a realizzare i servizi più avanzati. Sfortunatamente
le peculiarità delle reti di sesnsori e le caratteristiche dei mote stessi rendono
difficilmente riutilizzabile il software disponibile in commercio e richiedono lo
sviluppo di soluzioni progettate appositamente per la piattaforma utilizzata e
16
Cap. 2. Analisi apparato
per la specifica applicazione. Questa argomentazione vale anche per il sistema
operativo, a cui è richiesto di soddisfare i seguenti requisiti:
• ridottissima occupazione di memoria
• basso consumo di energia durante l’esecuzione dei processi
• consumo quasi nullo durante lo stato di inattività (sleep mode)
• gestione della concorrenza (accesso simultaneo di più thread alla stessa
risorsa)
• supporto efficiente (in termini di consumo energetico) ai protocolli di rete
• facile accesso alle funzionalità di basso livello della piattaforma per mezzo
di interfacce esterne.
Sulla base di queste considerazioni generali, nell’Università della California di
Berkeley, è stato sviluppato il TinyOS [9], un sistema operativo appositamente
progettato per reti di sensori wireless e caratterizzato da:
1. un kernel ridotto che permette l’accesso all’hardware
2. meccanismi di gestione del processore che non prevedono cambi di contesto
3. una memoria considerata come un unico e lineare spazio fisico.
2.2.1
TinyOS
La caratteristica fondamentale della visione del sistema in chiave TinyOS è la possibilità di gestire ogni elemento del programma (file, moduli di gestione hardware,
etc.) come un modulo a sè stante, e collegabile con tutti gli altri tramite delle
connessioni, del tutto simili a delle ipotetiche linee elettriche. In questo modo
un programma che gestisca un nodo wireless, per quanto complesso e articolato,
è facilmente gestibile come insieme di tanti sotto/file che possono interagire tra
loro con estrema semplicità. Oltre a rendere molto più leggibile un programma,
questa tecnica ha l’enorme vantaggio di consentire il riutilizzo di una parte di esso
in un qualsiasi altro programma, una volta introdotto il modulo corrispondente.
In TinyOS per modulo si intende una unità fondamentale, che rappresenta una
parte di codice, in grado di interfacciarsi con altri moduli, di diversi livelli:
-un moduloA si definisce di livello superiore rispetto ad un moduloB se il moduloA comanda o usa il moduloB;
-un moduloB si definisce di livello inferiore rispetto ad un moduloA se il moduloB
è usato dal moduloA e fornisce delle interfacce per ricevere i comandi.
Sostanzialmente un modulo è un file, preposto alla implementazione di una singola parte dell’algoritmo di gestione se il modulo è di alto livello, o dell’hardware
se il modulo è di basso livello.
TinyOS è totalmente implementato in un nuovo linguaggio di programmazione, il
NesC, per meglio soddisfare i requisiti stringenti che caratterizzano questo sistema
operativo.
2.2 Software
2.2.2
17
Il linguaggio NesC
NesC [10] è un’estensione del linguaggio di programmazione C, progettato per
incorporare i concetti strutturali e i modelli di esecuzione di TinyOS.
I concetti base su cui erige NesC sono i seguenti:
• Separazione della costruzione e della composozione: i programmi sono fatti
di componenti, che insieme formano (tramite il wiring) l’intero programma. I componenti definiscono due campi, il primo per la loro specificazione
(contengono i nomi delle loro istanze di interfacce) e il secondo per la loro
implementazione. I componenti sono soggetti a concorrenza interne sotto
forma di tasks.
• Specifica del comportamento dei componenti in termini di set di interfacce.
Le interfacce possono essere fornite o usate da un componente.
• Le interfacce sono bidirezionali: individuano un set di funzioni che devono
essere implementate da chi fornisce l’interfaccia (comandi ), e un’altro set
di funzioni che deve essere implementato da chi usa le interfacce (eventi ).
• I componenti sono staticamente connessi tra di loro attraverso le loro interfacce. Questo aumenta l’efficienza del tempo di esecuzione, incoraggia
una progettazione più robusta e permette un’analisi statica migliore dei
programmi.
• Il modello di concorrenza del NesC è basato su run-to-completation tasks
(esecuzione fino al completamento) e su una gestione degli interrupts che
può interrompere i tasks e viceversa.
Capitolo 3
Studio del problema
Prima di proseguire nella spiegazione del tipo di algoritmo a cui fa riferimento il
titolo della tesi è d’obbligo analizzare ed esporre in modo dettagliato il problema
principale che ha richiesto la realizzazione del presente elaborato. Del resto è
risaputo che per risolvere un quesito, qualunque esso sia, è necessario innanzitutto
capire in modo preciso ciò che viene richiesto, e solo a quel punto si può passare
alla risoluzione dello stesso.
Ciò che ci si propone in questo capitolo è proprio l’esposizione chiara e minuziosa
del problema in questione, attraverso l’illustrazione di concetti teorici e l’analisi
di vari esperimenti eseguiti su una semplicissima WSN.
3.1
RSSI & RSS
Il chip radio CC2420 [5] presente sul Tmote Sky, come già accennato nel capitolo
2, è in grado di fornire, fra diversi indici, anche il valore di RSSI, Received Signal Strength Indicator, che significa letteralmente Indicatore di Forza del Segnale
Ricevuto. L’RSSI è un numero che la radio ci fornisce in un registro di 8 bit in
complemento a 2 (RSSI.RSSI VAL) che è legato alla potenza del campo elettromagnetico (RF level) ossia alla forza del segnale ascoltato, da cui il nome RSS.
L’RSS può essere ricavato direttamente dal valore del registro RSSI.RSSI VAL
mediante l’utilizzo della seguente equazione:
PRF = RSS = RSSI V AL + RSSI OF F SET
[dBm]
(3.1)
dove RSSI OFFSET è un valore, trovato empiricamente durante lo sviluppo del
sistema radio e dato quindi dal costruttore, di circa -45 dBm.
L’andamento generale dell’RSSI VAL in funzione della potenza del segnale ricevuto è riportato in figura 3.1. Il valore di RSSI nel registro RSSI.RSSI VAL viene
continuamente calcolato ed aggiornato dal chip radio ad ogni arrivo di un nuovo
pacchetto di dati.
20
Cap. 3. Studio del problema
Figura 3.1: Andamento RSSI rispetto alla potenza del campo elettromegnetico
3.2
Scopo del progetto
Il valore di RSSI, come già accennato nelle sezioni precedenti, diventa molto importante negli algoritmi di localizzazione [11] qualora venga utilizzato per stimare
la distanza di due nodi di una WSN. Tale distanza è infatti calcolabile, a partire
dal valore della potenza ricevuta (RSS), attraverso la seguente formula:
γ
d = e 2 10
A−PT X
10np
;
γ=(
σ ln 10 2
)
10np
(3.2)
dove PT X è la potenza di trasmissione del segnale ricevuto (RSS per l’appunto), σ è le deviazione media standard dell’errore della potenza del campo
elettromagnetico, A e np due parametri che dipendono rispettivamente solo dai
nodi e dall’ambiente in cui avviene la localizzazione.
Risolvendo l’equazione rispetto a PT X , ossia rispetto al valore di RSS, si può
facilmente ricavare la seguente:
PT X = RSS = A − 10np log(
d
γ )
e2
(3.3)
da cui si evince che:
RSSI = f (d)
(3.4)
ossia che il valore di RSSI di un nodo ricevente rispetto ad un altro nodo mittente dovrebbe essere una certa funzione (logaritmica) della distanza fra i due.
Da questo presupposto è logico dedurre che due mote in posizione statica, all’interno di un ambiente omogeneo, in grado di comunicare tra loro scambiandosi
reciprocamente informazioni, e che trasmettono con uguale livello di potenza
nominale (in poche parole due mote fisicamente identici nelle stesse condizioni),
in linea puramente teorica dovrebbero misurare lo stesso valore di RSSI.
3.3 Analisi preventiva della rete
21
In realtà dagli esperimenti svolti durante il periodo di tesi, presso il Laboratorio
Visione Computazionale e Navigazione Autonoma 2 nella sede DEI/A del Dipartimento di Ing. dell’Informazione dell’Università degli Studi di Padova, e riportati
in sezione 3.3, si può affermare che presi due nodi i, j, il valore di RSSI fornito
dal nodo i in ricezione del segnale proveniente da j (RSSIi←j ) si discosta di una
certa quantità da quello misurato da j in ricezione del segnale proveniente da i
(RSSIj←i ), ossia che:
RSSIi←j 6= RSSIj←i
(3.5)
poichè
RSSIi←j = RSSIj←i + oi,j
e
RSSIj←i = RSSIi←j + oj,i
(3.6)
dove ovviamente oi,j = −oj,i .
Quanto detto finora implica che l’RSSI misurato da ciascun nodo di una rete
wireless rispetto al segnale speditogli da un suo nodo vicino è sı̀ una certa funzione
della distanza fra i due, ma a cui va a sommarsi un determinato offset e quindi:
RSSIi←j = f (di,j ) + oi,j
(3.7)
Il fine ultimo di questo elaborato è l’implementazione di un algoritmo in grado
di stimare istante per istante l’offset in questione e di compensarlo con un determinato schema di calibrazione in modo tale da avere un valore pulito di RSS da
utilizzare ad esempio nella localizzazione per raffinare la stima delle distanze.
3.3
Analisi preventiva della rete
In questa sezione vengono illustrati due tipi di esperimento finalizzati alla pura
analisi che sono stati eseguiti su una rete di sensori minima, ossia una WSN
formata da due soli nodi comunicanti fra loro. In realtà i motes utilizzati sono
stati tre, ma uno di essi ha avuto solo la funzione di base-station ed è servito da
supervisore per scandire i tempi di trasmissione e ricezione degli altri due. Per la
spiegazione dettagliata del programma utilizzato e del rispettivo codice si rimanda
a [2]. Per adesso basti sapere che i due nodi in questione si sono scambiati a
rotazione, ed hanno memorizzato in flash, un certo numero di pacchetti contenenti
dei dati, tra cui il valore di RSSI fornito dal chip radio.
Lo scambio di informazioni tra i sensori in entrambe le esperienze è stato svolto
in tempi abbastanza ristretti, entro i 10 minuti, in modo tale da poter ritenere
statiche le condizioni ambientali del laboratorio, almeno con un margine di errore
accettabile.
3.3.1
Esperimento I
Il primo degli esperimenti svolti ha avuto come scopo l’analisi dell’offset relativo
al valore di RSSI che si instaura fra due nodi comunicanti di una WSN dovuto
solo all’hardware utilizzato.
22
Cap. 3. Studio del problema
Due motes i e j sono stati posti ad una distanza fissa pari a 7 m e dopo un certo
periodo di tempo (circa 7 minuti) durante il quale hanno potuto comunicare
fra loro e memorizzare i dati nelle rispettive memorie, attraverso un programma
di lettura appositamente progettato (preso da [2], modificato ed adattato) si
sono recuperati dalle flash i valori di RSSI di entrambi i sensori, ossia RSSIi←j
e RSSIj←i . Successivamente si è ripetuta la procedura mantenendo il nodo i
sempre uguale in termini di hardware, ma cambiando fisicamente il nodo j, questo
per 40 volte consecutive. In laboratorio sono disponibili più di un centinaio di
motes, ma esegurire l’esperimento con tutti sarebbe stato troppo dispendioso in
termine di tempo e comunque ripetitivo nei dati.
Figura 3.2: Raffigurazione stilizzata esperimento I
In ogni prova sono stati trasmessi pacchetti con tutti gli otto livelli di potenza
diponibili. Per ogni livello di potenza si sono graficati in seguito i valori medi e
le rispettive varianze (in valore assoluto) dei valori di offset di RSSI misurati dai
nodi variabili rispetto al valore medio di RSSI del nodo fisso che nel nostro caso
era il NAV00000.
Nelle figure 3.3 e 3.4 vengono riportati i valori di ∆RSSI (dBm)
rispettivamente della prima e seconda metà dei motes in esame con potenza di
trasmissione PA LEVEL pari a 23, mentre nelle due figure successive si leggono
i risultati con PA LEVEL 11.
Di seguito si riportano alcune osservazioni che si possono formulare dall’analisi
dei dati.
1. In linea teorica, dovendo essere i motes tutti identici , i segmenti riportati
nei vari grafici dovrebbero essere tutti sovrapposti fra loro, o almeno
molto vicini, ma in realtà svariano all’interno di un range di circa 10dBm.
Comunque questo fatto può essere imputabile alle variazioni ambientali
avvenute durante le varie prove e, infatti, da un’analisi satellite non
riportata, risulta che i valori medi di RSSI del nodo fisso risultano più
simili fra loro nelle prove eseguite in successione.
3.3 Analisi preventiva della rete
23
Figura 3.3: Offset di RSSI dei nodi variabili rispetto l’RSSI del nodo fisso con
PA LEVEL 23 (prime 20 prove)
Figura 3.4: Offset di RSSI dei nodi variabili rispetto l’RSSI del nodo fisso con
PA LEVEL 23 (seconde 20 prove)
24
Cap. 3. Studio del problema
2. Le medie delle differenze di RSSI tra il nodo fisso e quelli variabili si
aggira su valori compresi all’incirca tra 1 e 5 dBm.
3. Nelle prove che hanno dato valori molto prossimi di RSSI in lettura anche
le medie dell’offset sono risultate abbastanza vicine. Questa è un dato di
fondamentale importanza poichè indica che a parità di RSSI misurato
anche l’errore rimane all’incirca costante (si vedano i nodi 03, 49, 50 in
figura 3.3).
4. Man mano che si riduce la potenza in trasmissione e quindi
conseguentemente anche il valore di RSSI misurato, le medie e le varianze
degli offset aumentano sensibilmente (infatti media ∆RSSIP A23 = 2.4dBm
mentre ∆RSSIP A11 = 3.2dBm). Inoltre, con potenze basse, quanto detto
al punto 3 non è sempre verificato. Questo fatto risulta del resto
abbastanza logico: più il segnale è potente, più le prestazioni sono elevate,
ma cosı̀ facendo aumenta anche il consumo di energia.
5. Nonostante i costruttori reputino normale misurare differenze di RSSI tra
un nodo i e un nodo j in una WSN nell’ordine di 6/7dBm, durante le
prove si sono rilevati, in alcuni casi, valori di tale offset molto maggiori,
addirittura il doppio per qualche pacchetto. Molto probabilmente questi
casi sono da imputare ad interferenze di tipo ambientale, ma se cosı̀ fosse
sarebbe utile interrogarsi sull’affidabilità di questo tipo di reti in ambienti
di vita odierni, dove campi elettromagnetici di ogni genere sono presenti in
tutte le ore del giorno.
3.3.2
Esperimento II
Nel secondo esperimento i motes utilizzati sono stati solo due, sempre uguali,
ovvero il mote contrassegnato con ID NAV00003 (nodo1) e quello con ID
NAV00050 (nodo2). Anche in questo caso si sono eseguite all’incirca una
quarantina di prove, ma questa volta si è deciso di cambiare solo la distanza fra
i due nodi. Poichè le misure sono state efettuate all’interno del piano terra
dell’edificio DEI/A, oltre alla distanza in ogni prova sono variate anche tante
altre condizioni ambientali circostanti: muri, oggetti mobili, interferenze
elettromagnetiche, persone in movimento, ecc. Per questo motivo i vari ∆RSSI
tra nodo2 e nodo1 sono stati graficati rispetto al valore presente nel ragistro
RSSI.RSSI VAL del nodo1, e non rispetto alle distanze effettive.
Le prime venti misure sono state eseguite ponendo i due motes sempre
all’interno del Laboratorio NAVLAB, mentre le altre venti con uno dei due
posizionato in diverse zone di tutto il piano.
Analizzando i risultati nelle figure 3.7, 3.8, 3.9 e 3.10 relative rispettivamente a
potenze di trasmissione con PA LEVEL 23 le prime due e con PA LEVEL 11 le
altre, si possono fare le seguenti considerazioni:
3.3 Analisi preventiva della rete
25
Figura 3.5: Offset di RSSI dei nodi variabili rispetto l’RSSI del nodo fisso con
PA LEVEL 11 (prime 20 prove)
Figura 3.6: Offset di RSSI dei nodi variabili rispetto l’RSSI del nodo fisso con
PA LEVEL 11 (seconde 20 prove)
26
Cap. 3. Studio del problema
Figura 3.7: Offset di RSSI del nodo2 rispetto l’RSSI del nodo1 con PA LEVEL
23 (prime 20 misure)
Figura 3.8: Offset di RSSI del nodo2 rispetto l’RSSI del nodo1 con PA LEVEL
23 (seconde 20 misure)
3.3 Analisi preventiva della rete
27
1. le medie delle differenze di RSSI assumo valori in un range che va da circa
1 dBm a massimo 5 dBm in valori assoluti;
2. tali medie si mantengono molto vicine nel caso di prove che danno valori
di RSSI abbastanza simili (si vedano le misure 01 e 09 oppure 14 e 02 in
fig.3.7) e ciò è una nota alquanto positiva;
Figura 3.9: Offset di RSSI del nodo2 rispetto l’RSSI del nodo1 con PA LEVEL
11 (prime 20 misure)
3. sia le medie di ∆RSSI, ma soprattutto le varianze in valore assoluto delle
stesse, subiscono, in generale, peggioramenti notevoli man mano che la
potenza del campo elettromagnetico diminuisce (si notino nei garfici i
valori con RSSI al nodo1 inferiore ai -20 dBm);
4. in alcuni casi (ad esempio misure 02, 12, 33) si sono riscontrati valori di
∆RSSI molto maggiori di quelli ritenuti accettabili dai costruttori,
addirittura di 20 dBm in valore assoluto. Ciò sarebbe estremamente
preoccupante se le medie fossero notevolmente alterate, ma dato che ciò
non avviene si può ipotizzare che la colpa sia di qualche sporadico
pacchetto i cui dati sono stati alterati da forti ma momentanee
interferenze esterne;
5. infine è da notare come riducendo la potenza di trasmissione, più che le
medie degli offset che si creano tra i valori di RSSI dei due nodi, sia la
varianza degli stessi a farne le spese più gravi.
28
Cap. 3. Studio del problema
Figura 3.10: Offset di RSSI del nodo2 rispetto l’RSSI del nodo1 con PA LEVEL
11 (seconde 20 misure)
3.3.3
Brevi cosiderazioni
Da quanto osservato nelle due sezioni precedenti si evince che in una rete di
sensori wireless, se pur di dimensioni ridottissime, i valori di RSSI forniti dai
chip radio dei singoli nodi non sono da ritenere cosı̀ affidabili come dovrebbero.
Infatti non soddisfano in media alla condizione che dispositivi posti alla stessa
distanza devono restituire la stessa misura dell’intensità del campo elettrico.
Le cause di questo mal funzionamento sono da ricercare fra due argomentazioni
fondamentali:
• l’alta variabilità del tipo di ambiente in cui si opera
• le diversità costruttive a livello di hardware tra un nodo e l’altro.
Inoltre, nel caso di trasmissioni di dati di una certa importanza, è consigliabile
l’utilizzo di livelli di potenza notevoli per ridurre i margini di errore. Purtroppo,
però, potenze maggiori richiedono consumi energetici elevati.
Capitolo 4
Algoritmo sviluppato
Da quanto riportato nei capitoli precedenti, si può ora intuire la fondamentale
importanza dello sviluppo di un algoritmo, in grado di agire su ogni coppia di
sensori di una WSN, che riesca a minimizzare istante per istante la differenza
del valore di RSSI che si riscontra tra ogni nodo i e il suo vicino j.
E’ da tener ben presente, però, che ciascun mote della rete ha, nella maggior
parte dei casi, un numero di vicini superiore a 1, poichè per vicino in uno
schema ditribuito si intende ogni altro sensore con cui quello soggetto
comuninica. Quindi l’algoritmo in questione dovrà cercare di compensare tutti
gli offset presenti tra l’RSSI misurato da i e quello misurato dagli altri nodi che
scambiano informazioni con esso. Ecco perciò motivata la scelta del metodo del
consensus.
4.1
Algoritmi di consensus
Con il termine consenso (dal latino consensus) si intende la convergenza ad un
parametro comune di più agenti tramite scambio di informazioni o interazione
locale. In una rete di sensori distribuiti, l’obiettivo principale è quello di
ottenere, per ogni nodo, una buona stima di tale parametro sconosciuto, ossia
eseguire una calibrazione.
Lo schema che si propone aggiorna, per ciascun sensore, il dato in questione
attraverso una media pesata di quello dei suoi vicini.
4.2
Il consenso nel dettaglio
Si hanno N sensori che raccolgono misure di un parametro affetto da offset
yi←j = Θ + oi,j
(4.1)
e si vuole che tutti i sensori restituiscano misure coerenti, ovvero che
ŷi←j −→ yglob .
(4.2)
30
Cap. 4. Algoritmo sviluppato
Per fare ciò è necessario aggiungere un certo valore a yi←j in modo tale da
compensare l’offset presente e quindi
ŷi←j = yi←j + ôi
(4.3)
Lo scopo è scegliere ôi in modo tale che la somma degli offset in un ciclo di nodi
comunicanti sia il più possibile prossima a zero, ossia trovare
X
ôi |
(∆ŷi,j ) = 0
(4.4)
ciclo
Da notare che la scelta di ôi non è univoca. Basti pensare ad una rete composta
da due soli nodi i, j, dove ad esempio yi←j = A e yj←i = B, con A e B costanti.
Ora ŷi = A + ôi e ŷj = B + ôj e considerando che l’obiettivo si riduce all’avere
ŷi = ŷj , con pochi banali passaggi si ha
ôi = (B − A) + ôj
da cui si evince che un’infinità di coppie di valori (ôi , ôj ) risolvono il problema.
In realtà, nell’algoritmo sviluppato, ci si propone di soddisfare alla 4.4 cercando
il valore fra tutti gli ôi possibili che minimizza la somma dei quadrati ossia
X
ô2i sia minima.
(4.5)
ôi |
ciclo
Poichè il valore di Θ in 4.1 non interessa ai fini della calibrazione, si ipotizza per
adesso che
yi←j = yi = oi
(4.6)
e quindi si vuole trovare
ŷi = oi + ôi (t)
|
ŷi − ŷj = 0
∀ i, j.
(4.7)
L’algoritmo di consenso opera sugli N sensori comunicanti cercando una stima
di ŷi (t) che tenda ad una media pesata dei valori letti da ciascun nodo. Per
raggiungere tale stima si rende necessario lo schema iterativo
ŷi (t + 1) = pi,j ∗ ŷi (t)
(4.8)
con condizione iniziale ŷi (0) = yi , che in forma matriciale espansa agli N nodi
diventa




ŷ1
ŷ1
 .. 
 . 
 .  = P  .. 
ŷN t+1
ŷN t
La matrice P ∈ RN ×N , ovvero la matrice dei pesi, è una matrice doppiamente
stocastica , vale a dire che ha tutti gli elementi positivi e tali che la somma di
ogni riga e di ogni colonna sia uguale a 1. Essa infatti è costruita in modo tale
da soddisfare a
4.2 Il consenso nel dettaglio
31
P1 = 1
1T P = 1T
e i valori di pi,j vengono calcolati con la tecnica del Metropolis Weights [13] la
quale assegna, per ogni coppia di nodi comunicanti i, j il valore:
pi,j = αj =
1
max(degreei , degreej ) + 1
(4.9)
dove degreei non è altro che il numero di vicini con cui il nodo i riesce a
scambiare informazioni.
Tornando ora al caso scalare si ha che l’equazione di aggiornamento del valore
stimato risulta
X
X
ŷi+ =
αj ŷj + (1 −
αj )ŷi
(4.10)
j∈G
j∈G
dove G è l’insieme dei nodi comunicanti con i, escluso i stesso, e da cui con
banali passaggi si ha subito che:
X
ŷi+ = ŷi +
αj (ŷj − ŷi ).
(4.11)
j∈G
Sostituendo ora in questa la 4.3 si giunge all’equazione
X
ô+
αj (yj + ôj − yi − ôi )
i = ôi +
(4.12)
j∈G
la quale non è altro che l’equazione di aggiornamento dell’offset cercato. E’ da
notare che la 4.12 dipende soltanto dalle differenze tra le misure del parametro
y di due nodi vicini, e non dal valore reale di ciascuno di essi, e quindi si evince
che l’ipotesi 4.6 non era in realtà necessaria, ma solo utile alla comprensione
dell’algoritmo.
Inoltre è dimostrabile che con l’utilizzo di pesi ottenuti attraverso Metropolis
Weights si ha che
ŷi (t) −→
1 X
yi
N
e
ôi (t) −→
1 X
oi
N
(4.13)
ossia che sia la stima del parametro che quella dell’offset di compensazione
convergono in un punto che sarà la media rispettiva dei valori del parametro
raccolti dai motes e delle differenze degli stessi tra un nodo e l’altro.
Nel caso discusso in questa tesi il parametro yi←j diventa il valore di RSSI
fornito dal nodo i tramite ricezione del segnale dal nodo j ossia
RSSIi←j = f (di,j ) + oi
(4.14)
dove f (di,j ) è una certa funzione della distanza fra i due motes e oi l’offset che si
vuole minimizzare. Quindi se
32
Cap. 4. Algoritmo sviluppato
\ i←j = RSSIi←j + ôi
RSSI
è il valore stimato di RSSI da cui poi estrapolare la potenza del campo
elettromagnetico da usare nella localizzazione, il fine ultimo dell’algoritmo
descritto è proprio il calcolo della quantità ôi da sommare all’RSSI di ciascun
nodo i, istante per istante, per ottimizzare tale stima.
4.3
Sviluppo del software
L’algoritmo precedentemente illustrato viene implementato nell’elaborato
mediante l’utilizzo del software MATLAB [14], e costruito ad hoc per una rete
di quattro sensori tutti comunicanti fra loro. Ciò implica che il valore di αj
definito in 4.9 risulti sempre costante e pari a 41 .
Si costruisce una matrice y ∈ R4×4 di ingressi aggiornata istante per istante
dove il numero di riga corrisponde al nodo ricevente il messaggio, e il numero di
colonna indica il nodo mittente. In questo modo in ogni casella si ha il valore di
RSSIi←j ; ad esempio nella posizione (1,3) si ha RSSI1←3 ossia l’RSSI letto dal
mote n◦ 1 sul segnale inviatogli dal mote n◦ 3.
Si pongono quindi a zero (condizioni iniziali nulle) quattro nuove variabili ocapi
con i = 1 . . . 4 le quali altro non sono che i vari ôi , uno per ciascun nodo della
rete, e si esegue l’algoritmo. Quest’ultimo, istante dopo istante, aggiorna queste
quattro variabili come da equazione 4.12 e le memorizza riga per riga su una
matrice ocap ∈ R(k+1)×4 , dove k è il numero degli istanti in esame. Preso un
solo vettore-riga di tale matrice, si leggono da sinistra verso destra i valori di
ô1 . . . ô4 da sommare in quel preciso istante al valore di RSSI letto nei rispettivi
motes per minimizzare l’offset sul ciclo attenendosi alla condizione 4.5.
Si anticipa già da ora che i valori ottenuti attraverso l’algoritmo in esame di
ŷi (t) e di ôi (t) si attengono perfettamente alle condizioni di convergenza di 4.13.
Capitolo 5
Analisi dei dati
Come anticipato nel capitolo precedente, l’algoritmo descritto in questa tesi è
stato costruito ad hoc per una rete composta da quattro Tmote Sky tutti in
grado di comunicare fra loro scambiandosi informazioni.
Sui quattro sensori è stato caricato un software sviluppato in ambiente
TinyOS-2 progettato in origine per eseguire un semplice test di connettività [2].
Tale software è stato modificato ed adattato in modo da imporre ai nodi uno
scambio reciproco di pacchetti dati molto ridotti contenenti alcune informazioni
su diversi parametri tra cui, molto importante, l’ID del nodo trasmittente. I
sensori sono stati distribuiti come da figura 5.1 all’interno del piano terra
dell’edificio DEI/A nel Dipartimento di Ingegneria Dell’Informazione
dell’Università di Padova. Dopo un breve periodo di tempo (ca. 9 minuti) in cui
Figura 5.1: Distribuzione dei sensori sul piano terra dell’edificio DEI/A
i motes si sono scambiati tutti i pacchetti previsti dal codice, si è eseguita la
lettura delle loro rispettive flash, prestando particolare attenzione ai valori di
RSSI memorizzati.
34
Cap. 5. Analisi dei dati
A questo punto si è applicato ai dati ricavati l’algoritmo di calibrazione
esplicato nella sezione precedente. Tale algoritmo, infatti, dato che come
variabili di ingresso richiede solo i valori di RSSI letti dai nodi e non prevede
alcuna alterazione di parametri interni agli stessi, ha il vantaggio di poter essere
eseguito in modalità offline.
Un’ultima osservazione prima di analizzare se l’algoritmo sia stato efficace o
meno è la seguente: come si può notare in sezione 4.1.1, la potenza con cui viene
trasmesso un segnale non compare in nessuna delle equazioni descritte; ciò
significa che la bontà dell’algoritmo non dipende in alcun modo da essa. Per
questo motivo si è scelto di utilizzare un solo livello di potenza in trasmissione
per le prove efettuate sulla rete di quattro sensori. E’ comunque logico supporre
che diminuendo tale potenza, come osservato nel capitolo 3, gli offset di RSSI da
compensare aumentino anche in modo sensibile, ma ciò non metterà certo in
crisi il metodo del consensus che si adeguerà semplicemente con compensazioni
maggiori.
5.1
Risultati ottenuti
In questa sezione vengono riportati in grafici e tabelle i risultati ottenuti
dall’esperimento sia prima che dopo l’applicazione dell’algoritmo di consenso, in
modo tale valutare il buon funzionamento dello stesso.
Si ricorda che l’esperimento è stato svolto utilizzando una potenza di
trasmissione intermedia della radio, per la precisione P A LEV EL = 23. Inoltre
si è impostato uguale a 900 il numero di pacchetti dati inviati da ciascun nodo
verso ogni altro suo vicino.
I grafici riportati nelle figure da 5.2 a 5.7 illustrano gli offset del valore di RSSI
tra le coppie di nodi della rete in funzione del tempo trascorso inteso però come
numero di pacchetti scambiati (ad esempio se il tempo di invio di un pacchetto
è di 64 ms, uno step dell’algoritmo richiede 64 × 4 ms per essere eseguito; quindi
ogni unità sull’asse delle ascisse equivale a circa 300 ms tenendo in
considerazione anche i tempi di attesa e di scrittura dei singoli nodi).
I possibili link di due nodi i, j, che dialogano fra loro sono naturalmente 12 in
una rete di quattro sensori, ma è chiaro che essendo differenze di valori
comunque statici quelle che si vanno a graficare, una metà di questi link
misurano quantità uguali ma opposte in segno all’altra. Ecco spiegato il motivo
per cui vengono illustrati solo gli andamenti degli offset per sei link e non per
tutti quelli possibili.
In ciascun grafico vengono riportati, istante per istante, i valori dell’offset prima
dell’applicazione dell’algoritmo di consensus (colore blu, marker ×) ossia
∆RSSIi←j = RSSI V ALi − RSSI V ALj
e dopo l’esecuzione dello stesso (colore rosso, marker •), cioè i valori di offset
corretti dai vari ôi calcolati
\ i←j = RSSI V ALi + ôi − (RSSI V ALj + ôj ).
∆RSSI
5.1 Risultati ottenuti
35
In tabella 5.1, giusto per avere un’idea, si riportano i valori dei vari ôi definiti
dall’algoritmo per i primi dieci istanti. E’ facile notare come la risoluzione
massima di tali offset di compensazione sia pari a 0.25 dBm, ma ciò è logico dato
che il coefficiente αj descritto nel capitolo precedente è uguale proprio a 1/4.
ô1
2.25
1.75
2.25
2.75
2.50
3.00
2.75
3.25
2.75
2.75
ô2
0.75
0.75
1.00
1.25
1.25
0.75
1.00
0.75
1.25
0.75
ô3
-4.25
-3.50
-4.50
-4.25
-4.25
-4.00
-4.25
-4.25
-4.50
-3.75
ô4
1.25
1.00
1.25
0.25
0.50
0.25
0.50
0.25
0.50
0.25
Tabella 5.1: Valori di ôi calcolati dall’algoritmo nei primi dieci istanti
Esaminando i sei grafici delle figure da 5.2 a 5.7 si possono formulare le
considerazioni che seguono.
\ ossia quelli ottenuti dopo
1. Le costellazioni dei valori di ∆RSSI,
l’esecuzione dell’algoritmo di consenso, si sviluppano nel tempo con
quantità molto più prossime allo zero rispetto a quelle misurate prima
della correzione. Questo è un grande punto a favore. Infatti, come si può
\ risultano essere
notare dalla tabella 5.2, le medie nel tempo dei ∆RSSI
molto minori in valore assoluto rispetto a quelle dei ∆RSSI misurati dai
motes (ad esempio nel link 3 ← 4 si passa da media∆RSSI = 4.489 a
\ = −0.046) e ciò è uno degli scopi principali che si propone
media∆RSSI
l’algoritmo in questione.
Link
1←2
1←3
1←4
2←3
2←4
3←4
Prima del consenso
−1.926
−6.696
−2.278
−5.651
−0.907
4.489
Dopo il consenso
−0.358
0.237
0.121
−0.284
−0.075
−0.046
Tabella 5.2: Medie degli offset di RSSI prima e dopo l’applicazione dell’algoritmo
2. Anche il range in dBm delle costellazione si riduce sensibilmente dopo la
correzione dei dati efettuata con gli offset di compensazione ôi calcolati
dall’algoritmo.
36
Cap. 5. Analisi dei dati
Figura 5.2: Offset RSSI link 1—2
Figura 5.3: Offset RSSI link 1—3
5.1 Risultati ottenuti
37
Figura 5.4: Offset RSSI link 1—4
Figura 5.5: Offset RSSI link 2—3
38
Cap. 5. Analisi dei dati
Figura 5.6: Offset RSSI link 2—4
Figura 5.7: Offset RSSI link 3—4
5.1 Risultati ottenuti
39
Ad esempio in figura 5.5 si nota come si passa da un range di ∆RSSI di
\ di circa 4 dBm, oppure in figura 5.6 da
circa 8 dBm a quello di ∆RSSI
\ ' 5. Approssimativamente si
range∆RSSI ' 10 dBm a range∆RSSI
può dire che il range delle differenze di RSSI tra due nodi i, j si dimezza
con l’utilizzo dei dati proposti dal consenso.
3. L’unico punto a sfavore dell’algoritmo è che i valori corretti, ossia quelli di
\ non risultano avere una buona continuità nel tempo. Cercando
∆RSSI,
\ calcolati in istanti successivi
di spiegarsi meglio, valori di ∆RSSI
differiscono con maggior fraquenza rispetto a quelli di ∆RSSI. Si prenda
ad esempio la figura 5.7 (link 3 ← 4); si nota subito come l’offset non
corretto rimanga per molti istanti fisso a 4 dBm, mentre quello corretto
dall’algoritmo non si fissi mai su un certo valore, pur migliorando
nettamente media e range della costellazione.
La causa principale di questa nota sta nel fatto che l’algoritmo di consenso
lavora mediando i dati che un nodo i scambia con tutti i suoi vicini e non
con uno solo di essi. Bisogna sempre ricordare infatti che è stato studiato
in modo tale da azzerare la somma degli offset che si creano tra un nodo e
i suoi vicini. Dalla figura 5.8 si può intuire meglio questa realtà oggettiva.
Se un nodo i comunica con tre nodi A, B, C, si riscontrano valori di offset
Figura 5.8: Nodo i che comunica con i vicini
di RSSI pari a
∆RSSIi,j = RSSIi − RSSIj
con j = A, B, C. Dopo l’esecuzione dell’algoritmo del consenso si trovano
tre valori di
\ i,j = RSSI
\ i − RSSI
\j
∆RSSI
40
Cap. 5. Analisi dei dati
\ i = RSSIi + ôi .
dove, come già spiegato in precedenza, RSSI
L’algoritmo è studiato in modo da far sı̀ che:
X
\ i,j = 0
∆RSSI
(5.1)
j=A,B,C
istante per istante, ed a ciò esso si attiene con precisione.
Dopo queste osservazioni si può infine ritenere che l’algoritmo sviluppato risolva
in modo più che sufficiente il problema dell’offset del valore di RSSI tra i nodi di
una WSN, almeno per quel che riguarda la connessione tra coppie i, j di sensori.
5.2
Il problema dei cicli
Arrivati a questo punto della tesi si passa ad esaminare il buon funzionamento
dell’algoritmo sviluppato mediante la verifica dei risultati che si ottengono sui
cicli chiusi della rete di sensori.
Figura 5.9: Schema stilizzato ciclo n◦ 1
Per ciclo si intende una qualsiasi sequenza chiusa di nodi in grado di
comunicare fra loro. E’ chiaro che in una rete di quattro sensori tutti fra di loro
connessi, tali sequenze, percorse in un verso solo, sono in numero pari a 7, tre
formate da tutti i motes e quattro formate solo da tre motes (si escludono
dall’analisi i cicli di due nodi perchè degenerano a semplici links di cui si è già
discusso nella sezione precedente). In figura 5.9 si riporta in modo stilizzato per
5.2 Il problema dei cicli
41
facilitarne la comprensione uno di questi cicli composto dalla sequenza di nodi
1 → 2 → 3 → 4 → 1.
Nel capitolo 4, l’equazione 4.4 proponeve come scopo dell’algoritmo studiato che
la somma delle differenze di RSSI in un ciclo di nodi comunicanti fosse il più
possibile prossima allo zero. Ebbene in tabella 5.3 sono riportate le medie nel
tempo delle somme dei quadrati di tali differenze, ossia
P
2
media temporale di
ciclo (∆RSSI)
eseguite per tutti i sette possibili cicli sia prima che dopo l’applicazione
dell’algoritmo. Si è scelto di utilizzare l’elevazione al quadrato per ottenere tutti
valori positivi che valgono quindi come indice di bontà dell’algoritmo.
N◦ ciclo
1
2
3
4
5
6
7
Sequenza dei nodi
1→2→3→4→1
1→2→4→3→1
1→3→2→4→1
1→2→3→1
1→2→4→1
1→3→4→1
2→3→4→2
2
ciclo (∆RSSI)
P
68.29
74.00
91.02
83.88
15.95
76.70
56.78
\ 2
ciclo (∆RSSI)
P
3.89
3.31
3.69
2.44
2.88
3.20
2.37
Tabella 5.3: Medie delle somme dei quadrati delle differenze di RSSI eseguite sui
cicli
Dalla tabella e dal grafico in figura 5.10, dove sono semplicemente illustrati i
dati della stessa (prima dell’applicazione del consenso in blu, dopo
l’applicazione in rosso), si possono notare gli enormi miglioramenti che apporta
la tecnica del consensus agli offset di RSSI su tutti i cicli della WSN. E’ chiaro
che essendo progettato come spiegato nella sezione precedente, l’algoritmo non
\ sui cicli, ma ne consente
garantisce l’annullamento della somma dei ∆RSSI
senza dubbio una drastica diminuzione.
Detto ciò si può concludere che il metodo del consenso si rende oggettivamente
valido sia per quanto rigurada il singolo link di due nodi, sia per il
comportamento globale che assume su tutta la rete.
42
Cap. 5. Analisi dei dati
Figura 5.10: Medie delle somme dei quadrati delle differenze di RSSI eseguite sui
cicli
Capitolo 6
Conclusioni e studi futuri
Alla luce di quanto esposto in questa tesi emerge con chiarezza la notevole
importanza che acquisisce il valore di Received Signal Strength Indicator in una
rete di sensori wireless. Tale valore, più conosciuto con la sigla RSSI, è un indice
fornito dalla radio di ciascun nodo di una WSN che permette, mediante la
semplice aggiunta di un certo offset, il calcolo dellla potenza del campo elettrico
del segnale. Quest’ultimo, detto RSS, viene utilizzato da diversi algoritmi di
localizzazione i quali sfruttano il fatto che esso sia direttamente legato alla
distanza tra il nodo che trasmette e quello che riceve.
Purtroppo, però, si è verificato che il valore di RSSI non è molto affidabile,
specie in ambiente indoor, poichè affetto da disturbi di varia natura che ne
falsano la precisa acquisizione. Si è quindi reso necessario lo sviluppo di un
software in grado di eseguire la calibrazione di tale valore in una rete di sensori
distribuiti.
A questo scopo si è proposto un algoritmo di consensus capace di apprendere
una visione di insieme della rete in questione e calcolare in pochi semplici passi
un valore di offset da aggiungere istante per istante all’RSSI fornito da ciascun
nodo e renderlo cosı̀ molto più robusto alle alterazioni indotte dall’ambiente in
cui si sviluppa la WSN.
Partendo dal presupposto che due motes, posti alla stessa distanza, devono
fornire lo stesso valore di RSSI, e verificato che ciò non è sempre corretto, si è
dimostrato che l’algoritmo in questione apporta notevoli miglioramenti se
applicato alla rete, riducendo drasticamente l’offset che si crea appunto tra
l’RSSI di un nodo e quello di un suo vicino. Inoltre si è constatata la
funzionalità globale del software sviluppato con l’analisi dei cicli di nodi, ed
anche in questo caso esso si è rivelato una scelta vincente.
Si può quindi concludere che lo schema del consensus soddisfa in modo più che
buono le specifiche del progetto proposto, e si può quindi ritenere un ottimo
mezzo per eseguire la calibrazione di un certo parametro, quale l’RSSI, affetto
da offset in una wireless sensors network.
E’ chiaro che l’algoritmo finora descritto in questo elaborato è da ritenersi
44
Cap. 6. Conclusioni e studi futuri
tuttora in fase sperimentale. Esso, infatti, come già spiegato in precedenza, è
stato progettato ad hoc per una rete di soli quattro Tmote Sky. In primo luogo
si propone quindi come lavoro futuro un ampliamento del software per renderlo
più general purpose, cioè adattabile ad ogni tipo di rete, ed autoconfigurante,
ossia in grado di modificare da solo i propri parametri di calcolo qualora nella
rete accadano eventi non programmati quali malfunzionamenti o aggiunte di
nodi.
Inoltre è da sviluppare ancora tutto il codice in TinyOS per l’implementazione
dell’algoritmo sui sensori. Tale lavoro renderebbe possibile, almeno in linea
teorica, l’esecuzione di una calibrazione dell’RSSI in real time, sfruttando le
capacità di calcolo del chip MSP430. A quel punto non resterebbe che applicare
lo schema del consensus ad algoritmi complessi di localizzazione per verificare gli
effettivi miglioramenti che si verrebbero ad apportare alle stime delle distanze.
Quest’ultima affermazione, purtroppo, non è accertabile con il lavoro svolto fino
ad ora, ma è possibile almeno intuirne la veridicità... del resto anche Einstein
era sicuro che la teoria della relatività fosse esatta molto tempo prima di
riuscire a dimostrarla.
Appendice A
Algoritmo di analisi della
connessione
Per l’analisi della connessione e la raccolta dei dati di interesse si è utilizzato un
algoritmo proposto in [2] modificato e d adattato ai scopi della tesi.
Il file Config.h è il file di configurazione della rete. In esso vengono settati tutti i
tempi di trasmissione, il numero dei nodi della rete, quello dei pacchetti da
scambiare ed alto.
Il file BaseStation.nc è il corpo principale del software in TinyOS da caricare sul
mote che funge da base-station per l’appunto e quindi scandisce i tempi di
trasmissione e ricezione dei nodi.
Nel file PeerC.nc è contenuto il codice centrale del software da caricare sui nodi
veri e propri della rete. Quando i nodi terminano i cicli di scambio di pacchetti
è necessario collegarli al PC tramite porta USB e caricare il programma Lettura
in [2]. Quindi attraverso una stringa di comando si legge la flash dei sensori e si
traducono i dati in ciò che interessa lanciando il file letture.java anch’esso
presente in [2].
A.1
Config.h
#ifndef CONFIG_H
/**************************************************************
* Application: Config.h
*
* Description: Configurazione per il test della connettivit~
A
*
* Date:
14/12/2007
*
* Autore:
Simone Cieno
*
***************************************************************/
#define CONFIG_H
enum{
channelRadio = 15,
numNodi = 2,//numero di nodi, eclusa la BaseStation
numPkg = 160,//numero di pacchetti che ogni nodo spedisce
46
App. A. Algoritmo di analisi della connessione
numCicli = 20,//numero di cicli di rilevazione
AM_SERIAL = 9,
AM_RADIO = 6,
TIMER_SEND = 64,//tempo tra l’invio di due pacchetti
TIMER_GLOBALE = 26000,//22800, //TIMER_INVIO*numeNodi
// tempo di durata di un ciclo
TIMER_INVIO = 13000,//TIMER_SEND*numPkg minimo tempo per
//l’invio dei pacchetti da parte di un nodo
code_chiamata = 1,
code_stop = 2,
code_pacchetto = 3,
code_erase = 4,
};
typedef struct pacchetto{//pacchetto che effettivamente si invia
nx_uint8_t code;//codice identidicatico del pacchetto
nx_uint16_t nCiclo;//numero del ciclo di raccolta dati
nx_uint8_t wtx;//identificatico del nodo che trasmette
//nx_uint8_t battery;//livello di tensione del nodo che trasmette
nx_uint8_t ptx;//potenza di trasmissione
} pacchetto;
typedef struct asignal{
nx_uint8_t code;//codice identidicatico del pacchetto
nx_uint16_t nCiclo;//numero del ciclo di raccolta dati
nx_uint8_t wtx;//identificatico del nodo che deve trasmettere
} asignal;
typedef struct store{
nx_uint8_t nCiclo;//numero del ciclo di raccolta dati
nx_uint8_t ptx;//potenza di trasmissione
//nx_uint8_t Mybattery;//livello di tensione del nodo che trasmette
//nx_uint8_t Mytemp;//livello di temperatura del nodo che trasmette
//nx_uint8_t battery;//livello di tensione del nodo che trasmette
uint8_t lqi;
int8_t rssi;
nx_uint8_t wtx;//identificatico del nodo che trasmette (Who Transmitt)
} store;
#endif
A.2 BaseStationC.nc
A.2
47
BaseStationC.nc
/************************************************************
* Application: BaseStationC.nc
*
~
* Description: Applicazione per il test della connettivitA
*
* Date:
08/10/2007
*
* Autore:
Simone Cieno
*
*************************************************************/
/**
Funzionamento del protocollo:La basestation scandisce i tempi verso
gli altri nodi (peers).Il numero dei nodi ~
A¨ definito nel file di
configurazione, come i tempi dei timer, il canale radio...
All’avvio della basestation, questa invia per prima cosa un messaggio
in broadcast che segnala ad ogni nodo che ~
A¨ il momento di cancellare
la memoria flash;Inolte viene fatto partire il timer globale.Quando il
timerGlobale segnale lo scatto, ciclo numero 1, viene spedito il primo
pacchetto che segnala al nodo n^
A◦ 1 che deve trasmettere e si avvia
anche il timerInvio.
Allo scadere del timer invio, il nodo 2 dovr~
A trasmettere e cosi via.
Quando l’ultimo nodo ha trasmesso, viene fermato il timerInvio e si
resta in attesa dello scoccare del timer globale.Quando sono stati
eseguiti tutti i cicli, allora anche il TimerGlobale viene fermato.
**/
#include <Timer.h>
#include "Config.h"
module
uses
uses
uses
uses
uses
uses
uses
uses
}
BaseStationC {
interface Boot;
interface Leds;
interface Timer<TMilli> as TimerInvio;
interface Timer<TMilli> as TimerGlobale;
interface Packet;
interface AMSend;
interface SplitControl as AMControl;
interface CC2420Config;
implementation {
enum
{
CONFIG_ADDR = 0
};
bool busy;//stato della radio
48
App. A. Algoritmo di analisi della connessione
message_t pkg;
uint8_t whotx;//id del nodo che deve trasmettere
uint16_t ciclo;//numero di ciclo
event void Boot.booted() {
busy= FALSE;
whotx=0;
ciclo=0;
call CC2420Config.setChannel(channelRadio);
call CC2420Config.sync();
}
/**Task che manda un pacchetto di avviso, con l’intento di segnalare
ad ogni nodo che devono cancellare la flash**/
task void eraser() {
if(!busy){
asignal* sig=(asignal*)(call Packet.getPayload(&pkg,NULL));
sig->code=code_erase;
//call Leds.set(1);
sig->nCiclo=ciclo;
sig->wtx=whotx;
call TimerGlobale.startPeriodic(TIMER_GLOBALE);
if(call AMSend.send(AM_BROADCAST_ADDR,&pkg,
sizeof(asignal))==SUCCESS) {
busy=TRUE;
//call Leds.led0On();//segnalo l’invio con il led rosso
}
}
}
task void primoInvio(){
call TimerInvio.startPeriodic(TIMER_INVIO);
if(!busy){
asignal* sig=(asignal*)(call Packet.getPayload(&pkg,NULL));
sig->code=code_chiamata;
sig->nCiclo=ciclo;
sig->wtx=whotx;
if(call AMSend.send(AM_BROADCAST_ADDR,&pkg,
sizeof(asignal))==SUCCESS) {
busy=TRUE;
//call Leds.set(3);
//call Leds.led2On();
}
whotx++;
}
A.2 BaseStationC.nc
49
}
task void trasmissione(){
if(!busy){
asignal* sig=(asignal*)(call Packet.getPayload(&pkg,NULL));
sig->code=code_chiamata;
sig->nCiclo=ciclo;
sig->wtx=whotx;
//call Leds.set(whotx);
if(call AMSend.send(AM_BROADCAST_ADDR,&pkg,
sizeof(asignal))==SUCCESS) {
busy=TRUE;
//call Leds.set(3);
//call Leds.led2On();
}
whotx++;
if(whotx > numNodi){call TimerInvio.stop();}//se ~
A¨ l’ultimo nodo,
fermo il timer
}
}
event void CC2420Config.syncDone( error_t error ) {
call AMControl.start();
}
event void AMControl.startDone(error_t err) { // componentistica
Mote accesa
if(err != SUCCESS)
call AMControl.start();
else{
//call Leds.set(101);
//call TimerGlobale.startPeriodic(TIMER_GLOBALE);//faccio
partire il timer globale
post eraser();//posto il task che permette di cancellare le flash
}
}
event void TimerGlobale.fired() {
//call Leds.set(0);
whotx=1;
call Leds.set(whotx);
ciclo++;//incremento il numero di ciclo di raccolta dati
if(ciclo > numCicli){
call TimerGlobale.stop();
call AMControl.stop();
50
App. A. Algoritmo di analisi della connessione
//call Leds.set(111);
}
post primoInvio();//posto il task per il primo invio
}
event void TimerInvio.fired() {
call Leds.set(whotx);
if((whotx <= numNodi) && (!busy)){//se chi deve trasmettere "esiste"
post trasmissione();
}
}
event void AMControl.stopDone(error_t err) {
}
event void AMSend.sendDone(message_t* msg, error_t error) {
busy= FALSE;//segno che la radio ~
A¨ libera
//call Leds.led2Off();
//call Leds.set(0);//azzero le segnalazioni
//call Leds.set(ciclo);//segno il numero di ciclo
}
}
A.3
PeerC.h
/************************************************************
* Application: PeerC.nc
*
~
* Description: Applicazione per il test della connettivitA
*
* Date:
14/12/2007
*
* Autore:
Simone Cieno
*
*************************************************************/
/**
Funzionamento:All’avvio i peers sono in solo ascolto.All’arrivo di un
pacchetto fanno distinzione del tipo, cio~
A¨ se ~
A¨ un pacchetto di segnala
zione, che puo significare una richiesta di cancellazione, di inizio
trasmissione o di fine trasmissione, oppure un pacchetto dati.
In base al pacchetto arrivato vengono svolti i vari task.Una volta ricevuto un pacchetto di segnalazione, questo viene anche mandato in
A.3 PeerC.h
51
flooding, e "segnando" il pacchetto ricevuto.In questo modo non vengono
mandati pacchetti duplicati e si lascia il canale il piu possibile libe
ro.
Funzionamento del flooding:Quando ricevo un pacchetto (di tipo aSignal)
controllo se ~
A¨ il pacchetto piu recente ricevuto(di quel tipo).In tal
caso memorizzo l’informazione e mando in broadcast il pacchetto.Se il
pacchetto ricevuto non ~
A¨ "piu recente" dell’ultimo ricevuto, allora
scarto il pacchetto.
Quando un nodo deve trasmettere la sua serie di pacchetti, viene man
datoun burst di pacchetti, uno ogni TIMER_SEND.
**/
#include <Timer.h>
#include "Config.h"
#include "StorageVolumes.h"
#include "message.h"
module PeerC
{
uses
{
interface Boot;
interface Leds;
interface SplitControl as AMControl;
interface Timer<TMilli> as TimerSend; // Timer per inoltro pkt
dati quando scatta spedisco un pacchetto
interface BlockWrite as Write; // scrive in flash
interface Packet;
interface AMSend as AMSendPacchetti; // Send per inoltro sequenza dati
interface AMSend as AMSendFlooding; // Send per flooding
interface Receive;
interface CC2420Packet as SetRadio; // per avere LQI e RSSI della
trasmissione
interface AMPacket;
interface Packet as PacketSpedisco;
interface CC2420Config; // modifica canale radio
}
}
implementation {
enum {
CONFIG_ADDR = 0,// indirizzo di partenza per scrittura in flash
};
bool busy;//stato della radio
bool erased;
52
App. A. Algoritmo di analisi della connessione
bool flood;//per sapere se ho effettuato il flooding della /*fine
*/ trasmissione
message_t pacchet;
message_t segnalazione;
asignal sig;
pacchetto dati;
store ricevuti[numPkg];//salvo i pacchetti ricevuti prima di fare store
uint8_t i;//conta i pacchetti ricevuti
uint32_t j;
//uint8_t valBat;
//uint8_t valTemperature;
uint16_t tmpCiclo;
uint8_t lftx =0;//ultimo flooding trasmesso (last flooding transmitt)
uint8_t potenza;
uint8_t powerstate=1;//contatore x segnare quanti pkg per livello di
potenza ho inviato
event void Boot.booted() {
call CC2420Config.setChannel((uint8_t)channelRadio); // setto il
canale della radio
call CC2420Config.sync(); // applico la modifica al canale radio
busy = FALSE;
erased=FALSE;
flood=FALSE;
tmpCiclo=0;
i=0;
j=0;
potenza=23;
//call ReadVoltage.read(); // lettura livello batteria
//call ReadTemperature.read(); // lettura temperatura
}
event void CC2420Config.syncDone( error_t error ) {
//call Leds.set(111);
call AMControl.start();
}
event void AMControl.startDone(error_t error) {
//call Leds.set(0);
}
/**task per formattare la flash del mote **/
task void cancellazione(){
asignal* era=(asignal*)(call Packet.getPayload(&segnalazione,NULL));
//call Leds.set(sig.code);
A.3 PeerC.h
53
if(!erased){
call Write.erase();
atomic{erased=TRUE;}
era->code=sig.code;
era->nCiclo=sig.nCiclo;
era->wtx=sig.wtx;
//call Leds.set(era->code);
if(call AMSendFlooding.send(AM_BROADCAST_ADDR,&segnalazione,
sizeof(asignal))==SUCCESS)
atomic{busy=TRUE;}
}
}
/** alla ricezione di un pacchetto si segnalazione che indica che
nodo deve trasmettere, controllo il numero di ciclo.se il numero di
ciclo ~
A¨ piu recente di quello precedentemente memorizzato, lo aggiorno;Ora controllo se tocca a me spedire la mia serie di pacchetti(in tal caso avvio il timer), altrimenti faccio flooding di quella chiamata, stando attento ad inoltrare una sola volta il pacchetto di flooding**/
task void chiamata(){
asignal* tel=(asignal*)(call Packet.getPayload(&segnalazione,NULL));
if(tmpCiclo <= sig.nCiclo){
tmpCiclo=sig.nCiclo;
if((sig.wtx==TOS_NODE_ID)&&(!(call TimerSend.isRunning()))){
//se tocca a me spedisco i miei pacchetti
powerstate=1;
potenza=23;
call TimerSend.startPeriodic(TIMER_SEND);}
else if(sig.wtx!=TOS_NODE_ID){//altrimenti mando in flooding
il pacchetto
if((!busy)&&(sig.wtx!=lftx)){//se la radio ~
A¨ libera e
se non ho ancora trasmesso quel flooding
tel->code=sig.code;
tel->nCiclo=sig.nCiclo;
tel->wtx=sig.wtx;
if(call AMSendFlooding.send(AM_BROADCAST_ADDR,
&segnalazione,sizeof(asignal))==SUCCESS)
atomic{busy=TRUE;lftx=sig.wtx;}
}
}
}
}
/** ricevuto l’avviso di fine trasmissione, salvo i dati sulla flash**/
task void finetrasmissione(){
54
App. A. Algoritmo di analisi della connessione
if(!flood){
asignal* fine=(asignal*)(call Packet.getPayload
(&segnalazione,NULL));
fine->code=sig.code;
fine->nCiclo=sig.nCiclo;
fine->wtx=sig.wtx;
if(call AMSendFlooding.send(AM_BROADCAST_ADDR,&segnalazione,
sizeof(asignal))==SUCCESS)
atomic{busy=TRUE;flood=TRUE;}
}
call Write.write(CONFIG_ADDR+(j)*sizeof(store),&(ricevuti[0]),
(i)*sizeof(store));
j+=i;
call Leds.led0On();
potenza=23;
powerstate=1;
i=0;
}
/** RICEZIONE : il mote, in standby, ascolta la radio. Quando arriva un
messaggio lo selezione prima in base alla dimensione, poi controlla il
codice che lo contraddistingue */
event message_t* Receive.receive(message_t* msg, void* payload,
uint8_t len) {
call Leds.led2Off();
call Leds.led1Toggle();//se ricevo lampeggia il led verde
if(len == sizeof(asignal)){
asignal* ss=(asignal*)payload;
sig.code=ss->code;
sig.nCiclo=ss->nCiclo;
sig.wtx=ss->wtx;
//call Leds.set(sig.code);
if(ss->code==code_erase){//se ~
A¨ il pacchetto che segnala la
cancellazione della flash
post cancellazione();
}
else if(ss->code==code_chiamata){
post chiamata();
atomic{flood=FALSE;i=0;}//pongo i=0 per sicurezza
}
else if(ss->code==code_stop){
if((ss->wtx!=TOS_NODE_ID)&&(!flood)) post
finetrasmissione();//se non avevoo mandato
io il code_stop
else if(!flood){
A.3 PeerC.h
55
asignal* fine=(asignal*)(call Packet.getPayload
(&segnalazione,NULL));
fine->code=sig.code;
fine->nCiclo=sig.nCiclo;
fine->wtx=sig.wtx;
if(call AMSendFlooding.send(AM_BROADCAST_ADDR,
&segnalazione,sizeof(asignal))==SUCCESS)
atomic{busy=TRUE;flood=TRUE;}
}
}
}
else if(len == sizeof(pacchetto)){
dati=*((pacchetto*)payload);
ricevuti[i].nCiclo=(uint8_t)(dati.nCiclo);
/** attenzione 16 -> 8 byte**/
ricevuti[i].ptx=dati.ptx;
//ricevuti[i].Mybattery=valBat;
//ricevuti[i].Mytemp=valTemperature;
//ricevuti[i].battery=dati.battery;
ricevuti[i].lqi=call SetRadio.getLqi(msg);
ricevuti[i].rssi=call SetRadio.getRssi(msg);
ricevuti[i].wtx=dati.wtx;
i++;
}
return msg;
}
event void Write.writeDone(storage_addr_t addr, void* buf,
storage_len_t len,
error_t error) {
call Write.sync(); // assicuro la permanenza della scrittura in flash
}
event void TimerSend.fired() {
// invio un pkt dato ogni TIMER_PERIOD_MILLI millisecondi
call Leds.led1Off();
call Leds.led2Toggle();//quando invio lampeggia il led blu
if(powerstate>=numPkg) {
asignal* ftx=(asignal*)(call Packet.getPayload(&segnalazione,NULL));
ftx->code=code_stop;
ftx->nCiclo=sig.nCiclo;
ftx->wtx=TOS_NODE_ID;
call TimerSend.stop();
56
App. A. Algoritmo di analisi della connessione
if(!busy){
if(call AMSendFlooding.send(AM_BROADCAST_ADDR,&segnalazione,
sizeof(asignal))==SUCCESS)
atomic{busy=TRUE;}
}
}
else if(!busy){
pacchetto* pkg=(pacchetto*)(call Packet.getPayload(&pacchet,NULL));
pkg->code=code_pacchetto;
pkg->nCiclo=tmpCiclo;
pkg->wtx=TOS_NODE_ID;;
//pkg->battery=valBat;
//pkg->ptx=potenza;
switch (powerstate){//seleziono la potenza di trasmissione
case 20:potenza=27;break;
case 40:potenza=23;break;
case 60:potenza=19;break;
case 80:potenza=15;break;
case 100:potenza=11;break;
case 120:potenza=7;break;
case 140:potenza=3;break;
case 160:potenza=31;break;
default: break;
}
call SetRadio.setPower((message_t*)&pacchet,potenza);//setto la
potenza della radio
pkg->ptx=(uint8_t)(call SetRadio.getPower((message_t*)&pacchet));
if(call AMSendPacchetti.send(AM_BROADCAST_ADDR,&pacchet,
sizeof(pacchetto))==SUCCESS){//spedisco
atomic{busy=TRUE;}
}
powerstate++;//segno che ho inviato un altro pacchetto
}
}
event void AMSendFlooding.sendDone(message_t* msg, error_t error) {
//call Leds.set(0);
busy=FALSE;
}
A.3 PeerC.h
57
event void AMSendPacchetti.sendDone(message_t* msg, error_t error) {
busy=FALSE;
}
event void AMControl.stopDone(error_t error) {
}
event void Write.eraseDone(error_t error) {
//call Leds.led0Off();
//call Leds.led2Off();
//call Leds.set(0);
}
event void Write.syncDone(error_t error) {
call Leds.led0Off();
}
/******************************* Seriale **************************/
/* Task per l’invio dei messaggi alla porta seriale */
task void sendSerialMsg()
{
if(lockedSerial){}
else
{
serial_msg toSend = call QueuePing.dequeue();
serial_msg* rsm = (serial_msg*)call Packet.getPayload(&packet, NULL);
atomic
{
rsm->wtx = toSend.wtx;
rsm->nCiclo = toSend.nCiclo;
rsm->rssi
= toSend.rssi;
// rsm->rss
= toSend.rss;
rsm->lqi
= toSend.lqi;
// rsm->channel = toSend.channel;
rsm->ptx
= toSend.ptx;
}
58
App. A. Algoritmo di analisi della connessione
if (call AMSendToSerial.send(AM_BROADCAST_ADDR, &packet,
sizeof(serial_msg)) == SUCCESS)
{
lockedSerial = TRUE;
}
}
if(!(call QueuePing.empty()))
post sendSerialMsg();
else
call Leds.set(ZERO);
}
/* Evento che segnala l’invio corretto di un mess alla seriale */
event void AMSendToSerial.sendDone(message_t* msg, error_t error)
{
if (&packet == msg)
{
lockedSerial = FALSE;
call Leds.led0Toggle();
}
}
}
Appendice B
Algoritmo di consenso
I files di lettura .txt dove sono memorizzati i valori di RSSI dei nodi devono
essere rinomimati in questo modo:
S n◦ nodo sorgentemoten◦ nodo in esame
Ad esempio il file S1 mote2.txt è il file contenete i valori forniti dal nodo2
calcolati sul segnale ricevuto dal nodo1.
Poi questi file devono essere importati come variabili nel workspace di
MATLAB. In questa tesi basta importare il file variabiliIn.mat. A questo punto
si può lanciare dal command window di Matlab l’applicazione consenso.m dove
è sviluppapo l’algoritmo di consenso.
B.1
consenso.m
%%% Algoritmo di sincronizzazione dell’RSSI dei nodi di una WSN %%%
%****************************************
% APPLICATION: consenso.m
*
% DATE:
14/11/2007
*
% AUTHOR :
Simone Cieno
*
% E-MAIL:
[email protected]
*
%****************************************
% L’applicazione serve per sincronizzare il valore dell’RSSI in ogni
% istante da ciascun nodo di una qualsiasi rete di sensori wireless.
% L’applicazione è realizzata ad hoc per una rete formata da 4 sensori.
% Nel caso si voglia applicare l’algoritmo ad una rete con un numero di
% nodi superiori è necessario aggiornare la variabile "degree" che è il
% numero di vicini con cui ogni nodo comunica ed aggiungere per ogni
%matrice costruita all’interno del programma una riga ed una colonna.
% L’applicazione carica in una matrice di input "y" i valori dell’RSSI
60
App. B. Algoritmo di consenso
% di ciascun nodo.La matrice è cosı̀ costruita:
% riga i-esima: RSSI ricevuto da nodo i-esimo relativo a nodo j-esimo
% dove j è il numero della colonna associata.
%
%
%
%
L’applicazione esegue quindi il calcolo di un offset (ocap) da sommare in ogni istante k al nodo contrassegnato per compensare l’erro
re di misura esistente tra ogni coppia i-j. Il calcolo di tale offset
viene eseguito tramite l’utilizzo dell’algoritmo "Metropolis weigth"
% La matrice "ocap" è la mia matrice di uscita ossia quella con su ogni
% riga i valori di offset da sommare ai 4 nodi per ogni istante (riga1->
% istante1 ecc...)
%************************************************************************
degree = 3; % n◦ nodi vicini
%%% Inizializzo a zero le variabili ocap e le pongo sulla prima riga del%%% la matrice ocap
ocap(1,1)=0;
ocap(1,2)=0;
ocap(1,3)=0;
ocap(1,4)=0;
alfaj=1/(1+degree); % parametro derivato da Metropolis Weigth
%%% Variabili usate per eseguire delle medie alla fine
sumocap1=0;
sumocap2=0;
sumocap3=0;
sumocap4=0;
for k=1:900
% k= numero dei pkg su cui lavoro
y1from2 = S2_mote1(k,1);
y1from3 = S3_mote1(k,1);
y1from4 = S4_mote1(k,1);
% rssi ricevuti dal nodo 1
% Sx_mote1 nome del file in cui ho i pkg
% del nodo1 ricevuti dal nodo x
y2from1 = S1_mote2(k,1);
y2from3 = S3_mote2(k,1);
y2from4 = S4_mote2(k,1);
% rssi ricevuti dal nodo 2
y3from1 = S1_mote3(k,1);
y3from2 = S2_mote3(k,1);
y3from4 = S4_mote3(k,1);
% rssi ricevuti dal nodo 3
y4from1 = S1_mote4(k,1);
B.1 consenso.m
61
y4from2 = S2_mote4(k,1);
y4from3 = S3_mote4(k,1);
% rssi ricevuti dal nodo 4
%%%%%% MATRICE INGRESSI %%%%%%%%%
y=[0 y1from2 y1from3 y1from4;
y2from1 0 y2from3 y2from4;
y3from1 y3from2 0 y3from4;
y4from1 y4from2 y4from3 0];
o12=y1from2-y2from1;
o13=y1from3-y3from1;
o14=y1from4-y4from1;
% offset rssi relativo al nodo1
% serve solo a fini di controllo
o21=y2from1-y1from2;
o23=y2from3-y3from2;
o24=y2from4-y4from2;
% offset rssi relativo al nodo2
o31=y3from1-y1from3;
o32=y3from2-y2from3;
o34=y3from4-y4from3;
% offset rssi relativo al nodo3
o41=y4from1-y1from4;
o42=y4from2-y2from4;
% offset rssi relativo al nodo4
o43=y4from3-y3from4;
%%%%%% MATRICE OFFSET Oi %%%%%%%%%
o=[o12 o13 o14;
o21 o23 o24;
o31 o32 o34;
o41 o42 o43];
%%% Calcolo degli offset da sommare ad ogni nodo ---> ALGORITMO
%%% DI CONSENSUS
%*******************************************************************
ocap1= ocap(k,1)+ alfaj*[(y(2,1)+ocap(k,2)- y(1,2)-ocap(k,1)) + (y(3,1)+
ocap(k,3)- y(1,3)-ocap(k,1)) + (y(4,1)+ocap(k,4)- y(1,4)-ocap(k,1))];
ocap2= ocap(k,2)+ alfaj*[(y(1,2)+ocap(k,1)- y(2,1)-ocap(k,2)) + (y(3,2)+
ocap(k,3)- y(2,3)-ocap(k,2)) + (y(4,2)+ocap(k,4)- y(2,4)-ocap(k,2))];
ocap3= ocap(k,3)+ alfaj*[(y(1,3)+ocap(k,1)- y(3,1)-ocap(k,3)) + (y(2,3)+
ocap(k,2)- y(3,2)-ocap(k,3)) + (y(4,3)+ocap(k,4)- y(3,4)-ocap(k,3))];
ocap4= ocap(k,4)+ alfaj*[(y(1,4)+ocap(k,1)- y(4,1)-ocap(k,4)) + (y(2,4)+
ocap(k,2)- y(4,2)-ocap(k,4)) + (y(3,4)+ocap(k,3)- y(4,3)-ocap(k,4))];
%*******************************************************************
%%% pongo gli ocap calcolati su una nuova riga della matrice ocap
ocap(k+1,1)=ocap1;
62
App. B. Algoritmo di consenso
ocap(k+1,2)=ocap2;
ocap(k+1,3)=ocap3;
ocap(k+1,4)=ocap4;
%%% aggiorno la somma (per poter eseguire una media alla fine)
sumocap1=sumocap1+ocap1;
sumocap2=sumocap2+ocap2;
sumocap3=sumocap3+ocap3;
sumocap4=sumocap4+ocap4;
%*******************************************************************
%%% calcolo i nuovi valori di RSSI stimati, ossia quello corretti
y1from2Stim = y1from2 + ocap1;
y1from3Stim = y1from3 + ocap1; %rssi ricevuti dal nodo 1 corretti
y1from4Stim = y1from4 + ocap1;
y2from1Stim = y2from1 + ocap2;
y2from3Stim = y2from3 + ocap2;
y2from4Stim = y2from4 + ocap2;
%rssi ricevuti dal nodo 2 corretti
y3from1Stim = y3from1 + ocap3;
y3from2Stim = y3from2 + ocap3;
y3from4Stim = y3from4 + ocap3;
%rssi ricevuti dal nodo 3 corretti
y4from1Stim = y4from1 + ocap4;
y4from2Stim = y4from2 + ocap4; %rssi ricevuti dal nodo 4 corretti
y4from3Stim = y4from3 + ocap4;
%*******************************************************************
%%% PROVE SUI CICLI DI NODI prima e dopo la correzione dell’algori%%% tmo ciclo n◦ 1
sumBef1234(k,1)=(y1from2-y2from1)^2+(y2from3-y3from2)^2+
(y3from4-y4from3)^2+(y4from1-y1from4)^2;
sumAft1234(k,1)=(y1from2Stim-y2from1Stim)^2+(y2from3Stim-y3from2
Stim)^2+(y3from4Stim-y4from3Stim)^2+(y4from1Stim-y1from4Stim)^2;
%%% ciclo n◦ 2
sumBef1243(k,1)=(y1from2-y2from1)^2+(y2from4-y4from2)^2+
(y4from3-y3from4)^2+(y3from1-y1from3)^2;
sumAft1243(k,1)=(y1from2Stim-y2from1Stim)^2+(y2from4Stim-y4from2
Stim)^2+(y4from3Stim-y3from4Stim)^2+(y3from1Stim-y1from3Stim)^2;
%%% ciclo n◦ 3
sumBef1324(k,1)=(y1from3-y3from1)^2+(y3from2-y2from3)^2+
(y2from4-y4from2)^2+(y4from1-y1from4)^2;
sumAft1324(k,1)=(y1from3Stim-y3from1Stim)^2+(y3from2Stim-y2from3
Stim)^2+(y2from4Stim-y4from2Stim)^2+(y4from1Stim-y1from4Stim)^2;
%%% ciclo n◦ 4
B.1 consenso.m
63
sumBef123(k,1)=(y1from2-y2from1)^2+(y2from3-y3from2)^2+
(y3from1-y1from3)^2;
sumAft123(k,1)=(y1from2Stim-y2from1Stim)^2+
(y2from3Stim-y3from2Stim)^2+(y3from1Stim-y1from3Stim)^2;
%%% ciclo n◦ 5
sumBef124(k,1)=(y1from2-y2from1)^2+(y2from4-y4from2)^2+
(y4from1-y1from4)^2;
sumAft124(k,1)=(y1from2Stim-y2from1Stim)^2+
(y2from4Stim-y4from2Stim)^2+(y4from1Stim-y1from4Stim)^2;
%%% ciclo n◦ 6
sumBef134(k,1)=(y1from3-y3from1)^2+(y3from4-y4from3)^2+
(y4from1-y1from4)^2;
sumAft134(k,1)=(y1from3Stim-y3from1Stim)^2+
(y3from4Stim-y4from3Stim)^2+(y4from1Stim-y1from4Stim)^2;
%%% ciclo n◦ 7
sumBef234(k,1)=(y2from3-y3from2)^2+(y3from4-y4from3)^2+
(y4from2-y2from4)^2;
sumAft234(k,1)=(y2from3Stim-y3from2Stim)^2+
(y3from4Stim-y4from3Stim)^2+(y4from2Stim-y2from4Stim)^2;
%*****************************************************************
end
%
%
%
%
%
%
%
%
Calcolo medie dell’ offset calcolato da aggungere a ciascun nodo per
compensare l’errore.
NB: è chiaro che i 4 ocap-i variano per ogni serie di valori di rssi
di ingresso (in pratica per ogni ciclo, ossia per ogni riga della matrice y di input) e quindi la media è solo un valore indicativo ai
fini della lettura, ma non possiamo usarla da aggiungere al singolo
nodo perchè sarebbe troppo limitativo nella compensazione dello
offset.
mediaocap1=sumocap1/k;
mediaocap2=sumocap2/k;
mediaocap3=sumocap3/k;
mediaocap4=sumocap4/k;
Bibliografia
[1] Ing. Davide Di Palma, Wireless Sensor Network (WSN), appunti di lezione
, Università degli Studi di Firenze.
[2] Luca Boscato, Tesi di laurea Analisi sperimentale di connettività e qualità
del segnale per reti di sensori wireless, Università degli Studi di Padova,
2006/2007.
[3] Ferrari, Flammini, Marioli, Sisinni, Taroni Sensori wireless: da wi-fi e
bluetooth verso ZigBee e i nuovi standard emergenti, Dip. Elettronica per
l’Automazione e INFM, Università di Brescia.
[4] MoteIv Corporation, Tmote Sky Datasheet, www.moteiv.com.
[5] Chipcon AS Products, CC2420 Datasheet, www.chipcon.com.
[6] Texas Instruments, MSP430 Datasheet, www.ti.com.
[7] Sensirion AG, SHTxx Datasheet, www.sensirion.com.
[8] Hamamatsu Corporation, S1087 Datasheet, www.hamamatsu.com.
[9] TinyOS operating system, www.tinyos.net.
[10] Gay, Levis, Culler, Brewer, NesC 1.1 Language Reference Manual, Maggio
2003.
[11] Prof. Ruggero Frezza, Stefano Dazzo, Luca Parolini, Riccardo Sala, Il
problema della Localizzazione e dell’Autolocalizzazione in una Rete di
Sensori Wireless, Dip. di Ingegneria dell’Informazione, Università degli
Studi di Padova, 26 Settembre 2006.
[12] Ing. Luca Schenato, appunti di lezione dal corso Progettazione di sistemi di
controllo, Maggio 2007, Università degli Studi di Padova.
[13] Lin Xiao, Stephen Boyd, Sanjay Lall A Scheme for Robust Distribuited
Sensor Fusion Based on Average Consensus.
[14] The MathWorks Inc. , www.mathworks.com.
Elenco delle figure
1
Esempio di WSN per monitorare possibili incendi . . . . . . . . .
4
1.1
1.2
Classificazione delle reti in funzione dell’area coperta . . . . . . .
Classificazione delle topologie di rete . . . . . . . . . . . . . . . .
8
8
2.1
2.2
2.3
le due faccie del Tmote-Sky . . . . . . . . . . . . . . . . . . . . .
Antenna a microstriscia . . . . . . . . . . . . . . . . . . . . . . .
Schema a blocchi del Tmote Sky . . . . . . . . . . . . . . . . . . .
12
14
15
3.1
3.2
3.3
Andamento RSSI rispetto alla potenza del campo elettromegnetico
Raffigurazione stilizzata esperimento I . . . . . . . . . . . . . . .
Offset di RSSI dei nodi variabili rispetto l’RSSI del nodo fisso con
PA LEVEL 23 (prime 20 prove) . . . . . . . . . . . . . . . . . . .
Offset di RSSI dei nodi variabili rispetto l’RSSI del nodo fisso con
PA LEVEL 23 (seconde 20 prove) . . . . . . . . . . . . . . . . . .
Offset di RSSI dei nodi variabili rispetto l’RSSI del nodo fisso con
PA LEVEL 11 (prime 20 prove) . . . . . . . . . . . . . . . . . . .
Offset di RSSI dei nodi variabili rispetto l’RSSI del nodo fisso con
PA LEVEL 11 (seconde 20 prove) . . . . . . . . . . . . . . . . . .
Offset di RSSI del nodo2 rispetto l’RSSI del nodo1 con PA LEVEL
23 (prime 20 misure) . . . . . . . . . . . . . . . . . . . . . . . . .
Offset di RSSI del nodo2 rispetto l’RSSI del nodo1 con PA LEVEL
23 (seconde 20 misure) . . . . . . . . . . . . . . . . . . . . . . . .
Offset di RSSI del nodo2 rispetto l’RSSI del nodo1 con PA LEVEL
11 (prime 20 misure) . . . . . . . . . . . . . . . . . . . . . . . . .
Offset di RSSI del nodo2 rispetto l’RSSI del nodo1 con PA LEVEL
11 (seconde 20 misure) . . . . . . . . . . . . . . . . . . . . . . . .
20
22
Distribuzione dei sensori sul piano
Offset RSSI link 1—2 . . . . . . .
Offset RSSI link 1—3 . . . . . . .
Offset RSSI link 1—4 . . . . . . .
Offset RSSI link 2—3 . . . . . . .
Offset RSSI link 2—4 . . . . . . .
Offset RSSI link 3—4 . . . . . . .
Nodo i che comunica con i vicini .
33
36
36
37
37
38
38
39
3.4
3.5
3.6
3.7
3.8
3.9
3.10
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
terra dell’edificio DEI/A
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
25
25
26
26
27
28
68
ELENCO DELLE FIGURE
5.9 Schema stilizzato ciclo n◦ 1 . . . . . . . . . . . . . . . . . . . . . .
5.10 Medie delle somme dei quadrati delle differenze di RSSI eseguite
sui cicli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
42
Elenco delle tabelle
2.1
Potenza della radio . . . . . . . . . . . . . . . . . . . . . . . . . .
13
5.1
5.2
5.3
Valori di ôi calcolati dall’algoritmo nei primi dieci istanti . . . . . 35
Medie degli offset di RSSI prima e dopo l’applicazione dell’algoritmo 35
Medie delle somme dei quadrati delle differenze di RSSI eseguite
sui cicli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41