ArtNet Light Controller

Desde fines del 2010 vengo trabajando en un proyecto para Tangible Interaction (la empresa de mi amigo Alex Beim, en Vancouver) consistiente en un controlador de luces RGB, del cual les voy a hablar en este artículo. Comenzaré explicando algunos fundamentos técnicos de bajo nivel, para introducir luego el dispositivo que estamos desarrollando, y finalmente mostraré algunas instalaciones que hemos hecho utilizando esta tecnología.

LEDs RGB

El LED ha tenido un gran desarrollo en las últimas décadas, sustituyendo progresivamente a otras tecnologías en diversas áreas. Sin hablar ya de los displays, en lo que se refiere a LED discretos, podemos encontrar hoy en día unidades de gran luminosidad y múltiples colores, incluyendo por supuesto infrarrojos y ultravioletas.

Los LEDs RGB existen en el mercado hace tiempo, y consisten simplemente en tres LEDs que comparten un mismo encapsulado (y uno de sus terminales): un LED de color rojo (Red), uno verde (Green) y otro azul (Blue). La síntesis de color RGB es ampliamente utilizada en displays, pantallas, proyectores y televisores de todo tipo (incluso en los viejos televisores de tubo) y se basa en las características de nuestro propio sistema visual: las células llamadas “conos” presentes en nuestra retina, tienen sus picos de sensibilidad justamente en las frecuencias de estos 3 colores.

De este modo, podemos iluminar un LED RGB del color que deseemos, simplemente regulando el brillo individual de cada uno de sus 3 componentes. En instalaciones de mayor potencia, ya no es necesario usar LEDs RGB propiamente dichos, sino que suelen utilizarse múltiples LEDs discretos de cada uno de los 3 colores básicos, todos ellos incidiendo simultáneamente sobre una misma zona.

LED RGB estándar

PAR (parabolic aluminized reflector) compuesto de múltiples LEDs rojos, verdes y azules

Ahora bien, cuando hablamos de regular –controlar, variar, dosificar– el brillo de un LED, en realidad estamos aludiendo a una tarea que no es tan sencillo llevar a cabo, como veremos a continuación.

LED drivers

Como muchos dispositivos electrónicos, el LED funciona dentro de un margen muy ajustado de voltaje e intensidad, y no es variando estas magnitudes que se consigue controlar eficientemente su brillo, sino mediante la conocida técnica del PWM (modulación del ancho del pulso). El PWM está explicado en cuanto sitio de robótica y/o microcontroladores existe en la web –hay una buena explicación en el sitio de Arduino, sin ir más lejos– por lo tanto no me voy a detener en él en esta oportunidad.

Explicación del PWM sacada del sitio de Arduino

 

Los microcontroladores (otro concepto que no voy a explicar hoy), incluyendo la placa Arduino, suelen tener algunas salidas PWM entre sus múltiples funciones, pero estas salidas carecen de potencia y no es recomendable alimentar directamente con ellas un LED (excepto cuando se trata de meros indicadores, como los LEDs que están en la propia placa, el de encendido, los de TX/RX, etc.). Por esta razón, existen en el mercado circuitos integrados conocidos como LED drivers, categoría a la que pertenecen el Worldsemi WS2801 y el Allegro A6281, chips que mencionaremos recurrentemente a lo largo de este artículo.

Circuito integrado WS2801

Circuito integrado A6281

De hecho, estos dos integrados hacen mucho más que alimentar un LED. Tanto el WS2801 como el A6281 pueden manejar 3 LEDs de hasta 1W cada uno (un LED de 1W emite una luz considerable), generando ellos mismos las señales PWM, a partir de un control digital externo que se puede efectuar desde cualquier microcontrolador, mediante una conexión serial (tercer concepto que no voy a explicar [y último que aviso]). Y ahí no termina la cosa: ambos integrados disponen, además, de una manera de conectar varios de ellos en “cadena”, de tal modo que se puedan controlar múltiples LEDs RGB con una única señal.

DMX512

Resumiendo lo que sabemos hasta ahora: existen sistemas de LEDs RGB, que pueden llegar a ser de considerable potencia, y existen también integrados “manejadores” que, conectados adecuadamente (en cadena), nos permiten controlar un conjunto de luces RGB independientes, asignando a cada una de ellas un color arbitrario. Este control lo podemos efectuar desde el microcontrolador, utilizando un protocolo serial (luego vamos a ver que se trata de un serial sincrónico, o SPI) o eventualmente desde una computadora.

En el mercado profesional de iluminación de espectáculos (shows, escenarios, discotecas, etc.) existe un protocolo equivalente a lo que es el MIDI en la música. En efecto, el DMX512, o simplemente DMX, es un estándar que permite conectar consolas de luces (controladores) y luces propiamente dichas, entre otras cosas. Exactamente como ocurre con el MIDI, el “controlador” puede ser directamente una computadora, dotada de un interfaz DMX y un software apropiado.

Al igual que el MIDI, el DMX consta de cables unidireccionales, es un protocolo digital y serial (y más rápido, trabaja a 250.000 b/s, frente a los 31.250 del MIDI). El DMX es un poco más complejo en la capa física, pero muchísimo más simple en la “capa software”. Mientras que en el MIDI existen distintos tipos de mensajes y sistemas, en el DMX sólo existen los canales, y cada conexión puede transportar 512 de estos canales, cada uno de ellos con una resolución de 1 Byte (otra diferencia con el MIDI y sus clásicos 7 bits de resolución).

Pongamos un ejemplo: si cada canal de una conexión DMX se usara para controlar el brillo de un componente de una luz RGB, el protocolo nos permitiría manejar en total 170 luces independientes, cada una de ellas con una resolución de 24bits de color (512/3=170 [y sobran 2 canales]; 8bits x 3 = 24bits).

A pesar de su popularidad y simpleza, el DMX no está soportado directamente en los chips manejadores de LED, sigue siendo demasiado complejo para ellos. Lo mismo ocurre con el MIDI, son protocolos de “alto nivel”, vale decir, se necesita cierta “inteligencia” para hablar en esos lenguajes, y esta inteligencia nos la puede proporcionar un microcontrolador o, sin duda, una computadora.

ArtNet

Recapitulando: conocemos los LEDs RGB, los manejadores de LED “encadenables”, y el protocolo DMX. Un ejemplo de instalación que podemos hacer con todo esto sería el que presenta, a grandes rasgos, el siguiente esquema:

Diagrama en bloques de un posible controlador de LEDs RGB DMX

El protocolo DMX no es necesario per se, pero nos permite aprovechar una multiplicidad de productos que ya existen en el mercado (ese es el propósito de los estándares en electrónica). No obstante, estos productos suelen ser costosos, y por otro lado, hay que tener en cuenta que aplicado a leds RGB, un sistema DMX sólo nos permitiría controlar 170 de ellos (como vimos más arriba).

ArtNet es una evolución del DMX512, precisamente lo que podríamos llamar un DMX-over-Ethernet, o DMX-over-IP. Se trata de sustituir la capa física costosa del DMX, por la infraestructura de redes estándar de hoy en día, que es eficiente, económica y versátil. Algunas de las ventajas de ArtNet sobre el DMX clásico son las siguientes:

  • ancho de banda muy superior (10/100/1000 Mb/s contra 250 Kb/s);
  • la conexión es bidireccional;
  • soporta distancias mayores;
  • permite usar hubs, routers, WiFi, etc., es decir, múltiples opciones de conectividad;
  • supera el límite de los 512 canales; en ArtNet un conjunto de 512 canales se denomina “universo”, y pueden viajar muchos de ellos por la misma conexión;
  • la infraestructura de red es muy común y de costo prácticamente despreciable.

Luminair, aplicación para iPad que soporta ArtNet

Todo junto

Alex Beim venía trabajando con LEDs RGB alimentados con el WS2801, y quería contar con un dispositivo que permitiera controlar una cadena de estos LEDs desde el PC, utilizando el protocolo ArtNet. Fue así como surgió el ArtNet Light Controller, que actualmente se encuentra en la versión 8.

El ArtNet Light Controller puede operar con un total de 680 luces RGB (4 universos) a 30 cuadros por segundo (30 fps; es decir que cada luz puede cambiar de color hasta 30 veces en un segundo). Las luces pueden estar distribuidas en hasta 32 cadenas; cada cadena puede tener distinto largo y estar basada en cualquiera de los chips manejadores –WS2801 o A6281– indistintamente. El dispositivo posee, además, una salida DMX estándar y dispone de un interfaz web para configurarse remotamente desde el PC, aprovechando la conexión de red necesaria para la comunicación ArtNet. El soporte ArtNet es completo, e incluye los mensajes “ArtNetPoll”, gracias a los cuales otro software puede detectar la presencia del dispositivo en la red, y tomar su configuración automáticamente.

Características técnicas del Artnet Light Controller

Aunque la Arduino es mi tarjeta favorita de todos los tiempos, en esta oportunidad no le fui fiel. Para este proyecto utilizamos una placa distinta (y, en cierto modo, rival de la Arduino): la mbed NXP LPC1768. La razón principal es que necesitábamos un puerto Ethernet, y la mbed ya lo trae incluido, a un costo inferior al que resultaría de sumar una Arduino y un Ethernet Shield. Por otro lado, la mbed ofrece mucho más poder computacional: procesador ARM Cortex-M3 de 32bits a 96MHz, 512 KB de memoria flash, 32 KB de RAM, múltiples interfaces que incluyen –además del Ethernet– USB host/device, CAN, SPI, I2C, USART, por supuesto entradas y salidas analógicas y digitales (estas últimas con PWM), una unidad flash adicional con sistema de archivos, accesible tanto externa como internamente, y todo esto ocupando un espacio físico similar al de una Arduino Nano.

Tarjeta mbed NXP LPC1768

Conexión directa de un cable Ethernet a la mbed.

Funciones de los pines de la mbed

Existe una tercera razón por la que descartamos Arduino, pero antes de mencionarla tengo que explicar un poco más en profundidad el funcionamiento de los chips manejadores de LED. Más arriba dije que el WS2801 y el A6281 utilizaban un tipo de comunicación serial sincrónica, ¿recuerdan? El serial sincrónico (o síncrono), a diferencia del TX/RX clásico de los microcontroladores (UART), utiliza una línea especial de CLOCK, mediante la cual se sincronizan transmisor y receptor. Cuando llenamos un registro de desplazamiento –un shift register, 74595– en Arduino, por ejemplo, con el comando shiftOut, estamos usando serial sincrónico. De hecho, esta es una forma habitual de hacerlo, pero no es la más eficiente. El interface SPI hace lo mismo que el “shiftOut” pero utilizando el hardware interno del microcontrolador, lo que permite comunicaciones a altas frecuencias –8MHz en la Arduino, más de 20MHz en la mbed– sin consumir prácticamente ningún recurso.

Comunicación SPI entre 1 maestro y 3 esclavos (sacado de Wikipedia)

Cuando abordé por primera vez este proyecto, lo hice con Arduino, y desde un principio me planteé utilizar SPI para “hablarle” a las luces. Esto funcionó bien en las primeras pruebas, mientras la comunicación desde el PC la hacíamos por USB/serial (ver video 1). Cuando llegó el momento de integrar el Ethernet Shield, para implementar el soporte ArtNet, me topé con un problema, no imposible de resolver, pero sí bastante desanimador: el Ethernet Shield también utiliza SPI, y la placa tiene únicamente un puerto SPI. Esto fue, digamos, la gota que derramó el vaso, e inclinó la balanza definitivamente a favor de la mbed (por decirlo con metáforas un tanto trilladas).

 

Imagen de previsualización de YouTube

 

Múltiples salidas

Una idea interesante que manejamos desde el inicio, fue la de dotar al aparato de varias salidas para cadenas de luces (4 en un principio, 32 en la versión actual). Supongamos que tenemos 600 luces dispuestas formando una matriz de 25×24, o sea, en definitiva, una pantalla de LEDs RGB. Podríamos conectar dichas luces formando una única cadena en forma de “S” (lo que llamamos “una viborita”) y así utilizar una única conexión desde el microcontrolador, pero esto acarrearía básicamente dos inconvenientes (sin contar el hecho de que las filas pares e impares quedarían inversamente orientadas entre sí, que se resuelve fácilmente en el software): por un lado, el cableado puede resultar engorroso (no tanto en el ejemplo de la matriz, pero sí al utilizar otras disposiciones espaciales) y por otro lado, al tener una única cadena, si uno de los “eslabones” sufre un desperfecto, todo el resto de la cadena se va a ver afectado. Por ejemplo, si se corta el cable que une el manejador del LED 48 con el del 49, todos los LEDs desde el 49 hasta el 600 van a quedar sin señal. Evidentemente, tendremos un control mucho más eficiente y ordenado si utilizamos 24 cadenas de 25 luces cada una, usando una conexión distinta para cada fila.

Ventana de configuración del MADRIX (software de control de LEDs que usamos en el laboratorio). Obsérvese la opción "snake" (víbora)

La técnica para lograr múltiples salidas usando un único puerto SPI (aunque la mbed tiene dos, pero con uno solo nos alcanza) consiste en multiplexar las señales de CLOCK. Todas las otras señales son comunes a todas las salidas, mientras que el CLOCK va alternando entre ellas; se habilita en una salida y se apaga en todas las otras, luego rota a la siguiente, y así sucesivamente. La mbed “sabe” el número de luces que se encuentran conectadas en cada salida –gracias al archivo de configuración en donde el usuario tiene que declararlo– y de este modo el programa envía la cantidad exacta de pulsos de clock en cada salida, a efectos de actualizar únicamente las luces que están conectadas allí. Los mismos datos llegan a todas las salidas simultáneamente, pero sólo “penetran” en la que tiene activo el CLOCK.

Primera aproximación a la idea de varias salidas, que manejamos con Chachi para el proyecto "Celebra"

Pero en realidad hay una única señal de CLOCK; el programa se encarga de enviarle oportunamente una señal a una electrónica externa, para que conmute ese clock de una salida a la otra. La demultiplexión –así se llama ese proceso– se hacía, en la versión de 4 salidas, con un 74HC08, es decir con 4 puertas AND. Posteriormente, en la v7 pasamos a utilizar 4 demultiplexores 74HC238, para obtener 32 salidas. En la v8 volvimos al 74HC08, tenemos 4 salidas en el módulo principal, y la posibilidad de conectar en cada una de ellas un módulo expansor con un 74HC238, que obtiene 8 nuevas salidas a partir de una.

Toda esta electrónica, junto con los conectores, la propia mbed, un regulador de voltaje y el chip para la conexión DMX, están dispuestos en un PCB que yo diseñé utilizando Eagle, y que ha tenido sucesivas revisiones.

PCB v.5, con todos los componentes

PCB v.6, con algunos componentes

PCB v.7 con 12 de sus 32 salidas activadas

Diseño del PCB v.8, con el módulo expansor

Soporte para distintos tipos de cadenas

Como dijimos más arriba, nuestro aparato puede trabajar con los dos manejadores de LED que ya conocemos: el WS2801 y el A6281. Si bien se trata de chips diseñados para cumplir un mismo propósito, existen algunas diferencias entre ellos. En primer lugar, la técnica de direccionamiento (es decir, cómo se hace para mandar información distinta a chips distintos dentro de una misma cadena) difiere entre ambos. En el WS2801, cada integrado guarda los primeros 24 bits que le llegan y a partir de ese momento repite por su salida todo lo que le entra; de este modo, los primeros 24 bits que se mandan van al primer LED, los siguientes al segundo, y así sucesivamente. Para reiniciar el conteo, simplemente hay que dejar de enviar información durante 500µs. En el A6281, en cambio, toda la cadena se comporta como un inmenso shift register, de modo que los primeros bits recibidos van a parar al último LED de la cadena, los siguientes al penúltimo, etc., y al terminar la transmisión hay que activar una línea especial llamada LATCH, para que todos los LEDs tomen simultáneamente el color almacenado en los registros (de esto se deduce que, tanto con el WS2801 como con el A6281, es imposible modificar una dirección aislada dentro de la cadena, nuestra única opción es siempre actualizar toda la cadena junta; lo mismo ocurre con el protocolo DMX y sus 512 canales).

También difieren el orden de los colores, entre ambos chips, y la resolución: el A6281 tiene una resolución de 10 bits por canal, mientras que, como vimos recién, en el WS2801 la resolución es de 8 bits por canal. Nótese que, de todas maneras, la resolución interna del software es de 8 bits, que es la que impone el propio DMX.

Puerto DMX estándar

Para implementar la salida DMX física utilizamos, en un principio, un circuito integrado MAX485, que es lo que se conoce como un transceptor TTL-serial <-> RS-485. Desde el punto de vista de su capa física, el DMX utiliza un estándar de comunicaciones en bus llamado RS-485, muy utilizado también en otras aplicaciones y muy interesante, del cual les hablaré en otra oportunidad. En la versión 8 del Artnet Light Controller pasamos a utilizar un MAX490, que permite obtener una salida y una entrada simultáneas (se dice que opera en full duplex).

Utilización del MAX485 para obtener una salida DMX

Conexión del PCB v.6 a un conector XLR-3, comunmente usado en DMX

Conexión del PCB v.7 al tacho que me prestó Marcelo Vidal (VJ chindogu)

Firmware

Bien, ya hablamos bastante del hardware, y sería un capítulo aún más largo hablar del software, es decir del firmware que hay en la mbed para que todo esto funcione. Echémosle un vistazo superficial; el programa podría esquematizarse en los siguientes bloques:

Diagrama en bloques del firmware (está en inglés porque las palabras son más cortitas)

Algunos de estos bloques forman parte de la propia biblioteca de mbed, otros están basados en bibliotecas de usuarios, también disponibles en el sitio de mbed, o en fragmentos de código C++ que encontramos por ahí, y también hay módulos íntegramente escritos por nosotros (lo que está representado en color azul, en principio). El gran mérito de ensamblar todo esto y hacerlo funcionar por primera vez pertenece a Jorge Visca, que también trabajó en el proyecto durante la primera etapa. El módulo “ArtNet” es completamente obra suya, por ejemplo. “Luces”, en cambio, es mayoritariamente mío (sin duda lo que se me da mejor –como dicen los españoles– a la hora de programar, es “interfasear” con el hardware). El web server (junto con el stack TCP/IP) pertenece a la biblioteca NetServices (que a su vez hace uso de la lwIP), pero nosotros le modificamos la implementación de algunos servicios, además de alivianarla todo lo posible.

Interface web de configuración del ArtNet Light Controller

Hubo que optimizar mucho este motor básico para lograr la performance que queríamos: 4 universos a 30 fps, o sea un tráfico aproximado de 500 Kb/s. Puede parecer trivial, pero no olvidemos que estamos trabajando en un microcontrolador, al final de cuentas, no en una PC, y además, existe una dificultad extra a tener en cuenta: cada universo viaja en un paquete UDP, cuyo tamaño es de un poco más de 512 Bytes, pero el problema es que, a efectos de que todo el “frame” se actualice al mismo tiempo, los 4 paquetes se mandan prácticamente juntos y no repartidos en los 30ms que separan un frame del siguiente. Quiere decir que, si bien el tráfico promedio es de 500 Kb/s, el tráfico instantáneo real, por momentos llega a ser muchísimo más alto.

Bueno, llevo escritas ya 6 páginas, y aún podría decir mucho más sobre los aspectos técnicos de este proyecto, pero no lo voy a hacer, quédense tranquilos. Llegó el momento de hablar de las instalaciones, como prometí al principio, así que ahí voy… Casi al mismo tiempo, en noviembre de 2011, se estrenaron estas dos instalaciones artísticas, una en Vancouver, Canadá, la otra aquí en Montevideo, que comparten el hecho de usar el Artnet Light Controller como soporte fundamental.

 

Jelly Swarm

Imagen de previsualización de YouTube Imagen de previsualización de YouTube

Jelly Swarm (“enjambre de medusas”) es una intervención hecha por Tangible Interaction en el Acuario de Vancouver, por encargo de dicha institución. Consiste en 94 medusas de origami (realizadas por el artista Joseph Wu) con módulos LED en su interior, que cuelgan de una sofisticada estructura de aluminio, evocando a las medusas luminosas de la costa de British Columbia. La instalación está controlada por un software desarrollado en Flash, y dispone de una pantalla táctil que permite a los visitantes interactuar con las medusas, afectando sus patrones de luz y color; si ningún usuario interviene, el sistema despliega patrones generativos.

El proceso llevó 2 meses de diseño, programación y fabricación, y tres días de instalación en el acuario mismo; la obra permanecerá allí hasta fines de febrero de 2012. No puedo decir mucho más sobre esta instalación, la hizo Alex con su equipo allá en Vancouver, pero lo que es seguro es que usaron el Artnet Light Controller a full, concretamente la versión 5, y con un enlace WiFi. Muy buen trabajo, por cierto.

Página oficial del proyecto: http://tangibleinteraction.com/jelly-swarm/

Otros links:

http://www.designboom.com/weblog/cat/8/view/18189/jelly-swarm-interactive-origami-lighting-installation.html

http://www.creativeapplications.net/air/jelly-swarm-air/

 

Celebra

Imagen de previsualización de YouTube

Esta otra instalación se hizo en el Patio Norte del Espacio de Arte Contemporáneo (Arenal Grande 1930, Montevideo, ex cárcel de Miguelete) y consistió en una nube de 200 globos luminosos, controlados por un software modular que permitía diversos tipos de interacción. Estuvo a cargo del colectivo “Bondi” (Tomás Laurenzo, Christian Clark, Fabricio Devoto y quien suscribe) y contó con el apoyo de diversas instituciones, entre ellas la Comisión del Bicentenario de Uruguay.

Yo estuve a cargo de la parte electrónica, y cometí algunos errores. Utilizamos las luces modulares de Macetech, 25 octobars y 200 módulos Satellite S-001, de 3W cada uno. No contábamos con el PCB de Tangible Interaction (debe estar todavía descansando en los anaqueles del depósito de la aduana, en el aeropuerto), sí con la mbed, por lo que las 200 luces estaban conectadas formando una única cadena (con los riesgos que, como vimos, ello implica). La alimentación se hizo con fuentes de PC, y no falló. Lo que sí falló fueron los cables de datos que conectaban los octobars entre sí, eran demasiado largos, y estaban expuestos a todo tipo de interferencia. Siempre lo supe, y no me canso de repetirlo en mis cursos, mandar datos a la distancia no es “moco de pavo” (como diría nuestro presidente). El cable es un componente pasivo muy completo, se comporta como resistencia, condensador, bobina, transformador, antena, “e ainda mais”. Afortunadamente, el tercer día de instalación logramos dominar lo que inicialmente era un caos.

El software desarrollado por Tom y Christian para esta obra, fue uno de los puntos interesantes de la misma. Consiste en un servidor hecho en C++, que se comunica con la mbed usando ArtNet, y acepta conexiones de clientes mediante sockets. Los clientes pueden estar programados en cualquier lenguaje, pueden correr en la misma computadora o en una computadora remota, en una tablet o un smartphone, incluso a través de internet (recurso que finalmente no se usó, de todas maneras). Los clientes son los que generan la información visual, ya sea algorítmicamente o a partir de la intervención del usuario o la interacción con el ambiente. El servidor se encarga de seleccionar y mezclar las fuentes apropiadas para generar la imagen final. Al momento de la instalación teníamos 3 o 4 clientes, uno de ellos reaccionaba al sonido, otro generaba patrones basados en el ruido Perlin, otro reproducía secuencias pregrabadas, etc.

Con respecto a la parte material de la instalación, tuvimos ciertas dificultades. Para empezar, fue imposible mantener inflados los 200 globos todo el tiempo, durante los 3 días que duró el evento. No sé si sirve como excusa decir que lo armamos todo en un día –el mismo día de la inauguración– pero así fue. Cuando llegué aquella mañana al inmenso patio abierto del EAC, lo único que allí había era una tímida estructura de alambre (que para colmo, a eso de las 4 de la tarde se rompió) y un sol que rajaba las tablas. Obviamente teníamos todo lo mejor preparado posible, pero la cantidad de imprevistos fue enorme y nos mató, por así decirlo. Sólo por poner un ejemplo, recuerdo que entre dos personas, nos llevó cerca de 2 horas solamente sacar los módulos LED de su envoltorio y conectarle a cada uno un cablecito que ya tenía la ficha RJ11 colocada.

De todas maneras, la instalación se hizo y fue un éxito, en gran medida gracias a la persona que tenía cada detalle del proyecto en su cabeza hasta el límite de lo posible, el verdadero hombre-bondi: Christian “Chachi” Clark.

Pruebas con Octobar y LEDs en lo de Chachi

(Fotos de Jimena Schroeder)

Artículo en farq: http://www.farq.edu.uy/patio/conferencias-exposiciones-y-seminarios/celebra.html

Pablo Gindel, 13-02-2012

Be Sociable, Share!

17 Comentarios »

  1. avatar chachi Dice:

    Dejo un videito adicional de Celebra.
    http://youtu.be/CwCzOff9Bbg

  2. avatar pabloxid Dice:

    …y otro de Jelly Swarm que me mandó Alex:
    https://vimeo.com/38108583

  3. avatar peripecio Dice:

    Bonito proyecto y muy buen trabajo. Además, lo has documentado muy bien.
    Felicidades.

  4. avatar pabloxid Dice:

    Muchas gracias.

  5. avatar ARTURO MARTINEZ Dice:

    HOLA PABLO BUENAS NOCHES ,EXCELENTE TRABAJO SE VE QUE SABES MUCHO DEL TEMA , TE MANDE UN CORREO ESPERO LO CHEQUES POR FAVOR .
    SALUDOS DESDE MEXICO

  6. avatar pabloxid Dice:

    Hola Arturo, muchas gracias.
    Recibí tu correo. Respecto al controlador por el que me preguntas, sí, entiendo que puede servir para conectar MADRIX con las cadenas de luces basadas en el LPD6803. Necesitas, de todas maneras, un interface de salida DMX del lado del PC. Por otro lado, DMX sólo te permite controlar 170 luces, excepto que uses varias conexiones.
    Lo ideal, obviamente, es usar ArtNet, que es lo que hicimos nosotros. No conozco el LPD6803, pero estimo que su manejo ha de ser muy similar al del WS2801 y el A6281. 
    Saludos,
    P.G.

  7. avatar francisco escobar Dice:

    pablo excelente trabajo yo estoy intentando realizar un proyecto de pista luminosa pero me gustaria ver si me podrias dar algunos consejos ya que tengo conocimiento pero no se por donde empezar podria agregarte a messenger o algun chat en verdad lo agradeceria gracias

  8. avatar pabloxid Dice:

    Muchas gracias, Francisco.
    Msn no tengo, búscame en Skype.

  9. avatar Samir Dice:

    pablo excelente Trabajo. Me gusta hacer casi lo mismo para el vídeo, el control de los leds por MADRIX. Pero cabe la menor duda, con MADRIX ejecución, utilice el conector USB, se conecta a la placa Arduino usando FTDI, RGBS desea controlar los LED. Pero no puedo controlar los colores. No quiero usar DMX. ¿Me puede dar un consejo?

  10. avatar pabloxid Dice:

     
    Samir:
    Si tienes una Arduino anterior a la UNO, de las que venían con el chip FTDI (por ejemplo la Diecimilla o la Duemilanove), el MADRIX la detectará como un interfase ENTTEC (OpenDMX). Lo único que tienes que hacer es usar un código que decodifique DMX, como el que puedes encontrar aquí:
    http://arduino.cc/playground/DMX/Ardmx
    y agregar el código SPI para comunicarte con el WS2801 (por ejemplo este: https://github.com/adafruit/Adafruit-WS2801-Library) o lo que sea que uses para controlar los LEDs.

  11. avatar beatrice Dice:

    Excellent post. I was checking continuously this blog and I’m impressed! Extremely helpful information particularly the closing phase :) I care for such info a lot. I used to be seeking this particular info for a long time. Thank you and good luck.

  12. avatar Un sólido de Catalán | Palmera blog Dice:

    [...] 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 [...]

  13. avatar Javier Dice:

    Hola Pablo. Genial la presentacion. Me gustaria contactarme con vos via mail, puede ser?

  14. avatar pabloxid Dice:
  15. avatar Polis Dice:

    Hi Paul, this is really something special very well presented and with so many details! Excellent job thank you so much for sharing, I really learned a lot even if I used translator to read the contents :)
    Can you suggest how to do a similar DMX controller using the same mbed NXP LPC1768 and connect to any open DMX512 software? How can we handle the USB drivers ?
    Thanks!!!
     

  16. avatar pabloxid Dice:

    Hi Polis, thanks for your comment.

    I really don’t know much about DMX softwares, beyond MADRIX. Mbed has a virtual UART (Serial) port over the USB connection; maybe you can use that UART port to communicate directly with DMX software. By the way, this also can be done in Arduino, take a look here:

    http://playground.arduino.cc/DMX/Opendmx#.UwoqJ9LuJ8E

  17. avatar Andres Tobon Dice:

    Pablo felicitaciones por tus proyectos realizados y gracias por la informacion;

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

Dejar un comentario