Un sólido de Catalan

Me complazco en presentarles la última creación de Bondi Labs: “Barcelona”, también conocida como “El Dodecaedro del Demonio” (por el laburo que nos dio) o también “La Verdadera Pelota de los Dioses”. Vamos a observar el vídeo, y después les cuento un poco de qué se trata todo esto.

Copio aquí la información oficial de la obra, tal como aparece en Youtube:

Barcelona is an interactive installation.

Commissioned by Uruguay Encendido, http://uruguayencendido.gub.uy, Barcelona is a LED lit pentakis dodecahedron that reacts to sound and music, and to people that come close to it.

It was created by Bondi, in March 2013.

The structure is about two meters tall, made of iron. We hand crafted the diffusers, and only used our own electronics and software for controlling and addressing the LED.

Credits:

Christian Clark. Production. Coding. Electronics.
Tomás Laurenzo. Art direction. Coding.
Pablo Gindel. Electronics. Coding.
Fabrizio Devoto. Construction.
Tatjana Kudinova. Industrial design.
Marcela Abal. Industrial design.

Video by Tatjana Kudinova.
Music by Tomás Laurenzo.

Bondi is an interaction design collective.
http://bondi.cc

Un poco más en detalle…

La historia de Bondi comienza en el 2011 con la instalación Celebra, encargada en aquel entonces por la Comisión del Bicentenario del Uruguay, y estrenada en noviembre de ese año en el EAC. Esta instalación consistía en una nube de 200 globos luminosos, cada uno de los cuales era controlado en forma independiente –con un rango de color de 24bits– mediante un sistema de hardware y software diseñado por nosotros (Bondi). Este sistema permitía generar distintos patrones y efectos en la nube, ya fuera algorítmicamente, o a partir de la información captada por sensores, permitiendo así la interacción del público.

Si bien la descripción que acabo de dar es bastante técnica, es apenas un esbozo de la verdadera complejidad que implica una instalación así. Me interesa mostrarlo con más detalle aún, a través del siguiente diagrama en bloques:

Diagrama en bloques de la instalación Celebra.

Como vemos, el sistema involucra muchas partes, tanto de hardware como de software. El hardware, de por sí, es complicado, por el hecho de que hay que controlar en forma independiente 600 fuentes de luz (cada globo posee un componente rojo, uno verde y uno azul [síntesis de color RGB]), pero cada una de estas fuentes de luz, a su vez, tiene unos requerimientos de potencia considerables. El microcontrolador mbed se encuentra en el corazón del hardware, y es lo que permite que la información salga de la PC a través de un único cable Ethernet, y llegue finalmente a los 600 puntos, a cada uno la parte que le corresponde, en forma ordenada y segura. Esta información puede cambiar, de hecho, hasta 25 veces por segundo (25 frames per second, fps). Los controladores de potencia permiten “combinar” esa información con la energía eléctrica proveniente de las fuentes de alimentación (las 8 fuentes de PC, que suministran el poder necesario para iluminar todos los LEDs), y también, gracias a que se pueden conectar en cadena [los controladores de LED], simplifican la tarea de distribuir la señal a los 600 puntos, reduciendo el cableado necesario para ella.

El microcontrolador mbed se encuentra instalado en un PCB (circuito impreso) que expone sus conexiones, y posee un firmware, o sea, un programa con el que realiza sus tareas. Ambas partes son de desarrollo propio (de hecho, se trata del famoso Artnet Light Controller). Los controladores de potencia y los LEDs que se usaron en Celebra, en cambio, fueron comprados (a la firma Macetech, en USA).

Artnet Light Controller.

El software que corre en la PC es completamente original, de desarrollo propio, y está formado por 2 partes: el servidor y los clientes. El servidor es la aplicación principal; actúa como una mesa de control encargada de recibir la información de todos los clientes, mezclarla, y enviar el resultado al mbed, a través una conexión de red. Los clientes, por su parte, son los que implementan las conductas visuales propiamente dichas, ya sea reactivas a sensores, o generativo-algorítmicas. Esta arquitectura (cliente-servidor) se aplicó para facilitar el trabajo en equipo, dividiendo el problema total en partes que pudieran ser desarrolladas independientemente.

Diferencias entre Celebra y Barcelona

“Barcelona” es, desde el punto de vista técnico, una evolución de Celebra. Los bloques son exactamente los mismos, pero cada uno de ellos experimentó un proceso, que en la práctica significó muchas mejoras con respecto al sistema original. Algunas de estas mejoras ya se venían aplicando en las últimas exhibiciones de Celebra (en el 2012, Celebra estuvo en Ingeniería de Muestra, en la Facultad de Ingeniería, y posteriormente en el Liceo nº 61 del Cerro, en el marco del programa de difusión de la ciencia y la tecnología impulsado por Pro Ciencia).

Otras mejoras fueron implementadas expresamente para la nueva instalación, Barcelona, que fue encomendada por Uruguay Encendido para acompañar la conferencia de Singularity University en el Hotel Sofitel (ex Casino Carrasco), en abril de este año. (Dicho sea de paso, y como no podía ser de otra manera, la odisea de la instalación en sí, es digna de un relato aún más sorprendente de lo que fuera el de la planta del CCE [Aeropónica] en el 2010, o el de Celebra mismo; con situaciones como tener que armar 12 controladores de LED y recibir la importación de componentes faltando menos de 24 horas para la inauguración, y en ese momento comprobar que muchos de los componentes que vinieron, entre otras cosas, no eran los que habíamos pedido, etc., etc.. Es una historia realmente inverosímil, pero no la voy a contar esta vez…).

Preparativos de la conferencia de Singularity University en Montevideo.

Volviendo a las mejoras que sufrió el sistema de luces de Celebra para volverse el de Barcelona, ellas son, en síntesis, las siguientes:

  • los controladores de LED que estamos usando ahora son fruto de un desarrollo propio. Los llamamos –informalmente– “bondibar”; son parecidos a los de Macetech pero soportan mucha más potencia, son de menor tamaño, y cuentan con conectores USB para los cables de datos, una cosa que en el pasado nos diera grandes dolores de cabeza.

Nuevo controlador de LEDs RGB desarrollado por Bondi.

  • Asimismo, los LEDs que usamos ahora también son distintos; se trata, en realidad, de tiras de LED RGB estándar, que son mucho más económicas y permiten escalar la potencia lumínica que la aplicación requiere, simplemente poniendo más o menos metros de tira de LED, según el caso.
  • Se mejoró mucho el software del servidor, y se desarrollaron clientes nuevos, por ejemplo el cliente de Kinect y el nuevo cliente de audio (del cual voy a hablar en detalle más abajo). También se desarrolló una aplicación que permite visualizar y controlar la instalación desde un dispositivo Android.

“BondiApp”, aplicación para móviles y tablets Android.

El dodecaedro pentakis, o pentaquis dodecaedro, es uno de los 13 sólidos de Catalan.

Por otro lado, la instalación Barcelona tiene un aspecto geométrico muy característico, y este hecho fue aprovechado convenientemente. Me explico: el software de Celebra disponía ya de la posibilidad de trabajar sobre un modelo 3D de la instalación real… Pero, para sacarle provecho a esta característica, es necesario conocer la ubicación espacial exacta de cada fuente lumínica de la instalación. En el caso de Celebra, con sus 200 globos, que ocupan unos 150m2, esto se volvía realmente muy difícil de lograr. Pero en Barcelona, una instalación comparativamente más pequeña, donde lo que se ilumina –los “pixels”–  son las aristas de un poliedro cuya geometría es bien conocida (el dodecaedro pentakis, un sólido de Catalan), estaban dadas, en cambio, las condiciones para explotar esta característica “a full”. El único requisito –que se cumplió estrictamente, aunque no sin esfuerzo– era numerar una por una las aristas del poliedro, y saber a qué salida de qué controlador estábamos conectando cada arista. De este modo, los patrones geométricos que despliegan, por ejemplo, el cliente de audio o el de kinect, son respetados exactamente en la geometría de la instalación real, creando un grado de sofisticación en los efectos que nunca antes habíamos tenido.

Estructura de hierro, con las aristas identificadas a efectos de mapear correctamente las imágenes.

Detalle de la unión de las 3 pirámides pentagonales, mediante precintos plásticos (“sunchos”).

La instalación física

En Barcelona se utilizaron 12 de los nuevos controladores de LED, ubicados en una tabla al pie del “dodecaedro”. De esa tabla salen 90 cables (de 4 conductores cada uno), cada uno de los cuales se dirige a una de las 90 aristas del poliedro. El poliedro es una estructura de hierro formada por 12 pirámides de base pentagonal, que al ser acopladas entre sí (mediante “sunchos”) forman el esqueleto del pentaquisdodecaedro. En cada arista de este poliedro hay un tramo de tira de LED RGB de 45 centímetros (con aproximadamente 7W de potencia), rodeado por un difusor cilíndrico de papel (estos difusores fueron construidos a mano, uno por uno). Junto a la tabla de controladores se encuentran las 4 fuentes de PC que dan energía a todo el conjunto. El resto de la instalación es similar a Celebra, aunque con significativos avances en la parte de software.

Tabla de controladores de LED. Obsérvese el mbed en el centro (desenfocado).

Los 90 cables que van de la tabla al poliedro (no estaban todos conectados aun).

Proceso de colocación de los difusores, casi terminado.

El cliente de sonido

El nuevo cliente de sonido forma parte de estos avances, y representa mi primera intervención en el software de alto nivel del proyecto. Hasta ahora, mi participación en los proyectos de Bondi se había limitado a la electrónica y programación de bajo nivel, es decir microcontroladores, Arduino, mbed, etc. En esta oportunidad, debido al escasísimo tiempo con que contábamos, quedó en mis manos la tarea de programar un nuevo cliente (en virtud, talvez, de mi supuesta experiencia en el tema del sonido).

El cliente de sonido es lo que se ve en la mayor parte del vídeo (aunque, por la forma en que éste fue producido, no se pudo dejar el audio que originalmente generó esas imágenes). Es un programa que reacciona al sonido proveniente del micrófono de la PC, generando a partir de él diversos patrones y colores, aunque también es capaz de generar efectos no asociados a ningún estímulo. Todo su comportamiento se puede configurar en un panel densamente poblado de botones y valores para ajustar, del cual voy a intentar dar cuenta en el apartado siguiente.

Advertencia: lo que sigue es muy técnico, largo y aburrido. Sí, más que lo anterior.

Los clientes, en nuestro sistema, son pequeños módulos programados en C++, utilizando la herramienta OpenFrameworks. El servidor envía a cada cliente la lista de píxeles de la instalación, con sus respectivas coordenadas espaciales, y de esta manera, los clientes pueden modificar a gusto el color de cada pixel individual. La ubicación del pixel corresponde, en este caso, al punto medio de cada arista del poliedro.

Software “servidor” corriendo en una portátil.

La primera idea que me surgió, al enfrentarme a la tarea que se me había asignado, fue la de mover un punto por la superficie de una esfera circunscrita al poliedro, y colorear todos los píxeles (o sea, las aristas) en función de su distancia a ese punto. Consulté a Chachi sobre la posible implementación de un algoritmo como este, y, más allá de que no existía una manera demasiado elegante de llevarlo a cabo, a él le pareció una buena idea, así que seguí trabajando en esa dirección. Finalmente, esta idea resultó ser la que quedó, y es la base de todo el funcionamiento del cliente de audio.

A esta altura alguien se podrá preguntar: ¿qué tiene que ver un punto que se mueve por la superficie de una esfera con el sonido? Bueno, el punto se mueve y va coloreando los píxeles a su paso… Ahora bien, hay muchas maneras, muchas opciones para hacer esto; por ejemplo: ¿qué camino describe el punto? ¿a qué velocidad se mueve? ¿hasta qué distancia llega a colorear? ¿y de qué color? etc. Estas opciones, que son realmente muchas, están representadas en el programa por un juego de variables, algunas de las cuales podrían ser alteradas –de alguna manera– en función del sonido, para lograr algún efecto… Pero cuando decimos “en función del sonido”, aparece allí otro juego de variables, que determina justamente qué parte del sonido se usa y de qué manera se usa. Vemos entonces que surgen montones de variables, y el “arte” está en encontrar para cada una de ellas un rango y una forma de variarla –o no– que produzca efectos “interesantes”. En mi caso, yo llegué rápidamente a unos efectos que me gustaban, y la mayor parte del tiempo la dediqué a refinar el programa, dotarlo de un interfaz usuario (GUI) que permitiera controlar cómodamente todas las opciones, y seguir, por último, agregando pequeños detalles y accesorios, tanto al algoritmo como al GUI.

Ejemplo de luz que decae y cambia ligeramente de color con la distancia.

A grandes rasgos, el comportamiento básico del cliente de audio podría describirse de esta manera: existen 7 “puntos esféricos”, cada uno de los cuales está controlado por una banda de frecuencia del sonido (agudos, graves, medios, etc.). Cada punto tiene un rango de influencia, que provoca una mancha de mayor o menor tamaño en una zona del poliedro. Esta mancha se va moviendo de forma “controladamente aleatoria” (describiendo una suerte de movimiento browniano generado con la función ofNoise() de OpenFrameworks) por la superficie del poliedro (en realidad, de la esfera), y mientras lo hace puede ir cambiando gradualmente de color. A su vez, su zona de influencia decrece con la distancia, y puede también cambiar el color en función de la distancia. El sonido –de la banda de frecuencia correspondiente– afecta a la mancha, típicamente de las siguientes maneras: aumentando su tamaño, aumentando la intensidad lumínica, aumentando la velocidad del movimiento y aumentando la velocidad del cambio de color (aunque también puede afectar negativamente a cualquiera de los 4 parámetros, o sencillamente no afectarlo).

Lo que me gusta de este algoritmo es que la influencia del sonido… ¡es muy indirecta! Es perfectamente notoria, pero es indirecta; por eso el efecto resulta sutil, controlado y agradable. Este es para mí el gran secreto. Si yo hubiera optado por –pongamos el ejemplo diametralmente opuesto (y absurdo)– tomar cada valor del buffer del sonido (la información temporal) y controlar con ello la posición, la intensidad, o el color de unos cuantos píxeles, el resultado hubiese sido, inexorablemente, un parpadeo aleatorio, incomprensible y en última instancia, aburrido.

La clave, entonces, es, primero que nada, procesar el audio para extraer valores perceptivamente relevantes (la energía en una banda, por ejemplo), y en segundo lugar, asignar esos valores a variables también perceptivamente claras. Para lo primero utilicé mis aun rudimentarios conocimientos de DSP: hay por allí una rutina de FFT que encontré en la web, pero hay también una especie de algoritmo de Constant-Q (muy chancho, pero aparentemente efectivo), que transforma los 256 puntos de la FFT en las 7 bandas perceptivamente equiespaciadas que finalmente se usan. Y algo que es vital: pasar la energía de cada banda por una función logarítmica, para adaptarla a la escala de sensibilidad dinámica del oído (o sea, en una palabra, trabajar en dB), y aplicarle luego un filtro LPF (pasa bajos), a efectos de controlar qué tan rápido responde el parámetro controlado (por ejemplo, el tamaño de la mancha o su velocidad) a las variaciones en la señal de control, vale decir, las variaciones en la energía de la banda correspondiente.

En lo que respecta a la parte del algoritmo que no es audio, es decir, el comportamiento de los “puntos esféricos” en sí, hay también algunos secretos que me ayudaron mucho, y me gustaría comentar:

  • un detalle interesante, por ejemplo, es que los puntos, ya que se mueven por la superficie de una esfera, lo hacen en 2 dimensiones: latitud y longitud (como si fueran las propias coordenadas terrestres). Pero para calcular luego la distancia a cada arista del poliedro, se utilizan las coordenadas “normales” (cartesianas) X, Y, y Z. Para convertir de unas a otras, se usa la fórmula que podemos encontrar en la inefable Wikipedia.
  • otro gran descubrimiento es la función ofNoise() de openFrameworks, de la cual hice uso y abuso. El movimiento de los puntos, los cambios de color, montones de cosas en el programa están hechas con ofNoise(). Me encantó esa función; no me fijé cómo está implementada, pero me gustaría tenerla en otros ámbitos de programación (Arduino, por ejemplo).
  • y respecto al color, una cosa muy simple pero muy importante: trabajar el color siempre en HSV (hue, saturation, value). Talvez lo que voy a decir es muy obvio, pero el HSV es “la hostia”: perceptivamente hablando, el HSV es mucho más expresivo que el RGB, como lo es en el audio el espectro contra la información temporal.

Captura del cliente de sonido, con todos los parámetros de 1 banda desplegados.

Nota 1: la visualización del poliedro en el cliente de audio forma parte del interfaz común de todos los clientes; eso no lo hice yo, sino que es parte del “SDK” para desarrollar clientes que hizo Chachi. Allí está resuelta también la comunicación de los clientes con el servidor, el cual, por su parte, es también casi íntegramente obra de Chachi (en colaboración con Tom).

Nota 2: si me preguntan por qué el interfaz del programa está en inglés, la respuesta talvez no sea la que se imaginan. Yo escribo siempre todo en español, dentro del código los comentarios en español, soy partidario del español (y además, no sé inglés). Pero al momento de hacer un GUI, lo mismo que para ponerle nombres a las variables, muchas veces, resulta que en inglés todas las expresiones son mucho más cortas, y no hay manera de ponerlo en español sin consumir el doble de espacio (o más). Si uno opta por poner las palabras abreviadas, al final no se entiende nada y es mucho más claro en inglés.

Con respecto a la descripción del vídeo que está al principio, eso es “harina de otro costal”, ya que no la escribí yo.

Be Sociable, Share!

5 Comentarios »

  1. avatar Alfredo Bianchi Dice:

    ¿ Es posible ver a Barcelona en Montevideo? Por favor contactar
    Saludos

  2. avatar pabloxid Dice:

    Hola Alfredo, gracias por tu interés.
     
    La obra está completamente desarmada, de modo que ya no es posible verla, pero no se descarta que pueda volver a existir, si algún evento lo requiere.
     
    Costaría un trabajo enorme volver a construirla, tal vez no tanto como la instalación original, ya que algunas partes -como la estructura de hierro- aun las conservamos, pero sin duda sería costoso.
     
    Ojalá que se dé, la verdad que me muero por ver esa pelota andando nuevamente…

  3. avatar pabloxid Dice:

    Les dejo el vídeo documental de Celebra en Sydney (en el ISEA 2013). Esto fue al poco tiempo de la instalación Barcelona, yo no fui, fueron Tom y Chachi, pero como ven, se usó toda la parafernalia aquí descrita 🙂

  4. avatar Sendero: A lighting system for artistic production | Sendero Dice:

    […] Sendero, is an integral lightning system created by Christian Clark,Tomás Laurenzo y Pablo Gindel in the frame of the construction of new media art. In the first iteration, the Facultad de Ingeniería’s MediaLab developed two great artworks Celebra and Barcelona. […]

  5. avatar MVDrobotics Dice:

    Prueba del cliente de audio:

RSS alimentación de los comentarios de esta entrada. TrackBack URL

Dejar un comentario