Robot Serpiente Modular Simulado

(1)

PONTIFICIA UNIVERSIDAD JAVERIANA

Robot Serpiente Modular Simulado

-Framework Integrado(SMSR-IF) v0,1

Jose Manuel Monsalve Diaz

Juan Sebastian Le´

on Rivera

Director de Trabajo de Grado: Kamilo Melo Ph.D.

Facultad de Ingenier´ıa Departamento de Electr´onica

(2)

´Indice general

´_{Indice de Figuras} III

Abreviaturas V

1. Introducci´on 1

2. Marco Te´orico 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. Selecci´on de la Biblioteca . . . 6

2.2. Motor Gr´afico . . . 7

2.2.1. DirectX . . . 8

2.2.2. OpenGL . . . 8

2.2.2.1. Proceso de renderizaci´on . . . 8

2.2.3. OpenSceneGraph . . . 9

3. Estructura F´ısica y Representaci´on 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 Elast´omero . . . 14

3.3.2. lola-OP con Elast´omero . . . 15

3.4. Armado del Robot Simulado . . . 16

3.5. Modelos para la Visualizaci´on . . . 16

4. Representaci´on se˜nales Motores 19 4.1. Control de alto nivel . . . 19

4.1.1. Comunicaciones . . . 20

(3)

Contents

4.2. Control del motor DC . . . 21

4.2.1. Implementaci´on de los motores simulados . . . 22

4.3. Sensores . . . 23

5. Geometr´ıa y Caracter´ısticas de Contacto 24 5.1. Mapa de Elevaci´on . . . 24

5.1.1. Caracter´ısticas de los Mapas de Elevaci´on . . . 24

5.1.2. Implementaci´on en el Simulador . . . 25

5.2. Contactos . . . 26

6. Integración - validación 28 6.1. Descripción general de los bloques . . . 28

6.2. Flujo del Programa . . . 29

6.3. Interfaces Gr´aficas de Usuario . . . 30

6.4. Validaci´on . . . 31

6.4.1. Experimentos con el robot real . . . 31

6.4.2. Experimentos con el robot simulado . . . 32

6.4.3. An´alisis de los resultados . . . 33

7. Conclusiones 39 A. Nota de Publicaciones 41 B. Medidas de las partes constitutivas del M´odulo 42 C. Manual de uso del simulador 44 C.1. Inicio y formato de archivo . . . 44

C.2. Previo a la simulaci´on . . . 45

C.2.1. Par´ametros de la serpiente . . . 46

C.2.2. Par´ametros del motor de f´ısica . . . 47

C.2.3. El heightfield (Opcional) . . . 47

C.3. En simulaci´on . . . 48

C.3.1. Control de visualizaci´on y simulaci´on . . . 49

C.3.2. Ayudas visuales y m´as opciones de gr´aficos . . . 49

D. Registro de Cambios 53

(4)

´Indice de figuras

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

3.1. Estructura de un MSR . . . 12

3.2. MSR Lola-OPTM _{para simulaci´}_{on . . . .} ₁₃

3.3. Ensamblaje real del Robot . . . 13

3.4. Modelo Sin Elast´omero . . . 14

3.5. Modelo Con Elast´omero . . . 15

3.6. Modelos para los Gr´aficos . . . 17

3.7. Secci´on de la serpiente del grafo de escena . . . 18

4.1. Esquema de conexi´on 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 configuraci´on para el Mapa de Alturas . . . 26

5.3. Aproximaci´on de Coulomb . . . 27

5.4. Aproximaci´on piramidal del cono de Coulomb . . . 27

6.1. Diagrama de bloques del simulador . . . 29

6.2. Interfaces Gr´aficas de Usuario . . . 31

6.3. Montaje experimental . . . 33

6.4. Montaje experimental en el simulador . . . 33

6.5. Variaci´on k y µ.Linear Progression . . . 34

6.6. Trayectoria de Gait afectado por valores de µgrandes . . . 35

6.7. Variaci´on k y µ.Lateral Rolling . . . 36

6.8. Variaci´on k y µ.Side Winding . . . 37

6.9. Evidencia del Modelo de Fricci´on . . . 38

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

B.2. FP04-F2 (Robotis) . . . 43

B.3. FP04-F3 (Robotis) . . . 43

(5)

Lista de Figuras

C.3. Ventanas de los par´ametros de la serpiente . . . 46

C.4. Ventana de los par´ametros del motor de f´ıscia . . . 47

C.5. Ventana de configuraci´on de Heighfields . . . 48

C.6. Barra de progreso de carga . . . 49

C.7. Resultado de la simulaci´on . . . 49

C.8. Controles de visualizaci´on . . . 49

C.9. Ejes de referencia activados . . . 50

C.10.FOG Activado (No disponible en todos las tarjetas gr´aficas) . . . 50

C.11.Puntos de contacto Activados . . . 51

C.12.Trayectorias Activado . . . 51

C.13.Ejes en los m´odulos . . . 51

(6)

Abreviaturas

MSR Modular SnakeRobot

API ApplicationProgramming Interface

SDK Software Development Kit

ODE Open Dynamics Engine

OSG Open Scene Graph

(7)

Cap´ıtulo 1

Introducci´

on

Un Modular Snake Robot [1] tiene el potencial de moverse en terrenos dif´ıciles [2][3]. Sin embargo,

es necesario dise˜nar varias estrategias de movimiento y la transici´on entre ellas para darle usos

prácticos [4]. El flujo de diseño para el planeamiento de movimiento exige la verificación constante

de los m´etodos de locomoci´on, 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 operación es necesario ejecutar ajustes que consumen aún más tiempo. Surge

entonces la necesidad de verificar las estrategias de locomoci´on de una forma diferente.

Otra manera de conseguir esta verificaci´on es mediante la creaci´on de un modelo que permita la

predicci´on del comportamiento del robot. Un modelado matem´atico busca solucionar de manera

anal´ıtica las ecuaciones que gobiernan un fen´omeno, pero dada la complejidad del robot [5][4], una soluci´on de este tipo es inapropiada [6].

Una alternativa formal es la simulación por computadora, que mediante métodos numéricos [7]

re-suelve las ecuaciones mencionadas y muestra el efecto que tiene la variación de múltiples pará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 simulaci´on de robots, [8][9][10][11] entre otros.

Fueron creados con la intenci´on de probar algoritmos de inteligencia artificial y sistemas de control

de movimiento. Para ello cuentan con varias librer´ıas de plataformas rob´oticas y sensores de uso

amplio, y a pesar de que permiten la creaci´on de robots nuevos, la personalizaci´on es a alto nivel y

no se ajusta a la necesidad planteada.

Para la descripción de la cinemática y la dinámica de una plataforma robótica, un motor de f´ısica

es una buena herramienta [7]. Permite simular la mec´anica de un cuerpo real, detectar y recrear

(8)

Cap´ıtulo 1. Introducci´on

El desarrollo de un modelo simulado del Modular Snake Robot (MSR) lola-OPTM [12][13][14] y de

escenarios virtuales, as´ı como la emulaci´on de las entradas y salidas del robot existente, facilitar´a la

investigaci´on del grupo, especialmente en la generaci´on de estrategias de movimiento.

El objetivo principal de este trabajo es entonces proveer a la comunidad de rob´otica de una

herra-mienta computacional, para facilitar el proceso de generaci´on de estrategias de movimiento de un Modular Snake Robot. Como objetivos espec´ıficos se tiene:

1. Representar la estructura mec´anica del Modular Snake Robot (MSR) lola-OPTM_{, mediante el}

uso de una herramienta computacional.

2. Representar las se˜nales de los sensores internos de los servomotores del MSR, de acuerdo al

comportamiento din´amico de su representaci´on computacional.

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

de simulaci´on, 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 Te´orico, se presenta la teor´ıa de operaci´on y el estado del arte de las partes que constituyen el

simulador, en el cap´ıtulo 3,Estructura F´ısica y Representaci´on Virtual, se describe el tipo de robots

objeto del simulador y se presentan los modelos para su emulaci´on, en el cap´ıtulo 4,Representaci´on

de las se˜nales de los motores, se estudian los actuadores del robot y se presentan los detalles de

la implementaci´on de sus equivalentes virtuales, en el cap´ıtulo 5, Geometr´ıa y Caracter´ısticas de

Contacto, se discute la implementaci´on de estructuras para representar el ambiente y su interacci´on

con el robot, en el cap´ıtulo 6,Integraci´on y Validaci´on, se condensa la estructura del programa y su

(9)

Cap´ıtulo 2

Marco Te´

orico

El simulador se construye alrededor de dos bloques: el motor de f´ısica y el motor gr´afico, ensamblados

a partir de librer´ıas para C++. En este capitulo se discute la funci´on y teor´ıa de operaci´on de cada

uno as´ı como la selecci´on de las librer´ıas.

2.1. Motor de F´ısica

Una simulaci´on 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 métodos numéricos, que trabajan con pasos de tiempo definidos y utilizan métodos como el de Euler o mejoras del mismo,

como el método del punto medio. La relación entre la precisión de la respuesta y el tiempo de

cómputo es importante a la hora de escoger un método de resolución de ecuaciones diferenciales.

Una precisi´on alta permite la selecci´on de pasos de tiempo grandes, sin embargo, si el tiempo de

cómputo es elevado entonces puede ser preferible elegir un método más rápido con pasos de tiempo

peque˜nos.

Como se ha mencionado, las ecuaciones diferenciales pueden representar fenómenos de diferente naturaleza. Es deseable hacer que la porción de código que resuelve las ecuaciones diferenciales sea

independiente del fenómeno simulado y viceversa. Esto con la intención de poder reutilizar el código

o incluso intercambiar el m´etodo con que se resuelven las ecuaciones diferenciales [15].

(10)

Cap´ıtulo 2. Marco Te´orico

resolver [15]. Estas funciones se limitan a: conocer el n´umero de variables del sistema, obtener los

valores presentes de esas variables y calcularlos a medida que se ejecutan los pasos para la soluci´on.

Para llegar a una estructura que represente al sistema y que permita efectuar dichas operaciones, se debe modelar de alguna forma el fen´omeno 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

din´amica de cuerpo r´ıgido, de cuerpo flexible, de part´ıculas, de fluidos, o una combinaci´on de ellos.

Las matem´aticas detr´as de cada sistema f´ısico mencionado no solo proporcionan las ecuaciones

diferenciales que rigen al fen´omeno sino tambi´en un conjunto de restricciones [16].

Por ejemplo, en el caso de la din´amica de cuerpo r´ıgido, se definen cuerpos con propiedades como

la posici´on de su punto de referencia, velocidad del punto de referencia, orientaci´on del cuerpo,

velocidad angular, masa, posici´on 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 s´olo restringen la posici´on 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 din´amicamente 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 mover´a.

A parte de las restricciones y ecuaciones que rigen a la simulaci´on, una caracter´ıstica de los motores

de f´ısica es la detecci´on de colisiones. Cuando dos cuerpos colisionan el programa se detiene, eval´ua

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 direcci´on abruptamente, hacer un cambio paulatino de magnitud o incluso los cuerpos pueden penetrar uno al otro.

Una posibilidad es utilizar un motor gr´afico para mostrar al usuario el resultado de la simulaci´on

después de cada paso o de un número determinado de pasos. En este caso, y con la intención de

hacer más rápida la simulación se usan prácticas como definir dominios de colisió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 tama˜no de los pasos de tiempo, el m´etodo

de resoluci´on de las ecuaciones diferenciales, el algoritmo de detecci´on de colisiones (por ejemplo

para ignorar objetos lejanos), los coeficientes de fricci´on entre cuerpos y las caracter´ısticas de las

colisiones para alcanzar una simulaci´on r´apida 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 alg´un aspecto del proceso de simulaci´on.

(11)

y otros de texto, con opciones de edici´on de ambientes y objetos y las funciones y l´ımites est´an

muy bien definidos por las restricciones del programador y no pueden ser expandidos f´acilmente.

El segundo, las Application Programming Interface (API), en las que se encuentran un conjunto

de funciones gen´ericas y que pueden ser utilizadas a manera de biblioteca en programaci´on,

bus-cando resolver problemas bastante espec´ıficos. Normalmente, se encuentran en diferentes lenguajes,

y est´an pensadas para desarrollar aplicaciones o frameworks m´as grandes. En simuladores para

robótica encontramos opciones de software en ambas presentaciones, a continuación se describirán

las m´as significativas.

2.1.1.1. Frameworks

Empezando por los frameworks, CARMEN (Carnegie Mellon Robot Navigation Toolkit) [17] [18],

escrito en C y diseñado para resolver problemas de navegación de robótica en 2D. Es un

conjun-to de programas con una funci´on independiente entre las que se encuentran, comunicaci´on entre

procesos, especificaciones del robot, definición y planeamiento de rutas, localización, simulación,

interfaces gr´aficas, entre otros. Para que se comuniquen se usa Inter-Process Communication (IPC) y existe un encargado de organizar esta comunicaci´on. Esto permite que el simulador corra en 1 o

varios computadores a la vez, distribuyendo la carga. Las plataformas que soporta est´an definidas

en la documentaci´on; 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 tambi´en con diferentes sensores y c´amaras que pueden ser adaptados a las plataformas. Stage [9] trabaja en 2D y se centra en simular muchos agentes con

poca fidelidad, siendo bastante útil para analizar algoritmos de interacción. Gazebo [9], está diseñado

para 3D y, aunque permite simular varios robots, cuenta con un mecanismo para cuerpos r´ıgidos, haci´endolo m´as 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 José Cerqueira de la Universidade do Porto, en Portugal, es el má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 cámaras

del mundo, ver informaci´on del robot como posici´on, velocidad y datos de los sensores. El robot y

escenario están diseñados en archivos con formato XML donde se definen por etiquetas los obstáculos

y objetos, los sensores externos e internos y las partes del robot y sus junturas.

Existen tambi´en 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 rob´otico. El segundo,

(12)

2.1.1.2. APIs

Por otra parte, tenemos las API’s de f´ısica. Todas son funciones que resuelven numéricamente las interacciones y no cuentan con gráficos en la mayor´ıa de los casos. Bullet [22], Open Dynamics Engine (ODE) [7] y PhysX [23] son algunos de los má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 colisión e interacció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 precisi´on y la velocidad de cada uno.

ODE [7], Bullet [22] y PhysX [23], permiten la creación de cuerpos geométricos r´ıgidos, definir sus uniones y ubicarlos en un ambiente con una gravedad definida y unas caracter´ısticas de colisió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 peque˜no para garantizar la estabilidad de la soluci´on. El segundo,

creado principalmente por Erwin Coumans mientras trabajaba para Sony Computer Entertainment,

utiliza una adaptaci´on de PGS que reduce la precisi´on de los resultados y aumenta la velocidad de

c´omputo. por ´ultimo, 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 m´ultiples solucionadores tanto para cuerpos r´ıgidos como para part´ıculas.

2.1.2. Selecci´on 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 precisión y no en velocidad, la solución debe ser lo más cercana a la realidad.

Tercero, ser compatible con las pol´ıticas de licenciamiento libre definidas y Cuarto, debe tener suficiente documentaci´on para facilitar la tarea de desarrollo. Bajo estos criterios, es f´acil descartar

los frameworks, pues su integración a otro framework implicar´ıa una posible modificación del có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 ´ultimo,

Es destacable la cantidad de documentaci´on existente en Bullet, la constante actualizaci´on de su

software y la velocidad de ejecuci´on. Sin embargo, la precisi´on no cumple nuestras pautas, lo que

podr´ıa desencadenar f´acilmente en resultados no representativos para el proyecto. Por esto ODE se

posiciona como la mejor, contando con gran cantidad de documentación, no sólo en programación,

sino también en aplicaciones en simuladores de robótica; y permitiendo, por medio de la adaptación

(13)

Se ha mostrado en diferentes estudios [24] c´omo se debe adaptar ODE para que cumpla

requeri-mientos de una buena simulaci´on. Adem´as, se ha comparado su funcionamiento con Carmen y Stage

y Gazebo [25] recalcando su superioridad en resultados, complejidad de instalaci´on y velocidad de

ejecuci´on. 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 Gr´

afico

Una vez seleccionado ODE como motor de f´ısica es necesario plantear mecanismos para la

visuali-zación y análisis de los resultados. Un recurso fundamental para este fin es la presentació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 a˜nadir 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 informaci´on

funda-mental para el an´alisis final. Para estos se debe generar archivos con formato definido que permitan

utilizar los datos en herramientas de generaci´on de gr´aficas o como fuente para otros procesos.

Para la programaci´on del motor visual se debe seleccionar un API de gr´aficos 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 gr´aficos de bajo nivel son OpenGL y Direct3D (DirectX). Se clasifican como bajo nivel porque se comunican directamente con la tarjeta

gráfica y genera imágenes a partir de la transformación de vértices y su información, de un marco

de referencia hacia la pantalla. Estas librer´ıas no est´an dise˜nadas 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 posici´on de cada uno de los v´ertices, la forma en que se

conectan y especificar que se est´an dibujando caras s´olidas.

Para poder representar la escena, los vértices atraviesan un proceso junto con la información de ubicació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 posici´on en

la pantalla plana (R2). Luego, los v´ertices son pasados por una rasterizaci´on que completa la

in-formaci´on de los p´ıxeles entre v´ertices para dibujar una cara o arista de un color, o aplicar una

textura. Para darle realismo a la escena, y si est´a especificado, se lleva a cabo un sombreado, reflejos

y algunas veces, mezcla de resultados.

A continuación se da una introducción a DirectX y openGL. Se explica más a fondo el proceso de

(14)

2.2.1. DirectX

DirectX es una colecció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 grá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 creación de juegos, en especial para la plataforma de Microsoft. Su implemen-tación permite un control directo sobre el manejo de los recursos del hardware para gráficos y su

programaci´on 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, convirti´endolo 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 est´andar 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 est´andar 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 m´ultiples plataformas, principalmente en linux, se convierte en la opci´on principal para

este proyecto.

2.2.2.1. Proceso de renderizaci´on

OpenGL funciona como una máquina de estados que lleva la información desde los vértices a una renderización. Existen dos actores en este proceso, el cliente, normalmente interpretado por la CPU; y el servidor, quién usualmente es la unidad de procesamientos gráficos (GPU). El cliente, programado en c, organiza los vértices y la información necesaria para graficarlos en elementos

llamados primitivas; adem´as, texturas, iluminaci´on, transformaciones y variables que modifiquen

la renderizaci´on final. Esta informaci´on 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, posici´on y color de los v´ertices individuales sin tener en

cuenta las uniones entre ellos. la segunda, el Fragment Shader, lleva a cabo la rasterizaci´on, asignando

los valores de color a cada uno de los p´ıxeles, de acuerdo a la forma en que se unen los v´ertices,

las texturas que se requieras, la iluminaci´on, el sombreado y las dem´as opciones especificadas por

(15)

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 m´as 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 có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 pérdidas en el rendimiento. Ademá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.

Losgrafos de escena(Scene Graph) son estructuras de datos definidas por nodos, en forma de ´arbol,

que contienen los vértices, transformaciones y demás información necesaria para la escena gráfica.

Su intenci´on es generar una abstracci´on de la escena real. Todo elemento de OSG es un nodo que

puede ser a˜nadido al grafo de escena.

En un ejemplo, se tiene una habitaci´on, con una mesa caf´e y encima un libro y unas llaves. Se podr´ıa

decir que la ra´ız delgrafo de escena ser´ıa la habitaci´on, la cual tiene su propio marco de referencia y

sus valores de iluminaci´on y color descritos en losnodos hijos. Luego se agrega una transformaci´on

de posición y rotación para ubicar la mesa por medio de un nodo hijo, a esta transformación,

que funciona como nuevo marco referencial, se le agrega la mesa en un nodo que describe c´omo

est´a construida la mesa en v´ertices y como debe ser renderizada. A esta mesa se le pueden definir

tambi´en los valores de color espec´ıfico y comportamientos deseados uniendo a ella m`as hijos con

dichas caracter´ısticas. Por ´ultimo a esta mesa se agregan un par de nodos de transformaci´on de

posición y rotación donde irán, por separado, las llaves y el libro. la descripción de las llaves y el

libro pueden ser importadas de otro archivo. Este ejemplo puede ser observado en la figura 2.1.

(16)

Existen entonces nodos de diferente tipo en el ´arbol, cada uno con una funci´on propia tales como

transformaciones lineales, estados de OpenGL, definiciones de v´ertices, c´amaras, luces, animaciones o

nodos predefinidos que permiten crear objetos geom´etricos sencillos como cubos, esferas y cilindros,

sin necesidad de definir todos los v´ertices manualmente, especificando solamente su posici´on y

dimensiones. OpenSceneGraph est´a organizado en clases donde cada una de ellas representa uno de

estosnodos.

Una vez construido el grafo, es graficado y proyectado por unvisualizador. 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 c´amaras diferentes o con algunas de las

(17)

Cap´ıtulo 3

Estructura F´ısica y Representaci´

on

Virtual de Lola-OP

TM

Para completar la simulaci´on del robot con el motor de din´amica 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 simulaci´on cuya complejidad permite

balancear el tiempo de computación y la precisión de los resultados. En cuanto a la visualización,

es necesario definir las diferentes representaciones visuales de los modelos y como se integran a la

escena. En la secci´on 3.1 se muestran las caracter´ısticas de este tipo de robot, en la secci´on 3.2 se

estudian las caracter´ısticas de los componentes con que se construy´o el robot real, en la secci´on 3.3

se proponen algunos modelos para la simulación, en la sección 3.4 se hace una introducción a la

construcci´on del robot en el simulador y finalmente en la secci´on 3.5 se presentan los modelos para

la visualizaci´on y su importaci´on.

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 cinem´atica abierta en donde los eslabones est´an conectados

entre si por junturas rotacionales. Una juntura rotacional mantiene constante la distancia entre los

eslabones que conecta y hace variar el ´angulo que forman dichos eslabones alrededor del eje que

define la juntura.

Con excepci´on de los eslabones de los extremos, en un MSR las junturas siempre unen dos eslabones

y los eslabones, que son todos iguales, siempre est´an conectados a dos junturas. Para hacer una

(18)

Cap´ıtulo 3. Estructura F´ısica y Representaci´on 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 rotaci´on y el eje X se encuentre en la direcci´on que une una juntura y la siguiente. De

esta manera los par´ametros de Denavit-Hartenberg son:

a Este par´ametro coincide con la longitud de los eslabones.

d No hay desplazamiento en la direcci´on del eje de rotaci´on entre un marco de referencia y el

siguiente.

θ _{Este par´}_{ametro coincide con el ´}_{angulo de la juntura y el conjunto de todos ellos constituyen la}

configuraci´on del robot para cada instante de tiempo.

α _{En este par´}_{ametro 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 rotaci´on correspondientes a todas las junturas son

paralelos, mientras que en el otro caso hay una rotaci´on de 90◦ _{respecto a la juntura anterior.}

Como convención, al eslabón del extremo se le denomina eslabón 0, al siguiente eslabón se le

deno-mina eslab´on 1 y a la juntura rotacional que los une se la denodeno-mina 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 b´asica que se ensambla a partir de tres piezas,

como se ve en la Fig. 3.3, adem´as de los tornillos y tuercas. Todas las piezas hacen parte del kit de

(19)

Figura 3.2:_{MSR Lola-OP}TM _{para simulaci´}_on

Los actuadores son servomotores Dynamixel AX-12, mientras que las piezas utilizadas para com-pletar la estructura son los marcos pl´asticos FP04-F2 y FP04-F3. Las medidas relevantes de estas piezas est´an detalladas en el anexo B.

La segunda versi´on del robot esta basada en la plataforma b´asica, a la cual se le agregan unos

cilindros de elast´omero. Estos cilindros protegen las partes del robot durante el funcionamiento al

tiempo que aumentan la superficie de contacto y el coeficiente de fricción con el suelo. Hay un cilindro por cada eslabón, de 35 mm de longitud y 75 mm de diámetro.

Las dos versiones del robot est´an compuestas por 17 eslabones y 16 junturas rotacionales. Al conjunto

base de construcci´on, conformado por un actuador y dos marcos pl´asticos como se ve en el centro

de la Fig. 3.3, se le llama módulo. Siguiendo esta denominación y la convención de la sección 3.1,

el eslabóniy la juntura ihacen parte del móduloi. En el caso del eslabón 0, se utiliza otro marco

pl´astico en lugar de un actuador.

Figura 3.3:_{Ensamblaje real del Robot}

Como caracter´ıstica de diseño, y para proteger la integridad f´ısica del robot, el ángulo máximo que

puede rotar cada actuador desde la posición inicial (cuando los módulos están alineados) y en ambos

(20)

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

Para llevar a cabo la simulaci´on 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 distribuci´on de la masa, necesaria para evaluar la din´amica de cuerpo

r´ıgido y el efecto de la gravedad. En 3.3.1 y 3.3.2 se proponen modelos de simulaci´on para cada una

de las versiones del robot. Se tienen en cuenta la velocidad de simulaci´on as´ı como los primitivos de

colisión implementados en el motor de f´ısica y la estabilidad de la solución matemática al momento

de proponer la representaci´on de los m´odulos.

3.3.1. Lola-OPTM

No Elast´omero

Para representar la geometr´ıa de cada uno de los m´odulos 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 posici´on del eje de rotaci´on y la distancia

entre m´odulos. En este caso el centro geom´etrico del paralelep´ıpedo y el centro de masa del cuerpo

est´an en el mismo punto.

Figura 3.4:_{Modelo Sin Elast´omero}

En cuanto a la distribución de la masa se escoge también un paralelep´ıpedo cuya distribución de

masa es homog´enea. 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 Kgm2_.

T =

  

1,8792E−5 0 0

0 1,2027E−5 0

0 0 1,6152E−5

 

(21)

3.3.2. lola-OP con Elast´omero

En el segundo modelo propuesto para la simulaci´on se representa la geometr´ıa de cada uno de los

m´odulos como la composici´on de un paralelep´ıpedo y un cilindro. En la Fig. 3.5 se resalta el modelo

sobre la imagen real de un m´odulo y se muestran las medidas correspondientes a los lados de la

caja, el radio y longitud del cilindro, la posición del eje de rotación y la distancia entre módulos.

En este caso el cilindro coincide con el cilindro de elast´omero y la caja con la parte del actuador

que sobresale del mismo. El centro geom´etrico del cilindro est´a desplazado 0,0215 m del centro de

masa del cuerpo; el centro geom´etrico de la caja est´a desplazado 0,0105 m del centro de masa del

cuerpo.

Como se aprecia en Fig. 3.5 la caja de un m´odulo y el cilindro del m´odulo adyacente presentan

puntos de colisi´on a lo largo del rango de rotaci´on. Esto no sucede en el robot real dado que el

cilindro de elast´omero es hueco. Para completar la simulaci´on utilizando las geometr´ıas propuestas

es necesario permitir que los m´odulos adyacentes se penetren entre si, al ignorar las colisiones (en el motor de f´ısica) entre m´odulos adyacentes.

Figura 3.5:_{Modelo Con Elast´omero}

Para representar la distribuci´on de masa en el segundo modelo se utilizan el mismo paralelep´ıpedo

del modelo 1 y un cilindro hueco en la misma posici´on 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 est´a distribuida de manera uniforme y es de 0,055 Kg. La masa del cilindro

tambi´en est´a 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 Kgm2_.

T =

  

4,0849E−5 0 0

0 3,0173E−5 0

0 0 2,186E−5

 

(22)

3.4. Armado del Robot Simulado

El robot en la simulación se construye a partir de los modelos de módulo presentados en la sección

anterior. Se debe ubicar cada modulo en la posici´on inicial adecuada de acuerdo al n´umero de

modulo y teniendo en cuenta la rotaci´on de 90◦ _{de los m´odulos pares alrededor del eje sobre el que}

se extiende el robot.

Una vez ubicados los m´odulos se unen mediante articulaciones rotacionales, estas limitan el movi-miento relativo entre m´odulos de la misma forma que las junturas rotacionales pero son pasivas. Las

junturas rotacionales y modelos de motor se discutir´an en el capitulo 4. Para definir una articulaci´on

rotacional se debe especificar un punto sobre el eje de rotaci´on y la direcci´on del eje. De nuevo se

debe tener en cuenta la rotaci´on de 90◦ _{para satisfacer la estructura mencionada en la secci´}_{on 3.1.}

Para emular al robot real se impone la misma limitaci´on de 60◦ _{en el rango de rotaci´}_{on de los}

m´odulos. Como medida adicional se agrega un espacio muy peque˜no (0,0001 m) entre la caja y el

cilindro, en el modelo 2, para evitar la detecci´on de colisiones entre los componentes del m´odulo por

parte del motor de f´ısica.

3.5. Modelos para la Visualizaci´

on

As´ı como existen dos versiones del MSR, la visualizaci´on se divide en una plataforma b´asica y en

su extensión con cilindros de elastómero. Para cada uno se genera una representació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 construcci´on de la serpiente.

Los CAD (Computer Aided-design) son herramientas que permiten el dise˜no de modelos visuales

complejos tanto en 2D como en 3D. Seg´un 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 geom´etricas b´asicas (Cubos,

esferas, cilindros, etc), definición de aristas o enmallado en triángulos o cuadrados de vértices.

Información de ubicación y orientación espacial, dimensiones, texturas, colores y movimiento, entre

otras, tambi´en pueden ser encontradas en el CAD y son utilizadas en la renderizaci´on.

Para las representaciones simples se crean modelos iguales a los planteados para ODE de

para-lelep´ıpedos en la plataforma b´asica, y cilindros unidos a paralelep´ıpedos en la plataforma con

elast´omero; creados como nodos del grafo de escena especificando en la creaci´on las dimensiones

configuradas de acuerdo a los valores reales del robot. Estos nodos son del tipoosg::shape y deben

ser agregados a nodos osg::shapeDrawable que a su vez deben ser agregados a osg::Geodes. Estas

(23)

Para la representación compleja se utilizan archivos CAD importados y soportados por la librer´ıa OSG. Se importan archivos en formato .3ds que representa el módulo en un enmallado de vértices,

y cuentan con la descripci´on 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 p´agina oficial. Los datos del archivo son interpretados por OSG, quien

entrega en nodos la información necesaria para el visualizador. Una transformación de posición y

orientaci´on es agregada para acoplar el sistema de referencia del archivo CAD con el de la escena gr´afica.

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 Gr´}_aficos

Estas representaciones son agregados como nodos hijos a un objeto tipo interruptor llamadoosg::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 posición y orientación de los módulos de acuerdo a los valores arrojados por el motor

de f´ısica, y sincronizar los tiempos reales de la simulaci´on con la visualizaci´onOpenSceneGraphofrece

la clase osg::AnimationPath que modifica una matriz de transformaci´on en donde se encuentra el

(24)

Una ruta de animación almacena los valores de transformació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 animación y reproducidos en el instante preciso, por

medio de un nodo de control que contiene a elosg::AnimationPath, conservando el sincronismo.

Todo estos elemetos son creados en cada uno de los m´odulos. Por lo tanto, es necesario agrupar esta

informaci´on 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.

(25)

Cap´ıtulo 4

Representaci´

on se˜

nales 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 secci´on 4.1 se trata el mecanismo de control de alto nivel del servomotor, en la secci´on 4.2 se

considera el control del motor DC, finalmente en la secci´on 4.3 se enumeran los datos de sensores

disponibles y se discute su emulaci´on.

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 dise˜nado por el fabricante. Se conecta

a la unidad controladora a trav´es de un cable referido a tierra y su interacci´on ocurre mediante la escritura y lectura de un conjunto de registros en el microcontrolador. De esta manera, para

cambiar la posici´on del actuador se escribe en el registro correspondiente a la posici´on objetivo y

el programa en el microcontrolador se encarga de cumplirla sin m´as intervenci´on por parte de la

unidad controladora.

En la secci´on 4.1.1 se especifican el protocolo de comunicaciones entre el actuador y la unidad de

(26)

Cap´ıtulo 4. Representaci´on se˜nales Motores

detallan los registros disponibles en el actuador y en la secci´on 4.1.3 se presenta la implementaci´on

del sistema de control de alto nivel en el simulador, basado en la informaci´on presentada.

4.1.1. Comunicaciones

Los 16 actuadores que componen el robot y la unidad controladora se interconectan bajo un esquema

de conexi´on daisy chain. El bus de comunicaciones as´ı como la distribuci´on 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 conexi´on Daisy-Chain}

Entre los dos cables de DATA de cada actuador solo est´a un buffer tri-state, por lo que todos los

actuadores comparten el mismo bus serial. La comunicaci´on 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 transmisi´on se puede variar, siendo 1 MBPS la m´axima.

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 instrucci´on. El ID

de actuador es un numero entre 0 y 253 siendo 254 el ID para difusi´on. Entre los tipos de instrucci´on

se encuentran Ping, lectura y escritura de registro. El cuerpo del paquete incluye los datos relevantes

seg´un la instrucci´on y finalmente se agrega un Checksum.

Durante la operaci´on del robot real se utiliza la velocidad de transmisi´on de 1 MBPS y solo se

env´ıan instrucciones para cambiar la posici´on de los actuadores y recibir el paquete de estado de

cada uno. Teniendo en cuenta el tama˜no de los paquetes de red correspondientes y el n´umero de

actuadores, la frecuencia m´axima a la que se puede controlar cada actuador es 11,7 Hz. Se utiliza una frecuencia de 10 Hz.

4.1.2. Registros

(27)

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 est´an en la memoria EEPROM del microcontrolador y 18 est´an en la

memoria RAM. Es posible dividir los registros en 3 categor´ıas de acuerdo a su funci´on: registros de

informaci´on, que almacenan datos como la versi´on del programa que ejecutan o el ID que tienen

asignado, registros de configuraci´on o control, que permiten controlar variables como la posici´on

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 ubicaci´on de los registros en una memoria u otra esta relacionado con su funci´on. Los registros

que corresponden a información están en la memoria no volátil, y en algunos casos se utilizan los

valores almacenados all´ı para inicializar los registros de configuraci´on.

La lista completa de los registros y su descripci´on se encuentra en el anexo [29]. Los registros

relacionados con control y configuración se presentan con más detalle en la sección 4.2, de manera

similar se tratan los registros relacionados con los sensores en la secci´on 4.3.

4.1.3. Implementaci´on del protocolo de Comunicaci´on

Durante la operaci´on del robot y para producir el movimiento deseado, se extraen los ´angulos

correspondientes a cada actuador (configuraci´on) de un archivo de control. Este archivo de control

se puede generar a partir de 7 par´ametros [4] o programar paso por paso mediante las interfaces

creadas para tal fin [14]. Adicionalmente durante la operaci´on se almacena el estado de cada actuador

en otro archivo, diseñado por el grupo, para su inspección luego del experimento. Otros parámetros

de configuraci´on no se alteran durante el movimiento y solo son configurados antes de comenzar los

experimentos. Más información sobre la generación de á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-raci´on 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 simulaci´on 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 posici´on 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 está conectado al eje de rotación a través de

una reducción de engranajes con una relación de transmisión de 254. Como sensor de posición el

(28)

de 320◦_{. Para medir la ca´ıda de tensi´on en el potenci´ometro el microcontrolador utiliza su conversor}

an´alogo-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 público. La comunidad, a través de esquemáticos hechos

mediante la observaci´on del circuito impreso y experimentos, ha podido demostrar que los actuadores

AX-12 tienen lazo de realimentaci´on para el control de posici´on, mientras que la velocidad angular

y el momento de fuerza se controlan en lazo abierto. Para que la posici´on 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 posici´on a alta frecuencia

al actuador [31][30].

Como configuraci´on del usuario se pueden variar los par´ametros en la curva de la Fig. 4.2 (en donde

B y C corresponden al margen de error que puede existir en la posici´on angular antes de que el

actuador corrija la posici´on, y A y D corresponden a la pendiente que regula el momento de fuerza

cuando se est´a cerca a la posici´on objetivo) de manera que el momento de fuerza producido por el

actuador se ajuste de acuerdo a la distancia entre la posici´on angular actual y la posici´on angular

objetivo. También existe un parámetro de configuración adicional a los de la Fig. 4.2 para ajustar

la velocidad angular m´axima de movimiento del actuador.

Todos los par´ametros mencionados en este cap´ıtulo son configurables por el usuario del robot. Sin

embargo, el fabricante no especifica la codificaci´on 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

polarizaci´on 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. Implementaci´on de los motores simulados

(29)

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 limitaci´on

de momento de fuerza (T). En cada paso de simulaci´on, 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 simulación se calcula la diferencia entre la posición angular actual (α) y la posición angular

deseada (β). En base a esta informaci´on 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 direcci´on en que se debe corregir la posici´on; el

momento de fuerza se eval´ua en la funci´on 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 realimentaci´on de posici´on, velocidad, carga, voltaje y

temperatura. Como se mencionó en la sección 4.2 la posición se obtiene de un potenciómetro y la

resoluci´on de 1024 valores esta dada por el conversor A/D del microcontrolador. La velocidad y la carga son medidas indirectas y mantienen una relaci´on lineal entre si.

Los valores de posici´on y velocidad en cada juntura se obtienen directamente durante la operaci´on

del simulador y son almacenados en un archivo para su an´alisis 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 simulaci´on y dada

su relevancia no se emularan.

Un beneficio de la simulaci´on es la existencia de datos adicionales para los que no existen sensores

implementados en el robot. La posici´on y orientaci´on de cada modulo con respecto al marco de

(30)

Cap´ıtulo 5

Geometr´ıa y Caracter´ısticas de

Contacto

En este capitulo se discute el ambiente de simulaci´on. En la secci´on 5.1 se introduce a los mapas

de elevaci´on, su uso, formato e implementaci´on en el simulador, para representar la geometr´ıa de la

superficie del ambiente simulado. En la secci´on 5.2 se discuten los modelos f´ısicos que influyen en la

interacci´on entre el robot y el suelo.

5.1. Mapa de Elevaci´

on

En áreas como topolog´ıa y computación gráfica se utilizan mapas de elevación para representar

terrenos. Un mapa de elevaci´on 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 elevaci´on sonMapa Digital de elevaci´on (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 dem´as.

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 elevaci´on, y su implementaci´on en el simulador.

5.1.1. Caracter´ısticas de los Mapas de Elevaci´on

(31)

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 dise˜nados para programas de animaci´on y juegos. La diferencia

entre estos y las im´agenes radica en la presencia de meta-datos. Tener informaci´on 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 funci´on. 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

resoluci´on de la altura puede estar ligada a una funci´on.

Como con cualquier fenómeno que es codificado de forma digital, existe perdida de información y es posible que sea necesario hacer una interpolación para utilizar los datos. En aplicaciones geof´ısicas

es com´un el uso de algoritmos probabil´ısticos como elMonte Carlo para la reconstrucci´on, sin

em-bargo, en modelado f´ısico y generaci´on de gr´aficos por computador, el uso de interpolaciones lineales

conformando una red de poliedros es m´as 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 v´ertices. La figura m´as 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 tama˜no peque˜no de los archivos,

comparado con otros métodos y formatos, su implementación sencilla y el uso óptimo de memoria.

Adicionalmente existen funciones para la implementación de mapas de altura tanto en la librer´ıa gráfica como en el motor de f´ısica. Como desventaja, los mapas de altura no hacen ninguna optimi-zación cuando se codifican grandes regiones con valores constantes y no permiten describir terrenos en donde mas de un punto tiene la misma proyección sobre el plano, como en la pared escarpada de una cueva.

5.1.2. Implementaci´on en el Simulador

(32)

a la imagen se especifica el tamaño que cubre el mapa de altura (Tamaño X y Tamañ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 interacci´on entre el robot y el terreno se crea un plano temporal cuando se

detecta la colisi´on, siguiendo el primer patr´on presentado en la Fig. 5.1.

Figura 5.2: _{Medidas de configuraci´}_{on para el Mapa de Alturas}

5.2. Contactos

Si bien se ha escogido una simulaci´on basada en din´amica de cuerpo r´ıgido, donde no se tiene en

cuenta la elasticidad ni la din´amica de los impactos entre cuerpos, para modelar la interacci´on entre

el robot y el suelo se tienen en cuenta dos fen´omenos: el rebote y la fricci´on.

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 direcci´on

de movimiento de los cuerpos que colisionan ajustando la rapidez de acuerdo a una constante de

restituci´on. Actualmente no existe ninguna aplicaci´on 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

calibraci´on de las constantes de rebote y restituci´on a el mismo.

En cuanto a la fricci´on se utiliza la aproximaci´on de Coulomb. De acuerdo al modelo de Coulomb,

que fue desarrollado a partir de experimentación, la fuerza de fricción estática es proporcional a

la fuerza entre los cuerpos y no depende del ´area aparente de contacto. De manera formal, si la

componente tangencial a la superficie de contacto de la fuerza resultante es mayor que la componente

(33)

Figura 5.3:_Aproximaci´_{on de Coulomb}

La aproximaci´on de Coulomb se puede ver de manera gr´afica en la Fig. 5.3 donde se muestra el

cono de Coulomb. Si la fuerza resultante est´a por fuera del cono, existir´a movimiento relativo. En

el simulador, por motivos de eficiencia, se utiliza la siguiente aproximaci´on: 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 pir´amide como se muestra en la Fig. 5.4.

Figura 5.4:_Aproximaci´_{on piramidal del cono de Coulomb}

No se proveen valores para el coeficiente de fricci´onµdado que var´ıa para cada entorno de trabajo.

En la sección 6.4 se muestra la influencia de este parámetro sobre los resultados de la simulación.

Es importante recordarle al usuario que la aproximaci´on de coulomb va a influenciar directamente

sobre sus resultados y el valor del coeficiente puede variar en la superficie donde se est´a moviendo el

robot por factores de desgaste o suciedad, humedad relativa del aire, tiempo que llevan unidas las

superficies de contacto, la deformaci´on de los materiales, entre otros. Esto, sin embargo, no afecta la

(34)

Cap´ıtulo 6

Integraci´

on - validaci´

on

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 uni´on de los 6

bloques a un nivel donde los detalles de la implementaci´on 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

conexi´on es posible intercambiar entre versiones de un mismo bloque a medida que se trabaja en el.

Gracias a la adaptabilidad del dise˜no del programa fue posible el trabajo colaborativo durante

el desarrollo del código. Cada vez que se hacia un cambio importante en uno o mas bloques se generó una versión diferente del programa, los detalles de cada versión y los cambios se pueden ver en el anexo D.

Adicionalmente para facilitar la interacci´on del usuario final del simulador se han implementado varias interfaces gr´aficas en QT.

En la sección 6.1 se hace una descripción general de los 6 bloques funcionales, en la sección 6.2

se presenta el flujo del programa, finalmente en la secci´on 6.3 se presentan las interfaces gr´aficas

desarrolladas.

6.1. Descripci´

on general de los bloques

Un diagrama básico de los 6 bloques y su interconexión se muestra en la Fig. 6.1. A continuación

se describe cada uno:

Director Maneja el flujo del programa, organiza a los dem´as bloques, es la fuente de todas las

(35)

Cap´ıtulo 6. Integraci´on - Validaci´on

Figura 6.1:_{Diagrama de bloques del simulador}

motorODE Se encarga de todo lo relacionado con la simulaci´on basada en f´ısica. Inicializa el

ambiente y robot virtuales, se encarga de ejecutar cada paso de la simulaci´on y devuelve los

resultados de cada paso, como la posición de cada módulo y su orientación. As´ı como el bloque

Director dirige a otros bloques, este bloque dirige a los bloquessimSerpiente ysimEscenario.

simSerpiente Contiene un robot virtual, permite crearlo de acuerdo a los modelos existentes y

sus valores configurables. Tambi´en permite cambiar la configuraci´on 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 par´ametros de configuraci´on.

simOSG Se encarga de todo lo relacionado con los gr´aficos. Inicializa losSceneGraphs del ambiente

y robot virtuales y controla las entradas de rat´on y teclado dentro de la ventana de simulaci´on.

simDatos Maneja el flujo de archivos hacia y desde el simulador. Lee las lineas en los archivos de ´

angulos y escribe el archivo con los resultados de la simulaci´on. Tambi´en 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 conexi´on, el siguiente es el flujo del

programa que administra el bloque director:

Para comenzar eldirector inicializa los bloquesmotorODE ymotorOSG utilizando los par´ametros

globales de ODE y los par´ametros 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

(36)

de masa como se discutió en la sección 3.4. Lo segundo implica crear los nodos de visualización, los

transformadores de posición y los controladores de animación como se discutió en la sección 3.5.

Luego de crear el robot, eldirector agrega el mapa de alturas, tambi´en a ambos motores, si es que se

especific´o 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 discuti´o en la secci´on 5.1.2, para OSG se agrega

el nodo correspondiente teniendo en cuenta las transformaciones de posici´on y atitud.

Una vez que est´an inicializados el ambiente y el robot, el director inicia el reloj de simulaci´on y

se repite el siguiente ciclo hasta completar el tiempo de simulaci´on solicitado por el usuario en el

archivo de ´angulos de entrada:

A la frecuencia especificada en el motor de f´ısica se ejecuta un paso de simulaci´on, 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 secci´on 5.2. Adicionalmente se eval´uan las

posiciones de los actuadores para actuar en concordancia con el modelo de motor especificado en

la secci´on 4.2.1. Una vez considerados los contactos y actuadores se toma el paso de simulaci´on (a

cargo de la librer´ıa ODE) y se destruyen los puntos de contacto temporales.

A la frecuencia especificada en la secci´on 4.1.1 para enviar nuevas posiciones objetivo a los actuadores

se actualizan los registros correspondientes, para lo que se utilizan los bloquessimDatos para leer

una nueva linea del archivo de ´angulos y simSerpiente que contiene los registros que emulan a los

del actuador AX-12 como se mencion´o en la secci´on 4.1.3.

A la frecuencia especificada para grabar datos en el AnimationPath, que permite la visualizaci´on

luego de la simulación, se agregan los valores de posición y rotación de cada modulo y los puntos

de contacto encontrados, para lo que se utilizan las funciones de los bloquessimODE ysimOSG.

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

posición y orientación de cada modulo, y posición angular, velocidad angular y momento de fuerza

en cada juntura rotacional.

6.3. Interfaces Gr´

aficas de Usuario

Para facilitar la interacci´on del usuario final con el simulador se han implementado varias interfaces

gr´aficas en QT. Estas permiten seleccionar los archivos de ´angulos, mapas de alturas y texturas,

definir los par´ametros de configuraci´on de los modelos, motores y superficies, y alternar las funciones

(37)

Figura 6.2:_{Interfaces Gr´}_{aficas de Usuario}

6.4. Validaci´

on

En esta secci´on se validar´an 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 utilizó la versión del robot LoLa-OPTM con elastómero sobre un piso plano

de madera laminada. Se llevaron a cabo experimentos para trescore gaits [28];Linear Progression,

Lateral Rolling y Side Winding. En los tres casos se comenz´o con todos los m´odulos del robot en la

posición cero grados, se dividió la posición en dos tramos, se ejecutó el gait durante 4 segundos, se

detuvo en la posición alcanzada para realizar medidas y se ejecutó el gait en la dirección contraria

durante otros 4 segundos. Esto con la intenci´on de conocer el resultado en dos escenarios: cuando el

robot inicia con todos los actuadores en 0◦ _{y cuando el robot parte de una configuraci´}_{on que hace}

Robot Serpiente Modular Simulado

Texto completo