Università degli Studi di Cagliari -...

Università degli Studi di Cagliari

Facoltà di Scienze

Corso di Laurea in Informatica

Tesi di Laurea

Utilizzare Android e Arduino per la gestione di luci nello Spettacolo

Relatore: Tesi di Laurea di

Reforgiato Recupero Diego Angelo Gaetano Matteo Zanda

Anno Accademico 2016/2017

Tesi di Laurea Triennale – Matteo Zanda – matr.47143 II

Ringraziamenti

Giunto al termine di questo lavoro desidero ringraziare ed esprimere la mia riconoscenza nei

confronti di tutte le persone che, in modi diversi, mi sono state vicine e hanno permesso e

incoraggiato sia i miei studi che la realizzazione e la stesura di questa tesi.

Ringrazio il mio relatore prof. Reforgiato per avermi seguito e guidato durante la redazione di

questa tesi dandomi fiducia, disponibilità e preziosi consigli.

Grazie di cuore alla mia famiglia e in particolare i miei genitori che mi hanno sostenuto in

ogni modo per raggiungere questo importante traguardo.

Ringrazio Sara per la quotidiana preziosa vicinanza che mi spinge a dare il meglio di me ogni

giorno. Grazie anche a tutta la sua famiglia, che mi accoglie con grande affetto.

Vorrei ringraziare i colleghi e gli amici con cui ho condiviso più soddisfazioni e difficoltà in

questi anni di studi, in particolar modo Antioco, Nicola, Maurizio ed Enrico.

Ringrazio tutti i miei colleghi di lavoro, in particolare Basilio e Loїc per l’amicizia e la

fiducia riposta in me e nella mia professionalità.

Ringrazio infine tutti coloro che non sono stati citati ma che mi sono stati vicini in questi anni,

hanno creduto in me e mi hanno aiutato a formarmi e farmi crescere come uomo e come

professionista.

Tesi di Laurea Triennale – Matteo Zanda – matr.47143 III

Indice

1. Introduzione ....................................................................................................................................... 1

2. Stato dell’Arte ...................................................................................................................................... 2

2.1 - Le console luci digitali ................................................................................................................. 2

2.2 - Il protocollo DMX-512 ................................................................................................................. 5

Storia del protocollo ........................................................................................................................ 5

Spiegazione del protocollo a livello logico ..................................................................................... 7

2.3 - Gli MCU e Arduino ....................................................................................................................... 9

Microcontroller Embedded Systems ............................................................................................... 9

Cosa è Arduino? ............................................................................................................................... 9

2.4 - Il sistema operativo Android ..................................................................................................... 10

2.5 - La comunicazione Bluetooth ..................................................................................................... 11

3 - Il Progetto ......................................................................................................................................... 12

3.1 - Progettazione e Realizzazione ................................................................................................... 12

3.2 - Step di realizzazione del progetto: ............................................................................................ 13

3.3 - App ............................................................................................................................................ 14

3.4 - Interfaccia fisica, il Controller Bluetooth-DMX ......................................................................... 16

Interfaccia fisica - Lato Software .................................................................................................. 16

Interfaccia fisica - Lato Hardware .................................................................................................. 18

3.5 - Comunicazione App - Interfaccia fisica Bluetooth-DMX ........................................................... 18

3.6 - Sviluppi futuri ............................................................................................................................ 21

4. Conclusioni ........................................................................................................................................ 22

5. Bibliografia ......................................................................................................................................... 23

Tesi di Laurea Triennale – Matteo Zanda – matr.47143 1

1. Introduzione

Negli spettacoli televisivi, in teatro, nei concerti, nelle mostre e più in generale in tutte le

manifestazioni artistiche, la luce assume un ruolo di fondamentale importanza perché

permette di concentrare l’attenzione degli spettatori su precisi punti di fuoco.

Gli spettacoli teatrali, applicazione nella quale il progetto (di cui questa tesi tratta) trova

maggiore utilizzo, hanno in genere una sequenza di luci predeterminata dal Light Designer e

dal Regista della produzione. Tale sequenza segue il susseguirsi delle scene con posizione,

intensità, colore e tempi di transizione delle luci ben definiti e codificati.

Vengono quindi utilizzate sofisticate console luci digitali, capaci di offrire ai Light Designer

tutte le possibilità di gestione delle quali essi necessitano, comprendenti funzioni semplici

come Submasters e Cuelists e talvolta funzioni complesse, come gestione e creazione di

Fixtures, Macro, Exec, effetti per Motorizzati e Matrici RGB, Visualizer, gestione Audio-

Video, etc.

L'utilizzo dei dispositivi mobile è da alcuni anni sostenuto dalle grandi case produttrici, ma

col principale scopo di interfacciarsi alle loro costose consoles, dare loro una funzionalità

aggiunta. Lo sviluppo di sistemi a basso costo è un business ancora poco praticato ma molto

utile e richiesto. E’ da qui che parte l’idea di realizzare il progetto descritto in questa tesi.


2. Stato dell’Arte

2.1 - Le console luci digitali

Ad oggi le consoles digitali si dividono in tre tipologie principali:

All-In-One comprendenti interfaccia fisica con faders e pulsanti di controllo, tastierino

numerico, uscita video per uno o più

monitor touchscreen, veri e propri

computer all'interno, con sistema

operativo ottimizzato per far

funzionare al meglio il sistema. Costo

dai circa 2000 a più di 30000€.

Fig. 2.1 – Grand Ma 2 Full-Size

Interfaccia fisica collegabile via

USB (Wing) al proprio computer,

con installato il software di

controllo delle luci, per un costo

tra i circa 1500 e i 5000€

Fig. 2.2 – Laptop con Mini Wing Chamsys

Interfaccia fisica collegata a microcontrollore e piccolo

display, con capacità di gran lunga inferiori alle

precedenti tipologie, nella fascia di prezzo di alcune

centinaia di euro.

Fig. 2.3 – ShowTec Showdesigner 1024

Tutte queste centraline devono pilotare, tramite segnale digitale, moduli dimmer in grado di

erogare la corrente necessaria ad alimentare centinaia di lampade da 1000, 2000 o anche

5000W, oppure LED multicolore, luci motorizzate, cambiacolore, macchine del fumo,


meccanismi di movimento di scena, ognuno con uno o più canali, dedicati a tutte le funzioni

relative al device.

Ogni console dispone di una o più uscite DMX, con connettori tripolari, pentapolari o RJ45,

capaci di pilotare fino a 512 canali ciascuna. Ogni uscita gestisce un “universo”.

Per farci un’idea su cosa siano i canali di cui sopra osserviamo la seguente tabella, contenente

informazioni di massima su apparecchi comunemente utilizzati in ambito teatrale:

Device Info Canali DMX

Dimmer Alimenta fino a sei lampade a incandescenza da 2000W, un

canale DMX per ogni luce

1 - 4 - 6 - 8 -

12

Led Multicolore Un canale per ogni intensità di colore più i controlli:

dai fondamentali Rosso, Verde, Blu, per arrivare a Bianco,

Ambra, UV, Strobo, Master, Effetti, Macro, Service

3 - 11

Testa Mobile / Scanner Pan, Pan fine, Tilt, Tilt fine, Master, Ciano, Magenta,

Giallo, Ruote Colori, Ruote Gobos, Iris, Service, etc

~10 - 30

Macchina del fumo Intensità fumo, Ventola, Temperatura fumo 1 - 3

Tab. 2.1 - Esempi di quantità di canali DMX per i più comuni devices utilizzati in Teatro

Fig.2.4 - esempio di collegamento di catena di devices a singolo canale


Ad ogni device, collegato in cascata nella catena a valle della console, viene assegnato un

indirizzo DMX di partenza. L’impostazione dell’indirizzo si esegue maggiormente tramite

display e pulsanti o tramite DIP-Switch di selezione con codice binario, ad un indirizzo

nell’intervallo 1 - 512.

Fig. 2.5 - Esempi di interfacce di selezione indirizzo DMX presenti nei device

Il device quindi risponderà solo ai valori corrispondenti il proprio range di canali

Esempio:

il collegamento di due Dimmer da sei canali e due Par Led da sei canali. Un possibile schema

di indirizzamento dei canali è:

Dimmer A = Ch 1-6 In questo esempio:

Dimmer B = Ch 7-12 i Dimmer sono connessi a sei Par Can con

Led Par A = Ch 13-18 lampade alogene

Led Par B = Ch 19-24 i Led sono MSRGBW, hanno sei canali:

Led Par C = Ch 25-30 Master, Strobo, Red, Green, Blue, White.


Fig. 2.6 - Esempio semplice di collegamento dei devices nella catena DMX

2.2 - Il protocollo DMX-512

Storia del protocollo

“The original version of the DMX512 Standard was developed in 1986 by the

Engineering Commission of the United States Institute for Theatre Technology, Inc.

(USITT). Minor revisions were made in 1990. DMX512 has gained international

acceptance throughout the entertainment industry, even though USITT is not formally

accredited as a standards making body. The earlier versions of this Standard covered

only data used by dimmers. In practice this Standard has been used by a wide variety

of devices; this version recognizes this fact.

In 1998, it became evident that additional updates to the Standard were necessary and

formal recognition through an internationally recognized standards organization was

required. USITT issued a Call for Comments in order to solicit recommendations for

changes to the Standard. At the same time, USITT transferred maintenance of

DMX512 to ESTA's ANSI-accredited Technical Standards Program, now operating as

PLASA's Technical Standards Program.


A Task Group established under the TSP’s Control Protocols Working Group acted on

the proposals received in response to the Call for Comments. The primary goal was to

make editorial updates to DMX512 appropriate for current times, including the

addition of technical features while maintaining a balance with backward

compatibility. Many proposals, while technically innovative, could not be accepted

because their implementation would not have been backward compatible and would

have immediately rendered obsolete most of the installed base of equipment.

In 2004, as a result of the actions taken on those proposals and subsequent

development under the Policies and Procedures of the ESTA Technical Standards

Program, E1.11-2004 was approved as an American National Standard. Despite

being an American National Standard, development has had strong international

participation and support.

Beginning in 2007, based on comments and requests from users and manufacturers,

minor revisions were made to E1.11-2004 and submitted to the public for review and

comment. These changes included defining one of the reserved Alternate START

Codes for UTF-8 text packets, a note emphasizing refresh timings, and removal of the

informative PICS (Protocol Implementation Compliance Statement) clauses. The PICS

clauses were simply a summary of the mandatory requirements of the standard, but

often had to employ language that used double negatives and led to confusion about

some requirements. The 2008 edition was the result of those revisions to the 2004

edition. This edition is a reaffirmation of the 2008 edition.” [1]

Come citato nel documento dell’American National Standard riportato sopra, è importante

notare quanto impegno è stato impiegato, nel corso dell’evoluzione dello standard, per

mantenere retro-compatibilità con i vecchi sistemi. Le moderne consoles possono quindi

lavorare in teatri con vecchie dotazioni tecniche e viceversa.

[1]

American National Standard E1.11 – 2008 (R2013)

Entertainment Technology USITT DMX512-A Asynchronous Serial Digital Data Transmission Standard for Controlling

Lighting Equipment and Accessories CP/2007-1013r3.1 - ANSI E1.11-2008 (R2013) - Pag. xii

http://tsp.esta.org/tsp/documents/docs/E1-11_2008R2013.pdf



Il protocollo DMX, il cui nome è acronimo di Digital Multiplex, è basato su un sistema di

comunicazione seriale asincrona con lo scopo di uniformare i controller digitali con i Dimmer

di diversi produttori.

Esso è tuttora utilizzato negli impianti di illuminazione per controllare sia la luminosità delle

lampade che i movimenti dei sistemi più sofisticati, dai light-scanner ai dispositivi a testa

mobile, dai laser alle macchine per il fumo, tutti con compatibilità al protocollo.

Il segnale digitale di comunicazione sfrutta un’interfaccia elettrica differenziale basata sulla

comunicazione seriale del protocollo RS485. E’ sempre più diffuso l'utilizzo del protocollo

ArtNet, che sfrutta i supporti Ethernet per la trasmissione del segnale, più veloce del comune

cavo DMX e capace di trasmettere decine di segnali contemporaneamente. Esistono tuttavia

parecchi altri protocolli, quali ArtNet 2, ArtNet 3, StreamingACN (sACN), ESP Net, OSC

(Open Sound Control), PathwayPathport, SandNet, ShownetStrand. creati e supportati da

aziende che sperano il proprio possa diventare uno "standard de facto".

Spiegazione del protocollo a livello logico

“The controller bursts out a stream of bytes, up to 512 bytes long. Each device on the

bus has a configured address, and the address instructs which byte in the burst is

meant for it.

Fig.2.7 - composizione in byte di un pacchetto DMX, sono riportati i codici di inizio

comunicazione e i vari slot con i 512 valori

https://cdn.sparkfun.com/assets/learn_tutorials/4/0/8/dmx-512-burst.png


A simple light fixture might receive a single byte controlling brightness, while a

motorized fixture might receive many bytes, to control panning, color,

brightness, cucoloris selection, and other effects.

DMX - or more specifically DMX512 - is a standard for digital communication use to

control stage lighting - so a lighting desk sends DMX messages to fixtures thru the

cables to get control of them. That cables are 3 or 5 pin XLR cables, and devices can

be daisy-chained to make a network.

The 512 after the DMX refers to the number of control channels used on one network

segment (a “universe”) of devices.

One DMX channel controls one parameter - for example the intensity of a dimmer.

DMX channels using 8-bit so a value will be in the 0-255 range.

Some fixtures may using several channels to control various parameters like pan, tilt,

red, green, blue but there are things like mono-color LED strips with dimmers which

can be controlled on a single DMX channel.” [2]

Come descritto nell’articolo di cui sopra, gli apparecchi vengono collegati in catena tramite

cavo XLR a 3 o 5 pin, nel circuito di connessione passa il segnale con i valori dei 512

indirizzi. Tale segnale viene chiamato “universo”. Un universo può gestire 512 valori, qualora

vi fosse necessità di usarne di più (capita spesso quando si utilizzano numerose teste mobili o

led multicolore, o ancora fare “pixel Mapping” con matrici di led, o si vuole dividere in più

gruppi i device per diminuire la lunghezza della catena di collegamento e diminuire il rischio

di perdita di segnale o “Mirror effect”) si utilizzeranno quindi più universi. A tal proposito è

consigliato porre, alla fine di ogni catena, un terminale con resistenza da 120Ω. Gli schemi di

assegnazione dei canali all’interno dei device si chiamano fixtures.

[2] http://imimot.com/blog/lighting-for-beginners-dmx-and-art-net/ - articolo scritto il 09/14/2015

https://en.wikipedia.org/wiki/Cucoloris

http://en.wikipedia.org/wiki/DMX512

http://imimot.com/blog/lighting-for-beginners-dmx-and-art-net/


2.3 - Gli MCU e Arduino

Microcontroller Embedded Systems

Come citato nell’articolo “Microcontroller Embedded Systems” di Ian Poole [3]

, i

microcontrollori sono componenti hardware che comprendono i principali elementi di un

piccolo computer in un unico chip. Essi contengono processore, memoria rom, ram e talvolta

EEPROM, poi dei pin per connessioni digitali e analogiche. Questo accorpamento di

componenti consente di ridurre le dimensioni dei sistemi, i consumi energetici e i costi di

produzione rendendoli l’ideale per piccoli sistemi integrati. Sono tuttavia da accettare

compromessi in termini di prestazioni e flessibilità.

Fig.2.8 - Rappresentazione per blocchi dell’architettura di un microcontrollore base,

esso contiene CPU, RAM, ROM e IO.

Cosa è Arduino?

Sul sito ufficiale di Arduino è riportato che “Arduino is an open-source electronics platform

based on easy-to-use hardware and software. Arduino boards are able to read inputs - light

on a sensor, a finger on a button, or a Twitter message - and turn it into an output - activating

a motor, turning on an LED, publishing something online. You can tell your board what to do

by sending a set of instructions to the microcontroller on the board. To do so you use

[3] http://www.radio-electronics.com/info/processing-embedded/embedded-systems/microcontroller-mcu-systems.php - Ian

Poole

https://www.arduino.cc/en/Main/Products

http://www.radio-electronics.com/info/processing-embedded/embedded-systems/microcontroller-mcu-systems.php


the Arduino programming language (based on Wiring), and the Arduino Software (IDE),

based on Processing.” [4]

Il progetto è nato in Italia e nel corso degli anni sta venendo impiegato in molteplici progetti

in tutto il mondo, dal campo amatoriale a quello artistico fino a quello scientifico. Gli

elementi più importanti di questa piattaforma sono la semplicità di utilizzo e la comunità che

si è venuta a creare intorno ad essa e che lo spinge a crescere sempre di più condividendo

progetti, sviluppando nuove librerie e hardware compatibile che ne possa incrementare le

funzionalità e la possibilità di utilizzo nei più svariati contesti ed aprire le porte al mondo

della programmazione anche ai novizi.

La piattaforma Arduino è quindi non solo una scheda programmabile ma un ambiente di

sviluppo completo, con un software IDE dedicato.

La scheda è stata basata inizialmente solo su microcontrollori a 8-bit AVR prodotti dalla

Atmel e componenti complementari per facilitarne l'incorporazione in altri circuiti. Ad oggi

sono in commercio numerose versioni della scheda, alcune con processori Atmel basati su

architetture ARM a 32 bit o Atheros, con una distribuzione Linux ottimizzata.

2.4 - Il sistema operativo Android

Android è un sistema operativo sviluppato da Google per Smartphone e Tablet e

successivamente esteso ad apparecchi come televisori, automobili, orologi e occhiali, basato

su kernel Linux e gli sviluppi sono basati su codice Java.

Esso deve senz’altro parte del suo successo alla grande quantità di applicazioni per esso

disponibili e al Play Store, market on-line creato da Google che contiene migliaia di app

gratuite o a pagamento create dalla comunità di sviluppatori Android in tutto il mondo.

Sul Web è possibile trovare un’enorme quantità di tutorial e esempi, sono presenti IDE

gratuiti che aiutano l’apprendimento dello sviluppo software e stimolano la creatività degli

sviluppatori.

[4]

https://www.arduino.cc/en/Guide/Introduction

https://www.arduino.cc/en/Reference/HomePage

http://wiring.org.co/

https://www.arduino.cc/en/Main/Software

https://processing.org/

https://www.arduino.cc/en/Guide/Introduction


2.5 - La comunicazione Bluetooth

La tecnologia Bluetooth consiste di un protocollo di comunicazione a basso consumo ed a

breve raggio

I dispositivi Bluetooth possono instaurare fra loro delle connessioni dando vita a delle vere e

proprie reti. La rete più semplice, detta Piconet, è composta da un dispositivo che assume il

ruolo di master e fino a sette dispositivi che assumono il ruolo di slave. Ogni comunicazione

passa attraverso il master in maniera del tutto analoga ad una rete a stella. Il master gestisce la

frequenza di portante della comunicazione e trasmette solo nei timeslot pari, mentre lo slave

trasmette nei timeslot dispari al fine di evitare collisioni.

E’ possibile far comunicare i master di più Piconet tra loro, costituendo una rete più ampia e

chiamata Scatternet. Essa può contenere fino a dieci Piconet, per un totale di ottanta

dispositivi Bluetooth. Ogni Piconet opera a frequenze differenti per evitare interferenze nelle

comunicazioni.

Un terminale Bluetooth può appartenere contemporaneamente a due Piconet purchè sia in

grado di operare a frequenze differenti a seconda che comunichi con i dispositivi dell’una o

dell’altra: naturalmente non può assumere il ruolo di master in entrambe le Piconet

contemporaneamente.

Il progetto presentato nella presente tesi si avvale di una comunicazione Piconet tra il device

Android e il modulo Bluetooth dell’Arduino, in cui il device Android copre il ruolo di master.


3 - Il Progetto

Il progetto consiste nello sviluppo di un'app per smartphone e tablet Android per la gestione

delle luci nello spettacolo, sfruttando un’interfaccia fisica Bluetooth - DMX creata ad-hoc

utilizzando Arduino.

Lo sviluppo vuol permettere ai professionisti dello spettacolo, ma anche a DJ, musicisti e

appassionati di avere un apparecchio portatile e autonomo capace di gestire un parco luci

professionale, interagirci in tempo reale, dirigere le luci degli spettacoli comodamente seduti

in platea accanto al pubblico. Vuole soprattutto sopperire all'acquisto di console da centinaia o

migliaia di euro per piccoli teatri, club, o qualunque edificio con illuminazione centralizzata, a

fronte di una spesa di poche decine di euro per creare o acquistare l'interfaccia Bluetooth-

DMX.

3.1 - Progettazione e Realizzazione

Tutto il progetto è pensato e realizzato con l'ottica del garantire minor latenza e minor numero

di errori possibili dovuti alla trasmissione e ricezione dati durante l'utilizzo del prodotto.

Grandi attenzioni sono quindi state date al ridurre al minimo le operazioni di scrittura e

lettura, evitare trasmissione ridondante di dati, verificare integrità dei pacchetti e richiederne

l'invio in caso di errori.

Fig.3.1 - Architettura Hardware del progetto

Android device

Bluetooth Module

Arduino nano

Display LCD

MAX485

DMX Plug

Bluetooth Communication

Controller Bluetooth-DMX


3.2 - Step di realizzazione del progetto:

[Progetto] Concettualizzazione dell'idea,

[Progetto] Valutazione e analisi delle effettive necessità per i professionisti delle Luci

(Analisi dei requisiti)

[Progetto] Analisi dei sistemi attualmente utilizzati in Teatro e concettualizzazione

delle funzioni che si vuole implementare nel progetto

[App] Creazione di un mock-up dell'Android App

[App] Realizzazione delle schermate grafiche (xml) delle activity

[App] Implementazione della classe Java per la modalità Single Channels,

comprendente

o Barra delle funzioni, con Titolo e bottone Menu; Sei pulsanti funzione; lista di

Fader, in cui ogni elemento è composto da Numero Canale, SeekBar, Valore

Canale, Nome Canale.

o Realizzazione del metodo di invio dati via bluetooth, inviando tutti i valori in

un unico pacchetto ogni qualvolta si interagisce con i fader

[Hardware] Costruzione del sistema hardware, collegando su una breadboard:

o Un Arduino Nano

o Un modulo bluetooth HC-05

o Un integrato MAX485 per la comunicazione DMX

o Un Display LCD 16x2 utile a mostrare all’utente feedback dell'Arduino

[Arduino] Stesura del codice per l'Arduino, nel dettaglio:

o Ricezione dei dati Bluetooth tramite porta seriale

o Analisi della correttezza dei dati e memorizzazione in un array

o Invio dati DMX tramite porta RS-485

o Implementazione algoritmi di analisi dati ricevuti e gestione interrupts sulla

porta seriale al fine di ridurre il numero di errori

o Implementazione trasmissione di comandi per il reinvio dei dati arrivati

corrotti.

[App] Realizzazione della pagina per la modalità Scene

o Modifica del codice di invio pacchetti via Bluetooth, utilizzati i thread per

rendere più stabile la comunicazione


o Gestione delle scene, grafica molto simile alla modalità Singolo Canale, ma

con i nomi delle scene e diversi pulsanti. Ordinare i valori come array di array

di valori Fader.

[App] Modifica della struttura dei pacchetti inviati via bluetooth

o Ora viene inviato un solo canale per volta al fine di ridurre la dimensione dei

pacchetti e diminuire gli errori di comunicazione

[Arduino] Miglioramento della comunicazione:

o Adeguamento del codice alla nuova struttura di pacchetti

[Hardware] Saldatura dei componenti su basetta millefori

o Al fine di rendere il sistema più robusto durante il trasporto e l’utilizzo tutti i

componenti sono stati saldati ad una basetta millefori e alloggiati in uno

scatola metallica.

3.3 - App

Lo studio di un'interfaccia semplice, intuitiva ma al contempo completa, richiede lo studio

dei casi d'uso per tutte le varie modalità e tutte le fasi di creazione del prospetto luci, nel

susseguirsi delle scene durante gli spettacoli.

A seguire un’immagine che mostra che l’intera applicazione è costituita di sole tre activity:

Fig.3.2 - Schema delle activity che compongono la GUI.

All’avvio dell’applicazione si presenta la schermata di selezione del device, quindi la

modalità a singolo canale, da cui è possibile passare alla modalità scene.

1 - Device List

Activity

2 - Single

Channels

Mode Activity

3 - Scenes

Mode Activity


Device List - richiama la lista di devices Bluetooth associati al

telefono e permette di richiamare l’apparecchio compatibile.

Una volta scelto il device, il codice Java inizializza l’Adapter e

il Socket Bluetooth, che gestiscono il modulo bluetooth del

telefono/tablet.

Fig.3.3 - Device List Activity

Modalità Single Channels - permette l’interazione con i

singoli canali DMX, mostrando nell’interfaccia una SeekBar

per ogni canale. L’utente potrà creare la propria scena luci

settando i vari valori secondo le proprie esigenze, per poi poter

salvare i livelli in una nuova Scena.

I dati vengono memorizzati in un database SQLite.

Per rendere più semplice l’utilizzo su smarphone di un elevato

numero di canali, questi sono stati divisi in più pagine da 12

elementi, scorribili coi tasti Prev e Next.

Fig.3.4 - Single Channels Activity


Modalità Scene - Mostra la lista delle scene create e ne

permette la miscelazione. Le scene possono essere intese come

insieme di tutti i canali ognuno con il proprio livello, o come

gruppi di canali comandati insieme. La creazione di gruppi di

canali consente di gestire le luci secondo le logiche delle piante

luci, quindi per settori di luce. Ad esempio su un palcoscenico

possono essere considerati “gruppi” l’insieme di tutte le luci

frontali, oppure tutti i controluce, o i tagli laterali, o anche le

luci posizionate perpendicolari al pavimento, dette “a pioggia”.

Tale concezione dei gruppi consente una creazione molto rapida

delle scene e un’altrettanto semplice gestione di esse in tempo

reale.

Fig.3.5 - Scenes Activity

All’apertura, l’activity legge i valori memorizzati nel database e da essi crea le varie

memorie.

3.4 - Interfaccia fisica, il Controller Bluetooth-DMX

Interfaccia fisica - Lato Software

Il programma per l’Arduino (viene chiamato “sketch”) è stato scritto con il suo IDE ufficiale,

alla versione 1.8.1 e sono state utilizzate le seguenti librerie:

SoftwareSerial.h (libreria ufficiale) per creare una porta parallela virtuale alla quale

collegare il modulo Bluetooth e non impegnare i pin 0 e 1, evitando così conflitti con

la comunicazione seriale via USB col computer durante il caricamento degli sketch;

DMXSerial.h, (scritta da Matthias Hertel - www.mathertel.de) che gestisce l’invio

seriale del segnale tramite protocollo RS-485, sfruttando sfruttando l’UART di

Arduino;

LiquidCrystal.h, (libreria ufficiale) come dice il nome, serve a gestire il display LCD.


Esso è composto dalle seguenti funzioni e dichiarazioni

- inclusione delle librerie

- dichiarazione delle variabili

- setup() : funzione di inizializzazione dei pin dell’Arduino, del display LCD e delle

variabili che gestiscono la comunicazione DMX

- loop() : funzione “main” dello sketch, essa gestisce tutto il sistema hardware e

richiama le varie funzioni nel programma secondo gli esiti di variabili di controllo

che confermano la riuscita o non riuscita dei vari passi.

- receiveValues() : legge i valori nel buffer della porta seriale ricevuti via bluetooth e,

se non sono corrotti, poi memorizza le coppie indirizzo-valore in variabili temporanee

- saveValues() : controlla che i valori ricevuti siano entro i range richiesti e che non

siano ridondanti. Se i dati sono corretti vengono memorizzati nell’array che verrà

trasmesso via DMX

- sendDmxValues() : per ogni coppia indirizzo-valore da trasmettere, onde evitare

ridondanze, la funzione controlla che esso non sia stato modificato dopo l’ultimo invio

dello stesso. Dopo di che chiama la funzione DMXSerial.write(indirizzo, valore) di

libreria, che invia i dati all’impianto luci e la funzione sendBluetoothValues(indirizzo,

valore) che invia i dati al device Android, dal quale si stanno ricevendo i dati.

- sendBluetoothValues() : utilizzata per inviare feedback all’applicazione Android,

utile a contrastare gli errori di comunicazione.

- refresh() : invia periodicamente un impulso di refresh all’impianto luci per evitare

che questo si disattivi per timeout del tempo di ricezione di segnale, tempo che varia

secondo la tipologia di apparecchi e la loro casa costruttrice, in genere tra i cinque e

i venti secondi. Sfrutta il counter della funzione millis() per l’invio di un segnale

neutro ogni due secondi.

Fig.3.6 - Lista delle funzioni, richiamate all’interno della funzione loop()

loop()

receiveValues()

saveValues()

sendDmxValues()

sendBluetoothValues()

refresh()


Interfaccia fisica - Lato Hardware

Componenti utilizzati

Un Arduino Nano v3 basato su processore ATMega328 con logica a 5V e 16MHz;

Un modulo bluetooth v2.0 HC-05;

Un integrato MAX485 per la comunicazione DMX;

Un Display LCD 16x2 per i feedback dell'Arduino, utile per il debugging in fase di

programmazione e per dare un feedback all’utente sullo stato di funzionamento.

Fig.3.7 - Immagine che riporta il collegamento del circuito su breadboard

3.5 - Comunicazione App - Interfaccia fisica Bluetooth-DMX

Si è dedicata molta attenzione alla qualità di trasmissione dei dati e alla loro integrità.

Sono state implementate e testate due modalità di invio dei segnali verso l’interfaccia

Bluetooth-DMX, ognuna con differenti pregi e difetti.

La comunicazione bluetooth avviene tramite porta seriale e attraverso tale i dati vengono

trasmessi e ricevuti byte dopo byte in maniera seriale. Inizialmente è stato sviluppato un

algoritmo di invio dei dati in maniera massiva, trasmettendo ciclicamente tutti i valori in

un unico grande pacchetto ogni volta che viene toccato un fader nell’Applicazione. A


valle, il microcontrollore nell’interfaccia hardware riceve uno per uno i byte discernendoli

tra valori numerici e caratteri per poter suddividere tutti i valori secondo i canali di

appartenenza.

Un pacchetto risulta quindi essere composto come segue

“ ! ” carattere iniziale

valore 1 compreso tra 0 e 255

“ – ” carattere di divisione




--- ---

--- ---


“ & ” carattere finale

assumendo quindi una forma simile alla seguente

“!255-0-110-50-0-280- …….. -0&”

Il numero di Byte trasmesso sarà quindi compreso tra 1026 e 2050.

! (0-)*512 & 1+(1+1)*512 +1 = 1026

! (255-)*512 & 1+(3+1)*512 +1 = 2050

Durante la fase di test, utilizzando solo il modulo bluetooth dell’interfaccia, questo

metodo si è rivelato efficace, in quanto circa il 95% dei dati ricevuti risultava corretto

(percentuale ottenuta inviando una serie di pacchetti e contando il numero di quelli

corrotti nel totale dei pacchetti inviati).

Una volta attivata la funzionalità DMX, il sistema si è rivelato veramente debole, in

quanto la libreria utilizzata DMXSerial.h sfrutta il protocollo USART e gli interrupt di

sistema. Ad ogni invio di dati si avrà quindi l’intervento di un interrupt che blocca

momentaneamente le operazioni del microcontrollore, tra cui quella di

memorizzazione nel buffer della comunicazione bluetooth in ingresso via porta seriale.

E’ stato fallimentare il tentativo di gestire i timing di disattivazione e riattivazione

degli interrupt prima e dopo la trasmissione DMX. Il processo di disattivazione e


riattivazione richiede numerosi millisecondi al microcontrollore, rallentando tutto il

sistema.

La seconda opzione di trasmissione adottata consiste nell’inviare una per volta le

coppie Indirizzo – Valore.

I nuovi pacchetti si presenteranno nel seguente modo:

“ ! ” carattere iniziale

indirizzo 1 - 512


valore 0 - 255

“ & ” carattere finale

assumendo quindi una forma simile alla seguente nel caso del valore di 255

all’indirizzo 12:

“!12-255&”

La lunghezza delle stringhe trasmesse sarà ora compresa tra 5 e 9 caratteri, quindi la

sequenza di Byte in ogni trasmissione è circa 100/200 volte più piccola del metodo

precedentemente descritto.

Qui si è cercato di snellire la comunicazione per diminuire la possibilità di dati corrotti

ed è stata implementata una richiesta, da parte del microcontrollore, di reinvio dei

pacchetti scartati. Si avrà quindi meno ridondanza in quanto vengono inviati solo i

valori relativi ai canali con la quale si è interagito nel device Android.

Maggiore affidabilità è stata raggiunta utilizzando, all’interno dell’app Android,

thread per l’invio e la ricezione dei dati bluetooth.

Ora i pacchetti, nonostante siano drasticamente ridotti in lunghezza, non sono

aumentati in quantità. Ragionevolmente quindi, a parità di singoli pacchetti che

comunque possono arrivare corrotti e quindi scartati, quelli corretti sono più che

centuplicati.


3.6 - Sviluppi futuri

Importanti punti da sviluppare saranno, secondo categoria:

Relativamente all’Applicazione per Smartphone-Tablet

o Sviluppo multipiattaforma dell’applicazione, anche per IOS e Windows Phone.

o Playback - registrazione in tempo reale di una sequenza di luci in un intervallo

di tempo, memorizzazione su database e riproduzione della registrazione

o Stack - Creazione della sequenza di tutte le scene dello spettacolo, riprodotte in

sequenza con un GO o con temporizzazione, prevedendo fade-in e fade-out

delle scene.

o Salvataggio e caricamento degli show - salvataggio su file degli show,

composti dall’insieme delle scene create e dallo stack e da eventuali

impostazioni personalizzate.

Interfaccia hardware

o Sviluppare una versione che sfrutta il Wifi e il protocollo ArtNet

o Sviluppare una versione dotata di più uscite DMX da 512 canali ciascuno,

magari quattro uscite per un totale di 2048 canali

o Qualora un Arduino non dovesse riuscire a gestire le funzionalità sopra

riportate, sviluppare una versione sostituendo l’Arduino Nano con un

Raspberry PI Zero W, di dimensioni comunque contenute ma dotato di

maggior capacità di calcolo e già dotato di moduli Bluetooth e Wifi.


4. Conclusioni

La realizzazione di un prodotto a livello professionale richiede lo sviluppo di una piattaforma

robusta, stabile e affidabile in ogni situazione. Esso necessita di brevetti, certificazioni,

attrezzature industriali di fabbricazione e una struttura software capace di gestire ogni

possibile problema e garantire continuità nel lavoro.

Il progetto descritto in questa tesi è ben lontano da poter essere definito professionale. Esso

vuole essere stimolo al continuare ad ideare, concettualizzare, realizzare ciò di cui abbiamo

bisogno e ciò che la fantasia ci spinge a costruire.

Negli ultimi anni lo sviluppo “Embedded” si è diffuso in tutto il mondo tra hobbisti, artisti,

appassionati di elettronica e programmazione, anche inesperti. Si sono formate comunità di

sviluppatori che condividono le proprie idee e i risultati dei propri lavori, mettendoli a

disposizione di chiunque voglia replicarli, modificarli o migliorarli, nella filosofia dell’

“open-source”. Complice è poi il mercato dell’elettronica, che propone a prezzi bassissimi

microcontrollori e microcomputers, e con essi le cosidette “shield”, schede di espansione

ideate dalla comunità che permettono di aggiungere i componenti hardware necessari a

determinate funzionalità, come driver per motori, comunicazione wireless, display, pulsanti

per videogiochi, moduli GSM, Ehternet, led e tante altre.

Tutto questo ci consente di creare nuovi device: i nostri personali devices, con le funzionalità

che vogliamo e che possano interfacciarsi con sistemi già esistenti, utilizzare i loro standard,

aggiungerne delle funzionalità.

E’ dalla realizzazione delle piccole idee che prendono vita i grandi progetti.


5. Bibliografia

[1] American National Standard E1.11 – 2008 (R2013)

Entertainment Technology USITT DMX512-A Asynchronous Serial Digital Data

Transmission Standard for Controlling Lighting Equipment and Accessories CP/2007-

1013r3.1 - ANSI E1.11-2008 (R2013) - Pag. xii


[2] http://imimot.com/blog/lighting-for-beginners-dmx-and-art-net - Imimot Kft 09/14/2015

[3] http://www.radio-electronics.com/info/processing-embedded/embedded-

systems/microcontroller-mcu-systems.php - Ian Poole

[4] https://www.arduino.cc/en/Guide/Introduction

[5] http://sisinflab.poliba.it/scioscia/resources/Bluetooth_intro.pdf - Floriano Scioscia -

SisInfLab

Università degli Studi di Cagliari -...

Documents

Transcript of Università degli Studi di Cagliari -...