Aquí estudiaremos todos los aspectos técnicos de la construcción y programación de SAMSA II, en especial comparándolo con su antecesor, el SAMSA clásico.

-

Varilla central de acero de 7mm, sacada de un escáner.

Mecánica

La estructura mecánica de ambos robots es similar, una “columna vertebral” a lo largo de la cual se insertan las patas, 3 de cada lado. En SAMSA, la columna vertebral es un perfil de aluminio en forma de “U”, mientras que en SAMSA II es una varilla cilíndrica de acero de 7mm de diámetro, a la cual se acoplan directamente los motores. La ventaja de este nuevo diseño es que reduce todo lo posible el ancho del robot, dándole un aspecto más elegante. Por cierto, ensamblar los motores al caño es un poco más difícil, pero se resolvió satisfactoriamente.

Pata estilo SAMSA II

Amortiguador de SAMSA II. 1) soporte; 2) tubo de fibra de vidrio; 3) resorte; 4) tope; 5) punta de goma

SAMSA II cuenta con unos hermosos y efectivos amortiguadores en las patas, además de tener las puntas convenientemente terminadas en goma, para mejorar la adherencia al terreno. Esto representa una gran ventaja sobre SAMSA, en el cual la amortiguación, si bien estaba resuelta de una manera ingeniosa, presentaba no pocos problemas, y sus apoyos extremadamente finos tampoco lo ayudaban. Para construir los amortiguadores de SAMSA II, fue necesario modificar algunas piezas del kit Bioloid, y usar unos tubos de fibra de vidrio de 7mm de diámetro, con unos resortes fabricados en “La Casa del Resorte”, en Yaguarón y Valparaíso.

Por último, las dimensiones de SAMSA II son superiores a las de SAMSA, es de aproximadamente 1.5 veces el tamaño de su antecesor.

Motores

Bueno, aquí es donde radica la diferencia fundamental entre ambos hexápodos. Los motores de SAMSA son micro-servos débiles, de 1.3 Kg/cm de torque, bastante rápidos, eso sí, pesan 9g, cuestan menos de 10 dólares cada uno, y sus engranajes son de un plástico muy malo, cuyos dientes ceden a la más mínima fuerza. Los de SAMSA II son servos robustos, de 13 Kg/cm de torque, un poco más lentos, lamentablemente, pesan 55g, cuestan 45 dólares cada uno, y sus engranajes son de plástico pero resistentes.

Pero ahí no termina la cosa, la diferencia más importante, en realidad, es que los primeros son servos analógicos, “tontos”, que necesitan permanentemente una señal PWM para trabajar (y en el caso de SAMSA, esa señal, para los 18 motores, es generada por software, consumiendo más de la mitad del tiempo del único procesador disponible) y en el segundo caso se trata de los Dynamixel AX-12+, servos digitales “inteligentes”, a los cuales basta con indicarles una vez la posición a la que deben ir, y la velocidad con que deben hacerlo, a través de un interfaz serial a 1 Mb/s, los 18 motores conectados a un mismo bus (lo que al procesador central de SAMSA II le lleva muy poco tiempo, pero por si fuera poco, el robot cuenta con 2 procesadores adicionales).

Microservo analógico de 9g vs. Dynamixel AX-12+. El primer modelo aun se usa en la cabeza de SAMSA II.

La consecuencia de todo esto es evidente: si bien SAMSA es capaz de efectuar movimientos a gran velocidad, su sucesor le gana por lejos en complejidad, exactitud, fluidez y fuerza de los movimientos. Por otro lado, uno de los grandes problemas de SAMSA era que había que reducir al mínimo las pruebas, por el riesgo de que el robot sufriera alguna rotura en ellas.

SAMSA II tiene 2 servos adicionales para la cabeza. Para esto usamos los mismos microservos y los mismos brackets de aluminio caseros que en el viejo hexápodo, pero en este caso la señal PWM es generada por hardware, a través del Timer5 del ATmega1280 (timer de 16 bits), de manera que no consume tiempo del procesador.

Batería LiPo de 11.1V de SAMSA II.

Batería

La batería de SAMSA II es una LiPo 3 celdas, 11.1V / 730mAh, capaz de entregar corrientes de hasta 14A en régimen normal con picos de hasta 29A. Es exactamente igual a la de SAMSA, pero de 3 celdas en lugar de 2, por lo que entrega 11.1V en lugar de 7.4V.

Con esta batería, la autonomía de SAMSA II es de unos 10-20 minutos.

Microcontrolador

SAMSA está basado en la tarjeta Wiring, con un microcontrolador ATmega128, y SAMSA II en la Arduino Mega, con un ATmega1280. Ambas placas son bastante similares, el ATmega1280 tiene 8 KB de SRAM, el doble que el ATmega128. Asimismo, el entorno Arduino es levemente más amigable que Wiring, aunque ésta tiene siempre las bibliotecas más avanzadas. En SAMSA II no usamos el entorno Arduino, sino que programamos directamente en C++, utilizando bibliotecas tanto de Arduino como de Wiring.

Diagrama en bloques de la electrónica de SAMSA II.

Pero además de esto, SAMSA II cuenta con 2 microcontroladores adicionales. Uno de ellos es una tarjeta Arduino Mini de las viejas, con ATmega168, que se encuentra en la cabeza, y se encarga de procesar la información de los sensores. El otro es un ATmega8 y se encuentra integrado de fábrica en el display, por lo que podría considerarse ajeno al propio robot; sin embargo, el firmware de este display fue modificado, y toda la biblioteca gráfica se aloja en él, lo que libera al microcontrolador central de la tarea de tener un ‘frame buffer’ y actualizar permanentemente la pantalla pixel por pixel.

El micro de la cabeza se encarga de muestrear, filtrar y procesar la información del sensor de distancia Sharp, que, gracias a los dos sensores a led IR laterales, queda transformado en un “súper sensor inteligente de distancia”. Este módulo también se encarga de decodificar la señal proveniente del sensor IR de 38KHz, para el control remoto.

En conjunto, estos 2 micros alivianan aun más la tarea del ya relajado procesador central, creando un ambiente óptimo para desarrollar sofisticados movimientos y conductas complejas.

Sensores

Trabajar con sensores no es tan fácil como parece. Casi siempre, para sacar un buen provecho del sensor, hace falta muestrearlo periódicamente y aplicar algún tipo de procesamiento sobre el conjunto de muestras obtenidas (lo que se conoce como DSP, procesamiento de señales digitales). Esto es evidente en el caso de un sensor de sonido (micrófono) pero también se aplica a los sensores de distancia y a todos en general. El problema es que este muestreo y procesamiento también consume ciclos de procesador, y complica bastante la programación, sobre todo en un entorno donde la mayoría de los procesos tienen que ser real-time.

Por el momento, SAMSA II cuenta con un único sensor, el popular sensor de distancia Sharp GP2D12, pero por primera vez este sensor está aprovechado al máximo. Enumeremos las características que hacen posible este aprovechamiento:

• El sensor está integrado sobre una cabeza móvil, con 2 servos iguales a los de SAMSA, capaz de efectuar el clásico movimiento de pan/tilt.
• La cabeza posee su propio procesador, una Arduino Mini con ATmega168, que se encarga de muestrear el sensor a alta frecuencia, filtrar la señal, extraer datos como la distancia instantánea en milímetros, la velocidad con que se aproxima o se aleja un objeto, ciertos “gestos”, y compensar la falencia del Sharp en distancias menores a 10 cm, así como también detectar objetos lateralmente a cortas distancias.
• La compensación del Sharp en cortas distancias y la detección lateral se hace con una técnica similar a la del “ojo electrónico” del Robotito de 2008, que requiere también un muestreo y procesamiento.

Súper-sensor inteligente de distancia.

De esta manera, el procesador central queda liberado de todas estas tareas, y el programa principal sólo tiene que solicitar la información que desea a la cabeza, a través de un simple y eficiente protocolo Serial.

La cabeza también posee el detector de IR de 38KHz, que permite operar el robot desde el control remoto IR. Este detector genera una interrupción externa en el micro de la cabeza, y a continuación éste decodifica la señal, con el protocolo NEC, y manda el código correspondiente por Serial.

El SAMSA original también contaba con un micrófono, las antenas giratorias con encoder, y un acelerómetro de 3 ejes. El acelerómetro nunca llegó a utilizarse, y la razón es que la programación se volvió tan compleja sólo con el resto de los sensores, especialmente con el de audio, que nunca llegamos a la etapa del acelerómetro. La idea en SAMSA II es incluir también el micrófono y el acelerómetro, y también sensores de presión en las patas, para caminar sobre superficies irregulares, pero utilizando para esto cuantos procesadores auxiliares sean necesarios, con tal de no sobrecargar al procesador central con tareas, obligándonos a una programación intrincada, difícil de entender y de mantener, como ocurría en SAMSA. En particular me gustaría incluir todo el desarrollo que se hizo sobre reconocimiento de voz con redes neuronales, en un micro dedicado y con una circuitería externa un poco más prolija.

Por último, investigaremos la posibilidad de usar los propios motores AX-12 como sensores de fuerza, con lo cual el robot podría detectar cuando se lo empuja, o se le levanta una pata intencionalmente, etc.

 -

Display

El display es sumamente útil, no sólo a la hora de interactuar con el robot, sino durante el desarrollo, como monitor para la depuración del software. En SAMSA utilicé un display Led matricial de 8×8 monocromático. En SAMSA II, utilizamos también un display Led matricial de 8×8, pero esta vez RGB y de mayor tamaño.

En SAMSA el control del display estaba a cargo del procesador central y único del proyecto, así como el resto de las cosas (y pensándolo bien, es una auténtica proeza que realmente se pudiera controlar todo con ese solo micro). El display que usamos en SAMSA II cuenta de por sí con una electrónica que se encarga del multiplexado de los 64×3 leds, con un microcontrolador ATmega8. Dicha electrónica lo convierte en una simple pantalla de 64 pixels, a la que hay que enviarle la información de cada pixel via SPI, para visualizar cualquier gráfico. Con el firmware original, además, cada pixel soportaba 7 colores, es decir, las combinaciones básicas de rojo, verde y azul.

El truco aquí fue modificar ese firmware, de modo de:

1. aumentar la resolución de color a 64, 4 niveles por cada color básico
2. implementar un modo “inteligente”, en el que el display puede dibujar puntos, líneas, rectángulos, círculos, letras, y una variedad de gráficos, con un sistema de manejo del color, similar a una biblioteca gráfica 2D básica.

Esta biblioteca es, en realidad, la misma que ya habíamos implementado en SAMSA, con el agregado del manejo del color. De este modo, el programa principal se desentiende de los gráficos, ni siquiera tiene que gestionar un frame buffer, apenas mandar unos simples comandos por SPI para desplegar texto o imprimir hermosos gráficos en color.

Control remoto IR, perteneciente a una vieja tarjeta de video MSI.

Operación

SAMSA, y su antecesor “El Robotito” nunca fueron pensados para ser operados por un humano, yo planeaba que fueran completamente autónomos. Sin embargo, un mínimo de manejo externo siempre es necesario, y para ello recurrí oportunamente a soluciones bastante insólitas (el menú con antenas giratorias, los “gestos”). En SAMSA II, en cambio, volvimos al tradicional control remoto; de hecho, es el mismo control remoto de La Máquina de los Dioses, y la misma rutina de decodificación IR, reutilizada textualmente.

Software

Una de las especialidades de Jorge es sin duda la programación, y aquí es donde su aporte juega un rol decisivo. A comienzos del 2010 yo sólo sabía programar en el entorno Arduino, pero el contacto con programadores “de verdad” me fue volcando progresivamente hacia el C++ “puro”. Por otro lado, me fui dando cuenta de que programar no es solamente manejar la sintaxis de un lenguaje, es organizar tu código para que sea legible, entendible, manejable, mantenible y reutilizable, a la vez que elegante y eficiente en el consumo de recursos.

Y ahí no termina la cosa, la otra parte del asunto son los propios algoritmos. Por ejemplo, en el caso de un hexápodo, hay muchas maneras posibles de escribir un código que lo haga caminar, y la manifestación externa de todas ellas puede ser la misma, o muy similar en todos los casos. Sin embargo, según la conceptualización o “abstracción” inicial que hayamos hecho del problema, nos resultará más fácil, más dificil, o directamente imposible, luego, lograr que el mismo código lo haga caminar a distintas velocidades, con distintos pasos, en distintas direcciones, levantando más o menos las patas, haciendo otros movimientos a la vez, etc.

SAMSA II puede caminar conservando una posición arbitraria del tronco.

Si bien todas las líneas de código de SAMSA II hasta el momento las escribí yo, los grandes algoritmos, especialmente el de la caminata y el “agendamiento” de eventos, las directivas para encarar los distintos aspectos de la programación, la estructura general del programa, y la paciencia de contestar cientos de dudas con el lenguaje, pertenecen a Jorge.

Entorno de programación

En proyectos como el SAMSA original, yo sufría el problema de no poder separar los bloques de código en distintos archivos, y trabajar únicamente con la parte que me interesaba del programa, en determinado momento. Cuando abandonaba la programación por unos dias (y tenía que hacerlo, para atender mi verdadero trabajo, el que me da de comer), al volver sobre el programa, me costaba muchísimo meterme en él, entender cómo trabajaba y qué era lo que tenía que modificar o completar. Esto era consecuencia de una programación desordenada, a la que te empuja el propio entorno Arduino / Wiring. En programas grandes, se vuelve imprescindible separar el código en muchos archivos “.h” y “.cpp”, cosa que en el entorno Arduino se puede hacer, pero al precio de una tremenda incomodidad. El IDE Arduino era ideal para el tipo de proyectos que se podían hacer con la placa original basada en ATmega8, pero para lo que se puede hacer con las placas actuales como la Mega o la Mega 2560, ya hace falta un entorno de programación estándar, como el Eclipse o el Visual Studio.

El primer paso, entonces, para lograr una programación ordenada, era salir del entorno Arduino. Yo intenté primero crear un ambiente AVR en CodeBlocks, luego con Jorge intentamos lo mismo en Eclipse, pero en ninguno de los 2 casos logramos compilar código de Arduino. Finalmente yo encontré la herramienta de oro: el AVR Project IDE. Su nombre lo dice todo, es libre y es compatible con Arduino. La única desventaja que presenta (para Jorge, no para mí) es que corre únicamente en Windows.

Captura de pantalla del AVR Project IDE.

Con el AVR Project IDE logramos compilar el código Arduino original, y poco a poco transformarlo en un programa C++ puro. A partir de ahí, podemos utilizar algunas partes del propio Core de Arduino, bibliotecas como la String de Wiring, y reciclar código C y C++ que se encuentra fácilmente en la web.

Características del software

Las posibilidades de SAMSA II, por el momento, abarcan poco más que las rutinas de caminata y movimientos del cuerpo. Sin embargo hay una mejora sustancial en estos dos rubros, con respecto a lo que era el SAMSA original.

Comunicación Serial entre los módulos

Para la comunicación del módulo principal con la cabeza y el display, usamos un protocolo muy simple, implementado sobre el USART o sobre el SPI. La gestión de bajo nivel del USART la hacemos con la biblioteca HardwareSerial de Arduino, y el SPI directamente desde el microcontrolador. La capa alta del protocolo es la misma en ambos casos, y es, al igual que en todos mis proyectos anteriores, una variación del protocolo MIDI.

Al igual que en el MIDI, existen dos tipos de bytes, los bytes de datos y los de cabecera. Los bytes de cabecera indican que allí empieza un mensaje, y especifican qué tipo de mensaje es y cuántos bytes ocupa. La clase “serialcomm” es la que implementa el lenguaje de comunicación, y permite especificar cuántos bits ocupa la información de cabecera. Suponiendo que esa cantidad sea n, los bytes de datos quedan restringidos a valores en el rango 0 – 255-2^n.

Multitarea / Interrupciones

En “El Robotito” primero y posteriormente en SAMSA, utilicé la técnica de generar interrupciones periódicas para “automatizar” ciertas tareas, lo que constituye una suerte de multitasking elemental. En El Robotito, la tarea automatizada es el muestreo y procesamiento del “ojo electrónico”. En SAMSA, es el muestreo y procesamiento de todos los sensores, más la actualización del display, más lo que yo llamé el “subsistema de movimiento” (una locura, ahora que lo veo). El subsistema de movimiento es la rutina que genera las señales para los 18 servos, a partir de unos arrays en los que, desde el programa principal, se puede escribir el ángulo destino y la velocidad para cada servo.

Sistema de interrupciones en un timer del microcontrolador.

En SAMSA II, este concepto está llevado aun más lejos, y existen 2 niveles de interrupciones periódicas; uno de ellos se encarga del “subsistema de movimiento de bajo nivel” y en el otro se pueden habilitar o deshabilitar las siguientes tareas: movimientos de alto nivel, animaciones del display y polling de los sensores de la cabeza.

Obsérvese que todas estas tareas son, en cierto modo, “de alto nivel”, dado que las verdaderas tareas de bajo nivel son realizadas por los procesadores periféricos. Es decir, en SAMSA II, muchas de las tareas automatizadas son “burocráticas”, consisten en traficar información a través de los interfaces seriales, y no en controlar directamente los propios dispositivos.

Por ejemplo, en el más bajo nivel de movimiento en SAMSA II, la rutina sólo tiene que transmitir ángulos y velocidades a los motores, en lugar de generar 18 señales PWM, como pasaba en SAMSA. Por esta razón, el subsistema de movimiento de bajo nivel de SAMSA II permite una funcionalidad más sofisticada: en lugar de escribir ángulos destino, directamente escribimos posiciones de las patas en coordenadas cartesianas, y en lugar de especificar solamente la posición y la velocidad inmediatas en un array, podemos agendar “eventos” de movimiento con timestamp, a ejecutarse en el futuro, en una estructura de datos tipo deque (double-ended queue). Esto representa un avance notable con respecto al antiguo subsistema de SAMSA; en SAMSA II ya no se trabaja con ángulos, todos los movimientos son por cinemática inversa, y ya no hay necesidad de ir generando en tiempo real las secuencias, se puede pre-agendar toda una secuencia de movimientos, y la misma se ejecutará sola, mientras el programa esté haciendo otra cosa.

Subsistema de movimiento de bajo nivel.

La resolución temporal de los “eventos” es de 4ms. Cada 4ms, la rutina se fija qué servos necesitan ser actualizados, y los actualiza todos con un único mensaje SyncWrite, donde transmite posición y velocidad de todos esos servos. El chequeo se hace contra un array donde están todos los valores en ángulos, pero los eventos agendados son en coordenadas cartesianas. Es decir, la rutina toma el o los eventos para ejecutar, los pasa por la cinemática inversa, y los escribe en el array de “angulos destino”. Luego, ese array se compara con el de “ángulos actuales” y los que hayan cambiado se actualizan. La velocidad de cada servo se calcula en base a esta diferencia entre los ángulos destino y actual, teniendo en cuenta la duración del movimiento, y se envía junto con las posiciones en un único gran mensaje SyncWrite.

Ahora bien, algunas secuencias, como la caminata, aun deben ser generadas en tiempo real, puesto que no conocemos de antemano la trayectoria que el robot debe seguir, en caso de que ésta dependa de los sensores o del control del usuario. Pues bien, para esto existe el segundo nivel de interrupciones periódicas, el de “movimientos de alto nivel”. Es decir que, aun los movimientos complejos se pueden reducir a una orden única, como por ejemplo “caminata recta, angulo=PI/2, velocidad=30 cm/s, largo_paso=15 cm” y misteriosamente el movimiento se ejecutará solo, mientras el programa principal sigue procesando cualquier otro comando.

Utilización de los timers / interrupciones en SAMSA II.

Lo mismo ocurre con el display: la automatización ya no es para generar la imagen misma, ya que de eso se encarga el “coprocesador gráfico”, sino para generar animaciones, por ejemplo el texto –muy útil– que se va desplazando (para esto, la biblioteca del display cuenta con transformaciones como scroll, rotate, etc. de modo que, para el procesador central, animar gráficos sigue consistiendo en mandar comandos de alto nivel via SPI).

Y por último,  el “polling de sensores” se reduce a un simple tráfico de valores a través de un puerto serial (la Arduino Mega tiene 4 USARTs), y estos valores ya están prêt à utiliser, ya que han sido previamente procesados por el microcontrolador de la cabeza.

      

Manejo de los motores Dynamixel AX-12+

Para manejar los motores AX-12 usamos nuestra propia biblioteca AX-12, que ya va por la versión 2.3. La versión original era una adaptación de la biblioteca de Arbotix, que yo hice para el Proyecto Butiá, pero posteriormente la biblioteca fue evolucionando y tomando un rumbo propio. La versión 2.2 fue desarrollada especialmente para SAMSA II, ya que implementaba por primera vez los mensajes SyncWrite, esenciales en el hexápodo. 

  

Cinemática Inversa / Geometría 

La cinemática inversa en SAMSA II juega un rol mucho más importante que en SAMSA, ya que se la utiliza en todo momento. En SAMSA II ya no es posible atacar directamenrte los ángulos de los servos, todo lo que se puede hacer es mover las puntas de las patas, en coordenadas cartesianas. 

La rutina que efectúa la conversión de coordenadas cartesianas a ángulos, es básicamente la misma que lo hacía en SAMSA, con algunas optimizaciones en la matemática. Para el momento en que se hizo el video, esta rutina todavía arrastraba un error, que fue posteriormente corregido. 

Por otro lado, en SAMSA II todos los cálculos para los movimientos son universalmente efectuados con aritmética de vectores y matrices, gracias a lo cual el código se vuelve mucho más elegante y sencillo de entender. Este es un gran aporte de Jorge, que representa otra mejora sustancial con respecto al viejo SAMSA, en el que yo me había hecho unos entreveros bárbaros para implementar ciertos movimientos, y otros estaban todavía basados en la manipulación directa de los ángulos. 

Cinemática inversa de una pata.

La figura muestra cómo se convierten las coordenadas cartesianas a ángulos. Como vemos, se forman tres triángulos, y dos de ellos son rectángulos. En éstos, resulta fácil calcular los ángulos necesarios usando las funciones trigonométricas inversas, y las hipotenusas usando el teorema de Pitágoras. En el tercer triángulo, aplicamos el teorema del coseno, para calcular los ángulos restantes. 

     

Caminata  

Por ejemplo la caminata, es absolutamente superior en SAMSA II. Si bien lo que nos proponíamos con Jorge era aun más sofisticado, lo que resultó hasta el momento es sumamente interesante. 

La caminata en SAMSA estaba basada en ángulos, y era todo lo parametrizable que se podía, en virtud de su naturaleza, pero el resultado no está ni cerca de lo que se puede conseguir en SAMSA II. 

En éste, la caminata es absolutamente paramétrica, y está basada en un concepto que introdujo Jorge, con algunos aportes de ideas mias. Básicamente, durante la caminata ocurren contínua y simultáneamente dos procesos: por un lado el cuerpo se va desplazando en la dirección del movimiento, lo que genera una desviación de las patas que están apoyadas en el sentido contrario, y por otro lado hay una corrección periódica de la posición de estas patas, lo que llamamos los “pasitos”. Los pasitos son efectuados describiendo unas curvas llamadas “Bézier”, solución matemática que aportó Jorge a una inquietud original mia. Las curvas Bézier son pre-agendadas usando el subsistema de movimiento de bajo nivel, de modo que ambos procesos ocurren simultáneamente. Esta combinación del desplazamiento del cuerpo más los pasitos, da como resultado un andar fluido, elegante, y sumamente controlable. 

Principio de la caminata en SAMSA II.

La rutina de caminata posee un montón de parámetros que se pueden variar, por ejemplo, entre otros, los siguientes: 

• velocidad
• largo de los pasos
• postura de referencia
• secuencia de patas
• cantidad de “pasitos” simultáneos
• sub-agrupación temporal de los pasitos
• duración de los pasitos
• altura de los pasitos
• resolución temporal (subdivisión) del movimiento del cuerpo (lo que llamamos “micropasos”)
• dirección (ángulo) de la caminata (en caso de ser recta)
• en caso de ser curva, sentido y centro de la curva.

etc., etc. 

La única desventaja de SAMSA II frente a SAMSA, en materia de caminata, es que no puede alcanzar la velocidad de éste, pero ello se debe sencillamente a que los motores son más lentos. Tenemos en vista la sustitución de los AX-12 por AX-18, que cuestan 90 dólares cada uno, con lo que el costo total del hexápodo superaría los 1600 dólares. Se aceptan donaciones ;) 

Algunas cosas en la caminata pueden seguir mejorando, especialmente evitar que se choquen las patas al partir de posiciones arbitrarias. 

  

Movimientos del cuerpo  

Las rotaciones y traslaciones del cuerpo, infaltables en cualquier hexápodo que se precie, son efectuadas de un modo casi transparente, gracias a la aritmética de vectores (de forma muy similar a como lo hace una biblioteca gráfica 3D). Una consecuencia de esto, es que se pueden efectuar rotaciones con centro arbitrario en el espacio, por ejemplo, cosa que en el video no fue mostrada porque aun no tiene teclas asignadas en el control remoto. 

Movimiento del cuerpo en 3D.

  

Oscilaciones

En SAMSA existían una serie de rutinas dispersas como la “movimiento circular” o “movimiento browniano” que eran especies de “macros” de movimientos del cuerpo. En SAMSA II, merced a la automatización de movimientos de alto nivel, existe una rutina universal para generar todo este tipo de “firuletes”, llamada “oscilador”. Cada uno de los 9 parámetros (desplazamiento XYZ, rotación XYZ y centro de la rotación XYZ) puede ser asignado a un oscilador sinusoidal, con frecuencia, amplitud y fase independientes, o a un movimiento aleatorio (browniano) también parametrizable. Esto es algo que tampoco se ha visto en esta primer filmación. 

 

Trabajo a futuro 

Podríamos decir que este proyecto recién comienza, arrancamos hace seis meses y decidimos tomarnos un tiempo para mostrar lo que teníamos hecho hasta el momento, pero es muchísimo el trabajo que aun nos queda, de acuerdo a lo que planeamos hacer con SAMSA II.

Este trabajo podría agruparse en tres direcciones:

1. seguir refinando la cinemática y funcionalidad actual;
2. dotarlo de más sensores, accesorios y conductas “divertidas”;
3. en un nivel más académico -por el lado de Jorge-, investigar un sistema completamente distinto de desplazamiento, basado en modelos biológicos, algoritmos genéticos, etc.  

Pablo Gindel, Marzo de 2011 

Dibujos a mano y revisión de Jorge Visca 

Links

Fotos de SAMSA II. 

Código fuente de SAMSA II. 

Deja tu comentario en el artículo principal. 

Be Sociable, Share!

•