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.

Click here to view the embedded video.

Click here to view the embedded video.

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.

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…

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)