Por fin algo para subir al blog!

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.

Fuente de energía de SAMSA: batería LiPo de 7.4V/730mAh. Otra batería más grande y el cargador.

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.)

A escala.

Mini-circuito.

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.