MODELO DE PROTOCOLO DE COMUNICACIONES ENTRE ROBOTS …repository.udistrital.edu.co/bitstream/11349/5267/1... · 2019-08-14 · MODELO DE PROTOCOLO DE COMUNICACIONES ENTRE ROBOTS MÓVILES,

MODELO DE PROTOCOLO DE COMUNICACIONES ENTRE ROBOTS MÓVILES, PARA LA PLANEACIÓN DE RUTAS DE NAVEGACIÓN,

USANDO TEORÍA DE NODOS

Tesis Presentada Para Obtener El Título De Magister en ciencias de la información y las telecomunicaciones,

Universidad Distrital, Bogotá

Andrés Alexander Rodríguez Fonseca Enero 2017.

ii

Copyright © 2017 por Andrés Rodríguez. Todos los derechos reservados.

iiiDedicatoria

A mi esposa e hijos por su amor, paciencia y apoyo, a mis padres y profesores por su valiosa ayuda.

iv

Resumen

El presente documento busca dar un enfoque diferente a la planeación de rutas de desplazamiento en robots móviles.

El principal objetivo es la introducción del enrutamiento, usando por las redes de comunicaciones, al proceso de planeación de rutas de navegación (path planning) en robots que actúan en grupo. Modelando un protocolo de enrutamiento, basado en teoría de nodos, se busca la planeación de rutas de navegación, que tenga en cuenta la información publicada por cada miembro de la red.

v

Tabla de Contenidos

Capítulo 1 ........................................................................................................................................ 1

1.1 Introducción .......................................................................................................................... 1

1.2 Antecedentes ......................................................................................................................... 1

Capítulo 2 ........................................................................................................................................ 3

Planteamiento del Problema ....................................................................................................... 3 Capítulo 3 ........................................................................................................................................ 4

Objetivos ..................................................................................................................................... 4

3.1 Objetivo General ............................................................................................................... 4

3.2 Objetivos Específicos........................................................................................................ 4 Capítulo 4 ........................................................................................................................................ 5

Marco Teórico ............................................................................................................................. 5

4.1 Path Planning (Planeación de Rutas) ................................................................................ 5 4.2 Teoría de Nodos o Grafos ................................................................................................. 6 4.3 Protocolos de Enrutamiento en redes MANET, ............................................................... 7 4.3.1 Métricas en protocolos aplicables a MANET ................................................................ 8 4.3.2 Protocolos más usados ................................................................................................. 10 4.3.3 Protocolos OLSR y AODV .......................................................................................... 10

Capítulo 5 ...................................................................................................................................... 14

Congruencia y Metodología ...................................................................................................... 14 5.1 Fase 1 Simulación ........................................................................................................... 14

5.2 Fase 2 Métricas del protocolo ......................................................................................... 14 5.3 Fase 3 Modelado y simulación de algoritmo .................................................................. 14 5.4 Fase 4 Comparación y resultados .................................................................................. 14

Capítulo 6 ...................................................................................................................................... 16

Diseño y Modelado ................................................................................................................... 16

6.1 Fase 1 Simulación ............................................................................................................... 16

6.1.1 Selección de Herramienta de Simulación .................................................................... 16 6.1.2 Herramientas de Simulación Más Usadas .................................................................... 17 6.1.2.1 Distribución Linux con protocolos Ad-Hoc ............................................................. 17 6.1.2.2 GNS3......................................................................................................................... 17

6.1.2.3 OPNET (RIVERBED) .............................................................................................. 17 6.1.2.4 NS3 ........................................................................................................................... 18

6.1.2.5 NS2 ........................................................................................................................... 18

6.1.3 Comparación y Elección de Herramienta .................................................................... 19 6.1.4 Selección de algoritmo de enrutamiento base .............................................................. 20 6.1.5 Simulación de algoritmo de enrutamiento ................................................................... 21 6.1.5.1 Programación TCL.................................................................................................... 21 6.1.5.2 Script .tcl: Red Mobile Ad-Hoc con protocolo AODV ............................................ 22

6.1.5.3 Resultado de simulación ........................................................................................... 26 6.1.5.3.1 Simulación grafica Network Animator NAM....................................................... 26

6.1.5.3.2 Trazado de análisis archivo .tr ............................................................................... 28 6.2 Fase 2 Métricas del protocolo ............................................................................................. 30

6.2.1 Métrica: Posición ......................................................................................................... 30

vi6.2.2 Métrica: Movimiento ................................................................................................ 31

6.3 Fase 3 Modelado y simulación de algoritmo ...................................................................... 32 6.3.1 Modelo Matemático ......................................................................................................... 32

6.3.1.1 Etapas del modelo matemático. ................................................................................ 32 6.3.1.2 Diagrama de flujo del modelo................................................................................... 33 6.3.2 Simulación en Matlab .................................................................................................. 34 6.3.2.1 Simulación ................................................................................................................ 34

6.3.3 Simulación en NS-2 ......................................................................................................... 35

6.3.3.1 Simulación ................................................................................................................ 36

6.4 Fase 4 Comparación y resultados ...................................................................................... 38 Capítulo 7 ...................................................................................................................................... 39

Pruebas y Resultados ................................................................................................................... 39

7.1 Protocolo de pruebas. ...................................................................................................... 39 Capítulo 8 ...................................................................................................................................... 54

8.1 Conclusiones y Recomendaciones .......................................................................................... 54 8.2 Trabajos de investigación que complementan o se desprenden de esta investigación: .......... 55

9. Lista de referencias ................................................................................................................... 56

10. Apéndices ................................................................................................................................ 60

10.1 Apéndice A: Instalación de NS-2 ..................................................................................... 60 10.1.1 Instalación y Puesta en Marcha de NS-2 ................................................................... 60

10.2 Apéndice B: Adición de protocolos a NS-2 ...................................................................... 62 10.2.1 Configuración de protocolo NAODV en NS-2 .......................................................... 62

10.3 Apéndice C Algoritmos .................................................................................................... 68 10.3.1 Algoritmo en Matlab .................................................................................................. 68 10.3.2 Algoritmo en NS-2 ..................................................................................................... 70

viiLista de tablas

Tabla 1. Comparación de herramientas de simulación. ................................................................ 19 Tabla 2. Comparación de protocolos de enrutamiento. ................................................................ 20 Tabla 3 Captura de línea 4930 archivo .tr ..................................................................................... 29

viiiLista de figuras

Figura 1. Homólogo de red robot con red de computadores (Choregraphe, GNS3) ...................... 2

Figura 2. Ejemplo de un grafo(Vega, 2013) ................................................................................... 6 Figura 3. Resumen de los clases y protocolos de redes adhoc (L.A.Latiff, N. Fisal, 2010) .......... 7

Figura 4. Nodos MPR (Abolhasan et al., 2004) ........................................................................... 11 Figura 5. Parte superior simulación en NAM de la posición de inicio partido B.Human Vs Nao Team imagen inferior.(RoboCup.org, 1999) ................................................................................ 24 Figura 6. Conexión TCP entre nodos 2 y 1 y nodos 4 y 0 a través de 1, simulación NAM. ........ 27

Figura 7. Mensaje de broadcast del nodo 2 buscando alcanzar el nodo 1. ................................... 27 Figura 8. Contenido de archivo .tr ejecutado con bloc de notas. .................................................. 28 Figura 9. Estructura de archivo .tr (Issariyakul, Teerawat & Hossain, 2013) .............................. 29 Figura 10. División del campo de futbol, en cuatro espacios topológicos. .................................. 30 Figura 11. Dos equipos de robots Nao (Rojo y azul), circulo naranja balón, flechas moradas posibles rutas para el balón, flechas rojas mejor ruta ................................................................... 31 Figura 12. Modelo matemático del sistema donde los cambios de zona están regidos por la métrica de movimiento y el nodo final. ........................................................................................ 32 Figura 13. Diagrama de flujo del modelo. ................................................................................... 33 Figura 14. Representación gráfica de las matrices aleatorias programadas en Matlab. ............... 34

Figura 15. Ruta generada por el algoritmo en Matlab .................................................................. 35 Figura 16. Distribución de nodos en NS-2.................................................................................... 36 Figura 17. Solicitud RRT del nodo 3 y recepción de la misma del nodo 0 .................................. 36

Figura 18. Recepción de métrica por el nodo 3 de parte del nodo 4............................................. 37 Figura 19. Ruta calculada en NS-2 ............................................................................................... 38

Figura 20. Minuto 3:24 Nao Team tiene el balón ........................................................................ 39 Figura 21. Minuto 3:14 simulado en NS-2 ................................................................................... 40 Figura 22. Ruta propuesta por el protocolo .................................................................................. 40 Figura 23. Minuto 3:24 Desenlace jugada 1 minuto 3:14 ............................................................. 40 Figura 24. Minuto 13:37 Nao Team posee el balón ...................................................................... 41 Figura 25. Minuto 13:17 simulado en NS-2 ................................................................................. 41 Figura 26. Ruta propuesta por el protocolo. ................................................................................. 42 Figura 27. Minuto 13:39 Desenlace jugada 2 minuto 13:37 ......................................................... 42 Figura 28. Minuto 19:41 segundo tiempo. .................................................................................... 43 Figura 29. Minuto 19:41 simulado en NS-2 ................................................................................. 43 Figura 30. Ruta propuesta por el simulador .................................................................................. 44 Figura 31. Minutos 19:44, 19:50 desenlace jugada 3 ................................................................... 44 Figura 32. Minuto 2:36 B-Human Vs U. Australia ...................................................................... 45 Figura 33. Minuto 2:36 simulado en NS-2 ................................................................................... 45 Figura 34. Ruta propuesta por el simulador .................................................................................. 46 Figura 35. Minuto 2:43 desenlace jugada 4 .................................................................................. 46 Figura 36. Minuto 5:57 B-Human Vs U. Australia ...................................................................... 47 Figura 37. Minuto 5:57 simulado en NS-2 ................................................................................... 47 Figura 38. Ruta propuesta por el simulador .................................................................................. 48 Figura 39. Minuto 6:05 desenlace de la jugada 5. ........................................................................ 48 Figura 40. Minuto 7:07 B-Human Vs UT Austin ......................................................................... 49 Figura 41. Minuto 7:07 simulado en NS-2 ................................................................................... 49

ixFigura 42. Ruta propuesta por el simulador ............................................................................... 50

Figura 43. Minuto 7:17 desenlace de la jugada 6 ......................................................................... 50 Figura 44. Jugada planeada N1 posee el balón. ............................................................................ 51 Figura 45. Simulación en NS-2, jugada planeada ......................................................................... 51 Figura 46. Ruta calculada por el simulador. ................................................................................. 52 Figura 47. Jugada planeada N3 posee el balón. ............................................................................ 52 Figura 48. Ruta calculada por el simulador .................................................................................. 52 Figura 49. Jugada planeada N2 posee el balón ............................................................................. 53 Figura 50. Ruta calculada por el simulador .................................................................................. 53 Figura 51. Captura de pantalla VMware con sistema operativo Ubuntu 11.04 LTS .................... 60

Figura 52. NS 2 instalado correctamente, captura de pantalla terminal Ubuntu. ......................... 61

Figura 53. Captura almacenamiento de protocolo en NS-2 ......................................................... 62

1

Capítulo 1 1.1 Introducción

La evolución en los procesos industriales exige tareas cada vez más complejas y peligrosas a corto y mediano plazo para el ser humano. Con el desarrollo de máquinas autónomas (Robot) capaces de realizar tareas, dicho riesgo se ve mitigado, sin embargo las exigencias en cuanto a desempeño y proceso, sobre las maquinas requiere buscar nuevos caminos de desarrollo de software en pro de mejores resultados, intentando dotar de inteligencia dichas máquinas. El desarrollo tecnológico en el campo de la robótica ha sido notorio, robots humanoides como NAO de la compañía francesa Aldebaran Robotics, los cuales poseen 25 grados de libertar y más de 10 sensores de diferentes tipos(Maisonnier, 2015) simulan en gran medida la movilidad humana. Maquinas tan sofisticas operan en grupos para aplicaciones sumamente complejas como por ejemplo: El futbol robot(Mackworth, 2015) donde es vital el trabajo en conjunto y los robots están en constante movimiento. La motivación de este proyecto es buscar una visión diferente a la planeación de rutas de movimiento, al realizar dicha tarea en conjunto, aplicando el proceso de enrutamiento que usan las redes de comunicaciones, diseñando un protocolo de enrutamiento basado en teoría de nodos el cual será aplicado a la comunicación WiFi que incorporan los robots. 1.2 Antecedentes

Los robots ya no son las maquinas del futuro, son usados desde hace varios años, el primer robot usado en la industria con una visión de inteligencia artificial, fue Shakey 1978 un brazo robot que fue empleado para clasificar piezas (Romero, 2009). Las aplicaciones son innumerables, sin embargo siempre fueron tareas puntuales en la industria o en el hogar.

Con los avances tecnológicos en el diseño de micro-procesadores, se generó un auge en el diseño de robots, ya que con estos dispositivos es posible embeber algoritmos muy estructurados y sofisticados, con los cuales el robot raya en la inteligencia artificial, disciplina que aun continua en desarrollo (Brunette et al., 2009), y es el campo de acción de muchos investigadores alrededor del mundo(Mackworth, 2015).

El hardware para robótica está casi listo llegando a robots que simulan en gran medida la movilidad y capacidad humana(Maisonnier, 2015), por lo cual las necesidades de la robótica están en el software.

2

Las ramas de investigación en el desarrollo de software - algoritmos para robótica son muchas, pero la que motiva la presente investigación es el PATH PLANNING, planeación o diseño de rutas de navegación.

Los resultados en este campo saltan a la vista con algoritmos muy complejos que aplican métodos matemáticos como Monte Carlo, Filtro de Kalman, Método Difuso, triangulación etc.(Martin, Barrera, Rob, Rey, & Carlos, 2006)(Gallardo et al., 1990)(De la Puente, 2007).

Sin embargo todos son algoritmos individuales que corren sobre el robot y las aplicaciones actuales requieren trabajo en conjunto (Mackworth, 2015), por lo cual esta investigación se encamina a modelar un algoritmo enrutamiento que genere la trayectoria, que deberá seguir el robot para cumplir su tarea de forma homologa a las redes de comunicaciones con sus algoritmos de enrutamiento para el transporte de paquetes de información.

Figura 1. Homólogo de red robot con red de computadores (Choregraphe, GNS3)

3

Capítulo 2 Planteamiento del Problema

En aplicaciones donde los robots actúan en grupos se viene introduciendo métodos de posicionamiento y navegación como Markov en espacios topológicos y los resultados han sido bastante notorios (Martin et al., 2006), dado que en muchas aplicaciones, donde los robots actúan en grupo una localización muy fina no es necesaria, ya que hay multitud de posiciones de un entorno y el robot debe realizar las misma acciones. Simplificar la precisión de la localización reduce notoriamente la cantidad de información a procesar y le quita carga al sistema computacionalmente hablando.(Farber, 2005) La creación de algoritmos basados en modelos topológicos para planeación de rutas a seguir en un entorno, supone un acercamiento muy complejo de la matemática teórica a la aplicada. Sin embargo las rutas son planeadas de forma autónoma y no se ve un trabajo en grupo y la comunicación entre robot para la planeación de rutas es nula. Un referente mundial en el desarrollo de la robótica es la copa robot (RoboCup) modalidad humanoides NAO (Mackworth, 2015)(Maisonnier, 2015), allí se pone en competencia el trabajo de muchos investigadores de doctorado y maestría, sin embargo sus desarrollos en comunicaciones entre robots se encaminan a simular la comunicación humana, donde los robots se comunican en el campo de juego de forma verbal. Dejando de lado la telemática posee el robot. Dadas las características de confiabilidad, seguridad y velocidad, es viable usar la telemática incorporada como medio de comunicación entre robos. Lo cual le da cabida a la presente investigación, al tomar como base un algoritmo de enrutamiento para redes Ad-Hoc móviles y modelar un algoritmo que planeo las rutas de navegación física.

4

Capítulo 3 Objetivos

3.1 Objetivo General Diseñar y simular un algoritmo de enrutamiento para la planeación de rutas en robots móviles basado en teoría de nodos

3.2 Objetivos Específicos • Modelar un algoritmo de enrutamiento en una red WiFi sin punto de acceso. • Modelar la valoración de la posición de cada robot dadas las características de su

entorno como una métrica anunciada por el robot a la red. • Modelar un algoritmo de enrutamiento que pondere como métrica la posición de

cada robot basado en teoría de Nodos y genere rutas. • Diseñar y aplicar un protocolo de validación donde se compara el algoritmo

propuesto con un método que tenga buenos resultados en la práctica.

5

Capítulo 4 Marco Teórico

4.1 Path Planning (Planeación de Rutas) Básicamente la planificación de rutas de desplazamiento en robots (Robot Motion Planning RMP) busca encontrar un camino libre de colisiones desde un punto de inicio a un punto de llegada, sobre un espacio de trabajo que contiene múltiples obstáculos. Sin embargo, en muchas aplicaciones un camino hacia un punto de llegada no basta con evitar colisiones con obstáculos, dado que cabe la posibilidad de manipular objetos de bloqueo. Con lo cual las posibilidades para llegar a una meta son muchas. A demás en algunos casos particulares no existe ninguna ruta viable hacia el objetivo a menos que alguna obstrucción sea reubicada en el campo de acción. Desplazar obstáculos en la planificación de movimiento puede ser la línea que separa las tareas básicas y las de alto complejidad y ahondar en el área de investigación de sistemas integrados de planificación para robots autónomos. Con lo cual robots capaces de que realizan tareas de manipulación y de navegación son útiles en cualquier campo de aplicación. (Moghaddam & Masehian, 2016) En los últimos treinta años el path plannig ha dado lugar a una gran variedad de métodos de planificación de la ruta. La elección de un algoritmo de planificación de la trayectoria apropiado, depende en gran medida del modelo del medio ambiente. (Kruusmaa, 2003) Dichos modelos generalmente se dividen en dos categorías: Modelos topológico (ruta, cualitativos) y Modelos métricos (posición, basada en la cuadricula). Modelos Topológicos están representados en grafos donde los nodos representan lugares distintos y los bordes representan las relaciones entre ellos. Los gráficos de visualización o los diagramas de Voronoi entran en esta categoría de planificación de trayectoria basada en grafos. (Takahashi & Schilling, 1989) Los modelos métricos suelen representar el campo en forma de mapas con una malla regular o de multi - resolución o árbol de datos. La familia más popular de método de planificación de trayectoria en malla es: frente de onda wavefront. (Kruusmaa, 2003)(De la Puente, 2007) Existen dos problemáticas que se deben afrontar cuando se opera con modelos de mapas basados en mallas. El primer problema de debe a la carga computacional que se requiere cuando se modelan ambientes muy grandes lo cual no es apropiado para aplicaciones en tiempo real. El segundo problema se debe presenta cuando el entorno no tiene una estructura uniforme y elegir el tamaño de la cuadrícula se convierte en polémica. Si se elige una malla grande la planificación de rutas es más rápido, pero como se debe tratar con obstáculos se debe amplían el detalle de la red.

6

Por otro lado, si la rejilla es demasiado fina, la planificación de la trayectoria es demasiado lenta. Asimismo, no hay necesidad de una muy planificación precisa en entornos cambiantes, donde se elige otra la ruta, si se producen obstáculos inesperados. (Martin et al., 2006)(Kruusmaa, 2003). 4.2 Teoría de Nodos o Grafos La teoría de grafos o nodos es una rama de la Topología aplicable a campos tan diversos como la química, la biología, la sociología o la teoría de redes. Se denomina grafo G al par de conjuntos V(G) y E(G), donde V(G) es un conjunto de vértices o nodos y E(G) es un conjunto de aristas, pares de elementos de V(G). La figura 1 muestra a modo de ejemplo un grafo G formado por el conjunto de nodos V(G)={,u,v,w,z} y por el conjunto de aristas E(G)={(u,w), (w,v), (w,x), (w,w), (v,x), (v,x)}.

Figura 2. Ejemplo de un grafo(Vega, 2013)

Se dice que dos nodos son adyacentes si el grafo contiene al menos una arista que los une. Del mismo modo, dos aristas son adyacentes si poseen un vértice en común. El grado de un vértice v, denominado g(v), es el número de aristas de un grafo que inciden en v. Los vértices de grado 0 reciben el nombre de vértices aislados, mientras que los de grado 1 se denominan vértices terminal o extremo. Un lazo es una arista que tiene tanto como origen como por destino un nodo v, y contribuye de manera doble al grado de v. En el ejemplo de la figura 2, la arista ww se trata de un lazo. Un subgrafo de un grafo G es grafo cuyos vértices y aristas pertenecen a V(G) y E(G) respectivamente.(Vega, 2013)

7

4.3 Protocolos de Enrutamiento en redes MANET, El auge y expansión de las comunicaciones móviles da lugar a la aparición de las redes MANET (Redes Móviles Ad Hoc), redes simples, inalámbricas y de uso temporal en lugares donde no se cuenta con infraestructura de red y es necesario el intercambio de información entre los miembros de la red. Lo cual solo es posible incorporando una serie de protocolos de enrutamiento característicos de este tipo de redes ya que no son aplicables los protocolos para redes fijas (Lara, 2014). Dichos protocolos serán el objeto de estudio comparando parámetros de interés.

Figura 3. Resumen de los clases y protocolos de redes adhoc (L.A.Latiff, N. Fisal, 2010)

Generalmente, hay dos etapas diferentes en el enrutamiento; que son de descubrimiento de ruta y de reenvío de datos. En el descubrimiento de ruta el destino se encuentra mediante la difusión de la consulta. Una vez se ha establecido la ruta, el envío de datos se inicia a través de las rutas que se han determinado. Los nodos que reciben la consulta la difunden a todos los vecinos, por tanto se transmite gran número de mensajes de control. Lo cual se complica aún más si los nodos se mueven y nuevas rutas deben ser recalculadas.(Chlamtac, Conti, & Liu, 2003) Los protocolos de enrutamiento de dividen en dos grandes categorías “Topology-based” y “Position-based”. Los cuales hacen referencia a la topología de red, con base a la información de los enlaces de la red y la información física acerca de los nodos participantes, respectivamente. (L.A.Latiff, N. Fisal, 2010) Los protocolos o algoritmos de enrutamiento basados en la topología a su vez se dividen en proactivos, reactivos o hibrido. Proactivos: Esta clasificación hace referencia a la capacidad de mantener actualizada las tablas de enrutamiento a través de envíos de paquetes en intervalos de tiempo fijos, lo cual

8

es bueno al tener disponibles rutas en todo momento, pero la desventaja está en invadir el ancho de banda del canal. Reactivos: Invocando un procedimiento para determinar el correcto direccionamiento sólo en el momento en el que el paquete deba efectivamente transmitirse. De este modo, se reduce el tráfico de señalización en detrimento de un aumento de los tiempos de entrega. Hibrido: Como dice su nombre, busca unir las ventajas de ambos protocolos precedentes, limitando la aplicación de algoritmos proactivos sólo a los nodos adyacentes del que quiere transmitir.(Rahman & Zukarnain, 2009) Por su parte los protocolos basados en la posición física se dividen en reenvío codicioso e inundación restringida. Reenvío codicioso: Serán seleccionados los nodos que tienen el mejor progreso y el paquete de datos se remitirán a estos nodos. Idealmente, este proceso se repite hasta que el paquete llegue al destino, cabe destacar que no hay descubrimiento de ruta en el reenvió codicioso. Inundación restringida: Para mitigar el problema de broadcast sólo unos nodos en la dirección del destino participará en el descubrimiento de ruta hasta que se encuentra la ruta de destino. La participación de los nodos de enrutamiento optimizará la radiodifusión en MANET. Inundación restringida transmite mensajes a un número seleccionado de nodos que es por lo general, los que se encuentran más cerca del destino. Esto reduce significativamente no sólo el consumo de energía, sino también la probabilidad de colisiones de paquetes.(L.A.Latiff, N. Fisal, 2010) 4.3.1 Métricas en protocolos aplicables a MANET Las métricas son parámetros de comparación que posibilitan la elección de la ruta más conveniente para la transmisión de los datos. Las más utilizadas son las métricas basadas en la topología de la red y aquellas que se basan en la utilización de mediciones de sondeo activo.(Coya, Lucy & Ledesma, Talia & Garcia, 2014) A continuación se describen: Número de saltos: Su facilidad de implementación ha hecho que sea la métrica más utilizada en cualquier tipo de red. Cada enlace cuenta como una unidad, y el peso del trayecto es igual al número total de nodos que se encuentren en este. El fundamento para minimizar la métrica del número de saltos es sencillo. Menos saltos en la ruta de datos deben implicar una menor demora, un mayor throughput y menos desperdicio de recursos de red sin importar las características técnicas de enlace. (Georgios Parissidis, Merkourios Karaliopoulos & Thrasyvoulos Spyropoulos, 2009) Signal Strength: La intensidad de señal se ha utilizado como métrica de calidad del enlace en varios esquemas de direccionamiento inalámbricas en malla. La hipótesis es: Se recibe un paquete con éxito cuando la potencia de la señal supera un cierto valor umbral, la potencia de la señal podría ser vista como un buen indicador de la calidad del enlace. Las tarjetas de red inalámbricas básicas proporcionan un valor de intensidad de señal media

9

recibida por cada paquete recibido con éxito. Los valores de intensidad de señal se han utilizado en el enrutamiento de dos maneras diferentes: • Como parámetros de control para la exclusión de rutas con "mala" calidad del enlace. • Como métrica de enrutamiento convencional, en la función de coste se toma como uno de los parámetros de entrada la intensidad de la señal.(Georgios Parissidis, Merkourios Karaliopoulos & Thrasyvoulos Spyropoulos, 2009) Round Trip Time (RTT) por Salto: Esta métrica refleja la demora bidireccional en un enlace. Para poder medir el RTT, se envía periódicamente a cada nodo vecino un paquete de sondeo con un valor de timestamp, el cual cada nodo retorna inmediatamente. Esta respuesta posibilita que el nodo emisor calcule el valor de RTT. La métrica de trayecto RTT es simplemente la suma de cada uno de los valores de RTT estimados en cada enlace de la ruta. Esta es una métrica dependiente de la carga, ya que abarca las colas, la contención del canal y las demoras de retransmisión. Además de la sobrecarga de la red relacionada al envío de paquetes de sondeo, la desventaja de emplear RTT como métrica de enrutamiento es que puede llevar a una inestabilidad de la ruta (fenómeno de auto-interferencia) (Georgios Parissidis, Merkourios Karaliopoulos & Thrasyvoulos Spyropoulos, 2009) ETX (Expected Transmission Count): Es una de las pocas métricas que se han implementado en la práctica. ETX estima el número requerido de transmisiones (incluyendo las retransmisiones) para enviar un paquete a través de un enlace. Minimizar el número de transmisiones no solo optimiza el throughput general de la red, sino que también minimiza el consumo total de energía y la interferencia resultante. Si �� es la razón de entrega de paquetes hacia adelante y �� la razón de entrega en reversa (por ejemplo, la probabilidad de que la confirmación de un paquete sea transmitida satisfactoriamente), entonces la probabilidad de que un paquete arribe y sea confirmado correctamente es �� × ��, quedando definida la métrica ETX como:

�� =

�× (Singh, Kaur, Sharma, & Malhotra, 2015)

Las razones de entrega son calculadas utilizando paquetes de sondeo de capa de enlace enviados por difusión. El valor de ETX para una ruta se define como la suma de los valores de las métricas de los enlaces que conforman esa ruta. Las principales ventajas de la métrica ETX son su independencia con respecto a la carga del enlace (inmune al fenómeno de auto-interferencia) y que toma en cuenta los enlaces asimétricos. Las desventaja esenciales de la métrica ETX es la sobrecarga de la red debido a la transmisión de los paquetes de sondeo y que esta sólo es relevante para las interfaces de radio que realizan retransmisiones. (Georgios Parissidis, Merkourios Karaliopoulos & Thrasyvoulos Spyropoulos, 2009) ETT (Expected Transmission Time) y WCETT (Weighted Cumulative Expected Transmission Time): La métrica ETX no es óptima bajo algunas circunstancias, por ejemplo, ETX preferirá enlaces altamente congestionados a enlaces libres si la razón de

10

pérdida de paquetes de los enlaces congestionados es menor que la de los enlaces libres, y esto no es deseable. Para afrontar esta dificultad se propuso la métrica ETT, que incorpora el throughput a sus cálculos. Esta métrica depende del tamaño del paquete de sondeo, del ancho de banda medido en un enlace y de la propia métrica ETX. Como muchas tecnologías inalámbricas, incluyendo WiFi, proveen múltiples canales sin solapamiento, se ha propuesto una adaptación de la métrica que toma en cuenta el uso de múltiples canales, denominada Weighted Cumulative ETT (WCETT). Esta métrica utiliza un parámetro ajustable para balancear los pesos, y un número que representa el número de veces que el canal es utilizado o se ha experimentado interferencia intra-flujo en ese canal. WCETT define un menor costo para las rutas que utilizan canales más diversificados con menos interferencia intra-flujo. (Georgios Parissidis, Merkourios Karaliopoulos & Thrasyvoulos Spyropoulos, 2009) 4.3.2 Protocolos más usados Proactivos: DSDV: Destination-Sequenced Distance Vector. OLSR: Optimized Link State Routing. TBRPF: Topology broadcast based on reverse-path forwarding. BATMAN: Better Approach to Mobile Ad hoc Networking DREAM: Distance Routing Effect Algorithm for Mobility(Rey, Odete, Quiñones, & García, 2014) Reactivos: AODV: Ad hoc On demand Distance Vector routing. DSR: Dynamic Source Routing. Híbridos: ZRP: Zone Based Routing Protocol. Reenvío codicioso: SELAR: Scalable energy-efficient location aided. NFP: Nearest Forward Progress. MRF: Most Forward within Radius. Inundación restringida: RTCP: Real-Time Transport Control Protocol. DREAM: A distance effect algorithm for mobility. LAR: Location‐Aided Routin (Abolhasan, Dutkiewicz, & Wysocki, 2004) 4.3.3 Protocolos OLSR y AODV

4.3.3.1 Protocolo OLSR (Optimized Link State Routing) Es un protocolo de encaminamiento proactivo optimizado, diseñado expresamente para redes móviles ad hoc altamente dinámicas y con un ancho de banda limitado. Este

11

protocolo provee de un mecanismo eficiente de inundación (Fooding) de información parcial del estado de la red empleando un conjunto de nodos especiales, los Multipoint Relays (MPR)(Chlamtac et al., 2003). Periódicamente, los MPR intercambian información sobre los enlaces con sus nodos vecinos mediante el envío de mensajes de control de la topología (TC, Topology Control). Cada nodo envía, también de forma periódica, mensajes Hello y MID a sus nodos vecinos (1-hop) para comprobar la existencia de enlace entre ellos.

Figura 4. Nodos MPR (Abolhasan et al., 2004)

Cada nodo determina una ruta óptima (en términos de saltos) a cada destino utilizando la información de la topología (de la tabla de topología y la tabla de vecinos), y almacena esta información en una tabla de enrutamiento. Por lo tanto, las rutas hacia todos los destinos están disponibles inmediatamente cuando la transmisión de datos comienza. (Abolhasan et al., 2004) Los mecanismos del OLSR están regulados por la configuración de un conjunto de parámetros definidos en el OLSR RFC [10] enfocada principalmente para MANETs de propósito general. Los parámetros que más influyen en el rendimiento son: los intervalos de tiempo de espera para el reenvío de los mensajes Hello, MID y TC (HELLO_INTERVAL, REFRESH_INTERVALy TC_INTERVAL, respectivamente); los tiempos límite de validez de la información recibida mediante los tres tipos de mensaje que son NEIGHB_HOLD_TIME (Hello), MID_HOLD_TIME (MID) y TOP_HOLD_TIME (TC); el WILLINGNESS o predisposición de los nodos a actuar como MPR; y el tiempo máximo que los MPR almacenan información sobre los paquetes enviados para evitar el reenvío de duplicados (DUP_HOLD_TIME). (Toutouh, Garcia-Nieto, & Alba, 2010).

12

4.3.3.2 Protocolo AODV (Ad-Hoc On Demand Distance Vector) Es un protocolo de encaminamiento IP basado en DSDV (Destination-Sequenced Distance Vector) y DSR(Dynamic Source Routing) (Abolhasan et al., 2004) que permite a un nodo encontrar y mantener rutas hacia otro nodo la red. AODV es on-demand, o reactivo, en el sentido de que las rutas se establecen sólo cuando se necesitan (cuando la estación origen quiere transmitir datos a un destino). Las decisiones de encaminamiento se hacen usando vectores distancia, es decir distancias medidas en saltos a todos los nodos disponibles. El protocolo soporta unicast y broadcast. Dicho protocolo esta descrito en RFC 3561.(Perkins, 2003) Cada estación mantiene un número de secuencia que guarda un timestamp, y una tabla de encaminamiento que contiene rutas hacia los destinos. Los números de secuencia se usan para determinar si una ruta es actual (cuanto mayor sea el número, más actualizada está la ruta; el más antiguo puede descartarse) y con ellos el protocolo se asegura de que no hay bucles. Cada entrada de la tabla contiene la dirección del siguiente salto (siguiente nodo hacia el destino), un contador de saltos (número de saltos hacia el destino) y un destination sequence number. Ya que es un esquema de vector-distancia on-demand, los nodos mantienen las distancias de aquellos destinos con los que necesitan contactar o transmitir información. Cada ruta activa se asocia con un tiempo de vida almacenado en la tabla; cuando este tiempo finaliza, la ruta se marca como inválida y después se borra de la tabla para no sobrecargarla. AODV usa dos procedimientos principales, el descubrimiento de rutas y el mantenimiento de rutas,

4.3.3.2.1 Descubrimiento de rutas: Si el nodo fuente necesita una ruta a un destino, envía por broadcast un mensaje ROUTE REQUEST (RREQ). Cada nodo también guarda un identificador de broadcast que, junto con la direción IP del origen, identifica unívocamente a un RREQ. Cada vez que el emisor emite un RREQ, incrementa en uno su identificador de broadcast y el número de secuencia. Además, almacena este RREQ durante un tiempo PATH DISCOVERY TIME (PDT), y así no lo vuelve a procesar si un vecino se lo envía de vuelta. El emisor espera durante un tiempo NET TRAVERSAL TIME (NETT) a que le llegue un mensaje ROUTE REPLY (RREP). Si no se recibe un RREP durante este tiempo, volverá a mandar por broadcast otro RREQ hasta un número de veces RREQ TRIES. Con cada intento adicional, el tiempo de espera (NETT) se duplica. Cuando una estación recibe un mensaje RREQ que no ha visto con anterioridad, configura una ruta de vuelta a la estación de la que proviene el RREQ. Esta ruta de vuelta tiene un valor de tiempo de vida ACTIVE ROUTE TIMEOUT (ART). La entrada en la tabla correspondiente a la ruta de vuelta se almacena con la información de la dirección de destino requerida. Si la estación que recibe este mensaje no tiene una ruta al destino, reenvía por broadcast el RREQ. Cada estación guarda el número de saltos que ha hecho el mensaje y también qué estación ha reenviado el RREQ. Si una estación recibe un RREQ que ya ha procesado, lo descarta y no lo reenvía.

13

Si una estación tiene una ruta a un destino, contesta enviando por unicast un mensaje RREP a la estación de la que recibió el mensaje de petición. Como el RREP se propaga de vuelta a la estación fuente, las estaciones configuran punteros hacia el destino. Cuando la estación fuente recibe el RREP, la ruta se ha establecido y los paquetes de datos pueden enviarse al destino. Opcionalmente, la estación origen puede emitir un mensaje RREP-ACK al destino para asegurarse de la fiabilidad del camino bidireccional.

4.3.3.2.2 Mantenimiento de rutas: La función del mantenimiento de rutas es proporcionar un feedback al sender en caso de que un nodo o un enlace se rompa, y así la ruta puede modificarse o redescubrirse. Una ruta puede dejar de funcionar simplemente porque uno de sus nodos se mueva. Si se mueve un nodo fuente, debe informar a todos los vecinos que necesiten este salto. Este mensaje se reenvía a todos los otros saltos y la ruta obsoleta se borra. El nodo origen debe descubrir una nueva ruta. Una forma para que una estación guarde información de sus vecinos es usando mensajes HELLO. Estos se envían periódicamente para detectar fallos en los enlaces. Cuando se recibe una notificación de enlace roto, la estación fuente puede reiniciar el proceso de descubrimiento de rutas. Si hay un enlace roto, puede enviarse por broadcast un mensaje ROUTE ERROR (RERR) a la red. Cualquier nodo que recibe el RERR, invalida la ruta y reenvía por broadcast los mensajes de error con el destino inalcanzable a todos los nodos de la red.(Pastor, 2008)

14

Capítulo 5 Congruencia y Metodología

El proyecto se llevara a cabo en cuatro fases con las cuales se abordaran los objetivos propuesto de la siguiente manera: 5.1 Fase 1 Simulación 5.1.1 Objetivo 1: Modelar un algoritmo de enrutamiento en una red WiFi sin punto de acceso. El cual se desarrolla en la primera fase que consta de 4 etapas, partiendo de la selección del software de simulación de redes Ad-Hoc. En esta etapa la investigación se centrar en buscar el software más adecuado para simular la red Ad-Hoc, el cual debe ser de código abierto dadas las necesidades del proyecto. La siguiente etapa se centra en los protocolos que corren sobre dicha red y sus características, dado que va a ser el punto de partida del protocolo propuesto. La siguiente etapa se encamina en investigar las posibilidades que posee el software de simulación para ser programado y los lenguajes de programación que maneja y la última etapa busca seleccionar el software definitivo de simulación basado en los resultados de investigación generados por las etapas anteriores. 5.2 Fase 2 Métricas del protocolo 5.2.1 Objetivo 2: Modelar la valoración de la posición de cada robot dadas las características de su entorno como una métrica anunciada por el robot a la red. El cual se desarrolla en la segunda fase que consta de 3 etapas, partiendo de la información necesaria. En esta etapa la investigación se centrar en buscar que información deberá publicar el robot o será relevante al momento de seleccionar la ruta. La siguiente etapa se centra en valorar dicha información de tal manera que sea manejada como una métrica. Al tener valorada la información cada robot será tomado como un nodo que posee dicho valor y se procede con la última etapa de esta fase en donde se aplica la teoría de nodos como un selector de la mejor forma de saltar entre nodos. 5.3 Fase 3 Modelado y simulación de algoritmo 5.3.1 Objetivo 3: Modelar un algoritmo de enrutamiento que pondere como métrica la posición de cada robot basado en teoría de Nodos y genere rutas. El cual se desarrolla en la tercera fase que consta de 3 etapas, partiendo de los protocolos de enrutamiento usados en las redes AD – HOC para ver sus características y modelos matemáticos. La siguiente etapa se centra en investigar cuales de dichos protocolos son de código abierto, la forma de programación de los mismos y las posibilidades de reprogramación y adaptación a las necesidades del proyecto y como última etapa es programado de protocolo de enrutamiento y simulado. 5.4 Fase 4 Comparación y resultados 5.4.1 Objetivo 4: Diseñar y aplicar un protocolo de validación donde se compara el algoritmo propuesto con un método que tenga buenos resultados en la práctica. El cual se desarrolla en la cuarta fase que consta de 3 etapas, partiendo del diseño del protocolo de

15

pruebas. En esta etapa, la investigación se centrar en buscar la mejor forma de comparar dos mundos distintos, como los son los algoritmos individuales (usados actualmente) y los algoritmos en red, en la última fase será contrastado el algoritmo propuesto en esta investigación con el protocolo de validación seleccionado.

16

Capítulo 6 Diseño y Modelado

6.1 Fase 1 Simulación

6.1.1 Selección de Herramienta de Simulación Dados los limitados recursos con los que se cuenta para el desarrollo, las herramientas de simulación son el cimiento para el diseño, ya que facilitan la implementación y estudio de diferentes redes de comunicación, de tamaños variados, proveyendo el comportamiento de diferentes eventos de forma fiel sin tener que implementar los escenarios de forma física.(Katkar, 2016) La simulación no es un concepto nuevo; siempre se ha buscado la manera de evaluar sistemas complejos, la simulación es la ejecución de un modelo representado por un algoritmo sobre computadora.(Morales, Calle, Tovar, & Cuéllar, 2013). Para la selección general de herramientas de simulación se suelen tener en cuenta características como:

• Mejora la validación del comportamiento de protocolos existentes; • Permite el desarrollo de nuevos protocolos; • Brinda la oportunidad de estudiar protocolos a gran escala; • Permite comparar resultados entre diferentes implementaciones de red.(Morales et

al., 2013) En el caso particular de modelar un protocolo de enrutamiento en redes Ad-Hoc móviles, el cual planeara rutas para desplazamientos físicos las características descritas con anterioridad se quedad cortas, por lo cual los requerimientos exigidos en esta aplicación son software con:

• Licencia libre. • Código abierto. • Soporte para redes Ad-Hoc. • Soporte para varios protocolos de enrutamiento para redes Ad-Hoc. • Código abierto y compilación de protocolos de enrutamiento para redes Ad-Hoc. • Facilidad para simular movimiento entre miembros de la red Ad-Hoc, redes

MANET. • Entorno grafico para simulación y estadísticas. • Documentación suficiente. • Un solo pc requerido para ejecutar.

17

6.1.2 Herramientas de Simulación Más Usadas

6.1.2.1 Distribución Linux con protocolos Ad-Hoc Los sistemas operativos que poseen los robots humanoides, son distribuciones Linux (Aldebaran-Robotics., 2016), por lo cual crear una distribución Linux desde cero sobre un pc portátil(Beekmans, 2016) en la cual se instalen y compilen los protocolos de enrutamiento, es una simulación muy cercana a la realidad. Sin embargo requeriré el empleo de varios PCs, tantos como se desee crear la red. Lo cual dificulta la implementación y la simulación de movimiento al tener que desplazar los pc de forma física y eleva los costos del proyecto. 6.1.2.2 GNS3 Software gráfico de simulación de red que permite la emulación de redes complejas. Funciona en simultáneo cargando sistemas operativos emuladores como Vmware o Virtual Box. Además emula los IOS de los dispositivos activos de Cisco, Huawie, HP entre otros. Dynamips, es la base de este software, es el que permite esta tarea. La herramienta corre en ambientes Linux, Windows y Mac. GNS3 no toma el lugar de un router real, pero en ambientes de aprendizaje y preparación, para certificaciones Cisco como CCNA, CCNP y CCIE, se puede emplear como tal. Su interfaz gráfica es muy intuitiva para el usuario. La licencia de esta herramienta es de libre descarga, pero requiere de las imágenes de los dispositivos Cisco para emular su comportamiento, imágenes que se deben adquirir directamente con el fabricante.(Guppy Stephen & Mark, 2016)(Morales et al., 2013) 6.1.2.3 OPNET (RIVERBED) Es una herramienta de simulación que permite flexibilidad y escalabilidad en modelos jerárquicos – los cuales representan estructuras de redes reales y puede ser implementada en sistemas operativos tipo Unix o Windows. Dichos modelos, están divididos en tres dominios, denominados Red, Nodo y Procesos, los cuales están escritos en C++ y poseen su propio editor. Gracias a sus numerosas ventajas y a su poderosa interfaz gráfica, su uso por parte de grupos académicos es alto, puesto que la manera de simular es muy intuitiva; sin embargo, necesita de gran cantidad de conocimientos previos en redes y programación, por lo que su curva de aprendizaje es alta. De otro lado, aunque la licencia del simulador es comercial, existe una versión de este software que no genera cargos económicos, aunque su uso está limitado a actividades netamente académicas. Puesto que OPNET proporciona los mecanismos necesarios para el desarrollo fluido de una simulación, permitiendo arrastrar componentes para conformar topologías configuraron una solución de MPLS VPN activando los diferentes parámetros desde un cuadro de diálogo que ofrece una lista de ellos.

18

OPNET cuenta con características que permiten el estudio de los resultados de simulación. El servicio de análisis consiste en mostrar la información de los resultados de simulación en forma de grafos, presentados dentro de áreas rectangulares llamadas paneles de análisis, los cuales tienen propósitos específicos para presentar o transformar la información. Estos paneles, básicamente, contienen gráficas cartesianas que describen la relación entre diferentes variables, En cuanto a las tecnologías de nivel 2 y 3, hay varias que la herramienta soporta, realizaron las implementaciones de tecnologías WSN (Wireless Network Sensor). (Kennelly Jerry, 2016)(Morales et al., 2013). 6.1.2.4 NS3 Esta herramienta es un simulador de eventos discretos de red, que tiene como principales objetivos lograr un mayor énfasis en las capas 2 y 4 del modelo OSI y que su uso sea principalmente educativo; cabe resaltar que la documentación es limitada. En un principio la compatibilidad con NS-2 no es un objetivo del proyecto, por lo que NS-3 no es una actualización de NS-2, sino un proyecto diferente creado por asociaciones diferentes. Esta herramienta es open-source y permite la inclusión de otro software open-source; es escalable, modular. En relación con la usabilidad y adaptabilidad, NS-3 está escrito solo en C++ lo que lo hace más fácil de depura. Las plataformas que soporta esta herramienta, tanto de escritorio como de servidor, son: Linux, OS X, freeBSD, Solaris y Windows. La interfaz gráfica de esta herramienta soporta algunas formas de animación visual para todo o parte de una simulación. Es una herramienta útil para depurar y mostrar la simulación a terceros. Usa NAM para la animación del escenario de red, que es parte de NS-2 y logra simular visualmente ambientes Ad-Hoc. (Katkar, 2016)(National Science Foundation, 2016)(Morales et al., 2013) 6.1.2.5 NS2 Es una de las herramientas de simulación de eventos discretos de código abierto confiable y de mayor uso en proyectos de a nivel académico e industrial, Dado que presenta diferentes posibilidades que le permiten a sus usuarios realizar diversos tipos de trabajo sobre ella. En relación a que posee licencia GNU, se argumenta la disponibilidad del código fuente tanto para su inspección y modificación, como la libertad para modificar el código fuente de los distintos protocolos que incorpora. Lo cual incentiva el desarrollo de módulos, al interior de la comunidad, que permiten la creación de nuevos protocolos y sistemas para ser simulados. Cabe destacar los dos niveles de configuración y construcción que presenta NS2, el primero hace referencia a la configuración y simulación de redes basados en protocolos y características incorporados en la herramienta, lo cual se realiza con lenguaje TLC, por otro lado la construcción se encamina a la creación de módulos o protocolos no existentes en NS2, los cuales son descritos en C++ o OTLC (TLC orientado a objetos) con los cuales

19

se puede completar o modificar la herramienta. Lo que exige un gran conocimiento para el uso de la misma. Conlleva a poseer un nivel alto en su curva de aprendizaje. NS2 es un simulador visualmente muy pobre, ya que está orientado a programación, sin embargo han realizado varios desarrollos de simulación gráfica para aprovechar la potencia de la herramienta. La herramienta no contiene un entorno gráfico aunque existen otras herramientas, como NAM, que permiten hacerlo, lo cual minimiza el problema y permite aprovechar todos las mediciones que arroja el simulador de las tecnologías manejadas en las capas 2 y 3 de OSI. Tecnologías como: TCP/IP, UDP, FTP, RTP, SRN, GPRS, mobile IPv6, RSRV, MPLS, redes Ah Hoc, WLAN, Mobile-IP, UMTS y Wireless. Otro aspecto resaltable, de la herramienta es su capacidad de instalación en los diversos entornos y plataformas (FreeBSD, Linux, SunOs, Solaris, Windows y Mac OS X).(SARMAN, CONSER, ICIR, 2014)(Lara, 2014)(Spaho, Barolli, Mino, Xhafa, & Kolici, 2011)(Morales et al., 2013). 6.1.3 Comparación y Elección de Herramienta En la tabla 1. Se comparan las herramientas de software descritas con anterioridad. Validando los requerimientos descritos en el apartado “Selección de herramienta de simulación” del presente capitulo. Tabla 1. Comparación de herramientas de simulación.

Características Creación de Distribución Linux + Protocolos Ad-

Hoc GNS3 OPNET NS3 NS2

Licencia libre SI SI NO SI SI Código abierto SI NO NO SI SI Redes Ad-Hoc SI NO SI SI SI

Protocolos Ad-Hoc SI NO SI SI SI Compilación de

protocolos SI NO NO SI SI

Redes MANET NO NO SI SI SI Entorno Grafico NO SI SI SI SI Documentación SI SI SI NO SI

Un PC para ejecutar NO SI SI SI SI

Como se puede observar en la tabla 1 la opción más completa la presenta NS2, por tanto será el programa seleccionado para ejecutar la simulación y el desarrollo. En el apéndice

20

A de este libro, se encuentra a detalle información de instalación y puesta en marcha de NS2 sobre una máquina virtual Ubuntu. 6.1.4 Selección de algoritmo de enrutamiento base Las características de la aplicación (Path Plannig) que se le dará al algoritmo de enrutamiento propuesto, para transportar el balón por la mejor ruta, exige una mirada desde el punto de vista del futbol. Como en (Garganta, 1997) en un partido de futbol ocurren situaciones cuya frecuencia, orden cronológico y complejidad no pueden ser previstas, exigiendo un alto grado de adaptabilidad y respuesta inmediata por parte de los jugadores y los equipos. Esta manera de entender la táctica da especial énfasis a los movimientos y los posicionamientos en el campo dejando percibir la habilidad del jugador para ocupar y / o crear espacios libres en función de los principios tácticos adecuados para esa situación o instante(Teoldo, Garganta, Greco, & Mesquita, 2008). Lo que exige al algoritmo estar dispuesto al cambio y a reaccionar frente a este, características solo cubiertas por protocolos reactivos, dado que luego del cambio y la necesidad de enrutar paquetes, buscan la mejor opción entre las nuevas rutas. Por lo cual se exigen las siguientes características las cuales deben ir de la mano con la herramienta seleccionada.

• Protocolo de código abierto: Ya que será la base para el desarrollo del protocolo propuesto.

• Protocolo reactivo: Dado que es un sistema que dinámico la mejor opción es buscar rutas cuando sea necesario y no estar difundiendo información, si no es necesario.

• Protocolo incorporado en NS-2: Dado que es la herramienta selecciona, al tenerlo incorporado facilita su compilación y uso.

• Protocolo documentado. Tabla 2. Comparación de protocolos de enrutamiento.

Características OSLR AODV Código Abierto SI SI

Reactivo NO SI Incorporado en NS-2 SI SI

Documentación SI SI Las características mencionadas con anterioridad reducen notoriamente el universo de protocolos a solo dos, de los cuales es elegido es AODV.

21

6.1.5 Simulación de algoritmo de enrutamiento 6.1.5.1 Programación TCL Tcl, (Tool Command Language), es un lenguaje de programación dinámico de código abierto. Durante décadas ha servido como un componente esencial en los sistemas de organizaciones que van desde la NASA hasta Cisco Systems, es un lenguaje muy usado en el campo EDA (Electronics Design Automation), y grande compañías como FlightAware lo usan en sus buscadores. Posee una biblioteca de C, que proporciona un marco de desarrollo multi-plataforma ideal para cualquier proyecto de programación. TCL es uno de los pocos lenguajes, convenientes tanto en proyectos de programación grandes y pequeños, sin rayar tener que escalar el lenguaje o exagerar con el mismo. Por otra parte, los ecosistemas web completas y sistemas de control y de ensayo de misión crítica también se escriben en Tcl. Tcl sobresale en todas estas funciones debido a la sintaxis mínima de la lengua, el paradigma de programación única expuesta en el plano de la escritura, y la cuidadosa ingeniería que ha embebido en el diseño de las partes internas de Tcl. TCL es poco normativo, si se compara con otros de script. Su sintaxis se describe en sólo una docena de reglas. No hay palabras reservadas y no hay sintaxis incorporado para las estructuras de control o condicionales. En su lugar, el control y las operaciones de ramificación son como todo lo demás en un programa Tcl, implementado como comandos. Por ejemplo, IF es un comando que en su forma más simple toma una expresión condicional y un bloque de código que se ejecuta si la condición es verdadera. Un script Tcl podría reemplazar IF con su propia aplicación. Cada programa escrito en Tcl se convierte esencialmente en un lenguaje de dominio específico para lo que sea que el programa está diseñado para hacer. TCL es la utilización de scripts en FORTH: Un lenguaje simple que se ajusta a las necesidades. Al igual que Lisp, el proceso de crear un programa en Tcl es el acto de crear un lenguaje de dominio específico para una determinada tarea. TCL tiene todas las características necesarias para crear rápidamente programas útiles en cualquier campo de aplicación, en una amplia variedad de plataformas. Además de ser un lenguaje de programación, Tcl es también una biblioteca multiplataforma C.(Decoster Jos, Kenny Kevin, 2010)(Wall Kurt, 2008).

22

6.1.5.2 Script .tcl: Red Mobile Ad-Hoc con protocolo AODV En el siguiente script se simula una red MANET con 5 nodos, donde se generan movimientos entre nodos aleatorios y se realiza una conexión TCP y aplicación FTP. El código será comentado para facilitar la compresión del mismo. #************************************************** *********************#***** RED MANENT CON PROTOCOLO DE ENRUTAMIENTO AODV Y ***** # *****************APLICACIÓN F TP***************** # PARÁMETROS GENERALES set val(chan) Channel/WirelessChannel ;# Tipo de canal set val(prop) Propagation/TwoRayGround ;# Modelo de radio propagación set val(netif) Phy/WirelessPhy ;# Tipo de interface de red set val(mac) Mac/802_11 ;# MAC type set val(ifq) Queue/DropTail/PriQueue ;# Tipo de cola set val(ll) LL ;# Enlace de datos set val(ant) Antenna/OmniAntenna ;# Tipo de antena set val(ifqlen) 50 ;# Max número de paquetes set val(nn) 5 ;# Numero de nodos de red set val(rp) AODV ;# Protocolo de enrutamiento set val(x) 30 ;# Tamaño en X set val(y) 18 ;# Tamaño en y set val(stop) 200 ;# Tiempo de simulación # PARAMETROS DE VISUALIZACION EN NAM set ns [new Simulator] #Creación de simulación set tracefd [open s1AODV.tr w] # Creación de archivos de almacenamiento set windowVsTime2 [open winS1.tr w] # dichos archivos contienen la bitácora de

#simulación set namtrace [open s1AODV.nam w] # Creación de archivo de simulación #visual NETWORK ANIMATOR NAM $ns trace-all $tracefd # Se carga la simulación en la variable que #representa el archivo $ns namtrace-all-wireless $namtrace $val(x) $val(y) # Se crea el espacio de simulación #de tamaño X e Y # CONFIGURACIÓN DE TOPOLOGÍA set topo [new Topography] $topo load_flatgrid $val(x) $val(y) create-god $val(nn) # Se crean los nodos móviles de la red

23

#CONFIGURACIÓN DE PARÁMETROS DE RED MANET $ns node-config -adhocRouting $val(rp) \ #Tipo de Red y protocolo de enrutamiento -llType $val(ll) \ # Selección de canal, antena, activación de #movimiento -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace ON #CONFIGURACIÓN DE ANTENAS Y PARAMENTOS FÍSICOS DE LOS NODOS for {set i 0} {$i < $val(nn) } { incr i } { #Ciclo para configurar todos los nodos Phy/WirelessPhy set CPThresh_ 10.0 # Ventana sensibilidad Phy/WirelessPhy set CSThresh_ 9.21756e-7 ; # Ventana sensibilidad Phy/WirelessPhy set RXThresh_ 3.92278e-08 ; Phy/WirelessPhy set bandwidth_ 512kb Phy/WirelessPhy set Pt_ 0.2818 Phy/WirelessPhy set freq_ 2.4e+9 #Frecuencia de operación Phy/WirelessPhy set L_ 1.0 Antenna/OmniAntenna set X_ 0 Antenna/OmniAntenna set Y_ 0 Antenna/OmniAntenna set Z_ 0.5 # Altura de antenas Antenna/OmniAntenna set Gt_ 1 # Ganancia de antenas Antenna/OmniAntenna set Gr_ 1 set node_($i) [$ns node] #Configuración de nodos } # CONFIGURACIÓN DE POSICIONES INICIALES Ver figura 5 $node_(0) set X_ 0.20 $node_(0) set Y_ 3.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 1.0 $node_(1) set Y_ 1.20 $node_(1) set Z_ 0.0 $node_(2) set X_ 1.0

24

$node_(2) set Y_ 5.0 $node_(2) set Z_ 0.0 $node_(3) set X_ 4.0 $node_(3) set Y_ 4.50 $node_(3) set Z_ 0.0 $node_(4) set X_ 4.80 $node_(4) set Y_ 2.90 $node_(4) set Z_ 0.0

Figura 5. Parte superior simulación en NAM de la posición de inicio partido B.Human Vs Nao Team

imagen inferior.(RoboCup.org, 1999)

25

#GENERACIÓN DE MOVIMIENTOS ALEATORIOS for {set i 0} {$i < $val(nn) } { incr i } { # Posición final en X e Y y las # Velocidad de desplazamiento $ns at [ expr 7+round(rand()*60) ] "$node_($i) setdest [ expr 5+round(rand()*48) ] [ expr 5+round(rand()*38) ] [ expr 8+round(rand()*15) ]" } # CONEXIÓN TCP ENTRE NODOS (2) y (1) set tcp [new Agent/TCP/Newreno] # TCP New Reno definido en RFC6582 #Mejora la retransmisión durante la fase de recuperación $tcp set class_ 2 set sink [new Agent/TCPSink] #SINK: Sender sencillo con ACK por cada # paquete enviado. $ns attach-agent $node_(2) $tcp #Nodos en conexión $ns attach-agent $node_(1) $sink $ns connect $tcp $sink set ftp [new Application/FTP] #Capa de aplicación, FTP $ftp attach-agent $tcp $ns at 10.0 "$ftp start" # Inicio de envió paquetes # CONEXIÓN TCP ENTRE NODOS (4) y (0) set tcp [new Agent/TCP/Newreno] $tcp set class_ 2 set sink [new Agent/TCPSink] $ns attach-agent $node_(4) $tcp $ns attach-agent $node_(0) $sink $ns connect $tcp $sink set ftp [new Application/FTP] $ftp attach-agent $tcp $ns at 10.0 "$ftp start" # CONFIGURACIÓN DEL TAMAÑO DE NODOS EN NAM for {set i 0} {$i < $val(nn)} { incr i } { # 30 defines the node size for nam $ns initial_node_pos $node_($i) 10 #Tamaño de nodo pequeño dadas las # Características del campo de juego }

26

# CONFIGURACIÓN DE FINALIZACIÓN DE SIMULACIÓN for {set i 0} {$i < $val(nn) } { incr i } { $ns at $val(stop) "$node_($i) reset"; #val(stop) tiene el tiempo total de simulación } # PROCESO DE FINALIZACIÓN DE NAM Y SIMULACIÓN $ns at $val(stop) "$ns nam-end-wireless $val(stop)" $ns at $val(stop) "stop" proc stop {} { # Función de finalización reinician variables y #cerrando archivos de simulación. global ns tracefd namtrace $ns flush-trace close $tracefd close $namtrace } # COMANDO DE EJECUCIÓN Y FINALIZACIÓN DE CÓDIGO TCL $ns run 6.1.5.3 Resultado de simulación El script descrito en el apartado anterior, es compilado con el comando # ns namefile.tcl y genera los archivos .nam y .tr, archivos con la información necesaria para la simulación gráfica y el trazado de análisis respectivamente. 6.1.5.3.1 Simulación grafica Network Animator NAM Con el comando # nam namefile.nam se ejecuta NAM con el archivo que genera el script, en este caso s1AODV.nam. La simulación inicia como se observa en la figura 5, y dato que se está simulando movimiento sobre el campo los nodos cambian sus posiciones iniciales como en la figura 6. Cabe destacar que en dicha figura se observar la comunicación entre el nodo 2 y el 1 y el nodo 4 y 0 a través de 1.

27

Figura 6. Conexión TCP entre nodos 2 y 1 y nodos 4 y 0 a través de 1, simulación NAM.

Como se observa en la figura 7, transcurridos 97 segundos el nodo 2 está fuera del alcance del nodo 1 por lo cual el protocolo AODV genera un mensaje broadcast de ROUTE REQUEST (RREQ) para buscar alcanzar a 1.

Figura 7. Mensaje de broadcast del nodo 2 buscando alcanzar el nodo 1.

28

6.1.5.3.2 Trazado de análisis archivo .tr En este archivo, se consignan todos los eventos realizados durante la simulación línea por línea, y dado el tiempo que se emplee en simulación puede contener bastantes líneas. Por lo cual es complejo al momento de seguir una simulación. Siendo más viable emplear simuladores gráficos como NAM. Ya que los archivos .nam y .tr contienen la misma información, pero descrita de tal forma que sea decodificada por el simulador gráfico. Sin embargo es necesario describir la información que presenta el archivo .tr el cual puede ser ejecutado con un lector de texto plano.

Figura 8. Contenido de archivo .tr ejecutado con bloc de notas.

El contenido del archivo está organizado como la muestra la figura 9 empezando por el tipo de evento, el cual puede ser de r: recibido, s: envió +: encola, -: sale de cola, d: descartado.

29

Figura 9. Estructura de archivo .tr (Issariyakul, Teerawat & Hossain, 2013)

El siguiente campo tiempo denota el tiempo en que se ejecutó el evento, los siguientes dos campos denotan entre que nodos se presentó el evento, los siguientes dos campos son nombre y tamaño del paquete, el siguiente campo banderas identifica cualquier anormalidad puede ocurrir “-------------” indicando que no posee banderas el mensaje, el siguiente campo es el identificador de flow del paquete, los siguientes dos campos llevan las direcciones de fuente y destino respectivamente, en el penúltimo campo NS especifica el número de secuencia, facilitando el correcto ensamble de paquetes, y para mantener seguimiento de todos los paquetes, se registra un ID único de paquete en el último campo. (Issariyakul, Teerawat & Hossain, 2013) (Herrera, 2004) Para el caso particular descrito en la figura 7 se tiene: Tabla 3 Captura de línea 4930 archivo .tr s 97.4183550 _2_ RTR --- 0 AODV 48 [0 0 0 0] ------- [2:255 -1:255 5 0] r 97.4189447 _4_ AGT --- 14106 ack 40 [13a 4 0 800] ------- [0:0 4:0 30 4] [3845 0] 1 0 Como se observa en la primera fila de la tabla 3 el nodo 2 envía un mensaje de ROUTE REQUEST del protocolo AODV con dirección de broadcast. Para las necesidades del presente trabajo de investigación es suficiente con la información que arrojan estos dos tipos de simulaciones.

30

6.2 Fase 2 Métricas del protocolo

La decisión de cuál es la mejor ruta que debe seguir el balón, está gobernada por la valoración que se le da a las mismas, dicha valoración debe obedecer a las características en particular, que solo exige una aplicación específica. En la presente investigación el enfoque ha sido el juego de futbol robot de (Teoldo et al., 2008) se extrae: son bastantes las situaciones donde se evidencia la táctica por la organización espacial de los jugadores sobre el terreno en las circunstancias del partido en relación a los movimientos del balón y a las alternativas de acción (Garganta, 1997). Esta táctica da especial énfasis a los movimientos y los posicionamientos en el campo dejando percibir la habilidad del jugador para ocupar y / o crear espacios libres en función de los principios tácticos adecuados para esa situación o instante. Ya que los jugadores en este caso robot carecen de esta habilidad para ocupar o crear espacios es necesario que las métricas que valore el algoritmo se centren en posición respecto a la cancha y movimiento entendiendo este como la carencia de obstáculos. 6.2.1 Métrica: Posición Desde el punto de vista de la topología la forma en que se divida el campo no tiene mayor trascendencia dado que no es necesaria una división muy fina del campo (Martin et al., 2006), ya que las decisiones que se tomen en diferencias de decenas de centímetros serán las mismas.

Figura 10. División del campo de futbol, en cuatro espacios topológicos.

ZO

NA

1

ZO

NA

2

ZO

NA

3

ZO

NA

4

31

6.2.2 Métrica: Movimiento Cabe resaltar que el algoritmo contempla movimientos para el balón y no para los nodos, aunque en simulación se prevé movimiento de los nodos las decisiones están encaminadas a cuál es la ruta que debe seguir el balón. Por lo cual la métrica de movimiento hace referencia a que tan obstruido está el espacio en que se debe desplazar el balón.

Figura 11. Dos equipos de robots Nao (Rojo y azul), circulo naranja balón, flechas moradas posibles

rutas para el balón, flechas rojas mejor ruta Como se observa en la figura 11 tomar como métrica los obstáculos facilita el procesamiento y la toma de decisiones, esta métrica representa la cantidad de robots adversarios que ve el robot que posee el balón.

1

0 0

2

32

6.3 Fase 3 Modelado y simulación de algoritmo

6.3.1 Modelo Matemático

Partiendo de la simplificación hecha en el apartado anterior el problema se modela como el resultado directo de las reglas de interacción entre los componentes(Alzate, 2016). 6.3.1.1 Etapas del modelo matemático. De (Alzate, 2016) se describen las etapas que comprende el modelado matemático: 1. Identificación de componentes: Robots (nodos) y balón. 2. Determinación de variables descriptivas: Posición y movilidad. 3. Identificación de las reglas de interacción: El balón debe ser enviado de un robot a otro

buscado llegar de la forma más fácil y corta al arco contrario, evadiendo adversarios y actuando en equipo(Garganta, 1997).

4. Parámetros descriptivos de las interacciones: El sistema es una red Ad-Hoc en la que se emplea el protocolo de enrutamiento AODV para la comunicación entre nodos.

El sistema se divide en cuatro estados, los cuales son las zonas por las que se desplaza el balón y están descritas en la figura 10. El cambio entre estados está regido por la métrica de movimiento, en cuyo caso el balón puede cambiar de esta o permanecer en la misma, siendo esto un movimiento de balón entre dos nodos que se encuentra en la misma zona.

Figura 12. Modelo matemático del sistema donde los cambios de zona están regidos por la métrica de movimiento y el nodo final.

ZONA 1

ZONA 4

ZONA 3

ZONA 2 NF/M

NF/M

NF/M

NF/M

33

6.3.1.2 Diagrama de flujo del modelo

Figura 13. Diagrama de flujo del modelo.

INICIO POSEE BALÓN

SOLICITA RUTAS RRT

RECIBE MÉTRICAS

C

CERTIFICA RECEPCIÓN CARGA MÉTRICAS

EN TABLAS

RECIBE TODAS MÉTRICAS

CORRE ALGORITMO CAMINO MAS CORTO

RUTA

SI

SI

NO

NO

SI

NO

34

6.3.2 Simulación en Matlab Con el modelo anteriormente descrito se programa un script de Matlab, (código fuente Apéndice C) encargado de calcular aleatoriamente la ubicación de los robot y las métricas de cada uno con distribución uniforme. Dichas métricas se procesan a través de la teoría de grafos con el algoritmo de Dijkstra y se calcula y grafica la ruta óptima que deberá seguir el balón. Obteniendo los siguientes resultados. 6.3.2.1 Simulación Luego de interpretar el estado inicial aleatorio que genera Matlab se tiene:

Figura 14. Representación gráfica de las matrices aleatorias programadas en Matlab.

Cabe resaltar que el nodo final es el nodo 1 y el nodo que posee el balón es el nodo 4. Para lo cual el algoritmo recomienda como mejor ruta >> path = 4 2 3 1: Ya que es la ruta con menor peso. La grafica que genera el algoritmo se observa en la figura 15.

1

0

0

2

n4 n3

n5

n2

n1

35

Figura 15. Ruta generada por el algoritmo en Matlab

6.3.3 Simulación en NS-2

Dadas las facilidades de NS-2 de programar eventos discretos en tiempo continuo el script se concibe con las características de:

• Ubicar los nodos de forma que se pueda simular una jugada real. • Proponer un nodo como el que posee el balón. • Programar las métricas que cada nodo anuncia a la red. • Programar comunicación por difusión en cada uno de los nodos. • Programar el anuncio de necesidad de rutas y la publicación de métricas por

difusión. • Programar la recepción de paquete anunciando la recepción de los mismos,

paquetes TCP. • Programar la captura de información anunciada por cada nodo. • Programar la toma de decisiones valorando las rutas con las métricas a través de

teoría de grafos. • Publicar la ruta óptima como menos peso.

Cabe destacar la necesidad de crear un nuevo algoritmo de enrutamiento basado en AODV para modificar el código fuente de este sin afectar AODV en este caso se crea NAODV ( Nao AODV) proceso descrito en el Apéndice B. Para ver el código fuente en NS-2 remítase Apéndice C, Algoritmo en NS-2. Los resultados se describen a continuación:

n4

n2

n3

n1

n5

36

6.3.3.1 Simulación Tomando como referencia la simulación realizada en Matlab, se ubican los nodos de manera similar a la figura 14:

Figura 16. Distribución de nodos en NS-2

Para esta simulación cada nodo conoce su ubicación y la métrica de la misma, dicha información será divulgada a todos los nodos de la red, recibiendo confirmación de cada paquete enviado, proceso que es simulado en el cuadro de dialogo del software NAM. Dado que en NS-2 el tiempo es continuo se programan eventos en los tiempos que se requieran: A los 0.2 segundos el nodo 3 hace una solicitud de rutas, generando que todos los nodos envíen un acuse de recibo de dicho paquete y envían un paquete que lleva la métrica movimiento y otro que lleva la métrica de posición como se observa las figuras 17 y 18.

Figura 17. Solicitud RRT del nodo 3 y recepción de la misma del nodo 0

37

Figura 18. Recepción de métrica por el nodo 3 de parte del nodo 4

Con los paquetes de métricas todos los nodos actualizan sus tablas de métricas. Sin embargo es el nodo 3 quien necesita calcular la ruta óptima, por tanto llama la función que la calcula, empleando el algoritmo de Dijkstra, en las siguientes líneas de terminal Linux se describe el proceso. andres@ubuntu:~/Documents/NS2Simulacion$ ns sfnNAODVdijsktra.tcl num_nodes is set 5 INITIALIZE THE LIST xListHead channel.cc:sendUp - Calc highestAntennaZ_ and distCST_ highestAntennaZ_ = 0.5, distCST_ = 5.0 SORTING LISTS ...DONE! Node 3 Envia Informacion -1 # Solicitud de métricas del nodo 3. Node 0 Envia ACK 1 # Confirmación de recepción de todos los nodos. Node 2 Envia ACK 1 Node 4 Envia ACK 1 Node 1 Envia ACK 1 Node 0 Envia Informacion -1 # Los nodos empiezan envió de métrica de movimiento Node 3 Envia ACK 2 # El nodo 3 acusa recepción de métrica. Node 0 Carga Metrica 0 # El nodo 3 actualiza su tabla con la métrica del nodo

0, proceso continua hasta que todos los nodos anuncian sus métricas.

Node 1 Envia Informacion -1 Node 3 Envia ACK 3 Node 2 Carga Metrica 0

# Con la información de las métricas la función calcula la ruta:

La Ruta para el balón calculada por N3 es: N3 N3 0 N3 N0 0 N0 N2 0 N2 N1 1 Como se observa en la figura 19 es la misma ruta descrita en la simulación en Matlab.

38

Figura 19. Ruta calculada en NS-2

6.4 Fase 4 Comparación y resultados

El desarrollo propuesto en esta fase se llevara a cabo en el capítulo 7 de este libro.

39

Capítulo 7 Pruebas y Resultados 7.1 Protocolo de pruebas. Como se describe en el marco teórico de esta investigación, los algoritmos de patch planning que usan los robots en torneos como Robocup humanoides Nao, no contemplan las comunicaciones como un elemento de ayuda en el proceso. A causa de eso comparar dos algoritmos que actúan en condiciones tan diferentes, generando acciones y resultados totalmente distintos, no es una opción válida. Sin embargo, resultados comparables pueden ser evaluados desde la práctica, es decir observando los resultados que tienen dichos algoritmos en la práctica. Es por tanto que la evaluación del algoritmo se realiza con la simulación de momentos de juego derivados de la final Robocup European Open 2016 entre B-human de Alemania y Nao-Team HTWK de Alemania, la final Robocup 2015 entre B-human y la Universidad de Australia y la final Robocup 2016 entre B-human y la Universidad de UT Austin de EE.UU. (RoboCup.org, 1999). Tomando jugadas en distintos momentos de los encuentros y comparando resultados.

7.1.1 Jugada 1 minuto 3:14

Figura 20. Minuto 3:24 Nao Team tiene el balón

40

Como se observa en la figura 20 el robot de Nao Team tiene el balón y a la vista dos robots de su mismo equipo. La simulación de esta jugada se aprecia en la figura 21, donde N2 es el nodo que posee el balón y solicita información para buscar el mejor movimiento del balón.

Figura 21. Minuto 3:14 simulado en NS-2

Figura 22. Ruta propuesta por el protocolo

El resultado de la simulación se plasma en la figura 22 y se dibuja en la figura 21, aunque el momento de recibir el balón el nodo 3 debería repetir el proceso y decidir si es más viable hacer un pase o patear el balón hacia el arco. El desenlace de la jugada se observa en la figura 23 donde al transcurrir el minuto 3:24 el robot pierde el balón debido al ataque de un adversario ya que este continuaba con el balón los 10 segundos anteriores .

Figura 23. Minuto 3:24 Desenlace jugada 1 minuto 3:14

41

7.1.2 Jugada 2 minuto 13:37

Figura 24. Minuto 13:37 Nao Team posee el balón

Como en la simulación anterior se plasma la escena vista en la figura 24 con los siguientes resultados:


42

Figura 26. Ruta propuesta por el protocolo.

El nodo 4 N4 le anuncia a N2 una métrica de 2 ya que desde su punto de vista hay dos robots en frente de él. Lo cual evita que N2 intente un pase directo hacia el nodo N4, dicha ruta se expone en la figura 26 y se dibuja en la figura 25.

Figura 27. Minuto 13:39 Desenlace jugada 2 minuto 13:37

El desarrollo de la jugada 2 al igual que la jugada 1 es la pérdida del balón, por la misma razón, el robot intenta llevar el balón solo hasta la otra portería pero en el camino se interpone un adversario impidiendo su paso. Lo que evidencia una falta de comunicación entre robots.

43

7.1.3 Jugada 3 minuto 19:41 segundo tiempo

Figura 28. Minuto 19:41 segundo tiempo.

Como se puede ver en la figura 28 los Nodos N0, N1 y N2 difícilmente pueden entrar en la juagada dadas la distribución de los adversarios y lo lejos que se encuentran.


44

Figura 30. Ruta propuesta por el simulador

La opción propuesta por el algoritmo (figura 30) es intentada por el robot de Nao Team pero como se observa en la figura 30, sin embargo por la falta de comunicación entre quien debía recibir el balón se mueve en dirección opuesta, dando lugar a perder el balón. El desenlace de esta jugada evidencia la necesidad que hay de comunicación entre robots de lo contrario difícilmente jugaron como equipo.

Figura 31. Minutos 19:44, 19:50 desenlace jugada 3

Como se espera los resultados de trabajar en grupo son contundentes al momento de planear estrategias o como en este caso particular rutas para un balón.

45

7.1.4 Jugada 4 minuto 2:36 B-Human Vs Universidad de Australia 2015

Figura 32. Minuto 2:36 B-Human Vs U. Australia

Como se observa en la figura 32 el jugador 4 de Australia posee el balón y su compañero numero 3 está en mejor posición de tiro al arco.


46

Del proceso de simulación figuras 33 y 34 se deduce que el mejor movimiento para el balón es hacia el jugador número 3.


Sin embargo la figura 35 muestra que el jugador 4 intenta llevar el balón, dando tiempo a que sea atacado por un adversario y el jugador 3 se desplaza en otra dirección.

Figura 35. Minuto 2:43 desenlace jugada 4

47

7.1.5 Jugada 5 minuto 2:36 B-Human Vs Universidad de Australia 2015

Figura 36. Minuto 5:57 B-Human Vs U. Australia

En la jugada 5 el jugador tres de Australia (figura 36) esta muy cerca del arco pero tiene varios adversario que le impiden patear el balón directo al arco.


48

Por lo cual lo mejor es planear una estrategia y esta seria enviar el balón a un jugador con una mejor oportunidad y que se encuentra en la misma zona de juego, como lo muestra la figura 38 debe dirigir el balón al jugador 4.


El desenlace de esta jugada se observa en la figura 39 donde, el jugador pierde el balón por la llegada de demasiados adversarios a la zona.

Figura 39. Minuto 6:05 desenlace de la jugada 5.

49

7.1.6 Jugada 6 minuto 7:07 B-Human Vs UT Austin 2016

Figura 40. Minuto 7:07 B-Human Vs UT Austin

Para esta jugada Austin tiene dos jugadores, con un adversario muy cerca (figura 40), lo mejor que hacer es realizar un pase para evitar perder el balón.


50

Como se observa en la figura 41 y 42 el simulador recomienda un pase al frente.


La figura 43 muestra el obstáculo al que se enfrenta el jugador al intentar continuar con el balón.

Figura 43. Minuto 7:17 desenlace de la jugada 6

51

7.1.7 Jugada 7 Jugada planeada para correr 3 simulaciones una por cada nodo Para las simulaciones expuestas en las figuras 44, 47 y 49, se simula los eventos en cada nodo con sus respectivas métricas al momento de recibe el balón.

Figura 44. Jugada planeada N1 posee el balón.

La jugada que se observa en la figura 44 está planeada para corroborar el comportamiento de los nodos, una vez posean el balón.

Figura 45. Simulación en NS-2, jugada planeada

La ruta que recomienda el protocolo (figura 46), cumple con la necesidad de mover el balón por el campo evadiendo adversarios.

1 0

1

0

1

0

N0

N1

N2

N3

N4

52

Figura 46. Ruta calculada por el simulador.

La continuación de la jugada se observa en la figura 45, donde N3 ha recibido el balón y los adversarios se han desplazado en búsqueda del mismo, cambiando las métricas del protocolo.

Figura 47. Jugada planeada N3 posee el balón.

Dada la disposición del juego la figura 48 recomienda que el nodo 3 continúe con la jugada planeada por el nodo 1.

Figura 48. Ruta calculada por el simulador

0

0 1

1

2

0

N0

N1

N2

N3

N4

53

La culminación de la jugada se plasma en la figura 49, al igual que la reacción del equipo adversario.

Figura 49. Jugada planeada N2 posee el balón

La recomendación realizada por el protocolo (figura 50) es dirigir el balón hacia el nodo 4, lo cual es la culminación de la jugada prevista desde el nodo 1.

Figura 50. Ruta calculada por el simulador

0 2

1

0

0

0

N0

N1

N2

N3

N4

54

Capítulo 8 8.1 Conclusiones y Recomendaciones

• La aplicación que se le dio al algoritmo propuesto, genera un trabajo en grupo por parte de los robots como lo haría un ser humano en juego normal de futbol, dicha aplicación muestra un desempeño más humano, ya que los robots poseen una estructura global del juego, al saber cómo están distribuidos sus compañeros y sus adversarios.

• La teoría nodos es forma sencilla de modelar sistemas complejos a partir de estados

del mismo, el cual puede ser procesado con algoritmos como Dijkstra.

• Los protocolos de comunicación para redes que actúan sin punto de centralización son una herramienta eficaz para crear redes muy amplias solo usando equipos existentes, es decir poder hacer que un paquete viaje usando infraestructura como teléfonos celulares que incorporan IEEE 802.11, vehículos, casa etc, sería una red supremamente amplia con infraestructura ya desplegada.

• Las métricas que valoran el sistema, facilitan mucho la implementación del mismo

porque desde el punto de vista topológico la medida exacta de ubicación no genera mayor información puesto que la decisión que se tome es igual.

• El modelo matemático de sistemas a partir de eventos discretos en tiempo continuo

es una herramienta muy fuerte para analizar sistemas complejos y simularlos, dado que solo conociendo las variables de interacción, los estados del sistema y normas que rigen el sistema, el proceso puede ser simulado con un algoritmo sobre un pc.

• Pensar en sistemas que comparten el trabajo y se comunican entre sí, es pensar en

sistemas distribuidos, cuyas aplicaciones pueden ser muy complejas y cuyos modelos matemáticos de forma analítica son más complejos aun de obtener. Un modelo por estados es muy viable y de fácil implementación y simulación.

• El algoritmo obtenido en el presente trabajo de investigación cumple con el objetivo

propuesto. La generación de rutas de navegación de un balón en un partido de futbol robot, simulando el actuar de seres humanos y las tácticas que estos usan en un campo de juego, al proponer un protocolo de comunicación entre robots con el cual obtienen la movilidad y ubicación de sus compañeros de equipo.

• Para obtener un resultado óptimo, en tareas desarrolladas por robots que actúan en grupo es necesario el empleo de protocolos de comunicación para sincronizar la operación de los mismos buscando que actúen como un grupo unificado.

55

8.2 Trabajos de investigación que complementan o se desprenden de esta investigación:

• Obtener las métricas de movimiento y posición. El robot incorpora dos cámaras con las cuales a través de procesamiento digital de señales y la aplicación de algoritmos bioinspirados se pueden generar dichas métricas para que sean divulgadas a todos los nodos de la red y el algoritmo propuesto en esta investigación valore la mejor ruta.

• Generación y modelado de métricas diferentes, dado que dichas métricas son la

interfaz del mundo físico y el virtual.

• La abstracción propuesta en la presente investigación deja ver un mundo de aplicaciones para la misma, por ejemplo en Colombia la creación de centros logísticos (centros para almacenar y procesar carga) es bastante alta, por lo tanto los volúmenes de despachos dentro del país y las ciudades, requieren de sistemas muy eficientes que evalúen rutas de entrega minimizando costos, tiempo de entrega y personal. Por tanto la búsqueda de nuevas aplicaciones ofrece varios trabajos de investigación.

56

9. Lista de referencias

Abolhasan, M., Dutkiewicz, E., & Wysocki, T. (2004). A review of routing protocols for mobile ad hoc networks. Ad Hoc Networks, 2(1), 1–22. http://doi.org/10.1016/S1570-8705(03)00043-X

Aldebaran-Robotics. (2016). NAOqi Documentation. Retrieved from http://doc.aldebaran.com/1-14/index.html

Alzate, M. (2016). 250 Conceptos de Probabilidad, Variables Aleatorias y Procesos Estocásticos en Redes de Comunicaciones. Universidad Distrital F. J. C. Retrieved from http://comunidad.udistrital.edu.co/malzate/

Beekmans, G. (2016). Linux From Scratch. Retrieved from http://www.linuxfromscratch.org/lfs/view/development/index.html

Brunette, E. S., Flemmer, R. C., Flemmer, C. L., Minsky, M., Selfridge, O., Solomonoff, R., … Rochester, N. (2009). A Review of Artificial Intelligence, 385–392.

CANONICAL. (2016). GET UBUBTU. Retrieved from http://www.ubuntu.com/download

Chlamtac, I., Conti, M., & Liu, J. J. N. (2003). Mobile ad hoc networking: Imperatives and challenges. Ad Hoc Networks, 1(1), 13–64. http://doi.org/10.1016/S1570-8705(03)00013-1

Coya, Lucy & Ledesma, Talia & Garcia, W. (2014). SELECCIÓN DEL PROTOCOLO DE ENRUTAMIENTO PARA LA IMPLEMENTACIÓN DE UNA MANET ROUTING PROTOCOL. Conveción Cientifica de Ingeníeria Y Arquitectura, 1–11.

De la Puente, P. (2007). Sistema de navegación de un robot móvil, 163.

Decoster Jos, Kenny Kevin, T. P. (2010). Wiki TCL. Retrieved from http://wiki.tcl.tk/20791

Farber, M. (2005). TOPOLOGY OF ROBOT MOTION PLANNING Michael Farber University of Durham, (1987).

Gallardo, D., Colomina, O., Flórez, F., Arques, P., Company, P., & Rizo, R. (1990). Control local de robots móviles basado en métodos estadísticos y algoritmos genéticos. Inteligencia Artificial, 1–14.

57

Garganta, J. (1997). Modelado de juego táctico del fútbol, El estudio de la fase de organización en equipos ofensivos de alto rendimiento. (Facultad d). Oporto - Portugal: Horizonte Books Ltd. http://doi.org/224P

Gelsinger, P. (2015). VMware Workstation Player. Retrieved from http://www.vmware.com/

Georgios Parissidis, Merkourios Karaliopoulos, R. B., & Thrasyvoulos Spyropoulos, B. P. (2009). Routing Metrics for Wireless Mesh Networks. Guide to Wireless Mesh Networks. Paris. http://doi.org/10.1007/978-1-84800-909-7

Guppy Stephen, G. J., & Mark, B. (2016). GNS3 Documentation. Retrieved from https://www.gns3.com/support/docs

Henderson, T. (2011). ns Notes and Documentation. Retrieved from http://www.isi.edu/nsnam/ns/doc/node1.html

Herrera, M. (2004). NS2 - Network Simulator, 1–17.

Issariyakul, Teerawat & Hossain, E. (2013). Introduction to NS2. Journal of Chemical Information and Modeling (Vol. 53). http://doi.org/10.1017/CBO9781107415324.004

Katkar, P. S. (2016). Comparative Study of Network Simulator : NS2 and NS3, 6(3), 608–612.

Kennelly Jerry, B. H. (2016). RIVERBED Support. Retrieved from http://www.riverbed.com/products/steelcentral/opnet.html?redirect=opnet

Kruusmaa, M. (2003). Global level path planning for mobile robots in dynamic environments. Journal of Intelligent and Robotic Systems, 55–83. http://doi.org/10.1023/A:1026296011183

L.A.Latiff, N. Fisal, S. A. A. and A. A. A. (2010). Directional Routing Protocol in Wireless Mobile Ad Hoc Network. http://doi.org/10.5772/8486

Lara, R. A. (2014). Evaluación de Protocolos de Enrutamiento usados en las Redes Móviles AdHoc ( MANET ), utilizando el software Network Simulator NS2 . Network, 1–6.

Mackworth, A. (2015). RoboCup. http://doi.org/RoboCup World Championship and Conference

Maisonnier, B. (2015). Who is NAO? http://doi.org/Who is NAO?

58

Martin, F., Barrera, P., Rob, G. De, Rey, U., & Carlos, J. (2006). Localización topológica basada en visión para robots móviles. XXVII Jornadas de Automática, ISBN: 84-6.

Moghaddam, S. K., & Masehian, E. (2016). Planning Robot Navigation among Movable Obstacles (NAMO) through a Recursive Approach. Journal of Intelligent and Robotic Systems: Theory and Applications, 1–32. http://doi.org/10.1007/s10846-016-0344-1

Morales, M., Calle, M., Tovar, J., & Cuéllar, J. (2013). Elección de una herramienta de simulación. Retrieved from http://biblioteca2.icesi.edu.co/cgi-olib/?infile=details.glu&loid=254778&rs=971011&hitno=2

National Science Foundation. (2016). NS-3 Documentation. Retrieved from https://www.nsnam.org/documentation/

Pastor, F. J. H. (2008). Estudio de viabilidad de la utilización de redes inalámbricas Ad-Hoc en edificios departamentales, 19.

Patil, S. (2015). surajpatilworld. Retrieved from http://surajpatilworld.blogspot.com.co/2015/02/how-to-clone-protocol-in-ns2.html

Perkins, C. &. B. E. &. D. S. (2003). RFC 3561. Retrieved from www.ietf.org/rfc/rfc3561.txt

Rahman, A., & Zukarnain, Z. (2009). Performance comparison of AODV, DSDV and I-DSDV routing protocols in mobile ad hoc networks. European Journal of Scientific …, 31(4), 566–576. Retrieved from http://masters.donntu.edu.ua/2010/fknt/kondratyuk/library/routing2.pdf

Rey, L. C., Odete, T., Quiñones, L., & García, W. B. (2014). Protocolos de enrutamiento aplicables a redes MANET, 13(3), 59–74.

RoboCup.org. (1999). RoboCup. Retrieved from Standard Platform League

Romero, J. (2009). Desarrollo de un sistema de comunicaciones para robots AIBO. Universidad de Castilla La Mancha.

SARMAN, CONSER, ICIR, S. Microsystem. (2014). NS-2. Retrieved from http://nsnam.sourceforge.net/wiki/index.php/Main_Page

Singh, H., Kaur, H., Sharma, a, & Malhotra, R. (2015). Performance Investigation of Reactive AODV and Hybrid GRP Routing Protocols under Influence of IEEE 802.11n MANET. Advanced Computing Communication Technologies (ACCT),

59

2015 Fifth International Conference on, 325–328. http://doi.org/10.1109/ACCT.2015.50

Spaho, E., Barolli, L., Mino, G., Xhafa, F., & Kolici, V. (2011). Simulation evaluation of AODV, OLSR and DYMO protocols for VEhicular NETworks using CAVENET. Proceedings - 2011 International Conference on Network-Based Information Systems, NBiS 2011, 118–125. http://doi.org/10.1109/NBiS.2011.27

Takahashi, O., & Schilling, R. J. (1989). Motion Planning in a Plane Using Generalized Voronoi Diagrams. IEEE Transactions on Robotics and Automation, 5(2), 143–150. http://doi.org/10.1109/70.88035

TCL XCHANGE. (2015). TCL / TK. Retrieved from https://www.tcl.tk/

Teoldo, I. C., Garganta, J. M., Greco, J. P., & Mesquita, I. (2008). Principios tácticos del fútbol: conceptos y aplicaciones.

Toutouh, J., Garcia-Nieto, J., & Alba, E. (2010). Configuración Óptima del Protocolo de Encaminamiento OLSR para VANETs Mediante Evolución Diferencial. Actas Del {VII Congreso Sobre Metaheuristicas, Algoritmos Evolutivos Y Bioinspirados (MAEB’10)}, 463–471.

Vega, M. (2013). Aplicación de teoría de grafos a redes con elementos autónomos Índice. Universidad de Alcalá.

Wall Kurt. (2008). Tcl and Tk Programming for the Absolute Beginner. (Thomsom Technology Course, Ed.). Boston - Massachusetts: Cengage Learning.

60

10. Apéndices 10.1 Apéndice A: Instalación de NS-2

10.1.1 Instalación y Puesta en Marcha de NS-2

10.1.2 Sistema operativo Base Dado que NS 2 presenta un excelente soporte y documentación bajo sistemas operativos Linux. Se elige Ubuntu 16.04 a 64 bits y se corre con una máquina virtual VMware 11.0.(CANONICAL, 2016)(Gelsinger, 2015) Como se ilustra en la figura 51.

Figura 51. Captura de pantalla VMware con sistema operativo Ubuntu 11.04 LTS.

10.1.3 Adquisición e Instalación de NS 2 De la web de NS 2 (SARMAN, CONSER, ICIR, 2014) debe ser descargarse el archivo ns-allinone-2.35.tar.gz que data de noviembre 4 de 2011. Él cual es un comprimido con el código fuente de la herramienta, algunos protocolos y el entorno grafico NAM. Es recomendable actualizar los repositorios de la distribución: >sudo apt-get update >sudo apt-get dist-upgrate >sudo apt-get update

61

>sudo apt-get install build essential autoconf automake Se debe instalar los lenguajes de programación TCL y TK (TCL XCHANGE, 2015) y algunas aplicaciones para el manejo de gráficos y librerías de desarrollo. >sudo apt-get install tcl8.5-dev tk8.5-dev >sudo apt-get perl xgraph libxt-dev libx11-dev libxmu-dev Luego de extraer el contenido de allinone-2.35.tar.gz se ingresa desde una terminal a la carpeta ns-allinone-2.35.tar.gz y se ejecuta el comando para empezar la instalación: >./install Después de instalar la herramienta es necesario crear las rutas del mismo, en el archivo de ejecución .bashrc, pegando y modificando las siguientes líneas (con sus respectivas rutas de instalación): # LD_LIBRARY_PATH OTCL_LIB=/home/andres/Documents/ns-allinone-2.35/otcl-1.14/ NS2_LIB=/home/andres/Documents/ns-allinone-2.35/lib/ USR_Local_LIB=/usr/local/lib/ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:$NS2_LIB: $USR_Local_LIB # TCL_LIBRARY TCL_LIB=/home/andres/Documents/ns-allinone-2.35/tcl8.5.10/library/ USR_LIB=/usr/lib/ export TCL_LIBRARY=$TCL_LIBRARY:$TCL_LIB:$USR_LIB # PATH XGRAPH=/home/andres/Documents/ns-allinone-2.35/xgraph-12.2/:/home/andres/Documents/ns-allinone-2.35/bin/:/home/andres/Documents/ns-allinone-2.35/tcl8.5.10/unix/:/home/andres/Documents/ns-allinone-2.35/tk8.5.10/unix/: NS=/home/andres/Documents/ns-allinone-2.35/ns-2.35/ NAM=/home/andres/Documents/ns-allinone-2.35/nam-1.15/ export PATH=$PATH:$XGRAPH:$NS:$NAM >sudo nano .bashrc Si la instalación fue correcta al momento de teclear el comando ns debe aparecer como en la figura 52 el signo %, que indica que se puede empezar a describir código.

Figura 52. NS 2 instalado correctamente, captura de pantalla terminal Ubuntu.

62

10.2 Apéndice B: Adición de protocolos a NS-2

10.2.1 Configuración de protocolo NAODV en NS-2 Si es necesaria la modificación del código fuente de un protocolo nativo en NS-2, lo mejor es crear uno nuevo basado en el algoritmo nativo, en este caso AODV y se crea NAODV. Dicho protocolo es ajeno para la herramienta de simulación, lo que obliga a configurar el código fuente de NS-2, para que el protocolo NAODV sea parte de la pila de protocolos Ad-Hoc. Con lo cual es posible llamarlo desde cualquier script sin mayores cambios. Tomando como base (Patil, 2015) se recomienda seguir los pasos descritos a continuación;

1. El protocolo debe estar almacenado en la misma dirección donde almacena NS-2 sus protocolo pre compilados: /home/Andres/Documents/ns-allinone-2.35/ns-2.35

Figura 53. Captura almacenamiento de protocolo en NS-2

2. Desde una terminal se modifica el archivo packet.h, ubicado en: > ns-allinone-2.35\ns-2.35\common\packet.h Línea 203 se crea el nuevo tipo de paquetes: static const packet_t PT_NAODV = 73; Línea 271 se crea la clase para los nuevos paquetes: type == PT_NAODV || Línea 351 se crea la función de paquetes del protocolo: name_[PT_NAODV]= "NAODV";

3. Desde una terminal se modifica el archivo cmu-trace.h, ubicado en:

> ns-allinone-2.35\ns-2.35\trace\cmu-trace.h Línea 161 se crea la función para llamar los nuevos tipos de paquetes, con lo cual son rastreados y se identifica si son perdidos, recibidos o enviados por agentes, enrutadores u otros objetos(Henderson, 2011):

63

void format_naodv(Packet *p, int offset) 4. Creación de paquetes: Desde una terminal se abre el archivo cmu-trace.cc, el cual

es el archivo de implementación del ítem 3. >ns-allinone-2.35\ns-2.35\trace\cmu-trace.cc Línea 67 se hace inclusión de la cabecera creada: #include <taodv/taodv_packet.h> Línea 968 se inserta el siguiente código el cual define los tipos de paquetes que posee el protocolo de enrutamiento NAODV: void CMUTrace::format_naodv(Packet *p, int offset) { struct hdr_naodv *ah = HDR_NAODV(p); struct hdr_naodv_request *rq = HDR_NAODV_REQUEST(p); struct hdr_naodv_reply *rp = HDR_NAODV_REPLY(p); switch(ah->ah_type) { case NAODVTYPE_RREQ: if (pt_->tagged()) { sprintf(pt_->buffer() + offset, "- naodv:t %x - naodv:h %d - naodv:b %d -naodv:d %d " "- naodv:ds %d - naodv:s %d - naodv:ss %d " "- naodv:c REQUEST ",rq->rq_type, rq->rq_hop_count, rq->rq_bcast_id, rq->rq_dst, rq->rq_dst_seqno, rq->rq_src, rq->rq_src_seqno); } else if (newtrace_) { sprintf(pt_->buffer() + offset,"-P naodv -Pt 0x%x -Ph %d -Pb %d -Pd %d -Pds %d -Ps %d -Pss %d -Pc REQUEST ", rq->rq_type, rq->rq_hop_count, rq->rq_bcast_id, rq->rq_dst, rq->rq_dst_seqno, rq->rq_src, rq->rq_src_seqno);

64

} else { sprintf(pt_->buffer() + offset, "[0x%x %d %d [%d %d] [%d %d]] (RREQ)", rq->rq_type, rq->rq_hop_count, rq->rq_bcast_id, rq->rq_dst, rq->rq_dst_seqno, rq->rq_src, rq->rq_src_seqno); } break; case NAODVTYPE_RREP: case NAODVTYPE_HELLO: case NAODVTYPE_RERR: if (pt_->tagged()) { sprintf(pt_->buffer() + offset, "- naodv:t %x - naodv:h %d - naodv:d %d -nadov:ds %d " "- naodv:l %f - naodv:c %s ", rp->rp_type, rp->rp_hop_count, rp->rp_dst, rp->rp_dst_seqno, rp->rp_lifetime, rp->rp_type == NAODVTYPE_RREP ? "REPLY" : (rp->rp_type == NAODVTYPE_RERR ? "ERROR" : "HELLO")); } else if (newtrace_) { sprintf(pt_->buffer() + offset, "-P naodv -Pt 0x%x -Ph %d -Pd %d -Pds %d -Pl %f -Pc %s ", rp->rp_type, rp->rp_hop_count, rp->rp_dst, rp->rp_dst_seqno, rp->rp_lifetime, rp->rp_type == NAODVTYPE_RREP ?"REPLY" : (rp->rp_type == NAODVTYPE_RERR ?"ERROR" : "HELLO")); } else {

65

sprintf(pt_->buffer() + offset,"[0x%x %d [%d %d] %f] (%s)", rp->rp_type, rp->rp_hop_count, rp->rp_dst, rp->rp_dst_seqno, rp->rp_lifetime, rp->rp_type == NAODVTYPE_RREP ? "RREP": (rp->rp_type == NAODVTYPE_RERR ?"ERROR" : "HELLO")); } break; default: #ifdef WIN32 fprintf(stderr,"CMUTrace::format_ naodv: invalid NAODV packet type\n"); #else fprintf(stderr,"%s: invalid NAODV packet type\n",__FUNCTION__); #endif abort(); } } Línea 1526 se crea al caso para los paquetes NAODV: case PT_NAODV: format_naodv(p, offset); break;

5. Definición de encabezados de paquetes: Se realiza en el archivo ns.packet con lo cual queda definido el protocolo como Ad-Hoc, el archivo se única en : > ns-allinone-2.35\ns-2.35\tcl\lib\ns-packet.tcl Línea 174 Se inserta el siguiente código, con lo cual queda definido el nombre del protocolo NAODV como un protocolo de enrutamiento Ad-Hoc: NAODV

6. En el archivo ns-lid.tcl se define el tipo de nodo AODV, el archivo se ubica en: > ns-allinone-2.35\ns-2.35\tcl\lib\ns-lib.tcl Línea 633 se debe inserta: NAODV { set ragent [$self create-naodv-agent $node]

66

} Línea 864 se debe insertar para crear el agente NAODV: Simulator instproc create-naodv-agent { node } { set ragent [new Agent/NAODV [$node node-addr]] $self at 0.0 "$ragent start"; $node set ragent_ $ragent return $ragent }

7. Sobre el archivo priqueue.cc, encargado de las prioridades de colas, está ubicado en: > ns-allinone-2.35\ns-2.35\queue\priqueue.cc Línea 93 se debe insertar el siguiente código: case PT_NAODV:

8. Sobre el archivo de ejecución makefile se definen registros y tablas de enrutamiento

para el nuevo protocolo, está ubicado en: > ns-allinone-2.35\ns-2.35\Makefile .in y .vc Línea 264 se inserta el siguiente código: naodv/naodv_logs.o naodv/naodv.o \ naodv/naodv_rtable.o naodv/naodv_rqueue.o \

9. Con el archivo ns-agent.tcl se crea el nuevo agente TCP para el protocolo, encargado del envió o recepción y sus respectivas técnicas de control de congestion, está ubicado en: > ns-allinone-2.35\ns-2.35\tcl\lib\ns-agent.tcl Línea 195 se inserta el siguiente codigo: Agent/NAODV instproc init args { $self next $args } Agent/NAODV set sport_ 0 Agent/NAODV set dport_ 0

10. Para dar la posibilidad de tener nodos Ad-Hoc moviles es necesario modificar el archive ns-mobilenode.tcl ubicado en: > ns-allinone-2.35\ns-2.35\tcl\lib\ns-mobilenode.tcl Línea 202 es necesario insertar las siguientes líneas de código: set naodvonly [string first "NAODV" [$agent info class]]

67

if {$naodvonly != -1 } { $agent if-queue [$self set ifq_(0)] ; }

11. Para que las tablas de enrutamiento sean llenadas las rutas vecinas o los siguientes saltos es necesario generar una clase encapsulada en la clase Neighbor del archivo rtable.tcl ubicado en: > ns-allinone-2.35\ns-2.35\routing\rtable.h Línea 58 es necesario insertar las siguientes líneas de código: friend class NAODV; Línea 79 es necesario insertar las siguientes líneas de código: friend class NAODV; //Newly added friend class NAODVLocalRepairTimer;

12. Es necesario definir el encabezado del protocolo NAODV frente al estándar 802.11, por tanto es necesario modificar el archivo initTCL.cc ubicado en: > ns-allinone-2.35\dei80211mr-1.1.4\src\InitTCL.cc Línea es necesario insertar las siguientes líneas de código: PacketHeaderManager set tab_(PacketHeader/TAODV) 1\n\

13. Dado que se modificó el código fuente del NS-2, para que posea el protocolo NAODV, es necesario compilar y volver a instalar NS-2. Desde una terminal se abre la ubicación > ns-allinone-2.35 y se generan los siguientes comandos: > touch /…/ ns-allinone-2.35/ns-2.35/common/packet.cc > ./configure Si genera un error es necesario reinstalar NS-2 > ./install

NAODV ya es un protocolo incorporado en la herramienta de simulación y como tal puede ser usado solo llamándolo por su nombre(Patil, 2015)(Henderson, 2011).

68

10.3 Apéndice C Algoritmos

10.3.1 Algoritmo en Matlab %************************************************** ***************** %********* Algoritmo de Navegación del Balón******* ***************** %************************************************** ***************** %***** Distribución Aleatoria de Nodos************* ***************** clear all: clc; PoX=randi([0 60],1,5); PoY=randi([0 30],1,5); Msum=5; NcBalon=randi([1 5]); for i=1:5 hold on; plot(PoX(i),PoY(i),'bo','lineWidth',3); end %*********** Asignación de Métricas *************** ******************* while Msum ~= 4 Mnodes(1)=randi([0 4]); Mnodes(2)=randi([0 4]); Mnodes(3)=randi([0 4]); Mnodes(4)=randi([0 4]); Mnodes(5)=randi([0 4]); Msum=sum(Mnodes); end %*********** Asignación de Zonas ****************** ******************* for i=1:5 if PoX(i)<= 10 VnodesZ(i)=1; end if PoX(i)> 50 VnodesZ(i)=4; end if PoX(i)> 10 && PoX(i)<= 30 VnodesZ(i)=2; end if PoX(i)> 30 && PoX(i)<= 50 VnodesZ(i)=3; end end

69

%************** Calculo de Ruta con Dijkstra******* ***************** n=5; adj=zeros(n,n); for p=1:n for q=1:n if p == q adj(p,q)=0; else adj(p,q)=Mnodes(p)+Mnodes(q); end end end adj for p=1:n a(p).status=0; end temp=[]; acc=[]; s=NcBalon; dest=find(VnodesZ==4) if dest==0 dest=find(VnodesZ==3); end t=dest; if length(dest)>1 t=dest(1); end a(s).status=1; path=s; for k=1:inf for h=1:n if a(h).status==0 temp=[temp adj(s,h)]; else temp=[temp inf]; end end [aa,bb]=min(temp); acc=[acc aa]; temp=[]; s=bb; a(s).status=1; path=[path s]; if s==t

70

break end end h=length(path) for f=1:h-1 plot([PoX(path(f)) PoX(path(f+1))],[PoY(path(f)) PoY(path(f+1))],'r') end

10.3.2 Algoritmo en NS-2 #************************************************** ********************* #************************************************** ********************* #***** PROTOCOLO NAODV, SIMULADOR DE COMUNICACIÓN ENTRE ROBOTS ***************** #********* PARA PLANEAR RUTAS DE NAVEGACIÓN DE UN B ALÓN ******* #********************** APLICADO AL FUTBOL ROBOT ** **************** #************************************************** ********************* #************************************************** ** NOVIEMBRE 2016 #********************************************* ING ANDRES RODRIGUEZ #************************************************** ******************** Mac/Simple set bandwidth_ 1Mb set MESSAGE_PORT 48 set BROADCAST_ADDR -1 set Z 0 set M 1 set group_size 5 set num_groups 1 set num_nodes [expr $group_size * $num_groups] set val(chan) Channel/WirelessChannel ;#Channel Type set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/Simple set val(ifq) Queue/DropTail/PriQueue ;# interface queue type set val(ll) LL ;# link layer type set val(ant) Antenna/OmniAntenna ;# antenna model set val(ifqlen) 50 ;# max packet in if set val(rp) NAODV set ntest 1 set metrica(0) 0 set metrica(1) 0 set metrica(2) 0 set metrica(3) 0

71

set metrica(4) 0 set TreeDatabaseT {} # size of the topography set val(x) 30 set val(y) 18 set ns [new Simulator] set f [open SFdijsktra-$val(rp).tr w] $ns trace-all $f set nf [open SFdijsktra-$val(rp).nam w] $ns namtrace-all-wireless $nf $val(x) $val(y) $ns use-newtrace # set up topography object set topo [new Topography] $topo load_flatgrid $val(x) $val(y) # Create God create-god $num_nodes set chan_1_ [new $val(chan)] $ns node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace OFF \ -macTrace ON \ -movementTrace OFF \ -channel $chan_1_ for {set i 0} {$i < $num_nodes} {incr i} { set n($i) [$ns node] Phy/WirelessPhy set CSThresh_ 9.21756e-7 ; Antenna/OmniAntenna set Z_ 0.5 } $n(0) set X_ 6.0 $n(0) set Y_ 9.5 $n(0) set Z_ 0.0 $n(1) set X_ 23.0 $n(1) set Y_ 3.20 $n(1) set Z_ 0.0 $n(2) set X_ 17.0

72

$n(2) set Y_ 17.0 $n(2) set Z_ 0.0 $n(3) set X_ 3.0 $n(3) set Y_ 16.50 $n(3) set Z_ 0.0 $n(4) set X_ 7.5 $n(4) set Y_ 2.90 $n(4) set Z_ 0.0 for {set i 0} {$i < $num_nodes} {incr i} { $ns initial_node_pos $n($i) 2 } # subclass Agent/MessagePassing to make it do flooding Class Agent/MessagePassing/Flooding -superclass Agent/MessagePassing Agent/MessagePassing/Flooding instproc recv {source sport size data } { #puts "\n Empieza respuesta\n" $self instvar messages_seen node_ global ns BROADCAST_ADDR TreeDatabaseT metrica ntest # extract message ID from message set message_id [lindex [split $data ":"] 0] puts "\nNode [$node_ node-addr] Envia ACK $message_id\n" if {[lsearch $messages_seen $message_id] == -1} { lappend messages_seen $message_id $ns trace-annotate "[$node_ node-addr] received {$data} from $source" if {$message_id == 2} { set metric [lindex [split $data ":"] 1] set metrica($source) $metric puts "\nNode $source Carga Metrica $metrica($source)\n" $ns trace-annotate "Node $source Envia Metrica $metric" set metric 0 } if {$message_id == 3} { set metric [lindex [split $data ":"] 1] $ns trace-annotate "Node $source Esta en Zona $metric" } if {$message_id == 4} { #set TreeDataBaseT [dijsktra] $ns trace-annotate "$source Anucia la Ruta $TreeDatabaseT" #break }

73

$ns trace-annotate "[$node_ node-addr] sending Message $message_id" } Agent/MessagePassing/Flooding instproc send_message {size message_id data port} { $self instvar messages_seen node_ global ns MESSAGE_PORT BROADCAST_ADDR lappend messages_seen $message_id $ns trace-annotate "[$node_ node-addr] sending message $message_id" $self sendto $size "$message_id:$data" $BROADCAST_ADDR $port puts "\nNode [$node_ node-addr] Envia Informacion $BROADCAST_ADDR\n" } # attach a new Agent/MessagePassing/Flooding to each node on port $MESSAGE_PORT for {set i 0} {$i < $num_nodes} {incr i} { set a($i) [new Agent/MessagePassing/Flooding] $n($i) attach $a($i) $MESSAGE_PORT $a($i) set messages_seen {} } # now set up some events $ns at 0.2 "$a(3) send_message 200 1 {RRT} $MESSAGE_PORT" #$ns at 0.29 "Dest3" $ns at 0.3 "$a(0) send_message 200 2 {0} $MESSAGE_PORT" $ns at 0.33 "$a(0) send_message 200 3 {1} $MESSAGE_PORT" $ns at 0.4 "$a(1) send_message 200 2 {1} $MESSAGE_PORT" $ns at 0.425 "$a(1) send_message 200 3 {4} $MESSAGE_PORT" $ns at 0.5 "$a(2) send_message 200 2 {0} $MESSAGE_PORT" $ns at 0.535 "$a(2) send_message 200 3 {3} $MESSAGE_PORT" $ns at 0.6 "$a(4) send_message 200 2 {2} $MESSAGE_PORT" $ns at 0.645 "$a(4) send_message 200 3 {1} $MESSAGE_PORT" $ns at 1 "dijkstra" #$ns at 0.6 "$a(3) send_message 200 4 {0} $MESSAGE_PORT" #$ns at 0.4 "$a([expr $num_nodes/2]) send_message 600 2 {some big message} $MESSAGE_PORT" #$ns at 0.7 "$a([expr $num_nodes-2]) send_message 200 3 {another one} $MESSAGE_PORT" #********************* ALGORITMO DE DIJKSTRA ****** ***************** proc dijkstra {} { #Dijkstra algorithm as Routing SPF(Shortest Path First) algorithm in CT. #Reference Details: <Routing TCP/IP Volume I 2nd.Edition> Chapter 4, Dynamic Routing Protocols: Link State Routing Protocols #This file was originally written by warmeng<[email protected]>

74

#Distributed under the BSD software license #input: All router path & cost in the topology. following is reference :Table 4-2. <Routing TCP/IP Volume I 2nd.Edition> # VARIABLES DE ENTRADA #set debug 1 global metrica global root global LinkStateDatabase global CandidateDatabase global TreeDatabase global TreeDatabaseT global LinkStateDatabase global debug 1 #-----------------------begin procs---------------------------- #State machine reference:http://wiki.tcl.tk/8363 proc statemachine states { global root global TreeDatabase global lowestCostEntry array set S $states proc goto label { uplevel 1 set this $label return -code continue } set this [lindex $states 0] while 1 {eval $S($this)} rename goto {} } proc debugOutput {msgtype msg} { set debug 1 #puts "\nDatos Envia ACK $debug\n" switch $debug { 0 { #turn off debug output } 1 { #notification message if {[string first NOTI $msgtype] == 0} { #puts "$msg" } } 2 { #warning message

75

if {[string first NOTI $msgtype] == 0} { puts "$msg" } if {[string first WARN $msgtype] == 0} { puts "$msg" } } 3 { #debug message if {[string first DBG $msgtype] == 0} { puts "$msg" } if {[string first WARN $msgtype] == 0} { puts "$msg" } if {[string first NOTI $msgtype] == 0} { puts "$msg" } } default { puts "Debug level should be 0,1,2,3, but got: $debug" } } } proc checkNeighborsExistInTreeDB {entry Database} { set NeighborID [lindex $entry 1] set numbersOfEntries [llength $Database] for {set i 0} {$i < $numbersOfEntries} {incr i} { set neighborIDInDatabase [lindex [lindex $Database $i] 1] if {[string match $NeighborID $neighborIDInDatabase] == 1} { #if neighbor exist, return 1 return 1 } } #if not exist, return 0 return 0 } proc neighborIDOfEntry {entry} { return [lindex $entry 1] } proc calcChainsToRootCost {entry} { global TreeDatabase global root

76

if {$entry == ""} {debugOutput DBG "calcChainsToRootCost entry is empty";return} set entry [split $entry " "] if {[string match [lindex $entry 0] $root] == 1} { return [lindex $entry 2] } if {[string match [lindex $entry 0] [lindex $entry 1]] == 1} { return 0 } #Recursion generate full chain cost foreach line $TreeDatabase { debugOutput DBG "calcChainsToRootCost $entry $line [string match [lindex $line 1] [lindex $entry 0]]" if {[string match [lindex $line 1] [lindex $entry 0]] == 1} { return [expr [lindex $entry 2] + [calcChainsToRootCost $line]] } } } proc purgeCandidateDatabase {} { #delete entry frome Candidate Database that match: have the same neighborID, but higher cost to root global CandidateDatabase set numbersOfEntries [llength $CandidateDatabase] for {set i 0} {$i < [expr $numbersOfEntries - 1]} {incr i} { for {set j [expr $i + 1]} {$j < [expr $numbersOfEntries]} {incr j} { set left [lindex $CandidateDatabase $i] set right [lindex $CandidateDatabase $j] debugOutput DBG "purgeCandidateDatabase1 i$i,j$j,left$left,right$right,numbersOfEntries$numbersOfEntries" #compare neighbor ID if {[string match [lindex $left 1] [lindex $right 1]] == 1} { debugOutput DBG "purgeCandidateDatabase found match: $left \- $right" if {[expr [calcChainsToRootCost $left] - [calcChainsToRootCost $right]] >= 0} { lappend purgeList $i } else { lappend purgeList $j } } } } if {[info exist purgeList]} { set purgeList [lsort -decreasing $purgeList]

77

for {set k 0} {$k < [llength $purgeList]} {incr k} { debugOutput DBG "purgeCandidateDatabase2 k$k purgeList$purgeList CandidateDatabase$CandidateDatabase [lindex $CandidateDatabase [lindex $purgeList $k] [lindex $purgeList $k]]" if {$k != 1} { set CandidateDatabase [lreplace $CandidateDatabase [lindex $purgeList $k] [lindex $purgeList $k]] } } } } proc addNeighborsOfRouterToCandidateDB {RouterID {except 0}} { global LinkStateDatabase global CandidateDatabase global TreeDatabase #puts "\nDatos $LinkStateDatabase\n" foreach entries $LinkStateDatabase { set ifmatch [regexp {^([\d\w]+) +([\d\w]+) +(\d+)} $entries match Neigh NextNeigh Cost] if {$ifmatch} { if {[string match $RouterID $Neigh] ==1} { if {[string match $except EXCEPT] == 1} { if {[checkNeighborsExistInTreeDB $entries $TreeDatabase] == 0} { lappend CandidateDatabase [list $Neigh $NextNeigh $Cost] } } else { lappend CandidateDatabase [list $Neigh $NextNeigh $Cost] } } } else { debugOutput NOTI "addNeighborsOfRouterToCandidateDB DB error, cannot match correct entries, the Entry is: $entries" } } purgeCandidateDatabase } proc calcCandidateDB2rootCost {} { global CandidateDatabase foreach entries $CandidateDatabase { set ifmatch [regexp {^([\d\w]+) +([\d\w]+) +(\d+)} $entries match Neigh NextNeigh Cost] if {$ifmatch} {

78

lappend tableOfChainsToRootCost [list $entries [calcChainsToRootCost $entries]] } else { debugOutput NOTI "calcCandidateDB2rootCost DB error, cannot match correct entries, the Entry is: $entries" } } return $tableOfChainsToRootCost } proc lowestCostOfEntry {tableOfChainsToRootCost} { global lowestCostEntry set numbersOfEntry [llength $tableOfChainsToRootCost] set retVal [lindex $tableOfChainsToRootCost 0] for {set i 1} {$i < $numbersOfEntry} {incr i} { set tempVar1 [lindex $retVal 1] set leftside [lindex [lindex $tableOfChainsToRootCost $i] 1] if {[expr $tempVar1 - $leftside] > 0} { set retVal [lindex $tableOfChainsToRootCost $i] } } set lowestCostEntry [lreplace $retVal 1 1] debugOutput DBG "lowestCostOfEntry Found lowest cost entry: $lowestCostEntry in\n$tableOfChainsToRootCost" return $lowestCostEntry } proc checkCandidateDatabaseEmpty {} { global CandidateDatabase return [llength $CandidateDatabase] } proc deleteEntryFromDatabase {entry Database} { set retVal [eval lsearch {$Database} $entry] if {$retVal != -1} { return [lreplace $Database $retVal $retVal] } return $Database } proc moveEntryFromCandidateDB2TreeDB {entry} { global lowestCostEntry global CandidateDatabase global TreeDatabase eval lappend TreeDatabase $entry set CandidateDatabase [deleteEntryFromDatabase $entry $CandidateDatabase] debugOutput NOTI "\nCandidate\tCostToRoot\tTree\n" foreach Candidate $CandidateDatabase Tree $TreeDatabase {

79

debugOutput NOTI "[join $Candidate ","]\t[calcChainsToRootCost $Candidate]\t[join $Tree ","]" set Candidate "" set Tree "" } } #-------------------------end procs---------------------------- #-------------------------main start--------------------------- set TreeDatabase "" set CandidateDatabase "" set LinkStateDatabase "{N3 N0 $metrica(0)} {N0 N3 $metrica(0)} {N3 N4 $metrica(4)} {N4 N3 $metrica(4)} {N0 N4 $metrica(4)} {N4 N0 $metrica(4)} {N0 N2 $metrica(2)} {N2 N0 $metrica(2)} {N0 N1 $metrica(1)} {N1 N0 $metrica(1)} {N1 N4 $metrica(4)} {N4 N1 $metrica(4)} {N1 N2 $metrica(1)} {N2 N1 $metrica(1)}" set root N3 statemachine { 1 { #Step 1:A router initializes the Tree database by adding itself as the root. This entry #shows the router as its own neighbor, with a cost of 0. lappend TreeDatabase [list $root $root 0] goto 2 } 2 { #Step 2:All triples in the link state database describing links to the root router's neighbors #are added to the Candidate database. addNeighborsOfRouterToCandidateDB $root goto 3 } 3 { #Step 3:The cost from the root to each link in the Candidate database is calculated. The #link in the Candidate database with the lowest cost is moved to the Tree database. If #two or more links are an equally low cost from the root, choose one. moveEntryFromCandidateDB2TreeDB [lowestCostOfEntry [calcCandidateDB2rootCost]] goto 4 } 4 { #Step 4:The Neighbor ID of the link just added to the Tree database is examined. With the

80

#exception of any triple whose Neighbor ID is already in the Tree database, triples in the #link state database describing that router's neighbors are added to the Candidate database. addNeighborsOfRouterToCandidateDB [eval neighborIDOfEntry $lowestCostEntry] EXCEPT goto 5 } 5 { #Step 5:If entries remain in the Candidate database, return to step 3. If the Candidate database #is empty, terminate the algorithm. At termination, a single Neighbor ID entry in the Tree #database should represent every router, and the shortest path tree is complete. if {[checkCandidateDatabaseEmpty] > 0} { goto 3 } set rutaf [llength $TreeDatabase] set rutaf2 [lindex $TreeDatabase 3] puts "La Ruta para el balón calculada por $root es: \n" for {set i 0} {$i < $rutaf } {incr i} { set ruta($i) [lindex $TreeDatabase $i] puts "$ruta($i) " } break } } } $ns at 2.0 "finish" proc finish {} { global ns f nf val $ns flush-trace close $f close $nf # puts "running nam..." exec nam SFdijsktra-$val(rp).nam & exit 0 } $ns run (Henderson, 2011)(Coulter, 2013)