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
enrutador y una unidad remota a una distancia media de 20
metros sin línea de vista…………………………………………… 26
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
de 20 metros sin línea de vista entre un enrutador y una unidad
remota………………………………………………………………….. 26
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.

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.
1

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

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]
.

2


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.

3


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.

4


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

5


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).

4000000
Número de Unidades

3000000
2000000
1000000
0
Entretenimiento
Uso Profesional Uso Doméstico
personal
Número de Robots
49000 3400000 2000000
vendidos
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.

6


14000

Número de unidades
12000
10000
8000
vendidas 6000
4000
2000
0
Defe Aplic Cons Relac
Agric
nsa y Limpi acion trucc Medi Logís Inspe iones
ultur
Segu eza es ión y cina tica cción Públi
a
ridad sub… De… cas
Robots de Uso Profesional 12008 9800 6000 6000 4500 4500 2019 1079 130
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

7


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.

14000000
Número de unidades

12000000
10000000
8000000
6000000
4000000
2000000
0
Uso Personal y Tareas
Uso Profesional
Entretenimiento Domésticas
1995-2007 49000 3400000 2000000
2008-2010 103000 12100000 6600000
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.

8


Hogar; 1 Servicio de
Hoteles; 5 Oficina y
Logística; 10
Cuidado de
Enfermos; 10

Construcción; 54 Medicina y
Rehabilitación; 3

Servicios de
Control de
Comunidad; 10
Desastres y
Emergencias; 7

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

1.9. ORGANIZACIÓN DE LA TESIS

Capítulo I
Introducción

Desarrollo Teórico Desarrollo de Sistemas

Capítulo II Capítulo VII
Marco Teórico Análisis y diseño del
Software

Capítulo IV
Capítulo VI Implementación Arquitectura Hardware
Arquitectura de Teleoperación
de Teleoperación
Control de Red
Implementación
Diseño Top-Down
Down Diseño Top-Down
Experimentos Capítulo V
Síntesis del Protocolo

Capítulo III Diseño Top-Down
Enlace de
Comunicación

Capítulo VIII
Resultados y
Conclusiones

Figura 1.5 Organización de esta tesis

9

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].

10


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
[4]
frecuencia son de naturaleza no industrial . 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.

11


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.

12


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.

13


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 ENTRADA SALIDA ESTADO
ACTUAL 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

14


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.
15


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

16


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
Indica si existe información adicional al final del
Padding (P) paquete. Esta información puede ser útil para los 1
algoritmos de encriptación.
Extension (X) Indica si a continuación viene una cabecera de 1
extensión.
CSRC count (CC) Número de identificadores CSRC que siguen a la 4
cabecera fija.
Marker (M) Está indicada para señalar eventos especiales como 1
salirse de los límites.
Payload type (PT) Formato de la información que se transporta para que
lo interprete la aplicación. 7
Número Se incrementa en uno por cada paquete envía, y sirve
secuencia 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 32
del paquete.
Contributing Source Identifiers. Esta información es
CSRC list introducida por los mezcladores para indicar que han 32
contribuido a modificar la información.

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

17


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
[11]
todo momento conocer su posición dentro del ambiente . 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

18


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
[5]
con el robot sin la necesidad de conocer su estructura interna , tal como
se puede ver en la Figura 2.4.

Sistemas de Alto Nivel Middleware
(Software)
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

19


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

20


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, Paquetes de pequeño tamaño,
Datos de Configuración) 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 Paquetes de pequeño tamaño,
posiciones) requieren transferencias periódicas en
tiempo real, la pérdida de paquetes
puede ser aceptable.
Datos de Audio y Video (Retransmisión visual Requiere ancho de banda
desde el robot) 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

21

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.

22


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 54 11 54 600
(Mbps)
OFDM DSS DSSS DSSS
Modulación OFDM CCK CCK CCK
CCK OFDM OFDM
Banda (GHz) 5 2.4 2.4 2.5 o 5
Nº de Flujos 1 1 1 1a4
Canal (MHz) 20 20 20 20 o 40

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

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

23


retardos [17]. La suma de estos retardos constituye el retardo total nodal y se
muestra en la Figura 3.1.

Enrutador A Unidad Remota

Procesamiento Nodal Colas Transmisión Propagación

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

24


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].

(segundos)
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 26 Paquetes 26 Paquetes 0
enviados recibidos perdidos
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.

25


(segundos)
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.

Total de paquetes perdidos (1% perdidos)

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.

(segundos)
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


Total de paquetes perdidos (29%
perdidos)

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

27


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.

28

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].

29


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.

30


Estación de Telecontrol
Interfaz
Hombre-Máquina

Dispositivo de
Interfaz de Bus Serial Universal
Teleoperación *USB: Bus Serial Universal.
*NMEA: Protocolo
estándar usada por
receptores de GPS.

Conexión de Área Local
Enrutador
(Capa Física)

Protocolo 802.11

Unidad Remota
Unidad Remota de Controladora del
Procesamiento Robot

Actuadores
Dispositivos de
de Módulo orientación y
USB*
Adquisición RS-232 de GPS movimiento
(NMEA*)
de
Audio/Video

Bus Interno
USB*

Tarjeta de Adquisición
de Datos

Etapa de
Microcontrolador Bus Interno
Sensores de Bus Interno
Potencia
Temperatura (H-Bridge)

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

31


juego para realizar las diversas acciones necesarias para cumplir los
objetivos.

Figura 4.2 El gamepad como dispositivo de interfaz de teleoperación. Izquierda:
teleoperación
Disposició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 de telecontrol al ser un dispositivo
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. Otra ventaja
que permite su uso es el de poder procesar múltiples entradas a la vez, por
e
lo que diversos mecanismos podrán ser movidos o rotados a la misma vez.

4.2.1. INTERCONEXIÓN DEL GA
GAMEPAD CON JAVA

En esta sección se explicará cómo el gamepad ha sido conectado
satisfactoriamente con una aplicación en Java.

JInput es una Interfaz de Programación de Aplicaciones (API) para la
visualización y control de dispositivos de entrada que van desde el conocido
teclado hasta los populares joysticks e incluso gamepads. Sin embargo, a
pesar de la portabilidad y flexibilidad que ofrece esta API, el uso de este
API
dispositivo ha tenido que seguir un proceso de selección cuidadoso
verificando dos factores importantes que son:

32


• 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

33


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

34

Tesis de grado

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Tesis de grado

Similaire à Tesis de grado (20)

Plus de Rolando Palermo Rodríguez Cruz

Plus de Rolando Palermo Rodríguez Cruz (8)

Dernier

Dernier (20)

Tesis de grado