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.

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, como siempre, aquí van a ver parte de la presentación en dorkbot.mvd el 19 de abril de este año, pero prometo ampliar la información técnica y anecdótica de este maravilloso artefacto, en el futuro.

LA BAILATA

INTERACCION CON LA MAQUINA DE LOS DIOSES

 (Este post es provisorio, en breve tendremos información más detallada)