Diseño y Simulación de Piernas para Robot...

Equation Chapter 1 Section 1

Trabajo Fin de Grado

Grado en Ingeniería Electrónica, Robótica y

Mecatrónica

Diseño y Simulación de Piernas para Robot

Humanoide

Autor: Juan Manuel Marredo

Tutores: Alejandro Suárez

Jose Guillermo Heredia

Dpto. Sistemas y Automática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2018

iii

Trabajo Fin de Grado

Grado en Ingeniería Electrónica, Robótica y Mecatrónica

Diseño y Simulación de Piernas para Robot

Humanoide

Autor:

Juan Manuel Marredo Píriz

Tutores:

Alejandro Suárez


Dpto. Ingeniería de Sistemas y Automática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2018

v

Trabajo Fin de Grado: Diseño y Simulación de Piernas para Robot Humanoide

Autor: Juan Manuel Marredo Píriz

Tutores: Alejandro Suárez


El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2018

El Secretario del Tribunal

vii

A mi familia.

A mi novia.

A mis amigos.

ix

Agradecimientos

En primer lugar me gustaría dar las gracias a toda mi familia por el apoyo recibido durante todos estos años.

Especialmente a mis padres y a mi hermana, por ser los pilares de mi vida y los que me han hecho convertirme

en lo que soy hoy, y a mis tíos y a mi prima por acogerme y hacer que en todo momento me sintiese como en

casa.

Gracias a mi novia, Marta, por estar a mi lado todo este tiempo y apoyarme en los momentos difíciles.

Gracias también a mis amigos de la facultad, por aguantar mis tonterías y hacerme pasar algunos de los

mejores ratos de mi vida.

Y por último gracias a todos y cada uno de los profesores que me han guiado y enseñado a lo largo de toda la

carrera.

Gracias a todos.

Juan Manuel Marredo Píriz.

Sevilla, 2018.

Resumen

El presente trabajo, cuya finalidad es el diseño y simulación de la mitad inferior de un robot humanoide, se

divide en 5 partes. En la primera de ellas se realiza un análisis anatómico y biomecánico de unas piernas

humanas con el objetivo de obtener parámetros de interés de cara al diseño. La segunda parte aborda todos los

detalles sobre el diseño del mecanismo en CatiaV5. En la tercera parte se programa la descripción del robot

diseñado utilizando la plataforma ROS, para posteriormente implementar dicho robot en una simulación física

de Gazebo. La cuarta parte está destinada al control de las articulaciones del robot y en la quinta y última parte,

para comprobar el correcto funcionamiento tanto del robot como de la simulación, se realiza una prueba de

control utilizando trayectorias articulares adquiridas mediante Arduino.

xi

Índice

Agradecimientos ix

Resumen x

Índice xi

Índice de Tablas xiii

1 INTRODUCCIÓN 11 1.1 Objetivo 11 1.2 Historia de la robótica humanoide. 12

2 ANATOMÍA Y BIOMECÁNICA DE LAS PIERNAS HUMANAS 17 2.1 Análisis anatómico. 17

2.1.1 Pelvis. 18 2.1.2 Cadera. 19 2.1.3 Pierna. 19 2.1.4 Rodilla. 20 2.1.5 Pie. 21 2.1.6 Tobillo. 21

2.2 Análisis biomecánico. 22 2.2.1 Rangos de movimiento. 22 2.2.2 Longitud, masa y centro de gravedad. 23 2.2.3 Inercias y momentos. 24

3 DISEÑO MECÁNICO 25 3.1 Particularización de los parámetros biomecánicos. 25 3.2 Elección de los actuadores. 27 3.3 Diseño en Catia V5. 29

3.3.1 Planteamiento. 29 3.3.2 Obtención del modelo 3D del motor a utilizar. 31 3.3.3 Diseño de la cadera. 33 3.3.4 Diseño de la rodilla. 36 3.3.5 Diseño del tobillo y pie. 37

3.4 Análisis del diseño. 39 3.4.1 Longitudes de los segmentos. 40 3.4.2 Masas y centros de masa. 41 3.4.3 Comparación. 43

4 INSERCIÓN DEL MODELO EN GAZEBO/ROS 44 4.1 Introducción a ROS. 44

4.1.1 Sistema de archivos. 45 4.1.2 Red de computacion. 45

4.2 Introducción a Gazebo. 46 4.3 URDF. 47

4.3.1 Estructura de un archivo URDF. 47 4.3.2 XACRO. 49

4.4 Programación de la descripción del robot. 50 4.4.1 Preparación de los archivos CAD. 51 4.4.2 Definición de variables. 51 4.4.3 Transformaciones entre sistemas de referencia. 52 4.4.4 Definición de macros. 53 4.4.5 Finalización del código. 55

4.5 Validación del archivo URDF. 55 4.6 Ejecución del código y visualización del robot en RVIZ. 55 4.7 Simulación del robot. 59

4.7.1 Conversión de URDF a SDF. 60 4.7.2 Preparación de la simulación. 60 4.7.3 Comprobación de resultados. 62

5 CONTROL DE LOS ACTUADORES 66 5.1 Ros_control. 66 5.2 Gazebo y ros_control. 67 5.3 Modificación del archivo URDF. 68 5.4 Creación de los controladores. 69 5.5 Ejecución de los controladores. 70 5.6 Calibración de los parámetros de los controladores. 71 5.7 Comrobación de la estabilidad del modelo en simulación. 76

6 OBTENCIÓN DE TRAYECTORIAS ARTICULARES Y SIMULACIÓN FINAL 77 6.1 Creación del dispositivo de medidas. 77 6.2 Calibración del dispositivo de medidas. 78 6.3 Comunicación Arduino – ROS. 79 6.4 Ejecución de la simulación y resultados obtenidos. 80

7 CONCLUSIONES 83

8 Bibliografía 84

ANEXO A PLANOS Y MEDIDAS 85 Vistas y medidas: 85 Vista en perspectiva: 86 Ensamblaje de la cadera I: 87 Ensamblaje de la cadera II: 88 Ensamblaje de la cadera III: 89 Ensamblaje de la rodilla: 90 Ensamblaje del tobillo: 91

ANEXO B CÓDIGOS 92 Código de configuración de los controladores: 92 Código de Arduino: 93

xiii

ÍNDICE DE TABLAS

Tabla 2-1: Rangos de movimiento de las articulaciones del miembro inferior. 22

Tabla 2-2: Características de las muestras utilizadas en diferentes estudios de biomecánica. 23

Tabla 2-3: Parámetros aportados por Dempster (1955) [1] y por Clauser et al. (1969) [2]

con la modificaciónhecha por Hinrichs (1960) [3] 24

Tabla 3-1: Comparación entre longitudes del diseño y teóricas. 43

Tabla 3-2: Comparación entre masas y centros de masa del diseño y teóricos. 43

1 INTRODUCCIÓN

rante los últimos años, el mundo de la robótica ha experimentado un enorme crecimiento

prácticamente en todos sus campos. Hoy en día no nos resulta extraño pensar en un asistente personal

dentro de nuestro teléfono, un robot que limpie nuestra casa, o incluso un coche que se conduzca solo.

Sin embargo, existe un campo de la robótica que todavía hoy muchos solo imaginan dentro de la ciencia

ficción, y es el de los robots humanoides. Aunque en los últimos años empresas como Boston Dynamics han

mostrado al mundo que este tipo de robots no están tan alejados en el futuro, lo cierto es que todavía queda

mucho camino que recorrer.

Teniendo esto presente, la motivación de este trabajo es doble. Por un lado, todo lo desarrollado servirá para

posteriormente construir un robot humanoide completo con el que poder realizar investigaciones más

avanzadas. Por otro, todo el conocimiento adquirido durante el proceso el cual será de gran ayuda durante el

futuro.

1.1 Objetivo

El objetivo de este trabajo es, como se ha comentado anteriormente, el diseño y simulación de la mitad inferior

de un robot humanoide. Más concretamente, se pretende conseguir lo siguiente:

• Un modelo en tres dimensiones, y con las proporciones adecuadas, de unas piernas robóticas que

serán utilizadas como parte de un robot humanoide completo.

• Una descripción completa del robot de manera que pueda ser integrada en ROS para su análisis y

control. Se programarán tanto las partes rígidas como las articulaciones, teniendo en cuenta las

características físicas del root y las especificaciones de sus actuadores.

• Un modelo del robot simulado en Gazebo con todos los parámetros necesarios para que la simulación

sea lo más realista posible. Además, debe poder controlarse dicho robot utilizando ROS, por lo que

deben establecerse las comunicaciones necesarias entre ambos programas.

• Un control de posición para cada actuador del robot, de forma que respondan de manera realista ante

una referencia angular.

• Un dispositivo (basado en Arduino) capaz de medir, con una precisión razonable, los ángulos de la

cadera, la rodilla y el tobillo de una persona real.

D

INTRODUCCIÓN

12

12

• Utilizando el dispositivo anterior, reproducir los movimientos de unas piernas en el robot en tiempo

real.

• Recoger las trayectorias articulares al caminar y replicarlas en el robot de manera que pueda andar (sin

control de estabilidad).

Como se indica en el último punto, el control que se realizará en las piernas no será un control de estabilidad

en bucle cerrado, sino que únicamente se replicarán en bucle abierto las referencias recogidas al caminar por el

dispositivo fabricado. Esto se utilizará como comprobación de que la simulación es correcta y fiable.

1.2 Historia de la robótica humanoide.

En 1973, los investigadores de la Universidad de Waseda completaban el que sería el primer robot humanoide

funcional, y a escala real, del mundo. EL WABOT-1, como lo llamaron, podía caminar, transportar objetos

con las manos, incluía sensores táctiles, sensores de distancia e incluso un sistema de comunicación por voz.

Ilustración 1-1: WABOT-1.

Años más tarde, en 1984, el WABOT-2 era presentado al mundo con un renovado aspecto y nuevas

habilidades entre las que se incluían poder tocar el piano.

13

Ilustración 1-2: WABOT-2.

Paralelamente, en 1986, Honda empezaría la que sería una de las investigaciones más importantes hasta la

fecha en este ámbito. Hablamos de la serie E de robots caminantes. Esta colección de robots semi-humanoides

creados por Honda entre los años 1986 y 1993, estuvo dedicada al estudio dinámico y la estabilidad durante la

marcha humana, logrando imitarla con muy buenos resultados.

Ilustración 1-3: Serie E de robots de Honda.

INTRODUCCIÓN

14

14

Después de la serie E, Honda continuó con la serie P entre 1993 y 2000. Esta nueva serie de robots ampliaba la

investigación ya no solo a la marcha humana, sino a todo el cuerpo. Añadieron a los robots brazos, torso y

cabeza con el objetivo de imitar completamente el cuerpo humano. Durante estos años otros robots fueron

desarrollados también como por ejemplo el robot Wabian en 1997.

Ilustración 1-4: Serie P de robots de Honda.

Tras la serie P, Honda finalmente lanza en 2001 el que sería el robot humanoide más avanzado del mundo

durante años, el ASIMO. Este robot supuso un antes y un después en el desarrollo de robots humanoides

debido a su avanzada tecnología y a sus movimientos muy realistas. Durante años, ASIMO viajó por todo el

mundo realizando exhibiciones de todo tipo ante grandes cantidades de público.

Ilustración 1-5: ASIMO durante una exhibición bajando unas escaleras.

15

Durante este tiempo, otras compañías además de Honda desarrollaron sus propios robots humanoides para

tratar de competir con ASIMO. Sony con su QRIO, o Toyota con su Partner son solo algunos ejemplos.

Ilustración 1-6: A la izquierda, QRIO de Sony. A la derecha, Partner de Toyota.

Las investigaciones y los avances continuaron hasta que, en la RoboCup1 de 2007, el robot Nao de Aldebaran

Robotics es presentado al mundo. Este robot supondría años más tarde una revolución en el mundo de la

robótica educativa al lanzar en 2011 su versión NextGen. El Nao NextGen, además de mejorar sus

prestaciones e incluir dos cámaras de alta resolución, liberaba todo el código fuente para que desarrolladores

de todo el mundo pudiesen utilizarlo. Esto ha supuesto que, desde 2011, más de 200 instituciones educativas

hayan adoptado este robot como método de aprendizaje.

Ilustración 1-7: Robot Nao en la RoboCup.

1 Robot Soccer World Cup, un concurso internacional de robótica en el que dos equipos de robots se enfrentan en un partido de futbol en miniatura.

INTRODUCCIÓN

16

16

Durante los siguientes años y hasta el día de hoy, han ido aumentando cada vez más las apuestas de

Universidades e Instituciones privadas por este tipo de tecnología. Prueba de ello es el DARPA Robotics

Challenge, un concurso de robótica organizado por DARPA (Defense Advances Desearch Projects Agency)

entre los años 2012 y 2015. El concurso, considerado como uno de los más exigentes que han existido,

requería a los participantes la construcción de un robot terrestre semiautónomo (no obligatoriamente

humanoide) que fuese capaz de realizar tareas complejas en ambientes hostiles.

Ilustración 1-8: Robots del DARPA Robotics Challenge en algunas de las pruebas.

Robots muy avanzados participaron durante los 4 años de concurso, pero sin duda el más significativo es el

robot Atlas de Boston Dynamics. Este robot es considerado por muchos como el robot humanoide más

avanzado hoy en día. Aunque su aspecto no es tan amigable como por ejemplo el de ASIMO, la movilidad que

presenta y el control sobre su cuerpo resultan extraordinarios, llegando hasta el punto de hacer saltos mortales

hacia atrás.

Ilustración 1-9: Robot Atlas de Boston Dynamics.

17

2 ANATOMÍA Y BIOMECÁNICA DE LAS

PIERNAS HUMANAS

l estudio anatómico y la obtención de ciertos parámetros que sirvan para definir, en mayor o menor

medida, la estructura y el funcionamiento de aquello que se toma como modelo, resulta primordial a la

hora de realizar un buen diseño bioinspirado. Datos como masas, longitudes, o rangos de movimiento

entre otros, pueden aportar una valiosa información que haga que el diseño mejore en calidad. Debido a esto,

el primer capítulo de este trabajo se centrará en eso mismo, el estudio de la anatomía de unas piernas humanas

y la obtención de ciertos parámetros biomecánicos que permitan posteriormente realizar un buen diseño.

2.1 Análisis anatómico.

El objetivo que se pretende alcanzar en este trabajo no es el de simular a la perfección la anatomía y

comportamiento de unas piernas reales, como podría ser por ejemplo el caso de una prótesis robótica. En su

lugar, nos centraremos en realizar un diseño fácil de construir y con las mismas capacidades en cuanto a

movilidad y desempeño que un ser humano promedio. Todo ello respetando las proporciones físicas que la

evolución ha ido desarrollando durante miles de años. Debido a esto, no se realizará un análisis anatómico en

profundidad, sino que únicamente se estudiaran los conceptos más importantes relacionados con la estructura

ósea, las articulaciones y los movimientos de la mitad inferior del cuerpo humano.

Como podemos ver en la Ilustración 2-1, se puede dividir la mitad inferior del cuerpo humano en tres partes:

pelvis, pierna2 y pie.

2 Aunque en anatomía se denomina pierna a la porción de la extremidad inferior comprendida entre la rodilla y el tobillo, para una mejor compresión en este documento llamaremos pierna al conjunto pierna-rodilla-muslo.

E

ANATOMÍA Y BIOMECÁNICA DE LAS PIERNAS HUMANAS

18

18

Ilustración 2-1: Partes de la mitad inferior del cuerpo humano.

A su vez, estas tres partes se encuentran interconectadas entre sí por medio de tres articulaciones principales: la

cadera, la rodilla y el tobillo.

2.1.1 Pelvis.

La pelvis se corresponde con la región anatómica inferior del tronco. Su estructura ósea está formada

principalmente por 3 huesos: sacro, cóccix, y coxal. Estos huesos, a su vez, se encuentran unidos entre sí por

medio de una serie de articulaciones entre las cuales destaca la articulación sacroilíaca. Esta articulación actúa

como nexo entre la mitad superior y la inferior del cuerpo, permitiendo un cierto grado de movilidad entre

ambas partes que ayuda a redistribuir el peso a la hora de realizar movimientos como el de caminar.

Ilustración 2-2: Pelvis masculina. Ilustración 2-3: Articulación sacroilíaca.

19

Como apuntan algunos estudios3, el diseño de una pelvis bioinspirada puede mejorar notablemente la manera

en la que camina un robot humanoide. Sin embargo, debido a que en este trabajo no se tendrá en cuenta la

mitad superior del cuerpo y, por lo tanto, el control de esta no será un factor clave, no se incluirá en el diseño

una pelvis de este tipo, limitándose únicamente a la cadera.

2.1.2 Cadera.

La articulación de la cadera es la encargada de conectar la pierna con la pelvis y, por tanto, con el resto del

cuerpo. Está formada por una superficie cóncava llamada acetábulo, que se encuentra situada en la pelvis, y

por otra convexa llamada cabeza femoral, perteneciente al fémur.

Ilustración 2-4: Articulación de la cadera.

Al tratarse de una unión de este tipo (cóncava-convexa), que en robótica se conoce como unión esférica, la

cadera proporciona a la pierna una movilidad de 3 g.d.l. Por lo tanto, la pierna puede realizar un total de 6

movimientos, contando como movimiento el desplazamiento en una dirección y un sentido. Estos

movimientos se denominan flexión, extensión, abducción, aducción, rotación interna y rotación externa.

2.1.3 Pierna.

La pierna constituye la parte del cuerpo que va desde la cadera hasta el tobillo. Su estructura ósea está

compuesta principalmente por el fémur, la tibia, el peroné y la articulación de la rodilla. Se encuentra unida a

la pelvis por medio de la articulación de la cadera y al pie por medio de la articulación del tobillo.

3 “Anthropomorphic Design of the Human-Like Walking Robot”, Ming-Hsun Chiang - Fan-Ren Chang. [8]


20

20

Ilustración 2-5: Estructura ósea de la pierna.

2.1.4 Rodilla.

El punto de unión entre el fémur y la tibia, y parte central de la pierna, se conoce como articulación de la

rodilla. En el ser humano, la rodilla es la articulación más grande del cuerpo y una de las más complejas.

Soporta casi todo el peso en posición erguida por lo que tiene una construcción muy firme.

Ilustración 2-6: Articulación de la rodilla.

La rodilla puede realizar principalmente los movimientos de flexión y extensión. En ciertas condiciones

también puede realizar movimientos de rotación, aunque estos no serán tenidos en cuenta para el diseño.

21

2.1.5 Pie.

El pie conforma la porción terminal de la pierna y soporta el peso completo del cuerpo. Como se muestra a

continuación, puede dividirse en tres partes: tarso, metatarso y falanges.

Ilustración 2-7: Estructura ósea del pie.

Aunque el pie tiene más de 30 articulaciones, la que resulta más interesante es la formada por los metatarsos y

las falanges. Esta articulación juega un papel muy importante en la marcha humana ya que permite que la parte

delantera del pie siga en contacto con el suelo aun cuando el talón ya ha sido despegado, aportando mayor

estabilidad durante el paso.

2.1.6 Tobillo.

El último elemento cuya anatomía analizaremos es el tobillo. Se trata de una de las articulaciones más estables

de la extremidad inferior. La articulación del tobillo la forman la tróclea astragalina y la mortaja tibioperonea.

La tróclea astragalina se encuentra, como su propio nombre indica, en el astrágalo mientras que la mortaja

tibioperonea es como se denomina a la unión que forman la tibia y el peroné en su parte inferior.

Ilustración 2-8: Articulación del tobillo.

Tarso

Metatarso

Falanges


22

22

Además de esta, existen un gran número de articulaciones más en los huesos del pie que le permiten realizar

movimientos de acomodación y reajuste durante la marcha. De entre todos los movimientos, destacan el de

eversión e inversión, que evitan que el peso del cuerpo caiga sobre uno de los laterales del pie basculando la

superficie de contacto de la planta y repartiendo así el peso.

Sin embargo, los movimientos más importantes que involucran al pie y los que comúnmente suelen

relacionarse con el tobillo son los de flexoextensión.

2.2 Análisis biomecánico.

Una vez realizado un análisis anatómico básico para comprender la estructura de las piernas humanas, el

siguiente paso consiste en el análisis de los parámetros que definen su cinemática y su dinámica. Parámetros

como la longitud, la proporción de masa y los centros de gravedad de cada enlace, los rangos de movimientos

de las articulaciones o los momentos de inercia resultan indispensables para un correcto diseño.

2.2.1 Rangos de movimiento.

El rango de movimiento de una articulación puede definirse como el ángulo máximo que es capaz de alcanzar

dicha articulación al realizar un movimiento determinado partiendo de una posición de reposo.

Los datos que se utilizarán para este trabajo son los recogidos por Donna C. Boone y Stanley P. Azen (1979).

Ambos realizaron una serie de mediciones a un total de 109 sujetos masculinos obteniendo los siguientes

resultados:

Movimiento Articulación Rango de movimiento [ º ]

Flexión Cadera 122.3 ± 6.1

Extensión Cadera 9.8 ± 6.8

Abducción Cadera 45.9 ± 9.3

Aducción Cadera 26.9 ± 4.1

Rotación interna Cadera 47.3 ± 6.0

Rotación externa Cadera 47.2 ± 6.3

Flexión Rodilla 142.5 ± 5.4

Flexión (plantar) Tobillo / Pie 56.2 ± 6.1

Extensión (dorsiflexión) Tobillo / Pie 12.6 ± 4.4

Inversión Tobillo / Pie 36.8 ± 4.5

Eversión Tobillo / Pie 20.7 ± 5.0

Tabla 2-1: Rangos de movimiento de las articulaciones del miembro inferior.

23

2.2.2 Longitud, masa y centro de gravedad.

Durante los últimos 50 años han sido muchos los estudios realizados en este campo con el fin de obtener este

tipo de parámetros. Algunos han sido más aceptados que otros, pero hoy en día no existe todavía un consenso

sobre qué estudio es el más adecuado. Esto se debe a las diferencias que existen entre los sujetos que unos

experimentos y otros utilizaron. La diferencia más notable que se da entre estos estudios es la utilización de

cadáveres o sujetos vivos para los experimentos, aunque también existen otras diferencias importantes como la

edad promedio. A continuación, en la Tabla 2-2, podemos ver una revisión de los diferentes estudios

realizados y las muestras que utilizaron.

Tabla 2-2: Características de las muestras utilizadas en diferentes estudios de biomecánica.

Autor Muestra Edad Sexo Peso Estatura

Dempster (1995) 8 cad 52-83 M 49-72 1.59-1.86

Barter (1957) 12 cad M

Drillis y Contini (1966) 20 vivo 20-40 M 76-86 1.67-1.88

Bernstein (1967) 152 vivo M/F

Clauser et al. (1969) 13 cad. 28-74 M 54-88 1.62-1.85

Chandler et al. (1975) 6 cad. 45-65 M 51-89 1.64-1.81

McConville et al. (1980) 31 vivo 22-33 M 59-104 1.62-1.94

Zatsiorsky y Seluyanov (1985) 100 vivo 19-35 M/F 55-91 1.68-1.80

Los estudios más utilizados suelen ser aquellos en los que se emplearon cadáveres como muestras debido a

que, aunque la muestra es más pequeña, la precisión de las mediciones es mayor. De todos ellos, los

parámetros más utilizados han sido los proporcionados por Clauster et al. (1969) debido a que analizó la

muestra más amplia de cadáveres y a que la edad media es menor.

Años más tarde, algunos inconvenientes de los parámetros de Clauser et al. (1969) fueron resueltos por

Hinrichs (1990). En concreto, el problema era que Clauser no había utilizado los centros de las articulaciones

como puntos de inicio y fin de los segmentos, como era de costumbre.

En este trabajo se utilizarán, para las masas y los centros de masa de los segmentos, los parámetros

proporcionados por Clauser et al. (1969) con la correspondiente revisión de Hinrichs (1990). Debido a que en

Clauser et al. (1969) no se proporciona información referente a la pelvis ni al conjunto cabeza-brazos-tronco4,

estos datos serán tomados del estudio realizado por Dempster (1995). Por otro lado, para las longitudes de los

segmentos, debido a que los estudios antes mencionados no incluyen estos datos se utilizarán los

proporcionados por Drillis y Contini (1966).

Los parámetros inerciales aportados por Clauser et al. (1969) junto con la revisión hecha por Hinrichs (1960) y

los parámetros de la pelvis recogidos por Dempster (1955) están recogidos5 en la Tabla 2-3. Por otro lado, la

Ilustración 2-9 representa las medidas de cada segmento tomadas por Drillis y Contini (1966).

4 Estos datos serán útiles en un posterior análisis de esfuerzos. 5 Únicamente se muestran los parámetros que se utilizarán en este trabajo. Los parámetros referidos al centro de masas están expresados en porcentajes de la longitud total del enlace comenzando por su punto proximal.


24

24

Segmento Masa CM

Cabeza-brazos-tronco 67.8 % 62.6%

Pelvis 14.2 % 10.5 %

Muslo 10.3 % 40.01 %

Pantorrilla 4.3 % 41.79 %

Pie 1.5 % 44.9 %

Tabla 2-3: Parámetros aportados por Dempster (1955) [1] y por Clauser et al. (1969) [2] con la modificación

hecha por Hinrichs (1960) [3]

Ilustración 2-9: Longitudes aportadas por Drillins y Contini (1966) [1]

2.2.3 Inercias y momentos.

Llegados a este punto, es posible realizar con los datos obtenidos un modelo simplificado que incluya

longitudes, masas y centros de gravedad. Sin embargo, para una correcta elección de los actuadores, es

necesario obtener datos sobre inercias y momentos que soportarán las articulaciones del modelo. Existen

numerosos estudios que tratan estos temas en el cuerpo humano, calculando la inercia de cada extremidad y

los momentos y fuerzas que se ejercen sobre cada articulación. Sin embargo, estos datos no suelen ser

generalizados y no se dan en relación a otras magnitudes como la masa. Por el contario, suelen ser estudios

particularizados para un único sujeto con resultados absolutos. Debido a esto, resulta mucho más lógico y

adecuado calcular dichas variables para el modelo obtenido aquí. Los cálculos se realizarán en el siguiente

capítulo destinado al diseño.

25

3 DISEÑO MECÁNICO

l tercer capítulo de este trabajo estará dedicado al diseño mecánico. El capitulo está dividido en varias

partes, siendo cada parte una etapa del diseño. En la primera sección se particularizarán los datos

recogidos en el capítulo segundo para cumplir con los requisitos de diseño, en la segunda se calcularán

los momentos que tendrán que ejercer los actuadores que llevará el robot para así poder escoger unos motores

adecuados, la tercera sección estará dedicada al diseño en Catia V5 del robot y la cuarta y última sección estará

enfocada hacia el análisis del modelo diseñado y la recolección de datos.

Antes de comenzar con las secciones, conviene repasar los requisitos inicialmente propuestos que deberá

cumplir el diseño del robot:

• Altura total del robot (incluyendo la mitad superior) de 90 cm.

• Peso total del robot (incluyendo la mitad superior) de 4,5 kg.

• Materiales de construcción:

o Para los huesos, varillas de aluminio de perfil circular hueco de 8 mm de diámetro exterior y

6 mm de diámetro interior.

o Para las articulaciones, planchas de aluminio de 2 mm de espesor.

3.1 Particularización de los parámetros biomecánicos.

En primer lugar, dado que los datos recogidos en el capitulo anterior eran relativos a la masa y la altura total

del individuo, es necesario particularizarlos para cumplir con los requisitos establecidos.

Atendiendo a la Ilustración 2-9 y, sabiendo que la altura total H es de 90 cm, obtenemos las siguientes

longitudes para los segmentos del diseño:

E

DISEÑO MECÁNICO

26

26

• Ancho de la pelvis (distancia entre piernas): 0.191 ∗ 0.9 = 0.172 𝑚

• Cadera-Hombro6: (0.818 − 0.530) ∗ 0.9 = 0.259 𝑚

• Muslo: (0.530 − 0.285) ∗ 0.9 = 0.220 𝑚

• Pantorrilla: (0.285 − 0.039) ∗ 0.9 = 0.221 𝑚

• Alto del pie (distancia del tobillo al suelo): 0.039 ∗ 0.9 = 0.035 m

• Largo del pie: 0.152 ∗ 0.9 = 0.1369 𝑚

• Ancho del pie: 0.055 ∗ 0.9 = 0.049 𝑚

Una vez calculadas las longitudes de los segmentos, podemos calcular la posición de los centros de masa

correspondientes a cada uno7 con los datos de la Tabla 2-3:

• Cabeza-brazos-tronco: 0.626 ∗ 0.2592 = 0.16622 𝑚 comenzando en la cadera.

• Muslo: 0.4001 ∗ 0.2205 = 0.0882 𝑚 comenzando en la cadera.

• Pantorrilla: 0.4179 ∗ 0.2214 = 0.09252 𝑚 comenzando en la rodilla.

• Pie: 0.4490 ∗ 0.1369 = 0.0614 𝑚 comenzando en el talón.

Por último, nuevamente con la ayuda de los datos de la Tabla 2-3, y sabiendo que el peso total del robot debe

ser de 4.5 Kg, se calcularán las masas de cada elemento:

• Cabeza-brazos-tronco: 0.678 ∗ 4.5 = 3.051 𝐾𝑔

• Muslo: 0.103 ∗ 4.5 = 0.463 𝐾𝑔

• Pantorrilla: 0.043 ∗ 4.5 = 0.193 𝐾𝑔

• Pie: 0.015 ∗ 4.5 = 0.067 𝐾𝑔

Puede comprobarse la coherencia de los datos entre sí realizando una simple suma de la masa correspondiente

a la mitad superior con la masa correspondiente a una pierna multiplicada por dos:

𝑚𝑖𝑡𝑎𝑑 𝑠𝑢𝑝𝑒𝑟𝑖𝑜𝑟 + 2 ∗ (𝑚𝑢𝑠𝑙𝑜 + 𝑝𝑎𝑛𝑡𝑜𝑟𝑟𝑖𝑙𝑙𝑎 + 𝑝𝑖𝑒) = 𝑝𝑒𝑠𝑜 𝑡𝑜𝑡𝑎𝑙

En efecto, si realizamos el cálculo comprobamos que el error es de tan solo tres gramos:

3.051 + 2 ∗ (0.463 + 0.193 + 0.067) = 4.497 𝐾𝑔

6 Esta longitud es necesaria debido a que el centro de gravedad del conjunto cabeza-brazos-tronco está expresado relativo a esta medida. 7 La masa y el centro de masas correspondientes a la pelvis no serán calculados por incluir ya el conjunto cabeza-brazos-tronco a la pelvis.

27

3.2 Elección de los actuadores.

Antes de comenzar a diseñar es preciso conocer qué actuadores se van a utilizar para así poder realizar un

diseño lo más preciso posible.

En este caso, los actuadores que se utilizarán serán servomotores. Se utilizarán servomotores y no motores de

corriente continua para eliminar la capa de control de los actuadores. De esta forma, aunque en este trabajo no

se tratará, será posible centrarse en el diseño de controles a más alto nivel sin tener que preocuparse por el

control a nivel de actuador.

Uno de los mayores problemas que se pueden presentar a la hora de controlar el robot, es que los actuadores

no tengan la fuerza suficiente para realizar los movimientos que se les exigen. Debido a esto, para la correcta

elección de los servomotores, se realizará un pequeño análisis para comprobar los esfuerzos máximos que un

actuador tendría que ejercer para mantener unas posiciones extremas determinadas. En concreto, las posiciones

elegidas han sido una pierna flexionada completamente, ya que este será el mayor peso estático que el motor

de la cadera tendrá que soportar, y las rodillas flexionadas a 90º con el centro de masa de la parte superior a

45º, debido a que es una postura típica en la que se carga con la mayor parte del peso del cuerpo humano.

Comenzaremos analizando el caso de la pierna completamente extendida. En la Ilustración 3-1 se muestra un

esquema con las longitudes, masas y fuerzas del problema. Se supondrá un motor por articulación con un peso

de 125g, y con fuerza suficiente para mantener el resto de la pierna recta.

La única fuerza que se ejerce sobre toda la pierna es la fuerza de la gravedad, por lo tanto, haciendo el

sumatorio de momentos igual a cero obtendremos el momento que el motor de la cadera tendría que soportar

para mantener la pierna en esta postura:

∑𝑇 = 0 → ∑𝐹 ∗ 𝑥 = 0

𝑀 = 9.81 ∗ (0.463 ∗ 0.088 + 0.150 ∗ 0.220 + 0.193 ∗ 0.312 + 0.150 ∗ 0.441 + 0.067 ∗ 0.476 )

𝑀 = 2.2759 𝑁𝑚

Ilustración 3-1: Análisis de postura I

DISEÑO MECÁNICO

28

28

El segundo caso simula un movimiento típico en el día a día de una persona, levantarse. Al levantarnos

elevamos casi todo el peso del cuerpo con ayuda de las rodillas por lo que es uno de los momentos donde más

podría sufrir un actuador.

En primer lugar, calculamos la distancia del centro de masa al punto de giro:

𝑑 = cos(45) ∗ 0.166 = 0.117 𝑚

Y seguidamente aplicamos las mismas ecuaciones que en el caso anterior obteniendo:

𝑀 = 9.81 ∗ (0.463 ∗ 0.132 + 0.150 ∗ 0.220 + 3.051 ∗ 0.117)

𝑀 = 4.425 𝑁𝑚

Ilustración 3-2: Análisis de postura II.

Tras realizar una búsqueda de posibles servomotores que cumplan con los requisitos calculados, el que

finalmente será utilizado para las pruebas es el HerculeX DRS-0402 de DTS Robot.

El par máximo que este servomotor puede ejercer estáticamente (stall torque) es de hasta 5.099 Nm, por lo que

resulta adecuado para el diseño del robot. A continuación podemos ver una captura de la hoja de características

proporcionada por el fabricante:

29

Ilustración 3-3: Hoja de características del HerculeX DRS-042.

3.3 Diseño en Catia V5.

Para realizar el diseño se utilizará el programa CatiaV5. El proceso seguido a la hora de diseñar el mecanismo

puede dividirse en 5 etapas:

3.3.1 Planteamiento.

Es necesario tener en cuenta una serie de cosas antes de ponerse a diseñar en Catia.

La primera de ellas está relacionada con los materiales que se utilizarán para la construcción del robot. Como

se mencionó en la introducción del capítulo, el robot se construirá casi en su totalidad con planchas de

aluminio (a excepción del fémur y la tibia), por lo que todas las piezas que se diseñen deben poder fabricarse a

partir de ellas. Sabiendo esto, las piezas estarán diseñadas de tal forma que puedan ser construidas únicamente

doblando una plancha previamente cortada según las medidas. De esta forma se facilitará el trabajo de

construcción.

Para poder diseñar las piezas de esta forma, se utilizará el entorno de trabajo de CatiaV5 llamado Generative

Sheetmetal Design. Este entorno permite realizar diseños orientados a la fabricación utilizando planchas de

metal, ofreciendo múltiples herramientas como el “desdoblado” de la pieza para observar lo que se debería

cortar en la plancha. A continuación se puede ver cómo sería una pieza creada en este entorno tanto doblada

como desdoblada.

DISEÑO MECÁNICO

30

30

Ilustración 3-4: Pieza diseñada en Generative Sheetmetal Design (versión doblada).

Ilustración 3-5: Pieza diseñada en Generative Sheetmetal Design (versión desdoblada).

Otro punto a tener en cuenta a la hora de realizar el diseño es la minimización de las fuerzas sobre los ejes de

los motores. Debido a que este mecanismo estará sometido a múltiples fuerzas, es necesario diseñar pensando

en la distribución de estas para evitar así daños en los actuadores. Los actuadores están pensados para que

apliquen un par de rotación sobre un eje en particular y así permitir un movimiento. Idealmente, un actuador

debe estar sometido únicamente a un par debido al propio peso de lo que quiere rotar. Sin embargo, debido a

las fuerzas de reacción del suelo y al peso en sí del mecanismo, el eje del motor puede verse sometido a

fuerzas perpendiculares a este que lo dañen. La solución a esto será el diseño de unos “frames” que junto con

unos cojinetes absorban las fuerzas perpendiculares a los ejes redistribuyéndolas al chasis del robot.

Los cojinetes utilizados serán los EFOM-08 y EFSM-08 de Igus. A continuación puede verse el modelo 3D de

dichos cojinetes proporcionado por el fabricante.

31

Ilustración 3-6: EFOM-08

Ilustración 3-7: EFSM-08

Por último, se tratará el tema de los grados de libertad. Como se vio en el Capítulo 2, cada articulación de la

pierna tiene una serie de movimientos y por tanto grados de libertad. El robot que se pretende diseñar en este

trabajo dispondrá de tres grados de libertad para la cadera, uno para la rodilla y uno para el tobillo. Teniendo

en cuenta esto, el robot estará conformado por un total de 10 motores contando ambas piernas.

Cabe destacar que, aunque no se replicarán los movimientos de eversión e inversión, sí se permitirá que el pie

los realice utilizando los cojinetes. Esto se explicará con más detalle más adelante.

3.3.2 Obtención del modelo 3D del motor a utilizar.

En primer lugar, es necesario obtener un modelo tridimensional del motor que se utilizará. Para ello, el

fabricante del motor, DST robot, proporciona en su página web los archivos de este modelo en 2 formatos: .igs

y .stp. Aunque estos formatos son aceptados por Catia, muchas de las herramientas que se utilizan para el

diseño no pueden utilizarse en formatos de este estilo. Es por eso por lo que primero será necesario cambiar el

formato a catPART, el formato por defecto de CatiaV5. Para ello, simplemente abrimos el archivo en CatiaV5

y lo guardamos como catPART. Catia se encargará de hacer las conversiones necesarias.

DISEÑO MECÁNICO

32

32

Ilustración 3-8: Modelo 3D del motor HerculeX DRS-0402

Como posteriormente se realizarán análisis de inercia y peso en el mecanismo, es importante que la masa del

modelo del motor sea correcta. Observando la hoja de datos del motor que el fabricante proporciona, vemos

que el peso del motor es de 125 g. Utilizando la herramienta Measure Inertia de Catia comprobamos que el

peso del modelo es de tan solo 66 g (Ilustración 3-9) por lo que es necesario modificarlo.

Ilustración 3-9: Propiedades físicas del modelo original.

Catia calcula la masa de un modelo 3D en base a su volumen y a su densidad y la densidad de un modelo es un

parámetro que se define en el material de dicho modelo. En este caso, como el material es desconocido, Catia

aplica una densidad por defecto de 1000 Kg/m3.

Para poder obtener una masa de 125 g, se ha creado un material con las mismas características que el plástico

(datos proporcionados por Catia), pero con una densidad de 1890 Kg/m obteniendo los siguientes resultados.

33

Ilustración 3-10: Propiedades físicas del modelo modificado.

3.3.3 Diseño de la cadera.

El diseño que se ha realizado para la cadera es el que se muestra a continuación:

Ilustración 3-11: Diseño cadera (perspectiva).

DISEÑO MECÁNICO

34

34

Hay varios aspectos a tener en cuenta en este diseño:

Al ser la cadera/pelvis el elemento más grande del robot, es también el que más espacio ofrece por lo que

pueden incluirse elementos como los soportes de distribución de fuerzas mencionados anteriormente. Se han

diseñado sistemas de soporte para dos de los 3 motores de la cadera, el de extensión y el de abducción. No se

ha creído necesario añadir un tercer soporte debido a que el motor de rotación está colocado de tal forma que

las fuerzas que sobre él se ejercerán son en la dirección de su eje, por lo que no son tan dañinas como las de los

demás motores. En las siguientes imágenes se pueden ver con más detalle dichos soportes.

Ilustración 3-12: Soporte eje extensión (en verde)

Ilustración 3-13: Soporte eje abducción (en rojo)

35

Por otro lado, para que los movimientos de la cadera sean coherentes y las fuerzas se repartan correctamente,

es muy importante que los tres ejes de los motores intersecten entre sí. El punto de intersección será el origen

de coordenadas de la cadera y respecto a él se realizarán todos los movimientos. Debido a esto, se ha tenido

especial cuidado en realizar el diseño de tal forma que el origen se encuentre en el punto correcto. En la

Ilustración 3-14 se puede ver una representación del mismo.

Ilustración 3-14: Origen de coordenadas de la cadera.

Para una mayor comprensión del diseño, a continuación se muestran las vistas de alzado, planta y perfil.

Ilustración 3-15: Vista en planta de la cadera.

DISEÑO MECÁNICO

36

36

Ilustración 3-16: Vista en alzado de la cadera. Ilustración 3-17: Vista de perfil de la cadera.

3.3.4 Diseño de la rodilla.

Una vez visto el diseño de la cadera pasamos al de la rodilla. En la Ilustración 3-18 puede verse el diseño que

se ha realizado.

Ilustración 3-18: Diseño rodilla.

37

Como puede apreciarse, en este caso no se ha podido realizar el diseño aislando al eje de cargas axiales debido

a las limitaciones de tamaño de la articulación.

El punto en el que termina el muslo y comienza la pantorrilla se corresponde al punto donde el eje del fémur

intersecciona con el eje de rotación del motor de la rodilla. A continuación puede verse una imagen de la

rodilla flexionada, separando la parte correspondiente al muslo (verde) de la parte correspondiente a la

pantorrilla (rojo).

Ilustración 3-19: Rodilla flexionada.

3.3.5 Diseño del tobillo y pie.

Para finalizar, analizaremos el diseño realizado para el tobillo y el pie.

El diseño del pie se ha realizado tomando como modelo la geometría básica de un pie real (más ancho por la

punta que por el talón). Aunque el pie es una parte del cuerpo con una gran multitud de movimientos, en

especial el de las falanges como se vio en el capítulo 2, en este caso se ha optado por simplificar el diseño y

realizar un pie de una sola pieza. El diseño puede verse en la Ilustración 3-20.

Ilustración 3-20: Diseño del pie.

DISEÑO MECÁNICO

38

38

Por otro lado, para el diseño del tobillo se ha seguido el mismo procedimiento que para el de la rodilla, siendo

ambos prácticamente iguales. Al igual que en la rodilla, el punto donde termina la tibia está situado en la

intersección entre el eje de la tibia y el eje del motor del tobillo. A continuación puede verse una imagen del

diseño incluyendo el pie.

Ilustración 3-21: Diseño tobillo.

El único punto diferenciable entre la rodilla y el tobillo se encuentra en el cojinete sobre el que se sustenta la

tibia. Este cojinete cumple la función de permitir al pie adaptarse a la pisada al igual que un pie real se adapta

con movimientos como los de eversión e inversión.

En el caso del pie diseñado para este robot, al ser completamente rígido y plano, si se quisiera apoyar el peso

del cuerpo sobre él cuando existe un cierto ángulo entre el suelo y la planta (ángulo de abducción), el apoyo no

sería completo quedando solo un borde en contacto con el suelo. Colocando los cojinetes como se muestra en

la imagen se soluciona el problema ya que, como se mencionó anteriormente, estos cojinetes permiten un

cierto grado de movilidad entre su soporte y el eje conectado a el. De esta forma, en el mismo caso

anteriormente propuesto el pie con cojinete podría girar realizando un movimiento de eversión o anteversión

para poder apoyar toda la planta en el suelo.

39

3.4 Análisis del diseño.

Para finalizar el presente capítulo, se analizará el diseño creado con la ayuda de las herramientas de medición

de CatiaV5 para comprobar hasta qué punto se han replicado los datos obtenidos en el apartado 3.1.

Los datos correspondientes a las longitudes se tomarán utilizando los puntos inicial y final mencionados

anteriormente mientras que para los datos de masas y centros de masas se utilizará la división de segmentos de

la Ilustración 3-22.

Ilustración 3-22: Separación de segmentos (rojo - muslo, verde - pantorrilla, azul-pie)

DISEÑO MECÁNICO

40

40

3.4.1 Longitudes de los segmentos.

Como puede verse en la Ilustración 3-23 y la Ilustración 3-24, las longitudes del diseño son prácticamente

exactas a excepción de una. El ancho de la pelvis, es decir la longitud entre piernas es considerablemente

mayor a lo que se calculó. Esto se debe a que físicamente es imposible disminuir esta distancia sin renunciar a

los cojinetes. Debido a esto, se ha priorizado la distribución de fuerzas al cumplimiento de esta longitud ya que

la segunda no supone ninguna diferencia notable mientras que la primera si.

Ilustración 3-23: Longitudes diseño I.

41

Ilustración 3-24: Longitudes diseño II.

3.4.2 Masas y centros de masa.

En segundo lugar, se analizarán las masas y los centros de masa8 de cada segmento comenzando con el muslo.

Ilustración 3-25: Masa y centro de masa del muslo.

8 Las coordenadas del centro de masa de cada segmento están dadas respecto del centro total del robot, que se encuentra en el punto medio de la pelvis (entre los dos motores de extensión).

DISEÑO MECÁNICO

42

42

Ilustración 3-26: Masa y centro de masa de la pantorrilla.

Ilustración 3-27: Masa y centro de masa del pie

43

3.4.3 Comparación.

A continuación en las Tablas 3-1 y 3-2 se puede ver una comparación entre los valores teóricos y los valores

del diseño:

m Distancia entre

piernas

Longitud

muslo

Longitud

pantorrilla

Alto

pie

Largo

pie

Ancho

pie

Teórico 0.172 0.220 0.221 0.035 0.1369 0.0495

Diseño 0.206 0.220 0.221 0.035 0.1369 0.0495

Tabla 3-1: Comparación entre longitudes del diseño y teóricas.

Kg | m Masa

muslo

Masa

pantorrilla

Masa

pie

Centro de

masas muslo

Centro de masas

pantorrilla

Centro de

masas pie

Teórico 0.463 0.193 0.067 0.088 0.092 0.061

Diseño 0.413 0.065 0.043 0.006 0.113 0.078

Tabla 3-2: Comparación entre masas y centros de masa del diseño y teóricos.

Como se explicó anteriormente, los valores de las longitudes coinciden en su totalidad con los teóricos a

excepción de la distancia entre piernas. En cuanto a las masas, se puede observar que los valores son algo

diferentes, sin embargo, son bastante aproximados y están por encima del valor teórico lo que resulta positivo

para el diseño. Por último, los centros de masas son también aproximados a excepción del centro de masas del

muslo. Este se encuentra bastante más cerca de la cadera de lo que indica el valor teórico. Sin embargo, esto

también resulta positivo para el diseño ya que el centro de masas está mas cerca del eje de rotación lo que

significa que el motor tiene que ejercer menos par para moverla.

Para una mayor comprensión del diseño, pueden consultarse los planos adjuntos en el Anexo A.

INSERCIÓN DEL MODELO EN GAZEBO/ROS

44

44

4 INSERCIÓN DEL MODELO EN

GAZEBO/ROS

ras obtener datos tanto anatómicos como biomecánicos de unas piernas reales y diseñar un modelo CAD

del mecanismo, el siguiente paso es configurar dicho modelo y convertirlo en un robot funcional el cual

pueda recibir referencias de posición en sus actuadores y moverse en concordancia a dichas referencias.

Para lograr esto, se utilizará el entorno de programación de robots ROS, el cual es ampliamente conocido y

utilizado en el mundo de la robótica para describir y controlar sistemas robóticos complejos. Una vez se haya

programado la descripción del robot, es necesario disponer de un entorno de simulación realista para poder

llevar a cabo diferentes pruebas. Este entorno simulará el comportamiento que tendría el robot en el mundo

real proporcionando realimentación a ROS para el control. El entorno que se utilizará será Gazebo ya que,

además de sus muchas ventajas y funcionalidades a la hora de realizar simulaciones, es capaz de comunicarse

con ROS de manera sencilla.

A continuación se detallan los pasos seguidos para crear, partiendo del modelo CAD diseñado, un robot que

pueda ser controlado mediante ROS. Posteriormente, se realizarán las configuraciones necesarias para que

dicho robot pueda ser simulado en Gazebo de la manera más realista posible.

4.1 Introducción a ROS.

ROS (Robot Operating System) es un meta-sistema operativo de código abierto para robots, el cual

proporciona al usuario muchos de los servicios que podrían esperarse de un sistema operativo común

(abstracción hardware, control de dispositivos a bajo nivel, paso de mensajes entre procesos, manejo de

paquetes etc). De esta forma, ROS ofrece al desarrollador un marco de trabajo perfecto para descargar,

organizar, escribir y ejecutar códigos que implementen funcionalidades en nuestro sistema. Esto, sumado a la

amplia comunidad de desarrollo y al repositorio de paquetes que tiene, hacen de ROS un entorno ideal para

simplificar y organizar un sistema robótico complejo como puede ser el de este trabajo.

Ilustración 4-1: Logotipo de ROS.

T

45

4.1.1 Sistema de archivos.

Dado que ROS es un meta-sistema operativo, cuenta con su propio sistema de archivos que a su vez está

formado por varias entidades:

• Paquetes: es la unidad principal de organización de software en ROS. Cada paquete contiene una serie

de códigos cuya funcionalidad puede ir desde la ejecución de determinados procesos (nodos) hasta la

recopilación de librerías o archivos de configuración. En esencia, un paquete agrupa una serie de

archivos que quieren compartirse de manera conjunta.

• Metapaquetes: los metapaquetes son simplemente colecciones de paquetes que suelen utilizarse en

común. Es una manera de compartir código más eficientemente.

• Manifiesto de paquete: proporciona información acerca de un paquete, incluyendo su nombre,

versión, descripción, autor, dependencias de otros paquetes etc.

• Repositorios: colecciones de paquetes accesibles mediante internet para la descarga de código.

• Tipos de mensajes: archivos donde se define la estructura de un mensaje enviado en ROS.

• Tipos de servicios: archivos donde se define cómo será la petición y la respuesta en una comunicación

cliente servidor en ROS.

4.1.2 Red de computacion.

Se llama red de computación a la red formada por la interconexión de todos procesos que actúan en ROS

conjuntamente. Los conceptos relacionados con la red de computación son:

• Nodo: un proceso ejecutado bajo ROS es un nodo. Gracias a los nodos, aplicaciones muy complejas,

como por ejemplo el control de un robot móvil, pueden ser subdivididas en una serie de nodos

interconectados entre sí donde cada nodo realiza una tarea determinada. Para el caso del robot móvil,

en lugar de tener un solo proceso que se encargue de todo, podría tenerse un nodo encargado del

manejo de los actuadores, otro encargado de la odometría etc.

• Máster: el máster de ROS es el nodo encargado de organizar todos los demás nodos que se ejecuten,

proporcionando una serie de servicios que permiten a los nodos encontrarse e interactuar entre sí.

• Servidor de parámetros: se trata de una “memoria” que almacena parámetros accesibles por todos los

nodos.

• Mensajes: los nodos se comunican entre sí enviándose mensajes. Un mensaje es una estructura de

datos definida en un archivo de tipo de mensaje. Algunos tipos de mensaje predefinidos son integer,

floating point o boolean.

• Topics: los nodos se comunican entre sí mediante mensajes, pero el sistema de comunicación

mediante el cual se envían esos mensajes se denomina topic. La forma de interacción entre nodos y

topics, sigue una estructura de publicadores y suscriptores. Un nodo cualquiera puede publicar

mensajes en un topic, los cuales serán recogidos por todos aquellos nodos que estén suscritos a ese

topic. En un topic pueden publicar múltiples nodos y a un topic pueden suscribirse múltiples nodos

también. Cada topic está definido por un tipo de mensaje y todos los mensajes publicados en él tienen

que ser de ese tipo.

• Servicios: algunas veces a un nodo no le basta con recibir o proporcionar una información, sino que

necesita de una interacción más directa, una del tipo petición-respuesta. Cuando se requiere de algo

así, el concepto de topic no es suficiente, por eso se introduce el concepto de servicio. Un servicio es

un modelo de mensaje petición-respuesta definido en un archivo de tipo de servicio. En concreto, un

tipo de servicio se define mediante un par de tipos de mensajes (uno para la petición y otro para la

respuesta). Un nodo implementado con un servicio ofrece a los demás nodos este servicio bajo un

nombre. De este modo, un nodo que requiera de ese servicio puede actuar como cliente y mandar una

petición, recibiendo después la respuesta por parte del nodo que ofrecía el servicio.

• Bags: son los archivos utilizados en ROS para guardar y reproducir mensajes enviados.


46

46

Ilustración 4-2: Ejemplo de red de computación ROS [4]

4.2 Introducción a Gazebo.

Gazebo es un simulador gratuito utilizado ampliamente en el mundo de la robótica para realizar simulaciones

físicas y probar algoritmos, controles y demás funcionalidades directamente en un ordenador. Incluye una gran

variedad de características y herramientas que permiten realizar simulaciones de gran calidad. Además,

dispone de su propio sistema de archivos y formatos para describir todo lo necesario en una simulación, desde

las físicas del mundo hasta un robot. Por otro lado, también ofrece soporte para trabajar con ROS, por lo que se

puede diseñar un sistema completamente basado en ROS y comprobar su funcionamiento en Gazebo.

En el entorno de simulación Gazebo existen varios elementos a tener en cuenta:

• Archivos world: contienen todos los elementos de la simulación, incluyendo robots, luces, sensores, y

objetos estáticos.

• Archivos model: contienen la descripción de un único modelo de robot. Los robots pueden definirse

en archivos world o en archivos model, que luego serán incluidos en el archivo world.

• Variables de entorno: son una serie de variables que Gazebo usa para localizar archivos en el sistema.

• Gazebo server: es el encargado de recoger los datos del archivo world y realizar la simulación.

• Gazebo client: recoge los datos generados por el server y los muestra por pantalla. También funciona

como interfaz de comunicación para controlar la simulación.

• Plugins: son códigos que proporcionan una manera de interactuar con la simulación.

Ilustración 4-3: Logotipo de Gazebo.

47

4.3 URDF.

El sistema estándar de descripción de robot en ROS es mediante archivos URDF. URDF, o Universal Robot

Description Format, es un conjunto de paquetes de ROS que implementan un lenguaje basado en XML

utilizado para describir robots, sensores, escenas etc. En la Ilustración 4-4 puede verse la estructura de

paquetes que conforman URDF y su relación entre ellos.

Ilustración 4-4: Estructura de paquetes de URDF. [5]

Además del lenguaje, URDF también proporciona una serie de herramientas muy útiles para verificar,

visualizar y programar código más eficientemente. Dichas herramientas serán explicadas y utilizadas

posteriormente.

4.3.1 Estructura de un archivo URDF.

Los elementos básicos para describir un robot utilizando URDF son:

i. Links: Describen un elemento o parte del robot. A su vez, un link está compuesto por:

o Name: utilizado para identificar cada link.

o Visual: descripción visual del link. Se utiliza a la hora de representar el robot, pero

únicamente a nivel visual, no es tratado como algo físico por ROS. Pueden utilizarse

archivos CAD para definir la geometría.

o Collision: descripción física del link. Es la descripción que ROS interpreta como real y la que

interaccionará con otros elementos a nivel físico. Pueden utilizarse archivos CAD para definir

la geometría.

o Inertial: descripcion de las propiedades físicas del link (masa y momentos de inercia).


48

48

Ilustración 4-5: Representación gráfica de la estructura de un link. [6]

A continuación podemos ver cómo sería el código de descripción de un link cualquiera.

<link name="my_link">

<inertial>

<origin xyz="0 0 0.5" rpy="0 0 0"/>

<mass value="1"/>

<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />

</inertial>

<visual>

<origin xyz="0 0 0" rpy="0 0 0" />

<geometry>

<box size="1 1 1" />

</geometry>

</visual>

<collision>

<origin xyz="0 0 0" rpy="0 0 0"/>

<geometry>

<cylinder radius="1" length="0.5"/>

</geometry>

</collision>

</link>

ii. Joints: Describen la unión entre un link y otro. Los parámetros más significativos que definen una

joint son:

o Name: utilizado para diferenciar cada joint.

o Type: tipo de articulación. Pueden ser:

▪ Revolute.

▪ Continuous.

▪ Prismatic.

▪ Fixed.

▪ Floating.

▪ Planar.

o Origin: localización de la joint con referencia al sistema de coordenadas del link parent.

o Parent: link que ocupará un nivel superior en el árbol de descripción.

o Child: link que colgará del parent en el árbol de descripción.

49

o Axis: eje sobre el cual actúa la articulación (eje de rotación para rotacionales y de traslación

para prismáticas).

Ilustración 4-6: Representación gráfica de la estructura de una joint. [7]

Por lo tanto, podemos decir que describir un robot en URDF es, básicamente, definir los links que lo

componen y las joints que lo gobiernan. Además de esto existen muchas otras consideraciones y etiquetas que

pueden utilizarse sin embargo, para no extender en exceso la explicación, no se detallarán.

A continuación se puede ver cómo sería el código de descripción de una joint cualquiera.

<joint name="my_joint" type="floating">

<origin xyz="0 0 1" rpy="0 0 3.1416"/>

<parent link="link1"/>

<child link="link2"/>

<calibration rising="0.0"/>

<dynamics damping="0.0" friction="0.0"/>

<limit effort="30" velocity="1.0" lower="-2.2" upper="0.7" />

</joint>

4.3.2 XACRO.

Sabiendo que es necesario describir cada link y cada articulación del robot (las uniones rígidas también se

consideran articulaciones), es inevitable pensar en el arduo trabajo que supondría describir todos los elementos

del robot que se pretende crear. En total, teniendo en cuenta que hay 19 piezas por cada pierna, sería necesario

escribir el código anterior 38 veces solo para describir las partes.

Para facilitar el trabajo y agilizar el proceso, se hará uso del lenguaje de macros incluido en el paquete URDF

llamado XACRO. Este lenguaje se integra con URDF permitiendo definir variables, realizar operaciones

matemáticas sencillas y, lo más importante, definir macros de código todo dentro del mismo archivo de

descripcion URDF.

Por ejemplo, para definir una variable llamada masa que contenga el valor de la masa de un elemento, habría

que escribir dentro del archivo URDF lo siguiente:

<xacro:property name="masa " value="2.1" />


50

50

Una vez hecho esto, podrá referenciarse dicha variable en cualquier parte del documento únicamente

escribiendo ${masa}.

Sin embargo, la funcionalidad que más nos interesa es la de poder crear macros de código parametrizables.

Una macro parametrizable podría ser por ejemplo la siguiente:

<xacro:macro name="crea_joint" params="name axis tipo">

<joint name="${name}" type="${tipo}">

<axis xyz="${axis}" />

</joint>

</xacro:macro>

Para ejecutar la macro, el código que se tendría que escribir sería:

<xacro:crea_joint name="joint1" axis="1 0 0" tipo="continuous" />

Obteniendo como resultado final:

<joint name="joint1" type="continuous">

<axis xyz="1 0 0" />

</joint>

Utilizando estas herramientas es posible reducir considerablemente el número de líneas programadas y, por lo

tanto, el esfuerzo al programarlas. La estrategia que se seguirá consiste en crear una macro parametrizada que,

según sea la pierna izquierda o la derecha, cree los links y las joints necesarias. Una vez hecho esto,

únicamente habrá que llamar a la macro una vez por cada pierna para obtener el robot completo, ahorrándonos

programar la mitad del código.

4.4 Programación de la descripción del robot.

Antes de empezar a programar la descripción del robot, es necesario crear primero un paquete donde

almacenar todos los archivos. Utilizando el comando catking_create_package creamos un paquete con el

nombre piernas_description. Una vez creado, desde el workspace de ROS, ejecutamos catking_make para

compilar el paquete. La estructura interna del paquete deberá ser la siguiente:

• urdf: carpeta que contendrá los archivos de descripción del robot.

• meshes: carpeta que contendrá los archivos CAD del diseño.

• launch: carpeta que contendrá los archivos encargados de ejecutar el robot y otras herramientas.

Las dependencias del paquete, definidas en el archivo package.xml son:

• joint_state_publisher.

• robot_state_publisher.

• rviz.

Posteriormente se explicará para qué sirve cada una. A continuación se detallarán los pasos que se han seguido

para la creación del archivo de descripción del robot:

51

4.4.1 Preparación de los archivos CAD.

Antes de empezar a programar, es importante tener en cuenta dos cosas a la hora de utilizar modelos CAD

para las visuales y las colisiones de los links:

• Los modelos deben estar en formato .dae (Collada). URDF también soporta archivos .stl, pero se

recomienda siempre utilizar Collada.

• La unidad de longitud por defecto de ROS y Gazebo es el metro.

Esto resulta un problema ya que los archivos generados por CatiaV5 tienen formato .catPART y están en mm.

Para solucionarlo, utilizaremos una herramienta llamada Blender que nos permitirá realizar las

transformaciones necesarias sobre las piezas y guardarlas con el formato adecuado.

Después de descargar el programa, lo abrimos e importamos un archivo .stl (Catia exporta archivos a este

formato). Dado que las unidades en Blender también están por defecto en metros, para ajustar el tamaño de la

pieza únicamente debemos ir al apartado Dimensions y dividir las longitudes de la pieza entre 1000. De esta

forma la pieza quedará ajustada a sus dimensiones reales.

Ilustración 4-7: Captura de Blender.

Una vez hecho esto, exportamos el archivo a formato Collada la pieza ya estará lista para ser incluida en el

archivo URDF.

4.4.2 Definición de variables.

Para facilitar la programación, es conveniente definir algunas variables utilizando XACRO de forma que

después puedan ser mencionadas en cualquier parte del código. En este caso se han definido las rutas de los

archivos CAD como propiedades de la siguiente forma:

<xacro:property name="pie_file" value=

"package://piernas_description/meshes/pie.dae" />

XACRO automáticamente se encargará de encontrar la ruta del paquete piernas_description.

Además de las rutas, también se ha definido la constante PI como variable para aplicar giros más fácilmente.


52

52

4.4.3 Transformaciones entre sistemas de referencia.

Es muy importante antes de empezar a programar los links entender correctamente qué referencias se usan

para definir los orígenes de cada elemento. Como puede observarse en la Ilustración 4-6, el origen de

coordenadas general de un link coincide con el origen de coordenadas de la joint de la cual es hijo. A partir de

aquí, como podemos ver en la Ilustración 4-5, los orígenes de coordenadas de los elementos visual, collision e

inertial están situados en la posición que se defina en la etiqueta <origin> tomando como referencia el origen

general del link.

Por otro lado, al asociar un objeto CAD al elemento visual o al elemento collision, ROS asociará el origen de

coordenadas del archivo CAD (origen de Catia) con el origen del elemento y lo representará en concordancia.

Esto significa que, aunque el origen general del link esté en una posición, al cambiar el origen de los elementos

visual o collision también cambiará de posición el objeto (visualmente para uno y “físicamente” para otro).

Esta asociación nos proporciona una ventaja a la hora de describir el robot ya que en muchos casos (sobre todo

en joints rotacionales cuyo eje de rotación se define a partir de su origen) necesitaremos tener origen general

del link en una posición que no coincide con la posición real del objeto. Para solucionarlo bastará con

modificar los orígenes de los elementos visual y colllision9 para colocar el objeto donde mejor nos convenga y

así construir correctamente el robot.

Sin embargo, esta asociación del objeto CAD con los orígenes de los elementos visual y collision supone

también un gran problema a la hora de definir el origen del elemento inertia. Este origen debe coincidir

siempre con el centro de gravedad del objeto por lo que, para localizarlo correctamente, deberemos conocer la

posición del centro de gravedad respecto al origen de coordenadas general del link.

La pregunta entonces es inmediata, ¿cómo podemos conocer este dato si Catia solo ofrece la posición del

centro de gravedad respecto al origen del archivo CAD? Analizando el problema, el cual puede verse en la

Ilustración 4-8, podemos escribir lo siguiente:

�⃗� 𝑐𝑑𝑔0 = �⃗� 𝑂1

0 + 𝑅𝑂1

0 ∗ �⃗� 𝑐𝑑𝑔1

Siendo �⃗� 𝑐𝑑𝑔0 el vector de posición del centro de gravedad del objeto respecto al origen del link, �⃗� 𝑂1

0 el vector

de posición del origen visual/collision respecto al origen del link, 𝑅𝑂1

0 la matriz de rotación del origen

visual/collision respecto al origen del link y �⃗� 𝑐𝑑𝑔1 el vector de posición del cendro de gravedad respecto al

origen visual/collision.

Ilustración 4-8: Representación vectorial del problema de posición del cdm.

9 En realidad, el único elemento que tienen en cuenta tanto ROS como Gazebo de cara a simulaciones es el elemento collision, pero normalmente ambos se suelen colocar en el mismo punto para visualizar correctamente el robot.

53

Agrupando en la misma matriz la rotación y la traslación del origen visual/collision respecto al origen del link

obtenemos lo que se conoce como matriz de transformación homogénea.

𝑇 = [𝑅𝑂1

0 �⃗� 𝑂1

0

0 0 0 1] → �⃗� 𝑐𝑑𝑔

0 = 𝑇 ∗ �⃗� 𝑐𝑑𝑔1

De esta forma, ya que conocemos tanto la rotación como la traslación del origen viual/collision, podremos

obtener el vector de posición del centro de gravedad del objeto respecto al origen del link.

Cabe destacar que, dado que la rotación puede ser alrededor de los tres ejes, la matriz de rotación debe ser el

producto de las matrices de rotación alrededor de cada eje.

𝑅𝑥(𝛾) = [1 0 00 𝑐𝑜𝑠𝜃 −𝑠𝑒𝑛𝜃0 𝑠𝑒𝑛𝜃 𝑐𝑜𝑠𝜃

] 𝑅𝑦(𝜃) = [𝑐𝑜𝑠𝜃 0 𝑠𝑒𝑛𝜃

0 1 0−𝑠𝑒𝑛𝜃 0 𝑐𝑜𝑠𝜃

] 𝑅𝑧(𝛼) = [𝑐𝑜𝑠𝜃 −𝑠𝑒𝑛𝜃 0𝑠𝑒𝑛𝜃 𝑐𝑜𝑠𝜃 0

0 0 1]

𝑅𝑂1

0 = 𝑅𝑧(𝛼) ∗ 𝑅𝑦(𝜃) ∗ 𝑅𝑥(𝛾)

4.4.4 Definición de macros.

Tras entender cómo funcionan las referencias dentro de un link podemos empezar a programar las macros.

Este es el paso más importante de todos ya que las macros que creemos serán las que después formen nuestro

código. Para este archivo, se han creado 3 macros:

• crea_link: como su propio nombre indica, esta macro genera el código necesario para crear un link.

Tiene como parámetros el nombre del link, la ruta del archivo CAD utilizado en el link, las

coordenadas del origen visual, la masa, las coordenadas del origen de inercia y los momentos de

inercia. Para definir el origen de coordenadas del elemento inertia se ha utilizado la ecuación deducida

en el apartado anterior. Dado que XACRO no puede realizar operaciones matriciales, se ha

desarrollado completamente la multiplicación para que pueda ser calculada. A continuación podemos

ver el código:

<xacro:macro name="crea_link" params="nombre archivo O_visual_x

O_visual_y O_visual_z gamma beta alfa masa O_cdm_x O_cdm_y O_cdm_z ixx

ixy ixz iyy iyz izz">

<link name="${nombre}">

<visual>

<origin xyz="${O_visual_x} ${O_visual_y} ${O_visual_z}"

rpy="${gamma} ${beta} ${alfa} "/>

<geometry>

<mesh filename="${archivo}"/>

</geometry>

</visual>

<collision>

<origin xyz="${O_visual_x} ${O_visual_y} ${O_visual_z}"

rpy="${gamma} ${beta} ${alfa} "/>

<geometry>

<mesh filename="${archivo}"/>

</geometry>

</collision>


54

54

<inertial>

<mass value="${masa}"/>

<origin xyz="${cos(alfa)*cos(beta)*O_cdm_x +

(cos(alfa)*sin(beta)*sin(gamma)-

sin(alfa)*cos(gamma))*O_cdm_y +

(cos(alfa)*sin(beta)*cos(gamma)+

sin(alfa)*sin(gamma))*O_cdm_z + O_visual_x}

${sin(alfa)*cos(beta)*O_cdm_x +

(sin(alfa)*sin(beta)*sin(gamma)+

cos(alfa)*cos(gamma))*O_cdm_y +

(sin(alfa)*sin(beta)*cos(gamma)-

cos(alfa)*sin(gamma))*O_cdm_z + O_visual_y}

${-sin(beta)*O_cdm_x+

cos(beta)*sin(gamma)*O_cdm_y+

cos(beta)*cos(gamma)*O_cdm_z + O_visual_z}"/>

<inertia ixx="${ixx}" ixy="${ixy}" ixz="${ixz}"

iyy="${iyy}" iyz="${iyz}"

izz="${izz}"/>

</inertial>

</link>

</xacro:macro>

• crea_pierna_link: en esta macro, que tiene como parámetros el lado (derecho o izquierdo) y dos

variables auxiliares, se definen utilizando la macro anterior todos los links que componen una pierna.

Las posiciones y giros se han programado utilizando los dos parámetros auxiliares, de tal forma que se

pueda llamar dos veces a la macro y las dos piernas queden perfectamente definidas. Debido a la

longitud del código, este se encuentra adjunto en el Anexo A.

• crea_pierna_joint: esta macro realiza la misma función que la anterior, pero para las joints. Define

todas las joints de una pierna parametrizando su posición según el lado. Aunque el código completo

puede encontrarse también en el Anexo A, a continuación se muestra un ejemplo de cómo se ha

definido una joint rotacional y una fija:

<joint name="Tobillo_${lado}" type="revolute">

<origin xyz="${0.0215*sentido} 0 -0.046379"/>

<child link="soporte_pie_${lado}"/>

<parent link="motor_tobillo_${lado}"/>

<axis xyz="1 0 0"/>

<limit upper="${12.6*PI/180}"

lower="${56.2*PI/180}"

effort="5.099458"

velocity="6.464"/>

<dynamics damping="${damping}"/>

</joint>

<joint name="Pie${lado}_SoportePie${lado}" type="fixed">

<origin xyz="${-0.022*sentido} 0 -0.037"/>

<child link="pie_${lado}"/>

<parent link="soporte_pie_${lado}"/>

</joint>

Los parámetros upper y lower se corresponden con los límites de rotación de la articulación

(obtenidos en el apartado 2.2.1) y los parámetros effort y velocity son el par y la velocidad máxima de

la articulación (obtenidos de la hoja de especificaciones del motor). Por otro lado, el parámetro

damping se corresponde con la resistencia al giro de la articulación y se ha definido en una variable

para poder elegir el mejor valor en simulación.

55

4.4.5 Finalización del código.

Una vez creadas todas las macros, lo único que debemos hacer es llamar a cada macro dos veces con sus

parámetros adecuados para conseguir crear las dos piernas completas. Antes de eso, utilizando la macro

crea_link se debe definir el link de la cadera y un link llamado world que representa el eje de referencia global.

Fijaremos por el momento la cadera a este link global para que aparezca suspendida en el aire en la simulación

(posteriormente deberemos retirar esta joint si queremos que el robot pueda desplazarse). Finalmente,

llamamos a las macros para crear las piernas y finalizamos la descripción.

4.5 Validación del archivo URDF.

Tras escribir todo el código utilizando XACRO, el archivo final deberá tener extensión .xacro. Esto es debido

a que primero el archivo debe pasar por el compilador de XACRO, el cual se encargará de sustituir todas las

macros que hayamos creado y generará el archivo .urdf final. Para ejecutar el compilador de XACRO,

utilizamos el siguiente comando:

rosrun xacro –-inorder {ruta del archivo .xacro}

Tras programar todo el código y ejecutar el compilador de XACRO, obtendremos un archivo con extensión

.urdf que contendrá toda la descripción de nuestro robot. Para comprobar que el código es correcto,

utilizaremos dos de las herramientas de verificación anteriormente mencionadas (realmente solo una es de

verificación, la otra es simplemente para visualizar la descripcion en forma de árbol).

La primera que se utilizará será check_urdf. Esta herramienta analiza el código con formato .urdf y nos indica

si es correcto o no. Para ejecutarla, escribimos en consola lo siguiente:

check_urdf {ruta del archivo .urdf}

Si todo ha ido bien, obtendremos como resultado el siguiente mensaje:

robot name is: piernas

---------- Successfully Parsed XML ---------------

Seguidamente, el programa nos mostrará la estructura de links de nuestro robot. Sin embargo, para poder

visualizar esta estructura mejor utilizaremos la segunda herramienta llamada urdf_to_graphiz. Esta

herramienta lee la descripción del robot y la representa mediante un diagrama en formato .pdf. Para ejecutarla

escribimos en consola lo siguiente:

urdf_to_graphiz {ruta del archivo .urdf}

4.6 Ejecución del código y visualización del robot en RVIZ.

Una vez tenemos la descripción del robot verificada, es el momento de cargarla en el servidor de parámetros

de ROS para que este pueda acceder a ella. Para ello, se creará un archivo con extensión .launch, que son los

archivos utilizados en ROS para lanzar aplicaciones. Los archivos con esta extensión tienen sus propias reglas

y etiquetas, pero no nos pararemos a analizarlas en profundidad para no alargar la explicación. En lugar de eso,

se explicarán solo las líneas utilizadas.

El archivo creado, llamado piernas_rviz.launch y localizado en la carpeta launch de nuestro paquete, presenta

el siguiente contenido:


56

56

<launch>

<!—Carga en el servidor de parámetros la descripción del robot-->

<param name="robot_description"

command="$(find xacro)/xacro --inorder

'$(find piernas_description)/urdf/piernas.xacro'" />

<!—Ejecuta joint_state_publisher para enviar valores a las articulaciones -->

<node name="joint_state_publisher"

pkg="joint_state_publisher"

type="joint_state_publisher">

<param name="use_gui" value="TRUE"/>

</node>

<!— Ejecuta robot_state_publisher para la cinemática del robot -->

<node name="robot_state_publisher"

pkg="robot_state_publisher"

type="state_publisher"/>

</launch>

A continuación se explica paso a paso el contenido de este archivo:

• En primer lugar, debemos cargar en el servidor de parámetros de ROS la descripción de nuestro robot.

Para ello, creamos un parámetro con el nombre “robot_description” y cargamos en él el archivo que el

compilador de XACRO devuelve al ejecutarse.

• En segundo lugar, ejecutamos el nodo joint_state_publisher. Este código, perteneciente al paquete del

mismo nombre, lee la descripcion proporcionada en el parámetro robot_description y publica valores

para las articulaciones no fijas en el topic joint_states. Esto es necesario ya que en la descripción del

robot no se especifica en ningún momento qué valor deben tener las articulaciones, por lo que para

realizar una representación es necesario darles un valor. Para ello, el programa proporciona una

interfaz gráfica desde la cual es posible modificar los valores de las articulaciones a voluntad.

• Por último, ejecutamos el nodo robot_state_publisher. Este código, perteneciente al paquete del

mismo nombre, utiliza la descripción del robot ubicada en el parámetro robot_description y los

valores publicados por el nodo joint_state_publisher en el topic joint_states para calcular la

cinemática del robot y saber así en qué posición está. Estos datos los publica a través del paquete tf

(paquete utilizado para gestionar múltiples sistemas de referencia).

Para ejecutar el archivo, hacemos ejecutamos en la consola:

roslaunch piernas_description piernas_rviz.launch

Una vez el archivo ha sido ejecutado, aparecerá en pantalla la interfaz del joint_state_publisher, pero no el

robot. Para poder verlo, utilizaremos la herramienta de visualización de ROS llamada Rviz.

Ejecutando el comando rosrun rviz se abrirá la interfaz, aunque sin nada de momento. Para poder visualizar

nuestro robot, tenemos que añadir un nuevo modelo de robot y seleccionar el link de referencia (en este caso

world ya que hemos fijado por el momento la cadera a este). Rviz reconocerá automáticamente el robot y lo

mostrará en la pantalla.

57

Ilustración 4-9: Configuración de Rviz.

Ilustración 4-10: Visualización del robot en Rviz.


58

58

Para poder ver las referencias de cada link, debemos añadir al panel un elemento TF. Este puede encontrarse

en el mismo sitio que el elemento RobotModel anterior.

Ilustración 4-11: Visualización de los sistemas de coordenadas de cada link.

Para finalizar, podemos comprobar que las articulaciones de nuestro robot están correctamente definidas

utilizando la interfaz gráfica que proporciona joint_state_publisher. La interfaz nos proporciona un slider por

cada articulación rotacional que detecta en el robot desde donde poder enviar ángulos a las articulaciones. A

continuación se muestra un ejemplo de ello:

Ilustración 4-12: Robot en una posición definida por joint_state_publisher.

59

Como comprobación final, podemos ejecutar la herramienta rqt_graph. Esta herramienta muestra en formato

gráfico todos los nodos y topics que actualmente se encuentran abiertos en la red de ROS. Al ejecutarlo

obtendremos lo siguiente:

Ilustración 4-13: Nodos y topics proporcionados por rqt_graph.

Como era de esperar, aparece el nodo /joint_state_publisher publicando mensajes en el topic /joint_states. Al

mismo tiempo, esos mensajes son recogidos por el nodo /robot_state_publisher para poder realizar las

transformaciones que después publica en los topics /tf y /tf_static, que es de donde Rviz obtiene la

información para representar el robot.

Una vez hemos terminado todas las comprobaciones, si queremos que al ejecutar el archivo

piernas_rviz.launch se abra directamente Rviz mostrando todo lo que tenemos actualmente, únicamente

tenemos que guardar la configuración de la ventana de Rviz en la carpeta launch de nuestro paquete, y añadir

al archivo piernas_rviz.launch la siguiente línea de código:

<node name="rviz" pkg="rviz" type="rviz" args="-d $(find

piernas_description)/launch/piernas.rviz"/>

4.7 Simulación del robot.

Para poder ejecutar nuestro robot en el entorno de simulación Gazebo, es necesario primero instalar una serie

de paquetes llamados gazebo_ros_pkgs. Estos paquetes proporcionan las herramientas necesarias tanto a

Gazebo como a ROS para poder comunicarse entre sí y realizar simulaciones de robots controlados por ROS.

Los paquetes incluidos en el meta-paquete gazebo_ros_pkgs son los que se muestran en la Ilustración 4-14.

Ilustración 4-14: Estructura del meta-paquete gazebo_ros_pkg.


60

60

4.7.1 Conversión de URDF a SDF.

El formato de los archivos utilizados en Gazebo, tanto para la descripción de los mundos como para la

descripción de los robots, es el formato SDF. Como ROS utiliza el formato URDF para describir sus robots,

para poder realizar la simulación en Gazebo es necesario transformar el archivo URDF al formato SDF.

Afortunadamente, Gazebo cuenta con las herramientas necesarias (proporcionadas en el paquete

gazebo_ros_pkgs) para realizar esta conversión automáticamente. Sin embargo, hay algunos cambios que es

necesario hacer para que la simulación sea lo más precisa posible.

El único elemento que para Gazebo es indispensable, pero para ROS no, es el elemento <inertia>. Para que

Gazebo pueda realizar correctamente las simulaciones, cada link debe tener un elemento de este tipo asociado

y correctamente configurado10. Dado que este elemento ya ha sido añadido no es necesario añadirlo de nuevo.

Además del elemento <inertia>, existen otros elementos opcionales que no están recogidos en el estándar

URDF que, de incluirse, podrían mejorarán la calidad de la simulación. Estos elementos deben estar agrupados

dentro del elemento <gazebo> para que sean correctamente interpretados. Dependiendo de si el elemento

<gazebo> referencia a una joint, un link, o al robot entero, existirán diferentes configuraciones y parámetros.

Los parámetros adicionales que se añadirán para los links serán <mu1> y <mu2> (coeficientes de fricción para

los links) y <selfCollide>. Cuando este último parámetro está activado, los links del robot pueden interactuar

físicamente entre sí (por defecto está desactivado por lo que si el robot colisiona consigo mismo no se

detectará la colisión). En cuanto a las joints, el estándar URDF ya incluye los parámetros necesarios para una

correcta simulación por lo que no es necesario añadir ninguno más.

Por lo tanto, al archivo .xacro que incluía la descripción del robot, será necesario añadirle las siguientes líneas

de código (un bloque por cada link):

<gazebo reference="nombre del link">

<mu1>valor_mu1</mu1>

<mu2>valor_mu2</mu2>

<selfCollide>True</selfCollide>

</gazebo>

Para separar estos elementos (que pertenecen al entorno de Gazebo) de la propia descripción del robot, se

agruparán todos los elementos <gazebo> en un archivo a parte llamado piernas.gazebo, el cual estará en la

misma carpeta que el archivo piernas.xacro. Para que el compilador de XACRO incluya el contenido del

archivo .gazebo en el archivo principal, añadiremos el siguiente comando al archivo .xacro:

<xacro:include filename="$(find piernas_description)/urdf/piernas.gazebo" />

Gazebo proporciona una herramienta para comprobar de manera sencilla si el archivo URDF es válido para ser

convertido a SDF. Para ejecutarla, escribimos en consola lo siguiente:

gz sdf -p MODEL.urdf

4.7.2 Preparación de la simulación.

Una vez se ha conseguido una descripción del robot entendible por Gazebo, se preparará la simulación. Para

ello, crearemos un paquete llamado piernas_gazebo el cual contenga todos los archivos relacionados con la

simulación. La estructura de dicho paquete será la siguiente:

• launch: carpeta que contendrá los archivos .launch del paquete.

• worlds: carpeta que contendrá los archivos de mundos para las simulaciones.

10 Estos valores han sido obtenidos utilizando la herramienta measure inertia de CatiaV5.

61

Las dependencias del paquete son:

• gazebo_ros.

• piernas_description.

• Xacro.

Una vez creado y compilado el paquete, programamos un archivo .world básico donde inicializar nuestro

robot. El mundo donde simularemos el robot estará compuesto únicamente por un plano base que actuará

como suelo y una fuente global de luz:

<?xml version="1.0" ?>

<sdf version="1.4">

<world name="default">

<include>

<uri>model://ground_plane</uri>

</include>



<include>

<uri>model://sun</uri>

</include>

</world>

</sdf>

Con el archivo de mundo creado, el último paso es crear el archivo .launch que se encargará de ejecutarlo todo.

El archivo, ubicado en la carpeta launch del paquete piernas_gazebo, deberá contener lo siguiente:

<launch>



<arg name="paused" default="true"/>

<arg name="use_sim_time" default="true"/>

<arg name="gui" default="true"/>

<arg name="headless" default="false"/>

<arg name="debug" default="false"/>



<include file="$(find gazebo_ros)/launch/empty_world.launch">

<arg name="world_name" value="$(find

piernas_gazebo)/worlds/piernas.world"/>

<arg name="debug" value="$(arg debug)" />

<arg name="gui" value="$(arg gui)" />

<arg name="paused" value="$(arg paused)"/>

<arg name="use_sim_time" value="$(arg use_sim_time)"/>

<arg name="headless" value="$(arg headless)"/>

</include>



<param name="robot_description"

command="$(find xacro)/xacro --inorder '$(find

piernas_description)/urdf/piernas.xacro'" />



<node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model"

respawn="false" output="screen"

args="-urdf -model piernas -param robot_description"/>

</launch>


62

62

En primer lugar, se crean una serie de parámetros que se encargarán de controlar la simulación. Seguidamente

ejecuta el archivo .launch del paquete gazebo_ros que se encargará de lanzar el mundo y configurar todo el

entorno para la correcta comunicación entre Gazebo y ROS. A este archivo se le pasa como parámetros los

definidos anteriormente junto con la ruta del mundo que queremos cargar (el que anteriormente hemos

creado). Tras hacer esto, se carga en el servidor de parámetros la descripción del robot de la misma forma que

se hizo en el archivo piernas_rviz.launch y por último se ejecuta el urdf_spawner, un código incluido en

gazebo_ros que lanza el robot dentro del entorno Gazebo.

Con todos los archivos listos podemos ejecutar la simulación escribiendo el siguiente comando en la consola:

roslaunch piernas_gazebo {nombre del archivo}.launch

4.7.3 Comprobación de resultados.

Una vez ejecutado el archivo , se abrirá la ventana de simulación de Gazebo mostrando lo siguiente:

Ilustración 4-15: Robot en simulación.

En la ventana se muestra al robot ubicado a una cierta distancia del suelo (definida en la joint que une la cadera

con el link global) y con la simulación detenida (dado que así se lo hemos indicado en los parámetros del

archivo .launch) para poder analizarlo con claridad.

Para comprobar que todo ha salido correctamente, comprobaremos cómo se han definido los links, las joints,

las colisiones, las inercias y los centros de gravedad. A continuación se presentan los resultados obtenidos:

63

Ilustración 4-16: Links definidos por Gazebo.

Ilustración 4-17: Joints definidas por Gazebo (solo rotacionales)


64

64

Ilustración 4-18: Collisions definidas por Gazebo.

Ilustración 4-19: Inercias definidas por Gazebo.

65

Ilustración 4-20: Centros de gravedad definidos por Gazebo.

Como puede verse, las definiciones hechas por Gazebo son todas correctas y el resultado final del robot es

bastante preciso. La única modificación notable es que Gazebo une por defecto todos los links interconectados

mediante joints fijas, por lo que el número final de links es menor. Sin embargo, esto no afecta al resultado de

la simulación ya que también calcula la inercia y el centro de gravedad del conjunto de links.

Una vez se han hecho todas las comprobaciones, podemos poner en marcha la simulación y comprobar cómo

de bueno es el comportamiento del robot aplicando fuerzas y momentos a los links del robot. De esta forma,

visualizando la calidad de la simulación podemos ir modificando el parámetro damping hasta conseguir un

resultado aceptable11.

Ilustración 4-21: Robot con la simulación en marcha.

11 No es posible obtener este parámetro de otro modo ya que el fabricante del motor no proporciona esta información.

CONTROL DE LOS ACTUADORES

66

66

5 CONTROL DE LOS ACTUADORES

l último paso para que nuestro robot sea plenamente funcional es aplicar un control a los actuadores. En

el robot real, los actuadores serán servomotores cuya referencia es directamente la posición de la

articulación, encargándose internamente el servo del control para llegar a esa referencia. Sin embargo,

esa funcionalidad aún no está implementada en el robot simulado. Por ello, en el presente capítulo veremos

cómo aplicar a cada articulación un control PID utilizando la librería ros_control y así tener nuestro robot

controlado a nivel de actuador al igual que en robot real.

5.1 Ros_control.

Ros_control es un conjunto de paquetes de ros los cuales toman como entrada el estado actual del robot (en

nuestro caso proporcionado por Gazebo) y un punto de referencia. Utilizando eso, implementan un algoritmo

de control (típicamente un PID) para controlar la señal enviada a los actuadores (que suele ser una señal de

esfuerzo).

Ilustración 5-1: Diagrama de flujo de ros_control.

E

67

Incluido en ros_control encontramos el paquete ros_controllers que es el encargado de implementar los

controladores. Existen varios tipos de controles en este paquete:

• effort_controllers: la señal de control es el esfuerzo aplicado. Puede utilizarse para controlar posición,

velocidad o esfuerzo sin más.

• joint_state_controller: se encarga de recolectar los datos proporcionados por los sensores de las

articulaciones (en nuestro caso Gazebo) y publicarlos en el topic /joint_states como realimentación a

los controladores.

• position_controllers: fija la posición de una o múltiples joints.

• velocity_controllers: fija la velocidad de una o múltiples joints.

Además de los controladores, ros_control incluye una serie de paquetes denominados Hardware Interfaces

destinados a la comunicación con el hardware del actuador. Entre las interfaces hardware que existen

encontramos Joint Command Interfaces, que es la interfaz destinada al envío de referencias articulares. Al

igual que en el caso de los controladores, esta interfaz puede ser de comandos tipo esfuerzo (Effort Joint

Interface), de tipo velocidad (Velocity Joint Interface) o de tipo posición (Position Joint Interface).

Otro elemento importante relacionado con ros_control son las transmissions. Las transmissions son las

encargadas de asociar cada actuador con cada joint, de manera que ros_control sepa a qué actuador mandar

cada señal. Deberemos por tanto asociar una transmisión por cada joint de nuestro robot.

El último paquete que veremos de ros_control es el joint_limits_interface. Este paquete toma los valores

límites descritos para cada articulación en el archivo URDF y los aplica al control, saturando la señal de

control si esta supera dichos valores.

5.2 Gazebo y ros_control.

Para poder utilizar ros_control en Gazebo, es necesario primero tener instalado gazebo_ros_control. Este

paquete proporciona una serie de funcionalidades entre las que se encuentran:

• Una interfaz hardware, llamada DefaultRobotHWSim, para que ros_control pueda interactuar con

Gazebo.

• Un plugin para Gazebo encargado de leer los elementos transmissions y cargar la interfaz hardware

adecuada.

Para instalarlo, simplemente escribimos en consola:

Sudo apt-get install ros-{distro_ros}-gazebo-ros-control

A continuación podemos ver una imagen que resume las interacciones entre ros_control, Gazebo y el mundo

real.


68

68

Ilustración 5-2: Interacciones entre ros_control, Gazebo y el mundo real.

5.3 Modificación del archivo URDF.

Una vez tengamos instalado el paquete gazebo_ros_control, podemos empezar a modificar el archivo URDF

para poder controlar nuestro robot.

En primer lugar, añadiremos un elemento transmisión por cada articulación para asociar un actuador a cada

una de ellas. La sintaxis del elemento es la siguiente:

<transmission name="nombre_transmission">

<type>transmission_interface/SimpleTransmission</type>

<joint name="nombre_joint_asociada">

<hardwareInterface>

hardware_interface/EffortJointInterface

</hardwareInterface>

</joint>

<actuator name="nombre_actuador">

<hardwareInterface>

hardware_interface/EffortJointInterface

</hardwareInterface>

<mechanicalReduction>1</mechanicalReduction>

</actuator>

</transmission>

69

Como se puede ver, en primer lugar debemos definir el tipo de transmisión. Dado que no se trata de una

transmisión especial como podría ser una diferencial, elegimos como tipo SimpleTransmission.

Seguidamente, asociamos la joint sobre la que actuará el motor y seleccionamos como interfaz hardware

EffortJointInterface para que ros_control sepa que se trata de comandos de esfuerzo. Por último, definimos el

actuador asociándole un nombre y el mismo tipo de interfaz hardware. Por último, indicamos que la reducción

es de 1, es decir, no hay reducción.

Una vez hemos definido los actuadores, el siguiente paso es añadir al archivo .gazebo el plugin de

gazebo_ros_control. El código para hacerlo es el siguiente:

<gazebo>

<plugin name="gazebo_ros_control" filename="libgazebo_ros_control.so">

<robotNamespace>/piernas</robotNamespace>

</plugin>

</gazebo>

5.4 Creación de los controladores.

Existen una gran variedad de formas de diseñar un control para la dinámica de las articulaciones de un robot.

Por ejemplo, una posible solución sería la de analizar matemáticamente el sistema, obteniendo las ecuaciones

del modelo dinámico, y diseñar un control multivariable donde todas las articulaciones se controlen

conjuntamente. Esta solución bien implementada puede ofrecer unos muy buenos resultados, aunque resulta

muy complicada de aplicar a robots con una gran variedad de eslabones. Otra opción más sencilla, aunque

basada en un modelo matemático también, sería diseñar un control monoarticular del tipo precompensación de

gravedad o par calculad donde cada articulación se controle por separado pero teniendo en cuenta la dinámica

del robot completo. Estas soluciones, aunque teóricamente sean las recomendadas, carecen de sentido en un

robot como el que se pretende controlar aquí. Esto es debido a que a la hora de fabricar el robot, los actuadores

serán servomotores que ya vendrán con un control (típicamente un PID) integrado, lo que no permite realizar

controles más complejos. Como mucho, algunos motores permitirán la configuración de los parámetros de

dicho control para una mejor respuesta, pero nunca teniendo en cuenta la dinámica del robot. Es por esto por lo

que se optará por implementar únicamente un control PID por cada articulación, en el que los efectos del

movimiento del robot serán vistos como perturbaciones a rechazar.

Para crear los controladores, primero debemos crear un nuevo paquete donde almacenar los archivos

relacionados con el control. Para ello, al igual que en los casos anteriores, ejecutamos catkin_create_package y

creamos un paquete con el nombre piernas_control.

La estructura interna de este paquete deberá ser la siguiente:

• config: carpeta que contendrá las definiciones de los controladores y sus variables.

• launch: carpeta que contendrá el archivo encargado de ejecutar los controladores.

Las dependencias del paquete deben ser las siguientes:

• controller_manager.

• joint_state_controller.

• robot_state_publisher.

• rqt_gui.

• effort_controllers.

70

70

Una vez creado el paquete y sus subcarpetas, es momento de definir los controladores. Para ello, en la carpeta

config creamos un archivo llamado piernas_control.yaml. Para definir un controlador, se debe escribir el

siguiente código:

Nombre_controlador:

type: effort_controllers/JointPositionController

joint: joint_asociada

pid: {p: 100.0, i: 0.01, d: 10.0}

En principio dejaremos las constantes del PID por defecto, más adelante las configuraremos.

Tras definir un controlador por cada articulación, el último paso es definir la frecuencia de muestreo del

control. Dicha frecuencia es controlada por el joint_state_controller, que es el encargado de tomar los valores

de las articulaciones. Para definirlo, escribimos lo siguiente:

joint_state_controller:

type: joint_state_controller/JointStateController

publish_rate: 50

Donde publish_rate es la frecuencia a la que el control toma los valores de las articulaciones.

5.5 Ejecución de los controladores.

Para poder ejecutar los controladores, simplemente escribimos el siguiente archivo .launch dentro de la carpeta

launch del paquete piernas_control:

<launch>



<rosparam file="$(find piernas_control)/config/piernas_control.yaml"

command="load"/>



<node name="controller_spawner" pkg="controller_manager" type="spawner"

respawn="false"

output="screen"

ns="/piernas"

args="joint_state_controller {aquí se incluyen todos los controladores

creados en el archivo .yaml}

<node name="robot_state_publisher" pkg="robot_state_publisher"

type="robot_state_publisher"

respawn="false" output="screen">

<remap from="/joint_states" to="/piernas/joint_states" />

</node>

</launch>

71

Una vez esté creado el archivo que lanza los controladores, con la simulación del robot en marcha únicamente

tendremos que ejecutar los controles desde consola con el siguiente comando:

roslaunch piernas_control piernas_control.launch

Para comprobar que los controles están funcionando, abrimos el programa rqt_gui. En él, cargamos el módulo

Message Publisher el cual sirve para publicar mensajes en los topics que se desee. Seleccionamos los topics

correspondientes a las referencias de los controladores, habilitamos la publicación de mensajes y enviamos una

referencia escribiendo su valor en la casilla expression. En Gazebo podrá verse que el robot se mueve

intentando alcanzar la referencia, por lo que los controladores se encuentran funcionando.

Ilustración 5-3: Ventana de rqt_gui con Message Publisher.

5.6 Calibración de los parámetros de los controladores.

Tras ejecutar todos los controladores, se puede observar que no funcionan de manera adecuada. Esto es lógico

debido a que aún no se han seleccionado los parámetros de dichos controladores, sino que únicamente se han

puesto unos parámetros por defecto. Para conseguir resultados aceptables será necesario por tanto modificar

dichos parámetros hasta dar con la respuesta deseada.

Para realizar este ajuste, se utilizará la herramienta Dynamic Configuration proporcionada en el programa

rqt_gui. Esta herramienta permite modificar de manera sencilla los parámetros de los controladores que se

encuentren definidos en la red de ROS. De esta forma, junto con la herramienta Message Publisher para

introducir referencias y la herramienta rqt_plot para visualizar los resultados, se realizará el ajuste de los

parámetros.


72

72

Ilustración 5-4: Ventana Dynamic Configuration.

Ilustración 5-5: Ventana rqt_plot.

Uno de los métodos más utilizados a la hora de realizar el ajuste (tuning) de controladores PID es el método de

Ziegler-Nichols. Este método fue propuesto por John G. Ziegler y Nathaniel B. Nichols como una solución al

problema de obtener los parámetros de un controlador PID realizando experimentos directamente en bucle

cerrado. El método consiste en reducir al máximo posible la acción derivativa y la acción integral, e ir

aumentando poco a poco la acción proporcional hasta conseguir que el sistema oscile de forma mantenida ante

cualquier perturbación. Después, se realizan una serie de mediciones sobre la onda y se calculan las constantes

del controlador en base a estas medidas según una tabla de relaciones.

73

Tras aplicar este método para el ajuste de los controladores, los resultados obtenidos no fueron satisfactorios

debido a la imposibilidad de conseguir que las articulaciones se mantuviesen oscilando permanentemente ante

cualquier perturbación. Debido a esto, se optó por aplicar el método de ajuste manual, modificando las

ganancias teniendo en cuenta su efecto en el sistema hasta conseguir los resultados deseados.

Este era el resultado del control antes del ajuste:

Ilustración 5-6: Respuesta del control PID ante cambio de referencia (antes de ajuste).

Y este es el resultado después de realizar el ajuste de los controladores12:

Ilustración 5-7: Respuesta del control PID ante cambio de referencia (con ajuste).

12 Únicamente se muestra el resultado para el motor de extensión derecho, sin embargo el resultado para las otras articulaciones fue igual de satisfactorio.


74

74

Por otro lado, si realizamos un experimento para comprobar el rechazo a perturbaciones obtenemos los

siguientes resultados:

Ilustración 5-8: Respuesta del control PID ante cambio en la perturbación.

Como puede verse, el resultado es bastante bueno.

Como prueba final, se introdujo como referencia una senoide para comprobar el seguimiento de la articulación

ante una referencia cambiante con el tiempo. Además, en un determinado momento, se modifica el ángulo de

la rodilla para observar cómo afecta esto al control de una articulación en movimiento. Como puede verse en

la siguiente ilustración, los resultados son bastante satisfactorios:

Ilustración 5-9: Movimiento pendular con cambio de perturbación.

75

Una vez que se ha comprobado que la respuesta de los controladores es adecuada, es necesario comprobar la

magnitud de los esfuerzos que el control requiere para mover el robot. De esta forma, si los esfuerzos son

mayoritariamente cercanos al límite del motor (definido en el archivo URDF), se deberá seleccionar un motor

más potente para evitar estar trabajando siempre al límite de su capacidad. Por otro lado, si los esfuerzos se

mantienen en un valor aceptable, la elección de los actuadores habrá sido acertada.

Utilizando Rviz, y el módulo effort, podemos ver los esfuerzos que está generando cada articulación en todo

momento13.

Ilustración 5-10: Esfuerzos en las articulaciones mostrados por Rviz.

Tras realizar varios movimientos se comprobó que, aunque en ciertos momentos se alcanzan los valores

límites de esfuerzo de los motores, en los momentos en los que el robot se encuentra estático los esfuerzos no

llegan nunca al máximo.

Tras realizar todas las verificaciones y comprobar que todo funcionan adecuadamente, se deberá modificar el

archivo config.yaml, el cual incluye la definición de los controladores, y sustituir las constantes antiguas por

sus nuevos valores. De esta forma, al ejecutar el archivo piernas_control.launch, los controladores se iniciarán

por defecto con los parámetros correctos.

13 En este caso la cadera se ha fijado a una cierta altura del suelo para eliminar esfuerzos derivados de las reacciones del suelo y comprobar los debidos únicamente al control de posición de las articulaciones.


76

76

5.7 Comprobación de la estabilidad del modelo en simulación.

Tras añadir el control de las articulaciones y configurarlo adecuadamente, estamos listos para comprobar si el

robot se mantiene de pie por sí solo. Para ello, primero se debe modificar el archivo URDF y cambiar el

nombre del link world, utilizado como referencia global por Gazebo, por otro nombre cualquiera (importante

también cambiar el nombre en la joint). Esto hace que Gazebo ya no interprete que el robot está fijado al

mundo por lo que podrá moverse con total libertad14.

Una vez hecho esto, incluimos en el archivo de ejecución de la simulación (piernas_gazebo.launch) un

parámetro que le indique al código dónde localizar el robot inicialmente ejecutamos la simulación.

Tras realizar la simulación del robot, se observó que este se mantenía erguido de manera correcta, pero que las

interacciones con el mundo no eran las adecuadas. En concreto, el robot presentaba dos comportamientos

extraños: un rebote de los pies contra el suelo excesivamente grande, por lo que el robot acababa cayéndose

hacia atrás, y un deslizamiento por el suelo como si de hielo se tratase. Tras analizar la situación y realizar

varias pruebas, se descubrió que estos comportamientos se debían a la precisión de los cálculos de la

simulación ya que al reducir el paso máximo de integración (lo que aumenta la precisión de la simulación)

dichos movimientos desaparecieron y el robot se mantuvo estático.

14 Es necesario seguir incluyendo un link “fantasma” debido a que el motor de físicas de Gazebo no permite asignar inercias al link principal del robot, que sería el soporte_cadera. De esta forma, para mantener las inercias del robot intactas, se crea este link sin inercia y se define como link principal del robot.

77

6 OBTENCIÓN DE TRAYECTORIAS

ARTICULARES Y SIMULACIÓN FINAL

ras completar el control de las articulaciones y comprobar que el robot se mantiene erguido por sí solo,

podemos concluir en que el modelo del robot está completo y funcional. A partir de ahora, utilizando

este modelo se podrán realizar experimentos con trayectorias articulares para hacer que camine y se

mueva por el entorno. Aunque no es el objetivo final del trabajo, como prueba de una aplicación se realizará

un control en bucle abierto de las piernas, proporcionando unas trayectorias previamente recogidas por un

sensor en el mundo real para intentar que el robot camine. Además, se añadirá la posibilidad de que utilizando

el mismo sistema de medición utilizado en la recolección de las trayectorias articulares, el robot copie los

movimientos de la persona que lo lleve puesto en tiempo real.

6.1 Creación del dispositivo de medidas.

Para poder obtener en tiempo real la medida del ángulo de cada articulación, con el fin de replicarla

posteriormente en el robot, se ha fabricado el siguiente sistema:

Ilustración 6-1: Dispositivo de medición de ángulos de las articulaciones.

T

OBTENCIÓN DE TRAYECTORIAS ARTICULARES Y SIMULACIÓN FINAL

78

78

El sistema está formado por una serie de potenciómetros, asociados cada uno a una articulación, situados entre

dos varillas de madera. Estas varillas se sujetan cada una a un extremo de la articulación de tal forma que, al

variar el ángulo entre los segmentos que la forman, varíe también el ángulo entre las varillas permitiendo

obtener la medida mediante el potenciómetro. Las medidas de tensión de cada potenciómetro se realizarán

mediante una placa Arduino Uno situada en la cadera. Estas medidas, después de ser transformadas a radianes,

serán enviadas a ROS para su tratamiento.

Es muy importante entender cómo realiza las mediciones analógicas Arduino para poder realizar la

transformación adecuada a radianes. Las placas Arduino Uno disponen de un CAD de 8 bits de resolución

basado en la tecnología TTL, por lo que al realizar una medición de 0 V el convertidor devolverá un 0, y al

realizar una medición de 5 V el convertidor devolverá un 1024. Para transformar esa medida en el rango

[0,1024] a un valor en radianes entendible por ROS, se utilizará la función map. Esta función realiza el

escalado de un valor de un rango a otro. De esta forma, indicando como rangos [0,1024] y [-90,90], la función

se encargará de obtener el ángulo en grados correspondiente15. Después, únicamente habrá que multiplicar por

π y dividir entre 180 para conseguir el ángulo en radianes.

Debido a la dificultad mecánica de medir al mismo tiempo los tres ángulos de la cadera, se ha optado por

medir únicamente el de extensión por ser el que más influye en la mayoría de movimientos, especialmente al

caminar.

6.2 Calibración del dispositivo de medidas.

Una vez construido el dispositivo, es necesario antes de utilizarlo es necesario calibrarlo para poder obtener

mediciones angulares correctas. Esto se debe a que cada potenciómetro, debido a defectos de fabricación,

presenta el tope mecánico (valor de resistencia mínimo o máximo) a un ángulo distinto y por lo general mayor

de 90º. Debido a esto, si utilizamos la función map indicando como rangos los mencionados en el apartado

anterior, los resultados obtenidos no se corresponderán con los ángulos reales. Para corregir esto, se sitúa cada

articulación sobre un patrón angular previamente dibujado con un transportador de ángulos, y se realizan

mediciones de la tensión del potenciómetro para un ángulo de 0º y de 180º. De esta forma se obtendrán los

valores máximos y mínimos exactos para un ángulo de entre 0 y 180º (o -90 y 90). Estos valores serán los que

se introducirán en la función map en el rango de valores del convertidor.

Ilustración 6-2: Procedimiento de calibración de los potenciómetros.

15 Para que esta conversión sea correcta el potenciómetro debe ser lineal, no logarítmico.

79

A continuación se muestra la parte del código que se encarga de tomar las medidas y transformarlas a radianes:

for(int i=0;i<3;i++);{

cadera_d = cadera_d +

(3.1415*map(analogRead(A5),min_cadera_d,max_cadera_d,-90,90))/180;

cadera_i= cadera_i+

(3.1415*map(analogRead(A2),min_cadera_i,max_cadera_i,90,- 90))/180;

rodilla_d = rodilla_d+

3.1415*map(analogRead(A4),min_rodilla_d,max_rodilla_d,90,-90)/180;

rodilla_i =rodilla_i+

3.1415*map(analogRead(A1),min_rodilla_i,max_rodilla_i,90,-90)/180;

tobillo_d = tobillo_d+

3.1415*map(analogRead(A3),min_tobillo_d,max_tobillo_d,-90,90)/180;

tobillo_i = tobillo_i+

3.1415*map(analogRead(A0),min_tobillo_i,max_tobillo_i,90,-90)/180;

}

cadera_d = ((int)(100*(cadera_d/ 3)))/100.00;

cadera_i = ((int)(100*(cadera_i/ 3)))/100.00;

rodilla_d = ((int)(100*(rodilla_d/ 3)))/100.00;

rodilla_i = ((int)(100*(rodilla_i/ 3)))/100.00;

tobillo_i = ((int)(100*(tobillo_i/ 3)))/100.00;

tobillo_d = ((int)(100*(tobillo_d/ 3)))/100.00;

Tanto el bucle for como las operaciones posteriores se utilizan para eliminar ruido de la medida.

6.3 Comunicación Arduino – ROS.

Una vez que se han obtenido los valores de las articulaciones, es necesario publicarlos en algún topic de ROS

para que puedan ser utilizados. Para ello, utilizaremos la librería llamada ros_lib y el paquete de ROS llamado

rosserial_arduino.

• ros_lib: se trata de una librería disponible para Python y C++ que incluye la mayoría de las estructuras

de datos presentes en ROS así como las herramientas que permiten generar mensajes, servicios e

interactuar con la red de ROS.

• rosserial_arduino: se trata de un paquete que implementa un protocolo de comunicación serie entre

ROS y Arduino, permitiendo la comunicación entre ambos.

A continuación se muestra un código de ejemplo en el que una placa Arduino se comunica con ROS para

enviar una cadena de caracteres a un topic.

#include <ros.h>

#include <std_msgs/String.h>

ros::NodeHandle nh;

std_msgs::String str_msg;

ros::Publisher chatter("chatter", &str_msg);

char hello[13] = "hello world!";


80

80

void setup()

{

nh.initNode();

nh.advertise(chatter);

}

void loop()

{

str_msg.data = hello;

chatter.publish( &str_msg );

nh.spinOnce();

delay(1000);

}

El código comienza incluyendo la librería ros.h (ros_lib), y el formato de mensaje que se enviará a ROS, en

este caso un mensaje de tipo std_msgs/String. Seguidamente, se crea un manejador de nodos. Este manejador

se encargará en la función setup( ) de inicializar el nodo de recepción de datos en ROS (nodo que recibe los

datos de Arduino y los publica en los topics deseados) y de crear o asignar a dicho nodo los topics donde se

publicará la información. Tras esto, es el momento de crear una variable de tipo std_msgs/String para

almacenar el mensaje y un topic llamado “chatter” que recibirá mensajes de tipo str_msg. Por último, en la

función loop( ), se guarda en el campo de datos de la variable str_msg el mensaje a enviar y se envía utilizando

chatter.publish( ) para acabar llamando a la función spinOnce( ) del manejador que se encarga de mantener la

comunicación.

Utilizando este código como referencia, se ha programado la parte del programa que se encargará de enviar la

información de los potenciómetros a ROS. El código sigue la misma estructura que el anterior, pero en lugar

de mensajes str_msg se envían mensajes Float64. El código completo del programa puede consultarse en el

Anexo B

Para que ROS pueda recibir los mensajes de Arduino, es necesario ejecutar un programa incluido en el paquete

rosserial_arduino que se encarga de crear el nodo que recibirá los mensajes de Arduino. Para ejecutarlo, con

el Arduino conectado al ordenador, escribimos lo siguiente en consola:

Rosrun rosserial_python serial_node.py

6.4 Ejecución de la simulación y resultados obtenidos.

Tras ejecutar la simulación del robot (en modo estático) junto con el programa en Arduino que envía las

referencias, se observó que el robot copiaba los movimientos realizados con una precisión aceptable. En las

siguientes imágenes puede verse dos posturas realizadas y las correspondientes posturas del robot:

81

Ilustración 6-3: Postura 1 a copiar por el robot.


82

82

Ilustración 6-4: Postura 2 a copiar por el robot.

Tras esto, se cargó de nuevo el modelo del robot esta vez sin estar fijo al mundo para comprobar si mantenía la

postura por sí solo copiando los movimientos del usuario. Lamentablemente, los resultados no fueron los

deseados. A los pocos segundos de comenzar la simulación, el robot caía al suelo debido a las vibraciones de

los motores ocasionadas por el ruido en la medida. Debido a esto, aunque también se recogieron datos de las

trayectorias articulares el robot no fue capaz de replicarlas con éxito.

83

7 CONCLUSIONES

Analizando los objetivos principales del proyecto, podemos extraer las siguientes conclusiones:

En primer lugar, el diseño del robot se ha realizado conforme a lo esperado, cumpliendo en la mayoría de los

parámetros las previsiones establecidas y respetando por tanto las proporciones anatómicas humanas. Este

éxito se debe en gran medida al análisis previo realizado tanto anatómica como biomecánicamente, ya que una

mejor comprensión de lo que se quiere diseñar facilita mucho el propio proceso de diseño.

Posteriormente, la realización de la descripción del robot también se realizó con buenos resultados, obteniendo

el visto bueno en todas las pruebas y verificaciones que se realizaron. El modelo en simulación por su parte

también se desarrolló satisfactoriamente, con todos los parámetros situados y definidos de manera correcta.

El control del robot ha sido otro de los puntos a favor en el proyecto debido a las buenas respuestas

conseguidas por parte de los actuadores. Tanto en el experimento de seguimiento de referencia como rechazo a

perturbaciones los resultados fueron bastante buenos, además de cumplir también con los valores límite de los

esfuerzos. Incluso al realizar el experimento de movimiento oscilatorio con perturbación el robot se comportó

de manera correcta.

Por último, se logró construir un sistema capaz de medir los ángulos articulares y, aunque finalmente no se

consiguieron resultados aceptables en la recolección de trayectorias debido al ruido, los experimentos de

movimiento en tiempo real del robot sí que generaron buenos resultados.

Bibliografía

84

84

8 BIBLIOGRAFÍA

[1] D. A. Winter, Biomechanics and Motor Control of Human Movement, Waterloo, Ontario, Canada:

WILEY, 2009.

[2] e. a. Charles E. Clauser, «WEIGHT, VOLUME, AND CENTER OF MASS OF SEGMENTS OF THE

HUMAN BODY,» NTIS, Ohio, 1969.

[3] R. N. Hinrichs, «ADJUSTMENTS TO THE SEGMENT CENTER OF MASS PROPORTIONS OF

CLAUSER et al. (1969),» J. Biomechanics, vol. 23, nº 9, pp. 949-951, 1990.

[4] «Wiki ROS,» [En línea]. Available: http://wiki.ros.org/ROS/Concepts.

[5] [En línea]. Available: http://wiki.ros.org/urdf/.

[6] [En línea]. Available: http://wiki.ros.org/urdf/XML/link.

[7] [En línea]. Available: http://wiki.ros.org/urdf/XML/joint.

[8] F.-R. C. Ming-Hsun Chiang, «Anthropomorphic Design of the Human-Like Walking Robot,» Journal of

Bionic Engieneering, 2013.

[9] V. y. G. M. Soto, «Parámetros inerciales para el modelado biomecánico del cuerpo humano,» Motricidad,

vol. 2, pp. 169-189, 1996.

[10] D. C. B. a. S. P. Azen, «Normal Range of Motion of Joints in Male Subjects,» The Journal of Bone and

Joint Surgery, Vols. %1 de %261-A, nº 5, 1979.

[11] [En línea]. Available: http://wiki.ros.org/xacro.

[12] [En línea]. Available: http://wiki.ros.org/joint_state_publisher.

[13] [En línea]. Available: http://wiki.ros.org/robot_state_publisher.

[14] [En línea]. Available: http://gazebosim.org/.

[15] [En línea]. Available: http://wiki.ros.org/ros_control.

[16] [En línea]. Available: http://wiki.ros.org/rosserial_arduino/Tutorials.

85

ANEXO A PLANOS Y MEDIDAS

Vistas y medidas:


86

86

Vista en perspectiva:

87

Ensamblaje de la cadera I:


88

88

Ensamblaje de la cadera II:

89

Ensamblaje de la cadera III:


90

90

Ensamblaje de la rodilla:

91

Ensamblaje del tobillo:

ANEXO B CÓDIGOS

92

92

ANEXO B CÓDIGOS

Código de configuración de los controladores:

piernas:

# Publish all joint states -----------------------------------

joint_state_controller:

type: joint_state_controller/JointStateController

publish_rate: 50

# Position Controllers ---------------------------------------

Extension_izquierdo_position_controller:


joint: Extension_izquierdo

pid: {p: 500.0, i: 15.0, d: 20.0}

Extension_derecho_position_controller:


joint: Extension_derecho

pid: {p: 500.0, i: 15.0, d: 20.0}

#====================================================

Abduccion_izquierdo_position_controller:


joint: Abduccion_izquierdo

pid: {p: 500.0, i: 15.0, d: 20.0}

Abduccion_derecho_position_controller:


joint: Abduccion_derecho

pid: {p: 500.0, i: 15.0, d: 20.0}

#====================================================

Rotacion_izquierdo_position_controller:


joint: Rotacion_izquierdo

pid: {p: 100.0, i: 10.0, d: 0.0}

Rotacion_derecho_position_controller:


joint: Rotacion_derecho

pid: {p: 100.0, i: 10.0, d: 0.0}

#=================================================

Rodilla_izquierdo_position_controller:


joint: Rodilla_izquierdo

pid: {p: 500.0, i: 4.0, d: 1.0}

Rodilla_derecho_position_controller:


joint: Rodilla_derecho

93

pid: {p: 500.0, i: 4.0, d: 1.0}

#=================================================

Tobillo_izquierdo_position_controller:


joint: Tobillo_izquierdo

pid: {p: 100.0, i: 10.0, d: 0.0}

Tobillo_derecho_position_controller:


joint: Tobillo_derecho

pid: {p: 100.0, i: 10.0, d: 0.0}

#=================================================

Código de Arduino:

#include <ros.h>

#include <std_msgs/Float64.h>

ros::NodeHandle nh;

std_msgs::Float64 msg_cadera_d;

std_msgs::Float64 msg_cadera_i;

std_msgs::Float64 msg_rodilla_d;

std_msgs::Float64 msg_rodilla_i;

std_msgs::Float64 msg_tobillo_d;

std_msgs::Float64 msg_tobillo_i;

ros::Publisher

cadera_d_chatter("piernas/Extension_derecho_position_controller/command",

&msg_cadera_d);

ros::Publisher

cadera_i_chatter("piernas/Extension_izquierdo_position_controller/command",

&msg_cadera_i);

ros::Publisher

rodilla_d_chatter("piernas/Rodilla_derecho_position_controller/command",

&msg_rodilla_d);

ros::Publisher

rodilla_i_chatter("piernas/Rodilla_izquierdo_position_controller/command",

&msg_rodilla_i);

ros::Publisher

tobillo_d_chatter("piernas/Tobillo_derecho_position_controller/command",

&msg_tobillo_d);

ros::Publisher

tobillo_i_chatter("piernas/Tobillo_izquierdo_position_controller/command",

&msg_tobillo_i);

int max_cadera_d=600;

int min_cadera_d=700-430;

int max_cadera_i=140+340;

int min_cadera_i=240;

int max_rodilla_i=580;

int min_rodilla_i=780-310;

ANEXO B CÓDIGOS

94

94

int max_rodilla_d=620;

int min_rodilla_d=720-460;

int max_tobillo_i=860;

int min_tobillo_i=170;

int max_tobillo_d=820;

int min_tobillo_d=220;

float cadera_d;

float cadera_i;

float rodilla_d;

float rodilla_i;

float tobillo_d;

float tobillo_i;

void setup()

{

//Serial.begin(9600);

nh.initNode();

nh.advertise(cadera_d_chatter);

nh.advertise(cadera_i_chatter);

nh.advertise(rodilla_d_chatter);

nh.advertise(rodilla_i_chatter);

nh.advertise(tobillo_d_chatter);

nh.advertise(tobillo_i_chatter);

}

void loop()

{

for(int i=0;i<3;i++);{

cadera_d = cadera_d +

(3.1415*map(analogRead(A5),min_cadera_d,max_cadera_d,-90,90))/180;

cadera_i=

cadera_i+(3.1415*map(analogRead(A2),min_cadera_i,max_cadera_i,90,- 90))/180;

rodilla_d =

rodilla_d+3.1415*map(analogRead(A4),min_rodilla_d,max_rodilla_d,90,-90)/180;

rodilla_i =rodilla_i+

3.1415*map(analogRead(A1),min_rodilla_i,max_rodilla_i,90,-90)/180;

tobillo_d =

tobillo_d+3.1415*map(analogRead(A3),min_tobillo_d,max_tobillo_d,-90,90)/180;

tobillo_i =

tobillo_i+3.1415*map(analogRead(A0),min_tobillo_i,max_tobillo_i,90,-90)/180;

}

cadera_d = ((int)(100*(cadera_d/ 3)))/100.00;

cadera_i = ((int)(100*(cadera_i/ 3)))/100.00;

rodilla_d = ((int)(100*(rodilla_d/ 3)))/100.00;

rodilla_i = ((int)(100*(rodilla_i/ 3)))/100.00;

tobillo_i = ((int)(100*(tobillo_i/ 3)))/100.00;

tobillo_d = ((int)(100*(tobillo_d/ 3)))/100.00;

95

msg_cadera_d.data = cadera_d;

msg_cadera_i.data = cadera_i;

msg_rodilla_d.data = rodilla_d;

msg_rodilla_i.data = rodilla_i;

msg_tobillo_d.data = tobillo_d;

msg_tobillo_i.data = tobillo_i;

cadera_d_chatter.publish(&msg_cadera_d);

cadera_i_chatter.publish(&msg_cadera_i);

rodilla_d_chatter.publish(&msg_rodilla_d);

rodilla_i_chatter.publish(&msg_rodilla_i);

tobillo_d_chatter.publish(&msg_tobillo_d);

tobillo_i_chatter.publish(&msg_tobillo_i);

nh.spinOnce();

cadera_d = 0;

cadera_i = 0;

rodilla_d = 0;

rodilla_i = 0;

tobillo_i = 0;

tobillo_d = 0;

}

Diseño y Simulación de Piernas para Robot...

Documents

Transcript of Diseño y Simulación de Piernas para Robot...