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.

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

Buscando una herramienta para programar y experimentar con audio, efectos y síntesis, decidí probar la biblioteca Minim de Processing. Existen muchos entornos informáticos interesantes para diseñar sonido, algunos son gráficos, otros son de escribir código, algunos son libres, otros son pagos; cito algunos ejemplos: Reaktor, Max-MSP, PureData, SynthEdit, SynthMaker, JSyn, Csound, SuperCollider, ChucK.

Dentro de Processing, existen varias bibliotecas para manejar sonido, entre ellas: Ess, Sonia y Minim, siendo esta última la que viene con la distribución oficial del producto. Rápidamente, repasemos las principales ventajas e inconvenientes -a mi modesto entender- de Minim:

• Ventajas: es simple, transparente, bastante bien documentada y Open Source.
• Inconvenientes: utiliza Java Sound para comunicarse con el hardware de audio.

Muchas de las bibliotecas de Processing son justamente “wrappers” de las funcionalidades de Java. Minim utiliza Java Sound para el audio I/O, partes de otras bibliotecas para otras tareas -como reproducir mp3, por ejemplo- pero también agrega cosas propias e interesantes, en materia de análisis, procesamiento y generación de sonido. A su vez, uno de los principales inconvenientes del sistema de audio de Java es que no soporta ASIO, que como todos sabemos, es la única manera de obtener baja latencia, al menos bajo Windows XP.

¿Cómo funciona la generación de sonido a nivel de software?

El audio digital, a nivel del software, se maneja en buffers. Un buffer es un conjunto de muestras -por ejemplo, 1024 muestras- que se envían o se reciben en bloque hacia o desde el hardware. Mientras la tarjeta de audio reproduce esas 1024 muestras (lo que le llevará 23ms, si el muestreo es de 44,1KHz), el programa tiene tiempo de calcular el bloque siguiente. Cuanto más grande sea el buffer, o sea cuantas más muestras contenga, mayor será la latencia de la que hablábamos en el párrafo anterior (más información sobre buffers y latencia aqui).

En Minim, la clase Oscillator es la base de los generadores de sonido. Cuando se llama al método “generate”, este “llena” un buffer con una forma de onda calculada de alguna manera, por ejemplo con la función trigonométrica seno.

Una consecuencia interesante de esta naturaleza de Minim, es que si nosotros intentamos modificar un parámetro de la onda que se está generando -por ejemplo su amplitud o su frecuencia- desde el módulo principal (la Draw() de Processing) ya sea a partir de un control externo o de una función prefijada, los cambios se van a manifestar de a “saltos” equivalentes a la duración del buffer (23ms, en el ejemplo que veíamos). Esto nos impide hacer un cambio gradual y continuo de cierto parámetro, por ejemplo una envolvente de amplitud. Para lograr este tipo de control, necesitamos implementar otro “Oscillator” que genere la señal de control, y que el primer “Oscillator” consulte a esa señal al calcular cada muestra que pone en el buffer.

Aplicando esta idea a diversos módulos de la biblioteca, e implementando algunos módulos nuevos, surgió la Minim 2.02 PE (palmer edition), con la cual podemos hacer una modesta síntesis modular, que paso a describir y ejemplificar en la página a continuación.

Siguiente sección –> Minim 2.02 Palmer Edition

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 “deducir” 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 vago 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 las 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.

Para invocar el applet, hagan click acá.

A primera vista puede resultar incomprensible, pero este círculo nos presenta en un solo esquema muchas propiedades interesantes de las escalas. Aquí va la explicación.

1) La primer característica importante que van a observar es que en este círculo, en lugar de los nombres de las notas (DO, SOL, RE, etc.) tenemos intervalos: “Fundamental”, “5a. justa”, “2a Mayor”, etc.; es un círculo “relativo”.

2) Con las teclas de dirección izquierda y derecha podemos mover los “quesos” a lo largo del círculo. Con las teclas “arriba” y “abajo” cambiamos la escala generadora. La escala con la que arranca es la Mayor, y sugiero dejarlo en esa hasta familiarizarnos un poco con la onda del programa.

3) Al ubicar un modo en la posición “Fund.”, el resto de los quesos nos indicarán los intervalos presentes en ese modo, y los nombres de los modos que se forman en cada uno de ellos. Por ejemplo, si pongo el modo Jónico en la fundamental, el programa me dice que el mismo está formado por Fund., 2a.M, 3a.M, 4a.J, 5a. J, 6a.M y 7a.M y que en la 5a. tiene el modo Mixolidio, en la 4a. el Lidio, etc.

4) Asimismo, nada me impide colocar un modo en un intervalo cualquiera del círculo, por ejemplo, vamos a suponer que tenemos el modo Jónico en la 5a.J de “algo”. En ese caso, el programa nos dice que vamos a tener el Mixolidio en la 2a.M de ese mismo “algo”, el Dórico en la 6a.M, etc. Es un poco pirado, pero ya le van a encontrar utilidad.

5) Por último, el color de los quesos intenta indicar aproximadamente el “color armónico” de cada modo. Esta es la parte más  interesante del programa, la había esbozado en la versión original en Qbasic (última revisión, 2002) pero la concreté por primera vez en esta versión. Es interesante porque se plantea, al igual que en Zappator, el tema ”algoritmo vs. tabla”. Veamos cómo funciona.

El tema de asociar un “color” a determinado conjunto de notas, es, por supuesto, algo totalmente subjetivo. El criterio que yo adopté es el siguiente: el color tiende al azul cuando el acorde fundamental es un Maj7, al rojo cuando es un “dominante”, al verde cuando es un menor y se vuelve oscuro en presencia de un disminuido o de notas “raras”. La forma de implementarlo fue mediante una especie de red neuronal de 1 capa sola, con 4 nodos (los 3 colores básicos + la “oscuridad”) cada uno de ellos con 11 entradas (cada una de las posibles notas presentes o no en el modo, además de la fundamental). Los ”pesos” de esta red fueron asignados “a mano”, dando valores mayores a las notas más representativas del “color armónico”, valores negativos a las notas “antagónicas”, etc. De esta forma el programa “calcula” el color de cada modo, en lugar de leerlo de una tabla, como sí hace en cambio con los nombres, por ejemplo. Sigue pendiente una explicación de por qué me gustan tanto estos mecanismos “generativos”.

1) Malena Morgan – Azucena (1995)

La tendencia en Malena Morgan derivó hacia la canción, y los temas eran habitualmente de Herman. Este sin embargo es un tema mío e instrumental, que se editó en un disco colectivo del año ‘95, como resultado de un concurso de la IMM de música instrumental. Los integrantes acá son: Herman Klang en teclados, Sebastián Laurito en guitarra, Diego Bartaburu en batería y quien les habla en el bajo. Fue grabado en mi casa y mezclado en “El Estudio” por César Lamschtein. 

2) Ardito & Duré – El séptimo (2000)

Tema de Marcelo Rocha (el pelado) con él mismo en vocales, Gabriel Fletcher en guitarra, Sergio Fernández en percusión, Federico Moreira en batería, y yo en el bajo. Banda que duró muy poco, habremos tocado 4 o 5 veces y no editamos ningún disco. Este demo se grabó en el 2000, la batería en “La zapada” y el resto en mi casa, y lo mezclé yo mismo.

3) Hay que Armar – Desolación (2005)

Hay que Armar, banda que estaba integrada por Sebastián Laurito en guitarra y voz, Diego Bartaburu en batería, Elena en vocales y este humilde servidor en el bajo. Este tema lo compuso Sebastián Laurito, la grabación es un demo hecho en el estudio de Max Capote en el 2005.