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

Durante el evento se desarrollan diversas exposiciones, presentaciones de trabajos, competencias y talleres, organizados en tres actividades principales: 

• Campeonato de Sumo Robótico.
• Workshop en Inteligencia Artificial y Robótica Móvil.
• Concurso de Robótica.

Este año, en su 7ª edición, el programa tendrá lugar del 23 al 25 de setiembre, en el Estadio de Sumo Robótico, Edificio Polifuncional Faro (Facultad de Ingeniería), y contará con algunos detalles que paso a comentar. 

Presentación oficial del Proyecto Butiá

El Proyecto Butiá ha alcanzado ya su madurez, y se encuentra actualmente en fase de producción. El jueves 23 serán entregados oficialmente los primeros 27 kits robóticos a liceos públicos, con la presencia de las autoridades de enseñanza secundaria, los responsables del proyecto, autoridades del INCO, etc. 

• plataforma de acrílico de 5mm, con agujeros y piezas constructivas para montar sensores.
• motores Dynamixel AX-12+, ruedas de 6,5cm de diámetro que permiten una mayor velocidad de desplazamiento, “ruedas locas” con amortiguador de acero.
• pack de 8 baterías Ni-Mh, interruptor de encendido, conector para cargador de baterías externo.
• tarjeta de E/S Arduino Mega, con el firmware butiá (se están desarrollando también versiones para otras placas, p. ej. USB4ALL, GoGoBoard, etc.)
• completo kit de sensores y actuadores, que incluye sensores de temperatura, distancia, inclinación, luz, botones, etc., hasta un display LCD de 16×2 caracteres. 

Butiá shield

• el “butiá shield”, placa que se monta sobre la Arduino y contiene 8 conectores con funcionalidad Plug & Play (un modesto aporte de la casa).
• software para XO, fácilmente portable a otras plataformas. Consiste en el “bobot server”, un programa desarrollado en Lua, que permite comunicarse con el robot desde cualquier lenguaje de programación mediante sockets, incluso desde una computadora remota.
• implementación para el lenguaje gráfico TortugArte de las XO, que permite manejar el robot desde este entorno. Se puede interactuar,  mover los motores, leer los sensores, etc., gracias a una paleta gráfica que contiene los “ladrillos” específicos del Butiá.  

Walter Bender, creador de Sugar (el sistema operativo de las XO) y TortugArte.

Ejempo de programa en TortugArte para Butiá.

 

 

Workshop y exposiciones robóticas

Aeropónica

Dentro de lo que son las charlas, voy a tener el gusto de participar nuevamente, en esta oportunidad para hacer una breve presentación sobre el proyecto Aeropónica, de Juan Perazzo y Marcelo Vidal, en el cual estuve a cargo del diseño y construcción del sistema de control. 

SAMSA

SAMSA también estará presente en el evento, cumpliendo ya un año y medio de vida. El hexápodo ha tenido, por su parte, algunos avances en este tiempo, pero se trata más que nada de optimizaciones en el código que ya estaba. Ha agudizado sus sentidos, es capaz de escuchar y reconocer algunas palabras, puede mover sus antenas sin provocar interferencia en su sistema auditivo, y puede, por ejemplo, detectar la acción de una fuerza externa sobre las antenas, aunque él mismo las esté moviendo.  Sin embargo, aún no tiene una conducta autónoma concreta; estuvimos trabajando durante la primera mitad del año junto a Daniel Bebelaqua en pos de ese objetivo, pero no alcanzamos a cristalizar nada en las escasas horas que le pudimos dedicar. 

  

Se trata de un proyecto del Departamento de Informática de la Facultad de Arquitectura (dirigido por el Arq. Marcelo Payssé) y el GIGA de la Universidad de Zaragoza, financiado a través del Programa PCI 2009 de la Agencia Española de Cooperación Internacional para el Desarrollo (AECID) y con el apoyo de la IMM. 

Pinche aquí para ver el vídeo

Para desarrollar el software que controla a este sistema, fuimos contratados, junto a Tomás Laurenzo (el tom), y lo hicimos en C++, con Visual Studio 2008 (en Windows) y usando openFrameworks. Fue para mí la primera vez que tomé contacto con la programación “en serio”, y por lo tanto, una gran experiencia. Si bien no se trataba de algo extremadamente difícil, hubo que trabajar, nuestro software debió resolver, entre otras cosas, los siguientes aspectos:

• comunicarse con el sensor angular Intersense;
• dibujar varios “panoramas” cilíndricos, con niveles de transparencia ajustables, usando OpenGL;
• girar los cilindros, o bien girar la cámara GL (lo hicimos de las dos maneras);
• gestionar un interfaz gráfico de usuario, interactivo, manejado con dispositivos touchscreen;
• comunicarse con los dos dispositivos touchscreen, calibrarlos;
• hacer coincidir el movimiento de los “popups” (las ventanas con información, que aparecen sobre un plano) con el de los panoramas cilíndricos;
• comunicarse con dos cámaras Sony PS3, usando la biblioteca “CLEyeMulticam” de CodeLaboratories;
• “renderear” y controlar simultáneamente dos pantallas, en dos monitores de 42”;
• usar threads, a efectos de optimizar el rendimiento, logrando finalmente un framerate de 60 frames por segundo, sin que se noten saltos de ningún tipo;
• etc.

La estación ARAGON será estrenada el viernes 24 de setiembre, a las 16:00 hs,  en el Espacio Cultural “Al pie de la Muralla” (Bartolomé Mitre 1464), y se la podrá ver allí durante el Día del Patrimonio 2010. Posteriormente será ubicada dentro del proyecto “Muralla Abierta”, que obtuvo el Premio Santiago de Compostela de Cooperación Urbana 2009.

A continuación les dejo algunas fotos y más videos del proyecto.

Pinche aquí para ver el vídeo

Pinche aquí para ver el vídeo

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

El objetivo de este proyecto es crear una plataforma simple y económica, que permita a alumnos de liceos públicos, en coordinación con docentes e inspectores de Enseñanza Secundaria, interiorizarse con la programación del comportamiento de robots; de esta manera, se pretende transmitir a los profesores, estudiantes, y a sus familias, conocimientos básicos sobre las nuevas tecnologías y sus aplicaciones.

La propuesta aspira a incorporar estos sistemas robóticos de bajo costo en todos los liceos públicos con bachillerato tecnológico del país, organizando charlas y actividades extra-curriculares, en donde se explique el manejo, las características y las posibilidades del sistema.

Plataforma de acrílico con los 2 motores AX-12+

El Butiá-Bot

En octubre del año pasado me enteré de la existencia de este proyecto, y tuve la suerte de que me dejaran participar en él. Desde entonces tengo el honor de trabajar junto a Gonzalo Tejera, Santiago Margni, Andrés Aguirre, Jorge Visca y Federico Andrade, en todo lo que es el hardware y software del robot (hay más gente trabajando en otras áreas). En estos meses el avance ha sido paulatino; ello se debe a que cada decisión que se toma es analizada y discutida cuidadosamente.

A diferencia de los robots que yo había venido desarrollando por mi cuenta, los cuales funcionan integramente con un único microcontrolador, el Butiá-Bot consta de 2 niveles de procesamiento: el “bajo nivel”, gestionado por un microcontrolador, que se encarga del manejo básico de sensores y actuadores, y por encima de éste, el “alto nivel”, es decir, una computadora que se encarga de la conducta propiamente dicha del robot. Esto permite su programación en lenguajes de alto nivel de abstracción, así como, eventualmente, el procesamiento avanzado de imágenes y sonido, lo que a su vez nos posibilitaría el uso de cámaras web, micrófonos, y otros periféricos sofisticados. 

El sistema estaría diseñado de tal modo que permita usar como soporte hardware del “alto nivel” tanto una SBC (single-board computer), como cualquier dispositivo móvil, celular, netbook, incluso un router, capaz de correr alguna distribución de Linux, pero apuntando principalmente a las computadoras del Plan Ceibal, las XO.

En materia de hardware de bajo nivel, es decir el “microcontrolador”, teníamos que decidir entre 2 opciones: la ya conocida tarjeta Arduino, y el USB4ALL, un interfaz USB genérico basado en PIC, desarrollado en el propio seno del mina. Finalmente se optó por comenzar el desarrollo usando Arduino, dada la facilidad que nos ofrecía la biblioteca para controlar motores AX-12+, pero sin descartar una futura implementación usando USB4ALL.

El software de “alto nivel”, por su parte, consta de 2 “capas”: una capa “inferior” que se comunica con el “bajo nivel”, y la capa “superior” implementada en el lenguaje de programación propiamente dicho. Con respecto a esta capa “inferior”, se decidió finalmente usar el LuBot (Lua for roBots), otro poyecto del mina emparentado con USB4ALL, por lo tanto el protocolo de comunicación que usamos entre esta capa y el firmware (el software de “bajo nivel” que corre en el microcontrolador), terminó siendo una versión del protocolo USB4ALL pero “encapsulado” para viajar por serial (una diferencia entre los micros AVR usados por Arduino y el PIC18F4550 usado en USB4ALL, es que este último tiene soporte USB nativo, mientras que las Arduino utilizan un chip FTDI que emula un puerto serial sobre USB).

Físicamente hablando, el robot consiste en un “carrito”, “chata” o “tortuga”, como quieran llamarle, es decir una plataforma con dos motores y dos “ruedas locas”, una de ellas amortiguada, capaz de sostener una computadora XO, además de sus propios componentes, entre ellos el pack de 8 baterías recargables de Ni-MH. Respecto a los sensores, habrá un set de ellos y el usuario podrá elegir qué sensores quiere conectar, cuántos de ellos y la disposición espacial de los mismos. Entre los sensores que vendrán en el kit, estarán los clásicos Sharp GP2D12 (medidor de distancia infrarrojo) pero en su variante I2C, más algunos medidores de inclinación, de luz, de tacto, de temperatura, etc.

Les dejo ahora un par de videos del Butiá-Bot en una fase precaria (primeras pruebas hechas a mediados de febrero, con una rueda de menos) y la presentación del proyecto a cargo de Santiago Margni. No olviden visitar la página del Butiá http://www.fing.edu.uy/inco/proyectos/butia/, mantenida por Federico Andrade, quien es además el que subió los videos a YouTube.

Pinche aquí para ver el vídeo

Pinche aquí para ver el vídeo

El proyecto consiste en un soporte robótico para cámaras, que realiza los movimientos de PAN y TILT y es capaz de moverse en incrementos de 0,3º, para usar en películas de stop-motion. También cuenta con un sistema de movimientos continuos automatizados, y están previstas varias mejoras como ser: captura de movimientos, modo autónomo y sincronización con el programa “Dragon Stop Motion”.

A continuación les dejo los videos oficiales del producto y una documentación de la parte informática del mismo. Las animaciones 3D y los videos fueron hechos por Juan Pablo Colasso. En el segundo video puede verse el aparato funcionando, y al maestro Walter Tournier (el creador de “Los Tatitos”) haciendo una animación con el mismo.

Pinche aquí para ver el vídeo

Pinche aquí para ver el vídeo

Cuando la cantidad de combinaciones de variables de entrada es demasiado grande como para elaborar una tabla, y la función es demasiado compleja como para encontrar un algoritmo, las Redes Neuronales Artificiales constituyen una manera distinta de abordar el problema, sumamente efectiva aunque no perfecta, como ya veremos.

Podríamos considerar a la RNA como una especie de “algoritmo universal”, capaz de responder de muchísimas maneras distintas, y al que podemos “enseñar” el comportamiento deseado “mostrándole” ejemplos del mismo (una tabla parcial), para luego esperar que se comporte de la manera buscada frente a todos los casos posibles. Precisamente en esto radican sus principales virtud y defecto: el porcentaje de aciertos puede ser increíblemente grande (teniendo en cuenta lo general que es el método) pero no tenemos ninguna garantía de la exactitud del resultado. La analogía con un “cerebro” animal surge inmediatamente.

Existen en internet numerosos artículos introductorios y avanzados, que explican claramente el funcionamiento de una RNA, mucho mejor que cualquier cosa que yo pudiera escribir aquí al respecto (empezando por este). Mi aporte, en cambio, consistirá en presentar un programa mediante el cual podemos tener una aproximación práctica a la materia, experimentar con redes neuronales, introducir ejemplos reales, lidiar con el entrenamiento y visualizar el proceso de aprendizaje. PNN nos permite “sentir” las redes neuronales artificiales en nuestra propia experiencia, y también resolver algún caso práctico, que fue lo que originalmente me motivó a desarrollarlo.

Características técnicas del programa.

Este programa  se basa en el artículo de Steven W. Smith sobre redes neuronales artificiales, en el capítulo 26 de su excelente The Scientist and Engineer’s Guide to DSP. La red presentada vendría a ser un perceptrón multicapa, con una capa de entrada, una capa oculta y una capa de salida, cada una de ellas interconectada totalmente con la siguiente, con neuronas de bias en las dos primeras capas  y con función de transferencia sigmoide en cada neurona.  El algoritmo de entrenamiento es el que propone dicho autor, al que llama steepest descent, pero que también podemos encontrar bajo el nombre de gradient descent o simplemente backpropagation.

Instrucciones

Para invocar el applet, hagan click aquí.

Al hacerlo, aparecerán 2 ventanas: la ventana de visualización, hecha en Processing, y el panel de control flotante, hecho en Java (que a veces queda oculto tras aquella).

Lo primero que debemos hacer es dimensionar nuestra red. Escribimos el número de neuronas o nodos de cada capa, y apretamos el botón “Dimensionar”. Al hacerlo aparecerá en la ventana de visualización un modelo 3D en el que las neuronas de cada capa están representadas por esferas de distinto color (y las de bias, de un tamaño ligeramente mayor y blancas [ya nos ocuparemos de las opciones de esa visualización, antes de eso, sigamos con la parte "científica"]).

Al apretar el botón “Aleatorizar pesos” aparecen las conexiones entre las neuronas; las verdes son positivas y las azules negativas, y su diámetro es proporcional al peso de la conexión correspondiente.

A continuación deberíamos ir a “Archivo” y seleccionar “Cargar set de ejemplos”, pero lamentablemente esta opción no está habilitada en las applets de internet, por razones de seguridad. En su lugar podemos ir a “Ayuda” y seleccionar “Demo”. Esto tendrá el efecto de dimensionar una red con 7 entradas y 3 salidas, y cargar 3 sets de ejemplos.

Para simplificar las cosas, todos los ejemplos están “asociados” a una salida; esto quiere decir que se asume que producen “1” en dicha salida y “0” en todas las demás. En la lista podemos ver a qué salida está asignado cada ejemplo. Los ejemplos se pueden sacar, seleccionándolos y apretando la tecla “suprimir”. Si apretamos “Enter” sobre un ejemplo, éste se carga arriba, y podemos testear el comportamiento de la red apretando “Procesar salida”. También es posible ingresar valores manualmente en ese campo y probarlos, y una vez ingresados se pueden agregar a la lista con el botón “Agregar ejemplo”. Los valores en las entradas pueden ser enteros de cualquier tamaño; los pesos son números de coma flotante, y los valores de salida son de coma flotante entre 0 y 1.

Si ahora probamos cualquier grupo de valores de entrada, el resultado en las tres salidas va a ser siempre aproximadamente 0,5. Eso se debe a que la red no está entrenada aun. Para entrenarla debemos apretar el botón “Iniciar aprendizaje”. Al hacerlo, los pesos se irán modificando, y un número grande a la derecha nos irá indicando la suma del error que producen todos los ejemplos al ser procesados en la red actual. El objetivo del “juego” (si usted decide aceptarlo) consiste en dejar ese valor lo más bajo posible. El proceso de optimización se repite 1000 veces cada vez que apretamos “Iniciar aprendizaje”, pero habitualmente esto no es suficiente; la cantidad de repeticiones se puede subir a 10000 con el deslizador de abajo a la izquierda. En todo momento podemos ir probando el comportamiento de la red, entre aprendizaje y aprendizaje.

Hasta aquí la operación general del programa. Veamos ahora los detalles.

Redimensionar la red

Al cambiar el número de neuronas en las capas de entrada o de salida, se pierden todos los ejemplos y el aprendizaje realizado. No así al redimensionar la capa oculta. De hecho, es un buen recurso, si notamos que nuestra red tiene “dificultades para aprender”, dotarla de más “capacidad” aumentando el número de neuronas de la capa oculta.

Factor de aprendizaje

Al aumentar este número, hacemos que el aprendizaje sea más rápido, pero también inestable; en ocasiones el error puede quedar oscilando o incluso aumentar. Al disminuir el valor, el aprendizaje se vuelve lento pero seguro.

Aprendizaje extra

La idea de este parámetro está sacada del antes citado libro de S. W. Smith, y consiste darle más importancia, en el aprendizaje, a los ejemplos “positivos” o a los “negativos” (un ejemplo destinado a la salida 2 es un ejemplo “negativo” para la salida 1). Sinceramente yo no encontré ningún resultado con esto, lo voy a revisar para la próxima versión.

Menú Archivo

Todas las opciones del menú Archivo están desactivadas, algunas por razones de seguridad del Java, otras porque no están implementadas aun. La más importante sería la de salvar los pesos una vez concluido el entrenamiento. También podríamos volverlos a cargar para usarlos como punto de partida de una siguiente sesión de aprendizaje.

Menú Configuración

El “Modo Automático” va a estar implementado en la próxima versión. Consistiría en que el propio programa tome nota de cómo va decreciendo o aumentando el error, ajuste automáticamente los parámetros de entrenamiento, y siga actuando solo hasta llegar a un mínimo de error prefijado.

Los distintos “modos de aleatorización” afectan al comportamiento del botón “Aleatorizar pesos”. El algoritmo de aprendizaje parte de un estado aleatorio de los pesos y va modificando sus valores en el sentido en que el error decrece. Puede pasar que en determinado momento el error no descienda más, pero aun continúe alto: estaríamos frente a lo que llaman un mínimo local. Aquí viene al caso la aleatorización relativa, que lo que hace es modificar levemente los pesos pero en relación a su valor actual (introduce una pequeña “mutación”). Con esto conseguimos, a veces, que el error aumente un poco pero luego siga disminuyendo, es algo así como  ”un paso atrás, dos adelante”.

Respecto al error

El dato mostrado a la derecha como “error” se calcula de la siguiente manera:

cada uno de los ejemplos que están en la lista se pasa por la red, y se mide la diferencia entre el valor que debe producir en cada salida y el que realmente produce. Todos estos valores elevados al cuadrado, sumados entre sí y sumados con los provenientes del resto de los ejemplos, nos dan el error total para un estado en particular de la red (media cuadrática). Esto quiere decir que cuanto mayores sean el número de salidas y el número de ejemplos cargados, mucho más difícil va a ser llevar ese valor a 0 (y por supuesto, esto también depende del contenido de los ejemplos mismos). En el caso del problema que viene como demo (que, dicho sea de paso, consiste en diversas versiones de las palabras “uno”, “dos” y “tres” capturadas y codificadas por un nuevo programa de procesamiento de audio que estoy desarrollando para SAMSA) la red se desempeña aceptablemente bien con el error en 20, más o menos.

Opciones de visualización

Por último, la parte “coqueta” del programa.

Al hacer foco en la ventana de visualización, quedan disponibles las siguientes opciones:

• haciendo click con el botón derecho del mouse, detenemos o reanudamos la rotación automática del modelo. Cuando la rotación automática está detenida, podemos rotarlo libremente con el botón izquierdo del mouse.
• con las teclas de dirección seleccionamos un parámetro, que va a aparecer detallado en el ángulo inferior izquierdo de la pantalla, y con las teclas “+” y “–” modificamos ese parámetro.
• los parámetros que se pueden modificar son: la disposición espacial de las neuronas en cada capa, el espaciado de las mismas, la rotación de todo el plano de la capa y la cantidad de caras de la sección de los “caños” que interconectan a las neuronas, que por defecto es 20, pero puede ir de 2 a 50, generando la sensación cilíndrica.

Mejoras para el futuro

Esta es una lista de las mejoras que podrían implementarse en futuras versiones del PNN, algunas de las cuales fueron sugeridas por mis amigos Alvaro y Tomás  (y otras pueden ser un divague, también).

• que las neuronas se muevan, respondiendo a leyes físicas, y que las fuerzas de atracción y repulsión dependan de los pesos.
• ponerle sonido (con la biblioteca minim de Processing)
• esferas texturadas que giren sobre sí mismas
• que las conexiones cambien de color cuando son modificadas
• que las neuronas vibren según su “energía”
• que unas bolas circulen por adentro de los caños
• rotación de las conexiones
• hay que inventar algo para que no haya que apretar 200 veces “Iniciar aprendizaje”
• salvar y cargar pesos
• modo automático: que combine algoritmos genéticos con el backpropagation.

Toda la información aquí: http://www.fing.edu.uy/inco/eventos/sumo.uy/

El evento incluye las tradicionales competencias de sumo en varias categorías, el Concurso Uruguayo de Robótica 2009 y los Workshops. En estos últimos estaremos exponiendo el trabajo “Robótica Recreativa”, con la participación de nuestros amigos “el robotito” y “SAMSA”. Todavía no sé el dia ni la hora exactas, pero presumo que será el jueves a eso de las 19:00 hs. 

Tuve el honor de participar también en los Workshops el año pasado, y todo el evento estuvo buenísimo, no se lo pierdan.

A propósito, vieron la última muestra de talento de SAMSA? Se nos va pa’ Hollywood, se nos va…

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, en breve tendremos información más detallada)