Archivo

Archive for 27 mayo 2010

Trackmate

Trackmate es una de las opciones disponibles para utilizar como framework de visión, en la construcción de YARMI. Es un sistema de reconocimiento de fiducials desarrollado por el Tangible Media Group del MIT Media Lab, con el objetivo de ser económico y fácil de construir. Trackmate reconoce la posición, rotación e información de color de objetos etiquetados y dispuestos sobre una superficie. Envía toda esta información a las aplicaciones cliente mediante el protocolo LusidOSC (basado en OSC como su nombre sugiere), desarrollado por los autores.

El mayor fuerte de este framework, es la excelente documentación que posee y su presentación desde un sitio web muy bien diseñado y con un alto grado de usabilidad. En la página se puede ver distintos ejemplos de aplicaciones que utilizan el framework.

El sistema es capaz de reconocer una clase de fiducials especial, que permite manejar alrededor de unos  280 trillones de identificadores diferentes (códigos de barra circulares) de 1” (una pulgada) de diámetro.

Del sitio web, pueden descargarse las siguientes herramientas:

  • Tagger: permite generar las etiquetas que el sistema puede reconocer, exportándolas en formato PDF o PNG.
  • Tracker: es el módulo principal, que recibe la información de la cámara web especificada y publica un servidor dónde espera conexiones de clientes que hablen el protocolo LusidOSC. Además, tiene integrado el mecanismo de calibrado y testeo.
  • LusidOSC Bundle: conjunto de aplicaciones de ejemplo para ejecutar en Processing y probar el sistema fácilmente. Además, incluye una librería para Processing, que resuelve la comunicación entre programas desarrollados en este entorno y el servidor (Tracker).

El sistema prometía mucho, pero una vez iniciada la etapa de calibrado y testeo, se hicieron evidentes una serie de restricciones importantes.

Los parámetros más importantes a la hora de configurar el sistema son las dimensiones del área de trabajo, la resolución de la cámara y la cantidad de pixels (de cámara) por pulgada (de superficie).  La primer restricción que se observó, es que para un área de trabajo aplicable a nuestro proyecto, la taza de cuadros por segundo de información que el sistema puede generar no es suficiente. En la siguiente tabla puede verse su variación en función del área:

dimensión del área (pulgadas) cuadros por segundo
11.625 x 8.250 15
6.000 x 6.000 20
3.000 x 3.000 30

Se puede notar que recién para una relación fiducial-área de 1/9, el sistema provee una taza de cuadros por segundo razonable.

Otra restricción encontrada, es que el sistema es muy suceptible a cambios en la iluminación. Durante la etapa de calibrado, una vez que se fijan los parámetros arriba mencionados, es necesario realizar la “calibración de blancos”. Se puede notar como la imagen pre-procesada por el sistema se deteriora considerablemente por el más mínimo cambio en la iluminación, respecto a aquella con la que se realizó el calibrado.

Asociado a esto último, se notó que el sistema está construido para recibir una imagen formada solamente por el fondo blanco y los fiduciales. Cualquier otro objeto captado por la cámara dentro del área de trabajo (como un soporte para el fiducial, o una mano) hará que el sistema falle. En particular, el valor de las rotaciones de los fiducials es lo primero que se pierde por completo.

Tras el análisis del sistema, se concluye que éste está más orientado a un escenario con las siguientes características: libre de objetos que interfieran en la imagen (por ejemplo para flimarse desde abajo de la superficie, como se hace en la Reactable), con un área de trabajo relativamente chica, y en dónde tener tal cantidad de fiducials distintos pueda ser de utilidad.

El framework no cumple con los requisitos adecuados para nuestra aplicación, por lo que fue descartado.

ReacTIVision VS D-touch

Tanto ReacTIVision como D-touch son sistemas para el seguimiento de la ubicación y la orientación de marcadores (fiducials) en tiempo real.

ReacTIVision surge como una continuación de d-touch principalmente debido a los bajos tiempos de los frame rates alcanzados con d-touch.

D-touch utiliza una topología única para todos los fiduciales en un set.

El set consta de 120 fiduciales únicos que se diferencian mediante un código de permutación expresado por el número de hojas negras en el grafo de adyacencia. En el siguiente ejemplo el código de permutación es  (1,2,3,6,5,4).

d-touch asocia el código de permutación de las regiones de hojas negras a un conjunto específico de fiduciales.

En segundo lugar, el d-touch original no prescribe un determinado método para calcular la ubicación y orientación de los fiduciales.

Por último, las geometrías simples de los fiduciales (que por cierto tienen la ventaja de ser fácilmente dibujados a mano) no fueron diseñados para minimizar el tamaño de los mismos.

Por otra parte el sistema de reacTIVision admite conjuntos de fiduciales de distintos tamaños y topologías sin ningún cambio de código.

Consideramos que esta es una mejora significativa respecto a d-touch en nuestro contexto, donde queremos experimentar con fiduciales más pequeños.

El set consta de 128 fiduciales exclusivos, logrando tener una superficie del casi 50% menos que las del set de 120 fiduciales de d-touch.

A continuación mostramos una comparación de performance entre las diferentes librerías.

Figura 1

La figura 1 compara el uso de la CPU y el frame rate obtenido con reactTivision (libfidtrack) y dos versiones de d-touch: una versión reciente (libdtouch) y la versión original (dtouch_old)

Podemos ver que la actual implementación de reacTivision es 4 veces mas rápido que la versión actual de d-touch y mas de 16 veces mas rápido que la versión original.

Podemos resumir entonces las mejoras conseguidas por la reacTIVision frente a d-touch en tres áreas:

Funcionamiento, tamaño de los fiduciales y escalabilidad para diferentes topologías de fiduciales y tamaños establecidos.

Categorías:Estado del Arte

Estado del Arte VI

Audio d-touch

Es un sistema desarrollado por Enrico Costanza, S.B. Shelley y J. Robinson del Media Engineering Group la University of York (York, UK) en el 2003, y presentado como una “interfaz de usuario tangible para la composición y performance de música“.

Para su demostración, se implementaron tres aplicaciones musicales distintas: Augmented Musical Stave, Tangible Drum Machine y Physical Sequencer. Las dos últimas continuaron siendo mejoradas después de su presentación y actualmente se pueden descargar de la web official del sistema, junto con muy claras instrucciones sobre cómo construirlo y probarlo uno mismo.

La configuración general para las tres aplicaciones es la misma: está compuesta por un área interactiva y un conjunto de bloques marcados. El área es una superficie plana observada por una webcam (sostenida por el soporte de una lámpara de mesa) conectada a un PC, de la cual no se necesita el monitor.

El feedback al usuario es provisto tanto por el audio como por la disposición física de los bloques (que actúan como dispositivos de entrada y salida). El área interactiva, está cubierta por una hoja de papel con cuatro marcadores especiales en las esquinas, que son utilizados por el sistema para el calibrado automático, y algunas marcas visuales destinadas al usuario.

En cuanto a la implementación del sistema lo más interesante es el sistema de visión, el cual fue precursor del reacTIVision. Básicamente permite al implementador diseñar sus propios marcadores, de forma que tengan algún sentido para el usuario. Además, es posible construir el sistema en distintos tamaños, con la única restricción impuesta por la resolución de la webcam que determina la relación que se debe mantener entre el tamaño del área interactiva y el de los objetos. Hablaremos de este sistema más adelante ya que será uno de los posibles frameworks de visión a utilizar. La síntesis de audio se realiza utilizando el Syntehsis ToolKit (STK).

Parte del trabajo de los autores, fue testear las aplicaciones con un conjunto de usuarios con distintos grados de formación musical. Si bien obtuvieron mayormente resultados positivos, algunos usuarios señalaron que muchas veces les fue difícil saber que punto del loop estaba siendo reproducido en un momento dado, y que esto podría ser resuelto agregando feedback visual o de audio, extra. Esto es algo que también notamos al probar el sistema y es algo que el diseño de YARMI tiene en cuenta, por lo que será interesante evualuar el resultado en este sentido luego de construido.

Como trabajo a futuro, sugieren adaptar la interfaz para su utilización contra un instrumento de tiempo real genérico. Esto es, generar una salida de audio en algún protocolo estándar (como MIDI u OSC) para controlar aplicaciones de audio como Ableton Live o módulos desarrollados en PD o Max/MSP. Si bien YARMI va a estar comunicándose con un módulo PD o similar utilizando alguno de estos protocolos, queda a definir si va a ofrecer soporte para aplicaciones del estilo de Live, algo que sería muy interesante.

Las aplicaciones

A continuación se describen brevemente las tres aplicaciones y se muestran algunas imágenes del sistema armado por nosotros.

La primer aplicación mencionada es la Augmented Musical Stave, la representación física de un compás en partitura clásica sobre la que se dispondrán los distintos marcadores que simbolizan notas y silencios de diferente duración (blancas, negras, corcheas, semicorcheas…). La altura determina, así, la nota a reproducir.

La segunda aplicación es la Drum Machine, un secuenciador de sonidos de batería en loop. Existen dos tipos de marcador para las intensidades de sonido alta y baja. La altura en el compás indica el sonido de batería a reproducir.

La última aplicación es el Sequencer, donde los usuarios pueden grabar audio de entrada (conectado a la tarjeta de sonido) y asignándolo a los distintos bloques, que luego podrán ser reproducidos en algún punto del compás. La altura en el mismo representa para esta aplicación el volumen del sample. Es posible luego agregarle distintos efectos preestablecidos a la pista.

La diseño de la interacción para las tres aplicaciones está muy bien trabajado. Puede leerse con más detalle en el paper original.