tesis de grado

UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS

ESCUELA ACADÉMICO PROFESIONAL DE INFORMÁTICA

“TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE EXPLORACIÓN Y RECONOCIMIENTO EN SUPERFICIES

TERRESTRES”

Tesis para obtener el Título de Ingeniero Informático, presentada por:

GERARDO VÍCTOR ALAÍN SÁNCHEZ ARANDA ROLANDO PALERMO RODRÍGUEZ CRUZ

Asesor

Prof. Ing. JOSÉ LUIS PERALTA LUJÁN Universidad Nacional de Trujillo

Trujillo, Septiembre de 2011

DEDICATORIA

A ti nuestro Dios que nos diste fuerza, iluminación y empeño a través de una

maravillosa familia.

Como expresión de gratitud a nuestros padres y seres queridos por su apoyo

constante.

A nuestros asesores y amistades que supieron orientarnos durante la realización

del proyecto, por su tiempo y apoyo constante.

Con profundo respeto a nuestros GRANDES MAESTROS, por sus enseñanzas

impartidas.

Br. Gerardo Víctor Alaín Sánchez Aranda

Br. Rolando Palermo Rodríguez Cruz

AGRADECIMIENTOS

Gracias a Dios, creador del universo, por todas sus bendiciones.

Al Ingeniero José Luis Peralta Luján por dirigir y asesorar éste proyecto de grado.

A los protagonistas de este proyecto, Víctor M. Aguilar Alvarado, Mg. Orlando

Angulo Trujillo, Carlos Alfonso Rivadeneira León, por su participación activa en el

proyecto ya que nos permitieron crecer.

A nuestros padres y hermanos, por brindarnos todo el respaldo necesario para

poder culminar con éxito este proyecto.

A la Escuela de Informática, por el respaldo institucional dado para la realización

de este trabajo.

A Pedro Linares Kcomt, Jorge Cortez Segura, Gerald Fernando Infante Gonzales,

Henry Rojas Muñoz, Zully Sheena Silva Rodriguez, Cintia Natali Flores Ruiz, Edith

Terán Saldaña, Ramón Hernández Gutiérrez, que son buenos amigos y que nos

apoyaron en este proceso.

Así mismo a aquellas personas que de una u otra manera colaboraron o

participaron en la realización de esta investigación, hacemos extensivo nuestro

más sincero agradecimiento.

Br. Gerardo Víctor Alaín Sánchez Aranda

Br. Rolando Palermo Rodríguez Cruz

PRESENTACION

Señores Miembros del Jurador Dictaminador:

En cumplimiento con las disposiciones vigentes para grados y títulos de la

Facultad de Ciencias Físicas y Matemáticas de la Universidad Nacional de Trujillo,

sometemos a vuestra consideración la presente tesis titulada: “TELECONTROL

DE UN ROBOT MÓVIL PARA TAREAS DE EXPLORACIÓN Y

RECONOCIMIENTO EN SUPERFICIES TERRESTRES” .

El presente trabajo de investigación es el resultado de nuestros mejores

esfuerzos, donde se ponen en práctica los conocimientos adquiridos durante

nuestra formación profesional, el cual se complementa con la orientación y apoyo

de aquellas personas que nos brindaron su ayuda en el desarrollo.

Invocamos su comprensión en caso de haber incurrido en cualquier error

involuntario en el desarrollo de la presente tesis.

Los Autores.

Trujillo, Septiembre de 2011

ÍNDICE DE CONTENIDOS

CAPÍTULO I: INTRODUCCIÓN

1.1. Realidad Problemática………………………………………………………. 1 1.2. Antecedentes…………………………………………………………………. 2 1.3. Justificación……………………………………………………….………….. 4 1.4. Planteamiento del Problema……………………………………………….. 4 1.5. Hipótesis………………………………………………………………………. 4 1.6. Objetivos……………………………………………………………………… 5

1.6.1. Objetivo General……………………………………………………… 5 1.6.2. Objetivos Específicos………………………………………………… 5

1.7. Áreas de Aplicación………………………………………………………….. 5 1.8. Estado Actual………………………………………………………………… 6 1.9. Organización de la Tesis……………………………………………………. 9 CAPÍTULO II: MARCO TEÓRICO

2.1. Conceptos fundamentales………………………………………………….. 10 2.2. Protocolos…………………………………………………………………….. 12

2.2.1. Elementos……………………………………………….…………..... 12 2.2.2. Diseño……………………………………………………………….... 12 2.2.3. Máquinas de estado finito…………………………………………… 14

2.3. Puertos, Sockets y Modelo Cliente/Servidor……………………………… 16 2.4. Transmisión de datos en tiempo real……………………………………… 16 2.5. Robótica móvil, adquisición y transmisión de datos……………………… 18

2.5.1. Locomoción………………………………………………………….... 18 2.5.2. Percepción……………………………………………………………. 19 2.5.3. Control del robot…………………………………………………….... 19 2.5.4. Navegación…………………………………………………………… 20 2.5.5. Comunicación……………………………………………………….... 20 2.5.6. Transmisión………………………………………………………….... 21

CAPÍTULO III: ENLACE DE COMUNICACIÓN

1.1. Protocolo 802.11…………………………………………………………….. 22 1.2. Retardo de tiempo…………………………………………………………… 23

3.2.1. Retardo de nodo……………………………………………………… 24 3.2.2. Jitter……………………………………………………………………. 27 3.2.3. Pérdida de paquetes…………………………………………………. 28


CAPÍTULO IV: ARQUITECTURA HARDWARE DE TELEOPERACIÓN

4.1. Arquitectura principal del sistema de teleoperación……………………… 29 4.2. El Gamepad como dispositivo de interfaz de teleoperación……………. 31

4.2.1 Interconexión del Gamepad con Java…………………………….. 32 4.3. Dispositivos de audio y video………………………………………………. 35 4.4. Tarjeta de adquisición de datos……………………………………………. 36

4.4.1. Unidad de control……………………………………………………... 37 4.4.2. Fuente de alimentación……………………………………………… 37 4.4.3. Unidad de Adquisición y Buses Analógicos……………………….. 37 4.4.4. Salidas Digitales………………………………………………………. 38

4.5. Módulo de navegación y posicionamiento………………………………… 39 4.6. Módulo de potencia………………………………………………………….. 44

4.6.1. Etapa de potencia a base de relevadores…………………………. 44 4.6.2. Puente H usando el integrado L298N……………………………… 45 4.6.3. Puente H usando el integrado L293B……………………………… 46

4.7. Unidades y estructuras mecánicas………………………………………… 46 4.7.1 Estructura cinemática del robot…………………………………….. 47 4.7.2 Herramientas de manipulación e inspección……………………… 48

CAPÍTULO V: SÍNTESIS DEL PROTOCOLO

5.1. Descripción del problema…………………………………………………… 50 5.2. Estructura del protocolo……………………………………………………... 51 5.3. Nivel de abstracción…………………………………………………………. 52 5.4. Elementos del protocolo…………………………………………………….. 53 5.5. Servicio y ambiente………………………………………………………….. 54 5.6. Diseño del protocolo…………………………………………………………. 55

5.6.1 Modelo del cliente……………………………………………………. 56 5.6.2 Modelo del transmisor……………………………………………..... 56 5.6.3 Modelo del receptor………………………………………………….. 57 5.6.4 Modelo del canal de comunicación………………………………… 58

5.7 Implementación del protocolo………………………………………………. 60 5.7.1 HEADER………………………………………………………………. 60 5.7.2 USER DATA………………………………………………………….. 62 5.7.3 TRAILER……………………………………………………………… 65

5.8 Ejemplos de tramas………………………………………………………….. 65

CAPÍTULO VI: ARQUITECTURA DE CONTROL DE RED

6.1. Introducción…………………………………………………………………... 66 6.2. Método de control desarrollado……………………………………………. 71

6.2.1 Esquema de control basado en eventos…………………………... 71 6.2.2 Esquema de control basado en el tiempo…………………………. 74

6.3 Sincronización de paquetes………………………………………………… 74 6.4 Implementación experimental de un modelo de control basado en

eventos………………………………………………………………………... 77


CAPÍTULO VII: ANÁLISIS Y DISEÑO DEL SOFTWARE

7.1. Especificación de requerimientos…………………………………………… 82 7.1.1 Requerimientos funcionales…………………………………………. 82 7.1.2 Requerimientos no funcionales……………………………………… 83

7.2 Concepción…………………………………………………………………….. 84 7.3 Diagrama pictográfico………………………………………………………… 85 7.4 Casos de uso………………………………………………………………….. 86

7.4.1 Especificación de los casos de uso…………………………………. 86 7.5 Modelo de análisis del sistema………………..…………………………….. 93

7.5.1 Modelo estático del sistema…………………………………………. 93 7.5.2 Modelo dinámico del sistema………………………………………... 94 7.5.3 Diagrama de actividades…………………………………………….. 95 7.5.4 Diagrama de componentes………………………………………….. 97 7.5.5 Diagrama de despliegue……………………………………………… 98

CAPÍTULO VIII: RESULTADOS Y CONCLUSIONES

8.1. Resultados…………………………………………………………………… 99 8.2. Conclusiones………………………………………………………………… 103 8.3. Recomendaciones………………………………………............................. 103 REFERENCIAS BIBLIOGRÁFICAS …………………………………………….. 105

ANEXO A: MANUAL DE USUARIO …………………………………………….. 108

ANEXO B: IMÁGENES DEL ROBOT DE EXPLORACIÓN …………………... 118

ANEXO C: HERRAMIENTAS PARA EL ANÁLISIS DE RED ………………… 122

LISTA DE FIGURAS

CAPÍTULO I: INTRODUCCIÓN

Figura 1.1 Robots vendidos hasta el 2007………………………………….... 6 Figura 1.2 Robots de uso profesional vendidos……………………………… 6 Figura 1.3 Ventas de Robots estimadas para el periodo 2008-2011……… 8 Figura 1.4 Distribución de los robots en la actualidad según su área de

aplicación…………………………………………………………… 8

Figura 1.5 Organización de esta tesis………………………………………… 9 CAPÍTULO II: MARCO TEÓRICO Figura 2.1 Diagrama de transición de estados………………………….……. 15 Figura 2.2 Formato de una cabecera RTP……………………………………. 17 Figura 2.3 Cambio de dirección de un robot terrestre……………………….. 18 Figura 2.4 Diagrama de Bloques del Robot Móvil…………………………… 19

CAPÍTULO III: ENLACE DE COMUNICACIÓN Figura 3.1 Retardo nodal total en el enrutador A……………………………. 24 Figura 3.2 Tiempos de retardo en el envío de paquete ICMP entre un

enrutador y una unidad remota a una distancia media inferior a 5 metros con línea de vista…………………………………………

25

Figura 3.3 Tiempos de retardo en el envío de paquete ICMP entre un enrutador y una unidad remota a una distancia media de 20 metros sin línea de vista……………………………………………

26

Figura 3.4 Tiempos de retardo en el envío de paquete ICMP entre un enrutador y una unidad remota a una distancia media superior a 30 metros sin línea de vista………………………………………

26

CAPÍTULO IV: ARQUITECTURA HARDWARE DE TELEOPERACIÓN Figura 4.1 Diagrama general de bloques del sistema de teleoperación

desarrollado…………………………………………………………. 31

Figura 4.2 El gamepad como dispositivo de interfaz de teleoperación. Izquierda: Disposición de botones y palancas. Derecha: Estructura interna……………………………………………………

32

Figura 4.3 Ventana de controladores de juegos de Windows……………… 33 Figura 4.4 Ventana de propiedades y calibración de un dispositivo de

juegos en Windows………………………………………………… 34

LISTA DE FIGURAS

Figura 4.5 Resultados de las pruebas de interconexión entre Java y un gamepad……………………………………………………………..

35

Figura 4.6 Cámara web VGA Halion HA-184. Derecha: Sensor CMOS. Izquierda: Lente con filtro de vidrio cristalino…………………….

35

Figura 4.7 Cámara IP WIFI con movimiento y visión nocturna. Derecha: Vista posterior. Izquierda: Vista normal…………………………..

36

Figura 4.8 Diagrama de bloques de la tarjeta de adquisición de datos…… 37 Figura 4.9 Tarjeta de adquisición de datos basada en el Microcontrolador

18F4550……………………………………………………………… 38

Figura 4.10 Diagrama de bloques del módulo de navegación y posicionamiento……………………………………………………..

39

Figura 4.11 Receptor GPS Conexant Jupiter. Derecha: Vista superior. Izquierda: Vista inferior……………………………………………..

39

Figura 4.12 Recepción de datos de 4 satélites……………………………….. 40 Figura 4.13 Módulo de adquisición de datos de navegación y posición……. 43 Figura 4.14 Transistores en configuración de Puente H……………………… 44 Figura 4.15 Amplificador de potencia en base a relevadores……………….. 45 Figura 4.16 Puente H utilizando el integrado L298N………………………….. 45 Figura 4.17 Puente H utilizando el integrado L293B………………………….. 46 Figura 4.18 Rueda fija…………………………………………………………… 47 Figura 4.19 La locomoción……………………………………………………….. 47 Figura 4.20 La locomoción diferencial se caracteriza por la ausencia de

ruedas directrices…………………………………………………… 48

Figura 4.21 Estructuras mecánicas……………………………………………... 49

CAPÍTULO V: SÍNTESIS DEL PROTOCOLO Figura 5.1 Esquema del sistema de comunicaciones……………………….. 51 Figura 5.2 Ejemplos de niveles de abstracción………………………………. 53 Figura 5.3 Modelo del protocolo desarrollado en base a 4 autómatas……. 55 Figura 5.4 Modelo del cliente…………………………………………………... 56 Figura 5.5 Diagrama correspondiente al autómata del transmisor………… 57 Figura 5.6 Diagrama correspondiente al autómata del receptor…………… 58 Figura 5.7 Modelo del canal de comunicación……………………………….. 59 Figura 5.8 Principales campos del protocolo…………………………………. 60 Figura 5.9 Secciones del campo HEADER del protocolo…………………… 60 Figura 5.10 Secciones del campo DATA con respecto al servicio de

navegación…………………………………………………………… 64

Figura 5.11 Principales campos de la sección TRAILER…………………….. 65 Figura 5.12 Trama que indica el reinicio del servicio de video………………. 65 Figura 5.13 Trama para la rotación de un actuador del robot móvil…………. 65

CAPÍTULO VI: ARQUITECTURA DE CONTROL DE RED Figura 6.1 Esquemas de control tradicional y basado en eventos…………. 67 Figura 6.2 Efecto Buffering provocado por los retardos de tiempo en la

LISTA DE FIGURAS

red…………………………………………………………………….. 68 Figura 6.3 Eliminación del efecto Buffering a través de un esquema de

control basado en eventos………………………………………… 69

Figura 6.4 Comparación entre el muestreo de una misma señal según un esquema basado en eventos y un esquema basado en el tiempo…………………………………………………………………

70

Figura 6.5 Envío de paquetes basado en esquema de control por eventos 73 Figura 6.6 Estructura de paquetes…………………………………………….. 73 Figura 6.7 Estructura de un paquete con datos de posicionamiento………. 74 Figura 6.8 Esquema de sincronización de eventos………………………….. 76 Figura 6.9 Resultado del control basado en eventos con δ = 3%................ 78 Figura 6.10 Resultado del control basado en eventos con δ = 5%................ 78 Figura 6.11 Resultado del control clásico basado en tiempo para la

temperatura…………………………………………………………. 79

Figura 6.12 Control basado en tiempo en comparación con control basado en eventos con un límite δ = 3%.................................................

79

Figura 6.13 Control basado en tiempo en comparación con control basado en eventos con un límite δ = 5%.................................................

80

CAPÍTULO VII: ANÁLISIS Y DISEÑO DEL SOFTWARE Figura 7.1 Diagrama pictográfico……………………………………………… 85 Figura 7.2 Casos de Uso básicos del sistema………………………………. 86 Figura 7.3 Modelo Estático del dominio del problema. TRCU es la unidad

de control teleoperado (Teleoperated Robot Control Unit)……. 93

Figura 7.4 Diagrama de Estado general del sistema……………………….. 94 Figura 7.5 Diagrma de sub-estados del estado Operacional de la Figura

7.4……………………………………………………………………… 95

Figura 7.6 Diagrama de Actividades del proceso de exploración…………… 96 Figura 7.7 Diagrama de Componentes………………………………………… 97 Figura 7.8 Diagrama de Despliegue……………………………………………. 98

CAPÍTULO VIII: RESULTADOS Y CONCLUSIONES Figura 8.1 Comparativa de dos métodos de control: Control basado en

tiempo y Control basado en eventos…………………………….

100 Figura 8.2 Control basado en tiempo……………………………………….. 100 Figura 8.3 Control basado en eventos con δ = 3%.................................... 101 Figura 8.4 Control basado en eventos con δ = 5%.................................... 101

ANEXO A: MANUAL DE USUARIO Figura A.1 Vista superior del gamepad……………………………………… 112 Figura A.2 Vista lateral del gamepad………………………………………… 112 Figura A.3 Pantalla principal del software de telecontrol………………….. 113 Figura A.4 Barra de menús……………………………………………………. 114

LISTA DE FIGURAS

Figura A.5 Menú de herramientas……………………………………………. 115 Figura A.6 Menú de servicios…………………………………………………. 115 Figura A.7 Barra de herramientas……………………………………………. 116 Figura A.8 Pantalla de configuración de parámetros………………………. 116 Figura A.9 Botones de acceso rápido………………………………………... 117 Figura A.10 Consola…………………………………………………………….. 117 Figura A.11 Interfaz de control del robot……………………………………… 118 Figura A.12 Pantalla de localización satelital………………………………… 119 Figura A.13 Interfaces del software del robot móvil………………………….. 120

ANEXO B: IMÁGENES DEL ROBOT DE EXPLORACIÓN Figura B.1 Diagrama esquemático del circuito de control…………………. 121 Figura B.2 Pinzas del sistema de manipulación……………………………. 122 Figura B.3 Manipulador de 4 grados de libertad……………………………. 122 Figura B.4 Hardware de telecontrol del robot de exploración……………... 123 Figura B.5 Estación de telecontrol……………………………………………. 123 Figura B.6 Robot GERO II…………………………………………………….. 124

ANEXO C: HERRAMIENTAS PARA EL ANÁLISIS DE RED Figura C.1 Ejemplo de envío de un paquete ICMP………………………… 125 Figura C.2 Inicio del asistente de instalación……………………………….. 128 Figura C.3 Componentes disponibles para su instalación…………………. 128 Figura C.4 Pantalla para la selección de accesos directos………………... 129 Figura C.5 Ventana de selección del directorio de instalación……………. 130 Figura C.6 Proceso de instalación iniciado………………………………….. 130 Figura C.7 Ventana para la instalación de componentes adicionales……. 131 Figura C.8 Finalizando la instalación de Wireshark………………………… 131 Figura C.9 Proceso de instalación finalizado………………………………... 132

LISTA DE TABLAS

Tabla 2.1 Estados de transición de una máquina de estado finito………….. 14 Tabla 2.2 Descripción de los campos de una cabecera RTP……………….. 17 Tabla 2.3 Tipos de datos transferidos entre el robot móvil y la estación de

control………………………………………………………………….. 21

Tabla 3.1 Comparación de los diferentes estándares de la familia 802.11... 23 Tabla 3.2 Resultados del envío de paquetes ICMP a una distancia media

inferior a 5 metros con línea de vista entre un enrutador y una unidad remota…………..……………………………………………..

25

Tabla 3.3 Resultados del envío de paquetes ICMP a una distancia media de 20 metros sin línea de vista entre un enrutador y una unidad remota…………………………………………………………………..

26

Tabla 3.4 Resultados del envío de paquetes ICMP a una distancia media superior a 30 metros sin línea de vista entre un enrutador y una unidad remota……………..…………………………………………..

27

Tabla 6.1 Limites de las variables más usadas en la exploración de ambientes………………………………………………………………

72

Tabla 7.1 Requerimientos Funcionales del Sistema…………………………. 82

PRÓLOGO

Han pasado más de 50 años desde que la robótica sentó sus bases y principios y

nuestro país no fue ajeno a este acontecimiento. Y ha sido justo esta área de la

Ingeniería la que ha cambiado la vida de la gente, haciendo de esta más cómoda y

sencilla. Sin embargo estos alcances de la tecnología aún no se han visto muy

acentuados en nuestro país.

Cabe plantear la siguiente interrogante -¿Qué está haciendo la gente encargada

de desarrollar la tecnología en Perú?- Muchos países vecinos han iniciado

carreras espaciales con sus primeras sondas exploradoras, que si bien es cierto,

están lejos de las potencias mundiales, son investigaciones que servirán de base

para las futuras generaciones.

Hemos visto una fuerte filosofía que se está forjando en nuestras universidades

que hacen ver a la robótica como un aspecto netamente lúdico, sin embargo ya es

tiempo de cambiar esto. Los trabajos orientados a la robótica no alcanzan aún la

envergadura de verdaderos proyectos de investigación y en esta área somos

ampliamente superados por otros países de América latina.

En este presente trabajo queremos aportar algo diferente pues en esta era del

conocimiento y la información no podemos ser ajenos a los grandes cambios y

debemos apostar por la tecnología, que a nuestro punto de vista es hoy en día uno

de los pilares en el desarrollo de una nación.

Este trabajo de investigación es una obra multidisciplinaria, pero ha sido orientado

al área de Ciencias de la Computación y la Ingeniería de Redes y

Telecomunicaciones dejando otros aspectos para futuras mejoras y nuevas

propuestas.

RESUMEN

En este trabajo de investigación se describe el proceso de telecontrol de un robot

móvil como medio de exploración. Con el afán de poner énfasis en el sistema

proyectado a manera de prototipo, se implementó una sonda exploradora (a partir

de ahora será referenciada como sonda ) con los servicios que describimos a

continuación:

• La sonda cuenta con 4 cámaras de video con capacidad de rotación así

como un transmisor de audio, para el envío de datos multimedia en tiempo

real.

• Una herramienta de manipulación de 4 grados de libertad (número de

articulaciones móviles), un módulo de GPS y sensores de temperatura.

• Cuenta con un sistema de control basado en joystick lo cual permite que su

manejo se torne más ergonómico.

Gracias a estas capacidades la sonda nos permite conocer, preguntar y actuar

ante diversas situaciones y ambientes. Utiliza para ello, un protocolo de

transferencia de multimedia desarrollado sobre la plataforma Java (RTP) que

conjuntamente con el protocolo basado en sockets que aquí se plantea,

estructuran un protocolo aún más robusto que al trabajar directamente sobre

TCP/IP permiten no depender de ningún servicio en Internet e incrementar las

capacidades de control de la sonda al mejorar la infraestructura de la capa física

(según el modelo OSI).

A lo largo de este trabajo se explicará el proceso de comunicación que se realiza a

fin de hacernos comprender mejor los beneficios y utilidades de este proyecto.

ABSTRACT

In this study is described the telecontrol's process of a mobile robot as an

exploration tool. In an effort to emphasize the system shown as a way of prototype,

an exploration probe has been implemented (From now will be referenced like

"probe") with the services shown below:

• The probe has got 4 video cameras capable of rotating and an audio

transmitter for sending multimedia data in real time.

• A 4 degrees of freedom (number of movable joints) robotic arm, a GPS

module and temperature sensors.

• It has a control system based on a gamepad, which allows its management

becomes more ergonomic.

With these capabilities the probe allows us to know, ask and act on a variety of

situations and environments. It uses for this, a transfer protocol of multimedia,

developed on the Java platform (RTP) which together with the sockets-based

protocol which are proposed here, structure even more a robust protocol that

working directly over TCP / IP allow not rely on any Internet service and increase

capacity to control the probe by improving the infrastructure of the physical layer

(according to the OSI model).

Along of this work it will explain the process of communication that takes place to

make us better understand the benefits and profits of this project.

1

CAPÍTULO I

INTRODUCCIÓN

En este capítulo se presenta una descripción completa del entorno en el que ha

sido desarrollado este trabajo de investigación, detallando primero el estado del

arte de la robótica de exploración y el telecontrol para luego describir el impacto

que ha tenido en la sociedad actual. Por último se comentarán algunos avances

que se han logrado hasta el día de hoy mostrando estadísticas y proyecciones a

futuro.

1.1. REALIDAD PROBLEMÁTICA

Actualmente el Perú ha desarrollado un gran crecimiento en sectores como

la minería y la agroindustria, así como también se ha observado una mayor

exigencia con respecto a la seguridad ciudadana. Y es desventajoso que

hasta la actualidad no se haya apostado por soluciones que involucren a

dos de las ciencias más jóvenes que hay, nos referimos a la robótica y a la

computación.

En Perú las soluciones de telecontrol, inspección, seguridad y exploración

se reducen al rastreo y recuperación de vehículos robados, cámaras de

vigilancia o pequeños sistemas de telecontrol de hogares (Domótica).

En materia de seguridad, robots desactivadores de explosivos, robots de

exploración de plantas químicas o control en check-points o puestos

fronterizos no se encuentran comercialmente disponibles.

En aplicaciones donde se requiere de inspección de recintos muy extensos,

múltiples naves a cubrir o reforzar la vigilancia en zonas muy reservadas,

prácticamente el servicio no existe.

TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES

2

Dado lo expuesto anteriormente, se pretende lograr el telecontrol de sondas

de exploración y vigilancia, desarrollado con tecnología peruana.

1.2. ANTECEDENTES

El invento del telégrafo, en 1836, dio inicio al desarrollo de las

comunicaciones modernas y con esto el concepto de Telecontrol. La

tecnología obviamente ha avanzado a pasos agigantados estos dos últimos

siglos. Con el descubrimiento de las ondas Hertzianas en 1860 se inicia la

creación de los primeros transmisores inalámbricos en 1896 por Marconi [1].

Con el desarrollo de las tecnologías de telecomunicaciones cada vez es

más cotidiano realizar actividades de telemática, inclusive por gente que no

está inmersa en el desarrollo de tecnología, de tal forma que podemos

comunicarnos con las máquinas o ellas se comunican con nosotros para

informarnos de hechos relevantes.

El desarrollo de las comunicaciones dio paso a que la robótica empiece a

jugar un papel más importante en la sociedad. Los robots dejaron de ser

esas piezas fijas en fábricas de alta producción para empezar a desarrollar

roles fuera de éstas.

En 1950, el inglés Grey Walter creó una máquina que tenía comportamiento

autónomo. Se trataba de una tortuga mecánica capaz de desplazarse hacia

cualquier fuente de luz y en ausencia de la misma se desplazaba de

manera aleatoria [2].

En 1974, en el “Artificial Intelligence Laboratory” del MIT, se trabajó sobre

los aspectos de inteligencia artificial de la realimentación de fuerzas. Se

utilizó una técnica de búsqueda de aterrizajes, propia de la navegación

aérea, para realizar el posicionado inicial de una tarea de montaje precisa [1].


3

Estos fueron los precursores para proyectos de investigación más

ambiciosos que han llegado, inclusive, a explorar superficies de otros

planetas como se detalla a continuación:

En el año 2000 fue desplegado en la guerra urbana un robot que ha

marcado un hito en la carrera armamentista. Nos referimos al Talon Robot

desarrollado por Foster-Miller, Inc. Este robot equipado con cámaras y

manipuladores ha sido usado en la desactivación de explosivos, exploración

de campos de batalla y rescate de personas.

En Julio del 2003 se llevó a cabo la primera misión de la NASA, con el fin

de explorar y analizar la superficie de Marte consistente en el envío de dos

robots, el Spirit y Opportunity. Este ha sido posiblemente el proyecto más

ambicioso y eficaz de la incipiente exploración espacial.

En el 2008, ingenieros de la Universidad de Santiago, Chile, fabricaron el

primer vehículo explorador biónico con tecnología íntegramente

desarrollada en ese país, el robot Gastón. Este vehículo con cualidades

basadas en el reino animal fue destinado a explorar zonas extremas y

proyectos de construcción.

En Enero del 2011, por primera vez en la arqueología mexicana se usó un

robot para este tipo de exploraciones; la primera fue en Egipto hace ya más

de una década. TLALOQUE I, un pequeño robot que mide 30 centímetros

de ancho, 20 de alto y 50 de largo, ingreso al túnel teotihuacano, un espacio

localizado debajo del Templo de La Serpiente Emplumada, en la zona

arqueológica, que había sido sellado hace 1.800 años por habitantes de

Teotihuacán.

Los antecedentes son muchos y no hacen más que mostrar la importancia

de este tipo de investigaciones que han llevado a los países que apostaron

por esto a alcanzar altos niveles de desarrollo.


4

1.3. JUSTIFICACIÓN

El telecontrol es aún una tecnología no explotada en el Perú, y los servicios

basados en esta aún no están disponibles en una sociedad que busca

cambios que mejoren su calidad de vida, entregando comodidad y

seguridad al quehacer diario de cada persona. Es por ello, que se diseñó y

construyó un prototipo capaz de cubrir estas necesidades tan imperantes en

la sociedad de hoy en día, para de ese modo, alcanzar el nivel tecnológico

de países que en su momento tuvieron las mismas limitaciones que nuestro

país.

Las capacidades de este prototipo son aplicables a sectores como la

industria, el comercio, seguridad nacional, la minería, la agricultura,

sectores que son desarrollados fuertemente en nuestra región.

Este proyecto representa también el primer paso hacia una era espacial que

ya exige ser iniciada en un país como el nuestro, con otras alternativas

viables de aplicación. Y sobre todo, que al ser hecha con tecnología

peruana, representa una solución de bajo costo frente a prototipos ya

ensamblados por compañías extranjeras.

1.4. PLANTEAMIENTO DEL PROBLEMA

¿Cómo controlar remotamente un robot móvil para realizar tareas de

reconocimiento y exploración en superficies terrestres?

1.5. HIPÓTESIS

A través del telecontrol se puede controlar remotamente un robot móvil para

realizar tareas de exploración y reconocimiento en superficies terrestres.


5

1.6. OBJETIVOS 1.6.1. OBJETIVO GENERAL

Controlar remotamente un robot móvil para realizar tareas de exploración y

reconocimiento en superficies terrestres.

1.6.2. OBJETIVOS ESPECÍFICOS

• Implementar un software, una arquitectura de hardware y una

infraestructura de red para el control a distancia de una sonda.

• Dotar al prototipo de la capacidad sensomotriz elemental, lo que dará la

sensación de presencia física sobre el lugar que se está explorando.

1.7. ÁREAS DE APLICACIÓN [3]

De una manera concreta se puede indicar que la robótica móvil y el

telecontrol son usadas juntas en sectores como:

• Espacio

• Construcción

• Médico

• Submarino

• Nuclear

• Limpieza

• Agricultura

• Doméstico y de Oficina

• Militar y Seguridad

• Ocio y Entretenimiento


6

1.8. ESTADO ACTUAL

En cuanto al estado actual de la robótica de exploración y servicio, el

estudio anual WorldRobotics, de la Federación Internacional de Robótica

(IFR), proporciona cifras a nivel mundial de ventas y expectativas para los

próximos años. Diferenciando el total de robots de servicios entre robots

para uso profesional y robots para uso doméstico y entretenimiento, hasta

finales de 2007 se han vendido ya 49.000 robots de servicios para uso

profesional, 3,4 millones para uso doméstico y 2 millones de robots para

entretenimiento personal. En total, se han vendido cerca de 5,5 millones de

robots de servicios (ver Figura 1.1).

Figura 1.1 Robots vendidos hasta el 2007

Pensemos que hasta hace pocos años, el robot más conocido era el robot

manipulador industrial (el brazo robótico) que se utiliza en la industria y

define como hemos dicho la llamada robótica industrial. Actualmente, el

total de robots industriales operativos (trabajando en las fábricas con una

antigüedad menor o igual a 12 años) no llega todavía al millón de unidades

(995.000 a finales de 2007), y hablamos de robots instalados desde 1995

hasta ahora, cuando muchos robots de servicios actuales aún no estaban

en el mercado.

Uso Profesional Uso DomésticoEntretenimiento

personal

Número de Robots

vendidos49000 3400000 2000000

0

1000000

2000000

3000000

4000000

Nú

me

ro

de

Un

ida

de

s


7

Figura 1.2 Robots de uso profesional vendidos

De los 49.000 robots de uso profesional, la mayor parte (12,008 unidades,

el 25%) se utilizan en aplicaciones de defensa, seguridad y operaciones de

rescate. Le siguen a continuación los robots en aplicaciones de campo

(minería, agricultura, forestal, ganadería, etc.) con un 20% del total, siendo

la principal aplicación los robots para el ordeño de animales. Robots

dedicados a la limpieza profesional hay casi unos 6.000 robots (un 12%), al

igual que robots en aplicaciones submarinas (otro 12%). Robots dedicados

a tareas de construcción o demolición hay cerca de 4.500 en todo el mundo

(un 9%), y la cifra es aproximadamente igual en el caso de robots en

aplicaciones médicas (como cirugía por ejemplo), otro 9%. Otro grupo

importante son las plataformas móviles (robots con ruedas) para distintos

usos genéricos, siendo el número de unidades de unas 3.600 (7,4%). Otras

aplicaciones de robots de servicios de uso profesional son los robots

utilizados en logística (2.019 unidades), sistemas de inspección (1.079

unidades) y robots en tareas de relaciones públicas (130 unidades),

como por ejemplo información en museos y centros comerciales (Figura

1.2).

Los robots de servicio para uso personal (entretenimiento, educación, etc.)

y doméstico (tareas del hogar, limpieza principalmente) forman otro

mercado diferente, con canales de distribución distintos (centros

comerciales, internet) y precios muy inferiores comparados con los robots

de uso profesional. Aún así representan el mayor mercado de la robótica en

Defe

nsa y

Segu

ridad

Agric

ultur

a

Limpi

eza

Aplic

acion

es

sub…

Cons

trucc

ión y

De…

Medi

cina

Logís

tica

Inspe

cción

Relac

iones

Públi

cas

Robots de Uso Profesional 12008 9800 6000 6000 4500 4500 2019 1079 130

02000400060008000

100001200014000

Nú

me

ro

de

un

ida

de

s

ve

nd

ida

s


8

cuanto a número de robots, ya que actualmente se han vendido ya más de

5 millones de unidades. De robots aspiradores (vacuum robots) se han

vendido 3,3 millones de unidades, de robots cortacésped (lawn mowing

robots), 111.000 unidades, y de robots de entretenimiento

(juguetes, humanoides y robots móviles para montar y programar, etc.)

existen ya en hogares y centros educativos más de 2 millones de robots de

entretenimiento. De otros robots para el hogar, como robots de vigilancia en

el hogar (detección de incendios o extraños en la casa), o para ayuda a

discapacitados y personas mayores (sillas de ruedas robotizadas por

ejemplo), el número actual es aún relativamente pequeño.

Figura 1.3 Ventas de Robots estimadas para el periodo 2008-2011

Según también el estudio World Robotics 2008, se estima que en el periodo

2008 a 2011 se venderán 54.000 nuevos robots de servicio para uso

profesional, y nada menos que 12,1 millones de robots para uso personal-

entretenimiento (unos 7,4 millones de nuevos robots) y tareas domésticas

(aproximadamente 4,6 millones de robots) (ver Figura 1.3). Según el

informe del año anterior (World Robotics 2007), a finales de 2006 estaban

identificadas unas 200 empresas fabricantes o desarrolladoras de robots de

servicios. A la actualidad, los robots operativos descritos están distribuidos,

de acuerdo al área donde se desenvuelven, según se indica en la Figura

1.4.

Uso ProfesionalUso Personal y

Entretenimiento

Tareas

Domésticas

1995-2007 49000 3400000 2000000

2008-2010 103000 12100000 6600000

0

2000000

4000000

6000000

8000000

10000000

12000000

14000000

Nú

me

ro

de

un

ida

de

s


Figura 1.4 Distribución de los robots en la actualidad según su área de aplicación

1.9. ORGANIZACIÓN

Construcción; 54

Desarrollo Teórico

� Diseño Top-Down� Experimentos

Capítulo VI

Arquitectura de Arquitectura de Arquitectura de Arquitectura de

ControlControlControlControl de Redde Redde Redde Red

Capítulo III

Enlace Enlace Enlace Enlace de de de de

ComunicaciónComunicaciónComunicaciónComunicación

Capítulo II

Marco TeóricoMarco TeóricoMarco TeóricoMarco Teórico

MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES

9

Distribución de los robots en la actualidad según su área de aplicación

ORGANIZACIÓN DE LA TESIS

Figura 1.5 Organización de esta tesis

Hogar; 1 Servicio de

Hoteles; 5 Oficina y

Logística; 10

Cuidado de

Enfermos; 10

Medicina y

Rehabilitación; 3

Servicios de

Comunidad; 10Control de

Desastres y

Emergencias; 7

Construcción; 54

Arquitectura Hardware Arquitectura Hardware Arquitectura Hardware Arquitectura Hardware

de Telede Telede Telede Tele

� Diseño Top-Down

� Implementación

Capítulo VII

AnálisisAnálisisAnálisisAnálisis yyyy ddddiseño del iseño del iseño del iseño del

SoftwareSoftwareSoftwareSoftware

Desarrollo de Sistemas Desarrollo Teórico

Down

Arquitectura de Arquitectura de Arquitectura de Arquitectura de

de Redde Redde Redde Red

ComunicaciónComunicaciónComunicaciónComunicación

Marco TeóricoMarco TeóricoMarco TeóricoMarco Teórico

� �

Capítulo V

SíntesisSíntesisSíntesisSíntesis del Protocolodel Protocolodel Protocolodel Protocolo

Capítulo I

IntroducciónIntroducciónIntroducciónIntroducción

Capítulo VIII

Resultados y Resultados y Resultados y Resultados y

ConclusionesConclusionesConclusionesConclusiones

MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES

Distribución de los robots en la actualidad según su área de aplicación [3]

Oficina y

Logística; 10

Cuidado de

Enfermos; 10

Medicina y

Rehabilitación; 3

Servicios de

Comunidad; 10

Capítulo IV

Arquitectura Hardware Arquitectura Hardware Arquitectura Hardware Arquitectura Hardware

de Telede Telede Telede Teleoperaciónoperaciónoperaciónoperación

Implementación Diseño Top-Down

10

CAPÍTULO II

MARCO TEÓRICO

En este capítulo se revisan las bases teóricas, que dan pie a los métodos

propuestos en esta tesis, para poder controlar correctamente a una sonda

mediante un protocolo, a fin que esta realice tareas de reconocimiento y

exploración en superficies terrestres. Para esto se revisan algunos conceptos

relacionados con la ingeniería de protocolos, el telecontrol y la robótica móvil.

2.1. CONCEPTOS FUNDAMENTALES

Anteriormente se había mencionado que la sonda de exploración o robot

utiliza un manipulador para la recolección de muestras a tomar. Así que en

primer lugar se debe hacer una diferenciación entre robot y manipulador,

puesto que ambos términos, que si bien es cierto son usados

indistintamente, tienen conceptos diferentes.

Un Manipulador es un mecanismo formado generalmente por elementos en

serie o en paralelo, articulados entre sí, destinado al agarre y

desplazamiento de objetos. Es multifuncional y puede ser gobernado

directamente por un operador humano o por un dispositivo lógico.

Por otro lado un robot es un manipulador multifuncional reprogramable con

varios grados de libertad, capaz de manipular materias, piezas,

herramientas o dispositivos especiales según trayectorias variables

programadas para realizar diversas tareas.

Además, dentro de los robots existen dos grupos: los robots fijos y los

robots móviles [2].


11

Los robots fijos se utilizan en la industria para llevar a cabo tareas

peligrosas (soldadura de chasis o pintura de las carrocerías en una fábrica

de coches).

Los robots móviles se emplean para transportar cargas (desde las cadenas

de fabricación hasta los almacenes) o incluso para transportar el correo

dentro de la oficina. Estos tienen un alto número de aplicaciones, que con

frecuencia son de naturaleza no industrial [4]. Los robots móviles pueden ser

clasificados en:

• Remotos: Controlado por medios cableados o señales de radio. • Autónomos: De capacidad autónoma o controlado por un programa.

Existen otros términos que también deben ser explicados para tener un

mejor conocimiento del ámbito de este trabajo de investigación, así como

para enmarcar los alcances de las ideas que vayan surgiendo a lo largo de

esta tesis.

Telerobótica: Es el área de la robótica concerniente al control de robots

desde la distancia, principalmente usando conexiones wireless (como Wi-

Fi, Bluetooth, la Red del Espacio Profundo, y similares), conexiones

"ancladas", o a través de Internet. Es una combinación de dos campos

importantes, tele-operación y tele-presencia.

Telepresencia: Significa "sentir como si estuvieras en algún otro lugar".

Algunas personas tienen una interpretación demasiado técnica de esto, en

la que insisten que se debe tener pantallas montadas en cascos para ser

tele-presencia. Otras personas le dan un significado específico de la tarea,

donde la "presencia" exige sentir que se está conectado emocional y

socialmente con el mundo remoto, aunque esta sea una interpretación un

poco vaga.


12

Teleoperación: Significa "hacer una acción o trabajo a distancia". Además,

el término "distancia" no está bien definido: puede referirse a una distancia

física, donde el operador está separado del robot por una larga distancia,

pero puede también referirse a un cambio de escala, donde, por ejemplo

en cirugía robótica, un cirujano puede usar tecnología de micro-

manipulación para dirigir cirugías a nivel microscópico.

2.2. PROTOCOLOS

Básicamente, un protocolo es un acuerdo entre dos o más partes que se

comunican sobre cómo va a proceder el intercambio de datos. Este acuerdo

se da ya que los protocolos plantean conjuntos de normas que rigen la

interacción de procesos entre ambas partes [5].

2.2.1. ELEMENTOS

Los elementos de un protocolo son cinco:

• Servicio que proporciona un protocolo.

• Suposiciones sobre el entorno donde se ejecuta el protocolo.

• Vocabulario de los mensajes utilizados en el protocolo.

• Formatos de los mensajes del vocabulario del protocolo.

• Reglas de procedimiento que controlan la consistencia del

intercambio de mensajes.

2.2.2. DISEÑO

El diseño de un protocolo debe estar en base a ciertas reglas que marcan

las pautas en el desarrollo de los mismos. Las reglas son las siguientes:

Simplicidad: Un protocolo bien estructurado debería estar formado por un

conjunto de piezas conocidas, que hagan una función y la hagan bien. Se

consigue facilidad de implementación y comprensión del funcionamiento.


13

Modularidad: Un protocolo que desempeñe funciones complejas debería

construirse de piezas que interactúen de manera simple y bien definida.

(Abierto, extensible, modificable). Cada pieza puede desarrollarse,

implementarse, verificarse y mantenerse por separado.

Especificación adecuada

• Sobre-especificado: Partes de código nunca se ejecutan.

• Sub-especificado (incompleto): situaciones inesperadas.

• Acotado: No desborda el sistema.

• Auto-estabilizado: Si un error modifica el estado del protocolo, éste

debe volver a un estado deseable en un número finito de transiciones.

• Auto-adaptativo: Puede modificarse de acuerdo al entorno.

Robustez

• No es complicado diseñar protocolos que funcionan en circunstancias

normales.

• Deben funcionar en circunstancias especiales, en cualquier condición y

respondiendo a cualquier secuencia de eventos.

• Un diseño robusto se escala sin gran esfuerzo.

• No sobre-diseñar: El diseño mínimo es deseable, eliminando lo

innecesario.

Consistencia

Hay circunstancias típicas donde fallan los protocolos:

Deadlocks: No es posible ejecutar. Todos los procesos esperan unas

condiciones que nunca se darán.

Livelocks: Secuencias que se repiten infinitamente sin que el protocolo

progrese.

Terminación incorrecta: Protocolo finaliza sin cumplir las condiciones de

terminación adecuadas.


14

2.2.3. MÁQUINAS DE ESTADO FINITO

Las máquinas de estado finito son una herramienta muy útil para especificar

aspectos relacionados con tiempo real, dominios reactivos o autónomos,

computación reactiva, protocolos, circuitos, arquitecturas de software, etc.

El modelo de FSM (Finite State Machine) es un modelo que posee sintaxis

y semántica formales y que sirve para representar aspectos dinámicos que

no se expresan en otros diagramas [6].

Descripción Informal

Es un sistema que acepta una entrada, que podría producir una salida y

que tiene un tipo de memoria interna que pueda llevar el registro de cierta

información acerca de las entradas anteriores. La condición interna

completa de la maquina y de toda su memoria, en un instante particular,

constituye el estado de la máquina en ese instante [14].

La representación gráfica de una tabla de estados finitos es usualmente

especificada en la forma de una tabla de transición, muy similar a la que se

muestra en la Tabla 2.1 a continuación.

CONDICIÓN EFECTO

ESTADO ACTUAL

ENTRADA SALIDA ESTADO SIGUIENTE

Q0 - 1 Q2 Q1 - 0 Q0 Q2 0 0 Q3 Q2 1 0 Q1 Q3 0 0 Q0 Q3 1 0 Q1

Tabla 2.1 Estados de transición de una máquina de estado finito

Para cada estado de control de la máquina, la Tabla 2.1 especifica un

conjunto de reglas de transición. Existe una única regla por cada fila de la

tabla, y usualmente más de una regla por estado. La tabla de ejemplo

contiene reglas de transición para los estados Q0, Q1, Q2, Q3. Cada regla de

transición tiene cuatro partes. Cada parte correspondiente a una de las


15

cuatro columnas en la tabla. Las primeras dos son condiciones que deben

ser satisfechas para que la regla de transición sea ejecutada.

El comportamiento de una máquina de estados finitos es más fácilmente

comprendido cuando es representado gráficamente en la forma de un

diagrama de transición de estados, tal como se muestra en la Figura 2.1.

Figura 2.1 Diagrama de transición de estados

Los estados de control son representados por círculos, y las reglas de

transición son especificadas como flechas rotuladas. Cada etiqueta de la

flecha es de un tipo c/e, donde c especifica la condición de transición (por

ejemplo el conjunto requerido de valores de entrada) y e el correspondiente

efecto (por ejemplo una nueva asignación para el conjunto de valores de

salida).

Descripción Formal [7]

Una máquina de estado finito es una tupla M=(S, L, O, w, v, s1), donde

(a) S es el conjunto finito de estados para M;

(b) L es el alfabeto finito de entrada para M;

(c) O es el alfabeto finito de salida para M;

(d) �: �� → Ο es la función de Salida;

(e) �: �� → S es la función de estado siguiente; y

(f) ∈ � es el estado inicial.


16

2.3. PUERTOS, SOCKETS Y MODELO CLIENTE/SERVIDOR

Los puertos y los sockets son usados para identificar procesos de

comunicación entre sistemas finales proporcionando un espacio para el

almacenamiento temporal de la información que se va a transferir e

identificadores de protocolos. Los puertos son canales lógicos, que

conectan los procesos a cada extremo. Un puerto es el valor de 16 bits que

se usa, en el modelo de la capa de transporte, para distinguir entre las

múltiples aplicaciones que se pueden conectar al mismo host.

Un socket es la interface entre la capa de aplicación y la capa de red.

Constituyen el mecanismo para la entrega de paquetes de datos

provenientes de la tarjeta de red a los procesos o hilos apropiados. Un

socket queda definido por un par de direcciones IP local y remota, un

protocolo de transporte y un par de números de puerto local y remoto.

Una red de comunicación tiene normalmente dos partes, una del lado del

cliente y un servidor. El programa cliente solicita una conexión, y el

programa servidor espera una conexión y acepta las solicitudes. También,

una aplicación puede incluir un servidor y una parte del cliente que se

pueden ejecutar en la misma o en diferentes máquinas.

2.4. TRANSMISIÓN DE DATOS EN TIEMPO REAL

Se puede hablar de transmisión de información en tiempo real cuando se

puede asegurar que la información llegue a su destino con unos parámetros

determinados (retraso, rendimiento, fiabilidad, etc.). En este sentido se

puede asumir que la transmisión multimedia tiene unos requerimientos

temporales que necesitan del uso de esta transmisión en tiempo real.

En el desarrollo de esta tesis se ha optado por usar el protocolo RTP (Real-

time Transport Protocol) que es un protocolo de sesión utilizado para la

transmisión de información en tiempo real y que tiene implementaciones


17

para las plataformas más difundidas como Java y .Net. A pesar de que el

estado tecnológico actual es desolador en lo que se refiere a transmisión en

tiempo real, el protocolo RTP ha alcanzado una madurez aceptable, siendo

incluso la base de la industria VoIP [10].

RTP, como protocolo, tiene el formato que se encuentra en la Figura 2.2,

donde los primeros doce octetos, están presentes en todos los paquetes,

mientras que la lista de identificadores CSRC (Content Source) solo son

insertados por el mezclador.

0 4 8 16 32

V=2 P X CC M PT Número de secuencia

Timestamp

SSRC

CSRC

Figura 2.2 Formato de una cabecera RTP

En la Tabla 2.2 se especifica la descripción y el tamaño de cada campo.

Campo Descripción Tamaño

Versión (V) Versión de RTP. Actualmente es la 2. 2

Padding (P) Indica si existe información adicional al final del paquete. Esta información puede ser útil para los algoritmos de encriptación.

1

Extension (X) Indica si a continuación viene una cabecera de extensión.

1

CSRC count (CC) Número de identificadores CSRC que siguen a la cabecera fija.

4

Marker (M) Está indicada para señalar eventos especiales como salirse de los límites.

1

Payload type (PT) Formato de la información que se transporta para que lo interprete la aplicación.

7

Número secuencia

Se incrementa en uno por cada paquete envía, y sirve para que el receptor detecte perdidas de paquetes.

16

Timestamp Tiempo en el que se muestra el primer octeto de los datos transmitidos en el paquete.

32

SSRC Synchronization Source Identifier. Identifica la fuente del paquete.

32

CSRC list

Contributing Source Identifiers. Esta información es introducida por los mezcladores para indicar que han contribuido a modificar la información.

32

Tabla 2.2 Descripción de los campos de una cabecera RTP


18

2.5. ROBÓTICA MÓVIL, ADQUISICIÓN Y TRANSMISIÓN DE

DATOS

Como se ha mencionado anteriormente, la característica principal de los

robots móviles es la movilidad y la independencia de un sistema físico de

guiado como por ejemplo rieles o medios magnéticos. Esto implica que los

robots móviles requieren de un sistema de navegación que les permita en

todo momento conocer su posición dentro del ambiente [11]. Para poder

adquirir esos datos es necesario obtener la información que rodea al

entorno donde se desenvuelve el robot y es de vital importancia el tipo de

tecnología para adquirir la mayor cantidad de información posible.

2.5.1. LOCOMOCIÓN

La locomoción se descompone en dos partes: la que realiza el apoyo sobre

el medio en el que se espera que se desplace el robot y la que permite su

propulsión. Esta última incluye los motores y los mecanismos que permiten

el desplazamiento.

Los medios de desplazamiento son numerosos y es conveniente aplicar un

tratamiento diferente dependiendo de que el móvil se vaya a desplazar por

el suelo o dentro de un determinado medio (avión o fondo submarino). En el

caso de los robots que utilizan ruedas para desplazarse, el cambio de

dirección se logra variando la velocidad de los motores asociados a cada

una de las ruedas laterales [2] como se muestra en la Figura 2.3.

El robot gira sobre sí mismo

El robot gira mientras avanza

Figura 2.3 Cambio de dirección de un robot terrestre


19

2.5.2. PERCEPCIÓN

Esta parte del robot es normalmente la más difícil de construir. La

percepción pasa por dos etapas sucesivas: la lectura de los sensores y el

tratamiento de la información. La interpretación, que permite suministrar un

mensaje claro a la función de “locomoción”, se desarrolla en la función de

“decisión” del robot [2].

Al igual que sucede en el ser humano, la capacidad de visión dota al

operador de un sofisticado mecanismo de percepción, que le permite

responder a su entorno de manera más flexible e inteligente, en

comparación con otros mecanismos de detección [1].

2.5.3. CONTROL DEL ROBOT

El sistema de control es el encargado de la monitorización de los sistemas

físicos del robot y de su estado interno, como puede ser: energía

disponible, posicionamiento de servomecanismos, lectura de encoders, etc.

Este sistema también se encarga del control tanto de actuadores como de

sensores. Permite a la vez que otros sistemas de más alto nivel interactúen

con el robot sin la necesidad de conocer su estructura interna [5], tal como

se puede ver en la Figura 2.4.

Sistemas de Alto Nivel (Software)

Middleware

Sistemas de Control y Comunicaciones (Hardware y Firmware)

Estructura interna del robot móvil (Mecanismos y Actuadores)

Figura 2.4 Diagrama de Bloques del Robot Móvil


20

2.5.4. NAVEGACIÓN DEL ROBOT

Este sistema, junto con el sistema de transmisión de datos, es el encargado

de realizar tareas como el piloteado del robot, lo cual permite al móvil

desplazarse teniendo en cuenta el ambiente que lo rodea.

La capacidad de navegación del robot está en función de dos factores

importantes:

• La secuencia de imágenes que llegan a la estación de mando, a través

de las cámaras que posee el móvil. Esta técnica de control visual

necesita de manera explícita las variaciones de la información visual de

la imagen, los movimientos de la cámara (matriz de interacción) y otros

factores [12].

• Un módulo de posicionamiento global basado en el protocolo NMEA

(National Marine Electronics Association) el cuál entregará

constantemente parámetros de navegación de la sonda en el espacio

de exploración.

2.5.5. COMUNICACIÓN

Varios mensajes serán intercambiados entre el robot móvil y la estación de

control, lo cual implica, según:

• Administración de recursos en tiempo real

• Comunicación de datos de configuración y localización

• Transmisión de comandos en tiempo real

• Retroalimentación de posiciones

• Transferencia de imágenes y sonido


21

2.5.6. TRANSMISIÓN

Como se ha mencionado en la parte de comunicación, la información y los

datos a ser transferidos son de distinta naturaleza, por lo que requieren de

distintos métodos de transferencia. La solución óptima depende de la

calidad de los medios de comunicación, como la calidad de la red, las

circunstancias de tráfico actual, la cantidad total, la compresión y la

importancia de los datos especificados [13].

El telecontrol de un Robot Móvil implica la necesidad de transferir los datos

que se especifican en la Tabla 2.3.

Tipo de Señal Descripción

Datos Administrativos (Control de Acceso, Datos de Configuración)

Paquetes de pequeño tamaño, requieren transmisión fiable, sin limitaciones en tiempo real.

Comandos Paquetes de pequeño tamaño, requieren retransmisión fiable.

Señales de Control (Datos de medición de posiciones)

Paquetes de pequeño tamaño, requieren transferencias periódicas en tiempo real, la pérdida de paquetes puede ser aceptable.

Datos de Audio y Video (Retransmisión visual desde el robot)

Requiere ancho de banda considerable, transferencia periódica en tiempo real, la perdida de paquetes es aceptada.

Datos de localización Paquetes de pequeño tamaño, requieren transferencias periódicas en tiempo real, requieren retransmisión fiable.

Tabla 2.3 Tipos de datos transferidos entre el robot móvil y la estación de control

22

CAPÍTULO III

ENLACE DE COMUNICACIÓN

Los medios de comunicación llevan información entre todos los subsistemas de un

sistema de telecontrol. Las comunicaciones entre las unidades de control del robot

y los servidores o entre las cámaras y los servidores están implementadas a

través de conexiones RS-232 o USB. De otro lado, la comunicación entre el lado

del cliente y el lado del servidor, que es el medio de comunicación principal, está

establecida vía el protocolo 802.11x. En esta sección el protocolo 802.11x, el

retardo de tiempo como su principal inconveniente, así como la pérdida de

paquetes son descritos ya que ellos son relevantes al momento de diseñar

mecanismos y determinar estrategias de control.

3.1. PROTOCOLO 802.11

El protocolo IEEE (Institute of Electrical and Electronic Engineers) 802.11 es

un estándar de protocolo de comunicaciones de la IEEE que define el uso

de los dos niveles más bajos de la arquitectura OSI (Open Systems

Interconnection) en las capas físicas y de enlace de datos, especificando

sus normas de funcionamiento en una red inalámbrica. En general, los

protocolos de la rama 802.x definen la tecnología de redes de área local [3].

El estándar original de este protocolo data de 1997, era el IEEE 802.11,

tenía velocidades de 1 hasta 2 Mbps y trabajaba en la banda de frecuencia

de 2.4 GHz. En la actualidad no se fabrican productos sobre este estándar.

La siguiente modificación apareció en 1999 y es designada como IEEE

802.11b, esta especificación tenía velocidades de 5 hasta 11 Mbps también

trabajaba en la frecuencia de 2.4 GHz.


23

También se realizó una especificación sobre una frecuencia de 5 GHz que

alcanzaba los 54 Mbps era la 802.11a y resultaba incompatible con los

productos 802.11b y por motivos técnicos casi no se desarrollaron

productos. Posteriormente se incorporó un estándar a esa velocidad y

compatible con el b que recibiría el nombre de 802.11g. En la actualidad la

mayoría de productos son de la especificación b y g.

3.2. RETARDO DE TIEMPO

A la actualidad se han logrado mejoras en el protocolo 802.11x,

incrementando las capacidades en la transmisión de datos tal como se

muestra en la Tabla 3.1.

Estándar 802.11a 802.11b 802.11g 802.11n Fecha 1999 1999 2003 n.d.

Velocidad (Mbps)

54 11 54 600

Modulación

OFDM OFDM

DSS CCK CCK

DSSS CCK

OFDM

DSSS CCK

OFDM Banda (GHz) 5 2.4 2.4 2.5 o 5 Nº de Flujos 1 1 1 1 a 4 Canal (MHz) 20 20 20 20 o 40

Tabla 3.1 Comparación de los diferentes estándares de la familia 802.11 [15]

Sin embargo, el protocolo es aún parte de una red conmutadora de

paquetes, en donde la comunicación de mensajes usa recursos, como

buffers o ancho de banda, bajo demanda, y como consecuencia se

producen tiempos de espera para el acceso a los enlaces de comunicación.

Estos tiempos de espera son conocidos como colas .

Las colas de espera ocurren en cada enrutador a lo largo de la ruta que

sigue un paquete y ocasionan Colas de Retardo, que es un tipo importante

de retardo en la transferencia de datos. Los otros son Retraso de

procesamiento en los nodos, Retrasos de transmisión y Propagación de


24

retardos [17]. La suma de estos retardos constituye el retardo total nodal y se

muestra en la Figura 3.1.

Figura 3.1 Retardo nodal total en el enrutador A

3.2.1. RETARDO DE NODO

Retardo de Procesamiento: Es el tiempo requerido para examinar las

cabeceras de los paquetes y determinar a dónde se tendrá que reenviar el

paquete. Este tipo de retardo puede ser también inducido por otros factores,

tal como el tiempo requerido para revisar los bits indicadores de error en un

paquete. Este tipo de retardo en enrutadores de alta velocidad es

típicamente en el orden de los microsegundos.

Retardo de Colas: Un paquete se encuentra en retardos de cola, mientras

este espera a ser transmitido a través de un enlace. El retardo de cola de

un paquete específico dependerá del número de paquetes que hayan

arribado antes, hayan sido encolados y estén esperando a ser transmitidos

a través del mismo enlace. Los paquetes serán transmitidos usando una

política FIFO (first-in-first-out), es decir los primeros en llegar serán los

primeros en ser transmitidos. Si no hay ningún paquete esperando a ser

transmitido entonces el retardo será 0. En la práctica, los retardos de cola

pueden ser en el orden desde los microsegundos hasta los milisegundos.

Retardo de Transmisión: Este retardo está relacionado con la longitud del

paquete (L bits) y la tasa de transmisión en el enlace (R) desde un

enrutador A hacia un cliente o servidor de telecontrol a una velocidad de R

Procesamiento Nodal Colas Transmisión Propagación

Enrutador A Unidad Remota


25

bits/seg. El retardo de transmisión es L/R. Esta es la cantidad de tiempo

requerida para transmitir todos los bits de los paquetes en el enlace. En la

práctica, al igual que el retardo de cola, puede ser en el orden desde los

microsegundos hasta los milisegundos.

Retardo de Propagación: El tiempo requerido para propagar un paquete

desde el inicio del enrutador A es el retardo de propagación. Los bits se

propagan a la velocidad de propagación del enlace. La velocidad de

propagación está ligada al medio físico del enlace y está en el rango de

2x108 m/s a 3x108 m/s, que es igual a, o un poco menos que la velocidad

de la luz. El tiempo de propagación es la distancia entre dos elementos de

una red dividido por la velocidad de propagación [18].

Figura 3.2 Tiempos de retardo en el envío de paquete ICMP entre un enrutador y una

unidad remota a una distancia media inferior a 5 metros con línea de vista.

Estadísticas de ping para 192.168.1.1 Paquetes enviados

26 Paquetes recibidos

26 Paquetes perdidos

0

Total de paquetes perdidos (0% perdidos) Tiempos aproximados de ida y vuelta en milisegundos

Mínimo 1ms Máximo 2208ms Media 1100ms

Tabla 3.2 Resultados del envío de paquetes ICMP a una distancia media inferior a 5 metros con línea de vista entre un enrutador y una unidad remota.

(segundos)


26

Figura 3.3 Tiempos de retardo en el envío de paquete ICMP entre un enrutador y una

unidad remota a una distancia media de 20 metros sin línea de vista.




1

Total de paquetes perdidos (1% perdidos) Tiempos aproximados de ida y vuelta en milisegundos

Mínimo 1ms Máximo 1345ms Media 615ms

Tabla 3.3 Resultados del envío de paquetes ICMP a una distancia media de 20 metros sin línea de vista entre un enrutador y una unidad remota.

Figura 3.4 Tiempos de retardo en el envío de paquete ICMP entre un enrutador y una unidad remota a una distancia media superior a 30 metros sin línea de vista.

(segundos)

(segundos)


27




14

Total de paquetes perdidos (29% perdidos)

Tiempos aproximados de ida y vuelta en milisegundos Mínimo 8ms Máximo 2013ms Media 627ms

Tabla 3.4 Resultados del envío de paquetes ICMP a una distancia media superior a 30 metros sin línea de vista entre un enrutador y una unidad remota.

Todos estos retardos constituyen el retardo nodal, que es, el retardo en un

único enrutador. En la Figura 3.2 se muestra los retardos producidos al

enviar paquetes ICMP entre un enrutador y una unidad remota a una

distancia media inferior a 5 metros. En la Taba 3.2 se muestran los

resultados generales en donde se puede apreciar que el envío de paquetes

ha tenido una tasa de éxito del 100%. La Figura 3.3 y Figura 3.4 muestran

el decremento de éxito en la tasa de envío de paquetes ICMP en una

relación inversamente proporcional con respecto a la distancia media.

Conforme incrementamos la distancia entre la unidad remota y el enrutador,

la tasa de error se incrementa de manera alarmante. Los resultados de la

Tabla 3.3 y Tabla 3.4 muestran las altas tasas de error (o paquetes

perdidos) que servirán más adelante como factor para la toma de

decisiones respecto a los mecanismos y estrategias en el control de la

transferencia de datos.

3.2.2. JITTER

El tiempo de retardo en una red no es constante. Todos los parámetros

discutidos hasta el momento son variables. Estos parámetros son,

principalmente, el número de paquetes en espera, la tasa de transferencia

de cada enlace, las distancias entre enrutadores o el tamaño de los

paquetes a transmitir. Los paquetes son transmitidos a intervalos regulares

desde un origen pero estos llegan al destino a intervalos irregulares. A esta

situación se le denomina Jitter, también definido como la variación de una


28

métrica (por ejemplo el retardo) con respecto a alguna métrica de referencia

(por ejemplo el retraso promedio o el menor retraso registrado).

3.2.3. PÉRDIDA DE PAQUETES

Cuando la congestión en un enlace de comunicación se incrementa, puede

ocurrir la pérdida de paquetes. Un paquete puede encontrarse con una cola

llena cuando este arribe a un enrutador, lo cual provocará que el enrutador

lo elimine y no alcance su destino. La pérdida de paquetes es un factor

importante para la medida del rendimiento de un protocolo de telecontrol.

Muchos protocolos existentes implementan mecanismos de recuperación

para paquetes perdidos o corruptos, con el fin de retransmitirlos si es

necesario. En muchos casos estos mecanismos conducen a un alto grado

de latencia en la red pero por otro lado brindar fiabilidad en la transmisión

de paquetes a través de un enlace.

Teniendo en cuenta la variación del retardo (Jitter) y las pérdidas de paquetes, el

enfoque de control a aplicar debe hacer frente a estos factores perturbadores. La

entrega de los paquetes fuera de orden debe ser manejada y controlada para

asegurar la fiabilidad en la transmisión de datos entre unidades remotas. Tomar el

medio de comunicación en cuenta, como un factor realmente influyente, es

importante para mejorar el rendimiento del protocolo de telecontrol.

29

CAPÍTULO IV

ARQUITECTURA HARDWARE DE TELEOPERACIÓN

Como objetivo general para esta tesis se ha dispuesto realizar el telecontrol de un

robot móvil, el cuál consta de una arquitectura hardware que le permite ser

telecontrolado. En este capítulo se describe la arquitectura principal del sistema de

teleoperación diseñado, de forma global así como por medio de una descripción

por bloques que muestra la estructura funcional de cada módulo o circuitos

electrónicos que la compone.

4.1. ARQUITECTURA PRINCIPAL

Por lo general un sistema de telecontrol consta de dos componentes, el

maestro o sistema local y el esclavo o sistema remoto. Los comandos son

especificados por un operador a través del sistema maestro [17].

El sistema maestro suele ser simplemente una interfaz (un dispositivo

mecánico o la integración de este con un software). Estos comandos son

enviados a un esclavo y la información relevante sobre la ejecución de las

tareas es retornada al operador. El sistema esclavo suele ser una interface

a través de la cual se interactúa directamente con el entorno de trabajo y

puede ser más complejo que el dispositivo maestro, ya que al relacionarse

con un ambiente, requiere altos grados de libertad, mayor capacidad

sensitiva, destreza, alta capacidad de potencia entre otros muchos factores.

Inclusive en algunos casos puede ser necesaria la presencia de cierta

autonomía [17].


30

En esta tesis, el sistema maestro consiste en un software para la recepción,

interpretación gráfica y visualización de los datos de exploración y una

interfaz de entrada de tipo joystick para el envío de comandos de control a

la sonda. Los comandos de navegación son generados con la interface de

joystick o mediante el software. Estos comandos viajan a través de un

enrutador para llegar al sistema esclavo mediante el uso de sockets. Si los

comandos son completados satisfactoriamente o no, el maestro recibe un

acuse de recibo (mensajes de confirmación) y las imágenes de video

relacionadas a este evento.

El esclavo es un robot móvil equipado con 4 cámaras de video, un

micrófono, una tarjeta de adquisición de datos, sensores de temperatura,

etapas de potencia y un módulo receptor de GPS (Sistema de

Posicionamiento Global). Los comandos generados en el sistema maestro

son enviados a la sonda o robot y los acuses de recibo del robot

relacionados a estos comandos son procesados por una unidad remota de

control y enviados al sistema maestro para su evaluación.

La arquitectura principal es mostrada en la Figura 4.1. Esta arquitectura

está basada en dos partes principales: El sistema maestro y el sistema

esclavo.

El enlace de comunicación entre ambas partes es realizado a través de una

red de área local. Los protocolos de comunicación utilizados en este enlace

están implementados sobre el modelo TCP/IP.


31

Figura 4.1 Diagrama general de bloques del sistema de teleoperación desarrollado

4.2. EL GAMEPAD COMO DISPOSITIVO DE INTERFAZ DE

TELEOPERACIÓN

Un gamepad (Figura 4.2) es un dispositivo de entrada usado para

interactuar con un videojuego ya sea para consola o PC. El gamepad o

control de mando permite moverse e interactuar con los elementos del

Dispositivo de

Interfaz de

Teleoperación

Estación de Telecontrol Interfaz

Hombre-Máquina

Bus Serial Universal

Enrutador (Capa Física)

*USB: Bus Serial Universal. *NMEA: Protocolo estándar usada por receptores de GPS.

Protocolo 802.11

Unidad Remota

Controladora del

Robot

Etapa de

Potencia

(H-Bridge)

Actuadores

de

orientación y

movimiento

Bus Interno

Microcontrolador

Sensores de

Temperatura

Tarjeta de Adquisición

de Datos

USB*

RS-232 USB*

Unidad Remota de Procesamiento

Dispositivos

de

Adquisición

de

Audio/Video

Módulo de GPS (NMEA*)

Bus Interno

Bus Interno

Conexión de Área Local


juego para realizar las diversas acciones necesarias para cumplir los

objetivos.

Figura 4.2 El gamepad como dispositivo de interfaz de teleoperaciónDisposición de botones y palancas. Derecha: Estructura interna.

El uso del gamepad en el control de la sonda obedece a razones de

ergonomía ya que facilita el modo

integrado por botones y palancas que envía las señales o comandos al

equipo de cómputo para que este las procese y de ese modo dar al

operador una sensación de realismo al dirigir el robot móvil.

que permite su uso es el de poder procesar múltiples entradas a la vez, por

lo que diversos mecanismos podrán ser movidos o rotados a la misma vez.

4.2.1. INTERCONEXIÓN DEL GA

En esta sección se explicará cómo el gamepad ha sido conectado

satisfactoriamente

JInput es una Interfaz de Programación de Aplicaciones (API) para la

visualización y control de dispositivos de entrada que van desde el

teclado hasta los populares joysticks e incluso gamepads.

pesar de la portabilidad y flexibilidad que ofrece esta API

dispositivo ha tenido que seguir un proceso de selección cuidadoso

verificando dos factores importantes que son:


32


El gamepad como dispositivo de interfaz de teleoperaciónDisposición de botones y palancas. Derecha: Estructura interna.


ergonomía ya que facilita el modo de telecontrol al ser un dispositivo



operador una sensación de realismo al dirigir el robot móvil.

e su uso es el de poder procesar múltiples entradas a la vez, por


INTERCONEXIÓN DEL GAMEPAD CON JAVA


satisfactoriamente con una aplicación en Java.


visualización y control de dispositivos de entrada que van desde el

teclado hasta los populares joysticks e incluso gamepads.

la portabilidad y flexibilidad que ofrece esta API


verificando dos factores importantes que son:



El gamepad como dispositivo de interfaz de teleoperación. Izquierda: Disposición de botones y palancas. Derecha: Estructura interna.


al ser un dispositivo



operador una sensación de realismo al dirigir el robot móvil. Otra ventaja

e su uso es el de poder procesar múltiples entradas a la vez, por




visualización y control de dispositivos de entrada que van desde el conocido

teclado hasta los populares joysticks e incluso gamepads. Sin embargo, a

la portabilidad y flexibilidad que ofrece esta API, el uso de este



33

• El dispositivo debe ser definitivamente soportado por el sistema

operativo que alojará a la aplicación que se está desarrollando. Esto

usualmente no es un problema para las plataformas Windows, pero

para plataformas libres como Linux se tendrá que verificar el correcto

funcionamiento del dispositivo.

• Otro factor importante es el de elegir un dispositivo con una conexión

USB, a pesar de que esto no es obligatorio si es altamente

recomendable puesto que una conexión USB muchas veces supone un

correcto funcionamiento en múltiples plataformas, según la experiencia

de muchos desarrolladores de juegos.

Cuando Windows detecta un nuevo dispositivo de entrada automáticamente

instala sus propios controladores o solicita la instalación de uno por parte

del usuario. En caso el gamepad haya sido instalado correctamente, este

será accesible a través del panel de control de Windows como se muestra

en la Figura 4.3.

Figura 4.3 Ventana de controladores de juegos de Windows


34

Es importante que el gamepad sea calibrado, de este modo el sistema

operativo interpretará correctamente sus entradas. Una pobre calibración se

verá reflejada en valores que son incorrectamente redondeados o tienen

sentidos de orientación incorrectos. La ventana de calibración de

dispositivos de juegos (Figura 4.4) es accesible a través del Panel de

Control de Windows. Luego de realizar las calibraciones correspondientes,

la aplicación en java estará en la capacidad de interactuar con un gamepad

como interfaz de entrada.

Las pruebas de conexión mostrados en la Figura 4.5 indican que el primer

paso para el uso de un gamepad como interfaz de entrada de comandos ha

sido completado satisfactoriamente. La aplicación escrita en java ha

reconocido al dispositivo y muestra algunas de sus características.

Figura 4.4 Ventana de propiedades y calibración de un dispositivo de juegos en Windows


20/06/2011 02:19:17 PM net.java.games.input.DefaultControllerEnvironment getControllersINFO: Loading: net.java.games.input.DirectAndRawInputEnvironmentPluginEncontrado el control Teclado estMicrosoft Natural PS/2 KeEncontrado el control Mouse compatible con HID que es un MouseEncontrado el control Generic USB Joystick que es un Stick

Figura 4.5 Resultados de las pruebas de interconexión entr

4.3. DISPOSITIVOS

Cuatro videocámaras son usadas en el sistema de telecontrol propuesto

para proveer de un sistema de retroalimentación visual desde la sonda de

exploración al operador. Tres de estas cámaras son cámaras web con

sensor CMOS y de 5 megapixeles d

4.6) además de una cámara IP inalámbrica de similares características

micrófono incorporado para la transmisión de audio.

Figura 4.6 Cámara web VGA Halion HA

En teleoperación es importante proveer interfaces de usuario amigables con

el fin de que la interacción entre el

manera confortable

video de tal forma que esta disposición permite a la persona que está

controlando remotamente al robot tener una visión única del ambiente que

se está explorando, además de la posibilidad de poder rotar estas


35

20/06/2011 02:19:17 PM net.java.games.input.DefaultControllerEnvironment getControllersINFO: Loading: net.java.games.input.DirectAndRawInputEnvironmentPluginEncontrado el control Teclado estándar de 101/102 teclas o Microsoft Natural PS/2 Keyboard que es un Keyboard Encontrado el control Mouse compatible con HID que es un MouseEncontrado el control Generic USB Joystick que es un Stick

Resultados de las pruebas de interconexión entre Java y un gamepad

DISPOSITIVOS DE AUDIO Y VIDEO




sensor CMOS y de 5 megapixeles de resolución y conexiones USB (Figura

) además de una cámara IP inalámbrica de similares características

micrófono incorporado para la transmisión de audio.

Cámara web VGA Halion HA-184. Derecha: Sensor CMOS. Izquierda: Lente

con filtro de vidrio cristalino.


de que la interacción entre el operador y la sonda se lleve a cabo de

manera confortable [17]. Por esta razón se han posicionado 4 cámaras de



se está explorando, además de la posibilidad de poder rotar estas


net.java.games.input.DefaultControllerEnvironment getControllers

net.java.games.input.DirectAndRawInputEnvironmentPlugin ndar de 101/102 teclas o

Encontrado el control Mouse compatible con HID que es un Mouse Encontrado el control Generic USB Joystick que es un Stick

Java y un gamepad




y conexiones USB (Figura

) además de una cámara IP inalámbrica de similares características y un

184. Derecha: Sensor CMOS. Izquierda: Lente


operador y la sonda se lleve a cabo de

Por esta razón se han posicionado 4 cámaras de



se está explorando, además de la posibilidad de poder rotar estas cámaras


hasta en 4 diferentes grados de libertad

operador de una vista panorámica de 360 grados sin tener el problema que

se tendría con cámaras sobre soportes fijos

La cámara de la Figura 4.

soporte rotatorio para una fácil inspección de un ambiente.

Figura 4.7 Cámara IP WIFI con movimiento y visión nocturna. Derecha:

4.4. TARJETA DE ADQUISICI

La captura de señales procedentes de determinados sistemas físicos en

cuyo ámbito no puede disponerse de ordenadores convencionales o de

sistemas de instrumentación estándares, se puede realizar en la actualidad

utilizando la opción de tarjetas de adquisición para sist

El hardware, según se muestra en la Figura 4.

unidad de control, unidad de adquisición, dos buses análogos, salidas

digitales y una fuente de alimentación.

microcontrolador rodeado por una serie de conectores de entrada y salida.

Se puede observar relativamente pocos componentes lo que evidencia que

detrás de este circuito existe un firmware encargado de la gestión de todos

los datos adquiridos.


36

4 diferentes grados de libertad con el objetivo de proveer al

una vista panorámica de 360 grados sin tener el problema que

cámaras sobre soportes fijos.

La cámara de la Figura 4.7, al ser inalámbrica, puede ser colocada sobre un


Cámara IP WIFI con movimiento y visión nocturna. Derecha: Izquierda: Vista normal.

TARJETA DE ADQUISICI ÓN DE DATOS

señales procedentes de determinados sistemas físicos en



utilizando la opción de tarjetas de adquisición para sistemas móviles

El hardware, según se muestra en la Figura 4.8, está conformado por una


digitales y una fuente de alimentación. Dicho circuito no es más que un

rodeado por una serie de conectores de entrada y salida.



los datos adquiridos.


con el objetivo de proveer al

una vista panorámica de 360 grados sin tener el problema que

colocada sobre un


Cámara IP WIFI con movimiento y visión nocturna. Derecha: Vista posterior.

señales procedentes de determinados sistemas físicos en



emas móviles [19].

, está conformado por una


Dicho circuito no es más que un

rodeado por una serie de conectores de entrada y salida.




37

Figura 4.8 Diagrama de bloques de la tarjeta de adquisición de datos

4.4.1. UNIDAD DE CONTROL

El corazón de la tarjeta de adquisición de datos es un microcontrolador con

soporte USB de la casa de Microchip del tipo 18F4550 (Figura 4.9) cuyo

firmware se encuentra programado en lenguaje C y cuya función es la de

controlar todo el proceso de adquisición, conversión y envío de información

así como la de atender a los diferentes periféricos de la sonda.

4.4.2. FUENTE DE ALIMENTACIÓN

La tarjeta cuenta con una fuente de alimentación externa. El tener soporte

USB le permite recibir la corriente necesaria desde el computador sin

embargo se le ha acondicionado la fuente independiente para posteriores

mejoras del proyecto.

4.4.3. UNIDAD DE ADQUISICIÓN Y BUSES ANALÓGICOS

La unidad de adquisición se encarga de la captura de las temperaturas,

tanto interna como externa, mediante un par de sensores LM35,

provenientes del entorno explorado para luego ser enviadas por un par de

buses analógicos hacia la unidad de control.

Unidad de

Control

Unidad de

Adquisición

Salidas Digitales

Bus Analógico 1

Bus Analógico 2

Bus Interno


38

Figura 4.9 Tarjeta de adquisición de datos basada en el Microcontrolador 18F4550

El sistema de adquisición de datos posee dos canales analógicos y 28

canales digitales los cuáles, con una modificación en el firmware, pueden

convertirse en entradas digitales o analógicas inclusive ya que el diseño del

circuito impreso ha sido desarrollado de manera flexible ante posibles

cambios o mejoras en el proyecto. Esta flexibilidad permite iniciar sin

demasiados problemas la fase de integración con diferentes bloques del

proyecto en general.

4.4.4. SALIDAS DIGITALES

Las salidas digitales son utilizadas para el control de periféricos y

actuadores de la sonda de exploración usando como intermediario a

tarjetas de potencia que serán descritas posteriormente.

1 2Y1

ECS-10-13-1

RC7/RX/DT/SDO 1

RD4/SPP42

RD5/SPP5/P1B3

RD6/SPP6/P1C 4

RD7/SPP7/P1D5

VSS6

VDD7

VDD8

RB0/AN12/INT0/FLT0/SDI/SDA9

RB1/AN10/INT1/SCK/SCL10

RB2/AN8/INT2/VMO11

RB3/AN9/CCP2/VPO 12

NC13

RB4/AN11/KBI0/CSSPP14

RB5/KBI1/PGM15

RB6/KBI2/PGC16

RB7/KBI3/PGD 17

MCLR/VPP/RE318

RA0/AN0 19

RA1/AN120

RA2/AN2/VREF-/CVREF21

RA3/AN3/VREF+ 22

RA4/T0CKI/C1OUT/RCV23

RA5/AN4/SS/HLVDIN/C2OUT24

RE0/AN5/CK1SPP25

RE1/AN6/CK2SPP26

RE2/AN7/OESPP27

VDD28

VDD29

VSS30

VSS31

OSC1/CLKI32

OSC2/CLKO/RA633

RC0/T1OSO/T13CKI34

RC1/T1OSI/CCP2/UOE35

RC2/CCP1/P1A 36

VUSB37

RD0/SPP038

RD1/SPP139

RD2/SPP2 40

RD3/SPP341

RC4/D-/VM42

RC5/D+/VP43

RC6/TX/CK44

U2

PIC18F4550-I/ML

22pF

C1C0402

22pF

C2C0402

GND GND

12345678

P2

R

123456

P3

SOC

12345678910

P4

RA

IN1

2

OUT 3

GND

U1 MC7805CTD1

1N4007

100nF

C3C0402 100uF/25V

C4T491B

GND GND GND

VCC

12V

100uF/16v

C5T491B

GND

S1

SW-PB

11

6

4K7

R1A

1 16

100

R2A

VCC

GND

Reset

Reset

VBUS1

D- 2D+

3GND4

SHLD 5J1

440247-1

12

P1

C

GND

GND

11

6

330

R3A

VCC

OSC1

OSC2

OSC1 OSC2

RC4RC5

RC4RC5

47uF

C6C0402

GND

RE0RE1RE2

RA4RA5RA6

RE0RE1RE2RA4RA5RA6

RA3RA2

RA2RA3

RD0RD1RD2RD3RD4RD5RD6RD7

RD0RD1RD2RD3RD4RD5RD6RD7

RB0RB1RB2RB3

RB5RB6RB7

RB0RB1RB2RB3RB5RB6RB7RC0RC1RC2

RC0RC1RC2

VO2

+VS1

3

GND

U3 LM35DZ

VO2

+VS1

3

GND

U4 LM35DZ

GND

GND

VCC

VCC

11

6

100

R4A

11

6

100

R5A

GND

GND

AN0

AN1

AN0AN1


39

4.5. MÓDULO DE NAVEGACIÓN Y POSICIONAMIENTO

Este módulo (Figura 4.10) ha sido desarrollado con la finalidad de

determinar la ubicación del robot así como la velocidad a la que este viaja

tomando como referencia coordenadas reales. El análisis del entorno del

robot móvil no solo consiste en la transmisión de datos multimedia o

variables ambientales sino también su ubicación misma en el entorno. Esto

se logra mediante el Sistema de Posicionamiento Global (G.P.S.)

Figura 4.10 Diagrama de bloques del módulo de navegación y posicionamiento

El sistema diseñado está constituido por un receptor Conexant Jupiter como

el de la Figura 4.11, con el cual se consigue saber la ubicación del robot y

planear su recorrido. Para esto cuenta con una conexión serial mediante un

MAX232 con dos tipos de conectores: un conector DB9 y un RJ45.

Actualmente en cada 6 órbitas, de aproximadamente 20,000 kilómetros de

altitud, se puede encontrar 4 satélites GPS. Esto se debe a que el periodo

de una vuelta es aproximadamente 12 horas, y cada vez que uno está

saliendo de órbita otro ya se encuentra reemplazándolo [20].

Figura 4.11 Receptor GPS Conexant Jupiter. Derecha: Vista superior. Izquierda: Vista

inferior

MAX232

GPS


40

De acuerdo con esto, el receptor GPS es el encargado de recibir los datos

enviados por estos satélites y con ello calcular su posición mediante

triangulación. Para calcular esta posición se debe conocer primero el valor

de las distancias hacia los satélites que serán utilizados en el proceso de

cálculo [21] aplicando la siguiente ecuación:

�� = � ∗ � ± ∆

Donde: d: Distancia hacia el satélite i t: Tiempo de viaje de la señal c: Velocidad de las ondas electromagnéticas (299,792.458 m/s) ∆: Error que se admite ya que la señal no viaja en el vacío

Una vez conocidas las distancias, la triangulación es usada para la

ubicación de un punto en la tierra conociendo la ubicación de 4 satélites

(S1,S2,S3,S4) y las respectivas distancias (d1,d2,d3,d4) de los satélites al

punto buscado (P0) como se aprecia en el modelo vectorial de la Figura

4.12.

Figura 4.12 Modelo vectorial del proceso de triangulación

S1(x1,y1,z1) S2(x2,y2,z2)

S3(x3,y3,z3)

S4(x4,y4,z4)

P0

V0

V1

V2 V3

V4

d1

d2

d3

d4


41

‖01‖ = ‖02‖ = ‖03‖ = ‖04‖ = 5 01 = 06 + �1 02 = 06 + �2 03 = 06 + �3 04 = 06 + �4 De donde tenemos: ‖01‖ = ‖06‖2 + 20601 + ‖�1‖2 … … … … … … … . (1) ‖02‖ = ‖06‖2 + 20602 + ‖�2‖2 … … … … … … … . (2) ‖03‖ = ‖06‖2 + 20603 + ‖�3‖2 … … … … … … … . (3) ‖04‖ = ‖06‖2 + 20604 + ‖�4‖2 … … … … … … … . (4)

Efectuando:

(1) en (2) 06. (�1 − �2) = ‖�2‖2 − ‖�1‖22 … … … … … … … . (5)

(2) en (3) 06. (�2 − �3) = ‖�3‖2 − ‖�2‖22 … … … … … … … . (6)

(3) en (4) 06. (�3 − �4) = ‖�4‖2 − ‖�3‖22 … … … … … … … . (7)

Sabiendo que: �1 = =>1 − >6;@1 − @6; A1 − A6B �2 = =>2 − >6;@2 − @6; A2 − A6B �3 = =>3 − >6;@3 − @6; A3 − A6B �4 = =>4 − >6;@4 − @6; A4 − A6B


42

Tenemos: �1 − �2 = =>1 − >2;@1 − @2; A1 − A2B �2 − �3 = =>2 − >3;@2 − @3; A2 − A3B �3 − �4 = =>3 − >4;@3 − @4; A3 − A4B

De las ecuaciones (5), (6) y (7) tenemos el siguiente sistema: >6(>1 − >2) + @6(@1 − @2) + A6(A1 − A2) = ‖�2‖2 − ‖�1‖22

>6(>2 − >3) + @6(@2 − @3) + A6(A2 − A3) = ‖�3‖2 − ‖�2‖22

>6(>3 − >4) + @6(@3 − @4) + A6(A3 − A4) = ‖�4‖2 − ‖�3‖22

Con esto finalmente podemos determinar los puntos buscados:

>6 =CC‖�2‖2 − ‖�1‖22 @1 − @2 A1 − A2‖�3‖2 − ‖�2‖22 @2 − @3 A2 − A3‖�4‖2 − ‖�3‖22 @3 − @4 A3 − A4

CC

D>1 − >2 @1 − @2 A1 − A2>2 − >3 @2 − @3 A2 − A3>3 − >4 @3 − @4 A3 − A4D

@6 =CC>1 − >2 ‖�2‖2 − ‖�1‖22 A1 − A2>2 − >3 ‖�3‖2 − ‖�2‖22 A2 − A3>3 − >4 ‖�4‖2 − ‖�3‖22 A3 − A4

CC

D>1 − >2 @1 − @2 A1 − A2>2 − >3 @2 − @3 A2 − A3>3 − >4 @3 − @4 A3 − A4D


43

A6 =CC>1 − >2 @1 − @2 ‖�2‖2 − ‖�1‖22>2 − >3 @2 − @3 ‖�3‖2 − ‖�2‖22>3 − >4 @3 − @4 ‖�4‖2 − ‖�3‖22 CC

D>1 − >2 @1 − @2 A1 − A2>2 − >3 @2 − @3 A2 − A3>3 − >4 @3 − @4 A3 − A4D

Luego de calcular las variables correspondientes, el módulo entrega las

coordenadas de posicionamiento de acuerdo con el formato del protocolo

NMEA-0183 (National Marine Association) y la precisión de medición es

menor a 2 metros. Sin embargo para que el módulo pueda enviar los datos

hacia una computadora para su procesamiento necesita de componentes

adicionales que le permitan establecer una comunicación mediante el

protocolo RS-232. El módulo completo de localización y navegación se

puede ver en la Figura 4.13 en donde se observa un circuito integrado

MAX-232 así como los respectivos puertos de comunicación.

Figura 4.13 Módulo de adquisición de datos de navegación y posición

1

2

3

4

5

6

7

8

9

11

10

J1

D Connector 9

C1+1 VDD 2

C1-3

C2+4

C2-5

VEE 6

T2OUT 7

R2IN 8R2OUT9

T2IN10 T1IN11

R1OUT12 R1IN 13

T1OUT 14

GND15

VCC 16

U1

MAX232ACPE

1uF

C1Cap Pol1

1uF

C2Cap Pol1

1uFC3 Cap Pol1

1uF

C4Cap Pol1

100nF

C5Cap Semi

123

P3

RESET

123

P4

NMEA

123

P5

ROM

1 23 45 67 89 1011 1213 1415 1617 1819 20

P2

GPS

47K

R9

47K

R8

47K

R10

234

1

5678

J2

15-43-6233

270R5

270R6

270R7

270R12

10E

R11

1K

R13

D6D Zener

D51N4148

D71N4148

D81N4148

12

P7

BATERÍA

12

P6

ANTENA

100nF

C10

12

P1

ALIMENTACIÓN

D1

1N4007100uF/35V

C6Cap Pol1

680R1

1R2

D2

1N4002

D31N4002

47uF/16V

C8Cap Pol1220

R3

10uF/16V

C7Cap Pol1

1K

R4

D4LED

100nF

C9Cap Semi

IN3

1

OUT 2

ADJ

U2 LM317BT

C2+C1+

C1- C2-

C1+C1-C2+C2-

GND

GND

GND

GND

R1IN

R1IN

T1OUT

T1OUT

1 2 3 4

8 7 6 5

S1SW DIP-4

SW3

SW3

SW2

SW2

SW1

SW1

SW4

SW4

T2OUT

T2OUT

T2OUT

R2IN

R2IN

GND

GND

GND GND GND GND GND

OUT

VCC

T1IN

T2IN

T1INT2IN

GND GND GND

PR8 PR9 PR10

PR8 PR9 PR10

GPS15 GPS13 GPS14

GPS14GPS13GPS15

VCC VCC VCCVCC

VCC

DI5

DI5

GND

DI5

GND

VCC

GND

T1INGND

GND

GND

GNDGND

T2IN

R2OUT

R2OUT

R1OUT

R1OUT


44

4.6. MÓDULO DE POTENCIA

La parte mecánica del prototipo está constituida por 4 motores de un

consumo considerable para el movimiento del robot así como motores de

menor consumo que conforman el sistema de manipulación y la plataforma

giratoria de la cámara panorámica.

Antes de diseñar la etapa de potencia se ha hecho un estudio del consumo

en régimen nominal, los picos de corriente y las temperaturas que pueden

alcanzar estos motores. Cuando se quiere controlar el sentido de giro de un

motor de corriente continua de consumo medio se suelen utilizar

transistores de potencia en configuración de Puente H tal como se muestra

en la Figura 4.14.

Figura 4.14 Transistores en configuración de Puente H

Sin embargo cuando el motor es de alto consumo suelen utilizarse

relevadores en lugar de puentes H. A continuación se explicará cada tipo de

etapa de potencia que se ha desarrollado:

4.6.1. ETAPA DE POTENCIA A BASE DE RELEVADORES

EL control de sentido de giro a base de relevadores es uno de los más

sencillos de implementar sin embargo, dada su simpleza, posee bajos

tiempos de respuesta además de no permitir implementar controles de

velocidad utilizando técnicas como Modulación por Ancho de Pulso (PWM)

por ejemplo. Otro inconveniente que presenta es que, al tratarse de un

GND

VCC

M


45

sistema mecánico, es sensible al uso y su tiempo de vida es corto. La

ventaja que presenta es, como ya se dijo, su facilidad de implementación y

su alta capacidad para soportar cargas elevadas. En este caso estos drivers

(Figura 4.15) son utilizados para controlar motores de corriente continua

que alcanzan picos de 8 Amperios.

Figura 4.15 Amplificador de potencia en base a relevadores

4.6.2. PUENTE H USANDO EL INTEGRADO L298N

El integrado L298 es un doble driver de puente H que acepta niveles lógicos

TTL estándar y maneja cargas inductivas como relés o motores, como en

este caso. Posee dos entradas de activación para activar o desactivar cada

driver independientemente de las señales de entrada.

Figura 4.16 Puente H utilizando el integrado L298N

12

34

5

K1

Relay

12

34

5

K2

RelayM B1

MotorS1SW-SPST

S2SW-SPST

Q1NPN

Q2NPN

1K

R1

Res Semi1K

R2

Res Semi

D1Diode 1N4007

D2Diode 1N4007

GND GND

GND GND

VCC VCC

VCC VCCVCC VCCOUT1 OUT2

OUT1

OUT2

EN A6

EN B11

IN15

IN27

IN310

IN412

OUT12

OUT2 3

OUT313

OUT4 14

ISEN A 1

ISEN B 15

VS 4VSS9

GND8

U1

L298N

D3Diode 1N4007

D4Diode 1N4007

D5Diode 1N4007

D6Diode 1N4007

D7Diode 1N4007

D8Diode 1N4007

D2Diode 1N4007

D1Diode 1N4007

1000uF

C1Cap Pol1

1uF

C2Cap

1uF

C3Cap

100pF

C4CapM B1

MotorM B2Motor

12

P1

Input1

OUT1

OUT2

OUT3

OUT4

OUT1

OUT2

OUT3

OUT4

VCC

GND

VCC VCCGND GND

GND

VCC

OUT1 OUT2

OUT3 OUT4

OUT1OUT2OUT3OUT4

12

P2

Input2

IN1IN2

IN3IN4

IN1IN2IN3IN4

12

P3

Enable

EN AEN B

EN AEN B

GNDGND

VCC

12V

TIP31TIP31TIP31TIP31 TIP31TIP31TIP31TIP31


46

Para el control de los motores de la sonda se le ha agregado algunos

drivers de protección así como condensadores para eliminar los ruidos

provenientes de corrientes parásitas que generan los motores. En la figura

4.16 se puede apreciar el diagrama esquemático del circuito utilizado para

el control de giro de motores de consumo medio inferior a 1.6 Amperios.

4.6.3. PUENTE H USANDO EL INTEGRADO L293B

Para los motores de la sonda que presentan un consumo inferior a 1

Amperio se utilizó el circuito integrado L293B que es un driver de 4 canales

que acepta corrientes de hasta 1 amperio por canal. Cada canal es

controlado por señales de entrada compatibles TTL además cada par de

canales cuenta con un canal de habilitación. El modo de uso se pude ver en

la Figura 4.17.

Figura 4.17 Puente H utilizando el integrado L293B

4.7. UNIDADES Y ESTRUCTURAS MECÁNICAS

El dispositivo de control remoto es un robot con ruedas y lleva a cabo las

acciones que el operador le indica. El robot está provisto de un manipulador

de cuatro grados de libertad y pinzas. Así mismo cuenta con un sistema de

orientación de 3 grados de libertad. Las siguientes secciones describen la

unidad mecánica y la forma en cómo esta se maneja.

EN11

EN29

IN12

IN27

IN310

IN415 OUT1 3

OUT2 6

OUT3 11

OUT4 14

VC 8VCC 16

GND4

GND5

GND12

GND13

U1

L293B

M B1Motor

100nF

C1Cap

M B2Motor

VCC

GND

OUT1OUT2OUT3OUT4

OUT1

OUT2 OUT4

OUT3

VCC

GND

12

P2

Enable

1234

P1

Input

IN1IN2IN3IN4

EN1EN2


47

4.7.1 ESTRUCTURA CINEMÁTICA DEL ROBOT

Por las aplicaciones a las que ha sido orientado el proyecto (Exploración de

superficies terrestres) se ha decidido la construcción del robot a base de

ruedas ya que es la forma más simple de conseguir movilidad en terrenos

suficientemente duros.

Las ruedas son las encargadas de proporcionar el movimiento y en algunos

casos el sentido al robot. El tipo de rueda elegido es el que se aprecia en la

Figura 4.18 y es llamada rueda fija ya que solo gira en torno a su eje sin

tracción motriz.

Figura 4.18 Rueda fija

El tipo de locomoción es diferencial de cuatro ruedas. Las ruedas han sido

dispuestas de esta manera pues es el tipo de movimiento más fácil de

implementar ya que básicamente consiste en dos ruedas en un eje común

(Figura 4.19), donde cada rueda se controla independientemente.

Figura 4.19 La locomoción diferencial

r w


48

En este tipo de locomoción no hay ruedas directrices, el cambio de

dirección se realiza modificando la velocidad relativa de las ruedas a

izquierda y derecha (Figura 4.20).

Figura 4.20 La locomoción diferencial se caracteriza por la ausencia de ruedas directrices

Sin embargo, a pesar de ser una forma de movimiento sencilla y

relativamente barata de implementar, esta presenta algunos inconvenientes

como por ejemplo [21]:

• Es difícil controlar la dirección de marcha del robot.

• Requiere control de precisión para trayectorias rectas, además de que

cada motor debe girar exactamente a la misma velocidad.

• El cambio de diámetro de las ruedas distorsiona el control de dirección

del vehículo.

4.7.2 HERRAMIENTAS DE MANIPULACIÓN E INSPECCIÓN

La sonda cuenta con una herramienta de manipulación de 4 grados de

libertad y todas estas articulaciones son de revolución. La estructura del

movimiento y las principales partes del manipulador pueden ser vistas en la

Figura 4.21. Todos los actuadores son motores de corriente continua que

trabajan con voltajes inferiores a 5 voltios. El robot puede manejar una

carga de hasta 100 gramos en un amplio rango.

H

R

L VVVVLLLL

VVVV

VVVVRRRR

XXXX1111

YYYY1111

YYYY

XXXX

Θ

VVVVLLLL

L/2 L/2

ICRICRICRICR

ω

RRRR

VVVVRRRR


49

Adicionalmente el robot posee una cámara situada en la parte superior de la

pinza lo que le permite tener una vista en tiempo real de la tarea que se

está realizando en caso se trate de la manipulación de materiales delicados.

Una desventaja es que no posee enconders ni ningún otro dispositivo de

retroalimentación que permita conocer la posición de las articulaciones o si

es que realmente se está efectuando el movimiento.

a) Manipulador

b) Torre de orientación

Figura 4.21 Estructuras mecánicas

El robot también cuenta con un sistema de orientación que se encarga de

brindarle una visión completa del ambiente que se está explorando gracias

a sus 3 grados de libertad que permite rotar a una cámara en todas las

direcciones que se muestran en la Figura 4.21.

Todos estos mecanismos interactúan con la unidad remota de

procesamiento (Figura 4.1) mediante protocolos y directivas que serán

estudiados en los siguientes capítulos.

50

CAPÍTULO V

SÍNTESIS DEL PROTOCOLO

Los protocolos de comunicación juegan un papel importantísimo en los sistemas

de telecontrol de robos móviles, dándoles a estos la capacidad de abordar

aplicaciones del mundo real. Sin embargo protocolos que carecen de un diseño

formal o que no están bien adaptados a las características y funcionalidades de

los enlaces de comunicación actuales, pueden reducir enormemente la efectividad

de un sistema robótico. Es aquí donde la ingeniería de protocolos, pocas veces

abordada, propone una serie de etapas que se desarrollarán en este capítulo y

que conllevarán a la implementación de un protocolo completo y consistente.

5.1. DESCRIPCIÓN DEL PROBLEMA

La implementación de protocolos es, hasta la fecha, un tema que no ha sido

abordado formalmente y la poca información que existe no hace más que

mostrar el desarrollo de sencillos protocolos a modo de ejemplos

académicos.

Formalizar el ciclo de vida de un protocolo, es decir llevar el proceso de

síntesis, implementación y pruebas a través de un camino con bases

formales y modelos matemáticos de cimiento, es uno de los principales

retos de la Ingeniería de protocolos, dada la complejidad del desarrollo que

implica la implementación de verdaderos sistemas de comunicaciones que

tendrán su aplicación en entornos reales. Tomando en cuenta esta

situación, en este apartado se realizará el proceso de síntesis de un

protocolo real utilizando máquinas de estado finito que permitirán manejar

un ciclo de vida con etapas marcadas, de este modo al final del proceso el

protocolo alcanzará la consistencia y robustez que se requiere.


51

El caso que se presenta en este capítulo queda descrito del siguiente modo:

Se pretende diseñar un protocolo que permita controlar y supervisar

remotamente un robot de exploración terrestre equipado con sensores y

cámaras, en un ambiente desconocido (Figura 5.1).

Figura 5.1 Esquema del sistema de comunicaciones

La sonda transmite audio y video por un canal mientras que por otro envía

datos del ambiente como la temperatura. Concurrentemente está a la

espera de órdenes por parte de un operador quien desde un computador

envía secuencias de comandos para la activación de los distintos

actuadores que el robot posee.

Con este fin se muestra la perspectiva de implementar un protocolo ubicado

en el nivel de aplicación del modelo OSI con funcionalidades similares a

aquellos protocolos que intercambian caracteres ASCII.

5.2. ESTRUCTURA DEL PROTOCOLO

Al momento de analizar y elaborar la estructura de un protocolo, 2 son los

tipos de errores que se suelen cometer: Diseñar un conjunto de reglas

incompleto o diseñar reglas que son contradictorias. Para evitar esto es

necesario ser preciso especificando todas las partes relevantes del

protocolo, esto también requiere de algo de disciplina aislando las

dificultades encontradas y usando para esto modularidad y estructuración.

Puesto central

Ambiente desconocido

Sonda de Exploración (Unidad Remota)


52

Todas las reglas, formatos y procedimientos que hayan sido acordadas

entre dos dispositivos por así decirlo como ejemplo, vienen a ser

colectivamente lo que llamamos protocolo. De alguna manera el protocolo

estandariza el uso de cualquier canal de comunicación, por lo tanto puede

contener acuerdos en métodos usados por ejemplo para:

• Iniciación y terminación de intercambio de datos.

• Sincronización de emisores y receptores.

• Detección y corrección de errores de transmisión

• Formato y codificación de datos.

5.3. NIVEL DE ABSTRACCIÓN

Muchos de los problemas mencionados anteriormente pueden estar

definidos en más de un nivel de abstracción (ver Figura 5.2).

Un bajo nivel de abstracción puede ser por ejemplo alguna definición

aplicada a la sincronización del reloj entre un emisor y receptor durante el

proceso de comunicación que es usado por lo general para llevar o

escanear la línea de transmisión física.

En un nivel de abstracción más alto se podría mencionar la sincronización

de transferencia de mensajes (ejemplos claros son el control de flujo y

métodos de tasa de control) y en un nivel aún más alto se estaría tratando

ya con la sincronización y coordinación de las principales fases del

protocolo.

En el nivel más bajo se podría mencionar una definición de formato que

consistiría de un método para codificar bits con señales analógicas

eléctricas, un nivel arriba podría consistir de métodos para codificar los

caracteres individuales de un alfabeto de transmisión en patrones de bits.


53

Figura 5.2 Ejemplos de niveles de abstracción

Luego, códigos de carácter pueden ser agrupados en campos de mensajes,

y campos de mensajes en tramas o paquetes, cada uno con un significado

y estructura específica. Los métodos de control de error requeridos en un

protocolo dependen de las propiedades específicas de los medios de

transmisión usados. Este medio puede insertar, eliminar, distorsionar e

incluso duplicar y reordenar mensajes. Dependiendo del comportamiento

especifico del protocolo, el diseñador puede idear una estrategia de control

de errores.

5.4. ELEMENTOS DEL PROTOCOLO

El querer especificar un protocolo implica considerar cinco partes distintas,

es decir para estar completo cada especificación debe incluir explícitamente

lo siguiente:

• El servicio que brindará el protocolo.

• Las suposiciones que se deben considerar sobre el ambiente donde se

empleará el protocolo.

Señal Eléctrica

Bits

Símbolos/caracteres

Campos de mensaje

Paquetes


54

• El alfabeto de mensajes usados para implementar el protocolo.

• La codificación o definición del formato de cada mensaje en el alfabeto

definido anteriormente.

• Las reglas de procedimiento de protección de la consistencia del

intercambio de mensajes.

El quinto elemento de la especificación de un protocolo es el más difícil de

diseñar y también el más difícil de verificar.

5.5. SERVICIO Y AMBIENTE

Lo que se desea es realizar la transmisión y recepción de mensajes, los

cuales están divididos para 4 servicios específicos:

• Servicio de audio y video.

• Servicio de comandos de control.

• Servicio de muestreo de datos

• Servicio de monitorización del enlace de comunicación.

El término “mensajes” hace referencia a una serie de tramas enviadas

desde un dispositivo emisor (PC-Desktop) hacia el dispositivo receptor

(Laptop inmersa en el robot móvil) y viceversa.

Para llevar a cabo una tarea de un alto nivel como transferir un mensaje, un

protocolo debe desarrollar un rango de funciones como sincronización o

recuperación de errores. La realización específica de un servicio depende

de los supuestos que se hacen del medio en el cual se pondrá en

funcionamiento el protocolo. La recuperación de errores debería por

ejemplo corregir el comportamiento definido o asumido del medio de

transmisión.


55

Como bien se sabe, si un problema es demasiado grande lo que se debe

hacer es dividirlo en subproblemas que sean más fáciles de resolver o que

en todo caso ya hayan sido resueltos antes.

5.6. DISEÑO DEL PROTOCOLO

El modelo del protocolo está desarrollado en base a los siguientes 4

autómatas:

• Cliente: Representa el proceso que requiere el envío de una cierta

cantidad de bloques o tramas.

• Transmisor: Representa a la entidad del protocolo encargada de

efectuar el envío de los bloques de datos.

• Receptor: Representa a la entidad del protocolo encargada de recibir y

aceptar los bloques de información.

• Canal: Representa al medio que vincula al transmisor y receptor.

Básicamente se utiliza para modelar los retardos de transmisión y

propagación, así como también la eventual pérdida de paquetes.

Podemos pensar en estos 4 autómatas interactuando de la manera descrita

en la Figura 5.3.

Figura 5.3 Modelo del protocolo desarrollado en base a 4 autómatas

Cliente

Transmisor Canal Receptor

Send Ok Error

Msg

ACK/NAK

Msg

ACK/NAK


56

5.6.1 MODELO DEL CLIENTE

El cliente está representado por el autómata de la Figura 5.4. Su

trabajo consiste en requerir el envío de una cierta cantidad de tramas

del mismo tamaño, y esperar la finalización de la misma. El tiempo w

sirve para analizar el tiempo que puede demandar una transmisión.

Figura 5.4 Modelo del cliente

5.6.2 MODELO DEL TRANSMISOR

El transmisor está inicialmente en reposo, a la espera de la orden de

iniciar la transmisión (send?). A partir de esa orden comienza el envío

de cada una de las tramas, esperando una confirmación por cada una

de ellas.

Los parámetros más importantes son:

• NB: número de bloques a transmitir

• MAXR: máxima cantidad de reintentos

• timeout: tiempo máximo para esperar el ACK luego de enviar un

mensaje

OK

end_tx? abort_tx?

Error

Waiting

Send!

NB:=n,

W:=0

Idle


57

El proceso de transmitir una serie de bloques de datos puede demandar

una cantidad máxima de tiempo, luego de lo cual el autómata vuelve al

estado de reposo, previa notificación al cliente acerca del éxito (end_tx)

o fracaso de la comunicación (abort_tx). Se da por abortada una

comunicación cuando se supera el límite de reintentos para un bloque

en particular. Este proceso se muestra en la Figura 5.5

Figura 5.5 Diagrama correspondiente al autómata del transmisor

5.6.3 MODELO DEL RECEPTOR

La entidad del protocolo encargada de recibir y aceptar los bloques de

datos está por defecto en reposo (Idle), hasta que desde el canal de

comunicación recibe la notificación del arribo de un mensaje (rmsg?).

Si el identificador del mensaje (ns) coincide con el esperado (nr) se da

por aceptado el mensaje, y se pasa a esperar el siguiente. En caso de

recibir un mensaje fuera de secuencia, es posible que se deba a que el

último ACK enviado se haya perdido; por tal motivo simplemente se

reenvía el ACK.

abort_x! R=MAXR

Retry

rack?

wa<=timeout

ns==nr

wa<timeout

ns==sn+1

ack? end_tx! i==NB ns:=ns+1

i:=i+1

n=0

send? Idle

i:=0, n:=0

Sending

A<NB

smsg!

wa:=0

Wait_ack

wa<=timeout

wa:=0, r:=r+1

smsg!

R<MAXR

wa==timeout


58

Figura 5.6 Diagrama correspondiente al autómata del receptor

5.6.4 MODELO DEL CANAL DE COMUNICACIÓN

A fin de poder modelar los retardos impuestos por la transmisión y

propagación de los mensajes, sin agregarle elementos espurios a los

modelos del transmisor y el receptor, se desarrolló el autómata que se

puede ver en la Figura 5.7. Puede verse que en el caso de los

mensajes hay una sincronización entre el transmisor y el canal (smsg),

que da lugar a un retardo ttx + tprop, luego del cual se produce el

evento de sincronización entre el canal y el receptor (rmsg). De manera

análoga sucede para el envío de los reconocimientos (ACK) desde el

receptor al transmisor.

Cabe destacar que también está contemplada la posibilidad de que un

mensaje o un ACK se pierdan o se corrompan; esto está modelado por

las transiciones que retornan al lugar Idle, sin notificar ningún evento (ni

rmsg ni rack).

sack!

ns!=nr nr:=nr+1 sack!

Check_msg Idle

msg?

ns==nr


59

Figura 5.7 Modelo del canal de comunicación

La verificación del modelo desarrollado tiene básicamente los siguientes

objetivos:

• Asegurar que el protocolo no quede bloqueado en algún estado, es

decir que siempre que se inicie una transmisión, la misma finalice

(OK o Error).

• Determinar los valores adecuados de algunos parámetros (por

ejemplo: el timeout para efectuar una retransmisión).

• Determinar los tiempos máximo y mínimo que puede demandar una

transmisión. En este caso se puede analizar la influencia de algún

parámetro, como por ejemplo el valor del timeout y/o la cantidad

máxima de reintentos.

Sending_msg

d<=ttxprop

d:=0

d==ttx+prop

rack!

d:=tprop

smsg?

Idle

sack?

d:=0

d:=tprop

msg!

d==ttx+prop

Sending_ack

d<=ttxprop


60

5.7. IMPLEMENTACIÓN DEL PROTOCOLO

Luego de revisar los conceptos mencionados anteriormente, ahora se

aborda el diseño del protocolo en sí, para lo cual se tomará las siguientes

consideraciones:

• La trama a enviar constará de 3 secciones: Cabecera, datos y tráiler.

Ver Figura 5.8

• La cabecera constará de 7 subsecciones: Tipo de servicio, destino, bit

de sincronización (SYN), acuse de recibo (ACK), número de secuencia,

contador de bytes y paridad. Ver Figura 5.9

• El tráiler constará de 2 subsecciones: checksum y dirección de retorno.

HEADER USER DATA TRAILER

Figura 5.8 Principales campos del protocolo

Tipo de servicio IP Destino SYN ACK Número de secuencia Byte Count Paridad

Figura 5.9 Secciones del campo HEADER del protocolo

5.7.1 HEADER

• Tipo de servicio

El proyecto está definido en base a 4 servicios, por lo tanto para

asignar un identificador a cada servicio utilizaremos el sistema

binario para su respectiva identificación, los cuales seran

manejados como caracteres.

Al ser 4 servicios necesitaremos 2 bits para su respectiva

enumeración, quedando de la siguiente manera:

� Servicio de audio y video: 00

� Servicio de Comandos de Control: 01

� Servicio de Muestreo de Datos: 10


61

� Servicio de Monitorización del Enlace de Comunicación: 11

Con lo cual el campo tipo de servicio quedaría definido con un

tamaño de 2 caracteres.

• IP Destino

El IP destino representa la dirección destino de capa 3 (Según el

modelo OSI) del dispositivo al cual se le enviarán los datos.

• Bandera de SYNC

Cuando esta bandera está activa (vale 1, en lugar de 0), estamos

indicando al otro extremo que deseamos establecer una nueva

conexión. Esta bandera se utiliza únicamente al abrir una nueva

conexión.

• Acuse de recibo

Si la bandera ACK está puesta a activo, entonces este campo

contiene el número de secuencia del siguiente paquete que el

receptor espera recibir.

• Número de secuencia

Sirve para comprobar que ningún segmento se ha perdido, y que

llegan en el orden correcto. Su significado varía dependiendo del

valor de SYN.

� Si la bandera SYN está activa (1), entonces este campo indica

el número inicial de secuencia (con lo cual el número de

secuencia del primer byte de datos será este número de

secuencia más uno).

� Si la bandera SYN no está activa (0), entonces este campo

indica el número de secuencia del primer byte de datos.


62

• Byte Count

Especifica el tamaño de la trama de datos que estamos enviando al

IP destino.

• Paridad

Es una bandera para indicar la paridad que constituye esta trama

de datos.

5.7.2 USER DATA

Los datos que se insertaran en este campo estarán sujetos al tipo de

servicio que se inscriba en el campo “Tipo de Servicio”, según eso

quedarían definidos de la siguiente manera:

• Servicio de video (MULT)

Que constara de 4 diferentes valores, los cuales serán también

identificados por una secuencia de caracteres interpretados como

números binarios:

� Inicio: 00

� Detener: 01

� Reinicio: 10

� Cerrar : 11

• Servicio de comandos de control (CTRL)

Los comandos de control están referidos específicamente al control

de los motores con que cuenta el robot, a los cuales también

identificaremos con la misma regla que a los conceptos anteriores:

Motor de Movimiento o tracción (00):

Dentro de esta sección incluimos los 4 motores que corresponden a

las 4 llantas que permitirán el desplazamiento del robot: MT1, MT2,

MT3, MT4.


63

Los 4 motores a su vez tendrán asignados 4 valores más que

corresponden a los posibles movimientos que pueden realizar,

estos son:

Detenido 00

Sentido de Giro 0 10


Motor de Cámara Panorámica (01):

La cámara panorámica tendrá en efectos reales 3 grados de

libertad lo que significa que cuenta con 3 motores para su

funcionamiento: MCP1, MCP2, MCP3.

Al igual como en el caso de los motores de movimiento estos

también tendrán asignados 4 valores más que corresponden a los

posibles movimientos que pueden realizar, estos son:

Detenido 00



Motor de Brazo Robótico (10):

El brazo robótico cuenta con 4 grados de libertad sumado a un

manipulador lo cual conlleva a la utilización de 5 motores para su

funcionamiento: MBR1, MBR2, MBR3, MBR4, MBR5.

De igual manera estos motores también tendrán asignados 4

valores más que corresponden a los posibles movimientos que

pueden realizar, estos son:

Detenido 00




64

• Servicio de muestreo de datos (DXE)

El servicio de muestreo de datos es el encargado de la transmisión

de las diferentes mediciones que se hagan mediante los sensores

incorporados en el robot móvil y su regla es la siguiente:

GPS (00)

En los que estarán presentes los datos provenientes de la unidad

de posicionamiento global, tomando como base la siguiente

estructura:

Velocidad del robot Hora UTC Longitud Latitud Altitud

Figura 5.10 Secciones del campo DATA con respecto al servicio de navegación

Temperatura Interna (01)

Los datos procesados por el circuito integrado (PIC 18F4550)

recogidos del sensor de temperatura interna, son enviados tal cual

en forma de caracteres con una sintaxis del tipo: “XX.YYºC”, lo que

define una trama de datos de tamaño 5.

Temperatura Externa (10)

De la misma forma como en el envío de la temperatura interna,

serán manejados los datos recogidos por el sensor encargado de la

medición de la temperatura externa.

• Servicio de monitorización del enlace de comunicaci ón (MON)

Para este servicio se coloca en la trama de datos una cantidad de

caracteres que serán enviados y que a la vez la misma cantidad se

deberá recibir para la confirmación de la comunicación. Será una

simulación de la ejecución del comando ping para la comprobación

de la conectividad constante entre 2 hosts remotos.


65

5.7.3 TRAILER

CHECKSUM IP Receptor

Figura 5.11 Principales campos de la sección TRAILER

• CHECKSUM

Es una suma de verificación utilizada para comprobar si hay errores

tanto en la cabecera como en los datos.

• IP EMISOR

Es el IP que representa la dirección de retorno de capa 3 (según el

modelo OSI) del dispositivo al cual deben regresar los da<etos.

5.8. EJEMPLOS DE TRAMAS

A continuación se muestran dos ejemplos que ilustran el protocolo descrito

anteriormente. El ejemplo de la Figura 5.12 hace referencia al comando

para iniciar el servicio de transferencia de audio y video.

00 192.168.1.50 1 5 6 30 1 MULT 10 0xF1FA 192.168.1.45

Figura 5.12 Trama que indica el reinicio del servicio de video

La Figura 5.13 es un ejemplo de la trama que se envía para la rotación de la

base de la herramienta de manipulación de la sonda de exploración.

01 192.168.1.50 1 14 15 40 0 CRTL 10 MBR1 10 0x11F5 192.168.1.45

Figura 5.13 Trama para la rotación de un actuador del robot móvil

HEADER

HEADER DATA TRAILER

DATA TRAILER

66

CAPÍTULO VI

ARQUITECTURA DE CONTROL DE RED

Controlar un robot móvil sobre un canal susceptible a retardos y errores de

transmisión puede ser un gran reto. La fiabilidad y la sincronización son los

principales factores que determinan el rendimiento de un robot telecontrolado, ya

que problemas relacionados con los retardos de tiempo en las comunicaciones

inevitablemente degradarán el rendimiento del proceso de telecontrol. Éstos

retardos perturban las transmisiones de forma aleatoria por lo que es necesario

tomar en cuenta estrategias con el fin de mantener un enlace de comunicación

fiable.

6.1. INTRODUCCIÓN

Muchos sistemas de telecontrol no poseen grado alguno de autonomía en

el lado remoto [17] por lo que la supervisión, por parte del operador, de las

tareas ejecutadas se convierten en una necesidad fundamental.

Otro aspecto importante es que el telecontrol de un robot móvil debe verse

más como la realización de una serie de acciones en función de comandos

y directivas más no como la transferencia de información hacia una unidad

remota. Tomando en cuenta este enfoque, la ejecución de estas acciones

requiere la sincronización de las mismas, por ejemplo la sincronización

entre los comandos enviados por el teleoperador, el análisis de las señales

de realimentación y la ejecución de la acción en sí en el sistema robótico

remoto. Sin embargo el rendimiento de protocolos de telecontrol que

interactúan en medios como redes inalámbricas basadas en el estándar

802.11 se ve degradado tanto en sincronización como en estabilidad, por

los problemas que se estudiaron en el Capítulo III.


67

Dado esto, el tiempo no es buen referente al momento de implementar

técnicas de telecontrol que hagan frente a los retardos en las

comunicaciones. Y es que a pesar de que los sistemas de telecontrol

periódicos o activados por tiempo han sido usados por muchos años [22], las

restricciones de la arquitectura de este proyecto exigen el uso de nuevos

métodos de telecontrol para hacer frente a los retardos que ocurren de

manera aleatoria.

Una opción que está siendo ampliamente adoptada por los sistemas de

telecontrol es el control basado en eventos. Este tipo de control no se

encuentra ligado al tiempo y es la propia evolución de la dinámica de la

variable del sistema la que decide cuándo se ejecuta la acción de control,

muestreo o transferencia.

a) Control tradicional basado en el tiempo

b) Control basado en eventos

Figura 6.1 Esquemas de control tradicional y basado en eventos

La Figura 6.1 muestra una comparación entre los esquemas de control

tradicional y basado en eventos. En el esquema de control tradicional las

tareas son planificadas por adelantado y son en función del tiempo. El robot

móvil alimenta a las entradas de la estación de telecontrol de acuerdo con

PLANIFICADOR CONTROLADOR ROBOT

-

Y(t) Yd(t) e(t)

ACCIÓN DE REFERENCIA

Y(t) Yd(s) e(s)

-

PLANIFICADOR CONTROLADOR ROBOT


68

un plan predefinido a intervalos constantes de tiempo, es decir la progresión

del tiempo provoca la ejecución de las mismas acciones.

En cambio, en un esquema de control basado en eventos las acciones se

llevan a cabo de manera asíncrona solamente frente a un cambio en alguna

variable. Los beneficios que presenta este esquema es que una nueva

señal de control o transferencia es generada solo cuando ocurre un cambio

en una variable, evitando de este modo la sobrecarga de la red con datos

redundantes. Y es que normalmente se transmite gran cantidad de datos en

cada instante de muestreo, en especial debido a requerimientos del

protocolo de telecontrol. Sin embargo a veces esta solución puede producir

una gran carga en la red y por consiguiente, retardos de tiempo. Esto quiere

decir que a mayor tráfico de red es mayor la probabilidad de que ocurra una

pérdida de paquetes afectando de este modo el rendimiento del proceso de

telecontrol.

Otro problema que se puede evitar con un control basado en eventos es el

efecto buffering, muchas veces causante de la desincronización entre el

operador humano y el robot. En la Figura 6.2, el esquema de control basado

en tiempo da como resultado que muchos paquetes estén viajando a través

de la red sobrecargándola y provocando retardos.

Figura 6.2 Efecto Buffering provocado por los retardos de tiempo en la red

OPERADOR HUMANO

ROBOT MÓVIL

Cm Cm-1 …. C4 C3 C2

F1 F2

OPERADOR HUMANO

ROBOT MÓVIL

Cm+n Cm+n-1 …. Cm+2 Cm+1 Cm

F1 F2 F3 …. Fm-1 Fm

Tiempo=m

Tiempo=m+n


69

Figura 6.3 Eliminación del efecto Buffering a través de un esquema de control basado en eventos

Cuando se ejecuta el comando cm+n el comando cm ha de haber sido

ejecutado y las señales de realimentación pertenecientes a los comandos

generados previamente ya deben de haber llegado al teleoperador humano.

Sin embargo hasta que la señal de realimentación del comando cm+n llegue

a su destino, el operador humano no tendrá conocimiento del efecto que

este comando ha producido en la unidad remota pues recién se estarán

recibiendo las señales de realimentación previas.

El control basado en eventos proporciona una solución a los problemas de

desincronización en la transferencia de comandos pues el operador del

robot generará los comandos de acuerdo a la notificación de eventos que

este reciba.

Evento = n OPERADOR HUMANO

ROBOT MÓVIL

Cn Cn

Fn Fn

Evento = n+1 OPERADOR HUMANO

ROBOT MÓVIL

Cn+1 Cn

Fn Fn

Evento = n+1

OPERADOR HUMANO

ROBOT MÓVIL

Cn+1 Cn+1

Fn Fn


ROBOT MÓVIL

Cn+1 Cn+1

Fn Fn+1


ROBOT MÓVIL

Cn+1 Cn+1

Fn+1 Fn+1


70

En la Figura 6.3 se aprecia que el esquema planteado elimina los

problemas ocasionados por el efecto buffering proporcionando un mayor

nivel de sincronización entre la estación de telecontrol y el robot. Cualquier

comando no será retransmitido hasta que la señal de realimentación del

último comando transmitido no llegue al operador humano. El comando cn+1

no será transmitido hasta que llegue al señal de realimentación del

comando anterior. Luego que el comando cn+1 ha llegado al robot, este es

ejecutado y su señal de realimentación es enviada de vuelta al operador

humano. De acuerdo a este esquema, cada comando corresponde con un

determinado evento.

Sin embargo el uso de un esquema de control orientado a eventos

proporciona un buen nivel de control solo cuando las conmutaciones de la

señal o comando son reducidas, produciendo eventos a periodos de tiempo

distantes. En caso de una alta tasa de conmutaciones de la variable a ser

controlada, evidentemente un control que posee como referente al tiempo,

dará mejores resultados.

Figura 6.4 Comparación entre el muestreo de una misma señal según un esquema basado en eventos y un esquema basado en el tiempo

Según la Figura 6.4, cuando se aplica un control basado en eventos, se

pierden valores, que dependiendo del tipo de variable a controlar, puede

afectar el comportamiento de un sistema de telecontrol. Evidentemente la

Muestro según el control basado en eventos Muestro según el control basado en el tiempo

Tiempo

Señ

al


71

estrategia a tomar tendrá mucho que ver con las variables del entorno que

se desea controlar. Por esta razón, en esta tesis se aplicarán estrategias

que combinarán los aspectos más importantes de ambas técnicas para

adecuarlas a los requerimientos de la arquitectura del robot móvil.

Así mismo, se mostrará el resultado de aplicar las dos técnicas de control

sobre una misma variable a fin de corroborar todo lo expuesto en estas

secciones. Estos resultados serán muy importantes pues determinarán las

técnicas de control que serán implementadas en el software de telecontrol.

6.2. MÉTODO DE CONTROL DESARROLLADO

Como se mencionó anteriormente, para lograr el telecontrol de un robot

móvil se hará uso de los dos esquemas de control tratados en el apartado

anterior. Sin embargo, no es una simple mezcla de ambas partes, sino que

se trata más de una cooperación tomando los mejores aspectos de cada

esquema (basado en tiempo y basado en eventos). Este método tiene como

finalidad hacer frente a la generación de eventos y comandos, muestreo de

variables del entorno y control de señales de realimentación. El proceso de

este método y la forma de cómo es implementado será descrito en las

siguientes secciones.

6.2.1 ESQUEMA DE CONTROL BASADO EN EVENTOS

La idea del muestreo basado en eventos ha sido utilizada desde mucho

antes [23] y su paradigma indica que el método más apropiado para

muestrear una señal consiste en transmitir la información solo cuando

existe un cambio significativo en la señal, que justifique la adquisición de

una nueva muestra. Evidentemente la naturaleza del evento varía de

acuerdo a la señal censada, por ejemplo una señal cruza un límite o un

nuevo paquete de datos llega al robot móvil, proveniente de la estación de

telecontrol. Esto producirá una acción de control.


72

En el caso de señales censadas, una forma de indicar que es necesaria una

nueva muestra de esta variable, es que ésta cruce un cierto límite

preestablecido, en función de la naturaleza y dinámica de la variable. Por

ejemplo cuando el valor absoluto de la diferencia entre el valor actual del

error, e(tk), y el último valor del error calculado, e(ts), es mayor que un límite

δ, o cuando el tiempo transcurrido desde que se calculó la última supere un

límite hmax.

|e(t%) − e(t')| > ) ∧ t% − t' ≥ h-./

La Tabla 6.1 presenta los límites individuales de las variables más comunes

usadas para el control de un robot móvil. Estos límites de δ = 3% y δ = 5%

se han calculado basados en la experiencia de proyectos de investigación

sobre telecontrol y tras analizar años de datos [22].

Variable δ = 3% δ = 5% Temperatura interior 0.36 0.60 Temperatura exterior 0.36 0.61

Humedad 0.29 0.49 Radiación solar 20.58 34.30

Velocidad de viento 0.31 0.53 Dirección de viento 10.70 17.84

Tabla 6.1 Limites de las variables más usadas en la exploración de ambientes

Para el caso del envío de comandos, el método usa la siguiente técnica: Un

paquete es enviado desde la estación de control (operador humano) y este

esperará por un paquete de confirmación (ACK) antes de enviar cualquier

otro comando. La Figura 6.5 ilustra esta técnica.

Los comandos son generados por un gamepad, descrito en el capítulo IV.

Cada comando ejecutará una serie de directivas indicando la acción a

realizar sobre los actuadores del robot móvil. Para el robot desarrollado en

ésta tesis, todos sus actuadores están basados en motores de corriente

continua, por lo que la estructura de un comando generado por el operador

humano será como se muestra en la Figura 6.6.


73

Figura 6.5 Envío de paquetes basado en esquema de control por eventos

Figura 6.6 Estructura de paquetes

Sin embargo el arribo de una señal ACK no es suficiente para generar el

siguiente comando. Para maniobrar el robot, el operador humano debe ver

las últimas acciones realizadas por la sonda, correspondientes a la

ejecución de los últimos comandos. Proporcionar información visual al

operador en tiempo real es necesario para una teleoperación fiable, es por

esto que se ha implementado un sistema de orientación descrito en el

Capítulo IV. Sin embargo la información de realimentación también necesita

estar sincronizada. Esto será descrito en las siguientes secciones.

Enviar Paquete 1

Enviar Paquete 2

Recibir Paquete 1, hacer las

operaciones necesarias y responder

con ACK-1

Operador Humano Robot Móvil

TIPO DE COMANDO

SENTIDO DE GIRO 0

SENTIDO DE GIRO 1

NÚMERO DE SECUENCIA

(a) Estructura de un paquete de comando

TIPO DE COMANDO

NÚMERO DE SECUENCIA

SEGUNDO

(b) Estructura de un paquete ACK


74

6.2.2 ESQUEMA DE CONTROL BASADO EN EL TIEMPO

En un esquema basado en tiempo, es la progresión del mismo la que

provoca la ejecución de acciones de control [22]. Este tipo de control posee

ventajas que le permiten ser aplicadas a esta tesis, dados ciertos

requerimientos, por ejemplo son de fácil implementación y de bajo costo de

operación.

Existen variables que requieren de un muestreo constante, como los datos

de posicionamiento global. Esta es la razón fundamental para la utilización

(y aún predominancia) de esta técnica [24].

Figura 6.7 Estructura de un paquete con datos de posicionamiento

La figura 6.7 muestra los datos provenientes de la unidad de

posicionamiento global. La dinámica de estas variables exige un muestreo

continuo. Y esto es debido a las constantes oscilaciones del módulo de

GPS implementado para esta tesis. Este esquema le permitirá enfrentarse a

las oscilaciones de dinámicas lentas y rápidas de esta variable.

El resultado de compilar las ventajas de ambas técnicas será visto en las

siguientes secciones donde además se describirá con mayor detalle las

técnicas de sincronización utilizadas para el esquema de control

presentado.

6.3. SINCRONIZACIÓN DE PAQUETES

Debido a que cada comando corresponde a un evento, la información de

ejecución de un comando procedente de la unidad remota también

pertenece a ese evento. Por consiguiente, la información perteneciente al

VELOCIDAD DEL ROBOT HORA UTC

LONGITUD LATITUD ALTITUD


75

estado más actual tiene que estar sincronizado con el mensaje de

confirmación.

La sincronización de eventos está ligada con el esquema de control

orientado a eventos, mas no con el esquema orientado al tiempo. La

totalidad del esquema de sincronización de eventos se muestra en la Figura

6.8.

En la sección anterior se mencionó a las imágenes de video como un

referente de realimentación para el operador humano, sin embargo las

imágenes de video son de mayor tamaño en comparación con las señales

de control por lo que esperar por estas mientras los mensajes de

confirmación llegan al operador humano es algo inaceptable. Si una imagen

no ha llegado al operador humano en un determinado intervalo de tiempo,

de acuerdo con el mensaje de confirmación relacionado, ésta es esperada

hasta que llegue, sin afectar la emisión de comandos de control ya que solo

es un referente de apoyo en la sincronización.

Para sincronizar los acuses de recibo (ACK) es suficiente con conocer sus

números de secuencia. Sin embargo sincronizar las imágenes de video con

los correspondientes ACK asociados al mismo evento implica el análisis y la

adhesión de nuevos campos. Si el acuse de recibo de un evento y las

imágenes de video correspondientes a este, ambas provenientes del robot,

son concurrentes, la información del tiempo es usada para sincronizarlas en

el lado del operador humano. Por consiguiente, un segundo campo de

información (aparte de los números de secuencia) tiene que ser añadido

tanto al frame de video como a los paquetes ACK. Este campo contendrá

información asociada a la fecha, la hora, los minutos y los segundos. El

usar la implementación del protocolo RTP de Java proporciona la ventaja de

poder añadir estas cabeceras a los frames de video sin ninguna

complicación. Esta información de tiempo es usada para determinar qué

imagen pertenece a qué evento.


76

Figura 6.8 Esquema de sincronización de eventos

Para esto, el proceso que se sigue se muestra en la Figura 6.8. Los valores

añadidos a los ACK y a los frames de videos son extraídos y comparados.

Si el valor obtenido del ACK es menor o igual que el valor obtenido del

frame de video, se entiende que el video está siendo visto o fue visto

cuando su correspondiente ACK arribó a la estación de control. Por lo tanto,

el resultado de esta comparación indica que el siguiente comando puede

ser generado. Si el valor obtenido del paquete ACK es mayor que el valor

del campo obtenido del frame de video entonces las imágenes de video no

CLIENTE

SERVIDOR

M<N

O

M=N

Evaluación de

los mensajes de

confirmación

Generación de

comandos

Esperar hasta

que N=M

Sincronización

de eventos No

Si

Restringir

comandos

Permitir

comandos

Tiempo marcado

para mensaje

ACK (Segundo m)

Tiempo marcado

para frame de

video (Segundo n)

Dispositivo de

adquisición de

video

¿Hay algún

paquete

perdido?

No

Si


77

están llegando en el momento que se indica a pesar de que los paquetes

ACK ya han llegado y confirmado la ejecución de un determinado evento.

En este caso, el programa continuará revisando el valor del campo añadido

a los frames de video hasta que el valor sea igual al valor del paquete ACK

analizado. Cuando los valores coincidan, entonces se permitirá generar un

nuevo comando.

6.4. IMPLEMENTACIÓN EXPERIMENTAL DE UN MODELO DE

CONTROL BASADO EN EVENTOS

En esta sección se presentan los resultados de la simulación obtenidos

para el control de una variable del ambiente (en este caso la temperatura

interna del robot) mediante los dos esquemas planteados anteriormente.

Como se puede observar en las Figuras 6.9 y 6.10, el controlador calcula

una señal solo cuando se produce un evento. La aparición de estos eventos

es gestionada por un generador de eventos que detecta los posibles

eventos que puedan afectar al sistema.

Para este estudio de simulación, estos eventos están representados por

cambios marcados de temperatura al interior del robot. La secuencia de

eventos para esta variable climática depende del valor del límite δ usado

para el muestreo como se muestra en la Tabla 6.1. Los resultados para el

control basado en eventos (Figuras 6.9 y 6.10) están representados como

señales muestreadas para graficar la influencia de los eventos.


78

Figura 6.9 Resultado del control basado en eventos con δ = 3%

Para variables que exigen un control preciso o su dinámica es propensa a

cambios instantáneos, el control clásico representa la mejor opción, ya que

proporciona mejores resultados de control [22]. Sin embargo ocasiona un

número más elevado de conmutaciones de la señal como se puede apreciar

en la Figura 6.11.

Figura 6.10 Resultado del control basado en eventos con δ = 5%

0

10

20

30

40

50

60

0 100 200 300 400 500 600 700

Tem

pera

tura

Inte

rna

ºC

Tiempo (segundos)

0

10

20

30

40

50

60

0 100 200 300 400 500 600 700

Tem

pera

tura

Inte

rna

ºC

Tiempo (segundos)


79

Figura 6.11 Resultado del control clásico basado en tiempo para la temperatura

Figura 6.12 Control basado en tiempo en comparación con control basado en eventos con un límite δ = 3%

0

10

20

30

40

50

60

0 100 200 300 400 500 600 700

Tem

pera

tura

Inte

rna

ºC

Tiempo (segundos)

0

10

20

30

40

50

60

0 100 200 300 400 500 600 700

Tem

pera

tura

Inte

rna

ºC

Tiempo (segundos)

Control clásico

Control basado en eventos


80

Figura 6.13 Control basado en tiempo en comparación con control basado en eventos con un límite δ = 5%

Las figuras 6.12 y 6.13 muestran una comparación de los resultados de

control obtenidos usando el control clásico basado en el tiempo y el control

basado en eventos. La Figura 6.12 muestra los resultados de control

usando control basado en tiempo y control basado en eventos con un límite

de δ = 3% donde se muestra que el número de cambios de las señales de

control es más pequeña en comparación con la Figura 6.13 que posee un δ

= 5%. Este comportamiento, que se ha descrito en las secciones anteriores,

es muy importante para optimizar la transferencia de datos entre el robot de

exploración y la estación de telecontrol pues un número reducido de

conmutaciones implica la existencia de menos tráfico en la red.

Con el fin de medir el rendimiento del sistema de telecontrol, algunos

experimentos fueron realizados. En estos experimentos fueron probados

los esquemas de telecontrol que mejorarían el rendimiento del protocolo

propuesto en el capítulo anterior. Las variables del entorno a ser

muestreadas fueron generadas por los respectivos sensores y estas

mismas fueron analizadas para determinar su comportamiento y la medida

0

10

20

30

40

50

60

0 100 200 300 400 500 600 700

Tem

pera

tura

Int

era

ºC

Tiempo (segundos)

Control clásico

Control basado en eventos


81

en que aportan al mejoramiento del rendimiento del sistema de

comunicación entre el robot y el operador humano.

Utilizando un esquema basado en eventos con un límite δ=3% se observa

una alta correlación entre los datos que se adquieren por control tradicional

y por control basado en eventos (Figura 6.12). Sin embargo con un límite

δ=5% se empiezan a notar diferencias marcadas y la pérdida de valores,

que podrían repercutir en el rendimiento del proceso de telecontrol (Figura

6.13). Por lo tanto, para la implementación del software, el valor de δ será

del 3%.

Es importante poner énfasis en que ambos métodos de control propuestos

no se desempeñan igual para las mismas operaciones. El efecto de retardo

que aparece en la red así como el muestreo de variables del entorno que

poseen una dinámica no tan cambiante, son propicias para un esquema de

control basado en eventos. Sin embargo para variables que presentan un

alto número de conmutaciones es importante un control basado en tiempo.

Por lo tanto, la selección del método de control tiene que realizarse de

acuerdo a la naturaleza de la aplicación.

82

CAPÍTULO VII

ANÁLISIS Y DISEÑO DEL SOFTWARE

Este capítulo describe el análisis y diseño del software de aplicación. Esta

aplicación está compuesta de dos partes, el lado del operador humano y el robot

móvil, que se comunican mediante un enlace de red. El capítulo entrega

información acerca del proceso de desarrollo empleando el Lenguaje Unificado de

Modelado (UML) para describir los métodos y procesos desarrollados.

7.1. ESPECIFICACIÓN DE REQUERIMIENTOS

En esta sección se describe los servicios que ha de ofrecer el software así

como las restricciones asociadas al funcionamiento del mismo que deben

satisfacerse.

7.1.1 REQUERIMIENTOS FUNCIONALES

Número Requerimiento Descripción Prioridad

RF1 Transmisión de Video El sistema debe permitir la transmisión de video en tiempo real de la situación en la que se encuentre el robot móvil.

5

RF2 Transmisión de Comandos

El sistema debe permitir el envío de comandos de control de forma remota.

5

RF3 Comunicación con el Hardware

El sistema debe establecer la comunicación entre software y hardware.

5

RF4 Control de dispositivos electrónicos,

electromecánicos y eléctricos.

El sistema debe permitir el control de diversos dispositivos que en conjunto cumplirán con el objetivo del proyecto.

5

RF5 Transmisión de Sonido El sistema debe permitir la transmisión de sonido en tiempo real, el cual nos brindará información adicional sobre el entorno en el que se encuentra actualmente el robot móvil.

4

Tabla 7.1 Requerimientos Funcionales del Sistema


83

7.1.2 REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales están enmarcados en los siguientes

aspectos:

Escalabilidad:

• El diseño debe contemplar el uso óptimo de recursos tales como

conexiones remotas.

• Contemplar en el diseño la clara partición entre datos, recursos y

aplicaciones para optimizar la escalabilidad del sistema.

• Debe contemplar requerimientos de crecimiento para las

funcionalidades de adquisición de datos del robot móvil.

Disponibilidad:

• La disponibilidad del sistema debe ser continua, en función de las

capacidades de la infraestructura de red, garantizando un esquema

adecuado, que permita, ante una posible falla en cualquiera de sus

componentes, contar con un plan de contingencia.

• Debe contemplar requerimientos de confiabilidad y consistencia. En

caso de fallas de algún componente no debe haber pérdida de

información.

• Ante la falla del aplicativo, se debe contar con mecanismos que

contemplen la interrupción en la transferencia de comandos que

podrían averiar el sistema robótico.


84

Seguridad:

• La solución debe reflejar patrones de seguridad teniendo en cuenta

la alta sensibilidad de la aplicación, permitiendo autenticación de

usuarios y un enlace de comunicación seguro.

Mantenibilidad:

• Se debe estructurar el código de una manera consistente y

predecible.

• Para objetos que son frecuentemente manejados en la lógica del

negocio, implementar las respectivas interfaces que aseguren su

fácil implementación en el sistema.

7.2. CONCEPCIÓN

Listado de necesidades:

• Tener la facilidad de hacer reconocimiento y exploración de zonas a

distancia.

• Realizar tareas de búsquedas en zonas de alto riesgo.

• Garantizar que la información obtenida del entorno sea en tiempo real.

• Garantizar una comunicación visual constante entre el operador y el

robot móvil.

• Garantizar un envío constante de comandos de control entre el

operador y el robot móvil.

• Permitir la obtención de audio y temperatura como información del

entorno que se explora.


85

Reglas del negocio:

• Se debe asegurar que cada comando de control ejecutado corresponda

a la acción deseada.

• Se debe asegurar que las cámaras estén siempre conectadas al

sistema y que no haya interrupción de envío de video.

• Se debe asegurar que en caso de pérdida de la comunicación entre el

operador y el robot móvil, se tomen las medidas necesarias para

preservar la integridad del robot.

7.3. DIAGRAMA PICTOGRÁFICO

Figura 7.1 Diagrama pictográfico

Datos del

Ambiente

Comando de

Configuración

de Modo

µµµµCCCC

Tarjeta de Adquisición

de Datos

Trama RMI/RTP Trama RMI/RTP

Nivel de Capa Física y

Enlace de Datos

ENRUTADOR

Nivel de Capa de

Aplicación

ESTACIÓN DE CONTROL

ROBOT MÓVIL

Nivel de Capa de

Aplicación

802.11b

WIRELESS

Flujo de

Video

Dispositivos de adquisición

de audio y video

Flujo de

Audio Señal de

Inicialización

LM35

Temperaturas

Señales de Control

de Giro

Microcontrolador

Actuadores Mecánicos Sensores de Temperatura

Directivas y

Comandos

Temperatura del

Ambiente

Diagrama Pictográfico

Telecontrol de un robot móvil para

tareas de reconocimiento y exploración

en superficies terrestres


86

7.4. CASOS DE USO

La Figura 7.2 muestra los casos de uso de un operador humano, que

accede al sistema a través de una interfaz de entrada descrita en el

Capítulo IV. Estos casos de uso son de vital importancia para describir el

funcionamiento básico del sistema y sus objetivos primarios.

Figura 7.2 Casos de Uso básicos del sistema

7.4.1 ESPECIFICACIÓN DE LOS CASOS DE USO

En esta sección se detallan los casos de uso mostrados anteriormente para

comprobar de qué manera se aborda su descripción en el sistema en

concreto. Aunque estos casos de uso pueden presentarse también en otros

sistemas del dominio de aplicación, su descripción precisa solo era posible

para un sistema determinado.

Anteriormente ya se indicó que los casos de uso de un usuario local que

accede al sistema a través de una interfaz de entrada a base de pulsadores

Apagar

Parar

Sistema

Controlar Torre de

Orientación

Establecer Modo de

Operación Iniciar

Controlar

manipulador

Mover

Robot Reiniciar

Operador


87

son significativos del funcionamiento básico de un sistema típico en el

dominio de la tesis y su objetivo general. A continuación se procede a la

descripción de los mismos:

Iniciar:

Actor: Operador

Resumen: El operador pone en marcha el sistema para empezar con la

exploración.

Precondición: El sistema está apagado.

Secuencia Normal:

1. El operador pulsa el botón iniciar.

2. El sistema muestra video.

3. Se establece enlace con el sistema de monitorización.

4. Se revisa el estado Ok del sistema.

5. Se inicia los servicios de envío y recepción de comandos.

Postcondición: El sistema está arrancado.

Alternativas:

1. El sistema no está Ok. Se le muestra la causa al operador y se le

sugiere acción correctora para continuar.

2. No hay enlace de comunicaciones con el sistema de monitorización. Se

muestra mensaje no necesitando acción correctora. El sistema puede

funcionar sin este enlace, aunque no es recomendable.

3. No funciona el sistema de visión. Se le muestra la causa al operador y

se le sugiere acción correctora para continuar.

Comentario: Obsérvese que se permite trabajar aunque no haya enlace

con el sistema de monitorización. En el caso del sistema de visión, el

funcionamiento es imprescindible.


88

Apagar:

Actor: Operador

Resumen: El operador termina la ejecución del sistema.

Precondición: El sistema está iniciado.

Secuencia Normal:

1. El operador pulsa el botón apagar.

2. El sistema termina la transmisión de video.

3. Se termina el enlace con el sistema de monitorización en caso haya

sido iniciado.

4. Se terminan los servicios de envío y recepción de comandos.

Postcondición: El sistema está apagado y los servicios terminados.

Alternativas:

1. No se puede terminar la ejecución de algún servicio por parte del

operador. Se muestra un mensaje de error y se fuerza la finalización del

mismo.

Comentario: La finalización de los servicios iniciados al arrancar el sistema

es de vital importancia por lo que un fallo al intentar cerrarlos debe ser

solucionada forzando la finalización de éstos.

Establecer Modo de Operación:

Actor: Operador

Resumen: El operador establece el modo en que se controlará el robot.


Secuencia Normal:

1. El operador pulsa el botón correspondiente al modo (Joystick/Teclado).

2. El sistema envía el comando respectivo al robot.

3. Se inicia el servicio correspondiente.

Postcondición: El servicio (de acuerdo a la interfaz de entrada) está

iniciado.


89

Alternativas:

1. Ha ocurrido un problema con el inicio del servicio. El servicio por

defecto debe ser iniciado con un correspondiente mensaje al operador.

Comentario: En caso de ocurrir una falla en la interfaz de entrada basada

en Joystick, el servicio siempre disponible será la entrada por teclado.

Controlar Torre de Orientación:

Actor: Operador

Resumen: El operador envía comandos hacia los actuadores de rotación

de la torre de orientación.


Secuencia Normal:

1. El operador pulsa el botón correspondiente al actuador y su sentido de

giro.

2. El sistema envía el comando correspondiente y espera el acuse de

recibo.

3. El comando llega a la unidad remota y es ejecutado siendo la acción

seguida por el operador gracias a las imágenes de video

proporcionadas por las cámaras.

4. Una vez ejecutada correctamente la acción el operador recibe el acuse

de recibo de que la acción se ejecutó y se vuelve a enviar otro

comando, en caso lo hubiese.

Postcondición: El sistema está a la espera de un nuevo comando.

Alternativas:

1. No se ha recibido el acuse de recibo de la ejecución del comando por lo

que el sistema deberá esperar por un tiempo de vida y luego dar el

comando como no ejecutado y registrar el evento.

2. Se observa un desfase muy alto entre las imágenes de video y el

tiempo en el que se envió el comando. El sistema deberá informar al

operador sobre esto.


90

Comentario: No se permitirá el envió de un nuevo comando mientras no se

reciba el acuse de recibo del comando anterior o se haya vencido un tiempo

de espera.

Parar Sistema:

Actor: Operador

Resumen: El operador detiene la ejecución los servicios.

Precondición: El sistema está iniciado, el servicio de monitorización debe

estar activo.

Secuencia Normal:

1. El operador pulsa el botón parar.

2. El sistema detiene todos los servicios pero no interrumpe los enlaces de

comunicación.

Postcondición: Todos los servicios deben estar detenidos. En el lado del

robot el servicio de monitorización debe ser el único habilitado.

Alternativas:

1. Ha ocurrido un error al intentar detener un servicio. Se debe mostrar un

mensaje al operador dándole la opción de cerrar el servicio y reiniciarlo.

2. Ha ocurrido un fallo durante el proceso de parado, ajeno a los servicios.

Se debe hacer una revisión del sistema en general y mostrar el estado

de todos los servicios dando la opción de reiniciar los que han sido

detenidos.

Comentario: Al detener los servicios se debe tener especial cuidado con el

servicio de monitorización, pues será vital que esté en ejecución al

momento de reiniciar el resto de servicios.

Reiniciar:

Actor: Operador

Resumen: El operador reinicia los servicios que han sido detenidos.

Precondición: El sistema está detenido.

Secuencia Normal:


91

1. El operador pulsa el botón de reinicio.

2. El sistema verifica el estado del servicio de monitorización, de no estar

iniciado se inicia.

3. Se habilitan todos los servicios necesarios empezando por el servicio

de video.

4. Se lista el estado de todos los servicios.

Postcondición: Todos los servicios están iniciados.

Alternativas:

1. En caso de ocurrir un error al reiniciar un servicio, se deberá informar al

operador sobre el incidente.

2. Si el servicio de video no puede ser iniciado, el resto de servicios

tampoco lo serán.

Comentario: Es importante mantener el enlace de monitorización pues por

medio de este servicio se indicará el reinicio del resto de ellos.

Mover Robot:

Actor: Operador

Resumen: El operador pone en marcha el robot de exploración mediante el

envío de comandos.


Secuencia Normal:

1. El operador pulsa el botón correspondiente al sentido de giro del robot.


recibo.









92

Alternativas:




2. Se observa un desfase muy alto entre las imágenes de video y el

tiempo en el que se envió el comando. El sistema deberá informar al

operador sobre esto.



de espera.

Controlar Manipulador:

Actor: Operador

Resumen: El operador pone en marcha el sistema manipulación.


Secuencia Normal:

1. El operador pulsa el botón correspondiente al sentido de giro de la

articulación.


recibo.








Alternativas:





93



de espera.

7.5. MODELO DE ANÁLISIS DEL SISTEMA

7.5.1 MODELO ESTÁTICO DEL SISTEMA

El modelo estático es un modelo usado para entender la relación entre el

sistema y su entorno externo y para describir la estructura estática del

sistema en desarrollo [25]. Este modelo es principalmente usado en sistemas

de tiempo real y en sistemas embebidos como los sistemas robóticos [26].

Gracias al diagrama conceptual estático de la Figura 7.3 se obtiene una

visión general de los distintos componentes que forman en conjunto el

software. Este diagrama delimita también el alcance del sistema, detallando

los dispositivos con los que se interactúa.

Figura 7.3 Modelo Estático del dominio del problema. TRCU es la unidad de control teleoperado (Teleoperated Robot Control Unit)

Controls

0000..*..*..*..*

<<External System>> Teleoperation System

<<External I/O Device>> Local Interface

Serves images to

<<External System>> Vision System

Interacts <<System>>

TRCU

Controls

Locates

<<External I/O Device>>

Handling System

Move <<External System>> Vehicle

<<Actor>> Robot

Actuator

1..*1..*1..*1..* 1..*1..*1..*1..* 0000..*..*..*..*

Link Joint Sensor

1..*1..*1..*1..*

Camera

Guides & supervises

User


94

7.5.2 MODELO DINÁMICO DEL SISTEMA

El comportamiento global del sistema se puede representar como un

diagrama de estado como el de la Figura 7.4. En la misma se puede

observar que existen cinco estados principales: Inicializando, Apagando,

Error, Operacional y Configurando. Se puede apreciar que desde cualquier

estado se puede llegar al estado de Error, donde se debe solucionar el

mismo y volver al estado original. El estado Operacional del sistema es

precisamente aquel en el que el sistema puede realizar la labor para la que

ha sido diseñado.

El estado operacional se puede descomponer en los subestados que se

muestran en la Figura 7.5. Como se observa, en un estado concurrente se

distingue el movimiento del proceso de herramienta (En este caso

Manipulando). El sistema robótico puede estar en movimiento o estático y

en ambos casos puede estar realizando una tarea de manipulación o no

estarlo. Además se han adicionado algunas transiciones que invocan

alarmas; por ejemplo si es que el sistema recibe comandos, pero gracias a

las cámaras se aprecia que los comandos no están siendo realizados, debe

generarse una alarma y cancelar el comando para evitar daños en el robot.

Figura 7.4 Diagrama de Estado general del sistema

Apagando

Config

Apagar

Config

Apagar

Estado de error

Solución [prev. config]

Configurando

Solución [prev.

operacional]

Inicializando Estado de error Ok

Estado de error

Error Operacional


95

Figura 7.5 Diagrama de sub-estados del estado Operacional de la Figura 7.4

7.5.3 DIAGRAMA DE ACTIVIDADES

En esta sección se muestra la secuencia en que se realizan las operaciones

para conseguir el objetivo de esta tesis. La visión que aquí se presenta es

una visión simplificada de lo que ocurre en el proceso de exploración, que

muestra los pasos que se van realizando, usando para esto los diagramas

de actividades.

Los casos de uso que fueron descritos anteriormente como texto informal

ahora se detallan en el Diagrama de Actividades de la Figura 7.6.

En movimiento

Estático

Empezar movimiento

Parar manipulación Parar movimiento [No en manipulación]

Sin sincronización

Parar sistema/alarma

Sin sincronización

Parar sistema/alarma

Manipulando

Parado

Parar manipulación

Empezar

manipulación

Alarma crítica/Parar Manipulación


96

Figura 7.6 Diagrama de Actividades del proceso de exploración

Acrónimos

TX: Transmisión de Comandos

RX: Recepción de Comandos

TRCU: Unidad de Control Teleoperado

SM: Servicio de Monitorización

Fin del proceso

Inicio del proceso

[Ok]

[Ok] [Ok]

Falla en los servicios

Disponibles

Control de

actuadores

Enviar secuencia de

comandos

Petición de control

Esperando acuse de

recibo

Registrar Evento

TRCU

Respuesta

Parar servicios

de video y

comandos

Reiniciar

SM

Recibir secuencia de

órdenes del operador

Directiva de servicios

Reiniciar

Apagar

Parar

SM

parado

SM Ok

Reinicio

falló

Verificar estado de

servicios

Iniciar el

servicio de

monitorización

Iniciar TX y

RX de

comandos

Establecer parámetros

por defecto

Iniciar el servicio de

video

SM Ok ACK

Time out


97

7.5.4 DIAGRAMA DE COMPONENTES

En esta sección se muestran los elementos físicos del sistema y sus

relaciones (Figura 7.7), que en conjunto representan todos los tipos de

elementos software que forman parte del sistema de telecontrol.

Figura 7.7 Diagrama de Componentes

<< LAN>> << TCP/IP>> << UDP>> << TCP/IP>>

:Operador

<<component>> Generador de

comandos

<<component>> Panel de control

<<library>> jinput-dx8.dll

<<library>> jinput-raw.dll

<<library>> jinput-wintab.dll

<<component>> Modulo de

recepción de datos

:Robot

<<component>> Modulo de

envío de datos

<<component>> Modulo de transmisión multimedia

<<library>> libSerialPort.dll

<<component>> Modulo receptor

de comandos

<<library>> jpicusb.dll <<component>>

Analizador de datos

Datos del Ambiente


98

7.5.5 DIAGRAMA DE DESPLIEGUE

Tal como se mostró en la sección anterior, el software está formado por

componentes, pero ellos deben ser desplegados o implantados en algún

conjunto de hardware para su ejecución. Los componentes de la Figura 7.7

siempre correrán sobre algún equipo, ya sea este una única computadora,

una red de computadoras o en cualquier otro dispositivo. Cada parte física

en donde correrán estos componentes se denominan nodos y se muestran

en la Figura 7.8, que representa la distribución de los componentes a través

de los nodos y las relaciones entre ellos.

Figura 7.8 Diagrama de Despliegue

<<executionEnvironment>> PC Windows 7

<<executionEnvironment>> Tarjeta de Adquisición de

Datos

<<device>> Actuadores mecánicos

<<executionEnvironment>> PC Windows XP

RED DE AREA LOCAL

<<device>> Router

Inalámbrico

TCP/IP

TCP/IP

TCP/IP

RS-232/USB

SEÑALES ELÉCTRICAS

99

CAPÍTULO VIII

RESULTADOS Y CONCLUSIONES

En este capítulo se muestran los resultados obtenidos durante el proceso de

desarrollo de esta tesis, una vez implementados los elementos que forman parte

del proceso de telecontrol como el sistema de hardware, software y el protocolo.

8.1. RESULTADOS

• Aunque al principio la adquisición de video se presentó de manera muy

problemática, se logró transmitir video de cuatro cámaras diferentes

para ser utilizadas en el sistema de realimentación visual. El uso de

más de 3 cámaras web en una sola computadora genera problemas

con el ancho de banda USB por lo que se tuvo que emplear una cámara

IP.

• El tiempo que tarda el módulo GPS en converger con los satélites para

lograr la triangulación depende de las condiciones climatológicas y de la

línea de vista que tenga la antena.

• El uso de esquemas orientados a eventos también ha presentado

buenos resultados en la adquisición de temperaturas por parte del robot

móvil. En las siguientes imágenes se puede apreciar el resultado de

muestrear 1650 valores de temperatura adquiridas por el robot móvil

haciendo comparativas con tipos tradicionales de muestreo. La Figura

8.1 muestra una comparativa entre ambas formas de muestreo.


100

Figura 8.1 Comparativa de dos métodos de control: Control basado en tiempo y Control basado en eventos.

Figura 8.2 Control basado en tiempo

0

5

10

15

20

25

30

35

40

0 500 1000 1500 2000

Temperaturas

Tiempo

0

5

10

15

20

25

30

35

40

0 500 1000 1500 2000

Temperatura

Tiempo

Control basado en el tiempo Control basado en eventos con δ = 3% Control basado en eventos con δ = 5%


101

Figura 8.3 Control basado en eventos con δ = 3%

Figura 8.4 Control basado en eventos con δ = 5%

0

5

10

15

20

25

30

35

40

0 500 1000 1500 2000

Temperatura

Tiempo

0

5

10

15

20

25

30

35

40

0 500 1000 1500 2000

Temperatura

Tiempo


102

Las Figura 8.2, 8.3 y 8.4 muestran el resultado de los métodos de

control descritos en el Capítulo VI. Estas temperaturas fueron

adquiridas en un ambiente real de exploración y en función de ellas se

ha determinado que el muestreo de temperatura por control basado en

eventos produce menos cantidad de datos manteniendo la dinámica

cambiante de la variable. Sin embargo un δ = 5% no refleja el

verdadero comportamiento de la variable, sin embargo la señal

producida por un control basado en eventos con un límite δ = 3% es

similar al control clásico basado en tiempo.

• Para señales correspondientes a variables muy oscilantes, como las

provenientes del equipo de navegación GPS, se requiere de la

implementación de un esquema de control basado en tiempo.

• La modularidad en el desarrollo de componentes de hardware ha

demostrado ser el factor más importante pues, si bien es cierto que no

se puede desarrollar hardware genérico para este tipo de aplicaciones,

el uso de componentes determinados para una tarea específica hace

que el sistema de hardware tenga un cierto grado de escalabilidad que

permita ser capaz de ir de la mano frente a posibles cambios en las

tareas que un robot de exploración realizará.

• El protocolo implementado ha funcionado de manera correcta y ha

respondido a los cambios a lo largo de esta tesis ya que ha sido el

producto de un diseño previo por lo que se ha determinado que el uso

de modelos matemáticos, como máquinas de estado finito, para la

síntesis de un protocolo es de vital importancia.

• El software implementado junto a la infraestructura de red han sido

capaces de mantener un enlace de comunicación estable entre el

operador humano y la sonda de exploración.


103

8.2. CONCLUSIONES

• Las especiales características de las unidades de control de los

sistemas robóticos telecontrolados exigen un enfoque muy riguroso

para su desarrollo, ya que engloban en un solo sistema elementos

software y hardware.

• El diseño modular de los componentes de hardware es sin duda la

mejor manera de desarrollar prototipos de robots telecontrolados.

• Seguir un proceso de desarrollo incremental en la síntesis de un

protocolo es sumamente beneficioso al hacer frente a sistemas

telecontrolados ya que permite hacer frente a posibles cambios en los

datos a transmitir.

• Un esquema de control basado en eventos para los mecanismos del

robot ha mostrado mejores resultados que un esquema basado en

tiempo.

• El uso de un lenguaje de modelado como el UML es de vital

importancia, ya que sus fundamentos integran las mejores prácticas de

desarrollo de software.

8.3. RECOMENDACIONES

• Los mecanismos de control pueden ser mejorados con el uso de

codificadores rotatorios en los motores, que nos permita saber cuál es

la verdadera posición de los mecanismos y poder llevarlas a un modelo

de simulación basado en realidad virtual.

• En caso que se pierda la comunicación entre el operador humano y el

robot, este último debe tomar las medidas necesarias para tratar de

retomar el enlace perdido. Esto requiere un cierto grado de autonomía,

inclusive para regresar por el mismo camino por el que transitó, para lo

cual se necesitará lógicamente de más sensores que le permitan tomar


104

las decisiones adecuadas en un determinado ambiente. Las técnicas

empleadas pueden ir desde sencillos grafos de visibilidad para

ambientes estáticos hasta la reconstrucción de mapas en 3D

acompañados de alguna heurística para ambientes cambiantes.

• Ya que la seguridad ha sido siempre uno de los principales factores

tomados en cuenta en el desarrollo de protocolos, un buen aporte de

trabajos futuros sería la implementación de mecanismos de seguridad

que permitan llevar una comunicación entre el operador y la sonda de

exploración por un canal confiable.

105

REFERENCIAS BIBLIOGRÁFICAS

[1]. K. S. Fu, R. C. Gonzalez, C. S. G. Lee, “Robótica: Control, Visión e Inteligencia”,

Ed. McGraw-Hill.

[2]. Frédéric Giamarchi, “Robots Móviles, Estudio y Construcción”, Thomson Editores,

Madrid, España, 2000.

[3]. Antonio Barrientos, “Nuevas Aplicaciones de Robótica. Robots de Servicio”,

Departamento de Automática, Ingeniería Electrónica e Informática Industrial,

DISAM-UPM, Universidad Politécnica de Madrid, España.

[4]. Chávez Aragon J. A., “Análisis y Desarrollo de Técnicas para la Exploración de un

Ambiente Desconocido por un Robot Móvil”, Departamento de Ingeniería en

Sistemas Computacionales, Escuela de Ingeniería, Universidad de las Américas,

Puebla, México. Mayo, 2001.

[5]. Francisco José Ortiz Zaragoza, “Arquitectura de Referencia para Unidades de

Control de Robots de Servicio Teleoperados”, Universidad Politécnica de

Cartagena – Departamento de Tecnología Electrónica, España. 2005.

[6]. Andrew S. Tanenbaum, “Redes de Computadoras”, Prentice Hall Editores, Tercera

Edición, México, 1997, pág. 17-18.

[7]. “Máquinas de Estado Finito”, Universidad del Cauca, Colombia. Facultad de

Ingeniería Electrónica y Telecomunicaciones: Ingeniería de Software I.

[8]. Elmer Chuquiyauri Saldivar, “Máquinas de Estado Finito, Capítulo VIII”, Facultad

de Ingeniería, Universidad Nacional Hermilio Valdizan, Perú, pág. 3.

[9]. Willian Chen, “Discrete Mathematics: Finite State Machines”, Faculty of Science,

Macquarie University, Sidney, Australia, 2008, pág. 2-7.

[10]. Enrique Hernández Orallo, “Transmisión de datos en Tiempo Real, Síntesis de

protocolos y redes para transmisión en tiempo real”, Departamento de Informática

de Sistemas y Computadores, Universidad Politécnica de Valencia, España, 2000.

[11]. Duckett Tom, Nehmzow Ulrich, “Exploration of Unknown Environments Using a

Compass, Topological Map and Neural Network”, IEEE International Symposium

on Computational Intelligence in Robotics and Automation, Monterrey CA.

[12]. Ricardo Swain, Devy M., Stéphanie Jonquières, “Navegación de un robot móvil por

Medio de Control Visual en Ambiente Estructurado”, Laboratorio de Análisis y

Arquitectura de Sistemas, LAAS-CNRS. Tolouse, Francia. Enero, 1988.


106

[13]. András Lassó, Tamás Urbancsek, Ádám Helybély, “Microrobot teleoperation

through WWW”, Department of Control Engineering and Information Technology,

Budapest University of Technology and Economics, Hungría.

[14]. “Capítulo 1: Evolución de los Protocolos”, Ingeniería de Protocolos y Servicios,

I.T.T. esp. Telemática, España, pág. 26.

[15]. César David Alvarez Vázquez, “Análisis de Protecciones en Redes Inalámbricas

802.11 (a, b, g)”, Escuela de Ingeniería, Departamento de Ingeniería Electrónica,

Universidad de las Américas Puebla, México, 2005.

[16]. Eva Herrera-Ramírez, Arnoldo Díaz-Ramírez, Carlos T. Calafate, “Desarrollando el

estándar IEEE 802.11n, un paso adelante en WLAN”, Segundo Congreso

Internacional en Ciencias Computacionales, Baja California, México, 2007.

[17]. Mehmet Selçuk Arslan, “Improving performance of a remote robotic teleoperation

ovwer the internet”, School of Natural and Applied Sciences, Middle East Technical

University, Turkía, 2005.

[18]. Kurose, J. F. and Ross, K. W., “Computer Networking: a top down approach

featuring the Internet”, 2nd Ed., Addison-Wesley, Boston, 2003.

[19]. Jordi Prat Tasias, Antonio García Rozo, “Desarrollo de un sistema autónomo de

adquisición de datos”, Departamento de Ingeniería Electrónica, Universidad

Politécnica de Cataluña, España.

[20]. The Institute of Navigation, “Global Positioning System”, EE.UU, Editorial John

Wiley & Sons, 409 páginas, 1980.

[21]. J. Ruiz Del Solar, R. Salazar, “ROBOTS MÓVILES”, Departamento de Ingeniería

Eléctrica, Facultad de Ciencias Físicas y Matemáticas, Universidad de Chile.

[22]. A. Pawlowski, J.L. Guzmán, F. Rodríguez, M. Berenguel, “Control Basado en

Eventos de la Temperatura de un Invernadero”, Departamento de Lenguajes y

Computación, Universidad de Almería, España.

[23]. P. Ellis. “Extension of phase plane analysis to quantized systems. IRE

Transactions on Automatic Control”, 4(2):43– 54, 1959.

[24]. K. J. Astrom, “Analysis and Design of Nonlinear Control Systems, chapter Event

based control”, Springer Verlag, 2007.

[25]. Minseong Kim, Suntae Kim, Sooyong Park, “UML-Based Service Robot Software

Development: A Case Study”, Department of Computer Science, Sogang

University, Seoul, REP. of KOREA.


107

[26]. H. Gomaa, “Designing Concurrent, Distributed, and Real-Time Application with

UML”, Addison-Wesley, 2000.

[27]. Javier Yágüez, “Protocolo IPv6-ICMPv6”, Departamento de Lenguajes y Sistemas

Informáticos e Ingeniería de Software, Facultad de Informática, Universidad

Politécnica de Madrid, España, 2011.

[28]. “Manual de Usuario WireShark”, Dirección de Tecnología de Información y

Comunicaciones, Universidad Central de Venezuela, Venezuela.

108

ANEXO A

MANUAL DE USUARIO

A.1 CONFIGURACIÓN DEL GAMEPAD

El gamepad es el dispositivo de control primario del robot móvil. El software

dispone de dos métodos de control, un control usando una interfaz gráfica y

la otra usando el gamepad, sin embargo la primera forma podría acarrear

ciertos inconvenientes durante el proceso de telecontrol. Es por eso que se

diseñó el programa de tal modo que acepte el uso de un gamepad como

interfaz de entrada de directivas de control. Para su correcto funcionamiento

se deben seguir los siguientes pasos:

• Conectar el gamepad cuando el equipo esté prendido.

• En muchos casos el propio Windows detecta e instala el controlador

(la primera vez que uno conecta el periférico al sistema).

• Antes de continuar comprobar que no se trate de algún gamepad que

requiere de una conexión, y/o conectores especiales antes de

conectarlo.

• Una vez conectado el gamepad se podrá proceder a la ejecución del

programa, el cual deberá reconocer a este dispositivo.

La Figura A.1 y A.2 muestran las funciones de cada pulsador y joystick que

conforman el gamepad. Las imágenes mostradas deben ser tomadas como

referencia para cualquier tipo genérico de gamepad. Para gamepads con

ANEXO A – MANUAL DE USUARIO

109

drivers y conectores especiales se deberá seguir sus respectivos manuales

de referencia.

Figura A.1 Vista superior del gamepad

Figura A.2 Vista lateral del gamepad

Adelante

Atrás

Izquierda Derecha

Control de Tracción del Robot

Articulaciones

de la base del

brazo robótico

Articulaciones

superiores del

brazo robótico

Eje Y +

Eje Y -

Eje Z + Eje Z -

Cámara de vigilancia

Pinzas del

brazo robótico Base de la

cámara de

vigilancia

panorámica


110

A.2 INTERFACES GRÁFICAS

El software finalmente desarrollado es mostrado en las pantallas siguientes,

se tiene una pantalla principal de aplicación (Ver Figura A.3) en donde se

despliegan cuatro lienzos que muestran las imágenes de video adquiridas

por las cámaras del robot móvil, en la parte superior se encuentra una barra

de menú y otra de herramientas cuyas funciones se encuentran explicadas

más adelante.

Figura A.3 Pantalla principal del software de telecontrol

En la parte central derecha de la pantalla mostrada en la Figura A.3 se

encuentran ubicados tres paneles; el primero contiene una tabla en donde

se muestran todos los eventos ocurridos durante el proceso de telecontrol,

el segundo muestra un historial gráfico de la dinámica de cambio de las

variables de temperatura adquiridas por el robot móvil y en el tercer panel

se ubican la temperatura actual así como los datos de navegación

adquiridos por el módulo de GPS ubicado en la sonda de exploración.


111

En la parte central izquierda se ubican 4 botones que brindan acceso a las

herramientas de software utilizadas para el telecontrol de la sonda. Estas

herramientas serán descritas en las siguientes secciones.

En la parte inferior se encuentra un panel conteniendo una tabla que

muestra todo el tráfico de red, categorizando su tipo así como mostrando

datos importantes para la verificación del correcto proceso del telecontrol.

La barra de menú de la Figura A.4 contiene tres opciones que son archivo,

herramientas y servicios. La primera opción Archivo contiene una única

opción que es Salir , que sirve para terminar la ejecución del programa.

Figura A.4 Barra de menús

El menú de Herramientas de la Figura A.5 contiene todas las opciones de

conectividad y control.

El menú Parámetros de conectividad permite establecer las direcciones

IP y MAC y puertos de audio y video de la estación de telecontrol y del robot

móvil.

El menú Consola permite visualizar todas las tareas que se ejecutan en

segundo plano y es usado para determinar el estado de las variables del

programa.

El menú Control manual del robot muestra una ventana que nos permitirá

realizar el control por teclado o mouse de los actuadores de la sonda de

exploración.

El Visor de mapas satelital

para visualizar el mapa correspondiente a la posición actual del robot en

función de las coordenadas transmitidas por la sonda.

herramienta no tiene efecto alguno sobre el proceso de telecontrol y so

un agregado del software para darle

Dentro del menú Servicios

utilidad es la de iniciar el funcionamiento del sistema y todos los sub

servicios que lo componen, hay que tener en cuenta que para que el

sistema trabaje hay que tener iniciado el servicio de transferencia de video

en la sonda de exploración.

Detener servicios

servicios que han sido iniciados en el programa de telecontrol

Una barra de botones de acceso rápido localizada debajo de la barra de

menú nos permite realizar las tareas básicas de conecti

rápida. El primer botón nos permite, al igual que el menú

conectividad , establecer las direcciones y puertos, el segundo botón

permite iniciar los servicios de telecontrol como lo hace el menú


112

Figura A.5 Menú de herramientas

Visor de mapas satelital es una herramienta opcional que es usada


función de las coordenadas transmitidas por la sonda.

herramienta no tiene efecto alguno sobre el proceso de telecontrol y so

un agregado del software para darle usabilidad.

Figura A.6 Menú de servicios

Servicios se encuentran la opción Iniciar servicios

utilidad es la de iniciar el funcionamiento del sistema y todos los sub



en la sonda de exploración.

er servicios sirve para interrumpir la ejecución de las tareas

servicios que han sido iniciados en el programa de telecontrol


menú nos permite realizar las tareas básicas de conecti

El primer botón nos permite, al igual que el menú

, establecer las direcciones y puertos, el segundo botón

permite iniciar los servicios de telecontrol como lo hace el menú

MANUAL DE USUARIO

es una herramienta opcional que es usada


función de las coordenadas transmitidas por la sonda. El uso de esta

herramienta no tiene efecto alguno sobre el proceso de telecontrol y solo es

Iniciar servicios cuya

utilidad es la de iniciar el funcionamiento del sistema y todos los sub-



la ejecución de las tareas y

servicios que han sido iniciados en el programa de telecontrol.


menú nos permite realizar las tareas básicas de conectividad de manera

El primer botón nos permite, al igual que el menú Parámetros de

, establecer las direcciones y puertos, el segundo botón

permite iniciar los servicios de telecontrol como lo hace el menú Iniciar


113

servicios , el tercer botón detiene los servicios y el último botón finaliza la

ejecución del programa.

Figura A.7 Barra de herramientas

La pantalla de configuración de parámetros a la que se puede acceder

desde el menú Parámetros de conectividad es mostrada en la siguiente

figura:

Figura A.8 Pantalla de configuración de parámetros

La barra de botones del panel izquierdo (Ver Figura A.9) también nos

permite acceder a los servicios disponibles desde el menú de una manera

más rápida. El primer botón muestra la consola (Ver Figura A.10) donde se

ejecutan las tareas de segundo plano, el segundo botón muestra la interfaz

para el control de la sonda, donde existen botones para cada actuador del

robot (Ver Figura A.11), el tercer botón, como se aprecia en la Figura A.12,


114

sirve para visualizar la interfaz donde se despliegan los mapas del área en

donde se encuentra el robot, y el cuarto botón es para mostrar el estado de

los servicios.

Figura A.9 Botones de acceso rápido

Figura A.10 Consola

La interfaz de la Figura A.11 muestra los controles de los actuadores del

robot móvil. Este tipo de control es auxiliar al que puede ser realizado por el

gamepad y en caso de no disponer de uno, el control mediante este panel

es la única forma de enviar comandos hacia la sonda de exploración.


115

Figura A.11 Interfaz de control del robot

Como se mencionó al principio de esta tesis, el telecontrol del robot móvil

no depende de servicios externos, sin embargo de existir una conexión a

internet se podrá visualizar los mapas de acuerdo con las coordenadas que

se obtengan del módulo de navegación, pero la ausencia de la misma no

afecta el telecontrol del robot ni tampoco su rendimiento. La Figura A.12

muestra la interfaz en donde se despliega el mapa así como la posibilidad

de realizar zoom al mismo.


116

Figura A.12 Pantalla de localización satelital

La barra de botones del panel izquierdo (Ver Figura A.9) también nos

permite acceder a los servicios disponibles desde el menú de una manera

más rápida. El primer botón muestra la consola (Ver Figura A.10) donde se

ejecutan las tareas de segundo plano, el segundo botón muestra la interfaz

para el control de la sonda, donde existen botones para cada actuador del

robot (Ver Figura A.11), y el tercer botón, como se aprecia en la Figura

A.12, sirve para visualizar la interfaz donde se despliegan los mapas del

área en donde se encuentra el robot.

Las interfaces gráficas del software que se ejecuta en el lado de la sonda

de exploración se muestran en la Figura A.13. En esta pantalla se deberán

especificar las direcciones IP y MAC de la estación de telecontrol así como

los puertos de audio y video (que deberán ser los mismos que se han

especificado en la estación remota). Luego de esto se deberá hacer clic en

el botón Iniciar previa conexión de todos los dispositivos como el sistema de

hardware vía USB y el módulo de navegación GPS vía cable serial.


117

Figura A.13 Interfaces del software del robot móvil

El panel con los botones que se aprecian en la figura anterior corresponden

a un panel de pruebas el cual sirve para verificar el correcto funcionamiento

de los actuadores del robot móvil. El área de texto en la parte superior sirve

para mostrar las tramas adquiridas por el módulo de navegación GPS

mientras que el área en blanco de la parte inferior muestra las tramas en

texto plano conforme se va realizando el proceso de telecontrol.

118

ANEXO B

IMÁGENES DEL ROBOT DE EXPLORACIÓN

Figura B.1 Diagrama esquemático del circuito de control

ANEXO B – IMÁGENES DEL ROBOT DE EXPLORACIÓN

119

Figura B.2 Pinzas del sistema de manipulación

Figura B.3 Manipulador de 4 grados de libertad


120

Figura B.4 Hardware de telecontrol del robot de exploración

Figura B.5 Estación de telecontrol


121

Figura B.6 Robot GERO II

122

ANEXO C

HERRAMIENTAS PARA EL ANÁLISIS DE LA RED

C.1 INTERNET CONTROL MESSAGE PROTOCOL (ICMP) [27]

ICMP es el protocolo de envío de mensajes de control en Internet y está tan

íntimamente ligado al protocolo IP, que de hecho se puede ver como un

módulo más dentro del propio módulo o proceso IP. Los mensajes de

control ICMP en Internet están relacionados con errores, información y

diagnósticos. El destino de un mensaje ICMP de errores es siempre la

máquina de origen del datagrama en cuestión. Nunca se transmite un

mensaje ICMP de errores entre enrutadores o sistemas intermedios. Se

recuerda que un mensaje ICMP se utiliza para enviar mensajes de control o

aviso y no para hacer más fiable al protocolo IP, el cual jamás podrá

recuperar un datagrama.

Figura C.1 Ejemplo de envío de un paquete ICMP

R1 A

R3 no puede entregar el datagrama

a B por una mala configuración de

su tabla de enrutamiento

El mensaje ICMP se

envía al origen A R2

R4

R5

B R3

ANEXO C – HERRAMIENTAS PARA EL ANÁLISIS DE RED

123

La anterior Figura C.1 muestra un ejemplo del envío de un datagrama IP

desde la máquina “A” a la máquina “B”. El enrutadores R3 no dispone de

suficiente información en su tabla de enrutamiento y es incapaz de

encaminar dicho datagrama al destino “B” en cuestión. Consecuentemente,

R3 elimina el datagrama y envía un mensaje ICMP a la máquina de origen

“A”. El datagrama que encapsula dicho mensaje, incluso, no tiene por qué ir

por el mismo itinerario de enrutadores que el datagrama inicial.

Como la máquina de origen a la cual va destinado un mensaje ICMP puede

ser una máquina remota por Internet, los mensajes ICMP se encapsulan

siempre en datagramas IP. De ahí que ICMP ocupe un subnivel superior al

ocupado por el protocolo IP en el mismo nivel de Internet o red de la

arquitectura TCP/IP.

C.2 PING [17]

La herramienta de software más útil para probar operaciones en red al nivel

IP es el Ping. El ping es la aplicación más simple sobre TCP/IP. Este envía

datagramas IP a un destino específico y mide el tiempo de ida y vuelta para

recibir una respuesta. Ping es usado por el protocolo ICMP para determinar

si un host es inalcanzable en una red. Ya que ICMP es requerido en todas

las implementaciones de TCP/IP, los hosts no requieren un servidor

separado para responder a las peticiones de un ping. Algunas propiedades

que poseen los ping son las siguientes:

• Ping coloca un único número de secuencia a cada paquete que

transmite, e informa qué secuencia de número recibe de vuelta. Por lo

tanto, se puede determinar si los paquetes han sido eliminados,

duplicados o reordenados.

• Ping coloca una marca de tiempo en cada paquete, que es enviada de

vuelta, y puede fácilmente ser usada para computar cuanto tomó cada


124

intercambio de paquetes. A este valor se le conoce como RTT (Round-

Trip delay Time).

• Ping reporta si un enrutador de la red está declarando un host como

inaccesible.

• Algunos enrutadores pueden descartar silenciosamente paquetes que

no fueron entregados. Eso es especialmente común sobre internet ya

que no provee acuses de recibo a nivel de capa de enlace, por lo tanto

el ping no siempre proporciona razones por las cuales un paquete no

recibió una respuesta.

• Ping no declara por qué un paquete fue dañado, retrasado o duplicado.

Tampoco se puede declarar dónde ocurrió esto.

• Ping no proporciona información sobre los eventos ocurridos sobre el

paquete a lo largo de su camino.

C.3 WIRESHARK [28]

Es una herramienta gráfica utilizada por los profesionales y/o

administradores de la red para identificar y analizar el tipo tráfico en un

momento determinado. También denominado analizador de protocolos de

red, analizador de paquetes, packet sniffer o sniffer, Wireshark permite

analizar los paquetes de datos en una red activa como también desde un

archivo de lectura previamente generado

El proceso de instalación sigue los siguientes pasos:

1. Una vez que se obtiene el instalador desde

http://www.wireshark.org/download.html se ejecuta el archivo wireshark-

setup-1.0.0.exe (en este caso la versión es 1.0.0) para iniciar la


125

instalación. Es importante mencionar que las librerías necesarias como

WinPcap están incluidas en el instalador.

Se muestra la siguiente pantalla del asistente:

Figura C.2 Inicio del asistente de instalación

2. Presionando el botón se despliega la especificación de la

licencia y al presionar el botón se despliega la siguiente

ventana para seleccionar los componentes que se desean instalar.

Figura C.3 Componentes disponibles para su instalación


126

3. La siguiente pantalla permite seleccionar si se desea crear un acceso

directo a la aplicación en el escritorio, crear un menú de inicio y visualizar

el icono en la barra de tareas. Adicionalmente se tiene la posibilidad de

permitir, que los archivos generados por otros analizadores de tráfico

puedan ser visualizados con Wireshark (opción que debemos

seleccionar).

Figura C.4 Pantalla para la selección de accesos directos

4. A continuación se deberá seleccionar el directorio donde se instalará la

aplicación, en este punto se acepta el indicado por defecto en el

instalador.

El instalador de WireShark contiene una versión de WinPcap que verifica

si se debe actualizar versión de la computadora donde se está realizando

la instalación y ofrece la opción de agregar un servicio para que usuarios

que no tienen privilegios de administrador puedan capturar paquetes. En

este punto se seleccionan ambos ítems.


127

Figura C.5 Ventana de selección del directorio de instalación

Se presiona el botón para iniciar el proceso de instalación.

Figura C.6 Proceso de instalación iniciado

5. Como se mencionó anteriormente el instalador de WireShark para

Windows permite hacer la instalación de las librerías, plugins, servicios,

etc. Particularmente para el caso de WinPcap se interrumpe la

instalación en el punto que muestra en la Figura C.6 e inicia el asistente


128

para la instalación de WinPcap. Se debe seleccionar hasta

finalizar la instalación.

Figura C.7 Ventana para la instalación de componentes adicionales

Figura C.8 Finalizando la instalación de Wireshark


129

La siguiente pantalla indica que la instalación ha finalizado exitosamente.

Figura C.9 Proceso de instalación finalizado