Progettazione e Controllo di una Piattaforma Embedded Multiagente su Rete Wireless

(1)

Indice

1 Introduzione 6

1.1 Alcuni esempi di applicazioni . . . 9

1.2 Obiettivi della trattazione . . . 12

1.3 Struttura della tesi . . . 14

2 Algoritmi decentralizzati e implementazione nei sistemi em-bedded 15 2.1 Introduzione . . . 15

2.2 Gli algoritmi decentralizzati . . . 16

2.3 Principali limitazioni dei sistemi basati su reti . . . 18

2.4 Considerazioni sugli algoritmi decentralizzati . . . 20

2.5 Sistemi embedded . . . 22

3 Struttura degli agenti mobili 24 3.1 Analisi del problema . . . 24

3.2 Caratterizzazione del singolo agente . . . 28

3.2.1 Struttura del veicolo . . . 29

3.2.2 Cinematica . . . 31

3.2.3 Meccanica per l’attuazione . . . 34

3.2.4 Sensori . . . 37

3.2.5 Controllo . . . 39

3.2.6 Prototipazione . . . 51

(2)

INDICE

4 Progettazione dell’Hardware 52

4.1 Requisiti progettuali . . . 52

4.2 Modulo controllo motori . . . 56

4.3 Modulo lettura encoder . . . 62

4.4 Modulo implementazione algoritmo . . . 64

4.5 Circuito di alimentazione . . . 67

4.6 Progettazione del PCB . . . 68

5 Discretizzazione del sistema, approssimazione digitale del con-trollo e programmazione 71 5.1 Discretizzazione del sistema . . . 73

5.2 Approssimazione digitale del controllo . . . 79

5.3 Programmazione . . . 82

5.3.1 Implementazione della comunicazione fra i moduli . . . 82

5.3.2 Microcontrollore controllo motori . . . 85

5.3.3 Microcontrollore lettura encoder . . . 89

5.3.4 Microcontrollore implementazione algoritmo . . . 91

5.4 Analisi tempi di esecuzione e scheduling dei processi . . . 93

5.4.1 Calcolo dei tempi di esecuzione . . . 94 6 Algoritmo di test per la piattaforma: Generalized

Round-about Policy 98

7 Sviluppi futuri 100

Bibliografia 102

(3)

Elenco delle figure

1.1 Logo RUNES . . . 7

1.2 Termostato Madel . . . 10

1.3 Il robot aspirapolvere Orazio . . . 11

1.4 Il robot tagliaerba Oscar . . . 11

2.1 Anello di controllo chiuso con una rete . . . 19

2.2 Anello di comando chiuso con una rete . . . 20

2.3 Ritardo nello scheduling di un task . . . 23

3.1 Scenario . . . 24

3.2 Schematizzazione della struttura hardware della piattaforma . 26 3.3 Veicolo di tipo Uniciclo . . . 29

3.4 Veicolo di tipo Biciclo . . . 29

3.5 Schematizzazione di un veicolo di tipo uniciclo . . . 31

3.6 Grandezze in un veicolo di tipo uniciclo . . . 33

3.7 Servomotore Hitec HS-81 . . . 34

3.8 Motore CC con motoriduttore . . . 35

3.9 Vista dell’asse posteriore . . . 35

3.10 Motore CC con motoriduttore e ruota in foam . . . 36

3.11 Motore CC con encoder posteriore . . . 38

3.12 Motore CC con encoder posteriore e staffa di montaggio . . . 38

3.13 Modello di un motore CC . . . 39

3.14 Vista interna di un motore CC . . . 41

(4)

ELENCO DELLE FIGURE

3.16 Parte meccanica di un motore CC . . . 42

3.17 Modello della coppia d’attrito . . . 43

3.18 Modello Simulink del motore . . . 46

3.19 Modello Simulink del motore . . . 47

3.20 Risposta al gradino in anello aperto . . . 48

3.21 Schema del controllore . . . 48

3.22 Luogo delle radici . . . 49

3.23 Luogo delle radici: dettaglio . . . 49

3.24 Risposta in ciclo chiuso con riferimento pari a 100 RPM . . . 50

4.1 Moduli Hardware . . . 54

4.2 Schema elettrico di un Ponte ad H . . . 56

4.3 Diagrammi di bode del motore . . . 57

4.4 Package dell’integrato L298 . . . 59

4.5 Piedinatura dell’integrato L298 . . . 59

4.6 Disegno dello schematico per l’integrato L298 . . . 60

4.7 Disegno dello schematico per il collegamento dei motori . . . . 60

4.8 Disegno dello schematico per il microcontrollore Master . . . . 61

4.9 Parti dei montaggio dell’encoder ottico . . . 62

4.10 Disegno dello schematico del PSoC Slave . . . 63

4.11 Disegno dello schematico delle resistenze di pull-up . . . 63

4.12 Disegno dello schematico del bus di comunicazione degli encoders 63 4.13 Disegno dello schematico del PSoC per l’esecuzione dell’algo-ritmo . . . 64

4.14 Trama in una comunicazione seriale RS232 . . . 65

4.15 Funzionamento della porta 3-State . . . 65

4.16 Disegno dello schematico per la porta 3-State . . . 66

4.17 Disegno dello schematico per il connettore con il dispositivo wireless . . . 66

4.18 Disegno dello schematico per il circuito di alimentazione . . . 67

4.19 Componenti piazzati sulla board e collegamento dei segnali . . 68

(5)

ELENCO DELLE FIGURE

4.21 Rendering 3D del PCB . . . 70

4.22 Rendering 3D della board . . . 70

5.1 Approccio progettuale . . . 72

5.2 Schematizzazione del controllo . . . 73

5.3 Digitalizzazione di un segnale continuo . . . 74

5.4 Campionamento di un segnale . . . 74

5.5 Caratteristica ingresso/uscita di un quantizzatore . . . 75

5.6 Quantizzazione di un segnale continuo in ampiezza . . . 75

5.7 Modellizzazione dell’errore di quantizzazione . . . 76

5.8 Segnale quantizzato ed errore di quantizzazione corrispondente 76 5.9 Potenza dell’errore si quantizzazione . . . 77

5.10 Potenza del segnale . . . 77

5.11 Integrazione numerica a trapezi . . . 79

5.12 Mappatura dei punti del piano complesso s nel piano comp-lesso z . . . 80

5.13 Ambiente di programmazione PSoC Designer: blocchi UART per la comunicazione . . . 83

5.14 Pacchetto dati scambiato fra i moduli . . . 83

5.15 Diagramma di flusso per la sicurezza della comunicazione . . 85

5.16 Moduli interni del PSoC Master . . . 86

5.17 Schema a blocchi del controllore PID digitale . . . 87

5.18 Segnale PWM . . . 88

5.19 Moduli interni del PSoC Slave . . . 90

5.20 Segnale proveniente dai due canali di un encoder . . . 91

5.21 Moduli interni del PSoC per l’esecuzione dell’algoritmo: bloc-chi digitali per la ricezione e per la trasmissione dei dati . . . 92

(6)

Capitolo 1

Introduzione

I sensori embedded sono ormai onnipresenti. Si possono trovare in diversi campi di applicazioni, dai telefoni cellulari, agli allarmi antifumo, alle celle frigorifere dei camion. Consentire a questi sistemi di comunicare apre nuove possibilit`a nelle applicazioni: automazione industriale, salute, controllo del territorio, monitoraggio in senso lato, distribuzione dell’energia etc. Utiliz-zando queste nuove tecnologie queste applicazioni verranno rese pi`u efficienti oltre che meno costose. Altre invece, fino a poco tempo fa inimmaginabili, potranno essere rese possibili.

Lo sviluppo di sistemi embedded necessita di un linguaggio comune per tutti i sistemi. Senza questo si rischia inutilmente di sprecare risorse eco-nomiche e sforzi in attivit`a di ricerca per garantire l’interoperabilit`a dei sen-sori con le applicazioni.

Lo scopo di questa tecnologia è quello di mettere a disposizione reti di sistemi embedded, eterogenei, su larga scala, capaci di cooperare e ricoprire un ruolo ben preciso nel loro ambiente. A questo scopo, la complessità di questi sistemi deve essere ridotta perché possano essere utilizzati nelle loro piene potenzialità. Si richiede quindi un’architettura standardizzata che per-metta l’auto-organizzazione per adattarsi ad ambienti variabili.

(7)

Esistono vari tentativi per arrivare ad uno standard. Tra questi il pro-getto RUNES, nato a livello europeo, ha come scopo quello di rendere ef-fettiva questa standardizzazione. Gli strumenti per raggiungere questo obi-ettivo sono sistemi basati su piattaforme adattive e un linguaggio comune che semplifichi il processo di creazione delle applicazioni. Questo consentirà un notevole abbassamento dei costi di produzione e un tempo minore di re-alizzazione, trasformando applicazioni già tecnicamente possibili in progetti più facili da realizzare per i designers, consentendo anche la realizzazione di applicazioni fino ad oggi impensabili.

Figura 1.1: Logo RUNES I risultati attesi da questo progetto sono:

• lo sviluppo di tecnologie basate su componenti intelligenti e auto-organizzanti • lo sviluppo di nuovi metodi di controllo avanzato

• sviluppo di nuove applicazioni che migliorino le tecnologie hardware e radio gi`a esistenti

Di seguito vengono riportate alcune possibili applicazioni in cui queste architetture potrebbero essere integrate.

(8)

Salute - La qualit`a e i costi del sistema sanitario sono problemi fonda-mentali in per ogni nazione. In questa ottica l’idea `e quella di rendere pos-sibile il monitoraggio dei pazienti, anche nelle loro case, attraverso l’utilizzo di sensori che forniscano informazioni in tempo reale in modo da garantire una cura appropriata nel minor tempo possibile.

Servizi di emergenza - Disastri naturali o causati dall’uomo costitu-iscono un costante pericolo per singoli, comunità o intere regioni. Uragani, maree, terremoti, incendi sono eventi frequenti e potenzialmente devastan-ti. Le informazioni possono costituire un elemento chiave per prevenire o contrastare i possibili danni che questi eventi possono causare. L’utilizzo di ampie reti di sensori e dispositivi embedded può fornire, per esempio in caso di incendio, una mappa qualitativa e una stima dell’entità del disastro.

Automazione Industriale - Le catene di produzione sono forzate a produrre a costi sempre più bassi forzando l’efficienza della produzione stes-sa, in modo da competere sul mercato. Per questo motivo l’automazione nelle industrie sta avendo un massiccio utilizzo. L’impiego di sensori intelligenti e complessi algoritmi di controllo possono aiutare a ridurre gli sprechi, ridurre i costi e i tempi di lavoro aiutando il coordinamento fra i processi. Inoltre è possibile non solo aumentare le prestazioni ma anche conferire agli impianti un grado di riconfigurabilità superiore e molto veloce da realizzare.

Domotica - Un compito non meno importante è la sicurezza e la comod-ità dell’individuo. La casa è indicata spesso come uno dei posti più pericolosi per molte ragioni. La sicurezza nelle case sfrutta già tecnologie di networking come per esempio il collegamento con la centrale di una compagnia di sorveg-lianza per il controllo e la sorvegsorveg-lianza dell’abitazione. Esistono altri servizi che possono essere messi a disposizione da reti di sistemi embedded. Alcu-ni esempi sono il rilevamento di esalazioAlcu-ni di gas nocivi, surriscaldamento a causa di un possibile incendio, allagamento per la rottura di una

(9)

tubatu-1.1 Alcuni esempi di applicazioni

ra etc. Altri compiti possono essere dedicati al comfort come per esempio la gestione intelligente del frigorifero, luci automatizzate, riscaldamento in-telligente, taglia-erba autonomi e indipendenti etc. I sensori possono essere integrati su veicoli che acquisiscono informazioni direttamente dalla rete prin-cipale situata nell’abitazione.

1.1 Alcuni esempi di applicazioni

I prodotti maggiormente commercializzati negli ultimi anni puntano a coprire la totalit`a delle esigenze della casa automatica. Alcuni applicazioni pratiche di queste tecnologie sono, per esempio, i sistemi di regolazione della tem-peratura a zona. Questo sistema, denominato Zoning System R/C1, perme-tte di impostare e mantenere temperature differenziate nei diversi ambienti in cui viene installato un impianto di condizionamento e/o riscaldamento canalizzato.

In tal modo ogni zona (o stanza), raggiungerà e manterrà la temperatura richiesta in quel momento, evitando sia sprechi energetici sia di dover sac-rificare le esigenze degli uni per soddisfare quelle degli altri. Ad esempio è possibile climatizzare una sala riunioni solo per il tempo in cui viene usa-ta, lasciando spento l’impianto per quella zona quando essa non è occupata. Oppure si potrà mantenere una temperatura di confort in un salotto parti-colarmente affollato durante una festa estiva, senza obbligare i bambini che dormono nelle loro camerette a sopportare temperature poco salutari. Fino ad ora la scelta era fra un impianto che permette di regolare la temperatura stanza per stanza (multisplit), e un impianto più affidabile, economico, effi-ciente e di facile manutenzione (canalizzato), ma che viene controllato da un solo termostato (solitamente posto nell’ingresso o in corridoio). Pertanto un

(10)

1.1 Alcuni esempi di applicazioni

simile impianto, pur garantendo una più accurata e gradevole diffusione del-l’aria trattata, senza dover sopportare correnti fredde e/o calde tipiche degli impianti split, non permette agli occupanti delle diverse zone di impostare la temperatura più confortevole per loro, imponendo quindi una scelta che vada più o meno bene per tutti. E’ evidente che la temperatura di confort varia non solo in funzione di parametri oggettivi (esposizione della stanza, calore prodotto da apparecchiature elettriche e no quali computer, televisori, forno etc.), ma anche all’attività svolta in quel momento in quella singola stanza, dall’abbigliamento delle persone presenti, e dalla stessa percezione individ-uale della temperatura. Pertanto la temperatura di ogni zona dovrebbe poter essere regolata localmente.

Figura 1.2: Termostato Madel

Ogni stanza potrà essere dotata di un termostato/telecomando a radio frequenza, su cui impostare la temperatura desiderata. Quando questa viene raggiunta, alla serranda che controlla quella zona viene inviato un comando dalla centrale di controllo che la farà chiudere, impedendo l’immissione di ulteriore aria trattata. Quando la temperatura in ambiente varierà di solo mezzo grado centigrado rispetto a quella impostata, un nuovo segnale farà aprire la serranda, riportando cos`ı la temperatura ambiente conforme a quella richiesta. Non è necessario alcun collegamento fra le serrande motorizzate e la centrale di controllo, poiché la comunicazione fra di loro avviene via radio. Inoltre, se solo alcune serrande sono aperte, l’aria trattata in eccesso viene

(11)

1.1 Alcuni esempi di applicazioni

ricircolata attraverso una serranda di sovrapressione, in modo da ottenere un risparmio sia nei consumi energetici, sia per una minore usura dell’unit`a di trattamento.

Altri prodotti significativi nell’ambito della Domotica sono quelli real-izzati da Zucchetti Robotica2_{. In particolare, questi sono due prodotti}

con-cepiti per operare in modo autonomo ed automatico, senza controllo da parte umana, sono Orazio, aspirapolvere e pulisci-tappeti e Oscar, robot tagliaerba.

Figura 1.3: Il robot aspirapolvere Orazio

Figura 1.4: Il robot tagliaerba Oscar

(12)

1.2 Obiettivi della trattazione

Lo scopo di questo lavoro è la progettazione, la realizzazione e l’analisi delle prestazioni di una piattaforma per la gestione di sistemi multiagente. Gli agenti sono sistemi mobili, dotati di elettronica e sensoristica in grado di renderli più autonomi possibile. Essi devono asservire un compito globale (cioè di squadra) e un compito locale (cioè individuale). In particolare, il compito globale è quello di inseguire le traiettorie di riferimento, mentre il compito locale consiste nel mantenere un comportamento autonomo e in-dipendente, reso possibile dall’utilizzo di sensori per lo più propriocettivi.

Le proprietà principalmente richieste alla piattaforma sono scalabilità e riconfigurabilità; la prima viene raggiunta attraverso la decentralizzazione del controllo, mentre la seconda si ottiene scegliendo una struttura implementa-tiva per gli agenti modulare: questo consente di cambiare il comportamento di ogni agente semplicemente intervenendo sul modulo interessato.

Come case study per il test della piattaforma, è stata realizzata la simu-lazione di un algoritmo di pianificazione ottima della traiettoria, con controllo decentralizzato (cfr. [1]). Gli agenti devono seguire i riferimenti cinematici generati dall’algoritmo [1] ed essere dotati di capacità di comunicazione: sono necessari quindi una adeguata struttura informativa per la comunicazione fra gli agenti ed una corretta gestione delle informazioni provenienti dalle fonti come sensori, apparati di comunicazione, unità di elaborazione dell’algoritmo etc.

Il risultato finale comporta un elevato carico di lavoro. Per questo il pro-getto `e stato realizzato in collaborazione con il candidato Convalle Alessan-dro [6].

(13)

1.2 Obiettivi della trattazione

• Implementazione della parte di comunicazione su rete, realizzazione della struttura informativa per la comunicazione, studio dei protocolli di comunicazione fra nodi e sviluppo del software di visione per il RLS (Remote Localization Service)(cfr. [6].

• Progettazione della struttura hardware per il controllo distribuito, stu-dio del controllo dei veicoli, progettazione della parte elettronica per la realizzazionel controllo su sistema embedded, studio dei protocolli per l’interfacciamento con la rete di comunicazione, studio dei protocolli di comunicazione interni, prototipazione dei veicoli, porting dell’algorit-mo su sistema embedded (in questo lavoro).

(14)

1.3 Struttura della tesi

I passi eseguiti in questo lavoro sono schematizzati nei seguenti punti:

Capitolo 2 Introduzione agli algoritmi decentralizzati, principali differenze con gli algoritmi centralizzati, introduzione alle problematiche e alle limitazioni sui sistemi embedded.

Capitolo 3 Analisi dei requisiti progettuali, motivazione delle scelte proget-tuali, caratterizzazione ad alto livello di ogni singolo agente.

Capitolo 4 Implementazione della struttura dell’agente nel dettaglio: schema a blocchi del controllo, scelta della struttura implementativa, proget-tazione dell’elettronica.

Capitolo 5 Problematiche del sistema a dati campionati, programmazione dei microcontrollori.

Capitolo 6 Porting dell’algoritmo [1] su piattaforma embedded. Capitolo 7 Considerazioni e conclusioni.

(15)

Capitolo 2

Algoritmi decentralizzati e

implementazione nei sistemi

embedded

2.1 Introduzione

Negli ultimi anni la ricerca ha dato sempre più importanza al problema di come azioni individuali di un gruppo di agenti con possibilità di interagire fra loro, possa dare origine a un comportamento coordinato. I campi in cui questa situazione si può verificare sono molteplici. Nel campo del control-lo, questo interesse si concretizza nella ricerca di metodologie di gestione di veicoli autonomi, come aerei, robot mobili, veicoli marini etc. Il prob-lema può ritrovarsi in diverse applicazioni dal controllo del traffico aereo, terrestre, marino etc e con differenti intenti, quali evitare collisioni, control-lare le manovre di aerei o imbarcazioni in prossimità degli aeroporti o dei porti, volo in formazione di veicoli aerei o marini etc.

(16)

2.2 Gli algoritmi decentralizzati

La necessità di gestire sistemi costituiti da più agenti cooperanti porta alla necessità di sviluppare teorie per il controllo decentralizzato realizzato tramite reti, in modo da dare origine a sistemi multi-agente con capacità di auto-organizzazione. E’ opportuno, oltretutto, definire ed avere ben presenti le problematiche che si possono incontrare nella gestione di sistemi multi-agente tramite reti, soprattutto nel caso di reti Wireless.

In questo capitolo verr`a introdotto il concetto di algoritmo decentraliz-zato e verranno analizzate le principali differenze tra gli algoritmi di tipo centralizzato. Verranno inoltre accennate alcune problematiche da tenere in considerazione negli algoritmi decentralizzati.

2.2 Gli algoritmi decentralizzati

Un algoritmo decentralizzato è una strategia di controllo per un sistema de-centralizzato. Con sistema decentralizzato si intende una rete i cui nodi sono agenti che non necessitano di un’entità centrale, sia per il controllo che per la comunicazione, a differenza di quanto avviene nei sistemi centralizzati. Ogni nodo ha la capacità di auto-gestirsi e prendere decisioni in maniera autono-ma. Le decisioni sono prese solo in base alle proprie informazioni sensoriali e ai dati scambiati con gli agenti vicini. Pertanto non è presente un’unità cen-trale, o un agente con funzionalità diverse o superiori agli altri, responsabile di compiti decisionali, come invece succede nel caso di sistemi centralizzati. La differenza sostanziale sta quindi nel fatto che nei sistemi centralizzati l’al-goritmo di controllo ad alto livello risiede su un’unità centrale (per esempio un calcolatore con funzione di gateway) che trasmette i comandi ai nodi del-la rete. Gli agenti hanno quindi il solo compito di implementare il controllo dinamico. Diversamente invece, nei sistemi decentralizzati, l’algoritmo sia di controllo ad alto livello (cinematico) che a basso livello (dinamico) sono

(17)

2.2 Gli algoritmi decentralizzati

realizzati direttamente sui nodi.

I sistemi decentralizzati si distinguono da quelli centralizzati per diversi aspetti. In particolar modo, un sistema decentralizzato `e soggetto ai seguenti vincoli:

• Non c’`e un nodo centrale

• Non c’`e una direzione preferenziale nella comunicazione • Non `e nota a priori la topologia della rete

Questi aspetti sono fondamentali nella caratterizzazione dei sistemi e ne-cessitano di alcune riflessioni. Per esempio l’assenza di un’unità decisionale centralizzata rende il sistema facilmente scalabile: infatti non ci sono prob-lemi dovuti alla limitata complessità di calcolo dell’unità centrale, come nel caso degli algoritmi centralizzati. Per questo, la rete può gestire un numero non solo superiore, ma potenzialmente infinito, proprio grazie alla capacità di auto-gestione dei nodi. Un altro vantaggio di questo approccio, sta nella minore quantità di informazioni che devono circolare sulla rete: essendo gli agenti autonomi, non hanno bisogno di ricevere comandi dal nodo centrale, ma comunicano tra loro solamente in funzione della politica stabilita dal-l’algoritmo che implementano. Un altro importante aspetto è che non sia necessario conoscere a priori la topologia della rete: ciò presenta evidenti vantaggi. Per esempio, ancora in termini di scalabilità, non ci sono vincoli sulla topologia della rete, che può cambiare dinamicamente sia in termini di numero di agenti che nella morfologia della rete stessa (soprattutto nel caso di reti wireless con agenti mobili). Questi due vantaggi, conferiscono un’ul-teriore proprietà al sistema: in queste condizioni infatti, il sistema risulta più robusto e tollerante ai guasti. Infatti il comportamento della rete non viene compromesso dalla perdita di nodi esistenti. Senza dubbio però il vantag-gio principale dei sistemi decentralizzati è quello della maggiore semplicità di realizzazione: in virtù delle caratteristiche precedentemente elencate tali

(18)

2.3 Principali limitazioni dei sistemi basati su reti

sistemi risultano pi`u facili da implementare, in quanto si possono utilizzare tecniche di programmazione modulare.

I sistemi decentralizzati necessitano della presenza di una rete di comu-nicazione. Di conseguenza sono soggetti a tutte le problematiche legate alla comunicazione di rete, quali ritardi, perdita di pacchetti, limitazione di ban-da, protocolli di gestione etc. Questo aspetto diventa ancora pi`u importante nel caso di reti wireless. E’ dunque necessario rispettare i trade-off imposti dai parametri della rete e i requisiti del controllo, in modo da massimizzare le prestazioni.

2.3 Principali limitazioni dei sistemi basati

su reti

Spesso nel processo di design di un sistema di controllo si fanno implici-tamente delle ipotesi semplificative sull’idealità del processo da controllare. Talvolta nell’implementazione reale queste assunzioni possono essere non ac-cettabili. Di conseguenza, le prestazioni del sistema controllato risultano seriamente differenti da quelle aspettate, con evidenti perdite di prestazioni, fra cui anche la possibile perdita di stabilità. La presenza di una risorsa con-divisa quale la rete di comunicazione è la causa principale di inconvenienti quali il ritardo di comunicazione o la perdita dei pacchetti, con conseguenti problemi sui vincoli real-time a cui è spesso soggetto il sistema da controllare.

La decentralizzazione del controllo attraverso una rete `e generalmente strutturata distribuendo su nodi esterni all’unit`a centrale la parte di sen-soristica e quella di attuazione. In seguito vengono riportati due esempi di una possibile implementazione.

(19)

2.3 Principali limitazioni dei sistemi basati su reti

Nel primo (Figura 2.1) il controllore C, il sensore S e l’attuatore A sono implementati come nodi separati della rete. Questo tipo di approccio, uti-lizzato quando nel loop di controllo i sensori e gli attuatori devono essere separati dal controllore, `e tipico delle applicazioni “automotive”.

Figura 2.1: Anello di controllo chiuso con una rete

Spesso il controllore è implementato con una struttura a cascata, che può essere suddivisa in sottosistemi e implementata in più nodi facenti parte della rete. In presenza di tale situazione è necessario tenere in considerazione le due fonti principali di ritardo che possono essere introdotti da questa struttura:

• ritardi nella comunicazione, in quanto sulla rete devono transitare sia i segnali di misura (dagli sensori al controllore) che i segnali di controllo (dal controllore agli attuatori)

• ritardi computazionali, dovuti all’elaborazione delle informazioni che ogni nodo deve compiere

Queste limitazioni, inevitabilmente presenti in ogni rete, possono causare eccessivi ritardi, errori nella comunicazione, disturbi, limitazione nella ban-da, perdita di pacchetti etc.

Nel secondo esempio invece (Figura 2.2) il processo è localmente control-lato da uno o più controllori: quindi l’anello principale di controllo non è

(20)

2.4 Considerazioni sugli algoritmi decentralizzati

chiuso attraverso la rete.

Figura 2.2: Anello di comando chiuso con una rete

La rete realizza la connessione fra il supervisore e l’impianto, implemen-tando solo la comunicazione dei comandi ad alto livello e l’interfacciamento con l’operatore. In questo caso i vincoli temporali per garantire la tempo-rizzazione real-time son meno stringenti e la quantit`a di informazioni che transita sulla rete `e notevolmente ridotta.

2.4 Considerazioni sugli algoritmi

decentral-izzati

Negli ultimi anni l’interesse per i sistemi multi-agente sta crescendo rapi-damente. Le applicazioni che fanno uso di queste teorie sono molteplici: traffico aereo, esplorazioni, sorveglianza etc. L’approccio decentralizzato of-fre notevoli vantaggi rispetto all’approccio a singolo agente, in termini di esecuzione del task globale, di robustezza del sistema in presenza di guasti e soprattutto di scalabilit`a. Dall’altro lato necessita di sforzi per la gestione delle informazioni distribuite, la coordinazione degli agenti, la scelta di un protocollo di comunicazione e la ricerca della sicurezza.

(21)

2.4 Considerazioni sugli algoritmi decentralizzati

Il coordinamento dei veicoli è stato finora affrontato con algoritmi cen-tralizzati, in cui le traiettorie sono calcolate da un unico decision maker per tutti gli agenti. Le nuove tecnologie mettono a disposizione la possibilità di realizzare reti di sensori che hanno portato a rivoluzionare completamente il modo di gestione di questi algoritmi: ogni agente pianifica la sua traiettoria in base solo alle informazioni dei suoi vicini. Una soluzione di questo tipo reagisce in maniera molto più veloce a situazioni inaspettate, ma richiede una più attenta analisi delle condizioni di sicurezza, per evitare che possibili conflitti causino un effetto domino e che venga compromessa la convergenza della soluzione.

Gli algoritmi decentralizzati vengono studiati per raggiungere diversi obi-ettivi. Principalmente vengono introdotti nella risoluzione dei problemi di path-planning. A questo proposito, vengono riportati i tre compiti principali richiesti a gruppi di veicoli cooperanti:

Allineamento: tutti i veicoli devono muoversi asintoticamente alla stessa velocit`a

Collision-avoidance: ad ogni istante di tempo, le distanza fra i veicoli non devono essere minori di una soglia prestabilita

Coesione: la distanza fra coppie di veicoli deve convergere asintoticamente a un dato set-point

In questo lavoro di tesi verrà implementata un’architettura per la gestione di agenti mobili con controllo Embedded. Per la verifica delle funzionalità di questo sistema è stato implementato un algoritmo decentralizzato per la gestione del traffico aereo [1].

(22)

2.5 Sistemi embedded

Nei sistemi embedded è richiesta una attenta gestione delle risorse disponi-bili, in quanto generalmente sono soggetti a pesanti restrizioni in termini di capacità di calcolo. Un aspetto da non trascurare è l’analisi di schedulabilità dei processi da eseguire sul sistema embedded. In presenza di comunicazioni tramite reti le tecniche di analisi di schedulabilità devono prendere in consid-erazione i vincoli e la degradazione delle prestazioni introdotta da tale strut-tura. E’ indispensabile collezionare informazioni il più possibile attendibili sul sistema e sulla rete e analizzare le proprietà e le prestazioni nel worst-case.

Purtroppo non sempre `e possibile ottenere stime esatte o comunque sod-disfacenti per i problemi introdotti dalla comunicazione di rete, soprattutto in presenza di collegamento wireless. Per questo spesso si ricorre a sistemi con controllo adattivo, che forniscono servizi come la riallocazione dinamica delle risorse disponibili.

Una risorsa la cui disponibilit`a risulta critica `e il tempo. Le applicazioni real-time pongono vincoli stringenti sulla temporizzazione. Tali parametri diventano notevolmente importanti quando le reti introducono ritardi nella sincronizzazione del clock real-time e conseguentemente dello spostamento degli istanti di campionamento, a causa delle latenze che variano in maniera non deterministica.

Nei termini di un’applicazione di regolazione, si suppone generalmente che il task di controllo sia schedulato periodicamente agli istanti rk = hk,

con h intervallo di campionamento nominale del controllore.

L’istante reale in cui il processo viene schedulato varia nel tempo a causa delle latenze di rete. Quindi, con riferimento alla Figura 2.3, l’intervallo di campionamento `e tempo variante ed uguale a

(23)

2.5 Sistemi embedded

Figura 2.3: Ritardo nello scheduling di un task

hk = h − Lk−1s + L k

s (2.1)

Per i sistemi implementati attraverso reti in cui si hanno ritardi fissi, si può fare uso della teoria dei sistemi a dati campionati, dal momento che possono essere considerati sistemi lineari tempo invarianti. Diverso è il dis-corso in presenza di sistemi con ritardo variabile: il problema può essere affrontato in maniera stocastica o deterministica. Nell’analisi stocastica il ritardo variabile è modellato come una variabile casuale con distribuzione di probabilità conosciuta, mentre nel caso deterministico si suppongono noti i limiti inferiore e superiore del ritardo. Nel primo caso si preferisce un ap-proccio al controllo basato su metodologie stocastiche, mentre per il secondo si prediligono le tecniche di controllo robusto.

Il progetto di un sistema di controllo decentralizzato basato su una rete wireless deve tenere in considerazione l’architettura della rete, la gestione delle risorse, l’algoritmo di controllo e le prestazioni globali del sistema. Questo approccio `e particolarmente importante nel caso di sistemi con scarse risorse.

(24)

Capitolo 3

Struttura degli agenti mobili

3.1 Analisi del problema

Il progetto prevede la progettazione, la realizzazione e l’analisi delle prestazioni di una piattaforma per la gestione di sistemi multiagente costituita da agenti mobili. Come situazione per il test della piattaforma, `e stata scelta la simu-lazione dell’algoritmo [1]. Come possibile scenario di implementazione viene proposto quello di figura 3.1:

(25)

3.1 Analisi del problema

Come è possibile vedere dalla figura, è presente un numero n di veicoli il cui compito è quello di partire da un certo stato iniziale [x0, y0, ϑ0] e

por-tarsi in uno stato finale [xf, yf, ϑf] seguendo i riferimenti di velocit`a generati

dall’algoritmo cinematico. I veicoli devono essere in grado quindi di seguire tali riferimenti di velocità. Devono essere inoltre dotati di capacità di comu-nicazione in quanto è necessario uno scambio di informazioni tra gli agenti stessi, in base alle politiche stabilite dall’algoritmo implementato. Si nota inoltre la presenza di una webcam che ha la funzione di fornire il servizio di RLS (Remote Localization Service). Tramite questo sensore esterno infatti, ad ogni veicolo viene comunicato, ad ogni istante di campionamento, il suo stato attuale. Il sistema deve evolvere fino all’istante in cui tutti i veicoli sono giunti nello stato finale.

E’ necessario quindi analizzare il problema al fine di formalizzare le speci-fiche che deve rispettare il sistema e i vincoli a cui `e sottoposto.

Possiamo vedere il problema suddiviso nei seguenti punti principali: • Realizzazione degli agenti mobili

• Porting dell’algoritmo su piattaforma embedded basata su linguaggio C

• Implementazione dell’architettura di rete per la comunicazione • Sviluppo del software di visione per il RLS

La realizzazione di questi punti comporta un carico di lavoro molto oneroso. Per questo i compiti sono stati suddivisi per arrivare al lavoro finale. In par-ticolare, in questa trattazione viene sviluppato il primo e il secondo punto. Per quanto riguarda il punti tre e quattro, si rimanda alla bibliografia [6].

(26)

Tale suddivisione consente di svincolare il lavoro di progettazione di una struttura dall’altra, pur tenendo presente che andranno comunque mantenute delle specifiche al momento dell’interazione fra le due componenti. Restano da stabilire le specifiche di controllo per il sotto-sistema costituito dai veicoli e i protocolli per lo scambio delle informazioni con il sotto-sistema rappre-sentato dalla rete wireless che fornisce il servizio di comunicazione. Nella figura 3.2 viene mostrata una schematizzazione della struttura hardware del-la piattaforma.

Figura 3.2: Schematizzazione della struttura hardware della piattaforma

Per quanto riguarda i veicoli, ricordiamo che il task principale è quello di inseguire i riferimenti forniti dall’algoritmo. Si tratta di riferimenti di ve-locità, in quanto l’algoritmo opera a livello cinematico. Inoltre, gli agenti mobili devono essere in grado di comunicare fra di loro. E’ necessario per cui definire una struttura hardware capace di asservire ai compiti di controllo (sia cinematico che dinamico), nonché di una struttura informativa adeguata alla gestione e allo scambio delle informazioni.

Di seguito vengono riportati gli argomenti sviluppati in questo lavoro: • Progettazione della struttura meccanica dei veicoli

(27)

• Architettura del controllo

• Progettazione della parte elettronica

• Programmazione dei microprocessori per il controllo

(28)

3.2 Caratterizzazione del singolo agente

La progettazione della struttura di ogni singolo agente impone considerazioni di carattere tecnico in funzione dei requisiti e delle specifiche generali. Tali requisiti sono suddivisibili secondo lo schema seguente:

Struttura del veicolo Scelta della struttura cinematica in base alle manovre e alle prestazioni richieste all’agente.

Meccanica Scelta delle parti meccaniche per l’attuazione.

Capacit`a sensoriali Scelta della sensoristica di bordo strettamente nec-essaria a garantire l’autonomia.

Controllo Progettazione dell’architettura di controllo.

Prototipazione Progettazione della struttura Hardware/Software per l’im-plementazione del controllo.

Sono inoltre da tenere in considerazione altri requisiti comuni alle categorie sopra citate:

Dimensioni La dimensione finale di ogni singolo agente deve essere molto ridotta.

Risorse Le risorse energetiche e computazionali sono molto limitate. Modularit`a E’ preferibile impostare l’architettura su un sistema pi`u

modu-lare possibile, in modo da rendere più semplici eventuali modifiche/aggiornamenti. Scalabilità della rete La piattaforma non è basata su un numero ben

pre-ciso di agenti: `e necessario quindi che l’architettura risenta il meno possibile delle variazioni del numero di agenti.

(29)

3.2.1 Struttura del veicolo

La scelta della struttura di implementazione del veicolo influisce sia sulla manovrabilità del veicolo stesso che sulla complessità del controllo. Sono necessarie quindi alcune considerazioni a partire dalla cinematica del veicolo. Generalmente le tipologie più comuni e semplici di struttura cinematica per un robot sono quella di tipo uniciclo (figura 3.3) e biciclo (figura 3.4).

Figura 3.3: Veicolo di tipo Uniciclo

Figura 3.4: Veicolo di tipo Biciclo

Esistono anche strutture relativamente pi`u complesse, come il tipo skid-steering, ma la loro trattazione `e al di fuori di questo contesto.

Nelle figure 3.3 e 3.4 con la lettera C è indicato il CIR (Centro di Is-tantanea Rotazione). Come è possibile vedere, la struttura di tipo biciclo ha un solo grado di libertà, in quanto il CIR si trova nel punto di intersezione

(30)

delle perpendicolari alle direzioni di avanzamento delle ruote. Questo causa non solo una limitazione del raggio di curvatura del veicolo, ma anche una ridotta manovrabilit`a del veicolo stesso (dovuta al singolo grado di libert`a).

In un veicolo di tipo uniciclo invece, il CIR pu`o trovarsi in un qual-siasi punto della retta perpendicolare alla direzione di avanzamento delle ruote (retta dei CIR). Questa caratteristica consente al veicolo di effettuare manovre con raggio di curvatura da zero a infinito.

La struttura scelta per la realizzazione degli agenti è quella di tipo unici-clo. La scelta è dovuta alla maggiore mobilità di questa struttura cinematica (2 GDL) e alla maggiore semplicità di costruzione e implementazione del con-trollo. E’ sufficiente infatti una struttura meccanica costituira da due ruote allineate sullo stesso asse e una terza ruota, passiva. Non è infatti necessario un meccanismo per la sterzata.

(31)

3.2.2 Cinematica

Fissata la struttura del veicolo, `e necessario scrivere le equazioni che ne re-golano la cinematica diretta. Fissato il sistema di riferimento, le variabili necessarie per la completa descrizione del modello cinematico sono x, y e ϑ, cio`e le coordinate del centro dell’asse del veicolo e la direzione di avanzamen-to, riferita come angolo formato con l’asse delle ascisse, come mostrato in figura 3.5:

Figura 3.5: Schematizzazione di un veicolo di tipo uniciclo Per ricavarne le equazioni cinematiche partiamo innanzitutto con la scrit-tura delle equazioni che descrivono i vincoli. Per veicoli tipo uniciclo il vincolo è costituito dall’impossibilità di muoversi lungo la direzione parallela all’asse delle ruote. Questo può essere tradotto in un vincolo anolonomo espresso dall’equazione: [− sin(ϑ) cos(ϑ)] " ˙x ˙ y # = 0 (3.1)

(32)

3.2 Caratterizzazione del singolo agente Definito q =     x y ϑ     (3.2)

e portando l’equazione in forma Pfaffiana otteniamo:

A(q) ˙q = 0 (3.3)

A(q) = [− sin(ϑ) cos(ϑ) 0] (3.4)

A questo punto la cinematica del veicolo `e descritta dall’equazione:

˙

q = S(q)λ (3.5)

dove la matrice S(q) rappresenta il nullo della matrice A(q) e il vettore è il vettore delle quasi velocità. Ricavando l’espressione S(q) possiamo trovare le velocità del veicolo compatibili con i vincoli. In particolare:

S(q) =     cos(ϑ) 0 sin(ϑ) 0 0 1     (3.6)

per cui il modello cinematica del veicolo diventa:     ˙x ˙ y ˙ ϑ     =     cos ϑ sin ϑ 0     λ1+     0 0 1     λ2 (3.7)

(33)

dove λ1 e λ2 sono definite come quasi velocit`a compatibili con i vincoli

del sistema. L’interpretazione fisica di queste grandezze `e che effettivamente λ1 esprime la velocit`a di avanzamento perpendicolare all’asse delle ruote,

mentre λ2 indica la velocit`a di rotazione attorno al centro, anche se poi

esse non costituiscono delle vere e proprie velocit`a, in quanto integrandole non otteniamo niente di fisicamente significativo. Costituiscono comunque gli ingressi di controllo del modello cinematico. Supponendo inoltre di conoscere le velocit`a angolari wr e wr delle due ruote ed il loro raggio, con riferimento

alla figura 3.6, le espressioni per la velocit`a lineare ed angolare sono:

v = (wr+ wr)

2 r (3.8)

w = (wr− wr)

2L r (3.9)

(34)

3.2.3 Meccanica per l’attuazione

Data la cinematica del veicolo, sono necessari due attuatori indipendenti sulle due ruote. Anche la scelta di motori diversi può causare un diverso comportamento e prestazioni variabili. E’ dunque necessario scegliere il tipo di motori più adatto al fine di conferire al veicolo le prestazioni desiderate. In questo caso il requisito fondamentale è la precisione nei movimenti e nel seguire le manovre, piuttosto che un’alta velocità.

Allo scopo di garantire una bassa velocit`a di avanzamento e una coppia sufficiente per effettuare i cambi di direzione, si possono utilizzare i servomo-tori. Un servomotore standard `e mostrato in figura 3.7.

Figura 3.7: Servomotore Hitec HS-81

Questi motori offrono una bassa velocità di rotazione, una coppia elevata e, avendo integrata una parte elettronica per il controllo, nessun componente esterno per l’interfacciamento con un microcontrollore. Vengono comandati con un segnale PWM, ma non avendo la possibilità di essere sensorizzati tramite encoders, il controllo agisce il ciclo aperto. In questa applicazione ciò non è accettabile, in quanto gli agenti sono vincolati a rispettare specifiche restringenti dal punto di vista del controllo: devono infatti stabilizzarsi su circonferenze di raggio ben definito, seguire riferimenti di velocità con buone

(35)

prestazioni etc. E’ indispensabile quindi avere a disposizione la misura della velocit`a angolare dei motori.

Dunque, sono stati scelti due motori CC da 7,2 Vdc con motoriduttore mostrati in figura 3.8 (per le specifiche tecniche ed il modello del motore, si rimanda alla sezione ??). Il motoriduttire ha l’asse posteriore uscente, per il montaggio di un encoder, visibile in figura 3.9.

Figura 3.8: Motore CC con motoriduttore

(36)

In figura 3.10 `e visibile il motoriduttore montato su staffa con la ruota in foam.

(37)

3.2.4 Sensori

I sensori sono uno strumento fondamentale per rendere possibile l’interazione fra un robot e l’ambiente che lo circonda oppure per evolvere verso uno stato desiderato. Costituiscono la fonte di informazioni utili al controllo. Nel par-lare di informazioni un aspetto da tenere in considerazione è la ridondanza. Le informazioni, in quanto tali, risultano più affidabili, attendibili e sicure se ridondanti. Lo stesso potrebbe dirsi per una grandezza letta da un sensore: più misure vengono effettuate su tale grandezza, anche da sensori diversi, migliore sarà la misura, o almeno la sua stima.

Non sempre però è possibile o conveniente fare uso di sensori in elevato numero. Dover gestire un numero più elevato si sensori richiede una maggiore capacità computazionale per l’acquisizione, il filtraggio e la stima dei dati. In applicazioni in cui la criticità è data soprattutto dalle limitazioni dovute all’energia disponibile, alla compattezza e alla limitata capacità di calcolo, è preferibile un approccio diametralmente opposto: ridurre al minimi il carico in termini di pesantezza computazionale e consumo di energia.

In questo caso specifico, sensori di importanza fondamentale sono gli en-coders ai motori delle due ruote: `e importante infatti che i riferimenti cin-ematici, dopo essere trasformati in velocit`a angolari delle ruote, vengano seguiti con errore praticamente nullo.

(Altri sensori se ne verranno messi...)

Gli encoders scelti sono da 300 impulsi/giro (1200 se letti in quadratura) e sono mostrati in figura 3.11 e 3.12:

(38)

Figura 3.11: Motore CC con encoder posteriore

Figura 3.12: Motore CC con encoder posteriore e staffa di montaggio

(39)

3.2.5 Controllo

Il controllo a basso livello per ogni singolo agente consiste nella regolazione della tensione dei motori in modo tale da seguire i riferimenti di velocità generati dall’algoritmo. L’analisi del sistema e lo studio del controllore è sta-to realizzasta-to attraverso Matlab/Simulink. L’implementazione in linguaggio C sul dispositivo embedded verrà presentata più avanti.

Il modello di un motore DC `e mostrato in figura 3.13:

(40)

Con riferimento alla figura 3.13, indichiamo il significato dei parametri: • Va `e la tensione di alimentazione

• R `e la resistenza di armatura • L `e l’induttanza di armatura

• Vemf `e la tensione dovuta alla forza contro-effettomotrice

• τm `e la coppia generata dal motore

• ω = ˙ϑ è la velocità angolare dell’albero del motore • Kf è la costante di attrito

• J `e l’inerzia del rotore rispetto all’asse di rotazione

Generalmente, lo studio del modello di un motore in corrente continua si effettua suddividendo la parte elettrica dalla parte meccanica e scrivendo le equazioni dinamiche per le due sezioni distinte. Queste vengono poi messe in relazione da opportune costanti di interazione reciproca. Nel modello infatti sono presenti due parametri, non esplicitamente indicati nella figura 3.13. Sono la costante di corrente Ki e la costante contro elettro-motrice Kemf.

La prima indica il coefficiente di proporzionalit`a (assunto costante) che lega la corrente che scorre nel motore alla coppia generata all’albero; la seconda indica tensione generata per effetto Faraday nel circuito di armatura quando il motore ruota con velocit`a angolare ω, come mostrato in figura 3.14.

(41)

Figura 3.14: Vista interna di un motore CC

Si hanno allora le seguenti relazioni:

τm = Kii

Vemf = KemfVa

Per prima si considera la parte elettrica, schematizzata in figura 3.15:

(42)

dove il generatore di tensione Eg corrisponde alla tensione Vemf. Indicata

con i la corrente che scorre nel circuito di armatura del motore, l’equazione dinamica che regola questo sistema `e:

Va= Ri + L

di

dt + Kemfω (3.10)

Per quanto riguarda la parte meccanica, si deve tenere conto che il motore rappresenta un carico inerziale rotativo. Si consideri un corpo rigido vinco-lato a ruotare attorno ad un asse, schematizzato in figura 3.16. L’inerzia del corpo rispetto tale asse sia Jm.

Figura 3.16: Parte meccanica di un motore CC

Si supponga di applicare una coppia motrice τm, a cui si oppone una

coppia di attrito τf. Le equazioni del moto del sistema, riportato in figura,

sono le seguenti:

τm = J ˙ω + τf (3.11)

Per quanto riguarda la coppia di attrito sono necessarie alcune consid-erazioni pi`u dettagliate. La coppia di attrito pu`o essere modellizzata come riportato nella figura 3.17, dove ad un termine costante dovuto all’attrito

(43)

secco, si sommano un termine di attrito viscoso (che cresce linearmente con la velocit`a) ed uno di attrito statico (che decresce rapidamente per velocit`a immediatamente superiori allo zero).

Figura 3.17: Modello della coppia d’attrito

Per semplicità, l’attrito verrà considerato solo di tipo viscoso; per cui sarà considerato un solo termine costante, Kf, che lega la coppia d’attrito τf alla

velocit`a angolare ω. Si ottiene quindi:

τf = Kfω (3.12)

per cui l’equazione 3.11 diviene:

(44)

Si noti come si raggiunga un equilibrio tra la coppia motrice e quella di attrito (ovvero ˙ω = 0 ) quando

ω = τm

B (3.14)

Ricordando la 3.10, otteniamo:

Kii = J ˙ω + Kfω (3.15)

Nella 3.15 `e opportuno considerare un altro termine τd che tenga conto

di una eventuale coppia di disturbo esterna. Per cui:

Kii = J ˙ω + Kfω + τd (3.16)

Il modello del motore `e quindi completamente descritto dal seguente sis-tema di equazioni:

(

Va = Ri + L_dtdi+ Kemfω

(45)

I valori dei parametri sono i seguenti: • Resistenza di armatura R = 0.5 Ω • Induttanza di armatura L = 1.5 mH

• Costante contro elettro-motrice Kemf = 0.025 V /rad/s

• Costante di corrente Ki = 0.05 N m/A

• Inerzia del rotore J = 0.00025 N m/rad/s2

(46)

In figura 3.18 `e mostrato il modello del motore implementato sotto l’am-biente Matlab/Simulink :

Figura 3.18: Modello Simulink del motore

Il modello implementa i due sottosistemi, costituiti dalla parte elettrica e dalla parte meccanica: sono infatti visibili i due integratori per le variabili di stato i e ω. Nel modello `e inoltre presente un elemento di saturazione, necessario per limitare la tensione di controllo ad un valore di ± 7,2V. Sono inoltre presenti le due costanti Kemf e Ki, che legano i due sottosistemi.

Il blocco denominato reduction costituisce il termine dovuto al rapporto di riduzione del motoriduttore.

Le relazione precedentemente ottenute pongono in relazione la velocità di rotazione ω dell’asse alla tensione V di alimentazione. La misura effettiva-mente retroazionata dall’encoder è però la posizione angolare: è necessario quindi un ulteriore integratore pre ottenere la posizione angolare data da ϑ. In cascata al blocco integratore di ω è presente un elemento quantizzatore: questo è necessario a modellare la discretizzazione della misura introdotta dalle tacche dell’encoder.

(47)

Per comodit`a, l’intero modello del motore viene racchiuso in un unico blocco, come mostrato in figura 3.19:

Figura 3.19: Modello Simulink del motore

Le funzioni di trasferimento associate alle equazioni 3.10 e 3.16 sono rispettivamente: i V = Ki Ls + R (3.17) e: ω i = 1 J s + Kf (3.18)

Si hanno per cui i due poli del sistema:

p1 = R L (Polo Elettrico) (3.19) p2 = Kf J (Polo Meccanico) (3.20) Come primo passo `e stata osservata la risposta al gradino in ciclo aperto. Il grafico `e mostrato nella figura seguente:

(48)

Figura 3.20: Risposta al gradino in anello aperto

Dalla figura si nota che il valore di regime della velocità angolare è circa 175 rpm, esattamente il valore nominale per cui è dato il motoriduttore.

Per quanto riguarda la forma del controllore, `e stato scelto un controllo di tipo P ID mostrato in figura 3.21.

Figura 3.21: Schema del controllore

Per la scelta del guadagno, `e stato osservato il luogo delle radici della F.d.T. del sistema. Il grafico `e riportato in figura 3.22:

Esaminando il luogo delle radici con Matlab, si nota che il valore del guadagno K per cui i poli rimangono a parte immaginaria nulla, `e circa 0.07.

(49)

Figura 3.22: Luogo delle radici

Figura 3.23: Luogo delle radici: dettaglio

Fissato quindi per la componente proporzionale un guadagno di 0.05, i coeffi-cienti per le componenti integrale e derivativa, determinati con la procedura di Ziegler-Nichols, valgono rispettivamente Ki = 0.8 e Kd= 0.5.

Con questi valori per le costanti del controllore, otteniamo la risposta in ciclo chiuso mostrata in figura 3.24:

(50)

Figura 3.24: Risposta in ciclo chiuso con riferimento pari a 100 RPM

(51)

3.2.6 Prototipazione

La parte della progettazione della struttura Hardware / Software richiede un’analisi attenta dei fattori e delle variabili in gioco. Di solito è conve-niente utilizzare meno strutture Hardware possibile, lasciando più possibile i compiti al Software implementato nei microcontrollori. Questo approccio è adatto nelle situazioni in cui si utilizzino dispositivi con elevate capacità di calcolo, tipo FPGA, DSP etc. E’ necessario trovare un giusto compromesso fra numero di componenti esterni e codice da scrivere. Inoltre, si deve fare attenzione a come una scelta da un lato possa influenzare positivamente o negativamente dall’altro.

I vincoli in un’applicazione di questo tipo sono principalmente dovuti al-la limitazione delle risorse, sia energetiche che computazionali, oltre che alle dimensioni.

La progettazione dell’architettura di ogni agente è stata suddivisa in due sezioni: una per la progettazione dell’Hardware e una per la scrittura del Software. In entrambe le fasi è stato necessario considerare le funzionalità sia ad alto livello che a basso livello richiesta all’architettura. In particolare, ogni singolo agente ha il compito locale di implementare il controllo e il compito globale di mantenere una comunicazione con l’esterno. E’ necessaria quindi una struttura che implementi il controllo interno (basso livello) e un’ulteriore struttura che metta a disposizione il servizio di comunicazione (alto livello).

(52)

Capitolo 4

Progettazione dell’Hardware

4.1 Requisiti progettuali

Nella realizzazione dell’elettronica di controllo e gestione di qualsiasi proces-so `e necessario considerare aspetti quali la limitatezza delle risorse, il costo del controllo sia in termini di realizzazione che energetici, il grado di ricon-figurabilit`a richiesto al sistema etc. In particolare, in questa applicazione ad ogni agente sono richieste:

Riconfigurabilit`a : deve essere semplice cambiare il task di ogni agente Compattezza : gli agenti devono avere piccole dimensioni

Costi ridotti : nel caso di produzione in numero elevato, `e necessario minimizzare i costi

Bassi consumi : a causa delle dimensioni ridotte, le risorse energetiche sono limitate

Un buon grado di riconfigurabilit`a per un sistema `e generalmente raggiun-to attraverso una progettazione modulare che introduce i seguenti vantaggi:

(53)

4.1 Requisiti progettuali

1. ogni modulo `e visto come un blocco a s´e stante;

2. la progettazione di ogni singolo modulo `e pi`u semplice della proget-tazione dell’intero sistema;

3. minor carico di lavoro dovuto alla distribuzione dei compiti; 4. il sistema risulta pi`u flessibile e riconfigurabile;

5. in caso di guasto o malfunzionamento, non `e necessario; intervenire sull’intero sistema, solo sul modulo guasto.

Nel caso particolare di questa applicazione, la struttura modulare `e im-posta dall’elevato carico computazionale richiesto ad ogni veicolo. I task, come mostrato in figura 4.1 sono cos`ı suddivisi:

Modulo controllo motori: integrazione temporale per i controllori PID dei due motori, calcolo del controllo, attuazione del controllo ai motori Modulo lettura encoder: lettura delle misure degli encoder

Modulo implementazione algoritmo: calcolo dei riferimenti cinematici in base alle politiche dell’algoritmo [1]

Come sarà mostrato nei paragrafi successivi, non è possibile inglobare tutti i task in un unico microcontrollore, non solo per motivi legati alla frequenza di clock, ma soprattutto per limitazioni dovute alla capacità della memoria flash utilizzata per la memorizzazione del codice, e della memoria ram, necessaria all’esecuzione del codice stesso.

Ogni modulo `e implementato da un microcontrollore progrmmabile e dal-l’elettronica di interfacciamento necessaria per ogni specifico modulo. I col-legamenti necessari per la comunicazione fra i moduli sono di tipo seriale con riferimento allo standard EIARS232 (cfr. [8]).

(54)

Figura 4.1: Moduli Hardware

I microcontrollori scelti sono i PSoC (Programmable Systems-on-Chip) prodotti da Cypress1_{. I PSoC sono microcontrollori di nuova generazione}

che integrano funzionalità programmabili e la possibilità di utilizzare al loro interno blocchi analogici e digitali che normalmente si utilizzano con i mi-crocontrollori tradizionali, come timers, contatori, PWM, UART, SPI, filtri, guadagni, ADC/DAC etc. Questo conferisce una notevole versatilità ed una libertà di programmazione, in quanto la configurazione del microcontrollore non è statica, ma può essere definita dall’utente in base ai requisiti del-l’applicazione. La progettazione a livello del microcontrollore non consiste solamente nella programmazione della parte software, ma parte dalla proget-tazione dell’hardware al suo interno. Ogni singolo microcontrollore infatti, dovendo implementare un modulo ben preciso, richiede al suo interno com-ponenti e funzionalità differenti in ogni singola situazione. Nel paragrafo 5.3 questi aspetti saranno messi in evidenza e sarà trattata la progettazione hardware e la programmazione software per l’implementazione di ogni singo-lo modusingo-lo.

(55)

Per una pi`u completa panoramica sui microcontrollori, si rimanda al man-uale tecnico(cfr. [7]).

Le principali caratteristiche di questa famiglia di microcontrollori sono: • Frequenza di clock di 24 MHz

• 16 Kb di memoria ROM • 256 byte di memoria RAM

• 24 porte I/O suddivise in 3 gruppi

Per la progettazione del circuito elettronico è stato utilizzato il software Eagle CAD2. Per ogni modulo verrà di seguito riportato il disegno dello schematico, mentre per il layout del PCB finale sarà riportata una renderiz-zazione 3D eseguita con POV-RAY.

L’analisi delle problematiche del sistema discretizzato e di stesura del codice saranno presentate nel prossimo capitolo.

(56)

4.2 Modulo controllo motori

Il modulo per il driver dei motori ha il compito di convertire il segnale logico di controllo in uscita dal microcontrollore in segnale di potenza. E’ necessario quindi uno stadio di potenza che sia in grado di pilotare il carico rappresen-tato dal motore.

La soluzione scelta per il circuito di potenza è quella di utilizzare uno schema a Ponte ad H. Un ponte ad H è costituito da quattro interruttori co-mandati da altrettanti segnali logici e permette il funzionamento bidirezionale del motore in presenza di una alimentazione singola. In figura 4.2 è mostrato lo schema elettrico di una configurazione a ponte ad H.

Figura 4.2: Schema elettrico di un Ponte ad H

Lo schema mostra come i quattro transistor sono connessi. In genere i due transistor inferiori (2 e 4 nello schema) sono detti di sink oppure low side switch in quanto assorbono la corrente proveniente da motore; i due tran-sistor connessi direttamente alla Vcc sono detti di source oppure high side switch. Il ponte ad H `e utilizzabile in funzionamento on/off semplicemente applicando gli opportuni segnali logici per ottenere rotazione in un verso o nel verso opposto, frenata rapida o frenata lenta. In particolare, attivan-do un transistor di sink e il transistor di source dalla parte opposta si pu`o

(57)

controllare il verso del motore; `e importate evitare la situazione in cui siano attivi entrambi i transistor di source e di sink dallo stesso lato: in questo caso infatti si genererebbe un cortocircuito fra la linea di alimentazione e di massa.

Come già detto, il pilotaggio del motore avviene in maniera on/off. Questo si ottiene inviando alla base dei transistors un segnale PWM ad una frequen-za di almeno una decade superiore alla banda passante del motore: si ha come conseguenza che il motore agisce da filtro passa-basso e la tensione ai suoi capi è pari al duty-cicle del segnale PWM. In questo modo si ha la possibilità di controllare la velocità di rotazione dell’asse del motore. Per il dimensionamento della frequenza del segnale PWM si è fatto riferimento ai diagrammi di bode del motore, riportati in figura 4.3.

Figura 4.3: Diagrammi di bode del motore

Il microcontrollore PSoC ha un oscillatore interno a 32KHz da utilizzare come sorgente di clock per pilotare i moduli interni; pilotando il modulo PWM con questo clock, il segnale PWM ha una frequenza di 32KHz,

(58)

suffi-4.2 Modulo controllo motori

cientemente superiore alla banda passante del sistema.

Esistono due modalit`a principali per pilotare dal punto di vista logico un ponte ah H:

Sign/magnitude PWM: occorre un segnale pwm per l’ampiezza ed uno costante per il verso di rotazione. Il duty cycle del segnale pwm varia tra lo 0% (motore fermo) ed il 100% (motore a piena velocit`a); esso deve essere applicato direttamente ad una coppia diagonale di transistor mentre l’altra deve essere spenta. L’ingresso costante serve per scegliere a quale coppia di transistor applicare il segnale pwm.

Locked anti-phase PWM: occorre un solo segnale pwm tale che quando è alto è in conduzione una coppia di transistor, quando è basso l’altra. L’effetto è quello di forzare la corrente nel motore prima in un verso, poi nell’altra: a causa dell’induttanza si ha una stabilizzazione intorno al valor medio. In particolare quando un duty cycle è del 50% sia la corrente che la tensione media sono nulle e quindi il motore è fermo. Quando il duty cycle tende al 100% il motore ruota a piena velocità in un verso, quando è dello 0%, ruota a piena velocità nell’altro verso. Nella prima configurazione (Sign/magnitude PWM:) si rendono necessari due ingressi costanti per stabilire il segno e un segnale PWM per stabilire l’ampiezza. Nella seconda (Locked anti-phase PWM:) invece bastano due in-gressi: uno di enable e uno di comando, ma è necessario avere una sorgente di alimentazione duale, in modo che quando il duty-cicle del segnale PWM è al 50% la corrente che circola nel motore sia nulla.

In questa applicazione `e stata adottata la prima soluzione, che semplifica il circuito di alimentazione in quanto le uscite digitali fornite dal microcon-trollore sono sufficienti.

(59)

Per la realizzazione del circuito di potenza `e stato scelto l’integrato L298 prodotto da STMicroelectonics che implementa al suo interno un ponte ad H. Nelle figure 4.4 e 4.5 sono mostrati rispettivamente il package e la piedinatura dell’integrato. Per una completa descrizione delle specifiche dell’integrato, si rimanda al datasheet del componente, allegato in appendice.

Figura 4.4: Package dell’integrato L298

Figura 4.5: Piedinatura dell’integrato L298

(60)

realizzato attraverso il software EagleCad `e riportato in figura 4.6.

Figura 4.6: Disegno dello schematico per l’integrato L298 In figura 4.7 `e invece mostrato lo schematico per il disegno delle con-nessioni dei motori. La presenza dei diodi `e necessaria a prevenire danni all’integrato L298 dovute alle correnti di ricircolo causate del comportamen-to induttivo del mocomportamen-tore.

Figura 4.7: Disegno dello schematico per il collegamento dei motori Il microcontrollore dedicato alla gestione di questo modulo ha la il com-pito di implementare il controllore PID per l’inseguimento dei riferimenti di

(61)

velocità e di generare i quattro segnali logici per il controllo del verso di rotazione dei motori e dei due segnali PWM per il controllo della velocità. Sono inoltre state predisposte due linee di comunicazione seriale per la co-municazione con gli altri due microcontrollori dei due restanti moduli. Le linee sono unidirezionali, in quanto le informazioni dagli altri due moduli sono solo in ricezione. Questo modulo è stato implementato all’interno di un microcontrollore PSoC denominato PSoC Master. La figura 4.8 mostra lo schematico relativo.

Figura 4.8: Disegno dello schematico per il microcontrollore Master

(62)

4.3 Modulo lettura encoder

Per la lettura degli encoder è stato necessario realizzare un modulo dedicato. E’ stato quindi predisposto un ulteriore microcontrollore, denominato slave, programmato per misurare la velocità di rotazione degli assi dei due motori e comunicare i dati al processore master. In figura 4.9 è mostrato l’encoder ottico utilizzato per la misura della velocità.

Figura 4.9: Parti dei montaggio dell’encoder ottico

Il sensore ottico è un fototransistor, la cui base viene eccitata dalla luce emessa dal fotodiodo. L’uscita dell’encoder è di tipo open-collector, cioè direttamente collegata al collettore del fototransistor. Sono state quindi ag-giunte due resistenze di pull-up per ogni coppia di transistor. Lo schematico in figura 4.10 mostra il PSoC Slave con il bus di comunicazione con gli en-coders e la linea di comunicazione seriale con il PSoC master, mentre la figura 4.11 mostra le resistenze di pull-up per i quattro canali degli encoder. Infine in figura 4.12 sono mostrati i connettori per l’encoder ed il bus di comunicazione.

(63)

4.3 Modulo lettura encoder

Figura 4.10: Disegno dello schematico del PSoC Slave

Figura 4.11: Disegno dello schematico delle resistenze di pull-up

Figura 4.12: Disegno dello schematico del bus di comunicazione degli encoders

(64)

4.4 Modulo implementazione algoritmo

Date le esigue capacità computazionali disponibili su un processore, è sta-to necessario dedicare un intero microcontrollore per la sua esecuzione. Il porting dell’algoritmo sulla piattaforma embedded sarà descritto nel capito-lo ??. Nella figura 4.13 è riportato lo schematico del modulo che implementa l’algoritmo.

Figura 4.13: Disegno dello schematico del PSoC per l’esecuzione dell’algoritmo

In questo modulo sono presenti due linee di comunicazione: una, in us-cita, per comunicare al PSoC Master il comando generato dall’algoritmo e l’altra, in ingresso, per ricevere i dati provenienti dalla rete wireless, tramite comunicazione seriale.

Insieme a questo modulo è necessario un circuito di condizionamento per interfacciare il microcontrollore con il dispositivo per la comunicazione wire-less. Infatti il sensore wireless un modulo per la comunicazione radio e un modulo per la comunicazione seriale che sfruttano un unico bus di comuni-cazione. La condivisione di tale bus rende necessaria una politica di arbitrag-gio riportata in [6]. Ai fini di questa trattazione, è sufficiente riportare che nell’istante in cui il bus di comunicazione è dedicato al dispositivo radio, la porta di uscita del modulo di comunicazione seriale non viene mantenuta in

(65)

4.4 Modulo implementazione algoritmo

alta impedenza, ma viene lasciata a livello logico basso. Questo rappresenta una violazione dello standard EIARS232 (cfr. [8]) secondo il quale la linea di comunicazione, nello stato di idle deve essere mantenuta nello stato logico alto. La situazione `e mostrata in figura 4.14. Ricordiamo che per i segnali il livello il logico alto `e -12V mentre il livello logico basso corrisponde a +12V.

Figura 4.14: Trama in una comunicazione seriale RS232

Per adattare i livelli logici quando il bus di comunicazione del dispositivo wireless è dedicato al canale radio, è stata utilizzata una porta 3-state co-mandata dal dispositivo stesso: quando il dispositivo cede il bus al modulo di comunicazione seriale, disabilita la porta 3-state attraverso una sua porta I/O digitale, permettendo il passaggio del segnale verso il microcontrollore; quando il bus viene invece dedicato al modulo radio, il dispositivo, ancora attraverso la porta I/O digitale, abilita la porta 3-state, che mantiene quindi la linea in alta impedenza: il livello logico è forzato allo stato logico alto attraverso una resistenza di pull-up. La figura 4.15 illustra la situazione nei due casi. Si noti che il segnale di comando della porta 3-State è attivo basso.

Figura 4.15: Funzionamento della porta 3-State

(66)

trasmis-4.4 Modulo implementazione algoritmo

sione sono stati notevolmente stabilizzati.

L’integrato utilizzato per la porta 3-State è il 74HCT 244. Il disegno dello schematico è riportato in figura 4.16. Nello schematico è presente un’ulteri-ore linea di trasmissione in senso opposto, per rendere disponibile la comu-nicazione bidirezionale: questo è utile per gli sviluppi futuri previsti. Nella figura 4.17 è invece mostrato lo schematico per il connettore con il dispositivo di comunicazione wireless.

Figura 4.16: Disegno dello schematico per la porta 3-State

Figura 4.17: Disegno dello schematico per il connettore con il dispositivo wireless

(67)

4.5 Circuito di alimentazione

Per completezza, in figura 4.18 viene riportato anche lo schematico del cir-cuito di alimentazione della scheda. E’ stato utilizzato un regolatore di ten-sione monolitico 7805 per regolare la tenten-sione della batteria a +5V. Sono visibili i condensatori per la stabilizzazione della tensione e un diodo led per indicare la connessione della scheda alla linea di alimentazione.

Figura 4.18: Disegno dello schematico per il circuito di alimentazione