Marvin: progetto e sviluppo di un robot real-time guidato da ...

Università Politecnica delle MarcheFacoltà di Ingegneria

Dipartimento di Ingegneria dell’InformazioneCorso di Laurea Triennale in Ingegneria Informatica e dell’Automazione

Marvin: progetto e sviluppo di un robotreal-time guidato da informazioni visive

Tesi di:Francesco Di Benedetto

Relatore:Prof. Aldo Franco Dragoni

Correlatore:Dott. Andrea Claudi

Anno Accademico 2011/2012

Dipartimento di Ingegneria dell’InformazioneUniversità Politecnica delle Marche

Facoltà di IngegneriaVia Brecce Bianche – 60131 Ancona (AN), Italy

Al mio caro nonno Guido

Ringraziamenti

Il paragrafo dedicato ai ringraziamenti è sicuramente il più bello da scrivere ma anche il più complesso.Voglio ringraziare mio nonno Guido, a cui questa tesi è dedicata, che avrebbe dato di tutto per vedermifinalmente Dottore: a lui va il mio pensiero più grande e spero che da lassù possa comunque gioirne. Nonposso però mettere in secondo piano tutta la mia famiglia che in questi anni mi ha sempre supportato efatto coraggio, per me è stato fondamentale considerando soprattutto il mio carattere! Grazie Mamma egrazie Papà per la vostra vicinanza e comprensione sulle quali ho sempre potuto contare.Non posso nemmeno dimenticare tutti gli amici che durante questo percorso mi sono stati vicino e con

cui ho condiviso i momenti più belli di questi anni universitari, tra gli altri uno speciale ringraziamentova a Francesco e Luca.Un sincero ringraziamento al Prof. Aldo Franco Dragoni per avermi dato la possibilità di lavorare

a questo bellissimo progetto che mi ha coinvolto per interi mesi, risultando un’esperienza fantasticaed ottima per concludere questo percorso di studio di primo livello. Questa tesi mi ha permesso disperimentare argomenti che hanno spaziato dall’Informatica all’Automazione, passando per l’Elettronica.Un doveroso ringraziamento va anche ai ragazzi del dipartimento del DII e principalmente al laboratorio

di Intelligenza Artificiale e Sistemi in Tempo Reale, tra i quali il correlatore Andrea Claudi. Lui è statouna figura fondamentale per lo sviluppo di questo lavoro essendo sempre presente con il suo supporto e isuoi consigli.

Ancona, Luglio 2012Francesco Di Benedetto

v

Sommario

Nel linguaggio comune, un robot è un’apparecchiatura artificiale che compie determinate azioni siabasandosi sulle istruzioni assegnate, sia autonomamente.In questo lavoro il robot realizzato prevede esclusivamente un funzionamento autonomo. Esso è conce-

pito per fornire una base hardware semplice e affidabile, rendendo possibile sviluppare in maniera indi-pendente applicazioni di alto livello basate sul sistema operativo mobile Android, disponibile tipicamentesu smartphone e tablet.Le modalità di utilizzo del robot denominato Marvin - dall’androide paranoico di Guida galattica per

gli autostoppisti scritto da Douglas Adams - sono molteplici e vanno dall’aspetto puramente didatticoe di ricerca in ambito universitario fino a scenari più complessi quali la videosorveglianza e l’assistenzapersonale.Risulta interessante notare come la progettazione di questo sistema embedded ponga su piani diame-

tralmente opposti l’attuazione di un comando dall’applicazione, e quindi dal cervello, del robot seguendola filosofia del Plug & Play; qualsiasi possessore di uno smartphone potrebbe sviluppare la sua applica-zione utilizzando le primitive di movimento esposte dal robot in maniera separata dall’hardware essendocerto sia che il dispositivo venga supportato, sia che l’applicazione con possa attuare i suoi comandi -attraverso un sistema hardware di una certa complessità - utilizzando un set di API.

vi

Indice

1. Introduzione 11.1. Stato dell’arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Obiettivi della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Struttura del lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Componenti di Marvin 42.1. Flex Full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2. Convertitore TTL-USB PL2303 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3. FTDI Vinculum-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Libreria Open Accessory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5. Arduino Mega ADK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6. Control Module basato su chip Motion Processor MC3410 . . . . . . . . . . . . . . . . . . 142.7. Servomotori DFRobotics DF15SR e Hitec HS-485HB . . . . . . . . . . . . . . . . . . . . . 142.8. Smartphone Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.9. Circuito di Alimentazione, led e breadboard . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3. Ambienti di sviluppo 203.1. Eclipse Indigo con Android SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2. RT-Druid e ERIKA Enterprise v1.6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3. Microchip MPLAB v8.43 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4. Arduino IDE v1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5. Vinculum-II IDE v1.4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6. RealTerm v2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4. Analisi dei Requisiti e Progettazione del Sistema 364.1. Analisi dei Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2. Requisiti Funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.1. Dotare il robot dei movimenti spaziali tramite API portabili . . . . . . . . . . . . . 374.2.2. Garantire un canale di comunicazione con ogni dispositivo Android . . . . . . . . . 374.2.3. Garantire una comunicazione affidabile con Arduino . . . . . . . . . . . . . . . . . 384.2.4. Implementare algoritmi di visione su Android . . . . . . . . . . . . . . . . . . . . . 384.2.5. Aggiungere il motore che permette uno snodo “di testa” . . . . . . . . . . . . . . . 38

4.3. Requisiti Aggiuntivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.1. Elaborazione tramite RTOS ERIKA . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.2. Migliorare il programma di visione . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.3. Sostituire il Motion Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.4. Implementare un controllore PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.5. Comunicazione wifi tramite Android . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4. Architettura e funzionamento del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5. Protocolli di comunicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5.1. Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.5.2. Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

vii

Indice

4.5.3. Flex Full Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5. Implementazione del Software 445.1. Librerie Flex Full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.1. Libreria EEuart.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.1.2. Libreria Arduino.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.1.3. Libreria Utility.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.1.4. Libreria serialConsole.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.1.5. Libreria Servo.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.1.6. Libreria PWM.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.1.7. Libreria PID.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2. Componenti Hardware Flex Full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.1. Oscillatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.2. USART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2.3. Modulazione a Larghezza di Impulso (PWM) . . . . . . . . . . . . . . . . . . . . . 51

5.3. RTOS ERIKA Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.4. Implementazione dell’applicazione ERIKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.5. Firmware Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.6. Applicazioni Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.6.1. Caratteristiche comuni tra le due applicazioni . . . . . . . . . . . . . . . . . . . . . 625.6.2. Differenze tra le due applicazioni Android . . . . . . . . . . . . . . . . . . . . . . . 66

5.7. OpenCV e Linear Binary Pattern (LBP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6. Il Sistema di Controllo 776.1. Il controllore PID a tempo continuo: generalità . . . . . . . . . . . . . . . . . . . . . . . . 776.2. Il controllore PID a tempo discreto: generalità . . . . . . . . . . . . . . . . . . . . . . . . 806.3. Taratura dei parametri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7. Conclusioni e sviluppi futuri 837.1. Test di funzionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.2. Obiettivi raggiunti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.3. Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

A. Dettagli di cablaggio 87

B. Software utilizzato 92

viii

Elenco delle figure

1.1. AndroEEbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1. Flex Full e Flex Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2. Pinout del dsPIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3. Funzioni e connettori della scheda Flex Full . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4. Microchip ICD 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5. Pinout della scheda Flex Full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6. Retro e pinout del PL2303 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7. Fronte del PL2303 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8. Vinculum-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.9. Modulo di debug V2DIP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.10. Arduino Mega ADK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.11. Pinout ATMega2560 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.12. Hardware per il controllo del movimento di AndroEEBot . . . . . . . . . . . . . . . . . . . 142.13. Esempio di onda rettangolare generata con la PWM . . . . . . . . . . . . . . . . . . . . . 152.14. Servomotore HS-485HB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.15. Corrispondenza tra angoli e tempi di T-on in microsecondi . . . . . . . . . . . . . . . . . . 152.16. DF15SR con “Horns” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.17. HTC Evo 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.18. Regolatore di tensione LM7805CV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.19. Circuito regolatore di tensione positiva stabilizzata . . . . . . . . . . . . . . . . . . . . . . 19

3.1. Architettura di Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2. Ciclo di vita di una activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3. Repository Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4. Librerie Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5. Proprietà del progetto e link delle librerie . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.6. Repository RT-Druid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.7. Link librerie MPLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.8. Build del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.9. RT-Druid IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.10. Log della programmazione del dsPIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.11. Setup ICD2 e MPLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.12. Selezione prototype board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.13. Vinculum IDE toolchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.14. Architettura Vinculum-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.15. IDE del Vinculum-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.16. Ricezione dati dalla scheda Flex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.17. Invio dati alla scheda Flex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1. Assi di Marvin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2. Flowchart per l’algoritmo di controllo del movimento . . . . . . . . . . . . . . . . . . . . . 39

ix

Elenco delle figure

4.3. L’architettura a 4 livelli di Marvin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1. Determinazione di Fosc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2. Architettura hardware di una periferica USART . . . . . . . . . . . . . . . . . . . . . . . . 505.3. Il protocollo UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.4. Generazione dell’onda PWM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.5. Modifica del valore di duty cycle “on-the-fly” . . . . . . . . . . . . . . . . . . . . . . . . . 535.6. API del kernel Erika Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.7. Algoritmo di individuazione di un volto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.8. Calcolo delle coordinate e degli errori nell’applicazione “Marvin PID” . . . . . . . . . . . 725.9. Architettura della libreria OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.10. Funzionamento dell’algoritmo LBP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.1. Controllore PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.2. Azioni proporzionali a confronto per un ingresso a gradino . . . . . . . . . . . . . . . . . . 786.3. Azioni integrali a confronto per un ingresso a gradino . . . . . . . . . . . . . . . . . . . . 796.4. Azioni derivatrici a confronto per un ingresso a gradino . . . . . . . . . . . . . . . . . . . 796.5. Schema a blocchi di un sistema a dati campionati . . . . . . . . . . . . . . . . . . . . . . . 806.6. Ku e Tu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.1. Architettura finale di Marvin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.2. Marvin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

A.1. Connessione Flex-Arduino tramite USART1 . . . . . . . . . . . . . . . . . . . . . . . . . . 87A.2. Connessione Flex-Convertitore tramite USART2 . . . . . . . . . . . . . . . . . . . . . . . 88A.3. Connessione Flex-Servomotore di testa tramite PWM1 . . . . . . . . . . . . . . . . . . . . 88A.4. Dettaglio del servomotore di testa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89A.5. Connessione Flex-servomotori di propulsione tramite PWM2 e PWM3 . . . . . . . . . . . 89A.6. Dettaglio dei servomotori di propulsione alloggiati sotto la struttura . . . . . . . . . . . . 90A.7. Connessione Flex e Arduino ai led presenti sulla breadboard . . . . . . . . . . . . . . . . . 90A.8. Circuito di alimentazione e linee di tensione . . . . . . . . . . . . . . . . . . . . . . . . . . 91A.9. Connessione Arduino-Smartphone tramite cavo USB . . . . . . . . . . . . . . . . . . . . . 91

x

Elenco delle tabelle

2.1. Coppia di stallo per il servo DF15SR a diversi valori di tensione . . . . . . . . . . . . . . . 17

4.1. Formato del pacchetto trasmesso dall’applicazione Android “Marvin Grid View” . . . . . 424.2. Formato del pacchetto trasmesso dall’applicazione Android “Marvin PID” . . . . . . . . . 424.3. Formato del pacchetto trasmesso da Arduino nell’applicazione “Marvin Grid View” . . . . 434.4. Formato del pacchetto trasmesso da Arduino nell’applicazione “Marvin PID” . . . . . . . 43

A.1. Connessione Flex-Arduino tramite USART1 . . . . . . . . . . . . . . . . . . . . . . . . . . 87A.2. Connessione Flex-Convertitore tramite USART2 . . . . . . . . . . . . . . . . . . . . . . . 87A.3. Connessione Flex-Servomotore di testa tramite PWM1 . . . . . . . . . . . . . . . . . . . . 88A.4. Connessione Flex-servomotore di propulsione tramite PWM2 . . . . . . . . . . . . . . . . 89A.5. Connessione Flex-servomotore di propulsione tramite PWM3 . . . . . . . . . . . . . . . . 89A.6. Connessioni Flex-led . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90A.7. Connessioni Arduino-led . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

xi

Capitolo 1.

Introduzione

Nel linguaggio comune, un robot è un’apparecchiatura artificiale che compie determinate azioni siabasandosi sulle istruzioni assegnate, sia autonomamente.In questo lavoro il robot realizzato prevede esclusivamente un funzionamento autonomo. Esso è conce-

pito per fornire una base hardware semplice e affidabile, rendendo possibile sviluppare in maniera indipen-dente applicazioni di “alto livello” basate sul sistema operativo mobile Android, disponibile tipicamentesu smartphone e tablet.Le modalità di utilizzo del robot denominato Marvin – dall’androide paranoico di Guida galattica per

gli autostoppisti scritto da Douglas Adams – sono molteplici e vanno dall’aspetto puramente didatticoe di ricerca in ambito universitario fino a scenari più complessi quali la videosorveglianza e l’assistenzapersonale.Risulta interessante notare come la progettazione di questo sistema embedded ponga su piani diametral-

mente opposti l’attuazione di un comando dall’applicazione, e quindi dal “cervello”, del robot seguendola filosofia del “Plug & Play”; qualsiasi possessore di uno smartphone potrebbe sviluppare la sua applica-zione utilizzando le primitive di movimento esposte dal robot in maniera separata dall’hardware essendocerto sia che il dispositivo venga supportato, sia che l’applicazione con possa attuare i suoi comandi -attraverso un sistema hardware di una certa complessità - utilizzando un set di API.

1.1. Stato dell’arteLo sviluppo di Marvin nasce dalle ceneri di AndroEEbot (vedi fig. 1.1), dotato di funzionamento simile

ma di architettura più complessa.La tesi ha come obiettivo una riprogettazione totale del sistema, con l’utilizzo di componenti hardware

più idonei, accessibili e poco costosi e in grado di interfacciarsi con dispositivi di origini diverse.AndroEEbot basava i suoi spostamenti sul Motion Processor e riceveva dati solo da particolari telefoni

Android come il Nexus S, interfacciando questi componenti con il microcontrollore Flex Full sul quale èin esecuzione Erika Enterprise, un sistema operativo real-time embedded.Attraverso il Vinculum II, dispositivo dotato di due porte usb e una porta USART, i tre dispositivi

sopra citati erano messi in comunicazione. Il Vinculum-II quindi era impiegato come hub tra i varidispositivi.

1

Capitolo 1. Introduzione

Figura 1.1.: AndroEEbot

1.2. Obiettivi della tesiGli obiettivi e la direzioni intraprese per migliorare il progetto esistente e aggiungere nuove funzionalità

per evolvere il precedente sistema sono stati molteplici tra cui:

1. Definizione e studio del sistema e degli ambienti di sviluppo necessari: acquisizione e padronanzatale che la loro configurazione diventi una procedura standardizzata da inserire in un “how-to”.

2. Semplificazione del “sistema a basso livello”. Questo significa avere a disposizione un layer difunzionalità costituite dalla programmazione delle schede per lo svolgimento dei compiti di comu-nicazione, elaborazione dati, strutturazione del sistema real time in task, progettazione del sistemacon componenti più idonei alla robotica, ecc. . .

3. Realizzazione di librerie per accedere comodamente a numerose funzioni della Flex, tra cui la co-municazione USART (Universal Synchronous-Asynchronous Receiver/Transmitter), PWM (PulseWidth Modulation), I/O digitale, comando dei servomotori.

4. Realizzazione e testing di strumenti di Debug in Run Time per la Flex Full attraverso la libreriaSerial Console.

5. Utilizzo e modifica della libreria Microbridge ADB per comunicare con qualsiasi dispositivo Androide microcontrollore Arduino.

6. Aggiunta di features all’applicazione Android per fornire a Marvin migliori funzionalità di insegui-mento di volti tramite libreria OpenCV e controllore PID implementato sulla Flex Full.

7. Progettazione e implementazione di controllori PID per il controllo in anello chiuso dei movimentispaziali del robot mediante un kernel real-time .

8. Aggiunta dello “snodo di testa” e miglioramento della meccanica rispetto al precedente AndroEEbot.

Risulta quindi evidente come il lavoro svolto ha coinvolto diversi fronti portando novità al precedentesistema come il Plug & Play degli smartphone, la possibilità di utilizzare due microcontrollori per lalettura di sensori o l’utilizzo di attuatori come i motori a corrente continua oppure servomotori attraversoPWM, e infine le importanti funzioni di debug a run time originariamente non disponibili per la Flexconcludendo con la realizzazione di controllori PID per il controllo automatico del movimento del robotattraverso varie politiche di controllo.

2

Capitolo 1. Introduzione

1.3. Struttura del lavoroI diversi capitoli della tesi possono essere riassunti per macro-argomenti in maniera da avere una

panoramica generale su come il lavoro è stato impostato.Nel capitolo 2 viene fornita una descrizione dettagliata sui dispositivi hardware e l’elettronica utilizzata

per familiarizzare con gli strumenti di lavoro.Il capitolo 3 presenta gli ambienti di sviluppo riepilogando tutte le informazioni necessarie per l’in-

stallazione, l’importazione dei progetti esistenti e fornendo indicazioni sull’utilizzo per addolcire il piùpossibile la curva di apprendimento dei numerosi strumenti.Nel capitolo 4 si parlerà della progettazione sia hardware sia software che è stata necessaria per rico-

struire dalle fondamenta il sistema, venendo illustrate l’analisi dei requisiti e il funzionamento di Marvin,unitamente una schematizzazione a livelli del sistema per spiegarne a fondo l’architettura.Il capitolo 5 tratta le scelte implementative e le soluzioni progettuali per l’hardware e il software,

verranno spiegate le problematiche incontrate e soluzioni progettuali intraprese nonché spiegato a fondoil funzionamento del codice su Flex, Arduino e Android.Nel Capitolo 6 è affrontato il problema del Controllo Automatico mediante PID a tempo discreto

implementato in maniera congiunta tra Android e Flex Full, oltre alle conoscenze matematiche e operativenecessarie per tarare i parametri del controllore.Infine il capitolo 7 contiene i test e i risultati ottenuti con il nuovo sistema embedded e software

progettato e realizzato. Il capitolo contiene anche idee e spunti di riflessioni per sviluppi futuri di Marvin.Seguono due appendici utili a livello pratico, cioè lo schema dei collegamenti elettrici e l’elenco dei

software utilizzati.

3

Capitolo 2.

Componenti di Marvin

Nelle applicazioni dei sistemi embedded, l’ambiente di sviluppo è caratterizzato da hardware e software.A differenza dei sistemi PC general-purpose, dove grazie all’astrazione dei sistemi operativi e ai linguag-

gi di programmazione di alto livello, viene tendenzialmente ignorato l’hardware sottostante, nei sistemiembedded l’hardware rappresenta un elemento fondamentale del sistema stesso, che lo caratterizza, evincola il progettista nelle scelte e nelle soluzioni da adottareIn questo capitolo viene effettuata una panoramica sulle caratteristiche dell’hardware utilizzato per

comprendere al meglio gli strumenti di lavoro.

2.1. Flex FullFlex è una scheda embedded realizzata da Evidence srl, basata sui microcontrollori della famiglia dsPIC

DSC (Digital Signal Controller) di Microchip. Si tratta di una evaluation board che permette lo sviluppoe il testing di applicazioni real-time per dsPIC DSC; è dotata di un’architettura hardware modulare efornisce supporto al kernel real-time Erika Enterprise. La Flex è il “cervello” di Marvin, in quanto le sonoaffidati i compiti di coordinazione dei vari dispositivi ad essa connessi, nonché l’esecuzione del codice dicontrollo del robot.La Flex Full board adotta un’architettura modulare composta dalla board madre, su cui sono già pre-

senti tutte le funzionalità del microcontrollore, e da schede figlie chiamate daughter boards, che estendonoe semplificano l’accesso ad alcuni dispositivi e l’uso di alcune funzionalità. La Demo Daughter Board,ad esempio, fornisce supporto alla scrittura su display LCD, all’utilizzo di sensoristica come trasmet-titori e ricevitori infrarossi, sensori di temperatura e luminosità, e facilità l’utilizzo delle periferiche dicomunicazione attraverso bus I2C o SPI.

Figura 2.1.: Flex Full e Flex Base

4

Capitolo 2. Componenti di Marvin

La Famiglia delle board Flex, come si nota in fig. 2.1, è composta da due board: la Flex Full – utilizzatanel presente lavoro – e la Flex Base.La Flex Base differisce dalla versione Full per l’assenza della porta USB e del PIC 18 predisposto alla

sua gestione (e non direttamente programmabile dall’utente). Inoltre lo stadio di alimentazione della FlexBase accetta un range di tensioni di ingresso da 7 a 12 V, meno ampio rispetto ai 9-36 V della versioneFull.Sempre dalla fig. 2.1, si può notare come i pin disponibili nel microcontrollore dsPIC33FJ256MC710

della famiglia dsPIC DSC di Microchip vengano esportati attraverso connettori standard a passo 2.54mm, agevolando l’interconnessione con circuiti elettronici esterni.La caratteristica che rende la Flex Full un buon hardware su quale sviluppare la logica di controllo

di Marvin è individuabile nella possibilità di avere da una parte il sistema operativo Real-Time ErikaEnterprise, con il quale organizzare l’esecuzione del codice in tasks, avendo così a disposizioni su unmicrocontrollore il concetto di programmazione concorrente – cosa molto rara nei sistemi embeddedattuali – e dall’altra parte la possibilità di programmare a basso livello il dsPIC in linguaggio C oAssembly, avendo a disposizione le periferiche tipiche di un microcontrollore.Le caratteristiche principali del dsPIC33FJ256MC710 sono riassunte qui di seguito [1]:

• Architettura: 16-bit, di tipo Modified Harvard

• Massima velocità della CPU : 80 Mhz corrispondenti a 40 MIPS

• KB dedicati alla Memoria Programma: 256

• Tensione di funzionamento: da 3 a 3.6 Volt

• Pin disponibili: 100

• Oscillatori interni: 2 oscillatori, per due diverse modalità di funzionamento, rispettivamente 7.39MHz e 512 KHz (con possibilità di usare un PLL – Phase Loop Locker) per incrementare la frequenzafino a 80 MHz

• Periferiche di Comunicazioni digitali: 2 USART, 2 SPI, 2 I2C

• PWM (Pulse Width Modulation): 2 Moduli PWM dedicati al controllo dei motori, PWM conrisoluzione di 16 bits e possibilità di utilizzare 8 canali

• DMA (Direct Memory Access): 8 canali, 2 Kbytes DMA buffer area (DMA RAM) per memorizzarei dati trasferiti via DMA così è possibile il trasferimento di informazioni tra RAM e periferichementre la CPU sta eseguendo codice (no cycle stealing); la maggior parte delle periferiche supportaDMA.

• Real-Time Clock Circuit (RTCC) Hardware: non disponibile all’interno ma è possibile usare unaconfigurazione per usare un RTCC esterno

• Timers: 9 Timers a 16 bits, oppure 8 utilizzabili in coppia per ottenere 4 timers a 32 bits

• Output Voltage: i pin digitali hanno uscite che al massimo raggiungono i 3.6 volt, perciò la logicaAlto(H)/Basso(L) rispetta lo standard 3.3/0 volt.

• Moduli ECAN: 2

• ADC (Convertitore Analogico Digitale): 2

5


Figura 2.2.: Pinout del dsPIC

6


I 100 pin del dsPIC sono riportati totalmente sulla Flex Full sui connettori CON6 e CON5 con la stessanumerazione che si può trovare sul dsPIC (vedi fig. 2.2): ad esempio la Ricezione della USART 1 suldsPIC è multiplexata sulla linea 52 che corrisponde proprio al pin P52 sul connettore CON6 della Flex.In fig. 2.3 sono evidenziati i connettori e le principali funzionalità della board Flex Full.Per completezza, in fig. 2.5 è riportata la piedinatura della Flex Full.

Figura 2.3.: Funzioni e connettori della scheda Flex Full

La programmazione e il debug del microcontrollore dsPIC avviene attraverso delle apposite interfacce:In-Circuit Serial Programming (ICSP), Enhanced ICSP e Joint Test Action Group (JTAG).La ICSP è un’interfaccia proprietaria di Microchip, appositamente sviluppata per la programmazione

dei propri dispositivi. È quindi integrata nel core del MCU, dove una macchina a stati regola la scrittura inmemoria; oltre alla programmazione, la ICSP gestisce anche un canale per il debugging sul chip (in-circuitdebugging).Il dispositivo MPLAB ICD2 (vedi fig. 2.4) è necessario per eseguire le operazioni di programmazione

e debug del MCU.

Figura 2.4.: Microchip ICD 2

Purtroppo data la complessità del sistema operativo Erika, non è possibile eseguire le operazioni diDebug attraverso ICD2 e MPLAB. Per questo motivo è stato sviluppato durante questo lavoro di tesianche una libreria chiamata serialConsole.h, che va compilata insieme al programma di controllo del

7


robot sulla Flex, che permette di comunicare verso un PC attraverso un Convertitore TTL-USB basatosul chip PL2303.

Figura 2.5.: Pinout della scheda Flex Full

8


2.2. Convertitore TTL-USB PL2303Questo semplice convertitore presenta i pin per l’USART TX, RX e GND. Tali pin sono stati collegati

alla Flex Full ed utilizzati con la seconda USART della scheda, mentre si pone lato PC come porta serialeVirtuale (VCOM su sistemi Windows).

Figura 2.6.: Retro e pinout del PL2303

Figura 2.7.: Fronte del PL2303

Per visualizzare le stringhe di Debug è necessario utilizzare la libreria serialConsole.h e un pro-gramma per la ricezione tramite porta seriale. Per questo lavoro è stato utilizzato Real Term in quantocompleto e preciso nonché freeware.Si nota dalla foto come questo chip possa anche fornire due linee di alimentazione (3.3 e 5 V) a dispositivi

ad esso collegati, anche se questa caratteristica non è stata utilizzata per il progetto di Marvin.I driver del chip PL2303, affinchè esso sia riconosciuto come VCOM, sono reperibili senza difficoltà per

i sistemi operativi Linux, Windows Vista e Windows 7.

2.3. FTDI Vinculum-IIIl Vinculum-II (VNC2) è la seconda versione della famiglia Vinculum di FTDI; si tratta di un controller

embedded dual USB host. È dotato di un microcontrollore a 16-bit con memoria Flash da 256KB e 16KBdi RAM.Il VNC2 fornisce la funzionalità di interfaccia USB Host per una varietà di dispositivi USB.

Figura 2.8.: Vinculum-II

La comunicazione con dispositivi non-USB, come microcontrollori, può essere realizzata utilizzando leinterfacce USART, SPI oppure parallel FIFO (è presente inoltre anche un modulo PWM) e tutti i segnalisono prelevabili attraverso 24 pin 2.54 mm configurabili.

9


Il VNC2 è un dispositivo completamente programmabile e permette la realizzazione di firmware per-sonalizzati secondo le proprie esigenze, utilizzando l’apposito ambiente di sviluppo Vinculum- II IDE.Il linguaggio di programmazione utilizzato è il C e per permettere la connettività e il funzionamento

dei vari dispositivi – come l’istanziamento dei driver – è necessario utilizzare le primitive del VOS, ilsistema operativo Real-Time del Vinculum che gestisce e schedula i tasks.La programmazione del Vinculum-II avviene per mezzo di un apposito dispositivo, il VNC Debugger/-

Programmer Module progettato per fornire la connettività tra l’ambiente di sviluppo Vinculum-II IDE ei pin dell’interfaccia di debug presenti nel V2DIP2.

Figura 2.9.: Modulo di debug V2DIP2

Il modulo di debug VNC2 è una mini-scheda con un connettore USB miniB usato per connettersiall’ambiente di sviluppo sul PC; il connettore femmina a 6-vie è utilizzato per connettere il modulo didebug al dispositivo VNC2, dotato di un connettore maschio compatibile.Questo dispositivo comunque non è stato impiegato nella versione finale di Marvin mentre è stato

utilizzato come interfaccia per lo scambio di messaggi tra Flex Full, smartphone Nexus S e ControlModule per AndroEEbot.Le ragioni che hanno spinto alla sostituzione di questo modulo con il microcontrollore Arduino sono da

individuarsi nell’aspetto Plug & Play verso tutti gli smartphone Android che Arduino permette e che ilVinculum limita. Infatti seppur entrambi i dispositivi supportano la libreria Open Accessory di Googlesolo Arduino supporta MicroBidge ADB.Le due librerie differiscono molto per compatibilità dei dispositivi. Infatti la Microbridge ADB è

supportata da qualsiasi dispositivo Android con versione >= 1.5, mentre la Open Accessory è attualmentesupportata, solo da un paio di smartphone (Nexus S e Nexus One) e qualche tablet (come il MotorolaXoom). Ciò impone un pesante vincolo progettuale e di costo, e limita il concetto di Plug & Play.Con Arduino diverse applicazioni Android, create per comandare semplicemente l’hardware sottostante,possono essere condivise e impiegate su un qualsiasi smartphone; ciò non potrebbe accadere utilizzandoil Vinculum-II.

10


2.4. Libreria Open AccessoryOpen Accessory viene distribuita da Google per l’interfacciamento tra il mondo dei sistemi embedded

e il sistema operativo Android e i dispositivi che lo ospitano.La libreria viene distribuita in due versioni: come Add-on, per le versioni 2.3.4+ di Android (è un

backporting) e dalla 3.0+ come libreria ufficiale. Open Accessory che permette ad un dispositivo Androidche la supporti di poter usare la porta USB per scambiare dati con altri dispositivi.Questa libreria permette di utilizzare il dispositivo Android come USB Accessory e USB Host.Nel primo caso, che è quello specifico di questa tesi, il dispositivo viene riconosciuto come un accessorio,

cioè è atto a svolgere il compito di slave e quindi non può enumerare altri device ad esso collegati attraversola porta USB e fornire loro alimentazione elettrica.Il secondo caso invece permette al dispositivo di figurare come Master.In generale attraverso questa libreria il dispositivo Android può interfacciarsi con altri dispositivi USB

come Mouse, Tastiere, Fotocamere, Schede di Sviluppo ecc...La libreria è stata rilasciata verso la fine del 2011 e sono tutt’ora pochi i dispositivi che la utilizzano

appieno come riporta prorio Google1 stessa poiché oltre a delle feature software è necessario che i produt-tori di smartphone implementino via hardware la possibilità di utilizzare l’Open Accessory: Tipicamentegli smartphone che la supportano appartengono alla Fascia Alta della gamma e perciò richiedono costielevati, nell’ordine dei 300AC2.

2.5. Arduino Mega ADKArduino Mega ADK è una scheda di sviluppo basata sul microcontrollore ATmega2560. Esso differisce

dalla versione Arduino Mega per la presenza di una interfaccia USB Host usata per connettere smart-phone basati sul sistema operativo mobile Android. L’interfaccia USB è realizzata mediate l’integratoMAX3421e.

Figura 2.10.: Arduino Mega ADK

Tra le caratteristiche più interessanti di questo microcontrollore si ha che esso dispone di 54 pin I/O,un oscillatore interno a 16 MHz, bottone di reset, un ambiente di sviluppo di semplice utilizzo basato su

1Note: Accessory mode is ultimately dependent on the device’s hardware and not all devices will support accessory mode.Devices that support accessory mode can be filtered using a <uses-feature> element in your corresponding application’sAndroid manifest.For more information, see the USB Accessory Developer Guide. (dal sito dedicato alla libreria OpenAccessory, ultima consultazione – Luglio 2012)

2Dato ricavato da ricerche condotte su negozi online nell’anno 2012

11


Processing, programmazione tramite linguaggio ad alto livello chiamato Wiring, supporto per la libreriaOpen Accessory di Google per comunicare con Android.Questo seconda board di sviluppo è stata scelta in sostituzione del precedente Vinculum-II sul robot

Marvin per la sua predisposizione naturale per la comunicazione con Android. Infatti oltre a supportarenativamente la libreria Open Accessory di Google supporta (seppur con leggere modifiche) la libreriaMicrobridge ADB che rende possibile l’interfacciamento di qualsiasi dispositivo Android (versione 1.5 omaggiore) senza bisogno di permessi di root sul dispositivo. L’USB Host, che nel nostro caso è proprioArduino Mega ADK, tramite l’utilizzo del protocollo ADB (Android Debug Bridge) permette di aprireuna Shell sul telefono o inviare direttamente comandi tramite essa, trasmettere file tra PC e Android,leggere i log di debug (logcat), aprire porte TCP e sockets Unix.L’ultima caratteristica è quella usata dalla libreria Microbridge che utilizza sockets TCP per stabilire

un canale di connessione bidirezionale (pipe) tra un dispositivo Android e Arduino, l’applicazione Androidsi comporta da Server ascoltando una determinata porta scelta dal programmatore e Arduino si connettea quella porta tramite ADB comportandosi da Client; la libreria permette di effettuare riconnessioniautomatiche nell’eventualità che il device USB venga scollegato da Arduino o per altre cause come crashdell’applicazione Android, etc... aumentando di molto l’affidabilità e permettendo il “Plug & Play”concetto che si è voluto realizzare dai primi momenti del progetto di Marvin.Si fa notare che per lo sviluppo del progetto non è necessario usare proprio l’Arduino Mega ADK,

infatti basterebbe utilizzare un qualsiasi Arduino con annessa la USB Shield che permette di avere lestesse caratteristiche della board presentata (USB Host) ma attraverso un’architettura modulare del tipomother board + daughter board; questa soluzione è stata scartata in fase di progetto perché la versioneADK rispetto alla USB Shield permette di avere funzionalità integrate senza perdere pin e senza bisognodi ulteriori fonti di alimentazione.In fase progettuale l’utilizzo di un secondo microcontrollore di facile accesso come Arduino è stata

un motivata anche dall’aumento delle capacità computazionali e di comunicazione del robot. In questomodo infatti, risulta possibile dividere carichi di lavoro tra 2 CPU, già messe in comunicazione mediantela libreria Arduino.h sulla Flex e nel file AndroidFlexComunication.ino su Arduino, risulta possibileutilizzare sensoristica avanzata in maniera molto semplice grazie alle potenzialità di Wiring e per le altreperiferiche aggiunte con la board, principalmente:

• 15 PWM

• 16 Ingressi Analogici

• 3 USART

• 1 porta seriale Virtuale (VCOM) integrata nell’ambiente di sviluppo di Arduino

• 1 modulo SPI

12


Figura 2.11.: Pinout ATMega2560

13


2.6. Control Module basato su chip Motion Processor MC3410AndroEEBot è stato progettato per interfacciarsi con il Control Module del robot ER1 sviluppato

dalla Evolution Robotics nel 2002. Il Control Module gestiva il movimento robot attraverso 2 motoripasso passo Shinano Kenshi SST58D3820 da 3.4 Volt, 1.8 gradi/step, 2 Ampere/fase, pilotati in modalitàbipolare.I motori erano collegati al Control Module con due connettori seriali X.21 ed il connettore 1 era

associato alla ruota destra.

(a) Control Module del robot ER1 (b) Motore passo-passo Shinano Kenshi

Figura 2.12.: Hardware per il controllo del movimento di AndroEEBot

Il programmatore si interfaccia al modulo di controllo attraverso la porta USB e invia i comandi didirezione e velocità tramite sequenze di byte che verranno poi interpretate dalla circuiteria interna eattuate dai motori passo-passo.Il Control Module è fondamentalmente composto da 3 chip, due motion processor MC3410 che si

occupano di trasformare i byte ricevuti in ingresso tramite porta USB in comandi di direzione, traiettoriae velocità ,e da un chip FTDI RS232-USB utilizzato come convertitore USB→ Seriale secondo lo standardRS232.Proprio la presenza di questo chip ha permesso di optare per il Vinculum-II nel precedente AndroEEBot,

anch’esso appartenente alla famiglia di chip della FTDI.Questo componente è stato inizialmente utilizzato nell’architettura di Marvin come dimostrato in alcuni

video presi in fase di sviluppo ma poi è stato sostituito perché riduceva di molto i tempi di risposta delsistema, spesso risultava non essere preciso e generalmente rappresenta una sorta di “black box” cheavrebbe potuto rallentare lo sviluppo e l’evoluzione di Marvin.Il Motion Control e i motori passo-passo sono perciò stati sostituiti con dei Servomotori a rotazione

continua ad alta coppia: i DF15SR.

2.7. Servomotori DFRobotics DF15SR e Hitec HS-485HBI Servomotori sono dei motori DC (motori a corrente continua) che includono al loro interno ingranaggi

di riduzione o moltiplica della coppia, un circuito di controllo e un potenziometro utilizzato come sensoredi posizione. Attraverso queste caratteristiche essi risultano molto semplici da utilizzare e da installare.Per poter essere controllati questi motori hanno bisogno di un segnale di controllo PWM con duty cycle

variabile rispetto ad un periodo fissato; entrambi i motori utilizzati necessitano di un periodo si 20 msper il segnale PWM.

14


Il duty cycle è la frazione di tempo che un segnale passa in uno stato attivo in proporzione al tempototale considerato (periodo). In presenza di un segnale sotto forma di onda rettangolare, il duty cycle èil rapporto tra la durata del segnale “alto” (τ) e il periodo totale del segnale (T ), e serve a esprimere perquanta porzione di periodo il segnale è a livello alto intendendo con alto il livello “attivo”.Il duty cycle è definito come d = τ

T , dove τ è la porzione di periodo a livello alto (detta anche T-on) eT è il periodo totale.

Figura 2.13.: Esempio di onda rettangolare generata con la PWM

I servomotori utilizzati nella costruzione di Marvin sono di due tipologie, un servomotore standard(angolo di rotazione 0-180°) Hitec HS-485HB per lo snodo di testa alimentato a 5 V, coppia di stallo 4.8Kg·cm, ingranaggi in karbonite e drain massimo di corrente di 150 mA senza carico. I tempi T-on sonoriportati nello schema sottostante. Per questo particolare servomotore il valore di duty cycle definiscel’angolo in cui il motore deve posizionarsi.

(a) Rivestimento del servo HS-485HB (b) Riduttori in karbonite

Figura 2.14.: Servomotore HS-485HB

Figura 2.15.: Corrispondenza tra angoli e tempi di T-on in microsecondi

15


Si noti che 1.5 ms corrisponde alla posizione 0° del servo. Variando il tempo di T-on del duty cycle sipossono ottenere i vari valori dell’angolo che il braccio del servo deve raggiungere.Si riporta il cablaggio:

• Nero: Massa

• Rosso: Alimentazione (4.8 – 6 V)

• Giallo: Segnale PWM

Per la propulsione di Marvin, invece, sono stati utilizzati due servomotori a rotazione continua DF15SRdella DFRobotics che, a differenza del servomotore Hitec, permettono la rotazione continua (0-360°); ilvalore di duty cycle determina il verso di rotazione, e non la posizione come accade per il precedentemodello.Con valori di T-on di 1.5 ms il motore si ferma, con T-on pari a 2.4 ms esso ruota alla massima velocità

in senso orario mentre per T-on pari a 0.6 ms esso ruota alla massima velocità in senso antiorario,tecnicamente per tutti i valori di T-on compresi nei range sopra descritti la velocità del motore dovrebbeaumentare o diminuire linearmente, anche se data la limitazione di valori imponibili è difficile notarecambiamenti di velocità apprezzabili; in ogni caso attraverso un controllore PID con mapping dei valoriè possibile notare concretamente l’accelerazione o la decelerazione dei motori.

Figura 2.16.: DF15SR con “Horns”

I servi di propulsione sono alimentati a 5 V, coppia di stallo 10 Kg*cm, e drain massimo di corrente di1.2 A senza carico alla massima tensione di alimentazione (7.2 V).Si riporta il cablaggio:

• Marrone: Massa

• Rosso: Alimentazione (4.8 – 7.2 V)

• Arancione: Segnale PWM

La particolarità di questo motore sta nel fatto di poter ottenere diversi valori di coppia di stallo perdiversi valori di tensione:

16


Coppia Tensione10 Kg·cm 4.8 V13 Kg·cm 6 V15 Kg·cm 7.2 V

Tabella 2.1.: Coppia di stallo per il servo DF15SR a diversi valori di tensione

2.8. Smartphone AndroidUno smartphone è un “telefono multimediale/intelligente” cioè un dispositivo che incorpora le funzio-

nalità di un telefono cellulare con quelle di un PDA, su questi dispositivi è possibile utilizzare un sistemaoperativo ed installare e sviluppare applicazioni che ne sfruttano la sensoristica e le peculiarità.Il progetto di Marvin ha previsto fin da subito l’utilizzo di uno smartphone che potesse interfacciarsi

con le componenti elettroniche e meccaniche sottostanti attraverso API portabili su diversi dispositivi cosìda permettere il Plug & Play di applicazioni capaci di utilizzare il robot per effettuare movimenti, men-tre l’elaborazione è affidata all’applicazione che può essere progettata indipendentemente dall’hardwaresottostante.L’applicazione sviluppata prevede l’utilizzo del sistema operativo Android tramite il quale è possibile

accedere alla videocamera posteriore di cui ogni smartphone è dotato, ed applicare sui vari frame catturatifiltri e algoritmi volti messi a disposizione dalla libreria di visione artificiale Open CV per Android.Inizialmente AndroEEbot prevedeva la sola compatibilità con lo smartphone Nexus S, ora attraverso

la libreria Microbridge ADB è possibile utilizzare un qualsiasi smartphone con Android >= 1.5.Vari dispositivi sono stati messi alla prova tra cui

• LG Optimus One

• HTC Desire

• HTC Evo 3D

Su ognuno di essi la compatibilità è stata verificata con successo, ma al di là del testing l’HTC Evo 3Dè stato utilizzato come riferimento per il sistema poiché dotato di caratteristiche hardware nettamentemigliori e per la possibilità di utilizzare ben due fotocamere per la visione stereoscopica.

(a) HTC Evo 3D (b) Particolare delle fotocamere stereoscopiche

Figura 2.17.: HTC Evo 3D

Caratteristiche e sensoristica:

17


• Giroscopio

• Accelerometro

• Sensore di prossimità

• Sensore di luminosità

• GPS integrato

• Doppia fotocamera da 5 megapixel con autofocus e doppio flash a LED

• Apertura f/2.2

• Registrazioni video in 2D/3D con risoluzione fino a 720p

• Fotocamera frontale da 1.3 megapixel a fuoco fisso

• CPU dual-core Qualcomm MSM8260 a 1.2 Ghz

• GPU Adreno 220

• RAM 1 GB

2.9. Circuito di Alimentazione, led e breadboardIl robot è costituito, oltre che dai microcontrollori e dagli attuatori, anche da alcune parti elettroniche.La circuiteria è stata realizzata mediante una breadboard per permettere una facile prototipizzazione.

Il circuito di alimentazione è diviso in due linee di tensione mediante il regolatore di tensione lineareLM7805CV, dove nel pin di input entra la linea 12 V e dal pin di output esce la 5 V.

Figura 2.18.: Regolatore di tensione LM7805CV

Il regolatore di tensione lineare, mediante una serie di transistor, attua la regolazione per dissipazionedella tensione in eccesso. La potenza dissipata è:

P = (Ving − Vout) · (Idrain) (2.1)

18


Risulta chiaro, anche con un calcolo sommario, che se la linea a 5 V è utilizzata per alimentare i treservomotori con un drain di corrente pari a circa 800 mA e la caduta di potenziale è 7 V, la potenzadissipata sarà pari nel caso peggiore 7 V * 0.8 A = 5.6 W.Per cui risulta necessario inserire un dissipatore affinché la potenza sviluppata dal componente, se

troppo elevata, non lo distrugga.

Figura 2.19.: Circuito regolatore di tensione positiva stabilizzata

Lo schema del circuito di alimentazione risulta essere:

• C1: 1000 uF, elettrolitico 16 V

• C2: 47 nF, poliestere metallizzato

• C4: 470 uF, elettrolitico 16V

• IC1: LM7805CV, dove E = IN, M = GND e U = OUT

I condensatori hanno la seguente funzione:

• C1: livella la tensione a monte del circuito.

• C2: questi due condensatori servono per togliere i disturbi in alta frequenza, il più usato è quelloda 100 nF. C’è una cosa più importante della sua capacità, ed è la posizione: devono essere il piùvicino possibile al regolatore per svolgere bene il loro compito.

• C3: serve a “pulire” la tensione in uscita.

Nel circuito sono presenti anche 3 LED che servono per indicare gli stati della macchina ed hanno laseguente funzionalità:

• Rosso: controllato da Arduino indica che l’applicazione Android sta inviando dei dati; serve perverificare che l’applicazione stia effettivamente inviando i byte. Inoltre indica che tali byte sonoricevuti e processati da Arduino.

• Verde: controllato da Arduino indica che la Flex ha inviato una richiesta tramite USART 1 adArduino, ed Arduino ha processato e risposto tramite l’invio di byte alla Flex.

• Arancione: controllato dalla Flex indica che i dati ricevuti da Arduino corrispondono effettivamentea dati utili per il movimento dei motori.

19

Capitolo 3.

Ambienti di sviluppo

Nel campo dell’informatica per ambiente di sviluppo si intende uno o più software che aiutano ilprogettista/programmatore nello sviluppo e nel testing del codice. Normalmente un ambiente di sviluppoconsiste in un editor di codice sorgente, un compilatore e/o un interprete, un tool di building automaticoe solitamente, un debugger.Per lo sviluppo di Marvin gli ambienti di sviluppo utilizzati sono stati molteplici.Saranno quindi de-

scritti i vari tools e, in maniera concisa, verrà spiegato come installare e configurare tali software disviluppo1.

3.1. Eclipse Indigo con Android SDKL’ambiente di sviluppo per le applicazioni Android è basato su Eclipse, IDE flessibile multi- linguaggio

e multi-piattaforma open source che mediante l’utilizzo del plugin Android SDK diventa un validissimomezzo tramite il quale programmare, compilare, generare .apk (Android Package file: pacchetti eseguibiliper il sistema operativo Android), emulare terminali e mandare in esecuzione in debug, sul propriodispositivo, le applicazioni.Android è un sistema operativo basato sul kernel Linux 2.6, appositamente realizzato per dispositivi

portatili. L’architettura è suddivisa in 5 componenti. Al di sopra del kernel Linux ci sono le libre-rie C/C++ utilizzabili dalle applicazioni; ad un livello superiore si trova l’Application Framework, chefornisce le API e i servizi che possono essere utilizzati dalle applicazioni (chiamate anche App); questeultime si trovano in cima all’architettura, nel livello Application, e sono sviluppate usando il linguaggiodi programmazione Java.

Figura 3.1.: Architettura di Android

1Affinché tutti i tools di sviluppo possano funzionare correttamente è consigliato lavorare in ambiente Windows Vista oWindows Seven

20

Capitolo 3. Ambienti di sviluppo

Il componente chiave del framework Android è l’Android Runtime, che contiene le librerie di sistemae la Virtual Machine Dalvik, una macchina virtuale appositamente progettata e ottimizzata da Googlesecondo le caratteristiche hardware dei dispositivi mobile.Lo sviluppo delle applicazioni Android avviene utilizzando l’IDE Eclipse per Java, con installato il

plugin Android Develoment Tools (ADT); in aggiunta, è necessario il pacchetto Android SDK che contienei vari strumenti di sviluppo e le librerie per le versioni di Android, necessari per compilare l’applicazionerealizzata nel formato .apk.Sono quattro i tipi di componenti delle applicazioni: Activity, Service, Content Providers, Broadcast

Receivers.Una Activity visualizza una schermata singola; in una applicazione più attività funzionano in con-

temporanea per costruire un’interfaccia grafica più complessa, ma ognuna è indipendente dalle altre.In applicazioni multi-activity, ne esiste una identificata come principale, che viene mostrata all’utentequando l’applicazione è lanciata per la prima volta; le attività possono poi avviare altre attività persvolgere determinate operazioni; in queste situazioni l’attività precedente è fermata e il sistema si occupadi memorizzarne lo stato nello stack.Il ciclo di vita delle Activity è il seguente:

Figura 3.2.: Ciclo di vita di una activity

21


Il prerequisito per l’installazione dell’Android SDK su Eclipse è l’avere sul proprio PC il JDK (JavaDeveloper Kit). Successivamente si passa all’installazione dell’Android SDK tramite l’installer che perònon contiene l’ambiente di sviluppo completo ma solo il nucleo dei tools utili a scaricare il resto delpackage dell’SDK.Nel momento in cui si installa il software è utile prendere nota della directory di installazione che verrà

richiesta durante l’installazione dell’ADT, il plugin per Eclipse.Ad installazione avvenuta verrà visualizzata la finestra in fig. 3.3:

Figura 3.3.: Repository Android

Verranno automaticamente selezionati i pacchetti consigliati e raccomandati da installare. Nello speci-fico per la corretta compilazione ed esecuzione dell’applicazione Android “Marvin Face Follow” e “MarvinPID” sono stati utilizzati i file di Android 2.3.3 con le Google API 10 rev.2.Una volta ottenuti tali file è possibile passare all’installazione dell’ADT per Eclipse che viene installato

tramite il menù Help > Install New Software di Eclipse e digitando nel campo “Work with” l’URLhttps//dl-ssl.google.com/android/eclipse/. Dare invio dopo aver selezionato tutti i plugin checompariranno nel repository.La fase successiva è la configurazione dell’ADT tramite il menù Windows > Preferences e selezionando

Android dal pannello a sinistra. Inserire la locazione nel file system dell’Android SDK precedentementeinstallato attraverso il tasto Browse e successivamente confermare le modifiche, come illustrato in fig.3.4.L’ultimo passaggio è l’importazione dell’applicazione “Marvin Face Follow”, o equivalentemente “Mar-

vin PID”, nel workspace selezionato: dal menù File > Import scegliere la directory contenente i file delprogetto (Android > Marvin Face Follow e le librerie Open CV) utilizzando l’opzione “Importa comeprogetto esistente” e quindi spuntare “Copy project into workspace” e dare invio.Dopo aver importato il progetto è necessario verificare che il link alle librerie Open CV sia stato

mantenuto: quindi andare in proprietà del progetto cliccando con tasto destro sul progetto nel packageexplorer di Eclipse, segliere Properties > Android e confrontare la schermata con la fig. 3.5.

22

https//dl-ssl.google.com/android/eclipse/


Figura 3.4.: Librerie Android

Figura 3.5.: Proprietà del progetto e link delle librerie

23


Se dovessero mancare le librerie OpenCV si può aggiungerle con il tasto “Add” e ricercarle tra i progettiimportati.

3.2. RT-Druid e ERIKA Enterprise v1.6.1RT-Druid è l’ambiente di sviluppo per la Flex Board, o meglio per ERIKA RTOS. Infatti la particolare

architettura della Flex impone di utilizzare RT-Druid come unico IDE sia per la scrittura dei Task e deicomponenti del sistema Real-Time che per la scrittura a basso livello delle istruzioni del microcontrolloredsPIC.RT-Druid ha una struttura modulare, integrata nel framework Eclipse attraverso lo strumento dei

plugin, è composto da un modulo per la generazione del codice, e uno per l’analisi di schedulabilità.Il code generator è distribuito anche in versione stand-alone indipendente da Eclipse, si tratta essenzial-

mente di un compilatore per OIL (il linguaggio dello standard OSEK ) che, in base alle specifiche definitenel file OIL di configurazione del sistema, costruisce la struttura necessaria alla compilazione di ERIKA(makefiles, inizializzazione delle strutture dati, ecc.). Il plugin per l’analisi della schedulabilità permettedi modellare, analizzare e simulare il comportamento temporale del sistema embedded progettato, ma èdisponibile solo nelle versioni commerciali di ERIKA.RT-Druid è corredato di una serie di esempi, disponibili per varie di architetture hardware: ciò agevola

la realizzazione delle applicazioni, potendo prendere spunto da tali esempi di codice. Nel caso della Flexè possibile trovare tali esempi nel menù File > New > RT-Druid OIL e C/C++ project dove, dando unnome al progetto e cliccando su “next”, è possibile avere un elenco di hardware ed esempi collegati; i piùinteressanti sono quelli per il pic30 che corrispondono ai progetti utili per l’architettura dsPIC.Una applicazione per la Flex Board, come detto, è dipendente sia dai file del sistema operativo ERIKA

sia dal codice di basso livello del microcontrollore. Proprio per questo tutti gli oggetti che vengonoutilizzati dal sistema operativo devono essere definiti nel file OIL (di solito config.oil), che attraverso unaparticolare sintassi, istanzia gli oggetti (ad esempio gli Alarm, i Task, le Risorse) da utilizzare e definiscenell’oggetto OS le caratteristiche globali dell’applicazione, come la presenza di possibili stack non condivisidai task in esecuzione (MultiStack), del tipo di Kernel da utilizzare e le specifiche sul microcontrolloreattraverso la proprietà MCU_Data.La scrittura del file OIL porta alla generazione del codice di configurazione per ERIKA Enterprise(EE),

del codice sorgente e dei makefiles richiesti per compilare l’applicazione.Definito il file OIL si possono usare gli oggetti istanziati nei file .c che costituiscono il codice sorgente

dell’applicazione. Questi oggetti sono richiamati mediante opportuna sintassi: ad esempio un task èistanziato con la keyword TASK(nometask) e richiamato attraverso particolari API messe a disposizioneda ERIKA tra cui la semplice ActivateTask(nometask).La configurazione di questo ambiente di sviluppo su Windows prevede l’installazione di ERIKA En-

terprise e RT-Druid. In questa tesi è stata utilizzata l’ultima versione disponibile di RT-Druid la 1.6.1.Su Windows è necessario anche installare Cygwin 1.7.9, che viene utilizzato dall’IDE per compilare i filesorgenti, e Java Runtime Environment versione 6 o superiore.I passi necessari a configurare correttamente l’IDE sono:

1. Installare Java Runtime Environment

2. Installare Cygwin nella sua directory originaria C:/cygwin.

3. Copiare RT Druid ed Erika 1.6.1 in una directory. Se si usa Vista è necessario che non ci sianospazi nella directory di installazione, ad esempio è consigliabile installare tutto in C:/Evidence

4. Quando si seleziona il workspace di lavoro per RT-Druid non bisogna usare spazi. Ad esempio, èpossibile posizionare il workspace in C:/Users/yourusername/workspace

24


5. È importante non creare mai delle directory, oltre a quelle specificate, con cui lavorare con questoIDE in altri path tranne la directory Users, quindi scegliere sempre C:/Users/yourusername/ perlavorare senza problemi

6. Una volta installato il pacchetto contenente Erika e RT-Druid 1.6.1 bisogna effettuare l’aggior-namento dei plugin da Eclipse, quindi andare su “Help > Install New Software” ed utilizzareil seguente repository http://download.tuxfamily.org/erika/webdownload/rtdruid_161_nb/,selezionando tutti gli aggiornamenti

Figura 3.6.: Repository RT-Druid

Per ultimare l’installazione è necessario installare il Compilatore per il dsPIC montato a bordo dellaFlex Full e che avrà il compito di trasformare il codice scritto per la macchina e quello di ERIKA in codiceoggetto, producendo un .cof che, attraverso l’IDE MPLAB della Microchip, finalmente programmerà lascheda di sviluppo.Il compilatore testato e funzionante con RT Druid 1.6.1 è l’MPLAB C Compiler for PIC24 and dsPIC

v3.31 versione Combo, edizione per studenti, installato nella directory di default.Utilizzando questo compilatore tutte le vecchie versioni di RT Druid non sono più funzionanti perciò è

consigliabile lavorare con 1.6.1.Dopo aver finito di installare il compilatore, ritornare su RT-Druid e andare su Windows > Preferences

e dal menù laterale della schermata che si aprirà cercare RT Druid -> Oil -> dsPIC e verificare che laschermata corrisponda alla fig. 3.7:

25

http://download.tuxfamily.org/erika/webdownload/rtdruid_161_nb/


Figura 3.7.: Link librerie MPLAB

26


Infine andare su Project e togliere la spunta su Build Automatically; ogni volta che si vorrà fare labuild del progetto dalla finestra Project Explorer andare su Build Project (vedi fig. 3.8).

Figura 3.8.: Build del progetto

La Build si compone di due parti. Prima di tutto viene creato e compilato il sistema ERIKA; questorichiede generalmente più tempo rispetto alla seconda parte che è invece solo la traduzione in codiceoggetto delle istruzioni presenti nei file .c o .h del progetto.Se il file OIL non ha subito modifiche recenti la Build fa partire solo la seconda.L’ambiente di sviluppo RT-Druid non supporta alcune funzionalità offerte da Eclipse, come il com-

pletamento automatico o il supporto completo a tutti i valori dei registri del microcontrollore, ancheun ambiente correttamente configurato mostrerà a schermo falsi errori, come è possibile notare nellaschermata sottostante:

Figura 3.9.: RT-Druid IDE

27


questo non compromette la compilazione del file .cof, infatti gli “errori” vengono “risolti” in fase dicompilazione.Tuttavia rendono questo IDE può risultare confusionario e di difficile accesso.Per importare il progetto “Marvin Face Follow” (o equivalentemente Marvin PID) si procede attraverso

il menù File > Import > existing project into Workspace e si seleziona Marvin spuntando la copia delprogetto nel workspace.Dopo aver importato il progetto è necessario spostarsi nel Project Explorer e selezionare dal menu a

tendina Clean Project e successivamente Build Project per ottenere un nuovo file .cof.Il log della corretta compilazione di Marvin PID, ma è equivalente per il Face Follow, è il seguente che

include entrambi gli step cioè la compilazione di ERIKA e del codice .c [2]**** Build of configuration Default for project Marvin PID ****C:\ Users \ WISTA \ flexworkspace \ Marvin PID\ Debug \ make_launcher .bat allC:\ cygwin \bin\bash found !cygwin warning :MS -DOS style path detected : C:\ Users \ WISTA \ flexworkspace \ Marvin PID\ DebugPreferred POSIX equivalent is: / cygdrive /c/ Users /.../ Marvin PID/ DebugCYGWIN environment variable option " nodosfilewarning " turns off this warning .Consult the user ’s guide for more details about POSIX paths :http :// cygwin .com/cygwin -ug -net/ using .html#using - pathnamesUsing erika files in / cygdrive /c/ EVIDEN ~2/ eclipse / plugins /.../ ee_filesLooking for the MPLAB C30 directory ...... Using C:\ Program Files \ Microchip \ mplabc30 \v3 .25CPP eecfg .cCPP code.cCPP ee_hal_structs .cCPP ee_context .cCPP ee_irq .cCPP ee_utils .cCPP ee_alcancel .cCPP ee_altick .cCPP ee_alget .cCPP ee_alsetabs .cCPP ee_alsetrel .cCPP ee_irqsc .cCPP ee_rqexchg .cCPP ee_rqinsert .cCPP ee_schedule .cCPP ee_thact .cCPP ee_thendin .cCPP ee_mutex .cCPP ee_internal .cCPP ee_utils .cAR libee .aLDOBJDUMP************************************Compilation terminated successfully !**** Build Finished ****

28


3.3. Microchip MPLAB v8.43Per la programmazione del dsPIC, a bordo della scheda FLEX, si utilizza il programmatore Microchip

MPLAB ICD2 collegando, con un apposito cavo, i due dispositivi attraverso la porta ICD2.La Microchip mette a disposizione l’ambiente di sviluppo MPLAB IDE per programmare il microcon-

trollore, sono integrate diverse funzionalità: gestione dei file e organizzazione dei progetti, editor per isorgenti, compilatori, programmazione e debugging con MPLAB ICD2.In questo lavoro l’IDE è utilizzato solamente nella gestione dei file, importando il file dell’applicativo

realizzato con RT-Druid per programmare il dsPIC.Per programmare il dsPIC è necessario andare su File > Import e scegliere il .cof generato da RT-

Druid (nella directory Debug del progetto).Successivamente dopo aver collegato fisicamente PC e Flex Full andare nel menù Programmer > Select

Programmer MPLAB ICD2; successivamente dopo che la comunicazione è stata stabilita seguire i seguentipassaggi:Programmer > Connect e successivamente Programmer > Program

Figura 3.10.: Log della programmazione del dsPIC

Una volta collegato l’ICD2 il dsPIC è tenuto in uno stato di “Reset”, per sbloccarlo è sufficientescollegare l’ICD2 oppure utilizzare Programmer > Release from Reset.Per poter utilizzare correttamente questa procedura è necessario effettuare una configurazione per

l’ICD2 cioè andare in Configure > Select Device e settare i parametri come in fig. 3.11:

29


Figura 3.11.: Setup ICD2 e MPLAB

3.4. Arduino IDE v1.0Arduino IDE è l’ambiente di sviluppo per il microcontrollore Arduino, basato su Processing, un software

nato in origine come ambiente di sviluppo Java. Arduino IDE è molto semplice da utilizzare e daconfigurare e questo risulta un grande punto a favore di questo progetto open-source italiano. Una voltaottenuto l’ambiente di sviluppo non c’è bisogno di nessuna installazione, basta lanciare Arduino.exe periniziare a lavorare sull’IDE.Per utilizzare la Board Arduino Mega ADK sono necessari dei drivers di comunicazione USB tra il PC

e la board che una volta installati faranno apparire Arduino come una porta seriale virtuale VCOM.Fatto questo bisogna definire in Tools > Board la board “Arduino Mega 2565 or Mega ADK” e definire

in Tools > Serial Port a quale porta seriale è associato Arduino così da poter uploadare il codice e aprireil Serial Monitor (vedi fig. 3.12).Il codice per Arduino di solito viene compilato nel momento in cui viene inviato alla Board attraverso

l’icona Upload

senza bisogno di un programmatore esterno, in quanto ogni board Arduino è fornita di un Bootloader:un piccolo programma che permette di programmare il microcontrollore Atmel via USB.Il bootloader è attivo per alcuni secondi nel momento in cui la board viene resettata e viene avviato

ogni qual volta c’è del nuovo codice sulla board. Dopo aver completato l’upload i led TX e RX sullaboard lampeggeranno e il codice srà quindi compilato ed inviato sulla board. Essa inizierà da subito lasua esecuzione, non esiste modo -come succede programmando la Flex- di mantenere la board in unostato di Reset.

30


Figura 3.12.: Selezione prototype board

31


La libreria Microbridge ADB deve essere installata insieme all’IDE e per fare ciò basta copiare lacartella nella directory libraries di Arduino.Per utilizzare questa libreria con Arduino IDE 1.0 e la Mega ADK bisogna effettuare delle modifiche

ai file che la compongono:

• Adb.h, usb.cpp, max3421e.cpp : la stringa Wiring.h va sostituita con Arduino.h, poiché Wiring.hha subito una ridenominazione passando alla versione 1.0 dell’IDE

• Nel file max3421e.cpp alla riga 387 bisogna sostituire questo codice// Wait until the PLL is stablewhile (!( max3421e_read ( MAX_REG_USBIRQ ) & bmOSCOKIRQ )){

// Timeout after 256 attempts .tmp ++;if (tmp == 0)

return ( false );}

Con questo:// Wait until the PLL is stablewhile (!( max3421e_read ( MAX_REG_USBIRQ ) & bmOSCOKIRQ ))

Per evitare che l’oscillatore interno non effettui un corretto setup.

Per effettuare il debug sulla board bisogna utilizzare la funzionalità Serial Monitor, infatti dall’ArduinoIDE non si ha la possibilità di impostare breakpoints ed effettuare una esecuzione del codice step-by-step.Per questo Arduino ha a disposizione dei comandi per abilitare la porta seriale (comunicazione lato boardvia USART) per inviare stringhe, caratteri di controllo oppure risultati di elaborazione sullo schermo delPC.La comunicazione seriale è abilitata con le istruzioni Wiring Serial.Begin(baudrate) e istruzioni di

scrittura come Serial.println(stringa,formato). Il Monitor Seriale viene aperto nell’IDE attraversol’icona

Si può affermare dunque il Serial Monitor è il mezzo built-in di Arduino equivalente alla libreriaSerialConsole.h e del convertitore PL2303 usato per il debug della Flex.Per importare il progetto esistente di Marvin è sufficiente aprire il file Marvin.ino (File > Open) ed

effettuare l’upload sulla Board attraverso il comando Upload dell’IDE.

3.5. Vinculum-II IDE v1.4.4FTDI mette a disposizione una serie di firmware precompilati per alcune semplici applicazioni realiz-

zabili con il chip Vinculum-II; per applicazioni più complesse è necessario realizzare un proprio firmwareche deve essere programmato nel chip.A tal fine FTDI ha creato il Vinculum-II Toolchain, un insieme di strumenti software necessari per

la compilazione e lo sviluppo di applicazioni per il VNC2, che includono: un compilatore C, assembler,linker, debugger e un IDE.Lo sviluppo di applicazioni per il VNC2 è facilitato dall’utilizzo di kernel, driver di dispositivo e librerie

di runtime fornite nel Vinculum-II Toolchain. I vari strumenti della toolchain sono delle applicazioniconsole, e come tali vengono integrate nell’IDE.

32


Figura 3.13.: Vinculum IDE toolchain

Il Vinculum-II IDE è il software utilizzato nello sviluppo delle applicazioni per il VNC2. Gestisce ifile di progetto e permette di creare l’output binario dell’applicazione usando gli strumenti integrati nellatoolchain:

• il compilatore VinC;

• l’assembler VinAsm;

• il linker VinL;

• il debugger VinDbg;

Figura 3.14.: Architettura Vinculum-II

La programmazione del firmware per il VNC2 avviene utilizzando il linguaggio C; l’architettura delfirmware è composta da tre livelli:

• il VOS Kernel, responsabile della gestione delle risorse hardware, degli interrupt e dello schedulingdei thread;

33


• i driver FTDI, forniscono un’interfaccia di programmazione per il controllo delle risorse hardware.

• le librerie FTDI, che mettono a disposizione un insieme di funzioni C per operazioni comuni diinput/output e gestione dinamica della memoria.

IL VNC2 RTOS (VOS) kernel è un sistema operativo preemptive, multi-tasking, basato su priori-tà; esegue i task secondo l’ordine deciso dallo scheduler sulle priorità di ognuno; inoltre fornisce anchemeccanismi di sincronizzazione tra i task come semafori e sezioni critiche.Il C non è l’unico linguaggio con cui è possibile programmare il Vinculum II. Infatti esiste anche un

insieme di API semplificate chiamate Vinco libraries che sono inspirate al linguaggio Wiring - simile aquello usato per programmare Arduino - che se da un lato semplificano l’accesso alla piattaforma dall’altranon permettono di usare appieno tutte le funzioni del RTOS VOS.L’installazione di questo IDE è molto semplice ma essendo stato escluso dal progetto l’utilizzo del

Vinculum-II, non si approfondirà l’argomento.Si rende presente comunque che il Vinculum IDE ha strumenti ottimi per il debugging del codice

attraverso i quali è possibile monitorare quali task sono in esecuzione ed il loro stato, è possibile leggereil valore di tutte le variabili e effettuare un run del codice step-by-step per mezzo della definizione di unmassimo di 3 breakpoints.

Figura 3.15.: IDE del Vinculum-II

3.6. RealTerm v2.0RealTerm è uno dei tanti programmi freeware per leggere dati da porta seriale. Essenzialmente esso

è stato scelto per la sua facilità di installazione ed per le molte opzioni che mette a disposizione; vieneutilizzato come strumento di debug per la Flex. Le impostazioni per avere una corretta configurazionesono:

• Nel tab Display spuntare “new line mode” in maniera tale che il programma processi la sequenzadi escape \n, inviata attraverso la libreria serialConsole.h, come un “a capo” .

• Nel tab Port impostare come porta seriale il convertitore Prolific e come Baud 115200, che è il baudrate di comunicazione della Flex.

Fatto questo è possibile ricevere ed inviare correttamente i dati utilizzato il tab “Send”.

34


Figura 3.16.: Ricezione dati dalla scheda Flex

Un esempio dell’utilizzo della libreria in combinazione con RealTerm può essere di questo genere: Lalibreria permette di inviare stringhe al PC senza aspettarsi una risposta attraverso la sintassiSendStringReply ("\ nTesto \n",PC ,NoReply ,false ,false , UARTx );

oppureSendNumReply (1234 ,PC ,NoReply ,,false ,false , UARTx );

È anche possibile bloccare l’esecuzione del codice sulla Flex (come se si avessero dei breakpoints) finchénon vengono inviati un numero di caratteri sufficienti dal PC verso la board attraverso l’istruzioneSendStringReply ("\ nTesto con risposta \n",PC ,Reply ,& reply [0] ,1 , UARTx );

oppureSendNumReply (1234 ,PC ,Reply ,& reply [0] ,1 , UARTx );

Figura 3.17.: Invio dati alla scheda Flex

che inviano rispettivamente una stringa o un numero e si aspettano 1 carattere di risposta che la Flexsalverà nell’array reply partendo dalla posizione 0.

35

Capitolo 4.

Analisi dei Requisiti e Progettazione delSistema

Il sistema da realizzare è composto da diversi componenti hardware e software per questo la realizzazioneè stata condotta attraverso layer di funzionalità. Ogni layer deve essere in grado di fornire interfacce ailivelli sovrastanti ed essere descritto mediante input ed output.Il capitolo inizia con una panoramica sull’analisi dei requisiti del sistema, ovvero cosa deve fare il

sistema per poi spiegare le funzionalità dei vari layer realizzati.

4.1. Analisi dei RequisitiVi sono due diversi tipi di requisiti sul sistema, quelli funzionali – cioè necessari per rispondere al

quesito riguardante cosa il robot “deve fare” – e i requisiti aggiuntivi o non funzionali, che fornisconovincoli addizionali, permettendo un ulteriore sviluppo del progetto nel tempo.I requisiti sono schematizzati qui di seguito.

Requisiti funzionali:

• Dotare il robot dei movimenti spaziali tramite API portabili

• Garantire un canale di comunicazione con ogni dispositivo Android

• Garantire una comunicazione affidabile con Arduino

• Implementare algoritmi di visione e decisione del movimento su dispositivo mobili dotati di AndroidOS

• Aggiungere il motore che permette uno snodo “di testa”

Requisiti aggiuntivi:

• Gestire l’elaborazione della scheda Flex Full attraverso l’RTOS ERIKA in maniera intelligente

• Migliorare il programma di visione attraverso un semplice algoritmo di ricerca volti

• Sostituire il Motion Processor con motori controllabili

• Implementare un controllore PID

• Rendere più accessibile la scheda Flex creando API per la gestione ad hoc delle periferiche sullafalsariga di Wiring

• Comunicazione wifi tramite Android OS

36

Capitolo 4. Analisi dei Requisiti e Progettazione del Sistema

4.2. Requisiti Funzionali

4.2.1. Dotare il robot dei movimenti spaziali tramite API portabiliIl sistema deve essere in grado di controllare i movimenti del robot; ricevuto in ingresso il comando che

identifica il movimento da eseguire, dovrà azionare i motori per muovere opportunamente il robot.I comandi che il sistema deve gestire sono:

• avanti

• indietro

• gira a destra

• gira a sinistra

• stop

• muovi la testa verso l’alto

• muovi la testa verso il basso

In un primo momento si è implementato questa caratteristica così come era stato fatto su AndroEE-Bot, cioè utilizzando il Motion Processor ma, come precedentemente anticipato, questa versione è statamodificata per raggiungere il requisito aggiuntivo relativo alla sostituzione del Motion Processor.E’ stato necessario pensare all’elettronica di alimentazione e lo studio dei servomotori e la scrittura

della libreria Servo.h per permettere il controllo del robot attraverso comandi inviati dallo smartphone.

4.2.2. Garantire un canale di comunicazione con ogni dispositivo AndroidQuesto requisito è stato raggiunto attraverso l’inserimento nel sistema di Arduino poiché compatibi-

le con la libreria Microbridge ADB, che è risultata la libreria migliore per gestire una comunicazioneaffidabile con qualsiasi smartphone.A livello applicativo sono state incluse in Android le classi:

• AbstractServerListener

• Client

• ServerListener

• Server

Per gestire la comunicazione con Android, inoltre, da parte di Arduino bisogna includere gli headerSPI.h, Adb.h. Nel setup() bisogna inizializzare l’ADB subsystem così:ADB :: init ();connection = ADB :: addConnection ("tcp :4568 ", true , adbEventHandler );

Il polling dell’ADB deve essere inserito in loop() per ricevere i dati ad ogni ciclo di elaborazione,con l’istruzione ADB::poll(), che richiamerà l’unica funzione implementata, tra quelle disponibili nellalibreria, cioèvoid adbEventHandler ( Connection * connection , adb_eventType event , uint16_t length ,

uint8_t * data)

filtrando solo gli eventi di tipo ADB_CONNECTION_RECEIVE.

37


4.2.3. Garantire una comunicazione affidabile con ArduinoIl requisito è raggiunto attraverso l’implementazione lato Flex della libreria Arduino.h che contiene

API per richiedere dati al microcontrollore, mentre lato Arduino la verifica di ricezione di informazionidalla Flex è ottenuta mediante l’API serialEvent() che viene richiamata automaticamente del sistemaArduino ad ogni ciclo di loop() e verifica quali tipi di dato sono presenti nel registro. La ricezione avvienedalla porta seriale 1 a cui la Flex è fisicamente collegata.

4.2.4. Implementare algoritmi di visione su AndroidIl requisito relativo all’implementazione di algoritmi di visione e decisione del movimento su dispositivo

Android è stato soddisfatto ereditando quasi in toto l’applicazione dal precedente progetto. L’applicazioneutilizza l’algoritmo detectMultiScale() tramite il quale è possibile identificare, dato un frame, unoggetto corrispondente ad alcune caratteristiche descritte nel file “cascade”, scritto in formato XML.Nel progetto è stato utilizzato come cascade lbpcascade_frontalface.xml, permettendo il riconoscimento

di volti in posizione frontale attraverso l’algoritmo di face detection Local Binary Pattern (LBP).

4.2.5. Aggiungere il motore che permette uno snodo “di testa”AndroEEBot effettuava movimenti solo sull’asse X e Z (vedi figura seguente), con Marvin si è reso

possibile il movimento anche sull’asse Y attraverso l’aggiunta del servomotore HS-485HB e lo studio edimplementazione del modulo PWM che ha portato alla scrittura delle librerie PWM.h e Servo.h.

Figura 4.1.: Assi di Marvin

4.3. Requisiti AggiuntiviI requisiti aggiuntivi rappresentano una sorta di sperimentazione e una dimostrazione di come sia

possibile evolvere e migliorare un’idea di partenza attraverso passi incrementali.Definiti gli obiettivi principali pian piano ci si è resi conto di come migliorare e aggiungere diversi

aspetti al sistema; questi requisiti risultano essere degli ulteriori vincoli.

38


4.3.1. Elaborazione tramite RTOS ERIKAIl multithreading e lo sviluppo di thread concorrenti/collaborativi sono possibili anche su microcon-

trollore attraverso l’uso ottimale di ERIKA, seppur l’applicazione Marvin e AndroEEBot ne fanno unutilizzo semplice, istanziando un thread periodico.Il lavoro si è orientato principalmente nel capire come utilizzare al meglio l’RTOS e successivamente si

è ipotizzata una suddivisione dell’applicazione in thread secondo una politica “Produttore-Consumatore”.

4.3.2. Migliorare il programma di visioneAndroEEBot necessitava di un volto che fosse presente nella scena per applicare l’inseguimento. Esten-

dendo questo concetto ad un contesto più reale risulta necessario che il robot debba effettuare una, seppursemplice, ricerca di eventuali volti intorno ad esso.Il semplice algoritmo implementato nell’applicazione Android permette di definire due intervalli di

tempo, regolabili in fase di programmazione: startBehaviour e stopBehaviour che indicano un numerodi cicli entro i quali fermare o mantenere attiva la ricerca di un volto. Il comportamento implementatoconsiste nel far ruotare su se stesso il robot; il verso di rotazione dipende dall’ultimo spostamento che èstato registrato. Se il volto prima di sparire dal frame si è spostato verso destra, ad esempio, il robotgirerà verso destra nella speranza di trovare da quella parte il volto.Il comportamento di ricerca funziona anche nel caso in cui all’avvio del robot nessun volto dominante

è stato mai inquadrato nella scena, allora si impone un verso di rotazione a priori che nel caso di questatesi è destra.

Figura 4.2.: Flowchart per l’algoritmo di controllo del movimento

4.3.3. Sostituire il Motion ProcessorQuesto requisito è di fondamentale importanza per lo sviluppo futuro, il controllo e la personalizzazione

del progetto Marvin.Come spiegato in precedenza, seppure il Motion Processor sia un’ottima soluzione tecnica, esso limitano

l’aspetto real-time dell’applicazione delegando ad un altro “processore” il compito di eseguire i comandidi controllo. La soluzione è stata quella di inserire i servomotori DFRobotic ma in futuro, attraverso lalibreria PWM.h, l’API digitalWrite() e una circuiteria composta da un ponte H, sarà possibile sostituirei servo con motori DC più performanti.

39


4.3.4. Implementare un controllore PIDLa Meccanica, l’Elettronica e l’Informatica sono le scienze su cui l’Automazione si basa; avendo seguito

lo sviluppo del robot in tutte queste fasi è sembrato naturale cercare di attuare un Controllo per lospostamento nello spazio di Marvin. Non avendo a disposizione il modello matematico del robot, l’unicocontrollo applicabile è stato quello PID realizzato mediante l’implementazione dell’azione proporzionaleprima, e poi dell’azione proporzionale ed integratrice poi.Rendere più accessibile la scheda Flex creando API per la gestione ad hoc delle periferiche sulla falsariga

di Wiring: lo sviluppo del progetto in questo senso è stato dettato sia come evoluzione naturale dellostudio della scheda Flex e del microcontrollore dsPIC, sia come “emulazione” di Wiring: il linguaggio diprogrammazione embedded di Arduino.API semplici sono la forza del progetto Arduino poiché rendono accessibile la scheda di sviluppo in

poco tempo.

4.3.5. Comunicazione wifi tramite AndroidQuesta caratteristica disponibile già per AndroEEBot è stata mantenuta, ma non testata, anche in

Marvin; essa permette la comunicazione con un applicazione ad hoc su un PC attraverso la rete wifi dicui ogni smartphone è dotato.

4.4. Architettura e funzionamento del sistemaL’architettura del sistema è divisa in 4 livelli dal più basso al più alto:

• Attuazione: è composto dall’elettronica, della meccanica e da tutti gli attuatori del sistema, ovverodai 3 servomotori

• Controllo: comprende l’ MCU dsPIC che gestisce il movimento del robot, l’interfacciamento conla sensoristica e il sistema operativo Real Time ERIKA;

• Comunicazione: composto da Arduino e dalla libreria Microbridge ADB, questo livello fungeanche da espansione del sistema. Infatti è possibile sfruttare Arduino come una seconda logica dicontrollo da affiancare alla Flex per controllare l’attuazione di comandi verso il mondo esterno

• Comando: è il livello rappresentato dallo smartphone che attraverso applicazioni Java permettedi controllare i livelli sottostanti e comunicare con PC attraverso wifi.

Uno schema grafico dell’architettura è visibile in fig.4.3Il ciclo di funzionamento di Marvin è composto da diverse fasi di elaborazione gestite indipendentemente

da i vari livelli architetturali sopra descritti, l’elaborazione parte dal livello di Comando che analizzandoi frame video decide quali spostamenti imporre ai livelli sottostanti e/o inviare i dati tramite wifi al PC.I dati sono inviati al layer di comunicazione in maniera asincrona, proprio come se il livello superiore

fosse un enorme sensore; i comandi di spostamento, espressi come singolo byte o insieme di essi, vengonoinviati tramite microbridge ADB ad Arduino che li conserva in una variabile globale, intanto esso restain attesa di interrupt sulla Serial 1 (è opportuno ricordare che Arduino ha 4 porte seriali USART) oppurepotrebbe elaborare altri dati provenienti da un eventuale sensoristica.Indipendentemente dai livelli superiori sulla board Flex Full , dopo l’inizializzazione delle periferiche,

ogni 100 ms viene mandato in esecuzione da ERIKA un task periodico che richiede i dati via USART 1ad Arduino.La risposta che proviene da quest’ultimo è l’ultimo dato di movimento che Android ha inviato al

layer di comunicazione in modo asincrono. La Flex quindi elabora questi dati attivando, in base al

40


tipo di applicazione presente sul layer di comando il controllo PID oppure la semplice generazione deicorrispondenti comandi di attuazione per i servomotori.La Flex durante un suo ciclo di elaborazione può anche ricevere dati dalla sensoristica o inviare, tramite

USART 2, informazioni di debug verso Arduino o PC.

Figura 4.3.: L’architettura a 4 livelli di Marvin

4.5. Protocolli di comunicazioneData la complessità del sistema, è fondamentale definire quali sono i dati che vengono scambiati tra

i vari componenti e le interfacce utilizzate. Il sistema è stato concepito per funzionare in due differentimodalità, spostamento “manuale” e PID: è necessario, dunque, distinguere queste due istanze, creandodue opportuni protocolli di comunicazione.

4.5.1. AndroidEsistono due versioni dell’applicazione Android e sono “Marvin Grid View” e “Marvin PID”.“Marvin Grid View” calcola gli spostamenti in base alla posizione del volto rispetto a delle aree pre-

definite nel frame. La definizione predefinita delle aree è detta Grid View, e divide il frame in cinquearee distinte; una centrale, due aree laterali – destra e sinistra –, un’area superiore ed una inferiore. La

41


presenza di un volto in ciascuna di queste aree induce la generazione di un particolare pacchetto che èformattato come segue:

1 byte: MODE 1 byte: DIRECTIONOxOF OxOn

Tabella 4.1.: Formato del pacchetto trasmesso dall’applicazione Android “Marvin Grid View”

MODE serve per notificare ad Arduino quale applicazione è in esecuzione su Android. Il byte associatoall’applicazione “Grid View” è 0x0F.

DIRECTION, invece contiene un byte di spostamento calcolato da Android e può assumere i seguentivalori:

• 0x00 STOP

• 0x01 AVANTI

• 0x02 INDIETRO

• 0x03 GIRA A DESTRA

• 0x04 GIRA A SINISTRA

• 0x05 SNODO DI TESTA VERSO L’ALTO

• 0x06 SNODO DI TESTA VERSO IL BASSO

La seconda applicazione, “Marvin PID”, è invece pensata per sfruttare il PID e perciò utilizza unadiversa formattazione del pacchetto:

1 byte: MODE 15 byte: ERROROxOC sX errorX sY errorY sZ errorZ

Tabella 4.2.: Formato del pacchetto trasmesso dall’applicazione Android “Marvin PID”

Nell’applicazione “Marvin PID” MODE è pari a 0x0C.I successivi 15 byte, ERROR, possono essere interpretati a blocchi di 5 byte. Ogni blocco contiene:

• sK: 1 byte che contiene il segno dell’errore sull’asse K;

• errorK: 4 byte che forniscono, quando interpretati, un float che rappresenta l’errore in valoreassoluto sull’asse K.

4.5.2. ArduinoNel layer di comunicazione i due differenti comportamenti di controllo sono contemporaneamente pre-

senti e il byte MODE inviato da Android determina quale comportamento implementare. I comandi cheAndroid invia vengono captati da Arduino attraverso void adbEventHandler(), che filtra solo gli eventidi tipo ADB_CONNECTION_RECEIVE come spiegato in precedenza; in particolare il byte MODE viene salvatonella variabile globale MODE e riutilizzato in fase di risposta alla Flex. I dati inviati da Android sonocontenuti nell’array data.if ( event == ADB_CONNECTION_RECEIVE ){

MODE = data [0];/* The Application is using the Grid View */if (MODE != 0x0C)

42


{// data in position data [1] contains robot ’s directiondirection =data [1];

}/* The application is using the PID View */else

for(i=0;i <15;i++) directions [i]= data[i+1];}

Nella funzione void serialEvent1(), associata agli interrupt della Serial1, il seguente frammento dicodice Arduino verifica che la Flex abbia richiesto l’invio dei dati di direzione, e risponde in base al MODEprecedentemente salvato. Arduino antepone al pacchetto un byte di controllo per l’integrità dei dati.if( Serial1 . read () == 0x7F){

Serial1 . write (0 x0A);/* The Application is using the PID View */if(MODE != 0x0C)

Serial1 . write (( byte ) direction );/* The application is using the Grid View */else

for(j=0;j <15;j++) Serial1 . write ( directions [j]);}

1 byte: MODE 1 byte: DIRECTIONOxOF direction

Tabella 4.3.: Formato del pacchetto trasmesso da Arduino nell’applicazione “Marvin Grid View”

1 byte: CTRL 15 byte: ERROROxOA directions[j]

Tabella 4.4.: Formato del pacchetto trasmesso da Arduino nell’applicazione “Marvin PID”

4.5.3. Flex Full BoardLa Flex Full, come detto, gestisce la comunicazione percependo Arduino e Android come un unico

sensore a cui richiedere, ogni 100 ms, i dati di spostamento attraverso il task periodico denominatoTaskSend. Sulla Flex esistono due diverse implementazioni del firmware a seconda di quale applicazioneAndroid si sta utilizzando, poiché varia il numero di dati da richiedere ad Arduino. La richiesta vienefatta usando la funzione Arduinio_Data_Request() contenuta in Arduino.h.Per l’applicazione “Grid View”, la funzione è:

Arduino_Data_Request (& arduinoData [0] , 2, UART1 );

Invece, per l’applicazione “PID”, la funzione è:Arduino_Data_Request (& arduinoData [0] , 16, UART1 );

Il byte di controllo inviato da Arduino viene verificato in entrambi i casi dalla Flex e se esso corrispondeal carattere di controllo atteso – 0x0A – allora esso farà illuminare il led Arancione (pin 25).if ( arduinoData [0] == 0x0A)

ledBlink (25 ,1 ,100);

43

Capitolo 5.

Implementazione del Software

Al termine della fase di progettazione e definizione del problema, dei requisiti e di vincoli si passa allafase di sperimentazione/studio e programmazione sia dei componenti embedded sia dell’applicazione adalto livello.Apre il capitolo una descrizione delle librerie e delle API scritte per la Flex. Si passa poi alle caratteristi-

che hardware sfruttate; segue una descrizione di ERIKA Enterprise con uno sguardo alle sue peculiarità.In seguito viene descritto il firmware per Arduino. L’implementazione per smartphone chiude il capitolo.

5.1. Librerie Flex FullIl lavoro maggiore si è concentrato sullo studio della scheda Flex Full partendo dal suo nucleo il dsPIC.

Come già detto si può fare a meno dell’architettura modulare - soprattutto se la parte elettronica darealizzare è ridotta all’osso – tutte le funzionalità sono già presenti sul microcontrollore e la flex esportatutti i 100 pin all’esterno.L’obiettivo principale è stato quello di semplificare l’accesso a funzionalità ricorrenti come le porte

USART di comunicazione, il PWM, il comando servomotori e motori DC e dotare la scheda di strumentidi debug a run time.Le librerie realizzate ed utilizzabili senza troppe difficoltà, in quanto poco dipendenti dall’applicazione

Marvin, sono descritte qui di seguito.

5.1.1. Libreria EEuart.h

// ----------------- Public functions ---------------void ee_usb_init ()void ee_usb_write (BYTE *ch , BYTE len , BYTE UART)void ee_usb_read (BYTE *data , BYTE UART)void ee_usb_read_len (BYTE *data , BYTE len , BYTE UART)

// ----------------- Internal functions ---------------void EE_UART1_Init ( EE_UINT32 baud , EE_UINT16 format , EE_UINT16 mode)EE_INT8 EE_UART1_Send ( unsigned char data)EE_INT8 EE_UART1_Receive ( unsigned char* data)void EE_UART2_Init ( EE_UINT32 baud , EE_UINT16 format , EE_UINT16 mode)EE_INT8 EE_UART2_Send ( unsigned char data)EE_INT8 EE_UART2_Receive ( unsigned char* data)

Con questa libreria è possibile inviare dati attraverso le due porte USART di cui la Flex Full è dotata.ee_usb_init() attiva ed imposta il modulo hardware della USART1 e USART2 con baudrate a 115200

baud. Attraverso ee_usb_write() vengono inviati tutti i byte contenuti nel vettore data attraverso laporta USART selezionata (1 o 2).

ee_usb_read() e ee_usb_read_len() permettono di leggere rispettivamente un byte o len byte esalvarli nel vettore data.

44

Capitolo 5. Implementazione del Software

Queste letture sono “bloccanti” cioè la macchina resta bloccata su queste funzioni finché non riceveesattamente len byte.L’implementazione delle API pubbliche viene fatta attraverso le chiamate alle funzioni private che im-

plementano a livello hardware la lettura/scrittura dei byte nei registri opportuni.

5.1.2. Libreria Arduino.h

void Arduino_Data_Request (BYTE reply [], BYTE len , BYTE UART)float convert4ByteTO1Float ( EE_INT32 byteArray []);

Arduino_Data_Request() permette di leggere len byte da Arduino e li salva nell’array reply.Convert4ByteTO1Float() converte un array formato da 4 byte nel corrispondente numero float; è uti-

lizzata per passare da Android alla Flex un numero in float sotto forma di byte e poi ricostruirlo sulla Flex.

5.1.3. Libreria Utility.h

void mydelay (int ONEMILLION );void pinMode (BYTE pin , BYTE mode);void digitalWrite (BYTE pin , BYTE voltage );void ledBlink (BYTE pin , BYTE times , int delay );float potenza ( float base , float esponente );double map ( double value , double in_min , double in_max , double out_min , double out_max );

mydelay() è un semplice delay, utile soprattutto in fase di debug, che blocca la macchina per diversicicli di clock; con valori di 2000-3000 si riesce a bloccare la macchina per 1-2 secondi, ma non garantiscela scansione precisa del tempo.

pinMode(), come su Arduino, attiva un determinato pin come input o output attraverso il parametromode, ogni pin sulla Flex è multiplexato, cioè può svolgere diverse funzionalità. Quindi solo alcuni pinpossono essere dati in ingresso a questa funzione e sono tutti quelli di PORTB [pin 20-27] e 2 di PORTA [pin91-92].

digitalWrite() permette di cambiare lo stato logico di un pin precedentemente attivato con pinMode()ponendolo HIGH o LOW, questa funzione può essere usata per accendere e spegnere un led oppure per invia-re segnali a logiche elettroniche di controllo esterne (es. flip-flop). ledBlink() è appositamente pensataper far “blinkare” un led impostando il pin a cui esso è associato, il numero di blink richiesti e il tempodi blinking di solito tra i 100 e i 1000 ms, funziona sui pin attivabili con pinMode().

potenza() effettua l’elevamento a potenza anche con esponenti negativi, è stata necessaria implemen-tarla poiché la libreria math.h della Flex non restituisce risultati corretti con esponenti negativi.

map() permette di effettuare un mapping di una variabile che varia in un insieme di valori A ad unaltro insieme di valori B.

5.1.4. Libreria serialConsole.h

void SendStringReply (char string [], BYTE ArduinoDebug , BYTE WithReply , BYTE reply [], BYTElen , BYTE UART);

void SendNumReply ( unsigned long int number ,BYTE ArduinoDebug , BYTE WithReply , BYTE reply[], BYTE len ,BYTE UART);

È la libreria che permette di inviare stringhe e numeri tramite porta USART.Le API sono dotate di diversi parametri ed possibile inviare solo dati oppure bloccare la macchina in

attesa di una risposta attraverso il byte WithReply impostato a true e definendo quanti byte leggereprima di sbloccarsi e dove salvarli.Si può scegliere anche se effettuare debug tramite il serial Monitor di Arduino utilizzando la costante

“Arduino” oppure “PC” per debug con il convertitore.

45


Se si comunica con Arduino si deve impostare il byte UART a UART1 mentre se si comunica con il PCimpostare il byte come UART2.

5.1.5. Libreria Servo.h

void ServoModule_init ();void ServoMotor_init (BYTE motor );void Servo_Neutral (BYTE motor );void Servo_plus90 (BYTE motor );void Servo_minus90 (BYTE motor );void Servo_Set_Position (BYTE motor , float hightime , float period );void Servo_Move (BYTE motor , float increment , float period );

La libreria è basata sulla libreria PWM.h. Queste API sono delle funzioni pubbliche della PWM ma i dueinsieme di API sono separati perché potrebbe essere necessario utilizzare la PWM non solo per utilizzarei motori, ma anche per altre periferiche fisiche ad esempio variare la luminosità di un led.

ServoModule_init() è la prima funzione da chiamare per attivare il modulo hardware dei servomotorial modulo hardware sono associati ben 8 uscite PWM. In Marvin ne vengono utilizzate solo 3 e il periododel PWM è impostato di default a 20 ms.

ServoMotor_init() dando le costanti HEAD, DX o SX attiva l’uscita PWM corrispondente che faparte dell’insieme degli 8 PWM attivabili dal modulo PWM inizializzato.

Servo_Neutral() in base al PWM scelto imposta il duty cycle a 1.5 ms questo significa che i motoriassociati a tale uscita PWM ritornano in posizione neutra, i motore di testa quindi si pone all’angolo 0°mentre i motori di propulsione smettono di girare.

Servo_plus90() e Servo_minus90() sono funzioni pensate per il motore di testa e impostano rispet-tivamente il duty cycle a 2.4 ms e 0.6 ms che corrispondono a +90 e -90 gradi. Se applicate ai motori dipropulsione questa API ha l’effetto di far ruotare in avanti o indietro i motori alla massima velocità.

Servo_Set_Position() è l’API migliore per controllare la posizione dello snodo di testa, infatti datoun valore di hightime (T-on) esso si sposterà precisamente all’angolo corrispondente. E’ anche l’APIpiù utile per controllare i motori di propulsione in quanto specificando 1.5 < T-on < 2.4 si controlla lavelocità di rotazione dei servi di propulsione in senso orario mentre con 0.6 < T-on < 1.5 si controlla lavelocità di rotazione dei servi di propulsione in senso antiorario.

Servo_Move() è l’API ideale per muovere con precisione il motore di testa infatti questa funzionericorda in automatico la posizione precedente del motore e permette di dare un incremento positivo onegativo allo snodo di testa così da effettuare micromovimenti partendo da una posizione fissata.

5.1.6. Libreria PWM.h

void PWM_module_on ();void Enable_PWM (int PWM);void PWM_Set_Duty_Cycle (int PWM , float hightime , float period );void PWM_Module_close ();void Disable_PWM (int PWM);

Questa libreria controlla il PWM hardware.PWM_module_on() attiva il modulo PWM impostando il periodo dell’onda quadra a 20 ms.Enable_PWM() attiva una particolare uscita PWM da 1 a 3 del modulo PWMPWM_Set_Duty_Cycle() imposta il registro P1DCx corrispondente ad una precisa uscita PWMPWM_Module_close() disabilita il modulo PWM spegnendo tutte le uscite PWMDisable_PWM() disabilita un preciso output PWM

46


5.1.7. Libreria PID.h

float PI_pid_Y ( float error )float P_pid_Y ( float error )float PI_pid_Z ( float error )float P_pid_Z ( float error )float PI_pid_X ( float error )float P_pid_X ( float error )

Contiene l’implementazione del controllore PID e le costanti impostate per i 3 assi di movimento:• Y associato al motore di testa

• Z associato al movimento avanti/dietro dei motori di propulsione

• X associato al movimento destra/sinistra dei motori di propulsione

Questa libreria utilizza la libreria Servo.h ma l’utilizzo di questa maschera il comando diretto deimotori.Per utilizzare questa libreria bisogna utilizzare anche l’applicazione Android corrispondente.Le API sono sempre le stesse sui tre assi e sono:

• PI_pid_K() utilizza il controllore proporzionale ed integrativo sull’asse K

• P_pid_K() utilizza il controllore proporzionale sull’asse K

5.2. Componenti Hardware Flex Full

5.2.1. OscillatoriUn oscillatore è un circuito elettronico che genera forme d’onda di frequenza, forma e ampiezza di

molteplici tipi senza un segnale di ingresso. Gli oscillatori nella loro vastità sono impiegati in innumerevoliapplicazioni che spaziano dalla temporizzazione di circuiti digitali e non, alla generazione di portanti perle telecomunicazioni, agli strumenti elettromedicali, ecc.Gli oscillatori possono dividersi in due principali categorie:

• Armonici o sinusoidali (o, più propriamente, quasi-sinusoidali);

• A rilassamento o bloccati;

Gli oscillatori armonici producono un segnale di andamento sinusoidale (o quanto più possibile prossimoad esso). Essenzialmente si tratta di un amplificatore in cui l’uscita è riportata all’ingresso con unaretroazione positiva, attraverso un filtro passa-banda stretto. Quando il circuito è acceso, l’amplificatoreproduce inevitabilmente in uscita del rumore. Il circuito di reazione riporta in ingresso le componenti delrumore di frequenza determinata, le quali vengono amplificate. Il ciclo si ripete fino al raggiungimento delregime di funzionamento. Essi sono suddivisibili in tre principali categorie in base agli elementi circuitaliutilizzati che cono RC, LC e Quarzati. Il dsPIC utilizza un oscillatore RC, composto esclusivamente daresistori e condensatori.Il dsPIC integra due oscillatori uno principale, FRC – Fast RC – a frequenza di 7.37 MHz e un

oscillatore secondario LP – Low Power – a 37.768 Khz e sono previste 7 diverse configurazioni per gestirlivia software:

• FRC Oscillator

• FRC Oscillator con PLL

• Primary Oscillator (XT, HS, EC)

47


• Primary Oscillator con PLL

• Secondary Oscillator (LP)

• LPRC Oscillator

• FRC Oscillator con Postscaler

La frequenza dell’FRC può essere modificata via software attraverso il circuito PLL (Phase LoopLocker) che ne incrementa di molto la frequenza i base portandola al massimo fino a 80 MHz.Il Primary Oscillator può essere:

• XT: Risonatore in Cristallo e Ceramica, genera armoniche da 3 MHz a 10 MHz esso è connesso aipin OSC1 e OSC2

• HS: Cristallo ad alta velocità (High Speed) con frequenze di clock generabili da 10 MHz a 40 MHz

• EC: Identifica un segnale di clock dato da un oscillatore esterno che può variare nel range difrequenze 0.8 – 64 MHz

L’oscillatore secondario (LP) è studiato per bassi regimi di potenza e per questo usa un cristallo cheoscilla a frequenze sensibilmente più basse rispetto a l’FRC; esso è collegato ai pin SOSCI e SOSCO.LPRC – Low Power RC – è una diversa modalità di impiego dell’LP ed è usato come timer per il

Watchdog1 e FSCM (Fail Safe Clock Monitor).La scelta della modalità è fatta attraverso i “Configuration Bits” FOSCSEL<2:0> e FOSC<1:0> in una

situazione di Power-on o Reset.Per ottenere la frequenza di funzionamento del dispositivo Fc, la frequenza di output dell’oscillatore

(oppure oscillatore + PLL) Fosc va divisa per 2:

Fc = Fosc2 (5.1)

Come detto, sia FRC sia LP possono utilizzare PLL per generare frequenze maggiori ma visto l’utilizzoche si fa del dsPIC, in questa tesi si adopererà solo l’FRC e si indicherà con FOSC il suo output.Fin indica la frequenza d’ingresso del PLL. Essa è divisa da un Prescaler, chiamato N1 che effettua

divisioni di 2, 3, ..., 33 prima che esso diventi input del PLL; a questo punto esso è indicato com Vco.Per impostare il fattore del prescaler N1 bisogna impostare i bits PLLPRE del registro CLKDIV. Il PLL

Feedback divisor PLLDIV del registro PLLFBD è denotato con M e rappresenta il fattore per il qualel’ingresso del PLL, Vco, viene moltiplicato. Infine l’output del PLL è diviso ancora di un fattore decisodal Postscaler, chiamato N2, il cui valore è impostato nei bit PLLPOST del registro CLKDIV. N2 può essere2, 4 oppure 8.Per cui, Fosc è dato dalla formula:

Fosc = Fin ·M

N1 ·N2 (5.2)

1letteralmente: cane da guardia. È un sistema di temporizzazione hardware che permette alla CPU la rilevazione di unloop infinito o di una situazione di deadlock,tale rilevazione può consentire di prendere dei provvedimenti per correggerela situazione, generalmente effettuando un reset del sistema

48


Figura 5.1.: Determinazione di Fosc

La frequenza più importante è ovviamente Fc, ovvero quella di funzionamento del dispositivo. Nelpresente lavoro essa è impostata al massimo valore disponibile, 40 MHz. Per ottenere questo valore ènecessario che Fosc sia di 80 MHz per cui utilizzo:

• XT con PLL in questo modo ottengo circa 10 MHz

• N1 = 2, cioè CLKDIVbits.PLLPRE = 0, questo porta la frequenza a 5 MHz

• M = 32, cioè PLLFBDbits.PLLDIV=0x1E (78 in decimale), ottenendo una frequenza di 160 MHz

• N2 = 2, cioè CLKDIVbits.PLLPOST = 0 ottenendo finalmente Fosc = 80 MHz, da cui Fc = 802 =40

MHz

5.2.2. USARTÈ la periferica per la comunicazione seriale asincrona e le sue funzioni sono contenute nel file eeuart.h.

Le varie funzionalità sono precedute dall’istruzione __INLINE__ al fine di rendere le chiamate più velo-ci; infatti il compilatore di fronte a questa keyword sostituirà la chiamata alla funzione con il codicecorrispondente.La Flex Full possiede due porte USART indipendenti denominate UART1 e UART2 e ogni porta può

essere configurata in maniera separata dall’altra.Per le funzionalità necessarie in questa tesi esse sono configurate allo stesso modo, cioè con il protocollo

8-N-1-None ovvero:

• 8 Data Bits

• Parity None

• 1 Stop Bit

• Flow Control None

49


Figura 5.2.: Architettura hardware di una periferica USART

Il diagramma semplificato della periferica vede 3 componenti principali: il Baud Rate Generator, inTrasmettitore Asincrono e il Ricevitore Asincrono.L’inizializzazione dei registri della periferica vengono effettuati dalla funzione ee_usb_init() che ri-

chiama EE_UART1_Init() e EE_UART2_Init(). L’attivazione della periferica è regolato dal bit UARTENdel registro UxMODE: se esso è pari a 0 la periferica è disattivata, risulta buona norma disabilitare gliinterrupt che tale periferica può generare per la ricezione e l’invio di byte attraverso i bit UxRXIE edUxTXIE del registro IEC0 infine fare una pulizia dei flag degli interrupt dedicati ovviamente alla ricezionee alla trasmissione nel registro IFS0.Importantissimo per stabilire una comunicazione è definire il Baud Rate, che rappresenta il numero di

simboli che viene trasmesso in un secondo. Per simbolo non si intende un solo bit ma in insieme di essi;per cui questa misura differisce dalla misura bps cioè bits per secondo. Per la Flex esso è impostato a115200 baud/s per ottenere questo valore viene utilizzata la seguente formula nel caso di BRGH = 0:

UxBRG = Fc16 ·DesideredBaud − 1 (5.3)

Questa formula è riportata nel codice del microcontrollore in questo modo:U1BRG = (2500000 ul / baud) - 1; // With BRGH = 0U2BRG = (2500000 ul / baud) - 1; // With BRGH = 0

dove:

Fc16 = 40 · 106

16 = 2500000⇒ baud = 115000 (5.4)

Successivamente all’impostazione del Baud Rate è necessario definire i pin di output che assumerannoil carattere di RX e TX. Essi sono stati scelti in accordo con il manuale di riferimento impostando i pincorrispondenti ai bit 2 e 3 per la UART1 e ai bit 4 e 5 per la UART2 sulla porta di I/O digitale PORTF2.La funzione EE_UART1_Init() ha una struttura molto flessibile permettendo di impostare il Baud Rate

desiderato, la modalità di funzionamento (con o senza Flow Control ) e il byteformat per modificare ilprotocollo 8-N-1.

2Vedi figura 3

50


Figura 5.3.: Il protocollo UART

Il registro UxRSR è lo shift register3, che si occupa della ricezione. I dati sono ricevuti sul pin UxRXe sono inviati al Data Recovery Block che opera ad un velocità pari a 16 volte il Baud Rate; dopo cheè stato acquisito lo Stop Bit del protocollo seriale, i dati ricevuti nel registro UxRSR sono trasferiti inuna coda FIFO. Essa può contenere al massimo 4 word contemporaneamente; se arriva una quinta worde il registro non è stato letto si entrerà in una situazione di buffer overrun, che deve essere gestita viasoftware.Il registro UxTSR invece è lo shift register che si occupa dell’invio dei dati verso il mondo esterno. Esso

riceve i dati dal buffer FIFO UxTXREG che viene caricato via software con i dati in uscita. Esso è caricatocon nuovi dati se e solo se è stato inviato lo Stop Bit dall’UxTSR.

5.2.3. Modulazione a Larghezza di Impulso (PWM)La modulazione di larghezza di impulso è un tipo di modulazione digitale che permette di ottenere una

tensione media variabile, dipendente dal rapporto tra la durata dell’impulso positivo e di quello negativo.Tale modulazione è utilizzata per protocolli di comunicazione in cui l’informazione è codificata sotto formadi durata nel tempo di ciascun impulso. Questa modalità è quella utilizzata dalla logica dei servomotori,logica in cui la durata nel tempo di ciascun impulso determina il comportamento dell’attuatore.La periferica del dsPIC utilizzata per generare la PWM è MCPWM1 che può generare output multipli e

sincronizzati rendendo la periferica ottimale per controllare diverse tipologie di motori.Alcune delle features del modulo MCPWM1 sono:

• fino ad otto output PWM con quattro generatori di duty cycle

• possibilità di attivare o disattivare manualmente le singole uscite PWM

• possibilità di cambiare la PWM “on-the-fly”

• Dead time generabile via hardware

• Diverse modalità di utilizzo:

– Single event mode

– Edge-aligned mode

3registro a scorrimento costituito da una catena di celle di memoria ad 1 bit interconnesse tra loro. Ad ogni impulso diclock consentono lo scorrimento dei bit da una cella a quella immediatamente adiacente, al fine di convertire i bit arrivatiin forma seriale a quella parallela.

51


– Center-aligned mode

– Center-aligned mode with double updates

– Complementary output mode

– Independent output mode

Il dsPIC ha anche un secondo modulo per il controllo motori tramite PWM, MCPWM2, leggermentediverso rispetto a MCPWM1. Tale modulo non è stato utilizzato nella progettazione di Marvin.L’MCPWM1 è stato utilizzato nella modalità Free Running Mode Edge-aligned.La generazione degli interrupts PWM dipende dalle modalità operative quindi dai bits PTMOD (Time

Base Mode) nel registro P1TCON (Time Base Control Register) e dai bits di PTOPS (Time Base OutputPostscaler) del registro P1TCON.In modalità Free Running un interrupt è generato quando il registro PWM P1TMR (Time Base Register)

viene resettato a 0 a causa del raggiungimento del valore impostato nel registro PTPER.I bits del postscaler sono utilizzati in questa modalità per ridurre la frequenza degli eventi di interrupt.

Per generare un’onda rettangolare, oltre al periodo – che definisce ogni quanti secondi il segnale vienegenerato mediante interrupt – bisogna generare un corretto duty cycle mediante la scrittura dell’appositovalore nel registro P1DCx.I registri di duty cycle sono 4, ognuno legato a una coppia di uscite PWMxH/L. Nel progetto di Marvin

sono utilizzati in primi tre registri di duty cycle dell’MCPWM1 cioè P1DC1, P1DC2 e P1DC3. Il valore scrittonel registro permette di generare un’onda PWM con opportuno duty cycle; infatti il segnale PWM èalto all’inizio del periodo, cioè quando P1TMR = 0, dopodiché esso verrà incrementato fino a raggiungereil valore contenuto nel registro P1DCx. Il segnale torna quindi basso e viene generato finché P1TMR nonraggiunge il valore di PTPER. A questo punto l’onda PWM è stata completamente generata e il ciclo siripete.

Figura 5.4.: Generazione dell’onda PWM

Una caratteristica interessante è la possibilità di cambiare il valore di duty cycle “on-the-fly” impo-stando il bit IUE = 1 nel registro PWM1CON2. Tale impostazione ha l’effetto di eliminare l’attesa che ilregistro P1TMR raggiunga il valore di PTPER, e permette immediati aggiornamenti della larghezza dell’ondarettangolare. Abilitando questa feature si va incontro a tre possibili casi:

52


Figura 5.5.: Modifica del valore di duty cycle “on-the-fly”

1. se l’uscita PWM è attiva nel momento in cui in nuovo valore di duty cycle è scritto nel corrispondenteregistro ed il nuovo valore è maggiore rispetto al corrente valore del registro P1TMR allora la larghezzadell’onda rettangolare è estesa.

2. se l’uscita PWM è attiva nel momento in cui in nuovo valore di duty cycle è scritto nel corrispondenteregistro ed il nuovo valore è minore rispetto al corrente valore del registro P1TMR allora la larghezzadell’onda rettangolare è diminuita.

3. se l’uscita PWM non è attiva nel momento in cui il nuovo valore di duty cycle è scritto nel cor-rispondente registro, ed il nuovo valore è maggiore rispetto al corrente valore del registro P1TMRallora l’uscita del PWM viene immediatamente attivata e rimane attiva per il valore impostato nelregistro duty cycle.

Il controllo dei servomotori viene fatto basandosi su un periodo di 20 ms. Questo valore è proporzionalealla frequenza di funzionamento del dsPIC, Fc per cui è necessario imporre questa frequenza in base alleconsiderazioni precedenti.Affinché sia generato un segnale periodico con periodo di 20 ms, il registro PTPER associato alla periferica

PWM deve contenere un valore in bit opportuno. La formula che permette di calcolare questo valore è:

PTPER = FcFpwm · prescaler

− 1 (5.5)

Il prescaler serve a ridurre il valore calcolato quando Fc � Fpwm. Poiché il registro PTPER è compostoda 15 bit il massimo valore rappresentabile è 215 − 1 = 32767.La frequenza della PWM richiesta in questo progetto è di 50 Hz. Sappiamo infatti che il periodo

richiesto è di 20 ms, per cui la frequenza può essere determinata semplicemente come:

Fpwm = 1T

= 120 · 10−3 = 50Hz (5.6)

Risulta evidente che Fc � Fpwm, quindi è necessario un prescaler elevato. Si utilizzerà il prescalermassimo, con rapporto 1:64, in questo modo:

PTPER = 40 · 106

50 · 64 − 1 = 12499 (5.7)

Non rimane ora che impostare il valore corretto per il duty cycle, in modo da ottenere l’onda PWMdesiderata. Tale valore può essere ricavato in base ad un semplice ragionamento basato sulle proporzioni.

53


Infatti quello che si vuole ottenere è un segnale di periodo T che sia “alto” per un tempo pari a T − on.Allora è sufficiente impostare la seguente relazione:

T − on : T = P1DCx2 : PTPER (5.8)

da cui si ricava:

P1DCx = 2 · PTPER · T − onT

(5.9)

Per i tre valori limite dei servomotori scelti per Marvin, si ha dunque che:

• +90° corrisponde ad un T-on di 0.6 ms, ovvero P1DCx = 2 · 12499·0.620 = 750

• 0° corrisponde ad un T-on di 1.5 ms, ovvero P1DCx = 2 · 12499·1.520 = 1875

• -90° corrisponde ad un T-on di 2.4 ms, ovvero P1DCx = 2 · 12499·2.420 = 3000

La formula 5.9 è stata inserita nella libreria Servo.h. In questo modo è la Flex che, dato un T-on,calcola il valore di P1DCx e muove di conseguenza i motori.

5.3. RTOS ERIKA EnterpriseERIKA (Embedded Real tIme Kernel Architecture) è un kernel di piccole dimensioni con piene funzio-

nalità real-time, progettato per supportare applicazioni embedded su piccoli microcontrollori con scarsapotenza di calcolo e memoria limitata, ma caratterizzate da vincoli temporali. È distribuito in doppialicenza (commerciale e GNU GPL con linking exception) da Evidence srl, uno spin-off del laboratorioReTiS della Scuola Superiore Sant’Anna di Pisa. L’architettura del kernel ERIKA comprende due partiprincipali: il Kernel Layer e l’Hardware Abstraction Layer (HAL).Il Kernel Layer contiene un’insieme di moduli che implementano la gestione dei task e le varie strategie

di schedulazione real-time disponibili (FP ed EDF). Questo livello esporta per il livello di applicazioneun insieme di API RTOS per la gestione di Task, Alarms, Resources e Semaphores. L’HAL racchiude laparte di codice dipendente dall’hardware, ad esempio la gestione delle interruzioni e i cambi di contesto.Uno degli aspetti interessanti di ERIKA è il supporto alle API definite dallo standard OSEK (Offene

Systeme und deren Schnittstellen für die Elektronik im Kraft-fahrzeug - open system and the correspon-ding interfaces for automotive electronics), un progetto congiunto di alcune industrie automobilisticheper lo sviluppo di sistemi di controllo distribuiti nei veicoli. Il consorzio prende il nome di OSEK/VDX(VDX sta per Vehicle Distributed eXecutive) poiché si occupa della definizione di un insieme di API persistemi operativi real-time (OSEK) e di sistemi per la gestione di rete (VDX).Gli standard OSEK/VDX sono orientati ad ottenere: portabilità e riutilizzo delle applicazioni soft-

ware, scalabilità tra differenti requisiti per adattarsi alle particolari esigenze dell’applicazione (usandole conformance classes), configurazione del sistema attraverso il linguaggio OIL (OSEK ImplementationLanguage), allocazione statica delle risorse del sistema durante la compilazione dell’applicazione.ERIKA RTOS ha un footprint massimo di 4 Kb ed ha a disposizione diversi Kernel che vengono

tipicamente divisi in:

• Kernels standard OSEK/VDX, attraverso le Conformance Classes BCC1, BCC2, ECC1 ed ECC2

• Kernels non starndard FP, EDF e FRSH

Le differenze principali tra queste tipologie di kernel sono le API che vengono implementate: i kernelsnon standard utilizzano solo un insieme ridotto di API per consentire il multithreading mentre quelli cheimplementano le Conformance Class aggiungono all’insieme di API minimali altre funzionalità tipichedello standard OSEK.

54


È possibile fare porting da un tipo di kernel non standard ad uno OSEK e viceversa. Evidence haprovveduto ha stilare un documento di compatibilità relativamente al porting di applicazioni. [3]Le Conformance Classes BCC1, BCC2, ECC1 ed ECC2 servono per implementare i diversi comporta-

menti del sistema; le classi di conformità BCC1 e BCC2 utilizzano meno spazio possibile e sono le piùindicate per realizzare piccoli sistemi a tasks concorrenti anche per la possibilità di avere la condivisionedello stack tra i vari task.Le classi di conformità ECC1 e ECC2 sono scelte per supportare task più complessi in quanto sup-

portano le primitive di sincronizzazione e per questo ogni task deve essere dotato di uno stack separato.Ovviamente ciò peggiora il footprint in memoria del sistema.

BCC1Fornisce i Task Base, essi non hanno primitive bloccanti, possono terminare ed essere prelazionati,

possono condividere lo stack e può esserci una sola attivazione del task.

BCC2Sono uguali ai BCC1 ma supportano attivazioni multiple. Per creare questo tipo di Tasks va specificato

nel Kernel che si utilizza la BCC2 con l’istruzioneOS myOS {

KERNEL_TYPE = BCC2;}

e le attivazione multiple sono specificate nell’oggetto Task, come da esempioTASK Task {

ACTIVATION = 4;};

ECC1Forniscono i Task Estesi che a differenza dei Tasks Base supportano gli Eventi e i Counting Semaphores

per effettuare sincronizzazioni. ECC1 non supporta le attivazioni multiple.OS myOS {

KERNEL_TYPE = ECC1;}

Mentre gli eventi sono così definitiTASK Task {

PRIORITY = 0x01;ACTIVATION = 1;SCHEDULE = FULL;AUTOSTART = TRUE;STACK = PRIVATE {

SYS_SIZE = 1024;};EVENT = " TimerEvent ";EVENT = " ButtonEvent ";

};

EVENT TimerEvent { MASK = AUTO; };EVENT ButtonEvent { MASK = AUTO; };

È necessario comunque definire nel file .c la maschera EventMaskType mask;

55


ECC2ECC2 è simile a ECC1 con la differenza che sono supportate le attivazioni multiple

OS myOS {KERNEL_TYPE = ECC2;

}

TASK Task {ACTIVATION = 4;

};

Nel documento [4] è possibile trovare la documentazione delle API di ERIKA, mentre per l’implemen-tazione su microcontrollore e scrittura del file OIL si rimanda a [5].Il Kernel Type può essere anche impostato a FP, EDF o FRSH, che sono trattate come Conformance

Classes non appartenenti allo standard OSEK/VDX:

• Fixed Priority (FP): supporta il multithreading a priorità fissa con più di 1 task per ogni priorità,e con più di una pending activation per ogni task. In questa Conformance Class le risorse vengonogestite tramite Immediate Priority Ceiling.

• Earliest Deadline First(EDF): provvede al supporto per lo scheduler EDF. Ogni task ha una pro-pria deadline relativa che viene valutata al momento dell’attivazione del task. La deadline vienecodificata usando un circular timer. In questa Conformance Class le risorse vengono gestite tramiteStack Resource Protocol (SRP).

• Frescor Scheduler (FRSH): include l’implementazione di uno scheduler EDF e, a livello superiore,l’implementazione dello IRIS scheduler.

Le API disponibili sono elencate in fig. 5.6, per le specifiche delle varie primitive si rimanda al manualedi ERIKA [4]

56


Figura 5.6.: API del kernel Erika Enterprise

57


5.4. Implementazione dell’applicazione ERIKAMarvin utilizza solo una parte delle caratteristiche di ERIKA. L’applicazione istanzia un singolo task

periodico utilizzando attivamente gli oggetti Alarm, Counter e Task definiti nel file OIL:CPU mySystem {

OS myOs {EE_OPT = " DEBUG ";CPU_DATA = PIC30 {

APP_SRC = "code.c";MULTI_STACK = FALSE ;ICD2 = TRUE;

};MCU_DATA = PIC30 {

MODEL = PIC33FJ256MC710 ;};BOARD_DATA = EE_FLEX {

USELEDS = TRUE;};

KERNEL_TYPE = FP;};

}

L’oggetto CPU imposta le proprietà CPU_DATA e MCU_Data per funzionare con il dsPIC ed utilizzareil programmatore ICD2. APP_SRC indica quale file .c contiene il codice sorgente; in questo lavoro esso èchiamato semplicemente code.c. Il kernel utilizzato è l’FP.TASK TaskSend {

PRIORITY = 1;STACK = SHARED ;SCHEDULE = FULL;

};

L’oggetto TASK istanzia TaskSend che rappresenta il task periodico. Come si può notare la periodicitànon è espressa attraverso istruzioni nell’oggetto TASK: essa infatti è data dall’oggetto ALARM:COUNTER myCounter ;ALARM AlarmSend {

COUNTER = " myCounter ";ACTION = ACTIVATETASK { TASK = " TaskSend "; };

};

L’ALARM è legato ad un oggetto COUNTER (contatore), che dopo un determinato numero di tick richiamal’oggetto ALARM in cui è specificata una ACTION che, per la nostra applicazione, corrisponde all’attivazionedel task TaskSend.Una seconda versione più complessa del Kernel, studiata e non testata in questo progetto, prevede

un utilizzo più intelligente delle potenzialità di ERIKA. Nell’applicazione sono implementati 4 Taskperiodici, dove TaskRead ha il compito di effettuare la lettura dei dati da Arduino e gli altri 3 tasks,ognuno associato ad un asse, hanno il compito di eseguire le azioni di movimento4. Di seguito il file OILassociato all’applicazione appena descritta.CPU mySystem {

OS myOs {EE_OPT = " DEBUG ";CPU_DATA = PIC30 {

APP_SRC = "code.c";MULTI_STACK = FALSE ;ICD2 = TRUE;

4Vedi code.c in Source > Flex Full > Marvin PID-flex Task sperimentale

58


};MCU_DATA = PIC30 {

MODEL = PIC33FJ256MC710 ;};BOARD_DATA = EE_FLEX {

TYPE = DEMO {OPTIONS = ALL;

};};KERNEL_TYPE = FP;

};

TASK TaskRead {PRIORITY = 1;// A high number corresponds to a high prioritySTACK = SHARED ;ACTIVATION = 1;SCHEDULE = FULL;RESOURCE = " Motor_X ";RESOURCE = " Motor_Y ";RESOURCE = " Motor_Z ";

};

TASK TaskMotor_X {PRIORITY = 1;ACTIVATION = 1;STACK = SHARED ;SCHEDULE = FULL;RESOURCE = " Motor_X ";

};

TASK TaskMotor_Y {PRIORITY = 1;ACTIVATION = 1;STACK = SHARED ;SCHEDULE = FULL;RESOURCE = " Motor_Y ";

};

TASK TaskMotor_Z {PRIORITY = 1;ACTIVATION = 1;STACK = SHARED ;SCHEDULE = FULL;RESOURCE = " Motor_Z ";

};

COUNTER CounterRead ;COUNTER Counter_X ;COUNTER Counter_Y ;COUNTER Counter_Z ;

ALARM Alarm_Read {COUNTER = " CounterRead ";ACTION = ACTIVATETASK { TASK = " TaskRead "; };

};

ALARM Alarm_onX {COUNTER = " Counter_X ";ACTION = ACTIVATETASK { TASK = " TaskMotor_X "; };

};

59


ALARM Alarm_onY {COUNTER = " Counter_Y ";ACTION = ACTIVATETASK { TASK = " TaskMotor_Y "; };

};

ALARM Alarm_onZ {COUNTER = " Counter_Z ";ACTION = ACTIVATETASK { TASK = " TaskMotor_Z "; };

};

RESOURCE Motor_X { RESOURCEPROPERTY = STANDARD ; };RESOURCE Motor_Y { RESOURCEPROPERTY = STANDARD ; };RESOURCE Motor_Z { RESOURCEPROPERTY = STANDARD ; };

}

L’oggetto Resource è utilizzato per le sezioni critiche ovvero semafori binari tali che il task di letturadei dati risulti avere priorità alta e non essere prelazionato dagli altri tasks se i dati di movimento nonsono disponibili; esso rilascerà le risorse sbloccando i task solo dopo la corretta ricezione da Arduino.Gli oggetti Resources sono definiti dallo statement:

RESOURCE name { RESOURCEPROPERTY = STANDARD ; };

e vanno incluse nell’oggetto Task che le utilizzerà.Il concetto di risorsa critica è fondamentale per proteggere la variabile condivisa arduinoData in

modo che i task dei motori non accedano alla variabile per leggere i dati se essa non è stata riempitaprecedentemente dal task di lettura.

5.5. Firmware ArduinoIl firmware realizzato per Arduino ricopre il ruolo di hub per lo scambio di informazioni dal livello di

Comando a quello di Controllo. Per questo motivo è stato progettato secondo una logica ad interrupt.Un firmware Arduino si compone di due funzioni: void setup(), in cui vanno inserite le inizializzazioni

o le azioni da eseguire una sola volta, e void loop() che contiene le azioni da svolgere ciclicamente. Questedue funzioni, in fase di compilazione, verranno inserite in una tipica struttura di un programma C, in cuicompare un main che chiama le funzioni sopra citate.Il firmware realizzato per questa tesi effettua in setup le inizializzazioni dei led, delle porte seriali

Serial e Serial1 e dell’ADB subsystemvoid setup (){

// Set pins as output used for LEDpinMode (22 , OUTPUT );pinMode (24 , OUTPUT );

// Init serial portSerial . begin (57600) ; // Computer & serial monitor DEBUG ComunicationSerial1 . begin (115200) ; // PIN 18 & 19, FLEX BAUDRATE : 115200

// Init the ADB subsystem .ADB :: init ();

// Open an ADB stream to the phone ’s shell . Auto - reconnect .connection = ADB :: addConnection ("tcp :4568 ", true , adbEventHandler );

}

60


loop() è composta dall’unica istruzione di polling dell’ADB subsystem in quanto la ricezione deidati sulla porta seriale è gestita da Arduino attraverso gli interrupt. Ogni volta il cui la periferica dicomunicazione riceve dati, automaticamente effettua una callback a serialEvent1(), funzione che sioccupa di gestire tale interruzione.void loop (){

// serialEvent1 () is called in automatic , so// in the loop the serialEvent1 is not present .

// Poll the ADB subsystem .ADB :: poll ();

}

Risulta quindi importante definire bene come interpretare e smistare i dati in arrivo su Serial1. Ilprotocollo di comunicazione suddivide i tipi di messaggi in due categorie: Request Message e DebugMessage. I Request Message sono la parte fondamentale del protocollo di comunicazione attraverso iquali Arduino risponde alla Flex inviando i dati ricevuti da Android; i Debug Message, invece, servonoper utilizzare Arduino come strumento di Debug per la Flex attraverso il Serial Monitor presente nell’IDE.I messaggi di debug sono divisi in due tipi: stringhe e numeri.void serialEvent1 (){

int i=0, j =0;byte msg [100];int msgNumber =0;byte messageType =0 x00;unsigned long int number ;byte fine =0 x00;

// A request data message// Arduino sends the last stored command ( direction ) to Flexif( Serial1 . read () == 0x7F){

Serial1 . write (0 x0A);if(MODE != 0x0C){

Serial1 . write (( byte ) direction );}else{

for(j=0;j <15;j++) Serial1 . write ( directions [j]);}

// Uses the GREEN led to notify the reception of the messagedigitalWrite (24 , HIGH);delay (10);digitalWrite (24 , LOW);delay (10);

}// A debug message// Arduino write the number or the string received from Flex to the serial monitorelse if( Serial1 . read () == 0xA7) {

/* HEADER PROCESSING */// Pop from the UART queque the lengh of payload that is in the position 1 of RX

buffermsgNumber = Serial1 . read ();// Pop from the UART queque the code command that is in the position 2 of RX

buffermessageType = Serial1 . read ();

61


/* PAYLOAD PROCESSING */for(i=0;i < msgNumber ;i++){

msg[i]= Serial1 . read ();}// A String from Flex: processing ASCII byte valuesif ( messageType == 0xBB){

Serial . println ("--STRING MESSAGE --");for(i=0;i < msgNumber ;i++) Serial . write (msg[i]);Serial . println (" ");

}// A number from Flex: processing DECIMAL valueselse if( messageType == 0xDD){

Serial . println ("--NUMBER MESSAGE --");// Take the integer value back from the 4 byte array from Flexnumber = ( (msg [0] << 24) + (msg [1] << 16) + (msg [2] << 8) + (msg [3] ) );Serial . println (number ,DEC);

}}

}

Per inviare messaggi di Debug dalla Flex verso Arduino bisogna utilizzare la libreria serialConsole.h.Una tipica impostazione per fare questo è:SendStringReply ("\ nTesto \n",Arduino ,NoReply ,false ,false , UART1 );

oppure:SendNumReply (1234 , Arduino ,NoReply ,false ,false , UART1 );

dove si è ipotizzato che Arduino sia collegato alla UART1 della Flex.

5.6. Applicazioni AndroidLe applicazioni realizzate per lo smartphone sono due. Seppur condividano molte funzionalità di

base, esse differiscono nella classe ER1Direction. Questa classe, infatti, è predisposta come punto finaledell’elaborazione dei dati acquisiti per mezzo delle altre classi.Escludendo le classi AbstrasctServerListner, Server, ServerListner e Client che implementano

la Microbridge ADB, si ha:

• FdActivity: si occupa di impostare l’applicazione per tutti gli stati richiesti da Android

• FdView: estende CvClientView ed è il cuore dell’applicazione, si occupa principalmente di gestire ithread della comunicazione wifi e di effettuare il riconoscimento dei volti tramite l’algoritmo LBPed il metodo per scegliere il volto dominante sulla scena.

• CvClientView: contiene il thread che operativamente utilizza l’algoritmo per il riconoscimento voltie il calcolo degli FPS tramite la classe FpsMeter.

• FpsMeter: contiene i metodi per calcolare il numero di Frame per Secondo (FPS) cioè la frequenzadi cattura delle immagini attraverso la fotocamera.

5.6.1. Caratteristiche comuni tra le due applicazioniAndroid Manifest

Il Manifest elenca i componenti del sistema che vengono utilizzati dall’applicazione; per esempio, se unaapk richiede la connessione alla rete, lo notifica nel Manifest e, qualora la connessione non sia disponibile,l’applicazione verrà bloccata a run-time.

62


<?xml version ="1.0" encoding ="utf -8"?><manifest xmlns:android =" http: // schemas . android .com/apk/res/ android " package ="it. univpm .

dii. marvinPID " android:versionCode ="1" android:versionName ="1.0"><uses - permission android:name =" android . permission . INTERNET " />

<supports - screensandroid:resizeable ="true" android:smallScreens ="true"android:normalScreens ="true" android:largeScreens ="true" android:anyDensity ="true" />

<application android:label =" @string / app_name " android:icon =" @drawable /icon"><activity android:name ="it. univpm .dii. marvinPID . FdActivity " android:label =" @string /

app_name " android:screenOrientation =" landscape " android:configChanges ="keyboardHidden | orientation "><intent - filter >

<action android:name =" android . intent . action .MAIN" /><category android:name =" android . intent . category . LAUNCHER " />

</intent - filter ></ activity ><menu xmlns:android =" http: // schemas . android .com/apk/res/ android ">

<item android:id ="@+id/ serverIP " android:title =" @string / ServerIP " /><item android:id ="@+id/help" android:title =" @string /help" />

</menu ></ application >

<uses -sdk android:minSdkVersion ="10" />

<uses - permission android:name =" android . permission . CAMERA "/><uses - feature android:name =" android . hardware . camera " /><uses - feature android:name =" android . hardware . camera . autofocus " />

</ manifest >

In questo manifest vengono riportati l’orientamento dell’applicazione, cioè Landscape, e i permessi dicui necessita, cioè l’accesso alla fotocamera e al modulo wifi.

Comunicazione USB

La logica di comunicazione è contenuta nelle classi che realizzano il modello client-server attraversol’ADB, l’obiettivo è stato utilizzare le API messe a disposizione all’interno dell’applicazione sostituendolea quelle dell’Open Accessory.Nella FdActivity viene instanziato l’oggetto mServer come pubblico e statico attraverso l’istruzione

public static Server mServer = null;

Nel metodo di Android onCreate(), che viene chiamato dal sistema operativo al lancio dell’applicazio-ne, mServer viene associato ad un oggetto Server che comunica sulla porta 4568 dopodichè esso vieneavviato attraverso il metodo start()

mServer = new Server (4568) ; // Use ADK portmServer . start ();

Tramite comunicazione USB possono essere inviati solo byte e questo avviene attraverso il metodomServer.send(), definito nella classe Server:public void send(byte [] data) throws IOException{

for ( Client client : clients )client .send(data);

}

il metodo richiama il metodo send della classe Client:

63


public void send(byte [] data) throws IOException{

try {output . write (data);output . flush ();

} catch ( SocketException ex){

// Broken socket , disconnectclose ();server . disconnectClient (this);

}}

Elaborazione Video

Le funzionalità del sistema di visione sono rese disponibili dalla libreria OpenCV appositamente com-pilata per il sistema operativo Android. La classe FdView è la classe centrale dell’applicazione e cometale viene creata all’avvio; il metodo processFrame() contiene l’algoritmo per l’elaborazione e l’estrazionedi un volto da una scena@Overrideprotected Bitmap processFrame ( VideoCapture capture ) {

capture . retrieve (mRgba , Highgui . CV_CAP_ANDROID_COLOR_FRAME_RGBA );capture . retrieve (mGray , Highgui . CV_CAP_ANDROID_GREY_FRAME );

if ( mCascade != null) {// clear previous detected faces arrayfaces . clear ();// equalize gray image histogramImgproc . equalizeHist (mGray , mGray );// invoke face detection algorithm , starting from a face dimension of 90 x90mCascade . detectMultiScale (mGray , faces , 1.3 , 3, 0, DEFSIZE );

// search each face on history face detected arrayfor (Rect r : faces ){

add=true;for ( CFace a : hFaces ){

if (a. updatePos (r)) {add= false ;break ;

}}// face not found into history array , new faceif (add) hFaces .add(new CFace (r));// print a green rectangle around each faceif ( develop ) Core. rectangle (mRgba , r.tl () , r.br () , new Scalar (0, 255 , 0, 255)

, 1);}

// initialize array variablesnewFace =null;maxT =0;hcopy . clear ();

// for each faces into history faces array , removes old face (not yet detected )and search dominant face (most time present )

for ( CFace a: hFaces ){if (a. aging ()){

hcopy .add(a);} else if (a. findBest ()) {

64


newFace =a;}

}hFaces . removeAll ( hcopy );

// if a face was detectedif ( newFace != null){

// draws a red rectangle around faceif ( develop ) Core. rectangle (mRgba , newFace .pos.tl () , newFace .pos.br () , new

Scalar (255 ,0 ,0 ,255) ,2);if ( dominantFace == null || newFace .id != dominantFace .id || repeat > REPEAT_LIMIT )

{// send face to server when first one detected or new face or need to re -

senddominantFace = newFace ;repeat =0;try{

// interrupt server response wait threadwaitResp = false ;// create bitmap image to senddominant = Bitmap . createBitmap ( mRgba .cols () ,mRgba .rows () ,Bitmap . Config .

ARGB_8888 );Utils . matToBitmap (mRgba , dominant );dominant = Bitmap . createBitmap (dominant , newFace .pos.x, newFace .pos.y,

newFace .pos.width , newFace .pos. height );faceCheck ="";sendImg =true;

} catch ( Exception e) {Log.e(TAG ," bitmap error "+e. toString ());

}Log.i(TAG , "new Face ");

}else if ( newFace .id == dominantFace .id && repeat <= REPEAT_LIMIT ){

// on same dominant face , count time until re -send to serverrepeat ++;

}}

else {// no dominant faces , reset variablesdominantFace =null;dominant =null;sendImg = false ;waitResp = false ;repeat =0;

}}

if ( develop ){// create image to send back to callerbmp = Bitmap . createBitmap ( mRgba .cols () , mRgba .rows () , Bitmap . Config . ARGB_8888

);if ( Utils . matToBitmap (mRgba , bmp))

return bmp;bmp. recycle ();

}return null;

}

Il video catturato con le istruzioni alle righe 2 e 3, viene elaborato equalizzandone l’istogramma, quindiviene eseguito l’algoritmo di face-detection tramite l’istruzione di riga 10. La scansione ricerca i volticon una dimensione minima di 110x110 pixel; ad ogni iterazione la dimensione viene incrementata di

65


un fattore 1,3. La variabile faces contiene la lista delle posizioni di tutti i volti individuati nel framecorrente; il passo successivo è quello di cercare ogni volto individuato nei frame precedenti, aggiornandonele informazioni per mezzo del metodo updatePos(); il vettore hFaces contiene le informazioni relativeai volti individuati nel frame attuale e in quelli precedenti. Il tipo di dati CFace è stato creato permemorizzare le informazioni relative ai volti individuati, ovvero la posizione e il tempo di permanenzasulla scena.Dopo aver aggiornato lo storico con i nuovi volti individuati, questo viene scansionato alla ricerca del

volto dominante, eliminando i volti non più presenti nella scena.L’operazione di ricerca del volto dominante si basa sul tempo di permanenza nella scena; ogni volto

individuato viene ricercato nello storico: se la posizione attuale del vertice superiore sinistro è in unintorno della posizione precedente, i due volti confrontati sono marcati come identici (vedi fig. 5.7)

Figura 5.7.: Algoritmo di individuazione di un volto

Il metodo updatePos() della classe CFace si occupa di confrontare le posizioni dei due volti, restituendoil valore false se non sono compatibili, altrimenti provvede ad aggiornare la posizione corrente e il tempodi permanenza. La variabile noFace viene utilizzata per eliminare, con un metodo aging, i volti non piùpresenti nella scena per un certo numero di frame consecutivi. Nella selezione del volto dominante, conil metodo findBest si cerca il volto con il valore massimo della variabile time.

5.6.2. Differenze tra le due applicazioni AndroidMarvin Grid View

Nell’applicazione “Marvin Grid View” la classe ER1Direction utilizza la Grid View, quindi calcola ilmovimento da imporre al robot in base alla posizione e rispetto alle aree ben definite.Il listato successivo riporta il modo in cui le aree sono definite il metodo init() che produce la

suddivisione nel momento in cui un’istanza ER1Direction viene creata .public void init(int width , int height ){

this. heigh = height ;this. width = width ;output = "";direction = cSTOP ;paint =new Paint ();

66


paint . setColor ( Color .RED);paint . setTextSize (20);limitLeft = width /4;limitRight = limitLeft *3;limitTop = height /4;limitBottom = limitTop *3;

}

public void updateLimits (int width , int height ){this. heigh = height ;this. width = width ;limitLeft = width /4;limitRight = limitLeft *3;limitTop = height /4;limitBottom = limitTop *3;

}

Il seguente listato, invece, contiene il metodo calc() che elabora la posizione ricevuta da parametro estabilisce il comando da inviare al robot.Esso controlla per prima cosa l’altezza del volto dominante; nel caso fosse maggiore di quella massima,

160px, viene inviato il comando di muovere il robot all’indietro per allontanarsi dal soggetto. Altrimentise è minore di 120px, il robot si avvicinerà al soggetto. Questo per mantenere il volto del soggetto nétroppo vicino né troppo distante dal robot.Viene controllata la posizione rispetto alle zone prestabilite, quindi sono inviati i comandi per mantenere

il volto nella zona centrale del frame.public void calc(Rect a){

if (a!= null){if (a.height >160) {

direction = cREVERSE ;output =" REVERSE ";startBehavior = DEFAULT_START_DURATION ;

}else if(a.height <120) {

direction = cFORWARD ;output =" FORWARD ";startBehavior = DEFAULT_START_DURATION ;

}else{

if (a.tl ().x< limitLeft ){output ="LEFT";direction = cLEFT ;researchCommand = cLEFT ;researchMovement ="LEFT RESEARCH ...";startBehavior = DEFAULT_START_DURATION ;

} else if (a.br ().x> limitRight ){output =" RIGHT ";direction = cRIGHT ;researchCommand = cRIGHT ;researchMovement =" RIGHT RESEARCH ...";startBehavior = DEFAULT_START_DURATION ;

} else if (a.tl ().y< limitTop ){output ="UP";direction =cUP;startBehavior = DEFAULT_START_DURATION ;

} else if (a.br ().y> limitBottom ){output ="DOWN";direction = cDOWN ;startBehavior = DEFAULT_START_DURATION ;

67


} else {output ="STOP";direction = cSTOP ;startBehavior = DEFAULT_START_DURATION ;

}}

} else {/* USE THIS SE NON HAI BISOGNO DELLA RICERCA /direction = cSTOP ;output =" STOP ";*//* ricerca di un volto dopo n iterazioni */startBehavior --;if( startBehavior %10 == 0)researchMovement ="THE RESEARCH WILL BEGIN IN " + startBehavior +" ITER ...";

if( startBehavior <= 0) // BEGIN THE RESEARCH TO THE RIGHT SIDE{ // this will last until the endBehavior reach 0

researchMovement =" RIGHT RESEARCH ...";researchCommand = cRIGHT ;endBehavior --;

}if( endBehavior <= 0){ // Now the robot stops

researchMovement =" RESEARCH STOPPED ";researchCommand = cSTOP ;// begin new cycle of research behaviorstartBehavior = DEFAULT_START_DURATION ;endBehavior = DEFAULT_END_DURATION ;

}output = researchMovement ;direction = researchCommand ;

}try{

FdActivity . mServer .send(new byte []{0 x0F , direction });} catch ( Exception e){ }

}

Si nota come se a è null viene avviato l’algoritmo di ricerca.In ogni caso il comando di movimento viene inviato attraverso l’mServer verso Arduino nel blocco

try/catch.La direzione che il robot deve seguire è calcolata in base alla posizione dei vertici evidenziati: viene

utilizzato il vertice inferiore destro (a.br) quando il volto si trova nella zona destra o inferiore del frame,in tutte le altre situazioni si usa il vertice superiore sinistro(a.tl).I comandi sono costanti di tipo byte:

public final static byte cSTOP = 0x00;public final static byte cFORWARD = 0x01;public final static byte cREVERSE = 0x02;public final static byte cLEFT = 0x03;public final static byte cRIGHT = 0x04;public final static byte cUP = 0x05;public final static byte cDOWN = 0x06;

essi vengono inviati tramite il metodo send() di mServer

FdActivity . mServer .send(new byte []{0 x0F , direction });

che prende in ingresso un array di byte, creato al momento dell’invio inserendo due byte. In questocaso si sta usando, dunque, il protocollo semplificato.Dal lato Flex invece essi vengono gestiti dal TaskSend e da uno switch:

68


Arduino_Data_Request (& arduinoData [0] ,2 ,1);if( arduinoData [0] == 0x0A) ledBlink (25 ,1 ,100);

switch ( arduinoData [1]) {case 0x00: // stop

Servo_Neutral (DX);Servo_Neutral (SX);break ;

case 0x01: // forwardServo_minus90 (DX);Servo_plus90 (SX);break ;

case 0x02: // reverseServo_plus90 (DX);Servo_minus90 (SX);break ;

case 0x03: // leftServo_minus90 (DX);Servo_minus90 (SX);break ;

case 0x04: // rightServo_plus90 (DX);Servo_plus90 (SX);break ;

case 0x05: // upServo_Neutral (DX);Servo_Neutral (SX);Servo_Move (HEAD , DEFAULT_INCREMENT ,20);break ;

case 0x06: // downServo_Neutral (DX);Servo_Neutral (SX);Servo_Move (HEAD ,- DEFAULT_INCREMENT ,20);break ;

}

L’istruzione Servo_plus90(motor) è equivalente a Servo_Set_Position(motor,2.4,20), mentre Servo_minus90(motor)è equivalente alla Servo_Set_Position(motor,0.6,20).La visualizzazione a griglia viene disegnata a schermo dal metodo draw():

public void draw( Canvas canvas , float offsetx , float offsety ) {canvas . drawLine ( limitLeft +offsetx , offsety , limitLeft +offsetx , totH+offsety , paint );canvas . drawLine ( limitRight +offsetx , offsety , limitRight +offsetx , totH+offsety , paint )

;canvas . drawLine ( limitLeft +offsetx , limitTop +offsety , limitRight +offsetx , limitTop +

offsety , paint );canvas . drawLine ( limitLeft +offsetx , limitBottom +offsety , limitRight +offsetx ,

limitBottom +offsety , paint );canvas . drawText ( output +" "+ FdView .faceCheck , 20 + offsetx , 90, paint );

}

Marvin PID

A differenza dell’applicazione precedente, mutuata in buona parte dal lavoro su AndroEEBot e quindiconsiderabile come Demo per l’utilizzo di singoli comandi alla parte hardware, questa applicazione è stataprogettata per funzionare attraverso la legge di controllo PID.Non vengono utilizzati dei comandi di spostamento: è l’implementazione digitale del controllo che

impone il giusto movimento al robot, attraverso gli errori calcolati sugli assi X, Y, Z affinché il volto siasempre mantenuto al centro del frame.

69


Per errore si intende la differenza tra un set-point -cioè il riferimento da raggiungere- e la posizioneattuale.La fase di inizializzazione della classe ER1Direction è:

public void init(int width , int height ){this. heigh = height ;this. width = width ;output = "";paint =new Paint ();paint . setColor ( Color .RED);paint . setTextSize (20);paintRECT =new Paint ();paintRECT . setColor ( Color .RED);paintRECT . setStyle ( Paint . Style . STROKE );

}

public void updateLimits (int width , int height ){this. heigh = height ;this. width = width ;

}

Qui vengono recuperati l’altezza e la larghezza totali del frame da elaborare. Segue quindi una partedi calcoli per ricavare gli errori sui tre assi e convertirli prima da float a interi attraverso un metododella classe Float, e successivamente suddividendoli in 4 byte per poter essere inviati dall’mServer versoArduino.public void calc(Rect a, float offsetx , float offsety ){

if (a!= null){output ="PID";data [0]=0 x0C;

coordX = ( float ) ((a.tl ().x)+(a. width /2))+ offsetx ;coordY = ( float ) ((a.tl ().y)+(a. height /2))+ offsety ;

ErrorX =( int) (( width /2) -(a.tl ().x+(a. width /2)));ErrorY =( int) (( heigh /2) -(a.tl ().y+(a. height /2)));ErrorZ =( int) (( SetPoint_onZ ) -(a. height ));

// USED to decide the direction of the robot : 0-> UP 1->DOWNif( ErrorY > 0) Ydirection =0;else Ydirection =1;

// USED to decide the direction of the robot : 1-> positive (LEFT) 0-> negative (RIGHT )

if( ErrorX > 0) Xdirection =1;else Xdirection =0;

// USED to decide the direction of the robot : 0-> positive ( FORWARD ) 1-> negative (BACKWARD )

if( ErrorZ > 0) Zdirection =0; //else Zdirection =1;

// Now i take the absolute values of errorsErrorY =Math.abs( ErrorY );ErrorX =Math.abs( ErrorX );ErrorZ =Math.abs( ErrorZ );

// Limita l’errore sull ’asse Z. Infatti il volto p u diventare molto grosso se// vicino alla telecamera e quindi l’errore p u crescere molto rispetto// in Forward rispetto a backward c o s allora unifico i valoriif( Zdirection ==1 && ErrorZ >=15) ErrorZ =14;

70


// inserisco delle tolleranze su ogni asseif( ErrorY <=4 ) ErrorY =0;else ErrorY =ErrorY -4; // else eliminate the acceptable zone

if( ErrorX <=10 ) ErrorX =0;else ErrorX =ErrorX -10; // else eliminate the acceptable zone

if( ErrorZ <=5 ) ErrorZ =0;else ErrorZ =ErrorZ -5; // else eliminate the acceptable zone

// Normalize the errors : ErrorK / ErrorMax_K con K={X,Y,Z}ErrorMax_X = (( width /2+ offsetx )/2);ErrorMax_Y = (( width /2+ offsetx )/2);ErrorMax_Z = 20;

ErrorX = ErrorX / ErrorMax_X ;ErrorY = ErrorY / ErrorMax_Y ;ErrorZ = ErrorZ / ErrorMax_Z ;

/* transfomate the FLOAT ErrorX ,ErrorY , ErroZ into a 4 bytes array and put them indata [] */

// java method that with some bit ’s masks convert the float bits to bit and// display bit with a int -> see official reference apiint Xint= Float . floatToIntBits ( ErrorX );int Yint= Float . floatToIntBits ( ErrorY );int Zint= Float . floatToIntBits ( ErrorZ );

// now i separate the int Xint into 4 bytes arraymsg [0] = (( Xint >> 24) & 0xFF) ;msg [1] = (( Xint >> 16) & 0xFF) ;msg [2] = (( Xint >> 8) & 0XFF);msg [3] = (( Xint & 0XFF));

// copy into the data [] array , that will be sended to flex , Xdirection and 0-3 msgbyte

data [1]=( byte) Xdirection ;data [2]=( byte)msg [0];data [3]=( byte)msg [1];data [4]=( byte)msg [2];data [5]=( byte)msg [3];

// now i separate the int Yint into 4 bytes arraymsg [0] = (( Yint >> 24) & 0xFF) ;msg [1] = (( Yint >> 16) & 0xFF) ;msg [2] = (( Yint >> 8) & 0XFF);msg [3] = (( Yint & 0XFF));

// copy into the data [] array , that will be sended to flex , Ydirection and 0-3 msgbyte

data [6]=( byte) Ydirection ;data [7]=( byte)msg [0];data [8]=( byte)msg [1];data [9]=( byte)msg [2];data [10]=( byte)msg [3];

// now i separate the int Yint into 4 bytes arraymsg [0] = (( Zint >> 24) & 0xFF) ;msg [1] = (( Zint >> 16) & 0xFF) ;msg [2] = (( Zint >> 8) & 0XFF);

71


msg [3] = (( Zint & 0XFF));

// copy into the data [] array , that will be sended to flex , Ydirection and 0-3 msgbyte

data [11]=( byte) Zdirection ;data [12]=( byte)msg [0];data [13]=( byte)msg [1];data [14]=( byte)msg [2];data [15]=( byte)msg [3];

// QUINDI QUELLO CHE HO ORA E’ UN ARRAY DI 4 BYTE CHE RAPPRESENTANO IL FLOAT// A QUESTO PUNTO LO INVIO AD ARDUINO CHE LO PASSA COSI ’ COM ’E’ ALLA FLEX// SUCCESSIVAMENTE LA FLEX RICOMPATTERA ’ QUESTI 4 BYTE IN UN FLOAT CON UN METODO// CHE PUOI VEDERE SUL CODICE DELLA FLEX

} else {int j=0;output ="PID STOPPED ";data [0] = 0x0C;// put the signal of stopdata [1] = 0x0B;data [2] = 0x12;data [3] = 0x0B;// for the drawErrorX = ErrorY = ErrorZ =0;coordX = coordY = -999.0f;

}try{

// Structure of data []: Control byte for Arduino [0] - X[1 -5] - Y[6 -11] - Z[12 -16]

FdActivity . mServer .send(data);} catch ( Exception e){ }

}

CoordX e CoordY calcolano le coordinate sull’asse X e Y, in pixel, della posizione del volto dominante.Esse verranno poi sottratte – senza offset – al set-point sui rispettivi assi per ottenere gli errori. I datiche rappresentano gli errori e i segni di ogni errore vengono inviati nel blocco try/catch.

(a) Set-point e calcolo delle coordinate (b) Calcolo degli errori sui tre assi di controllo

Figura 5.8.: Calcolo delle coordinate e degli errori nell’applicazione “Marvin PID”

Anche il metodo draw() si presenta differente in quanto non deve più mostrare un riferimento a “griglia”

72


ma visualizzare, per ogni asse, il set-point da raggiungere in maniera tale che il volto, rappresentato dalpunto in verde, sia sempre tenuto al centro del frame.public void draw( Canvas canvas , float offsetx , float offsety ) {

Paint punto =new Paint ();punto . setColor ( Color . GREEN );punto . setStrokeWidth (10);

// print a line parallel to the y-axiscanvas . drawLine ( width /2+ offsetx , 0+ offsety , width /2+ offsetx , heigh +offsety , paint );

// print a line parallel to the x-axiscanvas . drawLine (0+ offsetx , heigh /2+ offsety , width +offsetx , heigh /2+ offsety , paint );

// print the Acceptable zone where error = 0canvas . drawRect ( width /2+ offsetx -10 , heigh /2+ offsety -4, width /2+ offsetx +10 , heigh /2+

offsety +4, paintRECT );

canvas . drawText ( output +" "+ FdView .faceCheck , 20 + offsetx , 90, paint );

// print the point on Yif( coordX != -999.0f && coordY != -999.0f) {

canvas . drawPoint (coordX , coordY , punto );

canvas . drawText (" ERROR on X:"+ ErrorX , 20 + offsetx , 200 , paint );canvas . drawText (" ERROR on Y:"+ ErrorY , 20 + offsetx , 220 , paint );canvas . drawText (" ERROR on Z:"+ ErrorZ , 20 + offsetx , 240 , paint );

if( Xdirection == 0) stringaX = " RIGHT ";else stringaX = "LEFT";

if( Ydirection == 0) stringaY = "UP";else stringaY = "DOWN";

if( Zdirection == 0) stringaZ = " FORWARD ";else stringaZ = " BACKWARD ";

canvas . drawText (stringaX , 240+ offsetx , 200 , paint );canvas . drawText (stringaY , 240 + offsetx , 220 , paint );canvas . drawText (stringaZ , 240 + offsetx , 240 , paint );

}}

Il SetPoint dell’asse Z viene disegnato a schermo nella classe FdView dal codice// draw a blue line next to the left angle of the dominant face to visualize the set point

on Z (=130 px)CFace temp = new CFace ( newFace .pos);Point bo=temp.pos.tl ();bo.y +=130;// draws a blue line over the red rectange on the dominant faceif ( develop ) Core.line(mRgba , newFace .pos.tl () ,bo , new Scalar (0 ,0 ,255 ,255) , 4);

Dal lato Flex invece tale comportamento è gestito, sempre da TaskSend, in questo modoTASK( TaskSend ){

BYTE i=0;BYTE arduinoData [20];float DutyCycle =0;

EE_INT32 datoX [4];

73


BYTE Xsign ;float Error_on_X_axis =0;

EE_INT32 datoY [4];BYTE Ysign ;float Error_on_Y_axis =0;

EE_INT32 datoZ [4];BYTE Zsign ;float Error_on_Z_axis =0;

EE_led_on ();

Arduino_Data_Request (& arduinoData [0] ,16 , UART1 );

if( arduinoData [0] == 0x0A) ledBlink (25 ,1 ,100);

/* VERIFY IF THE PID IS ACTIVE OR NOT , THE PID IS NOT ACTIVE IF NO DOMINAT FACE ISFOUND ON THE SCREEN */

if( arduinoData [1] == 0x0B && arduinoData [2]== 0x12 && arduinoData [3] == 0x0B){

// So the PID is stopped then put DX e SX motors in a neutral position : stop themotor

Servo_Neutral (DX);Servo_Neutral (SX);

} else {// X AXIS : DIRECTIONS OF TURNING THE ROBOTXsign = arduinoData [1];for(i=0;i <4;i++) datoX [i]= arduinoData [i+2];

// Y AXIS -> "HEAD MOTOR " CORRESPONDING TO THE Y AXIS ON THE SMARTPHONEYsign = arduinoData [6];for(i=0;i <4;i++) datoY [i]= arduinoData [i+7];

// Z AXIS : DIRECTIONS FORN FORWARD / BACKWARD THE ROBOTZsign = arduinoData [11];for(i=0;i <4;i++) datoZ [i]= arduinoData [i +12];

/* Converting the 4 Byte to 1 Float */Error_on_X_axis = convert4ByteTO1Float ( datoX );Error_on_Y_axis = convert4ByteTO1Float ( datoY );Error_on_Z_axis = convert4ByteTO1Float ( datoZ );

// Seleziona quale movimento effettuare con i motori di propulsione , infattiessendone solo 2

// che vanno a gestire 4 movimenti (AVANTI ,DIETRO ,DX ,SX) essi devono essere "condivisi "

// la politica attuare la direzione in cui l’errore massimo in maniera daavere una

// compensazione media accettabile

if( Error_on_Z_axis >= Error_on_X_axis ) // based on absolute value{

/* Set the right sign of Z float used for the PI_pid controller , Ysign is usedin the P_pid function instead */

if( Zsign == 1) Error_on_Z_axis *= -1;

DutyCycle = P_pid_Z ( Error_on_Z_axis );

// attua il movimento Avanti o Indietro (in questo caso i due motori fannosempre la stessa cosa: sono coordinati )

74


Servo_Set_Position (2, DutyCycle ,20); // motore DX

// find the opposite duty cyclefloat Opposite_DutyCycle =map(DutyCycle ,0.6 ,2.4 ,2.4 ,0.6);

Servo_Set_Position (3, Opposite_DutyCycle ,20);} else {

/* Set the right sign of X float used for the PI_pid controller , Ysign is usedin the P_pid function instead */

if( Xsign == 1) Error_on_X_axis *= -1;

DutyCycle = PI_pid_X ( Error_on_X_axis );

// attua il movimento Gira a DX o Gira a SXServo_Set_Position (2, DutyCycle ,20);Servo_Set_Position (3, DutyCycle ,20);

}

// Actuate always the positioning on the HEAD motor , because this motor is notshared between different movements

if( Ysign == 1) Error_on_Y_axis *= -1;DutyCycle = PI_pid_Y ( Error_on_Y_axis );Servo_Set_Position (1, DutyCycle ,20);

}EE_led_off ();mydelay (200) ;

}

5.7. OpenCV e Linear Binary Pattern (LBP)OpenCV (Open Source Computer Vision) è una libreria open-source contenente centinaia di funzioni

per l’analisi di immagini e video, nel contesto della computer vision. A partire dalla versione OpenCV2.2 è stato aggiunto il supporto per il sistema operativo Android.

Figura 5.9.: Architettura della libreria OpenCV

Il progetto Marvin affronta l’argomento della Visione Artificiale e nello specifico quello della facedetection. Esistono diversi algoritmi per l’elaborazione di un frame video; tra di essi l’algoritmo di

75


Viola-Jones risulta il più affidabile e robusto per la localizzazione dei volti ed oggetti, sia in immaginistatiche sia in video. Diverse caratteristiche rendono questo metodo veloce e poco soggetto ai problemidi illuminazione, rotazione, scalatura e parziale occlusione dei soggetti inquadrati.Il metodo Local Binary Pattern (LBP) è un diverso metodo per la localizzazione di oggetti che prende

spunto da Viola Jones e ne migliora alcune caratteristiche; esso usa un codice binario per descrivere unpattern della texture locale, costruito confrontando i valori di grigio dei pixel vicini al punto centrale,preso come riferimento.Nella versione originaria del metodo LBP viene utilizzata una matrice di 3x3 pixel: gli 8 pixel che

circondano il pixel centrale vengono confrontati con il valore in scala di grigio di quest’ultimo; il risultatoè un numero binario, usato come descrittore della texture.

Figura 5.10.: Funzionamento dell’algoritmo LBP

Il metodo descritto è disponibile in versione migliorata tanto da implementare la ricerca di uni-form pattern (cioè pattern ricorrenti) oppure adattare la matrice di ricerca 3x3 ad una dimensionepersonalizzata.

76

Capitolo 6.

Il Sistema di Controllo

Il controllo automatico si prefigge di modificare il comportamento del sistema da controllare, le sueuscite, attraverso la manipolazione delle grandezze d’ingresso. Il controllo del sistema in esame vieneaffidato ad un altro sistema costruito appositamente, detto sistema controllante o controllore, che vieneprogettato dopo uno studio preliminare del sistema da controllare per individuarne il modello matematicoesatto, servendosi degli strumenti messi a punto dalla teoria dei sistemi.

6.1. Il controllore PID a tempo continuo: generalitàIl modello matematico di un sistema da controllare è determinato da dinamiche complesse e dai feno-

meni fisici, meccanici ed elettrici, che intervengono nel funzionamento del sistema. Per questo motivo èmolto difficile ricavare un modello matematico di un sistema da controllare. Il caso di Marvin è esempiodi quanto appena detto.Per quanto il problema possa essere affrontato con discreto successo mediante tecniche di identificazione

e modellistica, in questo lavoro si è scelto un approccio più semplice e molto diffuso nei processi industriali,ovvero l’utilizzo di un controllore PID.Questo controllore prende il nome dalle tre azioni che costituiscono la sua risposta impulsiva che nel

dominio di Laplace è:

R(s) = Kp ·(

1 + 1τi · s

+ τd · s)

(6.1)

per cui:

u(s) = R(s) · e(s) (6.2)

mentre l’uscita nel dominio del tempo è:

u(t) = Kp ·[e(t) + 1

τi

∫ ∞0

e(t)dt+ τd ·de(t)dt

](6.3)

Il controllore acquisisce in ingresso un valore dal processo, e lo confronta con un valore di riferimento.La differenza, il segnale di errore e(t), viene quindi usata per determinare il valore della variabile di uscitadel controllore u(t), che è la variabile manipolabile del processo.Il PID regola l’uscita in base a:

• il valore del segnale di errore (azione proporzionale);

• i valori passati del segnale di errore (azione integrale);

• la velocità di variazione del segnale di errore (azione derivativa).

77

Capitolo 6. Il Sistema di Controllo

Figura 6.1.: Controllore PID

Il contributo delle azioni del PID può essere riassunto come segue.Azione Proporzionale: è l’azione principale ed il suo scopo è quello di modificare l’uscita in modo che

essa sia proporzionale all’errore rilevato. Questa azione aumenta la prontezza del sistema aggiungendoguadagno, che in termini di risposta in frequenza corrisponde allo spostamento verso destra della pulsa-zione di attraversamento, provocando un aumento della banda passante e una diminuzione del tempo disalita. In questo modo il transitorio risulta essere più breve. Se il processo ha più di 3 poli l’aumentoincontrollato del guadagno porta il sistema inevitabilmente all’instabilità.

Figura 6.2.: Azioni proporzionali a confronto per un ingresso a gradino

Azione Integrale: migliora il tipo del sistema, rendendolo almeno di tipo 1. Questo significa chea regime permanente l’errore rispetto ad un ingresso a gradino risulta essere nullo, in quanto l’ordinedell’ingresso a gradino è pari a 0. Inoltre rende il sistema astatico rispetto a disturbi a gradino cheagiscono in catena diretta. Lo svantaggio è riscontrabile attraverso l’inserimento del polo in s = 0 checorrisponde a un ritardo di fase di -90° che potrebbe abbassare il margine di fase al di sotto dei 40° (minimomargine di fase consigliato). Il vantaggio apprezzabile che apporta questo termine è lo smorzamento delleoscillazioni introdotte dal termine proporzionale anche se questo è apprezzabile per alte frequenze infatti( 1s

)s=jω = 1

jω , che per ω →∞ da contributo pari a 0.

78


Effettivamente il termine integrale peggiora anche la prontezza del sistema attraverso il polo in s = 0.Per rendersene conto utilizzando le nozioni dell’analisi modale notiamo che se un modo aperiodico ècollocato nell’origine esso tenderà a non estinguersi mai o comunque molto lentamente.

Figura 6.3.: Azioni integrali a confronto per un ingresso a gradino

Azione Derivatrice: è l’azione che la maggior parte delle volte non viene inserita durante la realiz-zazione del controllore PID rendendolo di fatto un PI, questa azione ha lo scopo di migliorare la stabilitàdel sistema in quanto aggiunge uno zero in s = 0 che corrisponde in termini di risposta armonica ad unaumento di fase pari a +90°. Non viene quasi mai utilizzata; infatti l’operazione di derivata, non essendoun operatore lineare, potrebbe far divergere l’uscita ad infinito se sul sistema agisce del rumore. Inoltretende ad amplificare i disturbi alle alte frequenze.I vantaggi, comunque, non sono trascurabili. Se l’errore tende a diminuire, la correzione viene aumen-

tata non proporzionalmente, ma in base alla velocità di variazione. L’azione derivatrice può accelerareo decelerare l’intervento del regolatore in modo dinamico seguendo la tendenza dell’errore e “prevede”nella prossima lettura l’andamento dell’errore.

Figura 6.4.: Azioni derivatrici a confronto per un ingresso a gradino

La formula 6.3 deve essere discretizzata per poter essere inserita in un sistema di controllo digitale,come il dsPIC, poiché tale sistema accetta ingressi campionati e quantizzati, dovendo essi essere elaboratida un calcolatore.

79


Il tipico schema di controllo di un sistema digitale a dati campionati è il seguente

Figura 6.5.: Schema a blocchi di un sistema a dati campionati

Si noti la presenza del blocco A/D e D/A che effettuano rispettivamente la conversione analogico-digitale, che nel nostro sistema può essere individuato in Android, e il blocco digitale-analogico chetrasforma dei segnali numerici in segnali che variano nel tempo che nel nostro sistema è visto come ilmodulo MCPWM1.I servomotori sono rappresentati dal blocco di attuazione mentre il blocco impianto è il processo “Mar-

vin”. Il clock è rappresentato dalla periodicità del task di acquisizione garantita del RTOS ERIKA eimpostato a 100 ms, infine Android figura anche come trasduttore.

6.2. Il controllore PID a tempo discreto: generalitàLa discretizzazione non interessa il termine proporzionale, poiché esso è una moltiplicazione, ma è

necessaria per l’integrale e la derivata. Esistono diversi metodi per discretizzarli ma in questa tesi sonostati scelti quelli più semplici: ∫ ∞

0e(t)dt '

∞∑k=0

e(k) · Tc (6.4)

de(t)dt' e(k)− e(k − 1)

Tc(6.5)

avendo realizzato un controllore P e uno PI il termine derivato non è stato utilizzato.Si nota che il termine integrale richiede ad ogni istante k di calcolare una sommatoria. Tale somma

risulta un’operazione computazionalmente dispendiosa. Se si utilizza la versione ricorsiva dell’algoritmo,che tiene memoria dell’uscita passata u(k − 1), è possibile migliorare la situazione. Attraverso alcunesemplici sostituzioni si perviene così a questo algoritmo per il controllore PI:

u(k) = u(k − 1) +Kp ·[e(k)− e(k − 1) + Tc

τi· e(k − 1)

](6.6)

banalmente il controllore P è invece:u(k) = Kp · e(k) (6.7)

Nel caso specifico si somma all’uscita, u(k), una costante pari a 1,5, utile a traslare i valori dell’uscitaverso i valori di ingresso del servomotore. Infatti per u(k) = 0, e senza questa costante il servomotorefunzionerebbe con un duty cycle pari a 0,6, che non corrisponde alla posizione “neutra” dell’attuatore,così come l’uscita del controllore richiederebbe.L’algoritmo di calcolo del P e del PI è implementato in questo modo sulla Flex per un generico asse K:

float P_pid_K ( float error )

80


{float U = 0;U = Kp_K *( error ) + 1.5;return U;

}

float PI_pid_K ( float error ){

float U = 0;Ki_K = (Tc/Ti_K);float q1 = 1;float q2 = (-1 + Ki_K);U = ( lastU_K + Kp_K * (q1 * ( error ) + q2 * ( lastError_K ))) + 1.5;lastU_K = U - 1.5;lastError_K = error ;return U;

}

L’algoritmo PID è semplice da utilizzare ma risulta complicata la taratura dei parametri. Per ogniasse è necessario trovare empiricamente i parametri Kp, τi, τd, non possedendo il modello matematicodel processo. Essi dipendono fortemente dall’assetto del sistema e dai componenti utilizzati. Questacaratteristica del controllore PID si scontra leggermente con il concetto di Plug & Play che è alla basedella progettazione di Marvin: infatti sostituendo lo smartphone potrebbe essere necessario ritarare iparametri del PI e i margini di tolleranza.Segue quindi una metodologia di taratura che può essere replicata in diversi contesti.

6.3. Taratura dei parametriPer tarare i parametri ci si è basati sulla seconda tecnica di Ziegler e Nichols – che prevede la taratura

in catena chiusa – dove i parametri vengono trovati con il controllore collegato al sistema.Questa tecnica si basa sul trovare il guadagno critico Ku, cioè quel guadagno che porta la variabile

controllata a presentare oscillazioni sostenute, oscillazioni, cioè, che non si esauriscono nel tempo. Ov-viamente il guadagno critico si trova imponendo τi = τd = 0. Il Ku è importante perché fornisce unamisura del ritardo e della dinamica del processo.Successivamente viene osservato il Tu, cioè il periodo di oscillazione. A partire da questi dati si applicano

delle formule semi-empiriche per la taratura dei parametri.Per ogni asse sono stati eseguiti i seguenti passi:

1. Partendo dal controllore P, ponendo a zero le altre azioni, si è trovato Ku, cioè il guadagno cheportasse all’oscillazione il sistema. Per trovare Ku si è incrementato per tentativi il guadagnopartendo da un valore basso.

2. Le oscillazioni attorno al set-point, per ogni asse, sono state misurate “ad occhio”, non avendo avutoil tempo costruire una corretta misura dell’uscita oppure un esperimento di simulazione. In ognicaso trovato il Ku si misura il periodo di tempo che intercorre tra un’oscillazione e la successiva,indicandolo come Tu.

81


Figura 6.6.: Ku e Tu

3. Trovati Ku e Tu si procede al calcolo dei parametri Kp, τi e τd, secondo la tabella costruita daZiegler e Nichols.

Controllore Kp τi τd

P 0, 5Ku - -

PI 0, 45KuTu

1,2 -

PID 0, 6KuTu

2Tu

8

4. Quindi si testa il sistema inserendo l’algoritmo completo del controllore desiderato con i parametricalcolati.

5. Si conclude il lavoro di taratura con un ulteriore fine tuning dei parametri calcolati per adattarli inmaniera migliore al processo.

I parametri calcolati per lo smartphone di riferimento sono:

• Asse Y: Kp = 0, 17, τi = 1, 25, τd = 0;

• Asse X: Kp = 0, 4, τi = 2, τd = 0;

• Asse Z: Kp = 1, τi = 0, τd = 0;1

1È stato tarato anche un controllore PI con i seguenti parametri Kp = 1, 35, τi = 0, 5 ma non è usato nella build finale.

82

Capitolo 7.

Conclusioni e sviluppi futuri

In questo ultimo capitolo vengono riportati i test di funzionamento sul prototipo realizzato e un riepilogodei risultati ottenuti, concludendo il lavoro con uno sguardo al futuro del progetto.

7.1. Test di funzionamentoI test di funzionamento sono stati eseguiti attraverso diversi step. Nelle fasi iniziali di lavoro è

stato necessario concentrarsi sull’importazione e sul setup del precedente sistema, nello studio e nellacomprensione approfondita di come è stato sviluppato.Lo studio ha portato all’individuazione dei punti deboli del sistema. Da qui si è partiti per la

progettazione e l’acquisto dei nuovi componenti: in primis Arduino e i Servomotori.I test di funzionamento si sono spostati sulla Flex, portando a capire come il microcontrollore è im-

plementato all’interno della architettura progettata da Evidence, in che modo effettuare il debug e comel’architettura del dsPIC integrata nella Flex potessero essere utilizzate per lo sviluppo.I test di funzionamento si sono concentrati su come i vari tasks vengono schedulati da ERIKA e come

creare i diversi oggetti del sistema operativo quali risorse, os, cpu, kernel ecc.. Contemporaneamente sonostate sviluppate le librerie serialConsole.h, eeuart.h e utility.h.Lo studio del Vinculum II e del suo IDE è stato il secondo step anche successivamente è stato sostituito

da Arduino e dalla libreria Microbridge ADB. Ulteriori test sono stati effettuati sia su Arduino creandoMarvin.ino e la libreria Arduino.h sulla Flex per effettuare le comunicazioni UART.Diversi giorni sono stati impiegati per portare il sistema a funzionare nella configurazione: Arduino–

Vinculum-II–Flex–Control Module, poi scartata per le basse prestazioni.Quindi si è passati, nel terzo step, allo studio delle periferiche tra cui timers, oscillatori e PWM,

attraverso test di funzionamento sui motori, prima provando senza carico e successivamente inserendo uncarico -la ruota- per studiarne le prestazioni in termini di velocità e stabilità.In contemporanea con le periferiche si è anche condotto lo studio dell’alimentazione creando il circuito di

potenza e dividendo la breadboard in due linee di alimentazione. Test sull’elettronica sono stati condottiattraverso un multimetro e un oscilloscopio per verificare la forma d’onda della PWM.Una volta terminati i vari test sul lato hardware e scelta la configurazione Arduino-Flex- Servomotori si

è passati allo studio di Android, attraverso debug dell’applicazione già esistente e progettando un diversotipo di controllo del robot, non più secondo Aree ma utilizzando algoritmi tipici dell’automatica.I restanti test si sono concentratati appunto sull’applicazione ad alto livello e sulla la taratura dei

parametri del PID.Sono stati ipotizzati anche test formali al fine di estrarre risultati numerici dal prototipo realizzato.

L’idea di base consiste nel calcolare la velocità massima che un volto può assumere rimanendo riconoscibilee continuando ad essere inseguito dal sistema. La velocità è legata al numero di frames che il sistemariesce ad elaborare, e quindi si è stimato che processando 10 frame al secondo, un volto viene riconosciutose ha una velocità minore di 10 cm/s.

83

Capitolo 7. Conclusioni e sviluppi futuri

Studi più precisi possono essere condotti costruendo un sistema di test, come ad esempio una foto di unvolto mossa da un motore a rotazione continua, dove sarebbe possibile impostare la velocità di rotazionedel motore. Noto il diametro della ghiera e la velocità di rotazione, si potrebbe verificare effettivamentela velocità massima di riconoscimento dei volti dato un tetto massimo di frames per secondo.

7.2. Obiettivi raggiuntiAttraverso i test eseguiti si è notato un generale raggiungimento di tutti i requisiti e degli obiettivi

prefissati. Infatti il sistema è stato riprogettato rendendolo più “snello” e capace di evolversi nel temposenza troppe difficoltà. La scheda Flex è stata studiata e si è dimostrato come sia possibile usarne leperiferiche in maniera interessante, nonchè creare delle librerie che permettano una sempre più facileprototipizzazione ed accesso all’hardware.Il sistema ERIKA è stato approfondito attraverso esperimenti e ricerche in maniera tale da poter usare

tutti gli oggetti avanzati e non, messi a disposizione per il programmatore dimostrando come anche suun sistema embedded e dalla capacità di calcolo ridotta sia possibile effettuare uno scheduling real-time.Il lavoro di ricerca si è spostato anche sul versante Arduino ed Android, mostrando le potenzialità e

gli ambiti di applicazione soprattutto con la libreria Microbridge ADB, capace di eliminare il problemadei pochi smartphone compatibili e OpenCV per gli algoritmi di visione. Infine si è implementato uncontrollore PID funzionante, permettendo un ottimo inseguimento di volti, riutilizzabile all’occasionein molti ambiti diversi, tra quelli più affini -come l’inseguimento di oggetti- o per scopi più complessimanipolando gli errori e i Set points.Infine per una gestione manuale dei comandi di spostamento è stata costruita una sorta di “demo” sia

in ambito Android che su Flex per inviare e ricevere i singoli comandi di direzione.

Figura 7.1.: Architettura finale di Marvin

84


7.3. Sviluppi futuriMarvin è da considerarsi un vero è proprio laboratorio mobile, su cui sperimentare sia applicazioni a

basso livello tra cui l’estensione della sensoristica e delle periferiche utilizzabili tra cui SPI, CAN bus,Bottoni, LCD l’inserimento un nuovo motore per l’attuazione lineare del movimento di testa in manieratale che la testa, oltre a spazzare angoli, si muova linearmente attraverso un sistema meccanico che diapiena libertà di movimento lungo l’asse Y e sensoristica varia.E’ auspicabile la sostituzione del layer di Comunicazione attraverso porting della libreria ADB sulla

Flex, oppure utilizzando un modulo bluetooth per scambiare i dati tra Flex e Android.Ad alto livello è possibile avere uno scenario molto più ampio di possibili applicazioni. Ad esempio,

si potrebbe utilizzare il protocollo Voice XML per permettere di processare informazioni vocali e quindiestrapolare da essi comandi e attraverso un TTS (text-to-speech) “dare la parola” a Marvin utilizzandol’altoparlante dello smartphone.L’intelligenza artificiale trova grandi campi di applicazione su robot mobili tra cui la possibilità di

tracciare percorsi, riconoscere path e imparare attraverso reti neurali.L’ambito di controllo automatico può essere esplorato oppure affiancato alla sensoristica esistente per

l’esplorazione di ambienti sconosciuti e la creazione di mappe. Infine è possibile approfondire la computervision sia implementando nuovi algoritmi di visioni tra quelli disponibili in OpenCV sia idearne dei nuovi.

85


Figura 7.2.: Marvin

86

Appendice A.

Dettagli di cablaggio

Flex ArduinoP51 (U1TX) 19 (RX1)P52 (U1RX) 18 (TX1)

GND GND

Tabella A.1.: Connessione Flex-Arduino tramite USART1

Figura A.1.: Connessione Flex-Arduino tramite USART1

Flex Convertitore PL2303P50 (U2TX) RXP49 (U2RX) TX

GND GND

Tabella A.2.: Connessione Flex-Convertitore tramite USART2

87

Appendice A. Dettagli di cablaggio

Figura A.2.: Connessione Flex-Convertitore tramite USART2

Flex Hitec HB-485HSP94 (PWM1H) YELLOW

+5V REDGND BLACK

Tabella A.3.: Connessione Flex-Servomotore di testa tramite PWM1

Figura A.3.: Connessione Flex-Servomotore di testa tramite PWM1

88


Figura A.4.: Dettaglio del servomotore di testa

Flex DFRobotic (SX)P99 (PWM2H) ORANGE

+5V da breadboard REDGND BROWN

Tabella A.4.: Connessione Flex-servomotore di propulsione tramite PWM2

Flex DFRobotic (DX)P3 (PWM3H) ORANGE

+5V da breadboard REDGND BROWN

Tabella A.5.: Connessione Flex-servomotore di propulsione tramite PWM3

Figura A.5.: Connessione Flex-servomotori di propulsione tramite PWM2 e PWM3

89


Figura A.6.: Dettaglio dei servomotori di propulsione alloggiati sotto la struttura

Flex LedP25 (DGTL-OUTP) ORANGEP26 (DGTL-OUTP) YELLOW

Tabella A.6.: Connessioni Flex-led

Arduino Led24 (Digital) GREEN22 (Digital) RED

Tabella A.7.: Connessioni Arduino-led

Figura A.7.: Connessione Flex e Arduino ai led presenti sulla breadboard

90


Figura A.8.: Circuito di alimentazione e linee di tensione

Figura A.9.: Connessione Arduino-Smartphone tramite cavo USB

91

Appendice B.

Software utilizzato

In questa Appendice vengono riportate le versioni dei software utilizzati nello sviluppo di Marvin1.

Programmazione della scheda FLEX• Java JRE 1.6.0_27 a 32-bit

• Cygwin 1.7.9

• ERIKA Enterprise e RT-Druid 1.6.1

• Microchip MPLAB IDE v8.43

• Microchip C30 Compiler v3.30c

• RealTerm per il Debug

Programmazione della scheda Arduino• Arduino 1.0

• Microbridge ADB (modificata)

Programmazione dell’applicazione Android• Eclipse IDE for Java Developers, INDIGO (v3.7.1)

• Android SDK

• ADT Plugin per Eclipse

• Android 2.3.4 (Google API 10) installati tramite l’Android SDK Manager

Programmazione del Vinculum-II• Vinculum-II toolchain v 1.4.4

• Drivers per V2DIP

1I software citati sono tutti disponibili nella cartella “software” nel CD della tesi.

92

Bibliografia

[1] “dsPIC33FJXXXMCX06/X08/X10 Motor Control Family Data Sheet.” [Online]. Available:http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en024663#1

[2] “Microchip dsPIC – wiki page for ERIKA.” [Online]. Available: http://erika.tuxfamily.org/wiki/index.php?title=Microchip_dsPIC

[3] “Erika Enterprise Conformance Classes Comparison Guide.” [Online]. Available: http://erika.tuxfamily.org/download/manuals/pdf/ee_porting_1_0_1.pdf

[4] “Erika Enterprise reference manual.” [Online]. Available: http://erika.tuxfamily.org/download/manuals/pdf/ee_refman_1_4_4.pdf

[5] “RT-Druid reference manual.” [Online]. Available: http://erika.tuxfamily.org/download/manuals/pdf/rtdruid_refman_1_5.0.pdf

93

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en024663#1

http://erika.tuxfamily.org/wiki/index.php?title=Microchip_dsPIC

http://erika.tuxfamily.org/wiki/index.php?title=Microchip_dsPIC

http://erika.tuxfamily.org/download/manuals/pdf/ee_porting_1_0_1.pdf

http://erika.tuxfamily.org/download/manuals/pdf/ee_porting_1_0_1.pdf

http://erika.tuxfamily.org/download/manuals/pdf/ee_refman_1_4_4.pdf

http://erika.tuxfamily.org/download/manuals/pdf/ee_refman_1_4_4.pdf

http://erika.tuxfamily.org/download/manuals/pdf/rtdruid_refman_1_5.0.pdf

http://erika.tuxfamily.org/download/manuals/pdf/rtdruid_refman_1_5.0.pdf

Marvin: progetto e sviluppo di un robot real-time guidato da ...

Documents

Transcript of Marvin: progetto e sviluppo di un robot real-time guidato da ...