capÍtulo 3: el wii remotebibing.us.es/proyectos/abreproy/11526/descargar... · se experimentó con...

Aplicaciones de controlador Bluetooth en Robótica. 1

CAPÍTULO 3: EL WII REMOTE

3.1. INTRODUCCIÓN

En este capítulo desarrollaremos los entresijos del elemento central de este trabajo.

Figura 3.1: El Wiimote(Fte.: Nintendo)

El Wii Remote, informalmente conocido como Wiimote, es el principal dispositivo de entrada de la consola Wii de Nintendo. Es un dispositivo sin cables, que usa la tecnología estándar Bluetooth para comunicarse con la Wii.

El Wiimote parte de una concepción radicalmente distinta a los dispositivos que hemos venido explicando en el apartado anterior. Con forma de mando de television, el Wiimote incorpora acelerómetros que pueden medir el movimiento que está produciendo el jugador en él.

También puede interaccionar con una barra de infrarrojos que añade la funcionalidad de puntero. Podemos conectarle otros dispositivos al mando, que le añaden versatilidad, para jugar a juegos que no requieran la capacidad de sentir el movimiento: un nunchuk y un controlador clásico.

Por último, incorpora como no, multitud de botones, y el dispositivo que marcó un antes y un después en la evolución de los videojuegos, el D-Pad.

1


3.2. OBJETIVO: WIIMOTE

Todo indica que el desarrollo del Wii Remote comenzó en torno al 2001, coincidiendo con el desarrollo de la nueva consola Wii.

En este año, Nintendo solicitó la licencia de algunas patentes basadas en sensores de movimientos a Gyration Inc.[24], una compañía que produce ratones de PC inalámbricos con sensores de movimiento. Así mismo, Nintendo insta a la compañía a crear un controlador para una sola mano para ellos, que eventualmente desarrollaría el Gyropod' concept, un gamepad más tradicional que permitía control de movimiento.

Llegados a este punto, Gyration Inc. trabaja junto a la firma Bridge Design para trasladar a Nintendo sus ideas. Como requerimiento tenían que preservar la consola Game Cube de Nintendo que todavía se encontraba en el mercado.

Se experimentó con distintos modelos, esquemas, e incluso con encuestas a jugadores[1]. A finales de 2004 Nintendo alcanzó lo que pretendía, un controlador menos tradicional, con la forma habitual de un mando de televisióny diseñado junto con otro dispositivo, el Nunchuk. El mando tenía sensores de movimiento, puntero infrarrojo,... A finales de 2005 todos estaba preparado para la producción masiva del controlador[2].

Durante el desarrollo del Wii Remote, el diseñador de videojuegos, Shigeru Miyamoto acudió a teléfonos móviles y controladores de navegación automática para inspirarse[6]. Otro prototipo reunía las características de un stick analógico y un pantalla táctil, pero la idea fue desechada debido a la inminente salida de su consola portable, que tendría la misma filosofía[5].

Algunas fuentes aseguran que el Wiimote fue originalmente desarrollado para la Nintendo GameCube. Sin embargo, parece que el controlador quería ver la luz junto a un nuevo sistema, de forma que se creara una Revolución en el mundo de los videojuegos.

3.3. DISEÑO

El Wiimote es un diseño de control remoto de una sola mano, algo novedoso con respecto a los controladores tradicionales de las consolas previas. De esta forma, la sensibilidad de movimiento se hace más intuitiva, como control remoto encaja perfectamente. Con este novedoso diseño se ayuda a uno de los objetivos de Nintendo con la salida de la Wii: acercar el mundo de los videojuegos a un perfil que no responde al clásico jugador.

2


El controlador mide 148 mm de largo, 36.2 mm de ancho y 30.8 mm de alto[3]:

Figura 3.2: Wiimote(Fte.: Nintendo)

El Wii Remote tiene un nombre de modelo genérico, usado por Nintendo, RVL-003, una referencia al nombre en clave del proyecto Wii: Revolution.

El mando se comunica con la consola sin usar cables mediante una interfaz radio Bluetooth de corto alcance, de forma que es posible operar con hasta 4 controladores a una distancia de hasta 10 metros de la consola.

Puede usarse poniéndolo de forma horizontal y usarlo como un controlador más clásico. Es posible incluso jugar con un mando en cada mano por ejemplo para juegos de disparo.

A raíz de la E3 2006 (congreso mundial de videojuegos) se realizaron algunos cambios en el Wiimote sobre el diseño previo presentado. El controlador se hizo más alargado y se añadió un altavoz, en la parte central. También se cambió la nomenclatura de la botonera y se rediseñó el puerto de expansión.

3.4. DENTRO DEL WIIMOTE

El dispositivo se construye en torno al System-on-a-chip bluetooth Broadcom BCM2042[25], que además de gestionar la comunicación, contiene múltiples periféricos que proporcionan los datos, así como un puerto de expansión para añadir elementos.

El Wiimote usa el protocolo estándar de bluetooth HID para comunicarse con el sistema final, el cual se basa directamente en el estándar HID de USB. De esta forma, de cara a cualquier sistema final Bluetooth, el Wiimote se comportará como un dispositivo de

3


entrada estándar. Sin embargo el mando no hace uso de los tipos de datos y descriptores HID estándar, y sólo describe el formato y longitud.

En realidad, el Wiimote usa un conjunto de operaciones bastante complejo, transmitidos a través de los reports HID de salida (HID Output reports). De la misma forma, devuelve diferentes paquetes de datos a través de reports de entrada (Input Reports), que contienen datos de sus periféricos.

Recordemos que nos encontramos ante un problema de ingeniería inversa: no tenemos que diseñar algo, sino que tenemos algo ya diseñado que puede sernos de utilidad, pero del que hay que conocer sus entresijos.

3.4.1. Comunicación bluetooth con el Wiimote

Como hemos comentado, el Wii Remote es un dispositivo Bluetooth. Aunque posteriormente haremos un desarrollo de los aspectos que más nos interesan de esta tecnología, a continuación se introducen los conceptos básicos relacionados con ella.

Para iniciar la comunicación hemos de pulsar simultaneamente los botones 1 y 2, o bien pulsar el botón SYNC situado en la parte trasera del mando, junto a las baterias.

Figura 3.3: Acceso al botón de sincronización del Wiimote

En este momento empiezan a parpadear las luces frontales y, siempre que haya un “host” en el alcance, conectado, mediante el protocolo Bluetooth SDP (Service Discovery Protocol), el Wiimote

4


devuelve gran cantidad de información que lo identifica respecto a otros dispositivos Bluetooth que pudieran estar conectados al host.

Por ejemplo reporta la siguiente información:

Nombre dispositivo Vendor ID Product ID

Nintendo RVL-CNT-01 0x057e 0x0306

Tabla I: Parámetros del controlador

El Wiimote no parece requerir ninguna de las características de autentificación y encriptación propias del estándar Bluetooth.

3.4.2. Interfaz HID en el Wiimote

HID es un protocolo para dispositivos de interfaz humana (Human Interface Device). Define protocolos, procedimientos y características para ser usadas por dispositivos Bluetooth tales como teclados, punteros, dispositivos de juego.

El perfil HID de Bluetooth usa la definición de dispositivo HID de USB (Universal Serial Bus) para apoyarse en los drivers existentes para ellos.

El perfil HID describe como usar el protocolo HID de USB para descubrir las características de los dispositivos HID y cómo Bluetooth puede soportar los servicios HID apoyándose en la capa L2CAP (control de enlace lógico) de Bluetooth.

Aunque posteriormente se desarrollarán algunos aspectos clave de forma más exhaustiva, a continuación explicamos algunos conceptos necesarios para entender el funcionamiento del Wiimote que ahora nos ocupa.

El estándar HID permite a los dispositivos ser auto-descritos, usando un bloque descriptor HID. Este bloque incluye una enumeración de reports que el dispositivo entiende. Un número de report puede ser visto como un número de puerto asignado a un servicio particular.

Sin embargo los reports son unidireccionales, de forma que los descriptores HID listan la dirección de puerto, si es de

5


entrada o salida, y el tamaño de la carga útil para cada puerto. Como todos los dispositivos bluetooth HID, el Wiimote reporta su bloque descriptor HID cuando sea solicitado a través del protocolo SDP.

Hay que tener en cuenta que un InputReport se envía en dirección Wiimote-host, de forma que los OutputReports se envían desde el host al Wiimote.

Veamos un ejemplo de report y así definir la notación que usaremos en este apartado:

(a1) 30 00 00

Representaremos entre paréntesis el número de identificación del report, y la carga útil tal y como se describe en la secciones 7.3 y 7.4 de las especificaciones HID de BT[26]. Cada byte se escribe en hexadecimal, sin el prefijo 0x y separado por espacios.

Así en el ejemplo anterior (0xa1) se refiere al report ID, en este caso un paquete de datos de entrada, referido al canal 0x30, con una carga útil, 0x00 0x00.

En apartados siguientes se desarrollarán los periféricos que componen el mando y sus correspondiente reports asociados, aunque en los anexos se puede encontrar una lista completa de comandos.

En general, podemos observar como desde el host se envían comandos de control y de petición de información. El mando responde con comandos donde envía la información asociada al elemento solicitado.

3.4.2.1 Información común de los Output Reports

El primer byte de la mayoría de estos comandos tiene un significado común:

-El bit 0 del primer byte (0x01) controla la vibración del mando.

-El bit 2 del mismo (0x04) es la bandera que activa o desactiva la característica específica asociada al Output Report, es decir, si nos referimos al altavoz del mando, si lo activamos en el Output Report asociado, activaremos el altavoz.

Veamos un ejemplo para aclarar este concepto: si enviamos el siguiente report:

(52) 19 04

6


Silenciaremos (con 0x04) el altavoz (al que se refiere el Report 0x19). Lo que sigue lo desilenciará:

(52) 19 00

Todos los Output Reports siguientes tienen el mismo comportamiento:

(0x12), modo de envío de datos, (0x13), habilitación del sensor de infrarrojos, (0x14), habilitación del altavoz, (0x19), silenciar el altavoz.

Pasemos ahora a estudiar cuales son los elementos y capacidades del mando a los que nos referimos y que lo hacen tan atractivo para un desarrollador de aplicaciones.

3.4.3. El chip Broadcom BCM2042

El verdadero “cerebro” del Wiimote.

Fig. 3.4: El Chip Broadcom 2042(Fte.: Broadcom)

El BCM2042 es un dispositivo que, en un simple chip, integra el perfil completo, aplicaciones y la torre de protocos Bluetooth, de forma que cumple completamente con las especificaciones para dispositivos de interfaz humana del BT SIG (Special Interest Group de Bluetooth), siendo compatible con la versión 2.0, incluyendo las mejoras en el salto de frecuencia de forma adaptativa y conexión rápida, esenciales para aplicaciones con teclado y ratón en Pcs.

En los anexos se incluye el DataSheet de este dispositivo, aunque las características principales que resumen lo anterior son:

-Un dispositivo single-chip Bluetooth con el perfil completo de Human Interface Device y la pila de protocolos Bluetooth.

-Un procesador 8051 y memorias RAM/ROM on-board.

-Una solución de coste óptimo para ratones y teclados que logra el menor coste a través de la integración de componentes externos.

7


A continuación se muestra el diagrama de bloques que integran el chip:

Fig. 3.5: Diagrama de bloques del BCM2042(Fte.: Broadcom)

3.4.4. Recepción de datos

El Wiimote tiene distintos modos de reporte de datos. Cada una de ellos combina el envío del estado ciertas características del mando, junto con datos de periféricos. Se envían al host en la forma de distintos reports, cada uno de ellos identificado con su report ID. Los datos y el modo son empaquetados por los propios periféricos, lo que hace el controlador del Wiimote es agrupar todos los bytes y mandarlos al host.

Desde el host se puede solicitar el cambio de modo de reporte, de la siguinte forma:

(52) 12 TT MM

0x12 se refiere al report asociado al cambio de modo de envío de datos. En el siguiente byte, 0xTT, el bit 2 especifica si se desea envío continuo. Esto es, si este byte los ponemos a 0x04, el envío de dichos datos se producirá independientemente de si ha habido cambio en los periféricos o no. De otra forma, el mando nos enviará output reports sólo cuando los datos hayan cambiado.

8


El byte MM especifica el modo propiamente dicho. El modo se especifica por el identificador del output report a través del cual se recibirá.

Veamos un ejemplo que aclare todo esto:

(52) 12 00 33

Vemos que 0x12 es identificador de report de cambio de modo de envío de datos. Por otro lado, solicitamos un envío continuo 0x00. El byte que nos falta se ha ajustado a 0x33, de esta forma los datos llegarán a través del Report de entrada 0x33.

Tras el encendido, los datos nos llegan por defecto por el report 0x30. Por otro lado, después de una conexión o desconexión en el puerto de expansión, se deshabilita el reporte de datos y el modo debe resetearse antes de que nuevos datos lleguen.

Veamos todos los tipos de reports de entrada que nos transmiten datos del mando, aunque después analizaremos qué significan estos datos según el periférico a que se refieran:

-0x30, Botones: Este modo devuelve los datos de la botonera del Wiimote, de la siguiente forma:

(a1) 30 BB BB

donde 30 es el ID de report, y BB son bits de la botonera.

-0x31, Botones y acelerómetros: Este modo devuelve los valores de botonera y los acelerómetros:

(a1) 31 BB BB AA AA AA

donde BB son los datos de botones y AA de los acelerómetros.

-0x32, Botones con 8 bytes de extensión: Junto a los datos de botones, se reciben datos del controlador del puerto de expansión conectado:

(a1) 32 BB BB EE EE EE EE EE EE EE EE

donde BB son los datos de botones y EE datos del controlador de extensión conectado actualmente al puerto de expansión.

-0x33, Botones, acelerómetros y 12 bytes de Infrarrojos: A los datos de botonera y acelerómetros, se añaden 12 bytes de la cámara de IR:

9


(a1) 33 BB BB AA AA AA II II II II II II II II II II II II

BB son los datos de botones, AA de los acelerómetros e II son bytes de la cámara IR situada en el Wiimote.

-0x34, Botones y 19 bytes de extensión: Similar al modo 0x32, pero con más información destinada al controlador situado en el puerto de expansión:

(a1) 34 BB BB EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE

-0x35, Botones, acelerómetros y 16 bytes de expansión: De la siguiente forma:

(a1) 35 BB BB AA AA AA EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE

con el mismo significado que los anteriores.

-0x36, Botones con 10 bytes de IR y 9 de controlador externo: Este modo devuelve datos de los botones, junto con datos de la cámara de infrarrojos y 9 bytes del controlador conectado al puerto de expansión del Wiimote:

(a1) 36 BB BB II II II II II II II II II II EE EE EE EE EE EE EE EE EE

-0x37, Botones, acelerómetros con 10 bytes de IR y 6 bytes de extensión: Similar al anterior pero quitamos carga de controlador externo para poder transmitir datos de acelerómetros:

(a1) 37 BB BB AA AA AA II II II II II II II II II II EE EE EE EE EE EE

BB, botonera, AA, acelerómetros, II, infrarrojos, EE, puerto de expansión.

-0x3d, 21 bytes de extensión: Este modo devuelve sólo datos del dispositivo conectado al puerto de expansión del Wiimo, de la siguiente forma:

(a1) 37 EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE

-0x3e/0x3f, Datos de botones, acelerómetros y 36 bytes de IR entremezclados: Estos dos reports son equivalentes y devuelven alternativamente datos. Los datos se entremezclan, de forma que

10


la velocidad es la mitad que la de otros modos (son necesarios 2 reports). Sin embargo se devuelve mucha más información:

(a1) 3e BB BB AA II II II II II II II II II II II II II II II II II II

(a1) 3f BB BB AA II II II II II II II II II II II II II II II II II II

BB son los datos de botones, que se especificarán en el apartado sobre la botonera. AA son los datos de acelerómetros, en el formato específico que se describe en el apartado sobre acelerómetros. Finalmente se reciben 36 bytes de la cámara IR.

3.4.5. Memoria y registros

El Wiimote incluye una memoria EEPROM, parte de la cual es accesible al usuario para almacenar datos en ella. En esta parte accesible se guardan datos de calibración, así como los datos de Mii[9].

Adicionalmente, muchos periféricos del mando tienen registros que son accesibles a través de una porción del espacio de memoria.

Para acceder a ambos, memoria y registros, se usan los mismos reports, en los que una bandera sirve para discernir entre ellos.

3.4.5.1. Leyendo

Para leer datos de memoria y registros, debemos solicitarlo enviando el siguiente Output Report:

(52) 17 MM FF FF FF SS SS

El report que se usa es el 0x17. El bit 2 de MM selecciona el espacio de direcciones, ésto es, si se borra este bit se hará una lectura de la EEPROM, mientras que activándolo hacemos una lectura de los registros. FF y SS son el offset y el tamaño en bytes a leer.

Aunque no lo hemos mencionado, como en otros reports, se incluye el control directo de la bandera de vibración, de forma que se debe ajustar al estado actual de vibración, para que no se vea afectado por el envío del comando.

Los datos leidos se devuelven a través del Input Report 0x21 de la siguiente forma:

(a1) 21 BB BB SE FF FF DD DD DD DD DD DD DD DD DD DD DD DD DD

11


DD DD DD

BB es el estado de los botones, tal y como veremos.

El motivo para recibir aquí el estado de los botones es el siguiente: mientras se realiza la lectura de memoria, el envío de otros datos se suspende temporalmente, salvo lo relacionado con la botonera que se hace de esta forma.

FF es el offset del primer byte de datos devueltos. E es una bandera de error, donde algunos valores conocidos son 0 para no error, 7 cuando se intenta escribir en un registro de solo lectura y 8 cuando se pretende leer a una memoria que no existe.

S es el tamaño en bytes (menos uno) del paquete de datos. El valor habitual es 0xf (16 bytes), menos en el último, que será inferior si el tamaño de datos solicitado no es múltiplo de 16.

Los bytes DD son los datos propiamente dichos, rellenados con cero si es necesario. Si se requieren más de 16 bytes, se recibirán múltiples paquetes.

3.4.5.2. Escribiendo

Para escribir datos, los comandos se envían al Output Report 0x16, de la siguiente forma:

(52) 16 MM FF FF FF SS DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD

El significado es el mismo, salvo que en este caso, el tamaño máximo será de 16 bytes.

3.4.5.3. Memoria EEPROM

Hay un chip de memoria EEPROM de 128kbit en el Wiimote[5]. Parte del contenido de esta memoria incluye código para el microcotrolador, así como una sección genérica que puede ser leida y escrita por el sistema final. Esta sección tiene 1700bytes y parte es usada para almacenar datos Mii[6]. La memoria puede ser accedida desde las direcciones 0x0000-0x16FF en el espacio virtual de memoria del Wiimote, aunque la posición real en la EEPROM es 0x0070-0x176F.

El microcontrolador BCM2042 también tiene una memoria ROM de 108kbits para almacenar firmware. De esta forma, en la EEPROM la única información asociada al micro que podemos encontrar, son actualizaciones para el firmware. De hecho en la web de Broadcom encontramos: “el diseño basado en ROM elimina la necesidad de

12


memorias externas de tipo flash, aunque se ofrece la posibilidad de añadirlas para soportar nuevas características de cara a desarrolladores”.

En un Wiimote “virgen”, que no ha se ha comunicado nunca con un sistema final, la mayor parte de la memoria la encontraremos vacía, aunque los primeros bytes contienen lo que sigue:

0000: A1 AA 8B 99 AE 9E 78 30 A7 74 D3

000B: A1 AA 8B 99 AE 9E 78 30 A7 74 D3

0016: 82 82 82 15 9C 9C 9E 38 40 3E

0020: 82 82 82 15 9C 9C 9E 38 40 3E

Aunque no está del todo claro por qué se repiten las secuencias, se sabe que el último bloque se refiere a datos de calibración, mientras que el otro tiene propósitos de back-up en el caso de que hagamos actualizaciones de firmware.

En concreto, los bytes que empiezan en 0x0016 y 0x0020 guardan los valores zero de los acelerómetros. Hay que decir que muchos de los valores anteriores son distintos de un Wiimote a otro[1].

Los rangos conocidos en la memoria son:

Comienzo Fin Longitud Uso

0x0000 0x0029 0x002A Valores de calibración

0x002A 0x0FC9 0x0FA0 Datos de usuario

0x0FCA 0x12B9 0x02F0 Datos Mii (bloque 1)

0x12BA 0x15A9 0x02F0 Datos Mii (bloque 2)

0x15AA 0x16CF 0x0126 Desconocido/sin uso

0x16D0 0x16FF 0x0030 Desconocido/sin uso

Tabla II: Rangos de direcciones de la memoria EEPROM

3.4.5.4. Registros de control

13


El Wiimote tiene varios espacios de memoria para registros que están asociados a distintos periféricos, incluidos el altavoz, controladores de puerto de expansión y cámara de IR.

En general, el primer byte de dirección especifica el periférico que será accedido y los 16 bits de orden menor especifican el registro concreto de dicho periférico. Debido de nuevo al problema de ingeniería inversa en el que nos encontramos, el resto de bits tienen significado desconocido[1].

La lista del espacio de memoria de los registros es el siguiente:

Comienzo Fin Uso

0xA20000 0xA20009 Ajustes del altavoz

0xA40000 0xA400FF Ajustes control externo

0xB00000 0xB00033 Ajustes sensor IR

Tabla III: Espacio de memoria de los registros

3.4.6. Periféricos de entrada del mando

El Wiimote tiene 2 características principales de entrada, que son controladas directamente a través del chip Broadcom: un acelerómetro de 3 ejes y 11 botones en total. Adicionalmente, también tiene una cámara sensora de IR con un procesador de tracking, así como un puerto de expansión que permite que dispositivos externos puedan conectarse, el Nunchuk y el controlador clásico.

Desarrollemos todos ellos a continuación.

3.4.6.1. Botones

En el Wiimote existen en total 12 botones, 11 de ellos en la parte frontal y un gatillo en la trasera. Cuatro de ellos corresponden a una cruceta de dirección y el resto con funciones adicionales.

El botón de encendido es especial ya que es tratado de forma distinta por el Wiimote. El resto de botones son accesibles de forma independiente a través de una máscara que es transmitida en primer lugar en la mayoría de Reports de entrada. De esta forma,

14


si un botón es pulsado, el bit asociado está activo o si no a 0.

Por defecto, el estado de la botonera lo recibiremos a través del modo de reporte de datos dado por 0x30, y lo haremos sólo cuando el estado de alguno de los botones cambie.

Por ejemplo, si se pulsa el botón A, se recibe el siguiente paquete HID:

(a1) 30 00 08: en este caso 30h se refiere al HID Report asociado al envío de paquete con sólo estado de botones, los otros 2 Bytes no son más que dicho estado. En este caso vemos que se ha pulsado un botón, ya que aparece el bit tercero a '1'.

Los botones “normales” son: A, B (gatillo), cruceta de dirección con 4 botones, +, -, Home, 1 y 2. Su estado entonces lo podemos leer con una máscara de bits de 2 bytes, de la siguiente forma:

Bit Máscara Primer byte Segundo byte

0 0x01 Izquierda (D-Pad) 2

1 0x02 Derecha (D-Pad) 1

2 0x04 Abajo (D-Pad) B

3 0x08 Arriba (D-Pad) A

4 0x10 + -

5 0x20 Otros usos Otros usos

6 0x40 Otros usos Otros usos

7 0x80 Desconocido Home

Tabla IV: Posición del estado de botones

En cuanto al botón Power, cuando el Wiimote está apagado, si se pulsa el mismo, se intenta “despertar” la Wii que se ha sincronizado con él. De momento este mecanismo es desconocido.

Si el Wiimote está encendido y conectado al sistema final, si se mantiene pulsado el botón de encendido durante unos segundos el Wiimote se apaga y solicita desconexión al sistema final, que usa este evento para apagarse.

15


3.4.6.2. Sensores de movimiento

Este es el detalle más novedoso e innovador respecto a otros controles del Wiimote. El análisis de movimiento se realiza gracias a un acelerómetro “lineal” de 3 ejes, situados cerca del botón A (teórico centro de gravedad del mando).

Fig. 3.6: Sistema de referencia asociado al Wiimote

El circuito que incorpora los acelerómetros es el ADXL330 de Analog Devices[7].

Los acelerómetros miden la aceleración en un rango de -3g a 3g, donde g es el valor de la gravedad, con una sensibilidad del 10%. Para efectuar la medida, en el mando hay una estructura como la que se ilustra en la siguiente figura:

Fig. 3.7: Funcionamiento de los acelerómetros

16


Vemos que tenemos un trozo de silicio, sujeto a un extremo y colocado entre el campo eléctrico ejercido por dos capacidades. El movimiento se transmite cuando se desplaza el mando, ya que la barra de silicio queda más cerca de alguno de los capacitores, lo que hace que el campo eléctrico cambie, el cuál es detectado. Éste es convertido a voltage.

Si el mando está en “caída libre”, nos mandará un report con aceleración cero. En el resto de casos, nos mandará una aceleración positiva. Así por ejemplo, si lo colocamos horizontalmente sobre una mesa, recibiremos una aceleración en Z igual al valor de la gravedad (9,8 m/s2). Estos valores de aceleración nos permiten hallar la inclinación, posición,...

Es importante considerar el estado inicial de los acelerómetros, esto es, medida inicial que dan en estado de reposo y sobre la que se ajustan el resto de valores. Para ello es importante calibrar el mando antes de comenzar a usarlo. Básicamente hay que seguir los siguientes pasos:

-Poner el mando horizontalmente con el batón A hacia arriba. Se obtienen los siguientes valores:

1 1 1( , , )x y z (1)

-Mando vertical, con el sensor IR hacia abajo. Se obtienen:

2 2 2( , , )x y z (2)

-De lado, de forma que el lateral izquierdo mira hacia arriba:

3 3 3( , , )x y z (3)

Con cada paso lo que se consigue es medir el valor g en un eje, y el valor de equilibrio en los otros dos. La posición cero se obtiene en cada eje según (4),(5)y(6).

1 20 2x xx += (4)

1 30 2

y yy += (5)

2 30 2z zz += (6)

Por tanto, sea { }, ,r x y z=r el vector de datos en bruto que

17


recibimos del mando, { }0 0 0, ,r x y z=r el vector de datos que se

corresponden con una fuerza nula en cada eje. Los factores de escala necesarios vienen dados por (7),(8)y(9).

3 0

1xk x x

=− (7)

2 0

1yk y y

=− (8)

1 0

1zk z z

=− (9)

Una vez aplicado el factor de escala al eje correpondiente, deberíamos obtener respectivamente k

r, j

r e i

r, como vectores

normalizados de aceleraciones en las posiciones de calibración anteriormente definidas, dado que, tras el escalado, un valor unitario se corresponderá con una fuerza g ejercida en esa dirección.

El mando puede enviar la información asociada a los acelerómetros, de distintas formas (junto a la información de distintos periféricos):

--Reporte de acelerómetro normal: En casi todos los modos que incluyen datos de acelerómetro, los datos se reciben en 3 bytes de la siguiente forma:

(a1) RR BB BB XX YY ZZ

donde XX, YY y ZZ son los datos sin signo de la aceleración en cada uno de los ejes, donde un valor de aceleración cero equivale a 0x80.

Un ejemplo podría ser:

(a1) 31 40 20 86 8a a5: como se puede observar en los anexos, 31h se refiere al HID Report asociado al envío de paquete con estado de botones más información de acelerómetros. En concreto, los bytes 0x86 se refieren a la medida en el eje X, 0x8a en el eje Y, y 0xa5 para el eje Z. Los primeros bytes (0x40 y 0x20) del paquete se refieren al estado de los botones.

18


--Datos de acelerómetro entremezclados: El modo de envío 0x3e/0x3f ya vimos que era distinto, ya que los datos se reciben en los 2 reports, de la siguiente forma:

(a1) 3e BB BB XX

(a1) 3f BB BB YY

Como vemos los datos de eje X e Y se reciben en 1 byte simple, pero los datos del eje Z se codifican en los bits no usados de los bytes asociados a los botones, BB, de la siguiente forma:

Bit

Report ID Byte 7 6 5 4 3 2 1 0

0x3e 0 Z(5:4)

0x3e 1 Z(7:6)

0x3f 0 Z(1:0)

0x3f 1 Z(3:2)

Tabla V: Codificación de bits componente Z en modo entremezclado

Toda esta información se resume en los anexos.

3.4.6.3. Sensor de infrarrojos

Mientras en Nintendo estaban en fase de desarrollo de su nueva consola, se dieron cuenta de que los sensores de movimiento no eran demasiado útiles para manejar cursores: el mando es muy intuitivo cuando jugamos a un juego de lucha o manejamos una espada, pero no lo es tanto cuando tenemos que manejar menús y movernos a través de ellos.

Para corregirlo, lo que hicieron fue incluirle al Wiimote un sensor IR...

Lo que encontramos en el Wiimote es una cámara monocromo 1024x768, con un filtro en la banda IR delante. La cámara IR incluye un procesador, capaz de hacer tracking con hasta 4 objetos que se desplazan (los datos de píxeles en bruto no están disponibles para el sistema final).

Por otro lado, junto a la Wii, tenemos una barra sensora, consistente en 2 clusters de LED's IR que son usados por el

19


Wiimote para situar información de dónde se apunta.

De esta forma, tenemos 2 fuentes de luz infrarroja, que actúan como baliza, y un dispositivo que capta las señales y puede usar dicha información para localizar su posición. Si se eliminara el filtro, se podría localizar cualquier objeto brillante (cualquier zona del espectro).

-Inicialización: Para iniciar la cámara IR se tiene que seguir el siguiente proceso:

-Habilitar la cámara IR del Wiimote: Activar el segundo bit en el Report 13.

-Habilitar la cámara IR 2: Se procede de la misma forma con el Report número 1a.

-Escribir 0x08 en el registro b00030.

-Escribir el Bloque 1 de sensibilidad en el registro b00000.

-Escribir el Bloque 2 de sensibilidad en el registro b00030.

-Escribir el número de modo en el registro b00033.

-Ajustes de Sensibilidad: La sensibilidad se controla por medio de 2 bloques de configuración, a los que nos referimos antes. Respectivamente tienen 9 bytes y 2 bytes de longitud.

Debido al problema de ingeniería inversa en el que nos encontramos, se ha encontrado [4] que las siguientes configuraciones funcionan de forma correcta:

Bloque 1 Bloque 2

00 00 00 00 00 00 90 00 C0 40 00

02 00 00 71 01 00 aa 00 64 63 03

Tabla VI: Bloques de ajuste del sensor IR

El último byte de ambos bloques determina la sensibilidad en intensidad, de forma que al aumentar dicho valor se reduce la sensibilidad. El mando devolverá datos de la mayor cantidad de objetos posible cuando el último byte del bloque 1 se pone con el valor 41 y el segundo byte del bloque 2 a 00.

20


-Formato de datos: La cámara IR devuelve diferentes conjuntos de datos describiendo los objetos que está apuntando. Cuando la cámara IR identifica un objeto, le asigna el primer slot disponible. Si el objeto se sale del campo de visión del Wiimote, su slot se marca como vacío (devuelve 0xFF), pero otros objetos conservan sus slot.

Por ejemplo, si la cámara IR está siguiendo 2 objetos y el primero se sale del campo de visión, entonces se transmitirían los siguientes conjuntos de datos [vacío, segundo_objeto, vacío, vacío].

Con más de 4 objetos visibles, la cámara conmuta rápidamente entre ellos, de forma que se permite la percepción de más de 4 objetos en un tiempo de respuesta relativamente rápido.

Dependiendo de la cantidad de información relativa al sensor IR que nos manda el Wiimote tenemos los siguientes modos de funcionamiento, que como hemos visto se escogen en la inicialización.

Modo Número de modo

Básico 1

Extendido 3

Completo 5

Tabla VI: Bloques de ajuste del sensor IR

Veamos cómo es la información que se manda en cada uno de los modos:

-Modo básico: En este caso se devuelve un total de 10 bytes de datos, que corresponden a la localización en los ejes X e Y de hasta cuatro puntos. Cada localización se codifica en 10 bits, con un rango en X que varía entre 0 y 1023, y de 0 a 767 para la coordenada Y. Cada par de puntos se empaqueta en 5 bytes, de forma que se transmiten 2 de estos paquetes asociados a los 4 puntos. Veámoslo de forma más gráfica como es uno de estos paquetes (codificación de 2 objetos) en la tabla VII.

-Modo extendido: En este modo, la Wiimote envía los mismos datos que se hacen en el caso anterior, además de un valor aproximado del tamaño para cada objeto. Los datos se envían en 12 bytes, 3 bytes por objeto. El tamaño tiene un rango de 0 a 15 (4 bits).

21


Para cada objeto, el formato de los datos se representa en la tabla VIII.

Bit

Byte 7 6 5 4 3 2 1 0

0 X1(7:0)

1 Y1(7:0)

2 Y1(9:8) X1(9:8) Y2(9:8) X2(9:8)

3 X2(7:0)

4 Y2(7:0)

Tabla VII: Formato de datos IR en modo básico

Bit

Byte 7 6 5 4 3 2 1 0

0 X(7:0)

1 Y(7:0)

2 Y(9:8) X(9:8) S(3:0)

Tabla VIII: Formato de datos IR en modo extendido

-Modo completo: En el modo completo, la cámara IR devuelve incluso más información: 9 bytes por objeto, que hacen un total de 36 bytes para los 4 puntos.

Estos bits son repartidos entre 2 reports de entrada, 18 bytes cada uno (ver los modos de reporte de datos 0x3e/0x3f). Este modo de funcionamiento no ha sido todavía desarrollado como problema de ingeniería inversa.

3.4.7. Características de realimentación al jugadorEl mando juega con 3 características de salida para aportar

sensaciones al jugador: LEDs, vibración y altavoz.

3.4.7.1. LEDs de jugador

En el mando se han incorporado 4 LEDs azules. La utilidad es mostrar que número jugador tenemos de forma tan sencilla como mirar el mando mientras jugamos.

22


Por otro lado, los LEDs desempeñan otras funciones: mientras se está reconociendo el mando (sincronización), estos empiezan a parpadear; mientras parpadean, se iluminarán una cantidad de LEDs proporcional a la batería que le queda al mando.

Es interesante de cara a nuestro programa el hecho de que el funcionamiento de los LEDs está totalmente a nuestro control: se pueden mostrar los patrones que deseemos, se puede controlar la luminosidad de los mismos,... Esto último tiene un coste de ancho de banda demasiado elevado, aunque nos da una idea de la versatilidad del dispositivo.

Los LEDs se controlan enviando:

(52) 11 LL

donde 11 se refiere, como se puede ver en los anexos al HID Report de los LEDs, y LL son bits que controlan el comportamiento de los LEDs, de la siguiente forma:

Bits LL LEDs

0x10 ■ ■ ■ ■

0x20 ■ ■ ■ ■

0x40 ■ ■ ■ ■

0x80 ■ ■ ■ ■

Tabla IX: Control de los LEDs

3.4.7.1. Vibración

El mando incorpora características de vibración, todo gracias a un pequeño motor conectado a una aleta, de forma que empieza a vibrar cuando se activa.

La vibración puede activarse o apagarse con cualquier Output Report, de forma que si se activa el LSB del primer byte de cualquiera de ellos se activa. En otro caso se desactiva.

Ya que acabamos de estudiar los LEDs, si usamos su report podemos también ajustar la vibración. Así si enviamos lo que sigue

23


encenderemos el motor de vibración:

(52) 11 01

Este detalle tiene un problema si se mira desde la siguiente perspectiva: como no hay ningún report de salida que sólo afecte a la vibración, y todos los reports afectan a la vibración, es necesario ajustar la bandera de vibración de forma adecuada en cada report, de forma que se eviten vibraciones accidentales.

3.4.7.3. Altavoz

El mando tiene un altavoz de baja calidad, usado para cortos y rápidos efectos de sonido mientras se juega. Así por ejemplo, podemos escuchar el sonido de una pistola que dispara o una espada que se mueve.

El flujo de sonido se recibe directamente desde el sistema final, donde el altavoz tiene algunos parámetros ajustables que estudiaremos a continuación.

Hay que decir que hasta ahora el conocimiento que se tiene del altavoz es escaso, de forma que el problema de ingeniería inversa no está totalmente solucionado. De hecho, prácticamente hasta la elaboración de este documento, sólo se producían sonidos distorsionados.

Para el manejo del altavoz usamos 3 reports de salida, así como una pequeña sección del espacio de memoria de los registros.

-El report 0x14 se usa para habilitar o deshabilitar el altavoz. Para ello activaremos o desactivaremos el segundo bit del mismo. Así si enviamos el siguiente report, habilitamos el altavoz:

(52) 14 04

-El report 0x19 se usa para silenciar o desilenciar el altavoz. De la misma forma, usaremos el segundo bit del mismo. Lo que sigue lo silencia:

(52) 19 04

-El report 0x18 se usa para enviar los datos que serán reproducidos en el altavoz. Se pueden enviar de 1 a 20 bytes de una vez, siguiendo la siguiente estructura general:

(52) 18 LL DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD

24


DD DD DD

LL especifica la longitud de los datos que se transmiten, los bytes DD. La longitud se representa desplazando el valor 3 bits a la derecha.

Los reports que tengan menos de 20 bytes han de ser rellenados con 0, y los datos se deben enviar a la tasa correcta.

--Secuencia de inicialización: Para iniciar la operación del altavoz seguiremos la siguiente secuencia:

1. Habilitar el altavoz, mandando 0x04 al report 0x14.2. Silenciarlo, mandando 0x04 al report de salida 0x19, tal y como hemos estudiado.3. Escribir 0x01 al registro 0xa20009.4. Escribir 0x08 al registro 0xa20001.5. Escribir los 7 bytes de configuración, que veremos a continuación, cada uno en uno de los registros desde el 0xa20001 al 0xa20008.6. Escribir 0x01 al registro 0xa20008.7. Desilenciar el altavoz, mandando 0x00 al report 0x19.

--Configuración y formato de datos: El altavoz puede usar múltiples formatos, aunque todos ellos son muy desconocidos. De hecho si lo usamos con un PC, los drivers no pueden mantener todos los formatos.

Los 7 bytes de configuración a los que nos hemos referido antes, permiten ajustar algunos valores de altavoz, entre otras cosas el formato de audio. La estructura “genérica” de dicho bloque es la siguiente:

00 FF RR RR VV 00

Decimos “genérica” porque los bytes 0x00 no se conocen. El resto de parámetros son los siguientes:

VV especifica el volumen, de forma que tenemos un volumen máximo teórico de FF (255).FF configura el formato de datos de sonido. Si lo ajustamos

a 0x40 se configura el altavoz en formato 8-bits PCM, mientras que si imponemos 0x00 se configura a un formato de 4 bits ADPCM. Todos ellos son muy desconocidos.RR es la tasa de muestreo, de forma que tiene que ajustarse

al formato seleccionado.Veamos algunas configuraciones:

25


00 00 00 0D 40 00 00: Se producirán tonos en el modo 4bitADPCM.

00 40 00 1A 40 00 00: Se configura a 8bit-PCM a una tasa de 1794Hz (0x1A).

El formato por defecto del altavoz es actualmente desconocido, pero parece que es 4-ADPCM, con una tasa de muestreo más flexible. Decimos parece ya que si se repiten los mismos valores de 4 bits no se comportan como esperamos.

El formato de 8-bit PCM parece más cercano al estándar, pero en este caso no se pueden usar los valores superiores de frecuencia, ya que la calidad ya no es mala sino pésima.

En [8] encontramos una pequeña tabla (Tabla X) con algunos valores de tasa de muestreo.

Valor Frecuencia de mustreo

11 (0x0B) 4000-4364 Hz

12 (0x0C) 3692-4000 Hz

13 (0x0D) 3429-3692 Hz

14 (0x0E) 3200-3429 Hz

15 (0x0F) 3000-3200 Hz

Tabla X: Programación de la tasa del altavoz

Si observamos la tabla anterior, la relación valor-tasa de muestreo es inversamente proporcional. Si hacemos las cuentas la máxima frecuencia que podemos conseguir es de unos 7 Khz.

3.4.8. Controlador externo

El Wiimote incluye un conector de expansión de 6 pines, para transmitir datos serie de forma síncrona, datos que provienen de entradas externas.

Actualmente, Nintendo tiene a la venta 2 dispositivos: Nunchuk y control clásico(fig. 3.8 y 3.9). Estas entradas se mapean en una porción del espacio de memoria de los registros, y pueden incluso mandarse Output Reports hacia ellos.

26


Figura 3.8: Nunchuk

Figura 3.9: Controlador clásico

--Registros e inicialización: Los controles de extensión se mapean en la dirección 0xa40000 y tiene en total 100 bytes de longitud. Los registros se pueden leer y escribir.

Los datos están encriptados. El código de encriptación se configura al principio del registro 0xa40040. Si se escribe un valor nulo, se inicia el periférico y hace uso de un esquema de encriptación muy sencillo. Si queremos recuperar la información original hemos de usar la siguiente transformación:

decrypted_byte = (encrypted_byte XOR 0x17) + 0x17

El resultado debe truncarse a 8 bits.

--Identificación: Los últimos 2 bytes del bloque de registros para el controlador de expansión, identifican al dispositivo concreto conectado al puerto. Si se hace una lectura de 2 bytes en el registro 0xa400fe tendremos estos bytes. Podemos encontrar los valores registrados en la tabla XI.

Encriptado Desencriptado Significado

0x0000 0x2E2E Nada insertado

0xFFFF 0xFFFF Parcialmente insertado

0xFEFE 0x0000 Nunchuk conectado

0xFDFD 0x0101 Controlador clásico conectado

Tabla XI: Identificación del controlador externo

El caso Parcialmente insertado se produce cuando el conector se pierde o hay una mala conexión.

27


3.4.9. Información de estado

El Wiimote puede devolvernos su estado: estado de algunas configuraciones de periféricos, el estado del controlador de extensión y el nivel de la batería.

Para solicitar dicha información hemos de enviar cualquier información al report 0x15. Así por ejemplo, lo que sigue solicita el report de estado (también apaga la vibración):

(52) 15 00

La información de estado se recibe a través del report 0x20:

(a1) 20 00 00 FF 00 00 BB

En ese contexto, BB es el nivel de la batería y FF es una máscara de banderas con el siguiente significado de estado:

Bit Máscara Significado

0 0x01 Desconocido

1 0x02 Un control externo conectado

2 0x04 Altavoz habilitado

3 0x08 Envío continuo habilitado

4 0x10 LED 1

5 0x20 LED 2

6 0x40 LED 3

7 0x80 LED 4

Tabla XII: Información de estado del Wiimote

28

capÍtulo 3: el wii remotebibing.us.es/proyectos/abreproy/11526/descargar... · se experimentó con...

Documents