En setiembre del año pasado, luego de su presentación en el marco de los workshops del 6º Campeonato de Sumo Robótico, todavía no tenía muy claro qué hacer con SAMSA, hacia dónde orientar su programación.

Finalmente decidí que SAMSA tenía que ser un robot capaz de un nivel más sofisticado de sensibilidad auditiva, ya que en mis robots anteriores había experimentado más que nada con diversos tipos de dispositivos ópticos (con mayor o menor suerte), y de emisores de sonido. Esto podría darme la excusa, por ejemplo, para desarrollar un sistema de reconocimiento del ritmo, que le permitiera al robot bailar al compás de la música (y de paso me serviría para el momentáneamente abandonado proyecto Zappator). Por otro lado, me interesaba también experimentar con redes neuronales, ya que suponía que éstas podrían constituir una alternativa a tener que programar línea por línea todo el comportamiento de un robot.

Tal como había publicado en la 1ª etrega de la documentación de SAMSA, la distribución total de tareas del robot a cargo de un sólo y modesto ATmega128 (microcontrolador de 8bit/128KB/16MHz) dejaba, en lo que respecta al audio, tan sólo la posibilidad de medir la intensidad del sonido cada cierto lapso, y ni soñar siquiera con algún tipo de análisis de frecuencias.

La única alternativa parecía ser la de incluir un segundo procesador hardware, exclusivamente dedicado al procesamiento de sonido; pero eso implicaba agregar más componentes, en definitiva, exigirle más al ya sobrecargado sistema electro-mecánico del robot. Era mucho trabajo, y no me convencía.

Se me ocurrió entonces otra solución: al mejor estilo “ZX-81”, el robot entraría temporalmente en un modo “escucha”, durante el cual no podría moverse, mostrar gráficos ni hacer ninguna otra cosa; utilizaría todos sus recursos para “analizar” el audio y actuar en consecuencia. La idea sería aumentar la frecuencia de las interrupciones (a 8KHz, de hecho), y sustituir la actual ISR (interrupt service routine), por otra que sólo procesara audio.

Bien, y cuando decimos “procesar audio”, lo primero que nos viene a la mente es analizar frecuencias. ¿Por qué? Por muchísimas razones, talvez la más importante es que nuestro cerebro mismo percibe el sonido de esa manera. Como no soy para nada experto en FFT, ni estaba seguro de que fuera realmente posible su implementación con estos escasos recursos de cómputo, busqué algún tipo de proceso más liviano, hasta que llegué a un algoritmo que yo mismo bauticé “filtros por correlation recursivos”, que ya debe estar inventado, con otro o con el mismo nombre, y que veremos en breve.

Una vez implementados los 4 filtros de frecuencias fijas (o bandas, no me pregunten.. por cierto, es probable que toda la implementación esté plagada de errores de aliasing y distorsiones de todo tipo; no obstante, contra todo pronóstico, funciona) mirando en la pantalla las gráficas que estos filtros producían, tuve la intuición de que era posible intentar un reconocimiento de palabras, y eso me iba a dar la excusa para “entrarle” a las redes neuronales.

Pasaron un poco más de 6 meses, durante los cuales primero desarrollé la herramienta de diseño y entrenamiento de redes neuronales (Palmer Neural Networks), pero después, al momento de usarla, me daba cuenta de que faltaba algo y no podía avanzar, estaba bloqueado. Por un lado no disponía de mucho tiempo para pensar en esta idea, y por otro lado había empezado a dudar de que fuera posible cumplir con el objetivo. Finalmente a fines de febrero de este año, comencé a dedicarle horas al proyecto, hasta que llegué a este resultado, que dista de ser ideal, pero que nos ilustra claramente qué podemos esperar y qué no, de un sistema con estas características.

Los invito a compartir un viaje por la arquitectura interna de un sistema de reconocimiento de palabras implementado íntegramente en un microcontrolador ATmega128.

Siguiente sección –> Reconocimiento de voz en un ATmega128

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!

Click here to view the embedded video.

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.

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.