Leon Rivera Juan Sebastian 2013

PONTIFICIA UNIVERSIDAD JAVERIANA
Robot Serpiente Modular Simulado -

Framework Integrado(SMSR-IF) v0,1
Jose Manuel Monsalve Diaz

Juan Sebastian León Rivera
Director de Trabajo de Grado:

Kamilo Melo Ph.D.
Facultad de Ingenierı́a
Departamento de Electrónica
29 de mayo de 2013
Índice general
Índice de Figuras III
Abreviaturas V
1. Introducción 1
2. Marco Teórico 3
2.1. Motor de Fı́sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1.1. Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1.2. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Selección de la Biblioteca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Motor Gráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. DirectX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2.1. Proceso de renderización . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3. OpenSceneGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Estructura Fı́sica y Representación Virtual de Lola-OPTM 11

3.1. Estructura del Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Componentes del Robot Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Modelos del Robot para el Motor de Fı́sica . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. Lola-OPTM No Elastómero . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2. lola-OP con Elastómero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. Armado del Robot Simulado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5. Modelos para la Visualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Representación señales Motores 19

4.1. Control de alto nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.2. Registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.3. Implementación del protocolo de Comunicación . . . . . . . . . . . . . . . . . 21
i
Contents
4.2. Control del motor DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1. Implementación de los motores simulados . . . . . . . . . . . . . . . . . . . . 22
4.3. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Geometrı́a y Caracterı́sticas de Contacto 24

5.1. Mapa de Elevación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. Caracterı́sticas de los Mapas de Elevación . . . . . . . . . . . . . . . . . . . . 24
5.1.2. Implementación en el Simulador . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Contactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. Integración - validación 28
6.1. Descripción general de los bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Flujo del Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. Interfaces Gráficas de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4. Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4.1. Experimentos con el robot real . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4.2. Experimentos con el robot simulado . . . . . . . . . . . . . . . . . . . . . . . 32
6.4.3. Análisis de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7. Conclusiones 39
A. Nota de Publicaciones 41
B. Medidas de las partes constitutivas del Módulo 42
C. Manual de uso del simulador 44

C.1. Inicio y formato de archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.2. Previo a la simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.2.1. Parámetros de la serpiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.2.2. Parámetros del motor de fı́sica . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C.2.3. El heightfield (Opcional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C.3. En simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
C.3.1. Control de visualización y simulación . . . . . . . . . . . . . . . . . . . . . . . 49
C.3.2. Ayudas visuales y más opciones de gráficos . . . . . . . . . . . . . . . . . . . 49
D. Registro de Cambios 53
Bibliografı́a 56
ii
Índice de figuras
2.1. Ejemplo de un grafo de escena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Estructura de un MSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2. MSR Lola-OPTM para simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Ensamblaje real del Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Modelo Sin Elastómero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5. Modelo Con Elastómero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6. Modelos para los Gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.7. Sección de la serpiente del grafo de escena . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Esquema de conexión Daisy-Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2. Curva de control del Momento de Fuerza (Robotis) . . . . . . . . . . . . . . . . . . . 22
4.3. Diagrama de bloques del Modelo del Actuador Propuesto . . . . . . . . . . . . . . . 23
5.1. Patrones para construir la red de poliedros . . . . . . . . . . . . . . . . . . . . . . . 25

5.2. Medidas de configuración para el Mapa de Alturas . . . . . . . . . . . . . . . . . . . 26
5.3. Aproximación de Coulomb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4. Aproximación piramidal del cono de Coulomb . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Diagrama de bloques del simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2. Interfaces Gráficas de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.3. Montaje experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4. Montaje experimental en el simulador . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5. Variación k y µ. Linear Progression . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.6. Trayectoria de Gait afectado por valores de µ grandes . . . . . . . . . . . . . . . . . 35
6.7. Variación k y µ. Lateral Rolling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.8. Variación k y µ. Side Winding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.9. Evidencia del Modelo de Fricción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.1. AX-12 (Robotis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

B.2. FP04-F2 (Robotis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B.3. FP04-F3 (Robotis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.1. Ventana principal del simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

C.2. Ventana principal del simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
iii
Lista de Figuras
C.3. Ventanas de los parámetros de la serpiente . . . . . . . . . . . . . . . . . . . . . . . . 46

C.4. Ventana de los parámetros del motor de fı́scia . . . . . . . . . . . . . . . . . . . . . . 47
C.5. Ventana de configuración de Heighfields . . . . . . . . . . . . . . . . . . . . . . . . . 48
C.6. Barra de progreso de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
C.7. Resultado de la simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
C.8. Controles de visualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
C.9. Ejes de referencia activados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
C.10.FOG Activado (No disponible en todos las tarjetas gráficas) . . . . . . . . . . . . . . 50
C.11.Puntos de contacto Activados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
C.12.Trayectorias Activado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
C.13.Ejes en los módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
C.14.Graficas con y sin CAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
iv
Abreviaturas
MSR Modular Snake Robot

API Application Programming Interface
SDK Software Development Kit
ODE Open Dynamics Engine
OSG Open Scene Graph
GUI Graphical User Interface
v
Capı́tulo 1
Introducción
Un Modular Snake Robot [1] tiene el potencial de moverse en terrenos difı́ciles [2][3]. Sin embargo,
es necesario diseñar varias estrategias de movimiento y la transición entre ellas para darle usos
prácticos [4]. El flujo de diseño para el planeamiento de movimiento exige la verificación constante
de los métodos de locomoción, y las pruebas con el robot acarrean los problemas propios de todo
experimento: son costosas, consumen tiempo y, a pesar de la versatilidad y robustez de la plataforma,
deterioran el robot. Adicionalmente, de acuerdo con el protocolo de mantenimiento establecido, tras
una hora continua de operación es necesario ejecutar ajustes que consumen aún más tiempo. Surge
entonces la necesidad de verificar las estrategias de locomoción de una forma diferente.
Otra manera de conseguir esta verificación es mediante la creación de un modelo que permita la
predicción del comportamiento del robot. Un modelado matemático busca solucionar de manera
analı́tica las ecuaciones que gobiernan un fenómeno, pero dada la complejidad del robot [5][4], una
solución de este tipo es inapropiada [6].
Una alternativa formal es la simulación por computadora, que mediante métodos numéricos [7] re-
suelve las ecuaciones mencionadas y muestra el efecto que tiene la variación de múltiples parámetros
como el momento de fuerza de los motores, la gravedad y el ambiente, en el estado del robot.
Existen paquetes de software especializados en la simulación de robots, [8][9][10][11] entre otros.

Fueron creados con la intención de probar algoritmos de inteligencia artificial y sistemas de control
de movimiento. Para ello cuentan con varias librerı́as de plataformas robóticas y sensores de uso
amplio, y a pesar de que permiten la creación de robots nuevos, la personalización es a alto nivel y
no se ajusta a la necesidad planteada.
Para la descripción de la cinemática y la dinámica de una plataforma robótica, un motor de fı́sica

es una buena herramienta [7]. Permite simular la mecánica de un cuerpo real, detectar y recrear
colisiones, e incluso definir interacciones dinámicas cuando se trabaja con más de un cuerpo.
1
Capı́tulo 1. Introducción
El desarrollo de un modelo simulado del Modular Snake Robot (MSR) lola-OP TM [12][13][14] y de
escenarios virtuales, ası́ como la emulación de las entradas y salidas del robot existente, facilitará la
investigación del grupo, especialmente en la generación de estrategias de movimiento.
El objetivo principal de este trabajo es entonces proveer a la comunidad de robótica de una herra-
mienta computacional, para facilitar el proceso de generación de estrategias de movimiento de un
Modular Snake Robot. Como objetivos especı́ficos se tiene:
1. Representar la estructura mecánica del Modular Snake Robot (MSR) lola-OPTM , mediante el
uso de una herramienta computacional.
2. Representar las señales de los sensores internos de los servomotores del MSR, de acuerdo al
comportamiento dinámico de su representación computacional.
3. Representar la geometrı́a y caracterı́sticas de contacto de superficies que definen un ambiente

de simulación, usando una herramienta computacional.
4. Integrar las representaciones (robot, sensor, ambiente), validando los resultados usando un
robot y ambientes reales.
El libro esta organizado, de acuerdo a los objetivos planteados, de la siguiente forma: En el capı́tulo 2,
Marco Teórico, se presenta la teorı́a de operación y el estado del arte de las partes que constituyen el
simulador, en el capı́tulo 3, Estructura Fı́sica y Representación Virtual, se describe el tipo de robots
objeto del simulador y se presentan los modelos para su emulación, en el capı́tulo 4, Representación
de las señales de los motores, se estudian los actuadores del robot y se presentan los detalles de
la implementación de sus equivalentes virtuales, en el capı́tulo 5, Geometrı́a y Caracterı́sticas de
Contacto, se discute la implementación de estructuras para representar el ambiente y su interacción
con el robot, en el capı́tulo 6, Integración y Validación, se condensa la estructura del programa y su
funcionamiento, y se comparan los resultados del robot simulado y el real, finalmente en el capitulo
7 se presentan las conclusiones.
2
Capı́tulo 2
Marco Teórico
El simulador se construye alrededor de dos bloques: el motor de fı́sica y el motor gráfico, ensamblados
a partir de librerı́as para C++. En este capitulo se discute la función y teorı́a de operación de cada
uno ası́ como la selección de las librerı́as.
2.1. Motor de Fı́sica
Una simulación basada en fı́sica se reduce a resolver ecuaciones diferenciales. Estas ecuaciones
diferenciales pueden representar varios sistemas, como agrupaciones de resortes o una esfera en
caı́da libre. El conjunto de reglas que rigen a esos elementos simulados, ası́ como la capacidad de
traducir el problema a ecuaciones diferenciales y resolverlas conforma un motor de fı́sica.
Para resolver ecuaciones diferenciales mediante un computador se utilizan métodos numéricos, que
trabajan con pasos de tiempo definidos y utilizan métodos como el de Euler o mejoras del mismo,
como el método del punto medio. La relación entre la precisión de la respuesta y el tiempo de
cómputo es importante a la hora de escoger un método de resolución de ecuaciones diferenciales.
Una precisión alta permite la selección de pasos de tiempo grandes, sin embargo, si el tiempo de
cómputo es elevado entonces puede ser preferible elegir un método más rápido con pasos de tiempo
pequeños.
Como se ha mencionado, las ecuaciones diferenciales pueden representar fenómenos de diferente

naturaleza. Es deseable hacer que la porción de código que resuelve las ecuaciones diferenciales sea
independiente del fenómeno simulado y viceversa. Esto con la intención de poder reutilizar el código
o incluso intercambiar el método con que se resuelven las ecuaciones diferenciales [15].
Es posible obtener ese tipo de modularidad dado que para resolver ecuaciones diferenciales de forma
numérica es necesario efectuar un conjunto de operaciones claras sobre el sistema que se quiere
3
Capı́tulo 2. Marco Teórico
resolver [15]. Estas funciones se limitan a: conocer el número de variables del sistema, obtener los
valores presentes de esas variables y calcularlos a medida que se ejecutan los pasos para la solución.
Para llegar a una estructura que represente al sistema y que permita efectuar dichas operaciones,
se debe modelar de alguna forma el fenómeno para reducirlo a variables y ecuaciones diferenciales.
Es precisamente el modelado el que define la clase del motor de fı́sica y puede estar basado en
dinámica de cuerpo rı́gido, de cuerpo flexible, de partı́culas, de fluidos, o una combinación de ellos.
Las matemáticas detrás de cada sistema fı́sico mencionado no solo proporcionan las ecuaciones
diferenciales que rigen al fenómeno sino también un conjunto de restricciones [16].
Por ejemplo, en el caso de la dinámica de cuerpo rı́gido, se definen cuerpos con propiedades como
la posición de su punto de referencia, velocidad del punto de referencia, orientación del cuerpo,
velocidad angular, masa, posición del centro de masa respecto al punto de referencia y tensor
de inercia, entre otros. Adicionalmente los cuerpos pueden estar unidos entre sı́ por junturas con
diferentes grados de libertad y pasivas (si sólo restringen la posición relativa de los cuerpos que
unen) o actuadas (si producen fuerza sobre los cuerpos).
La estructura final, que involucra a las ecuaciones diferenciales, se debe crear dinámicamente a
medida que el usuario del motor de fı́sica crea objetos para ser simulados. Estos objetos pueden ser
las partes que conforman al robot y el escenario en el que se moverá.
A parte de las restricciones y ecuaciones que rigen a la simulación, una caracterı́stica de los motores
de fı́sica es la detección de colisiones. Cuando dos cuerpos colisionan el programa se detiene, evalúa
las velocidades de los cuerpos y las altera de acuerdo a las caracterı́sticas de los mismos y a la
voluntad del usuario. Las velocidades de los cuerpos pueden cambiar de dirección abruptamente,
hacer un cambio paulatino de magnitud o incluso los cuerpos pueden penetrar uno al otro.
Una posibilidad es utilizar un motor gráfico para mostrar al usuario el resultado de la simulación
después de cada paso o de un número determinado de pasos. En este caso, y con la intención de
hacer más rápida la simulación se usan prácticas como definir dominios de colisión diferentes a los
cuerpos reales, de manera que a una persona la puede representar un cilindro y el procesamiento
es menor. De la misma forma es posible manipular el tamaño de los pasos de tiempo, el método
de resolución de las ecuaciones diferenciales, el algoritmo de detección de colisiones (por ejemplo
para ignorar objetos lejanos), los coeficientes de fricción entre cuerpos y las caracterı́sticas de las
colisiones para alcanzar una simulación rápida o, por el contrario, precisa y cercana a la realidad.
2.1.1. Estado del Arte
Actualmente, se han desarrollado varios simuladores de fı́sica con diferentes caracterı́sticas. Algu-
nos muy similares entre sı́ y otros enfocados a mejorar algún aspecto del proceso de simulación.
Encontramos dos grupos diferentes de software. El primero, los frameworks, en el que el programa
tiene su propio ambiente de trabajo, cuenta con un conjunto de espacios definidos, algunos gráficos
4
y otros de texto, con opciones de edición de ambientes y objetos y las funciones y lı́mites están
muy bien definidos por las restricciones del programador y no pueden ser expandidos fácilmente.
El segundo, las Application Programming Interface (API), en las que se encuentran un conjunto
de funciones genéricas y que pueden ser utilizadas a manera de biblioteca en programación, bus-
cando resolver problemas bastante especı́ficos. Normalmente, se encuentran en diferentes lenguajes,
y están pensadas para desarrollar aplicaciones o frameworks más grandes. En simuladores para
robótica encontramos opciones de software en ambas presentaciones, a continuación se describirán
las más significativas.
2.1.1.1. Frameworks
Empezando por los frameworks, CARMEN (Carnegie Mellon Robot Navigation Toolkit) [17] [18],
escrito en C y diseñado para resolver problemas de navegación de robótica en 2D. Es un conjun-
to de programas con una función independiente entre las que se encuentran, comunicación entre
procesos, especificaciones del robot, definición y planeamiento de rutas, localización, simulación,
interfaces gráficas, entre otros. Para que se comuniquen se usa Inter-Process Communication (IPC)
y existe un encargado de organizar esta comunicación. Esto permite que el simulador corra en 1 o
varios computadores a la vez, distribuyendo la carga. Las plataformas que soporta están definidas
en la documentación; algunas de ellas son: IRobot ATRV, ActivMedia Pioneer I y II, Normadic
Technologies Scout y Segway.
Stage y Gazebo [9] [17] [11]son simuladores de multiagentes, permite modelar sus interacciones y las
del ambiente con cada uno de ellos. Cuenta también con diferentes sensores y cámaras que pueden
ser adaptados a las plataformas. Stage [9] trabaja en 2D y se centra en simular muchos agentes con
poca fidelidad, siendo bastante útil para analizar algoritmos de interacción. Gazebo [9], está diseñado
para 3D y, aunque permite simular varios robots, cuenta con un mecanismo para cuerpos rı́gidos,
haciéndolo más preciso y reduciendo la cantidad de agentes posibles. Ambos cuentan con modelos
preestablecidos de sensores y actuadores disponibles en el mercado o en investigaciones.
SimTwo [19] fue realizado por Paulo José Cerqueira de la Universidade do Porto, en Portugal, es el
más reciente y tiene un multiple document interface (MDI), un conjunto de aplicaciones corriendo
sobre un mismo ambiente llamado “world view”. Permite visualizar el robot, configurar las cámaras
del mundo, ver información del robot como posición, velocidad y datos de los sensores. El robot y
escenario están diseñados en archivos con formato XML donde se definen por etiquetas los obstáculos
y objetos, los sensores externos e internos y las partes del robot y sus junturas.
Existen también opciones privativas como V-rep [8] y Microsoft Robotics Developer Studio [20]. El
primero fue desarrollado por Mark Freeze [8], es comercializado por HiBot [21] y cuenta con todas
las herramientas necesarias para simular, probar y evaluar todo un sistema robótico. El segundo,
desarrollado por Microsoft y, aunque su descarga es gratuita, es necesario contar con Microsoft Visual
Studio para utilizarlo. Cuenta con muchas funciones entre las cuales se encuentra el simulador.
5
2.1.1.2. APIs
Por otra parte, tenemos las API’s de fı́sica. Todas son funciones que resuelven numéricamente las
interacciones y no cuentan con gráficos en la mayorı́a de los casos. Bullet [22], Open Dynamics
Engine (ODE) [7] y PhysX [23] son algunos de los más conocidos y utilizados. Fueron pensados
para ser utilizados en videojuegos y pelı́culas, por esto es necesario ser cuidadoso con la metodologı́a
utilizada para obtener los resultados. Aunque resolver la colisión e interacción entre cuerpos rı́gidos
es el objetivo de todos, cada uno define sus funciones y resuelve las ecuaciones diferenciales ordinarias
de manera diferente y es allı́ donde radica la precisión y la velocidad de cada uno.
ODE [7], Bullet [22] y PhysX [23], permiten la creación de cuerpos geométricos rı́gidos, definir sus
uniones y ubicarlos en un ambiente con una gravedad definida y unas caracterı́sticas de colisión y
error. El primero fue creado por Rusell Smith. Utiliza un solucionador de problema complementa-
riamente linear (LCP) llamado projected-Gauss-Seidel (PGS) para poder resolver el estado de los
cuerpos paso a paso en el tiempo. Sus resultados son precisos siempre y cuando se utilice un paso
incremental lo suficientemente pequeño para garantizar la estabilidad de la solución. El segundo,
creado principalmente por Erwin Coumans mientras trabajaba para Sony Computer Entertainment,
utiliza una adaptación de PGS que reduce la precisión de los resultados y aumenta la velocidad de
cómputo. por último, PhysX, creado por Novodex AG en 2004 bajo el nombre de Novodex y luego
adquirido, modificado y renombrado por Nvidia Corporation en 2008; cuenta con licenciamiento
privativo y múltiples solucionadores tanto para cuerpos rı́gidos como para partı́culas.
2.1.2. Selección de la Biblioteca
Para el objetivo de este trabajo de grado, es importante seleccionar adecuadamente el motor de

fı́sica. Primero, es importante destacar que uno de los objetivos del proyecto es ser compatible con un
framework de trabajo para el Robot Modular Serpiente, en el que el simulador debe poder reemplazar
a la serpiente original, tanto en entradas y salidas como en caracterı́sticas fı́sicas. Segundo, se
debe enfatizar en precisión y no en velocidad, la solución debe ser lo más cercana a la realidad.
Tercero, ser compatible con las polı́ticas de licenciamiento libre definidas y Cuarto, debe tener
suficiente documentación para facilitar la tarea de desarrollo. Bajo estos criterios, es fácil descartar
los frameworks, pues su integración a otro framework implicarı́a una posible modificación del código
de fuente de los programas. Otro que no cumple los requerimientos es PhysX que, por ser software
privativo, no permite crear un programa con la filosofı́a de licenciamiento planteada. Por último,
Es destacable la cantidad de documentación existente en Bullet, la constante actualización de su
software y la velocidad de ejecución. Sin embargo, la precisión no cumple nuestras pautas, lo que
podrı́a desencadenar fácilmente en resultados no representativos para el proyecto. Por esto ODE se
posiciona como la mejor, contando con gran cantidad de documentación, no sólo en programación,
sino también en aplicaciones en simuladores de robótica; y permitiendo, por medio de la adaptación
de los parámetros, ser lo suficientemente preciso y coherente con la realidad.
6
Se ha mostrado en diferentes estudios [24] cómo se debe adaptar ODE para que cumpla requeri-
mientos de una buena simulación. Además, se ha comparado su funcionamiento con Carmen y Stage
y Gazebo [25] recalcando su superioridad en resultados, complejidad de instalación y velocidad de
ejecución. Por esto, existen razones de peso para seleccionar a Open Dynamics Engine como un
buen Motor de fı́sica para el proyecto.
2.2. Motor Gráfico
Una vez seleccionado ODE como motor de fı́sica es necesario plantear mecanismos para la visuali-
zación y análisis de los resultados. Un recurso fundamental para este fin es la presentación de una
realidad virtual que imite visualmente lo que se observarı́a en caso de trabajar con el robot real. Este
entorno permite al usuario tener una idea general de los resultados e incluso añadir nuevas funcio-
nalidades difı́ciles de tener en la vida real; sin embargo, algunos datos como velocidades, momentos
de fuerzas y fuerzas, no generan resultados visuales interesantes, pero contienen información funda-
mental para el análisis final. Para estos se debe generar archivos con formato definido que permitan
utilizar los datos en herramientas de generación de gráficas o como fuente para otros procesos.
Para la programación del motor visual se debe seleccionar un API de gráficos en tiempo real en
3D, que nos permita representar la escena a partir de los datos generados por el motor de fı́sica.
Actualmente, los lı́deres en la industria en cuanto a APIs gráficos de bajo nivel son OpenGL y
Direct3D (DirectX). Se clasifican como bajo nivel porque se comunican directamente con la tarjeta
gráfica y genera imágenes a partir de la transformación de vértices y su información, de un marco
de referencia hacia la pantalla. Estas librerı́as no están diseñadas para especificar objetos concretos
como cubos o cilindros, y permiten el control total de el resultado visual final [26]. Por ejemplo,
para dibujar un cubo es necesario decir la posición de cada uno de los vértices, la forma en que se
conectan y especificar que se están dibujando caras sólidas.
Para poder representar la escena, los vértices atraviesan un proceso junto con la información de
ubicación, color y datos adicionales necesarios para interpretarlos. A estos se les realiza transfor-
maciones lineales para pasar de un sistema de referencia tridimensional (R3 ), a una posición en
la pantalla plana (R2 ). Luego, los vértices son pasados por una rasterización que completa la in-
formación de los pı́xeles entre vértices para dibujar una cara o arista de un color, o aplicar una
textura. Para darle realismo a la escena, y si está especificado, se lleva a cabo un sombreado, reflejos
y algunas veces, mezcla de resultados.
A continuación se da una introducción a DirectX y openGL. Se explica más a fondo el proceso de

renderización desde la perspectiva de OpenGL y se presenta una librerı́a alternativa de alto nivel.
7
2.2.1. DirectX
DirectX es una colección de API’s que tiene funciones para el manejo de multimedia para la plata-
forma Microsoft Windows. Entre ellas se encuentra Direct3D dedicada a los gráficos. Direct3D fue
lanzado en las versiones de DirectX2.0 en 1995, adquirido por Microsoft al comprar RenderMorp-
hics. Desde entonces ha estado compitiendo directamente contra OpenGL y hoy en dı́a es utilizado
ampliamente en la creación de juegos, en especial para la plataforma de Microsoft. Su implemen-
tación permite un control directo sobre el manejo de los recursos del hardware para gráficos y su
programación se realiza con los lenguajes compatibles con .NET Framework de microsoft. Debido
a su naturaleza, el licenciamiento de DirectX es privativo, aunque la descarga del SDK es gratuita,
convirtiéndolo en un freeware compatible con Microsoft Visual Studio.
2.2.2. OpenGL
OpenGL es una librerı́a para C++ desarrollada por Sillicon Graphics (SGI) en 1992 y administrado
actualmente por el grupo Khronos y su objetivo fue convertirse en un estándar para los generadores
de hardware y que pudiera ser construido por estos mismos. El licenciamiento de OpenGL es libre
para desarrolladores de software y existen librerı́as con implementaciones del estándar y nuevas
funcionalidades, como GLUT y GLEW, variantes entre un sistema operativo y otro, que facilitan
su uso. Para desarrolladores de hardware existe un licenciamiento diferente. Debido a su licencia y
su uso en múltiples plataformas, principalmente en linux, se convierte en la opción principal para
este proyecto.
2.2.2.1. Proceso de renderización
OpenGL funciona como una máquina de estados que lleva la información desde los vértices a una
renderización. Existen dos actores en este proceso, el cliente, normalmente interpretado por la
CPU; y el servidor, quién usualmente es la unidad de procesamientos gráficos (GPU). El cliente,
programado en c, organiza los vértices y la información necesaria para graficarlos en elementos
llamados primitivas; además, texturas, iluminación, transformaciones y variables que modifiquen
la renderización final. Esta información es enviada al servidor, programado en GLSL (Lengujae
de sompreado de OpenGL) y que cuenta con 2 tareas: la primera, el Vertex Shader, se encarga
de calcular las transformaciones de forma, posición y color de los vértices individuales sin tener en
cuenta las uniones entre ellos. la segunda, el Fragment Shader, lleva a cabo la rasterización, asignando
los valores de color a cada uno de los pı́xeles, de acuerdo a la forma en que se unen los vértices,
las texturas que se requieras, la iluminación, el sombreado y las demás opciones especificadas por
el programador.
8
Programar a este nivel es complejo y requiere mucho tiempo. Los resultados son completamente
flexibles y adaptables a cualquier necesidad y se pueden llegar a optimizar si se tienen los conoci-
mientos adecuados. Sin embargo, se puede facilitar el proceso utilizando librerı́as de más alto nivel
como OpenSceneGraph.
2.2.3. OpenSceneGraph
OpenSceneGraph(OSG) es una API que se ubica como Middleware entre OpenGL y otro software.
Esta librerı́a genera el código del cliente organizando los datos de la escena en grafos que son
almacenados en buffers y procesados para tener el mejor rendimiento en el proceso de renderizado
del servidor o GPU. OSG sacrifica parte de la flexibilidad que OpenGL ofrece, sin generar pérdidas
en el rendimiento. Además OSG puede ser escalado a la necesidad de cualquier software, portado
entre diferentes plataformas y cuenta con licenciamiento de software libre fundamental para este
proyecto.
Los grafos de escena (Scene Graph) son estructuras de datos definidas por nodos, en forma de árbol,
que contienen los vértices, transformaciones y demás información necesaria para la escena gráfica.
Su intención es generar una abstracción de la escena real. Todo elemento de OSG es un nodo que
puede ser añadido al grafo de escena.
En un ejemplo, se tiene una habitación, con una mesa café y encima un libro y unas llaves. Se podrı́a
decir que la raı́z del grafo de escena serı́a la habitación, la cual tiene su propio marco de referencia y
sus valores de iluminación y color descritos en los nodos hijos. Luego se agrega una transformación
de posición y rotación para ubicar la mesa por medio de un nodo hijo, a esta transformación,
que funciona como nuevo marco referencial, se le agrega la mesa en un nodo que describe cómo
está construida la mesa en vértices y como debe ser renderizada. A esta mesa se le pueden definir
también los valores de color especı́fico y comportamientos deseados uniendo a ella màs hijos con
dichas caracterı́sticas. Por último a esta mesa se agregan un par de nodos de transformación de
posición y rotación donde irán, por separado, las llaves y el libro. la descripción de las llaves y el
libro pueden ser importadas de otro archivo. Este ejemplo puede ser observado en la figura 2.1.
Figura 2.1: Ejemplo de un grafo de escena
9
Existen entonces nodos de diferente tipo en el árbol, cada uno con una función propia tales como
transformaciones lineales, estados de OpenGL, definiciones de vértices, cámaras, luces, animaciones o
nodos predefinidos que permiten crear objetos geométricos sencillos como cubos, esferas y cilindros,
sin necesidad de definir todos los vértices manualmente, especificando solamente su posición y
dimensiones. OpenSceneGraph está organizado en clases donde cada una de ellas representa uno de
estos nodos.
Una vez construido el grafo, es graficado y proyectado por un visualizador. En OSG un objeto que
se encarga de interpretarlo, optimizarlo y enviarlo al servidor para esta tarea. Se pueden definir
varios visualizadores en un mismo programa, cada uno con cámaras diferentes o con algunas de las
ramas del grafo de escena omitiendo el resto del grafo.
10
Capı́tulo 3
Estructura Fı́sica y Representación

Virtual de Lola-OPTM
Para completar la simulación del robot con el motor de dinámica de cuerpo rı́gido es necesario definir
a partir de cuerpos y articulaciones la estructura del robot. Para hacer esto se estudian la estructura
y las caracterı́sticas del robot real y se proponen modelos de simulación cuya complejidad permite
balancear el tiempo de computación y la precisión de los resultados. En cuanto a la visualización,
es necesario definir las diferentes representaciones visuales de los modelos y como se integran a la
escena. En la sección 3.1 se muestran las caracterı́sticas de este tipo de robot, en la sección 3.2 se
estudian las caracterı́sticas de los componentes con que se construyó el robot real, en la sección 3.3
se proponen algunos modelos para la simulación, en la sección 3.4 se hace una introducción a la
construcción del robot en el simulador y finalmente en la sección 3.5 se presentan los modelos para
la visualización y su importación.
3.1. Estructura del Robot
Los MSR comparten la misma estructura, independientemente de los actuadores y materiales con que
se construyan. Se trata de una cadena cinemática abierta en donde los eslabones están conectados
entre si por junturas rotacionales. Una juntura rotacional mantiene constante la distancia entre los
eslabones que conecta y hace variar el ángulo que forman dichos eslabones alrededor del eje que
define la juntura.
Con excepción de los eslabones de los extremos, en un MSR las junturas siempre unen dos eslabones
y los eslabones, que son todos iguales, siempre están conectados a dos junturas. Para hacer una
descripción completa de la estructura se utilizará la convención de Denavit-Hartenberg [27][28].
11
Capı́tulo 3. Estructura Fı́sica y Representación Virtual
Figura 3.1: Estructura de un MSR
Se ubican los marcos de referencia sobre los ejes de las junturas, de manera que el eje Z coincida
con el eje de rotación y el eje X se encuentre en la dirección que une una juntura y la siguiente. De
esta manera los parámetros de Denavit-Hartenberg son:
a Este parámetro coincide con la longitud de los eslabones.
d No hay desplazamiento en la dirección del eje de rotación entre un marco de referencia y el

siguiente.
θ Este parámetro coincide con el ángulo de la juntura y el conjunto de todos ellos constituyen la
configuración del robot para cada instante de tiempo.
α En este parámetro radica la diferencia entre un MSR planar y uno que se mueve en todo el espacio.
Para el caso de MSRs planares los ejes de rotación correspondientes a todas las junturas son
paralelos, mientras que en el otro caso hay una rotación de 90◦ respecto a la juntura anterior.
Como convención, al eslabón del extremo se le denomina eslabón 0, al siguiente eslabón se le deno-
mina eslabón 1 y a la juntura rotacional que los une se la denomina juntura 1.
3.2. Componentes del Robot Real
El MSR en particular que se simula en este trabajo (lola-OPTM ) es el de la Fig. 3.2. Existen dos
versiones del robot, la primera es una plataforma básica que se ensambla a partir de tres piezas,
como se ve en la Fig. 3.3, además de los tornillos y tuercas. Todas las piezas hacen parte del kit de
robótica Bioloid, fabricado por la empresa sur coreana Robotis.
12
Figura 3.2: MSR Lola-OPTM para simulación
Los actuadores son servomotores Dynamixel AX-12, mientras que las piezas utilizadas para com-
pletar la estructura son los marcos plásticos FP04-F2 y FP04-F3. Las medidas relevantes de estas
piezas están detalladas en el anexo B.
La segunda versión del robot esta basada en la plataforma básica, a la cual se le agregan unos
cilindros de elastómero. Estos cilindros protegen las partes del robot durante el funcionamiento al
tiempo que aumentan la superficie de contacto y el coeficiente de fricción con el suelo. Hay un
cilindro por cada eslabón, de 35 mm de longitud y 75 mm de diámetro.
Las dos versiones del robot están compuestas por 17 eslabones y 16 junturas rotacionales. Al conjunto
base de construcción, conformado por un actuador y dos marcos plásticos como se ve en el centro
de la Fig. 3.3, se le llama módulo. Siguiendo esta denominación y la convención de la sección 3.1,
el eslabón i y la juntura i hacen parte del módulo i. En el caso del eslabón 0, se utiliza otro marco
plástico en lugar de un actuador.
Figura 3.3: Ensamblaje real del Robot
Como caracterı́stica de diseño, y para proteger la integridad fı́sica del robot, el ángulo máximo que
puede rotar cada actuador desde la posición inicial (cuando los módulos están alineados) y en ambos
sentidos es 60◦ [28].
13
3.3. Modelos del Robot para el Motor de Fı́sica
Para llevar a cabo la simulación es necesario definir los cuerpos rı́gidos, que hacen el papel de
eslabones en el motor de fı́sica. Las caracterı́sticas de estos cuerpos incluyen: la geometrı́a, necesaria
para evaluar las colisiones, y la distribución de la masa, necesaria para evaluar la dinámica de cuerpo
rı́gido y el efecto de la gravedad. En 3.3.1 y 3.3.2 se proponen modelos de simulación para cada una
de las versiones del robot. Se tienen en cuenta la velocidad de simulación ası́ como los primitivos de
colisión implementados en el motor de fı́sica y la estabilidad de la solución matemática al momento
de proponer la representación de los módulos.
3.3.1. Lola-OPTM No Elastómero
Para representar la geometrı́a de cada uno de los módulos se escoge un paralelepı́pedo que encierra
al actuador AX-12. En la Fig. 3.4 se resalta el modelo sobre una imagen del robot real y se muestran
las medidas correspondientes a los lados de la caja, la posición del eje de rotación y la distancia
entre módulos. En este caso el centro geométrico del paralelepı́pedo y el centro de masa del cuerpo
están en el mismo punto.
Figura 3.4: Modelo Sin Elastómero
En cuanto a la distribución de la masa se escoge también un paralelepı́pedo cuya distribución de

masa es homogénea. La masa total del modelo es 0,055 Kg, la misma del actuador AX-12. El tensor
de inercia para el cuerpo propuesto es el de la Ec. 3.1 dado en Kg m2 .
 
1, 8792E − 5 0 0
T = 0 1, 2027E − 5 0 (3.1)
 

0 0 1, 6152E − 5
14
3.3.2. lola-OP con Elastómero
En el segundo modelo propuesto para la simulación se representa la geometrı́a de cada uno de los
módulos como la composición de un paralelepı́pedo y un cilindro. En la Fig. 3.5 se resalta el modelo
sobre la imagen real de un módulo y se muestran las medidas correspondientes a los lados de la
caja, el radio y longitud del cilindro, la posición del eje de rotación y la distancia entre módulos.
En este caso el cilindro coincide con el cilindro de elastómero y la caja con la parte del actuador
que sobresale del mismo. El centro geométrico del cilindro está desplazado 0,0215 m del centro de
masa del cuerpo; el centro geométrico de la caja está desplazado 0,0105 m del centro de masa del
cuerpo.
Como se aprecia en Fig. 3.5 la caja de un módulo y el cilindro del módulo adyacente presentan
puntos de colisión a lo largo del rango de rotación. Esto no sucede en el robot real dado que el
cilindro de elastómero es hueco. Para completar la simulación utilizando las geometrı́as propuestas
es necesario permitir que los módulos adyacentes se penetren entre si, al ignorar las colisiones (en
el motor de fı́sica) entre módulos adyacentes.
Figura 3.5: Modelo Con Elastómero
Para representar la distribución de masa en el segundo modelo se utilizan el mismo paralelepı́pedo

del modelo 1 y un cilindro hueco en la misma posición que el de la geometrı́a propuesta. El radio
exterior del cilindro y su longitud son iguales a las de la geometrı́a; el radio interior es de 0,035
m. La masa de la caja está distribuida de manera uniforme y es de 0,055 Kg. La masa del cilindro
también está distribuida de manera uniforme y es de 0,010 Kg. El tensor de inercia para el cuerpo
resultante es el de la Ec. 3.2 dado en Kg m2 .
 
4, 0849E − 5 0 0
T = 0 3, 0173E − 5 0 (3.2)
 

0 0 2, 186E − 5
15
3.4. Armado del Robot Simulado
El robot en la simulación se construye a partir de los modelos de módulo presentados en la sección

anterior. Se debe ubicar cada modulo en la posición inicial adecuada de acuerdo al número de
modulo y teniendo en cuenta la rotación de 90◦ de los módulos pares alrededor del eje sobre el que
se extiende el robot.
Una vez ubicados los módulos se unen mediante articulaciones rotacionales, estas limitan el movi-
miento relativo entre módulos de la misma forma que las junturas rotacionales pero son pasivas. Las
junturas rotacionales y modelos de motor se discutirán en el capitulo 4. Para definir una articulación
rotacional se debe especificar un punto sobre el eje de rotación y la dirección del eje. De nuevo se
debe tener en cuenta la rotación de 90◦ para satisfacer la estructura mencionada en la sección 3.1.
Para emular al robot real se impone la misma limitación de 60◦ en el rango de rotación de los
módulos. Como medida adicional se agrega un espacio muy pequeño (0,0001 m) entre la caja y el
cilindro, en el modelo 2, para evitar la detección de colisiones entre los componentes del módulo por
parte del motor de fı́sica.
3.5. Modelos para la Visualización
Ası́ como existen dos versiones del MSR, la visualización se divide en una plataforma básica y en
su extensión con cilindros de elastómero. Para cada uno se genera una representación simple y una
compleja. La primera busca representar el modelo utilizado en el motor de fı́sica y la segunda tener
el mayor parecido posible a los servomotores AX12 y las piezas usadas para la construcción de la
serpiente.
Los CAD (Computer Aided-design) son herramientas que permiten el diseño de modelos visuales
complejos tanto en 2D como en 3D. Según la necesidad se debe seleccionar un Software y formato de
archivo CAD especı́fico debido a que cada uno tiene diferentes formas de representar los objetos en
la escena y sus caracterı́sticas; por ejemplo representaciones en figuras geométricas básicas (Cubos,
esferas, cilindros, etc), definición de aristas o enmallado en triángulos o cuadrados de vértices.
Información de ubicación y orientación espacial, dimensiones, texturas, colores y movimiento, entre
otras, también pueden ser encontradas en el CAD y son utilizadas en la renderización.
Para las representaciones simples se crean modelos iguales a los planteados para ODE de para-
lelepı́pedos en la plataforma básica, y cilindros unidos a paralelepı́pedos en la plataforma con
elastómero; creados como nodos del grafo de escena especificando en la creación las dimensiones
configuradas de acuerdo a los valores reales del robot. Estos nodos son del tipo osg::shape y deben
ser agregados a nodos osg::shapeDrawable que a su vez deben ser agregados a osg::Geodes. Estas
estructuras son necesarias para el visualizador a la hora de interpretar los datos, pues contiene la
información adicional indispensable para el proceso de renderizado.
16
Para la representación compleja se utilizan archivos CAD importados y soportados por la librerı́a
OSG. Se importan archivos en formato .3ds que representa el módulo en un enmallado de vértices,
y cuentan con la descripción del material y colores blanco y negro usados por la estructura original.
Las dimensiones se ajustan de acuerdo a las reales y los CAD tanto del motor AX-12 como de
las partes FP04-F2 y FP04-F3 son entregados por la empresa Robotis en archivos individuales y
pueden ser descargados de la página oficial. Los datos del archivo son interpretados por OSG, quien
entrega en nodos la información necesaria para el visualizador. Una transformación de posición y
orientación es agregada para acoplar el sistema de referencia del archivo CAD con el de la escena
gráfica.
En la figura 3.6 se muestran ambas representaciones para cada uno de los eslabones que componen
las diferentes plataformas.
Figura 3.6: Modelos para los Gráficos
Estas representaciones son agregados como nodos hijos a un objeto tipo interruptor llamado osg::Switch.
Este permite asignar valores booleanos a sus hijos, quienes son graficados o no de acuerdo al valor
global que tenga el interruptor. De esta manera, se puede intercambiar de un modelo a otro con
facilidad.
Para cambiar la posición y orientación de los módulos de acuerdo a los valores arrojados por el motor
de fı́sica, y sincronizar los tiempos reales de la simulación con la visualización OpenSceneGraph ofrece
la clase osg::AnimationPath que modifica una matriz de transformación en donde se encuentra el
nodo interruptor.
17
Una ruta de animación almacena los valores de transformación y el instante de tiempo en que
ocurre en estructuras llamadas puntos de control, agregados como nodos. Luego, estos valores son
interpolados linealmente para completar la animación y reproducidos en el instante preciso, por
medio de un nodo de control que contiene a el osg::AnimationPath, conservando el sincronismo.
Todo estos elemetos son creados en cada uno de los módulos. Por lo tanto, es necesario agrupar esta
información en grupos de nodos (osg::group) que permitan ordenar los datos a la hora de agregarlos
a la raiz del arbol que representa el grafo de la escena.
Todo esto puede ser observado en la figura 3.7.
Figura 3.7: Sección de la serpiente del grafo de escena
18
Capı́tulo 4
Representación señales Motores
En este capı́tulo se consideran las caracterı́sticas de los actuadores del robot para construir un
modelo apropiado en el simulador. Cada uno de los servomotores dynamixel AX-12 esta compuesto,
principalmente, por un motor DC, un conjunto de sensores y un microcontrolador que cumple tres
funciones:
1. Se encarga del protocolo de comunicaciones para recibir instrucciones de alto nivel,
2. En concordancia con las instrucciones controla el motor DC y
3. Lee los datos de los sensores para enviarlos al controlador de alto nivel.
En la sección 4.1 se trata el mecanismo de control de alto nivel del servomotor, en la sección 4.2 se
considera el control del motor DC, finalmente en la sección 4.3 se enumeran los datos de sensores
disponibles y se discute su emulación.
4.1. Control de alto nivel
El microcontrolador a bordo de los motores dynamixel AX-12 es un Atmega8 de la familia AVR. Es

un microcontrolador de 8 bits y el programa que ejecuta es diseñado por el fabricante. Se conecta
a la unidad controladora a través de un cable referido a tierra y su interacción ocurre mediante
la escritura y lectura de un conjunto de registros en el microcontrolador. De esta manera, para
cambiar la posición del actuador se escribe en el registro correspondiente a la posición objetivo y
el programa en el microcontrolador se encarga de cumplirla sin más intervención por parte de la
unidad controladora.
En la sección 4.1.1 se especifican el protocolo de comunicaciones entre el actuador y la unidad de

control ası́ como las tramas para realizar la escritura y lectura de los registros, en la sección 4.1.2 se
19
Capı́tulo 4. Representación señales Motores
detallan los registros disponibles en el actuador y en la sección 4.1.3 se presenta la implementación

del sistema de control de alto nivel en el simulador, basado en la información presentada.
4.1.1. Comunicaciones
Los 16 actuadores que componen el robot y la unidad controladora se interconectan bajo un esquema
de conexión daisy chain. El bus de comunicaciones ası́ como la distribución de potencia del robot
esta conformada por tres cables, que se conectan en serie de modulo a modulo como se ve en la Fig.
4.1. El hardware de comunicaciones se compone de la unidad UART del microcontrolador a bordo,
compuertas tri-state como buffer en cada actuador (74HC126) y un circuito integrado FT232RL
que emula un puerto serial en uno de los puertos USB del computador controlador.
Figura 4.1: Esquema de conexión Daisy-Chain
Entre los dos cables de DATA de cada actuador solo está un buffer tri-state, por lo que todos los
actuadores comparten el mismo bus serial. La comunicación es serial ası́ncrona, Half Duplex, con
niveles TTL. La trama de red tiene un bit de parada, se transmite el bit menos significativo primero
y no hay paridad. La velocidad de transmisión se puede variar, siendo 1 MBPS la máxima.
El control de trafico se hace mediante Polling. El paquete de red tiene en la cabecera el ID del
actuador hacia el que el paquete va dirigido, la longitud del paquete y el tipo de instrucción. El ID
de actuador es un numero entre 0 y 253 siendo 254 el ID para difusión. Entre los tipos de instrucción
se encuentran Ping, lectura y escritura de registro. El cuerpo del paquete incluye los datos relevantes
según la instrucción y finalmente se agrega un Checksum.
Durante la operación del robot real se utiliza la velocidad de transmisión de 1 MBPS y solo se
envı́an instrucciones para cambiar la posición de los actuadores y recibir el paquete de estado de
cada uno. Teniendo en cuenta el tamaño de los paquetes de red correspondientes y el número de
actuadores, la frecuencia máxima a la que se puede controlar cada actuador es 11,7 Hz. Se utiliza
una frecuencia de 10 Hz.
4.1.2. Registros
Los dynamixel AX-12 cuentan con un total de 50 registros de 8 bits para el control y comunicación
con la unidad controladora. Para algunas de las instrucciones y datos de los sensores es necesario
utilizar más de 8 bits en la codificación, ası́ que varios registros funcionan como la parte alta ó baja
20
de un registro de 16 bits. Teniendo en cuenta esto hay un total de 32 registros operacionales en cada
actuador.
De esos 32 registros, 14 están en la memoria EEPROM del microcontrolador y 18 están en la

memoria RAM. Es posible dividir los registros en 3 categorı́as de acuerdo a su función: registros de
información, que almacenan datos como la versión del programa que ejecutan o el ID que tienen
asignado, registros de configuración o control, que permiten controlar variables como la posición
objetivo o el rango permitido de movimiento y registros de sensores, que almacenan los datos leı́dos
de los sensores a bordo, como temperatura y voltaje.
La ubicación de los registros en una memoria u otra esta relacionado con su función. Los registros
que corresponden a información están en la memoria no volátil, y en algunos casos se utilizan los
valores almacenados allı́ para inicializar los registros de configuración.
La lista completa de los registros y su descripción se encuentra en el anexo [29]. Los registros
relacionados con control y configuración se presentan con más detalle en la sección 4.2, de manera
similar se tratan los registros relacionados con los sensores en la sección 4.3.
4.1.3. Implementación del protocolo de Comunicación
Durante la operación del robot y para producir el movimiento deseado, se extraen los ángulos
correspondientes a cada actuador (configuración) de un archivo de control. Este archivo de control
se puede generar a partir de 7 parámetros [4] o programar paso por paso mediante las interfaces
creadas para tal fin [14]. Adicionalmente durante la operación se almacena el estado de cada actuador
en otro archivo, diseñado por el grupo, para su inspección luego del experimento. Otros parámetros
de configuración no se alteran durante el movimiento y solo son configurados antes de comenzar los
experimentos. Más información sobre la generación de ángulos para el movimiento del robot y el
marco de software para su uso se puede consultar en [14][30].
En el simulador se emulan los registros de cada actuador como posiciones de memoria. La configu-
ración del robot se toma de los mismos archivos de control generados por las mismas interfaces que
usa el robot real y se lee a las mismas frecuencia de 10 Hz. Durante la simulación se generan gran
cantidad de datos que son almacenados en archivos compatibles con los archivos que genera el uso del
robot real. De manera congruente con el robot real, solo las posiciones de memoria correspondientes
a la posición objetivo pueden ser editados durante el movimiento del robot simulado.
4.2. Control del motor DC
El motor DC en los actuadores dynamixel AX-12 está conectado al eje de rotación a través de
una reducción de engranajes con una relación de transmisión de 254. Como sensor de posición el
actuador esta equipado con un muRata sv01, que es un potenciómetro lineal de 10 kΩ y un rango
21
de 320◦ . Para medir la caı́da de tensión en el potenciómetro el microcontrolador utiliza su conversor

análogo-digital de 10 bits. Ası́ mismo el microcontrolador tiene un PWM de 10 bits, con el que se
controla el puente H, conformado por 4 mosfets 4536, para controlar el motor.
El lazo de control entre el motor DC y el microcontrolador es implementado por Robotis, el fabri-

cante, y sus detalles no son del dominio público. La comunidad, a través de esquemáticos hechos
mediante la observación del circuito impreso y experimentos, ha podido demostrar que los actuadores
AX-12 tienen lazo de realimentación para el control de posición, mientras que la velocidad angular
y el momento de fuerza se controlan en lazo abierto. Para que la posición y velocidad angulares del
actuador sigan curvas suaves, que tiendan a las sinusoides planteadas en los gaits parametrizados y
no dependan de la carga o la gravedad, se envı́an sucesivas instrucciones de posición a alta frecuencia
al actuador [31][30].
Como configuración del usuario se pueden variar los parámetros en la curva de la Fig. 4.2 (en donde
B y C corresponden al margen de error que puede existir en la posición angular antes de que el
actuador corrija la posición, y A y D corresponden a la pendiente que regula el momento de fuerza
cuando se está cerca a la posición objetivo) de manera que el momento de fuerza producido por el
actuador se ajuste de acuerdo a la distancia entre la posición angular actual y la posición angular
objetivo. También existe un parámetro de configuración adicional a los de la Fig. 4.2 para ajustar
la velocidad angular máxima de movimiento del actuador.
Todos los parámetros mencionados en este capı́tulo son configurables por el usuario del robot. Sin
embargo, el fabricante no especifica la codificación utilizada para el valor de la pendiente en la
curva de la figura 4.2, que toma uno de siete valores [29]. Adicionalmente, este valor cambia con la
polarización que utiliza el usuario, que puede variar entre 7 y 15 V [29].
Figura 4.2: Curva de control del Momento de Fuerza (Robotis)
4.2.1. Implementación de los motores simulados
Es posible aplicar fuerzas directamente a los cuerpos en el simulador de Fı́sica para emular el
momento de fuerza que ejercen los actuadores. Sin embargo esta es una practica no recomendada ya
que puede llevar a la simulación a inestabilidades, en especial cuando se simulan sistemas complejos
22
como el robot. Como alternativa, para emular el efecto de motores, la biblioteca de fı́sica ofrece un
modelo de motor angular. Se trata de un actuador con control de velocidad angular (ω) y limitación
de momento de fuerza (T). En cada paso de simulación, se aplica la fuerza adecuada (calculada por
la biblioteca) para alcanzar la velocidad final especificada (ω), siempre y cuando el momento de
fuerza indicado (T) no se exceda.
A cada una de las junturas del robot simulado se le asigna un motor angular, y en cada paso
de la simulación se calcula la diferencia entre la posición angular actual (α) y la posición angular
deseada (β). En base a esta información se establecen la velocidad final y el momento de fuerza de la
siguiente forma: para la velocidad se utiliza la misma magnitud que se especifica para los actuadores
dynamixel AX-12 (Vmax ) y el signo depende de la dirección en que se debe corregir la posición; el
momento de fuerza se evalúa en la función de la Fig. 4.2 proporcionada por el fabricante.
Figura 4.3: Diagrama de bloques del Modelo del Actuador Propuesto
4.3. Sensores
Los actuadores dynamixel AX-12 ofrecen realimentación de posición, velocidad, carga, voltaje y
temperatura. Como se mencionó en la sección 4.2 la posición se obtiene de un potenciómetro y la
resolución de 1024 valores esta dada por el conversor A/D del microcontrolador. La velocidad y la
carga son medidas indirectas y mantienen una relación lineal entre si.
Los valores de posición y velocidad en cada juntura se obtienen directamente durante la operación
del simulador y son almacenados en un archivo para su análisis posterior a una frecuencia de 10 Hz.
En cuanto al valor de carga entregado por los actuadores reales se almacena el momento de fuerza
en su lugar. Los datos de temperatura y voltaje no se obtienen directamente de la simulación y dada
su relevancia no se emularan.
Un beneficio de la simulación es la existencia de datos adicionales para los que no existen sensores
implementados en el robot. La posición y orientación de cada modulo con respecto al marco de
referencia del mundo y los puntos de contacto son registrados en el archivo de datos.
23
Capı́tulo 5
Geometrı́a y Caracterı́sticas de
Contacto
En este capitulo se discute el ambiente de simulación. En la sección 5.1 se introduce a los mapas
de elevación, su uso, formato e implementación en el simulador, para representar la geometrı́a de la
superficie del ambiente simulado. En la sección 5.2 se discuten los modelos fı́sicos que influyen en la
interacción entre el robot y el suelo.
5.1. Mapa de Elevación
En áreas como topologı́a y computación gráfica se utilizan mapas de elevación para representar
terrenos. Un mapa de elevación es un campo escalar de R2 → R, en donde se almacena la altura
correspondiente, en un terreno dado, para cada coordenada en el espacio (plano).
Otros nombres con los que se conoce a los mapas de elevación son Mapa Digital de elevación (DEM
por sus siglas en ingles), HeightMap y HeightField y de la misma forma en que no existe consenso
en cuanto al termino a utilizar tampoco existe un formato que se destaque por sobre los demás.
En las secciones 5.1.1 y 5.1.2 se discute el tema de los formatos, ası́ como otras caracterı́sticas
propias de los mapas de elevación, y su implementación en el simulador.
5.1.1. Caracterı́sticas de los Mapas de Elevación
Una forma de almacenar el mapa de elevación es mediante una imagen en escala de grises en donde
el valor de cada pixel representa la altura almacenada. Si se utiliza un solo canal en una imagen
RGB de 8 bits, se pueden codificar hasta 256 alturas diferentes, mientras que el uso combinado de
24
Capı́tulo 5. Geometrı́a y Caracterı́sticas de Contacto
los 3 canales permite tener 16’777.216 valores diferentes e incluso 4294’967.296 si se utiliza el canal
alpha.
Existen formatos especializados diseñados para programas de animación y juegos. La diferencia

entre estos y las imágenes radica en la presencia de meta-datos. Tener información adicional en
el mapa de alturas permite hacer uso de tasas de muestreo diferentes para cada eje coordenado o
incluso tasas variables de acuerdo a una función. De esta forma, cada valor de altura podrı́a estar
distanciado de los otros 1 m en el eje X y 1,5 m en el eje Z, por ejemplo. De manera similar la
resolución de la altura puede estar ligada a una función.
Como con cualquier fenómeno que es codificado de forma digital, existe perdida de información y es
posible que sea necesario hacer una interpolación para utilizar los datos. En aplicaciones geofı́sicas
es común el uso de algoritmos probabilı́sticos como el Monte Carlo para la reconstrucción, sin em-
bargo, en modelado fı́sico y generación de gráficos por computador, el uso de interpolaciones lineales
conformando una red de poliedros es más extendido ya que los requerimientos computacionales son
inferiores.
Para construir la red de poliedros a partir de los datos almacenados en el mapa de alturas se
construyen polı́gonos usando los puntos almacenados como vértices. La figura más utilizada es el
triangulo, siguiendo patrones como los de la Fig. 5.1.
Figura 5.1: Patrones para construir la red de poliedros
Entre las ventajas que tiene el uso de Mapas de altura esta el tamaño pequeño de los archivos,
comparado con otros métodos y formatos, su implementación sencilla y el uso óptimo de memoria.
Adicionalmente existen funciones para la implementación de mapas de altura tanto en la librerı́a
gráfica como en el motor de fı́sica. Como desventaja, los mapas de altura no hacen ninguna optimi-
zación cuando se codifican grandes regiones con valores constantes y no permiten describir terrenos
en donde mas de un punto tiene la misma proyección sobre el plano, como en la pared escarpada
de una cueva.
5.1.2. Implementación en el Simulador
Para almacenar los terrenos en el simulador se emplea una imagen en escala de grises. Se utiliza el
formato bmp, es decir, un canal RGB de 8 bits para un total de 256 valores posibles. Adicionalmente
25
a la imagen se especifica el tamaño que cubre el mapa de altura (Tamaño X y Tamaño Z), el numero
de muestras que incluye (c y r), el escalamiento vertical que se debe usar y la distancia al suelo que
se debe sumar a todas las muestras (offset). Estas medidas se ven sobre el mapa de alturas de la
Fig. 5.2. Para evaluar la interacción entre el robot y el terreno se crea un plano temporal cuando se
detecta la colisión, siguiendo el primer patrón presentado en la Fig. 5.1.
Figura 5.2: Medidas de configuración para el Mapa de Alturas
5.2. Contactos
Si bien se ha escogido una simulación basada en dinámica de cuerpo rı́gido, donde no se tiene en
cuenta la elasticidad ni la dinámica de los impactos entre cuerpos, para modelar la interacción entre
el robot y el suelo se tienen en cuenta dos fenómenos: el rebote y la fricción.
Para que se considere el rebote, los cuerpos que colisionan se deben estar acercando entre si con
una velocidad relativa superior a la constante de rebote. En caso de ser ası́, se cambia la dirección
de movimiento de los cuerpos que colisionan ajustando la rapidez de acuerdo a una constante de
restitución. Actualmente no existe ninguna aplicación o uso que haga rebotar al robot. Se imple-
menta el modelo de rebote en el simulador en caso de que el usuario quiera utilizarlo y se deja la
calibración de las constantes de rebote y restitución a el mismo.
En cuanto a la fricción se utiliza la aproximación de Coulomb. De acuerdo al modelo de Coulomb,

que fue desarrollado a partir de experimentación, la fuerza de fricción estática es proporcional a
la fuerza entre los cuerpos y no depende del área aparente de contacto. De manera formal, si la
componente tangencial a la superficie de contacto de la fuerza resultante es mayor que la componente
normal a la superficie de contacto multiplicada por una constante µ, los cuerpos se moverán uno
relativo al otro.
26
Figura 5.3: Aproximación de Coulomb
La aproximación de Coulomb se puede ver de manera gráfica en la Fig. 5.3 donde se muestra el
cono de Coulomb. Si la fuerza resultante está por fuera del cono, existirá movimiento relativo. En
el simulador, por motivos de eficiencia, se utiliza la siguiente aproximación: se descompone la fuerza
tangencial en dos componentes paralelas a la superficie de contacto y ortogonales entre si. Si una
de las dos componentes es mayor que la fuerza normal a la superficie de contacto multiplicada por
µ entonces hay movimiento relativo entre los cuerpos. El resultado es el de aproximar el cono de
Coulomb a una pirámide como se muestra en la Fig. 5.4.
Figura 5.4: Aproximación piramidal del cono de Coulomb
No se proveen valores para el coeficiente de fricción µ dado que varı́a para cada entorno de trabajo.
En la sección 6.4 se muestra la influencia de este parámetro sobre los resultados de la simulación.
Es importante recordarle al usuario que la aproximación de coulomb va a influenciar directamente
sobre sus resultados y el valor del coeficiente puede variar en la superficie donde se está moviendo el
robot por factores de desgaste o suciedad, humedad relativa del aire, tiempo que llevan unidas las
superficies de contacto, la deformación de los materiales, entre otros. Esto, sin embargo, no afecta la
función principal del simulador como apoyo al investigador en una etapa especı́fica del desarrollo.
27
Capı́tulo 6
Integración - validación
Dada la magnitud del programa, el simulador ha sido dividido en 6 bloques funcionales buscando
los beneficios del encapsulamiento y permitiendo el trabajo colaborativo. Cada uno de los bloques
tiene definidas sus funciones, entradas y salidas, de manera que el simulador es una unión de los 6
bloques a un nivel donde los detalles de la implementación de cada uno no son relevantes sino la
forma en que se interconectan y como se usan. De esta forma, una vez definidos los bloques y su
conexión es posible intercambiar entre versiones de un mismo bloque a medida que se trabaja en el.
Gracias a la adaptabilidad del diseño del programa fue posible el trabajo colaborativo durante
el desarrollo del código. Cada vez que se hacia un cambio importante en uno o mas bloques se
generó una versión diferente del programa, los detalles de cada versión y los cambios se pueden ver
en el anexo D.
Adicionalmente para facilitar la interacción del usuario final del simulador se han implementado
varias interfaces gráficas en QT.
En la sección 6.1 se hace una descripción general de los 6 bloques funcionales, en la sección 6.2
se presenta el flujo del programa, finalmente en la sección 6.3 se presentan las interfaces gráficas
desarrolladas.
6.1. Descripción general de los bloques
Un diagrama básico de los 6 bloques y su interconexión se muestra en la Fig. 6.1. A continuación

se describe cada uno:
Director Maneja el flujo del programa, organiza a los demás bloques, es la fuente de todas las
acciones en el simulador. Se encarga de manejar el tiempo de simulación.
28
Capı́tulo 6. Integración - Validación
Figura 6.1: Diagrama de bloques del simulador
motorODE Se encarga de todo lo relacionado con la simulación basada en fı́sica. Inicializa el

ambiente y robot virtuales, se encarga de ejecutar cada paso de la simulación y devuelve los
resultados de cada paso, como la posición de cada módulo y su orientación. Ası́ como el bloque
Director dirige a otros bloques, este bloque dirige a los bloques simSerpiente y simEscenario.
simSerpiente Contiene un robot virtual, permite crearlo de acuerdo a los modelos existentes y
sus valores configurables. También permite cambiar la configuración del robot mediante los
actuadores.
simEscenario Contiene el ambiente, ya sea un mapa de alturas o un plano, que se inicializa de

acuerdo a los parámetros de configuración.
simOSG Se encarga de todo lo relacionado con los gráficos. Inicializa los SceneGraphs del ambiente
y robot virtuales y controla las entradas de ratón y teclado dentro de la ventana de simulación.
simDatos Maneja el flujo de archivos hacia y desde el simulador. Lee las lineas en los archivos de
ángulos y escribe el archivo con los resultados de la simulación. También lee los archivos que
contienen el mapa de alturas y la textura que se le puede aplicar.
6.2. Flujo del Programa
Desde el punto de vista de los 6 bloques funcionales y su conexión, el siguiente es el flujo del
programa que administra el bloque director:
Para comenzar el director inicializa los bloques motorODE y motorOSG utilizando los parámetros
globales de ODE y los parámetros de escena de OSG.
En el siguiente paso el director agrega el robot tanto en el motor de fı́sica como en el motor de
gráficos. Lo primero implica crear las geometrı́as de colisión, junturas rotacionales y distribuciones
29
de masa como se discutió en la sección 3.4. Lo segundo implica crear los nodos de visualización, los
transformadores de posición y los controladores de animación como se discutió en la sección 3.5.
Luego de crear el robot, el director agrega el mapa de alturas, también a ambos motores, si es que se
especificó alguno, en caso contrarı́o se crea un plano horizontal como suelo. Para ODE esto implica
cargar la estructura del mapa de alturas como se discutió en la sección 5.1.2, para OSG se agrega
el nodo correspondiente teniendo en cuenta las transformaciones de posición y atitud.
Una vez que están inicializados el ambiente y el robot, el director inicia el reloj de simulación y
se repite el siguiente ciclo hasta completar el tiempo de simulación solicitado por el usuario en el
archivo de ángulos de entrada:
A la frecuencia especificada en el motor de fı́sica se ejecuta un paso de simulación, para lo que

primero se buscan colisiones y se crean puntos de contacto temporales de acuerdo a los criterios
para el rebote y el deslizamiento mencionados en la sección 5.2. Adicionalmente se evalúan las
posiciones de los actuadores para actuar en concordancia con el modelo de motor especificado en
la sección 4.2.1. Una vez considerados los contactos y actuadores se toma el paso de simulación (a
cargo de la librerı́a ODE) y se destruyen los puntos de contacto temporales.
A la frecuencia especificada en la sección 4.1.1 para enviar nuevas posiciones objetivo a los actuadores
se actualizan los registros correspondientes, para lo que se utilizan los bloques simDatos para leer
una nueva linea del archivo de ángulos y simSerpiente que contiene los registros que emulan a los
del actuador AX-12 como se mencionó en la sección 4.1.3.
A la frecuencia especificada para grabar datos en el AnimationPath, que permite la visualización

luego de la simulación, se agregan los valores de posición y rotación de cada modulo y los puntos
de contacto encontrados, para lo que se utilizan las funciones de los bloques simODE y simOSG.
A la frecuencia especificada para almacenar datos en el archivo de registro (Log File) se utiliza
el bloque simDatos para escribir una linea nueva en el archivo correspondiente con los datos de
posición y orientación de cada modulo, y posición angular, velocidad angular y momento de fuerza
en cada juntura rotacional.
6.3. Interfaces Gráficas de Usuario
Para facilitar la interacción del usuario final con el simulador se han implementado varias interfaces
gráficas en QT. Estas permiten seleccionar los archivos de ángulos, mapas de alturas y texturas,
definir los parámetros de configuración de los modelos, motores y superficies, y alternar las funciones
de realidad aumentada. El uso de las interfaces se describe de manera mas detallada en el anexo C.
30
Figura 6.2: Interfaces Gráficas de Usuario
6.4. Validación
En esta sección se validarán los resultados del simulador mediante experimentos con el robot real y
el simulador.
6.4.1. Experimentos con el robot real
En los experimentos se utilizó la versión del robot LoLa-OPTM con elastómero sobre un piso plano
de madera laminada. Se llevaron a cabo experimentos para tres core gaits [28]; Linear Progression,
Lateral Rolling y Side Winding. En los tres casos se comenzó con todos los módulos del robot en la
posición cero grados, se dividió la posición en dos tramos, se ejecutó el gait durante 4 segundos, se
detuvo en la posición alcanzada para realizar medidas y se ejecutó el gait en la dirección contraria
durante otros 4 segundos. Esto con la intención de conocer el resultado en dos escenarios: cuando el
robot inicia con todos los actuadores en 0◦ y cuando el robot parte de una configuración que hace
parte del gait. Se midió el desplazamiento relativo de los módulos 1, 8 y 17 en diez ocasiones luego
de ejecutar el gait en ambas direcciones.
31
Cuadro 6.1: Parametros utilizados para generar los gaits en el experimento
Parametro Linear Progression Lateral Rolling Side-winding

Apar (rad) 0 π/18 2π/9
Opar (rad) π/18 0 0
Aimpar (rad) π/6 π/18 π/18
Oimpar (rad) 0 0 0
ω (rad/s) 2π 2π π
λ (n/rad) π/6 0 π/6
δ (rad) 0 π/2 π/4
Cuadro 6.2: Resultados del experimento (Módulo 1)
Linear Progression Lateral Rolling Side-winding

Medida Mediana Desviación Mediana Desviación Mediana Desviación
X1 (cm) 17.0 0.0 4.0 0.58 25.5 0.0
Z1 (cm) 4.5 0.0 -60.5 1.15 74.0 1.01
X2 (cm) 8.0 0.87 13.0 3.068 -1.75 0.0
Z2 (cm) 14.5 0.58 22.0 2.29 46.0 2.74
Cuadro 6.3: Resultados del experimento (Módulo 8)
Linear Progression Lateral Rolling Side-winding

Medida Mediana Desviación Mediana Desviación Mediana Desviación
X1 (cm) 61.79 0.0 45.42 0.29 64.99 0.87
Z1 (cm) -6.5 0.0 -78.5 0.43 75.0 1.15
X2 (cm) 48.29 0.58 54.42 1.5 29.49 1.04
Z2 (cm) -5.0 0.87 1.0 1.44 17.0 1.0
En las tablas 6.1 se muestran los parámetros utilizados para generar los gaits y en las tablas 6.2 y
6.3 los resultados del experimento. Las imágenes de la Fig. 6.3 corresponden al montaje descrito.
6.4.2. Experimentos con el robot simulado
El montaje experimental se replicó en el simulador utilizando los modelos expuestos a lo largo del
libro para el robot Lola-OPTM con elastómero. Para los parámetros, que por su naturaleza, no se
especificaron a lo largo del trabajo (k y µ) se hizo un barrido en donde se evidencia la influencia de
cada uno en el resultado de manera que el usuario pueda seleccionar valores para su caso puntual.
El robot fue ubicado sobre el eje X, al igual que el robot real.
32
(a) Linear Progression (b) Lateral Rolling (c) Side Winding
Figura 6.3: Montaje experimental
(a) Linear Progression (b) Lateral Rolling (c) Side Winding
Figura 6.4: Montaje experimental en el simulador
En las gráficas 6.5, 6.7 y 6.8 se muestra el resultado de las simulaciones. Los tiempos son consecutivos
entre ellos debido a que ası́ estaban organizados en el archivo resultante de la simulación. Las gráficas
muestran los valores de posición de los módulos 1 y 8 para diferentes valores de µ. En la columna de
la izquierda, los valores de X y en la columna de la derecha los de Z. Las 2 primeras filas son para
k=2, y las 2 últimas para k=3. En lı́neas horizontales se encuentran la mediana de los experimentos
reales, entre 2 lı́neas calculadas con la desviación estándar de los experimentos.
6.4.3. Análisis de los resultados
En un Linear Progression el robot se mueve en la dirección del eje longitudinal de si mismo, propa-
gando una onda vertical que lo impulsa hacia adelante. Una curvatura en el plano perpendicular a
esta onda permite cambiar de dirección. [13][4] La forma de onda puede ser observada tanto en el
simulador como en el robot real en las Fig. 6.3(a) y 6.4(a). Las gráficas de la figura 6.5 muestran el
desplazamiento del robot en el eje X, paralelo al eje longitudinal de la serpiente, con una velocidad
constante. Por otra parte, los cambios sobre el otro eje mostrado en la gráfica son correspondientes
a el aporte de la curvatura para girar descrita anteriormente.
Para el Linear Progression se observa que la rapidez sobre el eje X es de 4.5 cm/s. Este valor no
se ve afectado ni por K ni por µ a excepción de u=0.2 donde hay una pequeña diferencia que es
debida a un deslizamiento. La distancia de el primer tramo y el segundo no son las mismas, debido
a la posición inicial del robot antes de empezar el tramo. El desplazamiento lateral mostrado en las
gráficas de la segunda columna no es tan significativo pero tiene una gran influencia de k y de la
curvatura que tenga el robot.
33
Modulo 1 K=2 Desplazamiento X Modulo 1 K=2 Desplazamiento Z
0.16
0.2 0.14
Desplazamiento (m) 0.12
Desplazamiento (m)
0.15
0.1
0.08
0.1
0.06
0.04
0.05
0.02
0 20 40 60 80 0 20 40 60 80
Tiempo ( 0.1 s ) Tiempo ( 0.1 s )
0.02
0.65
0
Desplazamiento (m)
Desplazamiento (m)
0.6
-0.02
0.55
-0.04
0.5
-0.06
0.45
0 20 40 60 80 0 20 40 60 80
0.25
0.2
0.2
Desplazamiento (m)
Desplazamiento (m)
0.15
0.15
0.1
0.1
0.05
0.05
0 20 40 60 80 0 20 40 60 80
0.65
0.05
Desplazamiento (m)
Desplazamieno (m)
0.6
0.55 0
0.5
-0.05
0.45
0 20 40 60 80 0 20 40 60 80
Figura 6.5: Variación k y µ. Linear Progression
En un Later Rolling el robot se configura tomando la forma de un arco que se conserva durante todo
el movimiento como se muestra en las Fig. 6.3(b) y 6.4(b) mientras gira sobre la superficie [13][4].
La velocidad de desplazamiento es constante y la dirección es perpendicular al eje longitudinal y
depende de la dirección de giro. Este comportamiento es evidenciado en las gráficas de la figura
6.8 donde, luego de salir del estado cero entre los tiempos t=10 s y t=10.5 s, la gráfica crece
en dirección del eje Z positivo, con velocidad constante, y luego regresa hacia el origen con el
34
mismo comportamiento. Los desplazamientos netos de los dos módulos simulados, la velocidad a
la que se ejecutó y su distancia constante en ambos ejes demuestra que la forma del robot se
conservó constante.
Para k=2 y µ mayor a 0.8 se observa una deformación en la curva trazada en el desplazamiento
en Z, eje que se encuentra paralelo al suelo. Lo que ocurre es una deformación del arco que el gait
deberı́a conservar. En la Fig. 6.6 se evidencia como hay una cambio en el gait durante su recorrido.
Sobresalen las posiciones iniciales y finales. Para k=3 y µ=0.2. Ambos módulos tienen un cambio
de pendiente entre ambos trayectos. En el segundo trayecto, esta pendiente corresponde a la misma
de otros valores de µ. Estos dos elementos muestran evidencia de una gran influencia de la fricción
en el gait cuando los valores son o muy grandes o muy pequeños. Además, al avanzar con un arco
en contra de la dirección del movimiento, esta influencia varia.
Figura 6.6: Trayectoria de Gait afectado por valores de µ grandes
Para los demás casos, la velocidad alcanzada por el robot fue aproximadamente de 20 cm/s en
dirección del eje Z. Se aprecia una influencia pequeña de la fricción en este valor, en especial para
k=3. En X el desplazamiento es despreciable.
En un Side Winding el movimiento es más complejo e imita el movimiento de las serpientes reales
en el desierto, donde se propaga una onda horizontal de gran amplitud desde la cola a la cabeza
ubicando algunos módulos sobre el suelo mientras otros avanzan por el aire, gracias a la propagación
de una onda vertical de poca amplitud. En las imágenes de las Fig. 6.3(c) y 6.4(c) se aprecia la onda
de gran amplitud que describe el robot. El movimiento resultante es ortogonal al eje longitudinal
de la serpiente cuando se encontraba estirada [13][4], comportamiento que puede ser observado en
las gráficas que se encuentran en la figura 6.8.
Para este tipo de Gait la velocidad no es constante como se aprecia en los valores de las gráficas
de la figura 6.8. Sobre las curvas de posición del eje Z se aprecia una señal sinusoidal dominante.
Al calcular en la gráfica la frecuencia de esta onda y el desfase entre módulos 1 y 8 se obtiene: 1)
La frecuencia es de πrad/s, correspondiente al valor de ω en los parámetros utilizados para generar
el gait. 2) el desfase entre el módulo 1 y 8 es de 9,11rad según las gráficas, mientras que el desfase
obtenido de la ecuación es de 9,163rad, representando un error de 0,57 %.
35
0.15
0.6
Desplazamiento (m)
Desplazamiento (m)
0.1 0.4
0.2
0.05
0 -0.2
100 120 140 160 180 100 120 140 160 180
0.8
0.56
0.54 0.6
Desplazamiento (m)
Desplazamiento (m)
0.52
0.4
0.5
0.2
0.48
0
0.46
0.44
100 120 140 160 180 100 120 140 160 180
0.16 0.6
0.14
0.4
0.12
Desplazamiento (m)
Desplazamiento (m)
0.1
0.2
0.08
0.06 0
0.04
-0.2
0.02
100 120 140 160 180 100 120 140 160 180
0.8
0.56
0.54 0.6
Desplazamiento (m)
Desplazamieno (m)
0.52
0.4
0.5
0.48 0.2
0.46
0
0.44
100 120 140 160 180 100 120 140 160 180
Figura 6.7: Variación k y µ. Lateral Rolling
En las gráficas de las figuras 6.5, 6.7 y 6.8 se ve como la variación de µ y la pendiente de la curva de
control del momento de fuerza de los actuadores 4.2 (k) influye en el desplazamiento total del robot
pero no en la forma de onda de los desplazamientos de los módulos, exceptuando casos extremos
como los de la Fig. 6.7 que corresponde al Gait Lateral Rolling en donde valores altos de fricción
producen deformaciones en el arco.
36
0
0.25
0.2 -0.2
Desplazamiento (m)
Desplazamiento (m)
0.15
-0.4
0.1
0.05
-0.6
-0.05 -0.8
200 220 240 260 280 200 220 240 260 280
0.65 0
0.6
Desplazamiento (m)
Desplazamiento (m)
0.55 -0.2
0.5
0.45 -0.4
0.4
0.35 -0.6
0.3
0.25 -0.8
200 220 240 260 280 200 220 240 260 280
0
0.25
0.2
-0.2
Desplazamiento (m)
Desplazamiento (m)
0.15
0.1 -0.4
0.05
-0.6
-0.05 -0.8
200 220 240 260 280 200 220 240 260 280
0.65 0
0.6
Desplazamiento (m)
Desplazamieno (m)
0.55 -0.2
0.5
0.45 -0.4
0.4
0.35 -0.6
0.3
0.25 -0.8
200 220 240 260 280 200 220 240 260 280
Figura 6.8: Variación k y µ. Side Winding
Al inicio del movimiento se puede evidenciar el efecto del modelo de fricción. Como se observa en
la Fig. 6.9 el módulo 17 toma caminos diferentes dependiendo del valor de µ. Para valores de µ
mayores a 0.65 las curvas siguen un camino, mientras que para valores menores siguen otro.
Para realizar comparaciones entre los resultados medidos con el robot real y los simulados se selec-
ciona un valor de k y µ donde se evidencie menor diferencia para el linear progression. Luego, con
37
Figura 6.9: Evidencia del Modelo de Fricción
estos mismos valores se calcula el error para todos los gaits. Este error es respecto a la distancia
mı́nima para estar dentro de la desviación estándar. Los resultados se presentan la tabla 6.4.
Cuadro 6.4: Errores en los resultados de la simulación para k=2 y µ=0.6
Modulo 1 Modulo 8
Tramo 1 Tramo 2 Tramo 1 Tramo 2
X Z X Z X Z X Z
LP Simulador 0.223 0.025 0.064 0.118 0.672 -0.015 0.49 -0.005
Error 31.18 % -44.44 % -10.29 % -15.25 % 8.76 % -76.92 % 0.27 % -87.91 %
LR Simulador -0.0049 0.7 0.04 -0.165 0.4512 0.7949 0.4707 0.0013
Error -85.68 % 13.54 % -59.78 % -16.28 % -0.03 % 0.71 % -11.06 % 0.00 %
SW Simulador 0.148 -0.568 0.084 -0.25 0.538 -0.621 0.489 -0.13
Error -41.96 % -22.18 % 380.00 % -42.21 % -16.10 % -15.91 % 60.15 % -18.75 %
Los valores de K y µ que replican los experimentos efectuados con el robot real no son evidentes
a partir de las curvas de X y Z. Medir los resultados del experimento llevado a cabo con un robot
complejo como este, a partir de solo una salida, la posición, da un panorama parcial de lo que ocurre.
Se requiere un trabajo más extenso, que tenga en cuenta más salidas del sistema y defina métricas
que representen mejor el comportamiento del robot.
38
Capı́tulo 7
Conclusiones
En este trabajo se desarrolló un simulador del Modular Snake Robot (MSR) Lola-OPTM que facilita
los procesos de investigación en estrategias de movimiento y control. El simulador forma parte del
Framework de trabajo en desarrollo de la plataforma[32][33].
Para completar el simulador se hizo una descripción general de la cinemática del tipo de robots
objeto del simulador (MSR) siguiendo la convención de Denavit-Hartenberg. También se especificó la
estructura mecánica y los componentes electrónicos del robot Lola-OPTM en particular.
Fue necesario hacer un planeamiento del software que permitiere el trabajo colaborativo, aprovechara
los beneficios del encapsulamiento mientras se producı́a una pieza de software compatible con el
framework y dejara las puertas abiertas a desarrollos futuros, tanto en el simulador como adiciones
al framework. El balance adecuado en la forma en que se dividió el código no solo permite a los
usuarios del simulador entender fácilmente la programación de la herramienta en caso de tener
que editarla, si no que facilitó el trabajo colaborativo entre desarrolladores y la implementación de
versiones básicas de cada bloque, que a su vez ayudaron a entender los resultados a medida que se
desarrollaba el simulador.
Se implementaron modelos para la dinámica de cuerpo rı́gido del robot, para las interacciones del
robot con el ambiente y para los actuadores. Como resultado el simulador arroja gran cantidad de
datos a los que no se tiene acceso en el robot real. Sin embargo queda pendiente un trabajo adicional
en donde se tomen medidas de varias salidas del sistema, de manera que se encuentren patrones
que permitan calibrar el simulador para replicar un entorno de trabajo especı́fico. Esto no afecta
el objetivo principal del simulador, que si bien permite al usuario una calibración precisa como la
descrita para trabajos que lo requieran, también se puede utilizar con los parámetros ofrecidos en
etapas de la investigación que no requieran emular un ambiente real especifico y sean conscientes
de las limitaciones de la simulación.
Se desarrollo un conjunto de herramientas de realidad aumentada que permiten al usuario final tener
una mejor compresión de lo que ocurre con el sistema. Estas incluyen la visualización del marco
39
Capı́tulo 7. Conclusiones
de referencia de cada módulo, la visualización de los puntos de contacto entre el robot y el suelo,
y la visualización de las trayectorias de cada modulo a través del tiempo. Adicionalmente el simu-
lador incluye controles de reproducción que permiten manipular la presentación de los resultados
a voluntad del usuario final, quien puede cambiar la velocidad de reproducción, el ángulo desde el
que observa el robot e incluso hacerlo hacia atrás. El potencial del simulador para desarrollar la
intuición y comprensión del fenómeno en el usuario final se evidenciará en trabajos futuros que se
beneficien del mismo.
Para su adición al framework de trabajo se hicieron actualizaciones a la definición de los archivos

de control y archivos de resultados, manteniendo la compatibilidad con herramientas existentes
mientras se agregan posibilidades como el uso de radianes o grados, y el almacenamiento de mas
variables, como la posición y orientación de cada modulo, y los puntos de contacto del robot con
el ambiente, adicionales a la posición angular, velocidad angular y momento de fuerza de cada
actuador.
El simulador es una herramienta que facilita el trabajo con MSR y abre el camino para varios
trabajos futuros, como la creación de herramientas de control de alto nivel en lazo cerrado, la
optimización de los parámetros de generación de gaits y apoya investigaciones en curso como la
determinación de métricas para la estabilidad del robot y la creación de configuraciones nuevas.
La modularidad del simulador permite la implementación de otros MSR al permitir cambiar los mo-
delos de cada módulo e implementar funciones que emulen actuadores diferentes. Las descripciones
aquı́ expuestas marcan un camino para quien complete dicha tarea en el futuro.
Se crearon piezas adicionales de software (plugins) para completar tareas repetitivas producto del
trabajo con el robot. Entre los plugins desarrollados están el angleFile generator, que permite generar
el archivo de control que utilizan las interfaces existentes además del simulador y un generador de
mapas de altura, pipeFile generator, que produce las imágenes en escala de grises correspondientes a
tubos del diámetro especificado por el usuario. Estas pequeñas herramientas de software se pueden
crear con facilidad en el futuro para resolver problemas puntuales y aumentar las funciones del
simulador.
40
Apéndice A
Nota de Publicaciones
A continuación se presenta la lista de publicaciones a los que este proyecto, a la fecha, ha contribuido:
K. Melo, J. Leon, J. Monsalve, V. Fernandez, and D. Gonzalez. Simulation and control

integrated framework for modular snake robots locomotion research. In System Integration
(SII), 2012 IEEE/SICE International Symposium on, pages 523–528, 2012. doi: 10.1109/SII.
2012.6427341
J. Leon, L. Paez, and K. Melo. Modular Snake ROS. In ROS Developer Conference (ROS-
Con2013), 2013
J. Leon, J. Monsalve, A. DiZeo, L. Paez, and K. Melo. Open Modular Snake Robot Software
Architecture. In VIII Workshop on Software Development and Integration in Robotics (SDIR
VIII), IEEE International Conference on Robotics and Automation (ICRA), 2013, pages 84–
86, may 2013
K. Melo, J. Leon, J. Monsalve, A. DiZeo, and L. Paez. Modular Snake Robots. Research on
Locomotion and Low Cost Open Hard/Software Platforms Development and Integration. In
Robotics for Risky Environments - Extreme Robotics (RISE-ER), 2013, International Works-
hop on, 2013. Acepted
41
Apéndice B
Medidas de las partes constitutivas

del Módulo
A4
Figura B.1: AX-12 (Robotis)
42
Apéndice B. Medidas de las partes constitutivas del Módulo
A4
Figura B.2: FP04-F2 (Robotis)
A4
Figura B.3: FP04-F3 (Robotis)
43
Apéndice C
Manual de uso del simulador
En este apéndice se describe el uso del simulador y se le da un recorrido al usuario a través de sus
diferentes opciones.
C.1. Inicio y formato de archivo
Al ejecutar el simulador se abre una ventana principal como se aprecia en la Figura C.1. Mediante
esta ventana el usuario controla todas las opciones posibles. La mayorı́a de los botones se encuentran
deshabilitados debido a que no se encuentra aún ningún archivo en simulación.
En la parte superior de la ventana se encuentra la barra de menú. En ella el usuario encuentra 3

opciones. La primera es Archivo donde se puede generar una nueva simulación y salir del programa.
En la segunda opción, Edición, se acceden a todas las opciones de configuración, también accesibles
desde los botones de la izquierda. Además se encuentra la opción para habilitar la generación del
logfile. En la tercera opción, Ayuda, el usuario encuentra esta información y una ventana acerca de
los autores y el software.
Continuando la descripción de la ventana principal, a la izquierda se encuentran los botones de con-

figuración, en el medio, la ruta del archivo en simulación, y a la derecha, los controles de simulación.
Figura C.1: Ventana principal del simulador
44
Apéndice C. Manual de Uso
Lo primero que el usuario debe hacer es cargar un archivo de simulación presionando en o en la

opción Nueva Simulación del menú Archivo. La extensión del archivo no es de importancia siempre
que su contenido sea de texto. El formato de este está establecido como se expresa a continuación:
En la primera lı́nea 3 columnas, separadas por tabulador. En la primera columna un número

entero con el número de actuadores que tiene la serpiente; en la segunda columna el periodo
en segundos de lectura de una lı́nea de archivo. Esto es, cada cuanto se le transmite una
configuración a los actuadores del robot; y en la tercera columna las unidades utilizadas en
los ángulos del archivo. Codificada con la letra ”g”para grados y r”para radianes.
las siguientes lı́neas contienen las configuración del robot, donde cada lı́nea cuenta con igual
columnas como número de actuadores y es leı́da pasado el periodo establecido en el encabezado.
Se aclara que en caso de tener más columnas que actuadores, el software asignará sólo las
primeras columnas hasta completar el número de actuadores; en caso de tener menos, los
demás motores conservarán la posición inicial de ángulo cero.
El final del archivo es una lı́nea en blanco y hay lectura hasta el EOF.
Un contenido de ejemplo para un archivo que represente una serpiente de 3 módulos, con un muestreo
por lı́nea de 1 segundo, los valores en grados y un tiempo de simulación de 3 segundos. se observa
a continuación:
3 1 g
90 0 60
90 90 90
19 40 40
Se puede modificar el archivo y continuar con la simulación desde el punto en que se iba. Sin embargo
no es posible borrar lı́neas o devolver la simulación a un punto anterior.
En caso de no cumplir estas caracterı́sticas el archivo es descartado o podrı́a producir resultados

inesperados en la ejecución del programa.
C.2. Previo a la simulación
Una vez el usuario haya agregado el archivo, la ruta es mostrada en la barra de texto del medio de
la ventana y nuevos botones son habilitados como se muestra en la figura C.2. En este punto se da
la opción de modificar los parámetros de simulación explicados a continuación.
45
Figura C.2: Ventana principal del simulador
C.2.1. Parámetros de la serpiente
Al presionar se abre una ventana que nos permite cambiar los parámetros de la serpiente como
se muestra en la figura C.3.
Figura C.3: Ventanas de los parámetros de la serpiente
La ventana cuenta con un selector de versión de la serpiente. El primero para el módulo sin elastóme-
ro, el segundo para el módulo con elastómero. Cada uno de los modelos tiene sus valores y son
explicados en una imágen que muestra a qué se refiere el valor.
Además una segunda pestaña permite establecer los valores que caracterizan al motor y la posición
inicial del primer módulo. Luego el robot se irá extendiendo hacia el eje X.
46
C.2.2. Parámetros del motor de fı́sica
El segundo botón de la derecha de la ventana principal es la configuración del motor de fı́sica

(ODE). Al presionarlo se muestra la ventana de la figura C.4
Figura C.4: Ventana de los parámetros del motor de fı́scia
A la izquierda, la ventana de configuración de los parámetros Globales que utiliza ODE, con una
reducida explicación de su significado; a la derecha, la ventana de configuración de los parámetros
de la superficie de contacto, sea suelo o heightfield.
C.2.3. El heightfield (Opcional)
Antes de describir esta opción se debe mencionar que en caso de no especificar un heightfield, se
establece un plano constante en el plano XZ y visualmente unas paredes en los planos X=20, X=-20,
Z=20 y Z=-20 que no generan colisiones en el motor fı́sico.
La cuarta opción de configuración es el mapa de alturas . Una imágen en escala de grises en

extensión bmp (Extensión para más extensiones es necesario tener las librerı́as pertinentes antes de
compilar OSG) de 8 bits. Luego de cargar la imágen con el botón Heightfield, y la textura (Opcional)
con el botón de Textura, se configuran los siguientes parámetros:
47
Figura C.5: Ventana de configuración de Heighfields
La posición está dada en el marco de referencia del simulador, con unidades de metros y
respecto a la esquina superior izquierda de la imagen utilizada.
El tamaño es cuanto en x y cuanto en z se extiende en el marco de referencia del simulador,

las unidades que se manejan son metros. Entre más resolución tenga la imagen más fiel es la
reproducción del terreno y menos sensible es al aumento de tamaño.
La escala habla de cuanto será el valor máximo de altura, teniendo en cuenta que es repre-
sentado por el color blanco (255 en 8 bits), a partir de este valor se pueden calcular cuánta es
la altura para las otras tonalidades de gris. Se debe tener en cuenta que entre mayor sea este
valor, más agresivos son los cambios de altura entre dos valores consecutivos de gris.
C.3. En simulación
Para arrancar la simulación se debe presionar el botón simular ubicado a la derecha de la ventana
principal.
Inmediatamente se abrirá una ventana con una barra de carga como se observa en la figura C.6.
Durante este tiempo se puede cancelar la simulación, sin embargo, los datos que se hayan analizado
del archivo y el resultado de simulación alcanzados se conservarán.
48
Figura C.6: Barra de progreso de carga
Figura C.7: Resultado de la simulación
C.3.1. Control de visualización y simulación
Una vez finalice la simulación, los resultados se empezarán a visualizar. En este punto se puede
hacer uso de los botones de control de la visualización. mostrados en la figura C.8.
Figura C.8: Controles de visualización
Los controles de simulación son similares a los de un reproductor de vı́deo. A la derecha, el número
precedido a la X es la velocidad de reproducción. Los botones de existe la posibilidad de acelerar
la reproducción con y o hacerla más lenta y pausada dejando presionado los botones de
y . La velocidad de reproducción normal se obtiene con el botón y en cualquier momento se
pueden hacer pausas con . Por último el botón refrescar retoma el archivo de ángulos desde la
última posición leı́da y continua con el proceso de simulación, lanzando nuevamente una barra de
carga.
C.3.2. Ayudas visuales y más opciones de gráficos
El tercer botón de la izquierda, deshabilitado en los momentos previos a la simulación, despliega

un menú que permite realizar modificaciones a los gráficos y generar algunas ayudas visuales. A
49
continuación se muestran los diferentes efectos de este menú.
Las opciones globales son:
Figura C.9: Ejes de referencia activados
Figura C.10: FOG Activado (No disponible en todos las tarjetas gráficas)
Las opciones por módulo, seleccionable por medio de un menú son:
50
Figura C.11: Puntos de contacto Activados
Figura C.12: Trayectorias Activado
Figura C.13: Ejes en los módulos
51
Figura C.14: Graficas con y sin CAD
52
Apéndice D
Registro de Cambios
Versión 0.001
Se creó el primer diagrama de clases y el primer acercamiento al código. se partió del reto
juanse y se dividió el código en carpetas ordenado.
Versión 0.002
Se mejoró el GL, se agregó cámara en perspectiva, se experimentó con colores, planos y los
diferentes valores del experimento
Versión 0.003
Se mejoró el GL, se agregó movimiento a la cámara con las flechas, las teclas W,A,S,D y
SHIFT + W,S. Se cambiaron los colores, se mejoró problemas de orientación de los objetos
entendiendo mejor la ubicación cartesiana de OpenGL.
Versión 0.010
Apareció la necesidad de 2 geoms para los módulos. Restauramos dimx , dimy , dimz para poder
hacer la escalización, y los offsets en GL. Termina con muchos errores de visualización. hay
un bug con el manejo del quaternion
Versión 0.011
Se arreglaron los problemas de visualización. La gravedad se puso en el eje Y hacia abajo, se
reorganizaron las posiciones de los objetos para dimensiones más pequeñas queda pendiente
velocidad de la cámara y posición inicial coherentes. Aún se tienen cubos para los módulos.
Versión 0.020
Reestructuración de el modelo de clases que se utilizó en todo el simulador. Desaparece la
clase Módulo y aparece la clase serpiente. Se le deja en control de tiempos a Simulador en vez
de a SimGL simODE recibe nuevas tareas al ser quién tenga una serpiente. Se plantea la clase
datos pero no se implementa. La nueva clase serpiente se encarga de los módulos, las junturas,
los motores y las junturas de datos.
53
Apéndice D. Registro de Cambios
Versión 0.021
Intento por utilizar CAD’s en el simulador.
Versión 0.022
Creación del primer modelo para ajustar el ángulo de los motores. Se agrega una variable
configuración a serpiente donde se almacenan los ángulos destino. Se arregló un problema con
el sistema coordenado de los ángulos de los motores.
versión 0.023
Creación de la clase datos.
Versión 0.024
Unión de las Versiónes 0.022 y 0.023. Se cambia la implementación de la rotación, ya no es
con quaterniones sino con matriz de transformación, se arma manualmente. Esto debido a un
error de pruebas en otros computadores.
Versión 0.025
Se quiere agregar luz y sombras
Versión 0.025a
Recuperación del movimiento de la serpiente luego de una desconfiguración de los valores de
ODE
Versión 0.026
Segundo intento por utilizar CADS. Con la versión 0.025 como base
Versión 0.030
Se hace necesario hacer primero el procesamiento de ode antes de mostrar. Implementación de
nuevas funciones en clase dato para crear un archivo binario con la información del movimiento
de la serpiente. Sincronización de los datos de entrada con el simulador y los datos de salida.
Versiion 0.031
Se hace para la presentación del simulador en SII2012 Fukuoka, japón.
Versión 0.032
versión para pruebas generales sin funcionalidad objetivas. Cambio de CADS, movimiento de
parámetros, implementación de vertex buffer.
Versión 0.033
Implementaciòn de la estructura de feedback en los joints: como el eedback utiliza el tipo de
dato djointFeedBack, cambié la definición del vector en la clase simserpiente, y en el getter
corresopndiendte.
Versión 0.040
Cambio en la clase SimGL. Se desea cambiar OpenGL por Open Scene Graph (OSG) debido
a la facilidad de uso y lo complejo que se hacı̀a utilizar OpenGL con GLSL y con Buffers.
54
Apéndice D. Registro de Cambios
Versión 0.041
Una vez realizada la implementaciòn en OSG, intentaremos utilizar texturas y agregar com-
ponentes que le den realidad a la simulaciòn. Jugando con Heightfields
Versión 0.042
Creación de la nueva clase simEscenario, donde se agregará el escenario de heighfield. Se crea
un plano como scenario por defecto. Se agrega a datos la posibilidad de leer heighfields en
formato BMP utilizando OSGDB.
Versión 0.044
implementadas las estructuras para (desde 0.033): feedback de junturas puntos de contacto
implementadas las clases para cargar el heightfield: motorODE-¿crearHeightfield simEscena-
rio() se crearon las constantes para completar los parametros correspondientes
por discutir: el data del heightfield de double a algo mas elegante? hacer un struct para los
parametros de las funciones que crean los heightfields? las clases para montar el heightfield en
OSG?
Versión 0.050
Adaptaciòn de todo el còdigo a qt. Cambio de IDE a QtCreator.
Versión 0.051
Más pruebas en Qt. Versión con errores
Versión 0.060
Creación de la primera versión en Qt. NO FUNCIONAL!
Versión 0.061
Reimplementaciòn de Qt, problemas de funcionalidad resueltos!
Versión 0.062
Se cambió la interfaz de usuario a todo el qt botones de play pause y demàs estàn pero no
funcionan, se agregò la parte gràfica a la ventana principal como un QWidget generado por
OsgQT
Versión 0.063
Correcciones mayores sobre la versiòn de qt, implementaciòn de la mayorı̀a de las funcionali-
dades
Versión 0.064
Correcciones menores
55
Bibliografı́a
[1] K. Melo, L. Paez, and C. Parra. Indoor and outdoor parametrized gait execution with modular
snake robots. In Robotics and Automation (ICRA), 2012 IEEE International Conference on,
pages 3525–3526, may 2012. doi: 10.1109/ICRA.2012.6224768.
[2] K. Lipkin, I. Brown, A. Peck, H. Choset, J. Rembisz, P. Gianfortoni, and A. Naaktgeboren.

Differentiable and piecewise differentiable gaits for snake robots. In Intelligent Robots and
Systems, 2007. IROS 2007. IEEE/RSJ International Conference on, pages 1864–1869, 29 2007-
nov. 2 2007. doi: 10.1109/IROS.2007.4399638.
[3] K. Melo, L. Paez, M. Hernandez, A. Velasco, F. Calderon, and C. Parra. Preliminary studies on
modular snake robots applied on de-mining tasks. In Robotics Symposium, 2011 IEEE IX Latin
American and IEEE Colombian Conference on Automatic Control and Industry Applications
(LARC), pages 1–6, oct. 2011. doi: 10.1109/LARC.2011.6086814.
[4] Matthew Tesch, Kevin Lipkin, Isaac Brown, Ross L. Hatton, Aaron Peck, Justine Rembisz,
and Howie Choset. Parameterized and Scripted Gaits for Modular Snake Robots. Advanced
Robotics, 23(9):1131–1158, 2009.
[5] Matthew Tesch, Jeff Schneider, and Howie Choset. Adapting control policies for expensive
systems to changing environments. In Intelligent Robots and Systems (IROS), 2011 IEEE/RSJ
International Conference on, pages 357–364, sept. 2011. doi: 10.1109/IROS.2011.6095039.
[6] A. Trujillo, J. Igua, K. Melo, and C. Parra. Dinámica Pasiva para una Cadena Articulada Co-
planar de 6 DOF. In Proc. IEEE IX Latin American Robotics Symposium and IEEE Colombian
Conference on Automatic Control, October 2011.
[7] Russel L. Smith. Open Dynamics Engine, September 2012. URL http://www.ode.org.
[8] Marc Andreas Freese. V-Rep (Virtual Robot Experimentation Platform), September 2012.
URL http://www.coppeliarobotics.com.
[9] Free Software for robots and sensor applications, March 2012. URL http://playerstage.
sourceforge.net.
[10] Olivier Michel. Webots 6, September 2012. URL http://www.cyberbotics.com.
56
Bibliography
[11] Open Source Robotics Foundation, May 2013. URL http://www.osrfoundation.org/.
[12] Kamilo Melo, Laura Paez, Andrea Polo, and Carlos Parra. Gait Programming and Data
Acquisition User Interfaces, for Modular Snake Robots. In Dehuai Yang, editor, Informatics
in Control, Automation and Robotics, volume 133 of Lecture Notes in Electrical Engineering,
pages 113–117. Springer Berlin Heidelberg, 2012. ISBN 978-3-642-25992-0. 10.1007/978-3-642-
25992-0 15.
[13] K. Melo and L. Paez. Modular snake robot gaits on horizontal pipes. In Intelligent Robots and
Systems (IROS), 2012 IEEE/RSJ International Conference on, pages 3099–3104, 2012. doi:
10.1109/IROS.2012.6385980.
[14] K. Melo, J. Leon, J. Monsalve, V. Fernandez, and D. Gonzalez. Simulation and control integra-
ted framework for modular snake robots locomotion research. In System Integration (SII), 2012
IEEE/SICE International Symposium on, pages 523–528, 2012. doi: 10.1109/SII.2012.6427341.
[15] A. Witkin and D. Baraff. Physically Based Modeling: Principles and Practice. Technical report,
Carnegie Mellon University. Robotics Institute, 1997.
[16] M. Tim Jones. Open Source Robotics Toolkits, 2006.
[17] James Kramer and Matthias Scheutz. Development environments for autonomous mobi-
le robots: A survey. Auton. Robots, 22(2):101–132, February 2007. ISSN 0929-5593. doi:
10.1007/s10514-006-9013-8. URL http://dx.doi.org/10.1007/s10514-006-9013-8.
[18] Carnegie Mellon University. Robotics Institute. CARMEN, Robot navigation Toolkit, June
2012. URL http://carmen.surceforge.net.
[19] Costa Paulo, Gonçalves José, Lima José, and Malheiros Paulo. Simtwo realistic simulator:
A tool for the development and validation of robot software. Theory and Applications of
Mathematics & Computer Science, 1(1), 2011. ISSN 2247 – 6202. URL http://www.uav.ro/
stiinte_exacte/journal/index.php/TAMCS/article/view/3.
[20] Microsoft Robotics, June 2012. URL http://www.microsoft.com/robotics/.
[21] HiBot, June 2012. URL http://www.hibot.co.jp/top.php?lang=en.
[22] Erwin Coumans. Bullet Continuous Collision Detection and Physics Library, September 2012.
URL http://www.bulletphysics.org.
[23] Nvidia. Physx, Scalable Multi-Platform Game Physics Solution, September 2012. URL http:
//developer.nvidia.com/physx.
[24] Evan Drumwright, John Hsu, Nathan Koenig, and Dylan Shell. Extending open dyna-
mics engine for robotics simulation. In Proceedings of the Second international conference
on Simulation, modeling, and programming for autonomous robots, SIMPAR’10, pages 38–
50, Berlin, Heidelberg, 2010. Springer-Verlag. ISBN 3-642-17318-7, 978-3-642-17318-9. URL
http://dl.acm.org/citation.cfm?id=1947545.1947554.
57
Bibliography
[25] P. Castillo-Pizarro, T.V. Arredondo, and M. Torres-Torriti. Introductory survey to open-source

mobile robot simulation software. In Robotics Symposium and Intelligent Robotic Meeting
(LARS), 2010 Latin American, pages 150–155, 2010. doi: 10.1109/LARS.2010.19.
[26] Richard S. Wright, Nicholas Haemel, Graham Sellers, and Benjamin Lipchak. OpenGL Su-
perBible: Comprehensive Tutorial and Reference (5th Edition). Addison-Wesley Professional,
5 edition, August 2010. ISBN 0321712617. URL http://www.amazon.com/exec/obidos/
redirect?tag=citeulike07-20&path=ASIN/0321712617.
[27] J. Denavit and R. S. Hartenberg. A kinematic notation for lower-pair mechanisms based
on matrices. Trans. of the ASME. Journal of Applied Mechanics, 22:215–221, 1955. URL
http://ci.nii.ac.jp/naid/10008019314/en/.
[28] Kamilo. Melo and Monica Hernandez. Parameterized Space Conditions for the Definition of
Locomotion Modes in Modular Snake Robots. In Robotics and Biomimetics (ROBIO), 2012
IEEE International Conference on, dec. 2012. Submited.
[29] Robotis. AX-12/ AX-12+/ AX-12A, September 2012. URL http://support.robotis.com/

en/product/dynamixel/ax_series/dxl_ax_actuator.htm.
[30] Kamilo Melo and Laura Paez. Modular Snake Robots on Horizontal Pipes. In Intelligent Robots
and Systems (IROS), 2012 IEEE/RSJ International Conference on, October 2012. to appear.
[31] Ethan Tira-Thompson. Digital servo calibration and modeling. Technical Report CMU-RI-
TR-09-41, Robotics Institute, Pittsburgh, PA, March 2009.
[32] K. Melo, J. Leon, J. Monsalve, V. Fernandez, and D. Gonzalez. Simulation and control integra-
ted framework for modular snake robots locomotion research. In System Integration (SII), 2012
IEEE/SICE International Symposium on, pages 523–528, 2012. doi: 10.1109/SII.2012.6427341.
[33] J. Leon, J. Monsalve, A. DiZeo, L. Paez, and K. Melo. Open Modular Snake Robot Software
Architecture. In VIII Workshop on Software Development and Integration in Robotics (SDIR
VIII), IEEE International Conference on Robotics and Automation (ICRA), 2013, pages 84–86,
may 2013.
[34] J. Leon, L. Paez, and K. Melo. Modular Snake ROS. In ROS Developer Conference (ROS-
Con2013), 2013.
[35] K. Melo, J. Leon, J. Monsalve, A. DiZeo, and L. Paez. Modular Snake Robots. Research on
Locomotion and Low Cost Open Hard/Software Platforms Development and Integration. In
Robotics for Risky Environments - Extreme Robotics (RISE-ER), 2013, International Workshop
on, 2013. Acepted.
58

Leon Rivera Juan Sebastian 2013

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Leon Rivera Juan Sebastian 2013

Cargado por

Copyright:

Formatos disponibles

PONTIFICIA UNIVERSIDAD JAVERIANA

Robot Serpiente Modular Simulado -

Jose Manuel Monsalve Diaz

Director de Trabajo de Grado:

Índice de Figuras III

3. Estructura Fı́sica y Representación Virtual de Lola-OPTM 11

4. Representación señales Motores 19

4.2. Control del motor DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5. Geometrı́a y Caracterı́sticas de Contacto 24

B. Medidas de las partes constitutivas del Módulo 42

C. Manual de uso del simulador 44

2.1. Ejemplo de un grafo de escena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1. Estructura de un MSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1. Esquema de conexión Daisy-Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1. Patrones para construir la red de poliedros . . . . . . . . . . . . . . . . . . . . . . . 25

6.1. Diagrama de bloques del simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

B.1. AX-12 (Robotis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

C.1. Ventana principal del simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

C.3. Ventanas de los parámetros de la serpiente . . . . . . . . . . . . . . . . . . . . . . . . 46

MSR Modular Snake Robot

Existen paquetes de software especializados en la simulación de robots, [8][9][10][11] entre otros.

Para la descripción de la cinemática y la dinámica de una plataforma robótica, un motor de fı́sica

3. Representar la geometrı́a y caracterı́sticas de contacto de superficies que definen un ambiente

2.1. Motor de Fı́sica

Como se ha mencionado, las ecuaciones diferenciales pueden representar fenómenos de diferente

2.1.1. Estado del Arte

2.1.2. Selección de la Biblioteca

Para el objetivo de este trabajo de grado, es importante seleccionar adecuadamente el motor de

2.2. Motor Gráfico

A continuación se da una introducción a DirectX y openGL. Se explica más a fondo el proceso de

2.2.2.1. Proceso de renderización

Figura 2.1: Ejemplo de un grafo de escena

Estructura Fı́sica y Representación

3.1. Estructura del Robot

Figura 3.1: Estructura de un MSR

a Este parámetro coincide con la longitud de los eslabones.

d No hay desplazamiento en la dirección del eje de rotación entre un marco de referencia y el

3.2. Componentes del Robot Real

Figura 3.2: MSR Lola-OPTM para simulación

Figura 3.3: Ensamblaje real del Robot

3.3. Modelos del Robot para el Motor de Fı́sica

3.3.1. Lola-OPTM No Elastómero

Figura 3.4: Modelo Sin Elastómero

En cuanto a la distribución de la masa se escoge también un paralelepı́pedo cuya distribución de

3.3.2. lola-OP con Elastómero

Figura 3.5: Modelo Con Elastómero

Para representar la distribución de masa en el segundo modelo se utilizan el mismo paralelepı́pedo

3.4. Armado del Robot Simulado

El robot en la simulación se construye a partir de los modelos de módulo presentados en la sección

3.5. Modelos para la Visualización

Figura 3.6: Modelos para los Gráficos

Todo esto puede ser observado en la figura 3.7.

Figura 3.7: Sección de la serpiente del grafo de escena

Representación señales Motores

1. Se encarga del protocolo de comunicaciones para recibir instrucciones de alto nivel,

2. En concordancia con las instrucciones controla el motor DC y

4.1. Control de alto nivel

El microcontrolador a bordo de los motores dynamixel AX-12 es un Atmega8 de la familia AVR. Es

En la sección 4.1.1 se especifican el protocolo de comunicaciones entre el actuador y la unidad de

detallan los registros disponibles en el actuador y en la sección 4.1.3 se presenta la implementación

Figura 4.1: Esquema de conexión Daisy-Chain

De esos 32 registros, 14 están en la memoria EEPROM del microcontrolador y 18 están en la

4.1.3. Implementación del protocolo de Comunicación