Univesit` di Siena a

Corso di Laurea in Ingegneria Informatica

Studio e implementazione di un sistema embedded adibito al controllo del traffico

Gian Lorenzo Meocci

Relatore: Chiar.mo Prof. Roberto Giorgi

Correlatore: Chiar.mo Prof. Alessandro Mecocci

Anno Accademico 2004-2005

Alla mia famiglia

ii

Indice
1 Prefazione 1.1 Una panoramica d’insieme . . . . . . . . . . . . . . . . . . . . 2 Controllare il traffico 2.1 Introduzione . . . . . . . . . . . . . . . . . . 2.2 Il sistema in breve . . . . . . . . . . . . . . 2.3 Soluzioni esistenti . . . . . . . . . . . . . . . 2.3.1 Sistemi centralizzati e decentrallizati 2.3.2 Microsoft MapPoint . . . . . . . . . 2.3.3 S.T.A del comune di Roma . . . . . . 2.4 Conclusione introduttiva . . . . . . . . . . . 3 Tecnologie utilizzate 3.1 Il Microcontroller . . . . . . . . . . . 3.1.1 Caratteristiche generali . . . . 3.1.2 L’ambiente di sviluppo . . . . 3.2 La Network camera . . . . . . . . . . 3.2.1 Caratteristiche generali . . . . 3.3 Comunicazione . . . . . . . . . . . . 3.3.1 Introduzione . . . . . . . . . . 3.3.2 Inviare il livello del traffico . . 3.4 Elaborare un’immagine . . . . . . . . 3.4.1 Che cos’` un’immagine . . . . e 3.4.2 Breve cenno al formato JPEG 3.4.3 Calcolare il livello del traffico 3.4.4 Determinazione dello sfondo . iii 1 1 5 5 6 6 6 7 8 8 9 9 9 9 10 10 10 10 11 13 13 13 14 19

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

iv 4 Implementazione del sistema 4.1 Il Microcontroller . . . . . . . . . 4.1.1 Il software di controllo . . 4.2 La Network camera . . . . . . . . 4.2.1 Ottenere un’ immagine . . 4.2.2 Il decoder JPEG . . . . . 4.3 Comunicazione . . . . . . . . . . 4.3.1 Il modem GSM . . . . . . 4.3.2 Inviare il livello del traffico 4.4 L’interfaccia di controllo . . . . .

INDICE 23 23 23 24 24 25 26 26 26 28

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

5 Valutazioni e test effettuati 31 5.1 Test effettuati . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2 Risultati conseguiti . . . . . . . . . . . . . . . . . . . . . . . . 32 6 Conclusioni 33 6.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.2 Conclusioni generali . . . . . . . . . . . . . . . . . . . . . . . . 34 A Codice A.1 Alcuni importanti #define . . . . . . . . . . . A.2 La funzione per il download di una immagine A.3 Le funzioni per l’ inizializzazione del modem . A.4 La funzione per l’invio di un SMS . . . . . . . 35 35 35 36 37

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

B Specifiche tecniche 39 B.1 Microcontroller Rabbit RCM3000 . . . . . . . . . . . . . . . . 39 B.2 Network Camera Axis2110 . . . . . . . . . . . . . . . . . . . . 39 B.3 Modem GSM Industrial Base . . . . . . . . . . . . . . . . . . 40

Capitolo 1 Prefazione
1.1 Una panoramica d’insieme

Questo lavoro di Tesi ha lo scopo di rilevare la densit´ veicolare di un tratto a stradale utilizzando un sistema embedded composto da un microcontroller, una telecamera e un modem GSM. Il sistema ` stato progettato principale mente per consumare poca energia, occupare una banda ridotta ed utilizzare componenti facilmente reperibili sul mercato e a costi contenuti. In particolare in questo lavoro di tesi sono state realizzate: 1. Il software per la comunicazione tra microcontroller e telecamera. 2. Il software per la conversione di immagini dal formato JPEG al formato PGM da utilizzare sulla Rabbit RCM3000. 3. Il software per il trattamento e l’analisi delle immagini. 4. Il software per la comunicazione (utilizzando un modem GSM) tra il microcontroller e il Data Center utilizzando messaggi SMS. 5. Un interfaccia per la verifica e il controllo del sistema. 6. Vari tool per il test e la simulazione dei componenti del sistema. Una prima fase del lavoro ` stata dedicata all’analisi del problema e alla rie cerca dei componenti hardware adatti a risolvere il problema, seguita da una 1

2

CAPITOLO 1. PREFAZIONE

seconda fase di sperimentazione ed da una terza di implementazione. Durante la fase di sperimentazione sono stati scritti vari tools per simulare il comportamento dei componenti reali permettendo di progredire passo dopo passo nella realizzazione di un prototipo finale, tenendo conto dello sviluppo complessivo. Il primo modulo ad essere messo a punto ` stato il modulo per l’elaborazioe ne delle immagini scritto in Java. Questo tool ha permesso di comprendere i vari problemi per l’elaborazione d’immagini riguardanti veicoli in movimento a varie velocit`. Utilizzando questo tool, sono stati definiti alcuni algoritmi a base da implementare in un microcontroller. Il microcontroller utilizzato ` e un Rabbit RCM3000 che ` basato su un processore Z80 ad 8 bit con un clock e da 30MHz il cui consumo complessivo risulta tipicamente intorno ai 495 mW. Utilizzando questo microcontroller ` stato fatto un primo porting del moe dulo d’elaborazione, simulando la produzione di immagini della telecamera con un altro tool realizzato anch’esso in Java. La telecamera comunica con il microcontroller attraverso un collegamento ethernet a 10Mbits, garantendo un’adeguata ampiezza di banda per l’acquisizione delle immagini. La fase d’acquisizione ` seguita da quella di processing che consente di e calcolare i livelli di traffico da spedire al server utilizzando un modem GSM. Il modem GSM (Industrial Base GSM) ` stato scelto per la sua semplie ce integrazione nei sistemi embedded utilizzati sia in ambito industriale che accademico. La comunicazione tra il microcontroller e il modem avviene attraverso una connessione seriale, attraverso la quale sono inviati i comandi standard AT della ETSI. Il terzo tool sperimentale (utilizzato per testare il modem) ` stato realizzato in C per ambiente Linux e consente l’invio di e un SMS sulla rete GSM. Tale software imposta una connessione seriale con il modem e successivamente imposta il modem per la registrazione sulla rete GSM. Si ` scelto di comunicare attraverso messaggi SMS sfruttando reti e geografiche ampiamente diffuse per veicolare l’informazione al server centrale. A seguito di ci` e stato realizzato un porting sul microcontroller per o verificarne il corretto funzionamento. Da tenere presente che questa scelta rispetta il secondo (e in parte terzo) requisito, in quanto senza alcun costo di cablatura o installazione di ripetitori consente una comunicazione semplice ed efficiente tra il sistema embedded e il server di controllo. La telecamera utilizzata ` la Axis 2110 (da cui dipendono molti fattori per e la corretta elaborazione delle immagini) che dispone di un interfaccia ethernet grazie alle quale ` possibile ottenere le immagini attraverso il protocollo e HTTP. E’ stato dunque scritto un tool, per il test, in grado di interfacciarsi

1.1. UNA PANORAMICA D’INSIEME

3

con la telecamera e scaricare i vari frame. Le immagini restituite sono poi convertite dal formato JPEG al formato PGM in modo da essere processate dal software sul microcontroller. La fase che ha visto la realizzazione del modulo di conversione da JPEG a PGM, sul microcontroller, ` stata la pi` e u delicata e complessa. Il problema principale scaturiva dalla complessa natura del JPEG che richiede molta memoria e potenza di calcolo. Il modulo di conversione si ` basato sul convertitore jpegdrc ed ` stato riscritto per essere e e utilizzato sulla Rabbit. Il lavoro principale ` stato quello di minimizzare l’ue tilizzo della memoria (portata da 265KB a poco pi` di 47KB) e di sostituire u l’interfaccia a file con quella a memoria estesa. E’ stato anche necessario, dopo aver terminato il porting del modulo di conversione sul microcontroller, interfacciare direttamente il microcontroller alla telecamera. L’intero software sul microcontroller ` stato scritto utilizzando il Dynae mic C, un ambiente di sviluppo progettato per le schede RCM3000 che si basa su una versione leggermente modificata dello standard ANSI C. Dato che nel sistema si prevede l’interazione con il Data Center (server di controllo) si ` resa anche necessaria la realizzazione, oltre a tutti i tool di e simulazione (di volta in volta sostituiti dai corrispettivi componenti reali), di una interfaccia (anch’essa realizzata in Java) che permettesse la gestione e la visualizzazione dei risultati elaborati dal sistema embedded. Nei capitoli successivi si analizzer` in maggior dettaglio il problema fora nendone una possibile soluzione.

4

CAPITOLO 1. PREFAZIONE

Capitolo 2 Controllare il traffico
2.1 Introduzione

Immaginiamo di voler attivare un servizio in grado di guidare ed informare adeguatamente un utente sulle condizioni del traffico di una determinata zona d’interesse. Tale servizio, basandosi su diverse informazioni, dovr` fora mulare un percorso ottimale che consenta all’utente di evitare quelle strade gi` intensamente trafficate e che dunque possa condurlo alla destinazione dea siderata nel minor tempo possibile. Dovremo perci´ realizzare un sistema o che consenta a tale servizio di essere costantemente aggiornato sull’evolversi del traffico nei diversi tratti stradali e garantisca al contempo un adeguato aggiornamento dei dati medesimi. Questa tesi f` parte del progetto IES [9] e si pone lo scopo di reperire a parte di quell’ informazione necessaria per determinare la corretta densit` a veicolare di un tratto stradale. La soluzione studiata ed implementata consiste nell’ utilizzare un sistema embedded connesso ad una network camera e ad un modem GSM in grado, come avremo modo di mostrare in seguito, di rispondere ai requisiti sopra citati e di preservare una flessibilit` strutturale che gli consenta di a adattarsi a svariate soluzioni implementative. 5

6

CAPITOLO 2. CONTROLLARE IL TRAFFICO

2.2

Il sistema in breve

Il sistema embedded ha una duplice funzione: ` parte attiva in quanto ha e il compito di elaborare le immagini estrapolandone il livello del traffico, ed ha una funzione di collegamento in quanto attraverso esso si controlla sia la telecamera che il modem. La telecamera1 comunica con il microcontroller2 attraverso una connessione ethernet e grazie al webserver incorporato riesce a scambiare le immagini con semplici richieste HTTP[2]. Il modem3 utilizza invece un collegamento seriale, attraverso il quale riceve i messaggi da inviare al server centrale(Data Center ). Questo sistema rientra nella categoria dei sistemi decentralizzati, cio` e quei sistemi in cui l’elaborazione dell’informazione ` contestuale all’ acquisie zione della medesima. Ci` che a noi interessa ` calcolare approssimativamente o e quanto traffico ` presente, in un determinato istante, in un tratto stradale e che ` ben diverso dal voler calcolare il numero di veicoli che vi transitano. e Sono problemi di natura diversa e come avremo modo di approfondire sono risolvibili entrambi con approcci diversi. Un’ultima precisazione, che vorrei fare, riguarda il fatto che difficilmente si potr` fare a meno di riferirsi ad una specifica tecnologia, vista la natura a sperimentale della tesi, ma ci` che spesso diremo in particolare varr` ano a che in generale a patto di cambiare qualche protocollo o aggiornare qualche componente.

2.3
2.3.1

Soluzioni esistenti
Sistemi centralizzati e decentrallizati

Un’importante distinzione deve essere fatta tra i sistemi centralizzati e quelli decentrallizati per l’elaborazione di immagini. E’ la natura del problema a determinare quale soluzione implementare dal momento che problemi diversi richiedono diversi carichi computazionali e quindi diverse architetture elaborative.
1 2

Axis Network Camera 2110, implementa il protocollo HTTP1.1. Rabbit RCM3000. 3 Industrial Base GSM, implementa i comandi standard AT della ETSI.

2.3. SOLUZIONI ESISTENTI

7

Fino ad oggi gli sforzi maggiori (e la ricerca in generale) si sono maggiormente concentrati nell’ elaborazione di immagini utilizzando soluzioni centralizzate, cio` elaborando tali immagini con grossi sistemi di calcolo. Tali e architetture consentono infatti di eseguire un enorme mole di calcoli e hanno dunque numerose applicazioni: tracking di oggetti in movimento, recupero di informazioni (ad esempio le targhe dei veicoli in transito), riconoscimento di volti e varie analisi statistiche. Questo approccio ha successo se abbiamo gli strumenti necessari per risolvere i problemi di comunicazione dovuti all’ elevata banda richiesta e alle grandi distanze da coprire. Una soluzione wired (in base ai vincoli di progetto iniziali del progetto IES) ` da escludersi a priori (problemi di protocollo e e costi di cablatura) mentre una soluzione wireless, anche se praticabile, comporterebbe comunque costi dovuti all’installazione di nuovi ripetitori e tutti i problemi che potremo definire socio-politici. Nonch` da tenere presente che e un sistema cos` progettato sarebbe comunque poco scalabile. ı Un sistema decentralizzato (come il nostro) poich` non deve trasferire ime magini ad alta definzione ma solo il risultato elaborato (e qualche immagine ridotta in determinati casi) pu` sfruttare le reti telefoniche mobili gi` esio a stenti(ad esempio la rete GSM[4]) con costi, dunque, irrisori. Tuttavia non potremmo pi` disporre di un sistema complesso di calcolo (anche un comuu ne PC rispetto a un microcontroller ` un sistema complesso di calcolo) e la e profondit` d’ analisi che potremmo raggiungere sar` strettamente legata alla a a potenza di calcolo del microcontroller, ma guadagneremo notevolmente sulla flessibilit` del sistema. a Quindi possiamo affermare che questi due approcci sono uno il complementare dell’altro e affrontano problemi che sono anch’essi complementari tra loro. In questa tesi si realizzer` un sistema embedded che permetta di a osservare direttamente le problematiche della realizzazione di un sistema decentralizzato. Qui di seguito sono riportati alcuni servizi gi` attivi che tentano di a risolvere parti delle problematiche sopra esposte.

2.3.2

Microsoft MapPoint

L’idea che st` dietro a questo prodotto ` quella di offrire un servizio, che a e attraverso il GPS ed un palmare, possa consentire all’ utente di localizzarsi facilmente su una mappa cittadina. Su tale mappa verranno inserite varie

8

CAPITOLO 2. CONTROLLARE IL TRAFFICO

tipologie di informazioni (dai ristoranti ai servizi di trasporto) ma tali informazioni non saranno aggiornate automaticamente e perci` tale prodotto non o potr` sostituire il nostro sistema di acquisizione ed elaborazione dei flussi a stradali, ma semmai potr` esserne una comoda interfaccia. a

2.3.3

S.T.A del comune di Roma

Il sistema centralizzato per il controllo del traffico del comune di Roma, ` e indubbiamente uno dei sistemi di monitoraggio e controllo pi` avanzati in u Italia e in Europa. E’ composto da oltre 60 telecamere connesse ad una dorsale in fibra ottica che costantemente monitorizzano i centri nevralgici della Citt`. Un cluster composto da 35 PC in parallelo elabora le numerose a informazioni che costantemente raggiungono la centrale di controllo. Inoltre numerosi semafori e segnalatori luminosi sono direttamente gestiti da un sistema di controllo che si basa su un DSS(Decision Support System) in grado di minimizzare i rallentamenti e gli ingorghi. Tuttavia monitorare automaticamente aree pi` distanti dal centro (ad u esempio aree periferiche) resta ancora una questione in parte aperta, che potrebbe essere risolta integrando la nostra soluzione nel sistema di controllo.

2.4

Conclusione introduttiva

Da quanto ` stato illustrato possiamo dedurre che una possibile soluzione alla e gestione e al controllo del traffico sia quella di integrare pi` sistemi tra loro in u modo da formare un unico sistema in grado di gestire il traffico sia all’interno della citt` che nelle zone limitrofe, offrendo inoltre un servizio fruibile dal a cittadino attraverso strumenti (palmari e cellulari) oggi ampiamente diffusi.

Capitolo 3 Tecnologie utilizzate
3.1
3.1.1

Il Microcontroller
Caratteristiche generali

Poich` le caratteristiche tecniche del microntroller influiscono sul tipo di elae borazione che pu` essere svolta su di esso ` necessario a questo punto introo e durre almeno gli aspetti principali di tale sistema. Innanzitutto si ` utilizzato e il Rabbit RCM3000 basato su un processore Z80 a 8 bit con una frequenza di clock pari a 30MHz e con una memoria complessiva di 512K. Tale sistema ` dotato inoltre di varie porte seriali e di una scheda ethernet a 10MBits che e ho utilizzato per connettere tra loro i tre componenti.

3.1.2

L’ambiente di sviluppo

L’ambiente di sviluppo fornito ` il Dynamic C, che oltre al compilatore, mette e a disposizione un IDE progettato per integrarsi con il microcontroller (molto utile nella fase di debug). Il linguaggio utilizzato ` un dialetto dell’ANSI C[7] e modificato per sfruttare la multiprogrammazione (cofunction e codata) e per semplificare la programmazione di rete. Tale ambiente fornisce anche molte librerie che vanno dalla gestione della memoria estesa a quella delle porte seriali comprimendo i tempi di sviluppo. Tuttavia la programmazione sui sistemi embedded (di questo tipo) richiede 9

10

CAPITOLO 3. TECNOLOGIE UTILIZZATE

un approccio sostanzialmente diverso alla tipica programmazione su ambienti workstation o desktop in quanto costringe il programmatore a fare i conti con poca memoria a disposizione, con una ridotta potenza di calcolo e con ridotti strumenti per il debug dell’applicazione.

3.2
3.2.1

La Network camera
Caratteristiche generali

Una network camera ` una telecamera che, attraverso un webserver ine tegrato, ` in grado di comunicare attraverso il protocollo HTTP con un cole legamento ethernet. Tali telecamere vengono utilizzate principalmente per sistemi di videosorveglianza remota, sia outdoor che indoor, vista la semplice realizzazione di complesse reti di controllo. La telecamera da noi utilizzata per le provi sperimentali ` la Axis 2110 adatta sia ad ambienti indoor che e outdoor. Ad ogni telecamera deve essere associato un indirizzo IP (si pu` o utilizzare anche quello di default) per consentirle di dialogare attraverso i normali protocolli (TCP[6], HTTP, FTP) e di scambiare immagini. Il formato utilizzato nella Axis 2110 per codificare le immagini ` il JPEG, e con la possibilit` di specificare la qualit` nella richiesta HTTP, mentre altri a a modelli consentono la richiesta di immagini in formato BMP.

3.3
3.3.1

Comunicazione
Introduzione

Si ` gi` illustrato come un’ importante requisito per il sistema sia quello di e a occupare poca banda per poter essere utilizzato anche in luoghi non raggiungibili da tecnologia a banda larga (fibra ottica, xDSL, etc.). La nostra scelta si ` dunque focalizzata nelle reti di telecomunicazioni esistenti e largamente e utilizzate nel territorio nazionale e internazionale. Grazie all’utilizzo di protocolli ormai standard ed ampiamente diffusi (GSM, GPRS, EDGE, UMTS) possiamo scegliere tra svariati servizi con costi e prestazioni diversificate. Possiamo, in definitiva, adattare ed ampliare il nostro sistema embedded in base alle risorse di cui disponiamo garantendo un’ elevata flessibilit` e a

3.3. COMUNICAZIONE

11

personalizzazione. Per la realizzazione del prototipo abbiamo optato per utilizzare la rete GSM (e in particolare gli SMS) per veicolare l’informazione tra il sistema embedded e il Data Center. Questa scelta ` stata dettata dalla semplice e interfaccia offerta dal modem GSM e dai bassi costi richiesti.

3.3.2

Inviare il livello del traffico

Per l’invio dell’informazione si ` utilizzato il servizio SMS (Short Message e Service) previsto nello standard GSM. Questo servizio rende possibile l’invio del livello del traffico a bassi costi e con poca banda rendendone molto semplice la ricezione al Data Center. Infatti ` sufficiente un solo processo, per e tutte le telecamere, che faccia il pool dei messaggi SMS in arrivo discriminandoli attraverso il SysID del messaggio. Un messaggio SMS ` composto e da tre campi:

Tabella 3.1: Struttura di un messaggio SMS SysID Type Body

- Il SysID ` l’identificativo del sistema embedded e serve per tenere e traccia di tutti i messaggi inviati al Data Center. - Il Type indica la tipologia del messaggio. Pu` assumere tre valori o {ALERT, TIME, IMAGE }. Il valore di ALERT indica al Data Center che si ` in presenza di un possibile congestionamento del traffico. Il vae lore TIME indica invece che il messaggio ` stato inviato per mantenere e aggiornata la base di dati. Infine il valore IMAGE, indica che si st` per a ricevere una serie di messaggi che costituiscono un’immagine. e - Il Body ` il corpo del messaggio. Un tipico messaggio assumer` dunque la seguente forma: a SysID: 1001,ALERT, Traffic: 3

12

CAPITOLO 3. TECNOLOGIE UTILIZZATE

Se invece il messaggio ` un IMAGE non baster` inviare un solo messaggio e a dal momento che vengono trasmesse immagini 80x60 pixel in bianco e nero. Per codificare un pixel viene utilizzato un bit (0=nero e 1=bianco). Facendo un semplice conto, e sapendo che un messaggio SMS pu` contenere 140 byte, o ricaviamo che il numero di messaggi necessari per inviare un’immagine sar`: a #Byte = 80 ∗ 60 = 600; 8 =⇒ 600 ∼ 5 messaggi SMS; 140

Per ridurre il numero dei messaggi necessari possiamo applicare l’algoritmo di compressione CCITT group 3 divenuto famoso per la sua applicazione ai fax. Figura 3.1: La codifica CCITT applicata ad un’immagine 80x60 a due colori

=⇒

(b0 , 0 )(b1 , 1 ) . . . (bn , n )

L’immagine viene rappresentata da un’insieme di coppie (bx , x ) in cui il primo elemento rappresenta il bit e l’altro campo ci dice di quanto dobbiamo saltare per trovare un bit diverso. Poich` in un segmento di 80 pixel ci sono in media e 10 variazioni e x occupa ln(80) = 4.3 ∼ 5 bit ci riportiamo ad un’immagine di 50x60=3000 bit che sono 3 messaggi SMS. La struttura di un tale messaggio sar` dunque: a SysID: 1001,IMAGE, nmex:3, dim: # of bit,id1 id2 id3

id1 id2

image data image data

id3 image data .......... .......................
8 1112

3.4. ELABORARE UN’IMMAGINE

13

Una volta che il messaggio ` stato preparato lo si invia attraverso la funzione e send sms che utilizza i comandi AT per comunicare con il modem GSM (vedere appendice per il codice).

3.4
3.4.1

Elaborare un’immagine
Che cos’` un’immagine e

Per trattare le immagini su un sistema con poca memoria disponibile, si deve necessariamente utilizzare immagini ridotte e possibilmente in scala di grigio. Si ` percio scelto di convertire le immagini JPEG che provengono dalla telee camera dal formato 320x240 al formato 160x120, eliminando l’informazione sul colore. Quello che otteniamo ` una matrice di 160x120 byte. Ogni pixel e ` codificato con un byte rappresentante la luminanza dell’imagine in quel e punto. Le considerazioni sopra fatte sono lecite in quanto ` ampiamente dimoe strato che il contenuto informativo di un immagine rimane sostanzialmente invariato se eliminiamo le informazioni sul colore, mantenendo solo quelle sulla luminanza.

3.4.2

Breve cenno al formato JPEG

Il formato JPEG (Joint Picture Expert Group) nasce agli inizi degli anni ’90 con l’ intento di trovare un formato in grado di ottenere buone prestazioni con immagini fotografiche. Tale formato doveva sostanzialmente occupare poca memoria garantendo livelli di qualit` differenti. Lo schema di principio a che st` dietro alla conversione JPEG lo possiamo osservare in figura 3.2. a Come possiamo notare ci sono varie fasi che trasformano una matrice multidimensionale di byte nell’imaggine compressa. La fase maggiormente significativa ` quella che trasforma in frequenza un blocco di pixel 8x8 utie lizzando la DCT(Discrete Cosine Transform). L’ idea di base ` quella di e eliminare il contenuto informativo alle alte frequenze (non significative per gli esseri umani) applicando un filtro che ` definito nella fase di quantizzae zione. Dopo la fase di quantizzazione si ottiene una matrice simile alla seguente:

14

CAPITOLO 3. TECNOLOGIE UTILIZZATE

   M= 

64 15 . . . 7 0 ... . . .. . . . . . 0 0 0

 0 0    0  0

In questa matrice compaiono molti zeri che consentono un’ulteriore fase di compressione denominata RLE (Run Length Encode). Tale tecnica consiste nel codificare una serie di dati attraverso una coppia (skip,value) dove skip ` e il numero di valori uguali a zero e value ` il successivo valore diverso da zero. e Nel formato JPEG tale compressione viene applicata dopo aver riordinato, con un andamento a Zig-Zag, la matrice 8x8 in un vettore di 64 elementi. In questo formato si codificano in maniera diversa le componenti DC (componenti continue) da quelle AC (componenti variabili). La componente DC non ` altro che il primo elemento della matrice M (nel esempio ` 64) e viene e e compressa utilizzando il DPCM, che si basa su informazioni statistiche dei blocchi (in pratica si codifica la variazione tra una componente DC e la successiva). Infine viene applicato Huffman, che consente di aumentare il grado complessivo di compressione.

3.4.3

Calcolare il livello del traffico

Conoscere il livello del traffico significa calcolare la funzione diff . Il valore restituito da tale funzione ci dice qual ` la distanza tra l’immagine di sfondo e ed il frame corrente. Questo ci permette di controllare il flusso del traffico in un determinato periodo. Infatti se il valore rimane costantemente alto per un certo ∆t possiamo ipotizzare che si st` formando una colonna o che a comunque il traffico in quel periodo ` elevato. e L’idea di base ` dunque semplice: contiamo il numero di pixel del frame e corrente che differiscono dallo sfondo rispetto ad una certa soglia predeterminata. La funzione diff , sotto riportata, ` colei che svolge tale operazione, la e soglia durante il test ` stata posta a 25. e

3.4. ELABORARE UN’IMMAGINE Figura 3.2: Le fasi per convertire un’ immagine in formato JPEG

15

int diff() { int i,j,r; byte b1[WIDTH2],b2[WIDTH2]; r=0;j=0; for(j=0;j<HEIGHT2;j++){ xmem2root(&b1[0],(unsigned long)(sfondo+j*WIDTH2),WIDTH2); xmem2root(&b2[0],(unsigned long)(Image+j*WIDTH2),WIDTH2); for(i=0;i<WIDTH2;i++)if (abs(b1[i] − b2[i]) > 25)r++; } return r; } Il valore della soglia ` stato calcolato considerando che la massima variazione e di un pixel codificato con un byte ` di 255 e che generalmente si considee ra accettabile una variazione del 10% sull’immagine di ingresso. Abbiamo

16 dunque:

CAPITOLO 3. TECNOLOGIE UTILIZZATE

soglia =

255 ∗ 10 = 25.5 ≈ 25 100

Un’altro parametro che sarebbe utile stimare ` il numero di pixel sopra la e soglia del 10% ma sotto quella del 15%. Il valore di questa soglia ` facilmente e calcolabile: 255 ∗ 15 soglia = = 38.25 ≈ 38 100 Se indichiamo con N il numero di pixel sopra la soglia e con N quelli compresi tra le due soglie si pu` notare come sia sempre vero che vale la relazione: o N ≥ N . Possiamo dunque esprimere N con: N =α+N ; α ∈ N+ ; 0

Se di tale relazione N fosse una componente significativa potremmo ritenere che non siamo in presenza di un traffico reale, ma probabilmente stiamo valutando variazione che dipendono da altri fattori (illuminazione, vibrazioni della telecamera, variazione di temperatura, etc.). In un caso reale tale parametro potrebbe essere significativo per determinare quando riaggiornare lo sfondo di riferimento riducendo l’errore commesso nell’analisi del traffico. Un’ ulteriore tecnica che si potrebbe implementare (uso il condizionale in quanto non ` stata sperimentata sul nostro prototipo) consiste nell’ analizzae re la distribuzione delle variazioni dei pixel tra lo sfondo e il frame corrente, estrapolando una coppia (ηx , ηy ) che rappresenti il baricentro di tale distribuzione. Quello che si prevede di ottenere ` un indice (γ) che indichi la e variazione della distribuzione nel tempo. Con questo ulteriore indice si pu` o costruire la tabella 3.2. Analizziamo adesso un possibile metodo per ottenere tale indice, definendo due matrici (S, F) che rappresentino lo sfondo e il frame corrente. Ipotizziamo ad esempio che si abbia una situazione simile (ovviamente S ed M sono matrici 160x120):  0 1 3 0 1 S =  2 0 1 0 1 ; 3 2 1 0 3   0 0 0 0 1 F =  2 0 0 0 1 ; 3 0 0 0 3 

3.4. ELABORARE UN’IMMAGINE Tabella 3.2: Tabella riassuntiva N alto alto basso basso γ alto basso alto basso Traffico normale alto basso basso

17

La matrice differenza (in valore assoluto) ` la seguente: e   0 1 3 0 0 T = |S − F| =  0 0 1 0 0  ; 0 2 1 0 0 In questo caso si avrebbe (con soglia = 1) N = 2. L’idea di base consiste nel sommare tutte le righe della matrice T e tutte le sue colonne ottenendo due vettori: Tr = [0 3 5 0 0]; Tc = [4 1 3]; Questi due vettori rappresentano lungo gli assi x ed y la distribuzione della matrice T . Qui di seguito sono riportati i relativi grafici. Si puo dunque calcolare ηx come: ηx =
k (Tr (k)

∗ k) 0∗0+1∗3+2∗5+3∗0+4∗0 = = 1.625; 8 k Tr (k)

Stessa cosa per ηy . ηy =
k (Tc (k)

∗ k) 4∗0+1∗1+2∗3 = = 0.875; 8 k Tc (k)

18

CAPITOLO 3. TECNOLOGIE UTILIZZATE

Figura 3.3: La rappresentazione del vettore Tr
5

4.5

4

3.5

3

2.5

2

1.5

1

0.5

0

0

0.5

1

1.5

2

2.5

3

3.5

4

Figura 3.4: La rappresentazione del vettore Tc
4

3.5

3

2.5

2

1.5

1

0.5

0

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

3.4. ELABORARE UN’IMMAGINE

19

Abbiamo determinato la coppia (ηx , ηy ) che rappresenta le coordinate del baricentro della distribuzione T . A questi punti possiamo calcolare il parametro γ. Ipotizzando che all’istante t0 il baricentro di T sia (µx , µy ) mentre all’ istante t1 sia (ηx , ηy ) si avr` che: a γ= (ηx − µx )2 + (ηy − µy )2 ;

che ` la distanza tra i due punti. e Calcolare γ sul microcontroller di riferimento comporta un carico computazionale notevole. Per fare due conti: 1. Tr : 120 somme per tutte le 160 colonne ⇒ 120*160=19200 somme 2. Tc : 160 somme per tutte le 120 righe ⇒ 120*160=19200 somme Complessivamente avremo 38400 somme da eseguire (con relativi accessi alla memoria estesa) oltre al calcolo della coppia (ηx , ηy ). Per questi motivi ` e necessario utilizzare un microcontroller con sufficiente potenza di calcolo.

3.4.4

Determinazione dello sfondo

Un’ importante passaggio consiste nel definire un algoritmo per determinare automaticamente lo sfondo di riferimento. Questo ` importante sia perch` il e e sistema pu` eseguire un reboot generale in qualsiasi momento, sia perch` il o e sistema nel normale corso di funzionamento deve essere in grado di riaggiornare il proprio sfondo indipendentemente dal Data Center. Dopo la fase di inizializzazione (registrazione sulla rete GSM e inizializzazione delle variabili globali) il sistema inizia una fase nella quale cerca di determinare uno sfondo. Lo schema degli stati che descrivono questo processo sono riportati figura 3.5. Tale schema non garantisce, tuttavia, che l’immagine acquisita non contenga veicoli, dal momento che tali veicoli potrebbero essere fermi durante l’intero ciclo di ricerca (B → C). Per ridurre ulteriormente l’incertezza si potrebbe eseguire un’ulteriore controllo basandosi su come dovrebbe essere fatto uno sfondo tipico. Poich` il manto stradale ` sufficientemente regolare si pu` assumere che e e o un buono sfondo non dovr` presentare forti discontinuit` per qualsiasi cona a dizione climatica si voglia considerare. Se riteniamo ragionevole tale criterio possiamo, senza commettere un grossolano errore, considerare l’uniformit` a

20

CAPITOLO 3. TECNOLOGIE UTILIZZATE Figura 3.5: Il grafo degli stati per l’acquisizione dello sfondo

dell’immagine, candidata ad essere lo sfondo, come un parametro qualitativo. Ovviamente maggiore ` l’uniformit` di tale immagine maggiore sar` la e a a probabilit` di aver scelto un giusto candidato. a Si ` detto, poco sopra, che un buon sistema deve essere in grado di riage giornare autonomamente lo sfondo durante l’intero arco del funzionamento per ridurre il disturbo dato principalmente dalla variazione della temperatura e luminosit` esterna, dalla formazione di ombre e dai cambiamenti climatici. a Quello che dunque si propone ` di riapplicare il procedimento sopra visto e durante la fase di elaborazione. Cio` se dopo quattro frame non si sono verie ficate variazioni significative dallo sfondo noi riaggiorniamo il medesimo con il frame corrente. In questo modo possiamo evitare ulteriori controlli sui valori da assegnare alle soglie di filtraggio (soglia, soglia ) dal momento che filtrano sufficiente-

3.4. ELABORARE UN’IMMAGINE

21

mente il rumore se viene utilizzato uno sfondo “recente”. In realt` il rumore non ` n´ uniforme nel tempo n´ uniforme nello spaa e e e zio. Questo comporter` sicuramente dei risultati soddisfacenti in alcuni casi a e meno soddisfacenti in altri. Ma come ` doveroso ricordare sar` comune a que il Data Center ha soppesare correttamente l’informazione che arriva dal sistema embedded, inquadrandola in un contesto generale e maggiormente informato.

22

CAPITOLO 3. TECNOLOGIE UTILIZZATE

Capitolo 4 Implementazione del sistema
4.1
4.1.1

Il Microcontroller
Il software di controllo
Figura 4.1: Lo schema complessivo del software di controllo

Lo schema precedente illustra, anche se in modo parziale, la sequenza delle 23

24

CAPITOLO 4. IMPLEMENTAZIONE DEL SISTEMA

operazioni che vengono eseguite sul microcontroller. Se in qualsiasi istante viene rilevato un’ errore critico il sistema si reinizializza utilizzando una chiamata alla funzione forceSoftReset. Un aspetto fondamentale, ed essenziale per le prestazioni del sistema, riguarda il formato delle immagini acquisite dalla telecamera. In molte telecamere l’unico formato disponibile ` il JPEG[8] e dunque, per non perdere e di completezza, si ` realizzato (in software) un decoder per tale formato. e In seguito, nel capitolo finale, valuteremo le prestazioni tra un sistema con decoder sw uno con decoder hw.

4.2
4.2.1

La Network camera
Ottenere un’ immagine

Per ottenere un immagine si costruisce una richiesta HTTP e la si invia al webserver della telecamera.
GET /axis-cgi/jpg/image.cgi?resolution=320x240&compression=50 HTTP/1.1 Host: 192.168.99.7 Authorization: Basic cm9vdDpwYXNz

Innanzitutto notiamo che si tratta di una richiesta GET per il protocollo HTTP v. 1.1 con autorizzazione di tipo Basic. La richiesta ` inoltrata verso e l’ host 192.168.99.7 che ` l’indirizzo assegnato alla telecamera. Ci` che segue e o dopo Basic ` la stringa root:pass (username=root, password=pass) codie ficata in BASE64[3]. Una tipica risposta data dalla telecamera ` la seguente: e
HTTP/1.0 200 OK Content-type: image/jpeg JPEG image data

Che oltre ad indicare la corretta interpretazione della richiesta invia anche l’ immagine (320x240) compressa con fattore di qualit` 50 con una a dimensione media di 7KB.

4.2. LA NETWORK CAMERA

25

4.2.2

Il decoder JPEG

Introduzione Il decoder JPEG che si ` realizzato si basa sul jpegdrc progettato da Pierre e Guerrier nel ’98 e successivamente aggiornato da Koen van Eijk nel ’99. Tale software, scritto in C, ` stato realizzato per piattaforme x86 non dunque ote timizzato per sistemi embedded ma sufficientemente compatto per renderne possibile il porting sul nostro microcontroller di riferimento. Il porting ha attraversato essenzialmente 5 fasi. Una prima fase ha visto la riduzione del codice non strettamente necessario e la fusione di tutti i file sorgente (compresi gli header) in un unico file. Nella seconda fase si sono eliminate le chiamate al filesystem, sostituendole con analoghe funzioni per la memoria estesa (il file da convertire viene infatti memorizzato nella memoria estesa del microcontroller). La terza fase ha visto la riscrittura di alcune parti del decoder per non occupare pi` di 47KB. Per ottenere questo u risultato (ottimo se si considera che la versione basse occupa piu di 265KB) ` e stato necessario ridurre l’immagine ogni volta che si decomprimeva il blocco base (MCU). La quarta e quinta fase (integrazione e ottimizzazione) sono state quelle maggiormente impegnative vista la differenza di architettura e gli scarsi strumenti di debugging. Poich` architetture e compilatori diversi codificano spesso differentemene te i tipi di base (int, long , float) si sono dovuti correggere tutti i cast in quelle parti di codice dove venivano eseguite operazioni matematiche per la conversione di un immagine. E’ stato dunque realizzato un decoder JPEG in grado di convertire un’immagine 320x240 a colori in un’immagine 160x120 in scala di grigio, in tempi ragionevoli, per il microcontroller Rabbit RCM3000. Altri possibili approcci: un’implementazione HW La realizzazione software di un decoder consente sicuramente una semplice realizzazione a bassi costi ma rende difficile ottenere delle buone prestazioni. Tuttavia esistono sul mercato svariate soluzioni hardware in grado di convertire immagini JPEG in poche frazioni di secondo. Una soluzione tipica ` e quella che vede l’utilizzo di FPGA collegate ad un microcontroller. Ovviamente tali soluzioni aumentano sensibilmente le prestazioni ma anche i costi ed i costumi complessivi.

26

CAPITOLO 4. IMPLEMENTAZIONE DEL SISTEMA

4.3
4.3.1

Comunicazione
Il modem GSM

Il modem GSM ` un modem Dual Band (900-1800MHz) controllabile attrae verso comandi AT (standard GSM ETSI 07.05 e 07.07) con potenza d’uscita da 1W per GSM1800 a 2W per GSM900. Il collegamento tra il modem e il microcontroller ` realizzato attraverso l’interfaccia seriale (connettore DB9 e per RS232) presente sul microcontroller Rabbit. Si ` resa necessaria la realizzazione di un cavo apposito per connettee re il modem al microcontroller, in quanto sul connettore DB9 della Rabbit vengono mappate due porte seriali (B,C). Lo schema del connettore DB9 ` e mostrato in figura 4.2.

Figura 4.2: Schema del connettore DB9 del modem

Nel microcontroller Tx ` connesso al RxB mentre Rx viene connesso al TxB. e

4.3.2

Inviare il livello del traffico

Per poter inviare un messaggio SMS vengono utilizzati, come precedentemente detto, i comandi AT. Tali comandi vengono incapsulati in normali stringhe ed inviati via seriale al modem. Lo schema che rappresenta l’insieme dei passi per inviare un SMS lo possiamo riassumere nello schema 4.3. Gli stati A, B e C vengono percorsi una sola volta durante la fase di inizializzazione dell’intero sistema. In particolare abbiamo che nello stato A la funzione init modem setta i parametri fondamentali della porta seriale sul

4.3. COMUNICAZIONE

27

microcontroller. Nello stato B si interroga il modem per determinare se si ` e registrato sulla rete GSM. Se cos` non fosse se permane in tale stato. Nello ı stato C si invia al modem i comandi necessari per l’invio di un SMS e per il controllo sugli errori. Infine negli stati D ed E viene costruito il messaggio da inviare attraverso la funzione sendSerial . Figura 4.3: Schema per l’invio di un SMS

Qui di seguito viene riportato ci` che appare su un comune cellulare facente o funzione di modem ricevente. Si pu` notare come il messaggio SMS rispetti o le specifiche definite nel precedente capitolo e come sia semplice l’intera fase di ricezione dei messaggi sul Data Center.

28

CAPITOLO 4. IMPLEMENTAZIONE DEL SISTEMA Figura 4.4: Il messaggio inviato su un cellulare

4.4

L’interfaccia di controllo

Per poter controllare i risultati ed il comportamento de sistema embedded si ` realizzata un’ interfaccia utilizzando Java [5] che potesse comunicare ate traverso una connessione ethernet con il microcontroller. L’ interfaccia si compone essenzialmente di tre parti: un box nel quale viene visualizzato (in percentuale) il livello del traffico, un zona nella quale viene visualizzata l’ immagine che st` analizzando il microcontroller ed infine un barra verticale a che proietta il livello del traffico (la densit` veicolare istantanea) su una scala a di valori che variano da “very low” a “very hight”. Questa scala di valori indica la percentuale di variazione del frame corrente rispetto allo sfondo, tale valore lo si ` definito un p` impropriamente livello e o del traffico dal momento che per noi viene utilizzato proprio per determinare tale livello. Tuttavia, come si pu` vedere dall’immagine, ci` che realmente o o interessa ` la media di questi valori un determinato arco temporale. e E’ quindi compito del Data Center fornire tale risultato. Questa semplice interfaccia ci mostra solo quello che accade istante per istante durante l’intero arco di funzionamento.

4.4. L’INTERFACCIA DI CONTROLLO

29

Figura 4.5: L’ interfaccia di controllo

30

CAPITOLO 4. IMPLEMENTAZIONE DEL SISTEMA

Capitolo 5 Valutazioni e test effettuati
5.1 Test effettuati

Per testare il sistema complessivamente si ` utilizzato un filmato di una tee lecamera posta su un cavalcavia autostradale. Questo filmato ci ` servito e in molte fasi dello sviluppo. Durante la fase di progettazione ` stato utie lizzato per testare il programma capture (realizzato dal sottoscritto). Tale programma mi ` servito come banco di prova per studiare ed implementare e alcuni algoritmi di elaborazione e per studiarne il relativo carico computazionale. Successivamente ` stato utilizzato per testare il vero e proprio algoritmo e di elaborazione sul microcontroller. Dopo il test di ogni singola componente si ` eseguito un test complessivo durante il quale ` stato fatto scorrere il e e filmato su un monitor ripreso dalla telecamera Axis. La telecamera ` stata, e ovviamente, posta sullo stesso segmento di rete del microcontroller e dell’interfaccia per consentire al microcontroller il download delle immagini e la relativa elaborazione. I risultati sono stati fatti pervenire sia all’interfaccia di controllo sia (se il livello del traffico era notevole) ad un cellulare attraverso un SMS. Come detto sopra sono stati testati tutti i componenti singolarmente. Si ` testato il modem scrivendo prima un’ applicazione per ambiente Linux e in grado di inviare un SMS e successivamente collegandolo direttamente al microcontroller. E’ stata poi scritta un’ applicazione per connettersi alla telecamera e convertire le immagini da Jpeg a PGM e poi ne ` stato fatto il e 31

32

CAPITOLO 5. VALUTAZIONI E TEST EFFETTUATI

porting sul microcontroller. Durante la fase di sviluppo si ` testato il sistema anche per scenari die versi, come ad’esempio la videosorveglianza per ambienti indoor. Le prove effettuate in ambienti esterni sono state limitate dai numerosi problemi logistici, ma tuttavia sono state comunque sufficienti per consentirci una buona generalizzazione del problema.

5.2

Risultati conseguiti

Dalle prove effettuate ` sempre emerso una forte correlazione tra ci` che venie o va ripreso dalla telecamera e quello che veniva elaborato dal microcontroller. Quello che ci eravamo proposti di ottenere, cio` un’ indice che misurasse l’ine tesit` del traffico, lo abbiamo ottenuto senza la pretesa che esso rappresenti a con precisione ci` che realmente st` succedendo nel tratto stradale. Il fatto o a che i risultati possano essere affetti da rumore non pregiudica necessariamente la validit` di questo approccio. Infatti da un test eseguito ` emerso a e come un cambio repentino della luminosit` impatti solamente per il 15% sul a risultato finale. Tale valore, anche se elevato, v` necessariamente inquadrato a in ottica generale del sistema, nel quale ` il Data Center ha dover soppesare e i singoli risultati comparandoli tra loro e con le loro medie. Quello che il sistema riesce a fornire da una serie di dati ` un’ altra serie e di dati maggiormente informativi dei precedenti, ma pur sempre dei dati. In tale ottica v` visto questo progetto, ed ` per questo che l’ indice del traffico a e che riusciamo ad estrapolare ` in realt` sufficiente per lo scopo che ci siamo e a posti. Da alcuni test effettuati ho notato come (sotto determinate condizioni) aumentando il numero di frame al secondo analizzati si potrebbe riuscire a determinare (con un basso margine d’errore) il numero di autoveicoli transitati nell’ arco del tempo preso in considerazione.

Capitolo 6 Conclusioni
6.1 Sviluppi futuri

Il sistema embedded utilizzato per realizzare questo prototipo ` sistema a e basse prestazioni e non del tutto adatto a questa tipologia di problemi (` e infatti progettato per la realizzazione di controllori automatici). Quello che si propone di utilizzare ` un sistema maggiormente ottimizzato per questa e tipologia di applicazioni, in particolare mi riferisco all’utilizzo di sistemi come XS400 della Xilix. Per quello che riguarda il decoder Jpeg un possibile upgrade potrebbe essere rappresentato dalla realizzazione in hardware del medesimo utilizzando delle FPGA opportune come precedentemente detto. Per la telecamera si potrebbero prevedere due scenari opposti tra loro. Il primo sarebbe quello di passare ad utilizzare una versione notturna con la possibilit` di autoadattamento alla luminosit` esterna. Il secondo approca a cio sarebbe quello di utilizzare due piccole webcam seriali per produrre una visione stereo del tratto stradale aumentando tuttavia la capacit` computaa zionale del microcontroller. Un’ interessante upgrade potrebbe essere quello che riguarda il modulo di comunicazione. Si potrebbe infatti adottare un modem GPRS con stack TCP/IP in grado di offrire una comoda interfaccia programmativa e ovviamente una maggiore banda. Si aumenterebbe, cos` facendo, la robustezza e l’affidabilit` del sisteı a ma con tecnologie gi` presenti e sufficientemente testate e standarizzate dai a 33

34

CAPITOLO 6. CONCLUSIONI

relativi enti e mantenendo un basso costo complessivo.

6.2

Conclusioni generali

Per risolvere il problema dell’analisi e del controllo del traffico attraverso l’utilizzo di calcolatori elettronici sono state adottate molte tecniche[1] che hanno esaurientemente affrontato questo problema. Tuttavia quello che ancora non ` stato concretamente realizzato ` un sistema che integri varie tipologie di e e controllori (sia centralizzati che decentralizzati) in modo che si riesca a coprire una vasta area geografica per offrire un servizio completo al cittadino. I servizi attuali si sono spesso concentrati ed evoluti in quelle aree in cui erano gi` presenti reti e strutture adeguate alle analisi che si volevano coma piere. Mi riferisco in particolare ai servizi per le autostrade o per i grandi raccordi, in cui sono gi` presenti telecamere e collegamenti in fibra ottica o a wireless. Ma in tutte quelle situazioni in cui non ` possibile ricorrere a tali strutture e dobbiamo per forza di cose ricorrere ad una elaborazione locale dell’immagine utilizzando dei sistemi embedded. Nel nostro caso abbiamo fatto vedere come ci` sia effettivamente possibile utilizzando a valle un Data Center, che o conoscendo tutti i dati di tutte le telecamere, sia in grado di dare informativit` ai dati inviati dai sistemi embedded sparsi lungo i vari tratti stradali. a Maggiore sar` la base di dati in possesso del Data Center maggiore sar` a a l’accuratezza e l’efficienza dei risultati calcolati, dunque maggiore sar` l’ina tegrazione delle varie soluzioni oggi esistenti (anche quella proposta in questa tesi) pi` efficacemente potremmo controllare e gestire situazioni di traffico u intenso o di pericolo.

Appendice A Codice
A.1
#define #define #define #define #define #define #define #define #define #define

Alcuni importanti #define
SYS ID 1001 // Siena tangenziale SID “SysID: 1001,ALERT, Traffic: ” PORT A 80 // Telecamera Axis PORT B 1755 // DataCenter WIDTH 320 WIDTH2 160 HEIGHT 240 HEIGHT2 120 ADDRESS “192.168.99.7” NUMBER “3334009570”

A.2

La funzione per il download di una immagine

void getimage() { char buffer[1024]; int i,n; unsigned long k; 35

36

APPENDICE A. CODICE

longword host; tcp Socket axis; n=0;jsize=0; host=resolve(ADDRESS); tcp open(&axis,0,host,PORT A,NULL); while(!sock established(&axis) && sock bytesready(&axis)==-1)tcp tick(NULL); sock write(&axis,&auth[0],strlen(&auth[0])); while(n<3){ sock read(&axis,&buffer[0],1); if(buffer[0]==0x0a)n++; } while(1) { memset(&buffer[0],0x00,1024); n=sock read(&axis,&buffer[0],1024); if(n<= 0)break; k=(unsigned long)(ImageSRC+jsize); root2xmem(k,&buffer[0],n); jsize+=n; } sock close(&axis); }

A.3

Le funzioni per l’ inizializzazione del modem

void init modem() { serBopen(9600); serBflowcontrolOff(); serBdatabits(PARAM 8BIT); serBparity(PARAM NOPARITY); } void init com() { sendSerial(“AT+CMGF=1\r”);recSerial(&p gsm[0]);

A.4. LA FUNZIONE PER L’INVIO DI UN SMS sendSerial(“AT+CMEE=1\r”);recSerial(&p gsm[0]); sendSerial(“AT+CSQ\r”);recSerial(&p gsm[0]); }

37

A.4

La funzione per l’invio di un SMS

void send SMS(char *mex) { memset(t gsm,0,255); memcpy(t gsm,SID,29); strncat(t gsm,mex,1); t gsm[strlen(t gsm)]=0x1a; sendSerial(t gsm);msDelay(11500); recSerial(&p gsm[0]); printf(“%s\n”,p gsm); }

38

APPENDICE A. CODICE

Appendice B Specifiche tecniche
B.1 Microcontroller Rabbit RCM3000

Microprocessore: Rabbit3000 Clock: 29.4MHz Flash Memory: 512K Static RAM: 512K Alimentazione: 3.15 - 3.45 V (145 mA) Temperature: da −40◦ C a 70◦ C Network: 10BaseT Ethernet networks (RJ-45)

B.2

Network Camera Axis2110

Microprocessore: AXIS ETRAX 100LX 32bit RISC CPU Flash Memory: 4 MB Static RAM: 16 MB OS: Linux 2.4 kernel Alimentazione: 9 VDC / 9 W Lens: F 1.0 Varifocal (3.0 - 8.0 mm) automatic DC-Iris Focus range: 0.5 mm to infinity Illumination: 0.75 - 500 000 Lux Network: 10BaseT/100BaseTX Ethernet networks (RJ-45) 39

40

APPENDICE B. SPECIFICHE TECNICHE

B.3

Modem GSM Industrial Base

Tecnologia: Dual Band (900-1800MHz) Servizi: Voce, Fax, SMS, Dati Potenza d’uscita: 2W per GSM900, 1W per GSM1800 Alimentazione: 8V Assorbimento: 140 mA Temperature: da −20◦ C a 55◦ C

Bibliografia
[1] Bruni, E. Analisi della velocit` del flusso veicolare in un sistema di a controllo del traffico basato su elaborazione di immagini. Univerit` di a Siena, Tesi di Laurea, 1999. [2] Fielding, R. Hypertext transfer protocol – http/1.1. RFC 2616, Network Working Group, June 1999. http://ds.internic.net/rfc/ rfc2616.txt;. [3] Freed, N. Multipurpose internet mail extensions. RFC 2045, Network Working Group, Nov. 1996. http://ds.internic.net/rfc/rfc2045. txt;. [4] Harte, L. Introduction to GSM: Physical Channels, Logical Channels, Network, and Operation. Althos, 2004. [5] Hekel, B. Thinking in Java. Apogeo, 2000. [6] Institute, I. S. Transmission control protocol. RFC 793, University of Southern California, Sept. 1981. http://ds.internic.net/rfc/ rfc793.txt;. [7] Kernighan, B. W., and Ritchie, D. M. The C Programming Language, Second Edition. Prentice Hall, Inc., 1988. [8] Tinku Acharya, P.-S. T. JPEG2000 Standard for Image Compression: Concepts, Algorithms and VLSI Architectures. Wiley-Interscience, 2004. [9] Yusef Maali, Gian Lorenzo Meocci, Luca Paolini. IES (Intelligent Evacuation System). Rapporto tecnico, Univerit` di Siena a (http://lnx.programmo.net/ies.pdf), 2004. 41

Sign up to vote on this title
UsefulNot useful