Habilidades_de_navegacion_para_el_robot

Outros

Ana Liz
em 09/04/2025
Material
Prévia do material em texto
1
2
3
4
Índice general
Índice general 5
Índice de figuras 9
Nomenclatura 11
Glosario 13
1. Introducción 17
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2. La importancia de la navegación . . . . . . . . . . . . . . . . . 18
1.3. Real vs Simulado . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4. Por qué ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2. Objetivos 21
3. Herramientas 23
3.1. ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1. Que es ROS . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.2. Conceptos Básicos . . . . . . . . . . . . . . . . . . . . 24
3.1.3. Diferencia entre los servicios, tópicos y acciones. . . . . 28
3.1.4. Comunicación en ROS . . . . . . . . . . . . . . . . . . 29
3.1.5. Como se instala ROS . . . . . . . . . . . . . . . . . . . 34
3.2. Gazebo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1. Que es Gazebo . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2. Caracteŕısticas . . . . . . . . . . . . . . . . . . . . . . 35
3.2.3. Como movemos un robot en Gazebo? . . . . . . . . . . 36
3.2.4. Como se conecta ROS con Gazebo? . . . . . . . . . . . 37
5
6 ÍNDICE GENERAL
3.2.5. Problemas con Gazebo . . . . . . . . . . . . . . . . . . 39
3.3. RVIZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1. Que es RVIZ . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.2. Como trabaja RVIZ . . . . . . . . . . . . . . . . . . . . 41
3.4. OMPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.1. Que es OMPL . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.2. Como se conecta OMPL con ROS . . . . . . . . . . . . 42
4. Ciclo de vida y Lenguajes de Programación 43
4.1. Ciclo de vida del Software . . . . . . . . . . . . . . . . . . . . 43
4.2. Lenguajes de Programación . . . . . . . . . . . . . . . . . . . 46
4.2.1. URDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2. XACRO . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.3. YAML . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.4. C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.5. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.6. XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . 49
5. Planificación, Costos y Licencias 51
5.1. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.1. Planificación WAM ARM . . . . . . . . . . . . . . . . 51
5.1.2. Planificación para IRI WAM . . . . . . . . . . . . . . . 52
5.2. Costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.1. Costos for WAM ARM . . . . . . . . . . . . . . . . . . 52
5.2.2. Costos para IRI WAM . . . . . . . . . . . . . . . . . . 54
5.2.3. Costo para el Robot . . . . . . . . . . . . . . . . . . . 55
5.2.4. Costos por la Memoria . . . . . . . . . . . . . . . . . . 55
5.3. Licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.1. Licencia BSD . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.2. Licencia LGPL . . . . . . . . . . . . . . . . . . . . . . 56
6. Especificación y Diseño 59
6.1. Especificación . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7. Stack WAM ARM: Primer Contacto 63
7.1. Códigos Gúıa: Wubble Robot y PR2 robot . . . . . . . . . . . 63
7.2. Licencia para WAM ARM . . . . . . . . . . . . . . . . . . . . 63
ÍNDICE GENERAL 7
7.3. Especificación y Diseño para WAM ARM . . . . . . . . . . . . 64
7.3.1. Análisis de Requerimientos . . . . . . . . . . . . . . . . 65
7.4. Diagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.4.1. Diagrama de Despliegue . . . . . . . . . . . . . . . . . 67
7.4.2. Diagramas de Componentes . . . . . . . . . . . . . . . 68
7.5. Descripción de los Packages . . . . . . . . . . . . . . . . . . . 70
7.5.1. wam arm gazebo . . . . . . . . . . . . . . . . . . . . . 70
7.5.2. wam arm kinemtaics . . . . . . . . . . . . . . . . . . . 71
7.5.3. wam arm teleop . . . . . . . . . . . . . . . . . . . . . 72
7.5.4. wam arm interface . . . . . . . . . . . . . . . . . . . . 72
7.5.5. wam arm action . . . . . . . . . . . . . . . . . . . . . 72
7.6. Efectos de una inadecuada documentación . . . . . . . . . . . 73
7.7. Conclusión para WAM ARM . . . . . . . . . . . . . . . . . . . 73
8. Stack IRI WAM: Luz al final del Tunel 77
8.1. Por que cambiar el WAM ARM por IRI WAM? . . . . . . . . 77
8.2. Licencia para IRI WAM . . . . . . . . . . . . . . . . . . . . . 78
8.3. Especificación y Diseño para IRI WAM . . . . . . . . . . . . . 78
8.3.1. Análisis de Requerimientos . . . . . . . . . . . . . . . . 78
8.4. Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.5. Package Description . . . . . . . . . . . . . . . . . . . . . . . . 80
8.5.1. iri wam arm navigation . . . . . . . . . . . . . . . . . 80
8.5.2. iri wam bringup . . . . . . . . . . . . . . . . . . . . . 86
8.5.3. iri wam controllers . . . . . . . . . . . . . . . . . . . . 86
8.5.4. iri wam description . . . . . . . . . . . . . . . . . . . 90
8.5.5. iri wam gazebo . . . . . . . . . . . . . . . . . . . . . . 92
8.5.6. iri wam wrapper . . . . . . . . . . . . . . . . . . . . . 93
8.6. Conclusion for IRI WAM . . . . . . . . . . . . . . . . . . . . . 93
9. Experimentos 95
9.1. Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.1.1. Experimentos con Gazebo . . . . . . . . . . . . . . . . 95
9.1.2. Experimentos con el robot WAM ARM . . . . . . . . . 97
9.2. Conclusiones de los Experimentos . . . . . . . . . . . . . . . . 98
10.Conclusión 99
11.Trabajo Futuro 101
8 ÍNDICE GENERAL
Agradecimientos 103
Bibliograf́ıa 105
Índice de figuras
3.1. Interacción Cliente/Servidor de las Acciones . . . . . . . . . . 27
3.2. Diagrama de estados de las Acciones . . . . . . . . . . . . . . 29
3.3. Ejemplo Comunicación TCPROS . . . . . . . . . . . . . . . . 30
3.4. Ejemplos de modelos en Gazebo . . . . . . . . . . . . . . . . . 35
3.5. Plugin Estático Gazebo . . . . . . . . . . . . . . . . . . . . . . 37
3.6. Plugin Dinámico Gazebo . . . . . . . . . . . . . . . . . . . . . 37
3.7. Ejemplo de uso de RVIZ . . . . . . . . . . . . . . . . . . . . . 40
3.8. Ejemplo de solución a un problema con OMPL . . . . . . . . . 41
4.1. Modelo de Cascada . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2. Modelo de Prototipaje . . . . . . . . . . . . . . . . . . . . . . 44
4.3. ROS Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4. Oren Ben-Kiki . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5. Bjarne Stroustrup . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6. John McCarthy . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7. Dave Winer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1. Wuuble Robot . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2. Ejemplo Diagrama de Despliegue . . . . . . . . . . . . . . . . 67
7.3. Diagrama de Despligue para WAM ARM . . . . . . . . . . . . 69
7.4. Diagrama de Componentes y sus Dependencias paraWAM ARM 70
8.1. Diagrama de Despligue para IRI WAM . . . . . . . . . . . . . 80
8.2. Código Fuente de iri wam planning description.yaml . . . . . . 81
8.3. Extracto de código fuente de joint limits.yaml . . . . . . . . . 82
8.4. Extracto de código fuente de ompl planning.yaml . . . . . . . 82
8.5. Extracto código fuente de ompl planning.yaml . . . . . . . . . 82
8.6. Extracto código fuente de ompl planning.yaml . . . . . . . . . 83
9
10 ÍNDICE DE FIGURAS
8.7. Extracto de código fuente de iri wam pr2 controller.yaml . . . 87
8.8. Extracto de código fuente de iri wam pr2 controller.yaml . . . 87
8.9. Extracto de código fuente de wam1.urdf.xacro . . . . . . . . . 88
8.10. Extracto de código fuente de wam1.urdf.xacro . . . . . . . . . 88
8.11. Extracto de código fuente de wam1.urdf.xacrorequerimientos, a con-
tinuación muestro resultados:
Con respecto a la cinemática fue conseguido la separación de
tareas, tambien, el intercambio se ha medianamente conseguido
ya que a pesar que el cambio es reemplazar una linea,este no
sigue la filosofia de ROS.
La interfaz de usuario es bastante amigable, no es necesario la
aapertura de varias terminales.
Los objetivos para el simulador, no se consiguieron, el detalle a
continuación:
1. Si bien es cierto, el robot se mueve como se le indica, pero
no esta simulando la realiadad, ya que el moviemiento de
un robot se genera en los joints, en cambio , en el simulador
lo que se hacie era reposicionar el link involucrado.
2. He creado una gran dependencia entre package, ya que el
simulador utiliza la cinemática directa para posicionar el
robot.En otras palabras,utilizo ¡t,q̂¿para mover el robot,
pero en realidad lo debiera mover el robot es[θ1 θ2 θ3 θ4 θ5
θ5 θ7]
3. Solo genera moviemientos simples, sin evitación de obstacu-
los
7.7. CONCLUSIÓN PARA WAM ARM 75
Además, nunca se llego a probar en el robot real. En difinitiva,
nunca se publicaron.
76 CAPÍTULO 7. STACK WAM ARM: PRIMER CONTACTO
Caṕıtulo 8
Stack IRI WAM: Luz al final
del Tunel
8.1. Por que cambiar el WAM ARM por IRI WAM?
Este cambio se debio a diversos factores, que detallo a conti-
nuación:
1. Los errores conceptuales en WAM ARM, provocaron que
este se convirtiera en un stack de aprendizaje
2. El stack WAM ARM, era un desarrollo independiente de
los stack del IRI
3. El Instituto decidió hacer publico sus repositorios de ROS,
hecho que obligó toda una reestructuración de los reposito-
rios
4. el stack WAM ARM fue creado en la versión diamondback
de ROS, Pero en Septiembre del 2011, ROS lanza su nueva
versión Electric
77
78 CAPÍTULO 8. STACK IRI WAM: LUZ AL FINAL DEL TUNEL
8.2. Licencia para IRI WAM
Todos los repositorios de ROS creados por el laboratorio de
robotica y por el laboratorio de manipulación y percepción, am-
bos pertenecientes al IRI, se les han otorgado la licencia LGPL
5.3.2 para el nuevo stack IRI WAM. Sin embargo, mi deseo que
los códigos estén abiertos para todos, y le he asignado la licen-
cia BSD 5.3.1, lo cual permite al Instituto,a la copia que tengan
ellos relicenciarla a LGPL 5.3.2 Actualemente, los códigos son
accesibles desde internet, para quién quiera utilizarlos. Ver las
referencias 5.3.2 5.3.1
8.3. Especificación y Diseño para IRI WAM
En este apartado mostrate la especificación y el diseño del
stack IRI WAM.
8.3.1. Análisis de Requerimientos
El Análisis se devide en 2 partes: Análisis de requerimientos
funcionales y Análisis de requerimientos no funcionales. ver el
significado en 7.3.1
Requerimientos Funcionales
1. Cada package debe contener el código necesario para llevar
a cabo la tarea asignada
2. Cada nodo creado debe representar una acción espećıfica
en robot
8.3. ESPECIFICACIÓN Y DISEÑO PARA IRI WAM 79
3. Cada package debe ser capaz de leer un mensaje deter-
minado con los datos necesarios para completar la tarea
asignada
4. El sistema debe ser capaz de calcular la cinemática inversa
de robots con diferentes grados de libertad
5. Los package deben ser fácilmente reemplazables
6. El sistema debe generar trayectorias consistentes
7. El sistema debe conectarse correctamente con ROS
8. Los códigos deben ser eficientes
9. El sistema debe conocer las limitaciones mecánicas del ro-
bot
10. Las trajectorias deben estar dentro de los limites del robot
11. La navegación debe ser capaz de sortear obstáculos
12. El sistema debe reutilizar codigo del PR2
13. El sistema debe mantener la arquitectura y filosofia de ROS
14. El simulador debe comportarse de la misma manera que el
robot real
15. El simulador debe tener el maximo de propiedades simula-
das posibles.
Requirimientos No Funcionales
1. Debe ser bastante amigable de cara al usuario.
2. El usuario debe conocer lo justo para ejecutar el sistema
3. Evitar el uso de demasiadas consolas
80 CAPÍTULO 8. STACK IRI WAM: LUZ AL FINAL DEL TUNEL
8.4. Diagrama
Figura 8.1: Diagrama de Despligue para IRI WAM
Diagrama de Despligue final para los package en IRI WAM
8.5. Package Description
8.5.1. iri wam arm navigation
Este package contiene 2 directorios
1. Config
2. Launch
8.5. PACKAGE DESCRIPTION 81
Estos directorios contienen la configuración necesaria para que
el stack de navegación funcione con la configuración del WAM
ARM
Config
En este directorio estan almacenados los ficheros de configu-
ración , escritos en YAML o VCG, Los ficheros tiene la reponsa-
bilidad de cargar los datos en el servidor de parametros para que
los nodos ROS puedan utilizarlos,tambien se pueden modifcar y
eliminar A continuación detallo los ficheros:
Figura 8.2: Código Fuente de iri wam planning description.yaml
iri wam planning description.yaml En este fichero se defi-
nen el grupo de joints a utilizar,las operaciones a seguir si
82 CAPÍTULO 8. STACK IRI WAM: LUZ AL FINAL DEL TUNEL
Figura 8.3: Extracto de código fuente de joint limits.yaml
Figura 8.4: Extracto de código fuente de ompl planning.yaml
Figura 8.5: Extracto código fuente de ompl planning.yaml
hay colisión, como conectarse a otro grupo de joints.En la
figura 8.2muestro el codigo fuente de este fichero.
lineas 1 hasta 5,Aqui defino como se conecta un grupo
de joints con el mundo o con otro grupo de joints
de lineas 6 hasta 9, Aqui defino el nombre para el grupo
de joints y cual de los links es la base y cual es la punta
de lineas 10 hasta el final, Aqui defino las operaciones
a seguirn en caso de colisión
8.5. PACKAGE DESCRIPTION 83
Figura 8.6: Extracto código fuente de ompl planning.yaml
joint limits.yaml En este fichero defino los limites de veolcia-
dad, posición y aceleración , para cada joint que conforma
la cadena cinemática,y también inicializo los flags que indi-
can la existencia de estos limites,En la figura8.3 Un extracto
del codigo que he implementado
planning components visualizer.vcg Este fichero es gene-
raco automaticamente al guardar un escenario de RVIZ,
guarda toda la configuración generada para ese escenario.
84 CAPÍTULO 8. STACK IRI WAM: LUZ AL FINAL DEL TUNEL
ompl planning.yaml Este fichero carga todas las variables ne-
cesarias po rle planificador OMPL
Al planificador se le especifica una configuración de
planificación. Una configuración especifica planificación
particular del uso y los parámetros de configuración
asociados con el uso de la misma. En el extracto en la
figura 8.4 , se muestra cómo se configura un planificador
mediante el uso de SBL y el otro para un planificador
con LBKPIECE.
El segundo paso consiste en especificar los grupos ,a los
cuales desea planificar la trayectoria. En la figura 8.4,
se muestra como se definen dos grupos para el planifi-
cador.
iri wam Para este grupo ,en la figura 8.5, se define
qué tipo de planificador (en este caso JointPlan-
ner) , también, las configuraciones permitidas, fi-
nalmente, definir la proyjection evaluator, En otras
palabras, donde leer la posición del robot, para esto
se utiliza el tópico joint state
iri wam cartesian Para este grupo,en la figura 8.6,se
define qué tipo de planificador (para este caso Car-
tesian Planner), se define el espacio ,como se mues-
tra en la figura 8.6,donde se define los ejes X,Y,Z y
los ejes de rotación r̂,p̂,ŷ. Y por ultimo se especifica
el tipo de plugin cinemático a usar para el calculo
de la cinemática inversa. Para este caso
arm kinematics constraint aware/KDLArmKinematicsPlugin
8.5. PACKAGE DESCRIPTION 85
Launch
Estos son los ficheros que crean los nodos, pero que también
pueden crear/modificar variables del servidor de parámetros
trajectory filter server.launch En este fichero,se cargan las
variables necesarias para ser utilizadas por el package tra-
jectory filter
ompl planning.launch En este fichero, Se crea el nodo de
OMPL, se cargan las variables que necesita este para fun-
cionar , y se inicializanvalores por defecto del planificador
move groups.launch Este fichero, llama a otro fichero launch
(move iri wam.launch). La eexplicación es muy sencilla, ya
que en vez, de modificar el fichero en cuestion, lo dejamos
intacto, y solo es neesario cambiar el nombre del fichero que
se llama.
move iri wam.launch Este fichero crea el nodo de move arm,es
este quien coencta el stack de navegación y con el robot(caulquier
tipo real o simulado)
iri wam planning environment.launch Este fichero no crea
ningun tipo de nodo, solo carga los datos contenidos en el
fichero iri wam planning description.yaml en el servidor de
parametros.
constraint aware kinematics.launch Este fichero carga e ini-
cializa las variables que utiliza el nodo de cinemática.
en ellos se especifica que plugin utilizo ycual link es la base
y cual es elink punta.
iri wam arm nagigation.launch Este es el fichero principal,
llama a todos los ficheros launch explicado anteriormente.
86 CAPÍTULO 8. STACK IRI WAM: LUZ AL FINAL DEL TUNEL
y este a su vez es llamado desde el fichero de launch de los
robots (package iri wam bringup)
8.5.2. iri wam bringup
Este paquete contiene los archivos para crear los nodos de
los robots y todo su sistema de comunicación con el stack de
navegación.
contiene un directorio launch, con 2 ficheros:
iri wam sim bringup.launch Este lanza el robot simulado ,
emprende varias acciones
1. Llama a iri wam description.launch
2. Carga la variable controller action name,que es la que
se utiliza para conectarse con el nodo de move iri wam
3. Llama a iri wam gazebo.launch
4. Carga el plugin dinamico de Gazebo para poder mover
los joints del robot,este esta encapsulado en el package
pr2 controller.
5. Finalmente se llama iri wam arm navigation.launch.
iri wam real bringup.launch Este fichero crea el nodo que
hace que se comuniquen el robot real y el stack de navega-
ción. Como este se debe adaptar a la interficie ya creada del
WAM , se utiliza la herramienta ”dynamic reconfigure”que
permite cambiar nombres en tiempo de ejecución.
8.5.3. iri wam controllers
Este package contiene un directorio llamado config y dentro
de este un fichero llamado iri wam pr2 controller.yaml,con to-
8.5. PACKAGE DESCRIPTION 87
Figura 8.7: Extracto de código fuente de iri wam pr2 controller.yaml
Figura 8.8: Extracto de código fuente de iri wam pr2 controller.yaml
dos los valores necesarios para que el plugin dinámico de ROS
para Gazebo funcione con el WAM simulado Cabe destacar, que
un controller equivale a un actuador en la realidad.Y por este
88 CAPÍTULO 8. STACK IRI WAM: LUZ AL FINAL DEL TUNEL
Figura 8.9: Extracto de código fuente de wam1.urdf.xacro
Figura 8.10: Extracto de código fuente de wam1.urdf.xacro
Figura 8.11: Extracto de código fuente de wam1.urdf.xacro
motivo, es que debo definir valores de PID para cada joints.La
creacion de estos controladores es automatica ya que ROS ob-
tiene esa información de las variables cargadas desde este mismo
8.5. PACKAGE DESCRIPTION 89
Figura 8.12: Extracto de código fuente de wam1.urdf.xacro
yaml, ver 8.7 y 8.8. En la figura 8.7 cargamos los datos al con-
trolador.
Linea 1 es el nombre del nodo para el controlador
Linea 2 es el nombre del package a utilizar y el nombre del
controlador a utilizar.Cabe destacar que robot mechanism controllers
es un paquete perteneciente al pr2 controllers. Sin este, el
primer package no puede funcionar.
Linea 3 hasta la 10 listo todos los joint que usarán este
controlador
Linea 11 hasta la 18 se configura la PID para cada actuador.
En la figura 8.8 cargo las variable de tiempos para cada joint.
Los controladores se ejecutan en background, el usuario solo in-
dica cual se debe utilizar. Cabe destacar que basandome en esto
controladores, propuese el crear un controlador para el wam que
a su vez, utilizara la API del WAM. pero despues de un tiempo
evaluando y programando, se desechó esta idea.ya que el con-
trolador, exige que sea transparetne al usuario en cambio, el
controlador del WAM, por razones de seguridad, exige la inter-
acción humano-maquina para arrancar el sistema.
90 CAPÍTULO 8. STACK IRI WAM: LUZ AL FINAL DEL TUNEL
8.5.4. iri wam description
Este package, junto con iri wam gazebo, fueron los package
que sufrieron mayor cantidad de cambios durante la ejecución
del proyecto.
Este package se divide en 4 directorios
Launch Este subdirectorio contiene los ficheros launch, en la
actualidad existen 2
cylinder.launch este fichero crea una vara como obstaculo en Gazebo
iri wam description.launch Carga la definición del robot en la variable robot description.
Mesh En este subdirectorio se almacenan todos los ficheros
MESH utilizados en la simulación (.stl), cada fichero MESH
describe una pieza del robot
Urdf Este subdirectorio contiene el fichero URDF(.urdf) con
todas las piezas y el plugin en un unico fichero, se auto-
genera desde xacro.
Xacro Este subdirectorio contiene los ficheros XACRO(.xacro)que
definen el robot. Existen tantos ficheros xacro como DOF
tenga el robot. El fichero wam.urdf.xacro es el fichero princi-
pal con el cual se construye el robot. En las figuras 8.9,8.10,8.11,8.12,
se muestra un extraacto de estos ficheros
En la figura[8.9], defino un link con nombre wam fk/wam1. No-
tar, que dentro del tag , 3 importantes.
inertial Aqui defino los valores necesarios para generar iner-
cia, por ejemplo, la masa de la pieza o los valores de los
momentos de inercia.
8.5. PACKAGE DESCRIPTION 91
visual Aqui se definen los parametros para la parte visual ,por
ejemplo que fichero mesh se utiliza, y el punto de origen de
la pieza.
collision Aqui se definen los valores para la colisión con objetos,
por ejemplo, el coeficionte de friccion,que fichero mesh se
utiliza en caso de colision.
En la figura [8.10], es para cambiar el color de las piezas
del robot en simulación. En general, se puede cambiar color,
coeficiente de fricción,agregar sensores,etc.
En la figura [8.11], se define un joint con nombre j1 joint.
Existen diversos tipos de joints, que a continuación detallo.
de revolución
fijos
flotantes
continuos
prismaticos
planar
Para este caso, se define un joint de revolución.
Luego defino que link es el padre del joint, que link es el hijo
del joint, los limites del mismo, las propiedades dinamicas del
robot,
En la figura 8.12, defino una transmisión simple de nombre
j1 transmission para el joint j1 joint. una transmisión es pa-
so de moviemiento desde un actuador hacia un joint. También,
defino constantes mecánicas.
Cabe destacar, que xacro y urdf , aunque se ven muy similares,
92 CAPÍTULO 8. STACK IRI WAM: LUZ AL FINAL DEL TUNEL
no tienen el mismo comportamiento. El fichero urdf define un
robot pero todo lo que sea externo al mismo, por ejemplo los
ficheros mesh, deben estar en el mismo package.
Por otra parte, XACRO , genera el fichero urdf, pero su cualidad
mas clara, es que permite unir distintos fragmentos de codigos
(en xacro por supuesto) ubicados en distintos package. Lo cual
es basstante útil, a la hora de poner herramientas al robot.
8.5.5. iri wam gazebo
En este package contiene la codificación necesaria para juntar
el plugin dinámico de ROS y el robot simulado, entre otras cosas.
Este se subdivide en 3 directorios:
launch: Este subdirectorio, contiene los siguientes ficheros launch:
iri wam gazebo.launch: Inicializa el simulador Gazebo,
y carga la definición del robot contenida en robot description
,en el simulador.
spawn vertical stick.launch: Este introduce obstaculos
en Gazebo.
src: En este subdirectorio se encuentra el codigo, que mediante
el tópico , le comunica al stack de na-
vegación la posición de un obstaculo y las dimensiones de
este.
xacro: Este subdirectorio contiene el fragmento de codigo, me-
diante la cual, introduzco en el urdf final la definición del
controlador de ROS
8.6. CONCLUSION FOR IRI WAM 93
Figura 8.13: Codigo fuente de tipo launch de iri wam wrapper
8.5.6. iri wam wrapper
Este packageya exist́ıa en el stack de IRI WAM, es respon-
sable de comunicar el robot fisico con ROS. También publica
información sobre el estado del mismo Internamente, se comuni-
ca con el robot mediante ethernet, The internally communicates
with the robot through both ethernet.Por lo tanto es necesario
saber la ip.
La ejecución se realiza en 2 pasos
1. En un terminal se ejecuta roscore.
2. En otro terminal se ejecuta el fichero compilado iri wam wrapper
Esto no es eficiente, ya que , cada vez que deseaba cambiar de
robot, debia recompilar el codigo. El trabajo que realicé en este
paquete, fue la creación de un fichero launch que me permitiera
intermcambiar los robots sin necesidad de recompialr el codigo.
En la figura 8.13, se puede observar este fichero.
8.6. Conclusion for IRI WAM
Como conclusión de este desarrollo, podemos decir que los
requisitos se cumplieron ampliamente. Por ejemplo, el stack de
94 CAPÍTULO 8. STACK IRI WAM: LUZ AL FINAL DEL TUNEL
navegación solo es necesario definir una unica variable para co-
nectarse con algun robot, por ende,el intercambio entre el robot
reale y simulado es transparente, ya el package es iri wam brinup
se encarga de actualizar esta variable.El robot se mueve con pre-
cisión, además de los ĺımites establecidos para cada articulación.
En la simulación se han agregado tantas propiedades del ro-
bot real, que funciona y se mueve con mucha similitud al real.
Como conclusión personal, debo decir que este desarrollo, ha
puesto en práctica ,y mejorar, todos los conocimientos obtenidos
durante el primer desarrollo de este proyecto. Fueron también
más seguidas las reuniones,debates,donde pude dar opiniones,
dar ideas, y con un conocimiento más firme de los temas. Tam-
bién debo señalar , que las decisiones fueron mucho más exitosas
que la primera vez.
Caṕıtulo 9
Experimentos
9.1. Experimentos
En esta sección explicaremos, los experimentos a que fueron
sometidos los códigos
9.1.1. Experimentos con Gazebo
El primer experimento con el robot simulado era muy sim-
ple, ya que el propósito de este es para comprobar la conexión
entre los nodos de ROS.En este experimento, hemos creado un
nodo cliente, que recibió el estado del robot desde gazebo y lo
imprimió en la pantalla.
Después de pasar el primer experimento,la segunda prueba se
realizó para mover el robot en una trayectoria simple,sin evita-
ción de obstaculos, desde un punto de partida (posición actual),
a un punto B. Este experimento se repitió varias veces hasta
conseguir un movimiento correcto de los joints. Después de que
el robot se moviera correctamente, se repitió el segundo experi-
mento muchas veces,con la diferencia de cada nueva ejecución se
95
96 CAPÍTULO 9. EXPERIMENTOS
trató de simular una nueva propiedad, hasta conseguir simular
el maximo de propiedades.
El tercer experimento se hace mover el robot simulado en di-
ferentes puntos (de A a B, B a C, etc) y en este se le agrega el
factor tiempo
A continuación, el cuarto experimento consistió en mover el
robot a un punto cualquiera pero violando los limites de los
joint, asi comprobar el comportamiento del simulador. Después
de esto, dentro de una trayectoria se colocaba posiciones inal-
canzables y puntos alcanzables.
Cabe destacar, todos los experimentos mencionados anterior-
mente fueron realizados sin evitación de obstaculos y sin conec-
tar el stack de navegación.
En el primer experimento con el stack de navegación, es muy
simple, es pasar de su posición actual hasta un punto A.Me gus-
taria recordar que el stack de navegación entrega una serie de
puntos que el robot debe tratar de seguir.
El segundo experimento fue similar al anterior, excepto que los
puntos de destino fueron los puntos inalcanzables para el ro-
bot, de esta manera, hemos podido probar y verificar el correcto
funcionamiento del planificador. El tercer experimento trata de
evitar obstáculos de un tamaño considerable en la mitad tra-
yectoria, al final, esta obstáculos se ubican en diferentes lugares
dentro de la trayectoria del robot. El cuarto experimento es que
el robot se mueva en un entorno con varios obstáculos en el
camino.
9.1. EXPERIMENTOS 97
9.1.2. Experimentos con el robot WAM ARM
El primer experimento fue obtener datos de robot real para
verificar la correcta conexión entre los nodos de ROS.
Luego vino el segundo experimento, que fue mover el robot des-
de su posición actual hasta un punto B, a continuación, una
trayectoria simple.
Cabe destacar lo siguiente:
Para la comunicación con el robot real, es utilizada la in-
terfaz para la comunicación con el hardware creada por el
IRI.
No se hizo la prueba de ir mas alla de los limites, ya que,
el robot contine su propio sistema de seguridad
Los experimentos anteriores wam real fueron trayectorias
simples.
Por último, he probado robot WAM real con el stack de na-
vegación. La primera prueba fue simple, era ir al punto B, desde
su posición actual. Aqúı me encontré con un problema, ya que
la interfaz de comunicación del IRI, no aceptar la trayectoria
(como una colección de puntos), por el contrario, aceptaba uni-
camente puntos muy separados.Esto obligó al IRI implementar
una nueva interfaz de comunicación al robot, para que pudiese
trabajar con trayectorias( colección de puntos)
Más tarde, al volver a ejecutar la prueba usando las nuevas in-
terfaces, nos hemos encontrado con otro problema, ya estaba
relacionado con el numero de puntos entregados por el planifi-
cador. El robot tiene un ciclo de procesamiento de 500 [Hz], en
otras palabras, 500 posiciones en 1 segundo, y el stack solo pro-
porciona 89 puntos. El IRI tuvo que implementar una interfaz
98 CAPÍTULO 9. EXPERIMENTOS
con spline para poder generar los puntos restantes.
Al final se ha puesto a prueba la trayectoria del robot, pero con
la generación de un obstáculo en el camino Y para terminar los
experimentos se generó a partir de un escenario con múltiples
obstáculos.
9.2. Conclusiones de los Experimentos
Como conclusión de los experimentos de simulación, se puede
decir que fueron muy útiles para ver > el compor-
tamiento del robot, afinar detalles, ajustar los valores de alguna
propiedad,para que el simulador actuara de la misma manera
que el robot verdadero.
Utilizado para los experimentos con el robot real fueron muy
útiles por varias razones.
Primero se demostró que los códigos se pudo conectar con el
robot real, sin mayores complicaciones. También muestran que
el robot de cambio es transparente para el stack de navegación.
También gracias a estos experimentos, los códigos se puede me-
jorar el IRI, que ofrece nuevas interfaces de comunicación.
Sin olvidar el objetivo centrar de todos estos experimen-
tos,que es demostrar que el stack de navegación funciona con
el WAM ARM
Caṕıtulo 10
Conclusión
Antes de dar la conclusión final para el proyecto, primero me
gustaŕıa repasar y contrarestar los objetivos con los resultados
obtenidos.
1. Para el primer objetivo, simular el robot en Gazebo,los re-
sultados fueron muy satisfactorios. ya que el alcanze final
sobrepaso al objetivo en si, al lograr unir los ficheros de
definición del robto real y el simulado en un unico fichero
2. Para el segundo objetivo,conectar el stack de navegación,
los resultados son satisfactorios. A pesar de la densa docu-
mentación se logro conectar y modificar las variables nece-
sarias para conectar el stack de navegación
3. Para el tercer objetivo,conectar el simulador Gazebo con
el stack de navegación y generación trayectorias simples,
Los resultados son satisfactorios, el robot simulado sigue la
trajectoria respetando sus limites.
4. Para el cuarto objetivo,conectar el robot real con el stack
de navegación y generación trayectorias simples, Los resul-
99
100 CAPÍTULO 10. CONCLUSIÓN
tados son satisfactorios, el robot sigue la trajectoria respe-
tando sus limites.
5. Para el quinto objetivo,conectar el simulador Gazebo con
el stack de navegacióny generación trayectorias evitando
obstáculos, Los resultados son satisfactorios, el sigue la tra-
jectoria respetando sus limites y evitando los obstaculos sin
problemas.
6. Para el sexto objetivo,conectar el robot real con el stack
de navegación y generación trayectorias evitando obstácu-
los, Los resultados son satisfactorios, el sigue la trajectoria
respetando sus limites y evitando los obstaculos sin proble-
mas.
7. Para el séptimo objetivo,crear un mecanismo de intercam-
bio sin obstáculos, los resultados fueron bastante acepta-
bles, ya que, si cambiamos en tiempo de ejecución el tipo
de robot, debe hacer uso del ”dynamic reconfigure”para co-
nectar el stack de navegación con el nuevo robot.
8. Para el octavo objetivo,crear un mecanismo de intercambio
con obstáculos, los resultados fueron bastante aceptables,
ya que, si cambiamos en tiempo de ejecución el tipo de ro-
bot, debe hacer uso del ”dynamic reconfigure”para conectar
el stack de navegación con el nuevo robot.
Después de comparar los resultados obtenidos, puedo concluir
que los objetivos fueron alcanzados, algunos mas alla del pro-
pio objetivos, y otros a un nivel aceptable. De hecho, en estos
momentos, mis codigos ya se encuentran publicados junto al re-
positorio del IRI,
Caṕıtulo 11
Trabajo Futuro
Tal cual como han quedado los packages en la actualidad,se
abre un sinfin de posibilidades, sobre todo al simulador.
por ejemplo se puede simular una camara TOF (por ejempo
swissranger) o una depht camara (como PMD o Kinect) para
coger lecturas del entorno del robot. Esto ayudaria mucho en
proyectos como .Estirabot”, al poder simular todo.
Con el tiempo, se puede simular las camaras NIR que ayudarian
al Proyecto ”Garnics”
Por otro lado, la simulación, nos permite tener 2 o mas robots
dentro de un mismo entorno, creando un escenario preciso para
trabajos colaborativos, También, seŕıa posible, simular un robot
Tambien en un tiempo mas cercano, es posible simular las
distintas herramientas que utiliza el WAM, asi se pueden hacer
prubas con el simulador.
101
102 CAPÍTULO 11. TRABAJO FUTURO
Agradecimientos
En las siguientes lineas, es de mi agrado plasmar agradecimien-
tos a todas aquellas personas, que de una manera u otra, han
contribuido en la realización de este proyecto
A mi hermano Oskar, por ser mi fuerza en tiempo de desanimo,
por ser una persona muy especial,que siempre da amor y cariño
de forma silenciosa espontanea.
A mi madre Roxanna, a Juan Carlos, y en general, a toda mi
familia, por su inestimable e incondicional apoyo tanto en la
alegria y en la adversidad, me dieron ánimos cuando deprimia y
dieron fuerzas cuando flaqueba .
A mi director de proyecto Guillem Alenya por permitirme tra-
bajar en este proyecto, y ser guia ante mis dudas
A mis copañeros y amigos del I.R.I. que soportaron intensas y
extensas jornadas de preguntas,ayudandome a profundizar en
temas de robotica, como son Sergi Foix, Edgar Simó, José Luis
Riveros y Diego Pardo, y sin olvidar a mi director.
A mis compañeros y amigos David Perez, Manel Peirato, y a mi
amiga Paola Sanchez, por darme fuerzas y animos para seguir
adelante.
103
104 Agradecimientos
Bibliograf́ıa
[1] Institute of Robotics and Industrial Informatics
(IRI), www.iri.upc.edu/
[2] Robot Operating System(ROS ), www.ros.org
[3] Answer List Of ROS, answers.ros.org/questions/
[4] Mail List Of ROS,
code.ros.org/lurker/list/ros-users.html/
[5] Help Ubuntu home page, help.ubuntu.com/
[6] Yet Another Robot Platform(YARP),
eris.liralab.it/yarp/
[7] Open Robot Control Software(OROCOS ),
www.orocos.org/
[8] Carnegie Mellon Robot Navigation
Toolkit(CARMEN ), carmen.sourceforge.net/
[9] Orca:Components for Robotics(ORCA),
orca-robotics.sourceforge.net/
[10] Cross Platform Software for Robotics
Research(MOOS ),
www.robots.ox.ac.uk/ mobile/MOOS/wiki/pmwiki.php/
105
106 BIBLIOGRAFÍA
[11] Microsoft Robot Studio,
msdn.microsoft.com/en-us/robotics/default.aspx/
[12] Player Project, playerstage.sourceforge.net/
[13] PR2 Robot,
www.willowgarage.com/pages/pr2/overview/
[14] PR2 Robot EtherCAT devices,
www.ros.org/wiki/pr2 etherCAT/
[15] PR2 Robot ,
www.willowgarage.com/blog/2009/06/10/orocos-rtt-and-
ros-integrated/
[16] Install ROS
,www.ros.org/wiki/electric/Installation/Ubuntu/
[17] Gazebo simulator,
playerstage.sourceforge.net/doc/Gazebo-manual-svn-html/
[18] Willow Garage, www.willowgarage.com/
[19] Unified Robot Description Format(URDF ),
www.ros.org/wiki/urdf/
[20] Dynamic Plugin fro Gazebo of PR2,
www.ros.org/wiki/pr2 simulator/
[21] Xacro, www.ros.org/wiki/xacro/
[22] Yet Another Markup Language(YAML),
www.yaml.org/
[23] Yet Another Markup Language(in ROS),
www.ros.org/wiki/YAML Overview/
BIBLIOGRAFÍA 107
[24] Yet Another Markup Language(in Wikipedia),
www.wikipedia.org/wiki/YAML/
[25] C++(in Wikipedia), www.wikipedia.org/wiki/C++/
[26] C++(in ROS), www.ros.org/wiki/roscpp/
[27] C++(in ROS(Overview)),
www.ros.org/wiki/roscpp/Overview/
[28] List Processing(LISP)in Wikipedia,
www.wikipedia.org/wiki/LISP/
[29] List Processing(LISP)in ROS(Overview),
www.ros.org/wiki/roslisp/Overview/
[30] List Processing(LISP)in ROS ,
www.ros.org/wiki/roslisp/
[31] Remote Procedure Call,RPC ,in ROS(Overview),
http://www.ros.org/wiki/ROS/Technical Overview/
[32] Remote Procedure Call,RPC ,Home Page,
xmlrpc.scripting.com/default.html/
[33] Remote Procedure Call,RPC ,in Wikipedia,
en.wikipedia.org/wiki/XMLRPC/
[34] Software LifeCycle,
en.wikipedia.org/wiki/Software development process/
[35] RVIZ, www.ros.org/wiki/rviz/
[36] Actions(actionlib), www.ros.org/wiki/actionlib/
[37] TCPROS, www.ros.org/wiki/ROS/TCPROS/
108 BIBLIOGRAFÍA
[38] UDPROS, www.ros.org/wiki/ROS/UDPROS/
[39] Latex Home Page, www.latex-project.org/
[40] Geany Home Page, www.geany.org/
[41] Dia Home Page, dia-installer.de/
[42] ArgoUML, argouml.tigris.org/
[43] BSD, en.wikipedia.org/wiki/BSD licenses/
[44] LGPL, en.wikipedia.org/wiki/LGPL/
[45] FSF(Free Software Foundation), www.fsf.org/
[46] Tutotial Wubble,
www.ros.org/wiki/arm navigation/Tutorials/Running arm
navigation on non-PR2 arm/
[47] IRI Repositories in ROS, ros.org/wiki/iri wam/
[48] IRI Repositories in WIKIRI,
wikiri.upc.es/index.php/IRI ROS Stacks/
[49] Tutotial of ROS for Written Contro-
ller.www.ros.org/wiki/pr2 mechanism/Tutorials/Writing a
realtime joint controller/
[50] Quaternion’s Definition,
en.wikipedia.org/wiki/Quaternion/
[51] Degree of Freedom,
en.wikipedia.org/wiki/Degrees of freedom (mechanics)
[52] Inverse Kinematics,
en.wikipedia.org/wiki/Inverse kinematics
BIBLIOGRAFÍA 109
[53] Forward Kinematics,
en.wikipedia.org/wiki/Forward kinematics
[54] Spline, en.wikipedia.org/wiki/Spline (mathematics)
[55] Gazebo Dynamic Plugin, wiki-
ri.upc.es/index.php/Creating a robot simulator for GAZEBO/
[56] Gazebo Static Plugin, wiki-
ri.upc.es/index.php/Creating a robot simulator for GAZEBO/
[57] Actions(actionlib
detailed),www.ros.org/wiki/actionlib/DetailedDescription/
[58] Joint State Message,
www.ros.org/doc/api/sensor msgs/html/msg/JointState.html/
[59] Tabla de Amortización Simplificada,
www.gabilos.com/webcontable/amortizacion/estimacion directa simplificada.htm/
[60] Designing Concurrent,Distributed, and Real-Time
Applications with UML.
Hassan Gomaa,Addison-Wesley Editorial, Sixth printing
,2006. . . . . . . . . 88
8.12. Extracto de código fuente de wam1.urdf.xacro . . . . . . . . . 89
8.13. Codigo fuente de tipo launch de iri wam wrapper . . . . . . . 93
Nomenclatura
t Es una Traslación
q̂ Es un Quaternion
r̂ Rotación de tipo Roll
p̂ Rotación de tipo Pitch
ŷ Rotación de tipo Yaw
θx Angulo de movimiento,en radianes, para el jointX
DOF Grados de Libertad
11
12 Nomenclatura
Glosario
Translación
Es la posición de un cuerpo respecto a los ejes del mundo (o del
entorno)
Cuaternión
Los cuaterniones[50], son una extensión de los números reales bastante
similar a la de los números complejos. Estos son muy utilizados en el campo
de matemáticas, robótica, f́ısica, y por extensión al campo de los videojuegos,
ya que son útiles para representar rotaciones.
La complejidad que presentan las rotaciones en el espacio tridimensional se
debe a su no conmutatividad. Los cuaterniones unitarios, tienen la capaci-
dad de capturar toda la geometŕıa, topoloǵıa, y estructura de las rotaciones
tridimensionales, en la forma más sencilla posible.
Roll
Se define como la rotación de un cuerpo sobre el eje x, del sistema de
coordenadas del cuerpo (ejes relativos) y no al sistema de coordenadas del
entorno (ejes absolutos)
Pitch
Se define como la rotación de un cuerpo sobre el eje y, del sistema de
coordenadas del cuerpo (ejes relativos) y no al sistema de coordenadas del
13
14 Glosario
entorno (ejes absolutos)
Yaw
Se define como la rotación de un cuerpo sobre el eje z, del sistema de
coordenadas del cuerpo (ejes relativos) y no al sistema de coordenadas del
entorno (ejes absolutos)
Spline
Spline [54], Es una curva diferenciable definida en porciones mediante po-
linomios.
En los problemas de interpolación, se utiliza a menudo la interpolación me-
diante splines porque da lugar a resultados similares requiriendo solamente el
uso de polinomios de bajo grado, evitando aśı las oscilaciones, indeseables en
la mayoŕıa de las aplicaciones, encontradas al interpolar mediante polinomios
de grado elevado.
Cinemática Inversa
Dada la posición del efector final representa la posición del end-
effector(tcp), La cinemática inversa [52] calcula las correspondientes coorde-
nadas articulares, es decir, el ángulo para cada uno de los actuadores rota-
cionales
Cinemática Directa
Dada las coordenadas articulares:[θ1,θ2,θ3,....,θn] que son los ángulos de
cada uno de los actuadores rotacionales, La cinemática directa [53] calcula
la posición del end-effector.
Grados de Libertad
Los grados de libertad (del ingles, degree of freedom)[51]: es el número de
parámetros que definen la configuración de un sistema mecánico. Los grados
Glosario 15
de libertad de un cuerpo son el número de parámetros independientes que
definen el desplazamiento y deformación de la cuerpo. Este es un concepto
fundamental en relación con los sistemas de cuerpos en movimiento en la in-
genieŕıa mecánica, ingenieŕıa aeronáutica, robótica y a ingenieŕıa estructural.
Link
Es el elemento fundamental , que combinados, forman la cadena cinemáti-
ca del robot
Joint
Es la unión entre 2 links y es capaz de generar movimiento para cambiar
la posición y orientación de los mismos.
16 Glosario
Caṕıtulo 1
Introducción
1.1. Motivación
En mi mente pasaba un proyecto final de carrera (PFC) en el cual mos-
traba todos, o gran parte, de los conocimientos que he adquirido durante
la carrera, a demás queŕıa realizar un proyecto en el cual pudiera aprender
nuevos métodos, técnicas, conocimientos, etc. Para demostrar no solo a los
miembros del tribunal sino a mi mismo lo capacitado que estoy para reali-
zar las tareas de un ingeniero informático Personalmente, apasiona mucho el
tema de robótica y espero en un futuro, trabajar como investigador de este
campo.
Gracias al curso de introducción a la robótica humanoide pude tomar contac-
to con el instituto de robótica e informática industrial (IRI) [1], espećıfica-
mente quien seŕıa mi director de proyecto sr. Guillem Alenya. En un primer
contacto, le he explicado la idea que tenia para mi PFC (estaba orientado
a la aplicación de un robot en un entorno social). Me comento que en el
IRI, no teńıan esa ĺınea de investigación, pero me ofreció un proyecto en el
cual trabajaba con navegación de un robot WAM Arm y percepción con una
depth cámara.
Sin embargo, durante el transcurso de este, por requerimientos del mismo
instituto, se procedió a modificar el proyecto, a tal punto, de centrarme úni-
camente con la navegación pero también de crear un simulador del robot con
el mismo comportamiento del robot real.
Durante las 2 fases del proyecto, yo me he sentido muy contento por trabajar
en el IRI, y agradezco enormemente la oportunidad que me han dado.
17
18 CAPÍTULO 1. INTRODUCCIÓN
1.2. La importancia de la navegación
Algunos robots son plataformas móviles, llamados robots cartesianos,
otros pueden volar, otros rotar sobre algún eje, y muchos tienen la capa-
cidad de simular el brazo humano, y otros son humanoides.
Independiente del tipo de robot, y de su configuración, este requiere de las ne-
cesidades de navegación, para realizar un movimiento.
La navegación proporciona unas trayectorias para que el robot pueda seguir-
las. Pero para calcular estas trayectorias, se debe tener toda la información
necesaria tanto del robot como del entorno(o área de trabajo), como por
ejemplo, la posición de los obstáculos, posición del robot en el entorno, la
odometria del robot, limites de cada actuador del robot, etc.
Con toda esta información, la navegación debe ser capaz de crear trayecto-
rias para transportar al robot, desde un punto A a un punto B, evitando los
obstáculos y respetando los ĺımites del robot.
1.3. Real vs Simulado
Si bien es cierto que el simulador, como dice su nombre, simula las ca-
racteŕısticas y comportamientos de un objeto, este nunca llegara a actuar
idénticamente. Por ejemplo, si imaginamos el siguiente escenario, podemos
tener una plataforma cuadriculada de 10 x 10 [cm] y un robot humanoide
cualquiera. Si programamos al robot real a que se detenga en el centro del
3 recuadro, la probabilidad de detenerse es minima, por factores como la el
roce de los pies con la mesa, la porosidad de la mesa, etc. En cambio, si pro-
gramamos la misma tarea en un robot simulado, la probabilidad de acertar es
muy alta , ya uqe por mucho simulemos el roce, este nunca actuara como tal.
Sin embargo, la caracteŕıstica más destacable de un simulador es que la de
proteger al robot real. Ya que en el simulador podemos probar códigos y li-
breŕıas experimentales, que ejecutadas directamente en el robot real, pueden
crear estragos en el mismo. Aśı, por mucho que destroce un robot simulado,
lo único que debemos hacer es reiniciar el simulador. También es posible con
un único modelo de robot, podemos crear toda una población del mismo.
1.4. POR QUÉ ROS 19
1.4. Por qué ROS
Uno de los mayores problemas de la robótica, es que cada proveedor crea
sus controladores para sus robots. Como tal, se crea un escenario de depen-
dencia e incompatibilidad. Por ejemplo, si hacemos una llamada al contro-
lador de un robot, este código totalmente incompatible con otros robots, e
inclusive, puede ser incompatible con el mismo robot en una versión mas
moderna. En este punto, entra ROS. Este sistema, con su estructura de pac-
kages y su arquitectura de cliente / servidor, el código que usa al controlador,
estará al final del toda la cadena de dependencias de packages(en las nodo-
hojas, si lo miramos como árbol). Por lo tanto, es posible separar el código
de comunicación con el robot y con el código, digamos, de cálculo, lo que
permite, entre otras cosas, el intercambio de robot s y la reutilización de
código.
20 CAPÍTULO 1. INTRODUCCIÓN
Caṕıtulo 2
Objetivos
A continuación detallare los objetivos generales a este pro-
yecto:
1. Mi primer objetivo para este proyecto,es simular el bra-
zo robótico WAM, utilizando los ficheros mesh entregados
(*.stl) para cada pieza del robot. Además , este tiene que
simular la mayor cantidad de propiedades del robot real.
2. El segundo objetivo es conectar todo el stack de navegación
reutilizando los códigos del PR2 para su correcto funciona-
miento con el robot WAM ARM.
3. El tercer objetivo es conectar el simulador Gazebo con el
stack de navegación , de tal manera, poder generar las tra-
yectorias simples obtenidas desde el stack de navegación en
el ,y además se mueva de forma coherente dentro de sus
limitaciones.
4. El cuarto objetivo es conectar el robot real con el stack
de navegación , de tal manera, poder generar las trayec-
torias simples obtenidas desde el stack de navegación en
21
22 CAPÍTULO 2. OBJETIVOS
el ,y además se mueva de forma coherente dentro de sus
limitaciones.
5. El quinto objetivo es conectar el robot simulado con el stack
de navegación , de tal manera poder generar las trayecto-
rias, evitando obstáculos, obtenidas desde el stack de nave-
gación en el ,y además se mueva de forma coherente dentro
de sus limitaciones.
6. El sexto objetivo es conectar el robot real con el stack de
navegación , de tal manera poder generar las trayectorias,
evitando obstáculos, obtenidas desde el stack de navegación
en el , y además se mueva de forma coherente dentro de sus
limitaciones.
7. El séptimo objetivo es lograr crea un mecanismo, que per-
mita al stack de navegación calcular la trayectoria simple,
sin necesidad de saber el tipo de robot al cual esta conec-
tado.
8. El octavo objetivo es lograr crea un mecanismo, que permi-
ta al stack de navegación calcular la trayectoria con evita-
ción de obstáculos, sin necesidad de saber el tipo de robot
al cual esta conectado.
Caṕıtulo 3
Herramientas
3.1. ROS
3.1.1. Que es ROS
ROS , es un meta- sistema operativo ,de código abierto que
es utilizado en robótica. Ofrece los servicios que se esperaŕıa
de un sistema operativo, como abstracción de hardware, control
de dispositivos de bajo nivel, paso de mensajes entre los proce-
sos y la gestión de paquetes. También proporciona herramien-
tas y bibliotecas para la obtención, construcción, escritura y la
ejecución de código en varios equipos. ROS es similar en algu-
nos aspectos,a otro robot frameworks”, como Player [12], Yarp
[6], Orocos [7], CARMEN [8], Orca [9], Moos [10] y Microsof-
tRobotics Studio [11].
El grafo en tiempo de ejecución de ROS, es una red peer-to-
peer, de procesos que están débilmente acoplados, utilizando la
infraestructura de comunicación ROS. ROS implementa diferen-
tes estilos de comunicación, incluyendo sincronizada RPC-style
, utilizada por los servicios, la transmisión aśıncrona de datos,
utilizada por los tópicos y almacenamiento de datos en un ser-
23
24 CAPÍTULO 3. HERRAMIENTAS
vidor de parámetros.
ROS no es un framework de tiempo real, a pesar de que es po-
sible la integración de ROS con el código de tiempo real. El ro-
bot PR2 [13] de Willow Garage [18],utiliza un sistema llama-
do pr2 etherCAT [14], que transporta los mensajes ROS dentro
y fuera de un proceso en tiempo real. ROS también tiene una
integración perfecta con el Orocos Real-Time Toolkit [7].
3.1.2. Conceptos Básicos
Package
Es el elemento mas fundamental en la organización de los
ficheros de ROS. Un paquete puede contener nodos de ROS,
bibliotecas externas , un conjunto de datos, archivos de configu-
ración, fragmentos de códigos, o cualquier otra cosa que lógica-
mente constituye un módulo útil. El objetivo de estos paquetes
es proporcionar esta funcionalidad útil en un formato fácil de
utilizar, y además, que el software pueda reutilizar esta misma.
En general, los paquetes de ROS siguen el principio de ”Goldi-
locks”: Debe tener la suficiente funcionalidad para ser útil, pero
no demasiado al punto de que el paquete sea pesado y dif́ıcil de
utilizar.
Los packages tienden a seguir una estructura común. Éstos son
algunos de los directorios y archivos que se pueden nombrar:
bin/ : donde se almacenan los ficheros binarios.
include/package name/ : directorio donde se alamcenan los
ficheros cabeceras (.h, .hh,.hpp,etc) de C++
msg/ : donde se definen los tipos propios de mensajes
3.1. ROS 25
src/package name/ : codigos fuente del package, especialmen-
te codigos fuentes de Python que se exportan a otros pa-
quetes.
srv/ : donde se definen los tipos propios de servicios
scripts/ : donde se almacenan los scripts
CMakeLists.txt : fichero de construcción de CMake
manifest.xml : Manifiesto del Package, muestra la dependen-
cias que tiene el package de otros package.
mainpage.dox : Fichero de configuración de Doxygen para crear
documentación automática sobre el package
Un package de ROS es un directorio mas, en el árbol de depen-
dencias desde ROS ROOT o ROS PACKAGE PATH. Es posi-
ble agrupar muchos paquetes en stacks
Stack
Cuando se crean una colección de package que comparten una
temática en común, por ejemplo: diversos paquetes que calculan
de distintas maneras las cinemáticas, se pueden agrupar en un
stack. Un stack , es una colección de packages que comparten
una misma funcionalidad, por ejemplo cálculos cinemáticos, y
como consecuencia de esto, es mas fácil la distribución de los
paquetes
Además, otra funcionalidad muy importante de estos, es que a
diferencia de las libreŕıas tradicionales que vinculan en tiempo
de compilación, los stack pueden ofertar estas funcionalidades
en tiempo de ejecución mediante servicios y topicos. Los stacks
también contienen un fichero llamado stack.xml, que muestra la
26 CAPÍTULO 3. HERRAMIENTAS
dependencia de un stack con otros. Además todo lo que dentro
de un stack, se considera parte de el
Topicos
Es uno de los métodos de intercambio de mensajes entre los
nodos. Tiene una semántica anónima de publicador/subscriptor,
que provoca la separación de la producción de la información.
En otras palabras, los nodos no tienen conocimiento de quien se
conecta con quien, solo sabe de la información que recibe o de
que env́ıa.
Se puede definir a un publicador, como un nodo que publica
información en un tópico determinado, en cambio, un subscrip-
tor es quien recibe la información de un tópico determinado. Es
posible la existencia de múltiples publicadores y múltiples subs-
criptores hacia un tópico.
El tópico tiene una comunicación unidireccional y una comuni-
cación en streaming y Además, no puede recibir/publicar otro
tipo de datos que no sea para el cual fue creado
Servicios
El modelo de publicador/subscriptor es un paradigma de
comunicación muy flexible, pero su cardinalidad de muchos-a-
muchos y su transporte unidireccional no es el mas apropiado
para interacciones petición/respuesta ,de tipo RPC, que a me-
nudo son necesarios en un sistema distribuido.
Para las interacciones petición/respuesta, se utiliza otro tipo de
comunicación de ROS, llamado servicios.Este utiliza un par de
mensajes determinados: uno para la solicitud y otro para la res-
puesta.
3.1. ROS 27
(a) Interacción de las Acciones (b) Interfaces de las Acciones
Figura 3.1: Interacción Cliente/Servidor de las Acciones
ROS proporciona un nodo que ofrece un servicio con un nom-
bre determinado, y el cliente llama al servicio por su nombre
enviando el mensaje de solicitud, y queda en espera del mensaje
de respuesta.
Un cliente puede hacer una conexión persistente a un servicio, lo
que permite un mayor rendimiento a costa de la menor robustez
a los cambios de proveedor de servicios.
Acciones
La acción [36], es un concepto implementado por la libreŕıa
actionlib y tiene una arquitectura cliente/servidor. El cliente y el
servidor se comunican mediante un protocolo denominado ROS
action protocol, y cada uno de ellos proveen de una API sencilla
para que el usuario solicite una referencia (en el lado del cliente)
o o ejecute dicha referencia (en el lado del servidor) mediantes
callbacks.
Para llevara cabo esta comunicación entre cliente y servidor, es
necesario definir unos mensajes , que a continuación especifico:
28 CAPÍTULO 3. HERRAMIENTAS
Goal Para realizar las tareas con las acciones, se introduce una
referencia “meta”. Si estamos trabajando con una platafor-
ma móvil, la referencia “meta” seria el punto al cual que-
remos que se mueva, si estamos trabajando con un láser, la
referencia puede ser el ángulo de este.
Feedback Feedback es un mensaje que tiene el servidor. Este
se utiliza para indicar al cliente como va el progreso incre-
mental de la tarea respecto a la referencia “meta”.
Result Este mensaje lo env́ıa el servidor hacia el cliente una
vez que ha alcanzado la referencia “meta”. Se diferencia li-
geramente al feedback, ya que este ultimo se env́ıa durante
la ejecución que lleva al robot a la referencia “meta”, en
cambio, el result se env́ıa únicamente al finalizar la ejecu-
ción
3.1.3. Diferencia entre los servicios, tópicos y acciones.
La diferencia entre estos 3 formas de comunicación de ROS
es muy marcada.
Los servicios requieren 2 nodos para crear la comunicación. Cuan-
do el nodo cliente env́ıa la solicitud al nodo servidor,debe dejar
en espera su ejecución hasta que reciba la respuesta, hecho que
marca el reinicio de su ejecución. Por el contrario, los tópicos
no es necesario la existencia de los nodos involucrados, en otras
palabras, pueden existir publicadores sin subscriptores, y vice-
versa, pueden existir subscriptores pero no publicadores. Los
acciones funcionan a base de callback, y en palabras simples es
un fragmento de código que se ejecuta respondiendo a un evento
determinado.
3.1. ROS 29
(a) Diagrama de estados para el cliente (b) Diagrama de estados para el servidor
Figura 3.2: Diagrama de estados de las Acciones
Esto son los diagramas de estado para el cliente y el servidor de las acciones
[?].
3.1.4. Comunicación en ROS
ROS , actualmente soporta el env́ıo de mensajes a través
de los protocolos de transportes TCP/IP y UDP. Para el caso
de TCP/IP, se usa con conexiones persistentes, y en ROS se
30 CAPÍTULO 3. HERRAMIENTAS
Figura 3.3: Ejemplo Comunicación TCPROS
Ejemplo simple de comunicación entre 2 nodos
utiliza por defecto bajo el nombre de TCPROS. UDP,llamado
UDPROS, solo es soportado por la libreŕıa roscpp y aun sigue
en fase de desarrollo.
Los nodos de ROS, son capaces de negociar el transporte en
tiempo de ejecución, basándose en las funcionalidades ofrecidas.
Por ejemplo, Si un nodo que utiliza UDP intenta conectarse con
un nodo que solo acepta TCP, puede cambiar su protocolo de
transporte durante la ejecución
TCPROS
TCPROS [37],es el protocolo ,por defecto, de transporte para
los mensajes y servicios de ROS. Se utiliza TCP / IP estándar
para el transporte de datos. Las conexiones entrantes son reci-
bidas a través de un socket de servidor TCP, desde donde serán
3.1. ROS 31
enrutados según la información de las cabeceras.
Cabeceras TCPROS
Las conexiones entrantes al socket del servidor TCPROS, se
redirigue ,o encaminan, por la información contenida en las ca-
beceras de los paquetes de transporte. Por ejemplo si el paquete
entrante dice “topic” se enviara a una conexión de publicación
de tópicos. Un suscriptor TCPROS debe enviar los siguientes
campos:
callerid: nombre del subscriptor
topic: nombre del tópico al cual se subscribe
md5sum: checksum del tipo de mensaje
type: tipo de mensaje
Un publicador TCPROS está obligado a responder con los si-
guientes campos en una conexión correcta:
md5sum: checksum del tipo de mensaje
type: tipo de mensaje
Un cliente de un servicio TCPROS debe enviar los siguientes
campos:
callerid: nombre del nodo cliente
service: nombre del servicio al cual se conecta
md5sum: checksum del tipo de mensaje
type: tipo de servicio
32 CAPÍTULO 3. HERRAMIENTAS
Un suscriptor TCPROS opcionalmente puede enviar los siguien-
tes campos:
tcp nodelay: Si es ’1’, indica que el publicador marca TCP NODELAY
en el socket( si es posible)
Un publicador TCPROS opcionalmente puede enviar los siguien-
tes campos:
callerid: nombre del publicador,Aunque este campo no es obli-
gatorio, es muy recomendable para fines de depuración.
latching: Si es ’1’,el publicador indica que el env́ıo de mensajes
esta asegurado. El protocolo para el intercambio de men-
sajes y el latching es idéntico, pero los suscriptores tal vez
desee tomar nota del enlace cerrado.
Un cliente de servicio TCPROS opcionalmente puede enviar los
siguientes campos:
persistent: Si es ’1’, indica que la conexión debe mantenerse
abierta para multiples solicitudes del servicio
TCPROS tiene los siguientes campos opcionales:
message definition: texto completo de la definición de men-
sajes
error: un mensaje explicativo de por que fallo la conexión
UDPROS
UDPROS [38], es un protocolo de transporte (en desarrollo)
para los mensajes y servicios de ROS. Se utiliza los paquetes
UDP estándar para el transporte de datagramas de datos . El
3.1. ROS 33
transporte UDPROS es útil cuando la latencia es más importan-
te que el transporte fiable. Ejemplos en el ámbito de la robótica
son teleoperación, aśı como el streaming de audio. UDPROS in-
tercambia las cabeceras de los mensajes en la fase de negociación
XML-RPC[31][32][33](See 4.2.6)
UDPROS Header
Los mensajes ROS son enviados a través de la red como una
serie de datagramas UDPROS. El tamaño máximo de los data-
gramas UDPROS se negocia en la conexión de XML-RPC 4.2.6.
Cada datagrama UDP contiene un encabezado UDPROS, se-
guido por los datos del mensaje. El formato de la cabecera es el
siguiente:
Connection ID Este valor de 32 bits se determina durante la
negociación de la conexión y se utiliza para denotar la co-
nexión al cual el datagrama está destinado.
Opcode UDPROS soporta múltiples tipos de datagramas. El
código de operación especifica el tipo de datagramas. Este
campo de 8 bits puede tener los siguientes valores :
-DATA0 (0) Este código de operación lo env́ıa el primer datagrama del
mensaje ROS
-DATAN (1) Todos los datagramas posteriores de un mensaje ROS utili-
zan este código de operación
-PING (2) Este paquete se env́ıa de forma periódica para saber si la co-
nexión todav́ıa está activa
-ERR (3) Este paquete de error se utiliza para indicar que una conexión
se ha cerrado inesperadamente
Message ID Este valor de 8 bits se incrementa por cada men-
saje nuevo y se utiliza para determinar si los datagramas si
los datagramas llegan en orden
34 CAPÍTULO 3. HERRAMIENTAS
Block # Cuando el código de operación es DATA0, este campo
contiene el número total de datagramas . Cuando el código
de operación es DATAn, este campo contiene el número
actual de datagramas.
Mensajes ROS se env́ıan a los suscriptores en uno o más da-
tagramas UDPROS. El primer datagrama contiene el número
total de datagramas a esperar. Cada datagrama contiene una
cabecera seguida de los datos serializados . La cantidad máxima
de datos por mensaje datagrama se determina durante la ne-
gociación de la conexión. Sólo ultimo de los datagramas de un
mensaje contiene menos que el número máximo de bytes.
3.1.5. Como se instala ROS
ROS es bastante fácil de instalar, ya que se puede descargar a
través del Synaptic de linux la versión ros-electric-desktop-full,o
también es posible instalar manualmente esto se puede ver en el
Anexo ??.
3.2. Gazebo
3.2.1. Que es Gazebo
Gazebo es un simulador multi-robot para entornos al aire li-
bre. Es capaz de simular una población de robots, sensores y
objetos, todo esto lo hace en un mundo tridimensional. Genera
tanto una retroalimentación realistas del sensor como interac-
ciones entre los objetos f́ısicamente plausible (que incluye una
simulación exacta de la f́ısica de cuerpos ŕıgidos). Fue creado
por Nate y Howard Andrew Koenig en 2003
3.2. GAZEBO 35
(a) Modelos sin piel (b) Modelos con piel
Figura 3.4: Ejemplos de modelos en Gazebo
3.2.2. Caracteŕısticas
El simulador Gazebo tienelas siguientes caracteŕısticas:
1. Simulación de sensores estándar de robots, incluyendo so-
nar, láser de barrido telémetros, GPS y IMU, monocular y
cámaras estéreo.
2. Modelos de robots de uso común como el Pioneer2DX, Pio-
neer2AT y SegwayRMP.
3. Simulación realista de la f́ısica de cuerpos ŕıgidos: los ro-
bots pueden empujar las cosas, recoger cosas, y, en general
interactuar con el mundo de una manera plausible.
4. Independiente de la operación: los programas pueden inter-
actuar directamente con el simulador con libgazebo (inclui-
do en la distribución).
5. Modelo de la cámara estéreo: genera pares estéreo de imáge-
nes, la disparidad y mapas de profundidad.
36 CAPÍTULO 3. HERRAMIENTAS
6. Plugins de Modelos: los usuarios pueden desarrollar sus pro-
pios modelos de robots / sensores, y que estos modelos se
carguen en tiempo de ejecución.
7. “Pieles”: modelos simples geométricos pueden ser aumen-
tados en realismo mediante pieles de los programas de mo-
delado 3D.(ficheros mesh).
8. Gazebo es un software libre, publicado bajo la Licencia
Pública GNU(en la distribución ROS.
3.2.3. Como movemos un robot en Gazebo?
En Gazebo es posible mover los robots mediante plugins. Par-
ticularmente en ROS, existen 2 tipos de plugins
Plugin Estático Como vemos en la figura 3.5,Este enfoque
consiste en escribir un nodo genérico ROS que será ca-
paz de comunicarse con Gazebo a través del tópico gaze-
bo/model state. Por ejemplo, en este nodo recibe el mensa-
je de velocidad, y odometŕıa simulada ,y finalmente, genera
y env́ıa el mensaje adecuado a gazebo/model state con el
fin deque el robot se mueva.
Plugin Dinámico Como vemos en la figura3.6,Esto es un en-
foque muy diferente al anterior (y probablemente más com-
plicado), pero algunas personas tienen mejores resultados
cuando se utiliza este método que el plugin estático. Este
método consiste en escribir un plugin dinámico que se pue-
de integrar en el archivo URDF del robot para ofrecer el
simulador de la capacidad de control. El plugin utiliza el
Gazebo y el código de ROS para realizar las acciones de
simulación.
3.2. GAZEBO 37
Figura 3.5: Plugin Estático Gazebo
Este es el esquema del ejemplo utilizado para plugin estático [56]
Figura 3.6: Plugin Dinámico Gazebo
Este es el esquema para un plugin dinámico [55]
En este proyecto, solo se utilizo el segundo tipo de plugin. La di-
ferencia es que en wam arm fue una creación propia, en cambio,
en iri wam, utilice el propio de ROS. Encapsulados en los pac-
kages wam arm gazebo(ver 7.5.1) y iri wam gazebo(ver 8.5.5)
respectivamente.
3.2.4. Como se conecta ROS con Gazebo?
Gazebo es parte del package llamado simulator gazebo. En
este paquete,se almacena un código ✭✭wrapper✮✮, en el cual se
38 CAPÍTULO 3. HERRAMIENTAS
implementa las interficies necesarias para comunicarse con el
simulador a través de servicios.
gazebo/spawn urdf model Este servicio introduce el robot
en el simulador, la definición del robot esta escrita en URDF
gazebo/spawn gazebo model Este servicio introduce el ro-
bot en el simulador, la definición del robot esta escrita en
una extensión xml propia del Gazebo
gazebo/delete model Este servicio elimina de la silumación
el modelo especificado
gazebo/get model properties Este servicio retorna las pro-
piedades del robot en simulación
gazebo/get model state Este servicio retorna el estado del
robot en simulación
gazebo/get world properties Este servicio retorna las pro-
piedades del entorno simulado
gazebo/get joint properties Este servicio retorna las propie-
dades de un joint en simulación
gazebo/get link properties Este servicio retorna las propie-
dades de un link en simulación
gazebo/get link state Este servicio retorna el estado de un
link en simulación.
gazebo/get physics properties Este servicio retorna las pro-
piedades f́ısicas usadas en la simulación
gazebo/set link properties Este servicio permite cambiar las
propiedades de los links en simulación
3.2. GAZEBO 39
gazebo/set physics properties Este servicio permite cambiar
las propiedades f́ısicas usadas simulación
gazebo/set model state Este servicio permite cambiar la po-
sición del modelo en simulación, en coordenadas cartesianas
gazebo/set model configuration Este servicio permite cam-
biar la posición del modelo en simulación, en coordenadas
joints,quitando la dinámica de los mismos.
gazebo/set joint properties Este servicio permite cambiar
la posición del modelo en simulación, en joints
gazebo/set link state Este servicio permite cambiar el estado
de un linko en simulación.
gazebo/pause physics Pone pausa a la f́ısica simulada
gazebo/unpause physics Reactiva a la f́ısica simulada
gazebo/apply joint effort Aplica esfuerzo al joint en simula-
ción.
gazebo/clear joint forces Limpia el esfuerzo aplicado al joint
en simulación.
Sin embargo desde la versión diamondback de ROS, se recomien-
da no usar estos servicios, por la aparición de las acciones, ver
3.1.3
3.2.5. Problemas con Gazebo
El primer problema al que me he enfrentado en este proyecto,
fue con Gazebo. Durante la primera ejecución del simulador en
mi portátil aparecio un problema de blinking.
40 CAPÍTULO 3. HERRAMIENTAS
Figura 3.7: Ejemplo de uso de RVIZ
El robot genera mensajes de posiciones, y RVIZ las interpreta.
Investigando entre el mail-list de ROS [4], answer-list de ROS
[3] y ubuntu help [5],pude esclarecer el problema. Este ocurre
por que Gazebo crea conflictos con las tarjetas gráficas ATI y el
gestor de efectos de ubuntu (compiz).
La solución es deshabilitar el gestor compiz con esta instrucción,
antes de ejecutar Gazebo
metacity –replace
Luego se puede restaurar con esta otra instrucción:
compiz –replace
En la actualidad, hay distribuciones de Ubuntu que permiten
desactivar el compiz desde el inicio. Como es el caso de la versión
11.04 , que en la pantalla de login permite activar/desactivar el
compiz.
3.3. RVIZ
3.3.1. Que es RVIZ
RVIZ [35], es una herramienta muy útil de ROS. Este es un
visualizador 3D,y es capaz de mostrar todo lo que ve, piensa y
hace el robot
3.4. OMPL 41
(a) Problema Cubicles (b) Solución Cubicles
Figura 3.8: Ejemplo de solución a un problema con OMPL
3.3.2. Como trabaja RVIZ
RVIZ [35], trabaja leyendo e interpretando los diferentes da-
tos contenidos en los mensajes ROS. Por tanto, es necesario
tener un generador externo de estos mensajes(como un robot
real o simulado) Por ejemplo, en la figura 3.7, RVIZ interpreta
el mensaje joitn state[58] enviado por el robot.
3.4. OMPL
3.4.1. Que es OMPL
El Open Motion Planning Library (OMPL),se compone de
muchos algoritmos de planificación de muestreo basado en el
movimiento. OMPL en śı no contiene ningún código relacionado
con, por ejemplo, control de colisión o de la visualización. Esta
es una opción de diseño deliberada, de modo que OMPL no
está vinculada a un corrector de colisión frontal en particular
o la visualización, solo entrega una trayectoria a seguir. OMPL
está destinada a ser eficiente, seguro para subprocesos, fácil de
42 CAPÍTULO 3. HERRAMIENTAS
usar, fácilmente extensible y de libre acceso.
3.4.2. Como se conecta OMPL con ROS
ompl ros interface es el package que tiene la interficie nece-
saria para conectar el OMPL con ROS.
Este paquete me permitie crear y configurar fácilmente un con-
junto de movimiento para el robot. La mayoŕıa de configuración
es automática, sin embargo, se tiene que especificar las partes
del robot para el que desea crear un planificador de movimiento.
Caṕıtulo 4
Ciclo de vida y Lenguajes de
Programación
4.1. Ciclo de vida del Software
Figura 4.1: Modelo de Cascada
Modelo inicial de desarrollo de este software
43
44CAPÍTULO 4. CICLO DE VIDA Y LENGUAJES DE PROGRAMACIÓN
Figura 4.2: Modelo de Prototipaje
Modelo utilizado en el desarrollo del PFC
El término ciclo de vida del software[34] describe el desarrollo
de software, desde la fase inicial hasta la fase final. El propósito
deeste, es definir las distintas fases intermedias que se requieren
para validar el desarrollo de la aplicación, es decir, para garan-
tizar que el software cumpla los requisitos para la aplicación y
verificación de los procedimientos de desarrollo: se asegura de
que los métodos utilizados son apropiados. Existen varios ti-
pos de modelos de ciclos de vida, como por ejemplo:modelo en
cascada,modelo de prototipaje,modelo en espiral,desarrollo in-
teractivo e incremental, etc..
Inicialmente para este proyecto, hab́ıa pensado en un desarrollo
basado el modelo en cascada(figura 4.1). Su funcionamiento es
4.1. CICLO DE VIDA DEL SOFTWARE 45
aśı: después de cada etapa se realiza una o varias revisiones para
comprobar si se puede pasar a la etapa siguiente, tal como se
muestra en la imagen, hasta que no se termina una etapa no se
inicia la siguiente, se le conoce como un modelo ŕıgido, es de-
cir, poco flexible y con muchas restricciones como por ejemplo
la necesidad de contar con todos los requerimientos al comienzo
del proyecto. Si se detectan errores y no se detectan en la etapa
inmediata siguiente, es muy costoso y dif́ıcil volver atrás para
realizar la corrección. Otra de las restricciones que nos ofrece
éste ciclo de vida es que no vemos los resultados hasta que no
lleguemos a las etapas finales del ciclo, por lo tanto, cualquier
error detectado nos repercute un aumento de tiempo considera-
ble en detectar la etapa y su solución.
Después de un estudio consensuado,finalmente, he decidido usar
el modelo de prototipaje 4.2, El ciclo de vida se empieza en la
fase de análisis de requerimientos, sigue en la fase de diseño,
prototipaje, evaluación de resultados y refinamiento del proto-
tipo, una vez en ésta fase se evalúa si cumple con los requisitos
preestablecidos, en caso contrario volvemos a la fase de diseño,
volvemos a pasar por las fases siguientes, una vez llegados a la
fase refinamiento del prototipo el proyecto cumple con los re-
querimientos se le entrega al cliente, en nuestro caso, se da por
finalizado el proyecto.
El motivo por el cual me he decantado por éste ciclo de vida ,es
porque nos permite tener fácilmente una estructura de la apli-
cación, que no siendo completa, nos ayuda a definir con mejor
exactitud los puntos importantes, y por otra parte poder mos-
trar al cliente, que en éste caso es el tutor del proyecto, como
va evolucionando y aśı poder redefinir o añadir si fuese preciso
46CAPÍTULO 4. CICLO DE VIDA Y LENGUAJES DE PROGRAMACIÓN
los requerimientos iniciales. Además la arquitectura de ROS nos
permite plenamente este modelo de desarrollo.
4.2. Lenguajes de Programación
En esta sección, daré una pequeña reseña a los lenguajes que
he utilizado y/o nombrado durante la memoria
4.2.1. URDF
,
Figura 4.3:
ROS Logo
Unified Robot Description Format [19] , es una
extensión del lenguaje XML, adoptado por Wi-
llow Garage[18] como de facto , formato de defi-
nición de los robots para Robot Operating System
(ROS)[2].Tiene etiquetas muy simple e intuitivas y
fácilmente identificables con términos de robótica.
En este lenguaje, he tenido que definir todo el ro-
bot (sobre todo en WAM ARM), También, se pue-
de auto-generar desde xacro( como ocurre con IRI WAM).
4.2.2. XACRO
Xacro [21], es un macro-lenguaje de XML. Con el, se pueden
construir más rapudo y es más fácil de leer archivos XML me-
diante el uso de macros, que a su vez, se expanden a expresiones
mas grandes en XML
Este package es muy útil cuando se trabaja documentos XML
de gran envergadura , tales como descripciones de robots. Es
muy utilizado ya que tiene la facilidad de auto-generar urdf.
4.2. LENGUAJES DE PROGRAMACIÓN 47
4.2.3. YAML
Figura 4.4:
Oren Ben-
Kiki
YAML [22][23][24],es un formato de serializa-
ción de datos legible por humanos inspirado en len-
guajes como XML, C, Python, Perl, aśı como el for-
mato para correos electrónicos especificado por el
RFC 2822. YAML fue propuesto por Clark Evans
en 2001, quien lo diseñó junto a Ingy döt Net y
Oren Ben-Kiki.
YAML es un acrónimo recursivo que significa
”YAML Ain’t Another Markup Language (en es-
pañol, ”YAML no es otro lenguaje de marcado”).
A comienzos de su desarrollo, YAML significaba
”Yet Another Markup Language”(.Otro lenguaje de
marcado más”) para distinguir su propósito centrado en los da-
tos en lugar del marcado de documentos. Sin embargo, dado
que se usa frecuentemente XML para serializar datos y XML es
un auténtico lenguaje de marcado de documentos, es razonable
considerar YAML como un lenguaje de marcado ligero.
En este lenguaje lo he utilizado para crear, actualizar,modificar,
y eliminar, datos y variables desde el servidor de parametros
4.2.4. C++
Figura 4.5:
Bjarne
Stroustrup
C++ [25][26][27], es un lenguaje de programa-
ción diseñado a mediados de los años 1980 por
Bjarne Stroustrup. La intención de su creación fue
el extender al exitoso lenguaje de programación C
con mecanismos que permitan la manipulación de
objetos. En ese sentido, desde el punto de vista de
los lenguajes orientados a objetos, el C++ es un
48CAPÍTULO 4. CICLO DE VIDA Y LENGUAJES DE PROGRAMACIÓN
lenguaje h́ıbrido.
Posteriormente se añadieron facilidades de progra-
mación genérica, que se sumó a los otros dos pa-
radigmas que ya estaban admitidos (programación
estructurada y la programación orientada a obje-
tos). Por esto se suele decir que el C++ es un lenguaje de progra-
mación multiparadigma. ROS[2],tiene una implementación de
C++ llamado roscpp.Este proporciona una biblioteca de cliente
que permite a los programadores de C++ de forma rápida, crear
y comunicarse con la interfaz de tópicos,servicios y parametros.
Este es el más utilizada la biblioteca de cliente ROS y está di-
señado para ser la biblioteca de alto rendimiento para ROS.
En este lenguaje, he creado por ejemplo, el nodo que le entrega al
stack de navegación las posiciones de los obstaculos. También he
creado ordenes para mover el robot. Además WAM ARM,existe
una implementación inicial del plugin de Gazebo.
4.2.5. LISP
Figura 4.6:
John Mc-
Carthy
LISP [28][29][30], o LISt Processing,es una fa-
milia de lenguajes de programación de computado-
ra de tipo multiparadigma con una larga historia y
una sintaxis completamente entre paréntesis. Espe-
cificado originalmente en 1958 por John McCarthy
y sus colaboradores en el Instituto Tecnológico de
Massachusetts, el Lisp es el segundo más viejo len-
guaje de programación de alto nivel de extenso uso
hoy en d́ıa; solamente el FORTRAN es más vie-
jo. Al igual que el FORTRAN, el Lisp ha cambia-
do mucho desde sus comienzos, y han existido un
número de dialectos en su historia. Hoy, los dia-
4.2. LENGUAJES DE PROGRAMACIÓN 49
lectos Lisp de propósito general más ampliamente
conocidos son el Common Lisp y el Scheme.
El Lisp fue creado originalmente como una notación matemáti-
ca práctica para los programas de computadora, basada en el
cálculo lambda de Alonzo Church. Se convirtió rápidamente en
el lenguaje de programación favorito en la investigación de la
inteligencia artificial (AI). Como uno de los primeros lenguajes
de programación, el Lisp fue pionero en muchas ideas en ciencias
de la computación, incluyendo las estructuras de datos de árbol,
el manejo de almacenamiento automático, tipos dinámicos, y el
compilador auto contenido.
En ROS, exite una implementación llamada roslip, y se utili-
za en la generación automática de la estructura (en C++) de
mensajes y servicios.
4.2.6. XML-RPC
Figura 4.7:
Dave Winer
XML-Remote Procedure Call [31][32][33],es un
protocolo de llamada a procedimiento remoto que
usa XML para codificar los datos y HTTP como
protocolo de transmisión de mensajes. Es un pro-
tocolo muy simple ya que solo define unos cuantos
tipos de datos y comandos útiles, además de una
descripción completa de corta extensión. La sim-
plicidad del XML-RPC está en contraste con la
mayoŕıa de protocolos RPC que tiene una docu-
mentación extensay requiere considerable soporte
de software para su uso.
Fue creado por Dave Winer de la empresa User-
Land Software en asociación con Microsoft en el año 1998. Al
considerar Microsoft que era muy simple decidió añadirle funcio-
50CAPÍTULO 4. CICLO DE VIDA Y LENGUAJES DE PROGRAMACIÓN
nalidades, tras las cuales, después de varias etapas de desarrollo,
el estándar dejó de ser sencillo y se convirtió en lo que es actual-
mente conocido como SOAP.
Caṕıtulo 5
Planificación, Costos y
Licencias
5.1. Planificación
5.1.1. Planificación WAM ARM
Planificación para WAM ARM
Este proyecto comienza el 21 de Febrero del 2011 y de acuerdo
con el estudio de planning, debió acabarse el 19 de Julio del
mismo año. Se trabajó en el proyecto de lunes a viernes, 4 horas
diarias, a lo largo de 105 d́ıas, sumando un total de 420 horas
de trabajo para completar el proyecto.
Extensión Planificación para WAM ARM
Debido a los problemas que tuve durante el desarrollo del
proyecto inicial, principalmente debido a la inadecuada docu-
mentación, éste sufre una extensión de tiempo, que continuación
detallo:
La extensión comienza desde el 20 de Julio del 2011 hasta el 12
de Agosto del 2011. con una dedicación diaria de 5 horas, que
51
52 CAPÍTULO 5. PLANIFICACIÓN, COSTOS Y LICENCIAS
en total hace unas 75 horas. Por lo tanto, el tiempo total para
WAM ARM es de 495 horas.
En el anexo ?? se muestra el diagrama de Gantt paraWAM ARM.
5.1.2. Planificación para IRI WAM
El desarrollo de los packages para IRI WAM, comienzan el
29 de Agosto del 2011 y deben terminar el 5 de Enero del 2012,
La dedicación para este nuevo desarrollo es de 6 horas diarias,
durante un periodo de 90 dias, el genera 540 horas totales de
trabajo.
En el anexo ?? se muestr el diagrama de Gantt para IRI WAM
5.2. Costos
En esta sección, realizo un estudio de costos para este PFC.
Cabe destacar, que este es un proyecto universitario que no ge-
nera costos, y aqui asumo un escenario ficticio , donde los desa-
rrollos se llevan a cabo en la empresa privada.
5.2.1. Costos for WAM ARM
Costos por Software
A continuación detallo los costos generados por la utilización
de software
ROS ROS [2] es un sistema de codigo abierto y licencia BSD
[43], Por tanto, el costo es 0 euros
UBUNTU La versión recomendada de ROS require el uso de
UBUNTU,Por tanto, el costo es 0euros
5.2. COSTOS 53
Geany [40] Editor de texto para programación, es Free Softwa-
re, Por tanto, el costo es 0euros
SVN Gestor de Versiones, con licencia Apache/BSD, Por tanto,
el costo es 0euros
En total el costo por software es 0 euros
Costos por Personal
El personal requerido para el desarrollo de este proyecto es el
siguiente:
Analista de Proyectos con un costo de 27 euros/hrs
Diseñador de Proyectos con un costo de 22 euros/hrs
Programador con un costo de 18 euros/hrs
Tomando en cuenta, que la jornada laboral es de 8 hrs diarias
Los costos para este proyecto son (En este calculo esta incluida
la extensión)
Analista de Proyectos 35 dias * 8 hrs/dia * 27 euros/hrs =
7560euros
Diseñador de Proyectos 29 dias * 8 hrs/dia * 22 euros/hrs
= 5104euros
Programador 37 dias * 8 hrs/dia * 18 euros/hrs = 5328euros
El total por el concepto de personal para WAM ARM es 17992
euros.
54 CAPÍTULO 5. PLANIFICACIÓN, COSTOS Y LICENCIAS
5.2.2. Costos para IRI WAM
Costos por Software
A continuación detallo los costos generados por la utilización
de software
ROS ROS [2] es un sistema de codigo abierto y licencia BSD
[43], Por tanto, el costo es 0euros
UBUNTU La versión recomendada de ROS require el uso de
UBUNTU,Por tanto, el costo es 0euros
Geany [40] Editor de texto para programación, es Free Softwa-
re, Por tanto, el costo es 0euros
SVN Gestor de Versiones, con licencia Apache/BSD, Por tanto,
el costo es 0euros
En total el costo por software es 0euros
Costos por Personal
El personal requerido para el desarrollo de este proyecto es el
siguiente:
Analista de Proyectos con un costo de 27 euros/hrs
Diseñador de Proyectos con un costo de 22 euros/hrs
Programador con un costo de 18 euros/hrs
Tomando en cuenta, que la jornada laboral es de 8 hrs diarias
Analista de Proyectos 40 dias * 8 hrs/dia * 27 euros/hrs =
8640euros
5.2. COSTOS 55
Diseñador de Proyectos 25 dias * 8 hrs/dia * 22 euros/hrs
= 4400euros
Programador 30 dias * 8 hrs/dia * 18 euros/hrs = 4320euros
El total por el concepto de personal para IRI WAM es 17360
euros.
5.2.3. Costo para el Robot
A continuación calcularemos el coste por el concepto de ma-
quinaria. Para el cálculo de la amortización utilizaremos el me-
todo de tablas [59], el cual nos dice que al acabo de un año, la
amortización es del 12%.
Asumiremos que el robot fue comprado el dia anterior al inicio
de WAM ARM, con un valor de 140000 euros. Por tanto, si apli-
camos la amortización, veremos que el robot se desvalúa un total
de 16800 euros/año, quedando el robot valorizado en 123200 eu-
ros.
5.2.4. Costos por la Memoria
Aqui calculo, el costo que supondŕıa la realización de la me-
moria. A continuación detallo:
Latex [39]Procesador de texto,es free software, su costo es 0
euros
Geany [40] Editor de Texto ,es free software, su costo es 0 euros
ArgoUML [42] Software usado para diagramas UML, su costo
es 0 euros
Dia [41] Software usado para diagramas UML,su costo es 0 eu-
ros
56 CAPÍTULO 5. PLANIFICACIÓN, COSTOS Y LICENCIAS
El costo total creado por la memoria es de 0 euros
5.3. Licencias
En esta sección mostraré una pequeña explicación sobre las
licencias utilizdas en este proyecto
5.3.1. Licencia BSD
BSD [43],es la licencia de software otorgada principalmente
para los sistemas BSD (Berkeley Software Distribution). Es una
licencia de software libre permisiva como la licencia de OpenSSL
o la MIT License. Esta licencia tiene menos restricciones en com-
paración con otras como la GPL estando muy cercana al dominio
público. La licencia BSD al contrario que la GPL permite el uso
del código fuente en software no libre.
La primera versión de licencia BSD (de 4 cláusulas) fue revisada
poco tiempo después de ser creada, existiendo dos variantes de
ella: La nueva licencia BSD (o licencia BSD modificada) y la
licencia BSD simplificada (o licencia de FreeBSD)
5.3.2. Licencia LGPL
The GNU Lesser General Public License,es una licencia de
software creada por la Free Software Foundation. Los contratos
de licencia de la mayor parte del software están diseñados para
jugar con su libertad de compartir y modificar dicho software.
En contraste, la GNU General Public License pretende garan-
tizar su libertad de compartir y modificar el software ”libre”,
esto es para asegurar que el software es libre para todos sus
usuarios. Esta licencia pública general se aplica a la mayoŕıa del
5.3. LICENCIAS 57
software de la FSF o Free Software Foundation (Fundación para
el software libre) y a cualquier otro programa de software cuyos
autores aśı lo establecen. Algunos otros programas de software
de la Free Software Foundation están cubiertos por la ”LGPL
Lesser General Public License”(Licencia pública general reduci-
da), la cual puede aplicar a sus programas también.
Esta licencia permisiva se aplica a cualquier programa o trabajo
que contenga una nota puesta por el propietario de los derechos
del trabajo estableciendo que su trabajo puede ser distribuido
bajo los términos de esta ”GPL General Public License”. El
”Programa”, utilizado en lo subsecuente, se refiere a cualquier
programa o trabajo original, y el ”trabajo basado en el Progra-
ma”significa ya sea el programa o cualquier trabajo derivado del
mismo bajo la ley de derechos de autor: es decir, un trabajo que
contenga el Programa o alguna porción de él, ya sea ı́ntegra o
con modificaciones o traducciones a otros idiomas.
Otras actividades que no sean copia, distribución o modificación
si están cubiertas en esta licencia y están fuera de su alcance.
El acto de ejecutar el programa no está restringido, y la salida
de informacióndel programa está cubierta sólo si su contenido
constituye un trabajo basado en el Programa (es independiente
de si fue resultado de ejecutar el programa). Si esto es cierto o
no depende de la función del programa.
58 CAPÍTULO 5. PLANIFICACIÓN, COSTOS Y LICENCIAS
Caṕıtulo 6
Especificación y Diseño
6.1. Especificación
En esta etapa de la Ingenieŕıa del software es donde se ob-
tiene una especificación básica del sistema propuesto, y por lo
tanto, un prototipo inicial, éste prototipo inicial es equivalente a
una demostración (conocido como demo) del software final. En
ésta etapa se adquieren, reúnen y se especifican las caracteŕısti-
cas funcionales y no funcionales que deberá cumplir el software
final. Cabe remarcar que esta etapa es muy importante, ya que
el software final, el entorno y los parámetros no funcionales de-
penden del desarrollo de esta etapa. A demás en ésta etapa no
interviene únicamente el analista de proyectos, ya que se inter-
actúa con el cliente/usuario que utilizará el software final, por
lo tanto el analista debe ser capaz de extraer la mayor informa-
ción posible de lo que espera el cliente/usuario del software a
realizar. Después de aceptar este proyecto, como analista deb́ıa
de interiorizar en los temas y conceptos de la robótica, como
la odometŕıa, cinemática inversa, cinemática directa, etc. Todo
este proceso a sido muy interesante. Como resultado de esta tra-
bajo se generó un stack llamado ”WAM ARM”7 y luego en un
59
60 CAPÍTULO 6. ESPECIFICACIÓN Y DISEÑO
segundo desarrollo, se generaron una serie de package incluiudos
en el stack ÏRI WAM”8, por ese mitivo separo la especificación
en 2 partes.
6.2. Diseño
La etapa de diseño consiste en la toma de diversas decisiones,
que permitan desarrollar un sistema capaz de resolver satisfacto-
riamente todas las necesidades identificadas en la etapa de espe-
cificación. Si el objetivo de la etapa de especificación es detectar
que ha de hacer el sistema a desarrollar, entonces el objetivo de
la etapa de diseño es intentar responder a la pregunta ¿cómo
se tiene que hacer? Una vez identificado el problema, hay que
pensar como se relacionan las diferentes clases entre śı, es decir,
como se pasa la información de una a otra, quién crea un deter-
minado objeto, quién se encarga de guardar dicho objeto, etc.
Es en ésta etapa dónde nos preguntamos: ¿Qué componentes,
de los identificados en la etapa anterior, se tienen que modelizar
como componentes en la etapa de diseño?, ¿Qué asociaciones
del modelo conceptual tiene que aparecer en nuestro modelo de
componentes? Para responder a éstas preguntas en dónde en-
tran decisiones de diseño que dependiendo de las respuestas, el
diseño será más o menos robusto.
Éste es un capitulo importante, ya que es la base del proyecto,
ya que es muy importante la toma de decisiones que se toman
en esta etapa, y dependiendo de éstas decisiones, la evolución
del mismo será más o menos compleja, a demás de la etapa de
implementación que está bastante relacionada.
Durante la carrera de Ingenieŕıa Técnica en informática de ges-
tión, se realizó una asignatura que trataba sobre éste capitulo:
6.2. DISEÑO 61
Ingenieŕıa del Software I (ESO1), en esa asignatura se estudian
los diferentes métodos para poder realizar un buen diseño, du-
rante la realización de ésta etapa he visto como los conocimientos
adquiridos me han ayudado enormemente, aunque como es evi-
dente, en cuatro meses no se puede aprender todo y he tenido
que investigar libros porque mis conocimientos eran limitados a
lo que requeŕıa el proyecto. Las tareas que se desarrollan en la
etapa de diseño son las siguientes:
Asignación: Asignar las responsabilidades citadas a los com-
ponentes que creamos oportuno y cumpla con los requisitos
para realizar la tarea.
Descomposición: Descomponer las tareas a realizar en respon-
sabilidades
Recomposición colaborativa: Una vez hemos tratado los com-
ponentes individualmente tenemos que realizar un sistema
tal que colaboren los componentes entre si.
62 CAPÍTULO 6. ESPECIFICACIÓN Y DISEÑO
Caṕıtulo 7
Stack WAM ARM: Primer
Contacto
7.1. Códigos Gúıa: Wubble Robot y PR2 ro-
bot
El stack fue creado bajo la influencia de los siguientes stacks:
Wubble Code,[46]: Los creadores de este robot, han creado
un tutorial donde se pueden utilizar los códigos del brazo
del PR2 en un brazo no-PR2
PR2 Code[2]: Son todos los stack diponible desde la distribu-
ción ROS
A continuación explico los resultados
7.2. Licencia para WAM ARM
Al final este stack se convirtió en un stack de parendizaje
de los conceptos, tanto generales como mas avanzados, de ROS.
Por lo tanto no han sido publicados oficialmente, sin embargo,
63
64 CAPÍTULO 7. STACK WAM ARM: PRIMER CONTACTO
(a) Wubble Real (b) Wubble Simulado
Figura 7.1: Wuuble Robot
la licencia de este era BSD 5.3.1 De esta manera, permito que
alguien pueda mejorar estos código y los relicencie al tipo de que
le sea mas conveniente
7.3. Especificación y Diseño para WAM ARM
En esta sección, hablare sobre la especificación y desarrollo
para el WAM ARM.
Cabe destacar que debido a la arquitectura de ROS (cliente/servidor)
y la organización en package del mismo,y de acuerdo a las ne-
cesidades, Comencé en plantearme el diseño desde el modelo de
implementación(especificamente Diagramas de despliegue y dia-
gramas de Componentes). Otro punto que me gustaŕıa señalar
que en ROS, solo conozco la interficie de comunicación del pac-
7.3. ESPECIFICACIÓN Y DISEÑO PARA WAM ARM 65
kage, pero no conozco nada mas allá de esto, por tanto , los
paquetes de ROS son cajas negras.
7.3.1. Análisis de Requerimientos
Tenemos dos tipos de requisitos, conocidos como los requeri-
mientos funcionales y requerimientos no funcionales.
Los requisitos funcionales son aquellos que describen el com-
portamiento de las entradas del sistema, la funcionalidad y las
salidas del sistema, aśı como la relación entre ellos.
Los requisitos no funcionales son las que definen las cualidades
generales que cuando se tiene el sistema funciona.
Requerimientos Funcionales
1. Cada package debe contener el código necesario para llevar
a cabo la tarea asignada
2. Cada nodo creado debe representar una acción espećıfica
en robot
3. Cada package debe ser capaz de leer un mensaje deter-
minado con los datos necesarios para completar la tarea
asignada
4. El sistema debe ser capaz de calcular la cinemática inversa
de robots con diferentes grados de libertad
5. Los package deben ser fácilmente reemplazables
6. El sistema debe generar trayectorias consistentes
66 CAPÍTULO 7. STACK WAM ARM: PRIMER CONTACTO
7. El sistema debe conectarse correctamente con ROS
8. Los códigos deben ser eficientes
9. El sistema debe conocer las limitaciones mecánicas del ro-
bot
10. Las trajectorias deben estar dentro de los limites del robot
11. La navegación debe ser capaz de sortear obstáculos
Requirimientos No Funcionales
1. Debe ser bastante amigable de cara al usuario.
2. El usuario debe conocer lo justo para ejecutar el sistema
3. Evitar el uso de demasiadas consolas
7.4. Diagramas
En esta sección mostrare y explicare los esquemas utilizados
para este proyecto .Para esto, me han sido muy útiles los cono-
cimientos adquiridos en las asignaturas de ESOE y ESO1. La
dificultad que encontré fue en el modelo de la arquitectura de
cliente/servidor ROS, ya que en las asignaturas anteriormente
señaladas se centraron en el diseño mono-puesto. Este esfuer-
zo me exigió la forma de modelar esta situación, que me pare-
ció bastante bueno el apoyo en el libro ”Designing Concurrent,
Distributed and Real-Time Applications with UML”[60]
7.4. DIAGRAMAS 67
Figura 7.2: Ejemplo Diagrama de Despliegue
7.4.1. Diagrama de Despliegue
Diagramas de Despliegue ,Fig.7.2,corresponden al UML 2.0
estándar y muestran la disposición f́ısica de las diferentes nodos
que componen un sistema y la distribuciónde los componentes
de estos nodos. Los nodos del diagrama, representan a un ele-
mento f́ısico que existe en tiempo de ejecución o representan un
recurso computacional. Hay dos tipos de nodos:
Procesadores: Nodos con capacidad de procesamiento, puede
ejecutar un componente
Dispositivos: Nodos sin capacidad de procesamiento
Los nodos están conectados a través de conexiones bidirecciona-
les que a su vez puede estereotipadas. Estas conexione modelan
las asociaciones entre los nodos. Gráficamente un nodo está re-
presentado por un cubo en 3D.
En este proyecto hay un nodo servidor, que ejecuta el núcleo de
ROS. Todos los package,al ejecutar un launch,generaran un nodo
68 CAPÍTULO 7. STACK WAM ARM: PRIMER CONTACTO
de este diagrama, sea o no nodos de ROS. En otras palabras, ca-
da nodo contendrá el componente de cliente creado, que genera
la ejecución de un paquete de ROS. ROS por defecto, está co-
nectado a través de TCP, la conexión (o asociación) entre el
nodo cliente y el nodo de servidor es el tipo de >.
El diagrama resultante se muestra en la figura 7.3
7.4.2. Diagramas de Componentes
Diagramas de componentes ,Fig. 7.4, se describen los elemen-
tos f́ısicos del sistema, sus relaciones, sus dependencias, la co-
municación y otras condiciones. Estos componentes representan
todos los tipos de elementos de software que entran en la creación
de aplicaciones informáticas (por ejemplo, pueden ser archivos,
paquetes, bibliotecas, etc.) Un componente puede consistir en
un paquete, en muchas clases o un grupo de componentes más
pequeños. En un componente también puede tener, interfaces
y subsistemas. Destaco en esto, porque es el medio por el cual
ROS comunica sus mensajes .
Interfaces
Son los puntos de entrada/salida que el componente pone a
disposición del resto para generar comunicación entre ellos.
Subsistemas
Un subsistema es una agrupación en paquetes, de diferentes
componentes en un sentido lógico y para una simplificación de
la aplicación. Concluyo que, cada paquete ROS que he creado
es un componente por las siguientes razones
1. Cada paquete contiene una colección las clases y/o librerias.
7.4. DIAGRAMAS 69
Figura 7.3: Diagrama de Despligue para WAM ARM
Diagram de Despligue final para el stack wam arm
2. Cada uno de los paquetes de Ros tiene su propia interfaz.
3. La existencia de los package, se justifica paraa la simpli-
ficación del sistema. Un package, crea un nodo en tiempo
ejecución, que a su vez tiene una tarea única.
Visto desde este punto de vista, puedo concluir que: Un package
de ROS es un subsistema perteneciente a un stack de ROS, y
esto a su vez es un subsistema de ROS
70 CAPÍTULO 7. STACK WAM ARM: PRIMER CONTACTO
Figura 7.4: Diagrama de Componentes y sus Dependencias para WAM ARM
En este modelo podemos ver los servicios ofrecidos por los componentes y
las dependencias entre ellos. Hay que tener en cuenta, que el concepto de
servicio es de comunicación entre componentes y no pertenece al concepto
de los servicios de ROS
7.5. Descripción de los Packages
7.5.1. wam arm gazebo
Es el último package en unirse. Contiene un prototipo de plu-
gin dinámico, que no funciona del todo bien, debido a la escasa
documentación de Gazebo dificulto el trabajo y exigió mucho
más tiempo por el mismo problema.Este plugin mueve el robot
de forma lineal, en otras palabras,genera trayectorias lineales
para mover el robot visualmente, utilizando la cinemática direc-
ta También contiene un directorio urdf, donde se almacena toda
7.5. DESCRIPCIÓN DE LOS PACKAGES 71
la definición del robot y los ficheros mesh.
7.5.2. wam arm kinemtaics
He creado este package con la tarea de encargarse de todo lo
referente a la cinemática del robot Este paquete contiene varios
ficheros, que a continuación detallo
wam arm kinematics: Este es el que contiene toda la interfi-
cie de comunicación de ROS
wam arm ik solver: Contiene toda la información necesaria
para realizar los calculos de cinemática (por ejemplo, nom-
bre de links, nombre de joints)
wam arm ik: Contiene la codificación necesaria para convertir
los datos provenientes de ROS, al tipo que necesita una
libreria externa para calcular la cinemática inversa( Matriz
Homogénea)
wamik: Esta es la libreria externa que calcula la cinemática
inversa, se llama Kaijen
wam arm constant: Contiene variables que se mantienen cons-
tante durante toda la ejecución, por ejemplo los DOF.
wam arm utils: Es una clase auxiliar, contiene metodos de ve-
rificación, de transformación, etc.
A pesar de que funciona a la perfección, este package tiene un
pequeño detalle sobre la cinemática directa. Desde el punto de
vista conceptual de la cinemática directa, es la posición cartesia-
na del TCP (tool cental point), pero en este código, proporciona
una cinemática directa para cada joint del robot.
72 CAPÍTULO 7. STACK WAM ARM: PRIMER CONTACTO
7.5.3. wam arm teleop
Este package que he creado,es bastante simple, y es para co-
municar al nucleo el punto destino Este package tiene un codigo,
en from keyboard.cpp , que lee desde teclado la posición final
que deseo La manera de introducir los datos es bastante simple
y se muestra a continuación: L[x x x x x x x]
Si L es una J, x son los angulos al cual el robot debe moverse
(en radianes) para cada joint, Por lo tanto,queda asi: j[θ1 θ2 θ3
θ4 θ5 θ5 θ7]
Si L es una C, las x son las coordenadas cartesianas del punto
final: c[t,q̂],t es la traslación y q̂ es un cuaternión
Se comunica con wam arm interface mediante servicios, y las
clases internas lo hacen mediante topicos.
7.5.4. wam arm interface
Este paquete lo he crado con la idea, de generar un punto
neuralgico , que fuese capaz de conectar todos los paquetes del
WAM ARM. También que creado un servicio propio, llamado
SetPosition, que es por donde se recibe el punto de destino del
robot desde wam arm teleop. Se comunica con wam arm action
con acciones y con el resto mediante servicios
7.5.5. wam arm action
Este package es quien envia las posiciones [θ1 θ2 θ3 θ4 θ5 θ5 θ7]
para mover el robot en iri wam gazebo. Este se comunica con el
wam arm gazebo con tópicos y con wam arm interface mediante
acciones
7.6. EFECTOS DE UNA INADECUADA DOCUMENTACIÓN 73
7.6. Efectos de una inadecuada documenta-
ción
El problema mas grande que me encontre en este proyecto,
es la documentación de ROS y de Gazebo
En Gazebo, tla documentación es paupérrima,las explicaciones
de los metodos son bastante ambiguos, las cabeceras de las clases
mostradas en el website no coinciden conlas encontradas en el
package de ROS. La precariedad de la documentación de Gazebo
me ha causado una perdida de tiempo enomre.
En ROS,en cambio,la cantidad de información estan grande y en
ocasiones es tan densa, que me perdia y tenia que volver a releer
todo.De hecho, muchos conceptos adquiridos en WAM ARM,
los tuve que reaprender en IRI WAM, ya que estaban erróneos
7.7. Conclusión para WAM ARM
Como conclusión personal a este trabajo, puedo destacar:
1. He aprendido lo importante que es tener una buena docu-
mentación sobre los proyectos, códigos, etc métodos
2. He aprendido y refinado terminoloǵıa de robótica y termi-
noloǵıa de cinemática
3. Aprendido otra forma de implementar aplicaciones clien-
te/servidor
4. También tuve que aprender a tomar decisiones sobre el
desarrollo del sistema,Obviamente basandome en las lec-
ciones aprendidas durante la carrera ,Pero debido a mi po-
ca experiencia , muchas de estas desiciones no fueron las
acertadas.
74 CAPÍTULO 7. STACK WAM ARM: PRIMER CONTACTO
5. He aprendido a trabajar en grupos de trabajo, como resulta-
do de esto, aprend́ı a trabajar con brainstroming, aprend́ı a
debatir sobre que opciones era las mas acertada y también
aprend́ı a defender la validesa de mis ideas con argumentos
solidos
6. También he aprendido algo muy imoprtante, si algo funcio-
na no quiere decir que lo haga de forma correcta
Como conclusión al trabajo respecto a los
Habilidades_de_navegacion_para_el_robot

Outros

Ferramentas de estudo

Mais conteúdos dessa disciplina
