Dikjtra Start

UNIVERSIDAD AUTNOMA DE MADRID
Escuela Politcnica Superior

Mster en Ingeniera Informtica y Telecomunicacin
Mayor en Sistemas Embebidos y Recongurables
Navegacin de un robot mvil autnomo
en entornos interiores con obstculos
Trabajo Fin de Master
Director:
Dr. Fernando J. Lpez Colino
Tutores:
Dr. Angel de Castro Martn
Dr. Javier Garrido Salas
Marco Pala
Ao 2011-2012
Para mi ta Maria,
mi familia
Pietro, Pina e Beppe
y mi amada Carolina.
iii
ndice general
1 Introduccin general 1
1.1 Estructura de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Arquitectura actual del robot . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Objetivos, motivaciones y alcance . . . . . . . . . . . . . . . . . . . . 4
2 Estado del arte 5
2.1 Algoritmos de bsqueda de recorridos . . . . . . . . . . . . . . . . . . 5
2.1.1 Algoritmo de Dijkstra . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Variaciones heursticas del algoritmo de Dijkstra . . . . . . . . 8
2.2 Navegacin basada en sensores . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Evolucin de los algoritmos de tipo Bug . . . . . . . . . . . . 9
2.2.2 Algoritmo DistBug . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Algoritmo HCTNav 12
3.1 Modelo de entorno interior . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1 Mapa en dos dimensiones . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Grafo disperso no dirigido . . . . . . . . . . . . . . . . . . . . 14
3.1.3 Denicin de las reglas de navegacin . . . . . . . . . . . . . . 15
3.2 Diseo del algoritmo HCTNav . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Estructura de datos de partida . . . . . . . . . . . . . . . . . 16
3.2.2 Estrategia de control de los obstculos . . . . . . . . . . . . . 17
3.2.2.1 Barrido de la trayectoria con lneas de Bresenham . . 18
3.2.2.2 Eleccin del punto de paso . . . . . . . . . . . . . . . 24
3.2.2.3 Rodeo de los obstculos . . . . . . . . . . . . . . . . 28
iv
3.2.3 Construccin del recorrido nal . . . . . . . . . . . . . . . . . 32
3.2.3.1 Grafo de navegacin . . . . . . . . . . . . . . . . . . 34
3.2.3.2 rbol optimizado de los recorridos posibles . . . . . 37
3.3 Comparacin con los otros algoritmos . . . . . . . . . . . . . . . . . . 41
3.3.1 HCTNav vs Dijkstra . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.2 HCTNav vs DistBug . . . . . . . . . . . . . . . . . . . . . . . 45
4 Resultados experimentales 48
4.1 Metodologas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.1 Entorno de desarrollo y de prueba . . . . . . . . . . . . . . . . 48
4.1.2 Conjunto de mapas de prueba . . . . . . . . . . . . . . . . . . 50
4.1.3 Metodologa de simulacin y criterios de comparacin . . . . . 52
4.2 Simulaciones y comparativas . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.1 Consumo de memoria dinmica . . . . . . . . . . . . . . . . . 57
4.2.2 Escalabilidad de los algoritmos . . . . . . . . . . . . . . . . . 62
4.2.3 Velocidad de clculo . . . . . . . . . . . . . . . . . . . . . . . 64
5 Conclusiones 66
5.1 Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Bibliografa 69
Agradecimientos 72
v
ndice de cuadros
3.1 Elementos bsicos que toman parte en el algoritmo. . . . . . . . . . . 17
3.2 Denicin de las lneas de Bresenham y condiciones para determinar
la composicin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Esquema de los puntos de partida y de llegada para construir las
lneas de Bresenham del trayecto. . . . . . . . . . . . . . . . . . . . . 21
3.4 Salida de la rutina de eleccin del punto de paso. . . . . . . . . . . . 27
3.5 Pesos totales de los recorridos devueltos por los tres algoritmos. . . . 45
3.6 Pesos totales de los tres recorridos para el caso de Ilustracin 3.21. . . 47
4.1 Caractersticas funcionales del simulador NavSim. . . . . . . . . . . . 49
4.2 Parmetros bsicos para el lanzamiento de los algoritmos desde consola. 53
4.3 Consumo de memoria dinmica de la familia Dijkstra en los mapas
de prueba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4 Consumo de memoria dinmica del algoritmo HCTNav en los mapas
de prueba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5 Consumo de memoria dinmica de HCTNav y Manhattan en los ma-
pas agrandados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6 Comparacin de los tiempos de ejecucin para todos los caminos po-
sibles en cada mapa. . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
vi
ndice de guras
1.1 Arquitectura simplicada del robot (se destacan las capas lgicas). . . 3
2.1 Estructura de clculo para el algoritmo de Dijkstra (nodos y aristas
describen un grafo disperso no dirigido); el recorrido de coste mnimo
desde el nodo origen hacia el destino forma parte del shortest path tree. 7
2.2 Distancias para las variaciones heursticas del algoritmo de Dijkstra
(algoritmos A
). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Ejemplo de simulaciones comparativas entre los algoritmos Bug2 y
DistBug; en 2.3(c) se aplica a DistBug una estrategia de eleccin
oportuna de la direccin de rodeo [12]. . . . . . . . . . . . . . . . . . 11
3.1 Ejemplo de mapa en 3D para videojuegos RTS. . . . . . . . . . . . . 13
3.2 Modelo de mapa en 2D (en amarillo las posiciones, en rojo los obs-
tculos y en marrn las casillas ocupadas aunque slo parcialmente);
las lneas puntuadas describen las rutas viables de navegacin (aristas). 14
3.3 Esquema de pasillo de la trayectoria entre dos celdas. . . . . . . . . 18
3.4 Direcciones de composicin de las lneas de Bresenham en los cuatro
cuadrantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Ejemplo de lneas de Bresenham entre la Celda[27] y la Celda[124]. . 22
3.6 Ejemplo de los tres grados de cobertura del trayecto. . . . . . . . . . 22
3.7 Deteccin de obstculos en el mapa bottleneck. . . . . . . . . . . . . 23
3.8 Diagrama de ujo de la rutina de deteccin de obstculos. . . . . . . 25
3.9 Esquema de eleccin del punto de paso. . . . . . . . . . . . . . . . . 26
3.10 Diagrama de ujo de la rutina de eleccin del punto de paso. . . . . . 28
3.11 Escenario de partida de la rutina de rodeo del obstculo. . . . . . . . 30
vii
3.12 Ejecuciones de la rutina de rodeo del obstculo (lneas puntuadas). . 32
3.13 Diagrama de ujo de la rutina para rodear un obstculo. . . . . . . . 33
3.14 Engrandecimiento del mapa javi2 al cabo del algoritmo HCTNav (el
grafo de navegacin resultante se representa con lneas puntuadas). 36
3.15 Grafo disperso orientado de navegacin construido por el algoritmo
HCTNav en el mapa javi2. . . . . . . . . . . . . . . . . . . . . . . . 38
3.16 rbol optimizado de los recorridos posibles (dos ramas), generado a
partir del grafo de navegacin devuelto por HCTNav. . . . . . . . . . 39
3.17 Construccin del rbol optimizado de los recorridos posibles. . . . . . 40
3.18 Final de la ejecucin del algoritmo HCTNav en el mapa javi2. . . . 42
3.19 Caso de estudio para el mapa obstacles. . . . . . . . . . . . . . . . 43
3.20 Comparacin entre DistBug y HCTNav en el mismo mapa propuesto
por los autores de DistBug en [12]. . . . . . . . . . . . . . . . . . . . 46
3.21 Caso de estudio [12] del algoritmo DistBug y rplica del mapa en
nuestro simulador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1 Capturas de los distintos elementos del men del simulador NavSim. . 49
4.2 Seis mapas del conjunto de prueba empleados en el simulador NavSim. 51
4.3 Captura del NavSim en su versin C para consola. . . . . . . . . . . . 53
4.4 Captura de la salida de la herramienta msprint de Valgrind (repre-
senta el perl del consumo dinmico de memoria para el lanzamiento
de una bsqueda de recorrido). . . . . . . . . . . . . . . . . . . . . . 55
4.5 Consumo de memoria de la familia Dijkstra, asociado a la Tabla 4.3. . 59
4.6 Grco sobre el consumo de memoria del algoritmo HCTNav asociado
a la Tabla 4.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.7 Comparacin del consumo de memoria entre HCTNav y Manhattan
(basada en las columnas Max (KB) de las respectivas tablas). . . . . 61
4.8 Crecimiento del consumo de memoria en relacin al nmero de casillas
(asociado a la Tabla 4.5). . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.9 Grco sobre los tiempos de ejecucin de los cuatro algoritmos, aso-
ciado a la Tabla 4.6. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
viii
ix
Para desembarcar
en la isla de la sabidura
hay que navegar
en un ocano de aicciones.
[Scrates]
xi
Captulo 1
Introduccin general
La navegacin autnoma de unidades robticas mviles constituye un reto actual
de investigacin en el campo de la Robtica. En respuesta a este inters, se han
desarrollado una gran cantidad de tcnicas de planicacin de ruta (path-planning)
en los ltimos veinte aos.
Los dos enfoques principales (y ms conocidos) son los algoritmos determinsticos,
basados en heursticas, y los probabilsticos, basados en el muestreo mediante sen-
sores. Idealmente, la dimensin del problema (el tamao y la granularidad del mapa
en el que navega el robot) nos permite discriminar entre los dos enfoques y elegir la
opcin ms adapta al caso.
En los mapas pequeos, se preeren los algoritmos determinsticos, puesto que pro-
porcionan una solucin de recorrido de mayor calidad (en trminos de longitud).
En cambio, en caso de mapas extensos, los algoritmos probabilsticos ofrecen unas
mejores prestaciones desde el punto de vista computacional, reduciendo el tiempo
de clculo o la cantidad de memoria necesaria [1].
Entre los algoritmos determinsticos destacan los que se formulan el problema de
navegacin como un grafo disperso. Los nodos representan las posiciones en el es-
pecio de trabajo. Las aristas del grafo modelan las transiciones posibles entre una
posicin y la otra. Con estos algoritmos es fundamental elegir de forma apropiada la
resolucin (o granularidad) del espacio de trabajo, si se quieren minimizar el tiempo
computacional, la longitud del recorrido y el consumo de recursos de memoria. Esta
1
1 Introduccin general
tarea incorpora tanto retos de diseo y automatizacin como vnculos (trade-os)
de disponibilidad de recursos computacionales y energticos.
Proporcionar una inteligencia articial que sea lo suciente exible para que el robot
emule el comportamiento esperado, requiere distintas capas de diseo y prototipado,
tanto en software como en hardware, adems de un gran nmero de simulaciones
y pruebas [2]. Por supuesto, es indispensable un trabajo de investigacin en equipo
para dividir la tarea principal en distintos mdulos, ms accesibles desde un punto
de vista individual. Este trabajo trata de aportar una nueva solucin al proble-
ma de la es parte de en un proyecto ms amplio y de largo plazo que involucra y
ha involucrado distintos investigadores del Human-Computer Technology Laboratory
(HCTLab) de la Escuela Politcnica Superior.
1.1 Estructura de la tesis
Se ha organizado la redaccin del TFdM en cinco captulos, empezando por esta
introduccin, en que se describen las motivaciones de la investigacin y nuestros
principales objetivos, junto con una panormica del proyecto general.
El Captulo 2 est dedicado al estado del arte vigente para las tcnicas de navega-
cin autnoma aplicadas a la robtica, pues se pasarn en resea dos importantes
familias de algoritmos: una de bsqueda de recorridos (familia Dijkstra [3, 4]) y la
otra de navegacin (familia Bug [5, 6]).
Esto nos permitir, una vez descrito nuestro algoritmo en el Captulo 3, argumentar
con ms facilidad las principales similitudes y diferencias con respecto a estas dos
familias. Luego, en el Captulo 4 se presentarn los resultados experimentales, reco-
gidos en nuestro banco de prueba, y se compararn con los resultados de la familia
Dijkstra. En las conclusiones del Captulo 5, nalmente, se discutir el grado de
cumplimiento de la investigacin con los objetivos jados, recalcando las direccio-
nes de mejoras para las futuras aportaciones. En apndice se presentarn los varios
simuladores que completan este proyecto n de master.
2
1.2 Arquitectura actual del robot
El punto de partida para desarrollar el algoritmo de navegacin (path-nding), ob-
jeto de este TFdM, ha sido denir sus vnculos de diseo inicial, pues est pensado
para en un futuro ser implementado en una placa FPGA.
En el estado actual del proyecto general, disponemos ya de una unidad robtica mvil
con motores (dotados de placa de control), capa de comunicacin serie inalmbri-
ca, capa de posicionamiento basada en ultrasonidos [7, 8] y capa de mapeado del
entorno [9]. En la Ilustracin 1.1 se presenta un esquema simplicado de la arquitec-
tura de dicho robot. Las capas representan las posibilidades del robot: desplazarse
sobre orugas, localizarse en un entorno interior (indoor) y construir un mapa del
entorno como conjunto de valores booleanos. Dichos valores representan una rejilla
de casillas libres u ocupadas.
Nuestro algoritmo de navegacin se situara junto a las capas funcionales del robot
para intercambiar informaciones con ellas, puesto que para el clculo de la ruta se
necesitan informaciones sobre la posicin actual del robot en su entorno de despla-
zamiento (Capa de localizacin) y el mapa que lo modela (Capa de mapeado);
una vez elaborada la ruta, se transmitir la secuencia de movimientos oportuna a
los motores (Capa de movimiento) para que pueda empezar la navegacin.
Debido a la naturaleza del mapa de partida, se ha restringido el clculo de las rutas
a los centros geomtricos de cada casilla, de forma que el espacio de posiciones es
Ilustracin 1.1. Arquitectura simplicada del robot (se destacan las capas lgicas).
3
discreto y se reduce al nmero de casillas libres en el mapa. Bajo estas condiciones
iniciales y vnculos de proyecto, hemos dirigido el diseo del algoritmo hacia el cum-
plimiento de una serie de objetivos en trminos de consumo de recursos, velocidad
de proceso, complejidad de realizacin y cercana con la solucin proporcionada por
los algoritmos ptimos (en concreto con el recorrido obtenido por el algoritmo de
Dijkstra).
1.3 Objetivos, motivaciones y alcance
Nos proponemos aadir al robot la capa de planicacin de ruta en presencia de
obstculos, introduciendo un algoritmo ms ligero de los que se encuentran en el
estado del arte clsico (Dijkstra, A
, Floyd-Warshall...) [10].
El objetivo de la investigacin consiste en calcular una ruta ecaz, es decir lo ms
cerca posible del recorrido ptimo (el de longitud mnima), entre dos puntos del
mapa, evitando los obstculos a lo largo del camino.
Como veremos en el Captulo 2, los algoritmos clsicos de bsqueda de recorridos
mnimos son completos y ptimos, pero tambin requieren una carga computacional
excesiva para los recursos limitados de un robot, comparados con los de un cualquier
ordenador de sobremesa [11]. sta es una de las premisas que motivan este TFdM.
En la evaluacin sobre la ecacia del algoritmo HCTNav, se dar ms peso a los
resultados relativos al consumo dinmico de memoria. Hay dos razones principales
para jar este criterio: en primer lugar, en el diseo de los sistemas embebidos
y recongurables, el coste de los recursos de almacenamiento es de importancia
vital, y, en el caso de las memorias, conocer el pico de consumo dinmico facilita
el dimensionamiento del tamao de la memoria. La ocupacin esttica en memoria
del algoritmo se conoce a priori y coincide con el tamao del cdigo ejecutable.
En segundo lugar, no se perdern de vista las prestaciones en termino de velocidad
computacional (o, de forma equivalente, de tiempo de ejecucin) y de longitud del
recorrido nal, comparando nuestros resultados con la familia Dijkstra.
4
Captulo 2
Estado del arte
En este captulo se discutirn los conceptos y las tecnologas que constituyen la base
de conocimientos en la que se apoya nuestro algoritmo. Adems de proporcionar las
oportunas referencias de la literatura cientca, se desglosarn las caractersticas de
dos familias de algoritmos en concreto.
En el Apartado 2.1 se presentar el algoritmo de Dijkstra [3] con sus variantes
heursticas [4], mientras que los algoritmos de la familia Bug [5, 6, 12] se discutirn
en el Apartado 2.2, ya que ambas familias representan las candidatas naturales de
comparacin con nuestros resultados.
2.1 Algoritmos de bsqueda de recorridos
En [13] se discute la ecacia de algunos mtodos de bsqueda de caminos (path-
nding), empezando por los algoritmos de bsqueda ciega (blind search) como el
DFS [14] (Deepth First Search) y el BFS [15] (Breadth First Search).
El primero, dada una estructura rbol, explora sistemticamente los nodos por pro-
fundidad (deepth) y retrocediendo, en el caso de que se encuentre un nodo hoja,
hasta el nodo ms cercano con ramas por explorar (backtracking). El segundo rea-
liza un barrido empezando por el nodo origen y explorando en secuencia todos los
vecinos a un paso de manera recursiva (a dos pasos, a tres pasos,. . .) hasta encontrar
el nodo destino.
5
2 Estado del arte
No se profundizar ms sobre estos dos algoritmos debido a que el DFS no garanti-
za la mejor ruta posible (no es ptimo). Aunque el BFS encuentre el recorrido ms
corto, es superado en prestaciones por el algoritmo de Dijkstra y sus variaciones con
heursticas. sto es debido a que la eleccin del prximo nodo a visitar se mejora
mediante el empleo de una cola de prioridad.
La eleccin de Dijkstra como base de estudio principal para desarrollar el algoritmo
HCTNav se basa en distintas razones: Dijkstra proporciona el resultado ptimo en el
problema del recorrido de coste mnimo, tiene una base matemtica y es fcil de im-
plementar. Otros autores, como en [16], preeren el algoritmo de Floyd-Warshall [17]
para abordar el problema de la bsqueda de recorridos, debido a sus ventajas a la
hora de implementar el paralelismo computacional en las FPGAs.
De todos modos, en el estado actual de la investigacin, nos hemos encontrado con
muchas referencias de empleo de Dijkstra y de sus variaciones heursticas en distin-
tos mbitos de investigacin.
Es el caso de la sntesis de co-procesadores de alta velocidad (high-speed shortest-path
co-processors), discutida en [11] y de las aplicaciones robticas para el transporte
asistido [2], como los sistemas de conduccin en rutas (RGS - Route Guidance Sys-
tems [18]) o los sistemas de transporte inteligente (ITS - Intel ligent Transportation
Systems [19]).
2.1.1 Algoritmo de Dijkstra
El punto clave del algoritmo de Dijkstra, y su principal ventaja con respecto al BFS,
es que en el primero, para el clculo de la ruta, se tienen en cuenta los pesos (weights)
de las aristas E entre los nodos V y la complejidad resultante es O((E+V ) log(V ));
en el segundo no se aplica ningn criterio de prioridad ni se asignan pesos a las aris-
tas, sino que, simplemente, se considera como ptimo el recorrido con menor nmero
de saltos, con una complejidad O(E +V ).
A partir de un grafo no dirigido (vase ms adelante en la Seccin 3.1.2 para su
denicin formal), un nodo origen s (source) y un nodo destino opcional t (target),
el algoritmo de Dijkstra construye el rbol de los recorridos ms cortos (shortest path
tree) desde el nodo origen hacia todos los nodos (incluyendo el nodo destino); en
6
2 Estado del arte
Ilustracin 2.1. Estructura de clculo para el algoritmo de Dijkstra (nodos y aris-
tas describen un grafo disperso no dirigido); el recorrido de coste mnimo desde el
nodo origen hacia el destino forma parte del shortest path tree.
la Ilustracin 2.1 se presenta en forma simplicada un escenario tpico de bsqueda
de recorrido de coste mnimo y los elementos que participan en la elaboracin. El
mecanismo de bsqueda se basa en visitar, en cada iteracin, el nodo ms cercano
al origen. A nivel de implementacin es vlida cualquiera estructura de datos cuya
abstraccin represente el funcionamiento de una cola de prioridad con ndices (in-
dexed priority queue). En cada registro de la cola se almacenan los datos necesarios
para el clculo:
el ndice i del nodo;
la distancia acumulada d
s
hasta el nodo origen (se inicializa con el valor de la
distancia actual para los vecinos a un paso de s y a innito para los dems
nodos);
la bandera (ag) v de visitadoo no visitado.
En cada iteracin, la cola, ordenada por d
s
crecientes, proporciona el ndice i
del
nodo ms cercano tal que valga la condocin de mnimo a continuacin:
d
s
(i
) := mn{d
s
(i) : v(i) = falso}. (2.1)
La nueva arista identicada por i
se aade al listado de aristas de coste mnimo y

se actualiza la cola de prioridad, recalculando el peso de las aristas de los vecinos a
un paso i
n
de i
, de modo que:
d
new
s
(i
n
) := mn{d
old
s
(i
n
), [d
s
(i
) +d
i
(i
n
)]}, i
n
, (2.2)
7
2 Estado del arte
donde d
i
(i
n
) representa la distancia entre i
n
e i
. Dicha cola representa la frontera

de bsqueda (search frontier) y el algoritmo termina cuando ya no quedan nodos
por visitar en ella o se ha alcanzado el nodo destino [3].
2.1.2 Variaciones heursticas del algoritmo de Dijkstra
El nico inconveniente del algoritmo de Dijkstra es que no avanza directamente ha-
cia al destino sino que llega gradualmente, visitando muchos ms nodos de los que
realmente se necesitan. Debido a este problema se han diseado variaciones heu-
rsticas de Dijkstra, donde se usan los valores estimados

d
t
, de la distancia nal
d
t
entre los nodos en la frontera de bsqueda y el nodo destino, para balancear el
criterio de prioridad de la cola con la suma de d
s
y

d
t
.
Estas variaciones funcionan siempre y cuando en la nueva funcin de coste, denida
como H(i) := d
s
(i) +

d
t
(i), la heurstica proporcione una subestimacin de la dis-
tancia nal a la hora de actualizar la frontera de bsqueda, de modo que

d
t
(i) d
t
.
Bajo esta condicin las variaciones del algoritmo de Dijkstra as construidas garan-
tizan alcanzar una solucin ptima. Se suele denominar a esta clase de algoritmos
como A
(A-star) [4]. La diferencia principal entre los A
y el algoritmo de Dijkstra
es que la bsqueda est orientada hacia el destino, ahorrando el clculo de la mayo-
ra de las aristas intiles (todas en el caso de mapas sin obstculos).
Con el propsito de comparar las prestaciones del algoritmo presentado en esta
memoria, en nuestro simulador se han implementado tanto Dijkstra como las dos
variaciones ms empleadas de los A
: en la primera variante, conocida como heu-

rstica eucldea (Euclidean heuristic [20]), la estimacin

d
t
representa la distancia
en lnea recta (eucldea) hasta el destino y necesita la evaluacin de una raz cua-
drada; en la segunda variante, heurstica Manhattan (Manhattan heuristic [21]),
d
t
representa la suma del desplazamiento horizontal y vertical desde el destino en
el plano cartesiano (Ilustracin 2.2). Esta ltima tcnica se usa en entornos en los
que el clculo de races cuadradas enlentecera en exceso: al estar basada slo en
sumas de enteros su empleo constituye un paradigma de clculo de los recorridos en
videojuegos [4].
8
2 Estado del arte
Ilustracin 2.2. Distancias para las variaciones heursticas del algoritmo
de Dijkstra (algoritmos A
).
2.2 Navegacin basada en sensores
Otro enfoque para el problema del path-planning consiste en combinar el muestreo
masivo del entorno de navegacin con unas reglas de rodeo en tiempo real de los
obstculos encontrados a lo largo del trayecto.
La ventaja principal de semejante criterio, conocido en la literatura como navegacin
basada en sensores (sensory-based motion planning), es que puede prescindir del
conocimiento a priori del mapa: el entorno se va descubriendo a medida de que
el robot se desplaza hacia su destino, conforme a la informacin proporcionada en
tiempo real por los sensores de proximidad.
A da de hoy se han desarrollado dos lneas principales de investigacin en este
sentido: una se apoya en la reconstruccin total del entorno [22] mientras que la
otra no tiene traza del mapa y se limita a la informacin local de muestreo [23].
La primera garantiza alcanzar el destino con un grado de convergencia global aunque
requiere una carga considerable para los recursos computacionales de los que dispone
un robot; la segunda tiene la ventaja de ser ms simple de implementar pero no
garantiza una convergencia global hacia el destino sino que el robot puede quedarse
atrapado en un mnimo local.
2.2.1 Evolucin de los algoritmos de tipo Bug
En la familia de algoritmos conocidos como Bug-type algorithms el resultado ob-
tenido con la navegacin basada en sensores y el rodeo de los obstculos se ha
9
2 Estado del arte
demostrado satisfactorio a nivel de ecacia en las aplicaciones prcticas
Diseado por Lumelsky y Stefanof en 1987, Bug [5] ha sido objeto de estudio y de
mejora en muchas publicaciones, por lo que se han producido distintas versiones
como VisBug [5] y Bug2 [6].
En la Seccin 2.2.2 se discutir brevemente el ms reciente de la familia, llamado
DistBug [12], ya que su idea de base para la planicacin de la ruta es parecida al
algoritmo propuesto para este TFdM, aunque el tipo de enfoque es totalmente dis-
tinto: DistBug pertenece a los algoritmos de navegacin basada en sensores mientras
que el HCTNav se basa en un conocimiento a priori del entorno de desplazamiento.
2.2.2 Algoritmo DistBug
El sistema de navegacin implementado con DistBug [12] consiste en dos modos de
movimiento: uno hacia el destino (motion towards the target) y el otro de rodeo de
los obstculos a lo largo del trayecto (obstacle-boundary fol lowing).
El algoritmo conmuta peridicamente entre dichas modalidades hasta que se en-
cuentra el objetivo (o se presenta una condicin de inalcance); durante el rodeo del
obstculo se registra la distancia mnima alcanzada desde el ltimo punto de cho-
que (hit-point) mientras que los sensores de proximidad muestrean el entorno para
valorar el espacio libre alrededor del robot.
Debido a que es preferible minimizar el tiempo de rodeo de los obstculos y maxi-
mizar la navegacin en direccin recta, la condicin de abandono del rodeo (leaving
condition) se adelanta al momento en que se puede garantizar la convergencia global
de la solucin, para evitar mnimos locales.
La ventaja principal de este algoritmo es la facilidad de implementacin, puesto
que se usan los datos en tiempo real de los sensores y no se requiere modelado del
entorno, pero al mismo tiempo se exige una fuerte carga computacional de I/O y
algunas informaciones de tipo global para la localizacin y las mediciones durante
el rodeo [12]. En la Ilustracin 2.3 se ofrece una reproduccin de las simulaciones de
DistBug: como puede verse, con este tipo de enfoque no se necesitan informaciones
sobre el mapa, ni rejilla de referencia pero no se garantiza la solucin ptima (el
recorrido desde S hacia T no es mnimo).
10
2 Estado del arte
(a) Algoritmo Bug2. (b) Algoritmo DistBug.
(c) DistBug con optimizacin de la ruta.
Ilustracin 2.3. Ejemplo de simulaciones comparativas entre los algoritmos
Bug2 y DistBug; en 2.3(c) se aplica a DistBug una estrategia de eleccin
oportuna de la direccin de rodeo [12].
11
Captulo 3
Algoritmo HCTNav
En este captulo se presentarn con ms precisin las caractersticas de nuestro
algoritmo de navegacin. En el Apartado 3.1 se exponen las premisas para denir el
entorno de navegacin, el grafo de navegacin y las reglas de bsqueda del recorrido.
El diseo denitivo del algoritmo se describe en el Apartado 3.2, empezando por
la estructura de datos que se necesita y luego pasando en resea las dos rutinas
operativas de HCTNav y la rutina adicional para la deteccin de obstculos en
una trayectoria. Finalmente, siempre en el mismo apartado, se describe otra rutina
adicional para obtener el recorrido de coste menor desde el grafo de navegacin
(Seccin 3.2.3).
3.1 Modelo de entorno interior
Come se ha discutido en el Apartado 1.2, la naturaleza del mapa de partida para la
bsqueda de recorridos hace que nuestras necesidades se acerquen a las tcnicas em-
pleadas en los videojuegos de estrategia en tiempo real (Real-Time Strategy games
- RTS [13]). Efectivamente, nos hemos inspirado en ellas para el modelado interno
del entorno de navegacin y para encontrar unos algoritmos candidatos con los que
se puedan comparar las prestaciones del algoritmo HCTNav.
En la Ilustracin 3.1 puede apreciarse una captura de un editor de mapa en tres
dimensiones para los videojuegos RTS.
12
3 Algoritmo HCTNav
Ilustracin 3.1. Ejemplo de mapa en 3D para videojuegos RTS.
El concepto de este enfoque, como se destaca en [13], es que el espacio de movimien-
to de una unidad en el mapa se limita a unos nodos interconectados por aristas - es
decir, las posiciones posibles y las rutas viables entre ellas.
La estructura de datos resultante es un grafo disperso no dirigido que cubre el rea
del mapa de forma homognea. A dicha estructura puede aplicarse un algoritmo de
bsqueda de recorrido que tiene en cuenta los obstculos y las distancias cubiertas.
Opcionalmente pueden aadirse distintas etiquetas (o pesos) a las aristas para dis-
criminar, adems de la distancia, otros trminos de comparacin de las rutas poten-
cialmente vlidas, de forma que los pesos reejan las condiciones de las rutas como
el tipo de terreno, la pendiente, etc.
3.1.1 Mapa en dos dimensiones
Nuestro mapa de partida, en dos dimensiones, respecta los conceptos de modelado
RTS adems de casar con la salida producida por la Capa de mapeado del ro-
bot [9]. La matriz de booleanos que se recibe en entrada describe a nivel lgico si
una casilla est libre, pudiendo ser recorrida, o si est ocupada, quedndose fuera
de la posible ruta. Este tipo de modelado del entorno presenta sus ventajas, ya que
puede representarse con facilidad de forma matemtica, garantizando una ocupa-
cin mnima de los recursos de memoria de los que dispone el robot y pudindose
transmitir rpidamente hacia la Capa de navegacin.
13
3 Algoritmo HCTNav
El inconveniente principal consiste en una prdida de granularidad en el modelo del
mapa, en el sentido de que no se representa el perl exacto de los obstculos ni se
conserva la informacin sobre la ocupacin parcial de las casillas, sino que cada ca-
silla se considera completamente libre (cero lgico) o del todo ocupada (uno lgico).
La estructura recin descrita se muestra en la Ilustracin 3.2, en la que se modela
con una matriz de booleanos un mapa de 20 casillas (13 libres y 7 ocupadas); como
convencin, las casillas parcialmente obstruidas por obstculos de forma variada se
consideran ocupadas al cien por cien.
Las coordenadas (x, y) pertenecen al conjunto de nmeros naturales N = {0,1, . . . , (c
r 1)}, donde c representa el nmero de columnas y r el nmero de las, tales que
x [0, c 1] e y [0, r 1]; como convencin, se ja el origen O
xy
del plano
cartesiano en la esquina superior izquierda del mapa y se asocian a cada nodo las
coordenadas del vrtice de la casilla correspondiente.
3.1.2 Grafo disperso no dirigido
Desde un punto de vista matemtico, y siempre rerindonos al esquema de Ilus-
tracin 3.2, los centros geomtricos de cada casilla representan el conjunto de no-
dos V = {n
i
} mientras que las lneas punteadas describen el conjunto de aristas
E = {e
ij
:= {n
i
, n
j
}} del grafo disperso no dirigido, denido por la estructura
G = {V, E}.
Ilustracin 3.2. Modelo de mapa en 2D (en amarillo las posiciones, en rojo los
obstculos y en marrn las casillas ocupadas aunque slo parcialmente); las lneas
puntuadas describen las rutas viables de navegacin (aristas).
14
3 Algoritmo HCTNav
Otra alternativa a la representacin de las aristas del grafo sera mediante una ma-
triz de adyacencia, en la que cada posicin e
ij
{0,1} indica la existencia o no de
la arista para el par de nodos correspondientes.
Nuestra eleccin cae en la primera opcin (conjunto de pares de nodos) y se justica
con su mayor versatilidad en la tarea de reconstruccin del recorrido a partir de un
nodo y visitando las aristas interesadas y almacenadas en un vector [24].
Para evitar una excesiva expansin de la estructura de datos resultante del grafo es
necesario limitar las aristas a tan slo los vecinos a un paso (one-hop neighbors).
Entre los vecinos en ortogonal - en horizontal y en vertical - siempre existe un tra-
yecto viable mientras que en el caso de los vecinos en diagonal se debe comprobar
que las casillas complementarias estn libres.
Abstrayendo las medidas en el mapa y jando ambas dimensiones de una casilla a
la unidad ( u = 1), se puede formular la denicin de las aristas e
ij
y de sus pesos
asociados w de esta manera:
i, j N e
ij
(w) n
i
, n
j
:
n
i
n
j
= 1
(n
i
n
j
=
2) [n(x
i
, y
j
) n(x
j
, y
i
)]
(3.1)
donde n
i
representa un nodo de coordenadas (x
i
, y
i
) y n
i
n
j
=
(x
i
x
j
)
+
(y
i
y
j
)
2
la distancia eucldea entre dos nodos, con w = n
i
n
j
.
3.1.3 Denicin de las reglas de navegacin
El algoritmo HCTNav consiste en una serie de reglas de navegacin, que contemplan
las acciones a emprender para llegar desde un origen hacia un destino en presencia de
obstculos
1
. En el caso de que se encuentre el destino, puede que se hayan producido
distintos caminos potenciales entre los que se podra elegir. Por ello, se aaden dos
reglas para optimizar la construccin del recorrido nal. La Regla 4 se debe a que
los saltos en el mapa pueden ser tan slo ortogonales y diagonales - con pendiente
de 45 - y se pueden producir desvos inesperados en trayectorias sin obstculos.
1
En el mbito del rodeo de obstculos, denimos con codo una casilla en que la direccin de
rodeo cambia de 90 (vase ms adelante en la Subseccinrefsubs:hrodobs.
15
3 Algoritmo HCTNav
Cuadro 1 Reglas de Navegacin
Regla 1. Intentar seguir recto hacia el destino hasta que el trayecto
no est obstruido.
Regla 2. Elegir una posicin de trnsito como destino intermedio
(marcar el punto de paso).
Regla 3. Abrir dos ramas de rodeo del obstculo.
Regla 3.1. Por cada rama, intentar rodear en lnea recta
hasta el primer codo.
Regla 3.2. Marcar cada codo como nuevo punto de paso.
Ejecucin: Iterar las reglas de 1 a 3 para todos los
nuevos puntos de paso encontrados.
Condicin de salida: La rutina acaba cuando no haya
ms puntos de paso para iterar.
Regla 4. Podar los saltos innecesarios.
Regla 5. Elegir el camino de longitud mnima.
Una vez denida a nivel funcional la lgica de comportamiento, se ha procedido
a formalizar las reglas de navegacin en un algoritmo que se pueda implementar
fcilmente a bordo de un robot, por ejemplo en el microprocesador de una FPGA.
3.2 Diseo del algoritmo HCTNav
En este apartado se presentar ms detalladamente el conjunto de reglas previamente
descrito, y, usando fragmentos de pseudocdigo y diagramas de ujo, se discutirn
las distintas fases del algoritmo y los conceptos relacionados con ellas.
3.2.1 Estructura de datos de partida
El contexto inicial del algoritmo, a parte del mapa descrito en la Seccin 3.1.1, se
compone por una serie de entidades lgicas (vectores y listados de elementos) para
almacenar estructuras de datos ms complejas (grafos y rboles), cursores para
16
3 Algoritmo HCTNav
recorrer estas estructuras, contadores, etc. Los elementos bsicos del clculo y sus
propiedades formales se listan en la Tabla 3.1 a continuacin; en ella el nmero de
columnas y de lneas que describen el mapa se denotan respectivamente con c y r.
Elemento Descripcin Propiedades Dominio
Celda[i]
Representa una casilla en el
mapa. Una celda puede ser
libre (i 0) u ocupada
(i < 0).
coordenada x x N : 0 x (c 1)
coordenada y y N : 0 y (r 1)
identicador i i Z : (c r) i (c r 1)
Nodo[i]
Representa una especializacin
de una celda libre en el mapa,
enriquecindola con unas
propiedades adicionales.
Celda[i] i N : 0 i (c 1)
visitado booleano
contorno booleano
puntoDePaso booleano
destinoEncontrado booleano
Obstculo[i] Representa una celda ocupada
(con identicador negativo).
Celda[i] i Z : (c r) i (c 1)
PuntoDePaso[i]
Representa un Nodo adyacente
al contorno de un obstculo.
Puede ser un punto de
apertura de una rama o un
codo encontrado durante el
rodeo.
Nodo[i]
contorno = 1
puntoDePaso = 1
Arista[j i]
Representa un salto entre dos
Nodos (desde la Celda[i] hasta
la Celda[j]), con longitud
asociada.
Celda[i] i N : 0 i (c r 1); i / = j
Celda[j] j N : 0 j (c r 1); j / = i
longitud w w R : w 1
Tabla 3.1. Elementos bsicos que toman parte en el algoritmo.
3.2.2 Estrategia de control de los obstculos
Antes de emprender un salto entre dos nodos se inspecciona la trayectoria a em-
prender para comprobar que no haya obstculos entre ellos.
Esta tarea podra realizarse de distintas maneras, por ejemplo con el auxilio de la
trigonometra o de sistemas de ecuaciones lineales para determinar la interseccin
de la trayectoria con el perl de un obstculo. En este trabajo hemos preferido una
tcnica de barrido de las celdas interesadas, inspirndonos en el algoritmo de la lnea
de Bresenham [25] para elegir correctamente las casillas a comprobar.
La principal razn para esta eleccin es que el algoritmo de Bresenham est pensa-
do para trabajar nicamente con enteros; segundo, las divisiones por 2 que ocurren
en el clculo pueden convertirse fcilmente en desplazamientos aritmticos hacia la
17
3 Algoritmo HCTNav
derecha (arithmetic right shift). En este lugar no nos centraremos en el detalle del
algoritmo de Bresenham sino que presentaremos las adaptaciones introducidas para
completar la tarea de deteccin del obstculo, descrita en la Subseccin 3.2.2.1 a
continuacin.
3.2.2.1 Barrido de la trayectoria con lneas de Bresenham
El pasillo (corridor) denido por la trayectoria entre dos celdas ([i], [j]) que que-
remos inspeccionar, se obtiene proyectando la anchura del robot desde la Celda[i]
hasta la Celda[j] en el entorno de navegacin. Ya que la anchura del robot es menor
que la longitud del lado de una celda, en nuestro modelo de mapa la diagonal misma
constituye el lmite superior de la anchura de proyeccin.
En la Ilustracin 3.3 se presenta un caso simplicado de barrido de la trayectoria:
como se ve en 3.3(a), una nica lnea de Bresenham no cubrira completamente la
inspeccin de todas las casillas en la trayectoria, quedndose una zona de barrido
no cubierta; es necesario incluir tambin aquellas celdas parcialmente interesadas,
es decir, que se encuentran en el borde del pasillo (vase 3.3(b)). Luego, para to-
das las celdas contenidas en el pasillo, se comprueba el identicador para determinar
si la celda es libre (i 0) o representa una casilla ocupada por un obstculo (i < 0)
2
.
(a) Lnea de Bresenham con zonas no cubiertas. (b) Todas las casillas interesadas por el pasillo.
Ilustracin 3.3. Esquema de pasillo de la trayectoria entre dos celdas.
18
3 Algoritmo HCTNav
Para garantizar la cobertura total del pasillo durante la fase de deteccin, hemos
denido una composicin de lneas de Bresenham que puede variar en nmero de 2 a
6, segn el grado de la pendiente asociada a la trayectoria: las dos lneas internas
se evaluarn en todo caso, mientras que las externas de primero y segundo nivel
se aadirn conforme se muestra en la Tabla 3.2 a continuacin.
Lnea de Bresenham Pendiente m Lneas totales
Interna superior
m [0,2]
2
Interna inferior
Externa superior de 1 nivel
m [0,2] m / = {
2
}
4
Externa inferior de 1 nivel
m [0,2] m / = {0,
2
, } m / = {
4
,
3
4
} 6
Tabla 3.2. Denicin de las lneas de Bresenham y condiciones para
determinar la composicin.
Dependiendo de cmo estn posicionadas en el mapa las dos celdas que describen
la trayectoria, el pasillo caer en uno de los cuatro cuadrantes del piano, como se
muestra Ilustracin 3.4 (siendo Celda[i] y Celda[j] respectivamente el punto de par-
tida y de llegada para un trayecto dado). En principio, cada lnea se calcula con un
lanzamiento secuencial del algoritmo de Bresenham, habiendo establecido oportuna-
mente los puntos iniciales y nales en cada ejecucin, conforme con la conguracin
asociada al cuadrante en que cae la trayectoria. El resumen de las conguraciones
de las lneas de Bresenham usadas en nuestro algoritmo, se ofrece en la Tabla 3.3: en
ella se muestran las distintas posibilidades de cada cuadrante, aunque es reconocible
cierto patrn de simetra entre las lneas en las cuatro rotaciones de los cuadrantes.
Cabe destacar que las dos lneas interiores empiezan y acaban en los mismos puntos,
coincidiendo en el punto de partida y de llegada del trayecto.
2
La comprobacin de celda libre u ocupada podra realizarse a nivel de mapa, redeniendo
los mtodos oportunos para que accedan directamente al mapa binario a travs de las coordenadas
de la celda (en lugar de su identicador).
19
3 Algoritmo HCTNav
Ilustracin 3.4. Direcciones de composicin de las lneas de Bresenham en
los cuatro cuadrantes.
Esta duplicidad no sera superua en primera instancia, debido a que en la es-
tructura interna del algoritmo de Bresenham se comprueba una condicin de error.
Dependiendo de si se usa mayor o mayor o igual en la comparacin y de la
distancia que se quiere inspeccionar, la dos lneas calculadas pueden diferir por una
o ms casillas, como se presenta en la Ilustracin 3.5.
En este ejemplo, en que se anticipan algunas capturas de pantalla de nuestro simu-
lador de navegacin, se muestran el pasillo, en 3.5(a), con las celdas interesadas
en la deteccin de obstculos (en verde) y la secuencia de lneas de Bresenham in-
dividuales. Como anticipado, las dos lneas interiores cambian slo por una casilla
en su zona central: la lnea de Bresenham interna superior, en 3.5(b), incluye la
Celda[68], mientras que la interna inferior, en 3.5(c), conmuta en la Celda[83].
Estas variaciones son puntuales y no justican la implementacin de ambas lneas
internas centrales; sin embargo, hemos preferido tratar el caso completo y conservar
las dos lneas redundantes en esta presentacin.
Otra razn que garantiza la robustez de esta rutina, frente a la exclusin de una
de las dos lneas internas, es que las lneas externas de primer nivel cubriran en
todo caso el posible hueco de deteccin. En 3.5(d) y 3.5(e) se presentan las lneas
20
3 Algoritmo HCTNav
Lnea de Bresenham Cuadrante Punto Inicial Punto Final
Interna superior
I, II, III, IV (x
i
, y
i
) (x
j
, y
j
)
Interna inferior
I (x
i
+ 1, y
i
)
(x
j
, y
j
1)
II (x
i
1, y
i
)
III
(x
i
, y
i
1)
(x
j
+ 1, y
j
)
IV (x
j
1, y
j
)
I
(x
i
, y
i
+ 1)
(x
j
1, y
j
)
II (x
j
+ 1, y
j
)
III (x
i
1, y
i
)
(x
j
, y
j
+ 1)
IV (x
i
+ 1, y
i
)
I (x
i
+ 2, y
i
) (x
j
, y
j
1)
II (x
i
1, y
i
) (x
j
, y
j
2)
III (x
i
, y
i
1) (x
j
+ 2, y
j
)
IV (x
i
, y
i
2) (x
j
1, y
j
)
I (x
i
, y
i
+ 1) (x
j
2, y
j
)
II (x
i
+ 2, y
j
) (x
j
+ 1, y
j
)
III (x
i
2, y
i
) (x
j
, y
j
+ 1)
IV (x
i
+ 1, y
i
) (x
j
, y
j
+ 2)
Tabla 3.3. Esquema de los puntos de partida y de llegada para construir las
lneas de Bresenham del trayecto.
externas de primer nivel, mientras que en 3.5(f) y 3.5(g) las externas de segundo
nivel. Resumiendo, con tan slo las lneas centrales se cubrira probablemente el
pasillo pero quedara descubierta una gran zona de celdas interesadas y, por ello,
hemos planteado el clculo de las dos lneas externas de primer nivel. Aun as, du-
rante las pruebas iniciales, nos hemos dado cuenta de que, cuando el pasillo se sale
del rango de pendientes mltiples de
4
, las dos lneas externas no son sucientes,
quedndose unas pocas casillas al descubierto.
En la Ilustracin 3.6 se presentan los distintos grados de cobertura de la trayec-
toria mediante la coloracin de referencia empleada hasta este punto; donde haya
superposicin de lneas se reparten los colores en la misma celda. En 3.6(b) se han
marcado en rojo las celdas interesadas por el pasillo que quedan al margen de la
inspeccin y que justican la introduccin del tercer grado de cobertura, en 3.6(c).
Si se considera un caso en concreto de deteccin de obstculos es an ms evidente
la necesidad de barrer todas las casillas que podran representar un obstculo en el
21
3 Algoritmo HCTNav
(a) Pasillo y celda interesadas. (b) Interna superior. (c) Interna inferior.
(d) Ext. sup. 1 nivel. (e) Ext. inf. 1 nivel. (f) Ext. sup. 2 nivel. (g) Ext. inf. 2 nivel.
Ilustracin 3.5. Ejemplo de lneas de Bresenham entre la Celda[27] y la Celda[124].
(a) Cobertura interna. (b) Cobertura externa de pri-
mer nivel.
(c) Cobertura externa de se-
gundo nivel.
Ilustracin 3.6. Ejemplo de los tres grados de cobertura del trayecto.
22
3 Algoritmo HCTNav
(a) Trayecto a inspeccionar. (b) Conjunto fusionado de lneas.
Ilustracin 3.7. Deteccin de obstculos en el mapa bottleneck.
recorrido. Con el auxilio de uno de los mapas de prueba, en que hemos modelado
un cuello de botella (de ahora en adelante llamaremos este mapa bottleneck), pre-
sentaremos la rutina de deteccin de obstculos en accin (Ilustracin 3.7).
Primero, en 3.7(a), se establecen los dos puntos de partida y de llegada, deniendo
de forma unvoca el pasillo con las celdas a inspeccionar. La rutina empieza cal-
culando individualmente las lneas de Bresenham necesarias y fusionndolas en el
conjunto de cobertura, para remover las redundancias. Trs la ejecuccin, en 3.7(b),
se marcan en rojo los tres obstculos que obstruyen el trayecto. Con respecto a este
escenario, la pseudosalida de la rutina se presenta en el cuadro a continuacin:
Pseudosalida de la rutina de Bresenham para el ejemplo 3.7(b)
1 INTERNAS
2 superior: [60] [46] [35] [-4] [17] [1]
3 inferior: [60] [46] [35] [-4] [17] [1]
4
5 EXTERNAS DE 1 NIVEL
6 superior: [47] [36] [-5] [18] [2]
7 inferior: [59] [45] [-14] [29] [16]
8
9 CONJUNTO: [60] [47] [59] [46] [36] [45] [35] [-5] [-14] [-4]
10 [18] [29] [17] [2] [16] [1]
23
3 Algoritmo HCTNav
Para una pendiente de 45 se requiere slo el segundo grado de cobertura, es decir,
las lneas internas y externas de primer nivel. De igual manera, por pendientes or-
togonales es suciente el primer grado de cobertura y se construyen slo las lneas
interiores (o solo la superior en el caso real).
En el conjunto fusionado de lneas de Bresenham se buscan las celdas con identica-
dor negativo, las que representan los obstculos en el mapa (numerados progresiva-
mente hacia atrs). Entre ellos, se elige el que ms cerca se encuentra con respecto
al punto inicial:
Obstculo[k
] := mn
k
{d
k
(Celda[i])}, k < 0, i 0, (3.2)
donde d
k
(Celda[i]) representa la distancia entre el Obstculo[k
] y la Celda[i] (el
punto de partida de la rutina). En caso de igualdad de d
k
, se puede jar otra condi-
cin de distancia mnima, esta vez hacia la Celda[j]. Si la simetra de los obstculos
vuelve a vericarse, se marcar con k
uno de los dos obstculos candidatos (de

forma indiferente).
El barrido de la trayectoria con lnea de Bresenham determina el punto de choque
actual, es decir, el obstculo que primero obstruira el camino del robot; en el ejem-
plo de Ilustracin 3.7, nuestro k
es representado por el Obstculo[5], aunque nos

valdra tambin el Obstculo[14].
Debido a que los dos son simtricos con respecto a la trayectoria, se igualan tan-
to en d
k
(Celda[68]) como en d
k
(Celda[1]). Si al cabo de la rutina de deteccin de
obstculos no se encuentran obstrucciones, el pasillo est libre y se puede navegar
con seguridad hasta la Celda[j].
En Ilustracin 3.8 se presenta de forma esquemtica el ujo de ejecucin para el
barrido del trayecto; la rutina de deteccin de obstculos traduce en instrucciones
ejecutables la Regla 1 de navegacin (presentada junto con las dems en la Sec-
cin 3.1.3).
3.2.2.2 Eleccin del punto de paso
La informacin sobre el prximo punto de choque devuelta por la rutina ante-
rior es necesaria, en el algoritmo HCTNav, a la hora de codicar en instrucciones
24
3 Algoritmo HCTNav
Ilustracin 3.8. Diagrama de ujo de la rutina de deteccin de obstculos.
25
3 Algoritmo HCTNav
(a) Los cuatro candidatos. (b) Celda devuelta por la rutina.
Ilustracin 3.9. Esquema de eleccin del punto de paso.
la Regla 2 de navegacin. El Obstculo[k
] representa, junto con la posicin actual

(Celda[i]), el dato de entrada de la rutina de eleccin del prximo punto de paso.
Empezando por el Obstculo[k
] se visitan sus cuatro vecinos ortogonales a un paso

(ortogonal one-hop neighbors), para elegir las celdas candidatas.
En la Ilustracin 3.9 hemos marcado las cuatro celdas a visitar con las etiquetas
NORTE, ESTE, SUR y OESTE. Para que una celda pueda elegirse como candi-
dato a punto de paso, debe satisfacer cuatro condiciones compuestas:
1. es un nodo de contorno (contour tile);
2. se encuentra en el mapa (inbound tile) y es una celda libre (free tile);
3. no ha sido visitada (not visited) ni es un punto de paso (not a turning-point);
4. no hay obstculos en el pasillo desde la posicin actual (free corridor).
La segunda condicin garantiza que no se evalen celdas fuera de los lmites del
mapa (en caso de que Obstculo[k
] se encuentre en el borde), excluyendo adems

los obstculos de los candidatos posibles; la tercera averigua que no se evalen du-
plicados, mientras que la cuarta comprueba que el trayecto hasta el candidato sea
navegable (para ello se usa la rutina de deteccin de obstculos discutida en la Sub-
seccin 3.2.2.1).
La primera condicin siempre es vericada para los vecinos a un paso de un obstcu-
lo (los nodos candidatos tienen la bandera contorno = verdadero). Bajo estas
26
3 Algoritmo HCTNav
condiciones, y rerindonos al ejemplo de Ilustracin 3.9, las cuatro casillas de par-
tida que se visitan devuelven las caractersticas presentadas en la Tabla 3.4.
Celda[c] Cond. 1 Cond. 2 Cond. 3 Cond. 4 Distancia celda PuntoDePaso[c
]
NORTE OK OK OK OK

2 NORTE
ESTE OK X - - - -
SUR OK OK OK X - -
OESTE OK OK OK OK 2 -
Tabla 3.4. Salida de la rutina de eleccin del punto de paso.
Todas las casillas visitadas satisfacen la primera condicin pero la Celda[ESTE]
representa un obstculo e incumple la segunda condicin. La Celda[SUR] no cumple
con la cuarta condicin: no se puede navegar hasta all debido al mismo Obstculo[k
]
que obstruye el trayecto desde la Celda[i]. De los dos candidatos que quedan, se elige
el ms cercano a la celda de partida:
PuntoDePaso[c
] := mn
c
{d
c
(Celda[i])}, c 0, i 0, (3.3)
Nodo[c
] puntoDePaso = verdadero
donde d
c
(Celda[i]) representa la distancia entre la Celda[c] y la Celda[i]. En caso de
que d
c
coincida para dos puntos de pasos, puede considerarse la distancia mnima
desde la Celda[j], o marcar de forma indiferente con c
uno de los dos. El esquema

de la rutina para elegir el prximo punto de paso se presenta en Ilustracin 3.10.
Si la evaluacin produce una salida vlida, el Nodo[c
] correspondiente a la Celda[c
]
se marca como puntoDePaso y se guarda en un listado para ser procesado en las
iteraciones a continuacin. Si se devuelve un valor nulo, es decir, si no hay candidatos
para esta iteracin, ningn candidato cumple con las tres condiciones de validez y
representan formalmente callejones sin salida (dead-end).
En esta situacin la rutina de eleccin del punto de paso no devuelve una celda
vlida, informando de que no hay candidatos en la iteracin actual. El control del
algoritmo cierra la rama actual de navegacin y se pasa a una nueva posicin en la
iteracin siguiente (escogiendo un punto de paso del listado de puntos de paso).
27
3 Algoritmo HCTNav
Ilustracin 3.10. Diagrama de ujo de la rutina de eleccin del punto de paso.
3.2.2.3 Rodeo de los obstculos
La Regla 3 de navegacin no se aplica a todas las iteraciones, sino que se dispara
cuando desde la posicin actual no se puede seguir navegando rumbo al destino.
Para abrir las dos ramas en el rbol de los recorridos es necesario disponer de la
informacin de contornode los vecinos a un paso actuales. Por ello se ha denido
28
3 Algoritmo HCTNav
dicha propiedad para cada nodo (vase la Tabla 3.1); se puede navegar bordeando
el obstculo nicamente y slo si el vecino ortogonal a un paso es un Nodo[b] de
contorno y an no ha sido visitado:
Nodo[b] : (contorno = verdadero) (visitado = falso), b 0 (3.4)
La rutina empieza por el punto de paso actual (PuntoDePaso[i]) y acaba cuando se
alcanzan los codos del rodeo. Los codos representan casillas en las que se puede
cambiar direccin de rodeo (formando un ngulo recto con la trayectoria actual).
Cada Nodo[b] del mapa tiene asociada una lista de vecinos de contorno (de ahora
en adelante ListaContorno
b
) de forma que, cuando se emprende la rutina de rodeo,
se inspeccionan recursivamente los nodos en la lista del Nodo[i] y se actualiza su
ListaContorno
i
con los nuevos vecinos heredados de las otras listas, navegando
en direccin de las dos ramas.
En cada nueva visita, primero se comprueba que el pasillo hasta el destino est
libre: en caso armativo, el Nodo[b] actual constituye un codo de destinoEncon-
trado(propiedad de Tabla 3.1) y se marca como punto de paso antes de visitar
el vecino siguiente; de lo contrario la rutina sigue con un bucle interno, esta vez,
visitando los vecinos de ListaContorno
b
. Por cada uno de ellos, se comprueban dos
condiciones:
no ha sido visitado ni es un punto de paso;
no coincide con la posicin actual y no se encuentra en la ListaContorno
i
.
De esta manera se evitan duplicidades y redundancias con respecto a las iteracio-
nes previas. Si es posible navegar desde el Nodo[b] actual hasta la posicin actual
Nodo[i], el cual representa un punto de paso adyacente a un obstculo, entonces este
nuevo vecino heredado se aade a la ListaContorno
i
principal.
De lo contrario, si el trayecto est obstruido, podemos inferir la presencia de un n-
gulo en la rama de rodeo: el Nodo[c] de la iteracin anterior se marca como punto de
paso y se guarda en una lista de puntos de pasos de rodeo (Surround Turning-Point
List) que ser devuelta a la salida de esta rutina. De ahora en adelante, haremos
referencia a dicha lista con el nombre PuntosDePasoRodeo.
29
3 Algoritmo HCTNav
Ilustracin 3.11. Escenario de partida de la rutina de rodeo del obstculo.
La eleccin de dos bucles para visitar las listas de vecinos de contorno se justica
con la necesidad de separar las dos tareas principales: en el bucle externo (extern
while-loop) se comprueba que no haya obstculos rumbo al destino, mientras que en
el bucle interno se comprueba si hemos encontrado un ngulo o, en caso contrario,
se aade el vecino al contorno de la posicin corriente.
En la Ilustracin 3.11 se presenta una iteracin que requiere el rodeo del obstculo.
En este caso, a la salida de la rutina previa de eleccin del punto de paso, el nodo
candidato a ser punto de paso coincide con la posicin actual y puede emprenderse
el rodeo.
Los nodos de contorno, que se han representado en azul claro, constituyen los dos
caminos de rodeo: en cada iteracin de esta rutina, se visita un nodo por rama, hasta
que se encuentre un nodo cuyo pasillo desde el Nodo[i] sea obstruido (esta condi-
cin identica un codo). La salida producida por la rutina de rodeo del obstculo,
para el escenario de partida, se muestra a continuacin:
Pseudosalida de la rutina de rodeo para el ejemplo 3.12
1 ListaContorno(Nodo[i]): Nodo[A], Nodo[1]
2
3 # Iteracin 1
4 - Nodo[A]: visitado = (falso verdadero) [RAGGIUNGIBILE]
5 - ListaContorno(Nodo[A]): Nodo[B], Nodo[i]
6 - Nodo[1]: visitado = (falso verdadero) [RAGGIUNGIBILE]
30
3 Algoritmo HCTNav
7 - ListaContorno(Nodo[1]): Nodo[i], Nodo[2]
8

Actualiza: ListaContorno(Nodo[i]): Nodo[B], Nodo[i], Nodo[i], Nodo[2]
9
10 # Iteracin 2
11 - Nodo[B]: visitado = (falso verdadero) [OBSTRUIDO]
12 Nodo[A] : puntoDePaso = (falso verdadero)
13 - Nodo[i]: visitado = verdadero [IGNORAR]
14 - ListaContorno(Nodo[2]): Nodo[1], Nodo[3]
15

Actualiza: ListaContorno(Nodo[i]): Nodo[1], Nodo[3]
16
17 # Iteracin 3
18 - Nodo[1]: visitado = verdadero [IGNORAR]
19 - Nodo[3]: visitado = (falso verdadero) [OBSTRUIDO]
20 Nodo[2] : puntoDePaso = (falso verdadero)
21
22

Actualiza: ListaContorno(Nodo[i]): {}
Al cabo de la rutina, se devuelve un listado temporal con dos nuevos puntos de paso
de manera que puedan almacenarse en el listado de puntos de paso del algoritmo y
usarse en las siguientes iteraciones de HCTNav. En la Ilustracin 3.12 se muestra
el resultado de mltiples iteraciones que involucran la rutina de rodeo: por ejemplo,
en la rama que empieza en Nodo[2], despus de una nueva iteracin de nuestro
algoritmo, la rutina de eleccin del punto de paso devuelve el Nodo[3]; en la iteracin
siguiente, no se puede marcar un punto paso y el control pasa al rodeo del obstculo,
que devuelve el Nodo[4] con la propiedad de destinoEncontrado = verdadero (no
se detectan obstculos en el trayecto hasta el Nodo[t]).
En la otra rama, la ejecucin es bastante similar: se marca como punto de paso el
Nodo[B] y, en la iteracin siguiente del algoritmo, el rodeo descubre un codo de
destino encontrado en el Nodo[C]. Como para las dems rutinas, se presenta en la
Ilustracin 3.13 un diagrama de ujo que resume la lgica del conjunto de Regla 3 de
navegacin, traducidas en pseudoinstrucciones.
Resumiendo, las tres rutinas principales recin descritas tratan de navegar recto
hacia el destino y, en caso de detectar un obstculo, se marca un punto de paso
intermedio para luego rodear el obstculo hasta que se pueda adelantar. Mediante
31
3 Algoritmo HCTNav
Ilustracin 3.12. Ejecuciones de la rutina de rodeo del obstculo (lneas puntuadas).
la reiteracin de las reglas de navegacin, HCTNav va generando un listado de
puntos de paso (PuntosDePaso) que se retro-alimenta en cada iteracin, llegando a
descubrir el nodo de destino. Si el destino no es alcanzable, debido por ejemplo a la
topografa del mapa, la condicin de salida es que no haya ms ramas de navegacin
por explorar.
3.2.3 Construccin del recorrido nal
Una vez se acabe la bsqueda, el algoritmo HCTNav termina su ejecucin. El paso
siguiente, es generar un camino vlido, si existe, y devolverlo como secuencia de
puntos de paso que permita al robot navegar desde el punto de partida hasta el
destino. La construccin del camino nal puede considerarse realmente como una
rutina de post-procesado auxiliar, pues podra elegirse entre distintas maneras de
abordar su generacin sin alterar el ncleo de ejecucin del algoritmo.
En este trabajo en concreto, presentaremos nuestra estrategia de construccin, que
se basa en recorrer al revs el grafo generado por HCTNav, podar las aristas no
necesarias y calcular el peso total acumulado en cada rama. De esta manera ser
posible distinguir, entre los caminos encontrados, el de peso menor (el mejor re-
corrido pero no necesariamente el ptimo). En las tres subsecciones a continuacin
32
3 Algoritmo HCTNav
Ilustracin 3.13. Diagrama de ujo de la rutina para rodear un obstculo.
33
3 Algoritmo HCTNav
se denir nuestra estrategia ayudndonos con un ejemplo en concreto, en el ma-
pa llamado javi2, donde se quiere calcular la mejor ruta entre el Nodo[89] y el
Nodo[39].
3.2.3.1 Grafo de navegacin
Mientras que el algoritmo va descubriendo nuevos puntos de paso, por cada uno
de ellos se almacena tambin el salto (de ahora en adelante arista o edge) que
referencia el camino desde el punto de paso anterior. Es decir, la posicin actual en
la iteracin, hacia el nuevo punto de paso.
Para las aristas de HCTNav se usar una semntica afn a la que hemos introduci-
do en el contexto de los grafos dispersos (Seccin 3.1.2). Todos los puntos de paso
encontrados referencian una y slo una arista, excepto el nodo destino que tiene
asociada una lista variable de puntos de paso con una o ms aristas, dependiendo
del nmero de ramas de navegacin que terminan en el objetivo.
Por ello, la reconstruccin del rbol de los caminos posibles se realizar en sentido
contrario, empezando por el nodo nal Nodo[t] y siguiendo las varias aristas desde
un punto de paso hacia el anterior hasta alcanzar el punto de partida. El grafo
de navegacin G (path-graph) es una estructura de grano grueso y se construye de
forma iterativa a lo largo de la ejecucin del algoritmo.
Los conjuntos PuntosDePaso (nodos) y Aristas que lo denen, contienen respecti-
vamente todos los puntos de pasos descubiertos y sus saltos asociados:
G = {PuntosDePaso, Aristas} :
PuntoDePaso[i], PuntoDePaso[j] G : i, j / = t Arista[j i] G
Nodo[t] G {Arista[t k
1
], . . . , Arista[t k
n
]} G (3.5)
En la Ilustracin 3.14 se muestra una ejecucin para el caso de estudio javi2,
destacando la generacin del grafo de navegacin. La composicin representa un
engrandecimiento del mapa original (vase Ilustracin 3.16 ms adelante en la Sub-
seccin 3.2.3.2), centrado en la zona de navegacin, en la que se han representado de
forma intuitiva las invocaciones de las tres rutinas principales de nuestro algoritmo:
34
3 Algoritmo HCTNav
barrido de las trayectorias con lneas de Bresenham produce en ambas ru-
tinas operativas (eleccin del punto de paso y rodeo de obstculos) los puntos
de choque y determina los Obstculo[k
] de rodeo, marcados con sus identi-

cadores negativos en rojo (denidos en la subs 3.2.2.1);
eleccin del punto de paso contribuye a formar el conjunto de nodos de trnsito,
marcados con un crculo verde, y las respectivas aristas, representadas como
echas en lnea continua, deniendo parte del grafo de navegacin (la otra
parte se produce durante el rodeo de los obstculos);
rutina de rodeo se emprende cuando el nuevo candidato coincide con la posicin
actual; se visitan los vecinos de contorno, marcados en azul claro, y se completa
el grafo de navegacin con nuevos puntos de paso y con nuevas aristas de rodeo,
marcadas con echas en lnea puntuada.
En nuestro caso de estudio, el Nodo[73] y el Nodo[77] representan un caso especial
de vecinos que tienen una lista de contorno formada por tres nodos, con respecto
al caso normal de uno o dos nodos. Por lo que se reere al Nodo[73], esta situacin
especial produce un punto de choque adicional de rodeo (en el Obstculo[40]) du-
rante el barrido del trayecto entre el Nodo[91] y el Nodo[72].
No obstante, todo funciona normalmente, ya que el Nodo[73] es un codo real y,
adems, en este nodo se sale de la rutina de rodeo con un salto hacia el Nodo[67].
La cosa es distinta para el Nodo[77]: la rutina de rodeo empezada en el Nodo[75],
al explorar el tercer vecino ListaContorno
77
, encuentra un codo fantasma, debi-
do al punto de choque detectado en el Obstculo[42] durante el barrido desde el
Nodo[75] hacia el Nodo[83].
De forma innecesaria, la rutina marca como punto de paso el Nodo[77], dando lugar
a una rama muerta de navegacin y a una iteracin adicional. Como se discutir
en el Seccin 4.1.1, el banco de simulacin montado ad-hoc para HCTNav nos ha
permitido renar el diseo del algoritmo, incorporando en su evolucin las solucio-
nes a los peores casos encontrados (worst-cases) y los parches para manejar los
comportamientos no esperados en ejecucin. Una pseudotraza de salida, que descri-
be las iteraciones del algoritmo llegado a este punto, se proporciona en el marco a
35
3 Algoritmo HCTNav
Ilustracin 3.14. Engrandecimiento del mapa javi2 al cabo del algoritmo HCT-
Nav (el grafo de navegacin resultante se representa con lneas puntuadas).
continuacin (se ha empleado la negrita para los nuevos puntos de pasos y las aristas
descubiertos en cada iteracin). El grafo de navegacin, enriquecido con los detalles
sobre el tipo de salto, los pesos de las aristas y las ramas producidas, se muestra en
la Ilustracin 3.15.
Pseudosalida del algoritmo HCTNav para el ejemplo 3.14
1 [Inicio]: Nodo[89]
2
3 #Iteracin 1
4 [Posicin]: Nodo[89]
5 [Punto de paso]: Nodo[89]
6 [Rodeo]: Nodo[91], (Arista[91 89])
7
8 #Iteracin 2
10 [Punto de paso]: Nodo[91]
12
13 #Iteracin 3
36
3 Algoritmo HCTNav
15 [Punto de paso]: Nodo[67], (Arista[67 73])
16 [Rodeo]: Nodo[58], (Arista[58 67]) {Inicio Rama 1}
17 [Rodeo]: Nodo[74], (Arista[74 58]) {Inicio Rama 2}
18
19 #Iteracin 4 {Rama 1}
23 [Destino Encontrado]: Nodo[39], (Arista[39 36]) {Fin Rama 1}
24
25 #Iteracin 5 {Rama 2}
28 [Rodeo]: Nodo[77], (Arista[77 75]) {Inicio Rama 2.1}
29 [Rodeo]: Nodo[79], (Arista[79 75]) {Inicio Rama 2.2}
30 [Destino Encontrado]: Nodo[39], (Arista[39 79]) {Fin Rama 2.2}
31
32 #Iteracin 6 {Rama 2.1}
34 [Punto de paso]: Nodo[77] /
(nada que hacer. . . )
/
35 [Rama muerta]: {Fin Rama 2.1}
3.2.3.2 rbol optimizado de los recorridos posibles
Para obtener el recorrido de menor coste, desde el grafo de navegacin se extrae un
rbol con los recorridos posibles. Esta tarea se realiza mediante un ltrado de las
aristas, con el n de optimizar la ruta donde sea oportuno. Como se ha adelantado
en la Subseccin 3.2.3.1, se proceder empezando por el nodo destino y avanzando
hacia el origen.
Debido a la generalizacin de las reglas de navegacin, pueden ocurrir ciertas re-
dundancias entre las aristas del grafo resultante, que hemos catalogado en dos
categoras principales: (1) dos o ms aristas cuyos puntos de paso yacen en la misma
direccin y (2) dos aristas cuyas direcciones forman ngulos innecesarios que pueden
corregirse.
37
3 Algoritmo HCTNav
Ilustracin 3.15. Grafo disperso orientado de navegacin construido por el algo-
ritmo HCTNav en el mapa javi2.
Con respecto al caso de estudio de Ilustracin 3.16, nuestra rutina de optimizacin
identicar las siguientes redundancias:
la Arista[79 75] y Arista[75 74], que ejemplican las del primer tipo,
se remplazan con la nueva Arista[79 74] de peso w = 5; ms adelante se
explicar por qu el Nodo[73] queda fuera de la poda aun estando en la misma
trayectoria de los nodos [74] y [75]; nuestra rutina excluye de forma implcita
la Arista[77 75], que pertenece a la Rama 2.2 (muerta) , gracias a que
se recorre el grafo al revs y nunca se llega a visitar el Nodo[77] (el Nodo[79]
referencia unvocamente al Nodo[75]);
la Arista[36 60] y Arista[60 58], que constituyen un ejemplo de codo
no deseado, se remplazan con la nueva Arista[36 58] de peso w = 2
2;
la Arista[58 67] y Arista[67 73], redundancia del segundo tipo, se
remplazan con la nueva Arista[58 73] de peso w =
5;
la Arista[74 67] y Arista[67 73], redundancia del segundo tipo, se
remplazan con la nueva Arista[74 73] de peso w = 1; este codo es la razn
38
3 Algoritmo HCTNav
(a) Escenario de partida. (b) Resultado de la simulacin.
Ilustracin 3.16. rbol optimizado de los recorridos posibles (dos ramas), generado
a partir del grafo de navegacin devuelto por HCTNav.
por la que se interrumpe la primera podadura en [74] y la rutina, al primer
nivel de ltrado, no consigue optimizar la redundancia de la Arista[74 73]
con la Arista[73 79].
Ahora se ve ms clara la ventaja al procesar el grafo de navegacin en sentido contra-
rio a su orientacin: el nmero de recorridos nales entre los que elegir se restringe al
nmero efectivo de aristas que llegan al destino (en este ejemplo la Arista[39 79]
y Arista[39 36]; esto hace que toda bifurcacin redundante (que termine en una
rama muerta), se ignora de forma implcita sin ningn clculo adicional (en este
caso, la Arista[77 75] de la Rama 2.2).
Tambin se ha destacado el inconveniente principal de la estrategia: el Nodo[73],
queda fuera del primer ltrado, debido a que desde el Nodo[74] se ira primero al
Nodo[67], interrumpiendo la podadura desde el Nodo[79] y empezando una nueva po-
dadura en el codo innecesario formado por la Arista[74 67] y la Arista[67 73].
En la Ilustracin 3.17, se presenta la secuencia completa de optimizacin del grafo
de navegacin, junto con el rbol optimizado de los recorridos nales que deriva
del ltrado inverso (aunque el grafo de navegacin se haya representado al revs, su
orientacin nal se conserva desde el punto de partida hasta el punto nal).
Para tratar formalmente los recorridos nales, empezamos por denir el rbol op-
39
3 Algoritmo HCTNav
(a) Poda de las aristas redundantes.
(b) rbol denitivo (la rutina excluye la rama muerta).
Ilustracin 3.17. Construccin del rbol optimizado de los recorridos posibles.
timizado T como el conjunto de puntos de paso y de aristas que derivan de la poda
del grafo de navegacin G. Por cada PuntoDePaso
[i] en el rbol, siempre existen,

y son nicas, dos aristas [m i] y [i n] que denen una salida y una entrada al
punto de trnsito, excepto por el nodo fuente Nodo
[s] y el nodo destino Nodo
[t]
que tienen, respectivamente, o slo una salida o slo mltiples entradas:
T = {PuntosDePaso
, Aristas
} :
PuntoDePaso
[i] T, i / = {s, t} Arista
[m i] Arista
[i n] (3.6)
Nodo
[s] Arista
[m s] (3.7)
Nodo
[t] {Arista
[t n
1
], . . . , Arista
[t n
k
]} (3.8)
Debido a que las ramas muertas no generan recorridos, la existencia del rbol de
los caminos optimizados est subordinada a la existencia de la solucin al recorrido
40
3 Algoritmo HCTNav
desde el Nodo[s] al Nodo[t]. Con estas premisas, podemos formalizar la denicin de
recorrido optimizado P
k
como la secuencia ordenadas de aristas que conducen desde
el nodo fuente hasta el nodo nal:
P
k
= {Arista
[t n], Arista
[n i
1
], . . . ,
Arista
[i
k
m], Arista
[m s]}. (3.9)
La longitud W
k
de cada recorrido es la suma de los pesos w
uv
de todas las Arista[v u]
que forman la secuencia. Finalmente, se proporciona un ejemplo de pseudosalida de
la rutina de construccin de los recorridos nales en el marco a continuacin (en
negrita se marcan los pesos relativos de los saltos y el peso total del recorrido):
Pseudosalida de la rutina de optimizacin para el ejemplo 3.18(b)
1 #Recorrido 1 [Peso = (7 +

5 + 2
2) 12]:
2 39 36(3) 58(
5) 73(2
2) 91(2) 89(2)
3
4 #Recorrido 2 [Peso = 14]:
5 39 79(4) 74(5) 73(1) 91(2) 89(2)
Una vez disponemos de los recorridos optimizados P
k
y de sus respectivos costes
totales W
k
, queda slo devolver el recorrido nal:
P
k
= mn
k
{W
k
: P
k
T}, (3.10)
que se corresponde con el recorrido de longitud mnima entre el conjunto T devuelto
al paso anterior. En la Ilustracin 3.18 se completar la presentacin del caso de
estudio de este apartado: a partir del rbol de los recorridos posibles T, en 3.18(a), se
devuelve la solucin de coste mnimo, es decir, el recorrido P
1
de longitud W
1
12,
en 3.18(b).
3.3 Comparacin con los otros algoritmos
En este apartado se presentar un informe cualitativo de las similitudes y diferencias
entre los conceptos de nuestro HCTNav y las dos familias de algoritmos discutidas
41
3 Algoritmo HCTNav
(a) Resultado de la simulacin. (b) Solucin de coste menor.
Ilustracin 3.18. Final de la ejecucin del algoritmo HCTNav en el mapa javi2.
en el Captulo 2. Como ya hemos subrayado, la familia Dijkstra aborda el problema
de la bsqueda del recorrido ptimo mientras que la familia Bug se coloca entre
los algoritmos de navegacin. Nuestro algoritmo puede considerarse un hbrido, en
el sentido de que se emplea la bsqueda del recorrido para establecer la ruta de
navegacin.
3.3.1 HCTNav vs Dijkstra
Con respecto al algoritmo de Dijkstra y sus variaciones heursticas, compartimos los
conceptos de exploracin recursiva de un grafo y las estructuras de datos a emplear
en el clculo, aunque con algunas distinciones:
en nuestro algoritmo, a la hora de inicializar los datos de partida, slo se
necesita el conjunto de nodos que representan las casillas libres en el mapa,
mientras que Dijkstra necesita conocer tambin todas las aristas a un paso
posibles; por ello, conseguimos un ahorro de memoria dinmica considerable
cuando los mapas crecen en nmero de casillas;
las aristas se establecen dinmicamente a lo largo de la ejecucin, si el trayecto
no presenta obstrucciones y, a diferencia de Dijkstra, los vecinos pueden distar
ms de un salto;
42
3 Algoritmo HCTNav
en HCTNav se ha introducido una estrategia de control de los obstculos para
elegir los puntos de trnsito y poder emprender el rodeo para adelantarlos;
en Dijkstra no se contempla la presencia de obstculos, ya que el rodeo es
implcito en la construccin del grafo inicial;
el algoritmo HCTNav no es ptimo, en el sentido de que no se devuelve nece-
sariamente el recorrido de coste mnimo, como para Dijkstra que apoya sobre
una slida demostracin matemtica; sin embargo, estadsticamente, la solu-
cin proporcionada por HCTNav se acerca al ptimo.
Para hacernos una idea de la diferente estrategia de exploracin empleada en los dos
algoritmos que estamos comparando, se presenta otro caso concreto de bsqueda
de recorrido en el mapa llamado obstacles, representado en la Ilustracin 3.19:
(a) Escenario inicial. (b) Simulacin con HCTNav.
(c) Simulacin con Dijkstra. (c) Simulacin con Manhattan.
Ilustracin 3.19. Caso de estudio para el mapa obstacles.
43
3 Algoritmo HCTNav
en 3.19(a) se muestra el escenario inicial del problema, con los obstculos, el punto
de partida (Nodo[45]) y el objetivo (Nodo[60]).
La ejecucin de HCTNav, en 3.19(b), produce un rbol de un solo recorrido, puesto
que slo existe la Arista[60 82] que llega al destino; en 3.19(c) se proporciona la
captura de la ejecucin del algoritmo de Dijkstra. Como puede verse, mientras que
HCTNav se conforma con el conjunto inicial de nodos (que representan las celdas
libres), el algoritmo de Dijkstra necesita conocer a priori el conjunto de aristas, re-
presentadas en el simulador con lneas puntuadas, para poder determinar el prximo
nodo a visitar y seguir iterando hasta encontrar el destino.
Es interesante contemplar el overhead computacional de los dos algoritmos: para
HCTNav se trata del grafo de navegacin (los puntos de paso y todas las aristas
implcitas aunque no directamente visibles) mientras que para Dijkstra el overhead
es representado por las aristas en verde, que indican las celdas visitada a lo largo de
la ejecucin.
En 3.19(c) se contempla la ejecucin de la variacin heurstica de Manhattan, pudin-
dose conrmar que el overhead de este ltimo es mucho ms reducido con respecto
a Dijkstra, que se mueve por espirales crecientes mientras que Manhattan intenta
seguir lo ms recto posible hacia el destino.
Para comparar de una manera ms objetiva los recorridos nales de cada algoritmo,
al implementar Dijkstra, hemos aadido una etapa de post-procesado que ejecuta las
mismas optimizaciones discutidas en la Subseccin 3.2.3.2 para eliminar las aristas
redundantes.
Los recorridos nales dieren slo por el codo en el Nodo[25], ya que Dijkstra pue-
de optimizarse en el sentido correcto de orientacin del grafo; los pesos totales se
comparan en la Tabla 3.5 a continuacin
3
, junto con el porcentaje de cercana con
la solucin ptima (una comparacin de los tiempos de ejecucin se ofrecer en el
Captulo 4).
3
Se ha omitido la longitud calculada por el algoritmo Manhattan ya que es idntica a la que
devuelve Dijkstra.
44
3 Algoritmo HCTNav
Algoritmo Longitud de recorrido Cercana de HCTNav con el ptimo Error
HCTNav W 21,16 98,95 % 0,59 (1,05 %)
Dijkstra W 20,57 - -
Tabla 3.5. Pesos totales de los recorridos devueltos por los tres algoritmos.
3.3.2 HCTNav vs DistBug
Los algoritmos de la familia Bug (discutidos en el Apartado 2.2), presentan una na-
turaleza distinta con respecto a HCTNav: en primer lugar se fundan en la rigurosa
premisa de no conocer a priori el entorno de navegacin; segundo, como consecuen-
cia directa del punto anterior, la navegacin es guiada por sensores de proximidad
y no mediante la exploracin recursiva de un grafo.
No obstante, es posible identicar ciertas similitudes entre nuestras reglas de nave-
gacin (discutidas en la Seccin 3.2.2) y las rutinas empleadas para el ltimo de la
familia: el algoritmo DistBug (Seccin 2.2.2). Debido a que no hemos implementado
DistBug en nuestro simulador para una comparacin directa con nuestro algoritmo,
nos limitaremos en esta seccin a comparar cualitativamente nuestro enfoque en los
dos ejemplos de simulacin ofrecida por Kamon y Rivlin [12].
En la Ilustracin 3.20 volvemos a proponer la captura 2.3(c), junto con una hipo-
ttica solucin que HCTNav encontrara en el mismo mapa
4
. La trayectoria que
devolvera HCTNav sera ms recta y, en consecuencia, de menor longitud.
La siguiente comparacin de Ilustracin 3.21, se reere a otro caso de estudio del
mismo artculo: esta vez, no se trata de una simulacin sino que el mapa y la solu-
cin de DistBug son tericos. Sin embargo, en este caso, el entorno propuesto por
Kamon y Rivlin [12] es ms adecuado para ser representado en nuestro simulador,
siendo sus obstculos ms rectilneos y la granularidad del mapa mayor que la del
caso anterior.
Las reglas de navegacin de HCTNav, en 3.21(b), se asemejan bastante a las ruti-
nas de DistBug, en 3.21(a), por lo menos desde un punto de vista lgico. Ello no
4
Lamentablemente, la granularidad de este mapa no nos permite representar el mapa de forma
apropiada en nuestro simulador, para llevar a cabo una comparacin directa.
45
3 Algoritmo HCTNav
(a) DistBug con ruta optimizada. (b) Solucin hipottica de HCTNav.
Ilustracin 3.20. Comparacin entre DistBug y HCTNav en el mismo mapa pro-
puesto por los autores de DistBug en [12].
nos debe sorprender, ya que el concepto de navegar rumbo al destino bordeando
los obstculos que se hallan en el trayecto, se inspira totalmente al comportamiento
intuitivo de movimiento de los seres vivos.
Por otro lado, cabe destacar un aspecto interesante de este caso de estudio: tras
replicar el mapa de los autores [12] en nuestro simulador, con las debidas aproxima-
ciones, y correr nuestro algoritmo se obtiene un comportamiento homlogo al del
algoritmo de bsqueda ciega guiado por sensores.
Efectivamente, el rbol de navegacin resultante de HCTNav incluye la solucin de
DistBug (el recorrido en verde que rodea a la izquierda el obstculo): hasta los dos
codos en H1 y H2, en 3.21(a), se reejan en los dos puntos de paso en la ejecucin
de nuestro algoritmo, en 3.21(b). La nica diferencia es que la rutina de construccin
del rbol optimizado elimina esos codos remplazndolos con unos saltos ms cortos.
La ventaja de nuestro algoritmo, que se debe al conocimiento a priori de la topogra-
fa del mapa, es que, en el punto de paso que se corresponde con H1, HCTNav abre
una bifurcacin en el grafo de navegacin, encontrndose con otro recorrido posi-
ble que llega al destino, esta vez, por el lado derecho. Adems de ser un recorrido
alternativo, su longitud es menor que la del recorrido encontrado por el algoritmo
DistBug y, de hecho, HCTNav lo marca en rojo como recorrido de coste mnimo.
46
3 Algoritmo HCTNav
(a) Planicacin de la ruta de DistBug. (b) Simulacin homloga de HCTNav.
Ilustracin 3.21. Caso de estudio [12] del algoritmo DistBug y rplica del
mapa en nuestro simulador.
Si se miden en nuestro mapa las longitudes de los recorridos del rbol optimiza-
do, se puede estimar, haciendo las oportunas aproximaciones, el coste del trayecto
propuesto por DistBug y compararlo con nuestro algoritmo, como se reporta en la
Tabla 3.6. Aunque el porcentaje de mejora del recorrido sea despreciable, este ejem-
plo demuestra la importancia de saber evaluar los pros y contras de las distintas
estrategias y tecnologas que pueden emplearse en la navegacin indoor.
Algoritmo Longitud de recorrido Mejora en nuestra solucin
HCTNav (verde) W 19,21 1,16 % (-3,14)
HCTNav (rojo) W 19,07 1,17 % (-3,28)
DistBug (estimacin) W 22,35 -
Tabla 3.6. Pesos totales de los tres recorridos para el caso de Ilustracin 3.21.
47
Captulo 4
Resultados experimentales
En este captulo se presentarn los datos producidos por las simulaciones realizadas
para HCTNav. En el Apartado 4.1 empezaremos describiendo el contexto tecnolgico
en que se ha desarrollado el simulador y realizado las pruebas experimentales; para
pasar luego a describir los criterios de comparacin con la familia Dijkstra. En el
Apartado 4.2 se presentarn los resultados estadstico de las pruebas, acompaados
por el anlisis nal sobre los puntos de fuerza y debilidad de HCTNav.
4.1 Metodologas
Antes de empezar a presentar los datos concretos de los experimentos, en este aparta-
do se denir formalmente nuestro banco de pruebas: la tecnologa empleada (Sec-
cin 4.1.1), el lote de mapas empleado en las simulaciones (Seccin 4.1.2) y los
criterios elegidos para evaluar los resultados experimentales (Seccin 4.1.3).
4.1.1 Entorno de desarrollo y de prueba
Tras haber producido el primer prototipo funcional del algoritmo, se ha procedido a
su implementacin en un entorno de prueba concreto con el que realizar simulaciones
y generar los resultados experimentales de comparacin. Las tareas de programacin
se han llevado a cabo en una mquina Linux con sistema operativo Karmik Koala
48
4 Resultados experimentales
(versin 9.10) y entorno de desarrollo CodeLite
1
.
Primero, con el n de poder comprobar de forma visual el comportamiento del al-
goritmo y realizar pruebas puntuales de bsqueda de recorridos, se ha diseado un
simulador con interfaz grca de usuario (Graphic User Interface o GUI) en lenguaje
de alto nivel (C++), que hemos llamado NavSim (Navigation Simulator).
Algunas capturas de pantalla de nuestro simulador se han adelantado a lo largo del
Captulo 3 para enriquecer la presentacin del algoritmo HCTNav. A continuacin,
en la Tabla 4.1, se resumirn las funcionalidades operativas del simulador, respalda-
das por las capturas de pantalla de las entradas de men de la Ilustracin 4.1.
mbito funcional Caractersticas disponibles en NavSim
Simulacin Correr una simulacin
Conguracin Cambiar puntos de partida y de llegada Cambiar algoritmo Cambiar mapa
Lneas de Bresenham Lanzar la rutina de Bresenham Cambiar las lneas de Bresenham
Ficheros Crear/editar un mapa Ver cheros de log Editar cheros de conguracin
Vistas Congurar las impostaciones grcas del simulador (rejilla, mapa, grafo, rutas, etc.)
Tabla 4.1. Caractersticas funcionales del simulador NavSim.
En segundo lugar, se ha desarrollado una versin C++ del simulador NavSim para
lnea de comando, que nos permite lanzar bsquedas en lotes (batch) iterando sobre
todas las posiciones posibles de un mapa, incluso sobre todos los mapas.
Ilustracin 4.1. Capturas de los distintos elementos del men del simulador NavSim.
1
Se puede consultar la documentacin ocial en: http://codelite.org/.
49
Gracias a estos experimentos masivos, hemos podido recopilar, desde un punto de
vista estadstico, las informaciones sobre los parmetros de medicin de los algorit-
mos implementados, que presentaremos con ms detalle a lo largo de este captulo.
Finalmente, se ha migrado la implementacin C++ de nuestro algoritmo al lenguaje
estndar ANSI C, con el n de optimizar nuestra solucin para su implementacin
futura sobre una placa FPGA, ya que el entorno de diseo HW/SW se basa en
adaptaciones del lenguaje C.
Este nuevo prototipo de HCTNav de ms bajo nivel, liberado de las componentes de
programacin orientada a objetos, nos ha garantizado un control ms directo de los
accesos en memoria, permitiendo analizar dinmicamente el consumo de memoria y
tiempo de ejecucin de los algoritmos.
4.1.2 Conjunto de mapas de prueba
Durante las prcticas se ha implementado en el simulador unos mapas que emulan
el resultado de la Capa de mapeado (descrita en el Apartado 1.2) hacia nuestra
Capa de navegacin.
El lote de mapas (en total 35) presenta las caractersticas de modelado descritas en
la Seccin 3.1.1: cada uno de ello es representado por una matriz de 0 y 1, compuesta
por 10 las (r = 10) y quince columnas (c = 15), por un total de 150 casillas.
Como era de esperar, la topologa de los mapas es determinante en las prestaciones
del algoritmo durante la bsqueda del recorrido, debido a las diferencias que pueden
producirse en el ujo de ejecucin.
Las rutinas de HCTNav implican diferentes costes computacionales, que pueden
determinarse mediante perlado de la implementacin (por ejemplo, el cuello de
botella introducido por el barrido con Bresenham, ha sido detectado mediante el
perlado de las llamadas a las rutinas). En la Ilustracin 4.2 se muestran otros seis
mapas del conjunto de prueba.
En respuesta a la necesidad de poder relacionar los comportamientos del algoritmo
frente al tipo de topologa del entorno de trabajo, sera oportuno denir unos crite-
rios formales para catalogar la complejidad de un mapa y automatizar el cmputo
de dicha informacin.
50
(a) Mapa no_obstacles. (b) Mapa alberto4.
(c) Mapa labyrinth. (d) Mapa bloque28b.
(e) Mapa javi3. (f) Mapa alberto6.
Ilustracin 4.2. Seis mapas del conjunto de prueba empleados en el simulador NavSim.
51
En este trabajo no se ha profundizado ms sobre el tema de la funcin de comple-
jidad de los mapas. En cambio, hemos establecido unos parmetros de complejidad
topolgica para orientar el eje de los mapas en los grcos:
el porcentaje de celdas libres;
el factor de adyacencia de las celdas libres;
el grado de linealidad del perl de los obstculos;
el factor de agrupacin de los obstculos.
Para completar la casustica de simulacin, hemos desarrollado otra herramienta de
procesado, llamada NavMap, que calcula, de forma individual o en lote, los valores
numricos de los parmetros de complejidad de los mapas. Adems, mediante Nav-
Map es posible generar automticamente nuevas versiones agrandadas del mismo
conjunto de partida.
Las tcnicas de agrandamiento empleadas han sido dos: la primera, escalado a topo-
loga constante, consiste en la expansin del mapa en las dos direcciones cartesianas
manteniendo las proporciones en el perl de los obstculos; en la segunda, reduplica-
do de topologa, se unen las replicas del perl de los obstculos en las dos direcciones
cartesianas. Los factores de agrandamiento siguen el patrn cuadrtico de las po-
tencias de dos: x2, x4, x8, x16 y x32.
4.1.3 Metodologa de simulacin y criterios de comparacin
Para ejecutar las simulaciones en lote se han preparado unos scripts en lenguaje
BASH para la consola de comandos de Linux. En estos programas se llaman de forma
iterativa los ejecutables de los cuatro algoritmos implementados en NavSim (HCT-
Nav, Dijkstra, Euclidean y Manhattan), pasndole oportunamente los parmetros
de lanzamiento, que se resumen en la Tabla 4.2.
Un ejemplo de lanzamiento de una simulacin individual sera el siguiente:
52
Ilustracin 4.3. Captura del NavSim en su versin C para consola.
$>$HCTDIR$ = /ruta/del/ejecutable
$>$HCTDIR$/.NavSim -d ../maps -m labyrinth -f 13 -t 33
Parmetro Comando [arg] Descripcin
dir -d [DIR] Directorio donde se halla el mapa
map -m [MAPA] Nombre del chero de mapa
from -f [NDICE] ndenticador del punto de partida
to -t [NDICE] ndenticador del punto de llegada
shell -s Salida reducida para ejecuciones en lote
help -h Imprime el manual de usuario
Tabla 4.2. Parmetros bsicos para el lanzamiento de los algoritmos desde consola.
En la Ilustracin 4.3 se presenta una captura de ejemplo del lanzamiento individual
de NavSim desde consola. En la salida se informan los datos de la simulacin: el
algoritmo, la condicin de salida, la ruta planicada, la longitud del recorrido y el
tiempo de ejecucin.
53
Para medir el consumo de memoria, hemos explotado las funcionalidades de la apli-
cacin libre Valgrind
2
3.8. Aparte de ser un poderoso depurador de memoria, con su
herramienta principal memcheck, este programa proporciona dos herramientas ms
para el perlado de las aplicaciones en tiempo de ejecucin:
massif, realiza un muestreo (congurable en frecuencia y umbral) de las re-
servas en el heap, es decir, en la pila de memoria asignada al proceso corespon-
diente; en el chero de salida, que se escribe durante el muestreo, se registran
todas las entradas relativas a reservas de memoria como son las calloc() y
las malloc().
msprint, realiza un post-procesado del chero de salida de massif, puesto que
el formato grueso generado por massif sera complejo de leer; el nuevo chero
de salida formateado por msprint se presta mejor al anlisis de los datos, ya
que viene en forma de grco cartesiano con el tiempo (o, en alternativa, el
nmero de instrucciones) en el eje-x y el nmero de bytes reservados en el
eje-y.
En prctica Valgrind hace de envoltorio de ejecucin a la aplicacin que se quiere
analizar, lanzndola como proceso hijo e interceptando las llamadas a las libreras
nativas del sistema operativo.
En la Ilustracin 4.4 se presenta una captura del chero nal generado por msprint.
Como puede observarse, el perl dinmico que se construye es completo y detallado:
se encuentran los porcentajes de reserva, las rmas de los mtodos que generan las
reservas (recorriendo toda la pila - o stack), la cantidad fsica asignada en bytes y
los picos de consumo.
El conocimiento de los picos de reserva es fundamental para establecer el consumo
dinmico mximo de memoria que el algoritmo requiere en tiempo de ejecucin; el
consumo esttico es fcil de determinar ya que coincide con el tamao de los cheros
ejecutables que se corrern en el microprocesador.
2
Se puede consultar la documentacin ocial en: http://valgrind.org/.
54
Ilustracin 4.4. Captura de la salida de la herramienta msprint de Valgrind
(representa el perl del consumo dinmico de memoria para el lanzamiento de
una bsqueda de recorrido).
Ahora que se han denido las herramienta de simulacin y de medicin, se descri-
birn brevemente los criterios de evaluacin que usaremos para discutir los puntos
fuertes (y los dbiles) de HCTNav y compararlo con los dems algoritmos.
Consumo dinmico de memoria. Representa el criterio de evaluacin al que da-
remos ms prioridad, en lnea con nuestro objetivo de respetar los vnculos
fsicos de proyecto: en concreto, el tamao (y el coste) de la memoria RAM; el
consumo se medir con simulaciones en lote procesadas por massif, msprint y
algunos comandos ms, que proporciona el entorno Linux para el tratamiento
de los ujos de entrada y de salida (pipe, awk, etc.).
55
Cercana con la solucin ptima. El recorrido generado por HCTNav puede con-
gurarse para ser siempre ptimo (dejando que las ramas de navegacin cum-
plan todos los rodeos que se han abierto desde los puntos de paso). Esto puede
afectar las prestaciones en mapas grandes y vanicar los logros relativos al
consumo de memoria. En alternativa se puede interrumpir la navegacin en
el momento en qu se encuentra el destino. En este caso es importante mo-
nitorizar la cercana con la solucin ptima para evaluar si esta eleccin es
apropiada al caso.
Tiempo de clculo. Contrariamente a lo que se pensaba, la velocidad de ejecu-
cin del algoritmo pasa a ser segundario cuando los dos sistemas en cuestin,
de movimiento (desplazamiento sobre orugas) y de navegacin (clculo de la
ruta), tienen tiempos de respuesta tan diferentes en orden de magnitud. El
robot se desplaza con velocidades del orden de 10 cm/s y para recorrer una
ruta tpica puede tardar 30 o 40 segundos. El algoritmo de navegacin pue-
de tardar desde un mnimo de 450 nanosegundos (en mapas de 150 casillas)
hasta un mximo de 3 segundos (en mapas de 150.000 casillas). Sin embargo,
no hemos despreciado este aspecto fundamental de las prestaciones globales
y en el Apartado 4.2 a continuacin, junto con el consumo de memoria, se
discutirn tambin los resultados de velocidad de clculo (obtenidos mediante
simulaciones en lote en qu no se invocan las herramientas de Valgrind).
4.2 Simulaciones y comparativas
En este apartado se presentarn algunos casos de estudio signicativos de simula-
ciones realizadas en el HCTLab. Se trata de los resultados de los script de ejecucin
en lote, para el lanzamiento de los cuatro algoritmos que hemos implementado en
NavSim. Para cada caso de estudio se proporcionarn uno datos concretos en forma
de tabla, acompaados por las respectivas grcas. Al mismo tiempo, se compara-
rn los consumos de memoria y los tiempos de ejecucin, destacando las ventajas y
desventajas de nuestro enfoque hbrido con respecto a la familia Dijkstra.
56
4.2.1 Consumo de memoria dinmica
Empezaremos con el anlisis de los consumos de memoria dinmica: la simulacin
consiste en calcular todos los recorridos posibles (de ida y de vuelta) de cada mapa
en el conjunto de prueba. En cada ejecucin, lanzada mediante Valgrind, capturamos
el valor de pico de la ocupacin de memoria, generado por la herramienta msprint
y normalizado a kilobytes (KB). Los picos se guardan en un chero temporal y,
al nal, se procesa este listado con awk para determinar el mnimo, el mximo y
el promedio de cada mapa. Estos valores agregados se redirigen a un chero CSV
(Comma-Separated Values) nal que puede importarse fcilmente en una hoja de
clculo para obtener el grco correspondiente.
Es oportuno destacar que Valgrind introduce un retraso considerable en la ejecucin
del algoritmo (estimado en 40 milisegundos) y estas simulaciones pueden tardar das
enteros por algoritmo, si se considera que en un solo mapa de 150 casillas existen en
media 12.000 recorridos:
0,04
s
ruta
12000
ruta
mapa
35 mapa = 168000 s ( 46 h).
Por lo que se reere a Dijkstra y sus dos variaciones heursticas (Euclidean y Man-
hattan), los resultados de las simulaciones se presentan en la Tabla 4.3. Como puede
verse en el grco asociado (Ilustracin 4.5), la familia Dijkstra necesita ms recur-
sos en los mapas donde hay un alto nmero de celdas libres. El caso extremo es en
el mapa no_obstacles de Ilustracin 4.2(a), en qu no hay obstculos. Los tres
algoritmos alcanzan un pico de 85,34 KB: esto se explica con el hecho de que, en
la familia Dijkstra, la componente mayor de ocupacin de memoria es representada
por la estructura de datos que se usa para el clculo (un grafo disperso no dirigido).
El tamao del grfo depende del nmero de casillas libres, determinando el nmero
de nodos y el nmero de aristas que los interconectan. Por la misma razn, las seis
curvas casi coinciden: los valores mnimos
3
y mximos (y el valor medio) son muy
cercanos para todos los mapas y entre los propios algoritmos.
3
Los valores mnimos no se han incluido en la Tabla 4.3 por razones de paginacin.
57
Nombre mapa
Dijkstra Euclidean Manhattan
Max (KB) Medio (KB) Max (KB) Medio (KB) Max (KB) Medio (KB)
no_obstacles 85,34 85,15 85,34 85,15 85,34 85,15
wall 78,12 77,91 78,12 77,91 78,12 77,91
wall3 78,12 77,90 78,12 77,90 78,15 77,91
wall1 72,86 72,67 72,88 72,67 72,93 72,67
wall2 76,24 76,00 76,24 76,00 76,24 76,00
wall4 74,31 74,10 74,31 74,10 74,34 74,10
wall_with_closed tile 71,38 71,16 71,38 71,16 71,38 71,16
wall5 70,55 70,31 70,57 70,31 70,57 70,31
frame 24,73 24,18 24,73 24,18 24,73 24,18
multiple_obstacles 69,88 69,66 69,88 69,66 69,97 69,66
bottleneck 52,96 52,68 52,96 52,68 52,98 52,68
javi1 41,66 41,39 41,66 41,39 41,69 41,39
javi2 42,12 41,65 42,12 41,65 42,19 41,65
obstacles 39,67 39,32 39,7 39,32 39,7 39,32
alberto10 60,2 60,03 60,2 60,03 60,2 60,03
javi4 40,39 40,10 40,39 40,10 40,39 40,10
javi3 34,25 33,91 34,25 33,91 34,27 33,91
alberto4 38,26 38,06 38,26 38,06 38,26 38,06
bloque12a 20,27 20,00 20,27 20,00 20,27 20,00
alberto9 41,34 41,02 41,34 41,02 41,34 41,02
alberto8 36,75 36,46 36,77 36,46 36,8 36,46
alberto1 31,92 31,58 31,92 31,58 31,92 31,58
alberto3 31,79 31,40 31,81 31,40 31,84 31,40
bloque28b 24,02 23,69 24,02 23,69 24,02 23,69
alberto7 66,77 63,04 66,77 63,04 66,77 63,04
alberto5 23,33 23,06 23,33 23,06 23,33 23,06
labyrinth 23,23 22,84 23,23 22,84 23,23 22,84
alberto6 13,29 13,29 13,29 13,29 13,29 13,29
susana4 27,77 26,93 27,77 26,93 27,77 26,93
susana3 37,2 36,82 37,2 36,82 37,2 36,82
susana1 26,79 26,20 26,79 26,20 26,81 26,20
susana6 28,55 27,98 28,57 27,99 28,57 27,99
susana5 29,47 29,05 29,47 29,05 29,47 29,05
fernando1 41,43 41,05 41,43 41,05 41,43 41,05
chessboard 32,02 31,49 32,02 31,49 32,02 31,49
Tabla 4.3. Consumo de memoria dinmica de la familia Dijkstra en los
mapas de prueba.
58
Ilustracin 4.5. Consumo de memoria de la familia Dijkstra, asociado a la Tabla 4.3.
El algoritmo HCTNav depende en grado menor del nmero de casillas libres, pero
es cierto que la topologa del mapa puede afectar considerablemente el consumo di-
nmico de memoria.
Por ejemplo, HCTNav presenta ciertas ventajas en los mapas con reas contiguas
libres y obstculos con perl lineal, mientras que gasta muchos ms recursos en
aquellos con perl de laberinto (como el mapa labyrinth de Ilustracin 4.2(c)).
En la Tabla 4.4 se presentan los resultados de simulacin para HCTNav, acompa-
ados por el grco del consumo mnimo, mximo y medio en la Ilustracin 4.6.
Con respecto a Dijkstra, HCTNav depende en grado menor del nmero de casillas
libres, pero es cierto que la topologa del mapa puede afectar considerablemente
el consumo dinmico de nuestro algoritmo. Por ejemplo, HCTNav presenta ciertas
ventajas en los mapas con reas contiguas libres y obstculos con perl lineal (como
el mapa obstacles), mientras que gasta muchos ms recursos en aquellos con perl
de laberinto (como el mapa labyrinth de Ilustracin 4.2(c)).
En la Ilustracin 4.7 se comparan directamente los picos de ocupacin de HCT-
Nav con los de Manhattan (lnea puntuada), siendo visibles las mejores prestaciones
de nuestro algoritmo en el consumo de memoria.
59
Nombre mapa Min (KB) Max (KB) Medio (KB)
no_obstacles 13,38 14,09 13,97
wall 13,12 17,8 15,05
wall3 13,12 18,06 15,02
wall1 12,76 17,41 14,59
wall2 13,05 18,78 15,19
wall4 12,97 18,8 15,22
wall_with_closed tile 12,76 21,04 15,56
wall5 12,81 19,59 15,65
frame 10,73 21,79 12,97
multiple_obstacles 12,81 23,3 15,41
bottleneck 11,98 22,8 15,56
javi1 11,17 26,39 15,52
javi2 11,41 31,05 15,20
obstacles 11,2 27,39 15,26
alberto10 11,59 22,76 15,64
javi4 11,35 27,52 15,61
javi3 11,29 21,85 14,13
alberto4 8,812 14,11 11,07
bloque12a 10,26 15,46 11,39
alberto9 12,29 27 17,48
alberto8 11,51 26,87 18,25
alberto1 11,27 29,95 15,88
alberto3 11,02 31,05 15,92
bloque28b 10,73 18,77 11,98
alberto7 22,02 53,01 30,53
alberto5 8,812 19,01 13,03
labyrinth 10,31 28,02 14,82
alberto6 10,94 11,22 11,13
susana4 10,94 20,79 14,22
susana3 11,33 25,23 15,00
susana1 11,37 22,76 14,32
susana6 11,02 30,32 15,12
susana5 10,88 30,52 15,13
fernando1 11,27 22,45 13,88
chessboard 11,04 22,66 14,63
Tabla 4.4. Consumo de memoria dinmica del algoritmo HCTNav en
los mapas de prueba.
60
Ilustracin 4.6. Grco sobre el consumo de memoria del algoritmo HCT-
Nav asociado a la Tabla 4.4.
Ilustracin 4.7. Comparacin del consumo de memoria entre HCTNav y Manhat-
tan (basada en las columnas Max (KB) de las respectivas tablas).
61
4.2.2 Escalabilidad de los algoritmos
Otro caso de estudio interesante es trazar el crecimiento de las reservas de memoria
cuando el nmero de casillas del mapa aumenta exponencialmente. Para correr esta
simulacin, hemos generado, mediante NavMap, las versiones agrandadas de dos
mapas de particular inters: no_obstacles y labyrinth.
Se trata de una prueba de carga y estrs para conrmar que, en HCTNav, hemos
logrado desacoplar la bsqueda del recorrido del uso intensivo del grafo de navegacin
(introduciendo el concepto de puntos de paso). En la Tabla 4.5 hemos informado
los picos (Max) de HCTNav y de Manhattan, esta vez en megabytes (MB). Para el
mapa no_obstacles solo hace falta una columna, ya que el escalado y las replicas
producen los mismos mapa.
Nombre mapa HCTNav (MB) Manhattan (MB)
no_obstacles 0,014 0,085
no_obstacles_scale_x2 0,046 0,351
labyrinth 0,028 0,023
labyrinth_scale_x2 0,042 0,087
labyrinth_repeat_x2 0,052 0,143
Tabla 4.5. Consumo de memoria dinmica de HCTNav y Manhattan en
los mapas agrandados.
Como era de esperar, la familia Dijkstra aumenta considerablemente con el anda-
miento tpico de las funciones exponenciales, mientras que HCTNav crece de forma
mas comedida y se mantiene en niveles aceptables de consumo (Ilustracin 4.8).
62
(a) Picos de consumo de Manhattan.
(b) Picos de consumo de HCTNav.
Ilustracin 4.8. Crecimiento del consumo de memoria en relacin al nmero de
casillas (asociado a la Tabla 4.5).
63
4.2.3 Velocidad de clculo
El ltimo caso de estudio, que concluye esta comparativa, se reere a los tiempos
de respuestas medios de los cuatro algoritmos para calcular todos los recorridos de
ida y vuelta en cada mapa. Aunque el esquema de la simulacin en lote es parecido
a los anteriores, en este caso no se necesita Valgrind y los algoritmos pueden correr
a su mxima velocidad.
En la Tabla 4.6 se resumen los datos producidos por los script mientras que el
grco asociado se representa en Ilustracin 4.9. Los resultados son aceptables con
respecto a las expectativas: a pesar del nivel de complejidad introducido por las tres
rutinas que componen nuestro algoritmo, el tiempo de ejecucin es equiparable al
andamiento de la familia Dijkstra con un error despreciable.
Nuestro caso peor (worst-case) en el lote de mapas es representado por el mapa
alberto6 4.2(f), de forma laberntica y con un perl diagonal de los obstculos.
Esta combinacin topolgica hace que el ujo de ejecucin conmute intensivamente
entre la rutina de barrido de Bresenham y de rodeo de los obstculos, empeorando
las prestaciones.
Ilustracin 4.9. Grco sobre los tiempos de ejecucin de los cuatro algorit-
mos, asociado a la Tabla 4.6.
64
Nombre mapa Dijkstra (s) Euclidean (s) Manhattan (s) HCTNav (s)
no_obstacles 113,35 93,96 77,90 90,14
wall 97,99 81,23 67,34 86,87
wall3 104,73 86,82 71,97 83,23
wall1 83,99 69,63 57,72 67,58
wall2 102,94 85,34 70,74 78,75
wall4 96,95 80,37 66,62 82,94
wall_with_closed_tile 93,16 77,23 64,02 86,87
wall5 84,51 70,06 58,08 73,71
multiple_obstacles 82,03 68,00 56,37 73,86
bottleneck 58,57 48,55 40,25 51,2
susana5 14,87 12,33 10,22 17,53
susana6 13,51 11,20 9,28 15,19
obstacles 38,51 31,92 26,46 35,4
susana4 23,54 19,51 16,18 26,35
javi1 32,52 26,96 22,35 38,74
susana3 25,94 21,50 17,83 23,88
susana1 17,57 14,57 12,07 18,41
Alberto9 35,92 29,78 24,68 37,34
Alberto10 36,79 30,50 25,28 43,41
javi4 38,84 32,20 26,69 44,43
javi2 42,5 35,23 29,21 39,9
labyrinth 20,47 16,97 14,07 20,19
javi3 29,72 24,64 20,42 34,6
Alberto6 32,29 26,77 22,19 31,21
Alberto5 32,42 26,88 22,28 28,87
Alberto4 38,98 32,31 26,79 46,75
Alberto8 34,43 28,54 23,66 31,78
Alberto7 30,38 25,18 20,88 30,29
Alberto3 32,98 27,34 22,66 27,19
Alberto1 35,19 29,17 24,18 34,72
Tabla 4.6. Comparacin de los tiempos de ejecucin para todos los caminos
posibles en cada mapa.
65
Captulo 5
Conclusiones
En el problema de la navegacin de robots mviles en interiores se unen los requisitos
de prestaciones, tpicos de los sistemas en tiempo real, y los vnculos de recursos,
tpicos de las unidades autnomas. En el caso de robots que se desplazan sobre oru-
gas, el compromiso entre la velocidad de clculo y la cantidad de memoria, necesaria
para almacenar el algoritmo y su estructura de datos, va a favor de la minimizacin
del consumo dinmico de memoria en tiempo de ejecucin. Puesto que el tiempo
medio para recorrer una ruta en un espacio interior es del orden de unas decenas de
segundos; el tiempo de respuesta del algoritmo de navegacin es despreciable, siendo
inferior de seis rdenes de magnitud (unas centenas de nanosegundos).
Con el presente trabajo hemos perseguido esta losofa de diseo, a la hora de es-
tablecer nuestras propias reglas de navegacin, premiando las prestaciones relativas
al consumo de memoria dinmica.
Teniendo en cuenta que los mapas tienen un alto rango de escalabilidad (puede va-
riar la granularidad de la rejilla), hemos desarrollado un algoritmo hbrido donde
se unen las caractersticas de los algoritmos de bsqueda ptima con las de los al-
goritmos de navegacin basada en sensores. De esta manera se consigue una buena
velocidad de respuesta y se mantiene controlada la tasa de reserva de los recursos de
clculo. Los resultados experimentales, producidos con el lote de mapas de prueba,
han conrmado nuestras expectativas iniciales.
66
5 Conclusiones
Hemos reducido la estructura de grafo, empleada en la familia Dijkstra, a un con-
junto de puntos de paso, barriendo el trayecto con las lneas de Bresenham para
detectar eventuales obstculos.
En lugar de inspeccionar los nodos alrededor, HCTNav intenta dirigirse directamen-
te hacia el destino, rodeando los obstculos detectados a lo largo de la ruta. Por lo
contrario, Dijkstra no contempla el concepto de obstculo si no que el grafo mismo
los excluye del conjunto de nodos que forma la estructura de navegacin. Con nues-
tra estrategia limitamos la estructura de datos an cuando el mapa crece en nmero
de casillas, caso en el que el consumo de memoria de Dijkstra crece de una forma
exponencial.
Con respecto a los algoritmos de navegacin basada en sensores, HCTNav pierde la
posibilidad de actuar en entornos desconocidos (se necesita un conocimiento a priori
del mapa). En cambio, se genera una reduccin de los costes de diseo, debido a que
ya no son necesarios los sensores de proximidad ni la placa de control. Al mismo
tiempo, como hemos comprobado, comparando HCTNav con el algoritmo DistBug,
se obtienen recorridos de menor longitud.
Estos logros se traducen en un signicativo ahorro energtico y, ste es de gran
importancia si se tiene en cuenta que los robots mviles trabajan en rgimen de
bateras con carga limitada en el tiempo.
Concluyendo, la eleccin sobre una u otra solucin depende estrictamente de qu
ndices de prestacin se quiere priorizar: por ejemplo, si se requiere minimizar la
distancia recorrida, el conocimiento a priori del mapa es vinculante para llevar a
cabo la bsqueda; de forma simtrica, si el requisito es poder navegar en entornos
desconocidos, la bsqueda ciega guiada por sensores sera la nica solucin posible.
En el robot del HCTLab, se intenta recuperar la capacidad de navegar en entornos
desconocidos empleando una Capa de mapeado: sta se ocupa de generar el mapa
del entorno en tiempo real antes de que el robot pueda emprender una navegacin
autnoma mediante el algoritmo HCTNav.
67
5 Conclusiones
5.1 Trabajos futuros
En lnea con la especialidad de este Mster, Recursos embebidos y recongura-
bles, el algoritmo de navegacin HCTNav ha sido desarrollado y probado en len-
guaje ANSI C, con el n de favorecer su futura implementacin en una placa FPGA
(Spartan-3).
De acuerdo con los principios aprendidos en el mbito del diseo HW/SW, el tras-
paso de un algoritmo de software a hardware puede no ser inmediato: pasar de un
contexto de ejecucin secuencial a uno de ejecucin paralela requiere un esfuerzo
adicional desde el punto de vista de la manipulacin de datos de ms bajo nivel.
La fase sucesiva al desarrollo de HCTNav y las simulaciones de prueba, sera realizar
pruebas con el robot real en un escenario tpico de trabajo.
Por lo que se reere al diseo de nuestras rutinas de clculo, quedan abiertos dos
aspectos de implementacin en los que se podra mejorar las prestaciones del algo-
ritmo: en la rutina de Bresenham se puede prescindir del clculo de la lnea interna
inferior (redundante); en segundo lugar se podra optimizar la construccin del re-
corrido nal aadiendo un segundo nivel de poda de las aristas innecesarias (una
alternativa sera invertir el sentido de inspeccin del grafo de navegacin a la hora
de construir el rbol optimizado de los recorridos).
68
Bibliografa
[1] J. Antich, A. Ortiz, J. Minguez. A Bug-inspired algorithm for ecient anytime
path planning, in IEEE/RSJ International Conference on Intel ligent Robots
and Systems (IROS 2009), pp. 5407-5413, 2009.
[2] L. Fu, D. Sun, L. R. Rilett. Heuristic shortest path algorithms for transportation
applications: state of the art, in Computers & Operations Research, vol. 33,
issue 11, pp. 3324-3343, 2006.
[3] T. H. Cormen, C. E. Leiserson, R. L. Rivest, C. Stein. Dijkstras algorithm,
in Introduction to Algorithms. MIT Press and McGraw-Hill, pp. 595-601, 2001.
[4] T. Cain. Pratical optimizations for A* path generation, in AI Game Program-
ming Wisdom. Charles River Media, pp. 146-152, 2002.
[5] V. J. Lumelsky, A. A. Stepanov. Path-planning strategies for a point mobile
automaton moving amidst obstacles of arbitrary shape, in Algorithmica, vol. 2,
pp. 403-430, 1987.
[6] V. J. Lumelsky, T. Skewis. Incorporating range sensing in the robot navigation
function , in IEEE Transactions on System, Man and Cybernetics, vol. 20,
pp. 1058-1068, 1990.
[7] A. Sanchez, A. de Castro, G. Glez-de-Rivera, J. Garrido. FPGA-based embed-
ded system for ultrasonic positioning, in Proceedings of the IEEE International
Symposium on Industrial Electronics (ISIE 2010), pp. 3051-3056, 2010.
[8] A. Sanchez, S. Elvira, A. de Castro, G. Glez-de-Rivera, R. Ribalda, J. Garrido.
69
Bibliografa
Low cost indoor ultrasonic positioning implemented in FPGA, in Proceedings
of the IEEE Industrial Electronics Conference (IECON 2009), pp. 2709-2714,
2009.
[9] D. Gonzalez-Arjona, A. Sanchez, A. de Castro, J. Garrido. Occupancy-grid
indoor mapping using FPGA-based mobile robots, in Conference on Design of
Circuits and Integrated Systems (DCIS 2011). Albufeira (Portugal), 2011.
[10] M. S. Miah, W. Gueaieb. Indoor robot navigation through intelligent proces-
sing of RFID signal measurements, in International Conference on Autonomous
and Intelligent Systems (AIS 2010), pp. 1-6, 2010.
[11] M. Idris, S. Bakar, E. Tamil, Z. Razak, N. Noor. High-speed shortest path
co-processor design, in Third Asia International Conference on Model ling &
Simulation, pp. 626-631, 2009.
[12] I. Kamon, E. Rivlin. Sensory-based motion planning with global proofs, in
IEEE Transactions on Robotics and Automation, vol. 13, n. 6, 1997.
[13] M. Buckland. Programming Game AI by Example. Wordware Publishing,
pp. 193-248, 2005.
[14] H. D. Parag, B. D. Himanshu. Design and Analysis of Algorithms. Pearson
Education, pp 312-321, 2007.
[15] X. Deng. Combining breadth-rst with depth-rst search algorithms for VLSI
wire routing, in International Conference on Advanced Computer Theory and
Engineering (ICACTE 2010). vol. 6, pp. 482-486, 2010.
[16] U. Bondhugula, A. Devulapalli, J. Fernando, P. Wycko, P. Sadayappan. Pa-
rallel FPGA-based all-pairs shortest paths in a directed graph, in IEEE Inter-
national Symposium on Paral lel and Distributed Processing, 2006.
[17] J. Ma, K. D. Li, L. Y. Zhang. A Parallel Floyd-Warshall algorithm based
on TBB , in IEEE International Conference on Information Management and
Engineering (ICIME 2010), pp. 1-5, 2010.
70
Bibliografa
[18] A. Selamat, M. Zolfpour-Arokhlo, S. Z. Hashim. A fast path planning algo-
rithm for route guidance system, in IEEE International Conference on Systems,
Man, and Cybernetics (SMC 2011), pp. 2773-2778, 2011.
[19] M. Langerwisch, B. Wagner. Dynamic path planning for coordinated motion of
multiple mobile robots, in IEEE International Conference on Intel ligent Trans-
portation Systems (SMC 2011), pp. 1989-1994, 2011.
[20] K. Grant, D. Mould. Combining heuristic and landmark search for path plan-
ning, in Proceedings of the Conference on Future Play: Research, Play, Share,
pp. 9-16 , 2008.
[21] T. Goto, T. Kosaka, H. Noborio. On the heuristics of A* or A algorithm in ITS
and robot path-planning, in IEEE/RSJ International Conference on Intel ligent
Robot and Systems (IROS 2003), pp. 1159-1166, 2003.
[22] N. Yu, C. Ma. Mobile robot map building based on cellular automata,
in Pacic-Asia Conference on Circuits, Communications and System (PACCS
2011), pp. 1-4, 2011.
[23] S. M. Sharef, W. K. Said, F. S. Khoshaba. A rule-based system for trajec-
tory planning of an indoor mobile robot, in International Multi-Conference on
Systems Signals and Devices (SSD 2010), pp. 1-7, 2010.
[24] B. Bollobs. Modern Graph Theory. Springer, pp. 252-259, 1998.
[25] A. Glassner. Graphic Gems Package: Graphics Gems, vol. 1, pp. 99, 1990.
71
Agradecimientos
Primero quiero dar las gracias a todo el personal del Laboratorio HCT: Javier Ga-
rrido, Angel, Fernando, Alberto, David, Guillermo, Susana y Javier Tejedor. Me
habis transmitido un gran sentido de la hospitalidad y, a la vez, habis tenido una
enorme paciencia conmigo. Sin vosotros esta aventura acadmica en el extranjero no
hubiera sido la misma.
Gracias al director de la tesis, Dr. Fernando Jess Lpez-Colino, por haberme sacado
de mil y un apuros, incluso a veces recorriendo a su varita mgica de informtico
puro y duro. Har tesoro de tus preciosos consejos profesionales.
Un gracias especial va a mi chica, Carolina, por haberme sujetado en todos los mo-
mentos difciles y por sus constantes revisiones ortogrcas de este Trabajo Fin de
Master, te quiero Doctora.

Dikjtra Start

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Dikjtra Start

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD AUTNOMA DE MADRID

Escuela Politcnica Superior

se aade al listado de aristas de coste mnimo y

. Dicha cola representa la frontera

(A-star) [4]. La diferencia principal entre los A

: en la primera variante, conocida como heu-

uno de los dos obstculos candidatos (de

es representado por el Obstculo[5], aunque nos

] representa, junto con la posicin actual

] se visitan sus cuatro vecinos ortogonales a un paso

] se encuentre en el borde), excluyendo adems

uno de los dos. El esquema

] de rodeo, marcados con sus identi-

(nada que hacer. . . )

[i] en el rbol, siempre existen,

[s] y el nodo destino Nodo

[i] T, i / = {s, t} Arista

También podría gustarte