Relazione sul progetto di realizzazione di un algoritmo di localizzazione (mediante trilaterazione) attraverso l'utilizzo del controllore cRIO e del software LabVIEW.

1. Misure Elettriche ed Elettroniche
Prof. Bruno Andò
PROGETTO CRIO
Mazza Dario 616/002007
Merlino Sebastiano 616/002008
Messina Marco 616/002000

2. Progetto cRIO
Obiettivi
• Acquisire conoscenze di base sull’apparato hardware.
• Comprendere il funzionamento del sistema software di base.
• Accumulare esperienze a proposito di interfacciamento dell’oggetto con hardware esterno.
• Utilizzare l’oggetto come controllore “stand alone” di sistemi automatici.
• Reimplementare l’algoritmo di trilaterazione utilizzato nel sistema CAN-Bus attualmente
realizzato mediante motore MatLab.
• Ottimizzare l’algoritmo di cui al punto precedente per un funzionamento “stand alone” sul
cRIO.
Generalità
Il cRIO (Compact Reconfigurable I/O) è un microcontrollore real-time programmabile per sistemi
embedded che offre ottime potenzialità come sistema stand alone per l’esecuzione di applicazioni
real-time in LabVIEW. Si trovano all’interno dello chassis
dispositivi FPGA (Field Programmable Gate Array), ovvero
dispositivi digitali la cui funzionalità è programmabile via
software. Esso è utilizzato ampiamente nelle fasi di sviluppo dei
prototipi, in quanto eventuali errori possono essere risolti
semplicemente riconfigurando il dispositivo.
Importante caratteristica del sistema è la sua modularità e grazie
a questa ed alle altre caratteristiche precedentemente elencate
esso va a confluire in quella categoria di sistemi automatici di
misura detti più precisamente SADD (Sistemi di Acquisizione e
Distribuzione Dati).
Il sistema cRIO consta di un’unità centrale (in cui risiede il
Sistema Operativo LabVIEW Real-Time ETS) e di uno chassis
ove è possibile ospitare fino a 8 moduli che estendono le
funzionalità dell’oggetto.
Progetto cRIO | Mazza, Merlino, Messina
FIGURA 1: NI CRIO-9004
Il modello di cRIO a nostra disposizione è il cRIO-9004 la cui
unità centrale include 64MB di memoria DRAM, disponibile per l’esecuzione delle applicazioni, e
512MB di memoria (a tecnologia flash) per l’immagazzinamento dei dati inerenti il software ed il
suo funzionamento.
Il sistema è caratterizzato da buona robustezza e da alta affidabilità; inoltre, risultano bassi i consumi
del controller progettato per funzionare con alimentazione duale compresa tra i 9 ed i 35 Volt in
continua. L’adattabilità del sistema viene dimostrata anche dalla sua resistenza ai fattori ambientali
essendo esso in grado di lavorare a temperature comprese tra i -40° C ed i 70° C.
L’utilizzo di un processore che lavora alla frequenza di 195 MHz permette il bilanciamento di bassi
consumi in potenza e buone capacità di calcolo. Il NI cRIO si interfaccia con sistemi informatici
tramite porta Ethernet BaseT 10/100, ed inoltre vi è una porta seriale RS232 per collegarvi device
1

3. esterni. Un FTP server facilita l’accesso ai file di log o di configurazione presenti all’interno del
cRIO.
I moduli di cui siamo dotati sono 4 e precisamente abbiamo:
• NI 9215 BNC: consta di 4 canali analogici(fino a 16 bits simultanei di
input), con un range di input 10 . Tale modulo ha una banda a -3
dB di almeno 420 kHz. Il convertitore A/D ha una frequenza di
campionamento di 800 kS/s in modalità multiplexer e 100 kS/s in
campionamento simultaneo.
• NI 9263: presenta 4 canali analogici per una risoluzione di 16 bit;
anch’esso presenta un range di input pari a 10 . E’ un modulo
con una discreta robustezza, in quanto possiede una protezione
contro tensioni non esterne al range di 30 . Ha una velocità di
aggiornamento simultaneo di 100 kS/s.
• NI 9265: è dotato di 4 canali analogici; vanta una risoluzione di 16 bit
e un range di output che spazia tra 0 e 20 mA. Può sostenere un
carico massimo di 600Ω. Ha una velocità di campionamento di 100
kS/s.
• NI 9401: è costituito da 8 canali digitali di input/output di tipo TTL
a 5 . Il massimo segnale di input processabile dipende dal
numero di canali di input utilizzati ed arriva ad un massimo di 30
MHz (solo 2 canali attivi). Il NI 9401 ha un delay time di I/O
inferiore a 100 ns.
Componenti Software del cRIO
Il NI cRIO è un dispositivo dotato di un processore e di una memoria non volatile. Grazie a queste due
caratteristiche è possibile installare sul cRIO dei componenti software. Il cRIO viene fornito con un
sistema operativo proprietario chiamato LabVIEW Real-Time (ETS): questo si occupa della gestione dei
processi e organizza le operazioni di IO effettuate tramite la porta ETHERNET. Oltre al sistema
operativo di base, che offre ben poche possibilità per lo sviluppo di applicazioni reali, è possibile
installare altri componenti o moduli software forniti dalla National Instruments. Di massima importanza
Progetto cRIO | Mazza, Merlino, Messina
sono il modulo Real-Time per l’organizzazione dei cicli ad alta priorità, il modulo NI Rio 2.3.1 e il
modulo FPGA che si occupa dell’interfacciamento con i moduli del Chassis. Un altro importante
strumento installato sul cRIO è il server FTP: grazie a questo è possibile accedere al file-system tramite
un qualunque Client FTP. Il server Web integrato nel dispositivo è un'altra risorsa molto utile che però
non è stata sfruttata in questo progetto.
Che cos'è l'FPGA? Come programmare FPGA con LabVIEW ?
Un dispositivo FPGA (Field-Programmable Gate Array) è un dispositivo che può essere configurato,
dall'utente o dal progettista, in modo da compiere uno specifico lavoro. La possibilità data all'utente
finale di programmare il dispositivo FPGA (Field-Programmable sta per programmabile sul campo) ha
2

4. permesso a questa tecnologia di diffondersi molto facilmente. Generalmente i dispositivi FPGA vengono
però programmati direttamente dai progettisti utilizzando linguaggi come il VHDL (VHSIC Hardware
Description Language dove VHSIC sta per Very High Speed Integrated Circuits).
La programmazione tramite VHDL dei dispositivi FPGA risulta generalmente abbastanza complessa.
LabVIEW e il suo modulo FPGA permettono di programmare i chip FPGA del sistema NI RIO (il cRIO
è il modello compatto della famiglia RIO) tramite una comoda interfaccia grafica. Tramite questo
modulo si possono sviluppare applicazioni che coinvolgono l'uso di dispositivi FPGA senza avere nessuna
conoscenza del VHDL o di progettazione hardware. Inoltre la programmazione grafica degli FPGA,
offerta da LabVIEW, incoraggia l'utente a sviluppare sistemi che possono competere, sia in termini di
ottimizzazione che di performance, con i dispositivi progettati dalle case produttrici.
Lo sviluppo di una applicazione FPGA si svolge su un computer host collegato al dispositivo FPGA;
utilizzando il modulo FPGA e il linguaggio G del LabVIEW si ottiene un Virtual Instrument (VI) che poi
verrà compilato e inserito nei chip. La compilazione è un processo lungo e, in relazione alla complessità
dell'applicazione, può durare solo 15 minuti ma si possono perdere anche diverse ore. La compilazione
inizia con la traduzione del VI (grafico) in codice VHDL, quindi viene evocato il compilatore Xilinx ISE
per ottimizzare, ridurre e infine sintetizzare la realizzazione hardware del nostro VI. Durante la
compilazione vengono inseriti dei vincoli temporali per ottimizzare l'uso delle risorse FPGA e viene,
inoltre, ridotta al minimo la logica digitale usata in modo da ottenere un'implementazione ottimizzata
che assicuri robustezza ed esecuzione parallela. Inoltre non essendoci nessun sistema operativo sui chip
FPGA, il codice così ottenuto è caratterizzato da performance molto alte. Il risultato della compilazione
è un file bit stream che, al momento dell'esecuzione, verrà caricato nei chip FPGA ed eseguito con un
clock di default a 40 MHz ( 25 ns per ogni tick).
Come funzionano le applicazioni sul cRIO ?
Un applicazione Real-Time realizzata per essere eseguita sul cRIO è composta essenzialmente da due
parti: la prima è quella che rimane sul computer Host mentre la seconda è quella caricata nel cRIO. Le
due parti comunicano tramite una connessione ETHERNET e utilizzando un protocollo TCP o UDP. La
parte residente sul cRIO è caratterizzata da tre componenti:
• Un'applicazione FPGA per l'input, l'output, la comunicazione ed il controllo;
• Un Time-Critical Loop per le operazioni in virgola mobile, il processamento e l'analisi dei
segnali;
Progetto cRIO | Mazza, Merlino, Messina
• Un Loop a priorità normale per data logging locale (IO sulla memoria non volatile),
l'interfacciamento Web con pannelli remoti e la comunicazione ETHERNET o seriale.
I due loop vengono mappati sul sistema operativo come thread separati garantendone l'indipendenza
durante l'esecuzione. Solo il Time-Critical Loop è in grado di interagire con l'applicazione FPGA
contenuta nei chip.
Collegando il cRIO ad un PC tramite cavo ETHERNET è possibile eseguire i VI residenti sul controllore
e visualizzarne il Front Panel senza necessariamente implementare la parte residente sul computer Host.
Il cRIO non è però stato ideato per essere sempre collegato ad un PC: uno dei suoi tanti punti di forza è
la possibilità di lavorare in modalità Stand Alone. In questa modalità si impostano una serie di VI da
eseguire quando viene avviato il controllore in modo da poter lavorare senza essere attaccato a nessun
3

5. computer. La parte Host viene così relegata a semplice pannello di monitoraggio e il computer sarà
necessario solo qualora debbano essere effettuate delle modifiche all'applicazione.
L'esperimento “Doppia Soglia”
L'esperimento “Doppia Soglia” è una semplice applicazione sviluppata per testare le capacità del cRIO e
la possibilità di integrare nei VI codice scritto in C. L'esperimento consiste nella lettura di due segnali
per controllare se superano due soglie (diverse per i due segnali), i risultati ottenuti dai controlli delle
soglie devono essere dati in ingresso ad un codice C che inverte i valori booleani ed, infine, l'uscita del
codice C deve essere utilizzata per accendere quattro led. Inoltre, si manda come output analogico la
somma dei due segnali in ingresso. Il risultato visibile è che se un segnale è sopra una determinata soglia
il led si spegne altrimenti rimane acceso.
Per questo esperimento ci siamo avvalsi di tre moduli: NI 9215 BNC per l'input analogico (acquisizione
dei due segnali), NI 9263 per l'output analogico (output delle somma dei segnali acquisiti) e NI 9401 per
l'output digitale (illuminazione dei led).
L'applicazione è divisa in due parti: la prima è l'applicazione FPGA e l'altra è il Virtual Instument che con
essa si va ad interfacciare. Usiamo un boolean per definire in quale delle due modalità deve lavorare
l'applicazione FPGA (Vero: INPUT, Falso: LED):
• INPUT per l'acquisizione dei due segnali, il confronto con le soglie e output della somma dei
due segnali;
• LED per l'illuminazione dei led tramite output digitale.
La prima modalità prende come input i segnali dai moduli e le soglie dal VI e fornisce in output al
modulo la somma dei due segnali e al VI quattro boolean (Veri se la soglia è stata superata, Falsi
altrimenti). La seconda modalità prende in input dal VI quattro boolean e fornisce in output
l'illuminazione dei led in base ai valori boolean ( Led acceso se vero, spento se falso ). Alla fine delle
operazione di ogni modalità si manda una IRQ sul canale 3 necessaria a comunicare con il VI.
Il Virtual Instrument in primo luogo apre l'applicazione FPGA,poi setta il valore del boolean a Vero per
scegliere la modalità INPUT, inserisce le quattro soglie e quindi avvia effettivamente l'applicazione
FPGA. Il VI legge i boolean in uscita per poi passarli al codice C e nel frattempo setta il boolean per
scegliere la modalità LED e si mette in attesa sulla IRQ 3. Arrivata l'IRQ prende le uscite del codice C ( i
quattro booleani invertiti) e li manda di nuovo all'applicazione FPGA per avviarla un'altra volta
permettendo l'accesione dei Led.
Progetto cRIO | Mazza, Merlino, Messina
La Trilaterazione: tecnica utilizzata
Nel software sviluppato durante il progetto utilizzeremo una tecnica per l’individuazione dei soggetti
nello spazio detta MTA (Multiple Trilateration Algorithm).
Si suppone di aver, innanzitutto, distribuito un numero N di sensori (ad ultrasuoni) all’interno di uno
spazio chiuso e che ogni sensore fornisca come dato la distanza che lo separa dall’utente di cui si vuole
rilevare la posizione.
4

6. Nell’algoritmo MTA la trilaterazione è applicata a singole terne di sensori e vengono inoltre, in questa
fase, eliminate le terne considerate non valide ovvero quelle formate da nodi allineati. Si può, quindi,
calcolare che, dati per ipotesi, 8 sensori (tutti supposti validi), avremo 56 differenti terne da valutare.
Si suppone, inoltre, per semplicità, che i sensori siano posti tutti alla stessa altezza.
L’algoritmo consiste, innanzitutto, nella creazione delle terne e, successivamente, nella realizzazione,
per ciascuna terna, delle matrice A e del vettore B tramite queste formule:
2 2
2 2
Nelle precedenti matrici, le variabili x e y rappresentano le coordinate cartesiane del sensore sulla
mappa e la variabile r, invece, va ad indicare la distanza rilevata dal sensore.
A questo punto utilizzando la formula:
· · ·
otterremo le coordinate, rappresentate dal vettore U, della posizione dell’utente per la singola terna di
sensori.
La media delle coordinate calcolate dalle singole terne fornirà la posizione finale dell’utente.
Funzionamento generale del sistema
In questa parte del progetto si è voluto realizzare un VI che calcolasse la posizione dell’utente una volta
fornita la mappa dei sensori ed il vettore delle distanze rilevate da questi.
Non essendo attualmente disponibile un modulo per l’invio di segnali bluetooth (per la comunicazione
con l’utente) si è dovuto realizzare un sistema di scambio informazioni su rete (basata su tecnologia
Ethernet) tra il cRIO ed un PC che provvederà a ricevere i dati sulle distanze inviati dai sensori e a
rimandarli al cRIO che diverrà, quindi, l’unità logica di calcolo dell’intero sistema e fornirà i risultati
ottenuti nuovamente al PC che implementa l’interfaccia utente.
Prima di poter spiegare il funzionamento del VI realizzato, è bene spiegare quale sia il metodo utilizzato
dal cRIO per l’invio e la ricezione delle variabili su rete.
Il cRIO utilizza un motore chiamato Network Variable Engine come server per l’organizzazione delle
variabili, un Network Variable Client per ottenerne il valore ed il modulo DataSocket for LabVIEW Real-time
per inviarle su rete.
Progetto cRIO | Mazza, Merlino, Messina
Le variabili vengono distinte dal cRIO in due classi:
variabili real-time;
variabili network.
La differenza tra le due classi di variabili è, praticamente già spiegata dal loro nome.
Le variabili real-time vengono gestite dal livello FPGA (hanno quindi priorità real-time nella coda dei
processi gestita dal processore del cRIO) e non vengono effettivamente mai trasmesse su rete né ricevute
attraverso di essa; per l’effettiva trasmissione e ricezione attraverso la rete ci si affida alla variabili
network.
La variabile real-time verrà, quindi, scritta su una di tipo network per l’invio di dati e sarà, invece, svolto il
processo inverso nel caso di ricezione di dati da utilizzare in processi real-time.
5

7. Andiamo ora a spiega il funzion
o are namento effe ettivo del sist
tema da noi r realizzato occcupandoci, dapprima,
d
del softw che sarà eseguito sul cRIO.
ware
Il VI è ccostituito da una Flat-Seq quence divisa in più fram Nella prim parte, si nota come il sistema
a me. ma i
attenda p 10 second di ricevere attraverso l rete la map dei senso Alla ricez
per di e la ppa ori. zione della mappa essa
m
verrà salvata su file in
nvece, nel ca in cui la m
aso mappa non ar entro i 1 secondi, v
rrivi 10 verrà importa da file
ata
una mappa precedent temente salva ata.
A questo punto inizia l’effettivo s
o a scambio dati, che è costitu da due l
, uito loop definiti rispettivamente loop
deterministico e loop non d deterministi che andr
ico ranno ad essere eseguiti contemporan neamente
in manie ciclica.
era
Il “loop n determin
non nistico” non fa altro che o occuparsi del trasferimen dei dati d
nto dalle variabili network
i
che si muovono su rete al variabili real-time che, invece, verranno utilizzate dal “loop
ulla lle d
determin nistico” al fin del calco di trilate
ne olo erazione. Per ogni ciclo terminato, inoltre, il “l
r loop non
determin nistico” copie su rete i r
erà risultati otten per reinv
nuti viarli al PC.
In breve il “loop no determini
e, on istico” otterr dalla rete il vettore di distanze inv
rà i viate dai sensori ed il
numero di sensori e li copierà ripettivamen in variab real-time. Al termine del ciclo, il loop si
nte bili e
occuperà dell’invio d
à delle coordin della po
nate osizione dell’utente su rete copiando le variabili Real-time
R
nelle varriabili Netwo Altri com di cui il “loop non deterministic si occupa è quello di attendere
ork. mpiti d co” a a
eventuali segnali di st dei proce provenien dalla rete ed inviare su rete possibi codici d’er
top essi nti u ili rrore.
Come gi detto, il “lo determin
ià oop nistico” si occ
cupa dell’effeettivo calcolo di trilateraz
o zione.
Una volt che le vari
ta iabili real-tim contenen le distanze ed il nume di sensor verranno passate al
me, nti ero ri, p
suddetto loop, esse saranno forn come in
o nite ngresso al bl locco di calccolo realizzat in C. Tal blocco
to le
fornirà in uscita le c
n coordinate de ell’utente op ppure, in cas di irregola
so arità, un cod d’errore Il tutto
dice e.
verrà ritrrasmesso su r rete, come sp piegato prece edentemente dal “loop non determini
e, istico”.
Molto pi semplice è il Sub-VI d
iù destinato ad e essere esegui sul PC. T Sub-VI v ad integra con il
ito Tale va arsi
sistema d trilaterazio esistente, fornendo un
di one , n’interfaccia per la comun nicazione con il cRIO.
n
Il Sub-V consiste in una sempl Flat-Sequ
VI n lice uence con im mposta una temporizzaz zione di 10 msec per
m
mantene la sincron con il cRIO
ere nia O.
Le azion svolte VI so due. In un primo mo
ni ono omento esso invia l’array di distanze (ricevute da sensori)
o y ai
ed il num totale d sensori al VI di calcolo sul cRIO; su
mero dei o uccessivamen riceve la posizione de
nte, a ell’utente
finale (ca
alcolata sul cRRIO) e l’even ntuale codice d’errore.
e
È stato, iinoltre, realizzato un VI d configuraz
di zione mappa, che si occup semplicem
pa, mente, dell’in della
nvio
mappa dei sensori, co vettore, sulla rete.
ome
Il codice C
Progetto cRIO | Mazza, Merlino, Messina
Passiamo ora a spieg
o gare quale si la logica d
ia del
codice i C ideato per calcolare l’effetti
in o iva
posizione dell’utente.
e
Sono sta realizzate due differen soluzioni in
ate nti
C per il calcolo della trilaterazion che abbiam
a ne mo
chiamato rispettiva
o, amente, “a taglio p per
valori” ed “a tag glio per occorrenze e”;
spieghiam in detta
mole aglio.
Entramb le soluzioni accettano in ingresso la
be
matrice delle posizio dei sensori ed il vetto
oni ore
FIGURA 2: SOGLIE DI TA
AGLIO DELL’ALG
GORITMO PER V ALORI
6

8. delle distanze rilevate da questi.
Il codice andrà a scartare i sensori che inviano un dato non valido di distanza (maggiore di 10 metri) e,
dati questi, calcolerà le terne di sensori valide (quelle per cui i tre sensori non siano allineati o
coincidenti).
Per ogni terna verrà calcolata la coordinata stimata sull’asse x e quella sull’asse y.
A questo punto si troverà la posizione dell’utente calcolando la media dei risultati ottenuti; è proprio in
questo calcolo che emerge la differenza fra i due codici.
Il codice “a taglio per valori” si basa sulla supposizione che i valori ottenuti per ciascuna coordinata
siano distribuiti, per numero di occorrenze, su una gaussiana e che quindi la media calcolata sui valori
corrisponda esattamente al risultato voluto.
Per poter scegliere i risultati da scartare, il codice ordinerà i risultati dal più piccolo al più grande e
scarterà i più piccoli N/5 ed i più grandi N/5, ove N rappresenta il numero totale di valori.
L’algoritmo di ordinamento che si è deciso di utilizzare è il QuickSort che assicura le massime
prestazioni possibili, rispetto ad altri algoritmi di ordinamento, bilanciando i consumi di memoria e il
lavoro del processore.
Avendo scartato i valori sicuramente non interessanti si calcola la media sui rimanenti e si ottiene il
valore della coordinata. L’operazione appena descritta viene eseguita sia per l’ascissa che per l’ordinata
ottenendo quindi la posizione esatta dell’utente.
Progetto cRIO | Mazza, Merlino, Messina
FIGURA 3: PARTICOLARE DEL VI DI TRILATERAZIONE SUL CRIO
Passiamo ora a valutare il peso 1 dell’algoritmo dal punto di vista dell’occupazione di memoria e della
complessità di calcolo.
1
Vedi nota successiva
7

9. Nel caso “peggiore” dal punto di vista della complessità, avremo 64 sensori (maggior numero possibile di
sensori sostenuto dalla rete CAN-Bus) tutti a distanza valida e fra i quali non vi siano mai tre sensori
allineati o coincidenti. Considerando che ogni variabile in ciascuno dei due vettori è rappresentata
mediante l’utilizzo di 64 bit e che nel caso descritto ritroviamo un numero di elementi per ciascun
666,62 kbyte.
vettore pari a 41664 avremo quindi una quantità di byte occupati pari a
Dal punto di vista della complessità di calcolo l’operazione più faticosa rimane il QuickSort che risulta
comunque un algortimo a complessità sottolineare.
Si nota un andamento crescente dei tempi di calcolo in maniera direttamente proporzionale al numero di
sensori (come si può verificare dal grafico 1).
Il codice “a taglio per occorrenze” si propone di risolvere i problemi dell’algoritmo
precedentemente descritto, individuati nella supposizione sulla gaussianità della curva dei valori e
nell’utilizzo di un algoritmo di ordinamento.
Questo algoritmo, non potendo più avvalersi della supposizione sulla gaussianità, dovrà considerare, per
ogni supposto valore, il suo numero di occorrenze. Per questo motivo, prendiamo in ingresso un intero
rappresentante il numero di cifre dopo la virgola che considereremo per noi significative; tale parametro
prenderà, per l’algoritmo, il nome di “accuratezza” e determinerà, perlappunto, l’accuratezza con cui
verrà determinata l’uguaglianza fra due numeri (ad esempio 2.3425 è uguale a 2.3476 se accuratezza
minore o uguale a 2; i due numeri risultano diversi altrimenti).
Per ciascuna coordinata troveremo il minimo ed il massimo valore fra quelli forniti dal calcolo sulle
terne di sensori ed allochiamo un vettore, definito vettore delle occorrenze, con un numero N di
elementi pari a:
10
Gli indici di tale vettore rappresentano il range di valori misurati, percui, ad ogni indice dell’array
possiamo associare un valore del range; la relazione che lega indice e valore è:
⁄10
L’elemento di indice i nel vettore delle occorrenze rappresenterà il numero di occorrenze del valore i
fra i valori supposti per la coordinata.
A questo punto viene riempito il vettore delle
occorrenze e si determinano quelli che hanno
numero massimo di occorenze; fra questi si sceglie
quello nel cui intorno ricadono il maggior numero di
Progetto cRIO | Mazza, Merlino, Messina
occorrenze. Il raggio dell’intorno di valutazione è
dato da
10 10
Il valore scelto corrisponderà alla coordinata finale
dell’utente.
Passiamo a valutare il peso 2 di un tale algoritmo. Il FIGURA 4: ESEMPIO DI ISTOGRAMMA DELLE OCCORRENZE. IN
caso peggiore sarà lo stesso del precedente. Dal QUESTO CASO SI SCEGLIEREBBE IL VALORE 3.1.
2
Le simulazioni sono state effettuate mediante l’utilizzo di mappe a numero variabile di sensori tutti a distanza valida e fra i quali non vi siano mai tre sensori
allineati. Simili mappe sono state ottenute attraverso la creazione di un algoritmo scritto in C che utilizza tecniche di generazione di punti pseudocasuali. Tali
punti vengono condizionati a trovarsi a non più di una certa distanza da un punto le cui coordinate vengono fornite come parametri al programma ed inoltre
viene fatto un controllo che assicura l’assenza di tre sensori allineati fra quelli generati.
8

10. punto di vista della complessità di calcolo, l’algoritmo risulta essere molto più leggero del precedente
avendo eliminato il QuickSort; uniche “fatiche” richieste al processore sono quella di dover scorrere il
vettore delle occorrenze (che può risultare abbastanza grande) e quella dovuta all’allocazione e alla
deallocazione di spazio in memoria.
L’occupazione di memoria dell’algoritmo sembra essere il suo punto debole si è per questo preferito
utilizzare elementi del vettore delle occorrenze a 2 byte. Nel caso peggiore si avrà uno spreco di
memoria pari ai 666,624 Kbyte dell’algoritmo precedente più una quantità variabile di memoria di
difficile calcolo (si sono, tuttavia, potute osservare variazioni nell’occupazione di memoria fra i 700
Kbyte e 1-2 Mbyte). Per ovviare ad eventuali problemi dovuti all’eccessiva occupazione di memoria si è
inserito un controllo che riduce l’accuratezza se il range dei valori supera una certa soglia.
L’andamento dell’algoritmo non è strettamente legato al numero di sensori (sebbene continui ad essere
influenzato da esso) ma risulta più influente sui tempi di calcolo la dimensione assunta dal range dei
valori (affermazione verificata dal grafico 1).
Sebbene l’andamento sia più oscillante si può facilmente notare come i tempi di calcolo si siano
nettamente ridotti.
Progetto cRIO | Mazza, Merlino, Messina
GRAFICO 1
9