UTILIZZO DI WIIMOTE E BALANCE BOARD COME STRUMENTO PER LA RIABILITAZIONE IN APPLICAZIONI REALIZZATE CON IL FRAMEWORK XNA - DISTA
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
POLITECNICO DI MILANO
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA IN INGEGNERIA INFORMATICA
UTILIZZO DI WIIMOTE E BALANCE BOARD
COME STRUMENTO PER LA RIABILITAZIONE
IN APPLICAZIONI REALIZZATE CON IL FRAMEWORK XNA
Relatore: Prof. Alessandro CAMPI
Correlatore: Ing. Paola SPOLETINI
Tesi di Laurea di:
Enrico BONTEMPI
Matricola n. 704443
Roberto CARETTONI
Matricola n. 704099
ANNO ACCADEMICO 2009-2010
1
Indice
Indice .................................................................................................................................2
Capitolo 1. Introduzione.................................................................................................5
Capitolo 2. L’innovazione di Nintendo Wii ....................................................................6
Capitolo 3. Il Wiimote [4] ..............................................................................................7
3.1 Pulsanti ................................................................................................................8
3.2 Accelerometro .....................................................................................................9
3.2.1 Accelerazione statica e dinamica ...................................................................9
3.2.2 Interpretazione dei valori rilevati ................................................................10
3.2.3 Calcolo delle inclinazioni degli assi ............................................................10
3.3 Puntamento Infrarosso .......................................................................................12
3.3.1 Sensor Bar ..................................................................................................12
3.3.2 Tecnica di puntamento ................................................................................13
3.3.3 Posizione di puntamento .............................................................................13
3.3.4 Levigatura del cursore.................................................................................14
3.4 Altre funzionalità ...............................................................................................15
3.4.1 LED ............................................................................................................15
3.4.2 Rumble .......................................................................................................15
3.4.3 Speaker .......................................................................................................15
3.5 Estensioni ..........................................................................................................16
3.5.1 Nunchuk .....................................................................................................16
3.5.2 Classic Controller .......................................................................................17
3.5.3 Wii Motion Plus ..........................................................................................17
3.5.4 Wii Balance Board ......................................................................................18
Capitolo 4. Interfacciamento e connessione dei dispositivi ...........................................19
4.1 HID [5] ..............................................................................................................19
4.1.1 L’innovazione di HID .................................................................................19
4.1.2 Il protocollo HID ........................................................................................20
4.1.3 Bluetooth HID ............................................................................................20
4.2 Bluetooth [6]......................................................................................................21
2
4.2.1 BlueSoleil [7] .............................................................................................21
4.2.2 Connessione del Wiimote ...........................................................................22
4.3 Wiimotelib .........................................................................................................24
4.3.1 Creazione del canale di comunicazione .......................................................24
4.3.2 Trasmissione dei pacchetti ..........................................................................26
Capitolo 5. Ambiente di Sviluppo .................................................................................28
5.1 Microsoft Visual Studio 2008 [12] .....................................................................28
5.2 C# [13] ..............................................................................................................28
5.3 Il Framework XNA [15].....................................................................................29
5.4 Struttura di un progetto XNA [16]......................................................................29
5.4.1 Metodi predefiniti .......................................................................................30
5.4.2 Componenti ................................................................................................30
5.4.3 Grafica 2D ..................................................................................................31
5.5 Audio .................................................................................................................32
5.5.1 XACT .........................................................................................................32
5.5.2 Classe statica Audio ....................................................................................32
5.6 Requisiti di piattaforma ......................................................................................34
Capitolo 6. Ideazione del software ................................................................................35
6.1 Specifiche del software ......................................................................................35
6.1.1 Design della batteria ...................................................................................35
6.1.2 Criteri di movimento ...................................................................................36
6.1.3 Composizione e disegno della batteria ........................................................39
6.1.4 Determinazione e controllo della posizione del centro di massa ..................40
6.1.5 Fase di gioco ...............................................................................................41
6.1.6 Modalità Free .............................................................................................42
Capitolo 7. Gestione del Wiimote con Wiimotelib ........................................................43
7.1 La classe Wiimote..............................................................................................43
7.1.1 Metodi ........................................................................................................44
7.1.2 Eventi .........................................................................................................44
7.1.3 WiimoteCollection ......................................................................................44
7.2 Le strutture dati..................................................................................................45
7.3 Eccezioni ...........................................................................................................47
3
7.4 Implementazione della classe WiiMote ..............................................................47
7.4.1 Metodi della classe WiiMote.......................................................................48
Capitolo 8. Implementazione del videogame ................................................................49
8.1 La classe DrumAble ...........................................................................................50
8.1.1 Modalità di esecuzione ...............................................................................51
8.1.2 Compiti della classe DrumAble...................................................................51
8.2 I componenti della sezione menu .......................................................................52
8.2.1 La classe Menu ...........................................................................................52
8.2.2 La classe Istruzioni .....................................................................................52
8.2.3 La classe Tracklist ......................................................................................52
8.2.4 La classe Speed...........................................................................................53
8.2.5 La classe RiproduzioneSequenza ................................................................53
8.3 Le tracce predefinite ..........................................................................................53
8.3.1 La classe Traccia ........................................................................................53
8.3.2 I DataSet .....................................................................................................54
8.4 L’input della fase di gioco ..................................................................................54
8.4.1 La classe Percussione ..................................................................................54
8.4.2 Rilevamento dei gesti..................................................................................55
8.4.3 Evento PercussioneChanged .......................................................................55
8.4.4 La classe BalanceBoard ..............................................................................55
8.5 I componenti della fase di gioco .........................................................................56
8.5.1 La classe PlayScreen ...................................................................................56
8.5.2 La classe Logica .........................................................................................57
Capitolo 9. Sviluppi futuri.............................................................................................58
Elenco figure ...................................................................................................................59
Elenco Tabelle .................................................................................................................59
Bibliografia ......................................................................................................................60
4
Capitolo 1. Introduzione
Nel 2006 Nintendo lancia la console Wii [1], appartenente alla settima generazione [2], la
cui innovazione è insita nella nuova natura dei controller, che non sono più dei semplici
telecomandi che permettono di comandare i giochi soltanto premendo dei pulsanti, ma
dispositivi in grado di rilevare il movimento del corpo o di alcune sue parti rendendo così
possibile un’associazione tra gesti compiuti dai giocatori e azioni di risposta all’interno dei
videogame.
Questo lavoro si colloca in un più ampio progetto di sviluppo di applicazioni rivolte a
soggetti con disabilità motorie [3], quali individui paraplegici. Tale progetto consiste nella
creazione di videogiochi con finalità terapeutiche, con l’intento cioè di intrattenere gli
utenti stimolandoli a compiere determinati movimenti, introducendo così l’uso di questi
software ad esempio nella riabilitazione post-trauma. Grazie alle loro caratteristiche, i
controller di Wii si prestano particolarmente a questo ambito di progetto, e sono l’ideale
strumento di interazione con l’utente in applicazioni di questo genere.
L’obiettivo di questo lavoro è sfruttare la tecnologia del Wiimote e della Balance Board
mediante la creazione di interessanti applicazioni indipendenti dai pulsanti e governabili il
più possibile attraverso i movimenti di un Wiimote e il rilevamento del baricentro tramite
la Balance Board. Il prodotto di questo lavoro è un software che simula una batteria
musicale, utilizzabile mediante il compimento di diversi gesti con il Wiimote, stando seduti
sulla Balance Board.
Questo progetto permette di estendere l’ambito dei lavori svolti in passato, che si
concentravano principalmente sull’equilibrio e sul movimento del busto mediante l’uso
esclusivo della Balance Board, all’utilizzo degli arti superiori.
5
Capitolo 2. L’innovazione di
Nintendo Wii
Le innovazioni introdotte con Nintendo Wii [1] aprono varie frontiere nel videogaming in
quanto l’utilizzo di movimenti come input per i giochi permette di modellare in maniera
molto più naturale le interazioni con l’utente. Diventa così possibile simulare i gesti
compiuti in discipline sportive, nell’uso di strumenti musicali o di utensili attraverso i
telecomandi di Wii, e introdurre tutte queste attività in svariati videogame che riscuotono
notevole successo.
Il controller principale della console Wii è il Wiimote; è un telecomando senza fili che
comunica con la console attraverso la tecnologia Bluetooth. Il Wiimote è dotato di
pulsanti, di un accelerometro in grado di rilevare i movimenti impressi al telecomando, e di
altri dispositivi che consentono l’interazione sia per l’input che per l’output.
Al Wiimote possono essere collegati mediante un apposito connettore altri controller tra
cui: Nunchuk, Classic Controller, WiiMotionPlus, chitarra e batteria di Guitar Hero e altri.
Questi dispositivi vengono identificati dalla console come estensioni del controller
principale, e il flusso di informazioni trasmesse relativo ad un’estensione viene inglobato
nelle informazioni del Wiimote. È possibile collegare una sola estensione al Wiimote, a
meno che si tratti del WiiMotionPlus, che dispone di un connettore per estensioni, agendo
così in modo “trasparente” e permettendo l’inserimento di una seconda estensione.
Un altro controller di Wii è la Wii Balance Board; è una pedana che comunica via
Bluetooth con la console attraverso lo stesso protocollo utilizzato dal Wiimote, ma che
differisce da quest’ultimo come tecnologia interna in quanto è composta da quattro bilance
che rilevano lo spostamento del peso dell’utente che si posiziona sopra di essa.
6
Capitolo 3. Il Wiimote [4]
Il controller di Nintendo Wii utilizza un approccio di interazione differente da quello
tradizionale, nel tentativo di risultare interessante per un pubblico più vasto. Il Wiimote ha
la forma di un comune telecomando da televisione e viene tenuto in una sola mano;
Essendo simmetrico, appare ugualmente utilizzabile da destrorsi e mancini.
Il componente principale del Wiimote è il chip Broadcom; esso è dotato di alcuni registri e
di un microcontrollore, attraverso cui gestisce il flusso interno dei dati (input e output dalle
periferiche interne) e le trasmissioni con la console. Il chip fa da riferimento per gli altri
componenti interni al dispositivo, in quanto la struttura del Wiimote è progettata intorno ad
esso.
Vi sono due funzionalità di input direttamente controllate dal chip: un accelerometro a tre
assi e 11 pulsanti (più il pulsante Power). In aggiunta, il telecomando, contiene un
ricevitore infrarosso con un processore di monitoraggio oggetti, una porta d’espansione che
permette di collegarvi fonti di input addizionali (le estensioni), uno speaker e un “rumble
pack” che consente al telecomando di vibrare.
Figura 1: Wiimote
73.1 Pulsanti
Il Wiimote ha 11 pulsanti sul lato frontale e uno sul retro; tra questi, il pulsante Power è
speciale ed è considerato differentemente dagli altri dal dispositivo. Tutti gli altri pulsanti
sono indipendentemente accessibili attraverso un pacchetto di 2 byte che viene trasmesso
per primo nella maggior parte dei report. Il bit corrispondente ad un pulsante assumerà
valore 1 se il pulsante è premuto oppure 0 in caso contrario. Di norma questi pacchetti
vengono inviati quando lo stato di qualche pulsante cambia, ma è anche possibile
configurare il Wiimote affinché invii lo stato dei pulsanti continuamente attraverso
un’alterazione del Data Reporting Mode.
I pulsanti dei Wiimote sono i seguenti: A, B (retro), un Pad direzionale, +, -, Home, 1 e 2.
Quando il Wiimote è spento, la pressione del pulsante Power provoca un tentativo di
riattivazione della comunicazione con la Wii a cui è sincronizzato. I dettagli
implementativi che portano all’accensione non sono stati resi pubblici e sono contenuti nel
modulo Bluetooth di Wii. La connessione del telecomando con un diverso host (pc) non
può invece avvenire automaticamente ma occorre ripetere il procedimento di connessione
dal software Bluetooth dell’host. Se il Wiimote è acceso e connesso a un host, la pressione
e il mantenimento del pulsante Power per qualche secondo fa sì che il telecomando
richieda una disconnessione dall’host e si spenga.
Vi è inoltre un ulteriore pulsante nascosto nel vano batterie: il Sync Button. Alla pressione
di tale tasto il Wiimote si disconnette dall’host con il quale ha una connessione attiva e si
pone in modalità di rilevazione accettando richieste di connessione o accoppiamento per
esattamente 20 secondi.
83.2 Accelerometro
Il Wiimote contiene un accelerometro lineare a tre assi posto sulla faccia superiore della
base del circuito interno, leggermente a sinistra del pulsante A. Si tratta di un componente
integrato semplicemente saldato al circuito: l’ADXL330 di Analog Devices. Questo
dispositivo può misurare l’accelerazione di gravità statica per applicazioni che
percepiscono l’inclinazione, così come l’accelerazione dinamica derivante da movimenti,
scosse o vibrazioni.
La misurazione avviene con valore minimo di fondo scala di ±3g e una sensibilità del 10%.
3.2.1 Accelerazione statica e dinamica
Poiché il funzionamento reale dell’accelerometro consiste nella misura della forza
esercitata da un insieme di piccole masse di resistenza poste al suo interno nei confronti del
guscio che le contiene, esso misura un’accelerazione lineare di un punto di riferimento in
caduta libera: questo significa che se il Wiimote fosse in caduta libera, riporterebbe
accelerazione zero. Quand’è immobile invece, rileva un’accelerazione pari
all’accelerazione di gravità g (ma nella direzione opposta, verso l’alto, +Z quando è fermo
in posizione orizzontale). Questo dato può essere usato per intuire l’inclinazione del
telecomando dagli output di accelerazione quando il Wiimote è ragionevolmente fermo.
Figura 2: Wiimote e assi direzionali
93.2.2 Interpretazione dei valori rilevati
La Figura 2 rappresenta il Wiimote e gli assi di riferimento dell’accelerometro:
l’orientamento degli assi permette di interpretare il valore letto per ognuno di essi e
dedurne l’inclinazione rispetto alla posizione piana (orizzontale) oppure la direzione del
movimento dell’accelerazione rilevata. Durante la fase sperimentale di studio del Wiimote
si è notato che non tutti i movimenti vengono rilevati, ma il valore relativo ad un asse varia
soltanto se tale asse si muove ruotando in un piano, necessariamente ortogonale al suolo,
che lo contiene. Ad esempio il movimento rotatorio del polso, mantenendo il telecomando
in posizione orizzontale, può essere modellizzato come la rotazione del piano XZ intorno
all’asse Y che funge da perno; tale movimento può essere rilevato dalle variazioni dei
valori dei tre assi, riconoscendo una variazione positiva o negativa dei valori di X e Z (a
seconda che la rotazione sia avvenuta in senso orario o antiorario) e una conservazione del
valore precedente di Y.
Al contrario, un movimento rotatorio del telecomando appoggiato su un piano (rotazione
del piano XY con perno l’asse Z) non può essere rilevato in quanto l’asse Z funziona da
perno e quindi non subisce scostamenti, e nonostante gli assi X e Y stiano effettivamente
ruotando, non ne viene riscontrata una variazione dei valori in quanto il piano da essi
costituito è parallelo al suolo e non ortogonale, quindi anche ripetendo o velocizzando il
movimento l’accelerometro non rileverebbe variazioni: come se il telecomando fosse
fermo.
3.2.3 Calcolo delle inclinazioni degli assi
Come conclusione allo studio del funzionamento dell’accelerometro nell’ambito
dell’accelerazione statica, si è cercata una formula che permettesse di tradurre i valori letti
dal dispositivo nelle rispettive inclinazioni degli assi corrispondenti, interpretate come
sfasamenti da una posizione base, e cioè un angolo di 0° equivalente a una posizione
orizzontale, parallela al suolo, dell’asse.
A seconda dell’inclinazione dell’asse, il valore letto dal telecomando assume valori
compresi tra +1 e -1. Definito l’orientamento degli assi come mostrato in Figura 2, si è
10messo in relazione il valore letto con la posizione dell’asse, raggiungendo le conclusioni
seguenti:
• Se l’asse (X, Y, Z) si trova in posizione orizzontale, e cioè ortogonale alla direzione
della forza di gravità, il valore rilevato è 0
• Se l’asse si trova nella stessa direzione della forza di gravità e con verso concorde
(verso il basso), il valore rilevato è -1
• Se l’asse si trova nella stessa direzione della forza di gravità ma con verso discorde
(verso l’alto), il valore rilevato è +1
Ponendo a questo punto gli angoli corrispondenti alle posizioni limite (aventi la direzione
della forza di gravità con verso concorde o discorde) rispettivamente -90° e +90°, si può
scrivere la seguente equazione che mette in relazione angoli e valori (fissati da un’ipotesi
teorica) di due posizioni limite:
(Y90° - Yα) : (Y90° - Y0°) = (90° - α) : (90° - 0°)
È un’interpolazione lineare dove:
• Y90° indica il valore di Y letto quando l’asse Y si trova a +90° (Y90° = -1)
• Yα indica il valore di Y letto quando l’asse Y si trova all’angolo α
• Y0° indica il valore di Y letto quando l’asse Y si trova a 0° (Y90° = 0)
• α è l’angolo corrispondente al valore dell’asse Y letto (Yα)
Da questa interpolazione si può ricavare la formula finale:
α = -90° · Yα
Che permette effettivamente di identificare in modo univoco l’angolo (di sfasamento)
corrispondente al valore dell’asse letto.
In Figura 2 sono indicati anche tre movimenti che in realtà non sono rilevabili dal Wiimote
ma possono essere individuati se si dispone del WiiMotionPlus, che verrà successivamente
trattato nella sezione estensioni.
113.3 Puntamento Infrarosso
Il Wiimote contiene un ricevitore monocromo 128x96 con un elaboratore d’immagine
integrato. Il ricevitore si presenta come un filtro infrarosso nella custodia di plastica del
telecomando. L’elaboratore d’immagine è capace di puntare fino a quattro oggetti in
movimento, e questi sono gli unici dati che trasmette all’host; i dati relativi ai pixel grezzi
“visti” dalla telecamera non sono raggiungibili dall’host, pertanto il ricevitore non può
essere usato per catturare immagini. Il processore integrato effettua un’analisi sub pixel 8x
per fornire una risoluzione 1024x768 dei punti tracciati.
3.3.1 Sensor Bar
La Wii dispone di una Sensor Bar contenente due gruppi di LED IR (infrarossi), che
vengono tracciati dal Wiimote per fornire informazioni sul puntamento. La distanza tra i
centri dei gruppi di LED è 20cm. La Sensor Bar non svolge nessun compito se non quello
di supporto e alimentazione (tramite un cavetto particolare che la collega alla console) ai
LED IR: funge in pratica soltanto da emettitore infrarosso.
I LED IR costituiscono i punti di riferimento per il ricevitore infrarosso del Wiimote:
questa correlazione permette di sfruttare un tecnica di puntamento nelle applicazioni; i
valori letti vengono spesso elaborati e convertiti ad esempio per l’uso di un cursore
governato dal movimento del telecomando.
Figura 3: Sensor Bar
123.3.2 Tecnica di puntamento
La prospettiva derivante dalla combinazione degli angoli (verticale e orizzontale) tra il
ricevitore e la Sensor Bar, può far apparire quest’ultima in una posizione in cui non si trova
realmente, ma attraverso semplici relazioni trigonometriche è possibile individuare lo
sfasamento degli angoli tra gli emettitori e il ricevitore.
Il primo passo dell’algoritmo di puntamento è la localizzazione della Sensor Bar. Poiché
potrebbero essere presenti fonti IR spurie, si rivela indispensabile individuare con
precisione i due punti che più probabilmente corrispondono alla Sensor Bar. Per far questo
si cercano due punti orizzontalmente allineati distanziati da uno spazio minimo predefinito
(per rimuovere ogni possibile riferimento duplicato se il Wiimote rilevasse più punti
raggruppati intorno ad un emettitore IR), usando l’inclinazione calcolata
dall’accelerometro per determinare qual è il piano orizzontale cui riferirsi. Le coppie
contraddistinte da un margine di sfasamento dal piano orizzontale superiore ai 10° vengono
scartate. Tra le rimanenti coppie, vengono scelte le due che più si avvicinano al piano
orizzontale; una coppia di punti con un terzo punto molto vicino alla linea immaginaria tra
di essi viene scartata, in quanto non è possibile che vi sia un emettitore IR tra gli estremi,
pertanto quella coppia non può essere la Sensor Bar.
Se il Wiimote smarrisce il puntamento di una delle estremità, che può scomparire dalla
vista una volta avvicinatosi ai bordi dell’area di puntamento o quando ne esce, il
telecomando tenta di proseguire usando il solo punto rimanente cercando di intuire la
posizione del punto scomparso, ad esempio usando i valori della distanza (fissa) tra i due
punti e i valori dell’accelerometro per calcolare l’angolo.
3.3.3 Posizione di puntamento
Noti i due punti della Sensor Bar, viene ruotato il campo del sensore per farli apparire in
allineamento orizzontale (usando i valori dell’accelerometro per assicurare di essere
nell’esatto quadrante, ad esempio se il Wiimote fosse sottosopra). Si può probabilmente
applicare almeno un filtro di base di movimento medio per ridurre gli scatti. Una volta
mappata la Sensor Bar in un sistema di coordinate orizzontali, si può semplicemente
calcolare la posizione intermedia tra i due punti e usarla per calcolare la posizione del
13puntatore definendo un quadro per mappare lo schermo su di esso. La posizione di questo
quadro può variare a seconda del luogo di posizionamento della Sensor Bar (sopra o sotto
lo schermo). Il quadro dovrebbe essere proporzionatamente dimensionato in modo da
accomodare più angoli senza aree morte. Una posizione di puntamento approssimata può
essere calcolata mediante l’uso delle seguenti formule:
Rotation = Math.Atan2(Accelerometer.Z, Accelerometer.X) - (float)(Math.PI / 2.0);
Position = (1 - Midpoint.x, Midpoint.y);
Position.Subtract(0.5,0.5);
Position.Rotate(Rotation);
Position.Add(0.5,0.5)
Se il punto intermedio non fosse disponibile si può usare il punto rimanente e comparare la
sua posizione corrente con la sua posizione quando entrambi i punti erano visibili.
3.3.4 Levigatura del cursore
La conversione dei dati rilevati dal ricevitore IR in informazioni per il posizionamento di
un cursore nello schermo consente a diverse applicazioni di sfruttare la tecnica di
puntamento nel loro funzionamento. Questa tecnica risulta particolarmente vantaggiosa nei
menu e nelle GUI; per queste applicazioni sarebbe auspicabile un filtraggio della posizione
del cursore. Una strategia per questo scopo è l’implementazione di uno schema circolare
trascinabile; Il software disegna un cerchio immaginario attorno alla nuova posizione
puntata; se il cursore si sposta al di fuori del cerchio, viene immediatamente trascinato al
suo interno. In ogni caso, se il cursore si trova già all’interno del cerchio, si muoverà in
direzione del centro ad una velocità proporzionale alla distanza dal centro. Questa tecnica
“leviga” il movimento del cursore e fa si che alcune piccole vibrazioni fisiche non
muovano drasticamente il cursore, consentendo comunque piccole correzioni.
Un’altra opzione è un algoritmo che corregge più attentamente la posizione quando il
Wiimote si muove lentamente e dà maggiore tolleranza in corrispondenza di movimenti
veloci. L’aspetto complesso di questo metodo sta nella difficoltà di apporto di piccole
correzioni quando il telecomando viene mosso di pochi pixel.
143.4 Altre funzionalità
3.4.1 LED
Sul lato frontale del Wiimote sono presenti quattro LED azzurri. Durante la modalità di
rilevazione e prima dell’inizializzazione, questi LED lampeggiano assieme. Il numero dei
LED che lampeggiano è proporzionale alla tensione sulla batteria, e indica la carica delle
pile (tutti e quattro indicano batterie completamente cariche, e un led soltanto indica che le
batterie stanno per esaurirsi e andrebbero sostituite). Il Wiimote è alimentato da due pile di
tipo AA. Quando il Wiimote è sincronizzato alla console, uno dei LED è acceso e indica il
numero giocatore assegnato dalla console al telecomando (fino a quattro giocatori). I LED
sono comunque indipendentemente controllabili dall’host, e possono essere accesi o spenti
a piacimento dal software. I LED possono anche essere modulati ad una comunque
moderata alta frequenza, abilitando un controllo di luminosità occupando però parecchia
banda Bluetooth. I LED sono montati sulla parte superiore del circuito, alimentati a 2.66 V
DC.
3.4.2 Rumble
Il Wiimote include una funzionalità di vibrazione, la cui implementazione consiste in un
piccolo motore unito a un peso decentrato (Rumble Pack). Il motore può essere attivato o
fermato attraverso un Output Report. Non tutti i Wiimote montano lo stesso motore; uno di
questi è il SEM 8728DA, alimentato a 3.3 V DC e a 35 mA.
3.4.3 Speaker
Il telecomando contiene un piccolo altoparlante di 21 mm piezo-elettrico di bassa qualità,
usato per brevi effetti sonori durante il gioco. I suoni provengono direttamente dall’host e
lo speaker ha qualche parametro regolabile. L’altoparlante è controllato tramite tre Output
Report assieme a una sezione del registro indirizzi del Wiimote.
153.5 Estensioni
Il Wiimote dispone di un connettore d’espansione a 6 pin che consente di connettervi
periferiche esterne. La comunicazione è bi-direzionale seriale e sincrona (il protocollo è
sconosciuto); le estensioni forniscono un blocco virtuale di registro mappato in una
porzione dello spazio indirizzi del Wiimote; la comunicazione è crittografata. I dispositivi
qui elencati sono tutte estensioni del Wiimote ad esso connesse tramite il connettore di cui
sopra, fatta eccezione per la Balance Board che comunica direttamente con l’host via
Bluetooth.
3.5.1 Nunchuk
È un telecomando di forma ovoidale leggermente più piccolo del Wiimote, dotato di un
accelerometro a tre assi simile a quello del Wiimote, di un joystick analogico, due pulsanti
dorsali (C e Z) e un microcontroller. La posizione centrale del joystick viene calibrata al
collegamento del Nunchuk al Wiimote, con un meccanismo finora sconosciuto. I due
potenziometri (30KΩ) che controllano gli assi del joystick sono collegati in parallelo. Il
chip di controllo dell’accelerometro è il LIS3L02 di STMicroelectronics.
Figura 4: Nunchuk collegato al Wiimote
163.5.2 Classic Controller
È un controller tradizionale, utilizzabile come seconda scelta in giochi che lo supportano; è
provvisto di 15 pulsanti, due dei quali sono trigger analogici e forniscono sia lo stato di
“click” una misura della pressione ad essi impressa, e due joystick analogici.
Sul lato frontale del controller sono posizionati i joystick e 11 dei pulsanti standard: A, B, -
, Home, +, X, Y, Up, Down, Left, Right. Sul lato superiore si trovano i trigger e gli altri
due pulsanti: Z e L; sono posizionati in modo da essere premibili con gli indici.
I trigger (destro e sinistro) sono sensibili a forze; alla pressione di un trigger, un
meccanismo fa scorrere un potenziometro lineare da 30KΩ. Il meccanismo utilizza solo un
quarto della distanza massima percorribile dal potenziometro. Al termine di uno
spostamento derivante da una pressione viene chiuso uno switch; il trigger è considerato
premuto appieno quando viene chiuso anche lo switch in fondo al percorso del
potenziometro.
Tutti i sei potenziometri nel dispositivo (due relativi a ogni trigger e due per ognuno dei
joystick) sono collegati in parallelo.
3.5.3 Wii Motion Plus
È un accessorio che migliora le prestazioni del Wiimote rendendolo molto più preciso e
realistico. Esso permette di compiere movimenti con il telecomando che saranno mappati
1:1 dalla console; in pratica vengono recepiti tutti i movimenti 3D compiuti nello spazio,
rilevati con altissima precisione. Il dispositivo ha una propria porta d’espansione che
consente di collegarvi ad esempio un Nunchuk, permettendo così l’uso di entrambe le
estensioni.
Il Wii Motion Plus contiene due giro sensori: un giroscopio a due assi (IDG-600 di
InvenSense) per il rilevamento di Pitch e Roll, e un giroscopio monoasse (X3500W di
EPSON TOYOCOM) per il rilevamento di Yaw. L’uso combinato dei due giroscopi abilita
il dispositivo alla lettura della velocità angolare in tutti e tre gli assi, consentendo così un
orientamento completo. In Figura 2 sono rappresentati i movimenti Pitch, Roll e Yaw
rilevabili dal Wii Motion Plus.
173.5.4 Wii Balance Board
La Wii Balance Board è una pedana che comunica via Bluetooth direttamente con la
console. È composta da quattro bilance che rilevano lo spostamento del peso dell’utente
che si posiziona sopra di essa, permette quindi di usare gli spostamenti del corpo per
controllare le azioni di gioco. La Balance Board è effettivamente un’estensione nonostante
non la si possa collegare fisicamente al connettore del Wiimote, tuttavia è utilizzabile
anche in assenza di un Wiimote in quanto appare alla console come un Wiimote con un
“Balance Board extension controller” permanentemente connesso, e trasmette i propri dati
alla console in maniera del tutto simile ad un’estensione connessa a un Wiimote.
I dispositivi di misurazione della Balance Board sono quattro estensimetri, incorporati in
ciascuno dei piedini su cui la pedana poggia al suolo. Il principio di funzionamento di
questi sensori è la misura della resistenza elettrica di un sottile filo di metallo posto al loro
interno, che aumenta all’allungamento del filo; l’estensione del filo è proporzionale alla
sollecitazione (forza peso) che il sensore subisce.
Grazie alla disposizione dei sensori ai quattro angoli della pedana, questa periferica è in
grado di misurare l’indice di massa corporea, analizzare la posizione del baricentro e il
peso corporeo. Nella versione europea la Balance Board può sostenere fino a un peso di
150Kg. La trasmissione dei dati misurati è continua, e avviene con un rate di 60 fps.
Figura 5: Wii Balance Board
18Capitolo 4. Interfacciamento e
connessione dei dispositivi
In questo capitolo vengono esposte le tecnologie e i meccanismi mediante i quali avviene
la connessione tra i controller di Nintendo Wii e l’host (console o pc).
4.1 HID [5]
Gli Human Interface Device (HID) sono dispositivi che interagiscono direttamente con
l’utente. Sono tipicamente dispositivi di input, ma spesso emettono anche output. Il
termine HID viene spesso associato alla specifica USB-HID, termine coniato da Mike Van
Flandern (Microsoft) quando propose al comitato USB la creazione di un gruppo di lavoro
per lo sviluppo delle tecnologie dei dispositivi di input. Il gruppo venne rinominato e
nacque la Human Interface Device class, che denota la comunicazione bi-direzionale
supportata dallo standard.
Le motivazioni principali che portarono alla nascita di HID furono l’abilitazione di
innovazioni per i dispositivi di input e la semplificazione del processo di installazione di
tali dispositivi.
4.1.1 L’innovazione di HID
Prima della nascita di HID, i dispositivi di input erano tipicamente utilizzati mediante
protocolli restrittivi per mouse, tastiere e joystick. L’innovazione dell’hardware ha
richiesto modifiche a protocolli esistenti o la creazione di driver personalizzati con
conseguente pubblicazione di nuovi protocolli per gli sviluppatori di applicazioni.
I dispositivi HID rilasciano dei pacchetti autodescrittivi che potrebbero contenere
un’infinità di tipi di dati e formati. Un singolo driver HID installato in un PC analizza i dati
e abilita l’associazione dinamica di informazioni di I/O con le funzionalità applicative.
19Molti sistemi operativi possono riconoscere dispositivi USB-HID, come mouse o tastiere,
anche senza l’utilizzo di un driver, e in questo caso un dispositivo viene riconosciuto come
“HID-compliant device”.
4.1.2 Il protocollo HID
Il protocollo HID si compone di due entità: l’host e il device. Il device è l’entità che
interagisce direttamente con l’utente, mentre l’host comunica con il device ricevendo (o
trasmettendo) dati in risposta ad azioni compiute dall’utente. Gli host sono tipicamente pc,
ma possono anche essere telefoni cellulari, PDA e console.
Il protocollo HID traduce l’implementazione dei dispositivi in modelli molto semplici. I
dispositivi definiscono un proprio pacchetto dati e quindi presentano all’host un “HID
descriptor”, che contiene la descrizione del contenuto del pacchetto dati. Le informazioni
contenute nel descrittore sono: il numero di pacchetti supportati dal dispositivo, lo spazio
occupato da ogni pacchetto e il significato di ciascun byte nel pacchetto. Tipicamente
l’HID descriptor è memorizzato in una ROM all’interno del dispositivo.
L’host è un’entità molto più complessa del device. Ad esso spetta il compito di ricevere
l’HID descriptor dal device ed analizzarlo allo scopo finale di comunicare in modo
pienamente funzionale con il device.
4.1.3 Bluetooth HID
Il Bluetooth HID è una versione derivante dal protocollo HID definito per USB, alleggerita
e adattata alla tecnologia della trasmissione Bluetooth. Questo permette il riutilizzo di
alcune delle già esistenti funzionalità per USB-HID per il supporto di Bluetooth HID.
Il profilo HID descrive il modo in cui utilizzare il protocollo USB-HID per rilevare una
classe di driver USB-HID preesistente, dalla quale estrarre un set di funzionalità della
classe HID del dispositivo; il profilo descrive inoltre come un dispositivo Bluetooth
supporta servizi HID che sfruttano il livello L2CAP. Il profilo HID è progettato al fine di
abilitare, inizializzare e controllare dispositivi auto-descriventi e di fornire una connessione
a bassa latenza con bassi requisiti di alimentazione.
20Il Wiimote e la Balance Board usano entrambi allo stesso modo il protocollo Bluetooth
HID standard per comunicare con l’host, quello che cambia è l’identificativo con cui
vengono individuati e associati all’host: il Wiimote viene riconosciuto come “Nintendo
RVL-CNT-01”, mentre la Balance Board come “Nintendo RVL-WBC-01”.
4.2 Bluetooth [6]
Il Wiimote si interfaccia alla console mediante la tecnologia Bluetooth, grazie a un
dispositivo BCM2042 di Broadcom. Il Wiimote e la Balance Board utilizzano il protocollo
HID Bluetooth standard per comunicare con l’host, direttamente basato sull’USB HID
standard. Grazie a questa caratteristica essi possono essere rilevati come dispositivi di
input standard da un qualunque host Bluetooth, quale ad esempio un pc dotato di scheda di
rete Bluetooth o di un adattatore USB (una chiavetta Bluetooth). Viene quindi introdotta la
possibilità di utilizzare il Wiimote e la Balance Board come dispositivi di input per
applicazioni per pc, svincolandosi così da un loro uso esclusivo con la console Wii.
4.2.1 BlueSoleil [7]
I primi tentativi di connessione dei dispositivi al pc hanno esito positivo, ma mostrano una
carenza di affidabilità della connessione in quanto spesso essa si disattiva senza preavviso
e non garantisce una continuità della comunicazione tra l’host e il device. La soluzione a
questo problema è stata raggiunta con la sostituzione del software standard del sistema
operativo che gestisce la rete e i dispositivi Bluetooth con un software avanzato e provvisto
di migliori funzionalità.
Questo software è BlueSoleil di IVT; è un’applicazione che consente a pc abilitati
Bluetooth di collegarsi ad altre periferiche abilitate Bluetooth, ma anche di creare reti e
scambiare dati tra dispositivi.
21Figura 6: IVT Bluesoleil
Funzione Bluetooth (Profilo) Client Server
Advanced Audio Bluetooth √ √
Auricolare e microfono Bluetooth √
Connessione remota Bluetooth √
FAX Bluetooth √
Trasferimento file Bluetooth √ √
Periferica d'interfaccia umana (HID) Bluetooth √
OPP (Object Push) Bluetooth √ √
PAN (Personal Area Network) Bluetooth √ √
Stampa Bluetooth √
Porta seriale Bluetooth √ √
Tabella 1: Profili Bluetooth supportati da BlueSoleil
Come illustrato in Tabella 1, BlueSoleil dispone di diverse funzionalità operative sulle reti
Bluetooth. Il software consente la gestione delle reti sia nella erogazione dei servizi
(Server) che nell’accesso a servizi (Client).
4.2.2 Connessione del Wiimote
Il Wiimote viene rilevato dal software come Bluetooth HID (Joystick), e identificato
attraverso un id univoco; Esso non richiede alcuna autenticazione o cifratura,
l’interfacciamento consiste nella pressione contemporanea dei tasti 1 e 2 o del tasto rosso
di sincronizzazione all’interno del coperchio delle batterie, che porta il Wiimote nella
22modalità di rilevazione nella quale viene accoppiato all’host (console o pc) mediante il
driver Bluetooth-HID. A sincronizzazione avvenuta, il Wiimote dirige automaticamente i
propri pacchetti verso l’host a cui è accoppiato.
L’interfacciamento con la console Wii è automatico una volta che il Wiimote viene portato
in modalità di rilevazione, in quanto la console si accoppia automaticamente al dispositivo
e vi associa un indice da 1 a 4 (alla console si possono interfacciare fino a 4 Wiimote
contemporaneamente) che viene normalmente indicato dall’accensione di uno dei 4 led sul
dispositivo.
Per connettere il Wiimote a un pc è invece necessario anzitutto effettuare nel software
BlueSoleil una ricerca dispositivi Bluetooth: se il Wiimote si trova in modalità di
rilevazione, esso viene trovato, ma non accoppiato. Occorre mantenere il Wiimote nella
modalità di rilevazione e indicare al software di connettere l’host al dispositivo. Se
l’operazione ha esito positivo l’icona relativa al dispositivo diventa verde. In Figura 7 è
mostrata la notifica della fase di sincronizzazione del dispositivo.
Figura 7: Sincronizzazione Wiimote
Tuttavia il Wiimote è inutilizzabile dai driver standard HID in quanto non usa né la
tipologia standard di dati né lo stesso descrittore HID, ma si limita a fornire la lunghezza
del pacchetto, senza descriverne il contenuto; questo aspetto ha reso necessaria la
creazione di alcuni driver Wiimote.
Il Wiimote utilizza un set di operazioni abbastanza complesso, trasmesse tramite il canale
HID di output, e restituisce attraverso il canale di input differenti pacchetti contenenti dati
provenienti dalle sue periferiche interne.
La connessione della Balance Board avviene in modo del tutto analogo.
234.3 Wiimotelib
Wiimotelib è una libreria .NET sviluppata da Brian Peek [8], che consente ad una
applicazione .NET di interfacciarsi a un controller Wiimote e alle varie estensioni esistenti.
Diverse versioni di questa libreria sono disponibili su CodePlex [9]. Gli algoritmi mediante
i quali la libreria abilita la comunicazione con il dispositivo sono descritti nei paragrafi
seguenti [10].
4.3.1 Creazione del canale di comunicazione
Quando il Wiimote e la Balance Board vengono sincronizzati con il pc, sono identificati
come HID-compliant devices, ma i loro pacchetti non sono decodificabili. Pertanto, per
connettersi funzionalmente ai dispositivi, occorre utilizzare le API di Win32 per la
gestione dei dispositivi HID; queste API sono definite nel Windows Driver Kit (WDK).
Non essendo disponibile in .NET un supporto integrato per tali API, diventa necessaria
l’introduzione di uno strumento che permetta di chiamare direttamente i metodi delle API
da .NET: questo strumento è P/Invoke. La difficoltà di questo passaggio consiste nella
ricerca della corretta signature per ogni metodo e le definizioni delle strutture che
introducono propriamente i dati attraverso Win32. Wiimotelib è scritta in C#, e i metodi
inerenti P/Invoke sono contenuti nella classe HIDImports.
Il processo attraverso il quale la libreria apre la comunicazione con il Wiimote (o con la
Balance Board, che come detto è considerata a tutti gli effetti un Wiimote) si compone dei
seguenti passi:
1. Trovare il GUID della classe HID definita da Windows
2. Trovare un gestore della lista di tutti i dispositivi che fanno parte di tale classe
3. Enumerare l’insieme di questi dispositivi e ottenere informazioni dettagliate
riguardo ognuno di essi
4. Comparare Vendor ID e Product ID di ognuno dei dispositivi della classe con i già
noti VID e PID del Wiimote
5. Una volta trovata la classe corrispondente, creare un FileStream per ricevere o
inviare dati al dispositivo
6. Svuotare la lista dei dispositivi
24Viene qui riportato il codice C# che esegue i passaggi precedentemente descritti:
// read/write handle to the device
private SafeFileHandle mHandle;
// a pretty .NET stream to read/write from/to
private FileStream mStream;
bool found = false;
Guid guid;
uint index = 0;
// 1. get the GUID of the HID class
HIDImports.HidD_GetHidGuid(out guid);
// 2. get a handle to all devices that are part of the HID class
IntPtr hDevInfo = HIDImports.SetupDiGetClassDevs(ref guid, null, IntPtr.Zero,
HIDImports.DIGCF_DEVICEINTERFACE);// | HIDImports.DIGCF_PRESENT);
// create a new interface data struct and initialize its size
HIDImports.SP_DEVICE_INTERFACE_DATA diData = new HIDImports.SP_DEVICE_INTERFACE_DATA();
diData.cbSize = Marshal.SizeOf(diData);
// 3. get a device interface to a single device (enumerate all devices)
while(HIDImports.SetupDiEnumDeviceInterfaces(hDevInfo, IntPtr.Zero, ref guid, index, ref diData))
{
// create a detail struct and set its size
HIDImports.SP_DEVICE_INTERFACE_DETAIL_DATA diDetail = new
HIDImports.SP_DEVICE_INTERFACE_DETAIL_DATA();
diDetail.cbSize = 5; //should be: (uint)Marshal.SizeOf(diDetail);, but that's the wrong size
UInt32 size = 0;
// get the buffer size for this device detail instance (returned in the size parameter)
HIDImports.SetupDiGetDeviceInterfaceDetail(hDevInfo, ref diData, IntPtr.Zero, 0, out size,
IntPtr.Zero);
// actually get the detail struct
if(HIDImports.SetupDiGetDeviceInterfaceDetail(hDevInfo, ref diData, ref diDetail, size, out
size, IntPtr.Zero))
{
// open a read/write handle to our device using the DevicePath returned
mHandle = HIDImports.CreateFile(diDetail.DevicePath, FileAccess.ReadWrite,
FileShare.ReadWrite, IntPtr.Zero, FileMode.Open, HIDImports.EFileAttributes.Overlapped,
IntPtr.Zero);
// 4. create an attributes struct and initialize the size
HIDImports.HIDD_ATTRIBUTES attrib = new HIDImports.HIDD_ATTRIBUTES();
attrib.Size = Marshal.SizeOf(attrib);
// get the attributes of the current device
if(HIDImports.HidD_GetAttributes(mHandle.DangerousGetHandle(), ref attrib))
{
// if the vendor and product IDs match up
if(attrib.VendorID == VID && attrib.ProductID == PID)
{
25// 5. create a nice .NET FileStream wrapping the handle above
mStream = new FileStream(mHandle, FileAccess.ReadWrite, REPORT_LENGTH, true);
}
else
mHandle.Close();
}
}
// move to the next device
index++;
}
// 6. clean up our list
HIDImports.SetupDiDestroyDeviceInfoList(hDevInfo);
4.3.2 Trasmissione dei pacchetti
Nel mondo di HID, i dati vengono trasmessi sotto forma di report, sono cioè blocchi di dati
di lunghezza predefinita e fissa con un header che descrive il report contenuto nel blocco.
Il Wiimote trasmette e riceve vari report, ognuno dei quali ha una lunghezza di 22 byte.
Una volta creato il FileStream su cui comunicare con il Wiimote, è possibile aprire la
trasmissione dei dati. Poiché i report saranno trasmessi e ricevuti quasi sempre in modo
continuo, è essenziale l’uso di operazioni di I/O asincrone; in .NET questo è
particolarmente semplice. Il processo consiste nell’avviare un’operazione asincrona di
lettura e fornire un metodo di risposta quando il buffer si riempie; terminato il metodo di
risposta, i dati sono stati manipolati e il processo può essere ripetuto.
// report length
private const int REPORT_LENGTH = 22;
// report buffer
private byte[] mBuff = new byte[REPORT_LENGTH];
private void BeginAsyncRead()
{
// if the stream is valid and ready
if(mStream.CanRead)
{
// create a read buffer of the report size
byte[] buff = new byte[REPORT_LENGTH];
// setup the read and the callback
mStream.BeginRead(buff, 0, REPORT_LENGTH, new AsyncCallback(OnReadData), buff);
}
}
private void OnReadData(IAsyncResult ar)
{
26// grab the byte buffer
byte[] buff = (byte[])ar.AsyncState;
// end the current read
mStream.EndRead(ar);
// start reading again
BeginAsyncRead();
// handle data....
}
Questo è il codice sufficiente ad aprire e avviare la comunicazione con il Wiimote. Il resto
del codice comporta l’analisi dei dati ricevuti dal dispositivo e l’invio di dati
adeguatamente formati al Wiimote. Si può inviare un qualunque comando al Wiimote
attraverso il seguente codice:
mStream.Write(mBuff, 0, REPORT_LENGTH);
27Capitolo 5. Ambiente di Sviluppo
L’ambiente di sviluppo dell’applicazione è XNA Game Studio 3.1, estensione di Microsoft
Visual Studio. Il linguaggio di programmazione utilizzato è C#.
È stato possibile utilizzare l’edizione 2008 Professional di Visual Studio grazie alla licenza
studenti per il Politecnico di Milano distribuita dall’MSDN Academic Alliance [11].
5.1 Microsoft Visual Studio 2008 [12]
È un IDE (Integrated Development Environment) di Microsoft, con nome in codice Orcas,
ed è uno strumento rivolto a sviluppatori di piattaforme Windows e .NET Framework 3.
Incorpora svariati linguaggi di programmazione tra i quali VB.NET, C#, C++ e altri
ancora. Offre inoltre la possibilità di creare applicazioni e servizi Web ASP.NET. Visual
Studio 2008 richiede il .NET Framework 3.5 che è stato rilasciato assieme all’IDE il 19
Novembre 2007, e per default compila su tale framework le applicazioni ma supporta
anche la compilazioni degli assembly nelle versioni precedenti del framework. Il debugger
di Visual Studio include funzionalità che semplificano il debug di applicazioni multi-
thread.
5.2 C# [13]
C# (C Sharp) è un linguaggio di programmazione Object-Oriented sviluppato da Microsoft
all’interno dell’iniziativa .NET, e successivamente approvato come standard ECMA
(associazione attualmente responsabile per molti standard).
La sintassi del codice C# prende spunto da Delphi [14] (del medesimo autore, Anders
Hejlsberg), da C++, da Java e Visual Basic per gli strumenti di programmazione visuale e
per la semplicità.
C# è il linguaggio che meglio descrive le linee guida del funzionamento di un’applicazione
.NET; i suoi tipi di dati primitivi hanno una corrispondenza univoca con i tipi .NET e
molte delle sue astrazioni come classi, interfacce, delegati ed eccezioni sono
particolarmente adatte a gestire il .NET Framework.
285.3 Il Framework XNA [15]
Microsoft XNA (Xna is Not Acronymed) è un insieme di strumenti per la progettazione, lo
sviluppo e la gestione di software per videogiochi contraddistinto dalla semplicità del
processo di creazione, poiché evita al programmatore l’inserimento di parti inutili di codice
e consente l’appoggio a un framework unificato, che contiene tutti i set di istruzioni utili
per un videogame. XNA attualmente comprende l’intera sezione di sviluppo videogiochi di
Microsoft, incluso lo standard Xbox Development Kit.
Il Framework XNA è basato sul .NET Framework 2.0 per Windows e sul .NET Compact
Framework 2.0 per Xbox 360, pertanto è virtualmente supportato da tutti i linguaggi .NET,
anche se è consigliato l’uso di C#. Esso appoggia sulle librerie grafiche di Microsoft
DirectX e incapsula tutti i dettagli di basso livello riguardanti lo sviluppo del videogioco,
risparmiando questo compito allo sviluppatore che può concentrarsi sul contenuto e
sull’esperienza di gioco in quanto sarà il framework a gestire le varie piattaforme di gioco;
sono inoltre presenti numerosi strumenti per la creazione di contenuti, come editor di
suono, visuali e di modelli.
Microsoft ha rilasciato degli IDE specifici per il game design (XNA Game Studio), che si
possono installare come estensione dell’IDE principale (Visual Studio), così come il
Framework XNA viene installato come estensione del .NET Framework.
5.4 Struttura di un progetto XNA [16]
La colonna portante di un progetto XNA è una classe di tipo Game. Questa classe è
implementata alla creazione di ogni progetto XNA e gestisce l’intera applicazione
attraverso dei metodi predefiniti.
In un progetto XNA è possibile separare le varie parti dell’applicazione mediante l’uso di
vari GameComponents, ciascuno dei quali possiede metodi predefiniti ereditabili dalla
classe Game.
29Puoi anche leggere
