Interfaces Tangibles para la Composición de Música
160
1 Interfaces Tangibles para la Composición de Música Francesconi, Juan Ignacio (67718) Director: Castro, Silvia Co-Director: Larrea, Martín
description
Interface Tangible, HCI, IHC, Visión por computadora, OpenCV
Transcript of Interfaces Tangibles para la Composición de Música
1
Interfaces Tangibles para la Composición de Música
Francesconi, Juan Ignacio (67718)
Director: Castro, Silvia
Co-Director: Larrea, Martín
2
3
Departamento de Ciencias e Ingeniería de la Computación
Universidad Nacional del Sur
Proyecto Final de Carrera de Ingeniería en Sistemas de Computación
INTERFACES TANGIBLES PARA LA COMPOSICIÓN DE MÚSICA
Autor: Francesconi, Juan Ignacio (67718)
Director: Castro, Silvia
Co-Director: Larrea, Martín
Bahía Blanca, Año 2012
4
Dedicado a mi madre, Mercedes Raquel Hait.
Y a mi padre, José Daniel Francesconi. Quien me enseño a nunca bajar los brazos.
5
Agradecimientos
Me gustaría brindar mis más sinceros agradecimientos a las siguientes personas:
A mi padre, José Daniel Francesconi. Por nunca dejar de creer en mí y brindarme su apoyo
incondicional durante toda mi carrera, sobre todo en los momentos más difíciles.
A Sergio Martig que fue mi director hasta el día de su fallecimiento. Desde el comienzo de mi
carrera me trató con respeto y siempre tuvo una increíble buena predisposición para responder
todas mis dudas, desde las más básicas como ingresante, hasta las más filosóficas relacionadas
con cómo dirigir mi futura profesión.
A Silvia Castro que acepto dirigir mi Proyecto Final luego del fallecimiento de Sergio. Pero sobre
todo, agradecerle la oportunidad de participar en el ámbito académico mediante su invitación para
formar parta de la Comisión Curricular de Ingeniería, lo que luego me motivara a postularme y
formar parte del Consejo Departamental del DCIC. Dos experiencias que me enriquecieron
notablemente, que me permitieron conocer, vivenciar y comprender parte de lo que es el mundo
académico.
A mi codirector Martin Larrea, que me guio y motivo sabiamente durante todo el proceso de
creación de este trabajo, respondiendo a todas mis inquietudes por más básicas que fueran.
A mi compañero y amigo Octavio Portaluppi por su invalorable colaboración en el desarrollo del
primer prototipo funcional del sistema.
A mi amigo Julio Bellabarba quien me asistió con el diseño y fabricación del tablero encastrable
mediante su máquina de grabado y cortado láser.
Al Departamento de Ciencias e Ingeniería de la Computación junto a cada uno de sus profesores,
asistentes, ayudantes y personal no docente que me ayudaron, guiaron, enseñaron y formaron
durante mi paso por la Universidad, no solo académicamente, sino como ser humano en su
conjunto.
¡Gracias a todos!
6
Resumen
Se diseñó e implementó una interfaz tangible de bajo costo para la creación de música, dicho
desarrollo se basó en el estudio previo de las interfaces tangibles, la interacción humano
computadora y los antecedentes relacionados a la composición de música utilizando estos medios.
El sistema se implementó mediante tecnología de visión por computadora con herramientas y
elementos de fácil acceso. La interfaz permite la creación de música de forma intuitiva,
incremental y colaborativa, con una curva de aprendizaje empinada.
El sistema desarrollado es un secuenciador musical tangible de mesa. El mismo identifica, en
tiempo real, mediante visión por computadora, patrones preestablecidos impresos en fichas que
son colocadas sobre un tablero, para luego asociarlos a notas musicales o instrumentos,
dependiendo el caso, permitiendo de esta forma generar música. Se desarrollaron dos prototipos
de dicho sistema. El segundo prototipo presenta, adicionalmente, un tablero con fichas
encastrables, el cual brinda importantes ventajas.
Abstract
A low-cost tangible interface for music creation was designed and implemented; this development
was based on the previous study of tangible interfaces, human computer interaction and
background related to the composition of music using these means. The system was implemented
using computer vision technology, and accessible tools and elements. The interface allows the
creation of music in an intuitive, incremental and collaborative manner, with a steep learning
curve.
The developed system is a tangible table music sequencer. It identifies, in real time, through
computer vision, specific patterns printed on tokens which are placed on a board, and then
associates them with musical notes and instruments, depending on the case, thus allowing the
user to generate music. Two prototypes of the system were developed. The second prototype has,
additionally, a board with sockets for the tokens, which offers significant advantages.
7
Tabla de Contenidos Tabla de Contenidos ........................................................................................................................ 7
PARTE I - INTRODUCCIÓN .................................................................................................................. 10
1. Motivación................................................................................................................................. 11
2. Objetivos ................................................................................................................................... 12
3. Estructura del trabajo ................................................................................................................ 13
PARTE II - MARCO TEORICO .............................................................................................................. 17
1. Conceptos básicos ..................................................................................................................... 18
1.1. Interfaces Tangibles de Usuario ......................................................................................... 18
2. Interacción Humano Computadora ........................................................................................... 19
2.1. Definición ........................................................................................................................... 19
2.2. Componentes de IHC .......................................................................................................... 21
2.3. Disciplinas que contribuyen a la IHC .................................................................................. 29
2.4. Historia ............................................................................................................................... 31
3. Orígenes de las Interfaces Tangibles ......................................................................................... 34
3.1. Graspable User Interfaces .................................................................................................. 35
3.2. Bits Tangibles ...................................................................................................................... 36
3.3. Precursores de las Interfaces Tangibles ............................................................................. 38
4. Dominios de Aplicación de las Interfaces Tangibles ................................................................. 41
4.1. TUIs para el aprendizaje ..................................................................................................... 41
4.2. Resolución de problemas y planificación ........................................................................... 42
4.3. Visualización de información ............................................................................................. 44
4.4. Programación Tangible....................................................................................................... 45
4.5. Entretenimiento, juego y entretenimiento educativo ....................................................... 46
4.6. Comunicación social ........................................................................................................... 50
4.7. Música y performance multimedia .................................................................................... 52
4.8. TUI de mesa para música ................................................................................................... 56
4.9. Secuenciadores Tangibles .................................................................................................. 59
5. Frameworks y Taxonomías de las Interfaces Tangibles ............................................................ 65
5.1. Propiedades de las Gaspables User Interfaces .................................................................. 65
5.2. Conceptualización de las TUIs y el modelo de interacción MCRit ..................................... 66
5.3. Clasificación de las TUIs ...................................................................................................... 67
8
5.4. Token And Constraint ......................................................................................................... 67
5.5. Fortalezas del enfoque Token + Constraint ........................................................................ 69
6. Tecnologías de implementación para TUIs ............................................................................... 71
6.1. RFID .................................................................................................................................... 71
6.2. Micro-controladores, sensores y actuadores ..................................................................... 72
6.3. Visión por Computadora .................................................................................................... 74
6.4. Toolkits y librerías para implementar Interfaces Tangibles ............................................... 79
7. Fortalezas y limitaciones de las TUIs ......................................................................................... 82
7.1. Fortalezas ........................................................................................................................... 82
7.2. Limitaciones........................................................................................................................ 87
PARTE III - DESARROLLO EXPERIMENTAL .......................................................................................... 91
1. Introducción .............................................................................................................................. 92
2. Primer Prototipo ........................................................................................................................ 93
2.1. Diseño ................................................................................................................................. 93
2.2. Implementación - Introducción .......................................................................................... 97
2.3. Elementos y herramientas utilizadas ................................................................................. 98
2.4. Diseño de clases e implementación del código ............................................................... 103
2.5. Análisis de los resultados ................................................................................................. 111
3. Segundo Prototipo .................................................................................................................. 114
3.1. Diseño ............................................................................................................................... 114
3.2. Elementos y herramientas utilizadas ............................................................................... 116
3.3. La Maquina: grabadora y cortadora laser ........................................................................ 116
3.4. Implementación del tablero ............................................................................................. 119
3.5. Calibración del software ................................................................................................... 123
3.6. Análisis de los resultados ................................................................................................. 123
PARTE IV - CONCLUSIONES .............................................................................................................. 125
1. Resumen .................................................................................................................................. 126
2. Limitaciones, problemas y cuestiones pendientes ................................................................. 126
3. Trabajo futuro ......................................................................................................................... 127
3.1. Mejoras ............................................................................................................................ 127
3.2. Extensiones ...................................................................................................................... 128
3.3. Pruebas de usabilidad ...................................................................................................... 129
9
PARTE V - ELEMENTOS FINALES ...................................................................................................... 130
Bibliografía .................................................................................................................................. 131
Anexo .......................................................................................................................................... 140
Código...................................................................................................................................... 140
10
PARTE I - INTRODUCCIÓN
Pues resulta que una vez el violinista Schuppanzigh se quejó por lo difícil que le resultaba tocar el
Nº 7, y Beethoven le contestó: “¿Cree que Pienso en sus miserables cuerdas cuando el espíritu me
habla?” – Beethoven
1. Motivación ………………………………………… 11 2. Objetivos …………………………………………… 12 3. Estructura del trabajo ………….………….… 13
11
1. Motivación Con el rápido desarrollo de las tecnologías de computación, la mayoría de los contenidos
multimedia, como audio, música, video, gráficos generados por computadora, están disponibles
en formato digital, pudiendo ser creados, accedidos y manipulados a través de las computadoras.
Por lo tanto, el uso de contenidos multimedia ha aumentado notablemente y juega, hoy en día, un
papel clave en el área del entretenimiento, la música y el arte. Sin embargo, mucha gente,
incluyendo a los músicos, todavía tiene dificultades para interactuar con estos medios digitales,
inclusive a través de las Interfaces Graficas de Usuario (GUI), las cuales mitigan el problema hasta
cierto punto. A fin de superar estos inconvenientes, la interfaz tangible de usuario se ha propuesto
como un nuevo tipo de interfaz que permita a los usuarios controlar intuitivamente la información
digital mediante el uso de objetos físicos.
Con el rápido desarrollo de las computadoras durante las dos últimas décadas, han surgido en el
mercado una gran cantidad de métodos de generación de sonido. Las herramientas de
composición también han evolucionado radicalmente con el uso de secuenciadores y sistemas de
grabación multi-pista. A pesar de esto, las interfaces no han evolucionado mucho. Todavía se
basan en los modelos de perillas y deslizadores, y en los modelos de los instrumentos clásicos,
sobre todo el del teclado. Sin embargo, existe una necesidad real de nuevas interfaces musicales.
Hoy se requieren nuevas interfaces musicales capaces de interpretar la música actual, con nuevas
capacidades gestuales y funcionales, pero con el mismo nivel de expresividad que se encuentra en
los instrumentos musicales tradicionales.
El software musical puede ofrecer la mayor parte de la funcionalidad que ofrece un estudio
musical completo en una sola computadora por una fracción pequeña? del costo. Pero gran parte
de la ventaja se pierde cuando la interfaz física desaparece y se sustituye por una réplica gráfica. El
mouse y el teclado son dispositivos de entrada genéricos, y aunque son eficaces para el
procesamiento de textos y las tareas orientadas al diseño gráfico, no son adecuadas para la
edición y composición musical.
Los años noventa presenciaron el surgimiento de un nuevo paradigma de interpretación musical.
Los músicos electrónicos, sentados detrás de los monitores de sus computadoras portátiles,
podían tocar su música ante el público sin traer un cargamento gigante de sintetizadores y cables
de conexión. Sin embargo, la transición a la performance basada en las computadoras portátiles
creó una grieta entre el artista y el público ya que no había casi ninguna presencia en el escenario
con la cual el espectador se podía relacionar. Por otra parte, los artistas perdieron gran parte de la
fuerza expresiva de los instrumentos tradicionales analógicos. Sus improvisaciones en vivo se
basaban en el uso de los teclados de sus computadoras portátiles y por lo tanto carecían de
matices, sutileza, y capacidad de improvisación.
Las interfaces más extendidas para resolver estas falencias han sido los controladores MIDI basado
en perillas o deslizadores. Estos dispositivos, disponibles comercialmente, son útiles debido a su
modularidad y a su similitud con las mesas de mezcla de audio analógico. Desafortunadamente,
tienen desventajas obvias. Las perillas y deslizadores son demasiado modulares: los músicos
12
pasan más tiempo recordando lo que hace cada perilla en lugar de centrarse en la interpretación o
performance en sí. Además, estas interfaces carecen de carácter expresivo, y es difícil controlar
varios parámetros a la vez.
El investigador y músico experimental John Bowers ha utilizado el término ecología de la
performance para describir la zona de actividad creada por un músico en su entorno inmediato. En
sus estudios resalta la importancia de la disposición espacial de los dispositivos de control y los
instrumentos, no sólo para permitir que el músico pueda ser más eficaz en su performance, sino
también para facilitar la comunicación de sus intenciones con los compañeros de interpretación y
la audiencia [1].
El objetivo de este trabajo es investigar, diseñar y desarrollar un tipo de interfaz que aproveche las
ventajas del software actual y las nuevas tecnologías para realizar un sistema que permita mejorar
la usabilidad y la experiencia de la manipulación de música digital.
Muchos ejemplos interesantes de interfaces tangibles de usuario se encuentran en el dominio de
la creación e interpretación musical tales como Audiopad [2], BlockJam [3], y ReacTable [4]. Esto
no es sorprendente, ya que estas modalidades alternativas de interacción a menudo pueden ser
más útiles, intuitivas y agradables para un músico que el teclado y el mouse tradicional, que son
más adecuados para el procesamiento de textos y las tareas de diseño gráfico, pero no tanto para
el trabajo con audio. Jordà [5] identifica varias propiedades de las interfaces tangibles y de las
mesas multi-táctiles que las sitúan como un enfoque prometedor para la interpretación musical: el
soporte para la colaboración y el intercambio de control entre usuarios, la interacción continua y
en tiempo real con datos multidimensionales, y el soporte para interacciones complejas,
especializadas, expresivas, y exploratorias.
2. Objetivos A continuación se enuncian los objetivos planteados en el presente proyecto. Primero se describe
el objetivo principal o general del trabajo, y luego el mismo se desglosa en objetivos específicos.
También se incluyen algunos objetivos secundarios que también se tendrán en cuenta.
Objetivo general
Realizar un estudio bibliográfico del campo de las interfaces tangibles de usuario y su
aplicabilidad en el área de composición musical para luego utilizar los conocimientos
adquiridos en el diseño, implementación, testeo y análisis de un prototipo funcional de
interfaz tangible para la creación de música.
Objetivos específicos
Realizar un estudio bibliográfico del campo de las interfaces tangibles, investigando sus
motivaciones, dominios de aplicación, taxonomías, tecnologías de implementación y sus
fortalezas y debilidades, teniendo siempre como objetivo la utilización de este
conocimiento para el desarrollo de una interfaz tangible de usuario para la creación de
música.
13
Diseñar e implementar el sistema basado en los conocimientos adquiridos en la
investigación previa.
Diseñar e implementar el sistema con herramientas y materiales de fácil acceso y bajo
costo.
Diseñar el sistema de forma tal que cuente con una curva de aprendizaje elevada, de
manera que permita ser rápidamente comprendido y operado.
3. Estructura del trabajo El presente trabajo se desarrolla en el marco del Proyecto Final de Carrera de Ingeniería de
Sistemas de Computación, carrera perteneciente al Departamento de Ciencias e Ingeniera de la
Computación (DCIC) de la Universidad Nacional del Sur de Bahía Blanca, Argentina. El mismo
también se encuadra dentro del proyecto de investigación dirigido por el Lic. Sergio Martig,
"Interfaces No Convencionales. Su Impacto en las Interacciones” (PGI SeCyT-UNS. Código:
24/ZN19.)
El trabajo se basa, inicialmente, en la investigación bibliográfica del campo de las interfaces
tangibles de usuario, centrándose en aquéllas relacionadas con la música. Dicha investigación
sienta las bases para el análisis, diseño y desarrollo de un prototipo que posea una interfaz
tangible de usuario para la creación de música que aproveche todo el conocimiento adquirido en
la investigación previa.
El trabajo se separa en cuatro partes: Introducción, Marco Teórico, Desarrollo Experimental y
Conclusiones. Adicionalmente hay una quinta parte llamada Elementos Finales que incluye las
fuentes bibliográficas y el anexo.
La primera parte, la Introducción, presenta los elementos introductorios del trabajo, con el
objetivo de presentar el proyecto y ubicar al lector en el mismo, dándole un pantallazo de lo que
va a encontrar. Se presentan las motivaciones que llevaron al autor a desarrollar el trabajo, así
como los objetivos buscados con el desarrollo del mismo. Finalmente se detalla la estructura del
trabajo presentando y describiendo brevemente cada sección, de forma tal de ofrecer al lector un
pantallazo de cada sección, permitiéndole entender la relación de cada parte del trabajo y el por
qué de la mismas.
En la segunda parte del trabajo, el Marco Teórico, se sientan las bases conceptuales para el
posterior desarrollo del prototipo, de forma tal que el mismo aproveche todo el conocimiento
detallado en esta sección. La investigación está pensada teniendo en cuenta el desarrollo de un
prototipo de interfaz tangible de usuario para la creación de música, por lo que es esto lo que
sienta la guía principal de investigación.
Inicialmente se introducen algunos conceptos básicos, una definición inicial de interfaz tangible de
usuario para que el lector tenga un conocimiento mínimo que le permita ir avanzando por el
trabajo a medida que se va formando un concepto más completo y global del tema
14
Las interfaces tangibles de usuario se encuentran enmarcadas dentro de un área mucho más
amplia, denominada Interacción Humano-Computadora, por lo que inicialmente se da una
introducción al tema, así como una breve descripción de su historia y evolución.
Posteriormente se abordan los orígenes de las interfaces tangibles así como las distintas
definiciones y su evolución. Adicionalmente se describen algunos sistemas que fueron los
precursores de dicho tipo de interfaz.
En la siguiente sección se analizan los distintos dominios de aplicación de las interfaces tangibles,
describiendo y analizando los ejemplos más relevantes de cada área de aplicación, así como sus
fortalezas y aquellos aspectos que los destacan. Se le da especial atención al dominio de aplicación
referido a la música y performance?, ya que es el área en la cual se encuadra el caso de estudio a
desarrollar. Luego se analizan casos específicos de interfaces tangibles de mesa para música y
casos específicos de secuenciadores tangibles. Estas dos últimas secciones se explicitan
detalladamente ya que se desea desarrollar un secuenciador tangible que también aproveche los
beneficios de las interfaces de mesa.
Luego se brinda un marco teórico para las interfaces tangibles, esto es, se desarrollan las
propiedades que debe tener una interfaz tangible para poder ser definida como tal, y se formaliza
su definición. El objetivo de esta sección es formalizar el conocimiento adquirido en el área. Luego
se presenta uno de los modelos de interacción tangible más populares, MCRit, contrastándolo con
el ampliamente conocido modelo MVC, con el objetivo de comprender más formalmente cómo se
desarrolla la interacción tangible. Luego se presenta una taxonomía de las interfaces tangibles.
Finalmente se presenta y analiza el paradigma Token And Constraint.
En esta sección se analizan las distintas alternativas de implementación que existen para el
desarrollo de interfaces tangibles. Se citan distintos ejemplos implementados con cada una de
estas tecnologías, así como las principales ventajas y limitaciones de cada una de ellas. Se hace
especial hincapié en las tecnologías de implementación basadas en visión por computadora. Entre
ellas se destaca la librería de visión por computadora OpenCV, la cual se investiga en mayor
profundidad dado que será utilizada en el desarrollo del prototipo.
Finalmente se abordan las principales fortalezas y limitaciones de las interfaces tangibles, de
forma tal que en el proceso de desarrollo del caso de estudio se puedan maximizar las primeras y
reducir las segundas. Cabe destacar que Shaer y Hornecker [6] brindan una excelente y completa
monografía sobre el trabajo existente en el campo de las interfaces tangibles de usuario, el cual
será utilizado como fuente principal de consulta.
Adicionalmente la estructura del trabajo se basa en dos fuentes bibliográficas [7] [8] que brindan
ciertas pautas de cómo desarrollar un escrito de esta índole.
La tercera parte del trabajo corresponde al Caso de Estudio y consiste en el desarrollo
experimental de un sistema tangible. En ésta se describe cómo se aplicaron los conocimientos
adquiridos durante la investigación en el diseño e implementación de un prototipo de interfaz
15
tangible para la creación de música. Esta tercera parte del trabajo cuenta con tres secciones
principales: una introducción que describe brevemente, y en términos generales, el prototipo
desarrollado; una segunda sección que describe el primer prototipo y una tercera y última sección
que describe el segundo prototipo, presentando las mejoras con respecto al primero.
La sección principal correspondiente al desarrollo experimental, Primer Prototipo, cuenta con
cinco sub secciones. En la primera sub sección, Diseño, se presenta la propuesta, se introduce la
idea conceptual del sistema junto a su modo de interacción. En las mismas se describe de forma
abstracta, independiente de la implementación, el concepto y la forma de interactuar con el
sistema. Adicionalmente se presenta un caso de uso para facilitar la comprensión de cómo utilizar
el sistema.
La siguiente sub sección, Implementación – Introducción, describe en términos generales cómo
fue implementada técnicamente la propuesta presentada en la sub sección anterior y justifica la
elección de visión por computadora como tecnología de implementación. El objetivo de esta sub
sección es presentar al lector una idea general de la implementación antes de proseguir en
profundidad, de forma que el mismo tenga una idea general de lo que se va a describir a
continuación y no se pierda en los detalles.
La próxima sub sección, Elementos y herramientas utilizadas, describe los elementos de Hardware
y Software utilizados para la implementación del prototipo y justifica la elección de los mismos.
En la siguiente sub sección, Diseño de clases e implementación del código, se describe el
modelado UML realizado y se explican las principales clases del sistema, incluyendo sus
responsabilidades y obligaciones. En esta sub sección se describe en detalle todo lo relacionado al
método de visión por computadora utilizado. Finalmente se describe la GUI implementada para el
prototipo y se indica la dirección web de donde se puede descargar el código completo del mismo.
En la última sub sección perteneciente a Primer Prototipo se describen los resultados obtenidos a
partir del desarrollo del sistema y de las pruebas informales realizadas sobre el mismo. En esta sub
sección de detallan los principales desafíos encontrados a lo largo del desarrollo del prototipo y las
soluciones utilizadas para superarlos. Finalmente se describen los principales problemas y
limitaciones de esta primera versión del sistema.
La parte de Desarrollo Experimental cuenta con una segunda y ultima sección titulada Segundo
Prototipo. En la misma se presenta un tablero con fichas encastrables que apunta a superar las
limitaciones más importantes que tiene el sistema diseñado e implementado anteriormente, la
robustez del reconocimiento de imágenes. En esta sección se diseña e implementa dicho tablero,
de forma tal que aproveche las ventajas del paradigma de interfaces tangibles denominado Tokens
+ Constraints. Se describen los elementos utilizados para implementar dicho tablero encastrable y
luego se explica el método utilizado para implementarlo mediante el uso de una máquina de corte
y grabado láser. Finalmente se analizan los resultados obtenidos y se enuncian las ventajas
brindadas por este nuevo sistema de tablero y fichas.
16
En la cuarta parte se presentan las conclusiones del trabajo. Adicionalmente se describen las
principales limitaciones del prototipo y se presentan posibles mejoras apuntadas a solucionar
dichas falencias. Se sugieren posibles extensiones pensadas para implementar en un trabajo
futuro. Finalmente, se hace hincapié en la importancia de realizar un trabajo apuntado a analizar
la usabilidad del prototipo mediante pruebas formales.
Finalmente, en la quinta y última parte del trabajo, denominada Elementos Finales, se incluyen las
referencias y fuentes bibliográficas utilizadas y el anexo, el cual incluye el código completo del
sistema.
17
PARTE II - MARCO TEÓRICO
"...queremos ser capaces de hacer con nuestros instrumentos todo lo que podamos imaginar: una
voz, una guitarra, un teclado, la idea es expresar, proyectar a través de tu instrumento lo que
quiera que tengas en tu mente...” - Jordan Rudess - Dream Theater
1. Conceptos básicos…………………………………………………………….…. 18 2. Interacción Humano-Computadora……………………………………... 19 3. Orígenes de las Interfaces Tangibles…………………………………….. 34 4. Dominios de Aplicación de las Interfaces Tangibles ……………… 41 5. Frameworks y Taxonomías de las Interfaces Tangibles ………… 65 6. Tecnologías de implementación para TUIs…………………………... 71 7. Fortalezas y limitaciones de las TUIs ……………………………………. 82
18
1. Conceptos básicos En esta sección se presenta una breve definición de interfaz tangible de usuario (TUI por su sigla
en inglés proveniente del término Tangible User Interface) con el objetivo de introducir al lector en
el tema, y permitirle tener una pequeña noción del concepto que le permita avanzar, sin
dificultad, por las distintas secciones del trabajo, a medida que se asimila el concepto de interfaz
tangible y todo su contexto.
1.1. Interfaces Tangibles de Usuario Una interfaz tangible es, básicamente, una interfaz de usuario que permite que una persona
interactúe con un sistema digital a través de un medio físico. Una característica central es la
perfecta capacidad de integración entre los conceptos de representación y control, con objetos
físicos o tangibles actuando simultáneamente como representación de información y control físico
para la manipulación directa de las asociaciones subyacentes. [9]
Esta "integración de la representación y el control" significa que los objetos físicos o tangibles
encarnan tanto a los medios de representación como a los medios de manipulación de los datos
digitales. Hay cuatro características claves que ayudan a definir a las TUIs:
1. Los objetos tangibles se acoplan, a través de funcionalidades computacionales, con datos
digitales (acoplamiento computarizado).
2. Los objetos tangibles representan los medios de control interactivo. El movimiento y la
manipulación de objetos físicos es la forma dominante de control.
3. Los objetos tangibles están perceptivamente ligados con representaciones producidas
digitalmente (por ejemplo, audio y visuales, proyecciones).
4. El estado de los objetos tangibles representa aspectos centrales del estado del sistema (el
sistema es, al menos, parcialmente legible si se corta la energía).
La exploración y la manipulación de objetos físicos son los componentes clave del aprendizaje,
como es el caso particular del aprendizaje musical. El poder educativo de la tecnología digital ha
sido típicamente limitado por el hecho que los usuarios exploran y manipulan representaciones
abstractas basadas en el monitor de dos dimensiones, y no enverdaderos objetos físicos. Embeber
interactividad en objetos físicos, por lo tanto, permite el "mejor de ambos mundos”, soporte del
juego exploratorio tradicional con objetos físicos que pueden ser ampliados y realzados por el
poder interactivo de la tecnología digital.
19
2. Interacción Humano-Computadora La Interacción Humano-Computadora (IHC) es un área de investigación y práctica que surgió en la
década de 1980, inicialmente como un área de especialidad en Ciencias de la Computación. La IHC
se ha expandido rápidamente y de manera constante durante las tres últimas décadas, atrayendo
a profesionales de otras disciplinas e incorporando diversos conceptos y enfoques. En gran
medida, la IHC es ahora una colección de agregados provenientes de distintos campos de
investigación y prácticas relacionadas a la informática centrada en el humano.
2.1. Definición Actualmente no hay acuerdo sobre la definición de la gama de temas que integran el área de
interacción humano-computadora. Sin embargo, es necesaria una caracterización del campo si se
quiere obtener y desarrollar conocimiento y material para la misma. Por lo tanto, la ACM ofrece
una definición de trabajo que nos permite desarrollar el tema:
La Interacción humano-computadora es una disciplina que estudia el diseño, evaluación e
implementación de sistemas informáticos interactivos para uso humano y el estudio de los
fenómenos más importantes que los rodean. [10]
Desde la perspectiva de la informática, la atención se centra en la interacción y, específicamente,
en la interacción entre uno o más seres humanos y uno o varios equipos de cómputo. La situación
clásica es una persona que usa un programa de gráficos interactivos en una PC de escritorio. Pero
está claro que la variación de lo que se entiende por la interacción, el humano, y la máquina
genera un rico espacio de posibles temas de estudio, algunos de los cuales, se identificarán como
temas centrales y otros periféricos a la IHC.
Tómese la idea de la computadora. En lugar de ser estaciones de trabajo, los equipos pueden ser
sistemas embebidos, tales como partes de cabinas de naves espaciales y hornos de microondas.
Debido a que las técnicas para el diseño de estas interfaces tienen tanto en común con las técnicas
para diseño de interfaces de estaciones de trabajo, ambas pueden ser provechosamente tratadas
de forma conjunta. Pero si se debilita aun más la restricción sobre los aspectos computacionales y
la interacción y se trata el diseño de máquinas mecánicas y pasivas, tales como el diseño de un
martillo, se estará claramente en los márgenes de la actividad, por lo que en general las relaciones
entre los seres humanos y los martillos no se consideran parte del campo de la interacción
humano-computadora. Este tipo de relaciones sería claramente parte del campo de Factores
Humanos en general, que estudia los aspectos humanos de todos los dispositivos diseñados, pero
no los mecanismos de estos dispositivos. La Interacción humano-computadora, por el contrario,
estudia tanto el lado del mecanismo como el lado humano, pero de una clase restringida de
dispositivos.
¿Qué es lo que se entiende por la noción de ser humano? Si se permite que el humano sea un
grupo de seres humanos o una organización, se pueden considerar interfaces para sistemas
distribuidos, sistemas de comunicación entre humanos, o la naturaleza del trabajo que se realiza
20
de forma cooperativa por medio de un sistema. Todos estos temas son considerados como
centrales en el ámbito de los estudios de interacción humano-computadora.
Hay otros puntos de vista de la disciplina, que hacen foco en IHC de forma diferente al que se hace
desde las Ciencias de la Computación. IHC es en general un área interdisciplinaria. Se está
convirtiendo en un tema de especialidad dentro de varias disciplinas, cada una con diferente
énfasis: Ciencias de la Computación (diseño de la aplicación e ingeniería de las interfaces
humanas), Psicología (aplicación de las teorías de los procesos cognitivos y análisis empírico del
comportamiento del usuario), Sociología y Antropología (interacciones entre la tecnología, el
trabajo y la organización), y Diseño Industrial (productos interactivos). Desde la perspectiva de las
Ciencias de la Computación, otras disciplinas sirven como disciplinas de apoyo, tanto como la
Física sirve como disciplina de apoyo para la Ingeniería Civil, la Ingeniería Mecánica sirve como
apoyo para la Robótica. Una lección aprendida por disciplinas de Ingeniería es que los problemas
de diseño tienen un contexto, y que la optimización excesivamente estrecha de una parte de un
diseño puede ser anulada por el contexto más amplio del problema. Incluso desde una perspectiva
directa de Ciencias de la Computación, es ventajoso enmarcar el problema de la Interacción
Humano-Computadora de manera suficientemente amplia para ayudar a los estudiantes,
investigadores y profesionales a evitar la trampa clásica del diseño divorciado del contexto donde
se ubica el problema.
Para brindar una caracterización más aproximada de Interacción Humano-Computadora como un
campo de investigación, se enumeran algunos de sus intereses específicos:
IHC se refiere a la actuación conjunta de humanos y máquinas para resolver tareas,
la estructura de comunicación entre humanos y máquinas;
las capacidades humanas para utilizar las máquinas (incluyendo la capacidad y facilidad de
aprendizaje de las interfaces),
los algoritmos y la programación de la interfaz en sí misma,
los desafíos ingenieriles que se plantean al diseñar y construir las interfaces,
el proceso de especificación, diseño e implementación de las interfaces, así como su
comparación y evaluación.
Por lo tanto IHC involucra tanto ciencia, ingeniería como también aspectos de diseño.
Independientemente de la definición elegida de IHC, es claro que debe incluirse como parte de las
Ciencias de la Computación y forma tanto parte de esta ciencia como de cualquier otra de las
disciplinas involucradas. Si, por ejemplo, se adopta la definición clásica de Ciencias de la
Computación que la define como "el estudio de las computadoras y los principales fenómenos
que los rodean"[11], entonces la interacción de las personas y las computadoras y el uso de la
mismas son sin duda partes de estos fenómenos. Si, por el contrario, tomamos la definición de la
ACM que sostiene que es "el estudio sistemático de procesos algorítmicos que describen y
transforman información: su teoría, análisis, diseño, eficiencia, implementación y aplicación "[12],
entonces los procesos algorítmicos claramente incluyen la interacción con los usuarios de la misma
21
manera que incluyen la interacción con otras computadoras a través de las redes. Los algoritmos
de computación gráfica, por ejemplo, son algoritmos que dan ciertas experiencias perceptivas al
aparato sensorial del ser humano. El diseño de muchas aplicaciones informáticas modernas
requiere ineludiblemente del diseño de algún componente del sistema que interactúe con el
usuario. Además, este componente suele representar más de la mitad de las líneas de código del
sistema. Es fundamental comprender cómo decidir sobre qué funcionalidad tendrá un sistema,
cómo llevar esto al usuario, la forma de construir el mismo y la forma de probarlo.
Debido a que IHC estudia la comunicación e interacción entre el ser humano y la computadora, se
basa en el conocimiento tanto de la computadora como del ser humano. Por el lado de la
computadora son relevantes las técnicas de gráficos por computadora, los sistemas operativos, los
lenguajes de programación y los entornos de desarrollo, entre otros; por el lado humano son
relevantes la teoría de la comunicación, las disciplinas de diseño gráfico e industrial, la lingüística,
las ciencias sociales, la psicología cognitiva, entre otros. Y, por supuesto, son también relevantes
los métodos de ingeniería y diseño.
2.2. Componentes de IHC El siguiente listado de temas abarca los tópicos representativos en relación con todos los aspectos
de diseño y de análisis de sistemas involucrados en el campo de Interacción Humano-
Computadora. Los temas se derivan de la consideración de los siguientes cinco (¿No serán cuatro?)
aspectos interrelacionados de IHC:
1. El uso y contexto del sistema (U)
2. El usuario humano (H)
3. La computadora (C)
4. El proceso de desarrollo del sistema (D)
Las letras entre paréntesis permiten referenciar cada uno de los aspectos en la Figura 1 -
Componentes de la IHC [10].
22
Figura 1 - Componentes de la IHC [10]
2.2.1. El uso y contexto del sistema (U)
Los usos de las computadoras se describen como “aplicaciones” en el mundo de la informática.
Estos usos y el grado en que la interfaz (y la lógica de la aplicación en el resto del sistema) se
adapta a ellos pueden tener un profundo impacto en cada parte de la interfaz y su éxito. Por otra
parte, el contexto social, de trabajo, y de negocios también puede ser importante. Además de los
requisitos técnicos, una interfaz puede tener que satisfacer normas laborales de algún sindicato o
cumplir con restricciones legales sobre el “look-and-feel" o inclusive ayudar a posicionar la imagen
de una empresa en un determinado mercado. Los siguientes temas tienen que ver con los
problemas generales de adaptar y combinar entre sí las computadoras, los usos determinados y
los contextos establecidos.
U1. Organización social y trabajo
Este epígrafe se refiere al ser humano como un ser social que interactúa. Se ocupa de la naturaleza
del trabajo, y de la idea de que los sistemas humanos y los sistemas informáticos se deben adaptar
mutuamente el uno al otro siendo considerados como un todo.
Puntos de vista (por ejemplo, ingeniería industrial, Investigación de Operaciones [13],
Ingeniería Cognitiva de Rasmussen [14], enfoque de Diseño Participativo de Aarhus [15],
Sistemas Abiertos de Hewitt [16])
23
Modelos de la actividad humana (por ejemplo, la planificación oportunista, los
procedimientos abiertos)
Modelos de pequeños grupos, y modelos de organizaciones
Modelos de trabajo, flujo de trabajo, actividad cooperativa, trabajo de oficina
Sistemas socio-técnicos, organizaciones humanas como sistemas abiertos adaptativos,
impacto mutuo de los sistemas informáticos en el trabajo y viceversa, sistemas
informáticos para tareas grupales, casos de estudio
Calidad de la vida laboral y satisfacción en el trabajo
U2. Áreas de aplicación
Esta sección trata sobre las clases de dominios de aplicación y las áreas de aplicación específicas
donde se han desarrollado interfaces específicas.
Caracterización de las áreas de aplicación (por ejemplo, el individuo frente al grupo)
Interfaces orientadas a documentos: edición de texto, formato de documentos, hojas de
cálculo, ilustradores, hipertexto
Interfaces orientadas a las comunicaciones: correo electrónico, conferencias por
computadora, teléfono y sistemas de mensajería de voz
Entornos de diseño: los entornos de programación, CAD/CAM
Sistemas de ayuda on-line
Puestos de información multimedia
Sistemas de control continuo: sistemas de control de procesos, sistemas de realidad
virtual, simuladores, juegos de video.
Los sistemas embebidos: controles de fotocopiadora, controles de ascensores, aparatos
electrónicos y controladores de electrodomésticos (por ejemplo, televisores,
videocaseteras, hornos de microondas, etc.)
Sistemas para la creación y performance de música en vivo. Instrumentos musicales
digitales.
U3. Ajuste y adaptación hombre-máquina
Parte de la finalidad del diseño es la de establecer una adecuación entre el objeto diseñado y su
uso. Hay varias dimensiones para esta adecuación y los ajustes se pueden realizar en varios
lugares:
1. En tiempo de diseño o en el momento de uso.
2. Cambiando al sistema o al usuario.
3. Los cambios pueden ser realizados por los usuarios o, a veces, por el propio sistema.
Los temas de este epígrafe se refieren a modificar algunos de los componentes de un sistema
socio-técnico con el fin de mejorar su ajuste.
Técnicas alternativas para lograr el ajuste
24
Naturaleza de los sistemas adaptativos, adaptaciones de los sistemas humanos que anulan
las mejoras de confiabilidad, la naturaleza del error en los sistemas adaptativos
redundantes, hallazgos empíricos sobre la improvisación del usuario en sistemas
rutinarios, factores determinantes de la introducción exitosa de sistemas
Selección del sistema: teorías de adopción de sistemas
Adaptación del sistema: técnicas de personalización
Selección del usuario: compatibilidades de las características del usuario y el sistema
Adaptación del usuario: facilidad de aprendizaje, métodos de entrenamiento (por ejemplo,
tutoriales on-line), relación con el diseño del sistema
Orientación del usuario: técnicas de ayuda, documentación, técnicas de manejo de errores
2.2.2. Características humanas (H)
Es importante entender algunas características del procesamiento humano de información, cómo
se estructura la acción humana, la naturaleza de la comunicación humana y las necesidades
humanas físicas y fisiológicas.
H1. Procesamiento humano de la información
Características del humano como procesador de información.
Modelos de la arquitectura cognitiva: sistema de símbolos, modelos conexionistas,
modelos de ingeniería
Fenómenos y teorías de la memoria
Fenómenos y teorías de la percepción
Fenómenos y teorías de las habilidades motoras
Fenómenos y teorías de la atención y la vigilancia
Fenómenos y teorías de la resolución de problemas
Fenómenos y teorías del aprendizaje y la adquisición de habilidades
Fenómenos y teorías de la motivación
Modelos conceptuales de los usuarios
Modelos de la acción humana
Diversidad humana, incluyendo la población con discapacidad
H2. Lenguaje, comunicación e interacción
El lenguaje como medio de comunicación e interfaz. Los fenómenos de la comunicación.
Aspectos del lenguaje: sintaxis, semántica, pragmática
Modelos formales de la lengua
Fenómenos pragmáticos de la interacción conversacional (por ejemplo, tomar turnos)
Fenómenos del lenguaje
Lenguajes especializados (por ejemplo, la interacción gráfica, consulta, comando, los
sistemas de producción)
Reutilización de la interacción (por ejemplo, listas de historial)
Lenguaje y comunicación tangible.
25
H3. Ergonomía
Las características antropométricas y fisiológicas de las personas y su relación con los parámetros
de espacio de trabajo y medio ambiente.
Antropometría humana en relación con el diseño del área de trabajo
Disposición de las pantallas y los periféricos de control
Limites cognitivos y sensoriales del humano
Efectos sensoriales y de percepción de las distintas tecnologías de visualización,
legilibilidad, diseño de la pantalla o dispositivo
Control de diseño
Fatiga y problemas de salud
Diseño de muebles e iluminación
Problemas de temperatura y ruido ambiental
Diseño de entornos estresantes o peligrosos
Diseño para personas con discapacidades
Diseño de nuevos instrumentos musicales.
2.2.3. Sistema informático y arquitectura de la interfaz (C)
Las máquinas tienen componentes especializados para interactuar con los seres humanos. Algunos
de estos componentes son básicamente transductores para mover la información física entre el
hombre y la máquina. Otros componentes tienen que ver con la estructura de control y la
representación de los aspectos de la interacción. Estos componentes especializados están
cubiertos en los siguientes temas.
C1. Dispositivos de entrada y salida
La construcción técnica de los dispositivos para mediar entre humanos y máquinas.
Dispositivos de entrada: encuesta, mecánica de un dispositivo particular, características
de rendimiento (humano y sistema), dispositivos para personas con discapacidades,
dispositivos de escritura, de gestos, de entrada de voz, seguimiento de ojos, dispositivos
exóticos (por ejemplo, electroencefalografía y otras señales biológicas)
Dispositivos de salida: encuesta, mecánica de los dispositivos, dispositivos vectoriales,
dispositivos de rasterizado, tarjetas graficas, manejo de eventos, características de
rendimiento, dispositivos de salida para personas con discapacidad, sonido y el habla,
pantallas 3D, movimiento (por ejemplo, simuladores de vuelo) , dispositivos exóticos
Características de los dispositivos de entrada/salida (por ejemplo, peso, portabilidad,
ancho de banda)
Dispositivos virtuales
Diseño, construcción e implementación mediante soluciones tecnológicas de interfaces
tangibles de usuario.
C2. Técnicas de diálogo
La arquitectura de software y las técnicas básicas para interactuar con seres humanos.
26
Diálogos de entrada:
Tipos de propósitos de la entrada (por ejemplo, selección, especificación de parámetros
discretos, control continuo)
Técnicas de entrada: técnicas de teclado (por ejemplo, comandos, menús), técnicas de
mouse (por ejemplo, “drag-and-drop”), técnicas basadas en el lápiz (por ejemplo,
reconocimiento de caracteres, de gestos), técnicas basadas en la voz
Diálogos de salida:
Tipos de propósitos de la salida (por ejemplo, transmitir información precisa, información
de resumen, crear visualizaciones de información)
Técnicas de salida (por ejemplo, scrolling de la pantalla, ventanas, animación)
Cuestiones de diseño de pantalla (por ejemplo, el enfoque, el desorden, la lógica visual)
Técnicas de interacción de diálogo:
Tipo y técnicas de diálogo (por ejemplo, técnicas alfanuméricas, rellenado de formularios,
selección de menúes, íconos y manipulación directa, funciones genéricas, lenguaje
natural)
Navegación y orientación en los diálogos, gestión de errores
Diálogos multimedia y no gráficos: entrada de voz, salida de voz, correo de voz, correos de
video, documentos activos, DVDs
Agentes y técnicas de Inteligencia Artificial
Diálogos multi-persona
Técnicas de diálogo o interacción tangible. (Ej: Token + Constraints )
Cuestiones relativas al dialogo:
Cuestiones relacionadas con las respuestas en tiempo real
Teoría de control manual
Control supervisado, sistemas automáticos, sistemas embebidos
Normas y estándares
Propiedad intelectual del “Look-and-Feel”
Técnicas de colaboración y trabajo en equipo.
C3. Tipos de diálogo
Los usos conceptuales que se llevan a cabo mediante la aplicación de los medios técnicos. Dichos
conceptos surgen en cualquier disciplina relacionada con los medios de comunicación (por
ejemplo, el cine, el diseño gráfico, etc.)
Metáforas de interacción (por ejemplo, la metáfora de herramientas, la metáfora del
agente)
27
Metáforas de contenido (por ejemplo, la metáfora del escritorio, la metáfora del
documento en papel)
Persona, personalidad, punto de vista
Modelos de espacio de trabajo
Gestión de la transición (por ejemplo, desvanecimiento, barrido de cámara)
Técnicas relevantes de otros medios (por ejemplo, cine, teatro, diseño gráfico)
Estilo y estética
C4. Computación Gráfica
Conceptos básicos de gráficos por computadora que son especialmente útiles para IHC.
Geometría 2D y 3D del espacio, transformaciones lineales
Primitivas gráficas y atributos: representaciones de mapas de bits y voxels, operaciones de
rasterizado, Quadtrees y Octrees, imágenes independientes del dispositivo, lenguajes de
descripción de páginas
Modelado de sólidos, splines, modelado de superficies, eliminación de superficies ocultas,
animación, algoritmos de renderizado, modelos de iluminación
Representación de color, mapas de color, gamas de colores de los dispositivos
C5. Arquitectura de diálogo
Arquitecturas de software y estándares para interfaces de usuario.
Modelo de capas de la arquitectura de los diálogos y los sistemas de ventanas, modelos de
referencia de sistemas de diálogo
Modelos de imágenes de pantalla (por ejemplo, RasterOp, PostScript, QuickDraw)
Modelos de gestión de ventanas (por ejemplo, la dirección compartida del espacio,
cliente-servidor), análisis de los sistemas de ventanas más importantes (por ejemplo, X,
New Wave, Windows, Open Look, Presentation Manager, Macintosh)
Modelos de conexión de diálogo a aplicación
Modelos para la especificación de diálogos
Arquitecturas de interfaz multi-usuario
Estandarización e interoperabilidad
2.2.4. Proceso de desarrollo (D)
La construcción de interfaces humano-computadora es tanto una cuestión de diseño como de
ingeniería. Estos temas tienen que ver con metodologías y prácticas de diseño de interfaces. Otros
aspectos del proceso de desarrollo incluyen la relación del desarrollo de la interfaz con la
ingeniería (software y hardware) del resto del sistema.
D1. Enfoques de diseño
El proceso de diseño. Temas relevantes de otras disciplinas de diseño.
Conceptos básicos de diseño gráfico (por ejemplo, lenguajes de diseño, tipografías, uso del
color, organización espacial en 2D y 3D, secuencia temporal, etc.)
28
Procesos alternativos de desarrollo de sistemas (por ejemplo, modelo de cascada, diseño
participativo), modelo de ciclo de vida, diseño interactivo, elección del método bajo
limitaciones de tiempo / recursos
Técnicas de análisis de tareas (por ejemplo, estudios de campo, métodos analíticos),
asignación de tareas, análisis de mercado
Técnicas de especificación de diseño
Técnicas de análisis de diseño
Conceptos básicos de diseño industrial
Casos de estudio de diseño y análisis empíricos de diseños
D2. Técnicas y herramientas de implementación
Tácticas y herramientas para implementación.
Relaciones entre el diseño, la evaluación y la implementación
Portabilidad y reutilización, portabilidad de la aplicación, portabilidad del dispositivo
Técnicas de creación de prototipos (por ejemplo, guiones gráficos, video, "El Mago de Oz",
HyperCard, implementaciones rápidas de prototipos)
Toolkits para creación de diálogos (por ejemplo, MacApp, NextStep, SAIU, HyperCard)
Métodos orientados a objetos
Representación de datos y algoritmos
Técnicas, librerías, toolkits y hardware disponible para el desarrollo de interfaces
tangibles.
D3. Técnicas de evaluación
Filosofía y métodos específicos para las evaluaciones.
Productividad
Figuras de mérito (por ejemplo, el tiempo, los errores, facilidad de aprendizaje, diseño
para adivinar, preferencias, etc.)
Técnicas de testeo de usabilidad, vinculación del testeo con las especificaciones
Técnicas de evaluación formativas y sumativas??? para la evaluación empírica, incluyendo,
métodos de observación de campo, observación de participantes, técnicas de entrevista,
diseño de cuestionarios, métodos psicométricos, protocolos de video, registros del
sistema, diseño de experimentos (por ejemplo, preocupación por el sesgo de la muestra,
etc.), métodos psicológicos y sociológicos de evaluación, ética del trabajo con
participantes
D4. Sistemas de ejemplos y casos de estudio
Diseños clásicos que sirven como ejemplos de diseño de interfaces humano-computadora.
Orientado a comandos:
OS/360 JCL (sistema de comandos por lote, punto de partida para ver futuras mejoras)
PC-DOS (interfaz de línea de comando aprendida por millones de personas)
29
Sistema de check-in de aerolíneas (restricciones de tiempo, entradas ambiguas, sistemas
distribuidos)
Orientado a gráficos:
Xerox Star (interfaz de ventanas e íconos, comandos genéricos)
Apple Macintosh (interfaz similar a lo largo de todas las aplicaciones)
MacPaint (programa gráfico ampliamente conocido y disponible)
Combinaciones definidas por el usuario:
Sistema operativo Unix (fuerte arquitectura combinatoria emparejada con una débil
consideración de factores humanos)
Emacs (orientado al lenguaje, amplio conjunto combinatorio de comandos)
Visicalc (aplicación hogareña con un fuerte modelo conceptual que tuvo éxito a pesar de
su poca consideración sobre los factores humanos)
DBASEIII (simple, pero exitosa, generadora de aplicaciones de usuario)
Interfaces para usuarios no entrenados, para usuarios al paso
Olympic Message System (uso práctico de pruebas de usuario bajo restricciones de
tiempo)
Nintendo Super Mario Bros (puede ser aprendido y comprendido sin un manual por niños
de escuela primaria)
2.3. Disciplinas que contribuyen a la IHC En esta sección se enumeran las disciplinas más influyentes que abarcan el campo de Interacción
Humano-Computadora, así como sus principales contribuciones al mismo. Éstas son:
Figura 2 - Disciplinas relacionadas con la usabilidad, la cual incluye las disciplinas que contribuyen a la IHC. [127]
30
Ciencias de la Computación:
Algoritmos, estructuras de datos, ingeniería de software.
Psicología Cognitiva:
Capacidades y limitaciones del usuario.
Interacción grupal (distributed cognition).
Apoyo a la toma de decisiones.
Psicología Organizacional
Estructura y funciones de la organización.
Ergonomía y factores humanos
31
Diseño de hardware y software que no dañen al usuario.
Desempeño y eficiencia.
Lingüística:
Diálogos (speech acts).
Inteligencia Artificial:
Hacer que la computadora haga lo más conveniente, en el momento adecuado, de
acuerdo al usuario correspondiente.
Antropología:
Aspectos culturales del usuario y su grupo.
Diseño:
Diseño Gráfico,
Diseño de información.
Ingeniería:
Desarrollo de tecnologías para dar soporte a nuevos tipos de interfaces e interacciones.
2.4. Historia A continuación se describen los orígenes del campo de Interacción Humano-Computadora, así
como su evolución histórica, con el objetivo de dar un pantallazo al lector, ubicarlo en el contexto
histórico de forma que comprenda los motivos de su surgimiento y de su evolución.
2.4.1. Orígenes
Hasta finales de 1970, los únicos seres humanos que interactuaban con computadoras eran los
profesionales de la tecnología de la información y los aficionados dedicados. Esto cambió con la
aparición de la computación personal en torno a 1980. La computadora personal, que incluye
tanto el software personal (aplicaciones de productividad, tales como editores de texto y hojas de
cálculo, y juegos de computadora) como la plataforma de computadora personal (sistemas
operativos, lenguajes de programación y hardware), hizo de todos en el mundo desarrollado un
usuario potencial, y claramente puso de manifiesto las deficiencias de los equipos con respecto a
la facilidad de uso para aquéllos que querían utilizar las computadoras como herramientas.
El reto creado por la computación personal se puso de manifiesto en el momento oportuno. El
amplio proyecto de Ciencia Cognitiva1, que incorporó a la Psicología Cognitiva, a la Inteligencia
1 Se denomina ciencia cognitiva al estudio interdisciplinario de cómo la información es representada y
transformada en la mente/cerebro. Es el conjunto de disciplinas que surgen de la convergencia interdisciplinaria de investigaciones científicas y tecnológicas, en torno a los fenómenos funcionales y
32
Artificial, a la Lingüística, a la Antropología Cognitiva y a la Filosofía de la Mente, se había formado
a finales de la década de 1970. Parte del programa de la Ciencia Cognitiva fue desarrollar
aplicaciones sistemáticas basadas en conocimiento científico que se conoce como "Ingeniería
Cognitiva". Por lo tanto, justo en el momento en que la computación personal presentó la
necesidad práctica de IHC, la Ciencia Cognitiva presentó las personas, los conceptos, las
habilidades, y la visión para hacer frente a esas necesidades. La IHC fue uno de los primeros
ejemplos de la Ingeniería Cognitiva.
Otros acontecimientos históricos fortuitos contribuyeron al establecimiento de la IHC. La
Ingeniería de Software, inmersa en el análisis de la complejidad del software de década de 1970,
estaba empezando a centrarse en los requisitos no funcionales, incluyendo la facilidad de uso y el
mantenimiento, así como también de los procesos no lineales de desarrollo de software que
dependían en gran medida del testing. Los gráficos por computadora y la recuperación de
información habían surgido en la década de 1970, y rápidamente se reconoció que los sistemas
interactivos eran clave para progresar más allá de estos primeros logros. Todos estos temas de
desarrollo en Ciencias de la Computación apuntaban hacia la misma conclusión: El camino a seguir
de la computación requería del estudio y entendimiento de los usuarios, así como también de
facilitarlos de mejor y mayor control. [17] NO SE entiende esta última oración. REESCRIBIT
Finalmente, la Ingeniería de Factores Humanos, que había desarrollado muchas técnicas para el
análisis empírico de las interacciones humano-sistema en los llamados dominios de control, como
la aviación y la fabricación, vio a la IHC como un dominio valioso y prometedor en el que los
operadores humanos ejercen regularmente un mayor rol en la resolución de problemas. Estas
necesidades y oportunidades convergieron en torno a 1980, concentrando una cantidad de
energía humana generada previamente, y creando un proyecto interdisciplinario de alta
visibilidad.
2.4.2. De una pequeña área de especialidad a la comunidad
El enfoque técnico original y permanente de la IHC es la usabilidad. Este concepto, inicialmente,
fue articulado en el lema "fácil de aprender, fácil de usar". La simplicidad contundente de esta
conceptualización dio a la IHC una identidad vanguardista y prominente en la informática. Sirvió
para mantener el campo de investigación unido, y para ayudarlo a influir en el desarrollo de las
ciencias de la computación y la tecnología de manera más amplia y efectiva. Sin embargo, dentro
de IHC el concepto de usabilidad ha sido reconstruido continuamente, y se ha convertido en un
concepto cada vez más rico y con problemáticas más intrigantes (seguro que intrigantes?). El
concepto de usabilidad hoy en día incluye cualidades como diversión, bienestar, eficacia colectiva,
tensión estética, potencialización de la creatividad, soporte al desarrollo humano, y muchos otras
más. Una visión más dinámica del concepto de usabilidad es el de un objetivo programático que
debe continuar desarrollándose a medida que la comprensión del mismo mejora.
emergentes, dados a partir de las actividades neurofisiológicas del encéfalo y del sistema nervioso, incorporados, y que típicamente se les denomina como mente y comportamiento.
33
Aunque el origen académico de la IHC fueron las Ciencias de la Computación, y su foco original
estaba en aplicaciones personales de productividad, sobre todo de edición de texto y hojas de
cálculo, el campo no ha dejado de diversificarse y ha superado todos los límites. Rápidamente se
expandió para abarcar visualización, sistemas de información, sistemas de colaboración, procesos
de desarrollo de sistemas, y muchas áreas de diseño. La IHC se enseña ahora en muchos
departamentos y facultades que tienen relación con la tecnología de la información, incluyendo
Psicología, Diseño, Estudios de Comunicación, Ciencia Cognitiva, Ciencias de la Información,
ciencia y estudios de la tecnología, Ciencias Geográficas, Sistemas de Gestión de la Información,
Ingeniería Industrial e Ingeniería en Sistemas. La investigación de la IHC y su práctica se basan e
integran todas estas perspectivas.
Un resultado de este crecimiento es que la IHC está menos singularmente enfocado en lo que
respecta a los conceptos básicos y los métodos, áreas problemáticas y suposiciones acerca de las
infraestructuras, aplicaciones y tipos de usuarios. De hecho, ya no tiene sentido considerar a la IHC
como una especialidad de Ciencias de la Computación, la IHC ha crecido hasta ser más amplia, más
grande y mucho más diversa que la informática. Se expandió a partir del comportamiento del
usuario individual y genérico para incluir la informática social y de organización, la creatividad y la
accesibilidad para las personas de edad avanzada, capacidades diferentes, y para todas las
personas. Se expandió desde las aplicaciones de escritorio de oficina para incluir juegos, e-
learning, comercio electrónico, sistemas militares, y control de procesos. Se expandió desde las
primeras interfaces gráficas de usuario para incluir multitud de técnicas de interacción y
dispositivos, como las interacciones multimodales y las nuevas interacciones ubicuas, de mano y
conscientes del contexto.
En la década de 1980, la IHC era un área de especialidad pequeña y enfocada. Fue un pequeño
grupo tratando de establecer lo que entonces era una visión herética de la informática. Hoy en día,
en gran parte debido al éxito de ese empeño, la IHC es una comunidad amplia y multifacética,
débilmente ligada por la evolución del concepto de usabilidad, y el compromiso integrador de
darle la mayor importancia y valor a los factores o problemáticas humanas como consideración
primordial en la creación de sistemas interactivos.
34
3. Orígenes de las Interfaces Tangibles El desarrollo de la noción de una "interfaz tangible" está estrechamente ligado a la motivación
inicial de Realidad Aumentada y Computación Ubicua. En 1993, un número especial de la revista
“Communications of the ACM” titulado "Back to the Real World" [18] argumentaba que los
equipos de escritorio y la realidad virtual alejaban a los seres humanos de su entorno natural. El
artículo sugería que en lugar de forzar a los usuarios a entrar en un mundo virtual, se debería
aumentar y enriquecer el mundo real con funcionalidad digital. Este enfoque fue motivado por el
deseo de conservar la riqueza y la dependencia del contexto (situatedness2) de la interacción
física, y por el intento de integrar la informática en los entornos existentes y las prácticas humanas
de forma tal de permitir una transición fluida entre "lo digital" y "lo real".
Mientras que las ideas que subyacen a las interfaces tangibles se habían discutido en la edición
especial de la revista "Back to the Real World" [falta referencia], pasarían algunos años hasta que
éstas evolucionaran hacia un estilo de interacción en su propio derecho. En 1995, Fitzmaurice,
Ishii, y Buxton [19] introdujeron la noción de “Graspable Interface” donde se utilizan manijas
físicas para manipular objetos digitales. Ishii y sus estudiantes [9] presentaron una visión más
completa de Bits Tangibles en 1997. Su visión se centraba en convertir el mundo físico en una
interfaz mediante la conexión de objetos físicos y superficies con datos digitales. Basándose en
este trabajo, la interfaz tangible ha emergido como un nuevo tipo de interfaz y estilo de
interacción propio.
Figura 3 - Un objeto graspable es una combinación de un objeto físico o manija y un objeto virtual.
Mientras que Ishii y sus estudiantes desarrollaron una rica agenda de investigación para ampliar y
perfeccionar su visión de Bits Tangibles, otros grupos de investigación se centraron en dominios de
aplicación específicos y en el soporte de prácticas de trabajo establecidas a través del aumento
digital de los medios y herramientas de trabajo utilizados. Tales esfuerzos a menudo resultaron en
sistemas que también pueden ser clasificados como interfaces tangibles. Particularmente notable
2 Por situatedness se entiende que cuando un usuario se mueve a través de una interacción, sus otras
acciones no están completamente predeterminadas, sino que los elementos de la situación o del contexto se utilizan para determinar dichas acciones.
35
es la obra de Wendy Mackay sobre el uso de tarjetas de progreso de vuelo en el control de tráfico
aéreo y sobre el papel aumentado para el desarrollo de storyboards para productores de video
[20]. Ideas similares se desarrollaron de forma simultánea en todo el mundo, indicando la
necesidad de un movimiento contrario a los cada vez más crecientes conceptos de digitalización y
virtualización.
Figura 4 – Izq.: Interactuando con Video Mosaic (Unix) con los botones de papel, la cámara y el video embebido. Der. Arriba: La tarjeta de storyboard de la versión para Macintosh. Der. Abajo: Versión para Macintosh con códigos de
barras y el video proyectado.
Durante la mayor parte de la década siguiente a la proposición de las TUIs como un nuevo estilo
de interfaz, la investigación se centró en el desarrollo de sistemas que exploran las posibilidades
técnicas. En los últimos años, esta fase de prueba de concepto ha llevado a una etapa más madura
de investigación con un mayor énfasis en el diseño conceptual, las pruebas de usuarios y las de
campo, la reflexión crítica, la teoría y la construcción de conocimientos de diseño. Las conexiones
con desarrollos relacionados a las disciplinas de diseño se hicieron más fuertes, sobre todo desde
que una amplia gama de herramientas se han vuelto disponibles reduciendo considerablemente la
complejidad para el desarrollo de TUIs.
3.1. Graspable User Interfaces En 1995, Fitzmaurice et al. [19] introdujeron el concepto de Graspable Interface, (podría ser
traducida al español como Interfaz Agarrable) mediante el uso de bloques de madera como
manijas fáciles de agarrar y manejar para manipular objetos digitales. Su objetivo era aumentar el
carácter directo y la manipulabilidad3 de las interfaces gráficas de usuario. Un bloque queda
anclado a un objeto gráfico en el monitor mediante su colocación sobre el mismo. Mover y rotar el
3 Cualidad de ser controlable por los movimientos especializados de las manos.
36
bloque produce que el objeto gráfico se mueva en sincronía. La colocación de dos bloques en dos
esquinas de un objeto gráfico activa el zoom mientras que se arrastran las dos esquinas con los
bloques. Esto permitió los tipos de interacciones de dos manos o dos dedos que hoy en día
conocemos a través de las superficies multi táctiles.
Figura 5 - Para estirar el cuadrado se pueden utilizar dos ladrillos físicos. Un ladrillo actúa como un ancla, mientras el segundo bloque se desplaza.
Las manijas físicas en combinación con herramientas de entradas dedicadas a la funcionalidad del
sistema se utilizaron para argumentar la distribución de las entradas en el espacio en lugar de en
el tiempo, la des-secuenciación de la interacción, el soporte de la acción bi-manual y la reducción
de la mediación entre los dispositivos de entrada y los objetos de interacción.
3.2. Bits Tangibles Sólo unos pocos años más tarde, Hiroshi Ishii y sus estudiantes introdujeron el concepto de Bits
Tangibles, que pronto dio lugar a la proposición de una interfaz de usuario tangible [9]. El objetivo
era hacer que los bits sfueran directamente accesibles y manipulables, usando el mundo real como
una pantalla y como medio para la manipulación: el mundo entero podría convertirse en una
interfaz. Los datos podrían estar conectados con los artefactos físicos y las superficies
arquitectónicas, haciendo los bits tangibles.
El cambio de terminología de graspable (agarrable) a tangible parece deliberado. Mientras que el
término “graspable”, subraya la capacidad de manipular objetos de forma manual, el sentido de
"tangible" abarca "realidad/certeza", pudiendo ser tocado, así como la acción de tocar, lo cual
incluye percepción multi-sensorial:
“Las interfaces gráficas de usuario no alcanzan a aprovechar la riqueza de los sentidos
humanos y las habilidades que las personas han desarrollado a través de toda una
vida de interacción con el mundo físico. Nuestra intención es cambiar los bits pintados
en la pantalla por '”bits tangibles”, aprovechando los múltiples sentidos y la multi-
modalidad de las interacciones humanas con el mundo real. Creemos que el uso de
objetos fáciles de manipular y de un ambiente interactivo nos llevará a una
experiencia mucho más rica y multi-sensorial de la información digital” [9]
El trabajo de Ishii se centró en el uso de objetos tangibles tanto para manipular como para
representar los contenidos digitales. Uno de los primeros prototipos de TUI fue Tangible
Geospace, un mapa interactivo del campus del MIT en una mesa de proyección. Colocando íconos
37
físicos sobre la mesa, por ejemplo, un modelo de plexiglás de la cúpula del MIT, se permitía que el
mapa se reposicionase de manera que el modelo quedara colocado sobre el edificio respectivo en
el mapa. Agregar otro modelo tangible producía que el mapa cambiara de tamaño y girara de
forma que el mismo coincidía con los modelos tangibles de los edificios. Pequeños monitores
móviles servían como lupas mágicas que mostraban una representación 3D de la superficie
subyacente. Estas interfaces se construyeron basadas en el principio de interacción de
manipulación bi-manual directa de las “Graspable Interfaces”, pero se reemplazaron los bloques
abstractos y genéricos con sustitutos icónicos y simbólicos.
Figura 6 - GeoSpace
Los primeros prototipos de TUI fueron fuertemente influenciados por las metáforas de las GUI.
Posteriormente, proyectos como Urp [21] apuntaban intencionadamente a diverger de la
interacciones similares a las GUI, centrándose en tokens físicos que sirviesen tanto para la
manipulación como para la representación de los datos. Urp brinda soporte a los procesos de
planificación urbana. Permite a los usuarios interactuar con el flujo del viento y las simulaciones de
la luz solar a través de la colocación de modelos físicos de edificios y herramientas sobre una
superficie. Los modelos tangibles generan sombras digitales que se proyectan sobre la superficie.
El flujo de viento simulado se proyecta como líneas sobre la superficie. Varias herramientas
tangibles permiten a los usuarios controlar y alterar el modelo urbano. Por ejemplo, los usuarios
pueden probar la velocidad del viento o las distancias, modificar las propiedades de los materiales
de los edificios (de vidrio o de paredes de piedra), y cambiar la hora del día. Estos cambios afectan
a las sombras digitales que se proyectan y a la simulación del viento.
38
Figura 7 – Izq.: Las sombras virtuales proyectadas por cada estructura tangible. Der.: Incidencia del flujo de viento sobre cada estructura tangible.
3.3. Precursores de las Interfaces Tangibles Varios trabajos previos a los de Ishii y sus estudiantes influenciaron el desarrollo de lo que luego
sería el campo de las interfaces tangibles. Las ideas introducidas por los dos sistemas descriptos a
continuación inspiraron más tarde a los investigadores de HCI en su búsqueda de desarrollo de
nuevas interfaces y conceptos de interacción.
3.3.1. La Máquina Tragamonedas (The Slot Machine)
Probablemente, el primer sistema que se puede clasificar como interfaz tangible fue la Máquina
Tragamonedas de Perlman [22]. La misma utiliza tarjetas físicas para representar las
construcciones del lenguaje Logo que se utilizan para programar la Tortuga Logo [23] . Las
investigaciones de Seymour Papert 4 han demostrado que mientras que la tortuga física robot
ayudaba a los niños a entender cómo se crean en el espacio las formas geométricas, escribir los
programas era difícil para los niños más pequeños e imposible para los preescolares que ni
siquiera sabían escribir con teclado. Perlman cree que estas dificultades son resultado no sólo de
la sintaxis del lenguaje, sino también de la interfaz de usuario. Su primer prototipo consistía en
una caja con un conjunto de botones que permitía la elaboración de programas simples a través
de acciones y números. La caja luego se utilizó como control remoto para la tortuga. Este
dispositivo también puede grabar y reproducir el movimiento de la tortuga, proporcionando un
modo de programación por demostración. Su prototipo final fue la Máquina Tragamonedas, la que
permitía las llamadas a procedimientos y la modificación de los programas.
4 Seymour Papert (Pretoria, Sudáfrica, 29 de febrero de 1928) es un pionero de la inteligencia artificial,
inventor del lenguaje de programación Logo. Es considerado como destacado científico computacional, matemático y educador. Trabajó con el psicólogo educativo Jean Piaget en la Universidad de Ginebra desde 1959 hasta 1963. En 1963 fundó junto a Marvin Minsky el Instituto de Inteligencia Artificial del MIT.
39
Figura 8 – Las tres filas de ranuras (una de cada color) de la Máquina Tragamonedas.
En la Máquina Tragamonedas, cada construcción del lenguaje de programación (una
acción, un número, variable o condición) está representada por una tarjeta de plástico. Para
especificar un programa, una secuencia de tarjetas se inserta en una de las tres filas de ranuras de
diferente color de la máquina. A la izquierda de la ranura se encuentra el botón "Do It", que hace
que la tortuga ejecute los comandos de izquierda a derecha. Colocando una tarjeta especial de
color en alguna de las ranuras de una de las tres filas se invoca una llamada al procedimiento de la
fila de ranuras del respectivo color que, cuando termina su ejecución vuelve, y continúa
ejecutando el resto de las tarjetas insertadas en la fila de ranuras que hizo la llamada. Este
mecanismo implementa las llamadas de función, así como la recursión simple.
3.3.2. The Marble Answering Machine
Otra de las implementaciones precursoras en este campo fue The Marble Answering Machine [3],
creada en 1992 por el diseñador de productos Durrell Bishop. La misma instanciaba los
mensajes de voz que llegaban mediante bolitas (canicas) para luego escucharlos. A tal efecto,
el usuario seleccionaba una de ellas y la depositaba en un agujero especial para su
reproducción en la máquina. Para devolver la llamada a la persona que había dejado el
mensaje, el usuario seleccionaba la bolita correspondiente y la depositaba en un agujero
destinado a tal fin. El mensaje podía ser eliminado e incluso almacenado para categorizarlo
y mantener organizados los mensajes recibidos.
40
Figura 9 – Marble Answering Machine. El mensaje de voz es mapeado a una de las bolillas. Luego, al insertar la bolilla en el lugar establecido, el mensaje es reproducido.
Los diseños de Bishop se basan en affordance5 físico y en el conocimiento de los usuarios de cómo
comunicar funcionalidad e interactuar a través de su experiencia previa, propia de sus actividades
habituales del día a día [24] . Estas ideas eran muy diferentes a las dominantes en la escuela de
diseño de productos de la década de 1990, que empleaba la semántica de productos
principalmente para influir en las emociones de los usuarios y sus asociaciones. Lo más
sorprendente es cómo Bishop asignaba nuevos significados a los objetos (mapeo de objetos),
convirtiéndolos en punteros a otras cosas, en contenedores de datos y en referencias a otros
objetos en una red. Muchos de sus diseños además emplearon mapeos espaciales, derivando el
significado de la acción desde el contexto (por ejemplo, su lugar). Los diseños de Bishop utilizaban
objetos conocidos como referencias legibles en el diseño estético de los nuevos proyectos
electrónicos, sin embargo, estas referencias se restringían a simples metáforas literales.
Recombinando significados y acciones, los diseños de Bishop han seguido siendo un desafío y una
fuente de inspiración para los diseñadores e investigadores del campo de IHC.
5 Affordance es una cualidad de un objeto que transmite las posibilidades de acción que brinda el mismo que
son inmediatamente percibidas por el usuario. Una definición más actual y glamorosa de affordance, sería la capacidad de un objeto para invitar al usuario a utilizarlo. Se podría traducir al español como "comprensión intuitiva".
41
4. Dominios de Aplicación de las Interfaces Tangibles Las áreas dominantes de aplicación de las TUIs parecen ser el aprendizaje, el soporte para la
planificación y resolución de problemas, las herramientas de programación y simulación, el
soporte para visualización y exploración de información, el entretenimiento y juego, la
comunicación social, la música y la performance multimedia.
Los dominios que se discuten aquí no son mutuamente excluyentes, es decir, un sistema TUI
puede pertenecer a más de un dominio o área de aplicación.
4.1. TUIs para el aprendizaje Un gran número de TUIs se pueden clasificar como herramientas o entornos asistidos por
computadora orientados al aprendizaje. Hay varias razones de fondo para ello. En primer lugar, los
investigadores de áreas del aprendizaje y diseñadores de juguetes han seguido siempre la
estrategia de aumentar los juguetes para aumentar su funcionalidad y su atractivo. En segundo
lugar, los entornos físicos de aprendizaje estimulan todos los sentidos y de ese modo contribuyen
al desarrollo integral del niño. Con referencia a Bruner6 y Piaget7, la investigación y la teoría sobre
el aprendizaje hace hincapié en el papel de la realización, el movimiento físico, y la interacción
multimodal [25] . Por otra parte, los estudios sobre gestos han demostrado que los gestos ayudan
al proceso de pensamiento y aprendizaje [26].
Una gama de sistemas de aprendizaje pertenecen también a las categorías de resolución de
problemas, planificación y sistemas de simulación que se describen en detalle más adelante. Éstos
incluyen, por ejemplo, Tinkersheets, que facilita el aprendizaje sobre logística [27] , Illuminating
Light [28], un entorno de aprendizaje de holografía y óptica. Muchos sistemas con interfaces
tangibles también combinan el aprendizaje con el entretenimiento, como es el caso de los
juguetes educativos o instalaciones de museo. Se mencionaran aquí algunos sistemas relacionados
al aprendizaje que también pertenecen a otras categorías, pero se dejaran las interfaces de
usuario tangibles relacionadas con programación tangible para una sección aparte.
Digital Manipulatives [29] son interfaces tangibles que se basan en los juguetes educativos
tradicionales, tales como kits de construcción, bloques de construcción, y materiales de
Montessori. Son versiones computacionalmente realzadas de objetos físicos que permiten a los
niños explorar conceptos, que implican procesos temporales y de computación. Uno de los más
conocidos y comercializados es el Lego MINDSTORMS, que es un kit de construcción robótica
Lego/Logo que fue desarrollado inicialmente por el grupo del MIT Media Lab Kindergarten [30].
6 Jerome Bruner es un reconocido psicólogo estadounidense. En 1960 fundó el Centro de Estudios Cognitivos
de la Universidad de Harvard y, aunque no es el inventor, fue quien impulsó la psicología cognitiva. Su teoría cognitiva del descubrimiento, desarrolla, entre otras, la idea de andamiaje, la cual retoma de la Teoría Socio-histórica de Lev Vygotski. 7 Jean William Fritz Piaget fue un epistemólogo, psicólogo y biólogo suizo, creador de la epistemología
genética y famoso por sus aportes en el campo de la psicología genética, por sus estudios sobre la infancia y por su teoría del desarrollo cognitivo.
42
Figura 10 – Lego MINDSTORM
Un excelente y detallado resumen sobre las razones para el aprendizaje con elementos tangibles y
sobre las fuentes de literatura de investigación disponible al año 2004 se presenta en el informe
de Futurelab sobre Tangibles y aprendizaje [31] .
4.2. Resolución de problemas y planificación Tres aspectos de las TUIs han demostrado ser eficaces para el soporte de resolución de problemas:
1. Las acciones epistémicas,
2. Las restricciones físicas,
3. Las representaciones tangibles del problema.
Las acciones epistémicas son las manipulaciones no pragmáticas de artefactos para lograr una
mejor comprensión del contexto de una tarea. Tales acciones han demostrado facilitar el trabajo
mental [32]. Las TUI dan soporte a una amplia gama de acciones epistémicas desde girar objetos
físicos en el espacio hasta organizarlos sobre una superficie. Las restricciones físicas pueden hacer
uso de affordance físico para comunicar la sintaxis de la interacción y para limitar el espacio de
soluciones. Por lo tanto, las restricciones físicas pueden disminuir la necesidad de aprender reglas
explícitas y reducen la complejidad de uso de un sistema computacional para una tarea
determinada [33]. Por último, la representación tangible es más convincente en los dominios de
aplicación espacial o geométrica, tales como la planificación urbana y arquitectónica donde la
disposición física y la manipulación de los objetos tienen una correspondencia directa con el
problema que representa. Se ha descubierto que el uso de TUIs soporta la cognición espacial de
los diseñadores, reduce la carga cognitiva, y permite una inmersión más creativa en el problema
[34]. Varios estudios también han demostrado los beneficios de la interacción tangible para
resolver tareas que involucran la manipulación de información abstracta [35].
Urp [21] es una TUI para la planificación urbana que permite a los usuarios manipular de forma
colaborativa una serie de modelos físicos de edificaciones y herramientas sobre una superficie,
con el fin de realizar un análisis de sombras, proximidades, reflexiones, viento y espacio visual.
Mientras que los usuarios colocan y manipulan modelos de edificios sobre la superficie, la interfaz
superpone información digital sobre la superficie, activando y actualizando múltiples simulaciones.
Además de la construcción de modelos físicos, Urp también ofrece una colección de herramientas
físicas para la manipulación de las condiciones ambientales tales como la hora del día y la
dirección del viento. Al permitir a los usuarios interactuar de forma colaborativa con los objetos
43
físicos, Urp proporciona una forma intuitiva de interactuar con complejas simulaciones
computacionales.
Más allá de la arquitectura y la planificación urbana, varios sistemas TUI fueron desarrollados para
ayudar en la resolución de problemas y simulación en dominios de aplicación de naturaleza
topológica. Los ejemplos incluyen Iluminating Light [36],un entorno de aprendizaje de holografía y
óptica, donde los objetos de plástico sustituyen a los elementos reales (y caros) de laboratorio. Los
rayos de luz se proyectan desde arriba según la configuración de objetos de plástico, simulando
haces de luz emitidos desde una fuente de luz y desviados por los espejos y prismas. Además, los
ángulos, distancias, y la longitud del camino se proyectan en la simulación.
Figura 11 – Iluminating Light
Existen pocos ejemplos de interfaces tangibles que exploren el uso de la interacción tangible en
una gama más amplia de tareas abstractas de manejo de información. TinkerSheet [37] es un
entorno de simulación para la logística de almacenes utilizados en la formación profesional.
Combina modelos tangibles de la estantería con los formularios de papel, donde el usuario puede
ajustar los parámetros de la simulación mediante la colocación de pequeños imanes en el
formulario.
44
Figura 12 - TinkerSheet
4.3. Visualización de información Al ofrecer una representación rica y multimodal que permite la entrada y manejo de datos
mediante el uso de ambas manos, las interfaces tangibles tienen el potencial para mejorar la
interacción con visualizaciones de información. Varios sistemas ilustran el uso de técnicas de
interacción tangible para explorar y manipular visualizaciones de información.
La “Props-Based Interface for 3D Neurosurgical Visualization” [38] es una TUI para visualización de
imágenes 3D de neurocirugía que se basa en la manipulación física utilizando ambas manos para
controlar herramientas de mando en el espacio. La representación tangible de los datos
manipulados consiste en una herramienta de visualización que es una cabeza de muñeca, una
herramienta que es un plano de corte, y una herramienta lápiz las cuales ayudan al cirujano a
controlar fácilmente la posición y el ángulo de corte de la rebanada que desea visualizar
simplemente manteniendo la placa de plástico cerca de la cabeza de la muñeca para demostrar la
sección de corte transversal que desea visualizar. El sistema fue evaluado de manera informal con
más de cincuenta neurocirujanos. Esta evaluación ha demostrado que con una introducción breve,
los cirujanos pueden comprender y utilizar la interfaz aproximadamente dentro del minuto de
entrar en contacto con las herramientas.
45
Figura 13 - Props-Based Interface for 3D Neurosurgical Visualization: el usuario seleccionado un corte transversal para visualizar.
GeoTUI [39] es una TUI para geofísicos que proporciona soporte físico para la definición de planos
de corte en un mapa geográfico que se proyecta sobre una superficie. El sistema permite a los
geofísicos seleccionar un plano de corte mediante la manipulación de una regla o controladores de
selección sobre el mapa proyectado. El sistema se evaluó con geofísicos en su lugar de trabajo. La
evaluación mostró que los usuarios de la TUI obtienen mejores resultados que los usuarios de una
GUI estándar para una tarea de selección de línea de corte en un mapa geográfico del subsuelo.
Figura 14 – GeoTUI. Izq.: Montaje del dispositivo, con la cámara y el proyector sobre el escritorio. Centro.: El mapa proyectado sobre la superficie. Der.: La regla siendo utilizada de forma natural con dos manos.
4.4. Programación Tangible El concepto de programación tangible, el uso de técnicas de interacción tangibles para la
construcción de programas de computadora, ha estado alrededor hace casi tres décadas desde la
aparición de The Slot Machine de Radia Perlman [22] <- ESTA ORACIÓN está un poco confusa.La
misma fue desarrollada para permitir a los niños pequeños crear programas físicos de Logo. Suzuki
y Kato utilizaron el término de programación tangible en 1993 para describir su sistema de
AlgoBlocks [40] . McNerney [41] proporciona una excelente visión histórica de los juguetes
electrónicos desarrollados principalmente en el MIT que están dirigidos a ayudar a los niños a
46
desarrollar habilidades avanzadas de resolución de problemas y programación. Edge y Blackwell
[42] analizan cómo las propiedades físicas de los lenguajes de programación tangibles influyen en
la facilidad de manipulación de las estructuras de datos creadas por un lenguaje en particular.
AlgoBlocks [40] ayuda a los niños en el proceso de aprendizaje de programación utilizando una
actividad de video juego. Grandes bloques representan las construcciones de programación del
lenguaje educativo Logo. Estos pueden ser conectados entre sí formando un programa ejecutable,
con el fin de dirigir un submarino a través de un laberinto subacuático. Durante la ejecución, un
LED ubicado en cada bloque se ilumina en el momento que se ejecuta ese comando. El tamaño de
los bloques y el movimiento físico de la manipulación de los mismos se argumentó que mejoraba
la coordinación y la atención en experiencias de aprendizaje colaborativo.
Figura 15 – Un grupo de niños programando de forma colaborativa el submarino en pantalla utilizando los Algoblocks.
4.5. Entretenimiento, juego y entretenimiento educativo Las interfaces de usuario tangibles relacionadas con juguetes, entretenimiento y entretenimiento
educativo son aéreas de aplicación que se superponen. La Nintendo Wii es probablemente el
mejor ejemplo de un dispositivo tangible para entretenimiento, y su éxito comercial demuestra el
potencial de mercado de los sistemas relacionados a las interfaces tangibles. Sin embargo, no
debemos pasar por alto otros ejemplos que se ajustan más estrechamente a la definición de
interfaz de usuario tangible. Muchos juguetes educativos modernos emplean los principios de la
entrada física, la representación tangible, y el aumento con contenido digital.
Se pueden encontrar muchos tipos diferentes de ejemplos y estudios sobre el tema. En los
siguientes ejemplos se presentan interfaces tangibles que se parecen a los juguetes tradicionales,
pero a las que se les ha dado un nuevo contenido que los hacen interactivos.
47
El Neurosmith Music Blocks [43] presenta cinco bloques multicolores para que los niños jueguen y
los usen para formar sus propias creaciones musicales. Los bloques encastran en una fila y son
sostenidos de forma segura mediante imanes. Cuando los niños hacen presión sobre los bloques,
cada bloque emitirá un sonido musical. Cada lado de cada bloque emitirá un sonido musical
diferente, y los niños son motivados a girar los bloques tanto para oír los diferentes sonidos como
así también para ver las diferentes formas visuales que contiene cada lado.
Figura 16 - Neurosmith Music Blocks
Una vez que ellos han decidido qué sonido musical les gusta para cada bloque y los han colocado
en sus lugares, pueden pulsar el botón rojo de play, y los bloques reproducirán el sonido uno tras
otro de izquierda a derecha creando una nueva composición musical. Los niños pueden seguir la
reproducción de cada sonido a lo largo de la fila observando cada bloque que se ilumina, y pueden
reajustar los bloques en tiempo real para crear nuevas composiciones.
El Spelling Bee [44] es un juego que ofrece un novedoso método para que los niños aprendan
ortografía. El juego es similar al juego clásico de cubos ABC y el objetivo del mismo también es
similar: se pretende que los niños formen palabras intentando diferentes combinaciones con los
bloques.
Figura 17 – Spelling Bee
Lo novedoso en Spelling Bee, comparado con la versión tradicional, es la respuesta multimodal
inmediata (luz y sonido) que los niños recibirán por su rendimiento. Por ejemplo, si la respuesta es
dada con luces, la luz verde representa una palabra correcta y la luz roja no representa una
palabra. La posibilidad de recibir una respuesta inmediata hace el aprendizaje más eficaz y
divertido.
48
Jabberstamp [45] , del Laboratorio de Medios del MIT (2007), es un sistema que los niños pueden
usar para embeber sus voces y sonidos ambiente en sus dibujos o trabajos artísticos. Jabberstamp
puede ser usado con dibujos de niños, collages o pinturas hechas en papel regular. Los papeles son
marcados con un sello de goma especial que es presionado sobre el papel para registrar sonidos
sobre el mismo. Después de grabar los sonidos, los niños pueden tocar las marcas hechas por el
sello con una pequeña trompeta y oirán los sonidos grabados. Estos sonidos pueden ser de
diferentes tipos, como voces humanas o (sólo lleva acento cuando va entre números) efectos
sonoros ambientales.
Figura 18 - Jabberstamp
Jabberstamp permite a los niños trabajar de forma colaborativa y hace posible compartir sus
ideas e historias con otros aunque ellos todavía no sean capaces de leer y escribir. Jubberstamp
está pensado para niños de más de 4 años.
El Magic Story Cube [46] , creado por Mixed Reality Lab (2004), permite narrar cuentos de un
nuevo modo aprovechando los beneficios de la tecnología de realidad aumentada. El libro
tradicional es sustituido por un cubo plegable. El desarmar el cubo sustituye el pasar de página de
los libros tradicionales. Cuando un niño va desplegando o desarmando el cubo, las diferentes
partes de la historia van apareciendo en 3D mediante un soporte multimedia, con voces humanas,
sonidos y música.
49
Figura 19 – Magic Story Cube
El uso del Magic Story Cube requiere del uso de un Head Mounted Display (HMD) y de una cámara,
que es montada en el frente del mismo. Éstos son conectados a una computadora que ejecuta un
software que reconoce, mediante la imagen que captura la cámara, qué parte de la historia será
narrada y mostrada. La manipulación de la historia se produce mediante la utilización de ambas
manos sobre el cubo.
El aumento digital de los juguetes y la interacción con los mismos ha sido durante mucho tiempo
un importante foco de investigación del área de las interfaces tangibles. Una aplicación directa de
la idea de interfaz tangible es aumentar digitalmente los juegos tradicionales de mesa, como es el
caso del proyecto de Philips Entertaible [47] y los demás ejemplos descriptos a continuación . Estos
preservan el ambiente social de los juegos de mesa al mismo tiempo que permiten nuevas
experiencias de juego.
Figura 20 - Philips Entertaible
Magerkurth et al. [48] introducen la plataforma STARS, que integra dispositivos móviles
personales (PDAs) con una mesa de juego y piezas de juego tangibles. Los jugadores pueden
acceder y gestionar la información privada en su PDA, sirviendo como un canal secundario y
privado. El motor del juego alivia a los usuarios de las tareas tediosas como contar el dinero o la
50
creación inicial de la partida y, además, puede alterar dinámicamente el tablero en respuesta a la
acción del juego.
Figura 21 – Plataforma STARS. Izq.: manipulando el objeto de forma pública. Der.: manipulando el objeto de forma privada a través del PDA.
Leitner et al. [49] presentan un juego de realidad mixta, que combina piezas de juego reales y
virtuales. Los objetos reales son seguidos por una cámara de profundidad y pueden convertirse en
obstáculos o rampas en una carrera virtual de autos o fichas de dominó, virtuales y reales, que
están conectadas de forma que unas pueden voltear a las otras.
4.6. Comunicación social Desde sus primeros días, las interfaces de usuario tangibles fueron empleadas como herramientas
de soporte para la comunicación. Los objetos tangibles parecen adecuados para representar a los
usuarios remotos y se pueden colocar en la periferia de la atención para brindar conciencia
ambiental. Uno de las varias alternativas de interfaces para Somewire, un espacio de
comunicación cuyo único medio es el audio, utiliza figuras tangibles que pueden ser colocadas en
un estante para determinar la audibilidad y la direccionalidad del sonido [50] . Esta interfaz de
usuario tangible se evaluó como la más adecuada para la tarea, comparada con dos prototipos
basados en interfaz gráfica de usuario. Greenberg y Kuzuoka [51] emplean figuras físicas como
sustitutos físicos, controlados digitalmente, de miembros remotos del equipo para un sistema de
videoconferencia. El sustituto Peek-a-Boo, por ejemplo, gira y mira hacia la pared, dando la
espalda, cuando la persona remota no está disponible, y gira mirando hacia el usuario, cuando se
detecta actividad en el escritorio de la persona remota. En consecuencia, se puede detectar la
disponibilidad del otro en cualquier momento, echando un rápido vistazo a la orientación del
sustituto: cuanto más directa o frontalmente mira al usuario, más probable es que la otra persona
se halle efectivamente presente.
51
Figura 22 – Sustituto Peek-a-boo
Una serie de proyectos recientes se centran en la concientización remota dentro de las redes
sociales, como en el caso de Connectibles [52] . Edge y Blackwell [53] emplean tangibles para la
gestión de tareas en el trabajo de oficina, y ponen de manifiesto su potencial para la comunicación
social simbólica, como la entrega de un símbolo puede representar la transmisión de la
responsabilidad de una tarea o un documento.
Una gama de prototipos aborda la intimidad remota, o la intimidad a distancia. En este contexto,
los investigadores suelen experimentar con diferentes modalidades sensoriales. Por ejemplo,
Strong y Gaver [54] presentan “Feather, Scent and Shaker" (pluma, aroma y agitador). El apretar
un pequeño dispositivo cuando uno piensa en la otra persona produce que en el dispositivo
remoto caigan plumas por un tubo, activando un aroma; agitar el dispositivo genera que el
dispositivo remoto vibre. LumiTouch [55] comunica la acción de tocar un marco fotográfico a su
compañero remoto mediante la iluminación del marco remoto. Las parejas pueden establecer un
vocabulario simple de toques, o tocar puede transmitir una forma abstracta de "Pienso en ti".
52
Figura 23 – Cuando el usuario toca el marco de la foto del sistema Lumitouch, un mensaje es transmitido hacia el marco remoto en forma de una luz que se enciende.
4.7. Música y performance multimedia Las aplicaciones musicales son una de las aéreas más antiguas y populares de las interfaces
tangibles, volviéndose omnipresente a partir del año 2000 con proyectos como Audiopad [2],
BlockJam [3], Squeezables [56], o la instalación musical SmallFish [57]. Jordà [5] identifica varias
propiedades de las interfaces tangibles y de las mesas multi-táctiles que las sitúan como un
enfoque prometedor para la interpretación musical: el soporte para la colaboración y el
intercambio de control entre usuarios, la interacción continua y en tiempo real con datos
multidimensionales, y el soporte para interacciones complejas, especializadas, expresivas, y
exploratorias. Una visión general de los sistemas existentes se proporciona en la página web de
Martin Kaltenbrunner [58] .En general, podemos distinguir entre cuatro enfoques de alto nivel
para las aplicaciones tangibles para música: instrumentos tales como el Reactable [59] [4] ( Ver
4.8.2. The ReacTable ), que son generadores de sonido o sintetizadores totalmente controlables,
secuenciadores tangibles que permiten mezclar y reproducir muestras de audio, juguetes sonoros
con un control de usuario limitado, y los controladores que manejan de forma remota un
sintetizador arbitrario.
53
Figura 24 - reacTable
Las interfaces tangibles para Música pueden diseñarse para principiantes y se presenta un juguete
intuitivo y de fácil acceso, o pueden tener como objetivo al profesional de la música que valora la
expresividad física, la legibilidad y la visibilidad al realizar la música electrónica en frente de una
audiencia. Además de ser un área de aplicación interesante para los proyectos de investigación,
muchas de las interfaces tangibles para música son desarrolladas por profesionales de la música,
tales como artistas de música electrónica. La serie de conferencias NIME (Nuevos Instrumentos
para la Expresión Musical, New Instruments for Music Expression) [60] es la más importante en
esta área. El desarrollo de nuevos instrumentos híbridos que hacen uso de entradas físicas y de
materiales de estilo antiguo que permitan a los usuarios experimentar con el sonido ha sido el
objetivo, desde hace varias décadas, de renombrados grupos de investigación y artistas, como el
grupo HyperInstruments del MIT, o STEIM, un estudio independiente de arte interdisciplinario
ubicado en Amsterdam.
Figura 25 – Izq.: AudioCubes. Der.: BlockJam
Las interfaces tangibles para música se han vuelto visibles en los primeros planos de la
investigaciones de interfaces tangibles gracias al reacTable [59] [4], un sistema de mesa que le ha
dado una nueva interfaz a la programación de síntesis modular y se convirtió en uno de los videos
54
favoritos de YouTube después de que la cantante y compositora islandesa Björk8 comprase uno
para su tour mundial de 2007. Cada token físico en el reacTable tiene una función específica, por
ejemplo, la generación de sonido, el filtrado de audio, o el control de parámetros de sonido. La
programación visual se hace más fácil gracias al sistema de “dynamic patching”, donde cada token
tiene una serie “conectores” de entrada y salida; el token buscará otros tokens cercanos por
“conectores” compatibles y disponibles y se conectará automáticamente según su proximidad.
Según sus creadores, el objetivo principal fue diseñar un instrumento atractivo, intuitivo y no
intimidatorio para múltiples usuarios para la interpretación de música electrónica, que sea
atractivo desde el primer momento, pero que también sea complejo (que sea complejo o que
tenga funcionalidad compleja???), sutil y permita crear infinitas variaciones. Otro sistema
comercialmente disponible es AudioCubes [61]. Se compone de un puñado de cubos que detectan
los cubos vecinos y se comunican entre sí. Cada cubo envía y recibe audio a través de sus caras.
Los cubos también actúan como parlantes y se iluminan con colores de acuerdo a su
configuración. Block Jam [3] es un secuenciador dinámico poli rítmico construido a partir de cubos
que se conectan unos con otros.
Figura 26 – Izq.: AudioPad Der.: Squeezables
El sistema Audiopad [2] ( Ver 4.8.1. Audiopad ) permite a los usuarios manipular y mezclar
muestras de sonido colocando tokens tangibles sobre una superficie aumentada digitalmente.
Nuevas muestras de sonido pueden ser arrastradas a la superficie desde un menú en el borde de
la mesa. mixiTUI [62] <-(¿¿¿???)es un secuenciador tangible de muestras de sonido y música
editada, que permite agregar loops, controles y efectos a los sonidos. Utiliza los mecanismos de
interacción (en particular “Dynamic Patching”) de la Reactable.
Kaltenbrunner [58] en su resumen de interfaces tangibles para música de su sitio web distingue
entre las siguientes categorías:
8 Björk Guðmundsdóttir es una cantante y compositora islandesa. Ha vendido más de 15 millones de
álbumes, además de ser nominada al Oscar a la mejor canción por la película Dancer in the Dark, 13 nominaciones al Grammy, y en el 2010, fue galardonada con el Polar Music Prize, prestigioso premio que concede la Real Academia de Música de Suecia.
55
Los artefactos tangibles musicales tienen música "contenida" dentro de un objeto
sensorizado, y diferentes interacciones, como frotar, apretar o agitar activan una
reproducción de sonido diferente (por ejemplo, los Squeezables [56] ).
Los bloques de construcción musical (por ejemplo, [3] ) consisten en bloques que
continuamente generan o manipulan sonido y se pueden apilar, conectar, o simplemente
colocar cerca de sí. Con algunos sistemas, los bloques trabajan independientemente uno
de otros, en otros sistemas la disposición espacial de los mismos modifica el sonido, que
se transmite y se procesa de forma secuencial a través de los bloques.
En los secuenciadores basados en tokens una superficie es constantemente escaneada y
cada sector explorado genera sonido; la posición del token, u otros atributos como el color
del mismo, determina la nota o el ritmo que se toca.
Las mesas musicales táctiles y las mesas musicales tangibles (por ejemplo, Audiopad [2],
reacTable [59] [4]), interpretan las interacciones de los tokens tangibles sobre la superficie
interactiva de la mesa.
Por último, hay una serie de juguetes musicales tangibles comerciales como Neurosmith
MusicBlocks [43] y Fisher-Price Play Zone Music Table [63] . Estos por lo general permiten
la selección y colocación de objetos tangibles en ciertas ranuras, activando sonidos
asociados modificados por la posición, orden y configuración general de los mismos.
Otra área de aplicación emergente para las TUIs relacionadas con la música es la de la
interpretación o performance en vivo. Por ejemplo, Media Crate [64] brinda soporte para VJ-ing,
permitiendo la presentación en vivo de medios audiovisuales en múltiples pantallas tomando
datos de entradas desde diversas fuentes. El sistema tiene una interfaz de mesa muy similar a la
reacTable. A través de la manipulación de objetos tangibles, llamados media cues (indicadores de
medios), apoyados sobre la mesa, el VJ puede ordenar y pre preparar los clips de videos para el
espectáculo, editar sus propiedades, reproducir los clips en una determinada salida, etc. Sheridan
y Bryan Kinns[222] experimentaron con el uPoi, un instrumento que está basado en el tradicional
juego de malabar llamado Carioca, que consistente en una pelota unida a un hilo. El juego consiste
en hacer girar la pelota de diferentes maneras para conseguir diferentes efectos visuales los cuales
son muy agradables a la vista. Al balancear la pelota, los datos de aceleración se convierten en
audio y sonido de salida. De presentarse en festivales al aire libre y atraer a la audiencia a
participar y jugar con el uPoi, se derivan los requisitos de diseño para la interacción tangible en
vivo: uso intuitivo, diseño sencillo y discreto, atractivo (visibilidad de la interacción y fácil de
comenzar a utilizar), portable, robusto y fácil de configurar.
56
Figura 27 – Media Crate. 1. Lista de indicadores de medios. 2 Controles tangibles sin usar. 3. Herramienta de edición de propiedades 4. Perilla de control sobre una propiedad 5. Salida número 1 mostrando un indicador de medios (un clip de video) 6. Vista previa número dos de un video 7. Lista de videos plegada 8. Colección de archivos de video.
4.8. TUI de mesa para música
4.8.1. Audiopad
Audiopad [2] es una interfaz para la interpretación musical que tiene como objetivo combinar la
modularidad de controles basados en perillas con el carácter expresivo de las interfaces de mesa.
La manipulación de discos físicos sobre una mesa por parte del artista controla un proceso de
síntesis en tiempo real. Los discos contienen etiquetas RFID LC que se utilizan para seguir su
posición en dos dimensiones mediante el uso de una serie de antenas. El sistema proyecta
información gráfica sobre y alrededor de los discos brindando al artista o intérprete un control
sofisticado del proceso de síntesis.
AudioPad es más expresiva que una interfaz gráfica, cuando se refiere a la creación de música
electrónica. En términos del estilo de interpretación o ejecución musical que fomenta, es más fácil
improvisar un estilo más expresivo de interpretación musical. Debido a que la interacción es física,
también hay una dinámica que involucra a la audiencia, que puede ver realmente lo que el
intérprete está haciendo.
57
El Audiopad se proyecta sobre una mesa especial equipada con sensores de radio que realizan un
seguimiento de la posición y el movimiento de media docena de discos de plástico.
La mayoría de los discos controlan una serie de pistas de audio pre-programadas, el ritmo, la línea
de graves, la melodía y demás.
Un disco circular grande cambia el volumen de cada pista cuando se mueve más cerca o más lejos,
lo que permite que diferentes pistas sean resaltadas en diferentes momentos.
Otro disco, con forma de estrella, permite que el músico modifique las pistas básicas pre
programadas de varias maneras. Si el disco en forma de estrella se mueve hacia uno de los discos
con pistas pre programadas, una selección de diferentes acciones se proyecta junto al mismo. Las
acciones "brotan" del tablero de la mesa, y cada una se selecciona moviendo el disco estrella
encima.
Los controles se proyectan sobre la mesa mediante un video proyector montado en el techo o en
la misma mesa utilizando un espejo. Una PC con Linux controla el sistema. Debian o Knoppix para
ser específico. La mayoría del código está escrito en Python, a excepción del código de bajo nivel
de seguimiento de los discos, que está en C y C + +. Se utiliza el optimizador Pysco para acelerar
Python. Se utiliza OpenGL para los gráficos, y la comunicación con el sintetizador es mediante
MIDI.
En la primera demostración pública de importancia, en el festival Sónar del año 2003 (Festival
Internacional de Música Avanzada y New Media Art) en Barcelona, España, los DJs fueron capaces
de entender los controles casi de inmediato.
El Audiopad se basa en los principios de Sensetable-Patten, una interfaz de mesa diseñada para
ayudar a resolver problemas espaciales como la simulación de negocios, la planificación de la red
de transporte, y el diseño de chips; en general, es adecuada para ayudar a resolver cualquier tipo
de problema en el que hay un componente espacial.
4.8.2. The ReacTable
The ReacTable [5] [59] [4] es un instrumento musical electrónico con una interfaz de usuario
tangible de mesa que se ha sido desarrollado dentro del Grupo de Tecnología Musical de la
Universitat Pompeu Fabra en Barcelona, por Sergi Jordà, Marcos Alonso, Martin Kaltenbrunner y
Günter Geiger.
El ReacTable es una mesa redonda traslúcida, que se utiliza en una habitación oscura, y aparece
como una pantalla retro iluminada. Al colocar bloques tangibles sobre la mesa, e interactuar con la
pantalla a través de los elementos tangibles o los dedos, un sintetizador modular virtual es
operado, creando música o efectos de sonido.
Hay varios tipos de elementos tangibles que representan diferentes módulos de un sintetizador
analógico. Alguno de los elementos tangibles de uso general disponibles son VCOs (Osciladores
controlados por tensión), LFOs (Osciladores de baja frecuencia) y FCRs (Registros de control de
58
frecuencia) de frecuencia de audio, y secuenciadores. También hay tangibles que afectan a otros
módulos: uno llamado radar, que es un disparador periódico, y otro llamado tonalizer que limita al
VCO a las notas de una escala musical dada.
La misma mesa es la pantalla. Cuando un tangible se coloca sobre la mesa, varios símbolos
animados aparecen, como formas de onda, círculos, rejillas circulares, o líneas de barrido. Algunos
símbolos se limitan a mostrar lo que ese tangible particular está haciendo, otros pueden ser
utilizados por los dedos para controlar el módulo respectivo.
Si un VCO tangible se coloca sobre la mesa, un módulo de VCO se añade al sintetizador virtual. En
la pantalla, una forma de onda aparece entre el tangible y la "salida" (un punto brillante en el
centro de la mesa), y aparece un círculo alrededor del tangible que permite un control preciso de
la amplitud de la onda. Además, en este ejemplo, el tangible puede girarse a mano para cambiar
su frecuencia.
Colocar un filtro tangible entre el VCO y la salida causa que la forma de onda del VCO se conecte al
filtro, y la forma de onda del filtro se conecte a la salida. Si una tangible LFO se coloca cerca del
VCO, una forma de onda aparecerá conectando los dos, y el LFO modulará al VCO.
La interfaz de usuario principal de la ReacTable consta de una mesa traslúcida. Debajo de la mesa
hay una cámara de video, apuntada hacia la parte inferior del tablero de la mesa que envía video a
una computadora personal. Hay también un proyector de video debajo de la mesa, también
conectado a la computadora, proyectando video en la parte inferior del tablero de la mesa que
puede ser visto desde el lado superior. El motor de audio del sistema está basado en Pure Data y
SuperCollider.
Colocados sobre la mesa están los tangibles que tienen fiducials (marcadores) unidos a su parte
inferior, siendo vistos a través de la mesa por la cámara. Los fiducials son imágenes impresas en
blanco y negro, que consisten en círculos y puntos formando diferentes patrones, optimizados
para ser usados por reacTIVision. Luego, reacTIVision utiliza los fiducials para entender la función
que representa un determinado tangible.
La mayoría de los tangibles son planos, con un fiducial en la parte inferior. Otros tangibles son
cubos, con fiducials adjuntados a varios de sus lados, permitiendo a esos tangibles ofrecer
múltiples funciones.
En la actualidad, hay dos versiones de la ReacTable, Reactable Live! y The Reactable Experience.
Reactable Live! es una versión más pequeña y más portátil diseñada para profesionales de la
música, se han producido sólo 20 (en la actualidad su precio es de € 9700). The Reactable
Experience es más parecida a la Reactable original, y está pensada para ser utilizada en
instalaciones en espacios públicos.
El video capturado por la cámara de video digital es procesado por el software de código abierto
de visión por computadora llamado reacTIVision [65], originalmente desarrollado por Martin
Kaltenbrunner y Ross Bencina para el proyecto Reactable. reacTIVision detecta la posición
59
cartesiana y la rotacional de los fiducials sobre la superficie de la mesa, a continuación, envía la
información mediante el protocolo de comunicación especialmente diseñado y basado en Open
Sound Control llamado TUIO, que se comunica con el sintetizador real y el software de
visualización que muestra los resultados a través del proyector de video. reacTIVision también es
capaz del seguimiento multi-táctil de los dedos sobre la superficie.
4.9. Secuenciadores Tangibles
4.9.1. The BeatBearing
BeatBearing [66] es un novedoso instrumento musical que permite a los usuarios manipular
patrones rítmicos a través de la colocación de bolitas metálicas en una cuadrícula. El BeatBearing
se ha desarrollado como un caso de diseño exploratorio de cómo la teoría de embodied
interaction9 puede contribuir al diseño de nuevos instrumentos musicales digitales.
Figura 28 – La interface de BeatBearing
BeatBearing ha sido diseñado para funcionar como un medio tangible de programación de
secuencias rítmicas, lo que permite la manipulación manual del ritmo. BeatBearing continúa en la
línea tradicional de los instrumentos musicales de mesa basados en interfaces tangibles de
Usuario, como Audiopad [2] y Reactable [4]. Pero BeatBearing difiere de éstos en la simplicidad de
9 Termino de difícil traducción, lo que prima aquí es el nexo entre la acción y la presencia del usuario en el
mundo físico. Por lo tanto involucra a la computación física o tangible, junto con la computación social. Es una cualidad relacionada con cómo la interacción del usuario con el sistema se ve afectada por el entorno físico donde se encuentra. Se puede pensar como interacción personificada o encarnada. El autor se siente más atraído por el término “interacción corpórea”.
60
su diseño, en el uso de puntos discretos en lugar de puntos continuos de interacción, y el uso de
restricciones físicas construidas sobre la superficie de trabajo.
BeatBearing ha sido deliberadamente diseñado para ser de bajo costo, simple, robusto y
fácilmente reconfigurable. Como tal, el BeatBearing original fue diseñado en torno al uso de un
monitor de computadora CRT de pantalla plana que se colocó horizontalmente de modo que su
pantalla actuara como mesa. El uso de una pantalla CRT que se puede conseguir de forma
económica (o incluso gratis ya que están siendo reemplazados por los monitores LCD) contrasta
con el uso predominante de proyectores en la construcción de interfaces de usuario tangibles. En
consecuencia con el uso de la pantalla CRT, se utilizó un conveniente método de entrada de bajo
costo, simple y robusto que consiste en el cierre de un circuito interruptor mediante la colocación
de una bolita metálica.
Figura 29 - Las arandelas metálicas dividas por la mitad colocadas y cableadas sobre el sustrato transparente de policarbonato
El BeatBearing utiliza una placa Arduino [67] para interactuar con la computadora. Esto permite
brindar soporte multi-plataforma, facilitando el desarrollo del sistema. La aplicación de
BeatBearing está escrita en parte en Processing (efectos visuales) y en parte en MaxMSP
(secuenciación). Esto permite un desarrollo multiplataforma de alto nivel, así como el prototipado
rápido. La aplicación MaxMSP envía datos MIDI que se pueden utilizar para reproducir muestras
de sonido o bien en otro programa, como por ejemplo, Ableton Live, o incluso en un sintetizador o
sampler físico externo.
Se han utilizado dos métodos diferentes para crear el interruptor que se cierra mediante la
colocación de una bolita de metal. El prototipo inicial utilizaba dos barras de alambre grueso como
contactos. La segunda versión utilizaba arandelas metálicas que se habían dividido por la mitad.
Aunque esto funciona satisfactoriamente, las arandelas obstruían gran parte del espacio de la
pantalla, y también se requería de un mayor esfuerzo para fabricar y diseñar. La solución actual es
61
la de grabar pistas de cobre sobre un sustrato transparente de policarbonato para crear un tablero
de circuito impreso transparente. Este enfoque proporciona flexibilidad de diseño y es
relativamente fácil y barato de fabricar.
Figura 30 – El sistema completo, el tablero sobre la pantalla CRT, conectado a la placa Arduino, que a su vez está conectada a la computadora.
Al activar el BeatBearing, una línea roja barre la pantalla de izquierda a derecha, desapareciendo
por la parte derecha y apareciendo de nuevo por la izquierda. Cuando no hay bolitas colocadas en
la cuadrícula, el sistema no genera ningún sonido. Un círculo de color gris oscuro se muestra en la
pantalla directamente debajo de cada orificio, lo que refuerza que éste es un sitio de interacción.
Cuando un usuario pone una bolita en la cuadrícula, el círculo de color gris oscuro justo debajo de
la bolita se vuelve blanco, lo que indica que la bolita está ahora activada. A medida que la línea
roja barre a través de la bolita, un círculo de color más grande se pinta alrededor de la bolita. Cada
fila tiene un color diferente, lo que indica un sonido diferente: bombo, redoblante, hi-hat, y
cencerro.
Indicaciones precisas de cómo construir el sistema se pueden encontrar en
http://makeprojects.com/Project/The-BeatBearing-Tangible-Rhythm-Sequencer/1237/1
4.9.2. The Bubblegum Sequencer
El Bubblegum Sequencer [68] es una interfaz física para la creación y performance de música
electrónica de percusión. Se trata de una herramienta de colaboración para componer, visualizar,
y enseñar música a través de una interacción sencilla y acogedora.
62
Los secuenciadores que aparecen en los instrumentos electrónicos han sido una herramienta
popular para la composición de música electrónica desde la década de 1980. Ya sea implementado
en software o hardware, un secuenciador consiste típicamente en una fila de 16 posiciones que
codifican las colocaciones de una muestra de sonido en el tiempo. Las muestras de sonido se
colocan mediante la activación de la cuadrícula correspondiente, por lo general haciendo clic o
pulsando un botón. El secuenciador crea un bucle de percusión reproduciendo repetidamente el
patrón construido. Los secuenciadores típicos pueden ser herramientas poderosas para la
composición, pero también son difíciles de aprender, y no son ideales para la performance en vivo,
ya que los artistas son propensos a terminar encorvados sobre una pantalla en lugar de dedicarse
a su público.
Figura 31 – La interfaz tangible con las bolitas de chicle de distintos colores colocados en los distintos agujeros. Cada color representa un sonido de percusión diferente.
El Bubblegum Sequencer constituye una interfaz atractiva y poco intimidante que mitiga estos
obstáculos relacionados con la performance. Muestras de sonido se asignan a objetos, bolitas de
chicles, en lugar de asignarse a pistas de audio, creando una interacción más intuitiva y divertida.
El jugador que desee un bombo en el tercer compás del bucle de percusión sólo necesita agarrar y
colocar la bolita de chicle apropiada.
Información visual adicional enriquece la interacción, proporcionando una manera fácil de
examinar el patrón activo en tiempo real. El uso de bolitas de chicles de colores brillantes como los
dispositivos de entrada crea una interfaz divertida y fácil de aprender, facilitando la colaboración y
la experimentación entre los usuarios.
El Bubblegum Sequencer en el mapeo de a objetos físicos. Sin embargo, la calidad de los objetos y
la naturaleza de la interacción combinan la facilidad de aprendizaje del The Marble Answering
63
Machine con los aspectos de composición colaborativa de Reactable y Audiopad. Considerando
que los dos últimos ejemplos requieren algún tipo de preparación de las muestras de sonido que
se van a utilizar y algún conocimiento de música electrónica, el Bubblegum Sequencer funciona
con el software estándar MIDI integrado en la mayoría de los sistemas operativos, utilizando un
objeto familiar y lúdico, la bolita de chicle. Mientras que el Bubblegum Sequencer soporta el uso
con software MIDI más avanzado, no es necesario ningún conocimiento de música electrónica o
MIDI para usarlo.
La interfaz consta de una matriz de 4 x 16 de agujeros perforados en una superficie de una mesa, y
bolitas de chicles de cinco colores diferentes que se colocan en esos agujeros. Cada una de las 16
columnas en la cuadrícula representa una semicorchea en términos de medidas musicales. Las
filas, a diferencia de las pistas en los secuenciadores tradicionales, no están asignadas a un
atributo particular de música, sino que simplemente permiten la colocación de varios chicles en
cualquiera de las 16 semicorcheas.
A medida que los usuarios colocan bolitas de chicle en la cuadrícula, las muestras de sonido
asignadas a cada color se reproducen en el momento oportuno. Mientras que se ejecuta el bucle,
LEDs debajo de la primera, quinta, novena y décimo tercera columna se iluminan en secuencia
para indicar las notas que se reproducen. Esta información visual ayuda a los usuarios comprender
sus composiciones y proporcionan una indicación constante del ritmo.
Información gráfica adicional se presenta en forma de una visualización proyectada que hace
estallar las bolitas de goma, la misma puede ser proyectada en una pared, o directamente sobre la
superficie de juego. Cuando se proyecta en la pared, el patrón de estallidos imita la superficie de
juego. Cuando se proyecta sobre la superficie en sí, cada chicle parece explotar cuando se
reproduce su sonido.
Un área sensible a la presión al costado de la superficie de juego permite a los usuarios ajustar el
tempo de la reproducción en tiempo real.
El modo de reproducción predeterminado de Bubblegum Sequencer es con sonidos de percusión.
Sin embargo, en el modo nota, las bolitas de chicles se pueden organizar en patrones para tocar
notas utilizando muestras de sonidos de un instrumento dado. Cada columna codifica una nota
según como se coloquen las bolitas de chicle en la misma.
64
Figura 32 – Procesamiento de imagen capturada por el sistema. Arriba la imagen original capturada por la cámara, abajo el resultado obtenido luego del procesamiento mediante ImageJ.
Los colores de las bolitas de chicle en la cuadrícula se detectan mediante una cámara web
montada debajo de la superficie y el software de procesamiento escrito en Java utilizando la
librería de procesamiento de imágenes ImageJ. Una cuadrícula superpuesta sobre la captura de
video de la cámara se alinea con las bolitas de chicle. Cada intersección de la cuadrícula
corresponde a la ubicación de un agujero en la superficie de juego. En cada agujero, se toma una
muestra de 5 x 5 píxeles, se calcula el color promedio, se calcula el valor cuantificado y se mapea a
la nota correspondiente.
Un hilo separado en el software lee los valores de la matriz para controlar la salida del programa.
Para cada valor distinto de cero, la nota MIDI apropiada se envía al controlador MIDI del sistema, y
la imagen del estallido del color correspondiente se muestra en la visualización.
65
5. Frameworks y Taxonomías de las Interfaces Tangibles A medida que el campo madura, los investigadores han desarrollado frameworks (marcos de
trabajo en castellano) y taxonomías que tienen como objetivo proporcionar a los desarrolladores
de TUIs de poder explicativo, permitiéndoles analizar y comparar las distintas instancias de TUIs, y
aplicar las lecciones aprendidas del desarrollo de casos anteriores a sus esfuerzos futuros. Algunos
frameworks pueden tener un papel generador, sugiriendo nuevas direcciones para explorar y
descubrir oportunidades abiertas en el espacio de diseño de TUIs. Los frameworks pueden ser
caracterizados para proporcionar una estructura conceptual para pensar y analizar un problema o
aplicación. De este modo, los frameworks pueden informar y orientar el diseño y el análisis. Las
taxonomías son un tipo específico de estructuras que clasifican las entidades en función de sus
propiedades, en lo posible sin ambigüedades.
5.1. Propiedades de las Gaspables User Interfaces Fitzmaurice [69] define una interfaz de usuario graspable como aquélla que proporciona un
"identificador físico a una función virtual, donde la manija física sirve como un manipulador
funcional dedicado". Los usuarios tienen "acceso simultáneo a múltiples dispositivos de entrada
especializados que pueden servir como herramientas físicas dedicadas de interfaz" permitiendo la
manipulación física y la disposición espacial.
Una propiedad fundamental de las interfaces de usuario graspables [69] [19] es el multiplexado
espacial, que es un concepto muy poderoso. Cuando sólo un dispositivo de entrada está
disponible, el mismo es multiplexado en el tiempo: el usuario tiene que seleccionar y des-
seleccionar repetidamente objetos y funciones de forma secuencial. Una interfaz de usuario
graspable, por otro lado, ofrece varios dispositivos de entrada de modo que la entrada y la salida
están distribuidas en el espacio, permitiendo al usuario seleccionar un objeto o una función con
sólo un movimiento al alcanzarlo mediante su manija física o tangible. Esto permite la selección
simultánea, pero independiente y potencialmente persistente de los distintos objetos.
La velocidad y la exactitud de la manipulación de objetos gráficos de esta manera ha sido probada
en experimentos empíricos [70]. Éstos revelaron que el multiplexado espacial es efectivo al reducir
el "costo de conmutación", aprovechando las habilidades motoras innatas, y la coordinación ojo-
mano. También reduce la carga de la percepción visual. Fitzmaurice [69] describe cinco
propiedades básicas de las interfaces graspables, con las últimas cuatro permitidas (pero no
necesitada) por la primera:
1. Multiplexado espacial.
2. Acceso y manipulación concurrente (a menudo a través de interacciones con dos manos).
3. El uso de dispositivos específicos para la tarea (en lugar de genéricos y no-icónicos).
4. Percepción espacial de los dispositivos.
5. Reconfiguración espacial.
66
Analizar estas propiedades sirve para ayudar a comprender las propiedades y limitaciones de los
diferentes sistemas, pero no debe utilizarse como una lista para decidir o descartar una interfaz
como graspable o tangible.
5.2. Conceptualización de las TUIs y el modelo de interacción MCRit En 2001, Ullmer e Ishii presentan los primeros pasos hacia la identificación de las interfaces
tangibles de usuario como una corriente clara y coherente de investigación [71] . Resaltan las
características clave y presentan un modelo de interacción de las interfaces de usuario tangibles.
Ullmer e Ishii definen las interfaces de usuario tangibles como los sistemas que dan forma física a
la información digital, empleando artefactos físicos, tanto para la representación como para el
control de los medios computacionales. Esta definición sería más tarde ampliada por frameworks
emergentes, tal como [72].
Inspirado en el modelo de interacción GUI denominado MVC (Modelo, Vista, Control), Ullmer e
Ishii proponen un modelo de interacción llamada MCRit, una abreviatura para Modelo-Control-
Representación (intangible y tangible). Mientras que el modelo MVC hace hincapié en la
separación entre la representación gráfica (es decir, la vista) y el control (mediada por los
dispositivos de entrada como un mouse y un teclado), el modelo MCRit destaca la integración de
la representación física y el control en las interfaces de usuario tangibles, que básicamente elimina
la distinción entre los dispositivos de entrada y de salida.
Figura 33 – Izq.: modelo de interacción GUI. Der.: modelo de interacción MCRit.
Esta "integración de la representación y el control" significa que los objetos tangibles encarnan
tanto a los medios de representación como a los medios de manipulación de los datos digitales. El
modelo MCRit ilustra tres relaciones centrales, que se traducen en propiedades de la TUIs. Una
cuarta propiedad resulta de integrar las tres primeras:
5. Los objetos tangibles se acoplan, a través de funcionalidades computacionales, con datos
digitales (acoplamiento computarizado).
6. Los objetos tangibles representan los medios de control interactivo. El movimiento y la
manipulación de objetos es la forma dominante de control.
7. Los objetos tangibles están perceptivamente ligados con representaciones producidas
digitalmente (por ejemplo, de audio y visuales, proyecciones).
67
8. El estado de los objetos tangibles representa aspectos centrales del estado del sistema (el
sistema es, al menos, parcialmente legible si se corta la energía).
5.3. Clasificación de las TUIs Ullmer et al. [73] identifican varios tipos dominantes de TUIs:
Superficies interactivas. Con frecuencia, los objetos tangibles se colocan y manipulan
sobre superficies planas. O bien la disposición espacial de los objetos y/o sus relaciones
(por ejemplo, el orden de colocación) son interpretadas por el sistema. Un ejemplo típico
de superficie interactiva es Urp[21].
Ensamblaje constructivo. Elementos modulares y conectable están unidos el uno al otro
de manera similar a los modelos de kits de construcción física. Tanto la organización
espacial como el orden de las acciones podrán ser interpretadas por el sistema. Un
ejemplo típico de este tipo de TUI es BlockJam[3].
Token + constraint (restricciones) combina dos tipos de objetos físico-digitales. Las
restricciones proporcionan la estructura (pilas, ranuras, huecos) que limitan el
posicionamiento y el movimiento de fichas mecánicas y asisten al usuario al proporcionar
una guía táctil. Las restricciones pueden expresar y hacer cumplir la sintaxis de interacción.
Ejemplos típicos son The Marble Answering Machine y The Slot Machine [22].
Figura 34 – Izq.: Superficie Interactiva. Cent.: Token + restricciones. Der.: Ensamblaje constructivo
Muchos sistemas pueden pertenecer a varias de estas categorías, por ejemplo, pueden tener
restricciones impuestas sobre una superficie interactiva.
5.4. Token And Constraint El paradigma TAC [74] (Token And Constraint) se refiere a la identificación de los elementos
básicos de una TUI. El paradigma TAC presenta un conjunto compacto de construcciones que es
suficiente para describir la estructura y la funcionalidad de un gran subconjunto de TUIs. Este
conjunto de construcciones tiene como objetivo permitir a los desarrolladores de TUI especificar y
comparar diseños alternativos teniendo en cuenta cuestiones tales como la forma, la sintaxis
física, el marco de referencia, y la interacción en paralelo.
Basándose en el enfoque de Token + Constraint de Ullmer [73], Shaer et al. [74] describen la
estructura de una TUI como un conjunto de relaciones entre objetos físicos e información digital.
68
Se identifican cuatro componentes básicos que en conjunto pueden ser combinados para describir
la estructura y funcionalidad de una TUI. Estos incluyen: Pyfo, Token, restricción, y TAC.
Figura 35 – Ilustración de las dos fases de interacción de token + constraint. Primero la asociación del token con la respectiva restricción, y luego la manipulación del token en función de esa restricción..
Un pyfo es un objeto físico que forma parte de una TUI (por ejemplo, una superficie, un modelo de
construcción, un bloque). Un pyfo puede realzar sus propiedades físicas con propiedades digitales,
tales como gráficos proyectados y sonido. Hay dos tipos de pyfos: tokens y restricciones. Cada pyfo
puede ser un token, una restricción, o ambos.
Un token es una pyfo tangible que está mapeado a información digital o una función
computacional. El usuario interactúa con el token con el fin de acceder a o manipular información
digital. Las propiedades físicas de un token pueden reflejar la naturaleza de la información o la
función que representa. Asimismo, las propiedades físicas del token pueden dar una idea de cómo
debe ser manipulado.
Una restricción es un pyfo que limita el comportamiento del token con el que está asociado. Una
restricción limita el comportamiento de un token en las siguientes tres maneras:
1. Las propiedades físicas de la restricción sugieren al usuario la forma de manipular (y cómo
no debe manipular) al token asociado.
2. La restricción limita el espacio físico de interacción del token.
3. La restricción sirve como un marco de referencia para la interpretación del token y la
composición de restricciones.
Finalmente, un TAC (Token And Constraints) es una relación entre un token y una o más
restricciones. La relación TAC a menudo expresa a los usuarios algo acerca de los tipos de
interacciones que se pueden llevar a cabo con una interfaz. Las relaciones TAC son definidas por el
desarrollador de la TUI y se crean cuando un token está físicamente asociado con una restricción.
Interactuar con un TAC implica la manipulación de un token físico (de una forma discreta o
continua) con respecto a sus restricciones. Esta interacción tiene interpretación computacional. La
manipulación de un token con respecto a sus restricciones resulta en la modificación tanto del
estado físico como digital del sistema.
69
Figura 36 – Tres ejemplos de relaciones TAC entre tokens y restricciones. Presencia, presencia + traslación, presencia + rotación.
Para especificar una TUI utilizando el paradigma TAC, el desarrollador de la TUI define las posibles
relaciones TAC de la TUI. Esto define una gramática de las formas en que los objetos se pueden
combinar entre sí para formar expresiones significativas, las expresiones que pueden ser
interpretadas tanto por los usuarios como por los sistemas computacionales subyacentes.
5.5. Fortalezas del enfoque Token + Constraint Cuando se compara el enfoque Token + Constraint con las superficies interactivas, el uso de
restricciones físicas ofrece una serie de beneficios [73], incluyendo:
1. Aumento de la respuesta táctil pasiva.
2. Mayores posibilidades de retroalimentación con fuerza activa.
3. Disminución de la demanda de atención visual.
4. Mayor conciencia kinestésica10.
5. Mayores posibilidades para uso embebido.
6. Mayor flexibilidad y accesibilidad para las tecnologías de sensado e implementación.
Muchos de estos beneficios se derivan del estilo de las formas físicas empleadas por el enfoque de
Token + Constraint. Específicamente, el uso de formas físicas limitadas por restricciones mecánicas
ayuda a expresar:
El conjunto de elementos físicos que pueden tomar parte dentro de una dada restricción.
La estructura mecánica de las restricciones puede ayudar a expresar compatibilidades
físicas/digitales con subconjuntos de tokens codificados como propiedades físicas tales
como tamaño y forma.
El conjunto de configuraciones físicas que los tokens pueden asumir. Los token son a
menudo mecánicamente restringidos a configuraciones que tienen interpretaciones
computacionales bien definidas.
La delimitación entre regiones de interacción con diferentes interpretaciones
computacionales. Los límites bien definidos de las restricciones son una ayuda para
combinar e integrar múltiples restricciones, cada una, potencialmente, con diferentes
comportamientos.
10
Percepción del equilibrio y de la posición de las partes del cuerpo.
70
Figura 37 – Restricciones múltiples o anidadas.
Visto desde una perspectiva algo diferente, el uso de restricciones físicas tiene otras
ramificaciones positivas desde el punto de vista de uso e implementación. Éstas incluyen:
Percepción humana. Las restricciones utilizan propiedades físicas para codificar
perceptualmente la sintaxis digital. Entre otras cosas, trasladan la carga cognitiva a las
representaciones externas y facilitan el agrupamiento perceptivo de agregados de objetos.
Manipulación humana. Las restricciones proporcionan a los usuarios una mayor sensación
de realimentación kinestésica, derivado de la realimentación táctil pasiva proporcionada
por la relación de encaje entre los tokens y las restricciones. Las restricciones también
facilitan la manipulación de los agregados formados por múltiples objetos físicos. Esto se
realiza tanto a través de la manipulación completa de las estructuras de restricción (por
ejemplo, mover una rejilla que contiene fichas o tokens), o por medio de acciones como
barrer una serie de fichas múltiples que están conjuntamente agrupadas.
Detección por la computadora. Las restricciones pueden simplificar significativamente la
detección del estado físico de la Interfaz Tangible. Esto puede facilitar la implementación,
aumentar la escalabilidad, y aumentar la flexibilidad de las formas físicas que las interfaces
tangibles pueden asumir.
Interpretación por la computadora. Las restricciones pueden simplificar la interpretación
computacional subyacente de los objetos físicos que componen una Interfaz Tangible, al
limitar físicamente a un espacio más pequeño los estados relativamente bien definidos.
Esto es una ayuda para la implementación, y puede ayudar a minimizar las condiciones de
error.
71
6. Tecnologías de implementación para TUIs Hasta la fecha, no existen dispositivos de entrada o salida estándar para TUIs. Los desarrolladores
de TUIs emplean una amplia gama de tecnologías que detectan objetos y gestos, y sensan y crean
cambios en el mundo físico. Las estrategias empleadas a lo largo de la corta historia de las TUIs
abarcan desde el uso de dispositivos electrónicos hechos a medida y hardware industrial estándar
hasta el desarmare y re utilización de los dispositivos electrónicos de algunos juguetes.
Las dificultades para la construcción de TUIs funcionales en los primeros días son difíciles de
imaginar hoy en día. Tuvieron que utilizarse, microprocesadores industriales estándar lo que
requería de programación de bajo nivel. Sin embargo, hoy en día un mejor conjunto de
herramientas y soporte de hardware están disponibles, facilitando el desarrollo a través de
lenguajes de programación de alto nivel y placas de propósito específico.
La amplia gama de tecnologías, dispositivos y técnicas que se utilizan para la creación de
prototipos e implementación de TUIs puede ser desconcertante. Por lo tanto, se utilizara un
número de propiedades organizativas para analizar y comparar las tecnologías más comunes de
implementación de TUIs. A continuación se describen tres tecnologías de aplicación que se utilizan
a menudo en el desarrollo de TUIs: RFID, visión por computadora, y micro controladores.
Finalmente, se describen las nuevas herramientas y toolkits que facilitan la implementación y
creación de prototipos de interfaces de usuario tangibles, y se basan en estas tecnologías básicas.
6.1. RFID La Identificación por radiofrecuencia (RFID) es una tecnología inalámbrica basada en señales de
radio que permite detectar la presencia y la identidad de un objeto etiquetado cuando está dentro
del rango de un lector de etiquetas (una antena). En general hay dos tipos de etiquetas RFID:
etiquetas RFID activas, que contienen una batería y por lo tanto puede transmitir una señal de
forma autónoma, y las etiquetas RFID pasivas, que no tienen batería y requieren una fuente
externa para iniciar la transmisión de la señal. En general, las etiquetas RFID contienen un
transpondedor (¿transductor?) que está compuesto por un circuito integrado que almacena y
procesa información, y de una antena para recibir y transmitir una señal. La mayoría de las TUIs
basadas en RFID emplean etiquetas RFID pasivas de bajo costo y por lo tanto, constan de dos
partes: un lector de etiquetas que se fija a un dispositivo de cómputo y un conjunto de objetos
etiquetados. La comunicación entre una etiqueta y un lector sólo se produce cuando ambas están
próximas. La distancia de detección varía en función del tamaño de la antena, de la etiqueta RFID y
de la fuerza de su campo electromagnético. Debido al costo de antenas grandes, el uso de RFID
está generalmente limitado a la detección a corta distancia, requiriendo a los objetos ser
colocados directamente en o pasarlos sobre el lector. Algunos lectores de etiquetas son capaces
de detectar varias etiquetas al mismo tiempo, o de escribir pequeñas cantidades de datos a las
etiquetas individuales. Otros lectores de etiquetas son sólo de lectura o sólo son capaces de
detectar una etiqueta a la vez. Cuando una etiqueta es detectada, el lector de etiquetas pasa un
ID, cadena ASCII, a la computadora. La aplicación TUI puede interpretar la cadena de entrada de
identificación, determinar su contexto de aplicación, y proporcionar una respuesta.
72
Múltiples TUIs se implementan utilizando tecnología RFID. Los ejemplos incluyen una serie de
prototipos que ilustran el potencial de uso de etiquetas RFID para conectar el mundo físico y el
digital presentados en 1999 por los investigadores de Xerox PARC. Estos prototipos incluyen libros
y documentos aumentados, así como un cubo de fotos y un reloj de pulsera. Un ejemplo muy
conocido implementado con esta tecnología es mediaBlocks [75], una TUI que consiste en un
conjunto de bloques de madera, marcados con etiquetas RFID, que sirven como iconos físicos
("phicons") para la contención, el transporte y la manipulación de medios digitales.
6.2. Micro-controladores, sensores y actuadores Los microcontroladores actúan como una pasarela entre el mundo físico y el mundo digital [76].
Son equipos pequeños y baratos que se pueden embeber en un objeto físico o en el entorno físico.
El microcontrolador recibe información del mundo físico a través de sensores, y afecta el mundo
físico a través de actuadores. Los microcontroladores se pueden utilizar de forma independiente o
se pueden comunicar con una computadora. Existe una amplia variedad de sensores y actuadores
disponibles para ser utilizados en sistemas embebidos. La tecnología de sensores pueden captar
una amplia gama de propiedades físicas, entre ellas la intensidad de la luz, la reflexión, el nivel de
ruido, el movimiento, la aceleración, la ubicación, la proximidad, la posición, el contacto, la altitud,
la dirección, la temperatura, la concentración de gas, y la radiación. Schmidt y Laerhoven [77] dan
una visión breve pero detallada de los tipos de sensores existentes. Los actuadores afectan el
mundo real mediante la producción de luz, sonido, movimiento, o realimentación táctil. Los
microcontroladores también pueden estar conectados a lectores RFID. Los actuadores de uso más
frecuente son los LEDs, altavoces, motores y electroimanes.
Muchos sistemas TUI se construyen utilizando micro-controladores integrados. Los ejemplos
incluyen Posey [78], un kit de construcción de piezas encastrables para modelar, jugar y aprender,
y Senspectra [79] un conjunto de herramientas de modelado físico para la detección y visualización
de tensión estructural. Estos sistemas TUI utilizan una amplia gama de microcontroladores y
sensores para permitir interacciones ricas y variadas. Sin embargo, todos ellos proporcionan una
realimentación física mínima mediante el uso de LEDs, mientras que se comunican con una
computadora para proporcionar una respuesta digital multimedial.
Si bien numerosos TUIs se implementan utilizando microcontroladores, relativamente pocos TUIs
demuestran el uso de una rica realimentación háptica, tal como movimiento, atracción ó
repulsión. Navigational Blocks [80] es una TUI para la navegación y la recuperación de información
histórica que ilustra el uso de la retroalimentación física táctil. El sistema consta de un conjunto de
bloques, cada uno con un microcontrolador. Cada cara de un bloque representa un parámetro de
consulta. Cada bloque es capaz de detectar su propia orientación así como la orientación de un
bloque adyacente. Cuando se conectan dos bloques, electroimanes en cada bloque se utilizan para
generar atracción magnética, o repulsión. Esta realimentación háptica refleja la relación entre los
parámetros de la consulta actual. Pico [81] es una TUI formada por una superficie interactiva que
utiliza accionamiento para mover elementos físicos sobre la superficie. Se pueden utilizar
restricciones mecánicas para limitar el movimiento de las fichas. El movimiento de las fichas se
genera mediante una matriz de 512 electroimanes.
73
Aunque algunos de los microcontroladores utilizados para el desarrollo de TUI requieren de
conocimientos de programación de bajo nivel, varias plataformas fáciles de utilizar para la
creación de prototipos están actualmente disponibles para propósitos educativos, así como para
los desarrolladores de TUIs sin conocimientos técnicos. Estas plataformas de prototipado de alto
nivel facilitan el desarrollo iterativo reducimiento substancialmente el umbral de creación de
prototipos de TUIs. A continuación, se discuten algunos ejemplos de tales plataformas de
prototipado de alto nivel.
Arduino [67] es una plataforma física de computación de código abierto basada en una simple
placa de entrada/salida y un entorno de desarrollo. Arduino puede ser utilizado para implementar
dispositivos autónomos interactivos o puede ser conectado a software que se ejecuta en una
computadora. El entorno de desarrollo de Arduino es una aplicación de JAVA multi-plataforma que
proporciona un editor de código y un compilador, y es capaz de transferir de forma serial el
firmware a la placa. Éste se basa en Processing, un entorno de desarrollo dirigido a las
comunidades de arte electrónicas y diseño visual. El lenguaje de programación de Arduino está
relacionado con Wiring, un lenguaje parecido a C.
El Handy Board y el Handy Cricket [82] son microcontroladores baratos y fáciles de usar dirigidos
principalmente a usos educativos y de aficionados. Diseñados originalmente como controladores
para robótica, se utilizaron en el desarrollo de múltiples TUIs, así como en varios cursos de
laboratorio [83]. El Handy Board está programado en C interactivo, un subconjunto del lenguaje de
programación C, el Handy Cricket se programa mediante Cricket Logo. Los entornos de desarrollo
de ambos microcontroladores son multiplataforma. Ellos proporcionan un editor y un compilador,
y permiten la transferencia del firmware hacia los controladores a través de una conexión USB.
O'Sullivan y Igoe [76] ofrecen un excelente resumen de los sensores y actuadores que se pueden
usar con una variedad de microcontroladores incluyendo Arduino, Handy Board, y Handy Cricket.
Lego Mindstorms NXT [84] es un kit de robótica programable, que sustituye a la primera
generación de Lego Mindstorm. El kit tiene capacidades sofisticadas, incluyendo controladores de
servo motor y una variedad de sensores, tales como un sonar de distancia y un sensor de sonido, y
puede ser utilizado para la creación de prototipos de TUIs. Lego ha lanzado el firmware para el
ladrillo NXT Intelligent Brick como Open Source; por lo tanto, varios kits de desarrollo están
disponibles para este sistema. Por último, el kit PicoCricket [85] es similar al kit de robótica Lego
Mindstorms. Sin embargo, Lego Mindstorms está diseñado especialmente para la robótica,
mientras que el Kit de PicoCricket está diseñado para desarrollar creaciones artísticas que incluyen
luces, sonido, música y movimiento. Este último sistema, aunque es especialmente atractivo para
un público joven, también puede utilizarse para desarrollar rápidamente prototipos funcionales de
TUIs.
74
6.3. Visión por Computadora
6.3.1. ¿Qué es la Visión por Computadora?
La visión por computadora es la transformación de los datos de una cámara de fotos o de video en
una decisión o una nueva representación. Todas estas transformaciones se llevan a cabo para
lograr algún objetivo particular. Los datos de entrada pueden incluir alguna información
contextual, como "la cámara está montada en un auto" o "el sensor láser indica un objeto a 1
metro de distancia". La decisión podría ser: "hay una persona en esta escena" o "hay 14 células
tumorales en esta diapositiva". Una nueva representación puede significar convertir una imagen
color en una imagen de escala de grises o la eliminación del movimiento de la cámara de una
secuencia de imágenes.
Debido a que los humanos son criaturas visuales, es fácil que se dejen engañar en pensar que las
tareas de visión por computadora son fáciles. ¿Qué tan difícil puede ser encontrar, por ejemplo,
un auto cuando se lo está mirando en una imagen? Sus intuiciones iniciales pueden ser algo
engañosas. El cerebro humano divide la señal visual en muchos canales que transmiten diferente
información al cerebro. El cerebro tiene un sistema de atención que identifica, de una manera
dependiente de la tarea, partes de una imagen que considera importantes para realizar una tarea
en tanto que suprime otras. Hay una respuesta masiva al flujo de información visual que es, hasta
ahora, poco comprendida. Hay un amplio conjunto de entradas asociativas proveniente de los
sensores de control de los músculos y de todos los otros sentidos que permiten que el cerebro se
base en asociaciones cruzadas adquiridas a lo largo de años de experiencia. Los ciclos de
realimentación en el cerebro se remontan a todas las etapas de procesamiento, incluyendo a los
sensores de hardware en sí (los ojos), que mecánicamente controlan la iluminación a través del iris
y ajustan la recepción sobre la superficie de la retina.
En un sistema de visión artificial, sin embargo, una computadora recibe una grilla o matriz de
números desde la cámara o desde el disco, y eso es todo. En su mayor parte, no hay
reconocimiento de patrones integrado, ni control automático de enfoque o de apertura, ni
asociaciones cruzadas basadas en años de experiencia. En su mayor parte, los sistemas de visión
son todavía bastante primitivos. La Figura 38 muestra una fotografía de un automóvil. En ese
cuadro se ve el espejo lateral del lado del conductor del vehículo. Lo que la computadora "ve" es
sólo una grilla de números. Cualquier número dado dentro de esa grilla, tiene un componente de
ruido bastante grande y por lo tanto por sí misma, brinda poca información, pero esta grilla de
números es todo lo que la computadora "ve". La tarea, por lo tanto, es convertir esta grilla ruidosa
de números en la percepción del "espejo retrovisor".
75
Figura 38 – Para una computadora, el espejo del auto es solo una grilla o matriz de números.
De hecho, resolver el problema, como se lo ha planteado hasta ahora, es extremadamente
complejo y además, probablemente, no se encuentre una buena solución (o aún, tal vez no se
encuentre una solución). Dada una vista bidimensional (2D) de un mundo 3D, no hay una única
forma de reconstruir la señal 3D. Formalmente, un problema tan mal planteado no tiene solución
única ni buena. La misma imagen 2D podría representar cualquiera de una infinita combinación de
escenas 3D, incluso si los datos son perfectos. Sin embargo, como ya se mencionó, los datos están
afectados por el ruido y las distorsiones. Esta corrupción se debe a las variaciones en el mundo (el
clima, la iluminación, los reflejos, los movimientos), las imperfecciones en la lente y la
configuración mecánica, el tiempo finito de integración del sensor óptico (desenfoque por
movimiento), el ruido eléctrico en el sensor y los métodos de compresión utilizados después de
capturar la imagen. En vista de estos enormes desafíos, ¿cómo se pude lograr algún progreso?
En el diseño de un sistema práctico, el conocimiento adicional del contexto a menudo se puede
utilizar para evitar las limitaciones impuestas por los sensores visuales. Considérese el ejemplo de
un robot móvil que debe encontrar y recoger abrochadoras en un edificio de oficinas. El robot
puede usar el hecho de que un escritorio es un objeto que se encuentra dentro de las oficinas y las
abrochadoras se encuentran en la mayoría de los casos sobre los escritorios. Esto da una
referencia implícita de tamaño ya que las abrochadoras deben caber sobre los escritorios.
También ayuda a eliminar falsos "reconocimientos" de abrochadoras en lugares imposibles (por
ejemplo, en el techo o en una ventana). El robot puede ignorar un dirigible publicitario de 200
metros con forma de abrochadora, porque el dirigible no cumple con el requisito de que el fondo
76
sea de madera como el de un escritorio. Por el contrario, en tareas tales como recuperación de
imágenes, todas las imágenes de abrochadoras en una base de datos pueden ser de abrochadoras
reales por lo que tamaños grandes y otras configuraciones inusuales pueden haber sido
implícitamente excluidas por los que tomaron las fotografías. Esto es, el fotógrafo,
probablemente, tomó fotografías sólo de abrochadoras reales, de tamaño normal. Las personas
también tienden a centrar los objetos cuando toman fotografías y tienden a ponerlos en
orientaciones características. Por lo tanto, a menudo hay información implícita no intencional en
las fotos tomadas por humanos.
La información contextual también puede ser modelada de forma explícita mediante técnicas de
aprendizaje automático. Variables ocultas tales como el tamaño, la orientación en dirección de la
fuerza de gravedad, y demás, pueden ser luego correlacionadas con sus valores a partir del uso de
conjunto de datos de entrenamiento. Alternativamente, se puede tratar de medir variables ocultas
de sesgo mediante el uso de sensores adicionales. El uso de un telémetro láser para medir
profundidad, por ejemplo, nos permite medir con precisión el tamaño de un objeto.
El siguiente problema de visión por computadora es el ruido. Por lo general se lidia con el ruido
mediante el uso de métodos estadísticos. Por ejemplo, puede ser imposible detectar un borde en
una imagen simplemente mediante la comparación de un punto con sus vecinos inmediatos. Sin
embargo, si se observan las estadísticas de una región local, la detección de bordes se hace mucho
más fácil. También es posible compensar el ruido tomando estadísticas a lo largo del tiempo.
Existen otras técnicas para lidiar con el ruido o la distorsión mediante la construcción de modelos
explícitos aprendidos directamente de los datos disponibles. Por ejemplo, debido a que las
distorsiones de las lente son bien comprendidas, sólo es necesario conocer los parámetros de un
modelo polinomial sencillo con el fin de describir y por lo tanto corregir tales distorsiones casi por
completo.
Las acciones o decisiones que la visión por computadora intenta tomar, basada en datos
provenientes de la cámara, se realizan en el contexto de una tarea o propósito específico. Es
posible que se desee eliminar el ruido de una imagen para que nuestro sistema de seguridad emita
una alerta si alguien trata de escalar una pared o porque necesitamos un sistema de monitoreo
que cuente cuánta gente cruza por una zona en un parque de diversiones. El software de visión
para robots que deambulan por edificios de oficinas empleará diferentes estrategias que el
software de visión del sistema de cámaras de seguridad fijas, porque los dos sistemas tienen
contextos y objetivos muy diferentes. Como regla general: cuanto más restringido es el contexto
de visión por computadora, más se puede confiar en esas restricciones para simplificar el
problema y más confiable será la solución final.
6.3.2. Visión por computadora aplicada a las TUIs
En el contexto de las TUIs, la visión por computadora es usada frecuentemente en aplicaciones
espaciales y de superficie interactivas, ya que esta tecnología es capaz de detectar la posición de
varios objetos en una superficie 2D en tiempo real, además de proveer información adicional,
77
como orientación, color, tamaño, forma, etc. Los sistemas de visión por computadora pueden ser
caracterizados en dos tipos:
Los que utilizan técnicas de inteligencia artificial, empleando algoritmos sofisticados para
interpretar automáticamente una imagen, ó
Los que usan etiquetas, donde el sistema sigue marcadores de referencia específicamente
definidos que están unidos a los objetos físicos.
Las etiquetas o marcadores permiten la identificación unívoca de cada marcador, así como un
cálculo preciso de su posición y su ángulo de rotación sobre una superficie 2D. Dado que los
marcadores de referencia son reconocidos y seguidos por un algoritmo de visión por computadora
que está optimizado para un diseño de marcadores específico, el sistema tiende a ser más
robusto, más preciso, y computacionalmente más barato que los sistemas basados en inteligencia
artificial. Por lo tanto, la tecnología de visión por computadora basada en etiquetas es
frecuentemente usada en el desarrollo de TUIs. Los sistemas TUIs basados en visión por
computador TUI normalmente requieren al menos tres componentes: una cámara de alta calidad,
un proyector LCD para proporcionar una salida o respuesta gráfica en tiempo real, y un paquete de
software de visión por computadora.
Una gran variedad de TUIs se implementan con visión por computadora basada en etiquetas o
marcadores. Algunos ejemplos incluyen Urp [21], una interfaz de usuario tangible para la
planificación urbana y ReacTable [4] . La técnica de EventTable [86] se basa en eventos en lugar de
centrarse en el seguimiento de objetos. Usando esta técnica, los marcadores de referencia se
parten y distribuyen entre los objetos, de modo que sólo cuando los objetos etiquetados están
conectados físicamente forman una etiqueta completa que se detecta.
Ejemplos de TUIs basados en visión por computadora que no utilizan marcadores de referencia o
etiquetas, incluyen Designers’ Outpost [87], una TUI para el diseño de sitios web que se
implementa por medio de una amplia librería de visión por computadora y algoritmos de
procesamiento de imágenes, y el ColorTable [88], un sistema para el diseño urbano, el cual utiliza
el color y la forma para distinguir objetos.
El rendimiento, la fiabilidad y la robustez de los sistemas basados en visión por computadora son
susceptibles a las variaciones en la iluminación y al desenfoque por movimiento. El uso del color
para identificar los objetos puede ser relativamente robusto, pero se debe limitar el
reconocimiento a un pequeño número de colores de alto contraste. Una forma de mejorar la
robustez y velocidad de detección es pintar las fichas de modo que reflejen la luz infrarroja y
emplear un filtro para la cámara. Esto hará que la cámara sólo detecte los objetos pintados, pero
reduce la capacidad de los sistemas para distinguir objetos diferentes.
Varias librerías brindan soporte para el desarrollo de TUIs basadas en visión por computadora. Las
librerias ARToolKit [89] [90] y reacTIVision [65], dan soporte para el seguimiento de marcadores de
referencia. Papier Mâché [91] [92] es un conjunto de herramientas para la creación de TUI
utilizando visión por computadora, etiquetas electrónicas, y códigos de barra. La misma introduce
78
un modelo de alto nivel de eventos para trabajar con visión por computadora, RFID y códigos de
barra, lo que facilita la portabilidad de la tecnología. El uso de una librería o toolkit de visión por
computador para el desarrollo de una TUI reduce sustancialmente la complejidad y el tiempo
requerido para el desarrollo de la misma.
6.3.3. OpenCV
A continuación se detalla una librería de visión por computadora. La misma es la elegida para
implementar parte del prototipo por lo que se hace una descripción más detallada de la misma.
OpenCV [93] es una librería de código abierto de visión por computadora disponible en
http://SourceForge.net/projects/opencvlibrary. La librería está escrita en C y C++ y corre bajo
Linux, Windows y Mac OS X. Existen desarrollos activos de interfaces para C#, Java, Python, Ruby,
Matlab y otros lenguajes.
OpenCV ha sido diseñada pensando en la eficiencia computacional y con un fuerte enfoque en las
aplicaciones de tiempo real. OpenCV está escrita en C optimizado y puede aprovechar las ventajas
de los procesadores multinúcleo.
Uno de los objetivos de OpenCV es proporcionar una infraestructura de visión por computadora
fácil de usar, que ayude a las personas a construir rápidamente aplicaciones de visión bastante
complejas. La librería OpenCV contiene más de 500 funciones que cubren muchas áreas de
aplicación del campo de visión por computadora, incluyendo la inspección de productos en
fábricas, imágenes médicas, seguridad, interfaces de usuario, calibración de cámaras, visión
estéreo, y robótica. Debido a que la visión por computadora y el aprendizaje automático a
menudo van de la mano, OpenCV también contiene una librería completa de aprendizaje
automático de propósito general (MLL). Esta última se centra en el reconocimiento estadístico de
patrones y algoritmos de agrupamiento.
OpenCV está dirigida a proporcionar las herramientas básicas necesarias para resolver problemas
de visión por computadora. En algunos casos, las funcionalidades de alto nivel de la librería serán
suficientes para resolver los problemas más complejos de visión por computadora. Aún cuando
éste no sea el caso, los componentes básicos de la librería son lo suficientemente completos para
permitir la creación de una solución completa propia para casi cualquier problema de visión por
computadora.
La licencia de código abierto para OpenCV se ha estructurado de tal manera que se pueda
construir un producto comercial utilizando la totalidad o parte de OpenCV. No se está bajo
ninguna obligación de que el código del producto creado sea abierto. En parte debido a estas
condiciones de licencia liberales, hay una gran comunidad de usuarios que incluye a personas de
grandes empresas (IBM, Microsoft, Intel, Sony, Siemens, y Google, por nombrar sólo algunas) y
centros de investigación (como Stanford, MIT , CMU, Cambridge, y el INRIA). OpenCV es popular
en todo el mundo, con grandes comunidades de usuarios en China, Japón, Rusia, Europa e Israel.
79
Desde su versión alfa en enero de 1999, OpenCV ha sido utilizada en muchas aplicaciones,
productos y proyectos de investigación. Estas aplicaciones incluyen: unión automática de
imágenes11, mapas satelitales, alineación de escaneo de imágenes, reducción de ruido de
imágenes médicas, análisis de objetos, sistemas de seguridad y detección de intrusos, sistemas
automáticos de control y seguridad, sistemas de inspección de manufacturas, calibración de
cámaras, aplicaciones militares y vehículos aéreos, terrestres, y submarinos no tripulados. Incluso
se ha utilizado en el reconocimiento de sonido y música, donde las técnicas de reconocimiento de
imágenes se aplican a imágenes del espectrograma de sonidos. OpenCV es una parte clave del
sistema de visión del robot de Stanford, "Stanley", que ganó la carrera DARPA Grand Desert
Challenge en el año 2005.
6.4. Toolkits y librerías para implementar Interfaces Tangibles Varios conjuntos de herramientas y librerías de software han surgido para facilitar la
implementación de prototipos funcionales de TUIs. Esta sección describe algunas de las
herramientas existentes para el desarrollo de interfaces tangibles, así como herramientas para
desarrollos basados en estilos de interacción de realidad aumentada. Se han seleccionado
herramientas y librerías que aportan una solución técnica para el desarrollo de TUIs.
Los Phidgets, disponibles comercialmente [94], proporcionan un conjunto de dispositivos plug and
play con conexión USB (por ejemplo, placas de E/S, sensores y actuadores) que son análogos a los
widgets de las interfaces gráficas de usuario. Este sistema permite que cualquier sensor analógico
pueda ser conectado en su placa, siempre que module una señal de 5-V. Del mismo modo,
cualquier interruptor on/off y otros dispositivos digitales de E/S pueden ser conectados a la placa y
controlados con un valor binario. Los Phidgets están apuntados a facilitar la tarea de los
desarrolladores de software en la implementación de prototipos mecatrónicos de TUIs
compuestos de sensores y actuadores cableados. Tales TUIs son capaces tanto de tomar entradas
físicas, como de generar salidas o respuestas físicas. La principal ventaja de Phidgets es que sus
dispositivos están controlados centralmente a través de una computadora convencional en lugar
de a través de un microprocesador estándar. Por lo tanto, la integración de capacidades digitales,
tales como la creación de redes, el uso de medios multimedia, y la interoperabilidad del
dispositivo se vuelven más fácil. Otra ventaja es la facilidad de programación y depuración que son
mucho más difíciles de hacer cuando uno compila y descarga un programa a un microprocesador
estándar. Una TUI implementada utilizando esta tecnología es AudioPad [2] .
Ya se ha descrito Arduino [67] en la sección anterior “5.2. Micro-controladores, sensores y
actuadores”. Se trata de un conjunto de herramientas que consiste en la placa Arduino y el
entorno de programación. A diferencia de los Phidgets, que son sensores y actuadores construidos
específicamente, fácilmente conectados entre sí y controlados centralmente desde una
computadora convencional, Arduino interactúa con componentes electrónicos estándar. Arduino
11
El stitching o foto stitching es el proceso por el cual se combinan múltiples imágenes para producir una imagen panorámica o una imagen de alta resolución.
80
por lo tanto, no trata a los dispositivos electrónicos como “cajas negras”, requiriendo cableado
físico y la construcción del circuito.
El sistema VoodooIO [95] es similar a los Phidgets en proveer una serie de controles físicos, pero
hace hincapié en la maleabilidad de las interfaces físicas . VoodooIO utiliza un material de sustrato
en el que los controles pueden ser dinámicamente añadidos, ordenados, manipulados y
eliminados. Este material de sustrato sirve como un bus de red y energía al que los controles se
pueden conectar sin esfuerzo, sin cables, y rápidamente. Varios entornos de programación
soportan la integración de la funcionalidad de VoodooIO en las aplicaciones interactivas.
Papier-Mâché [91] [92] proporciona un API de alto nivel para la facilitación de la adquisición y la
abstracción de entradas de TUIs a través de visión por computadora, RFID y códigos de barras, así
como la facilitación para la portabilidad de una interfaz de una tecnología a otra. A través de
abstracciones independientes de la tecnología de entrada, Papier-Mâché permite a los
desarrolladores de software implementar rápidamente prototipos funcionales de TUIs, así como
redirigir una aplicación a una tecnología de entrada diferente, con mínimos cambios en el código.
Por medio del uso de visión por computadora, tecnología RFID y códigos de barras, Papier-Mâché
permite el desarrollo de TUIs que hacen seguimiento de objetos pasivos, sin marcar, como notas
de papel y documentos. El toolkit se encarga del descubrimiento y la comunicación con los
dispositivos de entrada, así como de la generación de eventos de alto nivel a partir de los eventos
de entrada de bajo nivel. Para facilitar la depuración, Papier-Mâché ofrece una ventana de
monitoreo que muestra los objetos de entrada y los eventos que se crean o se invocan. Se
implementa como un plug-in para Eclipse y soporta el desarrollo de aplicaciones Java.
Sólo algunos de los toolkits físicos que se listan están disponibles en el mercado. Los toolkits que
impliquen electrónica por su propia naturaleza, incluso siendo de código abierto, no pueden ser
puestos a disposición de forma gratuita. Ambos conjuntos de herramientas de software de visión
por computadora que se describen a continuación están disponibles de forma gratuita y sólo
requieren de una cámara web para el desarrollo de prototipos.
ARToolKit [89] [90] es una librería de visión por computadora para seguimiento de marcadores
que permite a los desarrolladores de software implementar rápidamente aplicaciones de realidad
aumentada. Además de permitir el seguimiento de la posición 3D y la orientación de los
marcadores cuadrados, el toolkit permite superponer imágenes virtuales sobre un objeto físico
real etiquetado con un marcador. Para hacer esto, se calcula la posición de la cámara real con
respecto a un marcador, y luego coloca una cámara virtual en el mismo punto. Modelos gráficos
tridimensionales generados por computadora pueden ser superpuestos exactamente sobre el
marcador real. Aunque originalmente estaba destinado a la generación de aplicaciones de realidad
aumentada, ARToolKit se utiliza a menudo para el desarrollo de TUIs. Por haber sido desarrollado
para brindar soporte para el desarrollo de aplicaciones de realidad aumentada, ARToolKit
proporciona información 3D (tamaño del marcador, ángulo de visión), pero emplea un formato de
salida adaptado a las imágenes 3D de realidad virtual, por lo tanto, hace que la interpretación de
la información 3D para otros fines sea un tanto difícil.
81
Por último, reacTIVision [65] es un framework multiplataforma de visión por computadora
diseñado principalmente para la construcción de superficies multi-táctiles. Permite el seguimiento
rápido y robusto de marcadores de referencia vinculados a objetos físicos, así como el seguimiento
multi-táctil de dedos. El componente central del framework es una aplicación independiente para
el seguimiento rápido y robusto de los marcadores de referencia en una secuencia de video en
tiempo real. El protocolo de comunicación subyacente, TUIO, soporta la transmisión eficiente y
confiable de los estados de objetos a través de una red de área local o una WAN. Se ha convertido
en un protocolo y una API común para la implementación de superficies tangibles multi-táctiles. El
toolkit reacTIVision, hasta el momento, sólo implementa el protocolo TUIO 2D no proporcionando
información 3D.
La principal diferencia entre reacTIVision y otros toolkits es su arquitectura distribuida, que separa
el tracker o rastreador de marcadores de la aplicación o lógica del programa. TUIO proporciona
una capa de abstracción para el seguimiento, y por lo tanto permite la transmisión de los datos de
la superficie a los clientes. Este enfoque facilita el desarrollo de clientes TUIO en varios lenguajes
de programación.
La principal ventaja de las herramientas presentadas es que reducen el umbral para la
implementación de prototipos de TUIs totalmente funcionales al ocultar y manejar detalles y
eventos de bajo nivel. Por lo tanto, reducen significativamente la duración de cada ciclo de diseño,
implementación y prueba.
Sin embargo, como cada una de estas herramientas proporciona soporte sólo para tecnologías y
componentes de hardware específicos, cada vez que un prototipo de TUI utiliza diferentes
tecnologías y diferente hardware (es común que se desarrollen varios nuevos prototipos a lo largo
de un proceso de desarrollo) el desarrollador de TUI debe aprender un nuevo toolkit o librería de
software y debe re-escribir el código. Mientras que el esfuerzo por codificar las técnicas de
interacción existentes ya se ha iniciado, la búsqueda de nuevas técnicas de interacción y
soluciones tecnológicas aún continúa. Por lo tanto son necesarias herramientas de software que
puedan ser fácilmente extendidas para admitir nuevas técnicas de interacción y nuevas
tecnologías. Por último, aunque la programación con toolkits reduce sustancialmente el tiempo y
el esfuerzo necesario de los desarrolladores de software para construir prototipos TUIs
completamente funcionales, no alcanza a proporcionar un conjunto lo suficientemente amplio de
abstracciones para especificar, discutir y programar la interacción tangible dentro de un equipo de
desarrollo interdisciplinario.
82
7. Fortalezas y limitaciones de las TUIs El principio básico para la interacción humano-computadora es facilitar a los usuarios el
cumplimiento de un conjunto de tareas. Diferentes tareas son mejor soportadas con diferentes
estilos de interacción. Por lo tanto, la comprensión de las fortalezas y limitaciones de un estilo de
interacción particular es esencial para determinar si es adecuado para soportar ciertas tareas.
Desde un punto de vista de diseño orientado a la resolución de un problema, la tangibilidad como
objetivo de diseño podría no ser siempre la solución correcta. Sin embargo, desde el punto de
vista de investigación, a menudo hay un valor en la exploración de lo que lo tangible nos puede
aportar, así como el descubrimiento de nuevos y diferentes enfoques. Tales exploraciones nos
proporcionan una imagen cada vez más clara de las fortalezas y limitaciones de la TUIs. El buen
diseño tiene como objetivo poner de manifiesto los puntos fuertes y aliviar los débiles, por
ejemplo mediante la construcción basada en las fortalezas de los elementos tangibles y
facilitándose de las fortalezas de otras áreas relacionadas para el cumplimiento de cualidades que
no pueden alcanzarse por medio de las TUIs. En el sentido contrario, la integración de elementos
tangibles puede aliviar los problemas de interacción de los sistemas no tangibles.
7.1. Fortalezas
7.1.1. Colaboración
Desde el principio, un objetivo subyacente de muchos sistemas TUIs ha sido fomentar el diálogo y
la comunicación entre los expertos del dominio (por ejemplo, arquitectos) y las partes interesadas
(por ejemplo, los futuros habitantes de los edificios), y brindar soporte para el aprendizaje
colaborativo (ver [21] [40]).
Hornecker y Buur [96] listan una serie de factores que dan soporte para la colaboración cara a
cara. La familiaridad y el affordance (abordabilidad) conocidos de la interacción cotidiana con el
mundo real reducen el umbral para comenzar a interactuar con un sistema y por lo tanto
aumentan la probabilidad de que los usuarios contribuyan activamente. Los tangibles han
demostrado tener una cualidad de invitación a ser usados [97] en comparación con las interfaces
basadas en el mouse y la pantalla, produciendo, por ejemplo, que un mayor número de visitantes
lo utilicen en el contexto de un museo, especialmente niños y mujeres, en lugar de un sistema
similar pero con interface gráfica. Los múltiples puntos de acceso asegurarán de que no haya un
"cuello de botella” para la interacción, lo que permite la interacción simultánea y facilita la
participación. Por otra parte, la interacción manual con los objetos es observable y tiene una
legibilidad aumentada debido a la visibilidad de los objetos físicos. Esto facilita la coordinación y la
conciencia grupal. A través de un cuidadoso diseño de la configuración física, una interfaz puede
sutilmente limitar y orientar los comportamientos de los usuarios. Por ejemplo, a la reacTable [4]
se le dio deliberadamente una forma circular con el fin de fomentar el intercambio y proporcionar
igualdad de acceso a un variado número de usuarios. Proporcionar un único conjunto de tarjetas o
tokens también puede fomentar el intercambio y el compartir entre los usuarios. Por otra parte,
los objetos tangibles puede ser entregados y compartidos con más facilidad que los gráficos, por lo
tanto los objetos tangibles fomentan la discusión grupal.
83
Jorda [5] argumenta que la capacidad para la acción simultánea y la visibilidad del sistema que
tienen los participantes hacen que las interfaces tangibles de mesa sean superiores a las interfaces
gráficas para compartir el control de datos en tiempo real como por ejemplo en la ejecución
musical. Los artefactos tangibles, los tokens por ejemplo, pueden ser vistos como recursos para la
actividad compartida.
7.1.2. Ubicación
Las interfaces tangibles pueden ser interpretadas como una implementación concreta de la noción
original de Computación Ubicua, cuyo objetivo era permitir a los usuarios permanecer situados en
el mundo real, y retener la primacía del mundo físico. Sin embargo, aunque las interfaces tangibles
están insertas o embebidas en el contexto, el objetivo del diseño de las interfaces tangibles no es
la invisibilidad de la interfaz, sino más bien el aspecto físico de la interfaz.
Una de las principales fortalezas de las interfaces tangibles es que pueden habitar el mismo
mundo que el usuario humano, se encuentran en su mismo mundo físico. Del mismo modo,
Hornecker y Buur [96] sostienen que la interacción tangible está integrada en el espacio real y por
lo tanto siempre se encuentra en lugares concretos. Las interfaces tangibles, no sólo por residir en
una pantalla, son una parte tan importante del entorno físico como lo son los elementos
arquitectónicos o aparatos y productos físicos. Esta naturaleza de ubicación específica de las TUIs
las hace muy poderosas como dispositivos de cómputo ubicuo. Esta propiedad de ubicación,
además, implica que el significado del dispositivo de interacción tangible puede cambiar
dependiendo del contexto en el que se encuentre.
7.1.3. Pensamiento tangible
El cuerpo físico del usuario y los objetos físicos con los que interactúa desempeñan un papel
central en la conformación de su comprensión del mundo [98]. Los bebés desarrollan sus
habilidades cognitivas espaciales a través de la experiencia locomotora. Los niños aprenden
conceptos abstractos a través de la interacción corporal con objetos tangibles [99]. Los
profesionales tales como diseñadores, arquitectos e ingenieros a menudo utilizan artefactos físicos
para razonar acerca de problemas complejos. Uno de los puntos fuertes de los TUIs en
comparación con las interfaces de usuario tradicionales es que aprovechan esta conexión del
cuerpo y del conocimiento, facilitando el pensamiento tangible, el pensamiento a través de
acciones corporales, la manipulación física y las representaciones tangibles.
7.1.4. Gesto
Mientras que los gestos son típicamente considerados como medios de comunicación, múltiples
estudios han demostrado que el uso de gestos desempeña un papel importante en aliviar la carga
cognitiva en adultos y niños, y en la planificación conceptual de la producción del habla [100]. Al
proporcionar a los usuarios con múltiples puntos de acceso al sistema y mantener su movilidad
física (las manos no tienen que restringirse o “atarse” al teclado y mouse), las TUIs permiten a los
usuarios aprovechar la ventaja de pensar y comunicarse a través de gestos sin restricciones
mientras interactúan con el sistema.
84
Las TUI emplean gestos como modalidad de interacción aprovechando la memoria kinestésica de
los usuarios, la capacidad de detectar, almacenar y recuperar la fuerza muscular, la posición del
cuerpo y el movimiento para construir habilidades. Kirk y col. [101] argumentan que la memoria
kinestésica activada al mover un objeto tangible puede aumentar la conciencia de las acciones
realizadas, ayudando a reducir el riesgo de errores de modo12. Además las TUIs permiten la
manipulación 3D de manera que los sistemas computaciones basados en superficies no pueden.
7.1.5. Acciones epistémicas y apoyo al pensamiento
Diversos estudios han demostrado que los artefactos físicos brindan soporte al proceso cognitivo
al servir como ayudas en el proceso de pensamiento y como memoria externa. Kirsh y Maglio
[102] hacen una distinción entre las acciones prácticas, que tienen consecuencias funcionales y
por lo tanto contribuyen a lograr una meta, y las acciones epistémicas, que no tienen
consecuencias funcionales pero cambian la naturaleza de la tarea mental. Las acciones epistémicas
ayudan a explorar las opciones, a realizar un seguimiento de las decisiones previas tomadas, y a
dar soporte a la memoria. Acciones tales como señalar los objetos, cambiar su disposición,
girarlos, taparlos, anotarlos y contarlos, pueden servir como acciones epistémicas que disminuyen
la carga de trabajo mental involucrada en una tarea, recurriendo a recursos que son externos a la
mente. Al facilitar la interacción de forma relativamente libre con objetos físicos y permitir
interacciones que no se interpretan computacionalmente, las TUIs tienden a hacer que las
acciones epistémicas sean más fáciles y naturales que en las interfaces de usuario tradicionales.
7.1.6. Representación tangible
En un estudio ampliamente conocido, Zhang y Norman [103] demostraron que la representación
de una tarea puede afectar radicalmente la capacidad de razonamiento y el rendimiento. En base
a estos resultados, Zhang [104] llegó a la conclusión de que las representaciones externas son
componentes intrínsecos de muchas de las tareas cognitivas, ya que guían, limitan, e incluso
determinan la conducta cognitiva.
Algunos dominios de aplicación, como el de la navegación de información o el de creación de
material multimedial (ej.: creación de música) no tienen representaciones espaciales inherentes o
convencionales, pero pueden ser representados utilizando un mapeo simbólico o metafórico. En
todos los casos, la interacción con las representaciones físicas aprovecha los conocimientos
previos del usuario y sus habilidades de interacción con el mundo real, no digital, como la física
básica, la conciencia y habilidades corporales, las habilidades sociales, y las habilidades y
conciencia del entorno o el ambiente en donde se encuentra.
El enfoque Token + constraints utiliza las propiedades físicas del sistema para crear una sintaxis
que codifica perceptualmente la sintaxis de la interacción. Dicha sintaxis física, no sólo disminuye
la necesidad de reglas explícitas [103], sino que también permite la inferencia perceptiva, que es la
12
Un tipo de error cuando un usuario realiza una acción apropiada para una situación en otra situación. Los ejemplos incluyen software de dibujo, donde un usuario intenta utilizar una herramienta de dibujo, como si se tratara de otra (por ejemplo, dibujar una línea con la herramienta de relleno).
85
lectura directa a través de la percepción humana, que no requiere de una deducción lógica
explícita.
7.1.7. Multiplexado espacial e interacción directa
"Con multiplexado espacial la entrada de cada función se controla con un
transductor dedicado, ocupando cada uno su propio espacio. Cada transductor
puede ser accedido de forma independiente, pero también simultáneamente.
En contraste, la entrada mediante multiplexado temporal utiliza un mismo
dispositivo para controlar diferentes funciones en diferentes puntos del
tiempo”. [69]
En interfaces tangibles que emplean varios objetos de interacción, la entrada es multiplexada
espacialmente. Diferentes objetos físicos representan diferentes funciones o diferentes datos.
Esto permite al diseñador del sistema tomar ventaja de la forma, tamaño y posición del
controlador físico de forma tal de aumentar la funcionalidad y reducir la complejidad de la
interacción. Adicionalmente permite un mapeo más persistente, en comparación con una GUI
tradicional que se basa en multiplexado temporal, donde cada clic del mouse podría resultar que
se ejecute una función diferente o un objeto diferente sea seleccionado.
Sin multiplexado espacial, los objetos de entrada son de carácter genérico y por lo tanto deben
tener forma y apariencia abstracta. Con mapeos estáticos y múltiples objetos de entrada, los
elementos tangibles de entrada (tokens) pueden ser expresivos y, además, puede proporcionar
affordances específicos para la funcionalidad que brindan acceso.
Múltiples objetos específicos permiten acciones paralelas, en contraste con una GUI con la cual un
usuario tiene que realizar una acción después de la otra de forma secuencial. Las acciones
paralelas aceleran potencialmente la tarea, y permiten una interacción sin necesidad de utilizar la
vista, ya que el resto de los objetos en el espacio de trabajo son suficientes para guiar las manos.
Fitzmaurice [69] señala que los objetos multiplexados espacialmente permiten aprovechar nuestra
memoria espacial (o “memoria muscular”). Por otra parte, en una GUI tradicional sólo puede
haber una selección activa a la vez y cualquier nueva selección deshace la anterior. Una TUI puede
eliminar muchas de las acciones de selección redundantes (elegir la función, hacer la acción,
seleccionar la siguiente función). Los estudios de usuarios han demostrado que la interacción con
multiplexado espacial es superior a la interacción mediante multiplexado temporal en términos
de rendimiento [69] y reduce el costo de adquirir dispositivos de entrada.
7.1.8. La especificidad permite iconicidad y affordance
El empleo de varios objetos de entrada (multiplexado espacial) significa que éstos no tienen por
qué ser abstractos y genéricos, sino que pueden tener un significado específico [65], dedicado en
forma y apariencia a una determinada función o dato digital. En una TUI, los tokens pueden tener
un mapeo persistente. De este modo, la apariencia de un objeto puede indicar directamente su
significado o función, así como la forma de interactuar con él, haciendo uso de su affordance
físico. Por otra parte, los objetos específicos pueden limitar la manipulación para permitir (o
86
invitar a realizar) sólo aquellas acciones que tengan resultados razonables [105]. Una alta
especificidad, por lo tanto, puede mejorar el mapeo entre las acciones y los efectos. Las interfaces
tangibles, a través de su propia naturaleza de ser físicas y, por tanto menos maleables y menos
mutables que una representación puramente digital controlada por computadora, tienden a ser
altamente específicas. Esto es tanto una fortaleza como una debilidad.
Fitzmaurice [69] hipotetizó que los dispositivos especializados se desempeñan mejor que los
dispositivos genéricos en configuraciones de espacio multiplexado y demostró experimentalmente
que los dispositivos especializados aceleran la adquisición de datos, comparados con el uso de un
dispositivo digital genérico. Un token podría ser liviano o pesado, generado diferentes affordances
para levantarlo y moverlo. Pequeños cambios en la forma a menudo afectan la manera en que los
usuarios manipulan los objetos. Por ejemplo, los diferentes tamaños de los objetos resultan en
diferentes tipos de agarre. Como regla general, los tokens cuadrados con un ancho de 5 a 10 cm
son fáciles de agarrar, un ancho de 5 cm facilita un agarre de precisión (pellizcando con el pulgar y
usando uno o dos dedos) y un ancho de más de 10 cm requiere un agarre de fuerza, utilizando
toda la mano. Además, el peso de un token puede añadir significado a la interacción, la pesadez
podría indicar un objeto más importante y valioso. Un propiedad central de los objetos físicos es
que proporcionan retroalimentación táctil, facilitando el control sin necesidad de utilizar la vista
cuando se realizan operaciones finas, tales como rotar objetos, o mover dos objetos en relación
con los demás [101].
7.1.9. Ventajas de las Interfaces Tangibles para niños
El uso de interfaces tradicionales es a menudo inadecuado para los usuarios más jóvenes y puede
ser un obstáculo para el aprendizaje interactivo. La exploración y la manipulación de objetos
físicos son componentes clave del mundo de los niños pequeños y de su aprendizaje. El poder
educativo de la tecnología digital para niños ha estado típicamente limitado por el hecho de que
los usuarios exploran y manipulan representaciones abstractas basadas en el monitor de dos
dimensiones, y no verdaderos objetos físicos. Los niños pequeños no pueden leer selecciones de
menú basados en texto o escribir sus respuestas mediante un teclado. Además, ellos a menudo
son incapaces de usar un mouse o cualquiera de los dispositivos apuntadores estándar (trackball,
touchpad, trackpoint, lápiz óptico, joystick). Esta inhabilidad se debe a una variedad de factores de
desarrollo, incluso la carencia de control motor fino necesario para usar dispositivos de señalando,
la carencia del entendimiento cognoscitivo de la correlación entre el uso del dispositivo
controlador y lo que pasa en pantalla, y la carencia de habilidades representativas abstractas
necesarias para entender representaciones típicas basadas en el monitor [106] [107] [108] [109] .
Hay fuertes motivos de desarrollo cognoscitivos de por qué la interacción con objetos físicos
apropiados para la tarea es el mejor ambiente de aprendizaje para niños. Piaget y psicólogos del
Desarrollo han enfatizado la importancia crítica de la manipulación de objetos físicos para el
desarrollo cognoscitivo de niños pequeños [99] [110]. Además, Vygotsky enfatizó la importancia
del juego en la facilitación del desarrollo del niño [111]. Los objetos usados en el juego de niños
pueden incluir algo que el niño encuentra práctico, como palos, rocas o cajas de cartón, pero a
87
menudo incluyen objetos desarrollados con la intención de ser juguetes, como fichas, muñecas,
coches en miniatura, bloques, etcétera [109].
Las tecnologías tangibles pueden beneficiar el aprendizaje de los niños de muchas maneras:
Las TUIs requieren de poco tiempo de aprendizaje Las TUIs son interfaces naturales que requieren poco esfuerzo cognoscitivo para aprender, por lo
tanto los niños pueden concentrarse más en la tarea, en lugar de en cómo usar la computadora o
un determinado software.
Las TUIs ofrecen al usuario una forma alternativa de interacción y control del ambiente computacional Las TUIs pueden ofrecer una variedad de interacciones, permitiendo que el usuario solucione
problemas con objetos físicos concretos y acción física cuando ellos fallan en resolver el mismo
problema con representaciones más abstractas y sintaxis compleja; por lo tanto, las TUIs pueden
brindar a los niños el control del ambiente computacional; ellos sentirán y poseerán el ambiente,
estarán activamente involucrados y no perderán su interés fácilmente.
Las TUIs soportan la actividad empírica (Prueba y error) Las TUIs brindan la presentación continua del objeto de interés. Utilizan acciones incrementales
rápidas y reversibles cuyo impacto sobre el objeto de interés son inmediatamente visibles.
Las TUIs soportan más de un usuario La ventaja de usar interfaces tangibles consiste en que ya no se está restringido a un solo usuario,
los niños pueden sentarse y colaborar con sus amigos, cara a cara, de un modo completamente
natural. Esto puede proveer a los niños una experiencia social. La investigación muestra que los
niños son más productivos cuando ellos cooperan, por lo tanto comparado con un niño aislado, un
niño trabajando en grupo puede ser capaz de hacer una tarea más eficazmente y beneficiarse aún
más de la experiencia
Desde el punto de vista de pedagógico y psicólogico, los tangibles son beneficiosos para aprender;
esto se debe a que: la acción física es importante en el aprendizaje, los objetos concretos son
importantes en el aprendizaje, los materiales físicos dan lugar a imágenes mentales que pueden
dirigir, guiar y acotar la futura solución del problema en ausencia de dichos materiales físicos, los
principiantes pueden abstraer relaciones simbólicas de una variedad de casos concretos y los
objetos físicos familiares para los niños son más fácilmente entendidos que sus entidades
simbólicas [112].
7.2. Limitaciones Varias de las aparentes limitaciones de la TUIs resultan del siguiente desafío:
"Estos sistemas requieren un cuidadoso equilibrio entre la expresión física
y gráfica para evitar el desorden físico y para aprovechar las ventajas de
las diferentes formas de representación. Este equilibrio entre las
88
representaciones físicas y digitales se presenta como uno de los retos más
grandes del diseño de TUIs". [71]
Si bien es importante tener en cuenta las limitaciones de las TUIs a la hora de diseñar aplicaciones
para dominios específicos, estas limitaciones podrían ser vistas como retos que deben abordar las
investigaciones futuras.
A continuación se discuten algunas de las limitaciones actuales de las TUIs.
7.2.1. Escalabilidad y riesgo de perder objetos físicos
Uno de los mayores desafíos de las TUIs es la escalabilidad. Aplicaciones exitosas para problemas
pequeños o conjuntos de datos acotados a menudo no se adaptan bien a problemas complejos
que involucran muchos parámetros y conjuntos grandes de datos. Para cualquier aplicación que
trate de proporcionar una representación tangible, esto será un problema debido a que las
representaciones más grandes ocupan más espacio.
El problema de la escalabilidad se puede rastrear a varias razones subyacentes. La primera sería el
espacio físico que ocupan los tokens. En el diseño de GUIs, a esto se lo referencia como "espacio
de pantalla". Con TUIs la pregunta análoga sería, ¿cuántas fichas se pueden colocar en una
superficie interactiva?. Si el tamaño de la superficie creciera, se volvería más difícil para un usuario
poder acceder y mover las fichas, ya que tendría que caminar a través de o volar sobre la
representación. Relacionado a esto está el problema del desorden físico [69]. Si la superficie ya
está llena con el número máximo de fichas, ya no quedará espacio para colocar y utilizar fichas
adicionales. Por otra parte, los objetos físicos deben ser almacenados en algún lugar, aunque no
estén en uso, lo que podría requerir de un gran armario, pudiéndose ocasionar la pérdida de las
mismas.
La escalabilidad también puede ser interpretada literalmente. Con un mapa digital se puede
acercar la imagen para obtener una visión a escala de un sub-área y alejar la imagen para ver el
mapa de la zona en relación con su entorno. Con un modelo físico, el tamaño de cada elemento es
fijo. El aumento del tamaño de un elemento requiere de la ampliación de todo lo demás y de su
separación, lo que esencialmente requeriría de la construcción de un nuevo modelo. Edge y
Blackwell [113] describen esto como voluminosidad. Un efecto secundario de la voluminosidad
física es que si uno quiere trabajar en dos problemas distintos al mismo tiempo, hay que limpiar
para hacer espacio. Las representaciones digitales se pueden simplemente guardar y volver a
abrir, no ocupan espacio. Los modelos físicos son difíciles de comparar entre sí, debido a que no se
pueden guardar y abrir fácilmente, como sus análogos digitales.
Después de haber construido un modelo de arquitectura en URP [21], uno puede decidir, por
ejemplo, añadir un edificio a la izquierda de la estructura. Dependiendo de cómo se ha llenado la
superficie interactiva, esto podría requerir mover todo el modelo existente a la derecha. Con un
sistema GUI, el usuario sería capaz de extender la superficie virtual o simplemente mover la vista.
La escalabilidad también contribuye a lo que Edge y Blackwell [113] definen como compromiso a
largo plazo. Para iniciar la construcción de un modelo, uno tiene que decidir, por ejemplo, el
89
tamaño de los objetos y seleccionar una ubicación para colocarlos; más tarde los cambios son
difíciles.
Bellotti y col. [114] señalan otro problema potencial relacionado con la escalabilidad. Las TUIs se
basan en la noción de acoplamiento directo, donde los objetos tangibles incorporan tanto los
medios de representación como los medios de manipulación de datos digitales [71]. Por lo tanto
las TUIs proporcionan una forma extrema de manipulación directa. Bellotti y col. [114] sostienen
que con las interfaces de manipulación directa se necesita un mayor esfuerzo para ejecutar
comandos complejos. La manipulación directa no tiene un concepto de variables genérica y/o
comodín, como las que proporcionan las interfaces de línea de comandos, que permiten hacer un
fácil y rápido reemplazar todo, y no soportan adecuadamente la manipulación de múltiples
objetos de forma conjunta.
7.2.2. Versatilidad y maleabilidad
Mientras que los objetos digitales son maleables, fáciles de crear, modificar, reproducir y
distribuir, los objetos físicos son rígidos y estáticos. El aspecto icónico y el uso de la forma física
para crear affordance suelen dar lugar a objetos concretos y especializados. Como los objetos
físicos no son mutables, el sistema no puede transformar a éstos en diferentes objetos o alterar
sus propiedades físicas (por ejemplo, cambiar su color), incluso si tal cambio podría ser apropiado.
La especificidad de los objetos, mientras favorece el aprendizaje, entra en conflicto con los
conceptos de abstracción y versatilidad. Otra cuestión relacionada con la versatilidad y la
maleabilidad es la dificultad para brindar soporte para un sistema automático de deshacer, una
función de historial, o una repetición de las acciones (véase [101]).
Teniendo en cuenta la versatilidad adicional, una GUI se puede utilizar para realizar una variedad
de tareas tales como escribir un documento, chatear con amigos, y reproducir música. Sin
embargo, la TUI está diseñada especialmente para facilitar un conjunto limitado de tareas.
Además, una GUI permite a los usuarios cambiar entre diferentes vistas o representaciones (por
ejemplo, entre un mapa y una imagen de satélite). Con una TUI el cambio es difícil, ya que la
representación tangible ha sido elegida. Mientras que esta limitación puede ser abordada
parcialmente a través de la proyección digital, hay casos en los que un punto de vista diferente
puede retener la topología, pero no la geometría espacial. Jacob et al. [115] afirman que los
diseñadores deben aspirar a crear una interfaz que esté tan basada en la realidad como sea
posible (basado en los conocimientos de los usuarios de habilidades del mundo real no digital). Sin
embargo, cuando el realismo de una interfaz disminuye su versatilidad, el diseñador debe hacer
un compromiso explícito entre el realismo y la versatilidad, sólo renunciando al realismo de una
interfaz a cambio de un valor agregado para el usuario.
7.2.3. Fatiga del usuario
Los efectos del tamaño y del peso de los objetos tangibles no deberían ser subestimados. El diseño
físico por lo tanto, no sólo debe considerar affordances en términos de las acciones que se invita a
realizar a través de la forma física del objeto, sino también de la ergonomía y del desgaste y
90
tensión generados a más largo plazo, producto de la actividad manual necesaria para realizar las
tareas.
Por ejemplo, los tokens tangibles tienen que ser fáciles de agarrar, levantar, y posicionar: Los
tokens de las TUIs son constantemente levantados y movidos como su principal modalidad de
interacción. Por ejemplo, un token con un ancho de 10 cm requiere un agarre potente con toda la
mano. La interacción mediante una TUI tiende a requerir de movimientos más amplios y
diferentes a los tradicionales de mouse y teclado (que tienen sus propios problemas, por ejemplo,
el síndrome del túnel carpiano). Tener que estirarse sobre una superficie en repetidas ocasiones
puede llegar a ser agotador luego de un tiempo, donde los pequeños movimientos del mouse
requerirían de menos esfuerzo. Además, el tamaño físico del usuario en relación con la superficie
de interacción determina su alcance. También debemos recordar que la interacción física no
siempre tiene que ser fácil y sin esfuerzo. Por el contrario, la gente disfruta de un desafío en los
juegos y la sensación de dominio experto de un instrumento musical.
91
PARTE III - DESARROLLO
EXPERIMENTAL
"La imaginación es más importante que el saber" - Albert Einstein
1. Introducción ….………………………………………………..……….. 92 2. Primer Prototipo …….……………………………………………..…. 93 2.1. Diseño ……………………………………………………………….. 93 2.2. Implementación – Introducción …………………………. 97 2.3. Elementos y herramientas utilizadas ………………….. 99 2.4. Diseño de clases e implementación del código ….. 104 2.5. Análisis de los resultados …………………………………… 112 3. Segundo Prototipo ……………………………………………………. 115
92
1. Introducción El proyecto consiste en desarrollar una aplicación para la creación de música mediante una
interfaz tangible basada en el conocimiento adquirido en la investigación presentada previamente.
El diseño propuesto tiene como objetivo poner de manifiesto los puntos fuertes de las TUIs y
aliviar los débiles, mediante la construcción basada en las fortalezas de los elementos tangibles y
facilitándose de las fortalezas de otras áreas relacionadas para el cumplimiento de cualidades que
no pueden alcanzarse por medio de las TUIs.
La idea del prototipo es que el usuario o grupo de usuarios puedan modificar en tiempo real,
mediante el uso de sus manos, las combinaciones y posiciones de ciertos tokens (fichas) sobre un
tablero en forma de matriz. Cada uno de estos tokens tendrá asociado digitalmente un sonido o
nota musical predeterminada perteneciente a algún instrumento musical. El sistema reproducirá
dicho sonido en un momento dado según la posición del token en el tablero. La modificación de la
disposición de las fichas sobre el tablero permitirá al usuario o grupo de usuarios “tocar” música
en tiempo real de forma intuitiva y colaborativa. De esto se desprende la posibilidad de ir creando
música de forma incremental, iniciando con un solo instrumento y sonido e ir agregando más
instrumentos y mayor complejidad. Básicamente, el prototipo se comportara como un
secuenciador tangible. (PARTE I - 4.9. Secuenciadores Tangibles)
El prototipo será implementado mediante tecnología de visión por computadora (PARTE I - 6.3.1.
¿Qué es la Visión por Computadora?) por razones que se explican más adelante. El sistema toma la
posición de los tokens mediante visión por computadora y reproduce el sonido asociado a esa
ficha. El prototipo está pensado para aprovechar las ventajas de las interfaces tangibles e
implementarse con herramientas y elementos de fácil disponibilidad.
Basándose en el conocimiento adquirido, se desarrolla y presenta una interfaz tangible de bajo
costo para la creación de música de forma intuitiva, incremental y colaborativa. Dicho sistema
caerá dentro de la categoría de secuenciador musical tangible, según las categorías de sistemas
tangibles musicales de Kaltenbrunner ( PARTE I - 4.7. Música y performance multimedia ).
Se desarrollaron dos prototipos. El primero, al cual se le analizaron sus principales limitaciones y
un segundo prototipo más evolucionado basado en el paradigma de Token and Constraints. (
PARTE I - 5.4. Token And Constraint )
El primer prototipo desarrollado se ubica dentro de la categoría de superficies interactivas según
la clasificación de Ulmer. (PARTE I - 5.3. Clasificación de las TUIs). El segundo prototipo se ubica
dentro de la categoría Token + Constraint según esta misma clasificación. El mismo es mucho
mejor que el primer prototipo ya que implementa un tablero con fichas encastrables lo que
permite aprovechar todas las ventajas adicionales del paradigma Token + Constraints (PARTE I -
5.5. Fortalezas del enfoque Token + Constraint).
93
El primer prototipo fue diseñado y codificado en conjunto con Octavio Portaluppi en el marco del
proyecto final de la materia “Interacción Humano Computara”. Se trabajó de forma grupal, con
Octavio, mediante distintas aplicaciones que facilitaron el trabajo colaborativo.
2. Primer Prototipo
2.1. Diseño
2.1.1. Propuesta
Analizados los antecedentes de sistemas musicales antes mencionados (PARTE I - 4.7. Música y
performance multimedia) se propuso desarrollar una interfaz tangible de bajo costo para la
creación de música, más específicamente un secuenciador musical tangible (PARTE I - 4.9.
Secuenciadores Tangibles). El mismo está orientado a niños a partir de los 6 años de edad, con el
objetivo de estimular sus sentidos e introducirlos en el mundo musical de una manera divertida,
sencilla e intuitiva. (PARTE I - 7.1.9. Ventajas de las Interfaces Tangibles para niños)
La mayoría de las interfaces tangibles estudiadas requieren de un hardware especial,
generalmente de alto costo y difícil de configurar, siendo esto una desventaja importante si se
desea que la interfaz sea utilizada por un público variado sin conocimientos técnicos. Esto mitivó
el desarrollo de una interfaz que utilice elementos económicos, de fácil acceso y que a su vez sea
fácil de armar, configurar y operar.
La mayoría de las interfaces musicales analizadas están apuntadas a un público adulto, con cierto
conocimiento técnico y musical. Se vio como una oportunidad apuntar el diseño de la interfaz
tangible a un público infantil a efectos de estimular sus sentidos. La intención principal fue que la
herramienta permitiera a los niños interactuar y jugar con formas, colores, y sonidos, al mismo
tiempo que desarrollaran de forma sencilla e intuitiva su conocimiento musical, incorporando
conceptos de ritmo, notas, así como el sonido que identifica a cada instrumento.
La meta fue que el sistema permitiera crear música mediante la ubicación de distintos tokens o
fichas en una cierta posición de un tablero (matriz), asociando a cada ficha un sonido particular
que sería reproducido en un momento dado, determinado por su posición calculada a través de un
sistema de visión por computadora.
El objetivo fue que el usuario pueda modificar las combinaciones y posiciones de los tokens en
tiempo real, logrando “tocar” música en tiempo real. De esto se desprende la posibilidad de ir
creando música de forma incremental, iniciando con un solo instrumento y sonido e ir agregando
más instrumentos y mayor complejidad.
2.1.2. Concepto del sistema y modo de interacción
A continuación se detalla la idea conceptual del prototipo, es decir, se explica de forma abstracta,
independiente de la implementación, la forma de interactuar con el sistema de forma de utilizarlo
para crear música.
94
El sistema cuenta, básicamente, con un tablero en forma de matriz, es decir marcado con filas y
columnas, y un conjunto de fichas o tokens. Estas últimas se dividen en dos conjuntos, un primer
conjunto que indican instrumentos, que se denominaran “Instru-token” y otro conjunto que
indican notas musicales, que se denominaran “Noti-token”
El tablero tiene la siguiente forma:
Figura 39 – Esquema del tablero.
Básicamente, es una matriz de 6 filas por 9 columnas, de las cuales se distingue la primera
columna que cumple una función distinta al resto.
Cada fila del tablero representa un instrumento definido temporalmente por el “Instru-token”
colocado en su primera celda (la celda gris que define que instrumento se modelará en esa fila).
Cada columna representa un instante de tiempo dentro de un ciclo fijo. Éste se repite
indefinidamente a una velocidad determinada. Entonces, por ejemplo, para un ciclo de 4 segundos
y 8 instantes de tiempo (las 8 columnas reservadas para “Noti-tokens”) se tiene que cada etapa
del ciclo se ejecutará una después de otra cada 0.5 segundos. La música se genera posicionando,
primero, el “Instru-token” que identifica al instrumento en la primera posición de la fila (celda gris
en Figura 39 – Esquema del tablero.), y luego ubicando “Noti-tokens” deseados en las celdas de la
misma fila.
Se eligieron los instrumentos occidentales más conocidos: guitarra eléctrica, piano, bajo y batería,
con el propósito de que resulten familiares. Se optó por incluir varios instrumentos, de forma de
poder lograr una banda musical completa y funcional. En el caso del bajo se utilizaron notas
musicales asociadas a cada uno de los “Noti-tokens”, mientras que para el piano y la guitarra se
emplearon acordes a fin de generar un sonido más completo, al mismo tiempo que resultasen más
apropiadas para crear canciones simples. En el caso de la batería los diferentes “Noti-tokens”
identifican a cada uno de los cuerpos de la misma.
Ambos, los “Instru-tokens” y los “Noti-tokens” cuentan con varias copias de cada uno, es decir,
existen, por ejemplo, varios “Instru-token” guitarras, varios “Instru-token” piano con el objetivo de
poder modelar varias guitarras, o varios pianos a la vez, en la misma canción. Obviamente se
95
cuentan con inclusive mayor cantidad de copias de los distintos “Noti-tokens” de forma que sean
suficientes para modelar todas las posibles combinaciones de sonidos, aun en los casos que se
utilicen todas las filas, o se desee utilizar la misma nota al mismo tiempo, o a lo largo del mismo
instrumento.
Los “Instru-tokens” que identifican al instrumento que podrán ser colocadas en la primera
columna son, en términos de modelado:
Batería Guitarra Bajo Piano Figura 40 – Los cuatro “Instru-tokens”.
Los “Noti-tokens” que identifican las variantes de sonido de un instrumento son siete.
Do Re Mi Fa Sol La Si
Figura 41 – Los siete “Noti-tokens” de la Guitarra.
La decisión sobre qué figura representará cuál instrumento fue ad-hoc.
En el caso de la guitarra, los “Noti-tokens” representan acordes. Para el caso de este instrumento
la letra que contienen dentro de la figura es el respectivo acorde en notación americana. No se
incluyen las notas o acordes sostenidos para reducir la complejidad de implementación ya que
esto aumentaría la cantidad de notas y no brindaría beneficios importantes en términos de
investigación y desarrollo de la interfaz.
En el caso de la Guitarra y el Piano cada “Noti-token” representa uno de los 7 acordes indicados en
Figura 41 – Los siete “Noti-tokens” de la Guitarra. En el caso del Bajo, cada “Noti-token”
representa una nota simple del instrumento. En el caso de la Batería cada “Noti-token” representa
un sonido de cada uno de los cuerpos del instrumento, es decir, el “Noti-token” C representa el Hi-
Hat, el D el Tom de piso, el E el Platillo, el F y el G los Tomtom, el A el Bombo y el B el Redoblante.
C D E
E
F G A B
96
Figura 42 – Los distintos cuerpos de una batería: 1. Platillo, 2. Tom de Piso, 3. Tomtoms, 4. Bombo, 5. Redoblante y 6. Hi-hat
2.1.3. Caso de uso
A continuación se describe un caso de uso del sistema con la idea de ejemplificar el modo de
interacción. El objetivo de este caso de uso es generar un ritmo musical con batería, guitarra y
bajo.
Generamos la base musical de la batería:
Utilizamos el “Instru-token” en forma de círculo en la primera posición de la primera fila para
identificar a la batería. Utilizaremos 2 filas. La primera fila para el bombo (A) y la segunda para el
redoblante (B). Para el bombo establecemos que se dispare el sonido en el instante inicial y a
mitad de ciclo. Para el redoblante establecemos que se dispare únicamente a mitad de ciclo.
Generamos una base de guitarra y bajo:
Ponemos un “Instru-token” en forma de triangulo en la primera posición de la tercer fila para
identificar la guitarra. Utilizaremos una única fila, la cual tiene los “Noti-tokens” que indican Do
(C), Mi (E), Sol (G), Si (B). Tales acordes los ubicamos al comienzo, a ¼ de ciclo, ½ de ciclo y ¾ de
ciclo.
Ponemos un “Instru-token” cuadrado en la primer posición de la cuarta fila para identificar el bajo
y luego los “Noti-tokens” correspondientes en las posiciones indicadas del ciclo.
Gráficamente, el tablero con los tokens quedaría de la siguiente manera:
C E G B
B
A A
97
Figura 43 – Caso de uso del sistema. Un ritmo musical con batería, guitarra y bajo.
2.2. Implementación - Introducción Luego de analizadas las distintas tecnologías de implementación (PARTE I - 6. Tecnologías de
implementación para TUIs) y estudiado la implementación de varios sistemas (PARTE I - 4.7.
Música y performance multimedia), se decidió desarrollar un prototipo mediante visión por
computadora (PARTE I - 6.3. Visión por Computadora). Esto se debió principalmente a los costos
asociados y a la disponibilidad de las distintas herramientas y hardware necesarios para la
implementación. La visión por computadora se pudo implementar mediante el simple uso de una
cámara web estándar y una librería de visión de computadora gratuita. El resto de las tecnologías
de implementación requieren de hardware específico, el cual además de tener costos mayores
asociados, es difícil de conseguir en nuestro país y muchas veces no se comercializa en negocios
locales por lo que hay que adquirirlo en el exterior a través de Internet, con la desventaja de los
gastos adicionales de fletes e impuestos de importación. Adicionalmente, tanto el autor como
Octavio Portaluppi cuentan con mayor experiencia en programación de alto nivel que en
programación de bajo nivel y manejo hardware, conocimientos necesarios para implementar el
prototipo mediante RFID o microcontroladores y sensores. Debido a estas razones se decide
implementar el prototipo mediante visión por computadora.
C E G B
98
Figura 44 – Los elementos del prototipo: 1. La computadora que corre el software, muestra el estado del sistema mediante una GUI y reproduce los sonidos. 2. El tablero con algunas tokens colocados. 3. Las fichas o tokens de
cartón. 4. El sistema de soporte conformado por el trípode y la varilla de madera. 5. La cámara web que captura las imágenes.
El sistema desarrollado está compuesto por una parte de software y una de hardware. El software
se encarga de procesar las imágenes capturadas del tablero a través de la cámara web, de
procesar la información, de reproducir los sonidos adecuados y de mostrar el estado del sistema a
través de la GUI. La GUI permite visualizar el estado del sistema a través de un tablero virtual
mostrado por pantalla, permite iniciar y detener el sistema, como también modificar la frecuencia
de ejecución de los sonidos.
Básicamente el prototipo opera de la siguiente manera: una vez capturada la imagen del tablero,
el software la procesa y pasa a identificar los instrumentos, las notas y sus posiciones, cargando
toda esta información en una estructura de datos. Paralelamente, el programa procede a recorrer
esta estructura de datos, reproduciendo los sonidos respectivos, al ritmo establecido. La última
1
2
3 4
5
99
tarea que realiza es la de actualizar la interfaz gráfica, esto es, la versión digital del tablero físico
que se muestra por pantalla.
El hardware consiste en un tablero de papel en forma de matriz con filas y columnas, un conjunto
de fichas de cartón que representan los instrumentos, “Intru-tokens”, y otro conjunto de fichas de
cartón que representan las notas o acordes, “Not-tokens”. Además se cuenta con una cámara
web, y un sistema de soporte para la misma, el cual permite situar la cámara a una altura
determinada sobre el tablero.
2.3. Elementos y herramientas utilizadas A continuación se presentan y describen los elementos de hardware, cámara web, sistema de
soporte, tablero y fichas, y los elementos de software, esto es lenguaje de programación, librerías,
IDE, y demás herramientas auxiliares utilizados para implementar el sistema.
El prototipo se construyó teniendo como principal objetivo la utilización de componentes
económicos y de fácil acceso.
2.3.1. Hardware
Las pruebas se hicieron sobre una Notebook corriendo Windows Vista con un Microprocesador
Intel Core 2 Duo P8600 a 2.4Ghz y 4 GB de RAM.
Además de la computadora se utilizaron otros componentes de hardware, los cuales son descritos
a continuación.
Tablero y fichas
El tablero consiste en una grilla de papel impresa de 60cm x 30cm (aproximadamente 3 hojas A4
colocadas de forma vertical una al lado de la otra) que luego fue pegada sobre una superficie de
madera para evitar que se doble y por consiguiente que se deforme la imagen capturada. La grilla
fue impresa en color gris tenue, lo que permite que el usuario la distinga para posicionar
correctamente las fichas, y que a su vez sea imperceptible para la cámara, reduciendo el ruido de
la imagen capturada, simplificando así su posterior procesamiento. El objetivo de esta grilla
impresa en color gris es facilitar a los usuarios la ubicación correcta de los tokens sobre el tablero.
Tabla 1 – Arriba los “Noti-token” físicos de cartón utilizados sobre el tablero. Abajo, su representación mediante la
interfaz gráfica.
Se diseñaron fichas con formas tales que sean fáciles de interpretar por el usuario y a su vez
robustas y eficientes para que el sistema las pueda identificar correctamente. Las figuras fueron
100
impresas en blanco y negro en papel mediante una impresora láser y luego adheridas a cada ficha
de cartón. A las mismas se le agregaron números y letras para facilitar su detección.
Piano Guitarra Batería Bajo
Tabla 2 – Arriba los “Instru-tokens” físicos de cartón utilizados sobre el tablero. Abajo su representación mediante la interfaz gráfica.
Se utilizo un papel opaco para las fichas y el tablero con el objetivo de reducir los reflejos
ocasionados por la iluminación, y de esta forma minimizar el ruido de las imágenes capturadas por
la cámara.
Cámara
Se utilizó una cámara web Genius iSlim 1320 de 1.3 Mega Pixeles [116] para asegurar una buena
calidad de las imágenes capturadas. La cámara cuenta con objetivo Multi-layer y sensor CMOS que
proporcionan una gran calidad de imagen y captura de video de 640 x 480 a 30 cuadros por
segundo y de 1280 x 1024 a 15 cuadros por segundo. La misma es Plug and Play mediante
conexión USB por lo que no necesita driver. El precio de la misma es aproximadamente de U$D
30.13
Inicialmente se realizaron pruebas con otras cámaras VGA (640 x 480 con 0.3 Mega Pixeles); no
obstante, la calidad de las imágenes no era la suficiente para su posterior procesamiento. Otras
cámaras probadas no fueron reconocidas por la librería de visión por computadora elegida, por lo
que fueron descartadas.
Figura 45 – Genius iSlim 1320
13
Precio de referencia obtenido en Mayo del 2012 en el sitio Argentino de compras online Mercado Libre: http://listado.mercadolibre.com.ar/Genius-iSlim-1320
101
Sistema de soporte
Se diseñó un sistema de soporte para poder posicionar la cámara sobre el tablero a cierta altura,
de forma de capturar las imágenes sin deformación perspectiva. Para esto se utilizó un trípode
fotográfico y una varilla de madera, la cual se atornilló en un extremo del trípode, y en el otro se
colocó la cámara web. Este sistema brindó buena estabilidad y movilidad, al mismo tiempo que
permitió ajustar la cámara con facilidad. También permite colocar la cámara a una altura
suficientemente alta como para no entorpecer al usuario cuando interactúa con el tablero.
Figura 46 – Soporte para la cámara construido mediante el
uso de un trípode de fotografía y una varilla de madera.
Figura 47 – Genius iSlim 1320 montada sobre el
soporte de madera mediante un tornillo, una tuerca y arandelas.
Iluminación
Se debe utilizar una iluminación lo mas pareja posible, de forma que todas las aéreas de la
superficie del tablero reciban la misma intensidad lumínica. La luz no debe ser ni muy tenue, ya
que la cámara no podrá capturar imágenes nítidas, ni muy fuerte, ya que podría producir reflejos
indeseados en el tablero y las fichas.
La iluminación debe ser uniforme para evitar variaciones de tonalidad en las distintas aéreas de la
superficie del tablero. Si la luz es más fuerte en un sector, los tonos de grises serán distintos a los
tonos de grises de otros sectores que reciben menor intensidad lumínica. Esto produce problemas
a la hora de procesar la imagen capturada.
102
2.3.2. Software
El software se diseñó utilizando UML y se implementó mediante el paradigma de programación
orientada a objetos, lo que permitió un modelado más natural e intuitivo. Como resultado, la
implementación y codificación del sistema se simplificó de gran manera.
En este sentido, se optó por utilizar el lenguaje de programación C# dado que es orientado a
objetos y provee herramientas que facilitan la codificación.
El sistema se desarrolló utilizando el IDE Visual Studio 2010 de Microsoft. El mismo facilitó el
proceso de codificación y debugging, así como también brindó soporte para el trabajo colaborativo
y el control de versiones del código fuente mediante Visual Studio Team Explorer para la
plataforma Visual Studio Team Foundation Server 2010.
Una de las principales razones de la elección del lenguaje de programación C#, es que, además de
brindar soporte para la orientación a objetos, los autores contaban con experiencia previa en
dicho lenguaje y en JAVA, ambos con sintaxis similar. Dado que la librería de visión por
computadora elegida, OpenCV, sólo estaba disponible para ser utilizada con los lenguajes C y C++,
se utilizó un wrapper de esta librería para C#, llamado Emgu CV [117] que también es Open
Source.
Otra de las razones por lo que se eligió Visual Studio para desarrollar la aplicación es que contaba
con la herramienta para trabajo colaborativo y control de versiones llamada Team Foundation
Server 2010 lo que permitió hacer el desarrollo del código de forma grupal mucho más eficiente.
Para esto se cargó todo el proyecto al servicio de hosting de código gratuito de Microsoft llamado
CodePlex [118]. De esta forma el código fue trabajado de forma conjunta y paralela de una forma
segura y eficiente. Esto agilizó el proceso de desarrollo de manera notable.
A continuación se describen las librerías utilizadas por la aplicación.
Reconocimiento de Imágenes – Emgu CV [117]
Teniendo presente la importancia del reconocimiento de imágenes, fue importante utilizar una
herramienta que facilitara el trabajo y lo hiciera de forma eficiente. Luego de analizar las
alternativas disponibles, se decidió utilizar la librería OpenCV. Esta elección se fundamentó en la
cantidad de documentación de calidad, ejemplos disponibles en la red, facilidad de uso y que su
utilización académica y comercial es gratuita.
Asimismo, habiendo escogido el lenguaje de programación C#, se presentó la necesidad de
disponer de la librería OpenCV para su uso en .Net. por lo que se utilizó un wrapper de OpenCV
denominado Emgu CV (versión 2.2.1.1150) el cual es Open Source, está desarrollado
completamente en C# y es multiplataforma.
Los archivos de dicha librería son:
Emgu.CV.dll
Emgu.CV.UI.dll
103
Emgu.Util.dll
Metronómo - C# MIDI Toolkit [119]
Para emular un metrónomo que manejara la frecuencia de reproducción de los sonidos, se decidió
utilizar una librería específica destinada al control de entrada-salida MIDI denominada “C# MIDI
Toolkit” (versión 5.0.0.0) desarrollada por Leslie Sanford bajo licencia MIT. Cabe destacar que
haciendo uso del control de tiempo nativo que provee C# (timer), no se lograron buenos
resultados, ya que había demoras en la ejecución de los eventos, lo que producía que se altere la
reproducción de los sonidos y se pierda el ritmo.
El archivo de la librería es: Sanford.Multimedia.Midi.dll
Sonido – Microsoft DirectX [120]
Finalmente, para la reproducción de audio se decidió utilizar la librería “DirectX” de Microsoft, más
específicamente Microsoft.DirectX.AudioVideoPlayback (versión 1.0.2902.0), ya que ofrecía un
desempeño aceptable para nuestras necesidades. La misma permite que los sonidos se ejecuten
de forma simultánea. Es decir, permite modelar por ejemplo un acorde de la guitarra en
simultáneo con un sonido de la batería, u otro instrumento.
El archivo de la librería es: Microsoft.DirectX.AudioVideoPlayback.dll
2.4. Diseño de clases e implementación del código Básicamente, el funcionamiento que se desea modelar e implementar es el siguiente:
La aplicación detectará, a través de la cámara web, los tokens colocados sobre el tablero,
identificando su tipo y posición. Procesará la información y actualizará una estructura que modele
el tablero con sus tokens. Luego irá barriendo dicha estructura columna a columna según la
frecuencia o velocidad especificada por el usuario. A medida que barre las columnas, la aplicación
habrá detectado qué instrumento se asocia a cada fila y ejecutará el sonido asociado al token
existente en esa posición.
El código completo del sistema se encuentra en PARTE V - Anexo Código. Adicionalmente, el
mismo se encuentra disponible online para su descarga, ver 2.4.5. Descarga del proyecto.
2.4.1. Diseño UML
El programa fue, previo a su codificación, diseñado, discutido y modelado de forma de obtener los
mayores beneficios en términos de claridad, eficiencia y flexibilidad. Como resultado de tales
discusiones se generó el siguiente diagrama UML de clases; para diseñarlo se utilizó el software de
modelado Enterprise Architect de Sparx Systems.
104
Figura 48 – Diagrama UML de clases.
105
El modelado y diseño en UML se realizó inicialmente en español, luego se codificó en inglés con el
objetivo de que el código pueda ser comprendido por gente que hable otros idiomas. Por lo tanto
los distintos nombres de clases, métodos y atributos del diagrama UML se corresponden con sus
análogos en inglés en el código del programa.
Existen algunos cambios entre lo modelado inicialmente en la etapa de diseño, plasmado en el
diagrama UML, y lo implementado mediante C# y el uso de las librerías en la etapa de codificación.
Por ejemplo, mediante el uso de la librería para el manejo de sonido, DirectX, no fue necesario
crear una clase propia Sonido.
2.4.2. Principales clases
A continuación se describen brevemente las principales clases del sistema. Para una mirada
completa del código de cada una referirse a PARTE V - Anexo Código.
Instrumento (Instrument.cs)
Esta clase se encarga de representar un instrumento. El mismo se modela como un arreglo de
siete sonidos. La clase cuenta con un constructor que recibe por parámetro un preset que permite
crear automáticamente uno de los cuatro instrumentos antes mencionados, guitarra, bajo, batería
o piano, mediante la carga de sonidos predeterminados para cada instrumento a partir de archivos
de audio.
La clase cuenta con un método utilizado para reproducir un sonido dado del instrumento, el cual
recibe como parámetro una de las siete notas posibles.
Ventana (MainWindow.cs)
Esta clase se encarga de manejar la GUI del sistema. Contiene los event handlers de los distintos
botones de la interfaz. El atributo más importante que tiene es un objeto privado de tipo
MusicProcessor llamado musicProcessor, el cual será el corazón del sistema. Los dos métodos
públicos principales son para actualizar el estado del tablero gráfico, es decir, para actualizar la
representación gráfica de los “Instru-tokens” que aparecen en la primera columna, y los “Noti-
tokens” que aparecen en el resto del tablero; éstos son UpdateInstruments(…) y UpdateNotes(…)
respectivamente.
Un objeto de este tipo, MainWindow, es creado al inicio de la ejecución por el objeto inicial del
programa de tipo Program.
Tablero (Board.cs)
Es una clase abstracta que debe ser implementada por alguna versión concreta de tablero. El
objetivo de esta decisión de diseño es independizar la estructura que modela el tablero del modo
en que se cargan los datos en el mismo. La clase tablero implementa la estructura que modela al
tablero junto a todos los métodos necesarios para facilitar el manejo del mismo, salvo por dos
métodos que son abstractos. El más importante de estos es Update() y debe ser implementado
por la clase que quiera implementar la carga de datos al tablero, en nuestro caso la clase
BoardFromCam. Por ejemplo, si desearíamos cambiar el modo de carga del tablero, mediante
106
sensores o mediante una interfaz gráfica, lo único que deberíamos hacer es heredar la clase Board
y redefinir el método Update() de la forma más conveniente según nuestro tipo de interfaz. Los
métodos públicos de la clase Board están pensados para facilitar el manejo de la estructura que
modela el tablero.
Por lo tanto se tiene una aplicación que es independiente y transparente del sistema utilizado para
detectar los tokens físicos. Si en algún momento se deseara cambiar la tecnología de
implementación por sensores, por ejemplo, lo único que habría que hacer es heredar la clase
Board e implementar el método Update().
La estructura que guarda la información del tablero es el atributo protegido myBoard, que es un
arreglo de filas, donde cada fila está modelada con un atributo de tipo instrumento y un arreglo de
ocho componentes. El tamaño del tablero se define mediante el constructor.
TableroCam (BoardFromCam.cs)
Esta es una de las clases más importantes del sistema. La misma implementa todo lo relacionado a
la captura de las imágenes a través de la cámara, el procesamiento de las imágenes, y la
conversión de las mismas en información útil que se volcará en el tablero virtual del sistema.
Implementa la clase abstracta Board a través de la implementación del método Update(). La clase
BoardFromCam implementa la carga de los tokens al tablero mediante la detección de los mismos
a través de visión por computadora. Para dicha tarea se vale de varios métodos privados y de la
librería Emgu CV descripta previamente.
El proceso de detección de los tokens mediantes visión por computadora realizado por esta clase
será descrito en detalle en la siguiente sección.
Partida (MusicProcessor.cs)
Esta es la clase principal del sistema, el corazón del mismo. Se encarga de crear la estructura que
modela y contiene los distintos instrumentos con sus respectivos sonidos, de crear el objeto que
representa y carga el tablero mediante la cámara web, de pedirle al mismo que actualice el
tablero, de controlar el ritmo de la ejecución de los sonidos, y de ordenarle al objeto que se
encarga de la GUI (MainWindow) de que actualice la pantalla según los datos del tablero.
Esta clase utiliza un objeto metrónomo, el cual irá marcando el ritmo de la ejecución de los
sonidos, de la actualización de la pantalla, y de la captura de información mediante la cámara. Éste
es un objeto de tipo MidiInternalClock proveniente de la librería C# MIDI Toolkit.
Cada vez que el metrónomo haga tictac, el método metronome_Tick(…) se ejecutará. Este método
irá recorriendo la estructura que modela el tablero, avanzará una columna cada vez que se ejecute
y realizará ciertas tareas en cada ocasión. Arrancará, al inicio del programa, por la primera
columna e irá avanzando, guardando el número de columna actual. El mismo recorrerá la columna
actual del tablero y ejecutará los sonidos indicados en esa columna. Luego, en el caso que la
columna actual sea la quinta, creará un hilo que ejecutará el método Update() del objeto board de
tipo BoardFromCam, es decir le pedirá al objeto board que actualice la estructura del tablero
107
mediante sus métodos de visión por computadora. Si la columna actual es la sexta, le pedirá al
objeto mainWindow que actualice la interfaz gráfica. Por último, si la columna es la última del
tablero, asignará a la columna actual la primera para volver a comenzar a ciclar por las mismas al
ritmo que marque el metrónomo.
2.4.3. Reconocimiento de Tokens
El reconocimiento de imágenes es parte fundamental de la aplicación; ésta utiliza visión por
computadora para reconocer los distintos tokens físicos distribuidos sobre el tablero.
El sistema se basa en el reconocimiento de imágenes mediante la comparación de la imagen
obtenida a través de la cámara con una plantilla de imágenes previamente almacenadas. Éstas son
imágenes de cada uno de los distintos tokens tomadas y almacenadas previamente. Si la
comparación con alguna de las imágenes de la plantilla arroja un resultado mayor a un dado valor
establecido, entonces la imagen representa uno de los tokens del sistema. El método utilizado
para dicha comparación es provisto por la librería Emgu CV y se llama MatchTemplate(…).
En la siguiente sección se explica en detalle cómo funciona el proceso de detección mediante el
uso de la función MatchTemplate(…).
Previo a la comparación, la imagen del tablero es procesada. La misma es convertida a escala de
grises, para optimizar su procesamiento, y luego recortada, de forma de que sólo quede la imagen
del tablero, y la misma quede de un tamaño pre establecido. Sabiendo las dimensiones de la
imagen del tablero, el tamaño de cada celda en la misma, y la cantidad de filas y columnas, se
define una región de interés (ROI) del tamaño de una celda, la misma se irá moviendo a través de
la imagen del tablero, marcando cada una de las celdas, comenzando en la fila 0 y columna 0,
recorriendo todas las celdas de esa fila, y luego comenzando a hacer lo mismo, pero en la
siguiente fila. Cada vez que se mueve, dicha región de interés marcará justo una de las celdas del
tablero en la imagen tomada, que será comparada con las imágenes de la plantilla mediante el
método MatchTemplate(…) de la forma que se explicó previamente. De esta manera, además de
saber si se detectó algún token, se puede establecer fácilmente en qué celda se encuentra el
mismo.
Lo que se compara no son las formas de las fichas, sino los números y las letras que contienen.
Esto facilita la comparación y aumenta la robustez de la detección de las figuras. Por lo tanto, las
imágenes que se almacenan como plantillas no son los tokens en su totalidad, sino un fondo
cuadrado negro con el número o letra en blanco, según corresponda.
La clase que se encarga de esta tarea es la clase BoradFromCam, la cual hereda de la clase Board e
importa y hace uso de la librería de visión por computadora Emgu CV.
En términos generales, el reconocimiento de los tokens se realiza de la siguiente manera:
1. Inicialización (en la creación del objeto BoardFromCam):
1.1. Se define la cámara que será utilizada para tomar las imágenes y se define el tamaño de
las mismas.
108
1.2. Se crea un hilo que se encarga de mantener a la cámara tomando imágenes
constantemente, de forma tal que al solicitarle una imagen, la misma ya haya sido
tomada mientras el programa hacea otra cosa. Se inicia dicho hilo de ejecución.
1.3. Se cargan las imágenes tomadas previamente de los distintos tokens desde archivos en
forma de plantilla de comparación. Las mismas se cargan en una estructura para su
rápido recorrido.
2. Detección (cada vez que MusicProcessor solicite que se haga un Update() del tablero):
2.1. Se toma la última imagen que fue capturada por el hilo de ejecución mencionado en 1.2.
2.2. Se recorta dicha imagen a dimensiones preestablecidas y se convierte a escala de grises.
2.3. Se realiza la detección de los “Instru-tokens”
2.3.1. Según la cantidad de filas y columnas, y el tamaño de la imagen, se define un
tamaño de paso para avanzar el ROI.
2.3.2. Se selecciona la primera imagen plantilla de “Instru-tokens” desde la estructura de
datos que la contiene.
2.3.3. Se define un ROI del tamaño de una celda. El mismo se posiciona en la primera celda
de la primera columna.
2.3.4. Se compara la imagen plantilla con la imagen definida por el ROI. Para esto se utiliza
el método MatchTemplate(…). Luego se analizan los resultados de dicha operación.
Si dicho resultado es mayor a un valor establecido, se considera que hubo una
coincidencia exitosa, y dicho “Instru-token” se encuentra en esa celda, por lo que se
actualiza la estructura que modela el tablero con dicho token en esa celda.
2.3.5. A continuación se desplaza el ROI una celda hacia abajo y se vuelve a realizar la
comparación.
2.3.6. Cuando se terminan de recorrer todas las celdas de la primera columna, se pasa a
cargar la imagen de comparación del siguiente “Instru-token” y se vuelve a comenzar
la comparación desde la primera celda de la columna. Esto continúa hasta que se
hayam comparado las cuatro imágenes de plantilla de los “Instru-tokens”.
2.4. Se realiza la detección de los “Noti-tokens”. El método es análogo al de la detección de
los “Instru-tokens”, la diferencia es que se utiliza otro conjunto de imágenes de
comparación, las imágenes de los siete “Noti-tokens” y el ROI se desplaza a lo largo de las
filas, omitiendo la primera columna. En otras palabras, se recorre solo la sección donde
puede haber “Noti-tokens” comparando cada celda con la plantilla de imágenes
almacenada.
Template Matching (Coincidencia de plantillas)
A continuación se describe cómo funciona la función de OpenCV matchTemplate, utilizada en el
prototipo para buscar coincidencias entre una imagen de muestra o plantilla y una imagen de
entrada. También se describe la función de OpenCV minMaxLoc utilizada para encontrar el valor
máximo y mínimo (así como sus posiciones) en una matriz dada, en este caso generada como
resultado de la función matchTemplate.
109
Template Matching (Coincidencia de plantillas) es una técnica para encontrar áreas de una imagen
que coinciden (son similares) con una imagen de muestra (plantilla).
Se necesitan dos componentes principales:
1. La imagen fuente (I): La imagen en la que se espera encontrar una coincidencia con la
imagen de muestra (plantilla).
2. La imagen de muestra (plantilla) (T): La imagen de muestra que se puede comparar con la
imagen fuente.
El objetivo es la detección de la zona de mayor coincidencia:
Figura 49 – Izq.: Imagen fuente. Centro: Imagen de muestra (plantilla. Der.: la imagen de muestra el localizada en la imagen fuente.
Para identificar el área de coincidente, se debe comparar la imagen de muestra (plantilla) con
imagen fuente, deslizándola:
Figura 50 – La imagen de muestra se desliza, pixel a pixel, a través de la imagen fuente, comparándolas en cada ocasión.
Deslizar, se refiere a mover la imagen de muestra (plantilla) un pixel a la vez (de izquierda a
derecha, de arriba a abajo). En cada ubicación, se calcula un indicador que representa que tan
"buena" o "mala" es la coincidencia en ese lugar (o que tan similar es la imagen de muestra
(plantilla) con esa área en particular de la imagen original).
110
Para cada ubicación de T sobre I se almacena la métrica en la matriz de resultados R. Cada
ubicación (x, y) en R contiene la métrica de coincidencia:
Figura 51 – La matriz resultante formada por los valores arrojados por la comparación de I y T en cada punto. Los valores más claros representan puntos de mayor coincidencia.
La imagen de arriba es el resultado R de deslizar la imagen de muestra (plantilla) con una métrica
TM_CCORR_NORMED. Los lugares más brillantes indican las coincidencias más elevadas. Como se
puede ver, la posición marcada por el círculo rojo es probablemente una de las de mayor valor,
por lo que su ubicación (el rectángulo formado por ese punto como una esquina y el ancho y
altura igual a la imagen de muestra (plantilla)) se considera como acierto.
La métrica de comparación TM_CCORR_NORMED es calculada, en la función matchTemplate,
mediante la siguiente fórmula:
Existen otras 5 métricas de comparación disponibles en OpenCV, que pueden indicarse por
parámetro de la función matchTemplate.
Finalmente, en la práctica, se utiliza la función minMaxLoc para localizar el valor más alto (o bajo,
dependiendo del tipo de método de coincidencia utilizado) en la matriz R.
Una de las limitaciones de este método es que la imagen de muestra (plantilla) debe aparecer
dentro de la imagen fuente en el mismo tamaño, y sin ninguna rotación.
Para una excelente y detallada explicación teórica y práctica de cómo funciona la técnica de
reconocimiento mediante Template Matching en OpenCV referirse a [121]. En la misma se explica
qué es, cómo funciona y se presenta código de ejemplo.
111
2.4.4. GUI
El sistema cuenta con una interfaz gráfica de usuario que permite visualizar el estado del tablero.
Dicha interfaz permite modificar la velocidad con la que se ejecutan los sonidos, así también como
iniciar y detener la ejecución del sistema.
Figura 52 – Interfaz gráfica de usuario de la aplicación.
Para el diseño del mismo se tuvo como objetivo principal la simpleza de la interfaz. La misma es
una representación virtual del tablero, en el cual se indica en tiempo real los tokens que son
detectados por el sistema y un ícono en forma de mano en la parte superior indica la columna
cuyos sonidos se reproducen en ese momento. En la parte inferior cuenta con dos controles en
forma de botones, uno controla el inicio y la detención del sistema y otro, ubicado a la derecha,
permite modificar la velocidad con la que se ejecutarán los sonidos, es decir la frecuencia de
reproducción.
2.4.5. Descarga del proyecto
El código está disponible online para su descarga de forma gratuita. El mismo se encuentra en
formato de proyecto de Visual Studio 2010 en el servicio de hosting de código de Microsoft
llamado CodePlex bajo la licencia “GNU General Public License version 2 (GPLv2)” de código
abierto. La dirección web para acceder al mismo es: http://musicatangible.codeplex.com/
2.5. Análisis de los resultados Se realizaron varias pruebas informales, en las que ambos programadores fueron los sujetos de
prueba. El sistema se comportó adecuadamente en la mayoría de los casos, permitiendo crear
simples piezas musicales rápida y fácilmente.
112
Se encontraron algunos problemas de detección de tokens en los casos en que los mismos no se
encontraban colocados correctamente sobre el tablero, es decir, no se encontraban justo en el
medio de una celda, ó se encontraban levemente girados.
La posibilidad de utilizar ambas manos permitió a los usuarios realizar las tareas de forma
eficiente. Adicionalmente, la interfaz resultó muy útil para utilizarla de forma colaborativa, donde
ambos usuarios manipulaban distintos tokens paralelamente. Se observó rápidamente que varias
de las tareas se realizaron de forma mucho más eficiente y natural en comparación con el uso de
una interfaz gráfica tradicional. Por ejemplo, un usuario podía remover una ficha con la mano
izquierda mientras que con la derecha colocaba otra (multiplexado espacial), algo imposible de
hacer mediante el mouse, con el cual dichas tareas deben realizarse de forma secuencial
(multiplexado temporal).
2.5.1. Desafíos encontrados y soluciones
A continuación se describen los principales desafíos encontrados durante la implementación del
prototipo, y las soluciones utilizadas para superarlos:
Problema:
No detección de las figuras debido a una pobre calidad de imagen.
Solución:
Uso de una cámara de mayor resolución. Una cámara de 1.3MPixels en lugar de una cámara VGA.
Problema:
Falsos positivos o no detección de las figuras.
Solución:
Ajuste de la iluminación. Ajuste del valor establecido como éxito de una comparación entre dos
imágenes. Utilización de números y letras en las figuras de los tokens, en lugar de simples figuras.
Problema:
Actualización del tablero no lo suficientemente rápido.
Solución:
Uso de hilos de ejecución.
Problema:
Captura de imágenes no lo suficientemente rápido debido al tiempo que demora en activarse la
cámara para capturar la imagen
113
Solución:
Uso de un hilo que ejecución que haga que la cámara capture imágenes constantemente.
Problema:
Imprecisiones en el manejo del tiempo para controlar la frecuencia de ejecución de los sonidos
Solución:
Uso de una librería dedicada que permita la ejecución de un metrónomo a través de un hilo.
Problema:
Hacer que el programa sea independiente, o transparente, de la tecnología utilizada para
implementar la interfaz tangible.
Solución:
Utilización de clase abstracta Board con el método Update(…) definido de forma abstracta para
que lo implemente la clase que se encarga de implementar la interfaz. Esto permitiría, en un
futuro, la posibilidad de tener distintas clases que implementen distintos tipos de interfaces para
el programa. Con sólo implementar el método Update(…) el resto del sistema seguirá funcionando
sin problema.
2.5.2. Problemas y limitaciones
Uno de los problemas que presenta el prototipo es la sensibilidad de la cámara a la luz. En muchas
ocasiones los resultados se vieron afectados si se variaba el ángulo o intensidad de la luz, pero
mejoraban al iluminar uniformemente el tablero ubicando la fuente de luz sobre el mismo, siendo
ésta de buena intensidad. De otra manera el sistema entregaba falsos positivos y no detectaba
ciertas fichas. (¿y con cámaras infrarrojas?)
Otra limitación es la necesidad de calibrar la cámara respecto al tablero (en cuanto a distancia y
ángulo) cada vez que se requiere trasladar el sistema de un lugar a otro. Es pertinente recordar
que tal calibración resulta necesaria para operar el sistema de forma correcta.
Por último, el prototipo descripto no es completamente robusto. Las fichas deben estar
correctamente ubicadas en las celdas del tablero, de lo contrario es posible que no se detecten.
Asimismo, no pueden estar rotadas, ni desplazadas fuera de la celda correspondiente, ya que
podrían no detectarse o arrojar falsos positivos. No obstante, en la gran mayoría de los casos, el
prototipo opera de forma correcta.
114
3. Segundo Prototipo Basado en los resultados obtenidos a partir del desarrollo del primer prototipo se propone
desarrollar un prototipo superador. La creación del mismo tiene como objetivo principal mejorar
la robustez del sistema anterior. Para esto se propone utilizar el paradigma de Token + Constraints,
implementado mediante un tablero con fichas encastrables.
La limitación principal del prototipo anterior está relacionada con su robustez. Las fichas deben
estar correctamente ubicadas y centradas en las celdas del tablero; de lo contrario, es posible que
no se detecten. Asimismo, no pueden estar rotadas, ni desplazadas fuera del centro de la celda
correspondiente, ya que podrían no detectarse o arrojar falsos positivos.
Estas limitaciones puede ser superadas fácilmente mediante la implementación de un tablero con
fichas encastrables, que aproveche las ventajas brindadas por el paradigma de interfaces tangibles
denominado Tokens + Constraints. Al utilizar un tablero con fichas encastrables, que limite
físicamente la ubicación de las tokens, de forma que los mismos sólo se puedan ubicar de forma
correcta, se aumenta en gran medida la robustez del sistema.
Además de forzar al usuario a colocar las fichas de forma correcta, solucionando los problemas de
la colocación de fichas rotadas, o no centradas dentro de la celda, el tablero encastrable brinda
otra ventaja importante relacionada con la usabilidad. El paradigma de Tokens + Constraints
brinda affordance, en el caso del tablero encastrable, sugiriendo implícitamente al usuario dónde
y cómo puede colocar las fichas para interactuar con el sistema. En otras palabras, la interfaz le
sugiere al usuario cómo interactuar con ella.
Una restricción de diseño importante, tenida en cuenta para el desarrollo de este segundo
prototipo, fue que el mismo pueda reutilizar el código del primer prototipo. Por lo tanto el nuevo
tablero se desarrolló con ciertas restricciones de diseño, de forma de respetar ciertos parámetros
necesarios del primer tablero, como su tamaño, la cantidad y tamaño de las celdas, y el tamaño y
forma de los marcadores utilizados. De esta manera el nuevo tablero podrá utilizarse sin
problemas con el sistema de visión por computadora desarrollado para el primer prototipo. Sólo
serán necesarias unas pequeñas modificaciones.
3.1. Diseño Inicialmente se hicieron varios dibujos borradores sobre el posible formato del nuevo tablero,
principalmente de la forma que tendrían las fichas. Se dibujaron en papel las diferentes formas de
encastre. El objetivo fue diseñar un tablero con fichas encastrables.
Desde un principio se pensó en utilizar formas diferentes para los “Instru-tokens” y los “Noti-
tokens”, con la idea de que la forma de cada conjunto de fichas sugiriese dónde podrían colocarse.
La idea es evitar físicamente que el usuario coloque un “Instru-token” en una posición donde
corresponda colocar un “Noti-token”.
115
Figura 53 – Diseño de “Intru-token” encastrable con
mueca cuadrada.
Figura 54 – Diseño de “Noti-token” encastrable con
mueca redondeada-
Para facilitar el retiro de los tokens, una vez colocados en el tablero, se pensó en un pequeño
hueco o ranura con forma de medio circulo en la parte superior de cada celda del tablero. Esta
ranura tiene como objetivo facilitar al usuario poder retirar la ficha una vez colocada en el tablero.
Se podría haber utilizado un material más fino para el tablero y un material más ancho para las
fichas, de forma que estas últimas sobresalieran y sean más fáciles de retirar una vez que se
encuentren colocadas en las celdas. Pero esta ida requería de más material y elevaba los costos ya
que no se podría utilizar el material removido del tablero como fichas.
Figura 55 – El usuario introduce el dedo en el hueco sobre el encastre de la ficha para removerla.
La principal restricción, sin contar que los marcadores utilizados en cada ficha debía ser el mismo
que el utilizado en el sistema anterior, fue que el tamaño y la ubicación de las distintas nuevas
piezas debía respetar el esquema utilizado en el tablero perteneciente al primer prototipo. Por lo
tanto, el tamaño del tablero debería ser el mismo, la cantidad de filas y columnas la misma, y el
tamaño y posición de las celdas la misma. De esta manera se podría re utilizar el sistema de visión
por computadora del prototipo anterior aplicando solo unas pequeñas modificaciones.
116
3.2. Elementos y herramientas utilizadas Para diseñar el tablero se utilizó el editor de gráficos vectoriales CorelDRAW, con el cual se generó
un archivo vectorizado del modelo.
El nuevo tablero se implementó en dos versiones, una sobre acrílico negro y otra sobre fibro plus
blanco. Ambas implementaciones se fabricaron mediante el uso de una máquina de grabado y
cortado láser. La elección de los materiales y el método de fabricación se explican y justifican en
las sub secciones siguientes.
3.3. La Máquina: grabadora y cortadora láser El grabado, marcado y corte de superficies, son procesos que industrialmente pueden ser
realizados aprovechando la tecnología láser de CO2. Los equipos de cortado y grabado láser
pueden ser utilizados sobre casi todo tipo de superficies como metales, maderas, cartones, cueros
y cauchos, y su funcionamiento es similar al de una impresora convencional, con la diferencia que
en vez de realizar una impresión a base de tinta, realizan una diminuta excavación, marca o
penetración en el material soporte, a través de un rayo láser, para reproducir así, fielmente, una
imagen, fotografía o dibujo.
Los máquinas láser ofrecen varias ventajas con respecto a otros métodos de corte y grabado, una
de ellas es que permiten graficar imágenes de mayor calidad y precisión, dado que el haz de luz
casi invisible puede llegar a puntos donde otras herramientas, debido a su tamaño, no lo logran;
de hecho, ofrecen cortes y grabados en dos y tres dimensiones, con un alto nivel de complejidad.
El principio de funcionamiento de estos equipos se concentra, inicialmente, en un rayo láser
intenso de luz invisible que es creado por medio de la excitación de gas carbónico CO2 al contacto
con electricidad y que es direccionado por un sistema de espejos hasta que finalmente, a través de
un lente convexo, se proyecta sobre el material.
Figura 56 – Máquina de grabado y cortado láser.
Figura 57 – La máquina con la compuerta abierta. Aquí
se coloca la plancha de material que será grabada y cortada por el láser.
117
Al igual que una impresora, los equipos láser dependen de un software que se instala en la
computadora y se encarga de establecer comunicación entre la máquina y su sistema operativo. La
función principal del controlador es informar al equipo ciertas características o variables de
impresión como por ejemplo, el tipo de trabajo que se va a realizar, es decir, si es corte, grabado o
la combinación de ambos.
El software de impresión es un sistema en el que se puede seleccionar desde el tamaño del
grabado, hasta la calidad de impresión; de hecho, a través de este programa el usuario interactúa
realmente con la máquina, pues funciona como un panel desde el cual se regulan las velocidades
de grabado, de corte y las potencias, entre otras variables. La velocidad y potencia de control
puede ser igualmente regulada de forma manual o po computadora en rangos que pueden
aumentar de 1 hasta un 100 por ciento; además, ofrece una excelente resolución de grabado que
va desde los 100 a 1000 dpi (dots por pulgada).
El equipo utilizado es un Versa Laser VLS3.60 de 50 watts fabricado por Universal Laser System
[122]. El mismo tiene un área de trabajo de 610 x 305 mm sobre la que se puede trabajar
materiales de hasta 30,5 mm de grosor. Alcanza una velocidad de trabajo media, por lo que es
recomendable para trabajos en pequeñas empresas en las que no se necesitan productos a gran
escala y/o con un alto grado de complejidad. Permite además realizar trabajos a partir de
cualquier software de diseño basado en Windows, lo que incluye AutoCAD, Illustrator y
CorelDRAW. Con los mismos se genera un modelo del trabajo en un archivo vectorizado que luego
se importa por el software que controla la máquina.
Figura 58 – Se puede observar a Julio Bellabarba configurando, mediante el software en la PC, los parámetros de la máquina láser. (¿Volvió del futuro :o) ¿)
Para mayor información sombre máquinas de grabado y cortado láser referirse a [123].
118
3.3.1. El Material: Acrílico Negro – Fibro Plus Blanco
Una vez seleccionado el procedimiento de grabado y cortado láser como método de fabricación,
se eligió el material a utilizar para el tablero. Se analizaron diversos materiales, como madera,
fibrofácil, acrílico transparente, acrílico negro y plástico.
El acrílico transparente permite un acabado elegante, pero hay que pegarle a cada ficha su
marcador impreso en papel. El plástico tiene esta misma limitación, pero adicionalmente, este
material se deforma levemente por el calor generado por el láser de la máquina, lo que impide
que las fichas encastren prolijamente.
El Fibro Plus blanco presenta varias ventajas respecto al resto de los materiales analizados. El
mismo consiste en una plancha de madera prensada, con una de sus caras laminada en color
blanco. El mismo es muy económico, comparado con el plástico y el acrílico. Además, se puede
conseguir fácilmente en cualquier maderera. Este material permite un acabado prolijo y preciso al
utilizar la máquina de grabado láser. Otra ventaja muy importante, es el alto grado de contraste
que se puede lograr con este material al utilizar el modo de grabado de la máquina láser. Este
contraste se genera entre el blanco de la lámina blanca y el gris oscuro de la madera quemada por
el láser en las zonas donde se aplica el método de grabado.
Una propiedad fundamental del Fibro Plus, descubierta más adelante en el trabajo, es su
opacidad. Dicha cualidad aporta robustez al proceso de reconocimiento de marcadores. Esto se
debe a que brinda robustez respecto a los cambios de iluminación, sobre todo a los cambios del
ángulo de iluminación, consecuencia de ser un material extremadamente opaco (producto de
presentar una superficie irregular), sobre todo en las regiones que quedan grabadas por la
máquina láser, en las cuales se expone la madera prensada. La ventaja es que casi no se genera un
reflejo especular [124] sobre el material, algo que sí sucede en otros materiales brillantes como el
acrílico. Este reflejo especular hace que la imagen capturada por la cámara sea diferente según el
ángulo de iluminación (más formalmente entre formado entre la fuente de iluminación y la
cámara), haciendo que la comparación con la imagen de muestra almacenada nunca sea igual. En
cambio, el Fibro Fácil, al ser tan opaco, es invariante al ángulo de iluminación, facilitando la
comparación con la imagen patrón almacenada.
Al utilizar la máquina láser en modo de grabado, este material grabado se torna gris oscuro (color
de la madera quemada); por lo tanto, se pensó en utilizar este método para dibujar los
marcadores sobre las fichas de forma precisa y elegante, es decir utilizando el contraste entre el
blanco del material y el gris oscuro del área grabada.
Finalmente, vistas las ventajas de este material y teniendo en cuenta el objetivo de desarrollar un
prototipo económico y con materiales de fácil acceso, se adquirió una lámina de Fibro Fácil Plus
Blanco de 30 cm x 60 cm de 3 mm espesor, tamaño requerido por la plataforma de la máquina de
grabado y cortado láser utilizada. El precio de la plancha fue de 7 pesos argentinos.
Adicionalmente, se decidió realizar una prueba utilizando acrílico negro para la fabricación del
tablero. El mismo presenta algunas ventajas sobre el resto de los materiales analizados. El acrílico
119
negro permite darle un acabado muy elegante a las fichas y al tablero. Al utilizar la máquina láser
en modo de grabado, este material grabado se vuelve gris claro. Por eso se pensó en utilizar este
método para dibujar los marcadores sobre las fichas de forma precisa y elegante. Finalmente,
vistas las ventajas de este material, se adquirió una lámina de acrílico negro de 30 cm x 60 cm de
3,4 mm. El precio de la plancha fue de alrededor de 100 pesos argentinos.
Más adelante se descubriría que el acrílico negro presenta una limitación importante, además de
un precio elevado. La misma propiedad brillosa que permite un acabado elegante, genera un alto
grado de reflexión especular, volviéndolo un material poco adecuado para esta aplicación.
3.4. Implementación del tablero A partir del diseño realizado en papel, se prosiguió a formalizarlo mediante la generación de un
archivo vectorizado del modelo mediante la aplicación gráfica CorelDRAW.
Para aprovechar al máximo el material, se generaron las fichas de los “Noti-tokens” a partir de los
pedazos extraídos del mismo tablero. Lo mismo se hizo para fabricar los “Instru-tokens”, pero
utilizando el material extraído de la primera columna, ya que la forma del encastre de los “Instru-
tokens” es diferente a la de los “Noti-tokens”. Por lo tanto se fabricaron seis “Noti-token” de cada
tipo y seis “Intru-tokens”, dos con el número 3, dos con el número 1, uno con el número 4 y uno
con el número 2.
Figura 59 – Modelo vectorizado del tablero diseñado en CorelDRAW. El mismo fue utilizado por la máquina láser para producir el tablero. Las líneas de color rojo indican que la máquina realizará cortes. Las líneas de color azul la máquina
120
grabará ligeramente. Lo que está pintado de negro será grabado de manera un poco profunda, por lo que quedará pintado de un color distinto al del material utilizado.
Una vez finalizada la creación del modelo vectorizado se prosiguió a importarlo al software
controlador de la máquina de cortado y grabado láser.
Luego de importar el modelo, se pasó a hacer una pequeña prueba de impresión sobre madera,
material mucho más económico que el acrílico y el Fibro Plus. Esto se hizo para ver que la máquina
realice el trabajo de forma correcta, antes de proseguir con la generación completa del tablero.
Figura 60 – La plancha de madera colocada en la
máquina.
Figura 61 – Resultado de las pruebas de grabado y corte
de fichas sobre madera.
Una vez comprobado que la “impresión” sobre madera fue correcta, se prosiguió a “imprimir” el
tablero en la plancha de acrílico negro y luego en la plancha de Fibro Fácil blanco.
3.4.1. Tableros y fichas fabricados
A continuación se muestra el tablero y las fichas producidas sobre los dos materiales.
Tableros
Se presentan los dos tableros. El primero en Fibro Plus blanco y el segundo en acrílico negro.
Figura 62 – Tablero producido en Fibro Plus blanco.
Figura 63 – Tablero producido en acrílico negro. Se puede observar el reflejo especular en las celdas de más abajo.
121
Fichas
A continuación se exhiben los tokens del sistema fabricados en los dos materiales. Se puede
observar la opacidad de las fichas producidas en Fibro Plus blanco, en contraste con el brillo que
generan las fichas de acrílico.
Figura 64 – Los cuatro “Instru-tokens” producidos en acrílico negro. Se puede observar el reflejo especular.
Figura 65 - Los cuatro “Instru-tokens” producidos en Fibro Plus blanco.
Figura 66 – Los siete “Noti-tokens” fabricados en acrílico negro.
Figura 67 – Los siete “Noti-tokens” fabricados en Fibro Plus blanco.
Fichas colocadas en el tablero
Aquí se muestran dos posibles configuraciones del tablero y las fichas. Los respectivos “Instru-
tokens” colocados en la primer columna, y luego los “Noti-tokens” posicionados en las respectivas
filas. Se puede observar que el encastre, distinto entre los “Noti-tokens” y los “Instru-tokens”
fuerza al usuario a colocar los distintos tipos de fichas en los lugares correctos. Adicionalmente, se
puede observar un fuerte reflejo en la parte inferior del tablero fabricado con acrílico negro. Más
adelante se verá que este reflejo complica el proceso de reconocimiento de los marcadores,
concluyendo que los materiales opacos ofrecen mayor robustez respecto a los cambios de
iluminación.
122
Figura 68 – Tokens colocados en el tablero de Fibro Plus blanco. Se puede apreciar la opacidad de todos sus elementos
Figura 69 – Tokens colocados en el tablero de acrílico negro. Se puede observar un fuerte reflejo especular en el centro del mismo.
123
3.5. Calibración del software Una vez finalizado el nuevo tablero, se re configuró el código del prototipo anterior para que el
sub-sistema de visión por computadora opere correctamente. Dicha proceso consistió en dos
tareas relacionadas a la clase BoardFromCam. Las mismas se explican a continuación.
La primera tarea fue capturar las imágenes patrón de cada una de los nuevos “Noti-tokens” e
“Instru-tokens” creados, cortarlas de forma correcta, e importarlas al sistema para poder
utilizarlas como imágenes de comparación.
La segunda tarea consistió en ajustar el tamaño del corte de la imagen del tablero tomada por la
cámara, de forma que se ajuste correctamente a los límites del nuevo tablero, eliminando el resto
de lo que aparece en la foto. Dicha modificación se realiza en el método captureImage(). Luego se
re ajustó ligeramente el tamaño del paso y el tamaño de las celdas, de forma que el método
recorra de forma correcta cada una de las celdas del tablero de la imagen capturada, es decir que
el ROI caiga de forma justa y centrada en cada una de las celdas del tablero, para permitir una
comparación correcta de ese área con las imágenes patrones de comparación. Dicha modificación
se realizó en el método detectNotes() y en el método detectInstruments().
3.6. Análisis de los resultados Se realizaron varias pruebas informales sobre este segundo prototipo, donde el autor fue el sujeto
de prueba.
Basado en los resultados obtenidos, se pudo comprobar que se mejoró notablemente la robustez
del sistema con respecto a la detección de los marcadores, en comparación con el primer
prototipo. Esto se debió al uso del paradigma de Token + Constraints, el cual se implementó
mediante el tablero con fichas encastrables. Esta implementación permitió que las fichas fueran
colocadas en el lugar correcto, evitando que se posicionaran de forma rotada, o des centrada. En
otras palabras, sólo existe una forma posible de colocar las fichas, la correcta.
El paradigma Token + Constraints simplificó en gran medida el código del sistema relacionado a la
detección de los marcadores. Esto se debió a que eliminó muchos casos posibles que debían ser
contemplados en el proceso de reconocimiento de los tokens, como tokens rotados en infinitos
ángulos o tokens desplazados del centro de la celda. Todos estos casos se evitaron, ya que el
posicionado correcto de los tokens está guiado y limitado físicamente, por los encastres del
tablero.
Además de asistir al usuario a colocar las fichas de forma correcta, solucionando los problemas de
la colocación de fichas rotadas o no centradas dentro de la celda, el tablero encastrable brinda
otra ventaja importante relacionada con la usabilidad. El paradigma de Tokens + Constraints
brinda affordance, en el caso del tablero encastrable, sugiriendo implícitamente al usuario dónde
y cómo puede colocar las fichas para interactuar con el sistema. En otras palabras, la interfaz le
sugiere al usuario cómo interactuar con la misma.
124
Adicionalmente se mejoró la estética del sistema emulando, con los tokens encastrables, piezas o
fichas de juegos de mesa, como rompecabezas, de forma que los usuarios puedan utilizar sus
conocimientos previos, adquiridos con los mismos, para interactuar eficazmente con el sistema.
Uno de los problemas que sigue presentando el prototipo es la sensibilidad de la cámara a la luz.
En muchas ocasiones los resultados del reconocimiento de los marcadores se vieron afectados si
se variaba el ángulo o intensidad de la fuente de luz, pero mejoraban al iluminar uniformemente el
tablero ubicando la fuente de luz sobre el mismo, siendo ésta de buena intensidad. Se comprobó
que los materiales opacos, que no generan reflexión especular, como el Fibro Plus, son más
adecuados para la fabricación de las fichas y los marcadores, ya que sus reflejos son más
invariantes respecto a la variación de la intensidad y del ángulo de iluminación. En cambio, los
materiales brillosos, que generan reflexión especular, como el acrílico negro, no son adecuados
para utilizar para la fabricación de los marcadores, ya que la imagen capturada de los mismos varía
debido al reflejo ocasionado por las distintas variaciones de iluminación, complicando la
comparación con una única imagen patrón de comparación.
Una limitación, que sigue existiendo, es la necesidad de calibrar la cámara respecto al tablero (en
cuanto a distancia y ángulo) cada vez que se requiere trasladar el sistema de un lugar a otro. Es
pertinente recordar que tal calibración resulta necesaria para operar el sistema de forma correcta.
Finalmente, se observó que el sistema se comportó mejor que el primer prototipo en la totalidad
de los casos, por lo que se puede concluir que este segundo prototipo es ampliamente mejor que
primero.
125
PARTE IV - CONCLUSIONES
"La conclusión final es que sabemos muy poco y, sin embargo, es asombroso lo mucho que
conocemos. Y más asombroso todavía que un conocimiento tan pequeño nos pueda dar tanto
poder" - Bertrand Russell
1. Resumen …………………………………………………………………. 125 2. Limitaciones, problemas y cuestiones pendientes .….. 125 3. Trabajo futuro …………………………………………………………. 125
126
1. Resumen Se diseñó e implementó una interfaz tangible de bajo costo para la creación de música; dicho
desarrollo se basó en el estudio previo de las interfaces tangibles, la interacción humano-
computadora y los antecedentes relacionados a la composición de música utilizando estos medios.
El sistema se implementó mediante tecnología de visión por computadora con herramientas y
elementos de fácil acceso. La interfaz permitió la creación de música de forma intuitiva,
incremental y colaborativa, con una curva de aprendizaje empinada.
El sistema desarrollado es un secuenciador musical tangible de mesa. El mismo identifica, en
tiempo real, mediante visión por computadora, patrones preestablecidos impresos en fichas que
son colocadas sobre un tablero, para luego asociarlos a notas musicales o instrumentos,
dependiendo del caso y permitiendo de esta forma generar música. Se desarrollaron dos
prototipos de dicho sistema. El segundo prototipo presenta, adicionalmente, un tablero con fichas
encastrables, el cual brinda importantes ventajas.
2. Limitaciones, problemas y cuestiones pendientes Varias de las limitaciones del primer prototipo fueron superadas con la implementación del
tablero encastrable perteneciente al segundo prototipo, sobre todo los problemas relacionados
con la robustez del reconocimiento de imágenes.
Sin embargo, las limitaciones más importantes del segundo prototipo siguen estando asociadas
con la robustez y eficiencia del mismo en lo que respecta al reconocimiento de las fichas.
Uno de los principales problemas está relacionado con la ubicación de la cámara. Al tener la
cámara posicionada sobre el tablero, cuando el usuario mueve su brazo sobre el mismo para
colocar una ficha en alguna celda, bloquea la cámara por unos segundos, es decir introduce ruido,
ya que el sistema capturará la imagen del brazo e intentará analizarlo, arrojando resultados
erróneos.
Uno de los problemas que sigue presentando el prototipo es la sensibilidad de la cámara a la luz.
En muchas ocasiones los resultados del reconocimiento de los marcadores se vieron afectados si
se variaba el ángulo o intensidad de la fuente de luz, pero mejoraban al iluminar uniformemente el
tablero ubicando la fuente de luz sobre el mismo, siendo ésta de buena intensidad.
Otra cuestión pendiente está relacionada con el código del sistema. El código del prototipo no fue
optimizado aún, por lo que se debe realizar un análisis del mismo para lograr un funcionamiento
más eficiente del método de reconocimiento de imágenes y del sistema en su conjunto.
Por último, una limitación importante asociada con la usabilidad y robustez del prototipo está
relacionada con la calibración de la cámara. La misma debe colocarse correctamente sobre el
tablero, a una altura, ángulo y distancia correctos, de forma tal que el tablero quede centrado de
modo tal que el software funcione correctamente. Esta operación debe realizarse de forma
“artesanal” cada vez que se arma o mueve el tablero, volviéndose algo tedioso. Si el sistema queda
mal calibrado el mismo operará de forma incorrecta.
127
3. Trabajo futuro
3.1. Mejoras Basado en los resultados obtenidos, y a partir del desarrollo de los prototipos y las pruebas
informales realizadas sobre los mismos, se propone un conjunto de mejoras apuntadas a superar
las principales limitaciones.
Para mejorar la eficiencia y robustez relacionadas al reconocimiento de imágenes, se podría
estudiar el campo de los marcadores de referencia con el objetivo de desarrollar y utilizar diseños
más robustos y eficientes (Ver [125]). Esto se podría encarar utilizando alguna librería especifica,
como por ejemplo la librería para realidad aumentada ARToolkit [126], o algún sistema de
reconocimiento de marcadores, como códigos QR, fiducial markers o glyph’s recognition. Los
mismos pueden aportar una solución más eficiente y robusta, incrementando la usabilidad del
prototipo
Para solucionar el problema de reconocimiento de los marcadores relacionado con la variación
del ángulo e intensidad de la iluminación, se propone montar una lámpara sobre el soporte de la
cámara. El objetivo de esta propuesta es que la iluminación sobre el tablero y las fichas sea
siempre la misma, independientemente de la iluminación del ambiente donde se encuentre la
interfaz. De esta forma se podría aumentar la robustez del prototipo.
Otra mejora relacionada con la usabilidad del juego es la incorporación de un mecanismo para
calibrar la cámara de forma fácil y eficiente. Esto se podría lograr mediante software, ubicando
cuatro fichas especiales en las cuatro esquinas del tablero de modo que, al capturar la imagen del
mismo, al reconocer tales fichas, la cámara estaría correctamente ubicada y la iluminación sería la
apropiada. Adicionalmente, se podría realizar un segundo paso en la calibración, el cual consistiría
en colocar en el tablero los cuatro “Intru-tokens” de una forma pre establecida (por ejemplo, de
forma creciente), y los siete “Noti-token” también de una forma pre establecida (por ejemplo de
forma creciente en la primer fila). Una vez hecha la calibración descripta anteriormente, el sistema
podría tomar y almacenar las imágenes sabiendo cuál corresponde a cada token, de forma de
utilizar las mismas como imágenes patrón para las comparaciones posteriores. Esta segunda
calibración podría reducir los problemas producidos por las variaciones de iluminación, ya que las
imágenes patrones de los tokens serían tomadas con la iluminación que utilizará posteriormente el
sistema durante su ejecución.
Una vez comprobado que el prototipo se comportó de forma correcta, se propone una mejora
importante para evitar los problemas causados por la interferencia generada en las imágenes
capturadas por la cámara, producto del brazo del usuario. Esto sucede cuando el mismo coloca
alguna ficha en el tablero. Lo que se propone es colocar el tablero sobre una mesa o superficie de
acrílico transparente o vidrio, que permita posicionar la cámara debajo de la misma, permitiendo
tomar las imágenes sin interferencias. A su vez, los tokens tendrán dos marcadores distintos, uno
en cada cara. En una cara del token se colocará el marcador optimizado para el reconocimiento
mediante visión por computadora y en la otra cara del mismo, se colocará una figura que sea fácil
128
de reconocer y asociar para el usuario humano. De esta manera se mejora la robustez del sistema,
ya que no habrá interferencias en las imágenes; también se mejorará la eficiencia, ya que el
marcador utilizado se desdobla en las dos caras del token, uno optimizado para la computadora y
otro optimizado para el usuario humano. Adicionalmente se mejorará la estética del sistema ya
que el usuario sólo verá un tablero tradicional. (Ver Figura 70)
3.2. Extensiones Luego de implementadas las mejoras, se podría pensar en extender el sistema de alguna de las
maneras descritas a continuación.
Una extensión importante podría ser la utilización de un proyector colocado sobre el tablero, que
permita realimentar información sobre el mismo, es decir, afectar de cierta manera el mundo
físico, pintando con un dado color la columna del tablero que se está reproduciendo actualmente.
Adicionalmente, se podría pintar de algún otro color los tokens que son identificados
correctamente por el sistema, de forma tal que los usuarios cuenten con información visual
instantánea que les permita reconocer si el software detectó correctamente la ficha colocada.
Otra alternativa podría ser la utilización de acrílico transparente como material para el tablero y
los tokens y colocar el proyector debajo del tablero. Esto evitaría que el usuario interfiriera en la
proyección cuando coloca el brazo sobre el tablero para colocar alguna ficha.
Figura 70 – Sistema tangible con cámara debajo del tablero y realimentación de información a través de un proyector.
Otra extensión que se podría implementar es el manejo de ciertos parámetros del sistema, que
aún se manejan de forma gráfica por la interfaz tangible. Esto es, manejar los controles de “Play” y
“Stop”, el volumen y la frecuencia de reproducción mediante objetos tangibles. Tales funciones se
podrían implementar mediante ranuras que permitan deslizar cierto token por las mismas. El
control de volumen tangible podría ser una ranura vertical, ubicada a la derecha del tablero, que
permita aumentar el volumen deslizando un token especial hacia arriba, y reducir el volumen
deslizando el token hacia abajo. Algo similar se podría implementar para controlar de forma
conjunta la frecuencia de reproducción y las funciones de Play/Stop. Se podría colocar una ranura
horizontal en la parte inferior del tablero, que permita deslizar un token especial sobre la misma.
129
Cuando el token se encuentre en la posición más a la izquierda de la ranura, el sistema estará
detenido; a medida que se deslice el token hacia la derecha el sistema aumentará la frecuencia de
reproducción de los sonidos.
Adicionalmente se podrían utilizar distintos tipos de fichas con, por ejemplo, diferentes colores, materiales y formas. Esto último permitiría estimular el sentido del tacto, lo que sería una extensión ideal para personas no videntes. Se podría asociar la textura o forma de la ficha con un sonido particular.
Finalmente, el sistema podría contar con una librería de sonidos pre establecidos, o permitir la importación de los mismos para que luego el usuario los pueda asociar a un token en particular mediante el uso de la interfaz gráfica.
3.3. Pruebas de usabilidad Una cuestión pendiente, muy importante y que excede el alcance de este trabajo, es la realización
de un análisis formal de usabilidad del prototipo. Dicho análisis se deberá basar en pruebas
formales de usabilidad con el fin de contar con métricas objetivas que permitan comparar el
prototipo desarrollado con un análogo que utilice una interfaz gráfica tradicional.
130
PARTE V - ELEMENTOS FINALES
Bibliografía …………..……………………………… 130 Anexo .……………………………………….……….. 139 Código ………………………………..…………… 139
131
Bibliografía
[1] J. Bowers, “Improvising Machines: Ethnographically Informed Design For Improvised Electro-Acoustic Music,” ARiADA: Applied Research in Aesthetics in the Digital Arts, 2003. [Online]. Available: http://www.ariada.uea.ac.uk/ariadatexts/ariada4/index4.html.
[2] J. Patten, B. Recht, and H. Ishii, “Audiopad: A tag-based interface for musical performance,” in Proceedings of the International Conference on New Interface for Musical Expression NIME02, 2002, pp. 24-26.
[3] H. Newton-Dunn, H. Nakano, and J. Gibson, “Blockjam: A tangible interface for interactive music,” in Proceedings of the 2003 Conference on New Interfaces for Musical Expression (NIME-03), 2003, pp. 170-177.
[4] S. Jord, M. Kaltenbrunner, and R. Bencina, “The ReacTable*,” in ICMC 2005 - CDROM Proceedings, 2005.
[5] S. Jordà, “On stage: The reactable and other musical tangibles go real,” International Journal of Arts and Technology (IJART), Special Issue on Tangible and Embedded Interaction, vol. 1, no. 3/4, pp. 268-287, 2008.
[6] O. Shaer and E. Hornecker, “Tangible User Interfaces: Past, Present, and Future Directions,” Foundations and Trends® in Human–Computer Interaction, vol. 3, no. 1-2, pp. 1-137, 2009.
[7] C. Sabino, “Como hacer una Tesis,” 1994. [Online]. Available: http://paginas.ufm.edu/sabino/word/hacer_tesis.doc.
[8] R. Chandrasekhar, “How to Write a Thesis: A Working Guide,” 2002. [Online]. Available: http://www.mendeley.com/research/write-thesis-working-guide-1/.
[9] H. Ishii and B. Ullmer, “Tangible Bits: Towards Seamless Interfaces between People, Bits and Atoms,” in CHI ’97: Proceedings of the SIGCHI conference on Human factors in computing systems, 1997, no. March, pp. 234-241.
[10] Hewett et al., “ACM SIGCHI Curricula for Human-Computer Interaction: 2. Definition and Overview of Human-Computer Interaction,” 2009. [Online]. Available: http://old.sigchi.org/cdg/cdg2.html.
[11] Newell, Perlis, and Simon, “What is computer science?,” Science, no. 157, pp. 373-4, 1967.
[12] Denning, “Report on the ACM Task Force on the Core of Computer Science,” New York, 1988.
[13] F. Hillier, Introduction to Operations Research. Mcgraw Hill Higher Education, 2009, p. 1088.
[14] J. Rasmussen, A. M. Pejtersen, and L. P. Goodstein, Cognitive Systems Engineering. Wiley-Interscience, 1994, p. 396.
132
[15] Participatory Design, Human Computer Interaction group at Aarhus University, Department of Computer Science. [Online]. Available: http://www.daimi.au.dk/research/areas/human-computer-interaction/participatory-design/index.html.
[16] C. Hewitt and P. de de Jong, “Open Systems,” MIT Artificial Inteligence Memo, vol. 691, pp. 1-27, 1982.
[17] J. Carroll, “Human Computer Interaction (HCI),” in Encyclopedia of Human-Computer Interaction, M. Soegaard and R. F. Dam, Eds. The Interaction-Design.org Foundation, 2009.
[18] P. Wellner, W. Mackay, and R. Gold, “Computer-augmented environments. Back to the real world,” Communications of the ACM, vol. 36, no. 7, pp. 24-26, 1993.
[19] G. W. Fitzmaurice, H. Ishii, and W. Buxton, “Bricks: Laying the foundations for graspable user interfaces,” in Proceedings of CHI95, 1995, pp. 442–449.
[20] W. E. Mackay and A. L. Fayard, “Designing interactive paper: Lessons from three augmented reality projects,” in Proceedings of IWAR98, International Workshop on Augmented Reality, 1999.
[21] J. Underkoffler and H. Ishii, “Urp: A luminous-tangible workbench for urban planning and design,” in Proceedings of CHI ’99, 1999, pp. 386–393.
[22] R. Perlman, “Using Computer Technology to Provide a Creative Learning Environment for Preschool Children,” MIT Logo Memo 24, 1976.
[23] The MIT Media Lab, “Logo Foundation,” What is Logo? [Online]. Available: http://el.media.mit.edu/logo-foundation/logo/index.html. [Accessed: 2012].
[24] R. Abrams, “Adventures in tangible computing: The work of interaction designer ‘Durrell Bishop’ in context,” Master’s thesis, Royal College of Art, London, 1999.
[25] A. N. Antle, “The CTI framework: Informing the design of tangible systems for children,” in Proceedings of TEI ’07, 2007, pp. 195-202.
[26] S. Goldin-Meadow, Hearing Gesture: How Our Hands Help Us Think. Harvard University Press, 2003.
[27] G. Zufferey, P. Jermann, A. Lucchi, and P. Dillenbourg, “TinkerSheets: Using paper forms to control and visualize tangible simulations,” in Proceedings of TEI09, 2009, pp. 377-384.
[28] J. Underkoffler and H. Ishii, “Illuminating light: An optical design tool with a luminous-tangible interface,” in Proceedings of CHI98, 1998, pp. 542–549.
[29] O. Zuckerman, S. Arida, and M. Resnick, “Extending tangible interfaces for education: Digital montessori-inspired manipulatives,” in Proceedings of CHI ’05, 2005, pp. 859–868.
133
[30] M. Resnick, “Behavior construction kits,” Communications of the ACM, vol. 36, no. 7, pp. 64-71, 1993.
[31] C. O’Malley and D. Stanton Fraser, “Literature review in learning with tangible technologies,” in NESTA futurelab report 12, 2004.
[32] D. Kirsh and P. Maglio, “On distinguishing epistemic from pragmatic actions,” Cognitive Science, vol. 18, no. 4, pp. 513-549, 1994.
[33] B. Ullmer, H. Ishii, and R. Jacob, “Token+constraint systems for tangible interaction with digital information,” ACM Transactions on Computer-Human Interaction, vol. 12, no. 1, pp. 81-118, 2005.
[34] M. J. Kim and M. L. Maher, “The impact of tangible user interfaces on designers’ spatial cognition,” Human-Computer Interaction, vol. 23, no. 2, 2008.
[35] R. J. K. Jacob, H. Ishii, G. Pangaro, and J. Patten, “A tangible interface for organizing information using a grid,” in Proceedings of CHI ’02, 2002, pp. 339–346.
[36] J. Underkoffler and H. Ishii, “Illuminating light: An optical design tool with a luminous-tangible interface,” in Proceedings of CHI98, 1998, pp. 542–549.
[37] G. Zufferey, P. Jermann, A. Lucchi, and P. Dillenbourg, “TinkerSheets: Using paper forms to control and visualize tangible simulations,” in Proceedings of TEI09, 2009, pp. 377–384.
[38] K. Hinckley, J. G. R. Pausch, and N. Kassel, “Passive real-world interface props for neurosurgical visualization,” in Proceedings of CHI94, 1994, pp. 452–458.
[39] N. Couture, G. Riviere, and P. Reuter, “GeoTUI: A tangible user interface for geoscience,” in Proceedings of TEI08, 2008, pp. 89–96.
[40] H. Suzuki and H. Kato, “AlgoBlock: A tangible programming language, a tool for collaborative learning,” in Proceedings of the 4th European Logo conference (Eurologo93), 1993, pp. 297–303.
[41] T. S. McNerney, “From turtles to tangible programming bricks: Explorations in physical language design,” Pers Ubiquit Comput, vol. 8, pp. 326–337, 2004.
[42] D. Edge and A. Blackwell, “Correlates of the cognitive dimensions for tangible user interfaces,” Journal of Visual Languages and Computing, vol. 17, no. 4, pp. 366–394, 2006.
[43] J. Sosoka, B. Abercrombie, B. Emerson, and A. Gerstein, “EDUCATIONAL MUSIC INSTRUMENT FOR CHILDREN,” U.S. Patent US 6,353,168 B1,2002.
[44] A. Dekel, G. Yavne, E. Ben-Tov, and Y. Roschak, “The spelling bee,” in Proceedings of the international conference on Advances in computer entertainment technology - ACE ’07, 2007, p. 212.
134
[45] H. Raffle, C. Vaucelle, R. Wang, and H. Ishii, “Jabberstamp,” in Proceedings of the 6th international conference on Interaction design and children - IDC ’07, 2007, p. 137.
[46] Z. Zhou, A. D. Cheok, J. Pan, and Y. Li, “Magic Story Cube,” in Proceedings of the 2004 ACM SIGCHI International Conference on Advances in computer entertainment technology - ACE ’04, 2004, pp. 364-365.
[47] E. van Loenen et al., “EnterTaible: A solution for social gaming experiences,” in Tangible Play: Research and Design for Tangible and Tabletop Games, Workshop at the 2007 Intelligent User Interfaces Conference, 2007, pp. 16-19.
[48] C. Magerkurth, M. Memisoglu, T. Engelke, and N. A. Streitz, “Towards the next generation of tabletop gaming experiences,” in Graphics Interface 2004 (GI’04), 2004, pp. 73–80.
[49] J. Leitner, M. Haller, K. Yun, W. Woo, M. Sugimoto, and M. Inami, “IncreTable, a mixed reality tabletop game experience,” in Proceedings of the 2008 International Conference on Advances in Computer Entertainment Technology, 2008, pp. 9–16.
[50] A. Singer, D. Hindus, L. Stifelman, and S. White, “Tangible progress: Less is more in somewire audio spaces,” in Proceedings of CHI ’99, 1999, pp. 104-111.
[51] S. Greenberg and H. Kuzuoka, “Using digital but physical surrogates to mediate awareness, communication and privacy in media spaces,” Personal Tech-nologies, vol. 4, no. 1, 200AD.
[52] J. J. Kalanithi and V. M. Bove, “Connectibles: Tangible social networks,” in Proceedings of TEI08, 2008, pp. 199-206.
[53] D. Edge and A. Blackwell, “Peripheral tangible interaction by analytic design,” in Proceedings of TEI09, 2009, pp. 68-76.
[54] R. Strong and B. Gaver, “Feather, scent and shaker: Supporting simple intimacy,” in Proceedings of CSCW 1996, 1996, pp. 29-30.
[55] A. Chang, B. Resner, B. Koerner, X. Wang, and H. Ishii, “LumiTouch: An emotional communication device,” in Proceedings of CHI’01 Extended Abstracts, 2001, pp. 313–314.
[56] G. Weinberg and S. Gan, “The squeezables: Toward an expressive and interdependent multi-player musical instrument,” Computer Music Journal, vol. 25, no. 2, pp. 37-45, 2001.
[57] Furukawa, Fujihata, and Muench, “Small fish,” 2000. [Online]. Available: http://hosting.zkm.de/wmuench/small_fish.
[58] M. Kaltenbrunner, “Tangible Musical Interfaces,” Web site, 2012. [Online]. Available: http://modin.yuri.at/tangibles/.
135
[59] S. Jordà, G. Geiger, M. Alonso, and M. Kaltenbrunner, “The reacTable: Exploring the synergy between live music performance and tabletop tangible interfaces,” in in Proceedings of TEI ’07, 2007, pp. 139–146.
[60] NIME: International Conference on New Interfaces for Musical Expression. [Online]. Available: http://www.nime.org/.
[61] B. S. and J. Vanderdonckt, “AudioCubes: A distributed cube tangible interface based on interaction range for sound design,” in Proceedings of TEI ’08, 2008, pp. 3-10.
[62] E. W. Pedersen and K. Hornbæk, “mixiTUI: A tangible sequencer for electronic live performances,” in Proceedings of TEI ’09, 2009, pp. 223–230.
[63] F. Price, “Laugh & LearnTM Fun With FriendsTM Musical Table,” Fisher Price Toys website, 2012. [Online]. Available: http://www.fisher-price.com/fp.aspx?st=2341&e=detail&pcat=bulnl&pid=45350.
[64] T. Bartindale, J. Hook, and P. Olivier, “Media Crate: Tangible Live Media Production Interface,” in Proceedings of TEI09, 2009, pp. 255-262.
[65] M. Kaltenbrunner and R. Bencina, “reacTIVision: A computer-vision framework for table-based tangible interaction,” in Proceedings of TEI ’07, 2007, pp. 69-74.
[66] P. Bennett, “The BeatBearing: a tangible rhythm sequencer,” in Proceedings of NordiCHI, 2008.
[67] Arduino, Official Web site, 2012. [Online]. Available: http://www.arduino.cc/. [Accessed: 2012].
[68] H. Hannes and M. Andrew, “The Bubblegum Sequencer,” in CHI 2008 Extended Abstract Format, 2008.
[69] G. W. Fitzmaurice, “Graspable User Interfaces,” Thesis for Degree of Doctor of Philosophy, Graduate Department of Computer Science,University of Toronto, 1996. [Online]. Available: http://www.dgp.toronto.edu/~gf/papers/PhD - Graspable UIs/Thesis.gf.html.
[70] G. W. Fitzmaurice and W. Buxton, “An empirical evaluation of graspable user interfaces: Towards specialized, space-multiplexed input,” in Proceedings of CHI97, 1997, pp. 43–50.
[71] B. Ullmer and H. Ishii, “Emerging frameworks for tangible user interfaces,” in Human-Computer Interaction in the New Millenium, 2001, pp. 579–601.
[72] K. Fishkin, “A taxonomy for and analysis of tangible interfaces,” Personal and Ubiquitous Computing, vol. 8, pp. 347–358, 2004.
136
[73] B. Ullmer, H. Ishii, and R. Jacob, “Token+constraint systems for tangible interaction with digital information,” ACM Transactions on Computer-Human Interaction, vol. 12, no. 1, pp. 81-118, 2005.
[74] O. Shaer, N. Leland, E. H. Calvillo-Gamez, and R. J. K. Jacob, “The TAC paradigm: Specifying tangible user interfaces,” Personal and Ubiquitous Computing, vol. 8, no. 5, pp. 359–369, 2004.
[75] B. Ullmer and H. Ishii, “Mediablocks: Tangible interfaces for online media,” in Proceedings of CHI ’99, 1999, pp. 31-32.
[76] D. O’Sullivan and T. Igoe, Physical Computing: Sensing and Controlling the Physical World with Computers. Boston: Thomson, 2004.
[77] A. Schmidt and K. V. Laerhoven, “How to build smart appliances,” IEEE Personal Communications, Special Issue on Pervasive Computing, vol. 8, no. 4, pp. 66-71, 2001.
[78] M. P. Weller, E. Y. Do, and M. D. Gross, “Posey: Instrumenting a poseable hub and strut construction toy,” in Proceedings of TEI ’08, 2008, pp. 39-46.
[79] V. LeClerc, A. A. Parkes, and H. Ishii, “Senspectra: A computationally augmented physical modeling toolkit for sensing and visualization of structural strain,” in Proceedings of CHI ’07, 2007, pp. 801–804.
[80] K. Camarata, B. R. J. E. Y. Do, and M. D. Gross, “Navigational blocks: Navigating information space with tangible media,” in Proceedings of the 7th International Conference on Intelligent User Interfaces, 2002, pp. 31-38.
[81] J. Patten and H. Ishii, “Mechanical constraints as computational constraints in tabletop tangible interfaces,” in Proceedings of CHI’07, 2007, pp. 809-818.
[82] The Handy Board and The Super Cricket, Official web site. [Online]. Available: http://handyboard.com/. [Accessed: 2012].
[83] O. Shaer, M. S. Horn, and R. J. K. Jacob, “Tangible User Interface Laboratory: Teaching Tangible Interaction Design in Practice,” Journal of Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AIEDAM), vol. 23, no. 3, pp. 251-261, 2009.
[84] Lego Mindstorms, Lego web site, 2012. [Online]. Available: http://mindstorms.lego.com.
[85] “PicoCricket - Invention kit that integrates art and technology,” Commercial web site, 2012. [Online]. Available: http://www.picocricket.com.
[86] A. N. Antle, N. Motamedi, K.Tanenbaum, and Z. L. Xie, “The EventTable technique: Distributed fiducial markers,” in Proceedings of TEI ’09, 2009, pp. 307-313.
137
[87] S. R. Klemmer, M. W. Newman, R. Farrell, M. Bilezikjian, and J. A. Landay, “The designers outpost: A tangible interface for collaborative web site design,” in Proceedings of UIST’2001: ACM Symposium on User Interface Software and Technology, 2001, pp. 1-10.
[88] V. Maquil, A. T. Psik, and I. Wagner, “The ColorTable: A design story,” in Proceedings of TEI ’08, 2008, pp. 97-104.
[89] H. Kato and M. Billinghurst, “Marker tracking and HMD calibration for a video-based augmented reality conferencing system,” in Proceedings of the 2nd International Workshop on Augmented Reality (IWAR 99), 1999.
[90] H. Kato, M. Billinghurst, and et al., “Virtual object manipulation on a table-top AR environment,” in Proceedings of International Symposium on Augmented Reality ISAR 2000, 2000, pp. 111-119.
[91] S. R. Klemmer, J. L. J. Li, and J. A. Landay, “Papier-Mâché: Toolkit support for tangible input,” in Proceedings of CHI2004, 2004, pp. 399-406.
[92] S. Klemmer and et al, “HCI at Stanford University - Papier-Mâché: Toolkit support for tangible interaction,” UC Berkeley. [Online]. Available: http://hci.stanford.edu/research/papier-mache/.
[93] G. Bradski and A. Kaehler, Learning OpenCV. O’Reilly Media, 2008.
[94] Phidgets Inc. - Unique and Easy to Use USB Interfaces, Official web site, 2012. [Online]. Available: http://www.phidgets.com/.
[95] N. V. A and H. Gellersen, “A malleable control structure for softwired user interfaces,” in Proceedings of TEI ’07, 2007, pp. 49-56.
[96] E. Hornecker and J. Buur, “Getting a grip on tangible interaction: a framework on physical space and social interaction,” in Proceedings of the SIGCHI conference on Human Factors in computing systems - CHI ’06, 2006, p. 437.
[97] M. S. Horn, E. T. Solovey, R. J. Crouser, and R. J. K. Jacob, “Comparing the use of tangible and graphical programming languages for informal science education,” in Proceedings of the 27th international conference on Human factors in computing systems - CHI ’09, 2009, p. 975.
[98] S. R. Klemmer, B. Hartmann, and L. Takayama, “How bodies matter,” in Proceedings of the 6th ACM conference on Designing Interactive systems - DIS ’06, 2006, p. 140.
[99] J. Piaget, Play, dreams, and imitation in childhood. W. W. Norton and Company, Inc., 1962.
[100] M. W. Alibali, M. W. Alibali, S. Kita, A. J. Young, and D. Psychology, “Gesture and the process of speech production: We think, therefore we gesture,” LANGUAGE AND COGNITIVE PROCESSES, vol. 15, pp. 593 - 613, 2000.
138
[101] D. Kirk, A. Sellen, S. Taylor, N. Villar, and S. Izadi, “Putting the physical into the digital: issues in designing hybrid interactive surfaces,” in Proceedings of the 23rd British HCI Group Annual Conference on People and Computers: Celebrating People and Technology, 2009, pp. 35-44.
[102] D. Kirsh and P. Maglio, “On Distinguishing Epistemic from Pragmatic Action,” Cognitive Science, vol. 18, no. 4, pp. 513 - 549, 1994.
[103] J. Zhang, J. M, M. St, and D. A. Norman, “Representations in distributed cognitive tasks,” COGNITIVE SCIENCE, vol. 18, pp. 87 - 122, 1994.
[104] J. Zhang, “The Nature of External Representations in Problem Solving,” Cognitive Science, vol. 21, no. 2, pp. 179 - 216, 1997.
[105] D. Norman, La psicología de los objetos cotidianos. Madrid: NEREA, 1990.
[106] G. L. Revelle and E. F. Strommen, “The effects of practice and input device used on young children’s computer control,” Collegiate Microcomputer, vol. 8, no. 4, pp. 33-41, Nov. 1990.
[107] A. Lane and J. Ziviani, “The Suitability of the Mouse for Children’s Use: A Review of the Literature,” Journal of Computing in Childhood Education, vol. 8, no. 2/3, pp. 227-45, 1997.
[108] J. P. Hourcade, B. Bederson, and A. Druin, “Building KidPad: an application for children’s collaborative storytelling,” Software: Practice and Experience, vol. 34, no. 9, pp. 895-914, 2004.
[109] G. Revelle, O. Zuckerman, A. Druin, and M. Bolas, “Tangible user interfaces for children,” in CHI ’05 extended abstracts on Human factors in computing systems (CHI EA '05), 2005, pp. 2051-2052.
[110] B. Inhelder and J. Piaget, The Early Growth of Logic in the Child. 1999.
[111] L. Vygotsky, “Interaction between learning and development,” in In Mind in Society, 1978, pp. 79-91.
[112] D. Xu, “Tangible User Interface for Children - An Overview,” in UCLAN Department of Computing Conference, 2005.
[113] D. Edge and A. Blackwell, “Correlates of the cognitive dimensions for tangible user interfaces,” Journal of Visual Languages and Computing, vol. 17, no. 4, pp. 366-394, 2006.
[114] V. Bellotti, M. Back, W. K. Edwards, R. E. Grinter, A. Henderson, and C. Lopes, “Making sense of sensing systems,” in Proceedings of the SIGCHI conference on Human factors in computing systems Changing our world, changing ourselves - CHI ’02, 2002, p. 415.
139
[115] R. J. K. Jacob et al., “Reality-based interaction: a framework for post-WIMP interfaces,” in Proceeding of the twenty-sixth annual CHI conference on Human factors in computing systems - CHI ’08, 2008, p. 201.
[116] Genius iSlim 1320 Web Cam, Genius Web Site. [Online]. Available: http://www.geniusnet.com/wSite/ct?xItem=19463&ctNode=1303&mp=3.
[117] Emgu CV, Official Web Site. [Online]. Available: http://www.emgu.com.
[118] CodePlex, Project Hosting for Open Source Software. [Online]. Available: http://www.codeplex.com/.
[119] L. Sanford, “C# MIDI Toolkit", The Code Project, 2007. [Online]. Available: http://www.codeproject.com/Articles/6228/C-MIDI-Toolkit.
[120] Microsoft.DirectX.AudioVideoPlayback, Windows Desktop Development. [Online]. Available: http://msdn.microsoft.com/en-us/library/windows/desktop/bb318762(v=vs.85).aspx.
[121] Template Matching, OpenCV v2.4.0 documentation - OpenCV Tutorials - Image Processing. [Online]. Available: http://opencv.itseez.com/doc/tutorials/imgproc/histograms/template_matching/template_matching.html.
[122] VLS3.60, Universal Laser Systems, 2012. [Online]. Available: http://www.ulsinc.com/products/vls360/.
[123] L. F. Castro Patiño, “Corte y Grabado por Láser: Tecnología Novedosa Versátil y Sencilla,” Revista El Mueble y La Madera, Edición No. 68, pp. 84-94, 2010.
[124] S. M. Castro, “Iluminación,” Clases de Computación Grafica - VyGLab - DCIC - UNS, 2011. .
[125] M. Fiala, “Designing highly reliable fiducial markers.,” IEEE transactions on pattern analysis and machine intelligence, vol. 32, no. 7, pp. 1317-24, Jul. 2010.
[126] ARToolKit Official web site. [Online]. Available: http://www.hitl.washington.edu/artoolkit/.
[127] O. Carreras, “Disciplinas relacionadas con la usabilidad,” Usable y accesible. Olga Carreras. Blog, 2007. [Online]. Available: http://olgacarreras.blogspot.com.ar/2007/01/disciplinas-relacionadas-con-la.html.
140
Anexo
Código
Program.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
namespace MusicaTangible
{
static class Program
{
/// <summary>
/// Punto de entrada principal para la aplicación.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new MainWindow());
}
}
}
141
MainWindow.cs
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace MusicaTangible
{
public partial class MainWindow : Form
{
private MusicProcessor musicProcessor;
private PictureBox circleRed, circleOrange, circleYellow, circleGreen,
circleLightblue, circleBlue, circlePurple;
private PictureBox circle, quad, triangle, cross;
private PictureBox hand;
public MainWindow()
{
InitializeComponent();
this.GotoFullScreen();
this.CreatePictureBoxes();
this.musicProcessor = new MusicProcessor(this);
}
private void GotoFullScreen()
{
this.FormBorderStyle = FormBorderStyle.None;
this.Left = 0;
this.Top = 0;
this.Width = Screen.PrimaryScreen.Bounds.Width;
this.Height = Screen.PrimaryScreen.Bounds.Height;
}
public void CreatePictureBoxes()
{
#region Hand
this.hand = new PictureBox();
this.hand.Size = new System.Drawing.Size(47, 68);
this.hand.Image = global::MusicaTangible.Properties.Resources.hand;
this.hand.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.hand.Anchor = AnchorStyles.None;
#endregion
#region Notes
this.circleRed = new PictureBox();
this.circleRed.Size = new System.Drawing.Size(114, 112);
this.circleRed.Image =
global::MusicaTangible.Properties.Resources.token_c;
this.circleRed.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.circleRed.Anchor = AnchorStyles.None;
this.circleOrange = new PictureBox();
this.circleOrange.Size = new System.Drawing.Size(114, 112);
142
this.circleOrange.Image =
global::MusicaTangible.Properties.Resources.token_d;
this.circleOrange.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.circleOrange.Anchor = AnchorStyles.None;
this.circleYellow = new PictureBox();
this.circleYellow.Size = new System.Drawing.Size(114, 112);
this.circleYellow.Image =
global::MusicaTangible.Properties.Resources.token_e;
this.circleYellow.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.circleYellow.Anchor = AnchorStyles.None;
this.circleGreen = new PictureBox();
this.circleGreen.Size = new System.Drawing.Size(114, 112);
this.circleGreen.Image =
global::MusicaTangible.Properties.Resources.token_f;
this.circleGreen.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.circleGreen.Anchor = AnchorStyles.None;
this.circleLightblue = new PictureBox();
this.circleLightblue.Size = new System.Drawing.Size(114, 112);
this.circleLightblue.Image =
global::MusicaTangible.Properties.Resources.token_g;
this.circleLightblue.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.circleLightblue.Anchor = AnchorStyles.None;
this.circleBlue = new PictureBox();
this.circleBlue.Size = new System.Drawing.Size(114, 112);
this.circleBlue.Image =
global::MusicaTangible.Properties.Resources.token_a;
this.circleBlue.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.circleBlue.Anchor = AnchorStyles.None;
this.circlePurple = new PictureBox();
this.circlePurple.Size = new System.Drawing.Size(114, 112);
this.circlePurple.Image =
global::MusicaTangible.Properties.Resources.token_b;
this.circlePurple.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.circlePurple.Anchor = AnchorStyles.None;
#endregion
#region Shapes
this.quad = new PictureBox();
this.quad.Size = new System.Drawing.Size(114, 112);
this.quad.Image = global::MusicaTangible.Properties.Resources.quad;
this.quad.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.quad.Anchor = AnchorStyles.None;
this.circle = new PictureBox();
this.circle.Size = new System.Drawing.Size(114, 112);
this.circle.Image =
global::MusicaTangible.Properties.Resources.circle;
this.circle.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.circle.Anchor = AnchorStyles.None;
143
this.triangle = new PictureBox();
this.triangle.Size = new System.Drawing.Size(114, 112);
this.triangle.Image =
global::MusicaTangible.Properties.Resources.triangle;
this.triangle.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.triangle.Anchor = AnchorStyles.None;
this.cross = new PictureBox();
this.cross.Size = new System.Drawing.Size(114, 112);
this.cross.Image = global::MusicaTangible.Properties.Resources.cross;
this.cross.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
this.cross.Anchor = AnchorStyles.None;
#endregion
for (int i = 0; i < this.tableLayoutPanel1.RowCount; i++)
{
PictureBox pp = new PictureBox();
pp.Size = new System.Drawing.Size(114, 112);
pp.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
pp.Anchor = AnchorStyles.None;
pp.Image = null;
this.tableLayoutPanel1.Controls.Add(pp, 0, i);
for (int j = 1; j < this.tableLayoutPanel1.ColumnCount; j++)
{
PictureBox pp1 = new PictureBox();
pp1.Size = new System.Drawing.Size(114, 112);
pp1.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
pp1.Anchor = AnchorStyles.None;
pp1.Image = null;
this.tableLayoutPanel1.Controls.Add(pp1, j, i);
}
}
for (int j = 0; j < this.tableLayoutPanel2.ColumnCount; j++)
{
PictureBox pp1 = new PictureBox();
pp1.Size = new System.Drawing.Size(114, 112);
pp1.SizeMode =
System.Windows.Forms.PictureBoxSizeMode.CenterImage;
pp1.Anchor = AnchorStyles.None;
pp1.Image = null;
this.tableLayoutPanel2.Controls.Add(pp1, j, 0);
}
}
public void UpdateColumn(int current)
{
if (this.tableLayoutPanel2.InvokeRequired)
{
this.tableLayoutPanel2.Invoke(new
UpdateColumnDelegate(this.UpdateColumn), current);
}
else
{
if (current == 0)
144
((PictureBox)this.tableLayoutPanel2.GetControlFromPosition(8,
0)).Image = null;
else
((PictureBox)this.tableLayoutPanel2.GetControlFromPosition(current, 0)).Image =
null;
((PictureBox)this.tableLayoutPanel2.GetControlFromPosition(current + 1, 0)).Image
= global::MusicaTangible.Properties.Resources.hand;
}
}
private delegate void UpdateColumnDelegate(int current);
#region Event Handlers
private void pictureBox1_MouseEnter(object sender, EventArgs e)
{
this.pictureBoxIniciar.Image =
global::MusicaTangible.Properties.Resources.iniciar_on;
}
private void pictureBox1_MouseLeave(object sender, EventArgs e)
{
this.pictureBoxIniciar.Image =
global::MusicaTangible.Properties.Resources.iniciar_off;
}
private void pictureBox2_MouseEnter(object sender, EventArgs e)
{
this.pictureBoxDetener.Image =
global::MusicaTangible.Properties.Resources.detener_on;
}
private void pictureBox2_MouseLeave(object sender, EventArgs e)
{
this.pictureBoxDetener.Image =
global::MusicaTangible.Properties.Resources.detener_off;
}
private void pictureBox3_Click(object sender, EventArgs e)
{
Application.Exit();
}
private void pictureBox3_MouseEnter(object sender, EventArgs e)
{
this.pictureBox3.Image =
global::MusicaTangible.Properties.Resources.salir_on;
}
private void pictureBox3_MouseLeave(object sender, EventArgs e)
{
this.pictureBox3.Image =
global::MusicaTangible.Properties.Resources.salir_off;
}
private void pictureBox1_Click(object sender, EventArgs e)
{
this.musicProcessor.Play();
}
private void pictureBox2_Click(object sender, EventArgs e)
145
{
this.musicProcessor.Stop();
}
private void MainWindow_FormClosed(object sender, FormClosedEventArgs e)
{
this.musicProcessor.Stop();
}
#endregion
private void pictureBoxSpeedDown_Click(object sender, EventArgs e)
{
if (this.musicProcessor.Tempo > 1)
{
this.musicProcessor.Tempo--;
this.lblTempo.Text = this.musicProcessor.Tempo.ToString();
}
}
private void pictureBoxSpeedUp_Click(object sender, EventArgs e)
{
if (this.musicProcessor.Tempo < 15)
{
this.musicProcessor.Tempo++;
this.lblTempo.Text = this.musicProcessor.Tempo.ToString();
}
}
private delegate void UpdateInstrumensDelegate(int row, Shapes shape);
public void UpdateInstruments(int row, Shapes shape)
{
if (this.tableLayoutPanel1.InvokeRequired)
{
this.tableLayoutPanel1.Invoke(new
UpdateInstrumensDelegate(this.UpdateInstruments), row, shape);
}
else
{
PictureBox pp =
(PictureBox)this.tableLayoutPanel1.GetControlFromPosition(0, row);
switch (shape)
{
case Shapes.circle:
pp.Image =
global::MusicaTangible.Properties.Resources.circle;
break;
case Shapes.square:
pp.Image =
global::MusicaTangible.Properties.Resources.quad;
break;
case Shapes.triangle:
pp.Image =
global::MusicaTangible.Properties.Resources.triangle;
break;
case Shapes.cross:
pp.Image =
global::MusicaTangible.Properties.Resources.cross;
break;
default:
pp.Image = null;
146
break;
}
}
}
private delegate void UpdateNotesDelegate(int row, int column, Colors
color);
public void UpdateNotes(int row, int column, Colors color)
{
if (this.tableLayoutPanel1.InvokeRequired)
{
this.tableLayoutPanel1.Invoke(new
UpdateNotesDelegate(this.UpdateNotes), row, column, color);
}
else
{
PictureBox pp =
(PictureBox)this.tableLayoutPanel1.GetControlFromPosition(column+1, row);
switch (color)
{
case Colors.red:
pp.Image =
global::MusicaTangible.Properties.Resources.token_c;
break;
case Colors.orange:
pp.Image =
global::MusicaTangible.Properties.Resources.token_d;
break;
case Colors.yellow:
pp.Image =
global::MusicaTangible.Properties.Resources.token_e;
break;
case Colors.green:
pp.Image =
global::MusicaTangible.Properties.Resources.token_f;
break;
case Colors.lightblue:
pp.Image =
global::MusicaTangible.Properties.Resources.token_g;
break;
case Colors.blue:
pp.Image =
global::MusicaTangible.Properties.Resources.token_a;
break;
case Colors.purple:
pp.Image =
global::MusicaTangible.Properties.Resources.token_b;
break;
default:
pp.Image = null;
break;
}
}
}
private void MainWindow_KeyDown(object sender, KeyEventArgs e)
{
switch (e.KeyCode)
{
case Keys.Add:
if (this.musicProcessor.Tempo < 12)
{
147
this.musicProcessor.Tempo++;
this.lblTempo.Text =
this.musicProcessor.Tempo.ToString();
}
break;
case Keys.Subtract:
if (this.musicProcessor.Tempo > 1)
{
this.musicProcessor.Tempo--;
this.lblTempo.Text =
this.musicProcessor.Tempo.ToString();
}
break;
case Keys.Space:
case Keys.Enter:
if (this.musicProcessor.IsPlaying)
this.musicProcessor.Stop();
else
this.musicProcessor.Play();
break;
default:
break;
}
}
}
}
148
MusicProcessor.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Sanford.Multimedia.Midi;
using System.Threading;
namespace MusicaTangible
{
class MusicProcessor
{
protected Thread updateThread;
protected Board board;
protected Instrument[] instruments;
protected MidiInternalClock metronome;
protected int currentColumn;
protected MainWindow parent;
protected int tempo;
public int Tempo
{
get
{
return this.tempo;
}
set
{
this.tempo = value;
this.metronome.Tempo = 12000000 - this.tempo * 500000;
}
}
public bool IsPlaying { get; protected set; }
public MusicProcessor(MainWindow parent)
{
this.parent = parent;
this.currentColumn = 0;
this.board = new BoardFromCam(this, 8);
this.createDefaultIntruments();
this.metronome = new MidiInternalClock();
this.Tempo = 1;
this.metronome.Ppqn = 24;
this.metronome.Tick += new EventHandler(metronome_Tick);
}
private void createDefaultIntruments()
{
this.instruments = new Instrument[4];
instruments[(int)Shapes.circle] = new Instrument("Piano",
Instrument.InstrumentPresets.piano);
instruments[(int)Shapes.square] = new Instrument("Drums",
Instrument.InstrumentPresets.drums);
instruments[(int)Shapes.cross] = new Instrument("Bass",
Instrument.InstrumentPresets.bass);
instruments[(int)Shapes.triangle] = new Instrument("Guitar",
Instrument.InstrumentPresets.guitar);
}
protected void update()
149
{
this.board.Update();
}
public void UpdateForm()
{
for (int i = 0; i < this.board.NumberOfRows; i++)
{
this.parent.UpdateInstruments(i, this.board.GetInstrument(i));
for (int j = 0; j < this.board.NumberofColumms; j++)
{
this.parent.UpdateNotes(i, j, this.board.GetColor(i, j));
}
}
}
void metronome_Tick(object sender, EventArgs e)
{
this.parent.UpdateColumn(this.currentColumn);
for (int i = 0; i < this.board.NumberOfRows; i++)
{
Colors colorAux = this.board.GetColor(i, currentColumn);
Shapes instrument = this.board.GetInstrument(i);
if (instrument != Shapes.empty)
{
if (colorAux != Colors.empty)
{
this.instruments[(int)instrument].Play(colorAux);
}
}
}
if (this.currentColumn == 7)
this.currentColumn = 0;
else
this.currentColumn++;
if (this.currentColumn == 5)
{
this.updateThread = new Thread(this.update);
this.updateThread.Start();
}
if (this.currentColumn == 6)
{
this.UpdateForm();
//this.board.printBoard();
}
}
public void Play()
{
this.IsPlaying = true;
this.metronome.Start();
}
public void Stop()
{
this.IsPlaying = false;
if (this.metronome != null)
this.metronome.Stop();
this.board.Stop();
}
150
}
}
151
Board.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace MusicaTangible
{
public enum Shapes { circle, square, cross, triangle, empty }
abstract class Board
{
public int NumberOfRows { get; protected set; }
public int NumberofColumms { get; protected set; }
protected MusicProcessor parent;
protected struct Row
{
public Shapes instrument;
public Colors[] row;
}
protected Row[] myBoard;
public abstract void Stop();
protected void Initialize(int numberOfRows, int numberOfColumns)
{
this.NumberofColumms = numberOfColumns;
this.NumberOfRows = numberOfRows;
myBoard = new Row[numberOfRows];
for (int i = 0; i < numberOfRows; i++)
{
myBoard[i].instrument = Shapes.empty;
myBoard[i].row = new Colors[numberOfColumns];
for (int j = 0; j < numberOfColumns; j++)
{
myBoard[i].row[j] = Colors.empty;
}
}
}
public abstract void Update();
public void SetInstrument(int rowNumber, Shapes shape)
{
myBoard[rowNumber].instrument = shape;
}
public void SetColor(int rowNumber, int columnNumber, Colors color)
{
myBoard[rowNumber].row[columnNumber] = color;
}
public Shapes GetInstrument(int rowIndex)
{
return this.myBoard[rowIndex].instrument;
}
public Colors GetColor(int rowIndex, int columnIndex)
152
{
return this.myBoard[rowIndex].row[columnIndex];
}
protected void PlaceShapeOnBoard(int row, Shapes shape)
{
this.SetInstrument(row, shape);
}
protected void PlaceColorOnBoard(int row, int column, Colors color)
{
this.SetColor(row, column - 1, color);
}
public void printBoard()
{
char symbol = '#';
for (int i = 0; i < NumberOfRows; i++)
{
Shapes instrument = this.myBoard[i].instrument;
switch (instrument)
{
case Shapes.circle:
symbol = '1';
break;
case Shapes.triangle:
symbol = '2';
break;
case Shapes.square:
symbol = '3';
break;
case Shapes.cross:
symbol = '4';
break;
case Shapes.empty:
symbol = '-';
break;
}
System.Console.Write(symbol);
System.Console.Write('|');
for (int j = 0; j < NumberofColumms; j++)
{
Colors note = this.myBoard[i].row[j];
switch (note)
{
case Colors.red:
symbol = 'C';
break;
case Colors.orange:
symbol = 'D';
break;
case Colors.yellow:
symbol = 'E';
break;
case Colors.green:
symbol = 'F';
break;
case Colors.lightblue:
symbol = 'G';
break;
case Colors.blue:
symbol = 'A';
break;
153
case Colors.purple:
symbol = 'B';
break;
case Colors.empty:
symbol = '-';
break;
}
System.Console.Write(symbol);
System.Console.Write('|');
}
System.Console.WriteLine();
}
System.Console.WriteLine();
}
}
}
154
BoardFromCam.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Drawing;
using Emgu.CV;
using Emgu.CV.UI;
using Emgu.CV.Structure;
namespace MusicaTangible
{
class BoardFromCam : Board
{
private Capture capture;
private Image<Gray, Byte>[] shapeImageList;
private Image<Gray, Byte>[] colorImageList;
private Image<Gray, Byte> boardGrayImg;
protected Image<Bgr, Byte> boardCapture;
private Thread Capturator;
public BoardFromCam(MusicProcessor parent, int numberOfColumns, int
numberOfRows = 6)
{
this.NumberOfRows = numberOfRows;
this.NumberofColumms = numberOfColumns;
Initialize(numberOfRows, numberOfColumns);
this.parent = parent;
this.capture = new Capture(0);
capture.SetCaptureProperty(Emgu.CV.CvEnum.CAP_PROP.CV_CAP_PROP_FRAME_WIDTH,
1600);
capture.SetCaptureProperty(Emgu.CV.CvEnum.CAP_PROP.CV_CAP_PROP_FRAME_HEIGHT,
1200);
this.Capturator = new Thread(this.CaptureThread);
this.Capturator.Start();
this.capture.SetCaptureProperty(Emgu.CV.CvEnum.CAP_PROP.CV_CAP_PROP_BRIGHTNESS,
1);
shapeImageList = new Image<Gray,
Byte>[Enum.GetNames(typeof(Shapes)).Length];
colorImageList = new Image<Gray,
Byte>[Enum.GetNames(typeof(Colors)).Length];
this.loadTemplateImages();
}
public void addShapeImage(Shapes shape, string fileName)
{
this.shapeImageList[(int)shape] = new Image<Gray, Byte>(fileName);
}
public void addColorImage(Colors color, string fileName)
{
this.colorImageList[(int)color] = new Image<Gray, Byte>(fileName);
}
155
public void loadTemplateImages()
{
addShapeImage(Shapes.circle, "Img\\Instrumentos\\circle.bmp");
addShapeImage(Shapes.square, "Img\\Instrumentos\\quad.bmp");
addShapeImage(Shapes.triangle, "Img\\Instrumentos\\triangle.bmp");
addShapeImage(Shapes.cross, "Img\\Instrumentos\\cross.bmp");
addShapeImage(Shapes.empty, "Img\\Instrumentos\\empty.bmp");
//System.Console.WriteLine("Cargue las imagenes de formas con
exito");
addColorImage(Colors.blue, "Img\\Notas\\token_a.jpg");
addColorImage(Colors.green, "Img\\Notas\\token_f.jpg");
addColorImage(Colors.lightblue, "Img\\Notas\\token_g.jpg");
addColorImage(Colors.orange, "Img\\Notas\\token_d.jpg");
addColorImage(Colors.purple, "Img\\Notas\\token_b.jpg");
addColorImage(Colors.red, "Img\\Notas\\token_c.jpg");
addColorImage(Colors.yellow, "Img\\Notas\\token_e.jpg");
addColorImage(Colors.empty, "Img\\Notas\\empty.bmp");
//System.Console.WriteLine("Cargue las imagenes de colores con
exito");
}
public override void Update()
{
this.captureImage();
this.detectInstruments();
this.detectNotes();
}
protected void CaptureThread()
{
while (true)
boardCapture = this.capture.QueryFrame();
}
protected void captureImage()
{
this.boardCapture.Save("antesDeCortar.jpg");
Image<Bgr, byte> boardCapture2 = this.boardCapture;
double scaleFactor = 880.0 / boardCapture2.Width; // 880 / 1280 =
0,6875
Image<Bgr, Byte> resizedCapture = boardCapture2.Resize(scaleFactor,
Emgu.CV.CvEnum.INTER.CV_INTER_AREA); // newPic = 880 x 660
Rectangle ROI = new Rectangle(0,0,850,535);
boardGrayImg = resizedCapture.Copy(ROI).Convert<Gray, Byte>();
//this.boardGrayImg.Save("postCorte.jpg");
}
protected void detectInstruments()
{
#region Initialization
bool aux = false;
int cantShapes = Enum.GetNames(typeof(Shapes)).Length; // Sí recorro
el Empty
int curY = 0;
int height = this.boardGrayImg.Height;
int step = height / 6;
156
int width = this.boardGrayImg.Width / 9;
int widthAux = this.boardGrayImg.Width;
int heightAux = this.boardGrayImg.Height;
#endregion
#region Detection
for (int i = 0; i < 6; i++)
{
aux = false;
for (Shapes shape = 0; (int)shape < cantShapes; shape++)
{
boardGrayImg.ROI = new Rectangle(0, curY, width, step);
boardGrayImg.Save("generated\\" + i + "-" + "0.png");
Image<Gray, float> result =
boardGrayImg.MatchTemplate(this.shapeImageList[(int)shape],
Emgu.CV.CvEnum.TM_TYPE.CV_TM_CCORR_NORMED);
double[] min, max;
Point[] minLocations, maxLocations;
result.MinMax(out min, out max, out minLocations, out
maxLocations);
int k = 0;
foreach (var point in maxLocations)
if (max[k++] > 0.83)
{
if (shape == Shapes.triangle)
{
result =
boardGrayImg.MatchTemplate(shapeImageList[(int)Shapes.empty],
Emgu.CV.CvEnum.TM_TYPE.CV_TM_CCORR_NORMED);
result.MinMax(out min, out max, out minLocations,
out maxLocations);
k = 0;
foreach (var point2 in maxLocations)
if (max[k++] > 0.999)
{
this.PlaceShapeOnBoard(i, Shapes.empty);
aux = true;
}
if (!aux)
{
this.PlaceShapeOnBoard(i, Shapes.triangle);
aux = true;
}
}
else
{
this.PlaceShapeOnBoard(i, shape);
aux = true;
}
}
if (aux)
break;
}
curY += step;
if (curY > height) curY = height;
}
#endregion
boardGrayImg.ROI = new Rectangle(0, 0, widthAux, heightAux);
}
157
protected void detectNotes()
{
#region Initialization
bool aux = false;
int cantColors = Enum.GetNames(typeof(Colors)).Length; // Sí recorro
el Empty
int height = this.boardGrayImg.Height;
int width = this.boardGrayImg.Width;
int widthAux = this.boardGrayImg.Width;
int heightAux = this.boardGrayImg.Height;
int stepX = width / 9;
int stepY = height / 6;
int curY = 0;
int curX = stepX;
#endregion
#region Detection
for (int i = 0; i < 6; i++) //rows
{
for (int j = 1; j < 9; j++) //columns
{
aux = false;
for (Colors color = 0; (int)color < cantColors; color++)
{
boardGrayImg.ROI = new Rectangle(curX, curY, stepX,
stepY);
boardGrayImg.Save("generated\\" + i + "-" + j + ".png");
Image<Gray, float> result;
try
{
result =
boardGrayImg.MatchTemplate(this.colorImageList[(int)color],
Emgu.CV.CvEnum.TM_TYPE.CV_TM_CCORR_NORMED);
double[] min, max;
Point[] minLocations, maxLocations;
result.MinMax(out min, out max, out minLocations, out
maxLocations);
int k = 0;
foreach (var point in maxLocations)
if (max[k++] > 0.93)
{
this.PlaceColorOnBoard(i, j, color);
aux = true;
}
}
catch (Exception)
{
System.Console.WriteLine("OpenCV: Bad input roi in
methos detectNotes from class BoardCam");
}
if (aux)
break;
}
curX += stepX;
158
if (curX > width) curX = width;
}
curX = stepX;
curY += stepY;
if (curY > height) curY = height;
}
#endregion
boardGrayImg.ROI = new Rectangle(0, 0, widthAux, heightAux);
}
public override void Stop()
{
this.Capturator.Abort();
}
}
}
159
Instrument.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.DirectX.AudioVideoPlayback;
namespace MusicaTangible
{
public enum Colors { red, orange, yellow, green, lightblue, blue, purple,
empty };
class Instrument
{
public enum InstrumentPresets { drums, guitar, bass, piano };
public String Name {get; set;}
private Audio[] sounds;
public Instrument(String name)
{
this.Name = name;
this.sounds = new Audio[Enum.GetNames(typeof(Colors)).Length];
}
public Instrument(String name, InstrumentPresets preset)
{
this.Name = name;
this.sounds = new Audio[Enum.GetNames(typeof(Colors)).Length];
switch (preset)
{
case InstrumentPresets.drums:
this.sounds[0] = new Audio("Sounds\\Drums\\hihat.wav");
this.sounds[1] = new Audio("Sounds\\Drums\\hihat.wav");
this.sounds[2] = new Audio("Sounds\\Drums\\hihat.wav");
this.sounds[3] = new Audio("Sounds\\Drums\\hihat.wav");
this.sounds[4] = new Audio("Sounds\\Drums\\hihat.wav");
this.sounds[5] = new Audio("Sounds\\Drums\\kick.wav");
this.sounds[6] = new Audio("Sounds\\Drums\\snare.wav");
break;
case InstrumentPresets.guitar:
this.sounds[0] = new Audio("Sounds\\Guitar\\guitar_c.wav");
this.sounds[1] = new Audio("Sounds\\Guitar\\guitar_d.wav");
this.sounds[2] = new Audio("Sounds\\Guitar\\guitar_e.wav");
this.sounds[3] = new Audio("Sounds\\Guitar\\guitar_f.wav");
this.sounds[4] = new Audio("Sounds\\Guitar\\guitar_g.wav");
this.sounds[5] = new Audio("Sounds\\Guitar\\guitar_a.wav");
this.sounds[6] = new Audio("Sounds\\Guitar\\guitar_b.wav");
break;
case InstrumentPresets.piano:
this.sounds[0] = new Audio("Sounds\\Piano\\piano_c.wav");
this.sounds[1] = new Audio("Sounds\\Piano\\piano_d.wav");
this.sounds[2] = new Audio("Sounds\\Piano\\piano_e.wav");
this.sounds[3] = new Audio("Sounds\\Piano\\piano_f.wav");
this.sounds[4] = new Audio("Sounds\\Piano\\piano_g.wav");
this.sounds[5] = new Audio("Sounds\\Piano\\piano_a.wav");
this.sounds[6] = new Audio("Sounds\\Piano\\piano_b.wav");
break;
case InstrumentPresets.bass:
this.sounds[0] = new Audio("Sounds\\Bass\\bass_c.wav");
160
this.sounds[1] = new Audio("Sounds\\Bass\\bass_d.wav");
this.sounds[2] = new Audio("Sounds\\Bass\\bass_e.wav");
this.sounds[3] = new Audio("Sounds\\Bass\\bass_f.wav");
this.sounds[4] = new Audio("Sounds\\Bass\\bass_g.wav");
this.sounds[5] = new Audio("Sounds\\Bass\\bass_a.wav");
this.sounds[6] = new Audio("Sounds\\Bass\\bass_b.wav");
break;
default:
break;
}
}
public void AddSound(Colors color, Audio sound)
{
this.sounds[(int)color] = sound;
}
public void Play(Colors color)
{
if (color != Colors.empty)
{
this.sounds[(int)color].Stop();
this.sounds[(int)color].Play();
}
}
}
}
