Tesis Alfredo Alvarado Lepe

UNIVERSIDAD POPULAR AUTNOMA DEL
ESTADO DE PUEBLA
___________________________________________________________
(NOMBRE DE LA ESCUELA)
Facultad de Electrnica
Facultad de Electrnica
Tesis
TITULO DE LA TESIS
Construccin de un Mapa del Entorno y
Navegacin de un Robot Mvil Autnomo
Trabajo de Investigacin
que para obtener el Ttulo de
Licenciatura en Ingeniera Binica

(nombre del ttulo
Ingeniero profesional)
Binico
Presenta
AlfredoPresenta:
Alvarado Lepe
Colocar en
este lugar, el Nombre
Asesor
Alfredo del
de laalumno
Asesor tesisLepe
Alvarado
logotipo de la
escuela en
caso de Dr. HctorAsesor
SimndeVargas
la tesis:
Martnez
existir.
ANEXO B4
Dr. Hctor Simn Vargas Martnez
Puebla, Pue., Mxico Junio de 2014
Puebla, Pue., MxicoJunio de 2014 (mes)
Juniode
de(ao)
2014
52
Agradecimientos
En primera instancia, le agradezco a mi familia el apoyo moral y econmico que me brindaron
a lo largo de toda la licenciatura, desde que ingrese a esta carrera hasta la consecucin de la
misma, la cual se ve representada con la elaboracin de la presente tesis.
En segunda instancia, le agradezco al equipo de trabajo del Laboratorio de Control y Robti-
ca de la UPAEP, y en especial a mi asesor el doctor Hctor Simn Vargas Martnez, por
brindarme los medios, tanto tecnolgicos como acadmicos, para concluir satisfactoriamente
los objetivos de este proyecto.
En tercera y ltima instancia, quiero agradecer a la Universidad Popular Autnoma del Esta-
do de Puebla (UPAEP) por permitirme hacer uso de sus instalaciones y equipo, especcamente
hablando de los laboratorios de la Facultad de Electrnica y la biblioteca, durante los meses
invertidos en la realizacin de este trabajo de investigacin.
III
Resumen
Para que cualquier vehculo o robot mvil pueda ser considerado autnomo debe ser capaz de
navegar sobre su entorno. La presente tesis expone la integracin e implementacin de uno de los
mtodos de navegacin ms utilizados en el campo de la robtica, el cual debido a su precisin y
dinamismo puede ser adaptado a cualquier tipo de vehculo terrestre que se desee automatizar.
Cabe mencionar que se ajustaron varios parmetros de los algoritmos de este mtodo y, adems,
se realizaron algunas mejoras en la transformacin de coordenadas, todo para obtener mejores
resultados al utilizarlo en el robot de servicio Donaxi@HOME.
La navegacin aqu expuesta puede resumirse en cuatro amplias etapas: Percepcin, Lo-
calizacin, Planicacin y Control de Movimiento. Adems, antes de poder implementarla se
requiere de un mapa del entorno de desenvolvimiento del autmata, el cual debe ser elaborado
previamente por dicho robot haciendo uso del algoritmo de SLAM. Est ltima parte, a diferen-
cia de la navegacin que es completamente autnoma, necesita de un operador humano y slo
se hace una vez durante todo el proceso.
Tambin, el proyecto aqu descrito requiere de una amplia gama de dispositivos electrnicos,
tales como son: un telmetro lser, un giroscopio, una palanca de mando (joystick), dos servomo-
tores con sus respectivos codicadores rotativos incrementales y un controlador DMC-40x0. Sin
embargo, una ventaja respecto a este punto es el hecho de que las conexiones a las fuentes de ali-
mentacin, los interruptores de encendido y apagado, as como toda la infraestructura mecnica
del robot, fueron proporcionadas por el Laboratorio de Control y Robtica de la UPAEP.
Por otro lado, para que la tarea de comunicar cada sensor y actuador entre s por medio
de un ordenador fuese completada, result necesaria la creacin e implementacin de varios
programas, escritos con los lenguajes C++ y Python, encargados de comunicar y procesar los
datos adquiridos y transmitidos, y estos a su vez requirieron de protocolos para enlazarse entre
s, mismos que fueron proporcionados por la plataforma ROS, la cual tiene un captulo completo
dedicado ella.
En conclusin, la siguiente tesis constituye una alternativa interesante para todos aquellos
que deseen automatizar algn vehculo mvil, ya que a partir de esta misma, Donaxi@HOME,
un robot de servicio diseado para asistir a las personas de la tercera y discapacitados, fue
capaz de realizar un mapa aproximado de su entorno, localizarse dentro de l y navegar ade-
cuadamente y de manera completamente autnoma a cualquier objetivo pedido dentro de su
medio de interaccin.
V
Abstract
For any vehicle or mobile robot can be considered autonomous must be able to navigate on their
environment . This project exposes the integration and implementation of one of the most used
navigation methods in the eld of robotics, which due to its precision and dynamism can be
adapted to any type of land vehicle that you want to automate. It is noteworthy that several
algorithm parameters of this method were adjusted and, moreover, some improvements were
made on the coordinate transformation. These modications were made to get better results in
the service robot Donaxi@HOME.
The navigation process exposed here can be summarized in four broad stages: Perception,
Location, Planning, and Motion Control. Also, before you can implement the navigation, it
requires a map of the robot's environment, which must be previously prepared by this one
using the SLAM algorithm. The map construction, unlike the navigation that is a completely
autonomous process, requires a human operator and is done only once.
Also, this project requires a wide range of electronic devices such as: a laser rangender, a
gyroscope, a joystick, two servo motors with their respective incremental rotary encoders, and
a DMC- 40x0 controller. However, an advantage on this part is the fact that the connections to
power supplies , switches on and o, as well as all the mechanical infrastructure of the robot,
were provided by the Laboratory of Control and Robotics of UPAEP.
On the other hand , to complete the task of communicating each sensor and actuator together
using a computer, were necessary the creation and implementation of various programs. These
nodes, which were written in the C++ and Python code, are the responsible of communicate
and process data acquired and transmitted by the electronic devices, and at the same time, they
required protocols to link to each other. These protocols are provided by the ROS environment,
which has a full chapter dedicated to explain it.
In conclusion, the thesis is interesting for all the people who want to automate a moving
vehicle, being Donaxi@HOME, a service robot designed to assist senior and disabled persons,
the living proof of the results of this researching. This robot is able to perform a rough map of
its environment, localize itself within it, and navigate properly and autonomously to reach any
navigation target given by an user.
VII
ndice general
Agradecimientos III
Resumen V
Abstract VII
ndice general IX
ndice de guras XIII
1. Motivos, objetivos y organizacin de la tesis 1
1.1. Motivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Organizacin de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. ROS: La arquitectura base del robot Donaxi@HOME 5

2.1. Ventajas y desventajas de usar ROS . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Conceptos importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Nivel del sistema de archivos . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Nivel de la computacin grca . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3. Nivel comunitario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Herramientas de ROS utilizadas en el robot Donaxi@HOME . . . . . . . . . . . . 9
2.3.1. Herramienta roslaunch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Paquete rosbag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Aplicacin rqt_graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4. Visor rviz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Introduccin a la navegacin 15
3.1. Percepcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Localizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1. Localizacin relativa mediante medidas propioceptivas . . . . . . . . . . . 16
3.2.2. Localizacin absoluta basada en hitos o landmarks . . . . . . . . . . . . . 16
3.2.3. Localizacin basada en mapas . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. Planicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Control de movimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.1. Desplazamiento diferencial . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.2. Desplazamiento omnidireccional . . . . . . . . . . . . . . . . . . . . . . . 20
IX
X NDICE GENERAL
4. Percepcin y localizacin en el robot Donaxi@HOME 21

4.1. Percepcin del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1. Sensado del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1.1. Telmetro lser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1.2. Giroscopio electrnico . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1.3. Codicador rotativo (encoder) . . . . . . . . . . . . . . . . . . . 23
4.1.2. Interpretacin de los datos adquiridos . . . . . . . . . . . . . . . . . . . . 24
4.1.2.1. Generacin de mapa . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2.1.1. Nodo spatial . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2.1.2. Nodo spatial_client . . . . . . . . . . . . . . . . . . . . 25
4.1.2.1.3. Nodo motor_gen_mapa . . . . . . . . . . . . . . . . . . 27
4.1.2.1.4. Nodo odom_tf . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.2.1.5. Nodo hokuyo_node . . . . . . . . . . . . . . . . . . . . 30
4.1.2.2. Navegacin en el mapa generado . . . . . . . . . . . . . . . . . . 31
4.1.2.2.1. Nodo motor_formula . . . . . . . . . . . . . . . . . . . 32
4.1.2.2.2. Nodos restantes . . . . . . . . . . . . . . . . . . . . . . 32
4.2. Localizacin del mvil en su medio . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1. Algoritmo de localizacin y elaboracin de mapa simultneos (SLAM) . . 33
4.2.2. Algoritmo de localizacin de Monte Carlo aumentado (AMCL) . . . . . . 35
4.2.2.1. La pose del robot . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.2.2. El ltro de Bayes . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2.3. El ltro de partculas . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2.4. El modelo de movimiento . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2.5. El modelo sensorial . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2.6. Algoritmo de Localizacin de Monte Carlo (MCL) . . . . . . . . 39
5. Planicacin de trayectorias en el robot Donaxi@HOME 41

5.1. Planicador de campos potenciales . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2. Interaccin con el entorno ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1. Tpicos relacionados a la librera de acciones (actionlib) . . . . . . . . . . 43
5.2.2. Otros tpicos de subscripcin . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.3. Otros tpicos de publicacin . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.4. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.5. Parmetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.6. Componentes con aplicaciones propias . . . . . . . . . . . . . . . . . . . . 45
5.3. Implementacin en un robot real . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3.1. Implementacin en el robot Donaxi@HOME . . . . . . . . . . . . . . . . . 47
6. Control de movimiento en el robot Donaxi@HOME 49

6.1. Motores y codicadores rotativos utilizados . . . . . . . . . . . . . . . . . . . . . 49
6.1.1. Informacin tcnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1.1.1. Especicaciones de los motores . . . . . . . . . . . . . . . . . . . 50
6.1.1.2. Especicaciones de los codicadores rotativos . . . . . . . . . . . 51
6.1.2. Disposicin en el robot Donaxi@HOME . . . . . . . . . . . . . . . . . . . 51
6.2. Controlador empleado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.1. Nivel de hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.2. Nivel de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3. Nodos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3.1. Nodo motor_gen_mapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3.2. Nodo motor_formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
NDICE GENERAL XI
7. Pruebas y resultados 59
7.1. Generacin de mapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.1.1. Estructura y funcionamiento del arreglo . . . . . . . . . . . . . . . . . . . 59
7.1.1.1. Roslaunch del arreglo . . . . . . . . . . . . . . . . . . . . . . . . 60
7.1.1.2. Nodos pendientes . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.1.1.2.1. Nodo joy_node . . . . . . . . . . . . . . . . . . . . . . 61
7.1.1.2.2. Nodo teleop_joy . . . . . . . . . . . . . . . . . . . . . . 62
7.1.1.2.3. Nodo map_saver . . . . . . . . . . . . . . . . . . . . . 62
7.1.1.3. Operacin en conjunto . . . . . . . . . . . . . . . . . . . . . . . 63
7.1.2. Pruebas realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.1.2.1. Generacin del mapa a velocidad baja . . . . . . . . . . . . . . . 64
7.1.2.2. Generacin del mapa a velocidad media . . . . . . . . . . . . . . 64
7.1.3. Mejoras implementadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2. Navegacin en el mapa generado . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.2.1. Estructura y funcionamiento del arreglo . . . . . . . . . . . . . . . . . . . 66
7.2.1.1. Roslaunch del arreglo . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2.1.2. Nodos pendientes . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2.1.2.1. Nodo maestro . . . . . . . . . . . . . . . . . . . . . . . 69
7.2.1.2.2. Nodo dinamic_goal . . . . . . . . . . . . . . . . . . . . 70
7.2.1.2.3. Nodo cancel_goal . . . . . . . . . . . . . . . . . . . . . 70
7.2.1.2.4. Nodo map_server . . . . . . . . . . . . . . . . . . . . . 71
7.2.1.3. Operacin en conjunto . . . . . . . . . . . . . . . . . . . . . . . 71
7.2.2. Pruebas realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.2.2.1. Navegacin basada en mapa a velocidad baja . . . . . . . . . . . 73
7.2.2.2. Navegacin basada en mapa a velocidad media . . . . . . . . . . 73
7.2.3. Mejoras implementadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8. Conclusiones y trabajo a futuro 77

8.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.2. Trabajo a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Apndice A. Nodo spatial_client 81

Apndice B. Nodo motor_gen_mapa 85
Apndice C. Nodo motor_formula 91
Apndice D. Nodo maestro 95
Apndice E. Nodo dinamic_goal 97
Apndice F. Nodo cancel_goal 99
Bibliografa 101
ndice de guras
1.1. Robot de servicio Donaxi@HOME . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Revisin sugerida de captulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conceptos principales a nivel de la computacin grca . . . . . . . . . . . . . . 8

2.2. Ventana de rqt_graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Ventana de rqt_graph mostrando una visualizacin distinta . . . . . . . . . . . . 12
2.4. Comparacin de visualizaciones en rqt_graph . . . . . . . . . . . . . . . . . . . . 12
2.5. Ventana de rviz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Fases de localizacin de robots basada en Landmarks . . . . . . . . . . . . . . . . 16

3.2. Planicacin de movimientos tosca pero exitosa de un robot . . . . . . . . . . . . 18
3.3. Tipos de ruedas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Telmetro lser utilizado en el robot Donaxi@HOME . . . . . . . . . . . . . . . . 22

4.2. Diagrama de funcionamiento de un girscopo electrnico . . . . . . . . . . . . . . 23
4.3. Giroscopio electrnico utilizado en el robot Donaxi@HOME . . . . . . . . . . . . 23
4.4. Diagrama de funcionamiento de un codicador ptico rotativo . . . . . . . . . . . 24
4.5. Arreglo de nodos para la generacin del mapa . . . . . . . . . . . . . . . . . . . . 24
4.6. Nodo spatial y sus ramicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7. Nodo spatial_client y sus ramicaciones . . . . . . . . . . . . . . . . . . . . . . . 26
4.8. Diagrama de bloques de un ltro de Kalman . . . . . . . . . . . . . . . . . . . . 27
4.9. Nodo motor_gen_mapa y sus ramicaciones . . . . . . . . . . . . . . . . . . . . 27
4.10. Nodo odom_tf y sus ramicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.11. Movimiento del robot Donaxi@HOME en el espacio . . . . . . . . . . . . . . . . 29
4.12. Robot con mltiples partes mviles, y por ende, varios frames . . . . . . . . . . . 29
4.13. Perl de puntos generado por el telmetro lser montado en el robot Donaxi@HOME 31
4.14. Nodo hokuyo_node y sus ramicaciones . . . . . . . . . . . . . . . . . . . . . . . 31
4.15. Arreglo de nodos para la navegacin en el mapa generado . . . . . . . . . . . . . 32
4.16. Nodo motor_formula y sus ramicaciones . . . . . . . . . . . . . . . . . . . . . . 32
4.17. Nodo slam y sus ramicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.18. Nodo amcl y sus ramicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.19. Problema de estimacin recursiva bayesiana . . . . . . . . . . . . . . . . . . . . . 34
4.20. Proceso de certidumbre en la adquisicin de datos . . . . . . . . . . . . . . . . . 34
4.21. Robot PR2 de Willow Garage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.22. La pose del robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.23. El modelo de movimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.24. Las cuatro distribuciones que componen al modelo sensorial . . . . . . . . . . . . 39
5.1. Esquema de funcionamiento del nodo move_base . . . . . . . . . . . . . . . . . . 42

5.2. Comportamientos de recuperacin predeterminados en el nodo move_base . . . . 46
5.3. Implementacin del nodo move_base en el robot Donaxi@HOME . . . . . . . . . 47
XIII
XIV NDICE DE FIGURAS
6.1. Motor utilizado en el robot Donaxi@HOME . . . . . . . . . . . . . . . . . . . . . 50

6.2. Dimensiones de motores de acuerdo a NEMA . . . . . . . . . . . . . . . . . . . . 50
6.3. Dimensiones reales de cada motor . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4. Disposicin de los motores en el robot Donaxi@HOME . . . . . . . . . . . . . . . 52
6.5. Controlador utilizado en el robot Donaxi@HOME . . . . . . . . . . . . . . . . . . 53
6.6. Tpicos suscritos al nodo motor_gen_mapa . . . . . . . . . . . . . . . . . . . . . 56
6.7. Tpicos suscritos al nodo motor_formula . . . . . . . . . . . . . . . . . . . . . . 57
7.1. Arreglo de nodos generacin de mapa con sus respectivos tpicos . . . . . . . . . 59

7.2. Elementos suscritos a record en el arreglo generacin de mapa . . . . . . . . . . . 60
7.3. Archivo original donaxi.launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.4. Palanca de mando utilizada por el robot Donaxi@HOME . . . . . . . . . . . . . 61
7.5. Nodo joy_node y sus ramicaciones . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.6. Nodo teleop_joy y sus ramicaciones . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.7. Proceso nal de generacin de mapa . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.8. Arreglo de nodos navegacin en el mapa generado con sus respectivos tpicos . . 66
7.9. Elementos suscritos a record en el arreglo navegacin en el mapa generado . . . . 67
7.10. Archivo original ultimate_move_base.launch . . . . . . . . . . . . . . . . . . . . 68
7.11. Interfaz del nodo maestro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.12. Tpicos importantes publicados por el nodo move_base . . . . . . . . . . . . . . 72
7.13. Prueba completa de navegacin basada en mapa realizada a velocidad a media . 74
Captulo 1
Motivos, objetivos y organizacin

de la tesis
1.1. Motivos
Desde su creacin en 1999 dentro del Departamento de Ingenieras (antes Departamento de Sis-
temas) de la Universidad Popular Autnoma del Estado de Puebla, el Laboratorio de Control y
Robtica se ha encargado investigar y desarrollar prototipos tecnolgicos, centrndose principal-
mente en el rea de la robtica de servicio. Desde robots telederigidos (controlados por Internet)
y limpiadores de playa hasta autmatas creados con nes mdicos, en el laboratorio se han de-
sarrollado y presentado mltiples proyectos tanto en concursos nacionales como internacionales,
habindose obtenido resultados importantes en la mayora de estos.
Uno de los proyectos ms ambiciosos que se est desarrollando actualmente en el Laboratorio

de Control y Robtica es el robot de servicio domstico Donaxi@HOME (ver gura 1.1), el
cual tiene como nalidad principal asistir a las personas de la tercera edad y discapacitados en
sus actividades cotidianas. Aunque si bien es cierto que para lograr este objetivo se requieren
de una gran cantidad de funciones, hay una que destaca entre todas ellas: la capacidad de
navegar.
Figura 1.1: Robot de servicio Donaxi@HOME
1
2 CAPTULO 1. MOTIVOS, OBJETIVOS Y ORGANIZACIN DE LA TESIS
Donaxi@HOME debe de tener la capacidad de trasladar al usuario con quin interacte

a la cocina o al bao si es que este se lo solicita, o bien, debe poder posicionarse en cualquier
lugar del entorno en que se desenvuelva si as se lo indican, todo de manera automtica. Estas
son tareas que requieren de una navegacin precisa y amigable al usuario.
Aunque si bien es cierto que en la presente tesis no se da una denicin formal de la nave-
gacin y sus elementos hasta el tercer captulo, queda demostrado que es un elemento de fun-
damental importancia en el desarrollo del robot aqu presentado, esto sin mencionar que su
realizacin como proyecto de tesis requiri de una inversin considerable en cuestiones de tiem-
po, dinero y esfuerzo.
A continuacin se exponen los objetivos que se pretenden conseguir con la realizacin de este
trabajo, as como la organizacin temtica con la que fue nalmente estructurado.
1.2. Objetivos
Esta tesis tiene como objetivo principal permitirle al robot de servicio Donaxi@HOME ser
capaz de realizar las siguientes dos tareas:
1. Generar un mapa aproximado de su entorno para su desenvolvimiento con ayuda de un

operador.
2. Navegar de manera adecuada hacia cualquier objetivo que el usuario le solicite, siempre y
cuando dicho robot haya generado un mapa de su ambiente previamente.
Para que el autmata pueda cumplir con estas encomiendas, a su vez se requiere de lo
siguiente:
Analizar y comprender el funcionamiento del ltro de Kalman y el algoritmo de SLAM

para su posterior implementacin en la generacin del mapa del entorno.
Analizar y comprender el funcionamiento de los algoritmos de Monte Carlo y de campos

potenciales para su posterior implementacin en la navegacin del medio.
Tener nociones bsicas acerca de los sistemas operativos basados en LINUX, especca-
mente Ubuntu 12.04 LTS, ya que son los que mejor funcionan con el entorno ROS.
Aprender a utilizar el entorno ROS y perfeccionar su manejo en la medida de la posible,

ya que representa a la arquitectura base del presente proyecto.
Comprender la manera en que operan los sensores que utiliza el robot para poder, en
segunda instancia, adquirir datos a partir de estos y procesarlos.
Comprender la manera en que operan el controlador y los motores usados por el robot
para poder, en segunda instancia, comunicarse con el primero y controlar y monitorizar el
movimiento de los segundos.
Realizar el trabajo de software pertinente para enlazar todos los procesos necesarios para
la ejecucin de ambas tareas.
1.3. Organizacin de la tesis

La navegacin es un problema bastante complejo que necesita de importantes recursos, tanto
a nivel de hardware como de software, para resolverse. La presente tesis est organizada de
manera que todos los elementos implicados en su realizacin puedan ser explicados fcilmente,
partiendo de un plano general, que representa las bases tericas del proyecto, y desembocando
1.3. ORGANIZACIN DE LA TESIS 3
en cuestiones especcas de su implementacin. A continuacin se expone la estructuracin de

captulos.
Para que la generacin del mapa del entorno y su posterior navegacin sean posibles, se
requiere de una cantidad considerable de programas capaces de comunicarse entre s y con
los dispositivos electrnicos que componen al robot. Para poder cubrir esta necesidad se utiliz
ROS, un poderoso arsenal computacional que cada vez se utiliza ms en el campo de la robtica
y del cual se brindar un panorama general en el captulo dos.
Con la nalidad de hacer ms simple el estudio de la navegacin, est suele dividirse en
cuatro etapas, mismas que representan la base terica de todo este proyecto. El captulo tres
consiste en una breve introduccin de cada una de ellas y de la navegacin en general.
Debido a la importancia que tienen las etapas mencionadas anteriormente, se dedicarn tres
captulos, del cuatro al seis, para explorarlas a detalle. Sin embargo, estas secciones no estarn
orientadas para exponerlas de manera general, sino ms bien para describir la interaccin que
tiene cada una de ellas con el robot Donaxi@HOME.
El captulo siete, como su nombre lo indica, contiene informacin especca acerca de las
pruebas ms relevantes realizadas con el presente autmata, as como los principales resultados
obtenidos a partir de estas. Adems, en dicha seccin sern expuestos todos aquellos elementos
que, debido a diversos motivos, no fueron abordados en apartados anteriores pero tienen fun-
ciones importantes dentro de la generacin del mapa y la navegacin. Tambin aqu se menciona
un breve resumen de cada una de estas dos tareas, principalmente a nivel de software.
En el octavo y ltimo captulo de la tesis, el cual tambin es el de menor extensin, son
expuestas las conclusiones nales obtenidas a partir de la realizacin de este proyecto, as como
algunas propuestas en el caso de que, en un futuro, se desee continuar con su desarrollo y
actualizacin.
En la gura 1.2 se muestra un diagrama con todos los captulos de esta tesis, en el cual se
expone esquemticamente como debe de revisarse para obtener un mejor provecho de la misma.
Figura 1.2: Revisin sugerida de captulos

Captulo 2
ROS: La arquitectura base del robot

Donaxi@HOME
ROS, Robot Operating System, es un sistema metaoperativo1
por sus siglas en ingls
para robots de cdigo abierto (open source) . Este proporciona los servicios que cabe esperar
2
de un sistema operativo, incluyendo abstraccin de hardware, control de dispositivos de bajo
nivel, y la implementacin de la funcionalidad de uso comn entre los procesos de paso de
mensajes y gestin de paquetes. Tambin brinda herramientas y bibliotecas para la obtencin,
la construccin, la escritura y la ejecucin de cdigo en diversos ordenadores[1].
ROS funciona creando una red de procesos punto a punto que estn dbilmente acoplados
entre s utilizando la infraestructura de comunicacin que este mismo proporciona. Adems,
implementa varios mtodos diferentes de comunicacin, incluida la comunicacin sincrnica de
estilo RPC (Remote Procedure Call3 ) por medio de servicios, la transmisin asncrona
de datos a travs de tpicos de operacin y el almacenamiento de datos en un servidor de
parmetros[1].
Aunque este sistema no esta diseado para ejecutar instrucciones en tiempo real, posee
herramientas integradas al mismo que le permiten efectuar tareas de esta manera[1].
2.1. Ventajas y desventajas de usar ROS

Adems de ser una plataforma de cdigo abierto como fue mencionado anteriormente, ROS
ofrece muchas otras ventajas. A continuacin se mencionan las ms relevantes:
Esta diseado para ser lo menos pesado posible, por lo que el cdigo escrito en ROS puede
utilizarse con otros marcos de software para robot. Ha sido integrado exitosamente con
OpenRAVE, Orocos y Player[1].
Sus libreras estn diseadas de tal forma que resultan fciles de comprender y poseen
interfaces limpias para el usuario[1].
1 Un sistema metaoperativo es una plataforma que se construye y ejecuta sobre un sistema operativo
completo[2].
2 El software de cdigo abierto es aquel que puede ser utilizado libremente, ser intercambiado y compartido
(sufriendo modicaciones o sin ser alterado) por cualquier persona. Es distribuido bajo licencias de carcter libre
denidas por The Open Source Initiative[3].
3 La llamada a procedimiento remoto (en ingls RPC) es un protocolo que permite a un programa de ordenador
ejecutar cdigo en otra computadora remota sin tener que preocuparse por las comunicaciones entre ambas
mquinas. De esta manera el programador no tiene que estar pendiente de las comunicaciones, estando stas
encapsuladas dentro de las RPC. Estos protocolos son muy utilizados dentro del paradigma cliente-servidor.[4]
5
6 CAPTULO 2. ROS: LA ARQUITECTURA BASE DEL ROBOT DONAXI@HOME
Soporta mltiples lenguajes de programacin lo que le brinda una gran versatilidad de

implementacin. ROS posee libreras perfectamente funcionales para Python, C++ y Lisp,
y adems existen otras experimentales para Java y Lua[1].
Posee un marco de prueba de unidad/integracin incorporado llamado ROSTEST, el cual

permite que resulte fcil llevar a cabo pruebas de las aplicaciones desarrolladas, pudiendo
as mantener o detener la ejecucin de las mismas dinmicamente[1].
Es escalable, es decir, funciona apropiadamente en sistemas con tiempos de ejecucin

grandes y con bastos procesos de desarrollo[1].
Se encuentra en proceso de mejora y actualizacin continuamente. Esto se debe a que la

comunidad ROS, que son bsicamente todos los usuarios que lo utilizan, desarrollan cons-
tantemente nuevas aplicaciones y resuelven interrogantes sobre el uso de esta plataforma
en los foros de ayuda[5].
La principal desventaja de ROS, y posiblemente la nica que tiene, es que en la actualidad

slo se ejecuta en las plataformas basadas en Unix. Por esta razn, su software se utiliza princi-
palmente en sistemas Ubuntu y Mac OS X, aunque la comunidad ROS ha contribuido el apoyo
a Fedora, Gentoo, Arch Linux y otras plataformas Linux[1].
A pesar de que es posible utilizar un puerto de acceso para Microsoft Windows en ROS, esto
an no se ha explorado a fondo[1].
2.2. Conceptos importantes

Los conceptos de ROS se clasican en tres niveles:
1. A nivel del sistema de archivos.
2. A nivel de la computacin grca.
3. A nivel comunitario.
2.2.1. Nivel del sistema de archivos

Los conceptos a nivel del sistema de archivos se reeren principalmente a recursos de ROS que
encuentre en el disco duro de la computadora que lo alberga[5]. Los ms representativos son:
Paquetes: Son la unidad principal de la organizacin de software de ROS. Estos pueden

contener a: los procesos de ROS en tiempo de ejecucin (nodos), una librera dependiente
de ROS, conjuntos de datos, archivos de conguracin o cualquier otra cosa que deba
organizarse ecazmente, todo junto. Por esta razn, son el elemento de construccin ms
atmico y el punto de liberacin de dicho sistema metaoperativo, es decir, representan lo
ms elemental que se puede elaborar y utilizar en esta plataforma[5].
Metapaquetes: Son paquetes especializados que slo sirven para representar un grupo
de otros paquetes relacionados. Ms comnmente se utilizan como un lugar reservado
compatible para colecciones de programas ( stacks ) convertidos utilizando la herramienta
rosbuild [5].
Maniestos de paquetes: Son los archivos llamados package.xml existentes dentro los
paquetes de ROS cuya misin es proporcionar metadatos acerca de estos, lo cual incluye:
su nombre, su versin, su descripcin, informacin sobre su licencia, sus dependencias y
alguna que otra metainformacin como es el caso los paquetes que han sido exportados[5].
Para saber ms acerca de estos maniestos, se recomienda leer la documentacin REP-
0127 disponible en lnea[7].
2.2. CONCEPTOS IMPORTANTES 7
Repositorios: Son colecciones de paquetes que comparten un sistema VCS (Version

Control System4 ) comn. Los elementos con esta caracterstica poseen la misma versin
y pueden ser liberados o ejecutados al mismo tiempo usando la herramienta de liberacin
automtica bloom, la cual viene incluida en el gestor de paquetes catkin de ROS Groovy. A
menudo, estos se encuentran asignados a Stacks compilados con rosbuild. Cada repositorio
puede contener nicamente un paquete[5].
Tipos de mensajes (msg): Su funcin es denir las estructuras de datos para los men-
sajes enviados a travs de ROS. Se ubican en las carpetas llamadas msg existentes dentro
de los paquetes y se identican de otros archivos mediante la terminacin .msg [5].
Tipos de servicios (srv): Su funcin es denir las estructuras para solicitud y recepcin
de datos requeridas por los servicios que proporciona ROS y pueden crearse dentro del
mismo. Se ubican en las carpetas llamadas srv existentes dentro de los paquetes y se
identican de otros archivos mediante la terminacin .srv [5].
2.2.2. Nivel de la computacin grca

La computacin grca de ROS es la red de procesos que se encarga de la manipulacin de
los datos que uyen a travs de dicho sistema metaoperativo[5]. Los conceptos principales de
este nivel, los cuales proporcionan informacin al mismo de diferentes maneras, se mencionan a
continuacin:
Nodos: Son los procesos que realizan la computacin dentro de ROS. Debido a que dicha
plataforma metaoperativa est diseada para ser modular en una escala de grano no; un
sistema de control para un robot comprende generalmente muchos nodos. Por ejemplo, un
nodo controla un telmetro de lser, otro controla los motores de las ruedas, uno ms lleva
a cabo la localizacin, otro ms realiza planicacin de trayectoria, un ltimo proporciona
una vista grca del sistema y as sucesivamente. Un proceso de este tipo est escrito con el
roscpp (utilizada para lenguaje C++)
uso de una biblioteca de cliente de ROS, tales como
o rospy (usada en Python)[5]. Para invocar un nodo independiente sobre la terminal de
Linux, basta con tener un roscore activo (se explicar ms adelante) y usar la siguiente
sintaxis: rosrun nombre_paquete nombre_nodo
5
Maestro: Proporciona el registro de nombres y bsqueda para el resto de la computacin

grca. Sin el maestro, los nodos no seran capaces de encontrarse unos a otros, realizar
mensajes de cambio o invocar servicios[5].
Servidor de parmetros: Permite que los datos sean almacenados mediante una clave
en una ubicacin central. Actualmente forma parte del maestro[5].
Mensajes: Los nodos se comunican entre s mediante el paso de mensajes. Estos ltimos
son simplemente estructuras de datos, donde cada una comprende campos de un tipo
especco. Se admiten los tipos primitivos estndar (entero, coma otante, booleanos,
etc), as como los arreglos de tipos primitivos. Los mensajes pueden incluir estructuras
y arrays anidados arbitrariamente, guardando cierta similitud con lo que ocurre en las
estructuras ( Struct ) del lenguaje C[5].
4 Un sistema de control de versiones (en ingls VCS) o sistema de control de revisiones es una combinacin
de tecnologas y prcticas para el seguimiento y el control de cambios realizados a los archivos de un proyecto.
Los sistemas VCS suelen implementarse en el cdigo fuente y la documentacin del software fabricado. Son muy
utilizados en la creacin y el desarrollo de las pginas web.[8]
5 Sin terminacin en caso de haber sido creado en c++ y con terminacin .py en caso de ser un programa de
python.
Tpicos: Los mensajes se enrutan a travs de un sistema de transporte que se basa en la

semntica publicacin/suscripcin. Un nodo enva un mensaje publicndolo con un tpico
determinado y, de la misma forma, si otro nodo o el mismo est interesado en dicha in-
formacin se suscribir al mencionado tpico. En otras palabras, un tpico es el nombre
que se utiliza para identicar al contenido de un mensaje. Pueden haber mltiples publi-
cadores y suscriptores concurrentes para un solo tpico y un nico nodo puede publicar
y/o suscribirse a mltiples tpicos. En general, los publicadores y suscriptores no son cons-
cientes de la existencia de los dems. La idea es disociar la produccin de informacin de su
consumo. Lgicamente, se puede pensar en un tpico como un bus de mensajes inexible
de tipos. Cada bus tiene un nombre y cualquier persona puede conectarse al mismo para
enviar o recibir mensajes siempre y cuando sean del tipo correcto[5].
Servicios: El modelo de publicacin/suscripcin es un paradigma de comunicacin muy

exible, sien embargo, su transporte de un solo sentido de varios datos para varios datos
no es apropiado para interacciones de solicitud/respuesta que a menudo se requieren en un
sistema distribuido. Estas interacciones se realizan a travs de servicios, que se denen
por un par de estructuras de mensajes: una para la solicitud y otra para la respuesta.
Un nodo proveedor ofrece un servicio con un nombre y un cliente utiliza dicho servicio
mediante el envo de un mensaje de solicitud y espera la respuesta. Las libreras para
clientes de ROS generalmente presentan esta interaccin para el programador como si
fuera una llamada para un procedimiento remoto[5].
Contenedores (bags): Son un tipo de archivo diseado para guardar y reproducir datos
de mensajes de ROS. En consecuencia, son un mecanismo importante para el almace-
namiento de datos que pueden ser difciles de recoger, pero son necesarios para desarrollar
y probar algoritmos. Un ejemplo de este tipo de informacin es aquella que proviene de
los sensores conectados al robot[5].
A modo de resumen, la gura 2.1 muestra una comunicacin entre dos nodos de ROS.
Se puede apreciar la invocacin de un servicio y la utilizacin de un tpico que permite el
intercambio de informacin entre un publicador y un suscriptor.
Figura 2.1: Conceptos principales a nivel de la computacin grca [5]
2.2.3. Nivel comunitario

Los conceptos a nivel comunitario son los recursos de ROS que le permiten a las distintas comu-
nidades que usan este sistema intercambiar software y conocimientos[5]. Los ms representativos
son los siguientes:
Distribuciones: Son colecciones de programas con versiones especcas que se pueden

instalar. Las distribuciones de ROS (ROS Electric Emys, ROS Fuerte Turtle, ROS Groovy
2.3. HERRAMIENTAS DE ROS UTILIZADAS EN EL ROBOT DONAXI@HOME 9
Galapagos, etc. [6]) juegan un papel similar al de las distribuciones de Linux (Ubuntu, Fe-
dora, etc.): hacen ms fcil la instalacin de una coleccin de software y tambin mantienen
versiones consistentes en un conjunto de aplicaciones[5].
Repositorios: ROS se basa en una red federada de repositorios de cdigo, en los que
diferentes instituciones puedan desarrollar y lanzar sus propios componentes de software
para robots[5].
Wiki de ROS (ROS Wiki): Es el foro virtual ms importante que existe para documen-
tar informacin acerca de ROS. Cualquier persona puede inscribirse creando una cuenta,
contribuir con su propia documentacin, proporcionar correcciones o actualizaciones, es-
cribir tutoriales y ms[5].
Sistema de boletos para errores: Es una herramienta creada para los usuarios de ROS,
la cual les permite que, en caso de que estos encuentren un error dentro de dicha plataforma
o en algn software relacionado a la misma, puedan reportarlo adecuadamente[9].
Lista de correos para usuarios: Es el canal principal de comunicacin que informa

los nuevos cambios aadidos a ROS y, al mismo tiempo, es un foro para hacer preguntas
acerca del software relacionado a esta plataforma[5].
Respuestas de ROS (ROS Answers): Es un sitio web con formato pregunta/respuesta

diseado para responder a los usuarios interrogantes con respecto a ROS[5].
Blog: Administrado por Willow Garage, incubadora de empresas y laboratorio de investi-

gacin en robtica dedicado a la creacin de software de cdigo abierto con el objetivo de
desarrollar aplicaciones para robots personales[10], es una bitcora digital que ofrece actua-
lizaciones peridicas, incluyendo fotos y vdeos demostrativos acerca del entorno ROS[5].
Cabe mencionar que la organizacin que controla este blog, es tambin la encargada de
mantener y mejorar a ROS, aunque no es la creadora de esta plataforma[10].
2.3. Herramientas de ROS utilizadas en el robot Dona-

xi@HOME
La distribucin de ROS que el robot Donaxi@HOME utiliz para realizar la tarea de nave-
gacin, tal y como se describe a lo largo de la presente tesis, es la versin ROS Groovy
Galapagos.
Esta distribucin cuenta con muchas herramientas que permiten detectar errores, visualizar
resultados y facilitar la ejecucin de nodos. Entre dichos complementos destacan cuatro que, por
su sencillez y funcionalidad, fueron utilizados repetidamente a lo largo de este proyecto, siendo
presentados en la siguiente lista:
a) Herramienta roslaunch.
b) Paquete rosbag.
c) Aplicacin rqt_graph.
d) Visor rviz.
A lo largo de la presente tesis se presentan varias imgenes que muestran los resultados
obtenidos en las pruebas realizadas con el robot Donaxi@HOME. Dichas ilustraciones fueron
obtenidas, en su mayora, gracias a las elementos c) y d) de la lista anterior.
2.3.1. Herramienta roslaunch

La herramienta roslaunch permite realizar la ejecucin de mltiples nodos de ROS de manera
local y remota a travs de SSH, as como el establecimiento de parmetros para dichos nodos
en el servidor. Incluye opciones para reactivar de forma automtica los procesos que han sido
abortados o eliminados [11].
Roslaunch toma de uno o ms archivos de conguracin XML, los cuales deben poseer la
terminacin .launch, los parmetros para establecer y poner en marcha los nodos a ejecutar.
Tambin realiza la activacin de diversos procesos de ROS, tales como roscore, cuyo fun-
cionamiento resulta necesario para el funcionamiento de cualquier programa sobre este sistema
metaoperativo [11].
El paquete roslaunch contiene a la aplicacin homnima y mltiples herramientas rela-
cionadas, todas compatibles con el formato .launch/XML, diseadas para facilitar la utilizacin
de estos archivos [11].
La sintaxis bsica para ejecutar un roslaunch sobre la terminal de Linux es la siguiente:
roslaunch nombre_paquete nombre_roslaunch.launch [11]
Existe una especializacin de esta herramienta llamada roscore, la cual sirve para invo-
car el ncleo (core) del sistema ROS [11]. Sin esta utilidad, resulta imposible invocar nodos
independientes sobre la terminal de Linux.
Para invocar esta aplicacin sobre una terminal, basta con escribir roscore y presionar la
tecla enter.
2.3.2. Paquete rosbag

El paquete rosbag consiste en un conjunto de herramientas para grabar y reproducir tpicos
publicados a travs de ROS. Dicho software, diseado para tener un alto rendimiento, fue creado
con la nalidad de evitar la serializacin y deserializacin de los mensajes comunicados en este
sistema metaoperativo [12].
Las utilidades del paquete aqu descrito pueden ser invocadas haciendo uso de la lnea de
comandos, las cuales permiten trabajar tanto con bolsas de datos (bags) como con aplicaciones
de lectura/escritura compatibles con los lenguajes C++ y Python [12].
Los comandos soportados por esta aplicacin son los siguientes: record, info, play, check,
x, lter, compress, decompress y reindex [13].
Dentro de la lista proporcionada en el prrafo previo, las herramientas record y play fueron
resaltadas textualmente debido a que ambas tuvieron una importancia crucial dentro de la
realizacin de este proyecto, razn por la cual son explicadas a continuacin.
La utilidad rosbag record le permite al usuario suscribirse a cualquier cantidad de tpicos
que estn siendo publicados sobre ROS y guardar todos los mensajes transmitidos a travs de
estos en un archivo .bag. Este es el formato de grabacin ms amigable con el disco duro y, al
mismo tiempo, el de mayor rendimiento que ofrece ROS [13].
La herramienta rosbag play lee el contenido de uno o ms archivos .bag y los reproduce
durante un periodo de tiempo con una sincronizacin especca, la cual se produce con base a
las marcas de tiempo globales en que se recibieron mensajes. La reproduccin comenzar inme-
diatamente y luego ms mensajes se publicarn de acuerdo a los tiempos de espera producidos
durante la publicacin de los mensajes[13].
Si se utilizan dos o ms archivos .bag de manera separada y luego deciden tratarse como uno
slo con tiempos entrelazados de acuerdo con las marcas de tiempo denidas por la publicacin
de los mensajes, esto signicar que si se graba una bolsa de datos, se espera una hora y luego
se registra una segunda, cuando se reproduzcan en conjunto se tendr un perodo de tiempo
muerto de una hora en medio de la reproduccin entre ambos archivos[13].
Existen mltiples parmetros que pueden variarse cuando se invoca cualquier utilidad del
paquete rosbag sobre la terminal[13], sin embargo, aqu se abordar nicamente la sintaxis ms
comn empleada tanto con record como con play en el presente proyecto.
La sintaxis bsica del comando record es la siguiente: rosbag record -O /ruta/archivo.bag
/topico1 /topico 2 (...) [13], donde los tres puntos signican que se pueden realizar suscrip-
ciones a cualquier cantidad de tpicos.
La sintaxis ms simple de la funcin play es la siguiente: rosbag play /ruta/archivo.bag

[13]
2.3.3. Aplicacin rqt_graph

La aplicacin rqt_graph proporciona un complemento (plugin) que permite visualizar ele-
mentos a nivel de la computacin grca de ROS a partir de una interfaz grca para el usuario.
Sus componentes estn hechos de manera genrica para que otros paquetes, de los cuales de desea
lograr la representacin grca puedan depender de esta aplicacin, que en s tambin pertenece
a un paquete[14].
En la gura 2.2 se muestra una ventana tpica de rqt_graph. Los recuadros representan
tpicos y los valos representan nodos. Se puede ver claramente que el elemento rojo, donde se
haya posicionado el cursor, representa a un tpico que esta siendo publicado por dos nodos (en
azul) y, al mismo tiempo, un tercero (en verde) se esta subscribiendo al mismo.
Figura 2.2: Ventana de rqt_graph [14]
Para visualizar nicamente la interaccin entre nodos basta con hacer un ajuste en el men
que aparece en la esquina superior izquierda del panel, justo en donde apunta el cursor, de esta
forma los tpicos aparecern sobre las lneas que unen a dichos nodos. Todo se muestra en la
gura 2.3.
La ventaja que ofrece la conguracin de rqt_graph mostrada en la imagen 2.3 con respecto
a la vista en el diagrama 2.2 es que, al seleccionar un nodo, no slo cambian de color los tpicos
asociados a este, sino que adems se iluminan los nodos que publican dichos tpicos, lo que
proporciona un mejor entendimiento del proceso analizado. Esto se muestra en la gura 2.4.
Figura 2.3: Ventana de rqt_graph mostrando una visualizacin distinta. El arreglo

de nodos mostrado en esta imagen es diferente al visualizado en el diagrama 2.2.
Figura 2.4: Comparacin de visualizaciones en rqt_graph

2.3.4. Visor rviz

La herramienta rviz se trata de un entorno de visualizacin en tres dimensiones, el cual permite
entender lo que el robot esta observando, procesando y haciendo[15]. Existen dos maneras de
enviarle informacin a este visor:
1. Comunicar la informacin proveniente de los sensores con el formato adecuado como sera,
por ejemplo, utilizar el tipo de dato escaneo lser (laser scan) para transmitirle a rviz la
lectura homnima[15].
2. Disear marcadores de visualizacin. Estos elementos son guras en tres dimensiones,

tales como echas y poliedros, que pueden ser creadas y personalizadas para que aparezcan
en el entorno con diferentes propsitos[15].
Todo lo anterior convierte a rviz en un poderoso instrumento, ideal para entender aplicaciones
de depuracin. Al igual que todas las aplicaciones incorporadas a ROS es de cdigo abierto[15].
En la gura 2.5 se muestra una ventana del visor anteriormente descrito, el cual es utilizado
para entender el accionar de un robot diseado por Willow Garage.
Figura 2.5: Ventana de rviz [15]

Captulo 3
Introduccin a la navegacin
Se le llama navegacin al conjunto de mtodos y tcnicas usados para dirigir el curso de un
robot mvil a medida que ste atraviesa su entorno. Se dice que un robot ha logrado navegar
exitosamente a un destino pedido, si se desplaza hacia l sin perderse y sin chocar ni con
obstculos jos, ni con otros mviles que eventualmente puedan aparecer en el camino[16].
La navegacin es una tarea muy compleja pero puede dividirse en cuatro amplias etapas que
sern denidas brevemente a largo de este captulo y sern retomadas y analizadas a detalle en
captulos posteriores, enfocando cada una de ellas al robot Donaxi@HOME, autmata para
el cual fue realizada la presente tesis:
1. Percepcin.
2. Localizacin.
3. Planicacin.
4. Control de movimiento.
3.1. Percepcin
Muy estrechamente ligada a la autonoma de un robot est la capacidad de percibir el entorno
y actuar sobre el mismo. Por medio de los sensores el robot obtiene datos sobre su entorno
sensado) y luego los procesa para su utilizacin (interpretacin). De esta forma, los sensores
(
representan para el robot la fuente de datos sobre los cambios tanto en su entorno (distancias a
objetos, luz ambiental) como en s mismo (nivel de las bateras, consumo de los motores, pulsos
de codicadores, etc.)[17].
Acorde a lo dicho en el prrafo anterior, la percepcin del robot puede denirse como
el conjunto de modelos de medicin del entorno, los cuales describen el proceso de formacin
por el cual las mediciones de los sensores se generan en el mundo fsico. Dependiendo del sensor
utilizado sern las especicaciones del modelo a implementar[18].
3.2. Localizacin
En trminos de robtica, se dice que un vehculo o autmata es capaz de realizar el proceso de
localizacin si puede encontrarse as mismo dentro de una regin determinada. Esta es la tarea
ms importante en el desarrollo de la navegacin.
Actualmente los robots mviles pueden realizar esta tarea de diversas maneras, las cuales se
pueden clasicar en tres categoras de la siguiente forma:
15
16 CAPTULO 3. INTRODUCCIN A LA NAVEGACIN
Localizacin relativa mediante medidas propioceptivas.
Localizacin absoluta basada en Hitos o Landmark.
Localizacin basada en mapas.
3.2.1. Localizacin relativa mediante medidas propioceptivas

La localizacin relativa, en general es aquella que est basada en la sola observacin del robot
y de sus sensores de abordo; es decir, aquella donde no se usa informacin externa al autma-
ta, de all la denominacin por medidas propioceptivas1 . Una forma simplista de estimar la
localizacin relativa de un robot consiste en monitorear las variables de estado del robot, tales
como su velocidad linear y angular, usando sensores de abordo como giroscopios, acelermetros,
tacmetros y codicadores rotativos. Este tipo de localizacin se conoce como dead reckon-
ing, lo que originalmente es el proceso de estimar la posicin de un avin o de una embarcacin,
basndose en la velocidad y direccin del vehculo, y en el tiempo transcurrido desde la ultima
posicin conocida hasta la actual. De aqu que este tipo de medidas de posicin slo da infor-
macin referida al punto desde donde se inicio la navegacin del robot. Un inconveniente que
surge de inmediato es que el error en el estimado de posicin se incrementa con el tiempo ya
que el mismo esta basado en el estimado anterior[17].
Una de las tcnicas ms usadas para llevar a cabo la localizacin relativa de un robot se basa
en la integracin a travs del tiempo de la informacin proveniente de sensores de odometra
acoplados al cuerpo o a las ruedas del robot. Esta tcnica, mejor conocida como localizacin
odomtrica, esta sujeta a grandes fuentes de error como por ejemplo el derrape y patinaje de
las ruedas de odometra. Otra desventaja de la odometra es su sensibilidad al tipo de terre-
no, ya que estos sistemas no son capaces de detectar si se trata de una supercie plana o de
una con muchas irregularidades. A pesar de estas desventajas, la localizacin odomtrica sigue
siendo ampliamente usada porque proporciona buena exactitud, a bajos costos, para trayectos
cortos[17].
3.2.2. Localizacin absoluta basada en hitos o landmarks

Los hitos o landmarks son elementos del entorno que poseen caractersticas distintivas espe-
ciales, que mediante los sensores, el robot puede detectar. Una vez que estas Landmarks son
detectadas, se contrastan con la informacin a priori que se tiene del entorno (correspondencia
o matching), o tambin se pueden aplicar tcnicas de triangulacin, para determinar la posi-
cin del robot[17]. Este mtodo de localizacin puede dividirse en cuatro fases como se muestra
en la gura 3.1.
Figura 3.1: Fases de localizacin de robots basada en Landmarks [17]

1 Propioceptivo es un adjetivo que en medicina se aplica a las terminaciones nerviosas que proceden del propio
cuerpo y que transmiten informaciones sobre su postura y movimientos, entre otras cosas [20]. En el caso de un
robot, este trmino se aplicara a sus sensores de abordo o interoceptivos.
3.3. PLANIFICACIN 17
La clasicacin ms usual de estas Landmarks es la que las divide en naturales y articiales.

Las Landmarks naturales son aquellas que de antemano forman parte del entorno donde se
mueve el robot. Ejemplo de estas en ambientes interiores son las puertas, ventanas y lmparas
de techo; mientras que para ambientes exteriores se pueden mencionar a los rboles, caminos y
a las seales de trco. El problema principal con este tipo de Landmarks es que son difciles de
reconocer y en consecuencia el robot generalmente necesitar un nmero mayor de observaciones
para poder determinar inequvocamente su posicin[17].
Las Landmarks articiales son colocadas intencionalmente en el entorno donde se mueve el
robot, de forma tal que sean bien visibles a los sensores del mismo. Este tipo de Landmarks se
pueden clasicar en activas y pasivas. Las Landmarks activas, tambin conocidas como faros,
son aquellas que emiten algn tipo de seal que informa sobre su localizacin. Ejemplo de ellas
son los satlites de los sistemas GPS, los faros ultrasnicos, los radiofaros y dipolos magnticos,
etc. Las principales desventajas de este tipo de hitos activos, es que la seal que emiten puede
verse perturbada por las condiciones geogrcas o tambin por las condiciones atmosfricas
del entorno. Otra desventaja es que en la prctica estas Landmarks no pueden enviar la seal
en forma omnidireccional y por lo tanto el robot no las puedes ver desde cualquier lugar. Otra
importante desventaja es que su costo de construccin y mantenimiento puede ser excesivamente
elevado. Por su parte, las Landmarks pasivas son las que no emiten activamente ningn tipo de
seal, y en consecuencia el robot tiene que buscarlas activamente mediante sus sensores para
poder ejecutar el proceso posterior de autolocalizacin. Ejemplo de este tipo de Landmarks son
las balizas, las guras geomtricas coloreadas y los cdigos de barra. La principal desventaja
de estas Landmarks es que mientras ms alejado se encuentre el robot de ellas, menos ajustado
y preciso ser la estimacin de estado. Tambin, al compararlas con las Landmarks activas, se
pone de maniesto que las pasivas son ms difcil de detectar y que requieren de mayor cantidad
de proceso para poder identicarlas[17].
3.2.3. Localizacin basada en mapas

Esta metodologa se basa en la bsqueda de la correspondencia entre un mapa local que el
robot construye mediante sus sensores, y un mapa global del entorno que el robot conoce con
anterioridad, o que el mismo va construyendo mientras explora el entorno. De aqu el nombre
general que recibe esta tcnica: Correspondencia entre Modelos(Model Matching)[17].
Partiendo de que el robot dispone de un mapa de su entorno, el cual puede ser obtenido por
el mismo robot en una fase previa de exploracin, o pueden ser suministrado externamente en
una fase de inicializacin (mapa tipo CAD), o pueden ser construidos simultneamente mientras
el robot navega( SLAM); el procedimiento general que se sigue con esta tcnica de localizacin
se divide en los siguientes pasos[17]:
1. Prediccin de la posicin basada en el estimado previo y en los datos de odometra recogidos

mientras el robot esta en movimiento[17].
2. Prediccin de observaciones basado en el estado estimado de la posicin y en el mapa del

entorno el cual es conocido con anticipacin[17].
3. Observacin del entorno mediante los sensores del robot[17].
4. Bsqueda de correspondencia entre las observaciones y el mapa[17].
5. Actualizacin de la posicin real del robot[17].
3.3. Planicacin
De forma genrica, el problema de planicacin de movimientos consiste en llevar un
cuerpo, desde una conguracin inicial hasta otra nal dentro del espacio de conguraciones
Figura 3.2: Planicacin de movimientos tosca pero exitosa de un robot [23]
libres de colisin. Es importante mencionar que cuanto ms complejo es el entorno, mayor el

nmero de grados de libertad, o ms restricciones cinemticas presenta el robot, mayores son
tambin las limitaciones de los mtodos de planicacin y el tiempo necesario para encontrar la
solucin[21]. En la gura 3.2 se muestra un ejemplo de planicacin.
Tradicionalmente, una tarea de planicacin suele tener tres tipos de resultados: rutas,
caminos y trayectorias. Una ruta es un conjunto ordenado de conguraciones que deben ser
alcanzadas por el robot. Por camino se entiende la discretizacin de una funcin continua que
interpola las conguraciones denidas en una ruta. Finalmente, cuando se habla de trayectoria
temporal (por omisin simplemente trayectoria) se est haciendo referencia a un camino que
tiene asociado un perl cinemtico; es decir, a cada conguracin perteneciente al camino se le
asocia una velocidad[22].
El resultado de la planicacin se utiliza en sistemas de navegacin planicada. Una carac-
terstica comn de todos ellos es la utilizacin de un controlador que, en tiempo real, permita
que el sistema siga la trayectoria previamente obtenida. Dependiendo del tipo de controlador
ser necesario planicar caminos o trayectorias[22].
3.4. Control de movimiento

En robtica, control signica medir el valor de una variable a gobernar en un sistema y aplicar
una seal de mando sobre este ltimo para corregir o limitar la desviacin del valor medido a
partir de un valor deseado[24]. En el caso particular del control de movimiento, la variable
gobernada ser el movimiento de un autmata y el sistema al que esta pertenece ser dicho
robot.
El problema del control de vehculos autnomos (o robots) puede formularse como la ob-
3.4. CONTROL DE MOVIMIENTO 19
tencin de leyes de control que permitan estabilizar el vehculo sobre un punto de trabajo
(condiciones nominales de funcionamiento), anulando el efecto de las perturbaciones (problema
de regulacin), o bien hacer que el vehculo siga de forma autnoma una trayectoria de referen-
cia. En este segundo caso, se distingue entre el seguimiento de postura, en el cual se debe seguir
la trayectoria en el tiempo de una postura de referencia ref = (x, y, )ref , constituida por la
posicin y la orientacin, o bien slo el seguimiento en el tiempo de una posicin de referencia
ref = (x, y)ref [25].
Las caractersticas del robot mvil son importantes, es decir, dependiendo del tipo de aut-
mata a controlar variaran las tcnicas de control utilizadas[25]. Siendo la habilidad para moverse
o locomocin[19] la principal facultad de a considerar dentro de un robot para implementar
alguna tcnica de control para su movimiento, resulta necesario mencionar a continuacin una
categorizacin de acuerdo a esta.
Los robots mviles se pueden clasicar por su medio de movimiento o tipo de locomocin en
tres categoras: por ruedas [Muir et al., 1992], por patas [Todd, 1985] y por orugas [Grasnoik
et al., 2005]. Cabe sealar que aunque la locomocin por patas y orugas han sido ampliamente
estudiadas, el mayor desarrollo se presenta en los Robots Mviles con Ruedas (RMR).
Dentro de los atributos ms relevantes de los RMR, destacan su eciencia en cuanto a energa
en supercies lisas y rmes, a la vez que no causan desgaste en la supercie donde se mueven
y requieren un nmero menor de partes y menos complejas, en comparacin con los robots de
patas y de orugas, lo que permite que su construccin sea ms sencilla[26].
Dentro de los RMR, categora a la que pertenece Donaxi@HOME, a su vez existen di-
ferentes conguraciones cinemticas las cuales dependen principalmente de la aplicacin hacia
donde va enfocado el robot, no obstante, de manera general se presentan a continuacin las seis
ms comunes:Ackerman, triciclo clsico, traccin diferencial, skid steer, sncrona y
traccin omnidireccional[26].
Dependiendo de la conguracin cinemtica que los conformen, los robots mviles con ruedas
utilizan cuatro tipos de ruedas para su locomocin [Goris, 2005], estas son: convencionales,
tipo castor, ruedas de bolas y omnidireccionales[26] (ver gura 3.3).
Figura 3.3: Tipos de ruedas [26]
Como quedo evidenciado anteriormente, debido a la variedad de conguraciones que pueden

tener los RMR, existen muchos tipos de desplazamiento que pueden realizar, sin embargo,
en la prctica suelen ser clasicados en dos grandes clases[27]:
Desplazamiento diferencial.
Desplazamiento omnidireccional.
3.4.1. Desplazamiento diferencial

Un desplazamiento diferencial considera un arreglo par de ruedas. El principio de funcionamiento
es simple: Para que el robot se desplace hacia delante conservando su orientacin las ruedas deben
girar a la misma velocidad y en la misma direccin. Para que el robot cambie su orientacin
debe existir una diferencia de velocidades en las ruedas, mientras ms grande sea la diferencia
de velocidades en las ruedas ms grande ser el cambio en la orientacin del robot[27], es decir,
mayor ser la velocidad angular.
3.4.2. Desplazamiento omnidireccional

El desplazamiento omnidireccional brinda una completa maniobrabilidad. Los robots omnidi-
reccionales pueden moverse en cualquier direccin y en cualquier momento sin requerir una
orientacin especca para el desplazamiento del robot. Este tipo de desplazamiento requiere de
ruedas que se puedan mover en ms de una direccin[27].
El movimiento omnidireccional ha adquirido popularidad en los robots mviles porque per-
mite que el robot se desplace en lnea recta desde un punto origen hacia cualquier otro punto, sin
tener que rotar antes de desplazarse. Adicionalmente, la traslacin sobre la ruta deseada se puede
combinar con una rotacin, de modo que el robot llega a su destino en el ngulo correcto[27].
Captulo 4
Percepcin y localizacin en el
robot Donaxi@HOME
Para que el robot Donaxi@HOME lograr la tarea de navegar en un ambiente plano fue necesario
que cumpliera exitosamente con las cuatro etapas expuestas en el captulo anterior de forma
ordenada. En este apartado se detallan las primeras dos fases, las cuales son percepcin y
localizacin.
4.1. Percepcin del entorno

Como fue mencionado en el captulo anterior, la percepcin de un robot se divide en dos etapas:
1. Sensado del entorno.
2. Interpretacin de los datos adquiridos.
A continuacin se describe como se incorporo cada una de ellas dentro del robot Donaxi@HOME.
4.1.1. Sensado del entorno

Para cumplir con esta etapa exitosamente, el robot Donaxi@HOME requiri de los si-
guientes sensores:
Telmetro lser.
Giroscopio electrnico.
Codicador rotatorio o rotativo ( encoder).
4.1.1.1. Telmetro lser

Los telmetros lser son dispositivos capaces de rastrear objetos en el espacio libre sin am-
bigedad. El haz de luz altamente colimado 1 emitido por el lser provee un nico punto de
muestra que permite a este mtodo rastrear de forma exacta objetos particulares sobre grandes
distancias. Adems, la cantidad de tiempo que toma la luz en alcanzar el objetivo y regresar al
reejarse puede ser medido de forma precisa, permitiendo el uso de la velocidad de la luz como
una referencia para medir distancia. Aunque los sonares y los telmetros ultrasnicos pueden ser
1 Colimado signica "en una sola direccin ", ya que todas las ondas emitidas por un lser estn casi paralelas y
por tanto no hay divergencia en el haz de luz, por lo que permanece invariable an despus de largos recorridos[28].
21
22 CAPTULO 4. PERCEPCIN Y LOCALIZACIN EN EL ROBOT DONAXI@HOME
usados para el mismo propsito, la velocidad de muestreo es seis veces ms lenta en comparacin
con la velocidad de la luz[29].
En el caso de los robots autnomos, los sensores de este tipo actan como sus " ojos",
permitindoles a estos guiarse para evitar obstculos y, posteriormente con ayuda de su software,
planicar rutas y trayectorias.
El robot Donaxi@HOME utiliza el sensor Hokuyo UBG-04LX-F01 (Rapid URG) Scanning

Laser Rangender (ver gura 4.1), un telmetro lser compacto de dos dimensiones que brinda
apoyo en la tarea de navegacin en los vehculos no tripulados, permitiendo, con la ayuda del
software adecuado, la prevencin de colisiones, la determinacin de la posicin del objeto y la
vigilancia del permetro que rodea al mvil[30].
Figura 4.1: Telmetro lser utilizado en el robot Donaxi@HOME [31]
4.1.1.2. Giroscopio electrnico

Un girscopo o giroscopio electrnico es un sensor capaz de medir la velocidad angular utilizando
el efecto Coriolis. Para entender su principio de funcionamiento consideremos dos bloques de
masa m oscilando de forma constante con una velocidad V como se observa en la gura 4.2.
Al aplicar un movimiento angular z se producen un par de fuerzas de Coriolis, que genera
a su vez una variacin en la distancia entre las placas de un condensador. Dicha variacin es
medida mediante una interfaz sensora capacitiva y posteriormente, se conecta a un amplicador
diferencial de carga que se encarga de traducir las variaciones capacitivas en variaciones de
tensin. Las fuerzas de Coriolis son proporcionales a la velocidad angular que es la magnitud de
inters [32].
Para obtener mediciones angulares con respecto a un eje de rotacin es posible utilizar un
giroscopio y realizar una integracin discreta. Sin embargo, el efecto de deriva inherente a este
sensor hace que el valor de salida en una posicin estable se desplace, perdiendo toda la referencia
y obteniendo una lectura errnea del ngulo[32].
El robot Donaxi@HOME utiliza el dispositivo 1056 - PhidgetSpatial 3/3/3 (ver gura

4.3), instrumento capaz de medir aceleracin esttica y dinmica en tres ejes (mximo 5 g),
campo magntico en tres ejes (lmites 4 Gauss) y velocidad angular en tres ejes (lmites 400
grados por segundo). Esto debido a que incorpora tres sensores diferentes: un magnetmetro,
un acelermetro y un giroscopio electrnico; todos de tres ejes[33]. Sin embargo, en el proyecto
aqu presentado slo se utiliz el eje z del girscopo.
4.1. PERCEPCIN DEL ENTORNO 23
Figura 4.2: Diagrama de funcionamiento de un girscopo electrnico [32]
Figura 4.3: Giroscopio electrnico utilizado en el robot Donaxi@HOME [33]
4.1.1.3. Codicador rotativo (encoder)
A n de desarrollar sus estrategias de navegacin, la gran mayora de los vehculos en la robtica

mvil se fundamentan en la estimacin del estado. La forma ms simple de implementacin de la
estimacin del estado en robtica mvil se conoce como odometra, ya que el termino implica
que los desplazamientos del vehculo a lo largo de una trayectoria son derivados a partir de
las observaciones de un odmetro de abordo. Un instrumento odomtrico muy comn es el
codicador ptico rotativo (encoder), el cual se acopla directamente al eje del motor o al
de las ruedas de traccin. El principio bsico del codicador ptico esta centrado en un haz de luz
que alcanza un foto detector. Este haz de luz es interceptado por reas opacas y transparentes
que se alternan en un disco rotativo que est slidamente unido al eje de inters (ver gura
4.4)[17].
Figura 4.4: Diagrama de funcionamiento de un codicador ptico rotativo [17]
Existen dos tipos bsicos de codicadores rotativos: Los incrementales y los absolutos. La
versin incremental mide la velocidad de rotacin y puede inferir la posicin relativa. Por su parte
los modelos absolutos miden directamente la posicin angular y puede inferir la velocidad[17].
Donaxi@HOME utiliza dos codicadores rotativos incrementales, cada uno
El robot
acoplado a su respectivo motor, los cuales, en conjunto con elgiroscopio mencionado en el
apartado anterior, constituyen la odometra del robot de servicio desarrollado en la presente
tesis.
Las caractersticas tcnicas de los motores, y por ende de los encoders integrados a estos,
utilizados en este autmata se mencionan a detalle en el captulo 6.
4.1.2. Interpretacin de los datos adquiridos

Como ya fue mencionado en repetidas ocasiones, lo que los sensores detectan no es la percepcin
como tal, sino que es nicamente la primera etapa de la misma. La segunda y ltima fase que
permite completar dicho proceso es la interpretacin de los datos adquiridos.
Los nodos encargados de interpretar el sensado dentro del robot Donaxi@HOME fueron
denominados en la presente tesis para efectos prcticos como nodos de percepcin.
Se realizaron bsicamente dos arreglos distintos de nodos para poder completar exitosamente
los siguientes objetivos:
1. Generacin de mapa.
2. Navegacin en el mapa generado.
Cada uno cuenta con sus respectivos nodos de percepcin, los cuales sern abordados en esta
seccin.
4.1.2.1. Generacin de mapa

Como su nombre lo indica, el arreglo de nodos de generacin de mapa tiene por objetivo, valga
la redundancia, generar un mapa de un lugar especco a partir de los movimientos del robot.
Para cumplir con este propsito, fue necesaria la creacin de nueve nodos, tal y como se muestra
en la gura 4.5. Sin embargo, como la nalidad de este apartado es describir brevemente a los
nodos de percepcin de este arreglo, nicamente se mencionan estos.
Figura 4.5: Arreglo de nodos generacin de mapa

Los nodos de percepcin pertenecientes a la conguracin de programas anteriormente des-

crita son:
spatial.
spatial_client.
motor_gen_mapa.
odom_tf.
hokuyo_node.
4.1.2.1.1. Nodo spatial

El nodo spatial se encarga de establecer la comunicacin entre el dispositivo 1056 - PhidgetSpa-
tial 3/3/3 y la computadora, siendo la conexin va USB el medio para este enlace. Adems,
este programa permite manejar errores, tanto de ejecucin como de conexin entre el aparato y
el ordenador, de tal forma que si se presenta algn resultado inesperado en el funcionamiento
del primero, el nodo es eliminado ( killed ), es decir, se aborta la ejecucin de dicho bloque de
software. Esto es especialmente til para no consumir en vano los recursos del procesador.
Como fue mencionado anteriormente, el dispositivo 1056 - PhidgetSpatial 3/3/3 contiene

tres sensores que miden tres magnitudes fsicas distintas en tres ejes (x,y,z), sin embargo, de
todas estas la nica que es de inters para el robot es la velocidad angular en el eje z, siendo las
dems innecesarias para el objetivo a realizar. El nodo spatial almacena la informacin de cada
sensor en un arreglo de tres nmeros de tipo otante, correspondiendo la posicin 0 al eje x, la
posicin 1 al eje y y la posicin 2 al eje z. Basta con tomar el valor del dato de la posicin 2 en
el arreglo angularRate, que equivale a la velocidad angular en el eje z, y publicarlo.
En resumen, la nalidad principal de este programa dentro del entorno de comunicacin de
ROS, es tomar la velocidad angular en el eje z proveniente del giroscopio y publicarla en el
tpico giro. Esto se ilustra claramente en la gura 4.6, la cual, al igual que los diagramas 4.7,
4.9, 4.10 y 4.14, es un fragmento del grco 4.5.
Figura 4.6: Nodo spatial y sus ramicaciones
Aunque el programa descrito en esta seccin sufri algunas modicaciones para cumplir
satisfactoriamente las necesidades de este proyecto, el original puede encontrarse en Internet
[34].
4.1.2.1.2. Nodo spatial_client

El nodo spatial_client bsicamente realiza tres tareas: la primera es suscribirse al tpico giro
para saber la velocidad angular proveniente del girscopo, la segunda es procesar esta informa-
cin para convertirla en algo ms til para otros programas y la tercera es publicar los datos
obtenidos en el tpico pos. Esto se ilustra en la gura 4.7.
Figura 4.7: Nodo spatial_client y sus ramicaciones
La funcin de procesamiento de este nodo, mencionada en el prrafo previo, consiste fun-

damentalmente en calcular el ngulo de rotacin alcanzado por el robot girar a partir de su
velocidad angular. El siguiente algoritmo dene paso a paso como realizar esta encomienda:
1. Se calcula el tiempo que dura la ejecucin de cada ciclo de instrucciones con la siguiente
ecuacin: dt = current_time last_time, donde current_time el tiempo al inicio de
cada ciclo y last_time tiempo al nal de cada ciclo. Las unidades de dt se convierten a
segundos (s).
2. Empleando la ecuacin delta_th = vth dt, donde vth es la velocidad angular dada en /s,

por lo que delta_th lleva grados( ) como unidades.
3. Como no existe tal cosa como el reposo absoluto, el giroscopio nunca nos arroja valores
de cero en vth, por lo que establece la condicin de que s vth > 0.5, entonces th =
th + delta_th. De esta forma cuando se detecten velocidades angulares signicativas, el
ngulo de rotacin obtenido se ir incrementando.
4. En este paso ya se tiene un valor provisional del ngulo de rotacin del robot, sin embargo,
debido a las vibraciones causadas por el movimiento y al efecto de deriva inherente del
sensor, mencionado previamente en este captulo, entre otros factores, se obtienen datos
errneos. Para corregir este problema se emplea el ltro de Kalman una herramienta
matemtica que permite estimar variables de un amplio rango de procesos, utilizando
dos etapas: prediccin y correccin del valor[32]. Utiliza el teorema de Bayes de
probabilidad y asume que la variable a la que se le va aplicar, que en este caso es th,
forma parte de un sistema dinmico lineal[18]. Debido a que el objetivo de esta tesis no es
explorar a fondo la implementacin de este mtodo, slo se muestra un pequeo diagrama
que lo resume en la gura 4.8.
5. Por ltimo, ya que se obtiene el ngulo de rotacin despus de la etapa de ltrado, al

que se denominar th_kalman se establece una nueva condicin: si th_kalman > |15|,
entonces th = 0 y k = 1, de lo contrario, k = 0. De esta forma cuando el ngulo de rotacin

obtenido sea mayor a 15 , sin importar el sentido, dicho ngulo retomar el valor de cero
y una bandera denominada k alertar que se ha alcanzado la rotacin deseada.
Figura 4.8: Diagrama de bloques de un ltro de Kalman [35]
Cabe mencionar que en el tpico pos se comunican tres valores: la velocidad angular vth, la
posicin angular th_kalman y la bandera k.
Aunque el programa aqu descrito fue modicado casi en su totalidad, el original puede
encontrarse en la red [34].
4.1.2.1.3. Nodo motor_gen_mapa

El nodo motor_gen_mapa tiene como funcin principal establecer la comunicacin entre el
ordenador y el controlador de los motores, los cuales se conectan va ethernet mediante el pro-
tocolo TCP/IP. Sin embargo, los detalles acerca de este enlace, as como la manera en que se
le envan instrucciones a dicho controlador para los motores las ejecuten se analizarn a detalle
en el captulo 6.
En este apartado, basta decir que el intercambio de datos entre el mdulo de control de los
actuadores y la computadora ocurre en los dos sentidos, por lo que tambin se puede recibir
informacin proveniente de los codicadores rotativos integrados a los motores.
El nodo motor_gen_mapa se suscribe a dos tpicos: pos proveniente de spatial_client y
cmd_vel teleop_joy (este programa se explicar en el captulo 7). Adems,
proveniente de
publica informacin en el tpico cmd_vel2. Todo esto se ilustra en la gura 4.9.
Figura 4.9: Nodo motor_gen_mapa y sus ramicaciones
Como se menciono en el prrafo previo, este nodo adems de ser receptor tambin es publi-
cador, sin embargo, que datos publica? La respuesta a esta pregunta viene dada en el siguiente
algoritmo:
1. Cuando el programa el pregunta al controlador la velocidad de los motores, la respuesta

viene dada en cuentas/s pero se espera un valor en m/s, por lo que se utiliza un factor de
conversin para obtener las unidades deseadas. Experimentalmente se demostr que 1 m
= 600 000 cuentas, por lo la velocidad deseada de un motor se obtendra con la ecuacin
velocidadcuentas/s
velocidadm/s = 600000 .
2. Teniendo en cuenta que hay dos motores, denominados como y y z, se debern realizar
dos ecuaciones, una para cada uno, las cuales quedarn de la siguiente forma: vely =
velycuentas/s velzcuentas/s
600000 y velz =
600000 . Ntese el signo menos en la primera frmula, esto se
debe a la forma en como estn montados los impulsores en el robot, situacin que ser
explicada a fondo en el captulo 6.
3. Con el n de conocer la velocidad lineal resultante que lleva el autmata, se obtiene el

promedio de las velocidades de los actuadores y y z de la siguiente forma: vel_lineal =
vely+velz
.
2
4. Como tambin es necesario conocer la velocidad angular del mvil, simplemente se hace
uso de la velocidad de giro del eje z recibida del tpico pos de spatial_client y se multiplica
por 1: vel_angular = vel_giroeje_z . El signo menos de la ecuacin anterior se debe
a que el giroscopio fue montado boca arriba en el robot.
5. De esta forma en el tpico cmd_vel2 se publican dos datos: vel_lineal y vel_angular,

lineal y angular resultantes en el autmata.
las cules representan a las velocidades
Este programa fue diseado enteramente en el Laboratorio de Robtica de la UPAEP e

implementado exclusivamente en el robot de servicio Donaxi@HOME.
4.1.2.1.4. Nodo odom_tf

El programa odom_tf es posiblemente el nodo de percepcin ms importante de los menciona-
dos hasta ahora, ya que se suscribe al tpico cmd_vel2, de all toma las velocidades angular y
lineal obtenidas previamente, realiza una serie de transformaciones y, a partir de esto, publica en
el tpico odom la ruta que dibuja el robot al desplazarse y en el tpico tf la forma en como se
va posicionando en el mundo. En la gura 4.10 se muestran los tpicos utilizados por este nodo,
mientras que en la imagen 4.11 se ven los resultados de la implementacin de este programa.
Figura 4.10: Nodo odom_tf y sus ramicaciones

Figura 4.11: Movimiento del robot Donaxi@HOME en el espacio. Las lineas rojas re-
presentan el trayecto recorrido y los sistemas de referencia etiquetados como /odom, /base_link
y /laser corresponden a la posicin del origen del mundo, del centro de gravedad del robot y del
telmetro lser respectivamente
Antes de desglosar al algoritmo que compone a este nodo, resulta necesario mencionar algunos
conceptos fsicos sobre los cuales se cimentan las funciones de transformacin aqu empleadas.
La cinemtica es el clculo que describe el efecto de las acciones de control en la conguracin
de un robot. La conguracin de un robot mvil rgido es comnmente descrita a partir de seis
coordenadas cartesianas (x, y, z) y sus tres ngulos de Euler (alabeo,
variables, sus tres
cabeceo, guiada) relativos a un sistema de referencia externo[18].
En ROS existen una serie de herramientas que permiten denir la posicin de un sistema
de referencia, o frame en ingls, a partir de las seis variables anteriormente mencionadas. Esto
resulta especialmente til en el caso de autmatas que poseen mltiples partes mviles (ver gura
4.12). Tomando esto en consideracin, el programa odom_tf funciona de la siguiente manera:
Figura 4.12: Robot con mltiples partes mviles, y por ende, varios frames [36]
1. Primero se dene la ubicacin del lser con respecto al centro de gravedad del robot,
asignndole un valor esttico a cada una de las seis variables mencionadas con anterioridad:
x = 0.18 m, y = 0.0 m, z = 0.34 m, alabeo = 0.0 rad, cabeceo = 0.0 rad y guiada = 0.0
rad (medidas reales de Donaxi@HOME). Al frame padre o parent frame que corresponde
al centro de gravedad del robot se le nombr base_link, mientras que al frame hijo o
child frame se le llam laser. Las posiciones de los frames se ilustran en la gura 4.11.
2. Se toman las velocidades lineal y angular del tpico cmd_vel2 y se nombran como vx y
vth respectivamente, y adems, se agrega una tercera velocidad vy = 0.
3. Se obtiene el tiempo de ejecucin de cada ciclo o dt de la misma forma en el nodo spa-

tial_client.
4. Se implementan las siguientes ecuaciones para obtener las coordenadas en el plano carte-
siano, a partir de las velocidades suministradas: x = (vx cos(th) vy sin(th)) dt,
y = (vx sin(th) + vy cos(th)) dt y th = vth dt. Donde x, y y th corresponden
respectivamente a los incrementos en las coordenadas x e y y en el ngulo .
5. Para que la posicin y orientacin en el plano se vayan incrementando cada vez que se
ejecute un ciclo se utilizan las siguientes frmulas: x = x+x, y = y +y y th = th+th.
6. Posteriormente, se utiliza una funcin de ROS que permite obtener a los tres ngulos
espaciales de Euler a partir de un ngulo planar dado. Esta transformacin se realiza
a partir de th, donde tanto el dato de entrada como los tres de salida vienen dados en
radianes (rad).
7. Por ltimo, de la misma forma que en el primer paso, se dene la ubicacin del centro de
gravedad del robot con respecto al origen del mundo, siendo ahora el frame hijo base_link
(mencionado anteriormente) y el frame padre odom que corresponder al origen del mun-
do. De esta forma las seis variables quedaron de la siguiente manera: x = x m, y = y m y
z = 0.0 m; y alabeo, cabeceo y guiada con los valores obtenidos en el paso 6.
Publicar la informacin anteriormente obtenida con los tipos de datos adecuados en los
tpicos odom y tf, dar como resultado a lo observado en la gura 4.11.
El programa aqu mostrado fue desarrollado a partir de dos tutoriales de ROS que explican
paso a paso como realizar este proceso, los cuales se citan en las referencias [37] y [38].
4.1.2.1.5. Nodo hokuyo_node

El programa hokuyo_node se encarga de establecer la comunicacin entre el sensor Hokuyo
UBG-04LX-F01 (Rapid URG) Scanning Laser Rangender y el ordenador, siendo la conexin
va USB el medio para este enlace. Adems, al igual que el nodo spatial, permite manejar errores
que se puedan presentar en el intercambio de datos entre el dispositivo y la computadora, por
lo este nodo se cerrar en caso de presentarse algn imprevisto.
Pese a la importancia de las funciones citadas en el prrafo anterior, la complejidad este

no radica en la capacidad que este tiene para tomar la informacin proveniente del telmetro
lser, procesarla y convertirla en un arreglo de puntos en dos dimensiones que represente en una
escala muy precisa lo que mira el robot a travs su mencionado transductor. En la gura 4.13
se muestra un perl de puntos dibujado por este sensor, construido a partir de los objetos que
se encuentran dentro de su rango de visin.
Figura 4.13: Perl de puntos generado por el telmetro lser montado en el robot
Donaxi@HOME. El sistema de referencia etiquetado como /laser es el origen de la lectura
El arreglo de puntos en 2D generado por el nodo hokuyo_node es publicado sobre ROS por
medio del tpico scan, como se muestra en la imagen 4.14.
Figura 4.14: Nodo hokuyo_node y sus ramicaciones
Este bloque de cdigo, el cual fue ntegramente utilizado sin recibir ninguna modicacin,
se encuentra en Internet [39].
4.1.2.2. Navegacin en el mapa generado

El arreglo de nodos navegacin en el mapa generado hace justo lo que indica su nombre. Una vez
que se ha obtenido un mapa del entorno de desenvolvimiento del robot con el arreglo generacin
de mapa, este se guarda en formato de imagen para poder utilizarse precisamente por el arreglo
aqu presentado, de tal forma que su misin principal permitirle al robot generar una ruta a
travs de los obstculos presentes en su entorno y desplazarse siguiendo la misma. Para esto, es
necesario enviarle al autmata un objetivo que pueda alcanzar, cosa que tambin se encarga de
hacer este conjunto de programas intercomunicados.
Pese a que navegacin en el mapa generado se encuentra compuesto por 12 nodos entrelazados
por diferentes tpicos como se muestra en la gura 4.15, en este apartado se describen nicamente
a los nodos de percepcin (previamente mencionados) que lo componen, los cuales son:
spatial.
spatial_client.
motor_formula.
odom_tf.
hokuyo_node.
Figura 4.15: Arreglo de nodos navegacin en el mapa generado
4.1.2.2.1. Nodo motor_formula

El nodo motor_formula realiza las mismas funciones que el programa motor_gen_mapa, sirvien-
do de puente entre el controlador de los motores y la computadora y comunicando las velocidades
lineal y angular provenientes del robot a travs del tpico cmd_vel2. La diferencia crucial entre
ambos radica en las instrucciones que enva hacia los impulsores para que se muevan siguiendo
la trayectoria generada por el planicador de movimientos move_base, la cual es comunicada
mediante el tpico cmd_vel. Este proceso ser explicado en el captulo 6. Las conexiones de
este nodo se muestran en la gura 4.16 que es un fragmento del esquema 4.15 al igual el diagrama
4.18.
Figura 4.16: Nodo motor_formula y sus ramicaciones
Al ser una versin modicada de motor_gen_mapa, este programa tambin es un original

desarrollado para este proyecto.
4.1.2.2.2. Nodos restantes

Los nodos hokuyo_node, spatial, spatial_client y odom_tf del arreglo navegacin en el ma-
pa generado son exactamente los mismos que los utilizados en el conjunto generacin de mapa,
por lo que resulta innecesario volverlos a explicar.
4.2. Localizacin del mvil en su medio

De acuerdo a la informacin proporcionada en el captulo 3, el robot Donaxi@HOME utiliza
dos algoritmos de localizacin basados en mapas para ubicarse as mismo dentro de su entorno.
Estos son los algoritmos de SLAM y AMCL.
Los nodos slam (gura 4.17) y amcl (gura 4.18), los cuales ya vienen programados den-
tro de la paquetera de ROS Groovy, basan su funcionamiento en los algoritmos homnimos
mencionados en el prrafo anterior.
4.2. LOCALIZACIN DEL MVIL EN SU MEDIO 33
Figura 4.17: Nodo slam y sus ramicaciones
Figura 4.18: Nodo amcl y sus ramicaciones
A lo largo de la presente seccin, dichos algoritmos sern descritos de manera terica, es

decir, sin hacer hincapi en su implementacin como programas computacionales. Esto ltimo
para evitar limitar el funcionamiento de ambos a un lenguaje especco de programacin en caso
de que este mtodo desee ser aplicado en proyectos posteriores.
4.2.1. Algoritmo de localizacin y elaboracin de mapa simultneos

(SLAM)
El algoritmo de localizacin y elaboracin de mapa simultneos (Simultaneous Localization
And Mapping abreviado como SLAM) tiene por objetivo, como su nombre lo indica, permi-
tirle a un autmata realizar un mapa consistente de segmentos de dos dimensiones a partir de
mediciones sensoriales y localizarse dentro del mismo.
Existen mltiples variaciones de este algoritmo, tales como son: Online SLAM y Full
SLAM. Ambas versiones forman parte del SLAM Gmapping, el cual fue implementado en el
robot Donaxi@HOME y cuyo funcionamiento y razn de ser se describen a continuacin.
Para empezar se consideran tres variables de estado en el tiempo t: xt , que representa al
robot en el plano, esto incluye: su pose (su localizacin y orientacin con respeto a un marco
global), la conguracin de sus actuadores, su estado dinmico, los objetos estticos del entorno
(modelos, puntos, marcas del entorno(landmarks)), su apariencia y los objetos en movimiento;
zt , que contiene las lecturas de los sensores exteroceptivos, el lser en el caso de Dona-
xi@HOME; y ut , que representa a los controles de movimiento, los cuales son proporciona-
dos por el nodo motor_gen_mapa a partir de las mediciones de los sensores interoceptivos
(codicadores rotativos y giroscopio que componen a la odometra de Donaxi@HOME).
A partir de las mediciones obtenidas por zt y las acciones de control ut cuyo movimiento
provoca que el estado xt1 se convierta en xt , se desea estimar a xt , es decir, la meta es calcular
haciendo uso de la probabilidad un estado posterior del robot. Para esto se usa la frmula
P(xt |z1:t , u1:t ).
Aunque el estado a estimar es incompleto en todos los casos se supone de forma general
que, tericamente, si es completo, lo que hace de su evolucin un proceso de Markov. Esto
quiere decir que la probabilidad de transicin de un estado se dene con estas dos frmu-
las: p(xt |x0:t1 , z1:t1 , u1:t ) = p(xt |xt1 , ut ) y p(zt |x0:t , z1:t1 , u1:t ) = p(zt |xt ). Un proceso de
Markov convierte al problema de estimar el siguiente estado de un robot en un problema de

estimacin recursiva bayesiana, tal y como se ilustra en la gura 4.19.
Figura 4.19: Problema de estimacin recursiva bayesiana [18]
Dentro del SLAM, el estado ya no es simplemente el mapa ( occupancy grids) o el vector

de posicin del robot (problema de localizacin) sino un vector combinando los dos (robot y
mapa). Esto queda evidenciado en el hecho de que para que un robot se localice adecuadamente
necesita un buen mapa y al mismo tiempo, para poder construir un buen mapa es necesario que
dicho mvil este bien localizado al momento que son aadidos nuevos elementos a la mencionada
representacin del entorno.
La localizacin y construccin de un mapa deben de estar hechos simultneamente y en un
cuadro probabilstico para tener certeza en la adquisicin de datos. Este proceso, mostrado
en la gura 4.20, se realiza en cuatro etapas:
1. Descubierta o primera observacin.
2. Movimiento.
3. Reobservacin o corroboracin de la primera observacin.
4. Actualizacin (update) de mapa y posicin.
Figura 4.20: Proceso de certidumbre en la adquisicin de datos [18]

Figura 4.21: Robot PR2 de Willow Garage [40]
Las principales dicultades inherentes al algoritmo de SLAM son: la asociacin de datos,

es decir, asociar correctamente los puntos observados por el lser a los elementos del mapa que
corresponden, hecho conocido en visin como problema de reconocimiento; y la estimacin,
donde las mayores problemticas que existen son el tamao del estado que se desea considerar
y el hecho de que los procesos utilizados generalmente no son lineales.
El vector de estado del robot xt se dene mediante la frmula xt = (lt , mo , ..., mn )T

0
donde lt = (xt , yt , t ) es la posicin del robot y las mi = (xi , yi ) son las posiciones de las
diferentes marcas del entorno (landmarks).
EL esquema general de estimacin del estado en un instante de tiempo t se compone de

dos modelos: uno de observacin y uno de movimiento, denidos por las ecuaciones p(zt |xt )
y p(xt |xt1 , ut ) respectivamente. Por consiguiente,
R dicho esquema se resume en la siguiente
expresin: P (xt |u1:t , z1:t ) = p(zt |xt ) xt p(xt |xt1 , ut ) p(xt1 |u1:t1 , z1:t1 ), donde es un
factor que permite ajustar el valor de la funcin de probabilidad al rango de 0 a 1.
La frmula anterior es la base de funcionamiento del Online SLAM. Sin embargo, cuando se
desea estimar toda una trayectoria conformada por varios estados y al mapa mismo, se requiere
del algoritmo Full SLAM, denido por: P (x1:t |u1:t , z1:t ).
La combinacin de los algoritmos anteriores junto con la implementacion del ltro de
Kalman extendido (EKF), una versin ms compleja del ltro mencionado en el aparta-
do nodo spatial_client explicado en este captulo, para ajustar la estimacin del estado xt
componen alSLAM Gmapping.
SLAM Gmapping es probablemente el algoritmo de SLAM ms utilizado actualmente
que, adems de haber sido implementado en Donaxi@HOME, es utilizado por el robot PR2
(gura 4.21) elaborado por Willow Garage. Para ms informacin acerca de los diferentes tipos
de SLAM (incluyendo los aqu descritos) y temas relacionados consultar las referencias [18] y
[41].
4.2.2. Algoritmo de localizacin de Monte Carlo aumentado (AMCL)

El algoritmo de localizacin de Monte Carlo aumentado ( Augmented Monte Carlo Local-
ization abreviado como AMCL) tiene por objetivo permitirle a un robot localizarse en un
mundo conocido. El mapa del entorno, en el que el autmata debe ubicarse a s mismo, debe
serle comunicado de antemano. Este mapa, comnmente conocido como rejilla de ocupacin
(occupancy grid), contiene un valor para cada ubicacin, el cual indica la probabilidad de que
dicha ubicacin este ocupada por un objeto como, por ejemplo, una pared [42].
Este algoritmo puede resolver el problema de la localizacin global y el llamado dilema del
robot secuestrado2 de una manera muy robusta y eciente (Thrun et al, 2000;. Fox, Thrun,
Burgard, y Dellaert, 2001). Uno de los problemas del AMCL es que funciona bien con los mapas
en los que no hay incertidumbre, es decir, cuando se le proporciona al robot un mapa exacto
del entorno. Por esta razn suelen haber dicultades cuando se utiliza en el mundo real [42].
El AMCL es una versin extendida del algoritmo de localizacin de Monte Carlo (Monte
Carlo Localization abreviado como MCL), siendo la principal diferencia entre estos el hecho
de que el segundo no es capaz de resolver el dilema del robot secuestrado [42]. Debido a que
este ltimo escenario no es abordado en la presente tesis, en esta seccin slo ser explicada la
versin ms simple de dicho algoritmo, es decir, el MCL.
En robtica probabilstica un concepto clave es la conabilidad. Un robot no conoce
su propia pose (posicin y postura), ya que no puede ser medida directamente. En lugar de
ello, el autmata debe deducirla a partir de los datos proporcionados por el o los mapas de su
entorno y sus sensores. En consecuencia, dicho robot distingue de su verdadero estado a partir
de su conviccin interna o el conocimiento que tenga de este ltimo. El MCL representa la
conabilidad ( belief o bel) de este estado bel(xt ) utilizando una nube de partculas donde
xt es el estado del autmata en el tiempo t [42].
El MCL se compone fundamentalmente de los siguientes cinco elementos:
La pose del robot
El ltro de Bayes
El ltro de partculas
Un modelo de movimiento
Un modelo sensorial
4.2.2.1. La pose del robot

La pose del robot se reere al estado cinemtico del mismo en un ambiente plano. Se describe por
0
medio de tres variables: las dos dimensiones cartesianas (x e y ) y la orientacin en dicho entorno
( ). Su representacin en forma vectorial es la siguiente: xt = (x0t , yt , t ) [42]. Este concepto es
similar al expuesto en el algoritmo de SLAM.
La pose del robot se muestra grcamente en la gura 4.22, donde si = 0, entonces el frente
del autmata (representado por el radio remarcado de la circunferencia) quedar en la misma
direccin que el eje de las abscisas (eje x) [42].
Figura 4.22: La pose del robot [42]

2 El dilema del robot secuestrado es una variante del problema de localizacin global que representa una
mayor complejidad de resolucin. Consiste en que, durante la operacin del autmata, este puede ser secuestrado
y colocado en una nueva ubicacin dentro del entorno [18].
4.2.2.2. El ltro de Bayes
El ltro de Bayes es el algoritmo ms general para el clculo de conabilidades, siendo la si-

guiente expresin su forma ms completa: bel(xt ) = p(zt |xt ) bel(xt1 ), donde bel(xt1 ) =
p(xt |z1:t1 , u1:t ) [42]. Aqu representa un factor para normalizar al ltro y las dems variables
(xt , ut , zt ) son equivalentes a las homnimas explicadas en el SLAM.
Este proceso es recursivo (se aplica repetidas veces[19]) y tiene dos pasos esenciales:
1. En primer lugar, realiza el procesamiento de las acciones de control ut calculando la con-

abilidad bel(xt1 ). Este paso se conoce como la prediccin del ltro, ya que bel(xt )
predice el estado del robot en el tiempo t basndose en un estado previo antes de realizar
una medicin en el tiempo t [42].
2. La segunda etapa es denominada actualizacin de la medicin. En esta se multiplica la

conabilidad bel(xt ) por la probabilidad de que la medicin zt haya sido observada. Este
proceso se repite para cada estado posterior hipottico xt [42].
4.2.2.3. El ltro de partculas
El ltro de partculas es una variante del ltro de Bayes basada en la obtencin muestras a partir
de este ltimo. La idea clave de este proceso consiste en la representacin de la conabilidad
bel(xt ), tambin representada como X , a partir de un conjunto de muestras extrado de bel(xt1 ).
Las muestras de una distribucin son llamadas partculas y se indican con la siguiente notacin:
[1] [2] [M ]
Xt = xt , xt , ..., xt [42].
[m]
En esta ltima ecuacin, cada partcula xt (donde 1 m M ) es una hiptesis acerca
de cual puede ser el verdadero estado del mundo en el tiempo t y Xt representa al conjunto
de todas esas partculas (compuesto de M elementos). Debido a que este ltro tiene como
[m]
nalidad aproximar la conabilidad bel(xt ) a partir de Xt , la frmula xt p(xt |z1:t , u1:t ) es
perfectamente vlida [42].
La aproximacin obtenida a partir de este mtodo representa el principio fundamental de

funcionamiento del algoritmo MCL, que a su vez posee algunas nuevas mejoras. Una de sus
mayores ventajas del ltro es el hecho de que funciona bien con datos ruidosos, esto debido
a que se concentra solamente en regiones espaciales que resultan interesantes para el robot
manipulado [42].
4.2.2.4. El modelo de movimiento
Al igual que en el ltro de partculas existe una etapa de prediccin utilizada en el modelo
de movimiento. Este modelo p(x|ut , xt1 ) proporciona la probabilidad de encontrar la pose del
robot x despus de realizar el comando de movimiento ut teniendo en cuenta que la pose inicial
de dicho autmata fue xt1 [42]. En la gura 4.23 se muestra una visualizacin de este modelo.
Figura 4.23: El modelo de movimiento. Las distribuciones posteriores de la pose del robot
al desplazarse son ilustradas por la lnea continua. [42]
Existen dos modelos probabilsticos de movimiento especcos p(xt |ut , xt1 ), ambos para
robots mviles que funcionan en el plano [42]:
1. El primero supone que la informacin de movimiento ut equivale a los comandos de ve-

locidad dados a los motores del robot. Este suele utilizarse en ambientes simulados [42].
2. El segundo asume que ut es proporcionado por datos odomtricos [42]. Este suele usarse
en escenarios reales, por lo que fue el modelo implementado en Donaxi@HOME.
4.2.2.5. El modelo sensorial
El modelo sensorial devuelve la probabilidad de una medicin real dados la pose de una partcula
y un mapa. En otras palabras, calcula la probabilidad de obtener una lectura a partir de un
sensor en funcionamiento cuando el robot se encuentra en una posicin hipottica. Este modelo
se ocupa de la incertidumbre inherente asociada a mediciones de dicho transductor [42].
El proceso aqu descrito es modelado como la distribucin de probabilidad condicional

p(zt |xt , m), donde zt es la medicin en curso, xt es la supuesta pose y m representa al ma-
pa. Esta distribucin es elaborada a partir de una mezcla ponderada de cuatro distribuciones
probabilsticas individuales[42], las cuales son representadas grcamente en la gura 4.24. La
siguiente ecuacin describe lo aqu mencionado:
phit (ztk |xt , m)

zhit
zshort pshort (ztk |xt , m)
p(ztk |xt , m) =

zmax pmax (ztk |xt , m)
[42]

zrand prand (ztk |xt , m)
Figura 4.24: Las cuatro distribuciones que componen al modelo sensorial [42]
4.2.2.6. Algoritmo de Localizacin de Monte Carlo (MCL)

La estructura bsica del algoritmo de localizacin de Monte Carlo (MCL), disponible en las
referencias [18], se muestra a continuacin:
1: Algoritmo MCL(Xt1 , ut , zt , m):

2: X t = Xt = 0
3: for m=1 to M do
4:
[m]
xt = sample_motion_model(ut , x[m]
t1 )
5: wt
[m]
= measurement_model(zt , x[m]
t , m)
[m] [m]
6: X t = X t + (xt , wt )
7: endfor
8: for i=1 to M do
[i]
9: draw i with probability wt
[i]
10: add xt to Xt
11: endfor
12: return Xt
A continuacin se brinda una breve descripcin lnea por la lnea de este algoritmo.
1. Se declara el algoritmo MCL como una funcin dependiente de cuatro variables: el conjunto
de posibles estados del mundo en un tiempo a priori (Xt1 ), los controles que rigen el
movimiento del robot en el tiempo actual (ut ), las lecturas del telmetro lser en el tiempo
actual (zt ) y la variable m que representa a los datos del mapa.
2. La conabilidad del estado del robot (X t ) y el conjunto de posibles estados del mundo
(Xt ), ambos en el tiempo actual, se inicializan en cero.
3. Se inicializa el ciclo de repeticin for, donde la variable m se itera desde uno hasta el
nmero total de posibles estados del mundo (M ).
[m]
4. El estado estimado del mundo nmero m en el tiempo actual (xt ) se iguala al valor del
modelo de partculas de movimiento dependiente del control de movimiento (ut ) y
el estado a priori del mundo nmero
[m]
m (xt1 ).
5. Elfactor de importancia nmero m en el tiempo actual (wt[m] ) se iguala al valor del

modelo de medicin dependiente de las lecturas del telmetro lser en el tiempo actual
[m]
(zt ), el estado estimado del mundo nmero m en el tiempo actual (xt ) y la variable m.
6. La conabilidad del estado del robot (X t ) adquiere el valor de la sumatoria de su mismo

[m] [m]
valor con el de las variables xt y wt .
7. Termina el ciclo de repeticin for.

8. Se inicializa un nuevo ciclo de repeticin for, donde la variable i se itera desde uno hasta
el nmero total de posibles estados del mundo (M ).
9. Se dibuja cada partcula o posible estado del mundo (i) con una probabilidad de certeza
[i]
igual al factor de importancia (wt ).
[i]
10. Se agrega el valor de xt a la variable Xt .
11. Termina el ciclo de repeticin for.
12. Termina la funcin del algoritmo MCL, la cual devuelve el valor de Xt .
Captulo 5
Planicacin de trayectorias en el
robot Donaxi@HOME
Con el objetivo de que el robot Donaxi@HOME realizara la tarea de planicar trayectorias
hacia un objetivo especicado a travs de un mapa previamente generado (descrito en el captulo
move_base, el cual pertenece al repositorio de navegacin (Navigation
4) se utiliz el paquete
Stack) que viene incluido dentro la distribucin ROS Groovy Galapagos.
El paquete move_base permite implementar acciones que, dado un objetivo en el mundo,
tengan la funcin de llegar a este con una base mvil. Dentro de este paquete existe un nodo
del mismo nombre, el cual cuenta con dos planicadores de trayectorias (planners), uno a nivel
global y otro a nivel local, y dos mapas de costos (costmaps), uno para cada planicador[43].
El nodo move_base es uno de los componentes principales del repositorio de navegacin[43],
por lo cual es bastante complejo. Con el objetivo de explicar su funcionamiento de la mejor
manera posible, este programa fue dividido en tres niveles de accin que sern descritos a
continuacin:
1. Planicador de campos potenciales.
2. Interaccin con el entorno ROS.
3. Implementacin en un robot real.
5.1. Planicador de campos potenciales

La tcnica de navegacin de campos potenciales articiales armnicos, denominada en
planicador de campos potenciales, consiste en considerar a un robot
la presente tesis como
mvil como una carga puntual para la evasin de obstculos. Este mtodo reactivo, propuesto
por O. Khatib en 1985 y en el cual el movimiento del autmata es guiado por el gradiente de
campo, tiene como principal caracterstica el hecho de que la trayectoria es generada al mismo
tiempo que se realiza el movimiento del robot [44].
El mtodo de campos potenciales se basa en considerar el movimiento en un campo de
fuerzas, con los obstculos generando fuerzas de repulsin y la posicin objetivo actuando como
una fuerza de atraccin, es decir, es una tcnica reactiva de navegacin donde el movimiento del
robot es guiado por el gradiente del campo potencial articial [44].
La teora de campos potenciales considera al robot como una partcula bajo la inuencia de
un campo potencial articial, cuyas variaciones modelan el espacio libre. La funcin potencial
en un punto q del espacio euclidiano, q = (x, y), se dene sobre el espacio libre y consiste en
41
42 CAPTULO 5. PLANIFICACIN EN EL ROBOT DONAXI@HOME
la composicin de un potencial atractivo a (q), que atrae al robot a la posicin destino, y otro
repulsivo r (q) que lo hace alejarse de los obstculos, es decir: (q) = a (q) + r (q) [44].
La fuerza articial F (q) que afecta el vehculo en la posicin q , por el potencial articial (q)
se dene como: F (q) = (q) [44].
Al igual que la la funcin potencial, la fuerza articial es el resultado de la suma de una
fuerza de atraccin Fa (q), proveniente de la posicin destino , y otra fuerza de repulsin Fr (q)
debidas a los obstculos del entorno de trabajo: F (q) = Fa (q) + Fr (q) [44].
El problema con este tipo de mtodos viene de la aparicin de mnimos locales, es decir,
lugares que no son la posicin destino en los cuales el potencial resulta nulo. Una situacin de
este tipo puede hacer que el robot quede atrapado en una posicin que no sea la de destino, o
bien, debido a la naturaleza discreta del mtodo girar alrededor de ella [44].
El nodo move_base es una variante bastante robusta del planicador de campos potenciales
aqu expuesto.
5.2. Interaccin con el entorno ROS

El nodo move_base proporciona una interfaz dentro de ROS que permite congurar, ejecutar e
interactuar con el repositorio de navegacin de este sistema metaoperativo para implementarlo
posteriormente en un robot. En la gura 5.1 se muestra una vista de alto nivel de este nodo,
as como su interaccin con otros componentes. Los elementos azules son suministrados por el
robot a controlar, los grises son opcionales para el funcionamiento del programa, mientras que los
blancos son necesarios para esto; en los dos ltimos casos, dichos elementos son proporcionados
para todos los sistemas[43].
Figura 5.1: Esquema de funcionamiento del nodo move_base [43]
Este programa interacta a travs de ROS con la ayuda de varias instrucciones, las cuales
pueden clasicarse en las siguientes seis categoras:
Tpicos relacionados a la librera de acciones ( actionlib)

Otros tpicos de subscripcin.
Otros tpicos de publicacin.
Servicios.
Parmetros.
5.2. INTERACCIN CON EL ENTORNO ROS 43
Componentes con aplicaciones propias
5.2.1. Tpicos relacionados a la librera de acciones (actionlib)

El nodo move_base permite la ejecucin del servidor de acciones simples ( SimpleActionServer),
una herramienta de la librera de acciones que convierte mensajes de un tipo especco (cono-
cido como geometry_msgs/PoseStamped dentro de ROS) en metas (goals), las cuales son
posiciones objetivo que pueden ser localizadas (o no) dentro de un mapa previamente gene-
rado. Aunque dichas metas pueden ser comunicadas a este nodo a travs de ROS de manera
directa, la forma recomendada para enviarlas es mediante el uso del cliente de acciones sim-
ples ( SimpleActionClient), tambin perteneciente a la librera de acciones, utilidad que pro-
porciona el seguimiento del estado de estas, para saber si son o no son enviadas, recibidas o
concretadas[43].
El programa aqu abordado hace uso de la librera de acciones para recibir informacin
subscribindose a los siguientes tpicos:
move_base/goal : Por este tpico se reciben metas que se desean alcanzar en el mundo.
Los mensajes aqu recibidos son del tipo move_base_msgs/MoveBaseActionGoal [43].
move_base/cancel : Por este tpico se reciben solicitudes para cancelar metas espec-
cas. Los mensajes aqu recibidos son del tipo actionlib_msgs/GoalID [43].
Este nodo tambin enva informacin empleando dicha librera publicando los siguientes
tpicos:
move_base/feedback : En este tpico se publica la posicin actual de la base mvil en el

mundo. Los mensajes aqu transmitidos son del tipo move_base_msgs/MoveBaseActionFeedback
[43].
move_base/status : Por medio de este tpico se proporciona informacin sobre el estado

que presentan las metas enviadas al nodo move_base. Los mensajes aqu transmitidos son
del tipo actionlib_msgs/GoalStatusArray [43].
move_base/result : Por medio de este tpico se informa si una accin realizada por el
nodo move_base arroja un resultado nulo. Los mensajes aqu transmitidos son del tipo
move_base_msgs/MoveBaseActionResult [43].
5.2.2. Otros tpicos de subscripcin

Adems de los tpicos de recepcin mencionados anteriormente, el nodo move_base se suscribe
a uno ms:
move_base_simple/goal : Este tpico proporciona una interfaz para el nodo aqu

expuesto, la cual acta como un medio de adquisicin de informacin alternativo, com-
pletamente ajeno a la librera de acciones, para los usuarios que no se preocupan por el
seguimiento del estado de ejecucin de las metas que desean alcanzar con sus respectivos
robots. Los mensajes aqu recibidos son del tipo geometry_msgs/PoseStamped [43].
5.2.3. Otros tpicos de publicacin

El nico tpico no relacionado con la librera de acciones que publica el nodo move_base es el
que sigue:
cmd_vel : Este tpico es posiblemente el ms importante del programa, ya que se encarga

de publicar una corriente de comandos de velocidad cuyo destino es ser ejecutados por una
base mvil, es decir, le indica al robot como debe moverse para llevar desplazarse siguiendo
una trayectoria. Para que esto se cumpla, la informacin proporcionada debe ser traducida
para que los motores puedan interpretarla (esto ltimo se abordar en el captulo 6). Los
mensajes aqu transmitidos son del tipo geometry_msgs/Twist) [43].
5.2.4. Servicios
Los servicios que utiliza el nodo move_base para comunicarse a travs de ROS son los siguientes:
make_plan : Este servicio le permite al usuario solicitar un plan al nodo move_base

para alcanzar una determinada posicin sin causar que dicho programa lo ejecute. La
comunicacin aqu realizada se da utilizando mensajes del tipo nav_msgs/GetPlan [43].
clear_unknown_space : Este servicio le permite al usuario indicarle al nodo move_base
que libere el espacio desconocido de un rea que se encuentra directamente alrededor del
robot. Esto resulta til cuando dicho programa tiene su mapa de costos parado por un largo
perodo de tiempo y luego se comienza de nuevo en una nueva ubicacin dentro del entorno.
La comunicacin aqu realizada se da utilizando servicios del tipo std_srvs/Empty [43].
clear_costmaps : Este servicio le permite al usuario solicitarle al nodo move_base que
despeje obstculos existentes dentro de los mapas de costos que utiliza dicho programa.
Esto puede provocar que el robot controlado choque contra objetos existentes en su medio,
por lo que esta funcin debe utilizarse con precaucin. La comunicacin aqu realizada se
da utilizando servicios del tipo std_srvs/Empty [43].
5.2.5. Parmetros
Para que el nodo move_base opere apropiadamente, necesita de varios parmetros que sirvan
como guas para la realizacin de sus funciones. A continuacin se presenta una lista de todos
ellos:
base_global_planner : Este complemento le permite al nodo move_base la utilizacin

de un planicador global de trayectorias. Requiere de la interfaz nav_core::BaseGlobalPlanner
especicada en el paquete nav_core para funcionar[43].
base_local_planner : Este complemento le permite al nodo move_base la utilizacin
de un planicador local de trayectorias. Requiere de la interfaz nav_core::BaseLocalPlanner
especicada en el paquete nav_core para funcionar[43].
recovery_behaviors : Es una serie de complementos diseada para proporcionarle
al nodo move_base varios comportamientos de recuperacin. Estas tareas se ejecutan
cuando dicho programa no logra encontrar un plan vlido de accin para llegar a una
meta en el orden en que se solicita. Despus de haber completado uno de estos com-
portamientos, el nodo intentar hacer nuevamente un plan, el cual, si es realizado co-
rrectamente, le permitir al programa continuar con su funcionamiento normal. De lo con-
trario, se ejecutar la siguiente medida de recuperacin de la lista. Requieren de la interfaz
nav_core::RecoveryBehavior especicada en el paquete nav_core para funcionar[43].
controller_frequency : Este parmetro indica la frecuencia en hertz (Hz) a la cual se
repetirn las instrucciones existentes dentro del ciclo de control ( while ) del nodo move_base,
lo que tambin incluye al envo de comandos de velocidad que son publicados para con-
trolar a un robot. Se toma una frecuencia de 20 Hz en caso de no ser indicada alguna
otra[43].
5.2. INTERACCIN CON EL ENTORNO ROS 45
planner_patience : Este parmetro indica cunto tiempo (en segundos) esperar el

planicador tras un intento de encontrar un plan vlido antes de realizar operaciones
de liberacin de espacio en el mapa. Por defecto se toma un tiempo de espera de cinco
segundos[43].
controller_patience : Este parmetro indica el tiempo (en segundos) que el contro-

lador esperar sin recibir un control vlido antes de realizar sus respectivas operaciones
de liberacin de espacio en el mapa. Por defecto se toma un tiempo de espera de quince
segundos[43].
conservative_reset_dist : Este parmetro indica la distancia mnima (en metros)

que debern tener los obstculos con respecto al robot para poder ser retirados del mapa
de costos cuando se desee liberar espacio en el mapa del entorno. Por defecto se toman tres
metros. Este complemento no puede utilizarse si el llamado conservative_reset_dist,
presentado en la siguiente vieta, se encuentra deshabilitado[43].
conservative_reset_dist : Este parmetro habilita la utilizacin de comportamientos

de recuperacin en el nodo move_base para liberar espacio en el mapa. Se encuentra
activado por defecto[43].
clearing_rotation_allowed : Este complemento determina si el robot intentar una

rotacin sobre su eje cuando trata de liberar espacio en el mapa. Slo puede ser utilizado
cuando se emplean los comportamientos de recuperacin predeterminados. Se encuentra
habilitado por defecto[43].
shutdown_costmaps : Este complemento permite desactivar el mapa de costos cuando

el nodo move_base se encuentra en un estado inactivo. Se encuentra inhabilitado por
defecto[43].
oscillation_timeout : Este parmetro le dice al nodo move_base cuanto tiempo (en

segundos) debe permitir que el robot este oscilando antes de ejecutar los comportamientos
de recuperacin. Por defecto se toma un valor de cero, que equivale a un tiempo de espera
innito[43].
oscillation_distance : Este parmetro le indica al nodo move_base que distancia

(en metros) debe moverse el robot para considerar que no esta oscilando. Si el autmata
se desplaza como mnimo el recorrido aqu propuesto, se reiniciar el temporizador que
es tomado como referencia por el complemento oscillation_timeout, explicado en la
vieta anterior. Por defecto se toma un valor de medio metro[43].
oscillation_distance : Este parmetro establece la frecuencia (en Hz) a la cual se va

a ejecutar el ciclo de planicacin global. Si se establece un valor de cero, el planicador
global slo se ejecutar cuando se reciba un nuevo objetivo o cuando el planicador local
informe que el camino se encuentra bloqueado. Por defecto se toma un valor de cero
hertz[43].
5.2.6. Componentes con aplicaciones propias

El nodo move_base posee componentes que cuentan con sus propias aplicaciones dentro de
ROS. Dichos elementos pueden variar en funcin de los valores proporcionados en los parmetros
base_global_planner, base_local_planner y recovery_behaviors respectivamente[43], los
cuales fueron expuestos en el apartado anterior.
Son seis constituyentes de este programa que cumplen con la condicin descrita en el prrafo
anterior, sin embargo, debido a su complejidad slo son mencionados a continuacin:
costmap_2d.
nav_core.
base_local_planner.
navfn.
clear_costmap_recovery.
rotate_recovery.
5.3. Implementacin en un robot real

Ejecutar el nodo move_base en un robot que est congurado correctamente provoca que dicha
mquina intent alcanzar una posicin objetivo. EL accionar del autmata estar determina-
do por una tolerancia especicada por el usuario. En ausencia de obstculos dinmicos, este
programa eventualmente conseguir llegar a dicha meta o fracasar en el intento, lo que gene-
rar como respuesta una seal de conrmacin especca hacia el usuario en cualquiera de los
dos casos. Este nodo puede realizar opcionalmente comportamientos de recuperacin cuando
la base manipulada se percibe a s misma como atascada (ubicada en una posicin desde la
cual no puede llegar hacia un objetivo solicitado)[43]. De forma predeterminada, se tomarn las
siguientes acciones para tratar de despejar el espacio:
1. Los obstculos fuera de una regin especicada por el usuario sern borrados del mapa
del robot[43].
2. Si es posible, el autmata realizar una rotacin en el lugar para limpiar el espacio[43].
3. En caso de que lo anterior no se cumpla, el robot controlado utilizar recursos ms agresivos

para limpiar su mapa, lo que se traduce en la eliminacin de todos los obstculos fuera de
la regin rectangular sobre la que pueda girar rotando sobre su propio eje[43].
4. La base mvil girar sobre si misma una vez ms para corroborar su posicin[43].
5. Si todo falla, el robot tendr en cuenta su objetivo no es factible y noticar al usuario

que ha sido abortada su consecucin[43].
Todos los comportamientos de recuperacin aqu enumerados se pueden congurar mediante

recovery_behaviors y pueden ser desactivados mediante el mediante el llamado
el parmetro
recovery_behavior_enabled, expuestos en la seccin anterior[43]. La gura 5.2 ilustra el
accionar de estas medidas de recuperacin.
Figura 5.2: Comportamientos de recuperacin predeterminados en el nodo move_base [43]

5.3. IMPLEMENTACIN EN UN ROBOT REAL 47
5.3.1. Implementacin en el robot Donaxi@HOME

El robot Donaxi@HOME opera con los comportamientos de recuperacin predeterminados exis-
tentes en el nodo move_base, as como con las conguraciones mnimas propuestas en los tuto-
riales de navegacin de ROS existentes en lnea[45]. Esto se debe a que la mayora de las pruebas
se realizaron en entornos ideales, es decir, ambientes prefabricados con obstculos uniformes
fciles de detectar y esquivar para que la tarea de planicacin de trayectorias fuese ms sen-
cilla. En la gura 5.3 se ilustran, haciendo uso de rviz, los resultados de la implementacin del
software descrito a lo largo de todo este captulo en el autmata utilizado en la presente tesis.
Figura 5.3: Implementacin del nodo move_base en el robot Donaxi@HOME. Los

obstculos existentes en el entorno se ilustran en verde, donde el tono ms oscuro representa a
lo detectado por el lser y el ms claro a la inacin agregada hacia los mismos a travs de los
mapas de costos; la trayectoria azul es la ruta que ser seguida por el robot, representado por
el rectngulo negro, mientras que la curva roja es el planicador local de costos; por ltimo, la
echa roja es un vector que indica la posicin y orientacin del objetivo que se desea alcanzar.
Las principales aportaciones que se incorporaron al proyecto tienen que ver con la dinmica
del envo de objetivos y el perfeccionamiento en la ejecucin de los mismos, ms no en la tarea
de planicacin como tal. Esto ser explicado a profundidad en el captulo 7.
Captulo 6
Control de movimiento en el robot

Donaxi@HOME
A lo largo del presente captulo sern presentadas las herramientas, tanto de software como
de hardware, que fueron utilizadas para lograr controlar exitosamente el movimiento del robot
Donaxi@HOME.
El hardware empleado por el autmata aqu presentado para cumplir con la tarea de despla-
par de motores (cada uno con su respectivo
zarse a travs de su mundo est compuesto por un
codicador rotativo) y un controlador, mientras que su software es representado por un un
par de nodos que incorporan una serie de comandos que permiten enlazar a ROS con dicho
controlador. A continuacin se abordan todos estos elementos.
6.1. Motores y codicadores rotativos utilizados

Para que el robot Donaxi@HOME pudiera moverse a travs de su entorno con la nalidad
de resolver las tareas que le fueron encomendadas, se utilizaron dos impulsores con bastante
momento de torsin (torque1 ) que le permitieron a dicho autmata desplazarse de forma
diferencial sin mayor problema.
A continuacin se brindan detalles fsicos acerca de estos actuadores, los cuales van desde as-
pectos tcnicos acerca de los mismos hasta la manera en como fueron colocados o dispuestos
a lo largo del cuerpo del robot de servicio aqu expuesto.
6.1.1. Informacin tcnica

El robot Donaxi@HOME posee dos servomotores sin escobillas modelo BLM-N23-50-
1000-B (ver gura 6.1). Cada uno de estos actuadores tiene un codicador rotativo de
cuadratura incremental acoplado a su respectivo eje[47].
Enseguida se muestran dos listados de las principales especicaciones de estos dispositivos,
uno de los actuadores y otro de los sensores usados en conjunto con estos, mencionados en el
prrafo anterior.
1 El momento de torsin (del ingls torque ) o par sobre un objeto se dene como el producto de la fuerza
aplicada a dicho cuerpo por la distancia ms corta entre la lnea de accin de dicha fuerza y el eje de rotacin
del mismo elemento, es decir, = F r sen(). Mientras mayor sea el par aplicado sobre una pieza, su velocidad
angular cambiar con mayor rapidez. Sus unidades son N m en el sistema internacional y lb pie en el sistema
ingls, aunque en algunas hojas de datos se utilizan unidades de masa por distancia[46].
49
50 CAPTULO 6. CONTROL DE MOVIMIENTO EN EL ROBOT DONAXI@HOME
Figura 6.1: Motor utilizado en el robot Donaxi@HOME [47]
6.1.1.1. Especicaciones de los motores

Cada motor cumple con lo siguiente:
Proporciona un momento de torsin continuo de 55 oz pulg (3.96 kg cm) y un mximo

de 120 oz pulg (8.64 kg cm)[47].
Se alimenta de 48 v para alcanzar una velocidad mxima de 5 000 rpm y demanda 4.6 A
de corriente continua para funcionar[47].
Posee un tamao relativamente pequeo de23 frame, de acuerdo al estndar de NEMA

National Electrical Manufacturers Association2 )[47]. En la tabla 6.2, se muestran
(
las dimensiones equivalentes del motor de acuerdo a esta norma.
Figura 6.2: Dimensiones de motores de acuerdo a NEMA [48]
Responde a la inercia con un momento de torsin alto, lo que permite una rpida acelera-
cin y una gran capacidad de respuesta en aplicaciones punto a punto[47].
2 La
Asociacin Nacional de Fabricantes Elctricos, NEMA por sus siglas en ingls, es una asociacin interna-
cional de equipos elctricos y fabricantes de imgenes mdicas. Adems de ser lderes en ventas a nivel mundial,
NEMA proporciona un foro para el desarrollo de: los estndares tcnicos que se encuentran dentro de los princi-
pales intereses de la industria y los usuarios, la promocin de las polticas industriales sobre asuntos legislativos
y reglamentarios, y la recoleccin, anlisis y difusin de datos de la industria a nivel global[49].
6.1. MOTORES Y CODIFICADORES ROTATIVOS UTILIZADOS 51
Tiene un efecto de cogging3 extremadamente bajo, por lo que su desempeo a bajas

velocidades es bastante suave[47].
Cubre cualquier perl de movimiento solicitado sin importar la velocidad a la que se

realice con bastante precisin, esto siempre y cuando dicha velocidad este dentro de sus
limites[47].
6.1.1.2. Especicaciones de los codicadores rotativos

Cada codicador rotatorio de cuadratura incremental cumple con lo siguiente:
Tiene una resolucin de 1 000 lneas con pulso indexado4 [47].
Se alimenta de de 5 v 5 % y demanda una corriente mxima de 120 mA[47].
Proporciona seales de salida a un mximo absoluto de 20 mA por canal de fuga[47].
Responde a un momento de inercia mnimo de 3.5103 pulgozs2 (2.5105 kgm2 )[47].
Detecta una aceleracin mxima de 100 000 rad/s2 [47].
Es capaz de medir velocidades de 5 000 rpm como mximo[47].

Opera a temperaturas que van desde -20 C hasta 100 C[47].

Puede ser almacenado en temperaturas que van desde -40 C hasta 125 C[47].
Funciona a una humedad relativa mxima sin condensacin del 98 % en el ambiente[47].
6.1.2. Disposicin en el robot Donaxi@HOME

Aunque los motores usados en el robot Donaxi@HOME tienen un tamao relativamente
pequeo en comparacin con las funciones que realizan, como fue mencionado anteriormente,
poseen dimensiones importantes (ver gura 6.3). Esto, aunado al hecho de que se requirieron
dos transmisiones de cadena para incrementar el momento de torsin de los actuadores, provoc
que estos ltimos fueran dispuestos de una manera muy particular en el chasis del autmata
para ahorrar espacio.
3 Cogging es un trmino utilizado para describir a la velocidad angular no uniforme. Se reere a la rotacin
cuando esta se produce en forma de tirones o incrementos en lugar de hacerlo realizando un movimiento suave.
Este efecto se hace evidente a bajas velocidades. Cuanto menor sea el nmero de bobinas en un motor, mayor
ser la presencia de dicho efecto.[51]
4 El pulso indexado, a menudo tambin llamado pulso Z o pulso de marcador, de un codicador incremental
ptico es una seal digital que sucede una vez por cada revolucin del actuador acoplado. Se utiliza como un
nmero de vericacin de seales incrementales[52].
Figura 6.3: Dimensiones reales de cada motor [47]
En la fotografa 6.4 se puede observar una toma del robot Donaxi@HOME, ligeramente
levantado del piso visto desde atrs, donde se aprecia claramente la distribucin que tienen los
motores motores con sus respectivas transmisiones. Cada actuador tiene una etiqueta con una
letra: Y corresponde al actuador izquierdo, mientras que X al derecho. Ambos dispositivos estn
encontrados entre s, es decir, si X e Y rotan hacia el mismo sentido, el autmata girar sobre
su propio eje, y si lo hacen en sentidos opuestos, dicho mvil se desplazar linealmente hacia el
frente o en reversa.
Figura 6.4: Disposicin de los motores en el robot Donaxi@HOME
Cabe mencionar que los movimientos descritos en el prrafo anterior fueron expuestos de
manera ideal, ya que en la realidad siempre existir un cierto desfase debido a los problemas
mecnicos inherentes del robot aqu expuesto (mencionados en el primer captulo de la tesis).
Por ltimo, debido a la forma en que se realizaron las conexiones de los actuadores hacia el
controlador, en los programas que interactan con dichos impulsores, se utilizan las variables Y
y Z para representar a los motores Y y X respectivamente.
6.2. CONTROLADOR EMPLEADO 53
6.2. Controlador empleado

Para poder establecer la comunicacin entre los motores con sus respectivos codicadores ro-
tativos y el ordenador, fue necesaria la utilizacin de un controlador, el cual, en un contexto
meramente computacional, equivale un dispositivo fsico o un programa virtual que gestiona o
dirige el ujo de datos entre dos entidades[50]. En el caso del robot Donaxi@HOME se trata
del primer caso.
A continuacin se brinda informacin acerca de este dispositivo, tanto a nivel de hardware
como a nivel de software.
6.2.1. Nivel de hardware

El robot Donaxi@HOME utiliza el dispositivo DMC-40x0 (ver gura 6.5), un controlador
de motores independiente de alto rendimiento fabricado por la empresa Galil Motion Control,
Inc.[53] Enseguida se muestran sus especicaciones:
Figura 6.5: Controlador utilizado en el robot Donaxi@HOME [53]
Pertenece a la familia de controladores de ltima generacin Accelera Series, por lo cual

acepta lecturas de codicadores rotativos a una frecuencia de hasta 22 MHz, permite
actualizar la posicin de un servomotor a una tasa de 32 KHz y procesa comandos cada
40 microsegundos [53].
Se basa en la arquitectura RISC y utiliza un procesador multiplicador de tiempos con

funciones DSP [53].
Se comunica principalmente a travs de un puerto Ethernet 10/100BASE-T con auto-
MDIX. Aunque tambin posee puertos RS232 que aceptan una tasa mxima de transfe-
rencia de datos de 115 kilobaudios, estos no son utilizados por el robot Donaxi@HOME
[53].
Tiene una memoria que admite hasta 2 000 lneas de 80 caracteres cada una. Es capaz de
almacenar 510 variables, as como un total de 30 arreglos de hasta 16 000 elementos cada
uno [53].
Presenta los siguientes rangos cinemticos:

a) Comunica posiciones de hasta 32 bits ( 2.15 mil millones de cuentas por movimiento;
regreso automtico; movimientos sin lmite en las modalidades manuales y vectoriales
[53].
b) Comunica velocidades de hasta 22 millones de cuentas/s en servomotores [53].
c) Comunica aceleraciones de hasta 1 000 millones de cuentas/s2 [53].
Ofrece varias modalidades de movimiento [53].
Permite ltrar datos [53].
Posee entradas y salidas dedicadas por eje de movimiento. Cada eje representa un motor
a controlar [53].
Establece la comunicacin con los motores a pasos que gobierna a una frecuencia mxima
de 6 MHz [53].
Requiere de una alimentacin de 20 a 80 v de corriente directa para funcionar [53].
6.2.2. Nivel de software

Para que la computadora a la cual se conecta el controlador de los motores se pueda comunicar
con este ltimo, existen una serie de comandos o instrucciones con diferentes funciones que se
pueden utilizar, siendo la principal caracterstica de estos, el hecho de que deben ser caracteres
ASCII para que sean reconocidos.
Los comandos que aqu se describirn, fueron creados en cdigo DMC (Digital Motion
Controller), un lenguaje interpretado de alto nivel que, aunque es fcil de aprender y usar,
es sorprendentemente poderoso. Este cdigo, ha sido desarrollado y renado activamente desde
1983, siendo utilizado comnmente en aplicaciones para el control de movimiento y programacin
de PLCs. Galil Motion Control, Inc. emplea este lenguaje en todo el hardware que produce [54].
En la siguiente lista se mencionan todos los comandos que se implementaron en el robot
Donaxi@HOME:
RS (Reset): Reinicia las conguraciones del procesador a su condicin de encendido. El
estado previamente guardado en el hardware, junto con los valores de sus parmetros y
los programas salvados, son restablecidos [54].
Sintaxis: RS;
SH (Servo Here): Le indica al controlador que utilice la posicin actual del motor
como la posicin inicial para la recepcin de comandos, adems habilita el control de los
servomotores pasados como argumentos para esta instruccin [54].
Sintaxis: SH YZ;
AC (Acceleration): Establece la magnitud de la aceleracin lineal que tendrn los mo-

tores cuando realicen movimientos independientes, tales como los indicados en los coman-
dos PR y JG. Esta instruccin puede ser cambiada durante la ejecucin del movimiento.
Las unidades de sus parmetros son cuentas/s2 [54].
Sintaxis: AC 100000;
DC (Deceleration): Establece la magnitud de la desaceleracin lineal que tendrn los

motores cuando realicen movimientos independientes, tales como los indicados en los co-
mandos PR y JG. Esta instruccin puede ser cambiada durante la ejecucin del movimien-
to. Las unidades de sus parmetros son cuentas/s2 [54].
Sintaxis: DC 100000;
6.3. NODOS DE CONTROL 55
JG (Jog): Habilita el modo manual de movimiento, permitiendo asignarle una velocidad

(en cuentas/s) a los ejes (motores) [54].
Sintaxis: JG,100000,100000;
BG (Begin): Inicia un movimiento en el eje o la secuencia especicada [54].

Sintaxis: BG YZ;
TV (Tell Velocity): Devuelve la velocidad real del eje pasado como argumento (en
cuentas/s), de acuerdo a lo que indica el codicador rotativo en el momento en que se
pregunta. El valor devuelto incluye el signo, el cual depender del sentido de rotacin del
motor [54].
Sintaxis: TV Y;
PR (Position Relative): Establece la distancia incremental y la direccin del siguiente

movimiento, es decir, cuantas cuentas se van a desplazar y en que sentido van a girar los
actuadores. La medida toma como referencia a la posicin actual de los motores [54].
Sintaxis: PR,100000,100000;
SP (Speed): Establece la velocidad de giro para uno o varios ejes cuando estos realicen
movimientos independientes, tales como los indicados en los comandos PR y JG. Si se
indican valores negativos como argumentos de este comando, estos sern tomados como
absolutos [54].
Sintaxis: SP,100000,100000;
AM (After Move): Acta como un punto de partida, ya que se utiliza para sincronizar las
acciones realizadas por los motores. Su funcin principal consiste en impedir la ejecucin
de nuevos comandos hasta que se complete el movimiento que este siendo realizado por los
ejes indicados como parmetros. Se recomienda usar esta instruccin despus de cualquier
encomienda que implique un desplazamiento por parte de los actuadores [54].
Sintaxis: AM YZ;
ST (Stop): Detiene el movimiento en los ejes especicados. En cuanto el comando es

recibido, los motores empezaran a desacelerar hasta frenarse por completo. Si esta ins-
truccin es enviada sin especicar los parmetros a detener, adems de dicho movimiento
se parar la ejecucin de los programas en curso [54].
Sintaxis: ST YZ;
Y y Z para
En la sintaxis de los comandos descritos anteriormente, se utilizaron las variables
ejes de movimiento o motores a controlar (homnimas a las usadas en el
representar dos
robot Donaxi@HOME) y el nmero 100 000 como un valor arbitrario de cuentas a considerar,
esto nicamente para ejemplicar el funcionamiento de estas instrucciones.
6.3. Nodos de control

Los nodos de control son aquellos programas encargados de establecer la comunicacin entre
ROS y el controlador de los motores, esto con la nalidad de poder enviarle instrucciones de
movimiento a dichos actuadores.
De acuerdo a lo expuesto en el captulo 4, en el robot Donaxi@HOME fueron realiza-
dos dos arreglos de nodos llamados generacin de mapa y navegacin en el mapa generado,
donde cada conguracin posee un solo nodo de control denominados motor_gen_mapa y
motor_formula respectivamente.
Los dos programas mencionados en el prrafo anterior tienen una doble funcin, ya que
tambin se desempean como nodos de percepcin como fue explicado en el cuarto apartado
de esta tesis, sin embargo, en la presente seccin sern desarrollados desde el punto de vista del
control de movimiento.
6.3.1. Nodo motor_gen_mapa

El nodo motor_gen_mapa se encarga de dos tareas fundamentales para el control de movimien-
to: establecer la comunicacin entre ROS y el controlador y enviarle instrucciones a dicho hard-
ware para que sean ejecutadas por los motores conectados a l. El siguiente algoritmo resume el
accionar de este programa para realizar estas encomiendas:
1. La comunicacin entre la computadora y el controlador es establecida. Para esto, por medio

del protocolo TCP/IP, le es asignada una direccin IP esttica a dicho controlador para
que pueda ser reconocido por el ordenador, y en consecuencia, tambin pueda enlazarse
con ROS. La IP utilizada es la 192.168.0.30 y el medio de transferencia de datos es una
conexin va ethernet.
2. La suscripcin a los tpicos cmd_vel y pos es realizada. Esto se muestra en la gura 6.6.
Figura 6.6: Tpicos suscritos al nodo motor_gen_mapa
3. El tpico cmd_vel, proveniente del nodo teleop_joy que ser explicado en el captulo 7,
comunica nmericamente la posicin que adquiere una palanca de mando (joystick)
conectada a la computadora. A partir de esto, se establecen condiciones para que, depen-
diendo de hacia donde se mueva dicho dispositivo, una variable a adquiera valores enteros.
Esto queda establecido de la siguiente manera:
a) Si la palanca de mando se mueve hacia el frente, a = 1.

b) Si lo anterior no se cumple y la palanca de mando se mueve hacia atrs, a = 2.
c) Si lo anterior no se cumple y la palanca de mando se mueve hacia la derecha, a = 3.
d) Si lo anterior no se cumple y la palanca de mando se mueve hacia la izquierda, a = 4.
e) Si ninguna de las condiciones anteriores se cumple, a = 0.
4. Ahora, retomando lo expuesto en el cuarto apartado de esta tesis acerca del presente nodo,
se pregunta por vel_lineal, variable que representa al valor de la velocidad lineal que lleva
al robot y, al mismo tiempo, al promedio de las velocidades de los dos actuadores que
impulsan a Donaxi@HOME. De est manera, si vel_lineal = 0, entonces se ejecutarn las
instrucciones de control para el movimiento de los motores, de lo contrario dichas ordenes
no se realizarn.
5. Las condiciones de control para el movimiento de los motores mencionadas en el cuarto

paso de este algoritmo son las siguientes:
a) Si a = 0, los motores no se movern.
b) Si a = 1, los motores desplazarn al robot a una distancia de 120000cuentas hacia

el frente a una velocidad constante de 120000cuentas/s, cifras que equivalen a 0.2m
(20cm) y 0.2 m/s (20 cm/s) respectivamente.
6.3. NODOS DE CONTROL 57
c) Si a = 2, el autmata retroceder 0.2m a una velocidad constante de 0.2m/s.

d) Si a = 3, el robot girar hacia la derecha a una velocidad constante de 0.2m/s.
e) Si a = 4, el autmata girar hacia la izquierda a una velocidad constante de 0.2m/s.
6. Retomando lo expuesto en el captulo 4, el nodo spatial_client comunica una bandera a

travs del tpico pos, la cual indica cuando el ngulo del eje z del girscopo alcanza un
valor de 15 grados sin importar el sentido. El valor de dicha bandera es almacenado por
la variable m en el presente programa.
7. Por ltimo, antes de cerrar el ciclo de repeticin de este nodo, se establece una condicin
de paro para los motores la cual es muy simple: si m = 1, entonces los motores se detienen;
de lo contrario, la ejecucin del cdigo continua normalmente.
6.3.2. Nodo motor_formula

El nodo motor_formula opera de manera similar al programa motor_gen_mapa, ya que tambin
realiza las dos tareas fundamentales de las que se encarga este ltimo; la diferencia entre ambos
radica en el objetivo que cada uno realiza, ya que mientras el primero tiene la funcin de mover
al robot lentamente para que genera su mapa, el segundo desempea la tarea de hacer que dicho
autmata alcanza rpidamente la meta que le fue solicitada.
El funcionamiento del software motor_formula como nodo de control se expresa en el si-
guiente algoritmo:
1. La comunicacin entre la computadora y el controlador es establecida. Para esto, por medio

del protocolo TCP/IP, le es asignada una direccin IP esttica a dicho controlador para
que pueda ser reconocido por el ordenador, y en consecuencia, tambin pueda enlazarse
con ROS. La IP utilizada es la 192.168.0.30 y el medio de transferencia de datos es una
conexin va ethernet.
2. La suscripcin a los tpicos cmd_vel y pos es realizada. Esto se muestra en la gura 6.7.
Figura 6.7: Tpicos suscritos al nodo motor_formula
3. A partir del tpico cmd_vel, el nodo move_base, explicado en el captulo 5, le indica

al robot como debe moverse con el n de seguir una trayectoria a partir del envo de
dos magnitudes fsicas: la velocidad lineal (vlineal ) y la velocidad angular (vangular )
que dicho autmata debe adquirir. Sin embargo, estos parmetros representan acciones
absolutas que deben ser concretadas por una base mvil, mientras que lo que se necesita son
instrucciones particulares que puedan ser interpretadas por los dos motores que se desean
controlar. Para cumplir con esto, se realizo el siguiente proceso matemtico-computacional:
a) Se sabe que las velocidades lineal y angular de un robot con desplazamiento diferen-
cial se obtienen a partir de las siguientes frmulas respectivamente: vlineal = vd+vi
2 y
vdvi
vangular = D . Donde vd y vi representan a las velocidades de los motores derecho e
izquierdo vistos desde la parte trasera del autmata y D es la distancia entre las ruedas
unidas a los ejes de dichos actuadores.
b) Tomando en cuenta que en el caso de Donaxi@HOME D = 0.46m, entonces al

2vlineal 0.46vangular
despejar se llega a las siguientes ecuaciones: vi = 2 vd = vi + 0.46
y
vangular .
c) Se almacenan los valores de vd y vi en variables homnimas.
4. Debido a la manera en que se encuentran dispuestos los motores en Donaxi@HOME,

como fue visto anteriormente (ver gura 6.4), y al hecho de que los valores obtenidos en
vd y vi representan cantidades porcentuales (su valor oscila entre 0 y 1), resulto necesario
establecer algunas condiciones para el control de movimiento, las cuales fueron:
a) Si vlineal = 0, entonces V Y = viF y V Z = vdF . Donde V Y y V Z son las velocidades

(en cuentas/s) que sern enviadas a los motores identicados con las letras Y y Z
respectivamente y F = 220000.
b) De lo contrario, V Y = vd F y V Z = vi F . Ntese el signo negativo en ambas

ecuaciones.
5. Por ltimo, se redondean los valores de VY y VZ y, posteriormente, se convierten a

cadenas de texto para que puedan ser enviadas va ethernet al controlador de los motores.
Retomando lo mencionado en el cuarto captulo de la presente tesis, los dos nodos de con-
trol expuestos en este captulo son programas originales realizados exclusivamente para este
proyecto.
Captulo 7
Pruebas y resultados
Como ya fue mencionado en captulos anteriores, en el robot Donaxi@HOME se utilizaron
dos arreglos de nodos: generacin de mapa y navegacin en el mapa generado, los cuales sern
descritos a lo largo de la presente seccin en funcin de sus caractersticas y el trabajo realizado
entorno a estos.
Resumiendo lo dicho en el prrafo previo, cada arreglo se dividir en las siguientes etapas:
1. Estructura y funcionamiento.
2. Pruebas realizadas.
3. Mejoras implementadas.
7.1. Generacin de mapa

Para que el robot Donaxi@HOME pudiera crear un mapa de su entorno de la mejor manera
posible, fue necesaria la realizacin de varias pruebas y mejoras en torno a las mismas, as como
comprender a la perfeccin el funcionamiento y composicin del arreglo de nodos que hizo que
este objetivo fuese posible.
Todo el proceso de generacin de mapa puede abreviarse en tres fases, mencionadas en la
introduccin del presente captulo, las cuales sern explicadas a continuacin.
7.1.1. Estructura y funcionamiento del arreglo

El arreglo de nodos generacin de mapa se compone de nueve nodos, como se menciono en el
captulo cuatro, y nueve tpicos de comunicacin. Todo esto se ilustra, por medio de rqt_graph,
en la gura 7.1, que es una visualizacin ms completa de la imagen 4.5 presentada con anteriori-
dad. Adems, existe un nodo no mencionado anteriormente que se invoca poco antes de nalizar
la ejecucin del presente arreglo, el cual debido a que realiza su trabajo de manera instantnea,
no aparece en los diagramas de rqt_graph. Dicho programa tambin ser mencionado en esta
seccin.
Figura 7.1: Arreglo de nodos generacin de mapa con sus respectivos tpicos
59
60 CAPTULO 7. PRUEBAS Y RESULTADOS
En el presente aparatado se abordar lo siguiente:
Los parmetros de ejecucin de cada nodo, contenidos en el roslaunch del arreglo.

La descripcin de los nodos pendientes, es decir, los programas que an no han sido
explicados a los largo de la tesis.
El funcionamiento detallado del arreglo, o lo que es lo mismo, la operacin en conjunto

de todos los programas implicados en la generacin del mapa.
7.1.1.1. Roslaunch del arreglo

El roslaunch del arreglo generacin de mapa, llamado donaxi.launch, contiene, adems de
a cada uno de los nueve programas que lo componen incluyendo a la herramienta record de
rosbag, al visor rviz. Este archivo tambin establece los argumentos que los nodos requieren para
funcionar en caso de que los necesiten.
Del presente roslaunch se deriva la siguiente lista, la cual describe la informacin mencionada
en el prrafo previo:
Los programas spatial, spatial_client, motor_gen_mapa, joy_node, teleop_joy, hokuyo_node

y odom_tf, as como el visor rviz, no llevan parmetros.
Al nodo slam_gmapping se le pasa como argumento a scan, ya que requiere saber el
nombre del tpico que comunica las lecturas obtenidas por el lser. Aunque este programa
tambin necesita conocer la posicin del robot, dada por tf, no es necesario especicar a
este tpico como parmetro, ya que lo busca de forma automtica.
La herramienta record requiere saber la ruta y el nombre del archivo .bag a generar, as
como los tpicos de los que va a obtener la informacin a guardar (ver diagrama 7.2).
Figura 7.2: Elementos suscritos a record en el arreglo generacin de mapa
El archivo donaxi.launch se muestra en la gura 7.3.
Figura 7.3: Archivo original donaxi.launch

7.1. GENERACIN DE MAPA 61
7.1.1.2. Nodos pendientes

En este apartado sern expuestos todos aquellos programas que, debido a sus funciones tan
particulares dentro del arreglo generacin de mapa, no pertenecen a ninguna de las categoras
abordadas en captulos anteriores de la presente tesis.
Los tres nodos del presente arreglo cuya explicacin haba quedado pendiente son:
joy_node
teleop_joy
map_saver
7.1.1.2.1. Nodo joy_node

El programa joy_node se encarga de establecer la comunicacin entre una palanca de mando
joystick)
( y una computadora, ambas conectadas va USB. Adems, proporciona condiciones
para el manejo de errores que puedan presentarse en el intercambio de datos entre ambos dis-
positivos, por lo que este nodo abortar su ejecucin en caso de que alguno ocurra.
La palanca de mando utilizada en el robot Donaxi@HOME, mostrada en la fotografa 7.4
tomada en el laboratorio, cuenta con algunos botones y perillas, sin embargo, slo requerimos
del bastoncillo de control. Por esta razn, este programa, al igual que el nodo spatial explicado
en el captulo 4, nos permite discriminar los ejes de movimiento que no son requeridos. Esto
se logra comunicando, a travs del tpico joy, nicamente las valores de inters, los cuales son
extrados a partir de un arreglo de datos que almacena la informacin proveniente de los sensores
incorporados a dicha palanca de mando.
Figura 7.4: Palanca de mando utilizada por el robot Donaxi@HOME
El arreglo, mencionado en el prrafo previo, es creado por joy_node a partir de cualquier

palanca de mando enlazada va USB a la computadora. Esto supone una ventaja con respecto
a los nodos hokuyo_node y spatial, ya que estos slo funcionan con dispositivos de modelos
especcos.
En la gura 7.5, que es un fragmento de la imagen 7.1, se muestran las ramicaciones del
presente nodo.
Figura 7.5: Nodo joy_node y sus ramicaciones
7.1.1.2.2. Nodo teleop_joy

El programa teleop_joy realiza exclusivamente tres tareas:
1. Se suscribe al tpico pos y recibe los datos discriminados provenientes de la palanca de

mando.
sensor_msgs/Joy,
2. Convierte la informacin adquirida en el paso previo, la cual es del tipo
al formato geometry_msgs/Twist. Dentro de la lgica de ROS, esto equivale a transformar
magnitudes sensoriales a velocidades, un proceso necesario para que posteriormente los
nodos de control, mencionados en el captulo 6, puedan hacer su trabajo.
3. Publica los datos obtenidos a travs del tpico cmd_vel.
En la gura 7.6, que es un fragmento de la imagen 7.1, se muestran las ramicaciones del
presente nodo.
Figura 7.6: Nodo teleop_joy y sus ramicaciones
7.1.1.2.3. Nodo map_saver

A diferencia de los dems nodos pertenecientes al arreglogeneracin de mapa, el denomina-
do map_saver, considerado como un programa independiente para nes prcticos, no se invoca
dentro del roslaunch mencionado anteriormente ni se aprecia en los diagramas de comunicacin
generados usando rqt_graph. La razn a esto se debe a que dicho programa se invoca en el
momento en el que el usuario considera que se tiene un mapa completo del entorno, lo cual
se visualiza a travs de rviz por medio del tpico map proporcionado por el ya mencionado
slam_gmapping.
El nodo map_saver, que pertenece al paquete map_server de la distribucin ROS Groovy,
tiene por objetivo guardar un mapa en el disco duro a partir de un servicio generador de mapas
como, por ejemplo, un programa de SLAM. Lo que hace es generar dos archivos a partir de
dicho mapa: una imagen ( .pgm) y una base de datos (.yaml)[55].
La base de datos con terminacin .yaml proporciona los siguientes datos:
Imagen (image): Ruta al archivo de imagen que contiene los datos de ocupacin, puede
ser absoluta o relativa a la ubicacin del archivo YAML[55]. Dicha imagen es, en la mayora
de los casos, la generada por el map_saver con terminacin .pgm.
Resolucin (resolution): La resolucin del mapa en metros/pixel[55].
Origen (origin): La pose 2-D del pixel inferior izquierdo en el mapa, como (x, y, guiada),
donde la guiada representa a la rotacin en sentido antihorario (guiada = 0 signica
que no hay rotacin). Muchas partes del sistema en la actualidad ignoran este ltimo
parmetro[55], el cual fue explicado en el nodo odom_tf como uno de los parmetros que
denen la orientacin de un robot.
Umbral de ocupacin (occupied_thresh): Los pxeles con una probabilidad de ocu-

pacin mayor al especicado dentro de este umbral se consideran como regiones comple-
tamente ocupadas[55].
Umbral disponible (free_thresh): Los pxeles con una probabilidad de ocupacin

inferior al especicado dentro de este umbral se consideran como regiones completamente
libres[55].
Negacin (negate): Permite invertir las regiones blancas por las opacas o las regiones li-
bres por las ocupadas y vicebersa en el mapa cuando este parmetro es habilitado. La inter-
pretacin de los umbrales anteriormente descritos no se ve afectada por esta condicin[55].
Para que este nodo pueda funcionar necesita suscribirse al tpico map que comunica un tipo
de dato nav_msgs/OccupancyGrid [55].
7.1.1.3. Operacin en conjunto

El robot Donaxi@HOME realiza la tarea de generar su mapa bsicamente al moverse, siguien-
do las instrucciones enviadas a travs de la palanca de mando (joystick), por todo el entorno que
le rodea. De esta manera, el tamao del mapa es controlado completamente por el usuario y,
adems, aunque en primera instancia la precisin del mismo depende de los sensores acoplados
al autmata, el operario puede hacer mltiples lecturas del medio con el que se interacta, lo
cual se traduce en una reduccin signicativa de errores durante la elaboracin de dicho mapa.
En el siguiente algoritmo describe paso a paso el accionar de los programas encargados de
generar un mapa del entorno:
1. Los nodos joy_node y teleop_joy se encargan de transformar las seales provenientes de

la palanca de mando en instrucciones que motor_gen_mapa pueda entender. Al mismo
tiempo, spatial y spatial_client procesan la informacin proveniente del giroscopio y, de
igual forma, la comunican a dicho nodo de control.
2. El programa motor_gen_mapa, en primera instancia le comunica al controlador las ins-

trucciones a ejecutar y este, a su vez, se las reenva a los motores que gobierna; todo esto
se traduce en que el robot realice los movimientos deseados por el usuario. En segunda ins-
tancia, dichos movimientos, los cuales son transformados en datos cuanticables gracias a
los codicadores rotativos y al girscopo, son publicados por medio del tpico cmd_vel2.
3. El nodo odom_tf toma la informacin contenida en cmd_vel2 y la convierte en datos
odomtricos bien denidos, mismos que son comunicados en el tpico odom. Tambin
realiza las funciones de transformacin necesarias para que todas las mediciones aqu
manejadas puedan ser representadas por medio de uno o varios sistemas de referencia,
mismas que son enviadas a travs de tf. Al mismo tiempo, hokuyo_node recibe las lecturas
obtenidas del telmetro lser, las procesa y las publica en el tpico scan.
4. El nodo slam_gmapping realiza un mapa del entorno circundante al robot utilizando para
ello a la informacin contenida en tf y scan y, al mismo tiempo, realiza las funciones de
transformacin pertinentes para que dicho mapa cuente con su propio sistema de referencia
interrelacionado con el del robot. El mapa generado es publicado en el tpico map y su
sistema de referencia en el ya mencionado tf.
5. La herramienta record guarda toda la informacin proveniente de los tpicos scan, map,
tf y odom en el archivogenerando_mapa.bag con ruta al escritorio del ordenador
usado para la presente tesis.
6. Por ltimo, en cuanto el usuario considera que se tiene un mapa completo del medio, se
invoca, usando la terminal, al programa map_saver, mismo que genera una imagen de
dicho mapa y un archivo denominado mapa.yaml con todas sus caractersticas, mismos
que son guardados en el directorio que el usuario especique por medio de la ya mencionada
terminal. Para poder monitorear todo el proceso es altamente recomendable que el visor
rviz se mantenga activo en todo momento, razn por la cual se invoca desde el inicio por
medio de la utilidad roslaunch.
7.1.2. Pruebas realizadas

Poco tiempo despus de que se alcanz el objetivo de generar un mapa del entorno de man-
era exitosa, se realizaron algunas modicaciones en el nodo motor_gen_mapa (descritos en
el captulo 7) con la nalidad de cumplir con dicha encomienda a una mayor velocidad. Esto
ltimo pensando en futuras competencias, tales como el Torneo Mexicano de Robtica y la
Robocup, mismas que le demandan al robot Donaxi@HOME un trazado preciso de un mapa de
sus alrededores en el menor tiempo posible.
La modicacin de la velocidad de ejecucin de los motores establecida en el nodo de control
del presente arreglo, dio lugar a las siguientes dos pruebas de generacin de mapa :
1. Generacin del mapa a velocidad baja.
2. Generacin del mapa a velocidad media.
7.1.2.1. Generacin del mapa a velocidad baja

La generacin del mapa del entorno en esta prueba se realiz a una velocidad relativa de 120
000 cuentas/s, que equivalen a 0.20 m/s, si se aplica el factor de conversin descrito en el captulo
4. Se hace hincapi en la palabra relativa debido al hecho de que, aunque el controlador esta
congurado para enviarle esas velocidades a los motores, debido a la estructura del programa
hay tiempos muertos entre los movimientos que ejecuta el robot.
Las ventajas conseguidas al generar el mapa de est manera son las siguientes:
Alta precisin del mapa.
Control casi absoluto de los movimientos del robot.
Sin embargo, tambin se obtuvieron limitaciones importantes, mismas que derivaron en la

modicacin del nodo motor_gen_mapa y en pruebas posteriores con Donaxi@HOME. He
aqu las ms relevantes:
Demasiado tiempo invertido en generar el mapa.
Manejo tedioso del robot debido a las pausas entre movimientos.
Obtencin de bolsas de datos (.bag) demasiado grandes al usar la herramienta rosbag.
7.1.2.2. Generacin del mapa a velocidad media

La velocidad relativa con la que se gener el mapa en esta prueba fue de 220 000 cuentas/s,
o bien, 0.37 m/s.
Las ventajas conseguidas al generar el mapa de est manera son las siguientes:
Precisin aceptable del mapa.
Control aceptable de los movimientos del robot.
Reduccin del tiempo invertido en la generacin del mapa.

Reduccin de las bolsas de datos (.bag) obtenidas mediante rosbag.
Sin embargo, a pesar de que con el aumento de la velocidad de los motores se obtuvieron
los benecios anteriormente mencionados, subsistieron algunas limitaciones y surgieron otras
nuevas. La siguiente lista muestra las ms relevantes:
El tiempo invertido en generar el mapa sigue siendo considerablemente grande.
El manejo del robot sigue siendo tedioso debido a las pausas entre movimientos.
Los giros del robot producidos a alta velocidad producen vibraciones en el mismo. Esto
provoca que la calidad del mapa se reduzca y la integridad del autmata se vea compro-
metida.
7.1.3. Mejoras implementadas

A partir de estas pruebas se gener una nueva versin del nodo motor_gen_mapa, la cual
permiti disminuir considerablemente varias de las limitantes producidas al generar el mapa. A
continuacin se mencionan estas mejoras.
Se combino la velocidad de giro lenta empleada en la versin del programa usado en la

primera prueba con la velocidad alta de avance utilizada en la segunda, con esto se eliminaron
las vibraciones ocurridas durante las rotaciones del robot y se bajo el tiempo invertido en la
generacin del mapa.
Se sustituy el comando PR por el JG y se restringi el uso del comando ST empleados

en la comunicacin ordenador-controlador (documentados en el captulo 6), adems de que se
calibr la palanca de mando utilizada. Con estas modicaciones, los tiempos muertos existentes
entre cada uno de los movimientos del autmata fueron prcticamente eliminados, adems, se
logr un manejo remoto sobre el mismo incluso superior al que se tena en la primera prueba,
con la ventaja de que su manipulacin resultaba ms cmoda y menos tediosa, sin mencionar el
ahorro signicativo de tiempo producido en consecuencia.
Todo estos cambios se ven reejados en la signicativa reduccin del tamao de las bolsas de
datos (.bag), construidas con la herramienta rosbag, mismas que disminuyeron aproximadamente
un cincuenta por ciento en pruebas posteriores. En otras palabras, tomando en cuenta que el
tamao de estos archivos es proporcional al tiempo de grabacin que guardan, se puede armar
que el tiempo de generacin del mapa se redujo a la mitad.
En resumen, las tres principales mejoras obtenidas en la generacin del mapa fueron las
siguientes:
1. Reduccin del tiempo de generacin en un cincuenta por ciento.
2. ptima precisin del mapa obtenido.
3. Mxima manipulabilidad remota del robot y gran comodidad para el usuario

en el desempeo de esta tarea.
Se hace hincapi en el tercer elemento de la lista, debido a que este ltimo punto equivale a
una innovacin del presente proyecto con respecto a otros robots capaces de generar mapas.
En la gura 7.7 se ilustra la generacin de un mapa realizado en un escenario prefabricado

dentro del Laboratorio de Control y Robtica de la UPAEP. Esta imagen representa el resultado
nal conseguido en las ltimas pruebas realizadas.
Figura 7.7: Proceso nal de generacin de mapa
7.2. Navegacin en el mapa generado

Para que el robot Donaxi@HOME pudiera crear navegar sobre su entorno haciendo uso de un
mapa previamente generado de la mejor manera posible, fue necesaria la realizacin de varias
pruebas y mejoras en torno a las mismas, as como comprender a la perfeccin el funcionamiento
y composicin del arreglo de nodos que hizo que este objetivo fuese posible.
Todo el proceso de navegacin en el mapa generado puede abreviarse en tres fases, men-
cionadas en la introduccin del presente captulo, las cuales sern explicadas a continuacin.
7.2.1. Estructura y funcionamiento del arreglo

El arreglo de nodos navegacin en el mapa generado se compone de doce nodos, como se men-
ciono en el captulo cuatro, y diecinueve tpicos de comunicacin, de los cuales siete son publi-
cados por move_base. Todo esto se ilustra, por medio de rqt_graph, en la gura 7.8, que es una
visualizacin ms completa de la imagen 4.15 presentada con anterioridad.
Figura 7.8: Arreglo de nodos navegacin en el mapa generado con sus respectivos tpicos
En el presente aparatado se abordar lo siguiente:
Los parmetros de ejecucin de cada nodo, contenidos en el roslaunch del arreglo.

La descripcin de los nodos pendientes, es decir, los programas que an no han sido
explicados a los largo de la tesis.
7.2. NAVEGACIN EN EL MAPA GENERADO 67
Figura 7.9: Elementos suscritos a record en el arreglo navegacin en el mapa generado
El funcionamiento detallado del arreglo, o lo que es lo mismo, la operacin en conjunto

de todos los programas implicados en la navegacin sobre un mapa previamente generado.
7.2.1.1. Roslaunch del arreglo

El roslaunch del arreglo navegacin en el mapa generado, llamado ultimate_move_base.launch,
contiene, adems de a once de los doce programas que lo componen incluyendo a la herramienta
record de rosbag, al visor rviz. Este archivo tambin establece los argumentos que los nodos
requieren para funcionar en caso de que los necesiten.
Del presente roslaunch se deriva la siguiente lista, la cual describe la informacin mencionada
en el prrafo previo:
Los programas spatial, spatial_client, hokuyo_node, motor_formula, cancel_goal, odom_tf

y dinamic_goal, as como el visor rviz, no llevan parmetros.
Al nodo map_server se le pasa como parmetro la direccin del archivo .yaml, el cual fue
generado anteriormente por el nodo map_saver.
El nodo amcl requiere de una gran cantidad de argumentos para funcionar, los cuales son
mostrados en la gura 7.10. Para saber ms acerca de dichos parmetros, as como de este
programa en general, se recomienda consultar las referencias [56].
La herramienta record requiere saber la ruta y el nombre del archivo .bag a generar, as
como los tpicos de los que va a obtener la informacin a guardar (ver diagrama 7.9).
El archivo ultimate_move_base.launch se muestra en la gura 7.10.
7.2.1.2. Nodos pendientes

En este apartado sern expuestos todos aquellos programas que, debido a sus funciones tan
particulares dentro del arreglo navegacin en el mapa generado, no pertenecen a ninguna de las
categoras abordadas en captulos anteriores de la presente tesis.
Los cuatro nodos del presente arreglo cuya explicacin haba quedado pendiente son:
Figura 7.10: Archivo original ultimate_move_base.launch

maestro
dinamic_goal
cancel_goal
map_server
7.2.1.2.1. Nodo maestro

El nodo maestro es una interfaz grca diseada para que el usuario del robot Donaxi@HOME
pueda enviarle objetivos de navegacin a este ltimo, o bien, cancelarlos. Es una aplicacin muy
intuitiva, ya que slo posee cinco elementos de entrada: dos botones y tres cheros para intro-
ducir texto. Esto se muestra en la gura 7.11.
Figura 7.11: Interfaz del nodo maestro
Tomando como apoyo a la imagen 7.11, es posible describir las funciones del presente pro-
grama de la siguiente manera:
Al presionar el botn Ubicar, las coordenadas escritas en los cheros de texto (x, y, )
son publicadas a travs del tpico chatter. Los datos aqu comunicados corresponden al
tipo geometry_msgs/Twist, una estructura de seis elementos donde tres de ellos (linear.x
(posicin en x), linear.y (posicin en y) y angular.z (orientacin)) adquieren el valor de
dichos cheros y los restantes (linear.z, angular.x y angular.y ) se quedan en ceros.
Al seleccionar el pulsador Detener, se publica una bandera, en formato de cadena de

texto o std_msgs/String, a travs del tpico alto.
Independientemente del botn presionado, el nodo maestro permanece suscrito al tpico
conrma, a partir del cual recibe informacin acerca del estado de las tareas que le
fueron encomendadas al robot, mismas que fueron desencadenadas a partir de la seleccin
de alguno de los pulsadores anteriormente descritos. Estos mensajes son desplegados en
la parte baja de la interfaz, en una etiqueta nombrada como estado dentro del cdigo del
programa.
Queda evidenciado, de acuerdo a lista mencionada anteriormente, que esta aplicacin no se

encarga directamente del envo y cancelacin de objetivos. Sin embargo, realiza una funcin
de igual importancia permitindole al usuario controlar la ejecucin de estas tareas, por medio
de la activacin de los procesos encargados de desempearlas, los cuales sern explicados ms

adelante.
Cabe mencionar que esta utilidad es activada de manera independiente al roslaunch debido
a que el visor rviz consume demasiados recursos de la tarjeta grca del ordenador, por lo que
la invocacin simultnea de ambos programas ocasiona que uno de los dos procesos se aborte,
sin embargo, en cuanto dicho visor carga por completo sus conguraciones, este programa puede
ser ejecutado sin ningn riesgo.
El programa aqu expuesto, fue enteramente desarrollado en la Laboratorio de Control y
Robtica de la UPAEP para el presente proyecto.
7.2.1.2.2. Nodo dinamic_goal

El nodo dinamic_goal se encarga de enviarle los objetivos de navegacin al planicador de
trayectorias move_base, para que este ltimo los ejecute. La activacin de este proceso es com-
pletamente controlada por el usuario.
El funcionamiento de este programa queda establecido en el siguiente algoritmo:
1. Se inicializan los tpicos de suscripcin alto y chatter, as como el de publicacin con-

rma del presente nodo.
2. El programa espera la recepcin de un mensaje de tipo geometry_msgs/Twist a partir del
tpico chatter del nodo maestro. En cuanto lo recibe, se ejecuta el resto del algoritmo.
3. Espera a que se establezca la comunicacin con move_base publicando el mensaje Es-
tableciendo comunicacin a travs del tpico conrma mientras esto sucede.
4. Una vez que lo anterior se cumple, comunica las coordenadas recibidas del nodo maestro
empleando para ello el cliente de acciones simples expuesto en el captulo 5, no sin antes
obtener el alabeo, el cabeceo y la guiada a partir de la orientacin comunicada por el
nodo maestro utilizando para ello una funcin de transformacin.
5. En cuanto el objetivo es enviado, se activa una espera la cual no termina hasta que el ob-
jetivo sea completado o desechado. Mientras este retardo se encuentra en funcionamiento,
se comunica el mensaje Enviando objetivo a partir del tpico conrma.
6. Se establece una condicional la cual dice lo siguiente:
a) Si el objetivo se cumple, se comunica el mensaje Posicion alcanzada a travs del

tpico conrma. Ntese que los mensajes comunicados por este nodo son del tipo
std_msgs/String, por lo que slo pueden enviarse caracteres ASCII.
b) Si el objetivo falla en completarse, ser comunicado el mensaje No se logro el objetivo
a travs del mismo tpico.
7. Por ltimo, de forma independiente a los procesos activados producto de la recepcin de

datos en el tpicochatter, este nodo enva el mensaje Objetivo cancelado a travs del
tpico conrma cuando recibe cualquier informacin a travs del tpico alto.
Aunque el programa aqu expuesto sufri modicaciones importantes, el cdigo original se
encuentra en Internet [57].
7.2.1.2.3. Nodo cancel_goal

El nodo cancel_goal se encarga de cancelar todos los objetivos de navegacin que hayan si-
do enviados hacia el planicador de trayectorias move_base, o bien, estn siendo ejecutados. La
activacin de este proceso es completamente controlada por el usuario.
Este programa se divide en tres etapas:
1. Se suscribe al tpico alto y en cuanto recibe cualquier cadena de caracteres a partir este
ltimo, se ejecuta el resto del algoritmo.
2. Por medio del cliente de acciones simples, el presente nodo activa la funcin stopTrack-
ingGoal, cuya misin es indicarla a move_base que deje de monitorear los objetivos que
le han sido encomendados.
3. Por ltimo, recurriendo nuevamente al cliente de acciones simples, este programa le solicita
a move_base la cancelacin de todos los objetivos en progreso. Sin la ejecucin del paso
2, esto ltimo es imposible de realizar.
Aunque el presente nodo fue modicado casi en su totalidad, es una variante de otro programa
de ROS disponible en lnea [57].
7.2.1.2.4. Nodo map_server

El nodo map_server, perteneciente al paquete homnimo de ROS, comunica la informacin
perteneciente a un mapa contenido en cualquier parte del disco duro del ordenador a travs de
un servicio de ROS[55].
La versin actual de este programa convierte al valor numrico que tiene cada color dentro
de la imagen del mapa en tres diferentes valores de ocupacin, donde el cero (0) representa a las
regiones libres, el cien (100) a las regiones ocupadas y el uno con signo negativo (-1) al espacio
desconocido[55].
El presente nodo realiza las siguientes acciones de comunicacin a travs de ROS:
Publica mensajes del tipo nav_msgs/MapMetaData a travs del tpico map_metadata

y del tipo nav_msgs/OccupancyGrid a travs del tpico map[55].
Hace uso del servicio static_map para enviar un mapa existente en el disco duro. Esta
informacin es suministrada mediante el formato nav_msgs/GetMap [55].
Para que este programa funcione apropiadamente requiere de un identicador de frame
(frame_id) el cual, en caso de no ser suministrado, ser tomado por defecto como map [55]. Este
parmetro resulta de gran importancia si se desea visualizar los datos aqu generados usando
rviz.
7.2.1.3. Operacin en conjunto

El robot Donaxi@HOME realiza la tarea de navegar sobre su entorno, tomando como referen-
cias a un mapa previamente generado y a un conjunto de sensores, en su mayor parte gracias al
planicador de trayectorias (abordado en el captulo 5). Esto lo hace recibiendo las velocidades
comunicadas por dicho algoritmo, transformndolas y envindoselas a sus respectivos motores.
De esta manera, el nodo move_base carga con el trabajo de tomar las decisiones necesarias para
que el autmata navegue y el nodo motor_formula las convierte en movimiento, es decir, el
usuario slo debe limitarse a enviarle objetivos de navegacin al robot.
En el siguiente algoritmo describe paso a paso el accionar de los programas encargados de
la navegacin de Donaxi@HOME sobre su medio:
1. El origen de la navegacin se halla en el nodo maestro, ya que este publica dos tpicos:
chatter y alto. El primero contiene las coordenadas (x, y, ) que el usuario desea que
el robot adquiera dentro del mapa, mientras que el segundo comunica una bandera para
cancelar objetivos. Adems, el programa aqu expuesto se suscribe al tpico conrma e
imprime los mensajes que all se envan por medio de la interfaz, esto con la nalidad de
monitorear el proceso de navegacin.
2. El nodo dinamic_goal procesa las coordenadas del tpico chatter y las enva por medio
de un servicio a move_base. Tambin es el responsable de originar los mensajes de alerta
publicados en el tpico conrma.
3. Los nodos spatial y spatial_client, as como el programa hokuyo_node, realizan las mismas
funciones que en el arreglo generacin de mapa.
4. El nodo move_base realiza las mismas funciones que los programas joy_node y teleop_joy
en el arreglo anterior, ya que se encarga de enviarle las velocidades, en forma de porcentaje,
al nodo de control de la presente conguracin a travs del tpico cmd_vel. Aunque la
tarea aqu mencionada es el resultado nal de la toma de decisiones que conlleva el proceso
de navegacin, existe todo un arsenal de procesos intermedios antes de llegar a dicha
resultante, mismos que pueden ser visualizados por medio de rviz ; los ms importantes se
muestran en la gura 7.12, fragmento de la gura 7.8, aunque la lista completa de dichos
procesos fue mencionada en el captulo 5.
Figura 7.12: Tpicos importantes publicados por el nodo move_base
5. El programa motor_formula en esencia posee la misma nalidad que el nodo de control

del arreglo anterior, sin embargo, los operaciones que utiliza para adaptar las velocidades
recibidas del tpico cmd_vel hacia los motores son muy diferentes.
6. Los datos que enva el nodo motor_formula a travs del tpico cmd_vel2, as como el
funcionamiento del programa odom_tf son los mismos que en el arreglo generacin de
mapa.
7. El nodo amcl establece una comunicacin bilateral con el tpico tf para ajustar la posicin
del robot con respecto al mundo en funcin de la probabilidad que tiene este de encon-
trarse en un punto determinado. Tambin publica una nube de partculas en el tpico
particlecloud, la cual contiene un estimado de las posibles posiciones en la que podra
estar el autmata, esto puede ser visualizado en rviz como un parmetro para conocer que
tan incierta es la navegacin.
8. Por ltimo, en el nodo record se guarda la informacin publicada por los tpicos tf, scan,
particlecloud, map y los mostrados en la gura 7.12. Esta grabacin se hace para poder
analizar el comportamiento de la navegacin con respecto al mapa y el entorno.
* La cancelacin de objetivos se activa por medio de la interfaz descrita en el paso 1, la cual

comunica esta orden a travs del tpico alto. Los nodos cancel_goal y dinamic_goal
se suscriben a dicho tpico, el primero para ejecutar el servicio de cancelacin hacia
move_base y el segundo para publicar el mensaje Objetivo cancelado en conrma.
El proceso de cancelacin de objetivos se enlista on un asterisco ya que puede ser invocado
por el usuario en cualquier momento, o bien, no ser ejecutado sin que esto afecte a la
navegacin.
7.2.2. Pruebas realizadas

Para que al robot Donaxi@HOME pudiera navegar exitosa y velozmente su entorno utilizando
un mapa de este ltimo como referencia, se realizaron una serie de pruebas a partir de la
modicacin de la velocidad de ejecucin de los motores establecida en el nodo motor_formula.
A continuacin son expuestas las dos pruebas principales llevadas a cabo con el arreglo
navegacin en el mapa generado :
1. Navegacin basada en mapa a velocidad baja.
2. Navegacin basada en mapa a velocidad media.
7.2.2.1. Navegacin basada en mapa a velocidad baja

La navegacin en esta prueba se realiz a velocidades lineales que variaban desde 0.02 m/s
hasta 0.09 m/s y a velocidades angulares que oscilaban desde 3.322 rpm hasta 8.304 rpm.
Dichas variaciones se deben a que, aunque la constante de velocidad establecida en el nodo
motor_formula fue 120 000 cuentas/s o 0.20 m/s, los porcentajes de velocidad comunicados por
move_base a travs de del tpico cmd_vel son bastante cambiantes.
Las ventajas conseguidas al navegar con un mapa de referencia bajo estas condiciones son
las siguientes:
Navegacin bastante precisa.
Mnimos errores de percepcin por parte de los sensores.
Localizacin por medio de amcl en un periodo de tiempo relativamente corto.
Sin embargo, tambin se obtuvieron limitaciones importantes, mismas que derivaron en

nuevas modicaciones en el nodo motor_formula y en pruebas posteriores con el robot Do-
naxi@HOME. He aqu las ms relevantes:
Demasiado tiempo invertido en alcanzar los objetivos de navegacin.
Obtencin de bolsas de datos (.bag) demasiado grandes al usar la herramienta rosbag.
7.2.2.2. Navegacin basada en mapa a velocidad media

Al establecer una constante de velocidad igual a 220 000 cuentas/s o 0.37 m/s en el nodo
motor_formula velocidades lineales que variaban desde 0.04
para esta prueba, se obtuvieron
m/s hasta 0.17 m/s y velocidades angulares que oscilaban desde 6.145 rpm hasta 15.362 rpm.
Las ventajas conseguidas al navegar con un mapa de referencia bajo estas condiciones son
las siguientes:
Navegacin precisa, aunque no tanto como en la prueba anterior.
Disminucin importante del tiempo invertido en alcanzar los objetivos de navegacin.
Disminucin en el tamao de las bolsas de datos (.bag) obtenidas al usar la herramienta

rosbag.
Sin embargo, a pesar de que con el aumento de la velocidad de los motores se obtuvieron los
benecios anteriormente mencionados, tambin se presentaron las siguientes desventajas:
Localizacin por medio de amcl en un periodo de tiempo ms largo.
Breve incremento del nmero de errores de percepcin por parte de los sensores con res-
pecto a los acontecidos en la prueba anterior.
En la gura 7.13 se muestra una prueba de navegacin completa realizada a velocidad media.
Se pueden apreciar todos los elementos que intervienen en esta tarea, desde la interfaz con las
coordenadas ingresadas con el usuario hasta los movimientos (echas naranjas) que realizo el
robot para alcanzar el objetivo deseado, adems de los obstculos (nubes azules) detectados en
el mapa.
Figura 7.13: Prueba completa de navegacin basada en mapa realizada a velocidad a media
7.2.3. Mejoras implementadas

La versin del nodo motor_formula utilizada en la prueba a velocidad media es la que actualmen-
te utiliza el robot Donaxi@HOME. Esto se debe al hecho de que las ventajas de implementar
esta versin del programa con respecto a otras anteriores son mayores que las limitaciones que
acarrea.
A pesar de que las pruebas realizadas en el arreglo navegacin en el mapa generado estn
enfocadas en la modicacin de su nodo de control, las principales mejoras obtenidas se hallan
en los nodos maestro, dinamic_goal y cancel_goal. Esto se debe a que la interfaz con el usuario
junto con sus respectivas ramicaciones, las cuales en conjunto le permiten a este ltimo controlar
completamente y de manera intuitiva el proceso de navegacin, son la parte ms atractiva del
proyecto.
En la siguiente lista se enumeran las mejoras conseguidas al desarrollar e implementar el
mtodo de navegacin descrito en la presente tesis.
1. Interfaz amigable con usuario para enviarle al robot objetivos de navegacin,

la cual adems permite el seguimiento y la cancelacin de los mismos.
2. Navegacin precisa hacia los objetivos en un periodo corto de tiempo.
3. Implementacin de funciones de transformacin en las orientaciones objetivo

enviadas al robot. Esto repercute en un mayor precisin de las mismas y una
mejor interaccin con el usuario.
4. Ajustes en los parmetros del nodo move_base para evitar colisiones entre el robot y los
obstculos de su medio, tanto estticos como dinmicos, en casi cualquier situacin.
Se resaltan los elementos uno y tres de la lista, debido a que estos puntos equivalen a
innovaciones del presente proyecto con respecto a otros sistemas que emplean una navegacin
de este tipo.
Captulo 8
Conclusiones y trabajo a futuro

En el presente captulo, el cual tambin es el ltimo de esta tesis, se expone un resumen de todos
los avances conseguidos en la realizacin de este proyecto, tanto en la generacin del mapa como
en la navegacin del entorno, as como tambin se menciona una lista de los posibles avances
que pueden hacerse en aras de mejorarlo todava ms.
En sintona con lo mencionado en el prrafo previo, a continuacin se mencionan las con-
clusiones extradas de la tesis aqu desarrollada, as como el trabajo a futuro que an falta
por hacer.
8.1. Conclusiones
La elaboracin de la presente tesis implico una inversin considerable de tiempo, dinero y es-
fuerzo, la cual, afortunadamente, rindi frutos importantes, tanto para el laboratorio de Control
y Robtica como para su realizador. La siguiente es una lista de los principales logros obtenidos:
Comprensin de los algoritmos matemticos y fsicos ms usados en el campo

de la robtica. El funcionamiento del ltro de Kalman y los algoritmos de localizacin
y mapeo simultneos (SLAM), de localizacin de Monte Carlo aumentada (AMCL) y
de campos potenciales, mismos que son bastante socorridos en el campo de la robtica,
tuvieron que ser dominados en un nivel importante para su posterior implementacin.
Aprendizaje de nuevas herramientas de software y mejora en habilidades de

programacin. La interaccin de primera mano con el sistema operativo basado en LIN-
UX Ubuntu 12.04 LTS y la plataforma ROS Groovy Galapagos, en conjunto con los lengua-
jes Python y C++, se tradujo en un crecimiento profesional de gran relevancia para el
tesista.
Aprendizaje e implementacin de diversos dispositivos electrnicos. La uti-

lizacin adecuada del telmetro lser, el giroscopio, el controlador DMC, la palanca de
mando y los servomotores con sus codicadores rotativos incorporados al robot Dona-
xi@HOME, represent todo un reto para el realizador de la tesis mismo que, al ser
afrontado exitosamente, derivo en la adquisicin de valiosos conocimientos.
Generacin de un mapa aproximado del entorno. Esta tarea, la cual como ya

fue mencionado es un requisito necesario para desarrollar la tcnica de navegacin aqu
presentada, fue estandarizada con xito permitindole a cualquier usuario ejecutarla con
facilidad, de manera remota y en un periodo corto de tiempo. Adems, el mapa producido
a travs de la interaccin hardware-software se acerca bastante a las medidas reales del
77
78 CAPTULO 8. CONCLUSIONES Y TRABAJO A FUTURO
medio de interaccin del robot, permitindole al operador monitorear su construccin, y

hasta cierto punto su precisin, en todo momento.
La navegacin basada en mapas fue implementada y desarrollada correcta-

mente. Esto implica que el usuario tiene un control total del envo y la cancelacin de
objetivos de navegacin, as como la monitorizacin de los mismos, todo a travs de una
interfaz cmoda e intuitiva. Adems, estos objetivos son alcanzados velozmente y con un
margen de error aceptable, siendo la orientacin nal del robot un elemento que fue espe-
cialmente modicado para cumplir con estas condiciones. Implcito a esto va el hecho de
los obstculos en el medio, ya sean dinmicos o estticos, son evadidos de forma adecuada
por el autmata en escenarios prefabricados.
8.2. Trabajo a futuro

Aunque si bien es cierto que se lograron cosas importantes a lo largo de la presente tesis, la
navegacin en el robot Donaxi@HOME dista de ser perfecta ya que existen entornos en el
mundo real que resultan bastante complejos y, en consecuencia, repercuten en la generacin del
mapa, resolucin de objetivos y la navegacin en general. Esto sin mencionar el hecho de que el
autmata slo puede alcanzar un objetivo a la vez con la conguracin actual de la interfaz y
que la generacin del mapa requiere de un usuario para el proceso.
La lista que se presenta a continuacin, representa una serie de mejoras que an faltan por
hacer y que, en consecuencia, pueden ser realizadas para contribuir con la evolucin del presente
proyecto. He aqu el futuro de la navegacin:
Generacin autnoma de mapa. En el estado actual del proyecto, el robot requiere de

una persona que lo gue sobre su entorno para generar su mapa y, adems, el programa que
guarda dicho mapa debe invocarse manualmente. Hacer que Donaxi@HOME se desplace
sobre su entorno sin necesidad de un control remoto y que, al mismo tiempo, genere su
mapa y elija el momento apropiado para guardarlo representa toda una innovacin no slo
en el proyecto sino dentro de la robtica mvil en general.
Almacenamiento de objetivos en una base de datos. Guardar varios objetivos en

una base de datos para luego mandarlos a llamar simplica enormemente la interfaz y
cimenta las bases del envo de mltiples objetivos hacia el robot, incluso si este se limita
a alcanzarlos uno a uno.
Implementacin del algoritmo de Dijkstra. Si se tiene una base de datos con dos
o ms objetivos, es posible conectarlos entre s para simplicar an ms el proceso de
generacin de trayectorias. El algoritmo de Dijkstra, el cual bastante popular en el mundo
de la robtica, est diseado precisamente para elegir la mejor ruta cuando se tienen varios
puntos enlazados entre s.
Modicacin de los nodos de percepcin. Existen objetos en el entorno, como las

patas de una silla o de una mesa, que debido a sus caractersticas resultan difciles de
evadir incluso con la inacin de obstculos. Modicar los nodos de percepcin para cerrar
supercies particulares o evitarlas es una buena alternativa para mejorar la navegacin.
Incorporar nuevos sensores. El telmetro lser, como cualquier sensor de luz en general,
tiene dicultades para detectar reas demasiado opacas donde la luz simplemente no se
reeja. Debido a que este dispositivo representa la mayor parte de la visin del robot
en general, la incorporacin de sensores diferentes, como sonares o ultrasnicos, con sus
respectivos procesos de software pueden contribuir a la disminucin o incluso la eliminacin
de errores de este tipo.
8.2. TRABAJO A FUTURO 79
Generacin de mapa y navegacin en tres dimensiones. Actualmente, el robot es

capaz de desenvolverse de manera adecuada en entornos de dos dimensiones (2D) y el
mapa que genera es un plano como tal. Implementar hardware y software que le permitan
a Donaxi@HOME la capacidad de generar un mapa en tres dimensiones (3D) y navegar
en un escenario de este tipo es por mucho el desafo ms grande, a mediano plazo, que se
tiene contemplado en la realizacin de este proyecto.
Apndice A
Nodo spatial_client
81
82 APNDICE A. NODO SPATIAL_CLIENT
Archivo: /home/alfredo/catkin_ws/src/gyro2/src/spatial_client.cpp Pgina 1 de 2
#include <ros/ros.h>
#include <stdio.h>
#include <stdlib.h>
#include <sstream>
#include <phidget21.h>
#include <geometry_msgs/Twist.h>
#include "phidgets/spatial_params.h"
//c_str() -> convierte una cadena a un arreglo de caracteres que podemos manejar
//atoi -> Convierte un arreglo de caracteres en un nmero entero
//atof -> convierte un arreglo de caracteres a un nmero real (double)
double vth=0.0,vlineal=0.0;
//string w;
void spatialCallback(const geometry_msgs::Twist::ConstPtr& vel)

{
vth=vel->angular.z;
}
int main(int argc, char** argv)

{
ROS_INFO("Phidgets Spatial client");
ros::init(argc, argv, "spatial_client");
ros::NodeHandle n;
ros::Subscriber spatial_sub = n.subscribe("giro", 10, spatialCallback);
ros::Publisher pos_pub_;
pos_pub_ = n.advertise<geometry_msgs::Twist>("pos", 10);
geometry_msgs::Twist pos;
double th = 0.0;
//variables del filtro de kalman

float derivak0 = 0.0; //deriva en k-1
float gyrok0 = 0.0; //giroscopio k-1
float angulok0 = 0.0; //angulo k-1
float Yderivak0 = 0.0; //deriva en k-1

float Ygyrok0 = 0.0; //giroscopio k-1
float Yangulok0 = 0.0; //angulo k-1
float R=0.03;
float qangulo = 0.001; //data sheet
float qderiva = 0.003;
float Pk0_00 = 1;
float Pk0_01 = 0;
float Pk0_10 = 0;
float Pk0_11 = 1;
//
ros::Time current_time, last_time;

current_time = ros::Time::now();
last_time = ros::Time::now();
ros::Rate r(20.0);
while(n.ok()){
ros::spinOnce(); // check for incoming messages

current_time = ros::Time::now();
double dt = (current_time - last_time).toSec();
double delta_th = vth*dt;
if(abs(vth)>0.5)
{
th += delta_th;
83
Archivo: /home/alfredo/catkin_ws/src/gyro2/src/spatial_client.cpp Pgina 2 de 2
//Kalman
//PREDICCION
//estimacin apriori del sistema ###
float angulo_estk1=angulok0+(dt*gyrok0)-(derivak0*dt);
float deriva_estk1=derivak0;
//actualizacion ##
gyrok0 = vth;
// estimacin apriori de la varianza de Error ###
float Pestk1_00 = Pk0_00-(dt*Pk0_01)-(dt*Pk0_10)+((dt*dt)*Pk0_11)+qangulo;

float Pestk1_01 = Pk0_01-(dt*Pk0_11);
float Pestk1_10 = Pk0_10-(dt*Pk0_11);
float Pestk1_11 = Pk0_11+qderiva;
//CORRECCION ###
//ganancia de Kalman ###
float Kk1_0 = (Pestk1_00)/(Pestk1_00+R);

float Kk1_1 = (Pestk1_10)/(Pestk1_00+R);
//Estimacin a posteori del sistema ###
float angulo_acck1 = th;

float Xk1_0 = (angulo_estk1+(Kk1_0 * (angulo_acck1-angulo_estk1)));
float Xk1_1 =(deriva_estk1+(Kk1_1 * (angulo_acck1-angulo_estk1)));
angulok0 = Xk1_0;
derivak0 = Xk1_1;
//Estimacion posteori de covarianza del error ###
float Pk1_00 = Pestk1_00 - (Pestk1_00*Kk1_0);

//Actualizacion ##
Pk0_00 = Pk1_00;
Pk0_01 = Pk1_01;
Pk0_10 = Pk1_10;
Pk0_11 = Pk1_11;
if(abs(Xk1_0)>15)
{
pos.angular.x=1.0;
th=0.0;
//k=1;
}
else pos.angular.x=0.0;
pos.angular.y=Xk1_0;
pos.angular.z=vth;
pos_pub_.publish(pos);
last_time = current_time;
r.sleep();
}
}
Apndice B
Nodo motor_gen_mapa
85
86 APNDICE B. NODO MOTOR_GEN_MAPA
Archivo: /home/alfredo/catkin_ws/src/motor/src/motor_v1.cpp Pgina 1 de 4
// NODO MOTOR
//
//-------------------------------------------------------------//
//Cabeceras e inclusin de libreras
//---------------------------------------------------------------//
#include <iostream>
#include "mensajes.h"
#include "/home/alfredo/catkin_ws/src/motor/include/dmclnx.h"
//---------------------------------------------------------------//
#define VEL_CONST 120000

#define VEL_CONST2 120000
#define PI 3.1416
//---------------------------------------------------------------//
//Declaracion de variables globales
//---------------------------------------------------------------//
//Agregar la declaracin de las variables de mensajes (envo y recepcin) propias del nodo
double m=0.0, m2=0.0;
int a=0;
long rc = 0; /* Return code */
int fInMotion = 1; /* Motion complete flag */
char buffer[32] = ""; /* Response from controller */
HANDLEDMC hdmc = -1; /* Handle to controller */
CONTROLLERINFO controllerinfo; /* Controller information structure */
string Cad_Motor;
int bandDiag=0;
double Vel_X=0.0, Vel_Y=0.0;
//---------------------------------------------------------------//
//
//
//
//---------------------------------------------------------------//
void PrintError(long rc)
{
ROS_INFO("An error has occurred. Return code = %ld", rc);
//---------------------------------------------------------------//
// Inicializa el Controlador DMC-4040 por puerto Ethernet
// IP = "192.168.1.104"
// IMPORTANTE: Cargar el archivo de calibracin donde estn todos
// los parmetros para los motores y dems.
//---------------------------------------------------------------//
int Inicializa_DMC()
{
ROS_INFO("INICIALIZA DMC ......");
memset(&controllerinfo, '\0', sizeof(controllerinfo));
controllerinfo.cbSize = sizeof(controllerinfo);
controllerinfo.usModelID = MODEL_2100;
controllerinfo.fControllerType = ControllerTypeEthernet;
controllerinfo.ulTimeout = 1000;
controllerinfo.ulDelay = 5;
strcpy(controllerinfo.hardwareinfo.socketinfo.szIPAddress, "192.168.0.30");
controllerinfo.hardwareinfo.socketinfo.fProtocol = EthernetProtocolTCP;
DMCInitLibrary();
/* Open the connection */

87
rc = DMCOpen(&controllerinfo, &hdmc);
ROS_INFO("Abrir el DMC ...... %ld", rc);
if (rc)
{
ROS_INFO("ERROR DMC ......");
PrintError(rc);
return 1;
}
ROS_INFO("DMC OK!! ......");
return -1;
//---------------------------------------------------------------//
int Cierra_DMC()
{
/* Close the connection */

rc = DMCClose(hdmc);
if (rc)
{
PrintError(rc);
return rc;
}
return 0L;
}
void aviso(const geometry_msgs::Twist::ConstPtr& avi)
{
m=avi->angular.x;
m2=avi->angular.z;
}
void VelocidadMotores(const geometry_msgs::Twist::ConstPtr& v)

{
//Funcin para interpretar el mensaje recibido por el maestro

if (v->linear.x>0.1) a=1;
else if(v->linear.x<-0.1) a=2;
else if(v->angular.x> 0.1) a=3;
else if(v->angular.x< -0.1) a=4;
else a=0;
}
//---------------------------------------------------------------//
//Funcin Principal
//---------------------------------------------------------------//
int main(int argc, char **argv)
{
//Inicializacin y configuracin del nodo

ros::init(argc, argv, "motor_node");
ros::NodeHandle nh;
ros::Rate loop_rate(20.0);
//Apertura del canal de recepcin de mensajes del maestro, el nombre cambia dependiendo del nodo
float vely=0.0, velz=0.0, vellin=0.0, velang=0.0;
string comando;
if(!(rc=Inicializa_DMC())) {
ROS_INFO("No Encontr el Controlador = %d", rc);
return -1;
}else {
rc = DMCCommand(hdmc, "RS;", buffer, sizeof(buffer));
usleep(900000);
ROS_INFO("Ejecuto RS .....%d", rc);
88 APNDICE B. NODO MOTOR_GEN_MAPA
rc = DMCCommand(hdmc, "SHXYZ;", buffer, sizeof(buffer));

ROS_INFO("Ejecuto SH .....%d", rc);
if (rc) PrintError(rc); //, "Error SH");
rc = DMCCommand(hdmc, "AC150000,150000;", buffer, sizeof(buffer));
rc = DMCCommand(hdmc, "DC150000,150000;", buffer, sizeof(buffer));
}
comando = "PR,"+convertInt(0)+",-"+convertInt(0);
rc = DMCCommand(hdmc, (char *)comando.c_str(), buffer, sizeof(buffer));
rc = DMCCommand(hdmc, "BG YZ;", buffer, sizeof(buffer));
fInMotion = 1;
Vel_X=0.0;
Vel_Y=0.0;
ros::Publisher vel_pub_;
vel_pub_ = nh.advertise<geometry_msgs::Twist>("cmd_vel2", 100);
geometry_msgs::Twist vel;
ros::Subscriber sub = nh.subscribe<geometry_msgs::Twist>("cmd_vel", 1000, VelocidadMotores);
ros::Subscriber sub2 = nh.subscribe<geometry_msgs::Twist>("pos", 10, aviso);
//Ciclo de trabajo del programa
while (ros::ok())
{
rc = DMCCommand(hdmc, "TV Y;", buffer, sizeof(buffer));
vely=-atoi(buffer)/600000.0;
rc = DMCCommand(hdmc, "TV Z;", buffer, sizeof(buffer));
velz=atoi(buffer)/600000.0;
vellin=(vely+velz)/2.0;
vel.linear.x=vellin;
vel.angular.x= -m2*(PI/180.0);
if(vellin==0.0)
{
switch(a)
{
case 0:
Vel_X=0.0;
Vel_Y=0.0;
comando = "PR,"+convertInt(VEL_CONST*Vel_X)+",-"+convertInt(VEL_CONST*Vel_Y);
break;
case 1:
Vel_X=-1.0;
Vel_Y=-1.0;
comando = "SP,"+convertInt(VEL_CONST2*Vel_X)+",-"+convertInt(VEL_CONST2*Vel_Y);
//rc = DMCCommand(hdmc, "AM YZ;", buffer, sizeof(buffer));
break;
case 2:
Vel_X=1.0;
Vel_Y=1.0;
comando = "SP,"+convertInt(VEL_CONST2*Vel_X)+",-"+convertInt(VEL_CONST2*Vel_Y);
//rc = DMCCommand(hdmc, "AM YZ;", buffer, sizeof(buffer));
break;
case 3:
Vel_X = -1;
Vel_Y = 1;
comando = "JG,"+convertInt(VEL_CONST2*Vel_X)+",-"+convertInt(VEL_CONST2*Vel_Y);
89
break;
case 4:
Vel_X = 1;
Vel_Y = -1;
comando = "JG,"+convertInt(VEL_CONST2*Vel_X)+",-"+convertInt(VEL_CONST2*Vel_Y);
break;
}
}
if(m==1.0) rc = DMCCommand(hdmc, "ST YZ;", buffer, sizeof(buffer));

vel_pub_.publish(vel);
ros::spinOnce();
loop_rate.sleep();
}
Cierra_DMC();
}
Apndice C
Nodo motor_formula
91
92 APNDICE C. NODO MOTOR_FORMULA
// NODO MOTOR
//
//----------------------------------------------------------//
//Cabeceras e inclusin de libreras
//---------------------------------------------------------------//
#include <boost/math/special_functions/round.hpp>
#include <iostream>
#include "mensajes.h"
#include "/home/alfredo/catkin_ws/src/motor/include/dmclnx.h"
//---------------------------------------------------------------//
#define VEL_CONST2 220000

#define PI 3.1416
#define dist_ruedas 0.46
//---------------------------------------------------------------//
//Declaracion de variables globales
//---------------------------------------------------------------//
//Agregar la declaracin de las variables de mensajes (envo y recepcin) propias del nodo
double m2=0.0;
long rc = 0; /* Return code */

int fInMotion = 1; /* Motion complete flag */
char buffer[32] = ""; /* Response from controller */
HANDLEDMC hdmc = -1; /* Handle to controller */
CONTROLLERINFO controllerinfo; /* Controller information structure */
string Cad_Motor;
int bandDiag=0;
int Vel_X=0, Vel_Y=0;
//---------------------------------------------------------------//
//
//
//
//---------------------------------------------------------------//
void PrintError(long rc)
{
ROS_INFO("An error has occurred. Return code = %ld", rc);
//---------------------------------------------------------------//
// Inicializa el Controlador DMC-4040 por puerto Ethernet
// IP = "192.168.1.104"
// IMPORTANTE: Cargar el archivo de calibracin donde estn todos
// los parmetros para los motores y dems.
//---------------------------------------------------------------//
int Inicializa_DMC()
{
ROS_INFO("INICIALIZA DMC ......");
memset(&controllerinfo, '\0', sizeof(controllerinfo));
controllerinfo.cbSize = sizeof(controllerinfo);
controllerinfo.usModelID = MODEL_2100;
controllerinfo.fControllerType = ControllerTypeEthernet;
controllerinfo.ulTimeout = 1000;
controllerinfo.ulDelay = 5;
strcpy(controllerinfo.hardwareinfo.socketinfo.szIPAddress, "192.168.0.30");
controllerinfo.hardwareinfo.socketinfo.fProtocol = EthernetProtocolTCP;
DMCInitLibrary();
93
/* Open the connection */

rc = DMCOpen(&controllerinfo, &hdmc);
ROS_INFO("Abrir el DMC ...... %ld", rc);
if (rc)
{
ROS_INFO("ERROR DMC ......");
PrintError(rc);
return 1;
}
ROS_INFO("DMC OK!! ......");
return -1;
//---------------------------------------------------------------//
int Cierra_DMC()
{
/* Close the connection */

rc = DMCClose(hdmc);
if (rc)
{
PrintError(rc);
return rc;
}
return 0L;
}
void VelocidadMotores(const geometry_msgs::Twist::ConstPtr& vel)

{
float vi=(2*vel->linear.x - dist_ruedas*vel->angular.z)/2.0;
float vd=vi + dist_ruedas*vel->angular.z;
if (vel->linear.x==0.0) {
Vel_X=boost::math::iround(vi*VEL_CONST2);
Vel_Y=boost::math::iround(vd*VEL_CONST2);
}
else{
Vel_X=-1*boost::math::iround(vd*VEL_CONST2);
Vel_Y=-1*boost::math::iround(vi*VEL_CONST2);
}
}
void aviso(const geometry_msgs::Twist::ConstPtr& avi)
{
m2=avi->angular.z;
}
//---------------------------------------------------------------//
//Funcin Principal
//---------------------------------------------------------------//
int main(int argc, char **argv)
{
//Inicializacin y configuracin del nodo

ros::init(argc, argv, "motor_node");
ros::NodeHandle nh;
ros::Rate loop_rate(20.0);
//Apertura del canal de recepcin de mensajes del maestro, el nombre cambia dependiendo del nodo
string comando;
float vely=0.0, velz=0.0, vellin=0.0, velang=0.0;
if(!(rc=Inicializa_DMC())) {
ROS_INFO("No Encontr el Controlador = %ld", rc);
return -1;
94 APNDICE C. NODO MOTOR_FORMULA
}else {
rc = DMCCommand(hdmc, "RS;", buffer, sizeof(buffer));
usleep(900000);
ROS_INFO("Ejecuto RS .....%ld", rc);
rc = DMCCommand(hdmc, "SHXYZ;", buffer, sizeof(buffer));

ROS_INFO("Ejecuto SH .....%ld", rc);
if (rc) PrintError(rc); //, "Error SH");
rc = DMCCommand(hdmc, "AC150000,150000;", buffer, sizeof(buffer));
rc = DMCCommand(hdmc, "DC150000,150000;", buffer, sizeof(buffer));
}
fInMotion = 1;
ros::Publisher vel_pub_;
vel_pub_ = nh.advertise<geometry_msgs::Twist>("cmd_vel2", 100);
geometry_msgs::Twist vel;
ros::Subscriber sub = nh.subscribe<geometry_msgs::Twist>("cmd_vel", 1000, VelocidadMotores);
ros::Subscriber sub2 = nh.subscribe<geometry_msgs::Twist>("pos", 10, aviso);
//Ciclo de trabajo del programa

while (ros::ok())
{
comando = "JG,"+convertInt(Vel_X)+",-"+convertInt(Vel_Y);
rc = DMCCommand(hdmc, "TV Y;", buffer, sizeof(buffer));
vely=-atoi(buffer)/600000.0;
rc = DMCCommand(hdmc, "TV Z;", buffer, sizeof(buffer));
velz=atoi(buffer)/600000.0;
vellin=(vely+velz)/2.0;
vel.linear.x=vellin;
vel.angular.x= -m2*(PI/180.0);
vel_pub_.publish(vel);
ros::spinOnce();
loop_rate.sleep();
}
Cierra_DMC();
}
Apndice D
Nodo maestro
95
96 APNDICE D. NODO MAESTRO
Archivo: /home/alfredo/catkin_ws/src/maestro/scripts/maestro.py Pgina 1 de 1
#!/usr/bin/env python
# -*- coding: cp1252 -*-
import rospy
from geometry_msgs.msg import Twist
from std_msgs.msg import String
import time
import sys, os
from numpy import *
from PyQt4 import QtCore, QtGui
from P1 import Ui_Form
globvar=" "
def callback(data):
global globvar
globvar=str(data.data)
pub = rospy.Publisher('chatter', Twist)

pub2 = rospy.Publisher('alto', String)
rospy.init_node('maestro')
t=Twist()
rospy.Subscriber("confirma", String, callback)
class Principal(QtGui.QWidget):
def temp(self):
self.ventana.estado.setText(globvar)
def d(self):
s="a"
pub2.publish(s)
def __init__ (self):
QtGui.QWidget.__init__(self)
self.ventana = Ui_Form()
self.ventana.setupUi(self)
self.setWindowTitle('Donaxi 2014')
self.setWindowIcon(QtGui.QIcon('sharingan.gif'))
self.connect(self.ventana.ubicar,QtCore.SIGNAL('clicked()'),self.ubicar)
self.connect(self.ventana.detener,QtCore.SIGNAL("clicked()"),self.d)
self.timer = QtCore.QTimer()
QtCore.QObject.connect(self.timer,QtCore.SIGNAL("timeout()"),self.temp)
self.timer.start(1)
def ubicar(self):
t.linear.x=float(self.ventana.L1.text())
t.linear.y=float(self.ventana.L2.text())
t.angular.z=float(self.ventana.L3.text())*(3.1416/180.0)
pub.publish(t)
app = QtGui.QApplication(sys.argv)
ventana = Principal()
ventana.show()
sys.exit(app.exec_())
Apndice E
Nodo dinamic_goal
97
98 APNDICE E. NODO DINAMIC_GOAL
Archivo: /home/alfredo/catkin_ws/src/ngoals/src/dinamic_new_goal.cpp Pgina 1 de 1
#include <move_base_msgs/MoveBaseAction.h>
#include <actionlib/client/simple_action_client.h>
#include <tf/transform_broadcaster.h>
#include <std_msgs/String.h>
ros::Publisher chat;
std_msgs::String msg;
typedef actionlib::SimpleActionClient<move_base_msgs::MoveBaseAction> MoveBaseClient;
void instrucciones(const geometry_msgs::Twist::ConstPtr& ins)

{
MoveBaseClient ac("move_base", true);

//wait for the action server to come up
while(!ac.waitForServer(ros::Duration(5.0))){
msg.data ="Estableciendo comunicacion";
chat.publish(msg);
}
move_base_msgs::MoveBaseGoal goal;
//we'll send a goal to the robot to move 1 meter forward

goal.target_pose.header.frame_id = "base_link";
goal.target_pose.header.stamp = ros::Time::now();
goal.target_pose.pose.position.x = ins->linear.x;
goal.target_pose.pose.position.y = ins->linear.y;
goal.target_pose.pose.orientation = tf::createQuaternionMsgFromYaw(ins->angular.z);
msg.data ="Enviando objetivo";

chat.publish(msg);
ac.sendGoal(goal);
ac.waitForResult();
if(ac.getState() == actionlib::SimpleClientGoalState::SUCCEEDED)
{
msg.data ="Posicion alcanzada";
chat.publish(msg);
}
else{
msg.data ="No se logro el objetivo";
chat.publish(msg);
}
}
void detener(const std_msgs::String::ConstPtr& m)

{
msg.data ="Objetivo cancelado";
chat.publish(msg);
}
int main(int argc, char** argv){

ros::init(argc, argv, "simple_navigation_goals");
ros::NodeHandle n;
chat = n.advertise<std_msgs::String>("confirma", 10);
ros::Subscriber spatial_sub = n.subscribe("chatter", 10, instrucciones);
ros::Subscriber stop = n.subscribe("alto", 10, detener);
ros::spin();
return 0;
}
Apndice F
Nodo cancel_goal
99
100 APNDICE F. NODO CANCEL_GOAL
Archivo: /home/alfredo/catkin_ws/src/ntion_goals/src/cancel_goal.cpp Pgina 1 de 1
#include <move_base_msgs/MoveBaseAction.h>
#include <actionlib/client/simple_action_client.h>
#include <std_msgs/String.h>
typedef actionlib::SimpleActionClient<move_base_msgs::MoveBaseAction> MoveBaseClient;
void detener(const std_msgs::String::ConstPtr& m)

{
MoveBaseClient ac("move_base", true);
while(!ac.waitForServer(ros::Duration(5.0))){
}
ac.stopTrackingGoal();
ac.cancelAllGoals();
}
int main(int argc, char** argv){

ros::init(argc, argv, "cancelling_goals");
ros::NodeHandle n;
ros::Subscriber stop = n.subscribe("alto", 10, detener);
ros::spin();
return 0;
}
Bibliografa
[1] Willow Garage, Inc. (2013, 9 de noviembre). ROS/Introduction, [en lnea]. California, Esta-
dos Unidos de Amrica: Autor. Recuperado el 24 de enero de 2014, de http://wiki.ros.
org/ROS/Introduction
[2] Usuario Suzana_K (2013, 11 de marzo). What is the deference between operating system and
meta-operating system, [en lnea]. Massachusetts, Estados Unidos de Amrica: Je Attwood.
Recuperado el 27 de enero de 2014, de http://stackoverflow.com/questions/15150599/
what-is-the-deference-between-operating-system-and-meta-operating-system
[3] The Open Source Initiative (OSI) (2014, 27 de enero). The Open Source Initiative, [en
lnea]. California, Estados Unidos de Amrica: Autor. Recuperado el 27 de enero de 2014,
de http://opensource.org/
[4] Sun Microsystems, Inc. (1988, junio). RPC: Remote Procedure Call Protocol Specication
Version 2, [en lnea]. California, Estados Unidos de Amrica: Autor. Recuperado el 1 de
junio de 2014, de http://www.faqs.org/rfcs/rfc1057.html
[5] Willow Garage, Inc. (2014, 8 de enero). ROS/Concepts, [en lnea]. California, Estados
Unidos de Amrica: Autor. Recuperado el 26 de enero de 2014, de http://wiki.ros.
org/ROS/Concepts
[6] Willow Garage, Inc. (2013, 8 de diciembre). Distributions, [en lnea]. California, Estados
Unidos de Amrica: Autor. Recuperado el 26 de enero de 2014, de http://wiki.ros.org/
Distributions
[7] Thomas, D. (2012, 22 de septiembre). Specication of package manifest format, [en lnea].
California, Estados Unidos de Amrica: Willow Garage, Inc. Recuperado el 27 de enero de
2014, de http://www.ros.org/reps/rep-0127.html
[8] Fogel, K. (2013). Producing Open Source Software. California, Estados Unidos de Amrica:
O'Reilly Media.
[9] Willow Garage, Inc. (2013, 30 de noviembre). Tickets, [en lnea]. California, Estados Unidos
de Amrica: Autor. Recuperado el 27 de enero de 2014, de http://wiki.ros.org/Tickets
[10] Willow Garage, Inc. (2013, 24 de abril). About Willow Garage, [en lnea]. California, Es-
tados Unidos de Amrica: Autor. Recuperado el 27 de enero de 2014, de http://www.
willowgarage.com/pages/about-us
[11] Conley, K. (2014, 27 de febrero). Roslaunch, [en lnea]. California, Estados Unidos de Amri-
ca: Willow Garage, Inc. Recuperado el 1 de marzo de 2014, de http://wiki.ros.org/
roslaunch
[12] Field, T., Leibs, J. y Bowman, J. (2014, 15 de marzo). Rosbag, [en lnea]. California, Estados
Unidos de Amrica: Willow Garage, Inc. Recuperado el 23 de marzo de 2014, de http:
//wiki.ros.org/rosbag
101
102 BIBLIOGRAFA
[13] Field, T., Leibs, J. y Bowman, J. (2014, 15 de marzo). Rosbag/Commandline, [en lnea].
California, Estados Unidos de Amrica: Willow Garage, Inc. Recuperado el 23 de marzo de
2014, de http://wiki.ros.org/rosbag/Commandline
[14] Thomas, D. (2014, 27 de enero). Rqt_graph, [en lnea]. California, Estados Unidos de Amri-
ca: Willow Garage, Inc. Recuperado el 27 de enero de 2014, de http://wiki.ros.org/rqt_
graph
[15] Hershberger, D., Gossow, D. y Faust, J. (2014, 25 de enero). Rviz, [en lnea]. California,
Estados Unidos de Amrica: Willow Garage. Recuperado el 27 de enero de 2014, de http:
//wiki.ros.org/rviz
[16] Gonzlez Fernndez, V.R., Lpez Cruzado, A. y Cabero Esteban, J.A. (2012, 28 de abril).
Tema 5.5: Robots Mviles, [en lnea]. Valladolid, Espaa: Centro de Formacin del Profe-
sorado e Innovacin Educativa de Valladolid. Recuperado el 26 de diciembre de 2013, de
http://platea.pntic.mec.es/vgonzale/cyr_0708/archivos/_15/Tema_5.5.htm
[17] Navarro Garca, D.A.(2009). Contribucin a la autolocalizacin de robots mviles basada
en la fusin de informacin multisensorial. Trabajo de grado, Doctorado en Automtica e
Informtica Industrial, Universidad Politcnica de Valencia, Valencia, Espaa.
[18] Thrun, S., Burgard, W. y Fox, D. (2006). Probabilistic Robotics. Massachusetts, Estados
Unidos de Amrica: MIT Press.
[19] Oxford Advanced Learner's Dictionary (2010). Nueva York, Estados Unidos de Amrica:
Oxford University Press.
[20] Propioceptivo (2014, 2 de enero). Diccionario de Medicina Vox [en lnea]. Barcelona, Es-
paa: Larousse. Recuperado el 10 de enero de 2014, de http://www.diccionarios.com/
[21] Lpez, D., Gmez-Bravo, F., Cuesta, F. y Ollero, A. (2006). Planicacin de trayectorias con
el algoritmo RRT. Aplicacin a robots no holnomos. Revista Iberoamericana de Automtica
e Informtica Industrial, 3, 56-67.
[22] Gmez-Bravo, F., Cuesta, F. y Ollero, A. (2003). Planicacin de trayectorias en robots
mviles basada en tcnicas de control de sistemas no holnomos. En XXIV Jornadas de
Automtica, Len, Espaa.
[23] Cham, J. (2009). R.O.B.O.T. Comics: Path Planning, [imagen]. Recuperada de http://
www.willowgarage.com/blog/2009/09/04/robot-comics-path-planning
[24] Ogata, K. (2010). Modern Control Engineering (5ta Ed.). Nueva Jersey, Estados Unidos de
Amrica: Pearson Education, Inc.
[25] Ollero Baturone, A. (2001). Robtica. Manipuladores y robots mviles. Barcelona, Espaa:
Marcombo Boixareu Editores.
[26] Silva Ortigoza, R., Garca Snchez, J.R., Barrientos Sotelo, V.R., Molina Vilchis,
M.A., Hernndez Guzmn, V.M. y Silva Ortigoza, G. (2007). Una panormica de
los robots mviles. Telematique [en lnea], Vol. 6,

N 3. Recuperado el 5 de enero
de 2014, dehttp://www.publicaciones.urbe.edu/index.php/telematique/article/
viewArticle/833/2037
[27] Sotelo Iniesta, E.D.(2006). Diseo e Implementacin de los Robots F180 del ITAM. Trabajo
de grado, Ingeniera en Telemtica, Instituto Tecnolgico Autnomo de Mxico, Mxico
D.F., Mxico.
BIBLIOGRAFA 103
[28] Natera G., A.E. (2000). Usos del rayo laser en odontologia restauradora. Primera parte.
Aspectos generales, clasicacion, interrelacion con los tejidos vivos y precauciones en el
uso. Acta Odontolgica Venezolana [en lnea], Vol. 38, N 1. Recuperado el 9 de enero
http://www.actaodontologica.com/ediciones/2000/1/usos_rayo_laser_
de 2014, de
odontologia_restauradora.asp
Design and HCI Applications of a Low-Cost Scanning Laser

[29] Strickon, J.A. (1999).
Rangender. Trabajo de grado, Master of Engineering in Electrical Engineering and Com-
puter Science, Massachusetts Institute of Technology, Massachusetts, Estados Unidos de
Amrica.
[30] Sentek Solutions, Inc. (2012, 2 de septiembre). Scanning Laser Rangenders, [en lnea].
Carolina del Norte, Estados Unidos de Amrica: Autor. Recuperado el 4 de enero de 2014,
de http://senteksolutions.com/products/scanning-laser-rangefinders/
[31] RobotShop (2013). Hokuyo UBG-04LX-F01 (Rapid URG) Scanning Laser

Rangender, [fotografa]. Recuperada de http://www.robotshop.com/en/
hokuyo-ubg-04lx-f01-laser-rangefinder.html
[32] Concepcin Zavaleta, P.F. (2013).Implementacin de un sistema de estabilizacin de c-

mara de dos ejes instalado en un vehculo areo no tripulado. Trabajo de grado, Ingeniera
en Electrnica, Ponticia Universidad Catlica del Per, Lima, Per.
[33] Phidgets, Inc. (2013, 27 de diciembre). 1056_0 - PhidgetSpatial 3/3/3, [en lnea]. Alber-
ta, Canad: Autor. Recuperado el 9 de enero de 2014, de http://www.phidgets.com/
products.php?product_id=1056
[34] Mottram, B. (2011). ROS driver for Phidgets Spatial sensor, [en lnea]. California, Estados
Unidos de Amrica: Willow Garage, Inc. Recuperado el 14 de enero de 2014, de http:
//wiki.ros.org/phidgets
[35] Ramrez Manzanares, A. (2012). Figura 12.- Diagrama a bloques de un ltro de Kalman,
[imagen]. Recuperada de http://www.cimat.mx/~alram/VC/MSAA.htm
[36] Willow Garage, Inc. (2013). A robot that has many relevant frames, [imagen]. Recuperada
de http://wiki.ros.org/robot_state_publisher/Tutorials/Using%20the%20robot%
20state%20publisher%20on%20your%20own%20robot?highlight=%28robot_state_
publisher%29
[37] Willow Garage, Inc. (2013, 18 de octubre). Setting up your robot using tf, [en lnea].
California, Estados Unidos de Amrica: Autor. Recuperado el 15 de enero de 2014, de
http://wiki.ros.org/navigation/Tutorials/RobotSetup/TF
[38] Willow Garage, Inc. (2013, 18 de octubre). Publishing Odometry Information over ROS,
[en lnea]. California, Estados Unidos de Amrica: Autor. Recuperado el 15 de enero de
2014, de http://wiki.ros.org/navigation/Tutorials/RobotSetup/Odom
[39] Gerkey, B. P., Leibs, J. y Gassend, B. (2010). Hokuyo_node, [en lnea]. California, Es-
tados Unidos de Amrica: Willow Garage, Inc. Recuperado el 15 de enero de 2014,
de https://code.ros.org/svn/ros-pkg/stacks/laser_drivers/trunk/hokuyo_node/
src/node/hokuyo_node.cpp
[40] Willow Garage, Inc. (2013, 23 de diciembre). Robot for Research and Innovation, [imagen].
Recuperada de https://www.willowgarage.com/pages/pr2/overview
104 BIBLIOGRAFA
[41] Stachniss, C., Frese, U. y Grisetti, G. (2014, 9 de enero). What is OpenSLAM.org?, [en
lnea]. Freiburg, Alemania: OpenSLAM.org. Recuperado el 11 de febrero de 2014, de https:
//openslam.org/
[42] Hiemstra, P. y Nederveen, A. (2007, 24 de agosto). Monte Carlo Localization, [en lnea].
Groningen, Pases Bajos: Universidad de Groningen (Rijksuniversiteit Groningen). Recu-
perado el 22 de febrero de 2014, de http://citeseerx.ist.psu.edu/viewdoc/summary?
doi=10.1.1.99.7041
[43] Marder-Eppstein, E. (2014, 5 de febrero). Move_base, [en lnea]. California, Estados Unidos
de Amrica: Willow Garage, Inc. Recuperado el 8 de febrero de 2014, de http://wiki.ros.
org/move_base
[44] Osuna-Altamirano, T. , Gonzlez, L.A. y Aguilar L.T. (2010, 25 y 26 de marzo). Tcnica
de Navegacin de Campos Potenciales para un Robot Mvil para la Evasin de Obstculos.
Trabajo presentado en el Encuentro de Investigacin en Ingeniera Elctrica (ENINVIE)
celebrado en la Casa Municipal de la Cultura, Zacatecas, Mxico.
[45] Willow Garage, Inc. (2013, 18 de octubre). Setup and Conguration of the Navigation Stack
on a Robot, [en lnea]. California, Estados Unidos de Amrica: Autor. Recuperado el 13 de
febrero de 2014, de http://wiki.ros.org/navigation/Tutorials/RobotSetup
[46] Chapman, S. J. (2005). Mquinas Elctricas (4ta Ed.). (C. De Robina Cordera). Mxico
D.F., Mxico: McGraw-Hill Interamericana. (Original en ingls, 2005).
[47] Galil Motion Control, Inc. (2013, 24 de agosto). Brushless Servo Motor BLM-N23-50-1000-
B, [en lnea]. California, Estados Unidos de Amrica: Autor. Recuperado el 19 de febrero
de 2014, de http://www.galilmc.com/products/servo-motor.php
[48] NEMA (2013). NEMA Motor Mounting Dimensions, [tabla]. Recuperada de http://www.
numberfactory.com/NEMA%20Motor%20Dimensions.htm
[49] NEMA (2013, 8 de diciembre). About the National Electrical Manufacturers Association,
[en lnea]. Virginia, Estados Unidos de Amrica: Autor. Recuperado el 19 de febrero de
2014, de http://www.nema.org/About/pages/default.aspx
[50] Controller (2013, 5 de octubre). WhatIs.com, [en lnea]. Kansas, Estados Unidos de Amrica:
WhatIs.com. Recuperado el 20 de febrero de 2014, de http://whatis.techtarget.com/
definition/controller
[51] Cogging (2013). Super Glossary, [en lnea]. Arizona, Estados Unidos de Amrica: Su-
per Glossary. Recuperado el 19 de febrero de 2014, de http://es.superglossary.com/
Glosario/Tecnolog%C3%ADa/Motors/Cogging.html
[52] Miller, J. (2010, 1 de octubre). Finding the Index Pulse of an Incremental Encoder,
[en lnea]. Wisconsin, Estados Unidos de Amrica: Quantum Devices, Inc. Recupera-
http://quantumdevices.wordpress.com/2010/10/01/
do el 19 de febrero de 2014, de
finding-the-index-pulse-of-an-incremental-encoder/
[53] Galil Motion Control, Inc. (2014, enero). DMC-40x0 User Manual. Rev. 1.0n, [en lnea].
California, Estados Unidos de Amrica: Autor. Recuperado el 20 de febrero de 2014, de
http://www.galilmc.com/support/manuals.php
[54] Galil Motion Control, Inc. (2011, 11 de noviembre). DMC-40x0 Firmware Command Refer-
ence, [en lnea]. California, Estados Unidos de Amrica: Autor. Recuperado el 21 de febrero
de 2014, de http://www.galilmc.com/support/manuals.php
BIBLIOGRAFA 105
[55] Gerkey, B. P. y Pratkanis, T. (2014, 14 de marzo). Map_server, [en lnea]. California,

Estados Unidos de Amrica: Willow Garage, Inc. Recuperado el 21 de marzo de 2014, de
http://wiki.ros.org/map_server
[56] Gerkey, B. P. (2014, 14 de marzo). AMCL, [en lnea]. California, Estados Unidos de Amrica:
Willow Garage, Inc. Recuperado el 22 de marzo de 2014, de http://wiki.ros.org/amcl
[57] Leigh, A. (2014, 21 de marzo). Sending Goals to the Navigation Stack, [en lnea]. California,
Estados Unidos de Amrica: Willow Garage, Inc. Recuperado el 21 de marzo de 2014, de
http://wiki.ros.org/navigation/Tutorials/SendingSimpleGoals

Tesis Alfredo Alvarado Lepe

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tesis Alfredo Alvarado Lepe

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD POPULAR AUTNOMA DEL

Licenciatura en Ingeniera Binica

1.3. Organizacin de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. ROS: La arquitectura base del robot Donaxi@HOME 5

2.2. Conceptos importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1. Nivel del sistema de archivos . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.2. Nivel de la computacin grca . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.3. Nivel comunitario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Herramientas de ROS utilizadas en el robot Donaxi@HOME . . . . . . . . . . . . 9

2.3.1. Herramienta roslaunch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.2. Paquete rosbag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.3. Aplicacin rqt_graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.4. Visor rviz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1. Localizacin relativa mediante medidas propioceptivas . . . . . . . . . . . 16

3.2.2. Localizacin absoluta basada en hitos o landmarks . . . . . . . . . . . . . 16

3.2.3. Localizacin basada en mapas . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4. Control de movimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.1. Desplazamiento diferencial . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4.2. Desplazamiento omnidireccional . . . . . . . . . . . . . . . . . . . . . . . 20

4. Percepcin y localizacin en el robot Donaxi@HOME 21

5. Planicacin de trayectorias en el robot Donaxi@HOME 41

6. Control de movimiento en el robot Donaxi@HOME 49

8. Conclusiones y trabajo a futuro 77

Apndice A. Nodo spatial_client 81

1.1. Robot de servicio Donaxi@HOME . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1. Conceptos principales a nivel de la computacin grca . . . . . . . . . . . . . . 8

3.1. Fases de localizacin de robots basada en Landmarks . . . . . . . . . . . . . . . . 16

4.1. Telmetro lser utilizado en el robot Donaxi@HOME . . . . . . . . . . . . . . . . 22

5.1. Esquema de funcionamiento del nodo move_base . . . . . . . . . . . . . . . . . . 42

6.1. Motor utilizado en el robot Donaxi@HOME . . . . . . . . . . . . . . . . . . . . . 50

7.1. Arreglo de nodos generacin de mapa con sus respectivos tpicos . . . . . . . . . 59

Motivos, objetivos y organizacin

Uno de los proyectos ms ambiciosos que se est desarrollando actualmente en el Laboratorio

Figura 1.1: Robot de servicio Donaxi@HOME

Donaxi@HOME debe de tener la capacidad de trasladar al usuario con quin interacte

1. Generar un mapa aproximado de su entorno para su desenvolvimiento con ayuda de un

Analizar y comprender el funcionamiento del ltro de Kalman y el algoritmo de SLAM

Analizar y comprender el funcionamiento de los algoritmos de Monte Carlo y de campos

Aprender a utilizar el entorno ROS y perfeccionar su manejo en la medida de la posible,

1.3. Organizacin de la tesis

en cuestiones especcas de su implementacin. A continuacin se expone la estructuracin de

Figura 1.2: Revisin sugerida de captulos

ROS: La arquitectura base del robot

2.1. Ventajas y desventajas de usar ROS

Soporta mltiples lenguajes de programacin lo que le brinda una gran versatilidad de

Posee un marco de prueba de unidad/integracin incorporado llamado ROSTEST, el cual

Es escalable, es decir, funciona apropiadamente en sistemas con tiempos de ejecucin

Se encuentra en proceso de mejora y actualizacin continuamente. Esto se debe a que la

La principal desventaja de ROS, y posiblemente la nica que tiene, es que en la actualidad

2.2. Conceptos importantes

1. A nivel del sistema de archivos.

2. A nivel de la computacin grca.

2.2.1. Nivel del sistema de archivos

Paquetes: Son la unidad principal de la organizacin de software de ROS. Estos pueden

Repositorios: Son colecciones de paquetes que comparten un sistema VCS (Version

2.2.2. Nivel de la computacin grca

Maestro: Proporciona el registro de nombres y bsqueda para el resto de la computacin

Tpicos: Los mensajes se enrutan a travs de un sistema de transporte que se basa en la

Servicios: El modelo de publicacin/suscripcin es un paradigma de comunicacin muy

Figura 2.1: Conceptos principales a nivel de la computacin grca [5]

2.2.3. Nivel comunitario

Distribuciones: Son colecciones de programas con versiones especcas que se pueden

Lista de correos para usuarios: Es el canal principal de comunicacin que informa

2.2.2. Nivel de la computacin grca . . . . . . . . . . . . . . . . . . . . . . . . 7

5. Planicacin de trayectorias en el robot Donaxi@HOME 41

2.1. Conceptos principales a nivel de la computacin grca . . . . . . . . . . . . . . 8

Analizar y comprender el funcionamiento del ltro de Kalman y el algoritmo de SLAM

en cuestiones especcas de su implementacin. A continuacin se expone la estructuracin de

2. A nivel de la computacin grca.

2.2.2. Nivel de la computacin grca

Figura 2.1: Conceptos principales a nivel de la computacin grca [5]

Distribuciones: Son colecciones de programas con versiones especcas que se pueden

2. Disear marcadores de visualizacin. Estos elementos son guras en tres dimensiones,

La clasicacin ms usual de estas Landmarks es la que las divide en naturales y articiales.

Figura 3.2: Planicacin de movimientos tosca pero exitosa de un robot [23]

Como quedo evidenciado anteriormente, debido a la variedad de conguraciones que pueden

Codicador rotatorio o rotativo ( encoder).

El robot Donaxi@HOME utiliza el dispositivo 1056 - PhidgetSpatial 3/3/3 (ver gura

4.1.1.3. Codicador rotativo (encoder)

A n de desarrollar sus estrategias de navegacin, la gran mayora de los vehculos en la robtica

Figura 4.4: Diagrama de funcionamiento de un codicador ptico rotativo [17]

Los nodos de percepcin pertenecientes a la conguracin de programas anteriormente des-

Figura 4.6: Nodo spatial y sus ramicaciones

Figura 4.7: Nodo spatial_client y sus ramicaciones

5. Por ltimo, ya que se obtiene el ngulo de rotacin despus de la etapa de ltrado, al

Figura 4.8: Diagrama de bloques de un ltro de Kalman [35]

Figura 4.9: Nodo motor_gen_mapa y sus ramicaciones

3. Con el n de conocer la velocidad lineal resultante que lleva el autmata, se obtiene el

Figura 4.10: Nodo odom_tf y sus ramicaciones