La popularidad de Arduino sigue creciendo a nivel mundial, y nuestro pais no es la excepción. Estudiantes, docentes, hobbistas, diseñadores, artistas, técnicos en electrónica, ingenieros y “un largo etcétera” de profesionales y aficionados se interesan día a día en este innovador proyecto, curiosamente originado en Italia hace unos cinco años.

Aunque la plataforma Arduino se caracteriza precisamente por hacer las cosas más fáciles, el usuario uruguayo se choca inevitablemente con un primer y gran problema al intentar acercarse a ella: la dificultad para conseguir el hardware (es decir, la tarjeta misma) a un precio accesible, en forma rápida, sin necesidad de contar con tarjetas de crédito internacionales, despachantes de aduana, y otro “largo etcétera” de molestias.

La primer idea que surge ante esta dificultad, más aun, tratándose Arduino precisamente de eso que llaman hardware libre, es la de construirse la placa uno mismo. El concepto de hardware libre implica que toda la información necesaria para aprestarse a esa tarea debe estar disponible al usuario en forma libre y gratuita. Sin embargo, quien haya tomado por ese camino, se habrá encontrado inmediatamente con una serie de nuevos obstáculos, casi todos sorteables con mayor o menor esfuerzo, excepto uno especialmente difícil de esquivar.

Casi toda la información disponible para construirse su propia Arduino, apunta al antiguo modelo de placa Serial. La funcionalidad USB de las placas más modernas, viene dada por un chip que no sólo es caro y difícil de conseguir, sino que -y en esto radica la dificultad de la que hablábamos- es de tecnología SMD (montaje superficial), lo cual significa que es prácticamente imposible de soldar por un humano.

Todas las placas Arduino, hoy en dia, están hechas casi por completo de componentes SMD, pero esos componentes suelen existir también en versiones con encapsulado DIP o estándar, que son los que podríamos soldar manualmente a una placa. Lamentablemente, esto no se cumple en el caso del chip FTDI, tradicionalmente usado para dotar al Arduino de conexión USB, ni en el de su sustituto en los nuevos modelos UNO, el ATmega8U2.

Como consecuencia de esto, toda iniciativa de armar una Arduino “casera” termina sacrificando casi inexorablemente la conectividad USB. Urduino es el resultado de años de experiencia e investigación en este terreno, buscando insistentemente una alternativa para superar esta limitación. De esta manera, Urduino se convierte en el primer clon de Arduino 100% compatible con los modelos actuales, fabricado en nuestro pais, y probablemente primero también para una amplia región del mundo. El secreto de su diseño se halla en el nuevo chip MCP2200 de Microchip.

Detalle del MCP2200 en la Urduino.

El MCP2200 es un convertidor USB<–>Serial fabricado por Microchip, más económico que el FTDI o el ATmega8U2, y disponible en encapsulado SOIC, es decir que es de montaje superficial pero aún lo suficientemente grande como para ser soldado por una persona. Microchip es famoso por sus microcontroladores PIC, en cierto sentido “rivales” de Arduino; el MCP2200 es en realidad un PIC18F14K50 con un firmware programado de fábrica para desempeñar la función de convertidor USB<–>Serial. Esto coloca a Urduino en el mismo nivel que las Arduino de última generación de la serie UNO, en el sentido de que el chip USB<–>Serial que utiliza es programable y puede enumerarse como dispositivo HID.

En lo demás, la placa es muy similar a la Arduino Diecimila, de la que deriva su diseño: posee un ATmega328, entrada de alimentación externa, regulador de voltaje, pinout Arduino estándar, conector ICSP, led de encendido, led en el pin 13, leds de TX/RX, botón de reset, etc. Es compatible con el IDE Arduino 0022, y tiene drivers para Windows (XP|SP3 o superior) y Linux. La Urduino será fabricada y distribuida en Uruguay por MVD Robotics, y su precio de venta al público oscilará en torno a los 33 dólares más IVA. Estará disponible tanto en versión terminada como en kit para armar por el usuario.

A continuación, disfruten las fotos del primer prototipo de Urduino.

Pinche aquí para ver el vídeo

Pinche aquí para ver el vídeo

-

Escuché decir, en ambientes de ingeniería, que los proyectos no se terminan, se abandonan. Bueno, esto es exactamente lo que ocurre con los míos. Cuando empiezo a construir un robot, no tengo ninguna idea acabada de lo que resultará, apenas unas directivas básicas sobre la mecánica y el hardware, como para que me permita luego experimentar y poner en práctica mis últimos descubrimientos (que casi siempre resultan ser ”reinvenciones de la rueda”, como me han señalado en reiteradas ocasiones). Sobre esta plataforma básica, van surgiendo las ideas en función de la facilidad para programarlas, y para agregar, si es necesario, nuevos elementos al hardware, sin alterar la estructura original.

Llega un momento, sin embargo, en el que el avance se vuelve cada vez más trabajoso; me doy cuenta de que es necesario reprogramar toda una sección, sustituir los motores por otros de mayor torque, cambiar el diseño del software, reemplazar el microcontrolador por otro de mayores prestaciones (o dotar al robot de un segundo procesador), desoldar toda una placa de componentes, etc., para superar las dificultades con que tropieza la realización de alguna de las ideas que surgieron cuando el robot ya estaba construido. Está claro que no se trata de proyectos ingenierísticos, en los que el diseño está completamente estudiado “sobre el papel” antes de su realización, sino de una suerte de improvisaciones (que han dado lugar, no obstante, a interesantes problemas técnicos, y a soluciones no menos inusuales y divertidas).

Cuando estamos en los comienzos del desarrollo de un proyecto, no es tan traumático hacer grandes cambios en él, rediseñar toda una parte, arrancar a programar de nuevo desde 0 si es necesario, etc. Pero cuando es mucho ya lo que se trabajó, esto no resulta tan fácil, y a veces la solución pasa directamente por abandonar el proyecto y arrancar uno nuevo. Es así como surgió, en octubre del año pasado, la idea de hacer un nuevo hexápodo, que superara las limitaciones del SAMSA original. Mucho fue lo que dudé, al principio, perseguido por la presión auto-impuesta de intentar siempre hacer algo “original”; pero en el fondo, lo que yo realmente quería era sacarme las ganas de hacer un buen -y trillado- robot “araña”. Por suerte encontré cierto eco entre mis compañeros del Proyecto Butiá, especialmente Jorge Visca, quien se convirtió en el co-autor de este nuevo trabajo.

La mejor manera de introducir a SAMSA II será, entonces, mediante la siguiente comparación con su antecesor, el SAMSA clásico. La misma está organizada en diversos apartados, cubriendo los aspectos fundamentales del diseño de ambos robots, y está disponible, por primera vez, en dos sabores:

Documentación de SAMSA II –> en español | en inglés

Fotos de SAMSA II

Aeropónica es una planta artificial de 10 metros de alto y 6 de ancho, dotada de 28 flores robóticas que interactúan con el público mediante sensores, instalada desde el 27 de julio en el espacio central del Centro Cultural de España, lugar donde permanecerá por un lapso de 8 meses. Se trata de un proyecto original del artista plástico Juan Perazzo, que resultó seleccionado en la Convocatoria abierta Intervenciones espacios no convencionales llevada a cabo por el CCE en 2010.   

Aeropónica

Más allá de que el resultado final de esta obra es de una gran belleza, dejándonos plenamente satisfechos a todos quienes participamos en ella, este proyecto me parece particularmente destacable por las siguientes razones:   

• Fue realizado en un tiempo y con un presupuesto realmente acotados, teniendo en cuenta su magnitud: estamos hablando de dos meses para su realización total y aproximadamente 2000 dólares para la parte mecánico/electrónico/informática, incluyendo materiales y honorarios de la gente que trabajó (entre la cual me incluyo, por eso conozco la cifra; no conozco los detalles del resto del proyecto, pero es más o menos del mismo orden).
• Dadas las condiciones en que se desarrolló el trabajo, no hubo mayor tiempo para pruebas ni especulaciones: cualquier error o descuido en los cálculos o en la praxis, podría haber derivado en un fracaso total (situación de la que estuvimos al borde en todo momento). Hubo que hacer todo “de una”, como si realmente supiéramos hacerlo, y no faltaron imprevistos de todo tipo a lo largo del proceso.
• Se trata de una instalación grande y compleja, que nos obligó a pensar, resolver problemas, tomar decisiones, y sobre todo, trabajar duramente. Se usaron 30 microcontroladores, 1500 metros de cable, hubo que desarmar más de 200 unidades de DVD para reciclar el sistema mecánico (al cual muchas veces también hubo que hacerle adaptaciones), etc., y esto por hablar solamente de la parte que me involucra. La plástica, por su lado, es de una fineza extraordinaria, producto también del esfuerzo de mucha gente, y no olvidemos lo que es la estructura física, el trabajo de colgar la planta en ese lugar, etc., etc.   

Por todos estos motivos, me siento más que contento de haber aportado al desarrollo de Aeropónica. Aunque, como sistema interactivo, su “conducta” no es de las más originales que puedan encontrarse (por el momento), es la primer instalación de esta naturaleza que se realiza en el pais, y talvez en la región.   

El jueves 14 de Octubre, a las 19:30hs, habrá una charla en el café del CCE, a cargo de Juan, Marcelo y quien suscribe, para dar a conocer los detalles de la realización de este interesante proyecto. Por mi parte, les voy a contar aquí cómo fue mi experiencia en la elaboración del sistema de control, junto a quiénes tuve el placer de trabajar, los desafíos técnicos a los que nos enfrentamos y cómo los resolvimos, en lo que va a constituir un auténtico “thriller tecnológico”.   

Parte 1 – Los comienzos

Hace aproximadamente dos meses, Marcelo Vidal (VJ Chindogu) vino a mi casa y me mostró un PDF con unos dibujos de unas flores mecánicas, informándome que con ese proyecto acababan de ganar un concurso del CCE, pero que él se tenía que ir para Alemania, y a ver si yo los podía ayudar a controlar esas flores con Arduino. Acepté la propuesta, y ahí mismo nos pusimos a ver posibles soluciones para la mecánica. Su idea original era utilizar motores paso-a-paso con un “sinfín”, como suelen encontrarse en las disketteras y las unidades de CD.   

Boceto original de la flor, a cargo de Marcelo.

Debo decir que yo soy un poco lento para ir adquiriendo toda la información, o talvez me concentro demasiado en un primer aspecto y no presto atención al resto de los detalles. El asunto es que no fue hasta unos dias después cuando se produjo una nueva reunión, esta vez con Marcelo y Juan Perazzo (a quien tuve el gusto de conocer en esa oportunidad), que tomé conciencia del verdadero alcance de lo que se proponían. Se trataba de desarrollar un sistema que permitiera controlar 28 motores, y recibir data de 8 sensores de distancia ultrasónicos; había que diagramar un circuito electrónico que involucraría uno o más microcontroladores, construirlo, y luego programar el sistema con alguna conducta (de la cual ni hablábamos por entonces porque era algo aún demasiado lejano). Todavía no sabíamos qué tipo de motores se usarían, cómo sería el sistema de trasmisión mecánica, pero ya había una idea más clara de los plazos (27 de julio) y del presupuesto (no debíamos exceder los 30 ó 35 dólares por flor).   

Según mis cálculos, era absolutamente imposible cumplir con el objetivo, y fue lo que les dije, ya que dos meses era perfectamente el tiempo que podía tomar hacer las pruebas necesarias para decidir qué tipo de solución íbamos a adoptar. De todas maneras acepté seguir trabajando, confiado en que, llegado el momento, las dificultades iban a obligar a Juan a posponer la fecha de inauguración, como ocurre sistemáticamente con todo, aquí en Uruguay.   

Prototipo de flor, con el sistema de arrastre de bandeja de CD

Sin embargo, las cosas iban más rápido que lo que yo esperaba. No sé si fue en esa misma reunión o en la siguiente que quedó establecido cómo sería el sistema mecánico. Marcelo había quedado con la idea de los motores paso-a-paso, pero desarmando unidades de CD en busca de dicho motor, yo me percaté de que el sistema de arrastre de la bandeja era una buena alternativa, aunque tenía la desventaja de funcionar con un motor DC, es decir, sin ningún sistema que permitiera tener un control exacto de la posición. A Juan le gustó la idea de los sistemas de arrastre de bandeja, porque tenían un recorrido de unos 10cm, contra los 5cm de los steppers, y se veían más fáciles de adaptar al movimiento de las flores, que por aquel entonces ya tenían una forma definida (consistían en un pequeño paraguas infantil invertido, movido por una varilla metálica), aunque todavía no estaba clara la manera concreta de instalarlos.   

Bien, les dije entonces que para empezar necesitaba una Arduino Mega, una protoboard, cablecitos, un integrado L293D (puente en ‘H’ para controlar motores DC) y un sensor de distancia como los que se iban a usar (los Maxbotix LV-EZ1, eran sensores ultrasónicos baratos, con un rango bastante mayor al de los clásicos infrarrojos Sharp). Con todo eso y el paraguas metido en un caño de PVC con el sistema de arrastre de la bandeja de la unidad de CD que desarmamos acá mismo “recortado” y pegado con Poxipol, yo me encargaría de hacer un prototipo que luego extenderíamos a todas las flores. A modo de encoder, para tener un mínimo control de la posición, le dije a Juan que hiciera unos agujeritos a lo largo del recorrido de la pieza móvil, planeando utilizar un sistema óptico, con un emisor y receptor IR a ambos lados de dicha pieza.   

Pinche aquí para ver el vídeo

Parte 2 – Flores inteligentes

La semana siguiente Marcelo ya estaba de viaje, quedamos Juan y yo en un ping-pong de idas y venidas entre su casa y la mía (que, por suerte, se encontraban bastante próximas, al igual que el estudio de Marcelo, todos en la zona del Parque Rodó), durante el cual fuimos optimizando el sistema mecánico, que al principio estaba muy duro. El punto clave de esa etapa fue el descubrimiento de la curva en forma de “S” que había que practicarle a la varilla metálica que trasmitía el movimiento. Los materiales llegaron con cierto atraso, pero yo no tardé en desarrollar el prototipo que les había prometido. Hasta ahí no tuve ninguna dificultad, todo parecía encaminado, pero el momento de las decisiones difíciles no tardaría en llegar.   

Desde el principio, la propuesta que me había llegado era que yo diseñara el sistema, “alguien” se encargaría de construirlo y replicarlo 28 veces, y finalmente yo me encargaría de desarrollar el software para el mismo. Pero yo veía que algo se iba complicando. Si usábamos los sistemas de arrastre de las bandejas de CD/DVD, la mecánica se simplificaba (a esa altura parecía claro que no había tiempo ni recursos para intentar otra cosa) pero el sistema de control se hacía un poco más complicado desde el punto de vista del software: el encoder óptico pasivo, para funcionar correctamente, necesitaba que el microcontrolador estuviera todo el tiempo pendiente de él, de lo contrario, si le “perdía el rastro” no había manera de controlar la posición exacta del motor. Empecé a imaginarme un sistema con 28 de esos encoders y yo tratando de programar todo 5 días antes de la inauguración, y la ví muy oscura…   

Días antes yo había tirado la idea de hacer “flores inteligentes”, es decir dotadas de un microcontrolador propio, pero como divague teórico para un supuesto proyecto en el que el presupuesto no fuera una limitante. Sin embargo ahora tenía que decirle a Juan que no había otra opción, esa era la única solución posible, poner un microcontrolador en cada flor. Así tuviera que sacrificar mis honorarios, yo prefería la tranquilidad de tener un poder de procesamiento local a nivel de la flor, entre otras cosas, para implementar el famoso “plan B”, es decir, que si todo fallaba, cada flor se comportaría autónomamente, con alguna programación aleatoria que “salvara la plata”. Cada flor sería ahora una especie de servo digital inteligente, pensaba yo, lo cual simplificaría enormemente la programación en la placa central.   

Primer prototipo de Arduino "casera" que iría en cada flor

Para Juan no estaba clara la diferencia con lo anterior (es decir, con una sola placa controlándolo todo), excepto que esto era más caro, pero para mí era un profundo alivio. Posteriormente estuvimos viendo con Marcelo, al regreso de su viaje, cuál era el clon más económico de Arduino que existía en el mercado, y que pudiera conseguirse en Buenos Aires. Respuesta: Solarbotics Ardweeny, un clon de Arduino sin USB, sin regulador de voltaje, que viene desarmado y cuesta 10 dólares en origen, casi 20 en Baires.   

Pero cada decisión aparentemente acertada que tomábamos, nos abría las puertas a nuevos y más complicados problemas. El incluir una Ardweeny con un L293D y un encoder óptico en cada flor, complicaba bastante la labor de ese hipotético individuo encargado de la materialización del sistema electrónico. Dicho sea de paso, me enteré de que no existía tal individuo, y quedó en mis manos la consecución de una persona que pudiera cumplir ese rol. Afortunadamente el Fede (Federico Andrade, compañero del proyecto Butiá) aceptó el trabajo, y demostró una gran solvencia al encargarse de la fabricación de más de 20 placas (es decir, el circuito que hay en cada flor, formado por la Ardweeny, el L293D, un regulador de voltaje y otros componentes más) y de ayudarme con la programación y algunas decisiones difíciles.   

El mismo prototipo, construido sobre un circuito impreso "universal"

Aspecto final de las placas basadas en Ardweeny

Otra de las dificultades que surgieron, fue la de conseguir los materiales electrónicos: en Eneka se agotaron los L293D, en Buenos Aires también, como asimismo las Ardweeny. Finalmente hubo que comprar todo en Solarbotics y hacer una importación, con la consiguiente demora en trámites aduaneros y demás. Por su parte la obtención de unidades de CD/DVD para desguazar tampoco progresaba. Marcelo compró varios lotes, y hasta recorrió los asentamientos en busca de unidades, pero por error estábamos descartando todas aquellas que no tuvieran una trasmisión exclusivamente basada en engranajes (o sea la gran mayoría, que eran “a gomita”) como así también las que tenían más de 5 cm de alto (o sea aquellas en las que el motor con el sistema de reducción ocupaba más de la mitad del espacio entre un lado y el otro de la bandeja de CD).   

Parte 3 – 1Km y medio de cable

Mientras tanto yo me enfrentaba a otro problema no menos grave, del cual nunca di demasiados detalles a Marcelo y Juan para que no se alarmaran. Se trataba del problema de la comunicación entre la Arduino Mega central y las 28 Ardweenys que estarían en las flores. El factor del que yo tampoco había tomado conciencia en las primeras reuniones, era que entre las flores más distantes y el sistema de control podría llegar a haber distancias de hasta 15 metros. No estaba claro el sistema de comunicación (yo barajaba varias opciones, pero tampoco había tiempo ni presupuesto como para intentar soluciones más “profesionales” como Ethernet, WiFi, ZigBee, RS485, etc.) ni el tipo de cable que usaríamos. Otro factor que empeoraba las condiciones era la imposibilidad de hacer un cableado tipo bus que fuera recorriendo las flores. Por razones que nunca me quedaron del todo claras, pero que eran contundentes al fin, había que cablear desde cada flor directamente al sistema central. Las decisiones acerca del tipo de comunicación, tipo de cable y tipo de conectores (si es que usaríamos conectores; en principio estaba claro que sí, porque de otra manera el montaje hubiera sido prácticamente imposible) eran de una importancia vital, pero yo todavía no podía adelantar nada.   

Mi primer intento fue con el protocolo I²C. Estudié bastante sobre I²C, leí sobre cableados, sobre el famoso límite de capacitancia de 400pf, sobre las resistencias de pull-up, hice numerosas pruebas (para las primeras pruebas tuve que construir yo mismo 4 placas, y nunca tuve, hasta dos días antes del montaje final, 4 flores completas para realizar ensayos de comunicación), intenté hacer algunas correcciones en la biblioteca Wire de Arduino, la que se encarga de gestionar el I²C, dado que la misma no cuenta con un buen sistema de manejo de errores, me imprimí y estudié el largo y entreverado capítulo “2-wire interface” del manual del Atmega328 (el microcontrolador de las Ardweeny), pero en definitiva, nunca pude superar algunos problemas de fondo del I²C (de los cuales hablaré en otro artículo). Con Fede nos juntamos 2 ó 3 veces a trabajar en la programación y a hacer experimentos, trabajamos muchas cosas, probamos la comunicación, hicimos un “sistema operativo” que funcionaba tanto sobre I²C como sobre Serial (yo ya tenía claro que había que tener una alternativa al I²C, el Serial era una posibilidad, aunque había que probar si era posible compartir las mismas líneas para varias flores simultáneamente; también habíamos pensado usar serial sincrónico [el comando shiftOut de la Arduino] o directamente pines de I/O sueltos, y teníamos previsto incluso cablear directamente desde los sensores hasta el sistema central, si todo lo demás fallaba), estuvimos trabajando con los sensores (que a mí me daban un gran dolor de cabeza, muy inestables, pero al Fede parece que le respondían mejor), hicimos el famoso “timeout” con el que la flor entra en “modo automático”, y varias cosas más. Por ese entonces ya era normal acostarse a las 6 ó 7 de la mañana todos los días.   

Pinche aquí para ver el vídeo

Una de las ideas de Fede que se mantuvo hasta el diseño final, fue la de usar doble fuente de alimentación: una fuente para los motores y otra distinta para las Ardweeny, intentando de esta manera reducir la interferencia producida por los motores, que afectaba seriamente la comunicación y provocaba errores de medida en el sensor. Por mi parte, yo me preocupé por la posibilidad de programar remotamente las flores, dado que el firmware (o el software “slave” como lo llamábamos) todavía no estaba pronto, y teníamos claro que era muy probable que no estuviera pronto hasta el dia mismo de la inauguración, como así tampoco lo estaría el “master” (o sea el que corría en la Arduino Mega). Para programar remotamente las flores, yo había incluido una línea de Reset entre los cables que llegarían a las Ardweeny, pero comprobé que esto provocaba el reinicio involuntario de las placas. (15 metros de cable no son una cosa trivial, eso lo tenía claro desde el comienzo, pero nunca había tenido la oportunidad de probar en la práctica una cosa así, y finalmente tampoco la tuve: hubo que quedarse con la primer solución que funcionó, sin sacarse la duda de si existían soluciones mejores). Por suerte encontré, finalmente, una forma de programar las flores a la distancia sin usar el Reset: era un poco complicada, pero era segura. (De hecho, la seguimos usando hasta hoy y nunca falló.)   

A todo esto, había que llegar a un diseño definitivo en cuanto a cables y conectores, para poder ir comprando los materiales y armando de una vez las famosas placas. La compra de materiales quedaba casi siempre a cargo de Marcelo, a quien más de una vez le entregaron mal la mercadería en Eneka, lo que provocaba también algunos retrasos. Al final, una de las últimas compras la hice yo, quedando en manos de Marcelo el tema del cable. El diseño final en cuanto a cable y conectores fue el siguiente: a cada flor llegaría un cable telefónico con una ficha RJ11, para llevar los datos, 2 líneas para Serial y 2 para I²C, y 4 cables sueltos de 0.5mm, con una ficha “blanca” de 4 polos, para llevar la alimentación, 2 líneas de masa, una de +12V para el motor y otra de +9V para la Ardweeny (a través del regulador de voltaje interno).   

Mecanismos extraídos de las unidades de CD/DVD

Parte 4 – Papelera de reciclaje

Yo seguía intentando resolver el tema de la comunicación (todavía estábamos lejos de llegar a la programación de la “conducta” propiamente dicha) pero ya estábamos a dos semanas de la fecha de inauguración y todavía no se había llegado a reunir los 28 sistemas mecánicos de las flores, por lo que tuve que interrumpir mis tareas y abocarme a resolver el tema de la mecánica. En ese momento, recién había llegado la segunda partida de Ardweenys (¡y la primera de L293D!! hasta ese día sólo habíamos contado con 3 puentes en “H” en total, para hacer las pruebas) por lo que Fede estaba totalmente dedicado a armar las placas. Yo literalmente me interné en lo de Juan para sacar, a como diera lugar, los 28 sistemas mecánicos. Marcelo se nos sumó, y entre los tres logramos superar ese paso, que era apenas uno de los muchos que aún nos quedaban. En esa internación en lo de Juan, de paso, se me confirmó definitivamente una cosa, y por primera vez no me quedaron dudas al respecto: la inauguración sería el 27 de julio, pasara lo que pasase, no cabía en los planes ninguna posibilidad de aplazamiento.   

La conclusión de los sistemas mecánicos constituye todo un capítulo, como cada uno de los dias de estas últimas 2 semanas, en donde se fue dibujando la forma definitiva del proyecto. El primer paso fue utilizar los sistemas que eran “a gomita”. Pero aun así no llegábamos al número necesario, hizo falta utilizar también aquellos sistemas “altos”, a los cuales les cortábamos el motor, lo soldábamos a una pieza de cobre en forma de “U” y luego pegábamos esta pieza con Poxipol a la estructura, de forma tal de reducir las dimensiones del sistema, para que cupiera adentro del caño de PVC. Finalmente acoplábamos nuevamente el motor al resto del mecanismo usando alguna gomita del tamaño apropiado, sacada de alguno de los sistemas que por diversas razones quedaban descartados. Revolviendo hasta la última de las cerca de 100 unidades semidesarmadas que todavía quedaban en el estudio de Marcelo, y reciclando desde motores, hasta engranajes sueltos y gomitas, llegamos justo a los 28 mecanismos que necesitábamos. Nótese que tanto en esta etapa como en todas las siguientes, el paso fundamental, y el que más tiempo nos insumía, era el testeo de cada una de las flores. Algunas fallas que aparecieron después de instalada la planta, se debieron justamente a no haber tenido el suficiente tiempo para testear los sistemas, aunque debo decir que el poco tiempo que tuvimos, lo aprovechamos bien.   

El estudio de Marcelo, centro de reciclaje de las unidades de CD/DVD

Ejemplo de mecanismo adaptado, con el motor cambiado de lugar

Parte 5 – Nacen 28 flores

Una vez llegados a este punto, nos dimos cuenta de que el trabajo que quedaba era aun mayor que todo el que ya habíamos hecho. El proceso de cerrar cada flor consistía en:   

• desarmar los “ópticos” y montarlos en una plaquita. Los “ópticos” eran unos interruptores ópticos IR, que venían encapsulados con el emisor enfrentado al receptor, dejando entre ellos un espacio por el que podría pasar el riel agujereado, es decir, prácticamente lo que nosotros necesitábamos, con el único problema de que el espacio era muy angosto, entonces había que desarmar el encapsulado, extraer los componentes y soldarlos a una plaquita de PCB universal (hecha con los restos de las mismas PCB universales con las que Fede fabricaba los circuitos) a la distancia correcta.
• montar ese óptico en el mecanismo, pegándolo con silicona.
• dotar tanto al óptico como al motor de unos cables con un conector en la punta, para poder conectarlos en las placas. La decisión de usar conectores en lugar de soldar los cables directamente a las placas, fue mia y se respetó hasta el último momento, a pesar de que todo parecía indicar que insumía más tiempo. La razón para esto es que facilitaba el testeo: dado que cualquiera de los componentes podía fallar, era muy fácil probar un motor o un óptico en una placa que sabíamos que andaba, o probar una placa dudosa con un óptico y un motor buenos conocidos, etc. (Con respecto a los ópticos, hay un detalle curioso, y es que la luz ambiente los afectaba, introduciendo otro factor de incertidumbre en los testeos. Este fenómeno se veía notablemente reducido al iluminar con lámparas de bajo consumo, en lugar de incandescentes, hecho que asombró a Juan, pero que tiene en realidad una explicación muy simple).

Interruptores ópticos desarmados y soldados en pequeñas plaquitas

Colocación del "óptico" sobre el riel perforado

• pegar la placa con la Ardweeny, con silicona adentro de la flor, buscándole un lugar apropiado, sin que afectara al mecanismo, y en el que los cables pudieran salir cómodamente.
• Hablando de cables, éstos se conectaban con fichas a las placas, pero debían quedar colocados antes de cerrar la flor, porque el lugar donde se conectaban resultó quedar unos 15cm adentro de los caños de PVC que formaban la estructura. En consecuencia, había que preparar un juego de cables para cada flor antes de que éstas se cerrasen. La preparación del juego de cables consistía en cortar los cuatro cables de 0.5mm junto con el cable telefónico, en tiradas de 11m o 13m, ya que no se permitía que hubiera añadidos (ya se sabe que los añadidos introducen todo tipo de problemas en el cableado) y luego aproximarlos con cinta o con “sunchos” cada 15 ó 20cm. (Los cálculos que nos llevaron a estas medidas estandarizadas de 11 y 13 fueron muy confusos, un ping-pong entre Marcelo y yo, con el kilómetro y medio de cable ahí en el piso, y Juan que no soportaba más la conversación). Luego de cortar y juntar el cable, había que colocarle las fichas en las puntas, una de ellas soldada y la otra con la pinza telefónica.
• Finalmente había que alinear el caño de salida para que pasara la pieza móvil, pegar la tapa y el caño (con “cinta pato”), atar el cable con un precinto a la pared del caño (practicándole para ello dos agujeritos con un taladro), y por supuesto…
• …comprobar que anduviera todo bien. El testeo era una parte sumamente tediosa, pero habíamos llegado a la conclusión de que no nos lo podíamos “rifar”. Incluso una vez que adquirimos más práctica en el armado, hacíamos un “doble testeo”: uno antes de pegar la placa con silicona (“empetrolar” como decía yo) y otro al final de todo. Cada testeo consistía en: programar la placa remotamente (es decir, a través del cable; para ello usábamos mi notebook, instalado en el último metro cuadrado que quedaba disponible en la casa de Juan; con la prueba de programación remota, probábamos a su vez la comunicación Serial, que sería el sistema que a la postre terminaríamos usando en toda la planta) y luego probar el movimiento, es decir, dejar que el programa local arrancara, hiciera su propio test de la mecánica (el “pajeo” como lo llamábamos) y luego esperar que entrara en el modo automático e hiciera 4 ó 5 movimientos. Muchas veces, en este testeo saltaban problemas mecánicos que nos obligaban a volver atrás y revisar cosas como la alineación de la varilla, cambiar de gomita, hacerle “topes” a los sistemas, embadurnarlos en vaselina, etc. Cada flor era única, completamente distinta a las otras y tenía sus propias virtudes y defectos.

Este proceso no podía hacerse esperar, porque una vez finalizado, Juan y su equipo debían practicarle a las flores una decoración, que llevaría también unos días, y ya estábamos muy próximos a la fecha límite. Una semana antes de la inauguración debían estar todas las flores absolutamente prontas.   

Presentación del circuito en el interior de la flor

Sensores de distancia ultrasónicos Maxbotix LV-EZ1, usados en el proyecto.

El armado final de las flores insumió 4 días consecutivos, distribuidos de la siguiente manera:   

• Primer dia. Integrantes: Juan y yo. Resultado: 4 flores. Hora de finalización: muy tarde. Ese día lo que hicimos fue armar 4 flores con los 4 cables que yo usaba en mi casa para realizar las pruebas, que ya estaban prontos y probados. Después de eso, tuve que traerme nuevamente 4 flores, esperar que Fede tuviera prontas 4 nuevas placas, armar 4 nuevos cables, y todo eso para hacer pruebas durante unas pocas horas, ya que al otro dia tuve que entregar todo nuevamente.
• Segundo día. Integrantes: Juan, Marcelo y yo. Resultado: 6 flores. Hora de finalización: más tarde todavía. Ese dia instituimos la técnica “oficial” de testeo, por lo que debimos re-testear las 4 flores del dia anterior. En total íbamos 10 flores, no habíamos alcanzado el objetivo parcial propuesto originalmente, que era tener 14 flores por día.
• Tercer día. Integrantes: Marcelo, Fede y yo. Resultado: no me acuerdo bien, pero creo que entre 8 y 11 flores. Hora de finalización: 8 a.m. Ese día pasó de todo, empezaron a fallar mecanismos, ópticos, placas, todo. En un momento la vimos realmente negra. Al final empezaron a salir las flores, pero seguíamos lejos del final. Me acuerdo que no teníamos casi estaño para soldar los conectores, trabajábamos con tramitos de hasta 1cm. En esta jornada fue que empezamos también a armar las 8 flores que llevaban sensor, en las cuales el testeo abarcaba una etapa más: probar que la flor enviara correctamente los datos del sensor, a través del Serial.
• Cuarto día. Integrantes: Marcelo y yo. Resultado: todas las flores que faltaban, menos una. Hora de finalización: 5 a.m. Llegamos hasta la penúltima flor, requechando componentes electrónicos como antes lo habíamos hecho con las piezas mecánicas. Algunas placas que había construido Fede fallaron, entonces fueron desarmadas, y vueltas a combinar entre sí, y así logramos llegar hasta la flor número 27. Los ópticos que fallaron fueron sustituidos por unos nuevos comprados por Marcelo ese mismo día en Rondeau, que eran distintos a los originales, un poco más difíciles de instalar, pero igual funcionaron.

La última flor la armé yo acá en mi casa, requechando lo “inrequechable”, utilizando una Ardweeny adicional que Marcelo se había traido para él. (en una de las pruebas con Fede, volamos un microcontrolador, aplicándole por error 9V en lugar de 5V). Aproveché para quedarme con esa flor un par de dias más, y hacer las últimas pruebas antes de pasar a trabajar directamente en el CCE.   

Pinche aquí para ver el vídeo

Parte 6 – En el CCE

En los dias siguientes, mientras Juan y su equipo se dedicaban a armar la planta en el propio CCE (luego de transportar con sumo cuidado las 28 flores y el resto de las partes hasta allí), yo me dediqué a avanzar lo más posible con la programación. La primer medida que tomé fue descartar completamente el I²C. Usando Serial (a 57.6Kb/s) ya habíamos probado con Fede que se podía conectar el mismo TX del Master con múltiples RX de distintas flores, simultáneamente (cada flor tenía un ID distinto), pero mi intento de unir los TX de varias flores hacia un mismo RX del Master había fracasado, si bien sabía que esto era básicamente posible, porque es precisamente lo que hicimos en el Proyecto Butiá con los motores AX-12. No había tiempo para hacer más pruebas, de modo que la solución adoptada fue usar dos Arduinos Mega: cada una de ellas tiene 4 puertos Seriales, o sea que tendríamos 8 receptores, exclusivamente para las flores con sensor, y también 8 emisores, para compartir entre las 28 flores, lo que nos daba la seguridad absoluta de que iba a funcionar. Las dos Arduinos Mega las teníamos, porque Marcelo también se había traido una para él.   

Bueno, en esos días le di bastante forma al programa “Slave”, haciendo un protocolo de comunicación que soportaba varios comandos, permitía controlar la posición, la fuerza del motor (usando PWM), la frecuencia y amplitud de los “latidos”, enfín, una sobrada cantidad de sofisticaciones que finalmente no llegaron a usarse el día de la inauguración. El Master a su vez, estaba programado en forma totalmente orientada a objetos (las Arduino soportan C++), muy prolijo, y constaba de diversas “conductas” que tampoco se utilizaron mayormente.   

Con todo esto pronto, me fui al CCE a intentar realizar pruebas con las ramas que quedaran “boyando” por ahí. En el CCE, el ambiente de trabajo era sumamente cómodo, mucho mejor de lo que yo esperaba (había calefacción, por ejemplo). El primer dia, las cosas no me salieron del todo bien, pero luego llegó el Fede y pudimos encaminar nuevamente el trabajo. Llegamos a hacer una prueba por primera vez con 2 ramas simultáneas (7 flores) y anduvo todo bien, por lo que ya respirábamos una gran tranquilidad.   

Pinche aquí para ver el vídeo

Conexiones usadas en la prueba con 7 flores

Espacio central del CCE, dos dias antes de "colgar" la planta

El siguiente paso era esperar que la planta estuviera colgada, para soldar, de alguna manera que no estaba clara todavía, las 168 puntas de los cables a “algo”, y de allí a las Arduino Mega. El Fede ya no estaría para ese entonces (tenía que viajar a Bs. As. a un curso; la noche anterior habíamos estado reprogramando cada flor con el ID correcto y rotulando los cables, para facilitar la tarea ulterior) así que esta última etapa la resolveríamos entre Marcelo y yo. El domingo a eso de las 20hs llegué al CCE y ví aquello: era espectacular. No participé de la colgada, pero Juan y la gente que estuvo, aseguran que fue, por sí sola, una cosa digna de un artículo tan extenso como el presente. Sólo vi el resultado final, y la verdad es que impresionaba por lo aparatoso, siendo a su vez de una gran belleza.   

Marcelo había comprado los últimos materiales el sábado de mañana, y otra vez le habían entregado mal la mercadería, pero el lunes finalmente teníamos todas las cosas necesarias: 28 llavecitas dobles (que servirían para programar fácilmente las flores, sin necesidad de conectar y desconectar cables como veníamos haciendo hasta el momento), 2 PCB universales grandes, las 2 fuentes de alimentación (una de ellas era una fuente de PC) y una serie de conectores que finalmente no usamos, esta vez sí soldamos todos los cables directamente a la placa. Con todo el cablerío soldado, empezamos a probar rama por rama la conducta de las flores y los sensores. Era una tarea cansadora, porque había que subir y bajar repetidamente los dos pisos que separaban el sistema de control, de las puntas de algunas ramas. Para realizar estas pruebas, yo programé en el Master una conducta muy simple, que sustituía a todas las conductas sofisticadas en las que había estado trabajando los días anteriores: si el sensor superaba cierto umbral, todas las flores de esa rama se abrirían al máximo, separadas por cierto delay, y de lo contrario se cerrarían al máximo también. Con ese comportamiento inequívoco, establecimos los umbrales de los 8 sensores, los movimos cuando fue posible, para que no quedaran apuntando en direcciones erróneas, intentamos “revivir” un par de flores que sucumbieron al stress de la colgada, y cuando terminamos de hacer todo esto, eran las 5 a.m., y carentes ya de energía, decidimos dejar así la instalación, con esa misma conducta básica.   

No hubo sorpresas en cuanto al funcionamiento del sistema en general, todas las ramas andaban, cada una con su sensor, todas las flores respondían excepto las dos accidentadas, y una tercera que se trancaba ocasionalmente. Ya estábamos ultimando los detalles para la inauguración del dia siguiente (Marcelo se encargaba entretanto de acomodar los “tachos” alquilados especialmente para iluminar la obra), cuando en un momento, mientras le estaba explicando a Marcelo cómo encender el sistema, ocurrió algo que nos dejó paralizados.   

La fuente de alimentación que usábamos para las dos Arduino Mega y las 28 Ardweenys de las flores, era una fuente de esas que entregan varios voltajes, y cuya punta se puede intercambiar e invertir de polaridad. Nosotros la usábamos en 9V, 4A, con ella entrábamos a una Arduino, y desde allí sacábamos alimentación hacia las 28 flores. La Arduino tiene un diodo protector contra polaridades inversas a la entrada, pero como Marcelo había notado que éste calentaba mucho, yo decidí “puentearlo”; en efecto, el diodo, si bien “aguantaba”, no estaba preparado para alimentar 28 placas a la vez. Ocurrió entonces que al sacar el plug de alimentación por última vez, éste se separó del cable, y al volver a ponerlo, si bien verifiqué la polaridad, algo me traicionó y lo conecté al revés.   

Cuando le fui a mostrar a Marcelo “¿ves? Conectás este plug acá…” observé que al conectar el plug, los leds de “power” de las Arduino no se encendieron. Inmediatamente retiré el plug, y quedé inmovilizado por unos 10 segundos, temiendo lo peor. No sé si Marcelo realmente entendía el alcance del riesgo que estábamos corriendo, pero él también estaba inmovilizado. Verifiqué la polaridad de la conexión, y efectivamente, estaba al revés. A punto de ponerme a llorar, no me animaba a enchufar el plug nuevamente. Sabía que las Arduino iban a encender, que los leds se iban a iluminar, pero no podía asegurar nada respecto a la situación adentro de las flores. Si las Ardweeny se habían quemado, no había “plan B”, no había nada, estábamos perdidos para siempre.   

Afortunadamente no pasó nada, fue sólo un gran susto, probamos una por una las flores, todas seguían funcionando, fijamos ese plug con más o menos un metro de cinta pato, nos reímos bastante, imaginándonos el desastre, pero quedó claro que, por esa noche, no daba para hacer ninguna prueba más: así quedó hasta el día siguiente en la inauguración.    

P. G., 29/7/10 (corrección: T. Laurenzo.)   

Pinche aquí para ver el vídeo

Pinche aquí para ver el vídeo

Más fotos de Aeropónica

Algunas de sus características, que me vienen a la mente ahora:

• soporta rotación continua y modo servo standard, este último con un radio de giro de 300 grados
• velocidad y torque ajustables
• velocidad máxima: 300 grados/seg. Torque máximo: 16Kg/cm
• comunicación serial a 1Mb/s, half duplex. Se pueden conectar varios motores en cadena a un mismo bus.
• usa un microcontrolador ATmega8 (vale decir que adentro de cada motor hay una Arduino de las viejas)
• 10 bits de resolución en todos los parámetros (0-1023)
• alimentación de 7-10V (los servos standard funcionan entre 4,5-6V)
• feedback de todo tipo de información: posición angular, temperatura, voltaje, fuerza, velocidad, sobrecarga, errores, etc.  a través del bus serial, y posee además un led de notificación.
• y lo que más me gusta: viene con los famosos “brackets” en forma de “U”, de un plástico muy resistente, tornillos, y otras piezas mecánicas de gran interés, por sólo 45 dólares.

Cuando me enteré de la existencia de tan maravilloso actuador, comencé a buscar información sobre su control mediante Arduino. Dado que el propio motor implementa un ATmega8 y que el microcontrolador central de los Bioloid es un ATmega128, pensé que tenía que ser más que posible dicha combinación.

Afortunadamente encontré este proyecto, el ArbotiX RoboController, que es justamente una placa controladora de robots capaz de manejar los AX-12, basada en ATmega644 y de código abierto. La ArbotiX está basada en Sanguino, y no en la Arduino propiamente dicha. La principal diferencia es que estas placas, al igual que la CM-5 del Bioloid, tienen dos puertos USART, mientras que la Arduino “clásica” tiene solamente uno.

Si usamos los AX-12 en un proyecto, siempre nos va a convenir tener un segundo puerto serial, para comunicar con la PC u otro hardware “superior”. En el caso de la Arduino clásica, esto se resuelve usando la biblioteca SoftwareSerial, que fue lo que yo hice en el video de más abajo. Hay que tener en cuenta que la SoftwareSerial está limitada a 9600 baudios, y que consume memoria y tiempo del procesador, pero en muchos casos esto no representa mayor problema.

En resumen, la adaptación de la biblioteca de ArbotiX a una Arduino clásica consistió simplemente en cambiar el nombre de algunos registros. Una vez que probé que esto funcionaba, aproveché para ampliar y mejorar la funcionalidad de la librería, y actualmente estoy trabajando con mi propia versión, que pueden descargar aquí.

En el video de prueba, el setup es el siguiente:

• los pines 0 y 1 (RX y TX) van unidos entre sí y conectados al pin de datos del AX-12
• la alimentación del AX-12 se extrae de los mismos 9V que alimentan a la tarjeta
• los pines 2 y 3 se utilizan con la “software serial”, y van conectados a un convertidor serial-USB (FTDI) el cual a su vez se conecta al PC y es monitoreado con el Putty. No es posible usar para esto el propio convertidor serial-USB incluido en la Arduino, ya que el mismo se encuentra físicamente soldado a los pines 0 y 1.

Bueno, aquí les dejo el video. Saludos!

Pinche aquí para ver el vídeo

Pinche aquí para ver el vídeo

Pinche aquí para ver el vídeo

Pasaron casi 2 meses desde los últimos videos de SAMSA, aquellos de la caminata, y tal vez pueda parecer que son pocos los avances para 2 meses. Voy a comentar los puntos en los que estuve trabajando:

1) Idea central: todavía no tengo una idea central fuerte, que dé coherencia a todo el conjunto. SAMSA todavía no tiene una personalidad definida, pero ya presenta algunos rasgos. No es para inquietarse, a veces la “idea” me viene bastante tiempo después de tener armado todo el hardware, y a veces directamente no me viene. Siempre está la posibilidad de invitar a algún amigo y anotar en un papelito todas las ideas que se le escapan.

2) Autonomía: no fue fácil dar con la batería adecuada para SAMSA. El robot necesita como mínimo una tensión de 6V, y, no tengo amperímetro, pero mis cálculos daban que debía consumir unos 3.6A, ya que la especificación del servo HiTec HS-55 -del cual los que yo usé son una copia berreta- dice que el motor andando pero en el vacío (no load) consume unos 150mA. Los 18 servos andando a la vez y con el robot apoyado, generarían un consumo considerable, al que habría que sumar el del resto de la electrónica. Evidentemente me quedé corto, ya que el primer intento con baterías de 2000mAh/2C (el “2C” indica que admiten una descarga de 2 veces su carga, en este caso 4A) fue un fracaso. Necesitaba baterías de más “polenta”, pero ojo con aumentar el tamaño y el peso, dado que SAMSA es un robot más bien debilucho. El factor que hubo que sacrificar es la carga misma, es decir el tiempo de autonomía. Finalmente terminé usando la batería que se ve en la foto, de 730mAh/20C, que admite descargas puntuales (“burst”) de hasta 40C, o sea: un disparate, y pesa nada más que 35g. Estimo que la autonomía no será de más de 15 minutos, pero hasta ahora no lo he probado. 

Antenas y medidor de distancia Sharp GP2D12

Motor DC y encoder óptico de las antenas.

3) Sensores y periféricos: para el tiempo en que filmé la caminata, los sensores ni estaban conectados. Los dos cables del motor DC que mueve las antenas estaban colgando sueltos, el medidor de distancia estaba puesto “de adorno” y el resto de las cosas no existían. Conectar todas estas cosas dio un gran trabajo, en especial la parte de audio. Todos los periféricos -excepto el display, que para aquel entonces ya estaba perfectamente funcional aunque no tenía software que lo explotara- van conectados a un mini-circuito que está en la parte de abajo del tronco, el que muestra la foto. Ese circuito maneja las siguientes cosas:

• motor DC de las antenas, controlado por un puente en “H” a transistores, que ocupa menos espacio que un L293D.
• rotary encoder óptico de las antenas (sacado de un mouse viejo). Esto permite usar las antenas también como dispositivo de entrada, y ya tengo rutinas que explotan el recurso.
• micrófono, amplificado por un operacional diminuto que no se ve, porque está tapado por los componentes pasivos.
• acelerómetro y medidor de distancia Sharp GP2D12; éstos van directo a la Wiring, el circuito sólo se encarga de conectarlos. (El acelerómetro es para hacer trucos como que detecte cuando lo levantás, etc., por el momento no se está usando.)

Inserción en el robot.

Vista trasera.

Lo que realmente me dio trabajo acá fue el audio, tanto en el hardware como en el software. En el hardware, porque la electrónica analógica nunca fue mi fuerte, y ajustar ese circuito, a ojímetro como hago todo, fue casi imposible. Sabiendo además que el LM324 no era la mejor elección, lo hice así porque quería aprender de una vez a usar operacionales. Otro problema que tuve fue el ruido infernal que mete el Sharp GP2D12 en la línea de alimentación, el cual fue atenuado a base de sacar la alimentación de un punto lo más lejano posible al circuito de audio, y meter condensadores por todos lados a lo bestia.

El software también aportó lo suyo, pero de eso hablaremos más en detalle cuando encare la documentación “posta” del robot. Resumiendo, el tema con los sensores es que hay que actualizar la lectura con cierta frecuencia, y el tiempo que tenemos para tareas periódicas no es demasiado, una gran parte del mismo es consumida en manejar los 18 servos. En el caso del audio, además, hay que hacer otras cosas que recayeron finalmente en el software, como filtrar el componente de corriente continua (DC), rectificar, “logaritmizar” e integrar, lo que finalmente también consume abundante tiempo, y estamos hablando sólo de trabajar con la intensidad del sonido, no sueñen con una FFT ni con reconocimiento de palabras ni nada. De más está decir que toda la gracia del proyecto es hacerlo con un sólo procesador.

Pata del robot.

4) La “cinemática inversa” es lo que permitió hacer movimientos del tronco, dejando las patas fijas en un punto, como se ve en el segundo video. Los servos trabajan con ángulos, su posición angular es proporcional al ancho del pulso que reciben, y dentro del programa, yo puedo controlar linealmente el ancho de ese puso, y por ende manejar con exactitud -e independencia- los 18 ángulos (excepto por las limitaciones mecánicas, que hacen que para adoptar ciertas posiciones, lo tenga que “ayudar” con todas las patas haciendo fuerza a la vez). Las rutinas de caminata fueron hechas como secuencias de ángulos, experimentalmente (y me sigue resultando asombroso que pueda caminar tan rápido) pero para hacer movimientos con el tronco la cosa ya no es tan fácil. Por ejemplo, si quiero poner la punta de una pata 4cm por debajo de la altura del tronco, y mantenerla a esa altura mientras la alejo o la acerco perpendicularmente al mismo, necesariamente tengo que variar en forma continua 2 ángulos, y hacerlo de acuerdo a una fórmula matemática no evidente.

Utilizando el teorema de Pitágoras y el teorema del Coseno, encontré la manera de calcular los ángulos necesarios para poner cada pata en unas coordenadas dadas, en cm. También me valí de unas fórmulas que encontré en internet para calcular las funciones trigonométricas inversas utilizando sólo arcotangente, que es lo que la ‘math’ de Wiring tiene. Hice el siguiente programa de simulación en Processing, y la parte de “offsets” para que los resultados quedaran en el cuadrante y con el signo correcto también fue experimental, metiéndole “a mano” valores como PI/2, -PI/4, etc., a ver qué pasaba.

Una vez pronta esta rutina (que en mi programa se llama “alfabetagama”), calcular las 3 traslaciones y las 3 rotaciones del tronco fue tarea relativamente sencilla, casi todo con sumas y restas, excepto una de las rotaciones en la que usé la fórmula de la rotación en el plano, que involucra senos y cosenos. Todo esto lo voy a explicar detenidamente en la prometida documentación.

Vista trasera del circuito controlador del display.

Display LED matricial de 8×8 monocromático.

5) Display: varias personas me sugirieron que no perdiera tiempo con el display, que nadie lo iba a mirar, llegando incluso a cuestionar la presencia del mismo en el proyecto, pero a mí me gusta. Hice todo tipo de adornitos, rutinas que miden un parámetro y lo expresan como líneas o barras verticales y horizontales, como círculos, como escaleritas, como cuadrados, como puntos “aleatorio-probabilísticos”, rutinas que muestran y desplazan texto, rutinas que giran, que borran, que invierten, que mezclan, etc., y hasta le programé una versión del clásico juego de la vida de Conway.

Por último debo aclarar que lo que se ve en los videos no forma parte de la idea central sino que son cosas programadas “ad-hoc” al momento de la filmación, con la ayuda de mi amigo Daniel Lopes, el KBZA, como una forma de mostrar más o menos las posibilidades con que cuenta SAMSA hoy en día, aunque alguna idea ya estoy sacando de todo eso.

Este post es provisorio, como siempre, aquí van a ver parte de la presentación en dorkbot.mvd el 19 de abril de este año, pero prometo ampliar la información técnica y anecdótica de este maravilloso artefacto, en el futuro.

Pinche aquí para ver el vídeo

LA BAILATA

Pinche aquí para ver el vídeo

INTERACCION CON LA MAQUINA DE LOS DIOSES

Pinche aquí para ver el vídeo

 (Este post es provisorio, en breve tendremos información más detallada)